TCP三次握手四次挥手

1、TCP协议中的三次握手和四次挥手(图解)分类：基础知识2011-08-07 20:4375897人阅读评论(22)收藏举报tcpserversocket网络建立TCP需要三次握手才能建立，而断开连接则需要四次握手。整个过程如下图所示：先来看看如何建立连接的。首先Client端发送连接请求报文，Server段接受连接后回复ACK报文，并为这次连接分配资源。Client端接收到ACK报文后也向Server段发生ACK报文，并分配资源，这样TCP连接就建立了。那如何断开连接呢？简单的过程如下：【注意】中断连接端可以是Client端，也可以是Server端。假设Client端发起中断连接请求，也就是发

2、送FIN报文。Server端接到FIN报文后，意思是说我Client端没有数据要发给你了，但是如果你还有数据没有发送完成，则不必急着关闭Socket，可以继续发送数据。所以你先发送ACK，告诉Client端，你的请求我收到了，但是我还没准备好，请继续你等我的消息。这个时候Client端就进入FIN_WAIT状态，继续等待Server端的FIN报文。当Server端确定数据已发送完成，则向Client端发送FIN报文，告诉Client端，好了，我这边数据发完了，准备好关闭连接了。Client端收到FIN报文后，就知道可以关闭连接了，但是他还是不相信网络，怕Server端不知道要关闭，所以发送AC

3、K后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传。“，Server端收到ACK后，就知道可以断开连接了。Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，我Client端也可以关闭连接了。Ok，TCP连接就这样关闭了！整个过程Client端所经历的状态如下：而Server端所经历的过程如下：转载请注明:【注意】在TIME_WAIT状态中，如果TCP client端最后一次发送的ACK丢失了，它将重新发送。TIME_WAIT状态中所需要的时间是依赖于实现方法的。典型的值为30秒、1分钟和2分钟。等待之后连接正式关闭，并且所有的资源(包

4、括端口号)都被释放。【问题1】为什么连接的时候是三次握手，关闭的时候却是四次握手？答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，你发的FIN报文我收到了。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？答：

5、虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。TCP滑动窗口机制 TCP协议在能够发送数据之前就建立起了“连接”。要实现这个连接，启动TCP连接的那一方首先将发送一个SYN数据包。这只是一个不包含数据的数据包， 然后，打开SYN标记。如果另一方同时在它收到SYN标记的端口通话，它将发回一个SYN+ACK:SYN和ACK标志位都被打开，并将ACK(确认)编 号字段设定为刚收到的那个数据包的顺序号字段的值。接下来，连接发起方为了表示收到了这个SYN+ACK信息，

6、会向发送方发送一个最终的确认信息（ACK 包）。这种SYN、SYN+ACK、ACK的步骤被称为TCP连接建立时的“三次握手”。在这之后，连接就建立起来了。这个连接将一直保持活动状态，直到 超时或者任何一方发出一个FIN(结束)信号。任何一方都可以关闭一个TCP连接，要求双方发送一个FIN信号关闭自己的通讯频道。一方可以在另 一方之前关闭，或者双方同时关闭TCP连接。因此，当一方发送一个FIN信号时，另一方可发送“FIN+ACK”，开始关闭自己一方的通信并且确认收到了 第一个FIN信号。发送第一个FIN信号的人接下来再发送一个“FIN+ACK”信息，确认收到第二个FIN信号。另一方就知道这个连接

7、已经关闭了，并且 关闭了自己的连接。发送第一个FIN的人没有办法收到最后一个ACK信号的确认信息。这时它会进入“TIME_WAIT”(等待时间)状态并启动一个定时 器，防止另一方没有收到ACK信息并且认为连接仍是打开的。一般来说，这个状态会持续1至2分钟。现在，我们来讨论第一个问题。如果有人(假如一 个黑客)在你的Web服务器上留下一个半开或者半关的连接，那就是一个坏消息。每一个连接都要消耗内存，打开数千个虚假的TCP连接可能导致服务器瘫痪。 当然，你实际上不可能在不影响TCP正常工作的情况下调整TCP定时器。如果你听说过TCP SYN 攻击的话，那就是这个意思。为了防止出现这种情况，大多数操

8、作系统都要限制半开连接的数量。例如，Linux默认的限制一般是256个。关于持续 流控制问题，现在我们就来讨论这个问题。TCP中实现它的机制是TCP滑动窗口机制。TCP协议使用“重新发送与正向ACK”来保证数据传输的可靠性。发 送方将等待一段时间，如果没有收到其发送的数据包的ACK确认信息，发送方就要重新发送。顺便说一下，TCP协议中有许多定时器。这只是其中一个定时器。 ACK的概念对于流控制是非常重要的，因为TCP滑动窗口协议使TCP的往复确认变得更有效率。如果TCP要发送一个数据包并且等待每一个ACK确认信 息，它实际上就把数据吞吐量削减了一半。理想的情况是，我们能够一次发送许多数据包，然

9、后等待收到一个确认收到全部数据包的ACK信息，而不用对 方发来更多的数据。但是，我们如何知道发送了多少个数据包呢?TCP窗口尺寸可以控制在“已发送但是没有确认”的状态下能够容纳多少个数据包。如果这个窗 口尺寸很大，我们不必等待ACK信息就可以发送大量的数据包。这实际上就是流控制。接收方就是控制窗口大小的那一方。如果接收方将窗口大小设为 “0”，那么，发送方根本就不能发送任何数据。如果这个窗口的尺寸是“1”，那么，我们就回到了简单的“发送和等待ACK”的协议。如果最后的窗口尺寸是 “0”，发送者将发出一个探测信号以搞清这个窗口什么时间再次打开。如果发送方从来没有收到ACK信息，它就一直不断地重试

10、，直到定时器过期。请记住，这 个窗口尺寸在TCP头中是一个16位字段。如果你要一个窗口尺寸(按字节计算)大于16位可以表示的容量（2的16次方个字节），还可以使用一个名为“窗 口缩放”的TCP协议选项。这个选项允许窗口尺寸乘以比例因子。如果没有极大的窗口尺寸，TCP协议就就无法充分利用GB级别的高速连接。这也是我们需要 针对这些新的高速连接调整TCP参数的原因，关于TCP流控制的问题，我们不能不提一下Nagle算法。如果我们在一个telnet连接上使用一 个大的TCP窗口会发生什么事情呢?你会输入一个指令（例如敲了一个字母），然后一直等待回应它却迟迟不出现在终端回显上。这对于实时通信来说是一个

11、大问 题。而且，telnet也会增加网络的阻塞度，因为一个字节的数据（例如我们的一次击键）需要40个字节的包头。于是RFC 896定义这个Nagle算法，用以消除小的数据包。这个思路是我们应该在数据发送之前给先把小数据集中起来然后一次性发送，以便提高效率。为了更有效 率，它还限定只允许存在一个未经确认的数据段，你在得到确认信息之前不能发送更多的数据。Telnet和互动SSH连接使用TCP_NODELAY套接口 选项启用这个功能，这样当你按下一个按键的时候，你能够立即得到一个回应。当然，我们仍是忽略了有关TCP协议的许多事情。然而，通过这两篇文章的了解，你应该能够理解其它一些更专业的TCP著作。

12、阻塞控制与流控制不同，本文没有讨论。如果你真的对了解TCP协议的全部工作原理感兴趣，你可以详细阅读TCP RFC。小结TCP 协议非常善于解决流控制问题，因此非常适应于许多应用程序。TCP协议中的流控制的含义是:“在收到对发送的数据的确认信息这前，我可以发送多少数据?” 这就是TCP窗口。学习阻塞控制的问题可以留作读者的练习。需要指出的是，在TCP协议之下连接速度开始很慢，然后速度逐渐加快。这个做法并不总是最理想 的。TCP通过滑动窗口机制检测丢包，并在丢包发生时调整数据传输速率。滑动窗口机制利用数据接收端的接收窗口来控制数据流。接收窗口值由数据接收端指定，以字节数形式存储于TCP报文头，并告

13、知传输设备有多少数据将会存储在TCP缓冲区。缓冲区就是数据暂时放置的地方，直至传递至应用层协议等待处理。因此，发送端每次只能发送Window Size字段指定的数据量。为了使发送端继续传送数据，接收端必须发送确认信息：之前的数据接收到了。同时必须对占用缓冲区的数据进行处理以释放缓存空间。下图显示了接收窗口是如何工作的：上图中，客户端向服务器发送数据，服务器接收窗口是5000字节。客户端发送了2500字节，服务器缓冲区还剩2500字节，之后又发送了2000字节，从而缓冲区只剩500字节。服务器发送确认信息。对缓存中数据进行处理并清空缓存。此过程重复进行，客户端又发送3000字节和1000字节，服

14、务器缓存减少至1000字节，客户端再次确认数据并处理缓存中内容。更多信息调整窗口大小：当TCP堆 栈接收到数据的时候，生成一个确认信息并以回复的方式发送，但是放置在接收端缓存中的数据并不总是立即被处理。当服务器忙于处理从多个客户端接收的报文， 服务器很有可能因为清理缓存而变得缓慢，无法腾出空间接收新的数据，如果没有流控，则可能会造成丢包和数据损坏。好在，接收窗口所设定的速率无法使服务器 正常处理数据时，能够调整接收窗口大小。通过减小返回给发送端的ACK报文的TCP头窗口大小值来实现。如下图所示：上图中，服务器初始窗口大小为5000字节。客户端发送2000字节，之后又发送了2000字节，缓冲区中

15、只有1000字节可用。服务器意识到缓冲区正在快速填满，它知道如果数据继续以此速率传输，很快会有报文丢失。为了防止报文丢失，服务器发送确认信息给客户端，更新窗口大小为1000字节。结果，客户端减少数据发送，服务器以可以接受的速率处理缓存内容，即保持数据流以稳定的速率传输。调整窗口大小在两个方向都是可行的。当服务器能够更加快速的处理报文时，它会发送一个较大窗口的ACK报文。零窗口暂停数据流：某些情况下，服务器无法再处理从客户端发送的数据。可能是由于内存不足，处理能力不够，或其他原因。这可能会造成数据被丢弃以及传输暂停，但接收窗口能够帮助减小负面影响。当上述情况发生时，服务器会发送窗口为0的报文。当

16、客户端接收到此报文时，它会暂停所有数据传输，但会保持与服务器的连接以传输探测（keep-alive）报文。探测报文在客户端以稳定间隙发送，以查看服务器接收窗口状态。一旦服务器能够再次处理数据，将会返回非零值窗口大小，传输会恢复。下图示例了零窗口通知过程。服务器初始接收数据窗口为5000字节大小。从客户端接收4000字节数据之后，服务器负载变得非常繁重，无法继续处理客户端任何数据。服务器于是发送窗口大小值为0的报文。客户端暂停数据传输并发送一个探测报文。探测报文之后，服务器回复以告知客户端现在可以接收数据的报文，以及窗口大小为1000字节。客户端恢复传送数据。TCP滑动窗口实战：本例中，开始从1

17、0发送至0。我们关心的是窗口大小字段，可以从Packet List面板的Info栏以及Packet Details的TCP报文头看到。前三个报文后，可看到该值立刻减小，如下图所示：窗口大小值从第一个报文的8760字节变成第二个报文的5840字节到第三个报文的2920字节。窗口大小值的减小是主机延时的典型标志。在时间栏注意到这一过程发生的非常迅速。当窗口大小迅速减小的时候，通常就有可能下降为零。这就是第四个报文所发生的，如下图所示：第四个报文从0发送至0，目的是告诉0它不再接收任何数据。0

18、值见于TCP报文头，Wireshark的Packet List面板Info栏，以及TCP报文头的SEQ/ACK Analysis字段也告诉我们这是一个0窗口报文。一旦发送了零窗口报文，0的设备不会再发送任何数据，直到收到从0的窗口更新，告知窗口大小已经增加了。本例中导致零窗口的问题是暂时的，所以在下一个报文中发送了窗口更新信息，如下图所示。本例中，窗口大小增加到一个非常健康的数值64，240字节。Wireshark再次在SEQ/ACK Analysis告诉我们这是一个窗口更新。一旦收到更新报文，0的主机就再次开始发送数据，在报文

19、6和报文7中。这一过程发生很快。如果它持续时间再长一点，就可能会导致网络的潜在中断，引起数据传输减慢或失败。下一个关于滑动窗口的例子，第一个报文是正常HTTP，从8至5。此报文之后立刻跟随一个从5发送的零窗口报文，如下图所示：这与上一个例子中的零窗口报文十分类似，但结果显著不同，5主机不是发送一个窗口更新并回复通讯，而是一个探测报文，如下图所示：此报文被Wireshark标注为探测报文。时间栏告诉我们这一报文发生于最后一个接收到的报文3.4秒之后。这一过程持续若干次，一端发送零窗口报文另一端发送探测报文，如下图所示：探测报文发送间隙为3.4，6.