連接隊(duì)列

在外部請(qǐng)求到達(dá)時(shí)，被服務(wù)程序最終感知到前，連接可能處于SYN_RCVD狀態(tài)或是ESTABLISHED狀態(tài)，但還未被應(yīng)用程序接受。

對(duì)應(yīng)地，服務(wù)器端也會(huì)維護(hù)兩種隊(duì)列，處于SYN_RCVD狀態(tài)的半連接隊(duì)列，而處于ESTABLISHED狀態(tài)但仍未被應(yīng)用程序accept的為全連接隊(duì)列。如果這兩個(gè)隊(duì)列滿了之后，就會(huì)出現(xiàn)各種丟包的情形。

半連接隊(duì)列滿了

在三次握手協(xié)議中，服務(wù)器維護(hù)一個(gè)半連接隊(duì)列，該隊(duì)列為每個(gè)客戶端的SYN包開設(shè)一個(gè)條目(服務(wù)端在接收到SYN包的時(shí)候，就已經(jīng)創(chuàng)建了request_sock結(jié)構(gòu)，存儲(chǔ)在半連接隊(duì)列中)，該條目表明服務(wù)器已收到SYN包，并向客戶發(fā)出確認(rèn)，正在等待客戶的確認(rèn)包。這些條目所標(biāo)識(shí)的連接在服務(wù)器處于Syn_RECV狀態(tài)，當(dāng)服務(wù)器收到客戶的確認(rèn)包時(shí)，刪除該條目，服務(wù)器進(jìn)入ESTABLISHED狀態(tài)。

目前，Linux下默認(rèn)會(huì)進(jìn)行5次重發(fā)SYN-ACK包，重試的間隔時(shí)間從1s開始，下次的重試間隔時(shí)間是前一次的雙倍，5次的重試時(shí)間間隔為1s, 2s, 4s, 8s, 16s, 總共31s, 稱為指數(shù)退避，第5次發(fā)出后還要等32s才知道第5次也超時(shí)了，所以，總共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 63s, TCP才會(huì)把斷開這個(gè)連接。由于，SYN超時(shí)需要63秒，那么就給攻擊者一個(gè)攻擊服務(wù)器的機(jī)會(huì)，攻擊者在短時(shí)間內(nèi)發(fā)送大量的SYN包給Server(俗稱SYN flood攻擊)，用于耗盡Server的SYN隊(duì)列。對(duì)于應(yīng)對(duì)SYN 過(guò)多的問(wèn)題，linux提供了幾個(gè)TCP參數(shù)：tcp_syncookies、tcp_synack_retries、tcp_max_syn_backlog、tcp_abort_on_overflow 來(lái)調(diào)整應(yīng)對(duì)。

全連接隊(duì)列滿了

當(dāng)?shù)谌挝帐謺r(shí)，當(dāng)server接收到ACK包之后，會(huì)進(jìn)入一個(gè)新的叫 accept 的隊(duì)列。

當(dāng)accept隊(duì)列滿了之后，即使client繼續(xù)向server發(fā)送ACK的包，也會(huì)不被響應(yīng)，此時(shí)ListenOverflows+1，同時(shí)server通過(guò)tcp_abort_on_overflow來(lái)決定如何返回，0表示直接丟棄該ACK，1表示發(fā)送RST通知client；相應(yīng)的，client則會(huì)分別返回read timeout?或者?connection reset by peer。另外，tcp_abort_on_overflow是0的話，server過(guò)一段時(shí)間再次發(fā)送syn+ack給client（也就是重新走握手的第二步），如果client超時(shí)等待比較短，就很容易異常了。而客戶端收到多個(gè) SYN ACK 包，則會(huì)認(rèn)為之前的 ACK 丟包了。于是促使客戶端再次發(fā)送 ACK ，在 accept隊(duì)列有空閑的時(shí)候最終完成連接。若 accept隊(duì)列始終滿員，則最終客戶端收到 RST 包（此時(shí)服務(wù)端發(fā)送syn+ack的次數(shù)超出了tcp_synack_retries）。

服務(wù)端僅僅只是創(chuàng)建一個(gè)定時(shí)器，以固定間隔重傳syn和ack到服務(wù)端

命令

netstat -s命令

上面看到的 667399 times ，表示全連接隊(duì)列溢出的次數(shù)，隔幾秒鐘執(zhí)行下，如果這個(gè)數(shù)字一直在增加的話肯定全連接隊(duì)列偶爾滿了。

查看 Accept queue 是否有溢出

ss命令

如果State是listen狀態(tài)，Send-Q 表示第三列的listen端口上的全連接隊(duì)列最大為50，第一列Recv-Q為全連接隊(duì)列當(dāng)前使用了多少。
非 LISTEN 狀態(tài)中 Recv-Q 表示 receive queue 中的 bytes 數(shù)量；Send-Q 表示 send queue 中的 bytes 數(shù)值。

小結(jié)

當(dāng)外部連接請(qǐng)求到來(lái)時(shí)，TCP模塊會(huì)首先查看max_syn_backlog，如果處于SYN_RCVD狀態(tài)的連接數(shù)目超過(guò)這一閾值，進(jìn)入的連接會(huì)被拒絕。根據(jù)tcp_abort_on_overflow字段來(lái)決定是直接丟棄，還是直接reset.

從服務(wù)端來(lái)說(shuō)，三次握手中，第一步server接受到client的syn后，把相關(guān)信息放到半連接隊(duì)列中，同時(shí)回復(fù)syn+ack給client. 第三步當(dāng)收到客戶端的ack, 將連接加入到全連接隊(duì)列。

一般，全連接隊(duì)列比較小，會(huì)先滿，此時(shí)半連接隊(duì)列還沒(méi)滿。如果這時(shí)收到syn報(bào)文，則會(huì)進(jìn)入半連接隊(duì)列，沒(méi)有問(wèn)題。但是如果收到了三次握手中的第3步(ACK)，則會(huì)根據(jù)tcp_abort_on_overflow字段來(lái)決定是直接丟棄，還是直接reset.此時(shí)，客戶端發(fā)送了ACK, 那么客戶端認(rèn)為三次握手完成，它認(rèn)為服務(wù)端已經(jīng)準(zhǔn)備好了接收數(shù)據(jù)的準(zhǔn)備。但此時(shí)服務(wù)端可能因?yàn)槿B接隊(duì)列滿了而無(wú)法將連接放入，會(huì)重新發(fā)送第2步的syn+ack, 如果這時(shí)有數(shù)據(jù)到來(lái)，服務(wù)器TCP模塊會(huì)將數(shù)據(jù)存入隊(duì)列中。一段時(shí)間后，client端沒(méi)收到回復(fù)，超時(shí)，連接異常，client會(huì)主動(dòng)關(guān)閉連接。

“三次握手，四次揮手”redis實(shí)例分析

1. 我在dev機(jī)器上部署redis服務(wù)，端口號(hào)為6379,

2. 通過(guò)tcpdump工具獲取數(shù)據(jù)包，使用如下命令

1. 在dev2機(jī)器上用redis-cli訪問(wèn)dev:6379, 發(fā)送一個(gè)ping, 得到回復(fù)pong

2. 停止抓包，用tcpdump讀取捕獲到的數(shù)據(jù)包

共收到了7個(gè)包。

抓到的是IP數(shù)據(jù)包，IP數(shù)據(jù)包分為IP頭部和IP數(shù)據(jù)部分，IP數(shù)據(jù)部分是TCP頭部加TCP數(shù)據(jù)部分。

IP的數(shù)據(jù)格式為：

它由固定長(zhǎng)度20B+可變長(zhǎng)度構(gòu)成。

對(duì)著IP頭部格式，來(lái)拆解數(shù)據(jù)包的具體含義。

剩余的數(shù)據(jù)部分即為TCP協(xié)議相關(guān)的。TCP也是20B固定長(zhǎng)度+可變長(zhǎng)度部分。

可變長(zhǎng)度部分，協(xié)議如下：

這樣第一個(gè)包分析完了。dev2向dev發(fā)送SYN請(qǐng)求。也就是三次握手中的第一次了。
SYN seq(c)=4133153791

第二個(gè)包，dev響應(yīng)連接，ack=4133153792. 表明dev下次準(zhǔn)備接收這個(gè)序號(hào)的包，用于tcp字節(jié)注的順序控制。dev（也就是server端）的初始序號(hào)為seq=4264776963, syn=1.
SYN ack=seq(c)+1 seq(s)=4264776963

第三個(gè)包，client包確認(rèn)，這里使用了相對(duì)值應(yīng)答。seq=4133153792, 等于第二個(gè)包的ack. ack=4264776964.
ack=seq(s)+1, seq=seq(c)+1
至此，三次握手完成。接下來(lái)就是發(fā)送ping和pong的數(shù)據(jù)了。

接著第四個(gè)包。

tcp首部長(zhǎng)度為32B, 可選長(zhǎng)度為12B. IP報(bào)文的總長(zhǎng)度為66B, 首部長(zhǎng)度為20B, 因此TCP數(shù)據(jù)部分長(zhǎng)度為14B. seq=0xf65a ec00=4133153792
ACK, PSH. 數(shù)據(jù)部分為2a31 0d0a 2434 0d0a 7069 6e67 0d0a

dev2向dev發(fā)送了ping數(shù)據(jù)，第四個(gè)包完畢。

第五個(gè)包，dev2向dev發(fā)送ack響應(yīng)。
序列號(hào)為0xfe33 5504=4264776964, ack確認(rèn)號(hào)為0xf65a ec0e=4133153806=(4133153792+14).

第六個(gè)包，dev向dev2響應(yīng)pong消息。序列號(hào)fe33 5504，確認(rèn)號(hào)f65a ec0e, TCP頭部可選長(zhǎng)度為12B, IP數(shù)據(jù)報(bào)總長(zhǎng)度為59B, 首部長(zhǎng)度為20B, 因此TCP數(shù)據(jù)長(zhǎng)度為7B.
數(shù)據(jù)部分2b50 4f4e 470d 0a, 翻譯過(guò)來(lái)就是+PONGrn.

至此，Redis客戶端和Server端的三次握手過(guò)程分析完畢。

總結(jié)

“三次握手，四次揮手”看似簡(jiǎn)單，但是深究進(jìn)去，還是可以延伸出很多知識(shí)點(diǎn)的。比如半連接隊(duì)列、全連接隊(duì)列等等。以前關(guān)于TCP建立連接、關(guān)閉連接的過(guò)程很容易就會(huì)忘記，可能是因?yàn)橹皇撬烙浻脖沉藥讉€(gè)過(guò)程，沒(méi)有深入研究背后的原理。

所以，“三次握手，四次揮手”你真的懂了嗎？

參考資料

【redis】https://segmentfault.com/a/1190000015044878
【tcp option】https://blog.csdn.net/wdscq1234/article/details/52423272
【滑動(dòng)窗口】https://www.zhihu.com/question/32255109
【全連接隊(duì)列】http://jm.taobao.org/2017/05/25/525-1/
【client fooling】 https://github.com/torvalds/linux/commit/5ea8ea2cb7f1d0db15762c9b0bb9e7330425a071
【backlog RECV_Q】http://blog.51cto.com/59090939/1947443
【定時(shí)器】https://www.cnblogs.com/menghuanbiao/p/5212131.html
【隊(duì)列圖示】https://www.itcodemonkey.com/article/5834.html
【tcp flood攻擊】https://www.cnblogs.com/hubavyn/p/4477883.html
【MSS MTU】https://blog.csdn.net/LoseInVain/article/details/53694265