为什么 TCP 三次握手期间，客户端和服务端的初始化序列号要求不一样？

大家好，我是小林。

为什么 TCP 三次握手期间，客户端和服务端的初始化序列号要求不一样的呢？

接下来，我一步一步给大家讲明白，我觉得应该有不少人会有类似的问题，所以今天在肝一篇！

正文

为什么 TCP 三次握手期间，为什么客户端和服务端的初始化序列号要求不一样的呢？

主要原因是为了防止历史报文被下一个相同四元组的连接接收。

TCP 四次挥手中的 TIME_WAIT 状态不是会持续 2 MSL 时长，历史报文不是早就在网络中消失了吗？

是的，如果能正常四次挥手，由于 TIME_WAIT 状态会持续 2 MSL 时长，历史报文会在下一个连接之前就会自然消失。

但是来了，我们并不能保证每次连接都能通过四次挥手来正常关闭连接。

假设每次建立连接，客户端和服务端的初始化序列号都是从 0 开始：

过程如下：

客户端和服务端建立一个 TCP 连接，在客户端发送数据包被网络阻塞了，而此时服务端的进程重启了，于是就会发送 RST 报文来断开连接。
紧接着，客户端又与服务端建立了与上一个连接相同四元组的连接；
在新连接建立完成后，上一个连接中被网络阻塞的数据包正好抵达了服务端，刚好该数据包的序列号正好是在服务端的接收窗口内，所以该数据包会被服务端正常接收，就会造成数据错乱。

可以看到，如果每次建立连接，客户端和服务端的初始化序列号都是一样的话，很容易出现历史报文被下一个相同四元组的连接接收的问题。

客户端和服务端的初始化序列号不一样不是也会发生这样的事情吗？

是的，即使客户端和服务端的初始化序列号不一样，也会存在收到历史报文的可能。

但是我们要清楚一点，历史报文能否被对方接收，还要看该历史报文的序列号是否正好在对方接收窗口内，如果不在就会丢弃，如果在才会接收。

如果每次建立连接客户端和服务端的初始化序列号都「不一样」，就有大概率因为历史报文的序列号「不在」对方接收窗口，从而很大程度上避免了历史报文，比如下图：

相反，如果每次建立连接客户端和服务端的初始化序列号都「一样」，就有大概率遇到历史报文的序列号刚「好在」对方的接收窗口内，从而导致历史报文被新连接成功接收。

所以，每次初始化序列号不一样能够很大程度上避免历史报文被下一个相同四元组的连接接收，注意是很大程度上，并不是完全避免了。

那客户端和服务端的初始化序列号都是随机的，那还是有可能随机成一样的呀？

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

M是一个计时器，这个计时器每隔4毫秒加1。
F 是一个 Hash 算法，根据源IP、目的IP、源端口、目的端口生成一个随机数值，要保证 hash 算法不能被外部轻易推算得出。

可以看到，随机数是会基于时钟计时器递增的，基本不可能会随机成一样的初始化序列号。

懂了，客户端和服务端初始化序列号都是随机生成的话，就能避免连接接收历史报文了。

是的，但是也不是完全避免了。

为了能更好的理解这个原因，我们先来了解序列号（SEQ）和初始序列号（ISN）。

序列号，是 TCP 一个头部字段，标识了 TCP 发送端到 TCP 接收端的数据流的一个字节，因为 TCP 是面向字节流的可靠协议，为了保证消息的顺序性和可靠性，TCP 为每个传输方向上的每个字节都赋予了一个编号，以便于传输成功后确认、丢失后重传以及在接收端保证不会乱序。序列号是一个 32 位的无符号数，因此在到达 4G 之后再循环回到 0。
初始序列号，在 TCP 建立连接的时候，客户端和服务端都会各自生成一个初始序列号，它是基于时钟生成的一个随机数，来保证每个连接都拥有不同的初始序列号。初始化序列号可被视为一个 32 位的计数器，该计数器的数值每 4 微秒加 1，循环一次需要 4.55 小时。

给大家抓了一个包，下图中的 Seq 就是序列号，其中红色框住的分别是客户端和服务端各自生成的初始序列号。

图片

通过前面我们知道，序列号和初始化序列号并不是无限递增的，会发生回绕为初始值的情况，这意味着无法根据序列号来判断新老数据。

不要以为序列号的上限值是 4GB，就以为很大，很难发生回绕。在一个速度足够快的网络中传输大量数据时，序列号的回绕时间就会变短。如果序列号回绕的时间极短，我们就会再次面临之前延迟的报文抵达后序列号依然有效的问题。

为了解决这个问题，就需要有 TCP 时间戳。tcp_timestamps 参数是默认开启的，开启了 tcp_timestamps 参数，TCP 头部就会使用时间戳选项，它有两个好处，一个是便于精确计算 RTT ，另一个是能防止序列号回绕（PAWS）。

试看下面的示例，假设 TCP 的发送窗口是 1 GB，并且使用了时间戳选项，发送方会为每个 TCP 报文分配时间戳数值，我们假设每个报文时间加 1，然后使用这个连接传输一个 6GB 大小的数据流。

32 位的序列号在时刻 D 和 E 之间回绕。假设在时刻B有一个报文丢失并被重传，又假设这个报文段在网络上绕了远路并在时刻 F 重新出现。如果 TCP 无法识别这个绕回的报文，那么数据完整性就会遭到破坏。

使用时间戳选项能够有效的防止上述问题，如果丢失的报文会在时刻 F 重新出现，由于它的时间戳为 2，小于最近的有效时间戳（5 或 6），因此防回绕序列号算法（PAWS）会将其丢弃。

防回绕序列号算法要求连接双方维护最近一次收到的数据包的时间戳（Recent TSval），每收到一个新数据包都会读取数据包中的时间戳值跟 Recent TSval 值做比较，如果发现收到的数据包中时间戳不是递增的，则表示该数据包是过期的，就会直接丢弃这个数据包。

懂了，客户端和服务端的初始化序列号都是随机生成，能很大程度上避免历史报文被下一个相同四元组的连接接收，然后又引入时间戳的机制，从而完全避免了历史报文被接收的问题。

嗯嗯，没错。

为什么 TCP 三次握手期间，客户端和服务端的初始化序列号要求不一样？相关推荐

mysql服务器是否支持tcp/ip连接,(3)MySQL客户端与服务端的TCP/IP及socket连接方式-Go语言中文社区...
MySQL客户端与服务端的TCP/IP及socket连接方式客户端与服务器模型客户端与服务端模型 TCP/IP方式连接解释说明 TCP/IP套接字方式是MySQL在任何平台下都提供的连接方式,也 ...
mysql三次握手_一文彻底搞懂 TCP三次握手、四次挥手过程及原理
原创文章首发于公众号:「码农富哥」,欢迎收藏和关注,如转载请注明出处! TCP 协议简述 TCP 提供面向有连接的通信传输,面向有连接是指在传送数据之前必须先建立连接,数据传送完成后要释放连接. 无论 ...
TCP三次握手、四次挥手过程及原理
TCP 协议简述 TCP 提供面向有连接的通信传输,面向有连接是指在传送数据之前必须先建立连接,数据传送完成后要释放连接. 无论哪一方向另一方发送数据之前,都必须先在双方之间建立一条连接.在TCP/I ...
Linux网络编程——浅谈 TCP 三次握手和四次挥手
一.tcp协议格式二.三次握手在 TCP/IP 协议中,TCP 协议提供可靠的连接服务,采用三次握手建立一个连接. 第一次握手:建立连接时,客户端发送 syn 包(tcp协议中syn位置1,序号为 ...
java锁一次交互二次握手_Java后台开发面试实战（二）：TCP三次握手四次挥手
感谢牛客网网友提供的面试经验! 1. 解释一下TCP三次握手四次挥手图片来源于微信公众号:码农求职小助手答: 嗯(稍作思考)- 三次握手简单来说,在数据传输开始前: 第一次握手:客户端向服务端发送 ...
【Linux网络编程】TCP三次握手和四次挥手
00. 目录文章目录 00. 目录 01. 三次握手 02. 四次挥手 03. 三次握手和四次挥手原因 04. 2MSL 05. 附录 01. 三次握手在 TCP/IP 协议中,TCP 协议提供可 ...
【Linux网络编程】浅谈 TCP 三次握手和四次挥手
三次握手在 TCP/IP 协议中,TCP 协议提供可靠的连接服务,采用三次握手建立一个连接. 第一次握手:建立连接时,客户端发送 syn 包(syn=j)到服务器,并进入 SYN_SEND 状态,等 ...
TCP三次握手详解及面试题
为什么必须是三次握手? 大家都知道传输层(点击这里去传输层)中的TCP协议是面向连接的,提供可靠的连接服务,其中最出名的就是三次握手和四次挥手,今天先讲解三次握手(四次挥手点这里),如下图喜 ...
网络协议：TCP三次握手与四次挥手
本篇内容包括:TCP/IP 传输协议(TCP/IP 传输协议简介,IP 协议,UDP 协议,TCP 协议介绍),TCP 的三次握手.TCP 的四次挥手以及 TCP 协议是怎么保证有效传输等内容. 一 ...

为什么 TCP 三次握手期间，客户端和服务端的初始化序列号要求不一样？

正文

为什么 TCP 三次握手期间，客户端和服务端的初始化序列号要求不一样？相关推荐

最新文章

热门文章