我们在什么情况下需要发起HTTP请求呢？一般来讲，说完TCP三次握手之后就可以上菜了。今天复习的时候突然看到一篇帖子，说现在面试不问八股文了，换句话说就是八股文对面试没帮助了，心里不禁一阵恐慌，但是细想想，八股文真的没用吗？什么是八股文？有的人理解的八股文是单纯应付面试，有的人是借机系统化整理零碎的知识，这么多天复习下来，结合以前的开发经验，本豆认为八股文很有必要啊，比如页面频繁跳登录的问题迟迟不得解决，完全是一头懵找不到思路，但如果能整理下八股文，多深入了解下http以及浏览器相关的知识，从这个角度去分析那解决起来不是轻轻松松，扯远了，一句话总结就是多了解下八股文周边对实际开发还是很有必要的~ 想了解更多上下游周边本豆来个任意穿梭门：
- HTTP概述：
HTTP是一种能够获取如HTML这样的网络资源的通讯协议，是基于客户端和服务端的进行数据交换架构模型，是通过一个可靠的链接来交换信息，是一个无状态的请求/响应协议。
- HTTP特征：
- http是无连接的。限制每次连接只处理一个请求，由客户端发起，服务端处理完之后随即断开连接。这里结合iso七大层，我理解HTTP和TCP的关系类同于装修和房子的关系，没有房子何谈装修，TCP属于传输层，是应用层http的基础，就http本身而言是不考虑传输层的，即使后边http有长连接，也只是可设置过期时间罢了，本质上还是要断开的，这里容易搞混，理解有误的地方欢迎批评指正~继续
- http是可扩展的。在 HTTP/1.0 中出现的 HTTP headers 让协议扩展变得非常容易。只要服务端和客户端就新 headers 达成语义一致，新功能就可以被轻松加入进来
- HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快，使用Cookies可以创建有状态的会话
- HTTP消息结构
- 客户端请求消息：
- 服务器响应消息：
- HTTP请求方法
1.0定义了三种请求办法：GET、POST、HEAD 1.1新增了五种请求方法：OPTIONS、PUT、DELETE、TRACE、CONNECT
| 方法 | 描述 |
|---|---|
| GET | 用于获取目标资源 |
| HEAD | 和GET相似但是返回信息中只包含头部信息 |
| POST | 对目标资源提交数据并且修改返回结果 |
| PUT | 客户端向服务器传送的数据取代指定的文档的内容 |
| DELETE | 删除对应资源 |
| CONNECT | HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器，主要使用SSL和TLS将数据加密后通过网络隧道进行传输，这就设计我的iso知识盲区了。。以后再研究 |
| OPTIONS | 使服务器传回该资源所支持的所有HTTP请求方法。用 * 来代替资源名称，向 Web 服务器发送 OPTIONS 请求，可以测试服务器功能是否正常运 |
| TRACE | 回显服务器收到的请求，主要用于测试或诊断 |
实际开发中最常用的是GET和POST方法，resful接口一般用GET、POST、PUT、DELETE方法来分别对应增删改查 *RESTful是一种软件架构风格，主要是为了简化互联网应用的开发和交互过程，简单来说，就是使用HTTP方法（GET、POST、PUT、DELETE等）来操作服务器上的资源。每个方法代表不同的操作，使得接口易于理解和使用。
- HTTP 首部
分为通用首部、请求首部、响应首部和实体首部四种：
- 1.通用首部：提供了报文相关的基本信息，请求和响应都可用
- 请求首部：补充了请求的附加内容，客户端信息，响应内容相关优先级等信息
- 响应首部：补充了响应的附加内容，也会要求客户端附加额外的内容信息
- 实体首部：补充了资源内容的更新时间等与实体有关的信息
- 还有些报文字段不是HTTP协议中的，但是被广泛的应用在HTTP请求中
1.通用首部字段
| 首部字段 | 说明 |
|---|---|
| Cache-Control | 用于指定资源的缓存策略。它可以控制浏览器和其他中介缓存如代理服务器的行为：max-age: 资源将在多少秒后失效，s-maxage: 和 max-age 类似，但是用于共享缓存（如代理服务器），public: 资源可以被任何缓存所缓存，包括公有缓存和私有缓存，private: 资源只能被单个用户的缓存所缓存，不允许被共享缓存，no-cache: 需要进行缓存验证，no-store: 不允许缓存任何版本的资源 |
| Connection | 主要涉及到长连接和短连接的概念。在HTTP/1.1协议中，Connection头部字段用于控制客户端和服务器之间的连接状态。长连接（也叫持久连接）允许在请求或响应的数据传输完成后，连接不被断开，后续的请求或响应可以继续使用这个连接，这样可以减少资源消耗和缩短响应时间。长连接通过Connection: keep-alive来开启，而短连接则通过Connection: close来指示连接在数据传输完成后应被关闭。在HTTP/1.1中，长连接是默认开启的。客户端和服务器还可以通过Keep-alive: timeout=value来设置长连接的超时时间，但这一设置并不总是被严格遵守 |
| Date | 创建HTTP报文的日期和时间 |
| Pragma | Http/1.1之前的历史遗留字段，仅作为HTTP/1.0向后兼容而定义，虽然是通用字段，当通常被使用在客户单的请求中，如Pragma: no-cache, 表示客户端在请求过程中不循序服务端返回缓存的数据 |
| Trailer | 它允许在HTTP消息发送完成后，通过附加的方式提供额外的信息，这对于某些需要发送后处理状态或元数据的场景非常有用 |
| Transfer-Encoding | HTTP的Transfer-Encoding头部字段用于指定传输报文主体时采用的编码方式。当这个字段出现在HTTP头部中时，它通常表明实体内容将由多部分组成，每部分有自己的Content-Type和Content-Length，并且这些部分之间用一个特殊的边界进行分隔。常见的Transfer-Encoding值有：chunked。当使用chunked编码时，传输的内容分为多个块，每个块都会标记它的大小，最后一个块只是一个大小为0的块，表示数据发送结束。 |
| Upgrade | HTTP Upgrade是一种机制，允许客户端在同一个TCP连接上请求从HTTP协议升级到另一种协议。这通常用于实现长轮询、WebSocket通信等实时通信方法。在HTTP Upgrade过程中，客户端发送一个包含Upgrade头的HTTP请求到服务器，请求服务器使用另一个协议来处理该连接。如果服务器同意升级，它会返回一个101 Switching Protocols的响应，表示协议已经改变，此时连接可以用新协议进行通信。 |
| Via | 用于追踪请求和响应在传输过程中经过的代理服务器信息。这个字段由代理服务器自动添加和更新，每经过一个代理服务器，代理服务器会在Via头部添加自己的信息，包括协议版本、代理服务器地址、端口号以及可能的注释。Via头部的存在允许客户端和服务器了解请求和响应的传输路径，包括经过的代理服务器和它们的顺序，这对于识别问题、优化性能和确保协议遵从非常有帮助。此外，Via头部还能用于防止请求或响应在代理服务器之间发生循环转发的情况，避免请求和响应在代理服务器之间无限循环下去 |
| Warning | Http/1.1的报文字段，从Http/1.0的AfterRetry演变而来，用来告知用户一些与缓存相关的警告信息 |
2.请求首部字段
| 首部字段名 | 说明 |
|---|---|
| Accept | 客户端能够处理的媒体类型 |
| Accept-Charset | 表示客户端支持的字符集。例如：Accept-Charset: GB2312, ISO-8859-1 |
| Accept-Encoding | 表示客户端支持的内容编码格式。如：Accept-Encoding：gzip |
| Accept-Language | 表示客户端支持的语言。如：Accept-Language: zh-cn, en |
| Authorization | 表示客户端的认证信息。客户端在访问需要认证的也是时，服务器会返回401，随后客户端将认证信息加在Authorization字段中发送到服务器后，如果认证成功，则返回200 |
| Host | 表示访问资源所在的主机名，即URL中的域名部分。如：m.baidu.com |
| If-Match | If-Match的值与所请求资源的ETag值（实体标记，与资源相关联。资源变化，实体标记跟着变化）一致时，服务器才处理此请求 |
| If-Modified-Since | 用于确认客户端拥有的本地资源的时效性 |
| If-None-Match | If-Match的值与所请求资源的ETag值不一致时服务器才处理此请求 |
| If-Range | If-Range的值（ETag值或时间）与所访问资源的ETag值或时间相一致时，服务器处理此请求，并返回Range字段中设置的指定范围的数据。如果不一致，则返回所有内容。If-Range其实算是If-Match的升级版，因为它的值不匹配时，依然能够返回数据，而If-Match不匹配时，请求不会被处理，需要数据时需再次进行请求 |
| If-Unmodified-Since | 与If-Modified-Since相反，表示请求的资源在指定的时间之后未发生变化时，才处理请求，否则返回412 |
| Max-Forwards | 表示请求可经过的服务器的最大数目，请求每被转发一次，Max-Forwards减1，当Max-Forwards为0时，所在的服务器将不再转发，而是直接做出应答。通过此字段可定位通信问题 |
| Proxy-Authorization | 当客户端接收到来自代理服务器的认证质询时，客户端会将认证信息添加到Proxy-Authorization来完成认证。与Authorization类似，只不过Authorization是发生在客户端与服务端之间 |
| Range | 获取部分资源，例如：Range: bytes=500-1000表示获取指定资源的第500到1000字节之间的内容，如果服务器能够正确处理，则返回206作为应答，表示返回了部分数据，如果不能处理这种范围请求，则以200作为应答，返回完整的数据 |
| Referer | 告知服务器请求是从哪个页面发起的 |
| User-Agent | 将发起请求的浏览器和代理名称等信息发送给服务端 |
| Cookie | 在请求时添加Cookie, 以实现HTTP的状态记录 |
3.响应首部字段
| 首部字段 | 说明 |
|---|---|
| Accept-Ranges | 用于告知客户端资源是否可以被范围请求（分段请求），它主要用于支持断点续传，即客户端可以请求资源的某一部分 |
| Age | 用于指示从服务器创建响应到现在经过的时间，单位为秒。这个时间包括了响应在网络中的传输时间以及在代理服务器上的缓存时间。当响应通过代理服务器传输时，Age头部会记录响应在网络中停留的总时间，帮助判断响应的新鲜度或是否仍然可用 |
| ETag | ETag的值通常在HTTP响应头中传递给客户端，客户端在后续的请求中通过If-None-Match头部将之前接收到的ETag发送回服务器，服务器比较这两个ETag是否一致来判断资源是否发生变化。如果ETag没有改变，则返回状态码304，表示资源未变化，客户端可以继续使用本地缓存；如果ETag改变了，则返回状态码200，表示资源已更新，需要从服务器获取新的资源内容 |
| Location | 它主要用来告诉客户端（通常是浏览器）如何重定向到另一个URL。当服务器想要将客户端从一个URL重定向到另一个URL时，它会通过在响应中包含Location头部来实现这一点。这个头部通常与HTTP重定向状态码（如301或302）一起使用，指示客户端进行页面跳转 |
| Proxy-Authenticate | 它用于将由代理服务器所要求的认证信息发送给客户端。这个过程与客户端和服务器之间的HTTP访问认证行为相似，但区别在于其认证行为是在客户端与代理之间进行的。当客户端需要通过代理服务器访问某个需要认证的资源时，代理服务器会通过Proxy-Authenticate头部告知客户端需要进行何种认证，例如使用Basic认证并提供用户名和密码。客户端在收到这个提示后，需要按照代理服务器的要求准备相应的认证信息，并将这些信息放在Proxy-Authorization头部中，然后发送给代理服务器进行验证。如果代理服务器认为客户端提供的认证信息正确，则允许客户端通过代理访问目标资源；否则，代理服务器可能会要求客户端重新提供正确的认证信息 |
| Retry-After | 用于指示客户端在发送请求之前应该等待一段时间。 当服务器因为某些原因（如过载或维护）无法立即处理请求时，它会通过返回一个带有Retry-After头部的响应来告诉客户端稍后再试。这个头部可以指定一个具体的时间点或者等待的秒数，以便客户端知道何时再次尝试请求，一般涉及503和3XX两种情况 |
| Server | 用于向客户端表明提供响应的服务器信息。这包括服务器的类型、版本以及其他可能的相关信息。通过这个字段，服务器可以告知客户端关于其自身的一些基本信息，这对于客户端进行服务器性能分析、故障排查或者进行特定的服务器优化可能有所帮助。例如，如果客户端需要了解特定服务器的性能特点或者是否存在某些特定的bug，Server字段可以提供必要的参考信息。此外，对于开发人员来说，通过分析Server字段，可以了解哪些服务器软件在实际生产环境中被广泛使用，从而为未来的开发或优化提供方向。需要注意的是，虽然Server字段可以提供有关服务器的信息，但出于安全和隐私的考虑，某些服务器可能会选择不包含此字段或者使用通用的字符串以避免暴露过多的服务器细节给潜在的攻击者。因此，虽然Server字段对于合法用户和开发人员可能有一定的价值，但在设计和配置服务器时，也需要考虑到安全性和隐私保护的平衡 |
| Vary | 当缓存服务器收到一个请求，只有当前的请求和原始（缓存）的请求头跟缓存的响应头里的Vary都匹配，才能使用缓存的响应 |
| WWW-Authenticate | 于表示资源访问时需要的认证信息。当客户端请求一个受密码保护的网页，如果服务器判断客户端没有提供认证信息或认证失败，服务器会返回401状态码和WWW-Authenticate首部，提示客户端提供用户名和密码。WWW-Authenticate首部的一般格式如下： WWW-Authenticate: <认证方式> realm="<域名>", 其中<认证方式>可以是Basic、Digest、Bearer等，<域名>是需要认证的服务器区域或资源 |
| Set-Cookie | 用于在HTTP服务器上设置一个Cookie。它在服务器响应的头部中发送，在客户端请求的头部中传回服务器。Set-Cookie 首部字段在服务器端创建一个cookie，在客户端则通过 Cookie 首部字段将cookie返回服务器 |
4.实体首部字段
| 首部字段 | 说明 |
|---|---|
| Allow | 用于列出资源支持的 HTTP 方法。当客户端发送的请求方法在服务器上不被允许时，服务器可以通过这个首部字段告诉客户端支持哪些方法。例如，当客户端尝试使用不被允许的方法（如 PUT）向只接受 GET 请求的资源发送请求时，服务器可以返回一个状态码 405 Method Not Allowed，并在 Allow 字段中指出允许的方法，如 Allow: GE |
| Content-Encoding | 用于指示接收方如何解码实体内容数据。该字段值通常指示实体使用的压缩或编码方式。常见的Content-Encoding值包括gzip、compress、deflate、br（Brotili）等 |
| Content-Language | 用于指定资源的自然语言，同时允许客户端指示自己的语言偏好。该首部字段可以在响应中使用，也可以在请求中使用，以便指示服务器期望的语言 |
| Content-Length | 用于指示 HTTP 消息实体的传输长度 |
| Content-Location | HTTP 实体首部字段 Content-Location 用于指定资源的原始位置，当响应码为 300 系列时，该字段会被用来指示资源现在所在的位置。如果响应码不是重定向状态，则该字段可用来指示请求的资源在服务器上的具体位置 |
| Content-Type | 用于指示资源的媒体类型（即MIME类型）。它告诉客户端实体主体的数据类型 |
| Expires | 是用来控制缓存的失效日期。Expires是HTTP/1.0**协议中和网页缓存相关的一个字段，它用来告诉缓存服务器相关副本在多长时间内是新鲜的。过了这个时间，缓存服务器就会向源服务器发送请求，检查文档是否被修改。Expires字段的值是一个特定的日期和时间，表示资源过期的时间点，超过这个时间点后，缓存服务器在接收到请求时将不再使用本地缓存的资源，而是向源服务器请求新的资源。Expires字段的设置对于静态资源如图片、CSS、JavaScript文件等特别有用，因为这些文件更新频率较低，可以设置一个较长的过期时间，从而减少用户每次访问时都需要从源服务器下载相同资源的需求，提高网站的访问速度和性能。然而，需要注意的是，Expires字段有一个局限性，即它只能设置一个固定的过期时间，而不能根据资源的实际更新情况动态调整。因此，当HTTP/1.1引入Cache-Control**头后，Expires字段的地位逐渐被取代，因为Cache-Control提供了更灵活和强大的缓存控制机制。尽管如此，Expires字段在早期的HTTP缓存管理中仍然扮演着重要的角色 |
| Last-Modified | 它指明资源最后修改的时间 |
5.其他报文字段
- X-Frame-Options：首部字段X-Frame-Options属于HTTP响应首部 用于控制网站内容在其他Web网站的Frame标签内的显示问题，主要目的是为了防止点击劫持攻击
- X-XSS-Protection：首部字段X-XSS-Protection属于HTTP响应首部 针对跨站脚本攻击的一种对策,用于控制浏览器XSS防护机制的开关
- DNT(Do Not Track)：拒绝个人信息被收集,表示拒绝被精准广告追踪的一种方法
-HTTP返回状态码
| 状态码 | 类别 | 分类描述 |
| 1XX | Informational（信息性状态码） | 请求正在被处理 |
| 2XX | Success（成功状态码） | 请求处理成功 |
| 3XX | Redirection（重定向状态码） | 需要进行重定向 |
| 4XX | Client Error（客户端错误状态码） | 服务器无法处理请求 |
| 5XX | Server Error（服务器错误状态码） | 服务器处理请求时出错 |
1. 信息响应
| 状态码 | 字段 | 含义 |
| 100 | Continue | 继续，客户端应继续其请求 |
| 101 | Switching Protocols | 切换协议，只能切换到更高级的协议 |
2. 成功响应
| 状态码 | 字段 | 含义 |
| 200 | OK | 请求成功，一般用于GET与POST请求 |
| 201 | Created | 已创建，成功请求并创建了新的资源 |
| 202 | Accepted | 已经接受请求，但未处理完成 |
3. 重定向
| 状态码 | 字段 | 含义 |
| 300 | Multiple Choices | 多种选择，请求的资源可包括多个位置 |
| 301 | Moved Permanently | 永久移动 |
| 302 | Found | 临时移动，GET 或者 HEAD 请求 |
| 303 | See Other | 查看其它地址，与302类似。需使用GET请求查看 |
| 304 | Not Modified | 未修改，服务器返回此状态码时，不会返回任何资源 |
| 307 | Temporary Redirect | 临时重定向，不该改变请求方法 |
4. 客户端错误
| 状态码 | 字段 | 含义 |
| 400 | Bad Request | 客户端请求的语法错误，服务器无法理解 |
| 401 | Unauthorized | 请求要求用户的身份认证 |
| 402 | Payment Required | 保留，将来使用 |
| 403 | Forbidden | 服务器理解请求客户端的请求，但是拒绝执行此请求 |
| 404 | Not Found | 服务器无法根据客户端的请求找到资源（网页） |
| 405 | Method Not Allowed | 客户端请求中的方法被禁止 |
5. 服务器错误
| 状态码 | 字段 | 含义 |
| 500 | Internal Server Error | 服务器内部错误，无法完成请求 |
| 501 | Not Implemented | 服务器不支持请求的功能，无法完成请求 |
| 502 | Bad Gateway | 从远程服务器接收到了一个无效的响应 |
| 503 | Service Unavailable | 服务器暂时的无法处理客户端的请求 |
| 504 | Gateway Time-out | 未及时从远端服务器获取请求 |
| 505 | HTTP Version not supported | 服务器不支持请求的HTTP协议的版本，无法完成处理 |
HTTP内容类型
Content-Type，内容类型，一般是指网页中存在的Content-Type，用于定义网络文件的类型和网页的编码，决定浏览器将以什么形式、什么编码读取这个文件。
- 常见的媒体类型： 文本文件：text/html, text/plain, text/css, application/xml 图片文件：iamge/jpeg, image/gif, image/png; 视频文件：video/mpeg 应用程序使用的二进制文件：application/octet-stream, application/zip
- 常用的内容编码： gzip: 由文件压缩程序gzip生成的编码格式； compress: 由Unix文件压缩程序compress生成的编码格式； deflate: 组合使用zlib和deflate压缩算法生成的编码格式； identity：默认的编码格式，不执行压缩
HTTP Cookie
- Cookie主要用于以下三个方面：
- 会话状态管理
- 个性化设置
- 浏览器跟踪行为（mark住，不大理解）
- Cookie应知道：
- 会话期cookie在浏览器关闭即结束
- 持久性cookie可以指定过期时间(Expires)或者有效期(Max-Age)
- 安全性
- 标记为Secure的Cookie只能通过https加密传给服务端
- 为避免XSS攻击，标记为Secure的Cookie通过Documnent无法访问，只能发送给服务端
- Cookie的作用域 Domain 和 Path 标识定义了Cookie的作用域：即Cookie应该发送给哪些URL
HTTP1.x的连接管理
连接管理是一个 HTTP 的关键话题：打开和保持连接在很大程度上影响着网站和 Web 应用程序的性能。在 HTTP/1.x 里有多种模型： 长连接, 和 HTTP 流水线以及关于优化的域名分片。
- 短连接：每一个 HTTP 请求都由它自己独立的连接完成；这意味着发起每一个 HTTP 请求之前都会有一次 TCP 握手，而且是连续不断的。
- 长连接：一个长连接会保持一段时间，重复用于发送一系列请求，节省了新建 TCP 连接握手的时间，还可以利用 TCP 的性能增强能力。当然这个连接也不会一直保留着：连接在空闲一段时间后会被关闭(服务器可以使用 Keep-Alive 协议头来指定一个最小的连接保持时间)。
- 流水线：在现代浏览器中并不是默认被启用的，HTTP/2 流水线已经被更好的算法给代替，如 multiplexing
- 域名分片（域名发散）：将客户端请求的域名分片成多个域名连接，好处是迫使客户端建立更多连接，获取更快的响应速度，坏处是DNS消耗，http2.0已经弃用 后续websocket也写在这里，留个坑
HTTP缓存
- 缓存是一种保存资源副本并在下次请求时直接使用该副本的技术。当 web 缓存发现请求的资源已经被存储，它会拦截请求，返回该资源的拷贝，而不会去源服务器重新下载。
- 常见的 HTTP 缓存只能存储 GET 响应，对于其他类型的响应则无能为力。
分类
- 强缓存：浏览器如果判断本地缓存未过期，就直接使用，无需发起http请求
(200 from memory/disk cache) - 协商缓存:浏览器第一次请求数据时，服务器会将缓存标识与数据一起返回给客户端，客户端将二者备份至缓存数据库中。再次请求数据时，客户端将备份的缓存标识发送给服务器，服务器根据缓存标识进行判断，判断成功后，返回
304状态码，通知客户端比较成功，可以使用缓存数据。
常见的关于HTTP高频面试题：
1. GET和POST有什么区别？
- 请求参数的位置：GET请求参数会附在url之后，参数之间用&连接，而POST请求参数会放在实体中，不对外暴露
- 请求长度限制：浏览器对url长度有限制，GET请求如果多个参数会造成url长度增加，而POST请求不存在这个问题
- 安全性：从参数暴露程度来讲，POST安全性比GET略高，但其实安全性不是只体现在这里，安全性还是需要依赖SSL/TSL等加密手段
- 幂等性：GET请求多次返回结果是一样的，但是POST不是，每次请求都会创建新资源
- 缓存：GET请求可以被缓存，而POST请求则不会，除非在响应头中包含适当的Cache-Control或Expires字段
- 后退/刷新按钮的影响：：GET请求可以被浏览器缓存，因此可以通过点击后退按钮或刷新按钮来重复执行。而POST请求则不会，因为这些操作对POST请求没有实际意义
2. HTTP2相较于HTTP1有什么优势和特点？
HTTP/2相较于HTTP/1.1的主要优势和特点包括多路复用、头部压缩、服务器推送、优先级设定和二进制协议。
- 多路复用：HTTP/1.1中，每个请求都需要建立独立的TCP连接，存在“队头阻塞”问题，即某个请求处理时间过长会影响其他请求的响应速度。而HTTP/2引入了多路复用技术，可以在一个TCP连接上并行发送多个请求和响应，解决了队头阻塞问题，提高了并发性能
- 头部压缩：HTTP/1.1中，每次请求和响应都需要携带完整的头部信息，存在冗余。HTTP/2引入了HPACK算法对头部信息进行压缩，减少了数据传输量，提高了传输效率
- 服务器推送：HTTP/1.1中，客户端需要发送请求才能获取资源。HTTP/2允许服务器在客户端需要之前就将资源推送给客户端，减少了请求延迟，提高了性能
- 优先级设定：HTTP/1.1不允许客户端为请求设置优先级。HTTP/2允许客户端为请求设置优先级，这意味着服务器可以优先处理高优先级的请求，有助于页面更快呈现
- 二进制协议：HTTP/1.1使用文本协议，数据以纯文本形式传输。HTTP/2采用二进制格式传输数据，相比文本协议，二进制协议解析更高效，减少了解析时间
综上所述，HTTP/2通过引入多路复用、头部压缩、服务器推送、优先级设定和二进制协议等技术，显著提高了网页加载性能、减少了数据传输量、优化了资源加载顺序，从而提升了用户体验和服务器效率
3. HTTPS怎么保证安全？为什么比http安全？
HTTPS协议在HTTP协议的基础上加入了SSL/TLS协议，通过对数据进行加密和身份验证来保证通信的安全性。HTTPS比HTTP更安全的原因主要有以下几点：
- 数据加密：HTTPS通过SSL/TLS协议对传输的数据进行加密，确保数据在传输过程中不被窃取或篡改。这种加密机制可以保护数据在传输过程中的安全，防止数据被窃取或篡改
- 身份验证：HTTPS通过数字证书来验证服务器的真实性和身份，确保用户访问的是真实的网站，而不是被伪装的恶意网站。这种身份验证机制可以防止用户受到伪装攻击
- 混合加密技术：HTTPS采用混合加密技术，结合了对称加密和非对称加密。对称加密使用相同的密钥进行数据的加密和解密，只要密钥的安全性得到保障，整个通信过程就能确保机密性。非对称加密使用公钥和私钥，公钥用于加密数据，私钥用于解密，这种技术用于实现身份认证和密钥协商
4. HTTP请求状态码有哪些？分别代表什么意思？
上文中有详述
5. HTTP请求和响应报文是什么样的？
上文中有详述
6. POST请求为什么会多发送一次option？
POST请求多发送一次OPTIONS请求是因为浏览器的同源策略和CORS（跨源资源共享）机制。 当浏览器发起一个跨域的POST请求时，首先会发送一个OPTIONS请求，这是CORS机制的一部分。这个预检请求（也称为预检OPTIONS请求）的目的是探测服务器是否支持跨域请求，以及服务器允许的请求方法和请求头等信息。如果请求是跨域的，或者使用了非简单方法的请求（如POST）或自定义请求头，浏览器会先发送一个OPTIONS请求到服务器，以确认服务器是否允许这样的跨域请求。这个过程称为“预检请求”。如果服务器返回正面的响应，浏览器才会发送实际的POST请求。这样做的目的是为了保护用户的数据安全和防止恶意网站的攻击，确保只有合法的跨域请求被允许和执行
7. 同样是重定向，307，303，302的区别在哪里？
上文中有详述
8. 对keep-alive的理解
HTTP的keep-alive，也称为HTTP长连接，是一种通过重用TCP连接来发送和接收多个HTTP请求的机制。其主要作用包括：
- 减少连接建立开销：在没有keep-alive的情况下，每次HTTP请求都需要经过TCP三次握手建立连接，这会导致较大的延迟和资源消耗。而使用keep-alive，可以在一个TCP连接上发送多个HTTP请求，从而减少了建立连接的开销
- 降低网络负载：每次建立和关闭连接时，都会消耗网络带宽和服务器资源。通过保持持久连接，可以减少连接的频繁建立和关闭，从而降低了网络负载和服务器负载
- 提高性能和响应时间：由于避免了连接建立和关闭的开销，keep-alive可以提高请求的响应时间和整体性能。客户端可以在同一个连接上连续发送请求，而服务器也可以在保持连接的情况下更快地响应这些请求
- 支持HTTP管道化：HTTP管道化是允许客户端在同一TCP连接中连续发送多个请求而无需等待每个请求的响应的技术。当与keep-alive结合使用时，可以进一步提高性能
总的来说，HTTP的keep-alive机制通过重用TCP连接和优化请求处理流程，提高了HTTP通信的性能和效率
9. 简述tcp三次握手四次挥手
另外一篇有提过
10. TCP和UDP有什么区别
TCP和UDP的主要区别在于它们的连接方式、服务对象、可靠性、拥塞控制与流量控制、首部开销、传输方式、分片方式以及应用场景。
- 连接方式与服务对象：TCP需要先建立连接才能传输数据，是面向连接的，提供一对一服务。而UDP则无需建立连接，即刻就能传输数据，支持一对一、一对多以及多对多的交互通信
- 可靠性：TCP能够确保数据的可靠传输，数据在传输过程中无差错、不丢失、不重复，且能按需到达。UDP则采用尽最大努力交付的原则，不保证数据的可靠传输
- 拥塞控制与流量控制：TCP具备拥塞控制和流量控制机制，从而确保数据传输的安全性。而UDP则不受网络拥堵影响，其发送速率始终保持不变
- 首部开销：TCP的首部较长，会有一定的开销。其首部在未使用“选项”字段时为20个字节，使用“选项”字段后会变长。而UDP的首部仅有8个字节，固定不变，开销较小
- 传输方式与分片方式：TCP采用流式传输，无边界，但能保证数据的顺序和可靠性。当数据大小超过MSS时，会在传输层进行分片。而对于UDP，当数据大小超过MTU时，会在IP层进行分片
- 应用场景：TCP对应的是可靠性要求高的应用，如文件传输、电子邮件等。而UDP对应的则是可靠性要求低、传输经济的应用，如在线视频会议、网络电话等实时应用
11. TCP/IP协议包含哪几层？
TCP/IP协议包含四层，分别是应用层、传输层、网络层、链路层：
- 应用层：处理特定的应用程序细节，包含各种不同的协议，如HTTP、FTP、SMTP等，用于传输和接收数据
- 传输层：负责在源端和目的端之间建立、管理和终止会话，提供TCP（传输控制协议）和UDP（用户数据报协议）两种主要的协议。TCP提供可靠的数据传输服务，而UDP提供简单的数据传输服务，不保证数据的顺序和完整性
- 网络层：负责数据的路径选择和逻辑地址寻址，包含IP（互联网协议）和ICMP（互联网控制消息协议）等，用于发送数据包并根据目的IP地址选择最佳路径，实现数据包的路由和转发
- 链路层：负责在物理网络连接上发送和接收数据，包含各种硬件协议，如以太网（Ethernet）、无线局域网（WLAN）等，定义如何在物理连接上传输数据
这些层次共同构成了TCP/IP协议栈，使得数据能够从源端传输到目的端，同时确保数据的正确性和可靠性
还有一个问题是我认为比较重要的：HTTP和TCP的关系：
HTTP协议是在TCP协议的基础上工作的，TCP协议提供了可靠的数据传输机制。HTTP协议通过TCP协议的连接进行通信，利用TCP协议提供的可靠传输保证数据的正确性和完整性
HTTP（超文本传输协议）和TCP（传输控制协议）是两种不同的网络协议，它们在网络通信中扮演着不同的角色。HTTP是一种应用层协议，用于从Web服务器传输超文本到本地浏览器。它是基于请求-响应模式的，指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。HTTP协议本身并不处理底层的网络通信问题，而是依赖于TCP等传输层协议来实现可靠的数据传输
TCP是一种传输层通信协议，它提供了面向连接的、可靠的、基于字节流的传输服务。TCP协议通过对上层网络提供接口，使得上层数据的传输建立在“无差别”的网络之上。建立TCP连接需要经过“三次握手”过程，而断开连接则需要经过“四次握手”。TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP连接都将被一直保持下去
简而言之，HTTP协议作为应用层协议，运行在TCP等传输层协议之上，利用TCP提供的可靠数据传输服务，确保数据的正确性和完整性。这种分层的设计使得网络通信更加模块化和可扩展，不同的层负责不同的功能，从而简化了网络通信的开发和维护
说到http不得不谈到的就是浏览器，同时也是面试中老生常谈的问题，那么如何系统了解浏览器在大前端中发挥的作用呢？请移步：留个新坑
