HTTP相关协议

当今互联网技术发展迅速，HTTP协议作为Web应用的基础协议，掌握它对于学习Web开发有着重要的作用。本思维导图系统地总结了HTTP协议的基本知识，包括方法、响应状态码、请求头、响应头等内容，无论是对于初学者还是对于有一定经验的开发者来说，本思维导图都是一份很好的参考资料。

HTTP相关协议

• 概念
  • 请求报文
  • 响应报文
• HTTP 方法
  • 注：灰色原点代表不常见
  • GET
    • 获取资源
    • 只获取资源，不对数据进⾏行行添加、修改
    • 协议上说不应该带有 body，但是实现上代body 也不会报错，但是这么干很 SB
  • HEAD
    • 获取报文首部
    • 和 GET 方法类似，但是不返回报文实体主体部分。
    • 主要用于确认 URL 的有效性以及资源更新的日期时间等
  • POST
    • 增加或者修改数据
    • 给服务器器发送的数据都在body⾥⾯
  • PUT
    • 用于修改数据
    • 给服务器器发送的数据都在body⾥⾯
  • PATCH
    • 对资源进行部分修改
    • PUT 也可以用于修改资源，但是只能完全替代原始资源，PATCH 允许部分修改。
  • DELETE
    • 删除数据
    • 没有Body
  • OPTIONS
    • 查询支持的方法
    • 查询指定的 URL 能够支持的方法。会返回 Allow: GET, POST, HEAD, OPTIONS 这样的内容
  • CONNECT
    • 要求在与代理服务器通信时建立隧道
    • 使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输。
  • TRACE
    • 追踪路径
    • 服务器会将通信路径返回给客户端。
    • 发送请求时，在 Max-Forwards 首部字段中填入数值，每经过一个服务器就会减 1，当数值为 0 时就停止传输。
    • 通常不会使用 TRACE，并且它容易受到 XST 攻击（Cross-Site Tracing，跨站追踪）。
• 状态码
  • 1XX
    • 100 Continue表明到目前为止都很正常，客户端可以继续发送请求或者忽略这个响应
  • 2XX：成功
    • 200 OK
    • 204 No Content
      • 请求已经成功处理，但是返回的响应报文不包含实体的主体部分
      • 一般在只需要从客户端往服务器发送信息，而不需要返回数据时使用
    • 206 Partial Content
      • 表示客户端进行了范围请求，响应报文包含由 Content-Range 指定范围的实体内容
  • 3xx：重定向
    • 301 Moved Permanently ：永久性重定向
    • 302 Found ：临时性重定向
    • 303 See Other ：和 302 有着相同的功能，但是 303 明确要求客户端应该采用 GET 方法获取资源。
    • 307 Temporary Redirect ：临时重定向
      • 与 302 的含义类似，但是 307 要求浏览器不会把重定向请求的 POST 方法改成 GET 方法
  • 4XX：客户端错误
    • 400 Bad Request ：请求报文中存在语法错误
    • 401 Unauthorized ：该状态码表示发送的请求需要有认证信息（BASIC 认证、DIGEST 认证）。如果之前已进行过一次请求，则表示用户认证失败。
    • 403 Forbidden ：请求被拒绝。
    • 404 Not Found
  • 5xx：服务器错误
    • 500 Internal Server Error ：服务器正在执行请求时发生错误。
    • 503 Service Unavailable ：服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。
• HTTP 首部
  • 通过首部
    • Cache-Control：控制缓存的行为
    • Connection：控制不再转发给代理的首部字段、管理持久连接
    • Date：创建报文的日期时间
    • Pragma： 报文指令
    • Trailer 报文末端的首部一览
    • Transfer-Encoding 指定报文主体的传输编码方式
    • Upgrade 升级为其他协议
    • Via 代理服务器的相关信息
    • Warning 错误通知
  • 请求首部字段
    • Accept 用户代理可处理的媒体类型
    • Accept-Charset 优先的字符集
    • Accept-Encoding 优先的内容编码
    • Accept-Language 优先的语言（自然语言）
    • Authorization Web 认证信息
    • Expect 期待服务器的特定行为
    • From 用户的电子邮箱地址
    • Host 请求资源所在服务器
    • If-Match 比较实体标记（ETag）
    • If-Modified-Since 比较资源的更新时间
    • If-None-Match 比较实体标记（与 If-Match 相反）
    • If-Range 资源未更新时发送实体 Byte 的范围请求
    • If-Unmodified-Since 比较资源的更新时间（与 If-Modified-Since 相反）
    • Max-Forwards 最大传输逐跳数
    • Proxy-Authorization 代理服务器要求客户端的认证信息
    • Range 实体的字节范围请求
    • Referer 对请求中 URI 的原始获取方
    • TE 传输编码的优先级
    • User-Agent HTTP 客户端程序的信息
  • 响应首部字段
    • Accept-Ranges 是否接受字节范围请求
    • Age 推算资源创建经过时间
    • ETag 资源的匹配信息
    • Location 令客户端重定向至指定 URI
    • Proxy-Authenticate 代理服务器对客户端的认证信息
    • Retry-After 对再次发起请求的时机要求
    • Server HTTP 服务器的安装信息
    • Vary 代理服务器缓存的管理信息
    • WWW-Authenticate 服务器对客户端的认证信息
  • 实体首部字段
    • Allow 资源可支持的 HTTP 方法
    • Content-Encoding 实体主体适用的编码方式
    • Content-Language 实体主体的自然语言
    • Content-Length 实体主体的大小
    • Content-Location 替代对应资源的 URI
    • Content-MD5 实体主体的报文摘要
    • Content-Range 实体主体的位置范围
    • Content-Type 实体主体的媒体类型
    • Expires 实体主体过期的日期时间
    • Last-Modified 资源的最后修改日期时间
• 具体应用
  • 连接管理
    • 每次建立连接都需要三次握手，如果每次请求数据都要建立连接是很耗时的
    • 长连接
      • Connect：keep-alive， HTTP 1.1 默认开启，之前是默认关闭的。
      • 如果想断开传递 Connection : close
      • 是串行的,一次只能执行一个请求
      • 长连接只需要建立一次 TCP 连接，以后的 HTTP 请求都会复用他
      • 是按照域名+端口复用的，不同域名的请求不能混用
      • 串行的缺陷
        • 是串行的一次只能发送一个请求，不能打满带宽
        • 连接上的请求没有结束不能执行下一个
    • pipelining
      • 是并行的,可以同时提交多个请求
      • 但相应还是顺序的，需要一个一个返回，一个失败了就会阻塞后面的，不能打满带宽
  • Cookie
    • Http 是无状态协议，为了有状态引入了 Cookie 来保存状态信息
      • Cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器之后向同一服务器再次发起请求时被携带上，用于告知服务端两个请求是否来自同一浏览器。
      • 由于之后每次请求都会需要携带 Cookie 数据，因此会带来额外的性能开销（尤其是在移动环境下）。
    • 用途
      • 会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）
      • 个性化设置（如用户自定义设置、主题等）
      • 浏览器行为跟踪（如跟踪分析用户行为等）
    • 创建过程
      • 服务器发送的响应报文包含 Set-Cookie 首部字段，客户端得到响应报文后把 Cookie 内容保存到浏览器中
      • 客户端之后对同一个服务器发送请求时，会从浏览器中取出 Cookie 信息并通过 Cookie 请求首部字段发送给服务器。
    • 分类
      • 会话期 Cookie：浏览器关闭之后它会被自动删除，也就是说它仅在会话期内有效。
      • 持久性 Cookie：指定过期时间（Expires）或有效期（max-age）之后就成为了持久性的 Cookie。
    • Cookie 与 Session 选择
      • Cookie 只能存储 ASCII 码字符串，而 Session 则可以存储任何类型的数据，因此在考虑数据复杂性时首选 Session；
      • Cookie 存储在浏览器中，容易被恶意查看。如果非要将一些隐私数据存在 Cookie 中，可以将 Cookie 值进行加密，然后在服务器进行解密；
      • 对于大型网站，如果用户所有的信息都存储在 Session 中，那么开销是非常大的，因此不建议将所有的用户信息都存储到 Session 中。
    • Session
      • 也可以利用 Session 存储在服务器端，存储在服务器端的信息更加安全
      • Session 可以存储在服务器上的文件、数据库或者内存中。也可以将 Session 存储在 Redis 这种内存型数据库中，效率会更高
      • 维护用户登录状态
        • 用户进行登录时，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中
        • 服务器验证该用户名和密码，如果正确则把用户信息存储到 Redis 中，它在 Redis 中的 Key 称为 Session ID；
        • 服务器返回的响应报文的 Set-Cookie 首部字段包含了这个 Session ID，客户端收到响应报文之后将该 Cookie 值存入浏览器中；
        • 客户端之后对同一个服务器进行请求时会包含该 Cookie 值，服务器收到之后提取出 Session ID，从 Redis 中取出用户信息，继续之前的业务操作。
  • 缓存
    • 优点
      • 缓解服务器压力
      • 降低客户端获取资源的延迟
        • 缓存通常位于内存中，读取缓存的速度更快
        • 缓存服务器在地理位置上也有可能比源服务器来得近
    • 实现方法
      • 让代理服务器进行缓存；
      • 让客户端浏览器进行缓存。
    • Cache-Control
      • HTTP/1.1 通过 Cache-Control 首部字段来控制缓存。
      • 禁止进行缓存
        • no-store 指令规定不能对请求或响应的任何一部分进行缓存。
        • Cache-Control: no-store
      • 强制请求数据
        • no-cache 指令规定缓存服务器需要先拉取数据，更新缓存或证明缓存有效性。
        • Cache-Control: no-cache
      • 私有缓存
        • private 指令规定了将资源作为私有缓存，只能被单独用户使用，一般存储在用户浏览器中。
        • Cache-Control: private
      • 公共缓存
        • public 指令规定了将资源作为公共缓存，可以被多个用户使用，一般存储在代理服务器中。
        • Cache-Control: public
      • 缓存过期机制
        • max-age 指令出现在请求报文，如果缓存过期时间小于 max-age 则使用缓存
        • max-age 指令出现在响应报文，表示缓存资源在缓存服务器中保存的时间
  • 内容协商
    • 客户端通过内容协商让服务端返回最合适的内容
      • 例如根据浏览器的默认语言选择返回中文界面还是英文界面。
    • 类型
      • 服务端驱动型
        • 客户端设置特定的 HTTP 首部字段，例如 Accept、Accept-Charset、Accept-Encoding、Accept-Language 服务器根据这些字段返回特定的资源。
        • 问题
          • 服务器很难知道客户端浏览器的全部信息；
          • 客户端提供的信息相当冗长（HTTP/2 协议的首部压缩机制缓解了这个问题），并且存在隐私风险（HTTP 指纹识别技术）；
          • 给定的资源需要返回不同的展现形式，共享缓存的效率会降低，而服务器端的实现会越来越复杂。
      • 代理驱动型
        • 服务器返回 300 Multiple Choices 或者 406 Not Acceptable，客户端从中选出最合适的那个资源。
  • 内容编码
    • 内容编码将实体主体进行压缩，从而减少传输的数据量
    • 常用编码
      • gzip
      • compress
      • deflate
      • identity
    • 客户端发送 Accept-Encoding 首部，其中包含有它所支持的压缩算法，以及各自的优先级。
    • 服务器则从中选择一种，对数据压缩。并且发送 Content-Encoding 首部来告知浏览器它选择了哪一种算法
  • 范围请求
    • 可实现分段下载、断点续传
    • Range
      • 在请求报文中添加 Range 首部字段指定请求的范围
        • GET /z4d4kWk.jpg HTTP/1.1 Host: i.imgur.com Range: bytes=0-1023
      • 请求成功服务器返回的响应包含 206 Partial Content 状态码
        • HTTP/1.1 206 Partial Content Content-Range: bytes 0-1023/146515 Content-Length: 1024 ... (binary content)
    • Accept-Ranges
      • 响应首部字段
      • 用于告知客户端是否能处理范围请求
        • bytes 可以处理
        • none 不能使用
      • Accept-Ranges: bytes
    • 响应状态码
      • 206 Partial Content 请求成功
      • 416 Requested Range Not Satisfiable ： 请求的范围越界
      • 在不支持范围请求的情况下，服务器会返回 200 OK 状态码
• HTTPS
  • 在 HTTP 和 TCP 之间插入了验证层 SSL/TLS，保证了数据传输的安全
    • 密码学了解
    • 对称加密
      • 加密和解密算法一样
      • 优点：如果密匙泄漏，就可以伪造数据
      • 缺点；但是速度快，资源消耗小
    • 非对称加密
      • 有两个密匙：公钥、私钥。私钥永远保存在本地，公钥在网络上传输。
      • 加密场景：公钥负责加密，私钥负责解密
        • 既然是加密，那肯定是不希望别人知道我的消息，所以只有我才能解密
        • 通信双发都需要使用对方的公钥对信息加密，然后使用对应的私钥解开数据
      • 签名场景：私钥负责签名，公钥负责验证
        • 既然是签名，那肯定是不希望有人冒充我发消息，只有我才能发布这个签名
      • 优点：安全性高
      • 缺点：消耗资源大，效率没有对称加密高
      • 中间人攻击
  • Https 在证书认证阶段使用非对称加密，在数据传输阶段使用对称加密
  • 使用 CA 证书亮明对方身份，防止中间人攻击
  • 握手过程
    • Client 发送 Hello
      • SSL 版本号
      • 支持的加密算法
      • 一个随机数用于生成密匙
    • Server 接收到发送 Hello
      • 一个版本号（版本向下兼容）
      • 一个随机数
      • 双反都支持的加密算法
      • 对于 Client Hello 的 ACK
    • Server Certificate
      • 红色方框中的就是CA证书。
      • 证书中包含服务器的公钥
      • 客户端在收到证书后会使用系统内的 CA 根证书校验它
    • Server Key Exchange（可选）
      • 如果证书包含的信息不足以进行密钥交换，那么必须发送该信息
    • Server Hello Done
      • 服务器发送完上述信息之后，会立刻发送该信息，然后等到客户端的响应。
      • 告知客户端服务端发送了足够的信息，接下来可以和客户端一起协商出预备主密钥
      • 客户端接收到该信息后，可以进行证书校验、协商密钥等步骤
      • 校验过程
        • 验证证书的域名和访问的是否一致
          • 避免中间人替换证书
        • 对服务端发过来的证书做一次摘要
        • 使用系统根证书的公钥对传递过来的签名进行解密
          • 签名是对内容进行 hash 算法提取指纹
        • 将二者进行对比如果一直验证成功
    • Client Key Exchange
      • 接收到 Server Hello Done 后客户端会验证证书是否合法，不合法就发出警告，合法就开始此步骤
      • 目的是传递预主密匙：Pre-master secret
        • 生成一个随机数使用公钥加密后发送到服务端
        • Pre-master secret 就是用于加密的时候一个随机数
        • 前面的随机数都是明文的，此步骤经过加密处理提高了安全性
      • 此时就产生了三个随机数用于计算密匙
      • 以后的通信就使用双方个自己算的密匙进行对称加密
    • Client Change Cipher Spec
      • 客户端通知服务端，后续的报⽂文将被加密
    • Server Change Cipher Spec
      • 服务端通知客户端，后续的报⽂文将被加密
    • 开始传输数据
  • 握手过程简单版
    • Client发起请求；
    • Server端响应请求，并在之后将证书发送至Client；
    • Client使用认证机构的共钥认证证书，并从证书中取出Server端共钥；
    • Client使用公钥加密一个随机秘钥，并传到Server；
    • Server使用私钥解密出随机秘钥；
    • 通信双方使用随机数各自计算出对称秘钥进行加密解密
  • 双向认证
    • 客户端认证服务端的、服务端也得认证客户端的
  • 单向认证
    • 客户端只认证服务端的证书
• HTTP 1.1
  • 特征
    • 默认是长连接
    • 支持 pipelineing
    • 支持同时打开多个 TCP 连接
    • 支持虚拟主机
    • 新增状态码 100
    • 支持分块传输编码
    • 新增缓存处理指令 max-age
  • 缺点
    • 客户端需要使用多个连接才能实现并发和缩短延迟；
    • 不会压缩请求和响应首部，从而导致不必要的网络流量；
    • 不支持有效的资源优先级，致使底层 TCP 连接的利用率低下。
    • 请求是串行的，就算是 pipline 将若干个请求排队串行处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞；
• HTTP 2
  • 二进制分帧层
    • HTTP/2.0 将报文分成 HEADERS 帧和 DATA 帧，它们都是二进制格式的。
    • http2.0 是全双工
      • 只有一个 TCP 连接，它承载了任意数量的双向数据流（Stream）。
      • 一个数据流（Stream）都有一个唯一标识符和可选的优先级信息，用于承载双向信息。
      • 消息（Message）是与逻辑请求或响应对应的完整的一系列帧。
      • 帧（Frame）是最小的通信单位，来自不同数据流的帧可以交错发送，然后再根据每个帧头的数据流标识符重新组装。
  • 服务端推送
    • HTTP/2.0 在客户端请求一个资源时，会把相关的资源一起发送给客户端，客户端就不需要再次发起请求了
    • 例如客户端请求 page.html 页面，服务端就把 script.js 和 style.css 等与之相关的资源一起发给客户端。
  • 首部压缩
    • HTTP/1.1 的首部带有大量信息，而且每次都要重复发送。
    • HTTP/2.0 要求客户端和服务器同时维护和更新一个包含之前见过的首部字段表，从而避免了重复传输。
    • 不仅如此，HTTP/2.0 也使用 Huffman 编码对首部字段进行压缩。