1、引言
TCP 这段看过好几遍，老是记不住，没办法找工作涉及到网络编程这块，各种问 TCP 。今天好好整理一下握手和挥手过程。献给跟我一样忙碌，找工作的童鞋，欢迎大神批评指正。
2、TCP 的连接建立
建立 TCP 连接
上图画出了 TCP 建立连接的过程。假定主机 A 是 TCP 客户端，B是服务端。最初两端的 TCP 进程都处于 CLOSED 状态。图中在主机下面的是 TCP进程所处的状态。A 是主动打开连接，B 是被动打开连接。
三次握手过程分析：
（1）首先A向B发出连接请求报文段，这时首部中的同步位SYN=1，同时选择一个初始序号 seq=x。TCP规定，SYN报文段不能携带数据，但要消耗掉一个序号。这时，A进入SYN-SENT状态。【备注：序号指的是 TCP 报文段首部20字节里的序号，TCP 连接传送的字节流的每一个字节都按顺序编号，具体可以看看 TCP 可靠传输实现的原理】
（2）B收到请求后，向A发送确认。在确认报文段中把SYN和ACK位都置为1，确认号是ack=x+1,同时也为自己选择一个初始序号seq=y。请注意，这个报文段也不能携带数据，但同样要消耗掉一个序号。这时B进入SYN-RCVD状态。
（3）A收到B的确认后，还要向B给出确认。确认报文段的ACK置为1，确认号ack=y+1，而自己的序号seq=x+1。这时，TCP连接已经建立，A进入ESTABLISHED 状态，当B收到A的确认后，也会进入 ESTABLISHED 状态。
以上给出的连接建立过程就是常说的TCP三次握手。
2.1 为什么需要三次握手过程（面试经常问）
为什么A还要发送一次确认呢?这主要是为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。
所谓已失效的连接请求报文段是这样产生的。A发送连接请求，但因连接请求报文丢失而未收到确认，于是A重发一次连接请求，成功后建立了连接。数据传输完毕后就释放了连接。现在假定A发出的第一个请求报文段并未丢失，而是在某个网络节点长时间滞留了，以致延误到连接释放以后的某个时间才到达B。本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，就误以为A又发了一次新的连接请求，于是向A发出确认报文段，同意建立连接。假如不采用三次握手，那么只要B发出确认，新的连接就建立了。
由于A并未发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据。但B却以为新的运输连接已经建立了，并一直等待A发来数据，因此白白浪费了许多资源。
采用TCP三次握手的方法可以防止上述现象发生。例如在刚才的情况下，由于A不会向B的确认发出确认，连接就不会建立。
2.2 如果在TCP第三次握手中的报文段丢失了会发生什么情况?
Client认为这个连接已经建立，如果Client端向Server写数据，Server端将以RST包响应，方能感知到Server的错误。
3、TCP 连接释放
这里写图片描述
四次握手（两个二次握手）过程分析：
数据传输结束后，通信的双方都可以释放连接，并停止发送数据。假设现在客户端和服务端都处于ESTABLISHED状态。
（1）客户端 A 的 TCP 进程先向服务端发出连接释放报文段，并停止发送数据，主动关闭 TCP 连接。释放连接报文段中 FIN=1，序号为 seq=u，该序号等于前面已经传送过去的数据的最后一个字节的序号加1。这时，A进入 FIN—WAIT-1 (终止等待1)状态，等待 B 的确认。TCP 规定，FIN报文段即使不携带数据，也要消耗掉一个序号。这是 TCP 连接释放的第一次挥手。
（2）B收到连接释放报文段后即发出确认释放连接的报文段，该报文段中，ACK=1，确认号为ack=u+1，其自己的序号为v，该序号等于B前面已经传送过的数据的最后一个字节的序号加1。然后B进入CLOSE—WAIT(关闭等待)状态，此时TCP服务器进程应该通知上层的应用进程，因而A到B这个方向的连接就释放了，这时TCP处于半关闭状态，即A已经没有数据要发了，但B若发送数据，A仍要接受，也就是说从B到A这个方向的连接并没有关闭，这个状态可能会持续一些时间。这是TCP连接释放的第二次挥手。
（3）A收到B的确认后，就进入了FIN—WAIT(终止等待2)状态，等待B发出连接释放报文段，如果B已经没有要向A发送的数据了，其应用进程就通知TCP释放连接。这时B发出的链接释放报文段中，FIN=1，确认号还必须重复上次已发送过的确认号，即ack=u+1，序号seq=w，因为在半关闭状态B可能又发送了一些数据，因此该序号为半关闭状态发送的数据的最后一个字节的序号加1。这时B进入LAST—ACK(最后确认)状态，等待A的确认，这是TCP连接的第三次挥手。
（4）A收到B的连接释放请求后，必须对此发出确认。确认报文段中，ACK=1，确认号ack=w+1，而自己的序号seq=u+1，而后进入TIME—WAIT(时间等待)状态。这时候，TCP连接还没有释放掉，必须经过时间等待计时器设置的时间2MSL后，A才进入CLOSED状态，时间MSL叫做最长报文寿命，RFC建议设为2分钟，因此从A进入TIME—WAIT状态后，要经过4分钟才能进入到CLOSED状态，而B只要收到了A的确认后，就进入了CLOSED状态。二者都进入CLOSED状态后，连接就完全释放了，这是TCP连接的第四次挥手。
3.1 为什么需要四次挥手
①、为了保证A发送的最后一个ACK报文段能够到达B。即最后这个确认报文段很有可能丢失，那么B会超时重传，然后A再一次确认，同时启动2MSL计时器，如此下去。如果没有等待时间，发送完确认报文段就立即释放连接的话，B就无法重传了（连接已被释放，任何数据都不能出传了），因而也就收不到确认，就无法按照步骤进入CLOSE状态，即必须收到确认才能close。
②、防止“已失效的连接请求报文段”出现在连接中。经过2MSL，那些在这个连接持续的时间内，产生的所有报文段就可以都从网络中消失。即在这个连接释放的过程中会有一些无效的报文段滞留在楼阁结点，但是呢，经过2MSL这些无效报文段就肯定可以发送到目的地，不会滞留在网络中。这样的话，在下一个连接中就不会出现上一个连接遗留下来的请求报文段了。
可以看出：B结束TCP连接的时间比A早一点，因为B收到确认就断开连接了，而A还得等待2MSL.
【备注】当客户端执行主动关闭并进入TIME—WAIT是正常的，服务端执行被动关闭，不会进入TIME—WAIT状态，这说明，如果终止了一个客户程序，并立即重启该客户程序，则新的客户程序将不再重用相同的本地端口，而是使用新的端口，这不会带来什么问题，因为客户端使用本地端口，而并不关心这个端口是多少。但对于服务器来说，情况就不同了，服务器总是用我们熟知的端口，那么在2MSL时间内，重启服务器就会出错，为了避免这个错误，服务器给出了一个平静时间的概念，这是说在2MSL时间内，虽然可以重新启动服务器，但是这个服务器还是要平静的等待2MSL时间的过去才能进行下一次连接。
网友评论