關(guān)于兩個(gè)隊(duì)列
首先我們必須明白么抗，處于“LISTENING”狀態(tài)的TCP socket赘那，有兩個(gè)獨(dú)立的隊(duì)列：
- SYN隊(duì)列（SYN Queue）
- Accept隊(duì)列（Accept Queue）
這兩個(gè)術(shù)語(yǔ)有時(shí)也被稱為“reqsk_queue”，“ACK backlog”失息，“l(fā)isten backlog”矮台，甚至“TCP backlog”，但是這篇文章中我們使用上面兩個(gè)術(shù)語(yǔ)以免造成混淆根时。
SYN隊(duì)列
SYN隊(duì)列存儲(chǔ)了收到SYN包的連接（對(duì)應(yīng)內(nèi)核代碼的結(jié)構(gòu)體：struct inet_request_sock）瘦赫。它的職責(zé)是回復(fù)SYN+ACK包，并且在沒(méi)有收到ACK包時(shí)重傳蛤迎，直到超時(shí)确虱。在Linux下，重傳的次數(shù)為：
$ sysctl net.ipv4.tcp_synack_retries
net.ipv4.tcp_synack_retries = 5
文檔中對(duì)tcp_synack_retries的描述如下：
tcp_synack_retries - int整型
對(duì)于一個(gè)被動(dòng)TCP連接替裆，重傳SYNACKs的次數(shù)校辩。該值不能超過(guò)255窘问。
默認(rèn)值為5，如果初始RTO是1秒宜咒，那么對(duì)應(yīng)的最后一次重傳是31秒惠赫。
對(duì)應(yīng)的最后一次超時(shí)是63秒之后。
發(fā)送完SYN+ACK之后故黑，SYN隊(duì)列等待從客戶端發(fā)出的ACK包（也即三次握手的最后一個(gè)包）儿咱。當(dāng)收到ACK包時(shí)，首先找到對(duì)應(yīng)的SYN隊(duì)列，再在對(duì)應(yīng)的SYN隊(duì)列中檢查相關(guān)的數(shù)據(jù)看是否匹配，如果匹配哄芜，內(nèi)核將該連接相關(guān)的數(shù)據(jù)從SYN隊(duì)列中移除，創(chuàng)建一個(gè)完整的連接（對(duì)應(yīng)內(nèi)核代碼的結(jié)構(gòu)體：struct inet_sock）钳宪，并將這個(gè)連接加入Accept隊(duì)列。
Accept隊(duì)列
Accept隊(duì)列中存放的是已建立好的連接扳炬，也即等待被上層應(yīng)用程序取走的連接吏颖。當(dāng)進(jìn)程調(diào)用accept()，這個(gè)socket從隊(duì)列中取出恨樟，傳遞給上層應(yīng)用程序半醉。
這就是Linux處理SYN包的一個(gè)簡(jiǎn)單描述。順便一提厌杜，當(dāng)socket開(kāi)啟了TCP_DEFER_ACCEPT和TCP_FASTOPEN時(shí)，工作方式將會(huì)有細(xì)微不同计螺，本文不做介紹夯尽。
隊(duì)列大小限制
應(yīng)用程序通過(guò)調(diào)用系統(tǒng)調(diào)用listen(2)，傳入backlog參數(shù)登馒，來(lái)設(shè)置SYN隊(duì)列和Accept隊(duì)列的最大大小匙握。比如下面這樣，將SYN隊(duì)列和Accept隊(duì)列的最大大小同時(shí)設(shè)置為1024：
listen(sfd, 1024)
注意陈轿，在4.3版本之前的內(nèi)核圈纺，SYN隊(duì)列的大小是用另一種方式計(jì)算。
SYN隊(duì)列的最大大小以前是用net.ipv4.tcp_max_syn_backlog來(lái)配置麦射，但是現(xiàn)在已經(jīng)不再使用了《耆ⅲ現(xiàn)在用net.core.somaxconn來(lái)同時(shí)表示SYN隊(duì)列和Accept隊(duì)列的最大大小。在我們的服務(wù)器上潜秋，我們將它設(shè)置為16k：
$ sysctl net.core.somaxconn
net.core.somaxconn = 16384
隊(duì)列設(shè)置為多大合適
知道了上面這些信息后蛔琅，你可能會(huì)問(wèn)，隊(duì)列設(shè)置為多大合適峻呛？
答案是：看情況罗售。對(duì)于大多數(shù)的TCP服務(wù)來(lái)說(shuō)辜窑，這并不太重要。比如寨躁，Go語(yǔ)言1.11版本之前穆碎，并沒(méi)有提供設(shè)置隊(duì)列大小的方法。
盡管如此职恳，也存在一些合理的原因所禀，需要增大隊(duì)列的大小：
- 當(dāng)建立連接的請(qǐng)求速度確實(shí)很大時(shí)话肖，即使是對(duì)于一個(gè)高性能的服務(wù)來(lái)說(shuō)北秽，SYN隊(duì)列也可能需要設(shè)置的大一些。
- SYN隊(duì)列的大小最筒，換言之就是等待ACK包的連接數(shù)贺氓。也即與客戶端的平均往返時(shí)間越大，堆積在SYN隊(duì)列中的連接就越多床蜘。對(duì)于那些大部分客戶端都距離服務(wù)器很遠(yuǎn)的場(chǎng)景辙培，比如說(shuō)往返時(shí)間幾百毫秒以上，可以將隊(duì)列大小設(shè)置的大一些邢锯。
-
TCP_DEFER_ACCEPT選項(xiàng)如果打開(kāi)了扬蕊，會(huì)導(dǎo)致socket在SYN-RECV狀態(tài)下維持更長(zhǎng)的時(shí)間，也即增大了處于SYN隊(duì)列中的時(shí)間丹擎。
但是尾抑，將backlog設(shè)置的過(guò)大也會(huì)帶來(lái)不好的影響：
- SYN隊(duì)列中的每一個(gè)槽位都需要占用一些內(nèi)存。當(dāng)遇到SYN Flood攻擊時(shí)蒂培，我們沒(méi)有必要為這些發(fā)起攻擊的包浪費(fèi)資源再愈。SYN隊(duì)列中的
inet_request_sock結(jié)構(gòu)體，在4.14內(nèi)核下护戳，每個(gè)將占用256字節(jié)的內(nèi)存翎冲。
linux下，如果想查看SYN隊(duì)列的當(dāng)前狀態(tài)媳荒，我們可以使用ss命令來(lái)查詢SYN-RECV狀態(tài)的socket抗悍。比如如下執(zhí)行結(jié)果，表示80端口的SYN隊(duì)列中當(dāng)前有119個(gè)元素钳枕，443端口則為78缴渊。
$ ss -n state syn-recv sport = :80 | wc -l
119
$ ss -n state syn-recv sport = :443 | wc -l
78
還可以通過(guò)我們的SystemTap腳本來(lái)觀察這個(gè)數(shù)據(jù)：resq.stp
假如程序調(diào)用accept()不夠快？
如果程序調(diào)用accept()不夠快會(huì)發(fā)生什么呢鱼炒？
- 后續(xù)收到的SYN包疟暖，不會(huì)被SYN隊(duì)列處理
- 后續(xù)收到的（用于建立連接的）ACK包，不會(huì)被SYN隊(duì)列處理
-
TcpExtListenOverflows / LINUX_MIB_LISTENOVERFLOWS計(jì)數(shù)增加 -
TcpExtListenDrops / LINUX_MIB_LISTENDROPS計(jì)數(shù)增加
發(fā)生這種情況時(shí)，我們只能寄希望于程序的處理性能稍后能恢復(fù)正常俐巴，客戶端重新發(fā)送被服務(wù)端丟棄的包骨望。
內(nèi)核的這種表現(xiàn)對(duì)于大部分服務(wù)來(lái)說(shuō)是可接受的。順便一提欣舵，可以通過(guò)調(diào)整net.ipv4.tcp_abort_on_overflow這個(gè)全局參數(shù)來(lái)修改這種表現(xiàn)擎鸠，但是最好還是不要改這個(gè)參數(shù)。
可以通過(guò)查看nstat的計(jì)數(shù)來(lái)觀察Accept隊(duì)列溢出的狀態(tài)：
$ nstat -az TcpExtListenDrops
TcpExtListenDrops 49199 0.0
但是這是一個(gè)全局的計(jì)數(shù)缘圈。觀察起來(lái)不夠直觀劣光，比如有時(shí)我們觀察到它在增長(zhǎng)，但是所有的服務(wù)程序看起來(lái)都是正常的糟把。此時(shí)我們可以使用ss命令來(lái)觀察單個(gè)監(jiān)聽(tīng)端口的Accept隊(duì)列大芯钗小：
$ ss -plnt sport = :6443|cat
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 1024 *:6443 *:*
Recv-Q這一列顯示的是處于Accept隊(duì)列中的socket數(shù)量，Send-Q顯示的是隊(duì)列的最大大小遣疯。在上面的例子中雄可，我們發(fā)現(xiàn)并沒(méi)有未被程序accept()的socket，但是我們依然發(fā)現(xiàn)ListenDrops計(jì)數(shù)在增長(zhǎng)缠犀。
這是因?yàn)槲覀兊某绦蛑皇侵芷谛缘亩虝嚎ㄗ〔惶幚硇碌倪B接数苫，而非永久性的不處理，過(guò)段時(shí)間程序又恢復(fù)了正常辨液。這種情況下虐急，用ss命令比較難觀察這種現(xiàn)象，因此我們寫(xiě)了一個(gè)SystemTap腳本滔迈，它會(huì)hook進(jìn)內(nèi)核止吁，把被丟棄的SYN包打印出來(lái)：
$ sudo stap -v acceptq.stp
time (us) acceptq qmax local addr remote_addr
1495634198449075 1025 1024 0.0.0.0:6443 10.0.1.92:28585
1495634198449253 1025 1024 0.0.0.0:6443 10.0.1.92:50500
1495634198450062 1025 1024 0.0.0.0:6443 10.0.1.92:65434
...
通過(guò)上面的操作，可以觀察到哪些SYN包被ListenDrops影響了燎悍。從而我們也就可以知道哪些程序在丟失連接敬惦。
英文原文來(lái)自cloudflare的博客，地址如下：
SYN packet handling in the wild间涵。
英文原文在后半部分還介紹了SYN Cookies對(duì)于SYN Flood的影響仁热，我在本文中沒(méi)有翻譯榜揖，感興趣的可以看看原文勾哩。
本文原始地址： https://pengrl.com/p/46323/
聲明： 本文后續(xù)所有修改都會(huì)第一時(shí)間在原始地址更新。本文歡迎任何形式轉(zhuǎn)載举哟，轉(zhuǎn)載時(shí)注明原始出處即可思劳。
