字节一面:TCP 三次握手,问的好细!

网络 网络管理
TCP 三次握手中,客户端收到的第二次握手中 ack 确认号不是自己期望的,会发生什么?是直接丢弃 or 回 RST 报文?

大家好,我是小林。

有位读者在面试字节时,被问到这么个问题:

图片

概括起来,是这两个问题:

TCP 三次握手中,客户端收到的第二次握手中 ack 确认号不是自己期望的,会发生什么?是直接丢弃 or 回 RST 报文?

什么情况下会收到不正确的 ack(第二次握手中的 ack) 呢?

问题解答

不卖关子,直接说这个问题,是回 RST 报文。过程如下图:

图片

三次握手避免历史连接

当客户端连续发送多次建立连接的 SYN 报文,然后在网络拥堵的情况,就会发生客户端收到不正确的 ack 的情况。具体过程如下:

  • 客户端先发送了 SYN(seq = 90) 报文,但是被网络阻塞了,服务端并没有收到,接着客户端又重新发送了 SYN(seq = 100) 报文,注意不是重传 SYN,重传的 SYN 的序列号是一样的。
  • 「旧 SYN 报文」比「最新的 SYN 」 报文早到达了服务端,那么此时服务端就会回一个 SYN + ACK 报文给客户端,此报文的确认号是 91(90+1)。
  • 客户端收到后,发行自己期望收到的确认号应该是 100+1,而不是 90 + 1,于是就会回 RST 报文。
  • 服务端收到 RST 报文后,就会中止连接。
  • 后续最新的 SYN 抵达了服务端后,客户端与服务端就可以正常的完成三次握手了。

上述中的「旧 SYN 报文」称为历史连接,TCP 使用三次握手建立连接的最主要原因就是防止「历史连接」初始化了连接。

我们也可以从 RFC 793 知道 TCP 连接使用三次握手的首要原因:

The principle reason for the three-way handshake is to prevent old duplicate connection initiations from causing confusion.

简单来说,三次握手的首要原因是为了防止旧的重复连接初始化造成混乱。RFC 给出的三次握手防止历史连接的案例图如下:

图片

RFC 793

如果是两次握手连接,就无法阻止历史连接,那为什么 TCP 两次握手为什么无法阻止历史连接呢?

我先直接说结论,主要是因为在两次握手的情况下,「被动发起方」没有中间状态给「主动发起方」来阻止历史连接,导致「被动发起方」可能建立一个历史连接,造成资源浪费。

你想想,两次握手的情况下,「被动发起方」在收到 SYN 报文后,就进入 ESTABLISHED 状态,意味着这时可以给对方发送数据给,但是「主动发」起方此时还没有进入 ESTABLISHED 状态,假设这次是历史连接,主动发起方判断到此次连接为历史连接,那么就会回 RST 报文来断开连接,而「被动发起方」在第一次握手的时候就进入 ESTABLISHED 状态,所以它可以发送数据的,但是它并不知道这个是历史连接,它只有在收到 RST 报文后,才会断开连接。

图片

两次握手无法阻止历史连接

可以看到,上面这种场景下,「被动发起方」在向「主动发起方」发送数据前,并没有阻止掉历史连接,导致「被动发起方」建立了一个历史连接,又白白发送了数据,妥妥地浪费了「被动发起方」的资源。

因此,要解决这种现象,最好就是在「被动发起方」发送数据前,也就是建立连接之前,要阻止掉历史连接,这样就不会造成资源浪费,而要实现这个功能,就需要三次握手。

源码分析

我说回 RST 就回 RST 吗?当然不是了,肯定得用源码证明我说的这个结论。

听到要源码分析,可能有的同学就怂了。

其实要分析我们今天这个问题,只要懂 if else 就行了,我也会用中文来表述代码的逻辑,所以单纯看我的文字也是可以的。

这次我们重点分析的是,在 SYN_SENT 状态下,收到不正确的确认号的 syn+ack 报文是如何处理的。

处于 SYN_SENT 状态下的客户端,在收到服务端的  syn+ack 报文后,最终会调用  tcp_rcv_state_process,在这里会根据 TCP 状态做对应的处理,这里我们只关注 SYN_SENT 状态。

// net/ipv4/tcp_ipv4.c
int tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb)
{
...

int queued = 0;

...

switch (sk->sk_state) {
case TCP_CLOSE:
...
case TCP_LISTEN:
...
case TCP_SYN_SENT:
....
queued = tcp_rcv_synsent_state_process(sk, skb, th);
if (queued >= 0)
return queued;
...
}

可以看到,接下来,会继续调用 tcp_rcv_synsent_state_process 函数。

static int tcp_rcv_synsent_state_process(struct sock *sk, struct sk_buff *skb,
const struct tcphdr *th)
{
....

if (th->ack) {
/* rfc793:
* "If the state is SYN-SENT then
* first check the ACK bit
* If the ACK bit is set
* If SEG.ACK =< ISS, or SEG.ACK > SND.NXT, send
* a reset (unless the RST bit is set, if so drop
* the segment and return)"
*/
// ack 的确认号不是预期的
if (!after(TCP_SKB_CB(skb)->ack_seq, tp->snd_una) ||
after(TCP_SKB_CB(skb)->ack_seq, tp->snd_nxt))
//回 RST 报文
goto reset_and_undo;

...
}

从上面的函数,就可以得知了,客户端在 SYN_SENT 状态下,收到不正确的确认号的 syn+ack 报文会回 RST 报文。

小结

TCP 三次握手中,客户端收到的第二次握手中 ack 确认号不是自己期望的,会发生什么?是直接丢弃 or 回 RST 报文?

回 RST 报文。

什么情况下会收到不正确的 ack(第二次握手中的 ack) 呢?

当客户端发起多次 SYN 报文,然后网络拥堵的情况下,「旧的 SYN 报文」比「新的 SYN 报文」早抵达服务端,此时服务端就会按照收到的「旧的 SYN 报文」回复 syn+ack 报文,而此报文的确认号并不是客户端期望收到的,于是客户端就会回 RST 报文。

责任编辑:武晓燕 来源: 小林coding
相关推荐

2023-09-07 16:46:54

TCP数据传递

2020-12-08 06:34:16

TCP握手SYN 报文

2015-10-13 09:42:52

TCP网络协议

2024-01-12 08:23:11

TCPACK服务器

2022-10-10 07:34:36

TCP三次握手区块链

2023-10-24 15:22:09

TCPUDP

2022-07-07 09:00:17

TCP 连接HTTP 协议

2019-06-12 11:26:37

TCP三次握手四次挥手

2021-01-29 06:11:08

TCP通信三次握手

2021-05-18 12:27:40

TCP控制协议

2022-08-28 20:35:52

三次握手四次挥手TCP

2021-03-08 18:08:08

TCP Connect 协议

2022-07-25 07:07:35

TCP客户端服务器

2020-02-17 10:10:43

TCP三次握手四次挥手

2021-07-03 17:47:25

TCP控制协议

2018-10-15 08:06:33

TCP握手原理

2023-09-02 21:57:52

网络TCP协议

2019-12-12 10:36:43

TCPSYNIP

2018-07-05 14:25:01

TCP握手原理

2023-03-06 15:43:56

点赞
收藏

51CTO技术栈公众号