标签：UDP HTTP 请求 演变 TCP 版本 1.0 连接
我们的口号是: Make C++ great again!
http各个版本的基本情况
http协议经过20多年的演进出现过0.9、1.0、1.1、2、3.0五个主要版本
http 0.9
-
请求方法支持有限
只支持GET请求方式，不支持其他请求方式 因此客户端向服务端传输信息的量非常有限，也就是现在常用的Post请求无法使用 -
不支持请求头header
不能在请求中指定版本号，服务端只具有返回HTML字符串的能力 -
响应即关闭
服务端相响应之后，立即关闭TCP连接
http 1.0
1.0版本主要是对0.9版本的强化，效果也比较明显，主要特性和缺点包括：
-
丰富请求方法
请求方式新增了POST，DELETE，PUT，HEADER等方式，提高了客户端向服务端发送信息的量级 -
增加请求头和响应头
增添了请求头和响应头的概念，可以在通信中指定了HTTP协议版本号，以及其他header信息，使得C/S交互更加灵活方便 -
丰富数据传输内容
扩充了传输内容格式包括：图片、音视频资源、二进制等都可以进行传输，相比0.9的只能传输html内容让http的应用场景更多 -
链接复用性差
1.0版本中每个TCP连接只能发送一个请求，数据发送完毕连接就关闭，如果还要请求其他资源，就必须重新建立连接。TCP为了保证正确性和可靠性需要客户端和服务器三次握手和四次挥手，因此建立连接成本很高，基于拥塞控制开始时发送速率较慢，所以1.0版本的性能并不理想。 -
无状态无连接的弊端
1.0版本是无状态且无连接的，换句话说就是服务器不跟踪不记录请求过的状态，客户端每次请求都需要建立tcp连接不能复用，并且1.0规定在前一个请求响应到达之后下一个请求才能发送，如果前一个阻塞后面的请求就会被阻塞。 丢包和乱序问题和高成本的链接过程让复用和队头阻塞产生很多问题，所以无连接无状态是1.0版本的一个弱肋。
http 1.1
1.1版本在1.0版本发布后大约1年就推出了，是对1.0版本的优化和完善，1.1版本的主要特点包括：
-
增加长连接
新增Connection字段，可以设置keep-alive值保持连接不断开，即 TCP 连接默认不关闭，可以被多个请求复用，这也是1.1版本很重要的优化，但是在S端服务器只有处理完一个回应，才会进行下一个回应。要是前面的回应特别慢，后面就会有许多请求排队等着，仍然存在队头阻塞问题。 -
管道化
在长连接的基础上，管道化可以不等第一个请求响应继续发送后面的请求，但响应的顺序还是按照请求的顺序返回，即在同一个TCP连接中，客户端可以同时发送多个请求，进一步改进了HTTP协议的传输效率。 -
更多的请求方法
增加了 PUT、PATCH、OPTIONS、DELETE 等请求方式。 -
host字段
Host字段用来指定服务器的域名，这样就可以将多种请求发往同一台服务器上的不同网站，提高了机器的复用，这个也是重要的优化
http 2
2.0的设计目标是在兼容1.x语义和操作的基础上，给用户带来更快捷、更简单、更安全的体验高效地利用当前的网络带宽，为此2.0做了很多调整主要包括：二进制化分帧、多路复用、头部压缩等.
-
二进制格式
1.x是文本协议，然而2.0是以二进制帧为基本单位，可以说是一个二进制协议，将所有传输的信息分割为消息和帧，并采用二进制格式的编码，一帧中包含数据和标识符，使得网络传输变得高效而灵活。 -
多路复用
这是一个非常重要的改进，1.x中建立多个连接的消耗以及效率都存在问题，2.0版本的多路复用多个请求共用一个连接，多个请求可以同时在一个TCP连接上并发，主要借助于二进制帧中的标识进行区分实现链路的复用。 -
头部压缩
2.0版本使用使用HPACK算法对头部header数据进行压缩，从而减少请求的大小提高效率，这个非常好理解，之前每次发送都要带相同的header，显得很冗余，2.0版本对头部信息进行增量更新有效减少了头部数据的传输。 -
服务端推送
这个功能有点意思，之前1.x版本服务端都是收到请求后被动执行，在2.0版本允许服务器主动向客户端发送资源，这样在客户端可以起到加速的作用。
http 3.0
科技永不止步!
像谷歌这种重要的公司并没有满足于此，而且想继续提升HTTP的性能，花最少的时间和资源获取极致体验。
那么肯定要问HTTP2.0虽然性能已经不错了，还有什么不足吗？
- 建立连接时间长(本质上是TCP的问题)
- 队头阻塞问题
- 移动互联网领域表现不佳(弱网环境)
- …
择其善者而从之，其不善者而改之.
谷歌于是乎选择UDP.
TCP协议的不足和UDP的一些优点：
- 基于TCP开发的设备和协议非常多，兼容困难
- TCP协议栈是Linux内部的重要部分，修改和升级成本很大
- UDP本身是无连接的、没有建链和拆链成本
- UDP的数据包无队头阻塞问题
- UDP改造成本小
从上面的对比可以知道，谷歌要想从TCP上进行改造升级绝非易事，但是UDP虽然没有TCP为了保证可靠连接而引发的问题，但是UDP本身不可靠，又不能直接用。
综合而知，谷歌决定在UDP基础上改造一个具备TCP协议优点的新协议也就顺理成章了，这个新协议就是QUIC(Quick UDP Internet Connections快速UDP互联网连接)协议。
…
QUIC协议的核心思想是将TCP协议在内核实现的诸如可靠传输、流量控制、拥塞控制等功能转移到用户态来实现，同时在加密传输方向的尝试也推动了TLS1.3的发展。
但是TCP协议的势力过于强大，很多网络设备甚至对于UDP数据包做了很多不友好的策略，进行拦截从而导致成功连接率下降。
腾讯云对QUIC性能的测试
任何新生事物的推动都是需要时间的，出现多年的HTTP2.0和HTTPS协议的普及度都没有预想高，IPv6也是如此，不过QUIC已经展现了强大的生命力，让我们拭目以待吧！
参考文献:
标签：UDP,HTTP,请求,演变,TCP,版本,1.0,连接 来源： https://blog.csdn.net/new_bee_01/article/details/110674628
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。