HTTP连接

大概内容

1. HTTP 是如何使用 TCP 连接的?
2. TCP 连接的时延、瓶颈以及存在的障碍?
3. HTTP 的几种连接形式
4. 如何关闭连接

一 HTTP是如何使用 TCP 连接的(原理 重点)

例如我们访问

1.TCP流是分段的、由IP分组传送

HTTP 要传送一条报文时，会以流的形式将报文数据的内容通过一条打开的TCP 连接按序传输。TCP 收到数据流之后，会将数据流砍成被称作段的小数据块，并将段封装在IP 分组中,如下图结构

其中TCP 段的首部包含了TCP 端口号、TCP 控制标记，以及用于数据排序和完整性检查的一些数字值(数据有序和完整性保证)。
TCP 连接是通过4 个值来识别的: 源IP 地址、源端口号、目的IP 地址、目的端口号 ,这4个值中有任意一个不同都是不同的连接

WireShark抓包分析

二 性能(重点)

HTTP事务的时延

1. 将URL转换为IP的时间
2. 连接建立
3. 网络传输
4. 服务器回送HTTP 响应

以上这些TCP 网络时延的大小取决于硬件速度、网络和服务器的负载，请求和响应报文 的尺寸，以及客户端和服务器之间的距离。

性能聚焦区域

本节其余部分列出了一些会对HTTP 程序员产生影响的、最常见的TCP 相关时延，
其中包括：
• TCP 连接建立；
• 用于捎带确认的 TCP 延迟确认算法；
• TCP 慢启动拥塞控制；
• 数据聚集的 Nagle 算法；
• TIME_WAIT 时延和端口耗尽。

1 TCP 连接建立(三次握手)
小的HTTP 事务可能会在TCP 建立上花费50%，或更多的时间。
改善:重用现存连接。

2 延迟确认算法
由于因特网自身无法确保可靠的分组传输（因特网路由器超负荷的话，可以随意丢 弃分组），所以TCP 实现了自己的确认机制来确保数据的成功传输每个TCP 段都有一个序列号和数据完整性校验和。每个段的接收者收到完好的段时，都会向发送者回送小的确认分组。如果发送者没有在指定的窗口时间内收到确认信息，发送者就认为分组已被破坏或损毁，并重发数据。
延迟确认算法优点: 于确认报文很小，所以TCP 允许在发往相同方向的输出数据分组中对其进行“捎带”。TCP 将返回的确认信息与输出的数据分组结合在一起，可以更有效地利用网络。
弊端:HTTP 具有双峰特征的请求- 应答行为降低了捎带信息的可能。当希望有相反方向回传分组的时候，偏偏没有那么多,这时延迟确认算法会引入相当大的时延（通常是100 ～ 200 毫 秒）。如果在那 个时间段内没有输出数据分组，就将确认信息放在单独的分组中传送。

3 TCP 慢启动
TCP 数据传输的性能还取决于TCP 连接的使用期（age）。TCP 连接会随着时间进行自我“调谐”，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐被称为TCP 慢启动（slow start）。
改善:重用现存连接。
　
4 Nagle算法与TCP_NODELAY
优点:将大量TCP 数据绑定在一起，以提高网络效率。(缓存的概念)
缺点:首先，小的HTTP 报文可能无法填满一个分组，可能会因为等待那些永远不会到来的额外数据而产生时延。其次，Nagle 算 法与延迟确认之间的交互存在问题——Nagle 算法会阻止数据的发送，直到有确认分组抵达为止，但确认分组自身会被延迟确认算法延迟100 ～ 200 毫秒。
改善:向TCP 写入大块的数据可设置参数TCP_NODELAY，禁用Nagle 算法，提高性能。

5 IME_WAIT累积与端口耗尽
当某个TCP 端点关闭TCP 连接时，会在内存中维护一个小的控制块，用来记录最近所关闭连接的IP 地址和端口号。这类信息只会维持一小段时间，通常是所估计的最大分段使用期的两倍（称为2MSL，通常为2 分钟）左右，以确保在这段时间内不会创建具有相同地址和端口号的新连接。

在只有一个客户端和一台Web 服务器的异常情况下，构建一条TCP 连接的4 个值：

其中的3 个都是固定的——只有源端口号可以随意改
客户端每次连接到服务器上去时，都会获得一个新的源端口，以实现连接的唯一性。但由于可用源端口的数量有限（比如，60 000 个），而且在2MSL 秒（比如，120秒）内连接是无法重用的，连接率就被限制在了60 000/120=500 次/ 秒。如果再不断进行优化，并且服务器的连接率不高于500 次/ 秒，就可确保不会遇到TIME_WAIT 端口耗尽问题。要修正这个问题，可以增加客户端负载生成机器的数量，或者确保客户端和服务器在循环使用几个虚拟IP 地址以增加更多的连接组合。

三 HTTP的几种连接形式(了解内容)

四 关闭连接(了解内容)

HTTP 规范建议，当客户端或服务器突然要关闭一条连接时，应该“正常地关闭传输连接”，但它并没有说明应该如何去做。
总之，实现正常关闭的应用程序首先应该关闭它们的输出信道，然后等待连接另一端的对等实体关闭它的输出信道。当两端都告诉对方它们不会再发送任何数据（比如关闭输出信道）之后，连接就会被完全关闭，而不会有重置的危险。但不幸的是，无法确保对等实体会实现半关闭，或对其进行检查。因此，想要正常关闭连接的应用程序应该先半关闭其输出信道，然后周期性地检查其输入信道的状态（查找数据，或流的末尾）。如果在一定的时间区间内对端没有关闭输入信道，应用程序可以强制关闭连接，以节省资源。