[httpd] httpd server 在低負載的情況下對SYN無響應
如題：
兩臺client通過load balance訪問httpd server。兩個client互動訪問。load balance處於fullnat模式。
server在低負載情況下，常常對某一個client的請求無響應。
在server上，先後使用tcpdump，nstat, netstat等工具排障。定位在如下錯誤上：
netstat：
22960 passive connections rejected because of time stamp 98182576 SYNs to LISTEN sockets dropped
同時，nstat也有錯誤統計：
TcpExtListenDrops
另外，排除了backlog的問題。可見nstat統計中，backlogdrop為0
TcpExtTCPBacklogDrop
詳細的backlog排障，參考：http://jm.taobao.org/2017/05/25/525-1/
如上所述，通過錯誤
22960 passive connections rejected because of time stamp
可以順利排查到 tcp_tw_recycle和net.ipv4.tcp_timestamps的問題，詳細如下：
http://blog.51cto.com/leejia/1954628
這樣修改：
[[email protected]3 ~]# tail -n2 /etc/sysctl.conf net.ipv4.tcp_timestamps=0 net.ipv4.tcp_tw_recycle=0
測試可用，問題解決。
------------------------------------------
轉載如下：出處http://blog.51cto.com/leejia/1954628
一，背景：
今天下午發現線上的一臺機器從辦公網登入不上且所有tcp埠都telnet不通，但是通過同機房的其它機器卻可以正常訪問到出問題的機器。於是就立即在這臺出問題的server端抓包分析，發現問題如下：
server端收到了本地pc發的SYN包，但是沒有回syn+ack包，所以確認是server端系統問題。tcpdump抓包如下：
二，排查
1，發現系統沒有任何負載
2，網絡卡也沒有丟包
3，iptables策略也都沒問題
4，系統的SYN_RECV連線很少，也沒超限
5，系統的檔案描述符等資源也都沒問題
6，messages和dmesg中沒有任何提示或者錯誤資訊
7，通過netstat命令檢視系統上協議統計資訊，發現很多請求由於時間戳的問題被rejected
# netstat -s |grep reject 2181 passive connections rejected because of time stamp 34 packets rejects in established connections because of timestamp
三，通過google來協助
發現有同樣的人遇見這個問題：
是通過調整sysctl -w net.ipv4.tcp_timestamps=0或者sysctl -w net.ipv4.tcp_tw_recycle=0來解決這個問題，於是我就順藤摸瓜繼續查。
而在查詢這兩個引數的過程中，發現問題原因如下：
發現是 Linux tcp_tw_recycle/tcp_timestamps設定導致的問題。 因為在linux kernel原始碼中發現tcp_tw_recycle/tcp_timestamps都開啟的條件下，60s內同一源ip主機的socket connect請求中的timestamp必須是遞增的。經過測試，我這邊centos6系統（kernel 2.6.32）和centos7系統（kernel 3.10.0）都有這問題。
原始碼函式：kernel 2.6.32 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
總結：
我這邊和其它同事通過公司出口（NAT閘道器只有1個ip地址）訪問問題server，由於timestamp時間為系統啟動到當前的時間，故我和其它同事的timestamp肯定不相同；根據上述SYN包處理原始碼，在tcp_tw_recycle和tcp_timestamps同時開啟的條件下，timestamp大的主機訪問serverN成功，而timestmap小的主機訪問失敗。並且，我在辦公網找了兩臺機器可100%重現這個問題。
解決：
# echo "0" > /proc/sys/net/ipv4/tcp_tw_recycle
四，擴充套件
1，net.ipv4.tcp_timestamps
tcp_timestamps的本質是記錄資料包的傳送時間。基本的步驟如下：
-
傳送方在傳送資料時，將一個timestamp(表示傳送時間)放在包裡面
-
接收方在收到資料包後，在對應的ACK包中將收到的timestamp返回給傳送方(echo back)
-
傳送發收到ACK包後，用當前時刻now - ACK包中的timestamp就能得到準確的RTT
當然實際運用中要考慮到RTT的波動，因此有了後續的(Round-Trip Time Measurement)RTTM機制。
TCP Timestamps Option (TSopt)具體設計如下
Kind: 8 // 標記唯一的選項型別，比如window scale是3 Length: 10 bytes // 標記Timestamps選項的位元組數 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Kind=8 | Length=10 | TS Value (TSval) | TS ECho Reply (TSecr) | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 1 4 4
timestamps一個雙向的選項，當一方不開啟時，兩方都將停用timestamps。比如client端傳送的SYN包中帶有timestamp選項，但server端並沒有開啟該選項。則回覆的SYN-ACK將不帶timestamp選項，同時client後續回覆的ACK也不會帶有timestamp選項。當然，如果client傳送的SYN包中就不帶timestamp，雙向都將停用timestamp。
tcp資料包中timestamps的value是系統開機時間到現在時間的（毫秒級）時間戳。
引數：
0：停用
1：啟用(系統預設值)
2，net.ipv4.tcp_tw_recycle
TCP規範中規定的處於TIME_WAIT的TCP連線必須等待2MSL時間。但在linux中，如果開啟了tcp_tw_recycle，TIME_WAIT的TCP連線就不會等待2MSL時間（而是rto或者60s），從而達到快速重用（回收）處於TIME_WAIT狀態的tcp連線的目的。這就可能導致連線收到之前連線的資料。為此，linux在開啟tcp_tw_recycle的情況下，會記錄下TIME_WAIT連線的對端（peer）資訊，包括IP地址、時間戳等。這樣，當核心收到同一個IP的SYN包時，就會去比較時間戳，檢查SYN包的時間戳是否滯後，如果滯後，就將其丟掉（認為是舊連線的資料）。這在絕大部分情況下是沒有問題的，但是對於我們實際的client-server的服務，訪問我們服務的使用者一般都位於NAT之後，如果NAT之後有多個使用者訪問同一個服務，就有可能因為時間戳滯後的連線被丟掉。
引數：
0：停用(系統預設值)
1：啟用
參考：
http://hustcat.github.io/tcp_tw_recycle-and-tcp_timestamp/