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）防止“已经失效的链接请求报文段”出如今本链接中。