背景：一个短信服务，维护一个测试桩属于服务端，正常客户端发来了一个请求，服务端应该立即响应这个请求，但是实际是等待了2分钟，尝试 服务端第二次在发送重复请求，客户端就能马上收到响应，排查原因 原因是：由于服务端头部长度发错了，协议中提现指明需要30的字节长度，服务端给的确是39，导致第一次不成功，第二次在发送就成功了 修正服务端给定的客户端的字节数长度，请求与响应正常。通过wiresharek网络抓包分析解包查看错误
分析过程：
1.过滤数据包
因为我知道客户端连接服务端和服务端向客户端发送内容，都是通过端口7890进行过滤，所以我们通过7890就能进行过滤了，比如：
tcp.srcport ==7890 or tcp.dstport==7890
注：服务端端口为 7890 客户端端口为50280
下图就显示了过滤后的内容，不过滤会有很多不属于本次包的数据
图1
2.分析包
三次握手包，在转载文章中有介绍，后续还会讲述三次握手和四次挥手， 在 其他篇中介绍，现在我们讲解图1，32----40序列号的数据包,这一块就是客户端传输内容到服务端，服务端返回内容给客户端，数据交互的过程
32号包： 客户端请求服务端，且包的长度为39，src port:资源端口 Dst port：目标端口，能确认这个包就是从客户端请求到服务端（7890）
35号数据包：客户端回应服务端请求，且长度为30，回应的包的协议是TCP，已经能看出一些问题
37号包：客户端回应了，也是使用的TCP协议，因为应用回应的包是CMPP类型
38号包：服务端在次发送请求包，cmpp协议
39号包，客户端收到了请求，回应服务端使用的cmpp协议
通过上述查看包的协议，其实我们已经大体能定位出问题了
1.在35号包发送了请求，而服务端并没有使用cmpp协议进行回应，而是使用了最底层的TCP协议回应，说明这里与客户端协议上有些问题，不能使用cmpp协议进行传输，而是在第二次服务端在次发送请求时，有才发送了cmpp协议请求 ，所以问题很明显直接定位35号包，查看35号数据包的内容，点击35号包，选择追踪TCP流
按照我们的传输协议，前面4个字段就是“0x00, 0x00, 0x00, 0x27” 表示传输的字节长度，客户端长度正常，换算服务端就不正确，服务端长度0x27=39,明明长度是30（图片上35号包中的len=30就是表示长度是30）为什么会是39
在代码中查看把连接的长度写成39了，改为30发送就正确了
思考1：为什么服务端在发次请求，客户端能接收到数据，
猜测是这样：第一次需要30的字节长度，但是给了39，数据部分被截取了，放到缓存中，第二次在请求一个39，数据有是一部分，然后就组合成了一个完整包，以cmpp协议传输 给了客户端了
思考2：第一次服务端回应请求，为什么是使用的TCP协议
猜测：cmpp底层还是使用的TCP协议， 当服务端或者客户端没有按照规定的cmpp协议传输，默认还是会显示发送的过程，因为服务端确实发送了，但是在应用层的客户端中没有收到，所以使用了TCP协议，进行发送包，客户端在以TCP协议回应我，当我第二次能够用CMPP协议传输了，也就收到了客户端的cmpp协议的包，如果服务端没有进行回应，就可能出现丢包，那么客户端可能还会在重传，所以其实服务第一次都是有传送，只是没有使用cmpp协议