这是一个创建于 1412 天前的主题，其中的信息可能已经有所发展或是发生改变。
现象：访问 redis 超时。 客户端包在 1 楼。 服务端包在 2 楼。
客户端在容器里面，截图抓包是在容器所在的宿主机抓的包。 服务端 redis 部署在虚机里面。
有几个问题想不通：
-
客户端跟服务端抓包的 seq,ack 值不一样，但是应用层内容是一样的。
-
客户端发的 psh,ack 的包，到服务端 redis 那边就变成了 rst,ack 了。导致 redis 那边断开连接。
 | 1 yujianwjj OP 客户端 |
| 2 yujianwjj OP  客户端 |
| 3 yujianwjj OP fu'wu  服务端 |
 | 4 huangmingyou 2022-02-18 17:07:25 +08:00 这中间有别的网络设备修改了网络包？ |
 | 5 zhoudaiyu PRO 建议把 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 台，拿去生产环境下。如果不通，说明生产环境的网络有问题。 我曾经在这种环境下，也遇到过问题，最后分析出来，是某个网络安全硬件的某条规则有问题，把那条规则放行后，问题解决。 |
Select Language