三路握手协议与慢启动算法的效果

互联网已经成为了我们生活中不可或缺的一部分。没有它，我们的生活就无法完整。 每天，每个互联网用户都会在网上进行数百次搜索。无论是简单的谷歌搜索，还是访问任何网站，没有人愿意等待漫长的响应时间。 在本文中，我们将探讨那些会影响互联网速度的时间延迟问题。 在互联网诞生之初，当TCP协议刚刚被引入时，就采用了这种三路握手机制。 随着时间的推移，人们完全不再使用三路握手机制了，而是选择使用TCP FastOpen技术来替代它。 不过，仍然有一种非常著名的拥塞控制算法。当TCP流开始传输时，总会用到这种算法。这种算法被称为“慢启动重启算法”。 在开始向网络发送相当于缓冲区大小的数据包之前，需要相当长的时间。即便带宽完全可用的情况下也是如此。

缓慢启动：

缓慢启动重启过程的目的是“估算”当前的数据传输速率，从而尽快得到一个“合理的估算值”。 该算法在新的TCP连接开始建立时，或者当链接处于空闲状态超过1个RTO时间时，会默认被触发执行。 cwnd的值随着每次RTT的增加而逐渐增加，从10增加到20、40、80等等。 当一个新的ACK信号到达发送方时，cwnd的值会增加1。 当发送方在收到一个确认信号后，它会向连接中发送2个新的数据包。 其中，有一包数据被发送出来以弥补之前已经传输的数据量；另外一包数据则根据拥塞窗口大小的增加而发送。

慢启动算法的影响

每个TCP连接都必须经历慢启动阶段。这意味着，在连接建立之后，我们无法立即利用链路上的“可用带宽”。数据传输是从“initcwnd”开始的，并且每隔一个RTT时间，数据传输速率就会翻倍。假设发送方的传输速率受到接收方所公布的窗口大小的限制，该窗口大小为64KB。因此，发送方不能直接发送64KB的数据；它需要先经历慢启动阶段，然后才逐渐增加传输速率。

发送方需要花费的时间来扩大其拥塞窗口的大小，以便能够一次传输64KB的数据。这个时间可以通过给定的公式来计算得出。

时间 = RTT × ⌈log₂(1 + N/初始传输速率)⌉

在何处，

• RTT指的是往返时间。
• 初始化CWND这是一个局部变量，用于存储初始的拥塞窗口大小。这个数值在每种操作系统中都是默认设置的。
• N 这就是所期望的拥塞窗口大小，比如64KB。

例如：

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 ÷ 段大小 = 65536字节 ÷ 1460字节 = 44.88个段)

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
因此，发送方可以在168毫秒之后同时传输64KB的数据。

三方握手：

三路握手是建立初始连接的过程。 客户首先向服务器发送连接请求（即SYN数据包）。 如果服务器端有足够的内存和其他资源，那么服务器就会接受来自客户端的连接请求，并通过发送SYN+ACK数据包来确认这一请求。 当客户端接收到这个数据包时，它就会开始与服务器的实际通信。从下一个数据包开始，客户端会发送GET请求。 在回复中，服务器会发送客户端所请求的实际数据。

三路握手的影响：

如果RTT的测量结果为56毫秒的话。 这么长的时间都浪费在了建立连接上而已。 客户端向接收方发送SYN数据包，以请求建立连接。 服务器通过发送一个SYN+ACK数据包来回应客户端。 这种双向通信方式会占用与整个RTT相当的时间。 从下一个数据包开始，真正的通信过程就发生了。在这个过程中，客户端首先通过发送GET请求来向服务器请求某些数据。 因此，一个RTT指的是客户端在三次握手过程中所支付的成本。 如果能够以某种方式避免这种握手操作的话，那么每次客户端连接到服务器时，就可以节省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.

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

步骤2：接收方在时间=28毫秒时接收到SYN数据包，这属于单向传输时间。接收方接受了连接请求，并在收到发送方的SYN数据包后的同一时刻，发送了SYN+ACK数据包。

步骤3：ACK消息在时间t=56毫秒时到达发送方。而数据包从接收方传输到发送方还需要28毫秒的时间。因此，整个数据包的往返时间共计为1个RTT时间。现在，发送方和接收方之间已经建立了连接，使用的是三路握手机制来建立连接。

步骤4：现在，发送方在时间56毫秒时向接收方发送GET请求。该请求需要28毫秒才能到达接收方，之后接收方就能收到这个GET请求了。

步骤5：在时间等于84毫秒时，服务器收到了一个GET请求。

步骤6：服务器处理该请求需要40毫秒，之后才会生成用于回复的数据包。在40毫秒过后，服务器会在时间点124毫秒的同时发送这10段数据，而无需等待任何ACK信号。

步骤7：发送方或客户端会依次接收各个回复数据包，并为每个数据包发送ACK信号给服务器。客户端在时间为152毫秒时就能收到全部10个数据包。当接收到ACK信号后，服务器会将其拥塞窗口大小增加1。最初，拥塞窗口大小为10，因此服务器会同时发送10个数据包。当服务器的拥塞窗口增加1后，它就会向连接中发送2个新的数据包。

步骤8：在短短的RTT时间内，服务器就能收到所有10个数据包的确认消息。因此，此时服务器的发送速率将达到10×2=20字节/秒。此外，此时服务器还向网络中发送了20个新的数据包，而之前已经收到了10个数据包的确认消息。

步骤9：现在，在发送方和接收方之间的管道中，有20个段位，且这些段位在时间t=180毫秒时已经到达。

步骤10：当时间达到 208 毫秒时，客户端将会收到所有这些数据包。

步骤11：在时间达到236时，服务器会发送15个新的数据包。此时，服务器将会收到这20个数据包的确认信号。在此期间，服务器每收到一个确认信号，就会增加其传输速率1个单位。不过，由于还剩下15个数据包需要发送，因此服务器无法为每个确认信号发送两个数据包（总共45个数据包）。现在，服务器的传输速率为40个单位。

步骤12：因此，在时间达到 264 毫秒时，客户端已经接收到了 15 个数据段。所以，向客户端发送 64 KB 的数据需要 264 毫秒的时间。

步骤13：在时间=292毫秒时，将有15个ACK信号发送给服务器。此时，cwnd的值将变为40+15=55。但是，服务器此时并没有数据需要发送。

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

服务器与客户端之间的可用带宽仅为5MBPS。不过，一个大小为64KB的文件仍然需要264毫秒才能加载完成。即使我们将带宽提高到50MBPS或5GBPS，这个时间也不会缩短。如果客户端访问的是Gmail或Google的服务器，那么页面加载时间仍然会是264毫秒。因此，通过增加带宽是无法减少这一时间的。

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

假设连接处于空闲状态的时间短于RTO，那么慢启动过程不会再次开始。此时，客户端会向服务器发送另一个GET请求。

步骤1：发送方在时间0毫秒时发送了GET请求。

步骤2：GET请求在时间28毫秒时到达服务器。

步骤3：服务器处理请求所需的时间为40毫秒。在时间68毫秒时，服务器会生成回复，并将其发送给客户端。

步骤4：请注意，在之前的传输过程中，服务器的cwnd已经达到了55。因此，在时间=68毫秒时，服务器会同时发送45个数据段。

步骤5：在时间达到96毫秒时，客户端接收到了全部45个数据段。

因此，缓慢的启动过程浪费了 264 – 96 = 168 毫秒的时间。

结论：

264 毫秒 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 毫秒.
Server processing time = 40毫秒
Time elapsed in 3-way Handshakes =56毫秒
 
总时间 = 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毫秒.

如果不存在启动过程缓慢以及需要进行三次握手的情况，那么所需的传输时间就会是96毫秒。