一、背景

看监控看多了之后，就容易对一些细小的指标感兴趣。这不，以下两张图片展示了一批功能不同的服务器，发生了tcp timeouts。

二、理论依据

• TCP超时（TCP timeouts）：

TCP超时是指在TCP连接建立或数据传输过程中，如果一方在规定的时间内没有收到对方的确认或其他响应，就会触发超时机制。
当TCP超时发生时，通常会重新发送之前未得到确认的数据包，以确保数据的可靠传输。

• TCP重传（TCP retransmissions）：

TCP重传是指在发送端未收到对端确认的情况下，会重新发送之前发送的数据包。
TCP重传通常会在TCP超时后触发，以确保数据的可靠传输。

• TCP中止（TCP abort）：

TCP中止是指在某些情况下终止TCP连接的过程。
TCP中止可能是由于超时次数达到上限、连接出现严重错误、或者用户主动关闭连接等原因引起的。

三、排查过程

3.1 使用tshark抓包

tshark -i eth0 -Y "tcp.analysis.retransmission" -T fields -e ip.src -e tcp.srcport -e ip.dst -e tcp.dstport -e tcp.flags.syn -e tcp.flags.ack -e tcp.seq -e tcp.ack

从上图可以看出，有一些22端口的流量。难道是有人探测？
安装fail2ban保护服务器。后来发现，tcp timeouts还是有。
于是在云主机的外网防火墙，封禁22端口。效果不错。

此时，tshark抓包遇到了另外两个问题。

3.2 问题一 内网调用网外网服务

这个问题是由于内网服务去调用外网服务，而外网服务已经不用了。所以存在有没有删除的代码逻辑还在调用旧接口。

通过使用conntrack命令拿到云主机上哪个ip地址在连接

使用脚本

#!/bin/bash

# Get all running container IDs
container_ids=$(docker ps -q)

for id in $container_ids
do
  # Get container name
  name=$(docker ps --format '{{.Names}}' -f id=$id)

  # Get container image
  image=$(docker ps --format '{{.Image}}' -f id=$id)

  # Get container IP
  ip=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' $id)

  echo "ID: $id"
  echo "Name: $name"
  echo "Image: $image"
  echo "IP: $ip"
  echo "-------------------------"
done

查看信息，最终锁定了容器名称，等待交付研发。

3.3 问题二 长连接服务始终有tcp retrans

这种情况，可能跟业务场景有关系。好多物联网设备，低功耗的，网络延迟会大一些等等造成。也不算啥问题了。

总结

• tcp的状态监测是评估业务运行状况重要的指标之一。
• 灵活运行tshark和conntrack可以辅助定位问题。
• 因为外网ssh 22端口密码探测导致的问题，可以使用开启防火墙拦截。