TCP协议中的三次握手和四次挥手(图解)

转自http://blog.csdn.net/whuslei/article/details/6667471

建立TCP需要三次握手才能建立，而断开连接则需要四次握手。整个过程如下图所示：

先来看看如何建立连接的。

首先Client端发送连接请求报文，Server段接受连接后回复ACK报文，并为这次连接分配资源。Client端接收到ACK报文后也向Server段发生ACK报文，并分配资源，这样TCP连接就建立了。

那如何断开连接呢？简单的过程如下：

【注意】中断连接端可以是Client端，也可以是Server端。

假设Client端发起中断连接请求，也就是发送FIN报文。Server端接到FIN报文后，意思是说"我Client端没有数据要发给你了"，但是如果你还有数据没有发送完成，则不必急着关闭Socket，可以继续发送数据。所以你先发送ACK，"告诉Client端，你的请求我收到了，但是我还没准备好，请继续你等我的消息"。这个时候Client端就进入FIN_WAIT状态，继续等待Server端的FIN报文。当Server端确定数据已发送完成，则向Client端发送FIN报文，"告诉Client端，好了，我这边数据发完了，准备好关闭连接了"。Client端收到FIN报文后，"就知道可以关闭连接了，但是他还是不相信网络，怕Server端不知道要关闭，所以发送ACK后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传。“，Server端收到ACK后，"就知道可以断开连接了"。Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，我Client端也可以关闭连接了。Ok，TCP连接就这样关闭了！

整个过程Client端所经历的状态如下：

而Server端所经历的过程如下：转载请注明:blog.csdn.net/whuslei

【注意】 在TIME_WAIT状态中，如果TCP client端最后一次发送的ACK丢失了，它将重新发送。TIME_WAIT状态中所需要的时间是依赖于实现方法的。典型的值为30秒、1分钟和2分钟。等待之后连接正式关闭，并且所有的资源(包括端口号)都被释放。

【问题1】为什么连接的时候是三次握手，关闭的时候却是四次握手？
答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。因为网络原因，主动关闭的一方发送的这个ACK包很可能延迟，从而触发被动连接一方重传FIN包。极端情况下，这一去一回，就是两倍的MSL时长。如果主动关闭的一方跳过TIME_WAIT直接进入CLOSED，或者在TIME_WAIT停留的时长不足两倍的MSL，那么当被动关闭的一方早先发出的延迟包到达后，就可能出现类似下面的问题：1.旧的TCP连接已经不存在了，系统此时只能返回RST包2.新的TCP连接被建立起来了，延迟包可能干扰新的连接。

定时器在TCP可靠传输的过程中起着举足轻重的作用。TCP在建立连接之后可能(保活keep-alive定时器是可选的)会 启动四个定时器。

TCP使用四种定时器(Timer，也称为“计时器”)：

重传计时器：Retransmission Timer

坚持计时器：Persistent Timer

保活计时器：Keeplive Timer

时间等待计时器：Time_Wait Timer。

(1)重传计时器：Retransmission Timer

重传定时器：为了控制丢失的报文段或丢弃的报文段，也就是对报文段确认的等待时间。当TCP发送报文段时，就创建这个特定报文段的重传计时器，可能发生两种情况：若在计时器超时之前收到对报文段的确认，则撤销计时器;若在收到对特定报文段的确认之前计时器超时，则重传该报文，并把计时器复位;

重传时间=2*RTT;

RTT的值应该动态计算。常用的公式是：RTT=previous RTT*i + (1-i)*current RTT。i的值通常取90%，即新的RTT是以前的RTT值的90%加上当前RTT值的10%.

Karn算法：对重传报文，在计算新的RTT时，不考虑重传报文的RTT。因为无法推理出：发送端所收到的确认是对上一次报文段的确认还是对重传报文段的确认。干脆不计入。

(2)坚持计时器：persistent timer

专门为对付零窗口通知而设立的。

当发送端收到零窗口的确认时，就启动坚持计时器，当坚持计时器截止期到时，发送端TCP就发送一个特殊的报文段，叫探测报文段，这个报文段只有一个字节的数据。探测报文段有序号，但序号永远不需要确认，甚至在计算对其他部分数据的确认时这个序号也被忽略。探测报文段提醒接收端TCP，确认已丢失，必须重传。

坚持计时器的截止期设置为重传时间的值，但若没有收到从接收端来的响应，则发送另一个探测报文段，并将坚持计时器的值加倍和并复位，发送端继续发送探测报文段，将坚持计时器的值加倍和复位，知道这个值增大到阈值为止(通常为60秒)。之后，发送端每隔60s就发送一个报文段，直到窗口重新打开为止;

补充：

坚持定时器的原理是简单的，当TCP服务器收到了客户端的0滑动窗口报文的时候，就启动一个定时器来计时，并在定时器溢出的时候向向客户端查询窗口是否已经增大，如果得到非零的窗口就重新开始发送数据，如果得到0窗口就再开一个新的定时器准备下一次查询。通过观察可以得知，TCP的坚持定时器使用1，2，4，8，16……64秒这样的普通指数退避序列来作为每一次的溢出时间。

糊涂窗口综合症

TCP的窗口协议，会引起一种通常叫做糊涂窗口综合症的问题，具体表现为，当客户端通告一个小的非零窗口时，服务器立刻发送小数据给客户端并充满其缓冲区，一来二去就会让网络中充满小TCP数据报，从而影响网络利用率。对于发送方和接收端的这种糊涂行为。

再次补充：

TCP通过让接收方指明希望从发送方接收的数据字节数(即窗口大小)来进行流量控制。如果窗口大小为 0会发生什么情况呢?这将有效地阻止发送方传送数据，直到窗口变为非0为止。

TCP不对ACK报文段进行确认， TCP只确认那些包含有数据的ACK报文段。

如果一个确认丢失了(这个确认是”接收方“向”发送方“发送的ACK，通知”发送方“自己的窗口已经非0了)，则双方就有可能因为等待对方而使连接终止：接收方等待接收数据(因为它已经向发送方通告了一个非 0的窗口)，而发送方在等待允许它继续发送数据的窗口更新。为防止这种死锁情况的发生，发送方使用一个坚持定时器 (persist timer)来周期性地向接收方查询，以便发现窗口是否已增大。这些从发送方发出的报文段称为窗口探查 (window probe)。

(3)保活计时器：keeplive timer

每当服务器收到客户的信息，就将keeplive timer复位，超时通常设置2小时，若服务器超过2小时还没有收到来自客户的信息，就发送探测报文段，若发送了10个探测报文段(没75秒发送一个)还没收到响应，则终止连接。

补充：

保活定时器更加的简单，还记得FTP或者Http服务器都有Sesstion Time机制么?因为TCP是面向连接的，所以就会出现只连接不传送数据的“半开放连接”，服务器当然要检测到这种连接并且在某些情况下释放这种连接，这就是保活定时器的作用。其时限根据服务器的实现不同而不通。另外要提到的是，当其中一端如果崩溃并重新启动的情况下，如果收到该端“前生”的保活探察，则要发送一个RST数据报文帮助另一端结束连接。

(4)时间等待计时器：Time_Wait Timer

在连接终止期使用，当TCP关闭连接时，并不认为这个连接就真正关闭了，在时间等待期间，连接还处于一种中间过度状态。这样就可以时重复的fin报文段在到达终点后被丢弃，这个计时器的值通常设置为一格报文段寿命期望值的两倍。

补充：

2MSL定时器：MSL是报文段做大生存时间(Maximum Segment Lifetime),设置这个定时器有两个目的：

其一是为了测量连接处于TIME_WAIT状态的时间.这样可以让TCP再次发送最后的ACK以防止这个ACK丢失(如果丢失，另一端会重传FIN)。

其二，为允许老的重复分节在网络中消逝。具体可以解释为，如果一个TCP连接在断开之前有迷途分节尚未消逝，在断开该TCP连接之后立刻重启一个同样的连接(双方的IP地址和端口port相同)，这时之前的迷途的老分节可能对新的新的TCP连接接收，从而造成未定义的错误。为了避免这种情况，TCP规定在TIME_WAIT状态，不能启动一个连接的化身。既然TIME_WAIT状态维持2MSL，这就保证了一个连接上的分组及其应该在 2MSL内都会消失。