半連線佇列（syn queue）
全連線佇列（accept queue）
#ss -lnt
recv-q send-q local address:port peer address:port
0 100 *:8080 *:*
當連線狀態變為syn_rcvd時，連線資訊儲存到syns queue；當連線狀態變為established時，連線資訊從syns queue移動到accept queue；當accept()函式從accept queue獲取連線後，連線資訊從佇列中移除，具體過程如下：
半連線佇列溢位處理策略
全連線佇列溢位處理策略
如果全連線佇列滿了，在收到三次握手最後的 ack 時服務端會按照網路引數net.ipv4.tcp_abort_on_overflow的值進行處理：
應用層現象
排查過程
首先通過top或監控等手段確定服務端指標是否正常（rt、cpu、負載等指標）；
如果服務端指標正常，檢視佇列大小設定是否合理；
問題1：如果 client 走完了 tcp 握手的第三步，在 client 看來連線已經建立好了，但是 server 上的對應連線實際沒有準備好，這個時候如果 client 發資料給 server，server 會怎麼處理呢？
此時server會忽略client傳送的資料報，然後client認為資料報丟失進行重傳，若重試若干次數後仍沒有成功則client認為異常斷開連線；
問題2：syncookie機制是怎樣的，如何避免syn flood攻擊？
syncookie機制是指將連線資訊編碼在isn(initial sequence number)中返回給客戶端，而不需要將半連線儲存在佇列中，然後利用客戶端隨後發來的ack帶回的isn還原連線資訊，以完成連線的建立，從而避免了半連線佇列被攻擊syn包填滿。（因此，當啟用 syncookie機制時半連線佇列長度可看做無限的）
問題3：netstat命令和ss命令中 recv-q和send-q含義？
參考：阿里中介軟體：
核心引數：
Linux 半連線佇列,全連線佇列
socket 中 listen api中引數backlog指定的是 全佇列大小 accept api是從全佇列中獲取,沒有就阻塞了,直到有新連線進來.listen中指定的值大小,有乙個最大上限,這個上限是系統核心中設定的.在配置檔案中 proc sys net core somaxconn 這個值預...
TCP全連線佔滿問題
在實際工作中經常碰到一種情況，流量 的時候，服務端會出現大量的超時。此時的處理辦法一般是擴容。實際上就算沒有流量 當某個介面速度變慢時，呼叫該介面的服務也會出現超時。不管是流量 qps增加 還是介面變慢，導致超時的直接原因都是系統吞吐量不足 系統吞吐量 qps 響應時間 當系統吞吐量不足時，大量請求...
TCP連線和斷開連線
4.4 tcp資料報結構 帶陰影的幾個字段需要重點說明一下 1 序號 seq sequence number 序號佔32位，用來標識從計算機a傳送到計算機b的資料報的序號，計算機傳送資料時對此進行標記。2 確認號 ack acknowledge number 確認號佔32位，客戶端和伺服器端都可以傳...