公网服务器或客户端为 NAT 网络的服务器不要同时开启 tcp_tw_recycle 和 tcp_timestamps

目录

背景及现象

服务器：公网服务器
客户端：外网手游客户端
玩家侧现象：大批处于同一局域网内的内侧玩家连接服务器超时，但是切换成 4G 之后连接顺畅。
服务端现象：netstat -s" 显示 “passive connections rejected because of time stamp” 数量增长快速，关闭 tcp_tw_recycle 或 tcp_timestamps 恢复正常，玩家侧现象消失。

问题原因

tcp_tw_recycle 依赖于 tcp_timestamps， 前者默认关闭，后者默认开启。如果二者都开启，当服务器收到 FIN 包时，这个 FIN 包中的时间戳值会按 IP 缓存起来（缓存 TCP_PAWS_MSL, 即 60s），缓存时间内，当同一 IP 的 SYN 包时间戳小于该值，则直接丢弃。代码分析如下：

tcp_v4_conn_request()

/* VJ's idea. We save last timestamp seen
 * from the destination in peer table, when entering
 * state TIME-WAIT, and check against it before
 * accepting new connection request.
 *
 * If "isn" is not zero, this request hit alive
 * timewait bucket, so that all the necessary checks
 * are made in the function processing timewait state.
 */
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 ((u32)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;
        }
}

由于 peer->tcp_ts_stamp 记录的是之前收到 FIN 包时服务器的时间戳，peer->tcp_ts 记录的是 FIN 包中的时间戳，req->ts_recent 表示当前 SYN 包中的时间戳，因此 (u32)get_seconds() - peer->tcp_ts_stamp < TCP_PAWS_MSL 表示缓存还未过期，(s32)(peer->tcp_ts - req->ts_recent) > TCP_PAWS_WINDOW 表示当前 SYN 包中的时间戳比之前 FIN 包中的时间戳还小 1s, 因此认为当前 SYN 包时之前重传的，直接丢弃。

req - struct request_sock
peer- struct inet_peer, inet_getpeer()
get_seconds() - 获取当前服务器时间

TCP_PAWS_MSL

#define TCP_PAWS_MSL    60              /* Per-host timestamps are invalidated
                                         * after this time. It should be equal
                                         * (or greater than) TCP_TIMEWAIT_LEN
                                         * to provide reliability equal to one
                                         * provided by timewait state.

TCP_PAWS_WINDOW

#define TCP_PAWS_WINDOW 1               /* Replay window for per-host
                                         * timestamps. It must be less than
                                         * minimal timewait lifetime.
                                         */

tcp_v4_tw_remember_stamp()

int tcp_v4_tw_remember_stamp(struct inet_timewait_sock *tw)
{
        struct inet_peer *peer = inet_getpeer(tw->tw_daddr, 1);

        if (peer) {
                const struct tcp_timewait_sock *tcptw = tcp_twsk((struct sock *)tw);

                if ((s32)(peer->tcp_ts - tcptw->tw_ts_recent) <= 0 ||
                    ((u32)get_seconds() - peer->tcp_ts_stamp > TCP_PAWS_MSL &&
                     peer->tcp_ts_stamp <= (u32)tcptw->tw_ts_recent_stamp)) {
                        peer->tcp_ts_stamp = (u32)tcptw->tw_ts_recent_stamp;
                        peer->tcp_ts       = tcptw->tw_ts_recent;
                }
                inet_putpeer(peer);
                return 1;
        }

        return 0;
}

peer->tcp_ts_stamp 同 tcptw->tw_ts_recent_stamp, peer->tcp_ts 同 tcptw->tw_ts_recent, 见 tcp_timewait_state_process().

tcptw - struct tcp_timewait_sock, struct inet_timewait_sock

tcp_timewait_state_process()

/* FIN arrived, enter true time-wait state. */
tw->tw_substate   = TCP_TIME_WAIT;
tcptw->tw_rcv_nxt = TCP_SKB_CB(skb)->end_seq;
if (tmp_opt.saw_tstamp) {
        tcptw->tw_ts_recent_stamp = get_seconds();
        tcptw->tw_ts_recent       = tmp_opt.rcv_tsval;
}

/* I am shamed, but failed to make it more elegant.
 * Yes, it is direct reference to IP, which is impossible
 * to generalize to IPv6. Taking into account that IPv6
 * do not understand recycling in any case, it not
 * a big problem in practice. --ANK */
if (tw->tw_family == AF_INET &&
    tcp_death_row.sysctl_tw_recycle && tcptw->tw_ts_recent_stamp &&
    tcp_v4_tw_remember_stamp(tw))
        inet_twsk_schedule(tw, &tcp_death_row, tw->tw_timeout,
                           TCP_TIMEWAIT_LEN);
else
        inet_twsk_schedule(tw, &tcp_death_row, TCP_TIMEWAIT_LEN,
                           TCP_TIMEWAIT_LEN);
return TCP_TW_ACK;

从此处可以看出，tcptw->tw_ts_recent_stamp 记录的是收到 FIN 包时服务器当前时间，而 tcptw->tw_ts_recent 记录的是 FIN 包中对端的时间戳。

结论

由于大量内侧玩家位于同一 NAT 网络中，所有玩家的 IP 被转换成同一出口 IP, 但时间戳却保留，因此到达服务器的包中时间戳顺序跟到达顺序是不一致的，当同时开启 tcp_tw_recycle 和 tcp_timestamps 时，一个玩家断开连接可能导致其他玩家的 SYN 包被丢弃掉。

实践

如何配置 tcp_tw_recycle 和 tcp_timestamps

tcp_timestamp 建议开启。tcp_timestamp 是 RFC1323 定义的优化选项，主要用于 TCP 连接中 RTT(Round Trip Time) 的计算，开启 tcp_timestamp 有利于系统计算更加准确的 RTT，也就有利于 TCP 性能的提升。

tcp_tw_recycle 建议关闭。

多数系统的默认设置也是如此。

为什么很多时候开启了 tcp_tw_recycle 也并没有产生问题

一是现网中很少出现批量用户处于同一 NAT 网络中且包被 NAT 网关转发之后顺序错乱，即使出现数量也很少；
二是有些客户端系统并没有使用时间戳，例如 XP 和多数 Windows 7.