从最近三个实际问题来看tcpdump抓包
在实际开发中，我们经常会遇到一些疑难问题。以网络的客户端和服务端为例，经常出现客户端和服务端的现象矛盾，导致僵持不下，怎么确认和处理这类问题呢？
之前碰到过很多类似问题，最后直接用tcpdump抓包解决。下面仅来说说最近工作中碰到的三个实际问题(截图数据已经脱敏)。
场景一： 客户端A通过https API调用服务端B
服务端B说: 我收到了你的请求，但你没有传file字段
客户端A说：我明明传了file字段啊
服务端B说：你没有传file字段，我的代码解析不出file字段
客户端A说：这是我的log, 里面明明传了file字段啊
服务端B说：你自己检查一下吧，别人调用我一直没问题
僵持.......
场景二： 客户端A调用服务端B
服务端B说: 我没有收到你的请求
客户端A说：我发了请求啊
服务端B说：你发错IP了吧？是环境串扰了吗？
客户端A说：我调用的是正确的环境IP啊
服务端B说：不会啊，我的log没有看到请求
僵持......
场景三：客户端A调用服务端B
服务端B说: 我没有收到你的请求
客户端A说：我发了请求啊
服务端B说：我没有收到请求，log里面没有记录
客户端A说：我发了啊，返回log里面都有记录
服务端B说：不会，要不你再试一下
客户端A说：我重新发了请求，你收到没？
服务端B说：没有收到，我们服务很稳定呢
僵持......
在实际开发中，这种事情太多了，现象只是表象，还可能是假象，log也不一定可靠。
针对问题一：
由于是https API接口，如果直接tcpdump抓包，没法看到明文内容，可以向www.baidu.com发起http请求，同时用tcpdump抓包，从而证明客户端有传递file参数:
最后，查到的问题是，服务端开发同学给的文档有问题，导致file字段在json中的层级不对，客户端A调整后，就OK了。
针对问题二：
直接tcpdump抓包，可以看到客户端A确实有发请求：
最后发现，是服务端B漏了一个配置，导致在最开始入口处，服务端B就出错了，所以服务端B需要改。
现在看来，当初服务端B说没有收到请求，这只是现象，不一定可靠。
针对问题三：
直接tcpdump抓包， 可以看到服务端B是有返回信息的：
最后发现，是服务端B增加了一条规则，导致出错，所以服务端B需要修改。
现在看来，当初服务端B一口咬定没有收到请求，这只是现象，不一定可靠。
tcpdump抓包，超越了应用层的语言、框架、序列化协议和log, 所以它是靠谱且有说服力的。而log的说服力，就没那么强了，所以，很多时候双方各执一词。
tcpdump的功能很强大，直接man tcpdump就能详细查到它的用法。除了tcpdump, 还有一些其它的抓包工具，也可以在不同场景结合使用。
OK, 本文先说到这里，tcpdump用起来。