tcp 傳送syn重試次數，預設6次
net.ipv4.tcp_syn_retries = 6第 1 次重試發生在 1 秒鐘後，接著會以翻倍的方式在第2、4、8、16、32 秒共做 6 次重試，最後一次重試會等待 64 秒，如果仍然沒有返回ack，才會終止三次握手。所以，總耗時是 1+2+4+8+16+32+64=127 秒，超過 2 分鐘。
半連線狀態的佇列大小，預設1024
net.ipv4.tcp_max_syn_backlog = 1024開啟 syncookies 功能就可以在不使用 syn 佇列的情況下成功建立連線。syncookies 是這麼做的：伺服器根據當前狀態計算出乙個值，放在己方發出的 syn+ack 報文中發出，當客戶端返回 ack 報文時，取出該值驗證，如果合法，就認為連線建立成功。
其中值為 0 時表示關閉該功能，2 表示無條件開啟功能，而 1 則表示僅當 syn 半連線佇列放不下時，再啟用它。由於 syncookie 僅用於應對 syn 泛洪攻擊（攻擊者惡意構造大量的 syn 報文傳送給伺服器，造成 syn 半連線佇列溢位，導致正常客戶端的連線無法建立），這種方式建立的連線，許多 tcp 特性都無法使用。所以，應當把 tcp_syncookies 設定為 1，僅在佇列滿時再啟用。
重發 syn+ack 報文次數。它的重試會經歷1、2、4、8、16 秒，最後一次重試後等待 32 秒，若仍然沒有收到 ack，才會關閉連線，故共需要等待 63 秒。
tcp_abort_on_overflow是，當程序未及時呼叫accept函式，造成accept佇列溢位，最終導致連線被丟棄。設定為0關閉丟棄操作，等待程序取出；反之1開啟丟棄。
listen函式的backlog引數表示accepte佇列的大小。事實上，backlog引數還受限於linux系統級的佇列長度上限，就是net.core.somaxconn控制。
當下各監聽埠上的accept佇列長度可通過ss -ltn命令檢視。
通過netstat -s命令給出的統計結果，可以看到究竟有多少應溢位而被丟棄的連線。
# netstat -s | grep "listen queue"
14 times the listen queue of a socket overflowed
重發fin報文次數，預設值0，特指8次。
tcp_max_orphans 定義了孤兒連線的最大數量。當程序呼叫close函式關閉後，無論該連線是在fin_wait1狀態，還是確實關閉了，該連線都與該程序無關了，變成孤兒連線。
tcp_fin_timeout 控制連線收到對方傳送的fin報文，處於fin_wait2狀態下的持續時長。
當 time_wait 的連線數量超過該引數時，新關閉的連線就不再經歷 time_wait 而直接關閉。
當伺服器的併發連線增多，相應地，同時處於time_wait狀態的連線數量也會變多，此時就應當調大tcp_max_tw_buckets引數，減少不同連線間資料錯亂的概率。
允許作為客戶端的新連線，在安全條件下使用time_wait狀態下的埠。那怎麼判斷安全條件呢？有兩點：
1、只用用於連線發起方，也就是c/s模型中的客戶端
2、對應的time_wait狀態的連線建立時間超過1秒才可以被復用
老版本linux提供了tcp_tw_recycle引數，開啟它會有巨大坑，強烈不建議開啟。尤其是在nat、lvs環境下，會導致同乙個ip的，時間戳小於上次記錄的時間戳的包被丟棄。
TCP三次握手 四次揮手
tcp 三次握手 tcp 連線是通過三次握手進行初始化的。三次握手的目的是同步連線雙方的序列號和確認號並交換 tcp 視窗大小資訊。以下步驟概述了通常情況下客戶端計算機聯絡伺服器計算機的過程 1.客戶端向伺服器傳送乙個syn置位的tcp報文，其中包含連線的初始序列號x和乙個視窗大小 表示客戶端上用來...
TCP三次握手 四次揮手
服務端的tcp程序先建立傳輸控制塊tcb，準備接受客戶端程序的連線請求，然後服務端程序處於listen狀態，等待客戶端的連線請求，如有，則作出響應。1 客戶端的tcp程序也首先建立傳輸控制模組tcb，然後向服務端發出連線請求報文段，該報文段首部中的syn 1，ack 0，同時選擇乙個初始序號seq ...
TCP三次握手四次揮手
tcp transmission control protocol 傳輸控制協議 tcp是主機對主機層的傳輸控制協議，提供可靠的連線服務，採用三次握手確認建立乙個連線。位碼即tcp標誌位,有6種標誌 urg urgent緊急 ack acknowledgement 確認 psh push傳送 rst...