Monday, November 28, 2016

导致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大小。具体设置多大,可以通过配置来控制。

Thursday, November 3, 2016

DNS�NO�GLUE_flyfish_carol_新浪博客

DNS�NO�GLUE_flyfish_carol_新浪博客





DNS NO GLUE

 (2006-12-11 15:22:31)

DNS NO GLUE

Author: Hagen.GoO  转载请注明作者出处
MSN contact: wantm009@hotmail.com
Keyword: DNS Report,NameServer,NS RRs,NO-GLUE,

    DNS Report http://www.dnsreport.com/ 的在线工具在校验某域名配置时,parent nameservers 部分老是有 Glue at parent nameservers 即 NO GLUE 的警告。
    看了网页上的简短说明,也不是非常明白所谓的 NO GLUE 到底是什么概念。翻阅相关书籍,略有斩获,招贴备忘。
    我们知道,按照ICANN/IANA的协调:
        COM. NET. 2个域的 nameservers 是 a.gtld-servers.net. b.gtld-servers.net. 等 A-M 13台服务器。
        CN 和 COM.CN. 等中国国家的ccTLDs 的 nameservers 是 a.dns.cn. b.cns.cn. 等6台服务器。
    第一种情况:比如我们申请到域名 domain.com.,在域名配置的控制面板可以注册并添加多条 NS RRs,如 ns1.domain.com. ns2.domain.com.等。这些新添加的 NS RRs 在其 parent nameservers 将以如下的方式存在:
domain.com.       IN  NS    ns1.domain.com.
domain.com.       IN  NS    ns2.domain.com.
ns1.domain.com.   IN   A    xxx.xxx.xxx.xxx
ns2.domain.com.   IN   A    xxx.xxx.xxx.xxx
    即,我们可以使用类似这样的命令:
        nslookup -q=any ns1.domain.com. a.gtld-servers.net.
        nslookup -q=ns domain.com. a.gtld-servers.net.
    直接在 a.gtld-servers.net. 处查询(非递归)到 domain.com. 相关的 NS RRs 以及对应的IP地址,这种情况就是 GLUE 的。

    第二种情况:比如我们申请到域名 domain.com.,我们使用域名注册商提供的,且已经存在的 NS 来负责解析此域名,比如中国万网的 dns7.hichina.com. dns8.hichina.com.,这个时候在其 parent nameservers 将以如下的方式存在:
domain.com.       IN  NS    dns7.hichina.com.
domain.com.       IN  NS    dns8.hichina.com.
    由于这是2台已经注册过的 nameservers , 即还有:
dns7.hichina.com.    IN   A    xxx.xxx.xxx.xxx
dns8.hichina.com.    IN   A    xxx.xxx.xxx.xxx
    dns7.hichina.com. dns8.hichina.com.和 domain.com. 同属于一个 TLDs,所以我们在向 a.gtld-servers.net. 查询(非递归) domain.com. 相关 NS RRs以及对应IP地址时,a.gtld-servers.net. 都能给出正确应答,这种情况也是 GLUE 的。

    第三种情况:比如我们申请到中国国家域名 newdomain.cn.,我们使用域名注册商提供的 NS 来负责解析此域名,比如中国万网的 dns7.hichina.com. dns8.hichina.com.,这时 domain.cn.的相关NS在其 parent nameservers a.dns.cn中将以如下的方式存在:
newdomain.cn.       IN  NS    dns7.hichina.com.
newdomain.cn.       IN  NS    dns8.hichina.com.
    由于 dns7.hichina.com. dns8.hichina.com.和 newdomain.cn. 不是同属于一个 TLDs,所以我们在向 a.dns.cn. 查询(非递归) newdomain.cn. 相关 NS RRs以及对应IP地址时,a.dns.cn. 只都能给出 NS 记录,不能给出其对应 IP 地址,需要我们再另外一次的递归查询才能得到对应 IP 地址。这种情况就是 NO GLUE 的。

    另外还有一种特殊的情况,类似第二种情况,目标域名和 nameservers 的所属域名是同一个 TLDs 的,比如都是 COM. 的,但这几个 nameservers 没有在所属域名的 parent nameservers 中注册过,那么这种情况也应当是 NO GLUE 的。
   
    总结一句话,在同一个 TLDs 的 parent namservers 上直接可以查询到目标域名相关的 NS RRs 以及 NS 对应的 IP 地址的情况就是 GLUE ,否则就是 NO GLUE。虽然 NO GLUE 略微会造成解析上的延迟,但不是致命的问题。有条件的域名建议使用 GLUE 的 NS。
    另外: DNS Report 的工具在诊断 COM.CN.中国国家域名是否 GLUE 上有一点小小的问题,实用的时候,可以斟酌看待。