TCP的三次握手&&四次挥手

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端所经历的状态如下:
155802215.gif
host2所经历的过程如下:
这里写图片描述

总结:以前对TCP的三次握手与四次挥手没有进行深入的理解,只是一知半解,现在参照网上的一些资料写了此博文,对此知识点有了深刻认识。在TCP连接的建立与释放的过程中,host1与host2并没有严格的客户端与服务器之分,谁先发起请求,那就是客户端。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
1、 主机Host1 ping主机 Host2时,IP包的首部有哪些字段?各字段的值是多少? 找出该IP包的源IP地址与目的IP分别地址是多少?是谁的IP地址? 找出该IP包所封装成的数据帧的源MAC地址与目的MAC地址分别是多少?是谁的MAC地址? 2、 主机Host1 ping主机 Host3时,IP包的首部有哪些字段?各字段的值是多少? 找出该IP包的源IP地址与目的IP分别地址是多少?是谁的IP地址? 找出该IP包所封装成的数据帧的源MAC地址与目的MAC地址分别是多少?是谁的MAC地址? 3、 上述两次ping过程,IP包和数据帧为什么会有区别,原因是什么? 原因: 当Host1 ping Host2时,两台主机在同一个网络,不需要经过路由器,直接交付;而当Host1 ping Host3时,两台主机不在同一个网络,需要经过路由器,通过目的网络地址确定下一跳路由器,经过多次间接交付到达目的网络上的路由器(即R2),当到达最后一个路由器时,才试图与目的主机直接交付。 4、 主机Host1 ping主机 Host2时,该IP包是否会通过交换机Switch1的GE 0/0/2转发? 答:不会,因为两台主机在通一个网络,直接交付 5、 主机Host1 ping主机 Host3时,该IP包是否会通过交换机Switch1的GE 0/0/2转发?若转发,请捕获该IP包,并与第2步中Host1的E /0/0/1所捕获的IP包比较,是否相同?若转发,该IP包在数据链路层封装成MAC帧是什么格式?是否与第2步的MAC帧格式相同?有何不同?原因是什么? 6、 继续捕获路由器Router1的GE 0/0/0接口、路由器Router2的GE 0/0/0接口的IP包和MAC帧,对照教程P123页图4-9分析。总结上述过程,描述IP包在网络的不同设备转发过程。 从路由器Router1的GE 0/0/0接口所捕获的数据包里面,过滤出RIP报文,对照教程P157页的图4-32,回答如下问题: 7、 路由器Router1发给路由器Router2的RIP报文,包含了哪些路由信息?路由器Router2发给路由器Router1的RIP报文,包含了哪些路由信息?同时查看路由器Router1的路由表(使用display ip routing-table命令),此时的路由表有哪些信息? 8、 断开主机Host3与路由器Router2的连接,再次捕获路由器Router1的GE 0/0/0接口的RIP报文,此时的路由信息有何变化?为什么?同时查看路由器Router1的路由表(使用display ip routing-table命令),此时的路由表有哪些信息?与第7步的路由表比较,有何区别? 9、 总结上述过程,描述RIP协议是如何建立和维护路由表的。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值