TCP三次握手和四次挥手

今天看了一篇关于TCP三次握手和四次挥手的博文，经不住喜爱，特意把文章COPY下来了。原文传送门

TCP是面向连接的协议。运输连接是用来传送TCP报文的。TCP的运输连接有三个过程，即建立连接、数据传输和连接释放。

TCP连接建立过程中要解决以下三个问题：

• 1.要使每一方都能够确认对方的存在。
• 2.要允许双方协商一些参数
• 3.能够对运输实体资源进行分配

TCP连接的建立采用客户机／服务器模式，主动发起连接建立的应用进程叫做客户机，而被动等待连接建立的应用进程叫做服务器。

TCP的连接建立：

１.首先，客户机与服务器的TCP进程都处于CLOSED（关闭）状态，当要进行TCP连接时，客户机主动打开连接，服务器被动打开连接（这是因为服务请求总是由客户机向服务器发起，因为想要请求的资源都在服务器上，所以客户机想要获取资源就必须主动向服务器发起请求，而不能是等待服务器向自己（客户机）发起请求）。

２.然后，服务器的TCP进程先创建传输控制块TCB（传输控制块TCB存储了每一个连接中的重要信息，如：TCP连接表，指向发送和接收缓存的指针，指向重传队列的指针，当前的发送和接收序号，等等），此时，服务器就处于LISTEN（收听）状态。同样的，客户机也会首先创建一个传输控制块TCB发送给服务器。这样，准备工作就做好了。

３.现在就可以开始真正的三次握手了。首先，客户机先向服务器发送连接请求报文段，该报文段中将首部中的同步位SYN置为１（只有当SYN置为１时，才能表明客户机想要和服务器建立连接），并且随机选择一个初始序号ｘ，注意此时的SYN数据报中并没有携带数据，但是仍旧要消耗掉一个序号（意思就是下次客户机发送数据的时候，序号为x+１），此时客户机进入到SYN-SENT（同步已发送）状态。

４.此时，服务器收到客户机的请求时，如果同意与该客户机进行连接，则需要向客户机发送确认报文。在发送报文中需要将SYN与ACK都置为１（当ACK置为1时，表明服务器同意与客户机进行连接；同时将SYN置为1，表明服务器想要和客户机建立连接），并且随机选择一个初始序号y，确认号为x+1（确认号表明服务器渴望收到的下一个报文段的第一个数据字节的序号，因为之前发送了x，所以下一个序号为x+1），注意此时的SYN数据报中并没有携带数据，但是也要消耗掉一个序号（同样的，也就是说服务器下次发送数据的时候，序号为y+1），此时TCP服务器进程进入到SYN-RCVD（同步收到）阶段。

顺便提一句，在这两个阶段会发送SYN　Flooding攻击。

5.TCP客户端收到服务器的确认后，还要再向服务器给出确认。确认报文段中ACK置为1，确认号为ack=y+1(因为之前服务器给客户机发送的序号为y，因此现在客户机向服务器发送的确认号为ack=y+1，意思是客户机渴望收到的下一个报文段的第一个数据字节为y+1)此时客户机的发送序号为x+1（这是因为刚才刚才客户机向服务器发送连接请求时消耗了序号x，因此此时的序号为x+1）注意：在进行第三次握手时，ACK报文段可以携带数据，也可以不携带数据，如果携带数据，则消耗一个序列，这样客户机下次发送报文段时的序号为x+2，如果不携带数据则不消耗序号，下次客户机发送报文段时的序号为x+1。这时TCP连接已经建立，客户机和服务器都进入到ESTABLISHED（已建立连接）状态。

其实上面的三次握手实质上就相当于是下列的对话：

－客户机：服务器，我想要和你建立连接，你同意吗？（SYN＝１）

－服务器：客户机，我同意和你建立连接（ACK＝１）；我也想和你建立连接，你同意吗？（SYN＝１）

－客户机：服务器，我同意和你建立连接。（ACK＝１）

其实，在进行第二次握手时（即服务器向客户机进行应答时），可以看作时发了两次包，先回答客户机的服务请求（ACK＝１，ａｃｋ＝x+１），然后再向客户机发出请求（SYN＝１，ｓｅｑ＝ｙ）

常见面试问题：

问：三次握手中，为什么客户机最后还要再向服务器发送一次确认呢？

答：这是为了防止已失效的连接请求报文段突然又传到了服务器。所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常的情况，客户机发出连接请求，但因为连接请求报文丢失而未收到确认。于是客户机再重传了一次连接请求，后来收到了确认，建立了连接。数据传输完后，就释放了连接。客户机共发送了两个连接请求报文段，其中第一个丢失，第二个到达了服务器，没有所谓的“已失效的连接请求报文段”。

但是如果出现了一种异常情况，即客户机发出的第一个报文段并没有丢失，而是在某个节点上长时间滞留了，直至客户机向服务器发送了第二个报文段并且已经完成数据传输释放了连接，此时，第一个报文到达服务器后会被误以为是客户机重新发起的一次连接请求，实质上是一个早已失效的连接请求。如果没有第三次握手，那么这个连接就建立了，但是客户机并不会向服务器发送任何请求，这样连接就会一直持续，白白的消耗网络资源。

TCP的连接释放：

１.数据传输结束后，通信的双方都可以释放连接。此时，客户机和服务器都处于ESTABLISHED（已建立连接）状态。

２.假设客户机请求完资源了，想要释放连接。首先，客户机的应用进程先向服务器发出连接释放报文段，该报文段中将首部的终止控制位FIN置为１（只有当FIN置为１时，才能表明客户机想要和服务器断开连接），并且序号为ｕ（注意：此时的ｕ不是随机产生的，而是之前客户机传送的数据的最后一个字节的序号加１）。此时客户机进入到FIN－WAIT－１（终止等待１）状态，等待服务器的确认。

３.服务器收到连接释放报文后发出确认，在发送报文中将首部中的ACK置为１（ACK置为１，表面服务器同意与客户机释放连接），并且产生序号ｖ（注意：此时的v不是随机产生的，而是之前服务器传送的数据的最后一个字节的序号加１），并且发出确认号为u+１（确认号表明服务器渴望收到的下一个报文段的第一个数据字节的序号，因为之前发送了u，所以下一个序号为u+1）。此时服务器就进入CLOSE－WAIT（关闭等待）状态，客户机进入FIN-WAIT-2状态。

此时，从客户机到服务器这个方向的连接就被释放了，也就是说，客户机已经没有数据要向服务器发送了，但是如果服务器向客户机发送数据，客户机仍要接收数据。也就是说：从客户机到服务器的连接已经被释放了，但是从服务器到客户机的连接还没被释放。此时，TCP连接处于半关闭状态。

4.如果服务器向客户机也没有要发送的数据的话，那么服务器的应用进程就可以向客户机发出连接释放报文段（注意此时还是服务器向客户机发送数据），该报文段中将首部的终止控制位FIN置为1（只有当FIN置为１时，才能表明客户机想要和服务器断开连接），ACK也置为1，并且序号为w（重点注意，此时的w不一定等于v+1。如果在客户机释放了连接之后，服务器向客户机仍旧发送了一部分数据，那么此时w不等于v+1，但是如果期间没有再发送数据，那么w就等于v+1。总而言之，这个w等于服务器上一次发送的数据的最后一个字节加1），并且发送确认号为u+1（确认号表明服务器渴望收到的下一个报文段的第一个数据字节的序号，因为之前发送了u，所以下一个序号为u+1）。此时服务器就进入了LAST-ACK（最后确认）状态。

5.客户机收到服务器的连接释放报文后，必须对此报文进行确认。在该报文段中将ACK置为1，确认号为w+1（确认号表明服务器渴望收到的下一个报文段的第一个数据字节的序号，因为之前发送了w，所以下一个序号为w+1），产生序号为u+1（因为上一个发送的数据的序号为u）。此时服务器进入到TIME-WAIT（等待时间）状态。但是，此时TCP连接还没有被释放掉。必须经过2MSL后服务器才能进入到CLOSED状态。（注：MSL叫做最长报文段寿命，RFC建议为两分钟，也就是说，要经过四分钟才能进入到CLOSED状态）。

其实上面的四次挥手实质上就相当于是下列的对话：

-客户机：服务器，我想和你断开连接，你同意吗？（FIN=1）

-服务器：我同意（ACK=1）

（在此期间，服务器可能还会向客户机发送数据，但是客户机却不能再向服务器发送数据）

-服务器：客户机，我想要和你断开连接，你同意吗？（FIN=1）

-客户机：我同意。（ACK=1）

再等待2MSL时间后就真正断开了连接。

常见面试问题：

问：为什么客户机发送完最后一个数据后要在TIME-WAIT状态等待 2MSL（四分钟）的时间呢？

答：第一：为了保证客户机最后发送的那个ACK报文段能够到达服务器。这个ACK报文段可能会丢失。因而使处在LAST-ACK状态的B收不到对已发送的FIN＋ACK报文段的确认。服务器会超时重传这个FIN＋ACK报文段，而客户机就能在2MSL时间内收到这个重传的FIN+ACK报文段。接着客户机重传一次确认，重新启动2MSL计时器，最后客户机和服务器都可以进入到CLOSED（关闭）状态。如果没有2MSL等待时间，那么就无法收到重传的FIN+ ACK包，无法进入正常的CLOSED状态。

第二，防止“已失效的连接请求报文段”出现在本连接中。客户机在发送完最后一个ACK报文段，再经过时间2MSL，就可以使本连接持续的时间内所产生的报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。