端口过滤关键在于区分“经过该端口”（port 80）与“发往该端口”（dst port 80）：前者匹配双向所有含80端口的包（含响应、RST等），后者才精准对应客户端HTTP请求；调试客户端行为应优先用dst port 80，分析服务端响应用src port 80，抓完整连接需结合TCP标志位过滤。
直接说结论：端口过滤最常用也最容易出错，关键不是记语法，而是分清“经过该端口”和“发往/来自该端口”的语义差异。
port 80 和 dst port 80 的区别必须搞清
很多人以为 port 80 就是“HTTP 请求”，其实它匹配所有源或目的端口为 80 的包（包括响应、重传、RST 等）。而 dst port 80 才真正对应“客户端发给 Web 服务器的请求”。反过来，src port 80 匹配的是服务器返回的响应包。
常见错误现象：
用 port 80 抓包时看到大量重复 ACK 或 FIN，误以为是攻击流量；实际只是把双向通信全抓了。
使用建议：
• 调试客户端行为 → 优先用 dst port 80
• 分析服务端响应异常 → 用 src port 80
• 查连接建立全过程（SYN/SYN-ACK/ACK）→ 用 port 80，但加 tcp[tcpflags] & (tcp-syn|tcp-ack) != 0 过滤标志位更准
抓 HTTPS 流量时别漏掉 -nn 和 -s0
HTTPS 流量默认走 443 端口，但光写 port 443 往往看不到有效载荷——因为默认截断长度是 68 字节，TLS 握手的 ClientHello 通常超长；同时不加 -nn 会导致 DNS 查询阻塞输出，尤其在高并发场景下延迟明显。
性能影响：
• 不加 -s0：可能丢失 SNI 域名、ALPN 协议标识等关键字段
• 不加 -nn：每条包都尝试反解 IP，CPU 占用飙升，且输出时间戳严重漂移
推荐组合：
• 实时观察 TLS 握手：tcpdump -i eth0 -nn -s0 -A 'port 443 and tcp[tcpflags] & tcp-syn != 0'
• 抓完整 TLS 流量存文件：tcpdump -i eth0 -nn -s0 -w https.pcap port 443
按 IP + 端口组合过滤时注意 shell 转义
BPF 表达式里的括号、逻辑运算符在 shell 中会被提前解析，比如 src host 192.168.1.5 and dst port 3306 如果不加引号，shell 可能把它拆成多个命令执行，报错 tcpdump: syntax error。
容易踩的坑：
• 单引号最安全：'src host 192.168.1.5 and dst port 3306'
• 双引号在变量替换时可用，但内部有 $ 需转义
• 反斜杠转义括号（如 \(）易出错，不推荐
典型场景：
• 查某台 DB 客户端连错端口：tcpdump -i any -nn 'src host 10.0.2.15 and not dst port 3306'
• 排除监控探针干扰：tcpdump -i eth0 -nn 'not src host 172.16.0.100 and port 9100'
抓包后想快速定位关键词？别依赖实时 grep
直接 tcpdump ... | grep "POST" 看似方便，但会丢包：tcpdump 输出是行缓冲（尤其加了 -l），而管道传输存在延迟和截断风险，HTTP 方法头可能被切到两行，grep 漏匹配。
更可靠的做法：
• 先保存 pcap：tcpdump -i eth0 -nn -s0 -w tmp.pcap port 80
• 再用 tcpdump -r tmp.pcap -A | grep -C2 "POST"（-A 强制 ASCII 解码）
• 或用 tshark -r tmp.pcap -Y "http.request.method == POST" -Tfields -e ip.src -e http.host 提取结构化字段
关键点：
• -A 是 tcpdump 里唯一能做简单文本提取的选项，但它不识别 HTTP 协议层，只对 payload 做 raw dump
• 真正要分析 HTTP 内容，pcap 文件 + tshark/wireshark 是不可替代的
