昨天遇到一个网络事情，耗费了不小于4小时的时间才清楚。客观上没有任何问题，问题就在自己的主观上认为应该怎样怎样。两点感触：
1、一个问题如果纠结很长时间，自己尝试了能想到的所有方法都没能找到答案的话，换个思路重新审视问题应该就离真相不远了。如何换思路呢，自己单独继续处理多半无法换思路，找同事商量一下是个不错的选择。同事是否了解业务没有关系，不了解也同样能帮助你换思路。
2、千万不要以为自己熟悉的环节肯定不会出问题，往往是这些地方迷惑你。每一个环节的肯定结论你都应该保持一个怀疑的态度，支持你肯定结论的证据是真的吗？
问题描述：
客户端通过tcp发送一段数据给服务端，我发现服务器接收到的数据比发送端多一个字节，每次都在数据的固定位置多一个字节。如图1所示，wireshark抓包显示的业务层（TCP下一层的RTMP协议数据）数据长度为204bytes。而服务端接收到的程序为205bytes，尝试了很多次，发现都是在固定的位置多一个字节0xc3，如图2所示。
图1-发送端-client-rtmp-connect-vlc-2.2.8/vlc-3.0.4
图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。
图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是如何说的吧。
图4-rtmp_specification_1.0.pdf-[Page 30]
Property并没有名字的意思，所以vlc发送的“audio Codecs”也不能说是错误，只能说rtmp开源部分的程序员恶搞，不能让你们使用的太容易了。
其他
混迹tcp/ip多年，wireshark和tcpdump说每天都用有些夸张，但平均每天打开两次的概率绝对是有的。也正是这种不知道哪来的迷之自信让我纠结了那么长的时间。每一款软件都包含非常多的功能，我们使用的只是很少的一部分，可怕的是你只使用这一下部分，哪怕你用十年二十年，进步还是很小的。
要保持对技术对未知的渴望。多看书多交流，不要做井底之蛙，分享才能更快的进步。你所认为有技术含量的东西也许真的不值一提。
