8.经过不断的测试，二分法查询临界点，找到了1380是可处理长度临界点。发送1380的纯数据是正常的，发送1381的纯数据就不正常了。抓包的目标地址是12.23.45.67，简称MA，现在不确定的是MA是什么，是我方的设备，还是它方的设备，如果是我方的设备，排错继续，如果不是，排错终止。总之，1380这个临界点是一个疑点，常规来讲是不正常的，但也不能排除有这么限制的正常理由。无线链路没有问题是因为无线链路的MTU比较小，最大纯数据长度1360小与临界值1380。
9.补充测试，模拟问题机器，将其本机的MTU改为1380+20+20=1420，传输也是正常的，然而改为1421，就不行了。(注意，只有本机的MTU修改才有效，因为只有TCP数据始发设备，MSS才与MTU关联)
.....
1x.第9步后面的排查我没有参与，但是最终，我方设备确实没有收到客户端SSL握手过程传出的证书，说明确实是中间设备阻止了这个”大包“的传输，至于它到底是谁，到底怎么回事，与我们无关了，但对于我个人而言，对其还是比较感兴趣的。
对于该次排错的总结
这是一个典型的网络问题，涉及到IP和TCP，细节不多，但足够典型。其实这个问题与最终的业务逻辑没有关系，但是事实往往是，只有在业务逻辑无法正常时，这类底层的问题才会暴露，这是TCP/IP协议栈的性质所致。此类问题的排查要点在于，你要用最快的速度把它与高层协议隔离开来，并且不能陷入任何细节。
TCP细节：为何不必考虑TCP细节？这类场景既不特殊，又不复杂，如果陷入TCP细节的话，会掩盖或者忽略大量横向的问题，比如你会死盯着TCP的重传机制做细致研究，或者细致地研究RTT计算方法，最终也不一定能得到什么结论。换句话说，你一定要相信TCP是正常的。
服务程序细节：这个也是要隔离的。因为服务器并没有真的开始服务，且故障是100%重现的，因此可以确定这不是什么复杂的问题所导致，真正复杂的问题往往不是100%重现，即便是你挖掘出其重现规律，也够你喝一壶的。
TCP问题和IP问题的相异：它们虽然都是网络协议栈的一员，但是使用方式却大不相同。实际上TCP提高了使用者的门槛，一般而言，TCP是让程序去使用的，因此你要想TCP跑起来，起码要理解其大致原理，或者说懂socket机制，如果你上网浏览网页，虽然也是用的TCP，它确实跑起来了，但是使用者不是你，而是你的浏览器。IP就不同，IP的配置者可以是小白，并且随意配置都不会报错。再往下，布线问题，拓扑问题，几乎没有什么门槛，但是却更加容易出错。因此首先要排除的就是这类问题。
防火墙策略或者程序BUG：实际上，第一步就需要询问管理员，是不是防火墙上特殊的策略所致，然而对于无法得到这个消息的时候，你就不能从这儿开始了。接下来，与之平等的是怀疑程序的处理BUG，此时，隔离出原有的业务逻辑细节是重要的，现象是大包无法收到ACK，此时就要忽略掉这个大包的内容以及其上下文，直接发送一个任意大包进行测试。
因此，这类问题的排查是一个逐步隔离的过程，相对四年前的那次NAT bug的排查，这个故障在技术上要更容易些，所有的复杂性和时间的耽搁全部在人员协调交流上，人员之间信息的误传或者漏传也是一个难点，四年前的那个NAT bug，是一个技术上更加深入的问题，涉及到了内核协议栈代码级别，同时在此之前，我还要找到这个点，然而它的容易点在于，这个问题只涉及到我一个人，而且也是100%重现。