某客户配置SLB 7层监听，通过SLB访问业务偶发出现5秒才响应的情况，通过SLB访问日志查看是SLB与upstream TCP建立连接5秒超时后SLB重试转发请求到另外一个upstream后端，另外一个upstream后端建立连接成功并请求成功，由于SLB默认的TCP建联时间是5秒，第一个请求建联失败重试的请求建联正常，所以总请求时间就变成了5.x秒。

通过SLB访问日志查看，SLB后端10台upstream相同概率出现建联失败的情况，失败率不到1%。SLB 7层监听场景与后端建联失败是比较常见的一个现象，比较常见的原因是因为SLB与upstream是短连接，所以每个HTTP请求都会单独建立TCP连接，在QPS比较大的情况下，后端如果TCP监听队列比较小，就会出现TCP半连接或者全连接队列溢出导致建联失败，这种场景可以调整TCP内核参数和应用的backlog缓解问题。

此问题也是照常在后端抓包看是否是后端没有响应syn报文导致建联失败，通过抓包发现并不是连接队列溢出导致丢弃SYN而无法建联问题，抓包现场如下，SLB发给后端SYN报文，但是后端返回是ACK报文，且ACK number也不是期望的序号，正常服务端应该返回SYN ACK报文，且ACK序列号应该是客户端的Seq+1。由于服务端返回了ACK报文导致SLB无法建立连接，重传2此后5秒超时建联失败。

服务端收到SYN，回复的是ACK，没有回复SYN ACK的场景之前遇到过但是没有深究，此问题在容器/K8S环境中比较容易遇到，怀疑是因为K8S环境中会有比较多的源/目IP转换操作可能导致TCP连接串流、异常等场景。

为什么客户端发送syn,服务端回ack,没有回syn,ack

在其中一个ECS上抓包，抓取所有POD与ECS的报文，通过过滤报文异常请求如下。100.116.x.x是SLB的回源local ip地址段，10.254.109.57为ECS 网卡eth0的IP，172.29.67.0为10.254.109.57这个K8S worker节点的flannel0网卡IP，172.20.70.12为业务POD IP。

第一个连接ECS收到的五元组为： 100.116.238.146:28562-->10.254.109.57:30040

第一个连接经过IPtables转换后：172:20.67.0:40350-->172.20.70.12:8080

第一个连接请求结束后在32秒后发起了第二个请求

第二个连接ECS收到的五元组为： 100.116.238.186:35416-->10.254.109.57:30040

第二个连接经过IPtables转换后：172:20.67.0:40350-->172.20.70.12:8080

可以看到两次请求ECS收到的5元组是不同的，但是经过IPtables转换后五元组就相同了，而且两次连接请求相差32秒左右，由于第一个请求是服务端POD主动发起Fin的，所以POD在收到第二次请求的时候第一个连接五元组的TCP状态是在TIME-WAIT状态。

在 TIME_WAIT 状态的 TCP 连接，收到 SYN 后会发生什么？

在TCP正常挥手过程中，处于TIME_WAIT状态的TCP连接，如果收到相同五元组的SYN报文服务端会怎么处理？

源码分析

下面源码分析是基于 Linux 5.10 版本的内核代码。

Linux 内核在收到 TCP 报文后，会执行 tcp_v4_rcv 函数，在该函数和 TIME_WAIT 状态相关的主要代码如下：

int tcp_v4_rcv(struct sk_buff *skb)
{
  struct sock *sk;
 ...
  //收到报文后，会调用此函数，查找对应的 sock
 sk = __inet_lookup_skb(&tcp_hashinfo, skb, __tcp_hdrlen(th), th->source,
          th->dest, sdif, &refcounted);
 if (!sk)
  goto no_tcp_socket;
process:
  //如果连接的状态为 time_wait，会跳转到 do_time_wait
 if (sk->sk_state == TCP_TIME_WAIT)
  goto do_time_wait;
...
do_time_wait:
  ...
  //由tcp_timewait_state_process函数处理在 time_wait 状态收到的报文
 switch (tcp_timewait_state_process(inet_twsk(sk), skb, th)) {
    // 如果是TCP_TW_SYN，那么允许此 SYN 重建连接
    // 即允许TIM_WAIT状态变更为SYN_RECV
    case TCP_TW_SYN: {
      struct sock *sk2 = inet_lookup_listener(....);
      if (sk2) {
          ....
          goto process;
      }
    }
    // 如果是TCP_TW_ACK，那么，返回记忆中的ACK
    case TCP_TW_ACK:
      tcp_v4_timewait_ack(sk, skb);
      break;
    // 如果是TCP_TW_RST直接发送RESET包
    case TCP_TW_RST:
      tcp_v4_send_reset(sk, skb);
      inet_twsk_deschedule_put(inet_twsk(sk));
      goto discard_it;
     // 如果是TCP_TW_SUCCESS则直接丢弃此包，不做任何响应
    case TCP_TW_SUCCESS:;
 }
 goto discard_it;
}

该代码的过程：

接收到报文后，会调用 __inet_lookup_skb() 函数查找对应的 sock 结构；
如果连接的状态是 TIME_WAIT，会跳转到 do_time_wait 处理；
由 tcp_timewait_state_process() 函数来处理收到的报文，处理后根据返回值来做相应的处理。

接下来，看 tcp_timewait_state_process() 函数是如何判断 SYN 包的。

enum tcp_tw_status
tcp_timewait_state_process(struct inet_timewait_sock *tw, struct sk_buff *skb,
      const struct tcphdr *th)
{
 ...
  //paws_reject 为 false，表示没有发生时间戳回绕
  //paws_reject 为 true，表示发生了时间戳回绕
 bool paws_reject = false;
 tmp_opt.saw_tstamp = 0;
  //TCP头中有选项且旧连接开启了时间戳选项
 if (th->doff > (sizeof(*th) >> 2) && tcptw->tw_ts_recent_stamp) { 
  //解析选项
    tcp_parse_options(twsk_net(tw), skb, &tmp_opt, 0, NULL);
  if (tmp_opt.saw_tstamp) {
   ...
      //检查收到的报文的时间戳是否发生了时间戳回绕
   paws_reject = tcp_paws_reject(&tmp_opt, th->rst);
  }
 }
....
  //是SYN包、没有RST、没有ACK、时间戳没有回绕(开启timestamp参数)
  //是SYN包、没有RST、没有ACK、序列号递增(未开启timestamp参数)
 if (th->syn && !th->rst && !th->ack && !paws_reject &&
     (after(TCP_SKB_CB(skb)->seq, tcptw->tw_rcv_nxt) ||
      (tmp_opt.saw_tstamp && //新连接开启了时间戳
       (s32)(tcptw->tw_ts_recent - tmp_opt.rcv_tsval) < 0))) { //时间戳没有回绕
    // 初始化序列号
    u32 isn = tcptw->tw_snd_nxt + 65535 + 2; 
    if (isn == 0)
      isn++;
    TCP_SKB_CB(skb)->tcp_tw_isn = isn;
    return TCP_TW_SYN; //允许重用TIME_WAIT四元组重新建立连接
 }
 if (!th->rst) {
    // 如果时间戳回绕，或者报文里包含ack，则将 TIMEWAIT 状态的持续时间重新延长
  if (paws_reject || th->ack)
    inet_twsk_schedule(tw, TCP_TIMEWAIT_LEN);
     // 返回TCP_TW_ACK, 发送上一次的 ACK
    return tcp_timewait_check_oow_rate_limit(
      tw, skb, LINUX_MIB_TCPACKSKIPPEDTIMEWAIT); 
 }
 inet_twsk_put(tw);
 return TCP_TW_SUCCESS;
}
tcp_timewait_check_oow_rate_limit(struct inet_timewait_sock *tw,
          const struct sk_buff *skb, int mib_idx)
{
  struct tcp_timewait_sock *tcptw = tcp_twsk((struct sock *)tw);
  if (!tcp_oow_rate_limited(twsk_net(tw), skb, mib_idx,
          &tcptw->tw_last_oow_ack_time)) {
    /* Send ACK. Note, we do not put the bucket,
     * it will be released by caller.
     */
    return TCP_TW_ACK;
  }
  /* We are rate-limiting, so just release the tw sock and drop skb. */
  inet_twsk_put(tw);
  return TCP_TW_SUCCESS;
}

从源码可以看到，核心判断语句是 (th->syn && !th->rst && !th->ack && !paws_reject && (after(TCP_SKB_CB(skb)->seq, tcptw->tw_rcv_nxt) ||

(tmp_opt.saw_tstamp && (s32)(tcptw->tw_ts_recent - tmp_opt.rcv_tsval) < 0)))

th->syn：是否为SYN，是则为1，不是则为0，此判断中永久为1
!th->rst：是否为RESET，是则0，不是则为1，此判断中永久为1
!th->ack：是否为ACK，是则0，不是则为1，此判断中永久为1
!paws_reject：是否发生序列号回绕，发生回绕则为0，未发生回绕或者未开启时间戳则为1
after(TCP_SKB_CB(skb)->seq, tcptw->tw_rcv_nxt)：SYN包的序列号是否比TIME-WAIT时候增大，增大则为1，减小为0
tmp_opt.saw_tstamp：是否开启时间错，开启则为1，未开启则为0
(s32)(tcptw->tw_ts_recent - tmp_opt.rcv_tsval) < 0：TIME-WAIT记录的时间搓是否比SYN报文的小，小则为1，大则为0

总的来说有如下几种情况

双方开启TCP时间戳

时间戳发生回绕：返回TCP_TW_ACK
时间戳未发生回绕: 返回TCP_TW_SYN

双方未开启TCP时间戳

SYN序列号比TIME-WAIT中的大：返回TCP_TW_SYN
SYN序列号比TIME-WAIT中的小：返回TCP_TW_ACK

当收到 SYN 包后，如果该 SYN 包的时间戳没有发生回绕，也就是时间戳是递增的。就会初始化一个序列号，然后返回 TCP_TW_SYN，接着就重用该连接，也就跳过 2MSL 而转变为 SYN_RECV 状态，接着就能进行建立连接过程。

如果双方都没有启用 TCP 时间戳机制，就只需要判断 SYN 包的序列号有没有发生回绕，如果 SYN 的序列号大于下一次期望收到的序列号，就可以跳过 2MSL，重用该连接。

如果收到的 SYN 是合法的，tcp_timewait_state_process() 函数就会返回 TCP_TW_SYN，然后重用此连接。如果收到的 SYN 是非法的，tcp_timewait_state_process() 函数就会返回 TCP_TW_ACK，然后会回上次发过的 ACK。

结论

当处于TCP TIME-WAIT连接时收到SYN后会判断SYN是否合法，如果合法则返回SYN,ACK报文，如果是非法SYN会返回上一次四次挥手的ACK报文。

开启TCP时间戳

合法 SYN：客户端SYN 的「时间戳」比服务端「最后收到的报文的时间戳」要大。
非法 SYN：客户端SYN 的「时间戳」比服务端「最后收到的报文的时间戳」要小。

未开启TCP时间戳

合法 SYN：客户端的 SYN 的「序列号」比服务端「期望下一个收到的序列号」要大。
非法 SYN：客户端的 SYN 的「序列号」比服务端「期望下一个收到的序列号」要小。

收到合法 SYN

如果处于 TIME_WAIT 状态的连接收到“合法的 SYN ”后，就会重用此四元组连接，跳过 2MSL 而转变为 SYN_RECV 状态，接着就能进行建立连接过程。

用下图作为例子，双方都启用了 TCP 时间戳机制，TSval 是发送报文时的时间戳：

上图中，在收到第三次挥手的 FIN 报文时，会记录该报文的 TSval （41），用 ts_recent 变量保存。处于 TIME_WAIT 状态的连接收到 SYN 后，因为SYN 的 TSval（50）大于 ts_recent（41），所以是一个「合法的 SYN」，于是就会重用此四元组连接，跳过 2MSL 而转变为 SYN_RECV 状态，接着就能进行建立连接过程。

收到非法的 SYN

如果处于 TIME_WAIT 状态的连接收到“非法的 SYN ”后，就会再回复一个第四次挥手的 ACK 报文，客户端收到后，发现并不是自己期望收到确认号（ack num），就回 RST 报文给服务端。

用下图作为例子，双方都启用了 TCP 时间戳机制，TSval 是发送报文时的时间戳：

上图中，在收到第三次挥手的 FIN 报文时，会记录该报文的 TSval （41），用 ts_recent 变量保存。处于 TIME_WAIT 状态的连接收到 SYN 后，因为SYN 的 TSval（30）小于 ts_recent（41），所以是一个“非法的 SYN”，于是服务端重传一次第四次挥手时候的ACK包，客户端收到后，发现并不是自己期望收到确认号，就回 RST 报文给服务端。

复现抓包

使用scapy构造五元组连接来复现看是否与源码中定义的内容一致。

ans, unans = sr(IP(dst = "目的IP") / TCP(sport = 源端口 , dport = 目的端口, flags = "S",seq = 序列号,options=[('Timestamp', (时间戳, 0))]))

双方开启时间戳

构造TCP连接，发出与处于TIME-WAIT状态下相同的五元组连接，设置不同的序列号和时间戳。

SYN报文	序列号增大，时间戳增大	序列号增大，时间戳减小	序列号减小，时间戳增大	序列号减小，时间戳减小
结果	返回SYN ACK	返回四次挥手ACK	返回SYN ACK	返回四次挥手ACK

双方关闭时间戳

构造TCP连接，发出与处于TIME-WAIT状态下相同的五元组连接，设置不同的序列号。

SYN报文	序列号增大	序列号减小
结果	返回SYN ACK	返回四次挥手ACK

客户端关闭时间戳，服务端开启时间戳

在客户端关闭tcp timestamp，在服务端开启timestamp测试

SYN报文	序列号增大	序列号减小
结果	返回SYN ACK	返回四次挥手ACK

客户端开启时间戳，服务端关闭时间戳

在客户端开启tcp timestamp，在服务端关闭timestamp测试

SYN报文	序列号增大，时间戳增大	序列号增大，时间戳减小	序列号减小，时间戳增大	序列号减小，时间戳减小
结果	返回SYN ACK	返回SYN ACK	返回四次挥手ACK	返回四次挥手ACK

客户端第一次开启时间戳，第二次关闭时间戳，服务端开启时间戳

SYN报文	序列号增大	序列号减小
结果	返回SYN ACK	返回四次挥手ACK

客户端第一次关闭时间戳，第二次开启时间戳，服务端开启时间戳

SYN报文	序列号增大	序列号减小
结果	返回SYN ACK	返回四次挥手ACK

总结

SLB发起的连接请求到达ECS后，K8S环境中IPTABLES会把SLB的LOCAL IP转换为Flannel0网卡IP，由于网卡IP是固定的，只有源端口变化，所以当请求量比较大的时候，会复用TIME-WAIT状态的TCP连接。当复用五元组的时候，如果TCP时间戳timestamps没有递增，容器POD协议栈会返回四次挥手的ACK报文，此ACK报文不是SLB期望的SYN ACK报文，导致SLB与后端服务建联超时，建联超时后SLB重试连接请求发给另外一个后端，另外一个后端重新转化源地址如果没有命中重传一次四次挥手ACK的场景则可以正常建立连接，请求可以正常完成。

解决方案

由于这个问题是Linux 内核TCP协议栈正常的行为，想要解决此问题需要改变请求的请求方式避免服务端处于Time-Wait状态的连接收到相同五元组的SYN报文。

方案一（最佳）：使用阿里云terway eni的集群，由于terway是从SLB直接把报文发生给了POD的，不涉及snat地址转换，就在根源上避免了地址转换后导致五元组相同从而命中发生SYN返回ACK的条件，但是阿里云ACK集群无法在现有集群更改网络模式，无法直接从flannel调整成terway，只能重新创建集群，所以实际操作难度比较大。

方案二（次之）：将lb后面的pod的网络模式改成hostnetwork，不走nodeport，此方案也是避免了经过POD的报文在node节点地址转换导致5元组相同。

方案三：流量扩展策略使用cluster及增加前后pod数量，降低频率，对集群运维最友好，（实测从千分之一降低到十万分之一），但是只是降低概率并不能完全避免问题。

方案四：开启服务端Time-Wait快速功能，也就是在内核中同时启用 net.ipv4.tcp_timestamps 和net.ipv4.tcp_tw_recycle，使TimeWait状态的连接在POD中快速消失，也可以避免此问题。但是在Linux在4.12版本中取消net.ipv4.tcp_tw_recycle 参数配置，无法在开启TimeWait快速回收。