被经验蒙蔽——wireshark抓包问题

淩亂°似流年 2022-04-04 05:57 181阅读 0赞

昨天遇到一个网络事情，耗费了不小于4小时的时间才清楚。客观上没有任何问题，问题就在自己的主观上认为应该怎样怎样。两点感触：

1、一个问题如果纠结很长时间，自己尝试了能想到的所有方法都没能找到答案的话，换个思路重新审视问题应该就离真相不远了。如何换思路呢，自己单独继续处理多半无法换思路，找同事商量一下是个不错的选择。同事是否了解业务没有关系，不了解也同样能帮助你换思路。

2、千万不要以为自己熟悉的环节肯定不会出问题，往往是这些地方迷惑你。每一个环节的肯定结论你都应该保持一个怀疑的态度，支持你肯定结论的证据是真的吗？

### 问题描述： ###

客户端通过tcp发送一段数据给服务端，我发现服务器接收到的数据比发送端多一个字节，每次都在数据的固定位置多一个字节。如图1所示，wireshark抓包显示的业务层（TCP下一层的RTMP协议数据）数据长度为204bytes。而服务端接收到的程序为205bytes，尝试了很多次，发现都是在固定的位置多一个字节0xc3，如图2所示。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xhbmdxdW54aWFuZmVuZw_size_16_color_FFFFFF_t_70][] 图1-发送端-client-rtmp-connect-vlc-2.2.8/vlc-3.0.4

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xhbmdxdW54aWFuZmVuZw_size_16_color_FFFFFF_t_70 1][] 图2-接收端-server-rtmp-自己程序

在接收端抓包用wireshark分析发现和发送端显示的一样是204bytes，加断点使用netstat去查看tcp接收缓冲区数据长度就为205bytes。

接收端和发送端的数据长度就是对不上。这一步是双方数据交互的第3步，前两步都是正常的：

第1步：client发送给server 1537bytes，server正常收到；

第2步：server发送给client 3073bytes，client一个正常收到，不然不会有第3步的存在。

第3步：client发送给server 204bytes，server收到205bytes，多了1byte。

我能使用的办法和手段都使用上分析了不少于4个小时的时间，依然没有找到答案。做了5年多的网络协议相关工作，对自己的每一步操作都充满信息，对自己的程序也是充满信息，绝对不会有问题。收到的肯定是205 bytes，发送的肯定是204 bytes，这么简单的协议和逻辑wireshark绝对不会出错！它们确实都没有出现问题，出现问题的是我。我和同事沟通了一下，又和设备厂商研发人员进行了沟通（因为我已经开始怀疑底层除了问题，现在想想多么可笑），查看了adobe的rtmp官方文档。***最后按字节重新比较tcp负载发现的问题真相。***

### 原因 ###

我再贴上一个图3，注意红色标记，和图1比较，这就是真相。发送端实际发送了205bytes，而我之前根据wirekshark对rtmp层的显示认为发送端只发送了204bytes。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xhbmdxdW54aWFuZmVuZw_size_16_color_FFFFFF_t_70 2][] 图3-发送端-client-rtmp-connect-vlc-2.2.8/vlc-3.0.4-tcppayload

下面这一段是我的猜测，将来如果我研究libpcap和vlc源码的时候，如果我找到原因，我会再写一篇说明，如果您对此了解也欢迎留言。wirekshark为什么要这么做呢？因为vlc发送的协议不严谨，你能搜索到的rtmp技术文章都说虽然adobe推出了rtmp，现在rtmp在世界上也在大范围使用，但是rtmp并不严谨，adobe对rtmp也不严谨，总会出现各种问题。在connect协议音频Object中，vlc发送的是“audio Codecs”，视频Object发送的是“videoCodecs”，看到问题了吗？“audio”和“Codecs”字符串中间又一个空格，这个空格就是vlc偏要在它们俩中间加入的那个“0xc3”字节。视频Object就没有这个问题。图4是rtmp的官方文档截图，看看adobe是如何说的吧。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xhbmdxdW54aWFuZmVuZw_size_16_color_FFFFFF_t_70 3][] 图4-rtmp\_specification\_1.0.pdf-\[Page 30\]

Property并没有名字的意思，所以vlc发送的“audio Codecs”也不能说是错误，只能说rtmp开源部分的程序员恶搞，不能让你们使用的太容易了。

### 其他 ###

混迹tcp/ip多年，wireshark和tcpdump说每天都用有些夸张，但平均每天打开两次的概率绝对是有的。也正是这种不知道哪来的迷之自信让我纠结了那么长的时间。每一款软件都包含非常多的功能，我们使用的只是很少的一部分，可怕的是你只使用这一下部分，哪怕你用十年二十年，进步还是很小的。

要保持对技术对未知的渴望。多看书多交流，不要做井底之蛙，分享才能更快的进步。你所认为有技术含量的东西也许真的不值一提。

### 题外话 ###

今天听到以前在T公司现在在Y公司的Z同事说有一个T公司的高层G要去Y公司了，可能下个月就入职了。13年刚入T公司时，G就是我们嵌入式大部门的经理，后来我们大嵌入式各种拆分，最多分为4个嵌入式部门，13年时候的D组长也晋升为D经理，G进入整个研发的高层。这些年哪个部门人员变动较大，G都会作为救火队员入场，最为经理接管这个部门，这个工作其他人真的干不来。因为所有的老员工曾经都是G的手下，无论现在是主观还是经理，还是普通员工。5月份D经理离职，我们部门拆分，我们并入现在G接管的那个部门，11月初我离开T公司。仅仅过了1个月有余，今天早上就听Z同事说他已经看到了邮件。

G在T公司11年有余，可叹可叹。T的公众号一片大好，只有我们才知道真相。可叹可叹。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xhbmdxdW54aWFuZmVuZw_size_16_color_FFFFFF_t_70]: /images/20220404/8629568a2b9846d3a691420ce655c79e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xhbmdxdW54aWFuZmVuZw_size_16_color_FFFFFF_t_70 1]: /images/20220404/9e70cd5a83cf47e09019153e613e9000.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xhbmdxdW54aWFuZmVuZw_size_16_color_FFFFFF_t_70 2]: /images/20220404/6f7c70373be243bcadfee0a95d5fe562.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xhbmdxdW54aWFuZmVuZw_size_16_color_FFFFFF_t_70 3]: /images/20220404/0f1fc422136348769a9cace73b055531.png