下面是我的理解，可能有誤，僅供參考。
要調優，三次/四次握手必須爛熟于心。
client server
(SYN_SENT) —> (SYN_RECV)
(ESTABLISHED) <—
—> (ESTABLISHED)
client(主動) server
(FIN_WAIT_1) —> (CLOSE_WAIT)
(FIN_WAIT_2) <—
(TIME_WAIT) <— (LAST_ACK)
—> (CLOSED)
大家熟知的 SYN flooding/SYN spoofing 就是在 SYN_RECV 的狀態下發起的進攻。這種由于 TCP/IP 協議引起的缺陷只能防治而不好根治，除非換了 TCP/IP。通過下面的方式，可以在一定程度上緩解 DDOS 攻擊。
- 增大半連接的隊列，即 backlog queue
- 人工干預以減少 SYS_RECV 的時間，可以降低第一個重傳包的時間或者減少重傳的次數
檢測 SYN 攻擊，可以使用 netstat 命令查看當前的連接類型以及連接數目,如果發現有大量的 SYN_RECV,就值得懷疑了:
$ netstat -tuna | grep :80 | awk '{print $6}' | sort | uniq -c
或者可以通過 wget/curl 從遠端實際來測試一下訪問的速度：
$ time wget -O /dev/null www.example.com
正常情況下，其 real time 在個位數(s)左右，如果出現長達數十秒乃至幾百秒的情況，有可能是此類情況。
最簡單的方式是通過 syncookie 實現，Linux 還實現了一種稱作 SYN cookie 的機制，開啟：
# echo 1 > /proc/sys/net/ipv4/tcp_syncookies
該機制會在服務器收到 SYN 請求后，構造一個帶有 ISN(initial sequence number)的 SYN/ACK 包，該 ISN 稱為 cookie，其實就是一個哈希。通過此就可以驗證客戶端的真實性了
注意：SYN cookie 機制不會使用到 backlog queue，因此不必擔心 queue 被填滿然后服務器主動放棄連接。
使用了 SYN cookie 之后，在 /var/log/kern.log 會發現不少如下的 log，起作用了 ;-)
possible SYN flooding on port 80. Sending cookies
除了使用 syncookie，還可以修改 backlog queue 來達到目的。backlog queue 是一個用來處理在三次握手過程中帶有 SYN 標志的包的數據結構，可以用來控制系統同時處理的最大連接，當達到該閾值后，接下來的請求會被系統丟棄。這需要系統開辟額外的內存來處理進來的包。如果處 理的不好會導致系統內存耗盡，導致嚴重的性能問題。
tcp_max_syn_backlog 定義了 backlog queue 的半連接數量：
# echo 90000 > /proc/sys/net/ipv4/tcp_max_syn_backlog
當客戶端發起 SYN 請求后，服務端會立刻發送 SYN+ACK 的回應，該次半連接會到 backlog queue 中，服務器會等待客戶返回 ACK，如果在一段時間內沒有應答，服務器會重新發送剛剛的 SYN+ACK，經歷了幾次還是沒有回應后，服務器會主動斷開此次半連接。
我們就可以修改重發的次數來減少整個半連接的時間：
# echo 3 > /proc/sys/net/ipv4/tcp_synack_retries
——————————————————————————-
|Value| Time of retransmission | Total time |
——————————————————————————-
|1 | in 3rd second | 9 seconds |
——————————————————————————-
|2 | in 3rd and 9th second | 21 seconds |
——————————————————————————-
|3 | in 3rd, 9th and 21st second | 45 seconds |
——————————————————————————-
這張表格顯示了不同重傳次數消耗的總時間
上面屬于 passive 連接，也就是客戶端連接服務端，還有個相反的 active TCP connection 參數：
# echo 3 > /proc/sys/net/ipv4/tcp_syn_retries
tcp_fin_timeout 參數會通知 kernel 在 FIN_WAIT_2 狀態 sockets 的存活時間，根據理解應該是 server 主動終止，像下面這樣。
server client
(FIN_WAIT_1) —> (CLOSE_WAIT)
(FIN_WAIT_2) <—
(TIME_WAIT) <— (LAST_ACK)
—> (CLOSED)
當處于 CLOST_WAIT 的 client 有意(攻擊)/無意(client 突然崩潰等)不發 fin 來繼續時，server 會一直停留在 FIN_WAIT_2 狀態，造成資源的浪費。
可以適當的減小該時間：
# echo 15 > /proc/sys/net/ipv4/tcp_fin_timeout
跟 tcp_fin_timeout 相關的有 tcp_max_orphans 參數，表示沒有跟任何用戶文件相關聯的 socket 最大個數，超出的將被內核丟棄。
建議該參數只增加不減小，但增加也意味著內存的消耗增加：
# echo 327680 > /proc/sys/net/ipv4/tcp_max_orphans
相關的 tcp_orphans_retries 關閉本端 TCP 連接前的重試次數，默認 7，高負載的 webserver 建議可以減小。這里解釋了設置為 0 的情況。
下面這三個參數一起解釋：
tcp_tw_recycle
tcp_tw_reuse
tcp_timestamps
其中 tcp_tw_recycle/tcp_tw_reuse 這兩個官方的建議保持默認為 0，而 tcp_timestamps 這個參數在特定的情況開啟會引起很嚴重的問題(via 1, 2)。
基本的情況就是，你的客戶或者你的服務器在一個 NAT 后面，如果開啟這個參數，會導致服務器能收到三次握手的 SYN 但是不會返回任何的 SYN+ACK，其結果是客戶無法訪問你的網站。可以通過 tcpdump 或者下面的這個查看：
# netstat -s | grep timestamp
tcp_timestamps 是 tcp 協議中的一個擴展項，通過時間戳的方式來檢測過來的包以防止 PAWS(Protect Against Wrapped Sequence numbers)，可以提高 tcp 的性能，2.6 的內核默認是打開的。只要 client/server/nat/loadbalancer 不同時打開該選項就不會出現上面的問題。與之相關的包括 tcp_tw_recycle，如果 tcp_timestamps 和 tcp_tw_recycle 同時開啟，就會開啟時間戳選項，導致上面的問題。如果有上述的網絡結構，比較合理的方式是禁用 tcp_tw_recyle 而開啟 tcp_timestamps。禁用了 tcp_tw_recycle 其 TIME_OUT sockets 回收功能就沒了，可以配合 tcp_tw_reuse 讓 TIME_WAIT 降下來。
netdev_max_backlog 這個參數跟 TCP 的傳輸隊列有關,發送隊列長度是 txqueuelen ，netdev_backlog 則決定接收隊列的長度。
前者通過 ifconfig 命令改變：
# ifconfig eth0 txqueuelen 10000
對于高吞吐的網絡而言，默認的 100 肯定是不夠的，一個 rrt 為 120ms 的千兆以太網絡，可以設置成 10000 以上的值。
對于接受端而言，需要修改的話就涉及到了 /proc/sys/net/core/netdev_max_backlog 了，如果接收包的速度大于內核能處理的速度，則需要隊列來維持，此數值表示最大隊列值。默認為 1000，如果超過該數值，會引起丟包，根據實際情況增大。
對于網絡不是很好的情況，可以開啟 tcp_sack 參數。該實現是 TCP 的一個選項，稱為 Selective Acknowlegement(SACK)，默認開啟，對于千兆網絡可以關閉，能提高一定的性能。
keepalive 的情況，Linux 內置支持，只需要開啟相應的內核參數就可以了，主要是下面三個：
tcp_keepalive_time 表示 TCP 發出第一個 keepalive 信息之前等待的時間，默認為 7200
tcp_keepalive_intvl keepalive 的時間間隔，默認是 75
tcp_keepalive_probes 觸發的次數，默認是 9
ip_local_port_range 128M 內存以上的機器默認是 32768 61000，可以進一步擴大 10240 65535，盡量不要使用 1024 周圍的，避免沖突。
以上只是網絡內核參數的一小小部分，有待繼續補充。
ref:
http://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/tcpvariables.html
http://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
http://www.symantec.com/connect/articles/hardening-tcpip-stack-syn-attacks
http://www.saview.net/archives/201