TCP 的 三次握手 四次挥手

B的TCP服务器进程先创建传输控制块TCB，准备接受客户进程的连接请求，然后服务器进程处于LIsten(收听)状态，等待客户的连接请求，如果有，做出响应；

A的TCP客户进程也是首先创建传输控制块TCB，然后向B发出连接请求报文段，着时首部中的同步位SYN=1，同时选择一个初始序号seq=x。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但要消耗掉一个序号，这时，TCP客户进程进入SYN-SENT（同步已发送）状态。

B收到连接请求报文段后，如果同意建立连接，则向A发送确认。在确定报文段中应该把SYN位和ACK位都置1，确认号是ack=x+1，同时也为自己选择一个初始序号seq=y。

请注意，这个报文段同样不能携带数据，但同样要消耗掉一个序号，这是TCP服务器进程进入SYN-RCVD(同步收到)状态。

TCP客户进程收到B的确认后，还要向B给出确认，确认报文段的ACK置1，确认号ack=y+1；而自己的序号seq=x+1。TCP的标准规定，ACK报文段可以携带数据。但如果不携带数据则不消耗序号，在这种情况下，下一个数据报文段的序号仍是seq=x+1。这是TCP连接已经建立，A进入establised（已建立连接）状态。

当B收到A的确认后，也进入established 状态。

之所以采用A还需要发送一次确认的原因在于，防止已经失效的连接请求报文段突然又发送到了B，产生错误。

“四次挥手”

数据传输结束后，通信的双方都可以释放连接。现在A和B都处于established状态。A的连接释放报文段首部的FIN置1，其序号seq=u；它等于前面已经传送过的数据的最后一个字节的序号加1.这时候A进入FIN-WAIT-1（终止等待1）状态，等待B的确认。请注意，TCP规定，FIN报文段即使不携带数据，它也会消耗一个序号。

、

B收到连接释放报文段后发出确认，确认号是ack=u+1，而这个报文段自己的序号是V，等于B前面已经传送的数据的最后一个字节的序号加1.然后B进入CLOSE-WAIT（关闭等待）状态，TCP服务器进程这时候应该通知高层的应用程序。从A到B这个方向的连接就释放了，这个时候的TCP连接处于半关闭（half-close）状态，即A已经没有数据要发送了，但是B若发送数据，A仍要接受，也就是说从B到A这个方向的连接并未关闭。这个状态可能会持续一段时间。

A收到B的确认后，进入FIN-WAIT-2(终止等待2)状态，等待B发出的连接释放报文段。

若B已经没有数据发送到A，其应用程序通知TCP释放连接。这时候B发出的连接释放报文段必须使FIN=1.现在假设B的序号为W（在半关闭状态下B可能又发送了一些数据），B还必须重复上次以机构发送的确认好ack=u+1；这时候B进入last--ack（最后确认）状态，等待A的确认。

A收到B的连接释放报文段后，必须对此发出确认。在确认报文段中吧ACK=1，确认号ack=w+1，自己的序号是seq=u+1。然后进入TIME-WAIT(时间等待)状态。请注意，这时候，现在TCP连接还没有释放掉，必须经过时间等待计时器（TIME-WAIT TIMEr）设置的2MSL后，A才能进入closed 状态。时间MSL叫做最长报文段寿命。进入closeD状态后，才能开始建立下一个新的连接。当A撤销相应的传输控制块TCB后，就结束了这次的TCB连接。

B只要收到A发出的为确认，就进入“closed”状态，同样B在撤销相应的传输控制块TCB，结束这次的TCP连接。B结束TCP的时间比A稍微早一点。

为什么A要经过TIME-WAIT状态必须等待2MSL的时间呢？

（1）为了保证A发送的最后一个ACK报文段能够达到B；

（2）防止“已经失效的连接请求报文段”出现在本连接中。