TCP段格式:
TCP((Transmission Control Protocol)传输控制协议,是一个面向连接的协议。在运用此协议进行数据传输前都会进行连接的建立工作(三次握手);当数据传输完毕,连接的双方都会通知对方要释放此连接(四次挥手)。
认识TCP标志位
tcp标志位有6种标示:
SYN(synchronous建立联机)
ACK(acknowledgement 确认)
PSH(push传送)
FIN(finish结束)
RST(reset重置)
URG(urgent紧急)
图解TCP与UDP的三次握手与四次挥手过程
三次握手过程:
第一次握手:host1发送一个TCP标志位SYN=1、ACK=0的数据包给host2,并随机会产生一个Sequence number=3233.当host2接收到这个数据后,host2由SYN=1可知客户端是想要建立连接;
第二次握手:host2要对客户端的联机请求进行确认,向host1发送应答号ACK=1、SYN=1、
确认号Acknowledge number=3234,此值是host1的序列号加1,还会产生一个随机的序列号Sequence number=36457,这样就告诉host1可以进行连接;
第三次握手:host1收到数据后检查Acknowledge number是否是3233+1的值,以及ACK的值是否为1,若为1,host1会发送ACK=1、确认号码Acknowledge number=36457,告诉host2,你的请求连接被确认,连接可以建立
(一)三次握手的过程
如图所示TCP建立连接的过程形象的称为三次握手,客户端和服务器就像在进行如下的对话:
客户端:“可以连接你吗”
服务器:“可以呀,什么时候”
客户端:“就现在呀”
第一次握手时:SYN表示连接请求,序号是1000表示用作网络通讯的临时地址。这个序号每发送一字节数据,序号就加一。
这样就可以在接收端排出收到数据的先后顺序,建立连接虽然没有发送数据,但是SYN位占一个字节(FIN也占一个字节)所以下次再发送的时候,就要从1001开始。mss表示最大段尺寸,建议服务器发来的数据段不要超过这个长度。
第二次握手时:服务器收到服务器收到SYN包向客户端发送一个ACK确认包,同时发送一个自己的SYN包
第三次握手:客户端收到SYN+ACK包并向服务器发送确认ACK.
至于为什么是三次握手而不是两次或者四次原因一般如下:
如果改成两次
(1)防止已过期的连接信息再次传到主机
比如是A机要连到B机,结果发送的连接信息由于某种原因没有到达B机;于是,A机又发了一次,结果这次B收到了,于是就发信息回来,两机就连接。传完东西后,断开。结果这时候,原先没有到达的连接信息突然又传到了B机,于是B机发信息给A,然后B机就以为和A连上。
(2)防止产生死锁
计算机A和B之间的通信,假定B给A发送一个连接请求分组,A收到了这个分组,并发送了确认应答分组。按照两次握手的协定,A认为连接已经成功地建立了,可以开始发送数据分组。可是,B在A的应答分组在传输中被丢失的情况下,将不知道A是否已准备好,不知道A建议什么样的序列号,B甚至怀疑A是否收到自己的连接请求分组。在这种情况下,B认为连接还未建立成功,将忽略A发来的任何数据分组,只等待连接确认应答分组。而A在发出的分组超时后,重复发送同样的分组。这样就形成了死锁。
改成四次:
经过大量的实践发现三次连接已经能够可靠地连接自然不必要设计的更加繁琐。
四次挥手过程:
(二)四次挥手
断开连接端可以是Client端,也可以是Server端。
(1)假设Client端发起中断连接请求,就先发送FIN报文。
(2)Server端接到FIN报文后,但是如果还有数据没有发送完成,则不必急着关闭Socket,可以继续发送数据。所以服务器端先发送ACK,告诉Client端:请求已经收到了,但是我还没准备好,请继续等待停止的消息。这个时候Client端就进入FIN_WAIT状态,继续等待Server端的FIN报文。
(3)当Server端确定数据已发送完成,则向Client端发送FIN报文,告诉Client端:服务器这边数据发完了,准备好关闭连接了。
(4)Client端收到FIN报文后,就知道可以关闭连接了,但是他还是不相信网络,所以发送ACK后进入TIME_WAIT状态, Server端收到ACK后,就知道可以断开连接了。Client端等待了2MSL后依然没有收到回复,则证明Server端已正常关闭,最后,Client端也可以关闭连接了至此,TCP连接就已经完全关闭了!关闭连接的过程如下图所示:
第一次挥手:当传输的数据到达尾部时,host1向host2发送FIN=1标志位;可理解成,host1向host2说,我这边的数据传送完成了,我准备断开了连接;
第二次挥手:因TCP的连接是全双工的双向连接,关闭也是要从两边关闭;当host2收到host1发来的FIN=1的标志位后,host2不会立刻向host1发送FIND=1的请求关闭信息,而是先向host1发送一个ACK=1的应答信息,表示:你请求关闭的请求我已经收到,但我可能还有数据没有完成传送,你再等下,等我数据传输完成了我就告诉你;
第三次挥手:host2数据传输完成,向host1发送FIN=1,host1收到请求关闭连接的请求后,host1就明白host2的数据已传输完成,现在可以断开连接了,
第四次挥手:host1收到FIND=1后,host1还是怕由于网络不稳定的原因,怕host2不知道他要断开连接,于是向host2发送ACK=1确认信息进行确认,把自己设置成TIME_WAIT状态并启动定时器,如果host2没有收到ACK,host2端TCP的定时器到达后,会要求host1重新发送ACK,当host2收到ACK后,host2就断开连接;当host1等待2MLS(2倍报文最大生存时间)后,没有收到host2的重传请求后,他就知道host2已收到了ACK,所以host1此时才关闭自己的连接。这一点我觉得设计得非常巧妙!
整个过程host1端所经历的状态如下:
host2所经历的过程如下:
总结:以前对TCP的三次握手与四次挥手没有进行深入的理解,只是一知半解,现在参照网上的一些资料写了此博文,对此知识点有了深刻认识。在TCP连接的建立与释放的过程中,host1与host2并没有严格的客户端与服务器之分,谁先发起请求,那就是客户端。