HTTP 1.0

问题

• 性能问题，连接的建立、关闭都是耗时操作。
• 服务器推送问题，服务器无法主动向客户端推送消息。

Keep-Alive机制和Content-Length属性

Http 1.0设计了一个Keep-Alive机制来实现TCP连接的复用。客户端在HTTP请求的头部加上一个字段Connection:Keep-Alive。服务器收到带有这样字段的请求，在处理完请求之后不会关闭连接，同时在HTTP的Response里面也会加上该字段，然后等待客户端在该连接上发送下一个请求。服务端会有一个Keep-Alive timeout参数，过一段时间之后，如果该连接上没有新的请求进来，该连接就会关闭。以前一个连接就只发送一个请求，返回一个响应，处理完毕，把连接关闭，客户端就知道请求处理结束了。现在是在HTTP Response的头部，返回了一个Content-Length：xx的字段，这个字段可以告诉客户端Response的body公有多少个字节，额可兑换接收到这么多个字节之后，就知道响应成功接收完毕。

HTTP 1.1

连接复用与chunk机制

HTTP/2前的性能提升方法

• Spriting技术：专门针对小图片，将小图拼成大图，到了浏览器，再进行截取显示。减少http请求数
• 内联（Inlining）:将图片的原始数据嵌入css文件中
• js拼接：大量小js合并成一个文件并压缩
• 请求分片：多做几个域名，绕开浏览器限制

服务器主动推送问题解决

• 客户端定期轮询
• flashSocket、WebSocket
• HTTP长轮询：服务器端夯住请求连接，过时间关闭，变相用HTTP实现了TCP的长连接效果，最常用的服务器端推送方法
• HTTP Streaming：服务端利用Transfer-Encoding:chunked机制，发送一个没完没了的chunk流，就一个连接，但其Response永远接收不完。

HTTP/2

数字证书和证书认证中心

• close后，仍可能有数据包还在网络上”闲逛“，此时如果收到了这些数据包，可能会导致连接重开。4元组无法区分新老连接，导致之前的数据包在新连接打开后被当做新的数据包。老连接上的数据包会”串“到新连接上面，不可接受。任何一个IP数据包在网络上逗留的最长时间是MSL，这个值默认是120s。一个连接保持在TIME_WAIT状态后2xMSL后会进入CLOSE。
• 第四次发送的数据包，服务器是否收到是不确定的。可能会重新发送第三次的数据包，然后再次发送第四次的数据包，第三次和第四次数据包的时间和，最长是两个MSL，所以客户端在TIME_WAIT状态等待2xMSL时间。
  产生的问题：
  一个连接并不是想关就能立刻关的，关闭后还要等2xMSL时间才能重开，这就会造成一个问题，如果频繁地创建连接，最后可能导致大量的连接处于TIME_WAIT状态，最终耗光所有的连接资源。为了避免这种问题，可以采取如下措施：
• 不要让服务器主动关闭连接。这样服务器的连接就不会处于TIME_WAIT状态。
• 客户端做连接池，复用连接，而不要频繁的创建和关闭。这其实也是HTTP1.1和HTTP/2采用的思路。

QUIC