TCP三次握手和四次挥手

TCP三次握手的过程图

这是TCP三次握手的过程图，我们首先来说下SYN,ACK,seq,ack分别代表什么含义:
(1)确认ACK:仅当ACK=1时确认号字段才有效。当ACK=0时，确认号无效。
   TCP规定:当连接建立后所有传送的报文段必须把ACK置1。


(2)同步SYN:在连接建立时用来同步信号。
   SYN置为1表示这是一个连接请求或连接接受的报文。
   SYN=1,ACK=0          连接请求报文段
   SYN=1,ACK=1          连接接受报文段

(3)初始序号:seq

(4)确认号:ack

TCP三次握手的过程

(1)客户端向B发送连接请求报文段，此时首部的同步位SYN=1，同时选择一个初始序号seq=x。TCP客户端进程进入SYN_SENT状态。

(2)B收到连接请求报文段后，如果同意建立连接，则向A发送确认。确认报文段中置SYN=1,ACK=1，确认号ack=x+1,同时自己选择一个初始序号:
seq=y,此时TCP服务器进程进入SYN_RCVD(同步收到)状态。

(3)TCP客户端在收到B的确认后，还要向B给出确认。确认报文段置ACK=1,确认号ack=y+1,而自己的序号:seq=x+1。此时TCP连接已建立。
A进入ESTABLISHED(已建立连接)状态。
当B收到A的确认后，也进入ESTABLISHED状态。

两次连接可不可以?

考虑这样一种情况:
    A发送连接请求，但由于网络原因，造成长时间滞留。于是A重传了一次连接请求，建立连接，数据传输完成后，连接断开。
    这个时候，滞留的连接请求到达B，这本来是一个失效的报文段，但是如果采取两次连接的话，在B向A发出确认之后，新的连接就建立了。
    由于现在A没有发连接请求，因此不会理睬B的确认，也不会向A发送数据。而B却以为连接已建立，并一直等待A发送数据，造成了B的
    资源的浪费。
    而采用三次握手的话，A不会向B的确认发送确认，B收不到确认，就知道A并没有要求建立连接。

TCP四次挥手的过程图

TCP四次挥手的过程

(1)A的应用进程先向其TCP发送连接释放报文段，并停止再发送数据，主动关闭TCP连接。A将连接释放报文段首部的FIN置1，其序号seq=u,
它等于前面已传送过的数据的最后一个字节的序号加1。这时候A进入FIN-WAIT-1(终止等待1)状态，等待B的确认。
(2)B收到连接释放报文段后即发出确认，确认号是ack=u+1,而这个报文段自己的序号是v,等于B前面已传送过的数据的最后一个字节的序号加1。
然后B进入CLOSE-WAIT(关闭等待)状态。
此时TCP服务器的进程应通知高层应用进程，因为A到B这个方向的连接已经释放了，这时TCP处于半关闭状态。从B到A这个方向的连接
并没有关闭，所以B若发送数据，A仍要接收。

A收到B的确认后，就进入FIN-WAIT-2(终止等待2)状态，等待B发出连接释放报文段。
(3)若B已经没有要向A发送的数据，其应用程序就通知TCP释放连接。这时候B发出的连接释放的报文段必须使FIN=1,
假定B的序号为w,B还需要重复确认上次发送的确认号ack=u+1。这时候B就进入LAST-ACK(最后确认)状态，等待A的确认。
(4)A在收到B的连接释放报文段后，必须对此发送确认。在确认报文段把ACK置1,确认号ack=w+1,而自己的序号是seq=u+1,然后
进入TIME-WAIT(时间等待)状态。这时候TCP连接还没有释放掉，必须经过时间等待计时器设置的时间后，A才进入到CLOSED状态。