现象:访问 redis 超时。 客户端包在 1 楼。 服务端包在 2 楼。
客户端在容器里面,截图抓包是在容器所在的宿主机抓的包。 服务端 redis 部署在虚机里面。
有几个问题想不通:
客户端跟服务端抓包的 seq,ack 值不一样,但是应用层内容是一样的。
客户端发的 psh,ack 的包,到服务端 redis 那边就变成了 rst,ack 了。导致 redis 那边断开连接。
1
yujianwjj OP 客户端
|
2
yujianwjj OP |
3
yujianwjj OP |
4
huangmingyou 2022-02-18 17:07:25 +08:00
这中间有别的网络设备修改了网络包?
|
5
zhoudaiyu 2022-02-18 19:03:00 +08:00
建议把 pcap 文件发出来让大家瞅瞅
|
6
Huelse 2022-02-18 23:50:09 +08:00
从这些看不出来什么问题,我遇到 tcp 连接问题大多是系统时间、防火墙、网卡问题等
|
7
documentzhangx66 2022-02-19 07:46:17 +08:00
建议排查方法:
1.找 3 台相同系统、环境、软件、安装方式,把防火墙都关掉。然后把两者单独接入到一个家用路由器环境下,断开该路由器上级的物理网络,保证硬件网络环境的单纯,来进行测试。 之所以要找 3 台,是因为我之前在这种环境下,遇到过一次,2 台能通,一台不通,后来发现是这台的硬件有问题。就像 intel 11 代 CPU 的 4k 普遍有雪花 bug 一样。 这个环境下,还有可能遇到防火墙问题,所以才建议把防火墙全关掉。测试通过后,再打开防火墙,如果打开防火墙后,不通了,说明防火墙规则没处理好。 这个环境下,还有一个问题,就是容器本身的问题。比如 VMware WorkStation Pro 某个版本,在 Windows Server 2008 r2 x64 sp1 、Winodws 10 x64 企业版 下面,某种情况下,会导致 UDP 回包发生端口更改。 2.第一步测试通过后,再把这 3 台,拿去生产环境下。如果不通,说明生产环境的网络有问题。 我曾经在这种环境下,也遇到过问题,最后分析出来,是某个网络安全硬件的某条规则有问题,把那条规则放行后,问题解决。 |