網絡連接狀態

網絡連接狀態（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。

cat /proc/sys/net/ipv4/tcp_max_syn_backlog

已完成連接隊列：已經完成握手的連接從SYN隊列移動到這個隊列，也就是accept隊列，默認128（其實這個隊列最終的大小是由SOMAXCONN和使用listen函數傳入參數的兩者取最小值決定的），服務器端口狀態為ESTABLISHED，在Linux內核2.4.25之后在/etc/sysctl.conf中

net.core.somaxconn = 128直接修改。

cat /proc/sys/net/core/somaxconn

TCP的三次握手第一步服務器收到客戶端的SYN后，把該請求放在半連接隊列中，之后回復SYN+ACK，當客戶端收到這個信號并發送ACK之后并且服務器正常收到和處理后就把該請求從半連接隊列移動到ACCEPT隊列，進入這個隊列才能從Listen變成accept。

比如syn泛洪***就是針對syn隊列的，***方不同的建立連接，但是只做連接的第一步，當***者收到SYN+ACK后直接丟棄，導致受***的服務器上這個隊列滿了然后其他正常請求就無法進入。

常見問題：客戶端在發送完最后一個ACK之后服務器端如果收到正常情況下應該把該鏈接從SYNC隊列移動到ACCEPT隊列，如果ACCEPT隊列滿了，默認服務器丟棄不會響應，所以從客戶端角度來看三次握手已經完成，但服務器沒有響應這個鏈接，這種情況經常出現在服務器同時收到很多鏈接請求的時候。如何確定這個問題？使用如下命令：

netstat-s|egrep"listen|LISTEN"

如果出現：

xxxxxtimesthelistenqueueofasocketoverflowed（全連接隊列溢出次數）

xxxxxSYNs to LISTEN sockets ignored （半連接隊列溢出次數）

這兩個值有時你會看到一樣多，但是通常半連接溢出次數會大于等于全連接溢出次數。就說明可能會有這個問題。因為如果這個數值一直在增加那么就要注意了。如果想再次確認，那么你需要修改內核參數

echo '1' > /proc/sys/net/ipv4/tcp_abort_on_overflow

該參數默認為0，參數含義看后面。修改之后客戶端再次發起連接就會收到reset信號，如果抓包收到這個信號，就證明服務器端的accept隊列滿了，你需要進行調整。比如JAVA中默認socket的backlog值大小是50.

ss -lnt

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，默認短連接。

# 查看Accept隊列溢出情況，如果當前沒有溢出則沒有任何返回值 netstat -s | grep TCPBacklogDrop

思考：

如果客戶端發出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則可能有問題。

# 統計各種狀態的值 netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' # 統計特定進程的TCP狀態 netstat -ntap | grep '3141' | awk '{++S[$6]} END {for(a in S) print a, S[a]}'

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套接字拖死。

鏈接：https://www.cnblogs.com/rexcheny/p/9381433.html