內核參數優化之2-1 tcp/ip 標誌位報文解析

如下內容純屬虛構,切勿輕易相信!

---

 

• 衆所周知,tcp/ip三次握手和四次揮手,均由syn/ack/fin三個標誌位報文決定,可是這三個標誌位報文,並非說在構建鏈接的時候只發送一次的,由於協議不知道網絡情況. 故而就存在瞭如下參數,能夠調節發送次數
• net.ipv4.tcp_syn_retries
  • 這個參數從字面上來看就是syn標誌位報文的重試次數,何時發送syn標誌位呢?三次握手中,請求端第一次構建鏈接的時候,默認是5次,可是對於一個處於網絡情況好的請 求端,5次顯然是多了,所以,咱們來個2
• net.ipv4.tcp_synack_retries = 5
  • 這個參數從字面上來看是syn+ack標誌位報文的重試次數,何時發送syn+ack標誌位呢?三次握手中,響應端爲了應答請求端的syn標誌位報文,同時請求構建的時候,默認是5次,和上面同樣,網絡環境好,就來個2.
  • 這裏還牽扯到一個東西,ddos攻擊裏面有一個就是針對syn+ack報文的攻擊,也就是說,若是有瘋子一直大量發送syn標誌位,可是服務器須要發送syn+ack來響應,可是那個瘋子卻不回覆ack標誌位,致使服務器須要一直重試到次數結束.
  • 且服務器的syn等待隊列是有上限的,由於大量瘋子的syn報文佔用了,那麼服務器就接收不到正常的syn報文請求了.這裏還有一個響應端syn等待隊列的參數
• net.ipv4.tcp_max_syn_backlog 疑問項?
  • 這個參數就是定義響應端的SYN_RCVD狀態隊列,默認是1024,根據服務器性能和負載狀況,能夠調高此數值,好比8192
  • 假設被ddos syn flood了,syn等待隊列也溢出了,該怎麼搞?能夠啓用net.ipv4.tcp_syncookies
  • 到這裏,可能有人發現,設定了這個參數,可是服務器在併發測試的時候,發現SYN_RCVD的狀態仍是128或者512(內核小於2.6.20),其緣由以下:
    • 服務器的被請求源於服務的監聽端口,重啓服務,即從新調用listen函數
    • 在內核大於2.6.20的時候,listen函數會在調用的時候讀取內核參數net.core.somaxconn的值,它的默認值是128,來肯定backlog的大小
    • 在內核小於2.6.20的時候,listen函數有一個固定值TCP_SYNQ_HSIZE這個單向鏈表數組,它的默認值是512,你能夠修改這個值,確保這個值*16 <= net.ipv4.tcp_max_syn_backlog,這個鏈表的位置在$KERNEL/include/net/tcp.h
    • 可是無論你如何修改上面的參數,若是你不修改服務中listen的顯性參數backlog,那麼服務依然會限制
    • nginx中是這麼修改的listen 80 default backlog = 8192
    • php-fpm中是這麼修改的listen.backlog = 8192
• net.core.netdev_max_backlog 疑問項?
  • 若是說tcp_max_syn_backlog是針對syn半開鏈接的話,這個參數就是針對一個總體的,意思就是說當內核處理不過來的時候,多餘的就先扔到隊列中
• net.ipv4.tcp_syncookies
  • 這個參數的做用是當syn等待隊列溢出的時候,就給請求端發送syncookies,直接繞過三次握手,構建鏈接.但這違反了tcp/ip協議,可能會影響其餘服務,因此若是不肯定是攻擊,而是正常負載,則不要開啓

OK,假設咱們內核是大於2.6.20的,那麼咱們若是想要實現如下場景:

1. 一個服務器,加載的是nginx服務,他正在接收請求,請求愈來愈多,他處理不過來了,因此將多餘的請求扔到了一個隊列中(隊列上限8192);
   • net.core.netdev_max_backlog = 8192
2. 可是這時候又來了一大批奇怪的請求,服務器怎麼迴應,這些請求源都不響應,且這些請求量也很大,故而服務器將其扔到了另外一個隊列(隊列上限8192);
   • net.core.somaxconn = 8192
   • net.ipv4.tcp_max_syn_backlog = 8192
   • listen 80 default backlog = 8192
3. 爲了防止這些垃圾請求過於佔用資源,服務器規定迴應報文(ack+syn)的次數爲2
   • net.ipv4.tcp_synack_retries = 2

到目前爲止,三次握手已經走了一半,繼續路程~