导致TCP协议联通性的两类问题汇总_百度文库

导致TCP协议联通性的两类问题汇总_百度文库
导致TCP联通性的两类问题汇总 手机无线网络环境比PC网络环境更复杂，因此也带来了一些特殊的网络问题。这些网络问题并非手机无线网独有，但是在手机无线网络中，由于有无线运营商这个环节，这个环节对互联网运营商是个黑盒，他们运维的一些特殊配置，更可能导致无线网络上的问题。这里主要汇总两类问题。 1：tcp连接无法正常建立 2：大数据传输不正常 这两类问题都不是普遍存在的，可能只存在某个运营商网络，或者某个省份的运营商。 首先来分析第一个问题。 Tcp连接无法建立，最直接的表现是app与server之间的tcp连接不能正常完成，导致用户无法正常连接到server上。这类问题处理起来的确棘手。涉及到的情况比较复杂，比如也许是用户当时的无线信号不稳定，也许是用户连接的wifi掉线了，也许某个运营商与server之间的网络就不通，等等类似问题。这类问题都有共通的几个特性：1，非大面积发生；2，比较难重现；3，用户现场比较难获取；4，用户配合定位问题难度搞；5，用户tcpdump抓包困难。 手机Qzone在运营过程中也遇到了以上问题，像信号不稳定，wifi不通这类问题比较好解决。联系用户，核实情况一般都可以解决。其中有一个隐藏比较深，是由于server内核参数设置不当引起的问题。无线环境下，有很大一部分原因是这个问题导致的。 做互联网server开发，为了支持高并发，server一般都会打开tcp_tw_reuse，tcp_tw_recycle。这两个选项都可以控制tcp快速回收。还有另一个设置 tcp_timestamp。这个设置往往被忽略了。如果tcp_tw_recycle,tcp_timestamp同时被设置，可能就会导致connect连接失败的问题。这里正确做法是关闭 tcp_timestamp。导致这个问题的原因是：某些运营商通过NAT方式组网，如果NAT网络中有台设备的时间戳有问题，就会导致其他机器都不能正常的connect上我们的server了。 现在分析下第二个问题。 第二个问题一般出现在app与server之间传输传输大数据，导致出现丢失数据问题。此类问题一般都是由MTU引起。这里特指PMTU，tcp传输路径上的MTU。因为两端的MTU在tcp三次握手的过程中已经协商好了，PMTU确无法协商。IP包头中有个DF标志，默认情况下是1，标识不允许IP包分片。如果有一个IP包在传输过程中经过一个路由器，这个路由器的MTU设置小于此IP包，此时候由于DF为1，路由器不做IP分片，而是直接丢弃此IP包，并返回一个ICMP报文。（现实中很多路由器设置了不返回ICMP报文，而是直接丢弃IP包）发送端无法感知IP是因为MTU问题被丢弃，还是其他原因未到达对端，对于发送端来说，就是这个IP包丢包，于是触发了tcp的超时重传。但是由于这个问题是由于路由器MTU导致的，重传也解决不了问题。这里解决问题有几个方法： 1：更改server的mtu，改到一个比较小的值。这个方案可行，但是会影响这台server上的所有网络数据的mtu。一般建议改到1400左右，太小可能会引起更多ip碎片。 2：程序中设置DF为0，允许路由器对IP包做分片。 关闭df的方法： int val = IP_PMTUDISC_DONT;

int ret = setsockopt(sock, IPPROTO_IP, IP_MTU_DISCOVER, &val, sizeof(val)); 打开df的方法： int val = IP_PMTUDISC_DO; int ret = setsockopt(sock, IPPROTO_IP, IP_MTU_DISCOVER, &val, sizeof(val)); 3：可以通过程序设置mss，间接控制每个IP包大小。好处是不用更改server的mtu，只影响本程序。用setsockopt, SOL_TCP, TCP_MAXSEG设置。 以上方法主要解决了下行不通，有时候app到server也遇到数据太大的问题。 在这方面，Qzone在实现的时候，在客户端预埋了一个逻辑，如果客户端在上行大数据不通的时候，可以在客户端设置mss大小。具体设置多大，可以通过配置来控制。