[计网]TCP/IP 三次握手四次挥手

一、TCP报文格式

源端口号：本次TCP连接中，发起连接的主机使用的端口号；
目的端口号：本次TCP连接主，接受连接的主机使用的端口号；
序号：通过TCP传输的每一个数据段，都有一个序号，作用是为了确认此数据段的顺序。网络中允许传输的数据长度是有限制的，所以当我们要通过TCP传输一个较大的数据时，TCP会将数据切割成很多小的数据段进行传输。而将这些小的数据段发送到目的主机时（发送方会同时发送多个数据），并不能保证它们是按顺序到达目的地，所以对于每一个数据段，都要有一个序号，来标识它们是属于总数据的哪一部分，以保证在目的主机中能将他们重新拼接。
确认序号：期望收到对方下一个报文段的第一个数据字节的序号。接收方若接收到一个数据段，会发送一个确认报文给发送方，告诉发送方已经接收到这个数据段，而确认序号的作用就是告诉发送方接收到了哪条数据段。若接收方接收到了序号为n的报文段，则确认序号将是n+1，表示它已经接收了n，下一条想要接收n+1；
首部长度：TCP报文的首部+选项的字节数；
ACK：只有1 bit的标志位，若为1，表示这个数据段中的确认序号是有效的，即这个数据报是对之前接收到的某个报文的确认（一个TCP报文可以同时作为确认报文和传递数据报文）。
RST：只有1 bit的标志位，若客户端向服务器的一个端口请求建立TCP连接，但是服务器的那个端口并不允许建立连接（比如没开启此端口），则服务器会回送一个TCP报文，将RST位置为1，告诉客户端不要再向这个端口发起连接；
SYN：只有1 bit的标志位，若为1，表示这是一条建立连接的TCP报文段；
FIN：只有1 bit的标志位，若为1，表示这是一条断开连接的TCP报文段；

二、TCP 三次握手过程

2.1 三次握手过程

TCP建立连接的过程需要发送三次报文、所以TCP建立连接成为三次握手，接下来讲解三次握手过程，假设客户端向服务器发起TCP连接：

·第一步：客户端的TCP程序首先向服务器的TCP程序发送一个TCP报文，这个报文不含数据，切它的SYN标志位被置为1，表示这是一条建立连接的TCP报文段，因此这个报文段被称为SYN报文段。客户端的TCP程序随机选择一个序号作为客户端报文的初始序号（假设序号为clinet_isn），放入这个报文段的序号部分。这个报文段由运输层传递到网络层后，被封装在一个IP数据报中发往服务器。

·第二步：包含SYN报文段的IP数据包被服务器接收，服务器的网络层将SYN数据包抽取出来，交给运输层，同时服务器为该TCP连接分配资源（包括发送缓存、接收缓存和变量等）并向客户发送允许连接的TCP报文段。这条允许连接的报文段不包含数据、SYN标志位也被置为1，同时它的ACK标志位也被置为1，表示它是SYN报文段的确认报文，所以这条报文段也被成SYNACK报文段。服务器随机选择一个序号，作为服务器报文段的初始序号（假设成为server_isn），并将其放入SYNACK报文段的序号部分，同时确认号子段被设置为client_isn+1（SYN报文段的序号+1）。这个报文段可以解释为服务器向客户端说：“我收到了你的连接请求，我允许你连接，我的初始序号是server_isn”。

·第三步：当客户端接收到SYNACK报文段后，它也将为TCP连接分配资源（缓存和变量），同时生成一条SYNACK报文段的确认报文，并发送给服务器。由于经过上面两个步骤，已经算是建立了连接，所以这次的SYN标志将被置为0，而不是1,(ACK标志位为1）。同时，这条报文段的序列号被置为client_isn+1(第一条客户报文序号是client_isn，而这是它的下一条，所以+1)，而确认序号被设置为server_isn+1(第一条服务器报文序号是server_isn,客户端成功接收，所以期望服务器下一次发送server_isn+1)。和上面两条报文不同，第三条报文可以携带数据，比如HTTP的请求就是在TCP的第三次握手中发送到服务器的。

2.2 为什么不是2次握手

首先得明确，两次握手是必要的。第一次握手，客户端将SYN报文发送到服务器，服务器接收到报文后，即可确认客户端到服务器是可达的；而服务器向客户端发送的响应SYNACK报文，客户端接收到后，即可确认服务器到客户端是可达的。那么为什么还要三次握手呢？

客户端和服务器的握手过程，不仅仅是确认互相可达的过程，更重要的是一个同步的过程，SYN就是同步（Synchronize）的缩写。对于TCP报文段来说，序号是一个至关重要的部分，它保证了TCP传输数据的完整性。而我们上面也说过，TCP报文的初始序号不是从0开始的，而是一个随机的序号，而所谓的同步，就是TCP客户端和服务器互相同步初始序号的过程。第一次握手，客户端发送SYN报文，将自己的初始序号发送到了服务器，服务器接收到后，向客户端发送SYNACK报文段，告诉客户端已经收到了它的初始序号，同时在这个报文段中带上了自己的初始序号。这个时候，第三次握手的作用就出来了：第三次握手实际上就是客户端在告诉服务器，自己已经收到了它的初始序号，完成了同步，可以开始相互传输数据了。若没有第三次握手，服务器将无法保证客户端接收到了自己的SYNACK报文段，若此时SYNACK报文段丢失，客户端不知道服务器的初始序号，将无法处理之后到达客户端的数据。

在很多书籍和网上的博客中还流传另外一种说法。若仅仅是两次握手，将产生以下问题：客户端向服务器发送SYN报文段请求建立连接，但是没有在指定时间内收到SYNACK报文段，所以客户端认为SYN报文段在网络中丢失，则再次发送SYN报文段，并成功接收到了SYNACK报文段，但是客户端在很短的时间内就断开了TCP连接。然而，最初的SYN报文并没有丢失，只是传输时延太长，过了许久才到达。等它到达服务器时，其实客户端已经与服务器建立过TCP连接，并且已经断开了。此时服务器接收到这条SYN报文段，以为客户端又想建立一条新的连接，于是向客户端回送ACK报文，并为连接分配了资源。由于没有第三次握手，服务器将不知道这其实是上一次连接的报文，于是将它创建一个新的TCP连接并维持，直至因为太久没有接收到数据而释放。这种情况非常浪费资源，所以为了防止这种情况的发生，才需要客户端的再一次确认。

实际上，上面所述的第一点才是TCP三次握手的原因，第二个只能算是顺带的好处吧，从建立连接的报文被称为SYN（同步）就可以看出这点。

三、TCP四次挥手

3.1 四次挥手

TCP在断开连接时，客户端与服务器要交换四次报文，所以TCP的断开连接也叫四次挥手

·第一步：客户端进程发出断开连接指令，这将导致客户端的TCP程序创建一个特殊的TCP报文段，发送到服务器。这个报文段的FIN段被置为1，表示这是一条断开连接的报文。

·第二步：服务器接收到客户端发来的断开连接报文，向客户端会送这个报文的确认报文（ACK字段为1），告诉服务器已经接收到FIN报文，并允许断开连接。

·第三步：服务器发送完确认报文后，服务器的TCP程序创建一条自己的断开连接报文，此报文的FIN子段被置为1，然后发往客户端。

·第四步：客户端接收到服务器发来的FIN报文段，则产生一条确认报文（ACK为1）,发送给服务器，告知服务器已经接收到它的断开报文。服务器接收到这条ACK报文段后，释放TCP连接相关的资源（缓存和变量），而客户端等待一段时间后（半分钟，一分钟或两分钟），也释放处于客户端的缓存和变量。其实也可以由服务器断开连接。

3.2 客户端为什么等待一段时间后再释放资源

原因一：客户端接收到服务器发送的FIN报文后（第三次挥手），会回送一条确认报文（第四次挥手），但是，客户端并不知道这条确认报文是否可以顺利到达服务器。若这条确认报文在传送到服务器的过程中损坏、丢失或超时，将引起服务器重新发送FIN报文，客户端接收到后，将需要再次发送一条确认报文，直到服务器正确接收。但是，客户端发送确认报文后，立刻释放资源，将导致无法处理重传的FIN报文，所以客户端需要等待一段时间，直到确认没有出现上述情况出现再释放资源。
原因二：TCP四次挥手完成后，理论上已经断开了连接，但是这不代表之前通过这条连接发送的所有数据都处理完毕了，有些可能还在网络中传输。若在四次挥手后，立即释放客户端的资源，然后客户端立即以同一个源端口，向服务器的同一个目的端口再次建立一个TCP连接，这个连接和上一个的源端口+源IP+目的端口+目的IP 都一模一样，此时将会产生问题。若上一次连接遗留在网络中的报文此时到达，将会被当做新连接传输的数据处理，于是可能会产生一些不可预估的错误。所以，客户端在断开连接后，需要等待一段时间，直到网络中遗留的数据都死掉，才释放资源，而在资源没有被释放前，是不允许建立一个源端口+源IP+目的端口+目的IP 都一模一样的TCP连接的（因为TCP套接字由这四部分标识）。

3.3 为什么断开连接要四次挥手

有的人可能也会想，断开连接为什么是四次挥手，不能是两次呢？其中一方请求断开连接，另一方确认即可，为什么这个过程需要两边各发起一次？原因就是：TCP连接是全双工的。什么是全双工，即A与B建立连接，则A可以向B发送数据，而B也可以向A发送数据。

我们知道断开连接的请求什么时候发起？当然就是在不再有数据需要发送时。我们依旧以客户端向服务器断开连接为例。假设客户端和服务器建立了一个TCP连接，在客户端需要向服务器发送的数据都发送完后，客户端就可以向服务器发送一个FIN报文段，请求断开连接；服务器接收到后，将会回送一个ACK报文，告诉客户端，自己已经收到了它断开连接的请求。若只有两次挥手，这个时候连接就算是断开了。但是这样真的合理吗？答案当然是否定的。

客户端发送完数据后，告诉服务器，我没有数据了，可以和你断开，但是不代表服务器没有数据需要发送到客户端了呀。TCP是一个全双工的连接，代表服务器也有可能有数据需要发送到客户端。所以，只有当两端的数据都发送完毕，连接才能安全的断开。因此，服务器接收到了客户端的FIN报文段，他会等到自己所有的数据发送完，然后也向客户端发送一个FIN报文，告诉客户端我也没数据了，这时候连接才能真正断开，两端各自释放资源。