WEB性能--TCP

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文链接：https://blog.csdn.net/caomage/article/details/100515986

一、TCP介绍

因特网有两个核心协议：IP和TCP。IP，即Internet Protocol（因特网协议），负责联网主机之间的路由选择和寻址；TCP，即Transmission Control Protocol（传输控制协议），负责在不可靠的传输信道上提供可靠传输的抽象层。

TCP向应用层隐藏了大多数网络通信的负责细节，比如丢包重发、按序发送、拥塞控制、数据完整等等。采用TCP数据流可以确保发送的所有字节能够完整的被接收到，而且到达客户端的顺序也一样。也就是说TCP专门为精确传送做了优化，但并未过多顾及时间。这样也给优化浏览器Web性能带来了挑战。

二、三次握手

所有的TCP连接一开始都要经过三次握手。客户端与服务器在交换应用数据之前，必须就起始分组序列号，以及其他一些连接的相关细节达成一致。出于安全考虑，序列号由两端随机生成。

1. SYN 客户端选择一个随机序列号x，并发送一个SYN分组，其中可能还包含其他TCP标志和选项。
2. SYN ACK 服务器给x加1，并选择自己的一个随机序列号y，追加自己的标志和选项，然后返回响应。
3. ACK 客户端给x和y加1并发送握手期间的最后一个ACK分组。 三次握手完成后，客户端与服务器之间就可以进行通信了。客户端可以在发送ACK分组之后立即发送数据，而服务器必须等接收到ACK分组之后才能发送数据。这个启动通信的过程适用于所有的TCP连接，因此对所有使用TCP的应用具有非常大的性能影响，因为每一次传输应用数据之前，都必须经历一次完整的往返。 三次握手带来的延迟使得每创建一个新的TCP连接都要付出很大的代价。而这也决定了提高TCP性能的关键在于想办法重用连接。

1. TCP快速打开

前面说到重用TCP连接可以提高TCP的性能，但是连接并不是想重用就可以重用的。事实上，由于非常短的TCP连接在互联网上随处可见，握手阶段已经成为影响网络总延迟的一个重要因素。为解决这个问题，出现了一种叫TFO（TCP Fast Open，TCP快速打开）的方案。

三、拥塞预防及控制

由于传输层和数据报层的交互，会导致一些不常见的拥塞问题。特别是IP网关容易受到我们称为“拥塞崩溃”现象的严重影响。

那什么是拥塞崩溃呢？分组往返的时间超过了所有主机的最大中断间隔，于是相应的主机会在网络中制造越来越多的分组副本，使得整个网络陷入瘫痪。最终，所有交换节点的缓冲区都将被填满，多出来的分组必须删掉。目前的分组往返时间已经设定为最大值。主机会把每个分组都发送好几次，结果每个分组的某个副本会抵达目标。这就是拥塞崩溃。

为了解决这些问题，TCP加入了很多机制，以便于控制双向发送数据的速度，比如流量控制、拥塞控制和拥塞预防机制。

1. 流量控制

流量控制是一种预防发送端过多向接收端发送数据的机制。否则，接收端可能因为忙碌、负载过重或缓冲区容量有限而无法处理。为了实现流量控制，TCP连接的每一方都要通知对方自己的接收窗口（rwnd），其中包含能够保存数据的缓冲区空间大小信息。

第一次建立连接时，两端都会使用自身系统默认设置来发送rwnd。浏览网页通常主要从服务器向客户端下载数据，因此客户端窗口更可能成为性能瓶颈。然而，如果是在上传图片或视频，即客户端向服务器传送大量数据时，服务器的接收窗口大小又可能成为制约因素。

不管怎样，如果其中一端跟不上数据传输，那它可以向发送端通知一个较小的窗口。假如窗口为零，则意味着必须由应用层先清理缓冲区中的数据，才能继续接收剩余的数据。这个过程贯穿每个TCP连接的整个生命周期：每个ACK分组都会携带相应的最新rwnd（接收窗口）值，以便两端动态调整数据流速，使之适应发送端和接收端的容量以及处理能力。

2. TCP慢启动

尽管TCP有了流量控制机制，但网络“拥塞崩溃”现象仍然存在。流量控制确实可以防止发送端向接收端过多发送数据，但却没有机制预防任何一端向网络过多发送数据。换句话说，发送端和接收端在建立连接之初，谁也不知道可用带宽是多少，因此需要一个估算机制，然后还要根据网络中不断变化的条件动态地去改变速度。

要说明这种动态适应机制的好处，可以想象你在家里观看一个大型的流视频。视频服务器会尽最大努力根据你的下行连接提供高品质信息。而此时，你家里又有人打开一个新连接下载某个软件的升级包。可供视频流使用的下行带宽一下子少了很多，视频服务器必须调整它的发送速度。否则，如果继续保持同样的速度，那么数据很快就会在某个中间的网关越积越多，最终会导致分组被删除，从而降低网络的传输效率。

要理解慢启动，最好看一个例子。假如你正在从服务器下载一个文件。首先，三次握手，而且在此期间双方各自通过ACK分组通知对方自己的接收窗口大小（rwnd）。在发送完最后一次ACK分组后，就可以交换应用数据了。

此时，根据交换数据来估算客户端与服务器之间的可用带宽是唯一的方法，而且这也是慢启动算法的设计思路。首先，服务器通过TCP连接初始化一个新的拥塞窗口（cwnd）变量，将其值设置为一个系统设定的保守值。发送端不会通告cwnd（拥塞窗口）变量，即发送端和接收端不会交换这个值。此时，保存文件的服务器只是维护这么一个私有变量。然后又有一条新的规则，即客户端与服务器之间的最大可以传输（未经ACK确认的）数据量取rwnd（拥塞窗口）和cwnd（接收窗口）变量中的最小值。那服务器和客户端怎么确定拥塞窗口大小的最优值呢？毕竟，网络状况随时都在变价，即使相同的两个网络节点之间也一样。如果可以使用算法来确定每个链接的窗口大小，而不用手工调整就最好了。

解决方案就是慢启动！即在分组被确认后增大窗口大小，慢慢的启动。新的TCP链接传输的最大数据量取rwnd（接收窗口）和cwnd（拥塞窗口）中的最小值，而服务器实际上可以向客户端发送四个TCP字段，然后就必须停下来等待确认。此后，每收到一个ACK，慢启动算法就会告诉服务器可以将它的cwnd（拥塞窗口）增加一个TCP字段。每次收到ACK之后，都可以多发送两个新的分组。TCP连接的这个阶段称为“指数增长”阶段，因为客户端和服务器都在向两者之间网络路径的有效带宽靠拢。

慢启动导致客户端与服务器之间经过很长时间才能达到接近最大速度的问题，对于大型流式下载服务的影响倒是没那么明显，因为慢启动的时间可以分摊到整个传输周期中消化掉。可是对于很多HTTP连接，特别是一些短暂、突发的连接而言，常常会 出现还没有达到最大窗口请求就被终止的情况。换句话说，很多web应用的性能常常受到服务器与客户端之间往返时间的制约。因为慢启动限制了可用的吞吐量，而这对于小文件传输非常不利。

四、带宽延迟积

TCP内置的拥塞控制和预防机制对性能还有另一个重要影响：发送端和接收端理想的窗口大小，一定会因为往返时间以及目标传输速率而变化。

我们知道，发送端和接收端之间在途未确认的最大数据量，取决于拥塞窗口（cwnd）和接收窗口（rwnd）的最小值。接收窗口会随每次ACK一起发送，而拥塞窗口则由发送端根据拥塞控制和预防算法动态调整。

无论发送端发送的数据还是接收端接收的数据超过了未确认的最大数据量，都必须停下来等待另一方ACK确认某些分组才能继续。要等待多久，取决于往返时间。

带宽延迟积（BDP，Bandwidth-delay product）：数据链路的容量与其端到端延迟的乘积。就是任意时刻处于在途未确认状态的最大数据量。

发送端或接收端无论谁被迫频繁的停止等待之前分组的ACK，都会造成数据缺口，从而必然限制连接的最大吞吐量。为解决这个问题，应该让窗口足够大，以保证任何一端能在ACK返回前持续发送数据。只有传输不中断，才能保证最大吞吐量。而最优窗口大小取决于往返时间。无论实际或通告的带宽是多大，窗口过小都会限制连接的吞吐量。

五、队首阻塞

TCP在不可靠的信道上实现了可靠的网络传输。基本的分组错误检测与纠正、按序交付、丢包重发，以及保证网络最高效率的流量控制、拥塞控制和预防机制，让TCP成为大多数网络应用的传输协议。

虽然TCP很流行，但它并不是唯一的选择，而且在某些情况下也是最佳选择。特别是按序交付和可靠交付有时候并不必要，反而会导致额外的延迟，对性能造成负面影响。

可以想一想，每个TCP分组都会带着一个唯一的序列号被发出，而所有分组必须按顺序传送到接收端。如果中途有一个分组没能到达接收端，那么后续分组必须保存在接收端TCP缓冲区中等待丢失的分组重新发送过来。这一切都发生在TCP层，应用程序对TCP重发和缓冲区中排队的分组一无所知，必须等待分组全部达到才能访问数据。在此之前，应用程序只能在通过套接字读取数据时感到延迟交付。这种效应称为TCP的队首（HOL，Head of Line）阻塞。

六、针对TCP的优化建议

1、 主要问题

经过前面的介绍，TCP主要的问题如下：

• TCP三次握手增加了整整一次往返时间；
• TCP慢启动将被应用到每个新连接；
• TCP流量以及拥塞控制会影响所有连接的吞吐量；
• TCP的吞吐量由当前拥塞窗口大小控制。

2、 服务器配置优化

1. 增大TCP的初始拥塞窗口 ；
2. 慢启动重启 ；
3. 窗口缩放 ；
4. TCP快速打开 。

3、 应用程序优化

1. 再快也快不过什么也不用发送，能少发就少发；
2. 如果不能让数据传输更快，可以让它们的传输距离更短；
3. 重用TCP连接。