三次握手
客户端和服务端的初始化序列号是不同的
① 防止历史报文被下一个具有相同四元组的连接接收。
历史报文能否被对方接收,还要看该历史报文的序列号是否正好在对方接收窗口内,如果不在就会丢弃,如果在才会接收。如果每次建立连接时客户端和服务端的初始化序列号都「不一样」,就有大概率历史报文的序列号「不在」对方接收窗口。注意是很大程度上,并不是完全避免了。
RFC793 提到初始化序列号 ISN 随机生成算法:ISN = M + F(localhost, localport, remotehost, remoteport)
M
是一个计时器,这个计时器每隔4毫秒加1。
F
是一个 Hash 算法,根据源IP、目的IP、源端口、目的端口生成一个哈希值。
可以看到,随机数是会基于时钟计时器递增的,基本不可能会随机成一样的初始化序列号。初始化序列号可被视为一个 32 位的计数器,该计数器的数值每 4 微秒加 1,循环一次需要 4.55 小时。
序列号和初始化序列号并不是无限递增的,会发生回绕为初始值的情况,回绕发生时无法根据序列号来判断新老数据。
TCP 头部就会使用时间戳选项,它有两个好处,一个是便于精确计算 RTT ,另一个是能防止序列号回绕。
② 使用不同的初始序列号,还可以防止重放攻击。
为什么需要第三次握手
防止已经失效的连接请求报文段突然又传送到了服务端,避免服务器陷入不必要的等待。
第三次握手可以避免服务器陷入不必要的等待:客户端发送的数据包,可能因为网络拥塞,在网络中待的久了一些,客户端因为没有收到回复,已经放弃连接了,但这时候,服务器收到了这个数据包,开辟系统资源,返回确认包,系统的相关资源就白白浪费了。
最坏的情况是延迟的 "连接请求"和对 "连接被接受"的确认应答都在网络上存活着。因此最大分组存活时间T必须足够长,保证不仅分组数据,而且确认应答都已在网络中消失。
四次挥手
为什么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快到了
放个美图,别看了,快去工作!