1目录：1tcp out-of-order（tcp 有问题）2tcp segment of a reassembled PDU3Tcp previous segment lost（tcp 先前的分片丢失）4Tcp acked lost segment（ tcp 应答丢失）5Tcp window update（tcp 窗口更新）6Tcp dup ack（tcp 重复应答）7Tcp keep alive（tcp 保持活动）8Tcp retransmission（tcp 重传）1. tcp out-of-order（tcp 有问题）解答：1）、 应该有很多原因。但是多半是网络拥塞，导致顺序包抵达时间不同，延时太长，或者包丢失，需要重新组合数据单元 因为他们可能是通过不同的路径到达你电脑上面的。2）、 CRM IT 同仁上礼拜来跟我反应一个问题，由他们客服系统藉由邮件主机要寄送给客户的信件，常常会有寄送失败的问题，查看了一下 Log，发现正常的信件在主机接收 DATA 完成后会记录收到的邮件大小，然后开始进行后续寄送出去的处理，但这些有问题的寄送，都会发生 DATA 没有传送完，Server 就记录已读取到 EOF，然后结束连线，也因此这封信就不算顺利的送到 Server 上来。初步看了一下排除是 Timeout 问题，因为连线断的时间都还未达设定的连线 Timeout 时间，由于 CRM 系统是外面厂商写的，为了厘清问题我只好抓封包来看是不是用户端送出来结束传送的指令的。抓了一下结果如下：整封邮件的传送过程，包含了大量的 TCP Retransmission 或是 Segment Lost，到后来还有跑出 TCP Out-Of-Order，看起来是网路的问题，网路上对于 TCP Out-Of-Order 的建议是说，有些 Packet 可能 Lost，所以重新传送造成，2另一个可能是因为 Client 到 Server 间有两条网路路径，像是 Load Balance 之类的架构，因此若两个封包走不同路径，晚送的封包却比早送的到达，就会发生 Out-Of-Order。因此在断定有可能是网路造成，加上 CRM 系统上的网卡同事是把两张做成一张 Virtual，再请他拿掉 Bonding 只用单一张跑以后，问题就不存在了，观察流量还跑的比原本两张合起来的 Virtual 单张跑的高，所以 M$ 在 Bonding 网卡上是不是还有什么需要调整的就不得而之了，至少找出造成大量寄送失败的原因就好。2. tcp segment of a reassembled PDU解答：1）在连个连接建立的时候，SYN 包里面会把彼此 TCP 最大的报文段长度，在局域网内一般都是 1460. 如果发送的包比最大的报文段长度长的话就要分片了，被分片出来的包，就会被标记了“TCP segment of a reassembled PDU”，可以参考下图，看一下，被标记了的包的SEQ 和 ACK 都和原来的包一致：2）上周在公司里遇到一个问题，用 wireshark 抓系统给网管上报的数据发现里面有好多报文被标识为“TCP segment of a reassembled PDU”，并且每一段报文都是 180Byte，当时看到这样的标识，觉得是 IP 报文分片，以为系统的接口 MTU 值为设置小了，通过命令查询发现是1500，没有被重设过，当时有点想不通。3回来查了一下，发现自己的理解是错的，“TCP segment of a reassembled PDU”指的不是IP 层的分片，IP 分片在 wireshark 里用“Fragmented IP protocol”来标识。详细查了一下，发现“TCP segment of a reassembled PDU”指 TCP 层收到上层大块报文后分解成段后发出去。于是有个疑问，TCP 层完全可以把大段报文丢给 IP 层，让 IP 层完成分段，为什么要在 TCP 层分呢？ 其实这个是由 TCP 的 MSS(Maximum Segment Size，最大报文段长度)决定的，TCP 在发起连接的第一个报文的 TCP 头里通过 MSS 这个可选项告知对方本端能够接收的最大报文（当然，这个大小是 TCP 净荷的大小），以太网上这个值一般设置成 1460，因为 1460Byte 净荷+20Byte TCP 头+20Byte IP 头 1500 字节，正好符合链路层最大报文的要求。至于收到一个报文后如何确定它是一个TCP segment？如果有几个报文的 ACK 序号都一样，并且这些报文的 Sequence Number 都不一样，并且后一个 Sequence Number 为前一个 Sequence Number 加上前一个报文大小再加上 1 的话，肯定是 TCP segment 了，对于没有 ACK标志时，则无法判断。既然收到的 TCP 报文都是 180Byte 的 segment，那么应该是协商的时候 PC 端告知了 MSS为 180Byte，至于为什么这样，只能等抓包后确认是 MSS 的问题再排查了。另外，有一种情况也可能导致这个问题：被测系统因为 MTU 为 220Byte 而设置 MSS 为 180Byte，但是这种情况现在可以排除，因为前面讲过，已经查询过 MTU 值为 1500。3. Tcp previous segment lost（tcp 先前的分片丢失）解答：（1） 、 “TCP Previous segment lost” errors are not “fatal” errors. They simply indicate that the sequence number in the arriving packet is higher than the next-expected sequence number, indicating that at least one segment was dropped/lost. The receiving station remedies this situation by sending duplicate ACKs for each additional packet it receives until the sender retransmits the missing packet(s). 4TCP is designed to recover from this situation, which is why the image is downloaded correctly despite having a (briefly) missing packet.If you are getting a large number of lost packets, then there is likely a communication problem between the sender and receiver. A common cause of this is un-matched duplex settings between the PC and the switch. We (our lab) recently upgraded to Ethereal 0.10.14 with WinPCap 3.1. If I remember correctly, we had previously been using 0.10.2 with WinPCap 3.0. However, since the upgrade we have been noticing several issues.The first issue is with TCP Previous segment lost and TCP CHECKSUM INCORRECT messages appearing in the Packet Listing window. We do not remember seeing these in the previous version of Ethereal, or at least not nearly as many as we are seeing now. For example, one task for the student instructional part of the lab involves visiting a website containing two images and observing the network activity. After the two GET requests are sent for the images, it is not uncommon for one image to be returned with a typical 200 OK response packet, but the response packet for the other image will be displayed as TCP Previous segment lost. However, both images are downloaded and displayed perfectly fine in the browser. I would think that the segment lost error would mean the object wasnt returned correctly and shouldnt be able to be displayed, but apparently that is not the case. (The cache had been cleared when this was performed, so it was not defaulting to a local copy of the image.) Another problem weve been noticing is that some packets simply arent displayed in the Packet Listing window, even when they are obviously received. Using the same example as above, after the two GET requests are sent for the images, it is not uncommon for one image to be returned with a typical 200 OK response, but the other response will not appear. Yet both images are successfully displayed in the browser. Is this a problem with Ethereal not detecting the packets? Im not sure how typical this is, but we seem to be experiencing these issues often with 0.10.14 while we never did with 0.10.2. Could it also be an issue with WinPCap, and not necessarily Ethereal? Im just trying to find some answer