TCP建立连接3次握手及释放连接4次握手

TCP建立连接及释放连接示意图

注：假设左边运行TCP客户程序，右边运行TCP服务器程序

建立连接3次握手

TCP建立连接过程需要经过3次握手，最初服务器B的TCP服务器进程先创建传输控制块TCB,准备接收客户进程的连接请求，然后服务器进程就处于LISTEN（收听）状态，等待客户的连接请求。
1. 第一个次握手：A的TCP客户进程首先创建传输控制模块TCB，向服务器B发送连接请求报文段，即SYN报文段，此时首部中的同步位SYN=1，同时选择一个初始序号seq=x，这时，TCP客户进程进入SYN-SENT（同步已发送）状态（注：SYN报文段不能携带数据，但会消耗一个序号）。
2. 第二次握手：服务器B收到SYN报文段后，向A发送确认报文段，即SYN+ACK报文段，在此报文段中，SYN和ACK位置1，确认号是ack=x+1，同时也为自己选择一个初始序号seq=y，这时，TCP服务器进程进入SYN-RCVD(同步收到)状态（注：此报文段不能携带数据，但要消耗一个序号）。
3. 第三次握手：TCP客户进程收到服务器B的确认后，向服务器B发送确认报文段，即ACK报文段，在此报文段中，ACK置1，确认号ack=y+1，序号seq=x+1，这时，TCP客户进程进入ESTABLISHED（已建立连接）状态（注：此报文段可以携带数据，如果不携带数据则不消耗序号），当服务器B收到A的确认后，也进入ESTABLISHED状态，至此，TCP建立连接的三次握手结束。

建立连接要3次握手的原因

主要是为了防止已过期的连接请求报文段再次传到连接的主机。怎么理解呢？正常情况下，A向B发出连接请求，但因连接请求报文丢失而未收到确认，于是A再重传一次连接请求，后来接收到了确认，建立了连接，数据传输完毕后，就释放了连接。假设A发出的第一个连接请求报文段并没有丢失，而是由于在某个网络结点长时间滞留了，以致延误到连接释放以后的某个时间才到达B，而这个请求报文段即为已过期的连接请求报文段。
如果是两次，会出现以下的情况：
1. A发出的第一个连接请求报文段没有丢失，而是由于某个网络节点长时间滞留了，以致延误到连接请求释放以后的某个时间才到达B。B收到此失效的请求报文段后，误认为是A又发出一次新的连接请求，于是向A发出确认报文段，同意建立连接，新连接就建立了，而A由于没有发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据，但B却以为新的运输连接已经建立，并一直等待A发来数据。
2. 可能发生死锁。假定A给B发送一个连接请求分组，B收到了这个分组，并发送了确认应答分组。按照两次握手的协定，B认为连接已经成功地建立了，可以开始发送数据分组。可是，A在B的应答分组在传输中被丢失的情况下，将不知道B是否已准备好，不知道B建议什么样的序列号，A甚至怀疑B是否收到自己的连接请求分组。在这种情况下，A认为连接还未建立成功，将忽略B发来的任何数据分组，只等待连接确认应答分组。而B在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

释放连接4次握手

1. 第一次握手：A的应用程序先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接，向服务器B发送连接释放报文段，即FIN报文段，在此报文段中，终止控制位置1，其序号seq=u，它等于传送过的数据的最后一个字节的序号加1，这时，A进入FIN-WAIT1（终止等待1）状态，等待B的确认（注：FIN报文段即使不携带数据，也要消耗一个序号）。
2. 第二次握手：B收到连接释放报文段后，发出确认报文段，在此报文段中，确认号为ack=u+1，序号为v，等于B前面传送过的数据的最后一个字节的序号加1，此时，B进入CLOSE-WAIT（关闭等待）状态，同时TCP服务器进程通知高层应用服务器，从A到B这个方向的连接释放了，这时的TCP连接处于半关闭状态，即A已经没有数据要发送了，但B若发送数据，A仍要接收。
3. 第三次握手：A收到来自B的确认后，进入FIN-WAIT-2(终止等待2)状态，等待B发出的连接释放报文段，B若没有数据要向A发送时，其应用程序就通知TCP释放连接，向A发送连接释放报文段，即FIN-ACK报文段，在此报文段中，FIN和ACK置1，序号为w(在半关闭状态B可能又发送了一些数据)，确认号ack=u+1，这时，B进入LAST-ACK（最后确认）状态，等待A的确认。
4. 第四次握手：A收到B的连接释放报文段后，对此发出确认报文段，即FIN报文段，在此报文段中，ACK置1，确认号ack=w+1，序号时seq=u+1（因为前面发送的FIN报文段需要消耗一个序号），此时，A进入TIME-WAIT（时间等待）状态（注：现在TCP连接还没有释放掉，必须经过时间等待计时器（TIME-WAIT）设置的时间2MSL后，A才进入到CLOSED状态，MSL叫做最长报文段寿命）

释放连接4次握手的原因

因为TCP连接是全双工的，即数据可在两个方向上同时传递，所以进行关闭时每个方向上都要单独进行关闭，另一个对此进行确认；而关闭的方法是一方完成数据传输后，发送一个FIN报文段告知另一方将要终止这个方向的连接。发送FIN通常是应用层进行关闭的结果。

TIME-WAIT必须等待2MSL时间的原因

1. 为了保证最后一个ACK报文段不会丢失，没有加入TIME-WAIT的话，如果最后一个ack报文段丢失了，server要求重传，但此时client已经关闭了，将会出现问题
2. 使得当前连接的所有报文段在网络中失效，不会影响到下一个连接。

注：上述TCP建立连接和释放连接阶段，属于个人的学习理解，如存在疏漏，请留言或者邮件指明，也欢迎各位进行交流学习，邮箱地址：[email protected]