用户能ping通和tracert通网站，但打不开

浏览数：45 / 时间：2015年06月09日

问题描述：

最近更换升级了服务器后，一直有个问题，就是很多用户能ping通和tracert通我们的网站，但登陆的时候不正常，偶尔刷新能打开，很不正常。

抓包发现，用户过来的IP能到服务器，但服务器没有回复。

感谢黄总的分析！！！！

以下是从网上找的一些解决方法总结。

============================================================================================================================
原文：http://blog.csdn.net/gzh0222/article/details/8000508

针对有些用户能ping通我们的网站，但是连接时超时服务器没有任何响应，怀疑问题处在了了http的三次握手环节，这是决定通过抓包进行分析：

1、有问题机器的截图：

2、正常机器的截图：

3、发现问题

从抓包数据发现，web服务器对出问题机器和正常机器系统的tcp syn包都返回ACK包，但存在问题发出的tcp syn包有时候响应，有时候不响应。不响应时，终端与web服务器之间的tcp连接无法正常建立，导致页面不能打开。对比这两种数据包，就在时间戳上有差异，存在问题的机器发出的tcp syn包带有时间戳，因此怀疑时间戳问题导致的故障。

4、解决问题

既然怀疑是时间戳导致的，那我们就着手分析如果将出现问题的机器的时间戳去掉会不会解决问题。针对带有时间戳的tcp syn包不响应的问题，查阅了相关资料得知产生问题的原因是出问题系统中的注册表中有Tcp1323opts这个选项，会导致其在发包时加入时间戳，经过nat之后，如果前面相同的端口被使用过，且时间戳大于这个链接发出的syn中的时间戳，服务器上就会忽略掉这个syn，不返会syn-ack消息，表现为用户无法正常完成tcp3次握手，从而不能打开web页面。在业务闲时，如果用户nat的端口没有被使用过时，就可以正常打开；业务忙时，nat端口重复使用的频率高，很难分到没有被使用的端口，从而产生这种问题。

目前看有两种方法解决:

(1)    是在服务器上修改变量

首先我们先查看一下我们服务器net.ipv4.tcp_timestamps的默认值，如果该值为0测说名不是该问题导致，如果是1我们需要将该值设置为1。

查看默认值的方法：[root@localhost ~]# cat /proc/sys/net/ipv4/tcp_timestamps

修改该值的方法：vim /etc/sysctl.conf 添加 net.ipv4.tcp_timestamps=0

（2）修改客户端的注册表Tcp1323Opts设置为0。

备注：

Tcp1323Opts

说明：该参数控制 RFC 1323 时间戳与窗口缩放选项。默认情况下，启用时间戳与

窗口缩放，但是可以使用标志位进行控制。0 位控制窗口缩放，1 位控制时间戳。

值为0（禁用 RFC 1323 选项）

值为1（仅启用窗口缩放）

值为2（仅启用时间戳）

值为3（两个选项均启用）

net.ipv4.tcp_timestamps=0

说明：时间戳可以避免序列号的卷绕。一个1Gbps的链路肯定会遇到以前用过的序列号。时间戳能够让内核接受这种“异常”的数据包。这里需要将其关掉。

值为0（禁用时间戳）

值为1（启用时间戳）

只有客户端和服务端都开启时间戳的情况下，才会出现能ping通不能建立tcp三次握手的情况，所以做为提供服务的公司，不可能保证所有的用户都关闭时间戳，这个功能，所以我们必须关闭时间戳，这样才能给所用用户提供正常的服务。

使用该命令使其立马生效：/sbin/sysctl-p

============================================================================================================================
原文：http://blog.sina.com.cn/s/blog_781b0c850100znjd.html

    近来线上陆续出现了一些connect失败的问题，经过分析试验，最终确认和proc参数tcp_tw_recycle/tcp_timestamps相关；
1. 现象
    第一个现象：模块A通过NAT网关访问服务S成功，而模块B通过NAT网关访问服务S经常性出现connect失败，抓包发现：服务S端已经收到了syn包，但没有回复synack；另外，模块A关闭了tcp timestamp，而模块B开启了tcp timestamp；
    第二个现象：不同主机上的模块C（开启timestamp），通过NAT网关（1个出口ip）访问同一服务S，主机C1 connect成功，而主机C2 connect失败；

2. 分析
    根据现象上述问题明显和tcp timestmap有关；查看linux 2.6.32内核源码，发现tcp_tw_recycle/tcp_timestamps都开启的条件下，60s内同一源ip主机的socket connect请求中的timestamp必须是递增的。
    源码函数：tcp_v4_conn_request(),该函数是tcp层三次握手syn包的处理函数（服务端）；
    源码片段：
       if (tmp_opt.saw_tstamp &&
            tcp_death_row.sysctl_tw_recycle &&
            (dst = inet_csk_route_req(sk, req)) != NULL &&
            (peer = rt_get_peer((struct rtable *)dst)) != NULL &&
            peer->v4daddr == saddr) {
            if (get_seconds() < peer->tcp_ts_stamp + TCP_PAWS_MSL &&
                (s32)(peer->tcp_ts - req->ts_recent) >
                            TCP_PAWS_WINDOW) {
                NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_PAWSPASSIVEREJECTED);
                goto drop_and_release;
            }
        }
        tmp_opt.saw_tstamp：该socket支持tcp_timestamp
        sysctl_tw_recycle：本机系统开启tcp_tw_recycle选项
        TCP_PAWS_MSL：60s，该条件判断表示该源ip的上次tcp通讯发生在60s内
        TCP_PAWS_WINDOW：1，该条件判断表示该源ip的上次tcp通讯的timestamp 大于本次tcp

    分析：主机client1和client2通过NAT网关（1个ip地址）访问serverN，由于timestamp时间为系统启动到当前的时间，因此，client1和client2的timestamp不相同；根据上述syn包处理源码，在tcp_tw_recycle和tcp_timestamps同时开启的条件下，timestamp大的主机访问serverN成功，而timestmap小的主机访问失败；

    参数：/proc/sys/net/ipv4/tcp_timestamps - 控制timestamp选项开启/关闭
          /proc/sys/net/ipv4/tcp_tw_recycle - 减少timewait socket释放的超时时间

3. 解决方法
    echo 0 > /proc/sys/net/ipv4/tcp_tw_recycle;
    tcp_tw_recycle默认是关闭的，有不少服务器，为了提高性能，开启了该选项；
    为了解决上述问题，个人建议关闭tcp_tw_recycle选项，而不是timestamp；因为在tcp timestamp关闭的条件下，开启tcp_tw_recycle是不起作用的；而tcp timestamp可以独立开启并起作用。
    源码函数： tcp_time_wait()
    源码片段：
        if (tcp_death_row.sysctl_tw_recycle && tp->rx_opt.ts_recent_stamp)
            recycle_ok = icsk->icsk_af_ops->remember_stamp(sk);
        ......

        if (timeo < rto)
            timeo = rto;

        if (recycle_ok) {
            tw->tw_timeout = rto;
        } else {
            tw->tw_timeout = TCP_TIMEWAIT_LEN;
            if (state == TCP_TIME_WAIT)
                timeo = TCP_TIMEWAIT_LEN;
        }

        inet_twsk_schedule(tw, &tcp_death_row, timeo,
                   TCP_TIMEWAIT_LEN);

    timestamp和tw_recycle同时开启的条件下，timewait状态socket释放的超时时间和rto相关；否则，超时时间为TCP_TIMEWAIT_LEN，即60s；

    内核说明文档对该参数的介绍如下：
    tcp_tw_recycle - BOOLEAN
    Enable fast recycling TIME-WAIT sockets. Default value is 0.
    It should not be changed without advice/request of technical
    experts.

原文链接：http://blog.sina.com.cn/u/2015038597

============================================================================================================================
原文：http://www.verydemo.com/demo_c167_i3289.html
linux 服务器无法建立TCP连接时间戳 net.ipv4.tcp_timestamps

一.情况表现为
    1.在公司内网对站点的http访问：
        linux主机出现故障：curl以及抓包分析，发现服务端不响应linux客户端的请求，无法建立TCP连接，浏览器返回“无法连接到服务器”
        windows主机正常
    2.http访问质量下降：
        基调显示，新架构上线后，访问质量下滑，主要表现为
        2.1.访问提示“无法连接到服务器”
        2.2.仅少数人遇到这种故障，并且一天中不是每次访问都会遇到，而是出现时好时坏的现象

二.处理过程
    直接上google搜索关键字“服务器无法建立TCP连接”。
    翻了几页后，发现这篇博文：“http://www.sunchis.com/html/os/linux/2012/0518/413.html”。
    看了一下，和我们公司内网的表现一模一样，但各种问题（1为这方面基础知识薄弱，2为没有时间验证此配置）
    然后这种问题持续了n久...一直以为是内部设备问题
    后期搞不定了，大胆在线上启用这个参数“net.ipv4.tcp_timestamps = 0”，做了下测试后，发现故障解除，原故障机每次访问都正常了！
    不过还是不明其中原理，只是大意了解，同样处于NAT上网方式的用户里（与别人共用出口IP地址），如果你的时间戳小于别人的，那么服务器不会响应你的TCP请求，要忽略此项，将net.ipv4.tcp_timestamps = 0（/etc/sysctl.conf）

三.总结
    后期学习时，看见了一个更加详细的博客，讲的很详细，也引入了新的问题：http://huoding.com/2012/01/19/142
    ====== 小抄 ======
    其实，linux服务器原本对时间戳（timestamps）默认是不开启的，Linux是否启用这种行为取决于tcp_timestamps和tcp_tw_recycle，因为tcp_timestamps缺省就是开启的，所以当tcp_tw_recycle被开启后，实际上这种行为就被激活了。
    net.ipv4.tcp_tw_recycle又是啥呢，搜索了一下基本上是TIME_WAIT连接的回收参数
    当 net.ipv4.tcp_timestamps 没有设置（缺省为开启），并且 net.ipv4.tcp_tw_recycle 也开启时，这个坑爹的错误就出现了，但是注意，只表现在NAT网络环境中。而且，大多数博客，以及一些大牛们，都有说过要开启 net.ipv4.tcp_tw_recycle ...
    ====== 小抄 ======

四.未完成的事项
    上文 http://huoding.com/2012/01/19/142 中提到的：
    1.（未验证）关闭timestamps后，tw_recycle功能是失效的问题
    2.（未验证）新的解决TIME_WAIT连接过多的方法：net.ipv4.tcp_max_tw_buckets = 10000 设置一个最大值，不过坏处是系统日志会提示：TCP: time wait bucket table overflow