HTTP 1.0 2.0 3.0详解

HTTP

HTTP全称超文本传输协议，是一种属于应用层的通信协议。它允许将超文本标记语言文档（HTML）从Web服务器传输到客户端的浏览器。

HTTP报文结构

请求报文结构

请求方法：

1. GET：一般用来请求已被URI识别的资源，指定的资源经服务器解析后返回响应内容；也可以用来提交表单信息，但不安全。
2. POST：一般用来传输实体的主体，主要目的不是获取响应主体的内容
3. PUT：从客户端向服务器传送更新内容，具有幂等性，多次PUT请求结果一样。
4. HEAD：类似于GET请求，只不过返回的响应中没有具体内容，用于获取报头。
5. DELETE：请求服务器删除指定资源
6. OPTIONS：用来查询针对URI指定资源支持的方法
7. TRACE：回显服务器收到的请求，主要用于测试和诊断
8. CONNECT：开启一个客户端与请求资源的双向沟通通道，它可以用来创建隧道。应用于代理服务器的实现。

GET与POST的区别

1. GET一般是去获取数据，也可以提交数据，但多数是获取。POST一般是去提交数据。
2. GET用于提交时的URL有长度限制，POST没有长度限制，数据放在主体中。
3. GET是幂等操作，多次请求不会对服务器造成改变，POST不是幂等的，多次请求会影响服务器。
4. GET因为数据会放在URL中，安全性较差。POST安全性高一些。

常见请求报文字段

• Accept ：客户端希望获得资源的类型。
• Accept-Encoding ：客户端支持的压缩算法。
• Accept-Language ：客户端支持的语言。
• Host ：当前请求的域名。
• Connection ：客户端是否希望使用 TCP 长连接。
• User-Agent ：用户代理的信息。该字段标注了发送方的一些信息，你可以通过它来知道请求方的浏览器、操作系统版本等等

响应报文结构

状态码：

• 1XX：代表请求已被接受，需要继续处理。
• 2XX：代表请求已经被服务器端成功接收，操作被成功接收并处理。
• 3XX：表示重定向到了一个新的URL。代表客户端需要采取进一步操作才能完成请求。
• 4XX：表示请求错误。代表客户端发生了错误。
• 5XX：表示服务器发生了错误

状态码示例

• 200：请求已成功，响应头、响应体返回此响应
• 202：已接受请求，但还没有处理完成。
• 206：部分内容，服务器成功处理了GET的部分内容。（断点续传）
• 301：永久移动，请求的资源被永久移到了新的URI，客户端使用新的URI
• 302：临时移动，客户端继续使用原有的URI
• 400：客户端请求错误，服务器无法理解
• 401：请求需要用户身份认证
• 403：服务器理解客户端请求，但是拒绝执行此请求
• 404：服务器找不到客户端请求的资源
• 500：服务器内部错误
• 502：充当网关或代理服务器，从远端服务器收到一个无效的请求

常见响应报文字段

• Content-Type ：服务端返回的资源类型，可以带上使用的编码格式。
• Content-Encoding ：返回资源使用的压缩格式。
• Content-Length ：HTTP 消息体的长度。
• Date ：HTTP 响应报文生成的时间
• Connection ：服务端决定使用长连接还是短连接。
• Server ：使用了哪种服务器。

四种报文头

HTTP报文头大致分为四类：

1. 通用报文头：既可以用在请求报文中，也可以用在响应报文中。
2. 请求报文头
3. 响应报文头
4. 实体报文头

通用报文头

请求报文头

响应报文头

实体报文头

cookie和session

cookie

1. HTTP 是无状态协议，说明它不能以状态来区分和管理请求和响应。Cookie 技术通过在请求和响应报文中写入Cookie 信息来控制客户端的状态。
2. 服务器收到客户端请求，生成cookie，记录相应的信息，并在响应报文中附带上cookie。
3. 客户端收到服务器的响应报文并保存Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入Cookie 值后发送出去。
4. 服务器端发现客户端发送过来的Cookie 后，会对比服务器上的记录，最后得到之前的状态信息。

session

Session 对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。当用户请求来自应用程序的 Web 页时，如果该用户还没有会话，则 Web 服务器将自动创建一个 Session 对象。当会话过期或被放弃后，服务器将终止该会话。

鉴于HTTP 是无状态协议，之前已认证成功的用户状态无法通过协议层面保存下来。即，无法实现状态管理，因此即使当该用户下一次继续访问，也无法区分他与其他的用户。于是我们会使用Cookie 来管理Session，以弥补HTTP 协议中不存在的状态管理功能。

Session 管理及Cookie 状态管理（基于表单的认证）

1. 客户端把用户ID 和密码等登录信息放入报文的实体部分，通常是以POST 方法把请求发送给服务器。而这时，会使用HTTPS 通信来进行HTML 表单画面的显示和用户输入数据的发送。
2. 服务器会发放用以识别用户的Session ID。通过验证从客户端发送过来的登录信息进行身份认证，然后把用户的认证状态与Session ID 绑定后记录在服务器端。 向客户端返回响应时，会在首部字段Set-Cookie 内写入Session ID（如PHPSESSID=028a8c…）。
3. 客户端接收到从服务器端发来的Session ID 后，会将其作为Cookie 保存在本地。下次向服务器发送请求时，浏览器会自动发送Cookie，所以Session ID 也随之发送到服务器。服务器端可通过验证接收到的Session ID 识别用户和其认证状态。

HTTP1.0

1.0的HTTP版本，是一种无状态，短连接的应用层协议。 HTTP1.0规定浏览器和服务器保持短暂的链接。

浏览器每次请求都需要与服务器建立一个TCP连接，服务器处理完成以后立即断开TCP连接（短连接），服务器不跟踪每个客户单，也不记录过去的请求（无状态）。

这种无状态性可以借助cookie/session机制来做状态记录和身份认证。

特点

• 无状态：服务器不跟踪客户请求，不记录客户状态信息

• 短连接/无连接：每次发送请求都要重新建立tcp请求，即三次握手，非常浪费性能
• 不允许断点续传，而且不能只传输对象的一部分，要求传输整个对象

缺点：

1. 无法复用连接：每次发送请求，都需要进行一次TCP连接，而TCP的连接释放过程又是比较费事的。这种无连接的特性会使得网络的利用率变低。
2. 队头阻塞（head of line blocking）：由于HTTP1.0规定下一个请求必须在前一个请求响应到达之前才能发送，假设前一个请求响应一直不到达，那么下一个请求就不发送，后面的请求就阻塞了。

HTTP1.1

HTTP1.1继承了HTTP1.0的简单，克服了HTTP1.0性能上的问题。

特点

1. 连接方式 : HTTP 1.1 支持长连接，可以同时开启多个TCP连接。
2. 管道（pipeline）网络传输：只要第一个请求发出去了，不必等其响应回来，就可以发第二个请求出去，可以减少整体的响应时间。
3. 允许断点续传 ：引入了 range 头域，它允许只请求资源的某个部分。

缺点

1. 队头阻塞：服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据；
2. 请求 / 响应头部（Header）未经压缩就发送：首部信息越多延迟越大。只能压缩 Body 的部分；
3. 服务器只能被动响应：请求只能从客户端开始

HTTP2.0

特点

1. 二进制分帧：HTTP2.0通过在应用层和传输层之间增加一个二进制分帧层，改进传输性能。
2. 多路复用（并行传输）：2.0将消息拆分成了一个个帧，针对不同的消息的帧，用独一无二的 流 ID 来区分，不同流的帧是可以乱序发送的，因此可以并发不同的流。服务器可以通过流 ID 将帧有序组装成消息。HTTP2.0依此可以实现并发交错地发送消息 。
   1. 流（stream）：已建立连接上的双向字节流。

1. 头部压缩：
   1. HTTP2.0使用编码压缩来减少需要传输的头部大小
   2. 通讯双方各自缓存一份header_files表，避免重复header的传输，减少需要传输的大小。

1. 服务器推送 ：服务器还可以主动向客户端推送资源。

缺点：

1. TCP丢失重传导致阻塞：http 2.0虽然支持多路复用，但是所有消息的传输是基于一个TCP连接。TCP中前一个stream丢包重传导致后一个stream被阻塞，从而后面所有的消息传输都会阻塞。而HTTP1.1中可以开启多个TCP连接，就不存在这个问题。

HTTP3.0

Google搞了一个基于UDP协议的QUIC协议，并且命名为HTTP3.0

特点

• 基于UDP的多路复用（无队头阻塞）：基于UDP，一个连接上的多个stream之间没有依赖，即使丢包，只需要重发丢失的包即可，不需要重建整个连接。不会导致其他的消息被阻塞。
• 更快的连接建立：
  • 握手过程只需要 1 RTT，握手的目的是为确认双方的「连接 ID」，连接迁移就是基于连接 ID 实现的。
  • QUIC 内部包含了 TLS，它在自己的帧会携带 TLS 里的“记录”，再加上 QUIC 使用的是 TLS/1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商
• 基于ID识别（方便的连接迁移）：连接迁移时，不再用TCP四元组确定一个连接，而是用一个64位随机数来确定这个连接。无论网络环境如何变化，只要ID不变，就能迅速重新连上。

HTTPS

HTTPS在HTTP的基础上加了一层SSL/TSL四次握手来完成对称加密的操作，HTTPS一般加密URL和传输资源。

HTTP和HTTPS的区别

1. HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。
2. HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行四次 SSL/TLS 的握手过程，才可进入加密报文传输。
3. HTTPS的传输效率不如HTTP效率高
4. 两者的默认端口不一样，HTTP 默认端口号是 80，HTTPS 默认端口号是 443。

SSL/TSL流程

握手阶段

1. 客户端发起请求
2. 服务器返回证书和公钥
3. 客户端从CA验证证书（防止中间人攻击）
4. 证书合法，生成私钥（随机数）
5. 用公钥加密私钥并发送给服务器
6. 服务器解密获得私钥

传输阶段

1. 用私钥加解密，完成对称传输