tcp协议三次握手详细过程

　　TCP协议三次握手过程

        TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接：

　　位码即tcp标志位，有6种标示：SYN（synchronous建立联机） ACK（acknowledgement 确认） PSH（push传送） FIN（finish结束） RST（reset重置） URG（urgent紧急）

　　Sequence number（顺序号码） Acknowledge number（确认号码）

　　第一次握手：主机A发送位码为syn＝1，随机产生seq number=1234567的数据包到服务器，主机B由SYN=1知道，A要求建立联机；

　　第二次握手：主机B收到请求后要确认联机信息，向A发送ack number=（主机A的seq+1），syn=1，ack=1，随机产生seq=7654321的包

　　第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1，以及位码ack是否为1，若正确，主机A会再发送ack number=（主机B的seq+1），ack=1，主机B收到后确认seq值与ack=1则连接建立成功。

　　完成三次握手，主机A与主机B开始传送数据。

　　在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。

　　第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SEND状态，等待服务器确认；

　　第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态； 第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK（ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。 完成三次握手，客户端与服务器开始传送数据。

　　实例：

　　IP 192.168.1.116.3337 》 192.168.1.123.7788： S 3626544836:3626544836

　　IP 192.168.1.123.7788 》 192.168.1.116.3337： S 1739326486:1739326486 ack 3626544837

　　IP 192.168.1.116.3337 》 192.168.1.123.7788： ack 1739326487，ack 1

　　第一次握手：192.168.1.116发送位码syn＝1，随机产生seq number=3626544836的数据包到192.168.1.123，192.168.1.123由SYN=1知道192.168.1.116要求建立联机;

　　第二次握手：192.168.1.123收到请求后要确认联机信息，向192.168.1.116发送ack number=3626544837，syn=1，ack=1，随机产生seq=1739326486的包;

　　第三次握手：192.168.1.116收到后检查ack number是否正确，即第一次发送的seq number+1，以及位码ack是否为1，若正确，192.168.1.116会再发送ack number=1739326487，ack=1，192.168.1.123收到后确认seq=seq+1，ack=1则连接建立成功。

　　图解：

　　一个三次握手的过程（图1，图2）

　　

　　第一次握手的标志位（图3）

　　我们可以看到标志位里面只有个同步位，也就是在做请求（SYN）

　　

　　第二次握手的标志位（图4）

　　我们可以看到标志位里面有个确认位和同步位，也就是在做应答（SYN + ACK）

　　

　　第三次握手的标志位（图5）

　　我们可以看到标志位里面只有个确认位，也就是再做再次确认（ACK）

　　

　　一个完整的三次握手也就是 请求---应答---再次确认

　　三次握手的过程分析

　　

　　首先由Client发出请求连接即 SYN=1 ACK=0 （请看头字段的介绍）， TCP规定SYN=1时不能携带数据，但要消耗一个序号，因此声明自己的序号是 seq=x

　　然后 Server 进行回复确认，即 SYN=1 ACK=1 seq=y， ack=x+1，

　　再然后 Client 再进行一次确认，但不用SYN 了，这时即为 ACK=1， seq=x+1， ack=y+1.

　　然后连接建立，为什么要进行三次握手呢（两次确认）。

　     为什么A 还要发送一次确认呢？ 这主要是为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。

　　所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常情况。A 发出连接请求，但因连接请求报文丢失而未收到确认。于是A 再重传一一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。A 共发送了两个连接请求报文段，其中第一个丢失，第二个到达了B。没有“已失效的连接请求报文段”。

　　而是在某现假定出现一种异常情况，即A 发出的第一一个连接请求报文段并没有丢失，些网络结点长时间滞留了，以致延误到连接释放以后的某个时间才到达B。本来这是- 一个早已失效的报文段。但B 收到此失效的连接请求报文段后，就误认为是A 又发出一次新的连接请求。于是就向A 发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立了。也不会向B 发送数

　　由于现在A 并没有发出建立连接的请求，因此不会理睬B 的确认，据。但B 却以为新的运输连接已经建立了，并一直等待A 发来数据。B 的许多资源就这样白白浪费了。

　　采用3 次握手的办法可以防止上述现象的发生。例如在刚才的情况下，A 不会向B 的确认发出确认。B 由于收不到确认，就知道A 并没有要求建立连接。

　　下面是释放连接的过程：

　　

　　当客户A 没有东西要发送时就要释放 A 这边的连接，A会发送一个报文（没有数据），其中 FIN 设置为1， 服务器B收到后会给应用程序一个信，这时A那边的连接已经关闭，即A不再发送信息（但仍可接收信息）。 A收到B的确认后进入等待状态，等待B请求释放连接， B数据发送完成后就向A请求连接释放，也是用FIN=1 表示， 并且用 ack = u+1（如图）， A收到后回复一个确认信息，并进入 TIME_WAIT 状态， 等待 2MSL 时间。

　　为什么要等待呢？

　　为了这种情况： B向A发送 FIN = 1 的释放连接请求，但这个报文丢失了， A没有接到不会发送确认信息， B 超时会重传，这时A在 WAIT_TIME 还能够接收到这个请求，这时再回复一个确认就行了。（A收到 FIN = 1 的请求后 WAIT_TIME会重新记时）

　　另外服务器B存在一个保活状态，即如果A突然故障死机了，那B那边的连接资源什么时候能释放呢？ 就是保活时间到了后，B会发送探测信息， 以决定是否释放连接。