携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第十二天，点击查看活动详情
HTTP部分问题讨论
队头阻塞问题（head of line blocking）
队头阻塞问题不仅仅只是处在HTTP的问题，实际上更加底层的协议以及网络设备通信也会存在这线头阻塞问题。
交换机
当交换机使用FIFO队列作为缓冲端口的缓冲区的时候，按照先进先出的原则，每次都只能是最旧的网络包被发送，这时候如果交换机输出端口存在阻塞，则会发生网络包等待进而造成网络延迟问题。
但是哪怕没有队头阻塞，FIFO队列缓冲区本身也会卡住新的网络包在旧的网络包后面排队发送，所以这是FIFO队列本身带来的问题。
有点类似核酸排队，前面的人不做完后面的人做不了，但是前面的人一直不做，后面也只能等着。
交换机HO问题解决方案
使用虚拟输出队列的解决方案，这种方案的思路是只有在输入缓冲区的网络包才会HOL阻塞，带宽足够的时候不需要经过缓冲区直接输出，这样就避免HOL阻塞问题。另外无输入缓冲的架构在中小型的交换机比较常见。
线头阻塞问题演示
交换机：_交换机根据 MAC 地址表查找 MAC 地址， 然后将信号发送到相应的端口_一个网络信号转接设备，有点类似电话局中转站。
线头阻塞示例：第 1 和第 3 个输入流竞相将数据包发送到同一输出接口，在这种情况下，如果交换结构决定从第 3 个输入流传输数据包，则无法在同一时隙中处理第 1 个输入流。
请注意，第一个输入流阻塞了输出接口 3 的数据包，该数据包可用于处理。
无序传输：
因为TCP不保证网络包的传输顺序，所以可能会导致乱序传输，HOL阻塞会显著的增加数据包重新排序问题。
同样为了保证有损网络可靠消息传输，原子广播算法虽然解决这个问题，但是本身也会产生HOL阻塞问题，同样是由于无序传输带来的通病。
Bimodal Multicast 算法是一种使用 gossip 协议的随机算法，通过允许乱序接收某些消息来避免线头阻塞。
HTTP线头阻塞
HTTP 在 2.0 通过多路复用的方式解决了HTTP协议的弱点并且真正意义上消除应用层HOL阻塞问题，但是TCP协议层的无序传输依然是无法解决的。
于是在3.0中直接更换TCP协议为 QUIC 协议消除传输层的HOL阻塞问题。
HTTP/2 全双工支持
注意HTTP直到2.0才是真正意义上的全双工，所谓的HTTP支持全双工是混淆了TCP协议来讲的，因为TCP是支持全双工的，TCP可以利用网卡同时收发数据。
为了搞清楚TCP和HTTP全双工的概念， 应该理解HTTP中双工的两种模式：半双工（http 1.0/1.1），全双工（http 2.0）。
半双工：同一时间内链接上只能有一方发送数据而另一方接受数据。
- http 1.0 是短连接模式，每个请求都要建立新的 tcp 连接，一次请求响应之后直接断开，下一个请求重复此步骤。
- http 1.1 是长连接模式，可以多路复用，建立 tcp 连接不会立刻断开，资源1 发送响应，资源2 发送响应，资源3 发送响应，免去了要为每个资源都建立一次 tcp 的开销。
全双工：同一时间内两端都可以发送或接受数据 。
- http 2.0 资源1客户端发送请求不必等待 S响应就可以继续发送资源2 的请求，最终实现一边发，一边收。
HTTP 2.0 缺点
- 解决了HTTP的队头请求阻塞问题，但是没有解决TC P协议的队头请求阻塞问题，此外HTTP/2需要同时使用TLS握手和 HTTP握手耗时，同时在HTTPS连接建立之上需要使用TLS进行传输。
- HTTP/2的队头阻塞出现在当TCP出现丢包的时候，因为所有的请求被放到一个包当中，所以需要重传，TCP 此时会阻塞所有的请求。但是如果是HTTP1.X，那么至少是多个TCP连接效率还要高一些，
- 多路复用会增大服务器压力，因为没有请求数量限制，短时间大量请求会瞬间增大服务器压力
- 多路复用容易超时，因为多路复用无法鉴定带宽以及服务器能否承受多少请求。
丢包不如HTTP1.X
丢包的时候出现的情况是HTT P2.0因为请求帧都在一个TCP连接，意味着所有的请求全部要跟着TCP阻塞，在以前使用多个TCP连接来完成数据交互，其中一个阻塞其他请求依然可以正常抵达反而效率高。
二进制分帧目的
根本目的其实是为了让更加有效的利用TCP底层协议，
HTTP1.X的Keep-alive缺点
- 必须按照请求响应的顺序进行交互，HTTP2的多路复用则必须要按顺序响应。
- 单个TCP一个时刻处理一个请求，但是HTTP2同一个时刻可以同时发送多个请求，同时没有请求上限。
HTTP协议真的是无状态的么？
仔细阅读HTTP1.x和HTTP/2以及HTTP3.0三个版本的对比，其实会发现HTTP无状态的定义偷偷发生了变化的，为什么这么说？
在讲解具体内容之前，我们需要弄清一个概念，那就是Cookie和Session虽然让HTTP实现了“有状态”，但是其实这和HTTP协议本身的概念是没有关系的。
Cookie和Session的出现根本目的是保证会话状态本身的可见性，两者通过创立多种独立的状态“模拟”用户上一次的访问状态，但是每一次的HTTP请求本身并不会依赖上一次HTTP的请求，单纯从广义的角度看待其实所有的服务都是有状态的，但是这并不会干扰HTTP1.X本身无状态的定义。
此外HTTP协议所谓的无状态指的是每个请求是完全的独立的，在1.0备忘录定义也可以看出一次HTTP连接其实就是一次TCP连接，到了HTTP1.1实现了一个TCP多个HTTP连接依然是可以看做独立的HTTP请求。
说了这么多，其实就是说HTTP1.X在不靠Cookie和Session扶着的时候看做无状态是对的，就好比游戏里面的角色本身的数值和武器附加值的对比，武器虽然可以让角色获得某种状态，但是这种状态并不是角色本身特有的，而是靠外力借来的。
然而随着互联网发展，到了HTTP/2和HTTP3之中HTTP本身拥有了“状态”定义，比如2.0关于HEADER压缩产生的HPACK算法（需要维护静态表和动态表），3.0还对HPACK算法再次升级为QPACK让传输更加高效。
所以总结就是严谨的来说HTTP1.X是无状态的，在Cookie和Session的辅助下实现了会话访问状态的保留。到了HTTP/2之后HTTP是有状态的， 因为在通信协议中出现了一些状态表来维护双方重复传递的Header字段减少数据传输。
参考资料
吃透HTTP协议其实只要看官方的协议原文足矣，当然学习过程避免需要查资料，这里给了一些个人写文章的参考。
资料1：HTTP/2的官方介绍（官方的一手资料，定协议的作者写的，最权威的资料了）
RFC 9113 - HTTP/2 (httpwg.org)
资料2：这篇英文博客用5分钟的时间快速讲述了HTTP/3的新特性，比较有意思的文章。
www.jesuisundev.com/en/understa…
资料3：总结的非常不错的用心的博客，写作日期比较接近，个人很多内容理解也参考自这篇博客。
（最系统、最全面）这一次，彻底搞懂HTTP面试 - 掘金 (juejin.cn)
资料4：关于HTTP进化的一些历史讨论参考
资料5：有关HTTP的发展史参考
小结
这一章节本来应该是全书的核心内容，奈何作者似乎并不想让读者畏惧，所以讲的比较浅显，个人花费了不少精力收集网上资料结合自己的思考整理出第二章的内容。
关于HTTP的整个发展史是有必要掌握的，因为八股有时候会提到相关问题，问的深入一些确实有些顶不住，HTTP 协议也是应用层通信协议的核心，其次作为WEB开发人员个人认为是更是有必要掌握的。
另外了解HTTP的设计本身可以让我们过渡到TCP协议的了解，TCP的设计导致了HTTP设计的影响等问题可以做更多思考。
关于更多内容建议可以看看《网络是怎么样连接》的这一篇读书笔记，原书从整个TCP/IP 结构的角度通俗的讲述了有关互联网发展的基本脉络，而这一篇讲述了HTTP发展的基本历史和未来的发展方向。
