读《凤凰架构》- 从HTTP/1.0到QUIC

读《凤凰架构》- 从HTTP/1.0到QUIC

引用： 《凤凰架构》- 周志明

优化HTTP传输线路

• 雅虎 YSlow-23 条规则是 用于优化传输链路的前端原则（但不总是对的，了解即可）
• 为了减少各种分时系统的上下文切换所浪费的性能，同时又要提高并发数，以至于很多IO密集型的系统都喜欢引入多路复用机制。
• 跟服务器端不同，前端的多路复用是把一个TCP链接复用（服务器的多路复用技术是复用线程，用一个线程去维护多个socket列表）。即在一个TCP链接维护多个Request-Respond会话（在HTTP/1中一个TCP维护一个Request-Respond会话）
• HTTP/2的多路复用技术中提出了“流”“帧”的概念，
• 将所有HTTP报文按照Header和Body切割成很多个帧。然后放到一个TCP链接上去传输，并且还会把同一HTTP会话的帧打上标记，将这些标记相同的帧集合起来就叫做“流”（其实就是Request-Respond会话）。
• 众所周知，在计算机科学里“流是有方向的，我们把输出流叫Request流，输入流叫Respond,不喜欢这样叫也可以，随你。
• 跟服务器端的多路复用技术一种，HTTP/2的多路复用也喜欢传输小资源（减少线头阻塞）（这种特征在TCP的Offload技术中也会碰到过，Offload技术在网络不好时，容易造成线头阻塞）。
• 还有一个有趣的算法，HTTP/2为了提高Header帧太多事导致带宽浪费，引入“字典编码”算法，提高了数据压缩率。（值得好好学习参照）
• 多路复用技术中，一般同一个域名会共享同一个TCP链接。
• 在HTTP/1.1的时候的gzip压缩技术、Ajax、JSP、PHP等动态内容技术导致在传输Header无法实现知道Body的内容就被传输出去了，以至于无法知道 Content-Length多长，所以只要是动态内容就没有Content-Length属性。
• 在Http1.1以前客户端依靠服务器的TCP断开链接来识别Respond响应包结束。
• Http1.1时由于存在“持久链接机制”（Keep-alived机制），也就是Respond响应包结束，但TCP链接不会断开。换句话说，靠TCP断开来判断Response结束这招在HTTP/1.1里不好使了！
• 所以，HTTP/1.1里提出了“Transfer-Encoding: chunked”来标记response被分块，如果收到最后一个分块就表示链接结束（跟UDP传输大包时的more-fragment标记原理一样）。
• HTTP/2的多路复用技术也是用chunk机制解决跟keep-alive机制一种的“响应结束问题”。
• 由于HTTP over TCP, 以至于为了提高TCP的性能问题，在 HTTP/1.1和HTTP/2 引入了持久链接（Keep-alive机制）、多路复用技术、分块编码（Chunk）技术。细心的你们一定也跟我一样，发现这些技术在TCP协议和UDP协议里面已经有了，为什么在应用层又搞了一遍？
• 拥有70%浏览器市场份额的Google公司也发现了这个问题。因此，痛定思痛发起了“QUIC协议”（Quick UDP Internet Connection）
• QUIC协议是基于UDP在应用层实现的通讯协议，同样做为可靠性协议，它比TCP强在吗？
• TCP协议的两个特征：1.丢包容易造成接收窗口阻塞。2. TCP的会话socket是由四元组组成的（源IP,源端口，目的IP，目的端口），也就说换网线造成IP改变的同时TCP链接会被迫断开（比如我手机联通卡换成移动卡，所有TCP链接都会断开）。
• QUIC协议也不存在这个两个TCP的问题（因为引入了流错误隔离的概念，避免线头阻塞。这个概念HTTP/2在处理大文件时都做不到这一点）。另外QUIC提出了连接标识符的概念，不再像TCP依赖IP标识会话（也就是换网络线路不会断开链接，完美！）