網絡連接狀態
網絡連接狀態（11種）非常重要這裏既包含三次握手中的也包括四次斷開中的，所以要熟悉。
- LISTEN 被動打開，首先服務器需要打開一個socket進行監聽，監聽來自遠方TCP端口的連接請求，等於服務器端執行socket、bind、listen三個函數之後阻塞在accept處。
- SYN_SENT 表示主動連接，客戶端能通過應用程序調用connect()函數進行active open。於是客戶端TCP發送一個SYN以請求建立一個連接，之後狀態爲SYN_SEND，表示已發送一個SYN到服務器端，等待SYN 1+ACK 0響應。
- SYN_RECV 服務器端收到客戶端的SYN 1，然後狀態變爲SYN_RECV。表示服務器收到了客戶端發來的SYN，然後自己也響應了給客戶端一個SYN 1+ACK 1，然後等待客戶端確認。 這時候客戶端過來的連接（屬於半連接狀態）被放在一個SYN隊列裏面，SYN泛洪***也是這樣的，就是服務器響應了SYN+ACK之後，客戶端就不在發送ACK了，然後繼續發送SYN，直到把服務器的最大連接數量耗盡。 半連接隊列長度是由內核參數tcp_max_syn_backlog來決定的。
- ESTABLISHED 代表一個打開的連接，客戶端收到服務器發送的SYN 1+ACK 1，就變爲這個狀態，然後向服務器發送ACK，如果服務器收到這個ACK，那麼它也變爲這個狀態。這個狀態就是表示連接以及建立，正在或即將傳輸數據。服務器收到ACK以後就會把半連接從上面提到的SYN隊列中刪除，然後放到ACCEPT隊列中，這時這個半連接的狀態就變成了ESTABLISHED。
- FIN_WAIT1 主動關閉端（可以是服務器也可以是客戶端）應用程序調用了close，於是其TCP發出FIN主動關閉請求，也就是四次斷開的第一次，之後就進入了FIN_WAIT1狀態，等待遠程主機的ACK請求。
- CLOSE_WAIT 被動關閉端（可以是服務器有可以是客戶端）收到了對方發來的FIN後，進入該狀態，然後發出ACK+1以迴應FIN請求（它的接收也作爲文件結束符傳遞給上層應用程序）。這個狀態實際上是說客戶端告訴服務器我沒有請求或者數據要發送了，等待看看服務器或者說是進程還有沒有數據要發送，如果有則繼續發送，如果沒有的話，就發送反向關閉指令。如果服務器大量連接是這個狀態就要去查看程序，很有可能是程序設計的問題。
- FIN_WAIT2 主動關閉端收到ACK+1後，就進入的FIN_WAIT2狀態，也就等服務器是否還有數據發來，如果服務器沒有數據了，那麼服務器就發送的反向關閉指令。也就是反向關閉連接指令FIN1+ACK1。實際上是告訴客戶端我的數據發送完了，可以關閉連接了。
- LAST_ACK 被動關閉端，發送反向結束連接請求FIN 1+ACK 1，然後進入LAST_ACK狀態，等待主動關閉端發送ACK。
- TIME_WAIT 主動關閉端收到FIN 1 +ACK 1後，並進入TIME_WAIT狀態，然後發送ACK+1，等待一段時間（2MSL）以確保服務器收到了ACK+1，然後自己進入CLOSED狀態。這個階段主要是客戶端爲了再次確認一下服務器是否可以關閉連接，因爲網絡畢竟是不可靠的。對於服務器有大量TIME_WAIT這個問題通常調整sysctl來解決。
- CLOSING 比較少見，表示等待遠程TCP對連接中斷的確認。
- CLOSED 被動關閉端在收到ACK包以後，就進入closed狀態，連接結束。
三次握手過程
客戶端：發送SYN=J請求建立連接，此時客戶端進入SYN_SENT狀態等待服務器響應
服務器：收到客戶端的SYN=J後發送SYN=K, ACK J+1表示收到建立連接請求，然後自己進入SYN_RECV狀態進行等待客戶端的最後確認
客戶端：收到服務器發來的SYN=K, ACK J+1然後發送ACK=K+1表示收到之前確認，然後自己進入ESTABLISHED狀態表示自己處於連接建立狀態
服務器：收到客戶端的ACK以後則自己進入ESTABLISHED狀態，此時雙方都處於連接建立狀態，之後進行數據傳送。
三次握手的目的：是爲了告訴對方SEQ然後服務器回覆SEQ+1，這樣發送端就知道包沒有丟；另外握手的目的是交換信息，比如：
MSS：最大傳輸包（不含TCP/IP頭），MMS+包頭就是MTU，如果MTU過大傳輸就會卡死。
SACK_PERM：是否支持Selective ack（用戶優化重傳效率），比如客戶端發送5個包給服務器，中途丟了2號包，服務器回覆的時候只能回覆2，表示2號前面的都收到了，請求重傳2號包，可是客戶端並不知道2後面的345是否收到沒有，如果支持SACK的話，那麼服務器請求重傳2的時候就可以同時告訴345已經收到，這樣客戶端只需要重傳2，如果沒有SACK機制，那麼客戶端就會重傳2345，這樣效率就低了。
半連接和全連接
未完成連接隊列：客戶端發送SYN到服務器，服務器正在等待完成三次握手，此時就會把客戶端發起的這個連接請求放在該隊列裏，也就是sync隊列。這個隊列由net.ipv4.tcp_max_syn_backlog參數決定， 系統默認2048，服務器端口狀態爲 SYNC_RCVD。
|
1 |
|
已完成連接隊列：已經完成握手的連接從SYN隊列移動到這個隊列，也就是accept隊列，默認128（其實這個隊列最終的大小是由SOMAXCONN和使用listen函數傳入參數的兩者取最小值決定的），服務器端口狀態爲ESTABLISHED，在Linux內核2.4.25之後在/etc/sysctl.conf中
net.core.somaxconn = 128直接修改。
|
1 |
|
TCP的三次握手第一步服務器收到客戶端的SYN後，把該請求放在半連接隊列中，之後回覆SYN+ACK，當客戶端收到這個信號併發送ACK之後並且服務器正常收到和處理後就把該請求從半連接隊列移動到ACCEPT隊列，進入這個隊列才能從Listen變成accept。
比如syn泛洪***就是針對syn隊列的，***方不同的建立連接，但是隻做連接的第一步，當***者收到SYN+ACK後直接丟棄，導致受***的服務器上這個隊列滿了然後其他正常請求就無法進入。
常見問題：客戶端在發送完最後一個ACK之後服務器端如果收到正常情況下應該把該鏈接從SYNC隊列移動到ACCEPT隊列，如果ACCEPT隊列滿了，默認服務器丟棄不會響應，所以從客戶端角度來看三次握手已經完成，但服務器沒有響應這個鏈接，這種情況經常出現在服務器同時收到很多鏈接請求的時候。如何確定這個問題？使用如下命令：
|
1 |
|
如果出現：
xxxxx times the listen queue of a socket overflowed（全連接隊列溢出次數）
xxxxx SYNs to LISTEN sockets ignored （半連接隊列溢出次數）
這兩個值有時你會看到一樣多，但是通常半連接溢出次數會大於等於全連接溢出次數。就說明可能會有這個問題。因爲如果這個數值一直在增加那麼就要注意了。如果想再次確認，那麼你需要修改內核參數
|
1 |
|
該參數默認爲0，參數含義看後面。修改之後客戶端再次發起連接就會收到reset信號，如果抓包收到這個信號，就證明服務器端的accept隊列滿了，你需要進行調整。比如JAVA中默認socket的backlog值大小是50.
|
1 |
|
Send-Q：表示LISTEN端口上的全連接隊列最大爲多少
Recv-Q：爲全連接隊列當前使用了多少
全連接隊列大小取決於：min(backlog, somaxconn)，前一個是在socket創建時傳入的（listen函數），somaxconn是OS級別的參數，這個somaxconn的含義請查看後面的內涵參數說明
半連接隊列大小取決於：/proc/sys/net/ipv4/tcp_max_syn_backlog 這個內核參數
Nginx默認的accept隊列是511，而且是多個進程同時監聽一個端口；Tomcat的accept隊列是100，默認短連接。
|
1 2 |
|
思考：
如果客戶端發出ACK之後剛好服務器ACCEPT隊列滿了，也就是客戶端認爲連接成功建立而實際上服務器端連接沒有準備好，而這時客戶端認爲建立好了而強行發送數據會怎麼辦呢？客戶端發送之後肯定會得不到響應，因爲服務器丟棄了，然後客戶端認爲丟失所以進行重傳，一定次數之後客戶端認爲異常，然後一直到超時最後斷開。
關於Backlog
TCP連接客戶端connect()返回並不代表TCP連接成功，有可能是服務器接收隊列滿了，系統會丟棄後續的ACK請求，
客戶端以爲建立了連接，然後就執行後續操作，然後就等待到超時。服務器則會等待ACK超時，會重傳SYN。
TCP隊列的一些問題
-
客戶端通過connect向服務器發出SYN包，客戶端會維護一個socket等待隊列，而服務器則會維護一個SYN隊列
-
此時是半連接狀態，如果socket等待隊列滿了，服務器則會丟棄，而客戶端會返回超時。只要客戶端沒有收到SYN+ACK，3秒後客戶端會再次發送，然後依然沒有收到，9秒後再繼續發送。
-
半連接SYN隊列長度由tcp_max_syn_backlog決定
-
當服務器收到客戶端SYN後，會返回SYN+ACK包，客戶端的TCP協議棧會喚醒socket等待隊列，發出connect調用
-
客戶端返回ACK後，服務器會進入一個新的叫做accept的隊列，這個隊列長度爲min(backlog,somaxconn)默認情況下somaxconn是128，表示最多有129的ESTAB的連接等待accept()，而backlog的值由int listen(int sockfd,int backlog)中的第二個參數指定，其含義是設置listen()函數最多允許多個網絡連接同時處於掛起狀態，大部分平臺都是511
-
當accept隊列滿了之後，即是客戶端繼續向服務器發送ACK包，也不會得到響應，此時服務器通過tcp_abort_on_overflow來決定如何返回，0表示直接丟棄，1表示發送RST通知；客戶端則會分別返回read timeout或者connection reset by peer。從上面可以看到有2個隊列，一個保存SYN_SEND以及SYN_RECV，另外一個accept隊列保存ESTAB的狀態。
比如客戶端通Nginx通信，Nginx立即返回ACK，但是3秒後才返回響應數據，Nginx同後端通信，發送SYN請求等待3秒後端才響應，就可能是backlog值設置過小，導致accept queue溢出，SYN被丟棄導致3s重傳。
關於ss命令中Recv-Q和Send-Q的含義？
這兩個指標在不同場景含義不同。一個是狀態處於LISTEN狀態、一個是非LISTEN的其他狀態。
LISTEN狀態
這裏的含義就是上面說的Recv-Q是當前全連接隊列使用量；Send-Q是當前對應進程SOCKET套接字最大blacklog的數量，也就是全連接隊列最大長度
非LISTEN狀態
Recv-Q：數據已經接收到本地緩存，還有多少沒有被程序取走，單位bytes
Send-Q：要發送的數據有多少還在本地緩衝區對方未確認，如果不是0可能是本地發送數據過快或者對方接收數據過慢，單位bytes
上述兩個值在非LISTEN狀態下都應該保持0或者瞬間不爲0，如果長期不爲0則可能有問題。
|
1 2 3 4 |
|
Linux內核中的TCP/IP參數
tcp_abort_on_overflow 默認爲0
TCP全連接隊列也就是accept隊列滿了之後如何處理，默認是0，也就是丟棄，可以改爲1，表示如果隊列滿了這時候有客戶端建立連接則發送一個reset包給客戶端，表示廢除這個握手。
net.core.netdev_max_backlog 默認爲128
表示當每個網絡接口接收數據包的速率比內核處理這些包的速率快時，允許發送到隊列的數據包最大數目。就是說當接口接收包的速度比內核處理的快時，那麼多出來的數據包要存放到隊列中，那麼這個隊列最大可以放多少個呢？就是這個參數設置的。
net.ipv4.tcp_max_orphans
用於設定系統中最多允許存在多少TCP套接字不被關聯到任何一個用戶文件句柄上，如果超過這個值，那麼沒有與用戶文件句柄關聯的TCP套接字就會被複位，同時給出警告信息。這個值主要是爲了防止DOS***。一般在系統內存比較大的情況下可以調大。
net.ipv4.tcp_max_syn_backlog
用於記錄尚未收到客戶端ACK信息的連接請求最大值。內存比較多可以設置大一點。也就是半連接的隊列，表示服務器收到了客戶端的SYN包同時服務器也發送了ACK+SYN，但是還沒有收到客戶端返回的ACK包，此時連接處於SYN_RECV狀態，當服務器收到客戶端的ACK包時，則刪除該半連接條目，服務器進入ESTABLISHED狀態，這時候把該連接放入Accept隊列。修改這個值可以增加更多的網絡連接，但是過大容易受到SYN泛洪***。
net.core.somaxconn
表示用於調節系統同時發起的TCP連接數，一般爲128，當高併發的情況下，如果這個值比較小，就會導致連接超時或者重傳現象。Nginx服務器中定義的NGX_LISTEN_BACKLOG默認是511，所以需要調整這個參數。當服務器收到ACK包之後，就會進入一個叫accept的隊列這個隊列的最大長度就是由這個參數決定的。表示最多可有多少個ESTAB的連接等待accept()。這個值表示已客戶端和服務器已完成三次握手的已建立連接的隊列大小。
net.ipv4.tcp_timestamps
該參數用於設置時間戳，可以避免序列號重複，在一個端口速率比較大的網卡下，遇到重複的序列號的概率還是比較大的。如果設置爲0表示禁用對TCP時間戳的支持。默認情況下，系統是允許重複的。但是對於Nginx來說還是建議關閉。
net.ipv4_tcpsynack_retries
用於設置內核放棄TCP連接之前向客戶端發送ACK+SYN包的數量，也就是重試次數。這個參數主要影響三次握手中的第二次，也就是服務器向客戶端發送SYN+前一個SYN的ACK。一般設置爲1，表示內核放棄連接之前發送一次SYN+ACK包。比如客戶端發來SYN，然後服務器回覆ACK+SYN，這時候客戶端斷線了，之後會怎麼辦呢？服務器會進行重發ACK+SYNC，Linux中默認重試5次，每次時間間隔爲上一次的一倍，1s-2s-4s-8s-16s之後再等一個32s如果還沒有客戶端響應，則服務器斷開這個連接。
net.ipv4.syn_retries
參數和上一個類似，這是這次是設置內核放棄建立連接之前發送SYN包的數量。也建議設置爲1.
net.ipv4.tcp.syncookies
修改此參數可以有效防範syn flood***。原理是在TCP服務器收到SYN包後，***者就下線，這樣默認服務器需要等待63秒之後纔會斷開這個連接（中間服務器要重試幾次），這樣服務器的SYN隊列很快就滿了。這個參數的目的就是爲了解決這個問題，當SYN隊列滿了，服務器根據預源端口、目的IP和時間戳生產一個序列號（可以叫做cookie）發送出去，如果是***者它是不會響應的，如果是真實請求則會返回這個cookie，然後服務器根據這個Cookie來建立連接就算你不在SYN隊列中也可以。默認爲0，1表示開啓。對於連接請求很大的服務器不要開啓這個參數，因爲它並不嚴謹。你應該設置三個參數來變相解決這個問題：net.ipv4_tcpsynack_retries、net.ipv4.tcp_max_syn_backlog和tcp_abort_on_overflow也就是，也就是減少重試次數、增大SYN隊列長度和如果處理不過來就拒絕。
net.ipv4.tcp_tw_reuse
表示開啓重用。允許將TIME_WAIT狀態的sockets重新用於新的TCP連接，因爲大量處於TIME_WAIT狀態很浪費資源，佔用文件描述符，默認爲0，表示關閉，設置爲1表示開啓；
net.ipv4.tcp_tw_recycle
表示開啓TCP連接中TIME_WAIT sockets的快速回收，默認爲0，表示關閉。設置爲1表示開啓。
net.ipv4.tcp_fin_timeout
表示如果套接字由本端要求關閉，這個參數決定了它保持在FIN_WAIT-2狀態的時間。默認爲2MSL。不建議修改，如果要修改可以根據實際情況而定。
net.ipv4.tcp_keepalive_time
TCP keepalive心跳包機制，用於檢測連接是否已經斷開，這個值就是設置檢測頻率的。表示當keepalive起用的時候，TCP發送keepalive消息的頻度。缺省是2小時，改爲20分鐘。
net.ipv4.ip_local_port_range = 1024 65000
表示用於向外連接的端口範圍。缺省情況下很小，改爲1024到65000。
net.ipv4.tcp_max_tw_buckets = 5000
表示系統同時保持TIME_WAIT套接字狀態的最大數量，如果超過這個數字，TIME_WAIT套接字將立刻被清除並打印警告信息。默認爲180000，改爲5000。對於Apache、Nginx等服務器，上幾行的參數可以很好地減少TIME_WAIT套接字數量，但是對於Squid，效果卻不大。此項參數可以控制TIME_WAIT套接字的最大數量，避免Squid服務器被大量的TIME_WAIT套接字拖死。