三向握手和慢启动算法的影响

互联网成为了我们生活不完整的东西。每个互联网用户每天都会在互联网上进行 100 次查询，无论是简单的谷歌搜索还是访问任何网站，没有人喜欢响应延迟。在本文中，我们将讨论影响互联网速度的时间延迟。在 Internet 最初引入 TCP 时，引入了三次握手。在一段时间内，使用 TCP FastOpen 完全避免了 3 次握手。但是，仍然有一个非常臭名昭著的拥塞控制算法，它总是在 TCP 流启动时调用，这是一种慢启动重启算法。即使带宽完全可用，这也需要大量时间才能开始将缓冲区大小的数据包发送到网络中。

慢启动：

慢启动重启过程的目的是“估计”cwnd 并快速得出“体面的估计”。默认情况下，当新的 TCP 流启动或链路空闲 1 个 RTO 时间时，会调用此算法。每个 RTT 的 cwnd 值从 10 缓慢增加到 20、40、80 等等。当一个新的 ACK 到达发送方时，cwnd 加 1。发送者在收到一个 ACK 时向链路发送 2 个新数据包。发送一个数据包以补偿传递的数据包，另一个根据拥塞窗口大小的增加值发送。

慢启动算法的影响

每个 TCP 连接都必须经过慢启动阶段。这意味着我们不能在连接建立后“立即”利用链路上的“可用容量”。数据传输以“initcwnd”开始，并在（大约）每个 RTT 中翻倍。假设发送方受限于接收方的 64KB 广告窗口。发送方不能直接开始发送64KB；它以慢启动开始并提高发送速率。

发送方增大其拥塞窗口 (cwnd) 以使其一次可以传输 64KB 所需的时间可以使用给定的公式计算。

$Time = RTT \times\lceil{\log_{2}(1+\frac{N}{init cwnd})}\rceil$

在哪里，

• RTT代表往返时间；
• init_cwnd是存储初始拥塞窗口大小的局部变量，在每个操作系统中默认设置。
• N是所需的拥塞窗口大小，例如 64 KB。

例子：

RTT = 56 ms (London to New York)
Initial congestion window (initcwnd) = 10 segments
1 segment size = 1460 bytes
For the TCP Sender to transmit 64KB simultaneously, it must have a 
congestion window value of approximately 45 segments.
N = (64KB ÷ segment size = 65536 bytes ÷ 1460 bytes = 44.88 segments)

Time = RTT x ceil(log2(1 + 45/10))
= RTT x ceil(log2(5.5))
= 56 ms x ceil(2.459)
= 56 ms x 3
= 168 ms
Thus, the sender would be able to transmit 64 KB simultaneously after 168 ms.

三向握手：

三向握手是初始连接建立过程。客户端首先向服务器发送连接请求（SYN 数据包）。如果服务器端有可用的内存空间和其他资源，则服务器接受传入的连接请求，并通过发送 SYN+ACK 数据包向客户端确认。当客户端收到此数据包时，它开始与服务器进行实际通信，并从下一个数据包开始发送 GET 请求。在回复中，服务器发送客户端请求的实际数据。

三向握手的影响：

如果 RTT 测量为 56 毫秒。这么多时间只是浪费在连接建立上。客户端将 SYN 包发送给接收者以请求连接。服务器通过发送 SYN+ACK 数据包来响应客户端。这种双向循环消耗了整个 RTT 的时间。从下一个数据包开始，真正的通信发生了，其中客户端首先通过在新数据包中发送 GET 请求从服务器请求一些数据。因此，一个 RTT 是客户端为 3 次握手支付的成本。如果以某种方式可以避免这种握手，那么在这种情况下，每次客户端连接到服务器时都可以节省 56 毫秒。

TCP 握手和慢启动算法的影响

假设变量：

Round Trip Time = 56 ms, standard RTT time between London and New York
Available Bandwidth  to both server and client is= 5 MBPS
Receiver window size (rwnd) of both client and server= 
                    65,535 bytes = 64KB = 45 segments
Initial congestion window (init_cwnd)= 10 segments

Server processing time to process the given GET query and 
generate the corresponding response is = 40 ms

Assume the network is clean, with no packet loss and 
1 ACK per packet, only GET requests are sent.

TCP 握手和慢启动算法的影响

步骤 1：发送方在 time=0 时发送 SYN 数据包。

步骤 2：接收方在 time=28 ms 时收到 SYN 数据包，这是单向时间。接收方接受连接请求并在时间=28 ms 时发回 SYN+ACK 数据包，就在它收到发送方的 SYN 数据包之后。

步骤 3： ACK 在 time=56 ms 到达发送方，另外 28 ms 被数据包从接收方到达发送方，这使得总共有一个 RTT 时间，数据包的双向行程。现在使用 3 次握手在发送方和接收方之间建立连接。

第 4 步：现在发送方在 time=56 ms 时向接收方发送 GET 请求。它需要 28 毫秒才能到达，接收方收到 GET 请求。

第 5 步：在 time=84 ms 服务器收到 GET 请求。

第 6 步：服务器需要 40 毫秒来处理请求并生成数据以作为回复数据包发送。经过 40 毫秒后，服务器在 time=124 毫秒同时发送 10 段数据，而无需等待单个 ACK 的到来。

第七步：发送方或客户端将开始一个接一个地接收回复数据包，并将每个数据包的ACK发送给服务器。客户端将在 time=152 ms 之前获得所有 10 个段。在接收到 ACK 数据包时，服务器将每个 ACK 数据包的拥塞窗口大小增加 1。最初，cwnd 为 10，因此它同时发送 10 个段。当服务器将其 cwnd 增加 1 时，它会将 2 个新数据包发送到链接中。

步骤 8：在一个 RTT 时间内，服务器将获得所有 10 个数据包的 ACK，因此其 cwnd 在 time=180 ms 时将变为 10*2 = 20。此外，此时服务器已将 20 个新段发送到链接中，而不是最初的 10 个段，其交付已经是 ACK。

第 9 步：现在，发送方和接收方之间的管道中有 20 个段，时间 = 180 毫秒。

第 10 步：通过 time=208 ms，客户端将收到所有这些数据包。

第 11 步：通过 time=236 服务器发送 15 个新段。此时服务器将收到所有这 20 个段的 ACK。在 intrim 中，服务器将每个 ACK 将其 cwnd 增加 1，但不能为每个 ACK 发送 2 个新数据包，因为只剩下 15 个段要发送（总共 45 个段）。现在 cwnd=40。

第 12 步：因此在 time=264 ms 时，有 15 个段到达客户端。因此，将 64 KB 的数据发送到客户端需要 264 毫秒。

Step 13：在time=292 ms时，15个ACK会来到服务器，cwnd会变成40+15 = 55，但是服务器没有数据要发送。

因此，向客户端发送 45 个数据包需要 264 毫秒。

服务器和客户端之间的可用带宽为 5 MBPS，但 64 KB 的文件仍然需要 264 毫秒。即使我们将带宽增加到 50 MBPS 或 5 GBPS，这个时间也不会减少。如果客户端访问的是 Gmail 或 google 服务器，那么页面加载时间将为 264 毫秒，并且这个时间不能通过增加带宽来减少。

在同一个连接中再次请求同一个文件

假设连接空闲时间少于 RTO 几秒钟，慢启动没有重新启动，客户端向服务器发送另一个 GET 请求。

第 1 步：发送方在 time=0 ms 时发送 GET 请求。

第 2 步： GET 请求在 time=28 ms 时到达服务器。

第 3 步：服务器处理请求需要 40 毫秒的时间。在 time=68 ms 时生成回复并将其发送给客户端。

第四步：注意服务器的cwnd在之前的传输中已经是55了。因此，服务器将在 time=68 ms 时同时发送 45 个段。

第 5 步：在 time=96 ms 时，客户端收到所有 45 个段。

因此，慢启动浪费了 264 – 96 = 168 ms。

结论：

264 ms taken by the server to successfully(with ACK) send 45 segments to the client.
By formula time taken by Slow Start to grow the cwnd to 64 KB= 168 ms.
Server processing time = 40 ms
Time elapsed in 3-way Handshakes = 56 ms
 
Total time = 3-way-handshake + server_processing + Slow_start
264 = 56(3-way-handshake) + 40(server response time) + 168(Slow_start) ms

Thus, slow start and 3-way Handshakes have wasted = 168 ms + 56 ms = 224 ms.

如果没有慢启动和 3 次握手，则需要 96 ms。