TCP连接的建立与释放过程中的常考问题

本文详细阐述了TCP的三次握手过程,解释了为何需要不同的初始化序列号以防止历史报文被错误接收和重放攻击,同时指出第三次握手的作用在于避免服务器因过时的连接请求浪费资源。此外,还探讨了TCP四次挥手时等待2MSL的必要性,旨在确保旧连接的所有报文消失,保护新连接不受干扰。
摘要由CSDN通过智能技术生成

IP报文格式

三次握手

2

客户端和服务端的初始化序列号是不同的

① 防止历史报文被下一个具有相同四元组的连接接收。

历史报文能否被对方接收,还要看该历史报文的序列号是否正好在对方接收窗口内,如果不在就会丢弃,如果在才会接收。如果每次建立连接时客户端和服务端的初始化序列号都「不一样」,就有大概率历史报文的序列号「不在」对方接收窗口。注意是很大程度上,并不是完全避免了。

RFC793 提到初始化序列号 ISN 随机生成算法:ISN = M + F(localhost, localport, remotehost, remoteport)

M是一个计时器,这个计时器每隔4毫秒加1。
F 是一个 Hash 算法,根据源IP、目的IP、源端口、目的端口生成一个哈希值。

可以看到,随机数是会基于时钟计时器递增的,基本不可能会随机成一样的初始化序列号。初始化序列号可被视为一个 32 位的计数器,该计数器的数值每 4 微秒加 1,循环一次需要 4.55 小时。

序列号和初始化序列号并不是无限递增的,会发生回绕为初始值的情况,回绕发生时无法根据序列号来判断新老数据。

TCP 头部就会使用时间戳选项,它有两个好处,一个是便于精确计算 RTT ,另一个是能防止序列号回绕。

② 使用不同的初始序列号,还可以防止重放攻击。

为什么需要第三次握手

防止已经失效的连接请求报文段突然又传送到了服务端,避免服务器陷入不必要的等待。

第三次握手可以避免服务器陷入不必要的等待:客户端发送的数据包,可能因为网络拥塞,在网络中待的久了一些,客户端因为没有收到回复,已经放弃连接了,但这时候,服务器收到了这个数据包,开辟系统资源,返回确认包,系统的相关资源就白白浪费了。

只有 "连接请求"超时 "连接请求"和 "连接确认"都超时

最坏的情况是延迟的 "连接请求"和对 "连接被接受"的确认应答都在网络上存活着。因此最大分组存活时间T必须足够长,保证不仅分组数据,而且确认应答都已在网络中消失。

四次挥手

1

为什么TCP 4次挥手时等待为2MSL?

① 尽量保证被动关闭的一端收到它自己发出去的FIN报文的ACK确认报文。

② 避免前后两个使用相同四元组的连接中的前一个连接的报文干扰后一个连接。

等待2MSL的真正目的是为了避免前后两个使用相同四元组的连接中的前一个连接的报文干扰后一
个连接,换句话说,就是为了让此次TCP连接中的所有报文在网络中消失。
假如现在A发送ACK后,最坏情况下,这个ACK在1MSL时到达B;此时B在收到这个ACK的
前一刹那,一直在重传FIN,这个FIN最坏会在1MSL时间内消失。因此从A发送ACK的那一刹
那开始,等待2MSL可以保证A发送的最后一个ACK,和B发送的最后一个FIN都在网络中消失

其他有时间再补充吧,论文deadline快到了

deadline

放个美图,别看了,快去工作!

taylor-swift-singer-celebrity-taylor-wallpaper

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Anonymity~

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值