博客

参考博文：


关于队头阻塞（Head-of-Line blocking），看这一篇就足够了



快速掌握HTTP 1.0 1.1 2.0 3.0 的特点及其区别



一文牢记HTTP状态码（图解HTTP状态码）

浅诉HTTP各版本之间的区别

HTTP1.0

HTTP1.0的版本是一个无状态，无连接的应用层协议。无状态，无连接指的是浏览器每次向服务器发送请求都需要先建立一个短暂的TCP请求，获得响应之后就释放请求。


存在的问题

：①无法复用连接，每次向浏览器发请求都得重新进行3次握手与4次挥手，https还存在TSL握手的流程，大大降低了网络利用率。②存在队头阻塞的问题：即要把当前的数据完整发送到服务端，收到服务端的响应报文后才可以发送下一个数据包，如果迟迟没收到响应报文或者当前请求的数据很大就无法发送下一个请求。


总结

：HTTP1.0是一个无状态，无连接的应用层协议，不支持长连接。

HTTP1.1

HTTP1.1的版本在请求头中增加了connection字段，支持了长连接，可以通过Keep-alive字段开启长连接，并且基于这一功能，可以使得请求管道化（可以发送方无需等待当前请求的响应报文即可发送下一个请求）。但实际上管道化也并没有解决队头阻塞的问题，只是把先进先出的队列迁移到了服务端，服务器必须按照接收请求的顺序发送对这些（管道化）请求的响应。


存在问题

：队头阻塞。

但是从HTTP1.1这个版本支持多个TCP连接并行，这种方式从某种角度来说很大程度解决了队头阻塞的问题。


总结

：HTTP1.1支持长连接，默认采用长连接，可以使请求管道化，但Http1.1仍然没有解决队头阻塞问题，更确切的说是响应队头阻塞的问题。TCP并行连接的方式随着时间的推移也没有扩展得很好。

HTTP2.0

HTTP2.0新增的4大特点：

①

二进制分帧

：

在应用层中每个数据块前面加了一个数据帧，数据帧中包含了两个字段：流id和块的大小，分别代表当前数据块是属于哪个流的和记录了当前数据块的大小。

②

多路复用

：

基于在数据块前加入了帧的概念，就可以实现在一个TCP连接中传输多个不同的资源，接收方可以根据收到的数据包中的流id判断该数据块属于哪个流。

即： HTTP2.0之前，一个数据块中含有4个字节，1和2代表不同的资源，如果需要发送 1111 1111 2222的数据，得先得到1资源全部发送才可以发送2的资源，不然会发生错乱。而HTTP2.0允许在单个 TCP 连接上通过交错排列块来多路传输多个资源。它还解决了第一个资源缓慢时的队头阻塞问题.例如我们可以发送1212 1212 1111的数据，这样2的资源就不会被阻塞了。

③

头部压缩

：

http请求的头部一般会包含几百或者上千个字节，其中包括Connection ， Cookie，User-Agent ，Accept-encoding和Accept-Charset等字段，每次请求都带上这个头部，同样会降低网络利用率。Http2.0 可以使得请求发送方与接收方都存在一个头部索引表，在发送请求时，只需要在报文中定义一个key的字段，就可以到索引表中获取对应的头部。

④

服务端推送

：服务器除了最初请求的响应外，服务器还可以额外向客户端推送资源，而无需客户端明确的需求。


存在的问题

：虽然HTTP2.0从应用层方面解决了队头阻塞的问题，但是在传输层上，TCP层依然还没有解决队头阻塞的问题。原因在于TCP的重传机制。即当一个乱序的数据包到达服务端时，TCP协议会把该数据包先存放与乱序队列中，等到收到它期望序号的数据包时才会从乱序队列中取出序号相连的数据包。这个等待的过程，就是队头阻塞的过程。因此，HTTP3.0应运而生，它没有采用TCP做传输层的协议，而是UDP。

HTTP3.0

HTTP3.0结构图：



HTTP3.0版本与HTTP2.0 不一样，它将帧的概念下移到了QUIC层中，同样用来记录当前数据包所属的流id以及大小。


QUIC的特点

：

①0-RTT连接建立：RTT (Round Trip Time): 数据包在客户端与服务端间往返一次的时间。0-RTT即不需要一次往返，即可建立连接，马上传输数据。（TCP 3次握手是1 RTT ， 第三次握手才正式开始传输数据）。 是通过缓存当前会话的上下文，下次恢复会话的时候，只需要将之前的缓存传递给服务器，验证通过，就可以进行传输了。适用于传输层的建立连接与TSL加密层建立连接。

②多路复用：与HTTP2.0的二进制分帧差不多，只不过现在的帧是放在了传输层中。

③向前纠错机制：QUIC协议有一个非常独特的特性，称为向前纠错（Foward Error Connec，FEC），每个数据包除了它本身的内容之外还包括了其他数据包的数据，因此少量的丢包可以通过其他包的冗余数据直接组装而无需重传。在客户端发送完一个请求中的所有数据包后，还会算出这个三个包的异或值并单独发出一个校验包，如果某一个非校验包丢失了，服务端还可以根据其他数据包以及校验包得到丢失数据包中的数据，而无需重传该数据包。


总结

：QUIC在理论上解决了理想情况下（不发生丢包的情况）的队头阻塞问题，但在实际情况中，由于存在丢包的影响，对丢包的数量，包所在资源的位置，是不是并发数据流，对web网络性能的提升仍有待探索。

就如：

1111 2222 1111 第二个数据包丢了，对于资源1不会产生队头阻塞的问题。

而1212 1212 1212 第二个数据包丢失了，对资源1和2会产生阻塞。

1111 1111 2222 第二个数据包丢失了，对于资源2不会产生阻塞。

http协议状态码

总体的认识

① 1×× ： 信息化代码 补充：接收的请求正在处理

② 2×× ： 成功状态码 补充：接收的请求处理成功

③ 3×× ： 重定向状态码 补充：需要进行附加操作来完成请求

④ 4×× ： 客户端错误状态码 补充：服务器无法处理请求

⑤ 5×× ： 服务端错误状态码 补充：服务器处理请求出错

细化

200(成功)服务器已成功处理了请求。通常，这表示服务器提供了请求的网页。

301(永久移动)请求的网页已永久移动到新位置。服务器返回此响应(对 GET 或 HEAD 请求的响应)时，会自动将请求者转到新位置。

304(未修改)自从上次请求后，请求的网页未修改过。服务器返回此响应时，不会返回网页内容。（与重定向不太相关）

400(错误请求)服务器不理解请求的语法。（请求报文存在语法错误）

403(禁止)服务器拒绝请求。（如内网地址只能是内网IP才能访问，外网无法访问）

404(未找到)服务器找不到请求的网页。例如，对于服务器上不存在的网页经常会返回此代码。

500(服务器内部错误)服务器遇到错误，无法完成请求。

503该状态码表明服务器暂时处于超负荷或正在进行停机维护，现在无法处理请求。