redis协议传输延迟不能靠ping或redis-cli --latency准确定位，因ping走icmp、--latency仅测往返时间，真实瓶颈在tcp层；必须用tcpdump -i any -nn -s0 tcp port 6379抓包，结合wireshark过滤tcp.len==12或tcp.analysis.retransmission，并配合ss -i查rtt/rto/retrans字段定位重传、ack丢弃等根因。
Redis协议传输延迟不能靠ping或redis-cli --latency准确定位，因为前者走ICMP、后者只测客户端到服务端的往返时间，而真实瓶颈往往藏在TCP层——重传、ACK丢弃、窗口挤压都可能让一个12字节的PING包卡住80ms。必须用tcpdump抓到原始TCP流，才能看清问题出在哪一环。
只抓6379端口的TCP包，避免噪音干扰
Redis通信固定走TCP 6379端口（集群模式下Gossip心跳、主从复制、客户端请求全复用该端口），抓其他端口或全量流量只会淹没关键信号。
- 必须加
-nn：禁用DNS和端口名解析，否则tcpdump会卡在DNS查询上，漏掉关键包 - 必须加
-s0：默认只抓前96字节，而Redis协议虽简单，但大Key响应或带认证的AUTH命令可能超长，截断后看不到完整payload - 推荐命令：
tcpdump -i any -nn -s0 tcp port 6379 -w redis-delay.pcap，-i any确保不漏回环/多网卡流量
过滤出Redis协议的关键数据包
Redis协议本身是纯文本，但TCP层不认语义；真正能快速定位协议行为的，是固定长度的控制帧和TCP标志位。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
PING/PONG在集群Gossip中恒为12字节，Wireshark里用tcp.len == 12过滤即可聚焦心跳延迟 - 客户端请求看
Flags [P.]（PUSH+ACK），服务端响应看Flags [.]（纯ACK）或Flags [P.]带实际数据 - 若怀疑丢包，直接过滤
tcp.analysis.retransmission || tcp.analysis.duplicate_ack，重传包出现即说明链路已不稳定
结合ss -i看实时TCP连接状态
tcpdump是离线证据，ss -i是实时脉搏——二者配合才能判断是偶发抖动还是持续恶化。
- 执行
ss -i 'sport = :6379 or dport = :6379'，重点盯三个字段：rtt（当前估算RTT）、rto（重传超时值）、retrans（已发生的重传次数） - 如果
retrans > 0且rto跳变到200ms以上，基本可断定中间设备（如云厂商SLB、防火墙）在主动回收空闲连接或丢弃ACK -
rcv_space长期接近0，说明接收缓冲区被占满，不是Redis慢，而是应用层没及时读取socket，常见于客户端阻塞或GC停顿
别只在服务端抓包，客户端侧才是真相入口
服务端抓包看到的是“收到请求后多久发响应”，客户端抓包看到的是“发出请求后多久收响应”——两者差值就是纯网络耗时，这才是延迟归因的黄金标准。
- 在应用服务器（而非Redis机器）上运行
tcpdump，目标IP填Redis服务端地址，才能捕捉到真实请求发起时刻 - 如果客户端抓包显示请求发出后200ms才收到第一个ACK，但服务端抓包显示自己1ms内就发了响应，那问题100%在返回路径上
- 云环境尤其要注意：安全组ACL可能放行入向但限流出向，NAT网关会话老化导致ACK被丢，这类策略型丢包
ping完全测不出来
最常被忽略的一点：tcpdump抓到的只是现象，真正要解问题，得看retrans是否持续增长、rto是否异常拉长、以及重传间隔是否稳定在毫秒级——如果全是200ms整数倍的重传，基本就是中间设备在“定时清理”连接，这时候调Redis参数毫无意义，得找云厂商查网络策略。
