连接管理

由TCP承载

在TCP/IP协议层中，HTTP协议属于七层协议，当HTTP数据传输过程中到了第四层使用的就是TCP协议。TCP为HTTP提供了一条稳定可靠的传输通道，保证HTTP的数据能正确的传输到对端。
如下图HTTP的数据在传输层被封装成TCP段，然后TCP段在网络层被封装成IP数据报，然后在数据链路层被疯转层帧，这样就到达了我们的物理传输设备，传输到另一端，另一端会走一个逆流程进行解包。

每个IP报文都包括：

• IP分组首部（通常是20字节），包含源和目的IP以及其他信息
• 一个TCP端首部（通常是20字节），包含源和目的端口以及其他信息
• 一个TCP数据块（0或者多字节），HTTP报文数据
  我们平常见到HTTPS是在HTTP和TCP之间加了一个密码加密层（TLS或者SSL）
  

TCP性能

可以说HTTP就是跑在TCP上的，TCP的性能决定这HTTP的性能，下面我们看一下一个HTTP事务时间花在哪里了：

事务的时间由硬件的能力（传输设备，服务器），网络带宽，报文的大小，程序的处理能力来决定。
下面我们聚焦几点：

连接时延

上图中，我们只想看一下某个资源是否修改，但是我们的四次连接中有两个连接用于握手了，想象一下如果我们有上百万的这样的请求，那会怎么样呢？其实这样的问题我们可以用连接复用的手段来解决，后面我们会提到。

延时确认

TCP是稳定可靠的传输协议，每个TCP段都有自己的序列号，当它发送出去后，接收者应该返回一个确认，如果在指定时间内，发送者没有接收到确认，他就会重传。但是确认报文很小，大量的确认报文也是一种资源浪费，所以TCP有了延时确认。当要发送确认的时候，暂停一段时间（一般是100~200毫秒），看看是否有其他的返回消息，如果有就捎带上。

慢启动

当客户端和服务端建立了连接，此时服务端的程序其实是有问题的，而我们的客户端还一下子发送大量的请求，这样是不合理的。
慢启动的意思就是说，如果你本次成功传递了一个分组，那么你下次就能传送两个分组了。

Nagle算法

每个TCP的段都至少装载了40字节的标记和首部，如果每个段包含的数据很少，这样存在大量的段时，就是资源的浪费了。Nagle算法试图发送一个分组前，将大量的TCP数据绑定在一起，Nagle算法鼓励发送全尺寸的段。只有当所有其他分组都被确认以后，Nagle算法才允许发送非全尺寸的分组，如果缓存中积累了足够发送一个全尺寸的分组的数据时，也会将缓存中的数据发送出去。

TIME_WAIT累计和端口耗尽

TCP一个连接时<源IP 源端口 目的IP 目的端口>的组合，从四次断开角度看， 被动关闭的一方会有一个Time_wait的阶段，这个阶段一般是2MSL（通常120秒），以确保这段时间内这个这个端口不会重用。如果你的源端口的数据量是60000个，那么你并发超过60000/120=500秒每次，那么端口就会耗尽。

HTTP连接的处理

connection首部

承载的内容：

• HTTP首部，标识这些首部只与此次连接有关系，不应该转发到其他地方
• 任意标签值，用于描述此连接的非标准选项
• close，标识操作完成后关闭持久连接
  第一点的情况有可能出现在，有代理的情景下。比如：客户端和代理有些连接属性如token，close等属性，就不应该转发给后端，此时我们就可以在connection内部写上这些首部，在代理层转发时就应该删除掉这些首部。

串行事务

顾名思义就是排队做事情，试想一下我们的WEB页面有五十个图片，当我们打开页面是，浏览器先请求第一个，然后请求第二个…，如果我们的页面是这样，你会不会砸电脑呢？
针对这个问题，HTTP给出了四个答案：

• 并行连接
• 持久连接
• 管道化连接
• 复用连接
  （1）并行连接
  并行连接就是同时建立多个连接，每个连接完成一个事务。如下面我们五十个照片的场景，我们浏览器和我们的服务器同时建立五十个连接，每个连接完成一个图片的加载。但是打开大量的连接对于服务端来说是一个负担，当客户端非常多时，这会耗尽服务端的内存。所以我们可以说一定程度上的并行连接可以加快访问速度。
  （2）持久连接
  如果我们这五十张图片都来自一个站点，我们是否可以只建立一次连接，然后传送五十张图片，再关闭连接呢？这就是Http1.1提出的持久连接，它允许设备在事务处理结束后保持连接打开，以便未来使用。重用持久连接比重新打开一个连接要快，因为慢启动。
  持久连接的出现也带来了问题，就是什么时候关闭连接，如果时间选择不合适，就有可能出现大量空闲的持久连接或者连接不能合理的持久。另一方面，当要传递的事务特别多时，比如十万个照片，这时单纯的持久连接也是很乏力的。
  所以持久连接+并行连接是个不错的方案，事实上，我们的浏览器就是这么做的，他们会打开少量的并行连接，每个连接都是持久连接，
  HTTP/1.0+ "keep-alive"和现代的 HTTP1.1 “persistent”。
  HTTP/1.0 的keep-alive需要客户端把connection： keep-alive包含在首部中，服务端会回送一个connection：keep-alive,这样一个持久连接就打开了。另外keep-alive: max=, timeout= ;首部用于设置这个持久连接还要保持多少个事务或者多长时间。
• 如果服务端没有回应connection：keep-alive，那么客户端应该关闭这个链接
• 客户端必须把connection： keep-alive这个首部包含在所有希望保持持久连接的报文中，如果一个报文没有包含，那么服务端就会在这个报文处理之后关闭连接
• 有些比较老的代理或者网关，不理解持久连接这种机制。他会把connection： keep-alive转发给后端，后端认为你要持久连接了，就回应connection： keep-alive，这时客户端和老代理，以及老代理和服务端都建立起了持久连接。客户端发送一个请求，老代理转发给后端，后端返回报文，老代理转发给客户端。然后客户端认为是持久连接，就会发送下一个事务请求，但是老代理认为一个事务完事了，应该关闭了，所以老代理就不会处理这个请求了，这样这个连接就挂起了。
• 为支持老代理，网景公司提出了proxy_connection首部。客户端发送proxy_connection：keep-alive；。老代理会转发这个首部，服务端会忽略这个首部。新代理会把这个首部转换成connection： keep-alive发送给后端。但是当存在一个老代理和新代理组合是，这个首部也无能为力
  HTTP1.1的持久连接
• HTTP1.1的连接默认就是持久连接，除非在报文中包含connection：close；
• HTTP1.1的代理必须分别管理与客户端和服务器的持久连接----每个持久连接都只适用于一跳传输
  （3）管道化连接
  HTTP1.1允许在持久爱连接时可选的使用请求管道。也就是说在响应到达之前，可以将多条请求放入队列中。当第一条请求通过网络流向服务端时，第二条和第三条也开始发送。
• 如果HTTP客户端无法确认连接时持久连接，就不应该使用管道
• 必须按照与请求相同的顺序回送响应

---

先写到这里了，有问题进QQ群630300475聊一聊，大家一起进步