內核TCP: remove per-destination timestamp cache

2017年3月，內核主線將TCP Metrics表項中的時間戳緩存，補丁詳見patch---tcp: remove per-destination timestamp cache

struct tcp_metrics_block {
     struct inetpeer_addr        tcpm_saddr;
     struct inetpeer_addr        tcpm_daddr;
     unsigned long            tcpm_stamp;
-    u32                tcpm_ts;
-    u32                tcpm_ts_stamp;
     u32                tcpm_lock;
     u32                tcpm_vals[TCP_METRIC_MAX_KERNEL + 1];

與之一塊兒修改的，還有tcp: remove tcp_tw_recycle。tcp_tw_recycle機制是用於內核快速回收TIME_WAIT狀態的套接字。可是當網絡中存在NAT設備時，該機制反而可能會致使NAT設備背後的客戶端難以鏈接上服務器。

這樣的問題實在太多了！網絡上隨便一搜就是
No response to some SYN packets when timestamps are enabled
Why would a server not send a SYN/ACK packet in response to a SYN packet
why-does-my-linux-box-fail-to-send-syn-ack-until-after-eight-syns-have-arrived?

致使這些問題的緣由是服務器收到的SYN報文中攜帶的時間戳早於以前已經收到的FIN報文的時間戳，因而服務器認爲該SYN報文是因爲網絡阻塞遲到的舊鏈接的SYN報文的重傳，因而拒絕恢復SYN-ACK。出現這種狀況的緣由是傳輸鏈路上存在NAT設備。而緩存FIN報文時間戳的TCP Metrics是Per-Destination的，在有NAT的環境中，服務器看到的Destination是NAT設備，它看不到NAT設備背後還有多大的內部網絡，內部網路的每臺主機上沒法保證SYN報文的時間戳遞增。

固然，若是和我同樣，不能升級內核, 那麼不打開tcp_tw_recycle也是一個選擇

tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4) Enable fast recycling of TIME_WAIT sockets. Enabling this option is not recommended for devices communicating with the general Internet or using NAT (Network Address Translation).Since some NAT gateways pass through IP timestamp values, one IP can appear to have non-increasing timestamps. See RFC 1323 (PAWS), RFC 6191.