現象：
服務器產生大量SYN_RECV連接，而系統默認SYN_RECV爲1024，如果系統當前的syn_recv達到系統默認值，Nginx會不處理新來的連接，導致影響業務。
分析：
目前是使用f5的layer4模式轉發請求，故所有tcp連接的處理都在服務器端完成，有可能是網絡質量不好而導致產生大量的syn_recv，使用netstat命令查看TOP 10 syn_recv ip，發現都是移動網關過來的，初步判斷可能是移動網絡慢對方無法接受服務器返回的包而產生syn_recv，尤其是如下ip比較明顯：211.139.92.11（甘肅省蘭州市移動）。
解決方法：
1.F5改爲standard方式，所有tcp連接由F5處理，後端只關注業務，故障解決，但加大F5的性能負荷。
2.服務器修改內核，使其能容納更多的syn_recv，加大網絡連接;
修改內核參數如下：
1）net.ipv4.tcp_max_syn_backlog = 65536
該參數是SYN隊列的長度，默認爲1024，修改爲65536，加大SYN隊列長度可以容納更多等待連接的網絡連接數
2）net.core.netdev_max_backlog = 32768
該參數決定了，網絡設備接收數據包的速率比內核處理這些包的速率快時，允許送到隊列的數據包的最大數目，默認值爲300。根據需要調整改值，不要設置的過大。
3）net.core.somaxconn = 32768
該參數用來限制監聽隊列最大數據包的數量，超過這個數量就會導致鏈接超時或者觸發重傳機制。也就是說,web應用中listen函數的backlog會給我們內核參數的net.core.somaxconn 限制到128,在高突發的請求中可能會導致鏈接超時或者觸發重傳；例如：nginx的默認的backlog隊列爲511，如果內核參數net.core.somaxconn的值低於511，那麼nginx的backlog隊列將被限制爲該參數的值。此外，可以在nginx的配置中增加監聽隊列的數量，當然前提是不能超過net.core.somaxconn的值。
server {
listen 80 deafult backlog=8192;
server_name http://www.libertyvps.com]www.libertyvps.com;
}
listen 80 deafult backlog=8192;
server_name http://www.libertyvps.com]www.libertyvps.com;
}
4）net.ipv4.tcp_syncookies = 1
該參數是一個開關，是否打開SYN Cookie功能，該功能可以防止部分SYN***，默認爲0關閉，1開啓。
注意：該選項千萬不能用於那些沒有收到***的高負載服務器，如果在日誌中出現synflood消息，但是調查發現沒有收到synflood***，而是合法用戶的連接負載過高的原因，你應該調整其它參數來提高服務器性能。參考:
5）net.ipv4.tcp_synack_retries = 0默認值是5，對於遠端的連接請求SYN，內核會發送SYN ＋ ACK數據報，以確認收到上一個 SYN連接請求包。這是所謂的三次握手( threeway handshake)機制的第二個步驟。這裏決定內核在放棄連接之前所送出的 SYN+ACK 數目。不應該大於255，默認值是5，對應於180秒左右時間。(可以根據下面的 tcp_syn_retries 來決定這個值)
6）net.ipv4.tcp_syn_retries = 0
默認值是5，對於一個新建連接，內核要發送多少個 SYN 連接請求才決定放棄。不應該大於255，默認值是5，對應於180秒左右時間。(對於大負載而物理通信良好的網絡而言,這個值偏高,可修改爲2.這個值僅僅是針對對外的連接,對進來的連接,是由tcp_retries1 決定的)
注：5）6）這2項可根據業務的特性靈活調整，我這裏設置爲0，對業務本身沒有很大的影響，查看連接及日誌沒有減少的變化。
7）由於我們的業務是移動互聯網業務，根據其特殊性，如修改瞭如下2個參數，會對業務有一定影響，請不要調整，保持默認即可。
net.ipv4.tcp_rw_reuse = 0
net.ipv4.tcp_rw_recycle = 0
通過查看服務器，有大量的TIME_WAIT連接，而很多是出現在nginx+php-cgi的ip轉發連接方式，建議可調整爲通過unix socket方式訪問，減少不必要的網絡消耗。
經過以上調整，服務器在容納更多的SYN_RECV亦保證nginx能正常提供web訪問，查看系統負載，保持在1以下。