下午调试crawlermanager时，成同学反映：client发送的command包,有些没有收到响应。但是查我这边的日志显示是已经发送响应包了的。
不放心，就使用tcpdump抓了一下包，然后使用wireshark进行分析，成功定位了问题。
（1）运行tcpdump:
tcpdump -s 0 -c 100 dst host 109.119.20.82 -w ./target.cap
相关解释：
(1)-s 0 : 抓取数据包时默认抓取长度为68字节。加上-S 0 后可以抓到完整的数据包
(2)-c 100 : 只抓取100个数据包
(3)dst host 109.119.20.82 : 只抓取发送到109.119.20.82上的包
(4)-w ./target.cap : 保存成cap文件，方便用ethereal(即wireshark)分析
更多参见：http://www.cnblogs.com/ggjucheng/archive/2012/01/14/2322659.html
（2）使用wireshark打开target.cap：
然后逐个包分析。
终于，在一个包中发现如下情况：
按照我们规定的通信协议：头四个字节 00 00 00 2d表示该包body的长度，但实际抱得长度远远超出了该值！从内容看，是将多个包的内容合并到一个包一起发送了！
这就是tcp协议中经典的“粘包”问题，本来客户端是已经处理了该问题，但由于实现的bug，导致客户端在处理完第一个包后就丢弃了其他内容，于是客户端就出现了：“丢失响应包”的情况了。