本文主要是介绍被经验蒙蔽——wireshark抓包问题,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
昨天遇到一个网络事情,耗费了不小于4小时的时间才清楚。客观上没有任何问题,问题就在自己的主观上认为应该怎样怎样。两点感触:
1、一个问题如果纠结很长时间,自己尝试了能想到的所有方法都没能找到答案的话,换个思路重新审视问题应该就离真相不远了。如何换思路呢,自己单独继续处理多半无法换思路,找同事商量一下是个不错的选择。同事是否了解业务没有关系,不了解也同样能帮助你换思路。
2、千万不要以为自己熟悉的环节肯定不会出问题,往往是这些地方迷惑你。每一个环节的肯定结论你都应该保持一个怀疑的态度,支持你肯定结论的证据是真的吗?
问题描述:
客户端通过tcp发送一段数据给服务端,我发现服务器接收到的数据比发送端多一个字节,每次都在数据的固定位置多一个字节。如图1所示,wireshark抓包显示的业务层(TCP下一层的RTMP协议数据)数据长度为204bytes。而服务端接收到的程序为205bytes,尝试了很多次,发现都是在固定的位置多一个字节0xc3,如图2所示。
在接收端抓包用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。
下面这一段是我的猜测,将来如果我研究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是如何说的吧。
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的公众号一片大好,只有我们才知道真相。可叹可叹。
这篇关于被经验蒙蔽——wireshark抓包问题的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!