TCP代码含义.docxVIP

11.?? 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，所以重新传送造成，另一个可能是因为 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，没有被重设过，当时有点想不通。回来查了一下，发现自己的理解是错的，“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