HTTP知识点总结

HTTP相关知识

概述

HTTP 是超文本传输协议，也就是HyperText Transfer Protocol。

概念

URI（统一资源标识符）

URL（Uniform Resource Locator，统一资源定位符）

HTTP 协议用于客户端和服务器端之间的通信

无状态：服务器不维护任何有关客户端过去所发请求的信息

HTTP方法（请求类型）

GET ：获取资源

• 请求行、HOST、Use-agent、Connection、Accept-language 等、请求空行

POST：传输实体主体

• 在请求消息的消息体中上传客户端的输入

PUT：传输文件

• 将消息中的文件上传到URL字段所指定的路径

HEAD：获得报文首部

DELETE：删除文件

• 删除URL字段所指定的文件

OPTIONS：询问支持的方法

TRACE：追踪路径

CONNECT：要求用隧道协议连接代理

主要使用 SSL（Secure Sockets Layer，安全套接 层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容 加 密后经网络隧道传输

GET与POST的区别

网上版本

• 1. 从参数角度，GET使用URL或Cookie传参，而POST将数据放在BODY中，更适合传输敏感信息并且GET方式提交的数据有长度限制，则POST的数据则可以非常大。
  • 只是HTML标准对HTTP协议的用法的约定；HTTP没有限制GET方式提交的数据长度，而是现代浏览器和服务器对URL的长度有限制
• 2. 从缓存的角度，GET 请求会被浏览器主动缓存下来，留下历史记录，而 POST 默认不会。
• 3. 从编码的角度，GET 只能进行 URL 编码，只能接收 ASCII 字符(encodeURI()编码)，而 POST 没有限制。
• 4. 从TCP的角度，GET 请求会把请求报文一次性发出去，而 POST 会分为两个 TCP 数据包，
     首先发 header 部分，如果服务器响应 100(continue)， 然后发 body 部分。

根据HTTP协议描述，GET请求是幂等性的，POST请求不是

• 幂等性：指一次和多次请求某一个资源应该具有同样的副作用。简单来说意味着对同一URL的多个请求应该返回同样的结果。
• get用来获取数据，post用来提交数据

本实质上没有区别，都是基于TCP协议

Cookie

Cookie 技术通过在请求和响应报文中写入Cookie 信息来控制客户端的状态

• cookie保存在客户端上，由浏览器管理

Cookie使用

• 1. Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的首部字段信息，通知客户端保存 Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去
• 2. 服务器端发现客户端发送过来的 Cookie 后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。

为 Cookie 服务的首部字段

• Set-Cookie：开始状态管理所使用的Cookie信息
• Cookie：服务器接收到的Cookie信息

条件性GET方法

• 解决缓存过期问题：如果缓存有最新的版本，则不需要发送请求对象
• 客户端：在HTTP消息中声明所持有版本的日期：if-modified-since:
• 服务器：如果缓存的版本是最新的，则响应消息中不包含对象：HTTP/1.0 304 NOT Modified 。改了则200 ok返回

HTTP报文结构

HTTP 报文本身是由多行（用 CR+LF 作换行符）数据构成的字符串文本。

报文主体和实体主体的差异

• 报文（message）：是 HTTP 通信中的基本单位，由 8 位组字节流（octet sequence，其中 octet 为 8 个比特）组成，通过 HTTP 通信传输
• 实体（entity）：作为请求或响应的有效载荷数据（补充项）被传输，其内容由实体首部和实体主体组成。
• HTTP 报文的主体用于传输请求或响应的实体主体。通常，报文主体等于实体主体。只有当传输中进行编码操作时，实体主体的内容发生变化，才导致它和报文主体产生差异。

HTTP常见状态码

状态码类别

2XX 成功

• 200 OK
• 204 No Content：请求成功但是没有资源返回
• 206 Partial Content：表示客户端进行了范围请求，而服务器成功执行了这部分的GET 请求。响应报文中包含由 Content-Range 指定范围的实体内容。

3XX 重定向

• 301 Moved Permanently：永久性重定向，表示请求的资源已被分配了新的 URI，以后应使用资源现在所指的 URI

• 302 Found：临时性重定向，请求的资源已被分配了新的 URI，希望用户（本次）能使用新的 URI 访问

• 303 See Other：由于请求对应的资源存在着另一个 URI，应使用 GET方法定向获取请求的资源

• 304 Not Modified：客户端发送附带条件的请求时，服务器端允许请求访问资源，但未满足条件的情况

  附带条件的请求是指采用 GET方法的请求报文中包含 If-Match，If-ModifiedSince，If-None-Match，If-Range，If-Unmodified-Since 中任一首部

• 307 Temporary Redirect：临时重定向，与 302 Found 有着相同的含义

4XX 客户端错误

• 400 Bad Request：示请求报文中存在语法错误
• 401 Unauthorized：认证失败
• 403 Forbidden：对请求资源的访问被服务器拒绝
• 404 Not Found

5XX 服务器错误

• 500 Internal Server Error
• 503 Service Unavailable：服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。

HTTP首部（HTTP/1.1）

通用首部字段

请求首部字段

响应首部字段

实体首部字段

End-to-end 首部和 Hop-by-hop 首部

• 端到端首部（End-to-end Header）

  • 分在此类别中的首部会转发给请求 / 响应对应的最终接收目标，且必须保存在由缓存生成的响应中，另外规定它必须被转发

• 逐跳首部（Hop-by-hop Header）

  • 分在此类别中的首部只对单次转发有效，会因通过缓存或代理而不再转发。HTTP/1.1 和之后版本中，如果要使用 hop-by-hop 首部，需提供 Connection 首部字段

HTTP和HTTPS

HTTP 与 HTTPS 有哪些区别？

• HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。
• HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
• HTTP 的端口号是 80，HTTPS 的端口号是 443。
• HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

HTTPS 解决了 HTTP 的哪些问题？

• 窃听风险
• 篡改风险
• 冒充风险

HTTPS 是如何解决上面的三个风险的？

• 混合加密的方式实现信息的机密性。

• 摘要算法的方式来实现完整性。

• 将服务器公钥放入到数字证书中，解决了冒充的风险。

  • 证书工作流程

SSL/TLS 的建立过程

• 1. ClientHello，由客户端向服务器发起加密通信请求
  • （1）客户端支持的 SSL/TLS 协议版本，如 TLS 1.2 版本。
  • （2）客户端生产的随机数（Client Random），后面用于生产「会话秘钥」。
  • （3）客户端支持的密码套件列表，如 RSA 加密算法。
• 2. SeverHello：服务器收到客户端请求后，向客户端发出响应
  • （1）确认 SSL/ TLS 协议版本，如果浏览器不支持，则关闭加密通信。
  • （2）服务器生产的随机数（Server Random），后面用于生产「会话秘钥」。
  • （3）确认的密码套件列表，如 RSA 加密算法。
  • （4）服务器的数字证书。
• 3. 客户端回应

  客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。

  如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送响应

  • （1）一个随机数（pre-master key）。该随机数会被服务器公钥加密。
  • （2）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。
  • （3）客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。
• 4. 服务器的最后回应：服务器收到客户端的第三个随机数（pre-master key）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」
  • （1）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。
  • （2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。

• TLS1.3 改进为只需3次握手

HTTP演变

HTTP/0.9

• 1. 不涉及数据包（packet）传输，主要规定了客户端和服务器之间的通信格式，默认使用 80 端口
• 2. 只有一个命令 GET，服务器只能回应 HTML 格式的字符串，不能回应别的格式。

HTTP/1.0

• 新增特性

  • 1. 任何格式的内容都可以发送
  • 2. 引入了 POST 命令和 HEAD 命令，丰富了浏览器与服务器的互动手段
  • 3. HTTP 报文格式改变，报文都必须包括首部
  • 4. 新增功能还包括状态码（status code）、多字符集支持、多部分发送（multi-part type）、权限（authorization）、缓存（cache）、内容编码（content encoding）等

• 主要缺点：每个 TCP 连接只能发送一个请求

HTTP/1.1

• 新增特性
  • 长连接
    • 支持长连接（PersistentConnection）在 HTTP1.1 中默认开启 Connection： keep-alive，一定程度上弥补了 HTTP1.0 每次请求都要创建连接的缺点
  • 流水线处理
    • 请求的流水线（Pipelining）处理，在一个 TCP 连接上可以传送多个 HTTP 请求和响应，减少了建立和关闭连接的消耗和延迟。
  • 缓存处理
    • 在 HTTP1.0 中主要使用 header 里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1 则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
  • 带宽优化及网络连接的使用
    • 解决问题：客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能
    • 请求头引入了range 头域，它允许只请求资源的某个部分，即返回码是206（Partial Content）
  • Host 头处理
    • 解决问题：在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个 IP 地址
    • HTTP1.1 的请求消息和响应消息都应支持 Host 头域，且请求消息中如果没有 Host 头域会报告一个错误（400 Bad Request）
• 面临问题
  • 队头堵塞（Head-of-line blocking）
    • 同一个 TCP 连接里面，所有的数据通信是按次序进行的。服务器只有处理完一个回应，才会进行下一个回应
  • 安全性
    • 明文传输，无法校验对方身份
  • header开销
    • header 里携带的内容过大，在一定程度上增加了传输的成本，并且每次请求 header 基本不怎么变化
  • keep-alive 开销
    • keep-alive 使用多了同样会给服务端带来大量的性能压力，并且对于单个文件被不断请求的服务(例如图片存放网站)，keep-alive 可能会极大的影响性能，因为它在文件被请求之后还保持了不必要的连接很长时间

SPDY 协议

• 谷歌公开了自行研发的 SPDY 协议，主要解决 HTTP/1.1 效率不高的问题，SPDY 可以说是综合了 HTTPS 和 HTTP 两者有点于一体的传输协议
• 多路复用（multiplexing）
  • 多路复用通过多个请求 stream 共享一个 tcp 连接的方式，解决了 HOL blocking 的问题，降低了延迟同时提高了带宽的利用率
  • 一个 request 对应一个 id，这样一个连接上可以有多个 request，每个连接的 request 可以随机的混杂在一起，接收方可以根据 request 的 id 将 request 再归属到各自不同的服务端请求里面
• 请求优先级（request prioritization）
  • 多路复用带来一个新的问题是，在连接共享的基础之上有可能会导致关键请求被阻塞
  • 给每个 request 设置优先级，这样重要的请求就会优先得到响应
• header 压缩
  • 采用DEFLATE
• 加密传输
  • 基于 HTTPS 的加密协议传输，大大提高了传输数据的可靠性
• 服务端推送（server push）
  例如我的网页有一个 sytle.css 的请求，在客户端收到 sytle.css 数据的同时，服务端会将 sytle.js 的文件推送给客户端，当客户端再次尝试获取 sytle.js 时就可以直接从缓存中获取到，不用再发请求了

HTTP/2.0

• HTTP/2 可以说是 SPDY 的升级版（是基于 SPDY 设计的）
• 与SPDY不同之处
  • 1. HTTP2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS
  • 2. HTTP2.0 消息头的压缩算法采用 HPACK，而非 SPDY 采用的 DEFLATE
• HTTP/2.0的HPACK算法
  • 1. 在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键－值对，不再重复发送 header
  • 2. 首部表在 HTTP/2 的连接存续期内始终存在，由客户端和服务器共同渐进地更新
  • 3. 每个新的首部键－值对要么被追加到当前表的末尾，要么替换表中之前的值
• 对比SPDY采用二进制分帧
  • 采用二进制编码