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机制
默认连接复用，除非在请求头上加上connection:close。引入chunk机制（http streaming）。在响应的头部加上Transfer-Encoding:chunked属性。其目的是告诉客户端，响应的body是分成一块块的，块与块之间有间隔符，所有块的结尾有特殊标记，这样，就算没有Content-Length字段，也能方便客户端判断出响应的末尾。
pipeline和队头阻塞
pipeline有个致命问题，Head-of-Line Blocking，队头阻塞。客户单接收响应的顺序必须和发送的顺序一致，这样如果前面的响应延时了，后续的响应也会阻塞。也正因为如此，为了避免pipeline带来的副作用，很多浏览器默认把pipeline关闭了。
HTTP/2前的性能提升方法
- Spriting技术：专门针对小图片，将小图拼成大图，到了浏览器，再进行截取显示。减少http请求数
- 内联（Inlining）:将图片的原始数据嵌入css文件中
- js拼接：大量小js合并成一个文件并压缩
- 请求分片：多做几个域名，绕开浏览器限制
服务器主动推送问题解决
- 客户端定期轮询
- flashSocket、WebSocket
- HTTP长轮询：服务器端夯住请求连接，过时间关闭，变相用HTTP实现了TCP的长连接效果，最常用的服务器端推送方法
- HTTP Streaming：服务端利用Transfer-Encoding:chunked机制，发送一个没完没了的chunk流，就一个连接，但其Response永远接收不完。
HTTP/2
HTTP/2和Http1.1并不是平级的位置，而是处在HTTP1.1和TCP之间。
二进制分帧
每个请求和响应实际上组成了一个逻辑上的”流“，为每条流分配一个流id,把这个id作为标签，达到每一个帧上。这样就是没有了http1.1的pipeline限制，响应可以乱序返回。
二进制分帧并没有彻底解决pipeline的”队头阻塞“问题，只是从HTTP Request粒度细化到了”帧“粒度。
头部压缩
HTTPS
对称加密的问题
秘钥的传输和存储存在问题。
双向非对称加密
在这个过程中，存在着签名和验签与加密和解密两个过程：
1.签名和验签。私钥签名，公钥验签，目的是防篡改。如果第三方截取到信息之后篡改，则接收方验签肯定过不了。同时也防抵赖，既然没有人可篡改，只可能是发送方自己发出的。
2.加密和解密。公钥加密，私钥解密。目的是防止信息被第三方拦截和偷听。第三方即便能截获到信息，但如果没有私钥，也解密不了。
在双向非对称加密中，客户端需要提前知道服务器的公钥，服务器需要知道客户端的公钥，和对称加密一样，同样面临公钥如何传输的问题。
单向非对称加密
中间人攻击
通过分析可以发现，我们并不需要双向的非对称加密，而用单向的非对称加密就能达到传输的目的。但无论是单向还是双向，都存在着公钥如何被安全传输的问题。
客户端和服务器端都以为自己是在和对方通信，但其实他们都是在和中间人C通信。需要想个办法证明服务器收到的公钥，的确就是客户端发出的，中间没人可以篡改公钥，反过来也是一样的。
数字证书和证书认证中心
引入一个中间机构CA。当服务器把公钥发给客户端时，不是直接发送公钥，而是发送公钥对应的证书。服务器先把自己的公钥发送CA，CA给服务器颁发一个数字证书（Certificate），这个证书相当于服务器的身份证。之后，服务器把证书给客户端，客户端可以验证证书是否为服务器下发的。
根证书和CA信任链
SSL/TLS四次握手
在建立TCP连接之后，数据发送之前，SSL/TLS协议通过四次握手、两个来回，协商出客户端和服务器之间的对称加密秘钥。第一个来回，是公钥的传输与验证过程（通过数字证书）；第二个来回基于第一个来回得到的公钥，协商出对称加密的秘钥。接下来，就是正常的应用层数据包的发送操作了。为了协商出对称加密的秘钥，引入了几个随机数。
HTTPS过程
https主要解决安全问题，http/2主要解决性能问题。
TCP
- 解决不丢问题：ACK+重发。服务器每次收到一个包，就要对客户端进行确认，反馈给客户单已经收到了数据包；如果客户端在超时时间内没有收到ACK，则重发数据。
- 解决不重的问题，顺序ACK，例如，服务器给客户端回复ACK=6，意思是所有小于或等于6的数据包全部收到了，之后凡是再收到这个范围的数据包，则判定为重复的包，丢弃即可。
*解决时序错乱问题，服务器虽然接收数据包是并发的，但数据包的ACK是按照编号从小到大注意确认的，所以数据包的时序是有保证的。
总之，TCP通过ACK+重发+数据包顺序确认解决了丢包，乱序，重复的问题。
TCP的假连接（状态机）
为什么开始是处于CLOSED状态，而没有一个INT（初始）状态？是因为连接是复用的，每个连接用4元组唯一表示，关闭之后，后面又会开启，所以没有必要引入”初始“状态。
三次握手
四次挥手
TIME_WAIT状态存在的原因：
- close后，仍可能有数据包还在网络上”闲逛“，此时如果收到了这些数据包，可能会导致连接重开。4元组无法区分新老连接，导致之前的数据包在新连接打开后被当做新的数据包。老连接上的数据包会”串“到新连接上面，不可接受。任何一个IP数据包在网络上逗留的最长时间是MSL，这个值默认是120s。一个连接保持在TIME_WAIT状态后2xMSL后会进入CLOSE。
- 第四次发送的数据包，服务器是否收到是不确定的。可能会重新发送第三次的数据包，然后再次发送第四次的数据包，第三次和第四次数据包的时间和，最长是两个MSL，所以客户端在TIME_WAIT状态等待2xMSL时间。
产生的问题：
一个连接并不是想关就能立刻关的，关闭后还要等2xMSL时间才能重开，这就会造成一个问题，如果频繁地创建连接，最后可能导致大量的连接处于TIME_WAIT状态，最终耗光所有的连接资源。为了避免这种问题，可以采取如下措施： - 不要让服务器主动关闭连接。这样服务器的连接就不会处于TIME_WAIT状态。
- 客户端做连接池，复用连接，而不要频繁的创建和关闭。这其实也是HTTP1.1和HTTP/2采用的思路。
QUIC
略
