sysctl: cannot stat /proc/sys/net/ipv4/tcp_tw_recycle : No such file or director

admin

sysctl: cannot stat /proc/sys/net/ipv4/tcp_tw_recycle : No such file or directory

0 T# A' G* S# b4 q
最近发现一个奇怪的问题，一台服务器上部署的网站，用外网访问是正常的，但是使用公司内网访问就访问不上，不仅网站访问不上，连服务器有时候都连接不上。
原因是在内核优化时启用了net.ipv4.tcp_tw_recycle参数
% T& i9 e/ w& F" F2 o, v" l) U2 g+ P这个参数是默认关闭的，之所以打开是由于这个参数开启后，可以使TCP连接中TIME-WAIT sockets的快速回收，但是在NAT网络下，导致大量的TCP连接建立错误、
! Y1 `. M3 f; g* I4 C所以在公司内部有时候能访问，有时候访问不上
3 |. k/ ^- U- f2 O1.先确定参数
1 Y& x" i' N8 r2 A! H依次执行如下命令，查看当前内核配置，确认该参数值为“1”。

cat /proc/sys/net/ipv4/tcp_tw_recycle
cat /proc/sys/net/ipv4/tcp_timestamps
! V: C; t! r! K# ^
7 K) ?- J3 J' H9 l4 L; \" F2.在/etc/sysctl.conf配置文件添加如下内容。
8 H; C6 r6 H) Y+ w
& B% d% y  ^+ `% G6 tnet.ipv4.tcp_tw_recycle=0
net.ipv4.tcp_timestamps=0
2 d3 F& |  l7 U% U! R, c- U, `
3.执行如下命令，使配置生效。

( k3 z) r) K1 y2 N, }sysctl -p
, G3 G2 P6 H, b& i5 J" @$ Y
6 c5 p" k( Y. I+ X! |# X修改完成后，在公司中访问就正常了
  K" y1 W& l, S1 B记录下，对于网上提供的调优参数还是要多注意
( J, f; D8 O/ \% k0 ]4 U

( k4 H7 \0 F' t6 J* O& d

admin

同事反馈从公司连接线上一台服务器有时候会失败，经过抓包发现，TCP握手过程失败。查了相关资料，发现是跟net.ipv4.tcp_tw_recycle和net.ipv4.tcp_timestamps两个参数有关，将net.ipv4.tcp_tw_recycle改为0，问题解决。
( ?' t0 w1 P5 }) [# [3 Z7 d
排查过程
在PC上通过wireshark抓包发现，失败的时候，TCP syn包是一直在重传的。在server端通过tcpdump抓包发现，PC侧发的syn包是已经到达，所以基本排除网络问题。tcpdump抓包中确实看不到server端响应的syn-ack，所以基本判定问题出在server段，接下来就是分析为啥server端不响应。
. |; Z" Q* \+ r% |) J/ O1 |当net.ipv4.tcp_tw_recycle = 1和net.ipv4.tcp_timestamps = 1同时间开启，当多个PC经过NAT设备访问同一server的时候，受TCP PAWS(Protect Against Wrapped Sequence Numbers)影响，后发起连接的PC可能因为tcp options中的timestamp比前面PC的timestamp小，而导致syn不被响应。
: J4 K' g/ J5 Mlinux服务器上可以通过netstat -s查看是否存在该问题。如果多次执行下面的命令，发现数字再增加，说明存在该问题，而且现在还在发生。
; M. n8 C* ^2 F' w
4 ^1 I: ~" i3 ~; \, f[root@anonymous ~]# netstat -s | grep "connections rejected because of time stamp"26 passive connections rejected because of time stamp
9 n7 V& `  V0 h# A1 O# ]7 j7 {[root@anonymous ~]#
5 L( [. {0 v) V6 _5 Z: o4 i$ L2 |* L关于PAWS的检查机制，是对于处于TIME_WAIT状态的tcp连接的对端IP，为了防止来自同一IP的延迟数据的干扰，需要在60秒(#define TCP_PAWS_MSL 60)内新来的syn报文TCP options中的timestamp是递增的。详细解释可以参考RFC1323。
1 v1 A  l" e5 w$ s
9 I& K/ G8 W( Y; ~, L' \) |注意
排查过程中发现，windows系统和linux系统TCP syn options中timestamp是单调递增的，所以刚才描述的问题通常在多个PC经过NAT访问同一server的时候才容易复现。而测试中发现Mac系统本身syn报文options中的timestamp波动比较大，所以此问题很容易用Mac复现，只需要对着开启recycle和tcp_timestamps的server连续发起几次请求就可以。
Mac上的timestamp变化

: H7 C) V7 _% c) z% o总结
该问题将net.ipv4.tcp_tw_recycle或net.ipv4.tcp_timestamps改为0都可以解决，不建议将net.ipv4.tcp_timestamps改为0，因为它对精准计算RTT(Round-Trip Time))有用。此外，tcp_tw_recycle从4.12版本内核开始被移除了。我找了一个5.14版本的测试了下，确实不支持该配置了。

) K9 Q5 l( p' Y$ P# c! I) g" O/ ^3 ][root@test ~]# sysctl -p
5 h0 H/ ^2 W5 Q/ [/ ]0 @sysctl: cannot stat /proc/sys/net/ipv4/tcp_tw_recycle: No such file or directory
3 v0 ^0 Q) ^- ^' A( g[root@test ~]#