大家好,我是小林,又到了愉快的周末,我來水一水。
上周有位讀者面美團(tuán)時,被問到:TCP 四次揮手中,能不能把第二次的 ACK 報文, 放到第三次 FIN 報文一起發(fā)送?
雖然我們在學(xué)習(xí) TCP 揮手時,學(xué)到的是需要四次來完成 TCP 揮手,但是在一些情況下, TCP 四次揮手是可以變成 TCP 三次揮手的。
(資料圖片僅供參考)
而且在用 wireshark 工具抓包的時候,我們也會常看到 TCP 揮手過程是三次,而不是四次,如下圖:
先來回答為什么 RFC 文檔里定義 TCP 揮手過程是要四次?
再來回答什么情況下,什么情況會出現(xiàn)三次揮手?
為什么 TCP 揮手需要四次?TCP 四次揮手的過程如下:
具體過程:
客戶端主動調(diào)用關(guān)閉連接的函數(shù),于是就會發(fā)送 FIN 報文,這個 FIN 報文代表客戶端不會再發(fā)送數(shù)據(jù)了,進(jìn)入 FIN_WAIT_1 狀態(tài);服務(wù)端收到了 FIN 報文,然后馬上回復(fù)一個 ACK 確認(rèn)報文,此時服務(wù)端進(jìn)入 CLOSE_WAIT 狀態(tài)。在收到 FIN 報文的時候,TCP 協(xié)議棧會為 FIN 包插入一個文件結(jié)束符 EOF 到接收緩沖區(qū)中,服務(wù)端應(yīng)用程序可以通過 read 調(diào)用來感知這個 FIN 包,這個 EOF 會被放在已排隊等候的其他已接收的數(shù)據(jù)之后,所以必須要得繼續(xù) read 接收緩沖區(qū)已接收的數(shù)據(jù);接著,當(dāng)服務(wù)端在 read 數(shù)據(jù)的時候,最后自然就會讀到 EOF,接著read() 就會返回 0,這時服務(wù)端應(yīng)用程序如果有數(shù)據(jù)要發(fā)送的話,就發(fā)完數(shù)據(jù)后才調(diào)用關(guān)閉連接的函數(shù),如果服務(wù)端應(yīng)用程序沒有數(shù)據(jù)要發(fā)送的話,可以直接調(diào)用關(guān)閉連接的函數(shù),這時服務(wù)端就會發(fā)一個 FIN 包,這個 FIN 報文代表服務(wù)端不會再發(fā)送數(shù)據(jù)了,之后處于 LAST_ACK 狀態(tài);客戶端接收到服務(wù)端的 FIN 包,并發(fā)送 ACK 確認(rèn)包給服務(wù)端,此時客戶端將進(jìn)入 TIME_WAIT 狀態(tài);服務(wù)端收到 ACK 確認(rèn)包后,就進(jìn)入了最后的 CLOSE 狀態(tài);客戶端經(jīng)過 2MSL 時間之后,也進(jìn)入 CLOSE 狀態(tài);你可以看到,每個方向都需要一個 FIN 和一個 ACK,因此通常被稱為四次揮手。
為什么 TCP 揮手需要四次呢?服務(wù)器收到客戶端的 FIN 報文時,內(nèi)核會馬上回一個 ACK 應(yīng)答報文,但是服務(wù)端應(yīng)用程序可能還有數(shù)據(jù)要發(fā)送,所以并不能馬上發(fā)送 FIN 報文,而是將發(fā)送 FIN 報文的控制權(quán)交給服務(wù)端應(yīng)用程序:
如果服務(wù)端應(yīng)用程序有數(shù)據(jù)要發(fā)送的話,就發(fā)完數(shù)據(jù)后,才調(diào)用關(guān)閉連接的函數(shù);
如果服務(wù)端應(yīng)用程序沒有數(shù)據(jù)要發(fā)送的話,可以直接調(diào)用關(guān)閉連接的函數(shù),
從上面過程可知,是否要發(fā)送第三次揮手的控制權(quán)不在內(nèi)核,而是在被動關(guān)閉方(上圖的服務(wù)端)的應(yīng)用程序,因為應(yīng)用程序可能還有數(shù)據(jù)要發(fā)送,由應(yīng)用程序決定什么時候調(diào)用關(guān)閉連接的函數(shù),當(dāng)調(diào)用了關(guān)閉連接的函數(shù),內(nèi)核就會發(fā)送 FIN 報文了,所以服務(wù)端的 ACK 和 FIN 一般都會分開發(fā)送。
FIN 報文一定得調(diào)用關(guān)閉連接的函數(shù),才會發(fā)送嗎?
不一定。
如果進(jìn)程退出了,不管是不是正常退出,還是異常退出(如進(jìn)程崩潰),內(nèi)核都會發(fā)送 FIN 報文,與對方完成四次揮手。
粗暴關(guān)閉 vs 優(yōu)雅關(guān)閉前面介紹 TCP 四次揮手的時候,并沒有詳細(xì)介紹關(guān)閉連接的函數(shù),其實關(guān)閉的連接的函數(shù)有兩種函數(shù):
close 函數(shù),同時 socket 關(guān)閉發(fā)送方向和讀取方向,也就是 socket 不再有發(fā)送和接收數(shù)據(jù)的能力;shutdown 函數(shù),可以指定 socket 只關(guān)閉發(fā)送方向而不關(guān)閉讀取方向,也就是 socket 不再有發(fā)送數(shù)據(jù)的能力,但是還是具有接收數(shù)據(jù)的能力;如果客戶端是用 close 函數(shù)來關(guān)閉連接,那么在 TCP 四次揮手過程中,如果收到了服務(wù)端發(fā)送的數(shù)據(jù),由于客戶端已經(jīng)不再具有發(fā)送和接收數(shù)據(jù)的能力,所以客戶端的內(nèi)核會回 RST 報文給服務(wù)端,然后內(nèi)核會釋放連接,這時就不會經(jīng)歷完成的 TCP 四次揮手,所以我們常說,調(diào)用 close 是粗暴的關(guān)閉。
當(dāng)服務(wù)端收到 RST 后,內(nèi)核就會釋放連接,當(dāng)服務(wù)端應(yīng)用程序再次發(fā)起讀操作或者寫操作時,就能感知到連接已經(jīng)被釋放了:
如果是讀操作,則會返回 RST 的報錯,也就是我們常見的Connection reset by peer。如果是寫操作,那么程序會產(chǎn)生 SIGPIPE 信號,應(yīng)用層代碼可以捕獲并處理信號,如果不處理,則默認(rèn)情況下進(jìn)程會終止,異常退出。相對的,shutdown 函數(shù)因為可以指定只關(guān)閉發(fā)送方向而不關(guān)閉讀取方向,所以即使在 TCP 四次揮手過程中,如果收到了服務(wù)端發(fā)送的數(shù)據(jù),客戶端也是可以正常讀取到該數(shù)據(jù)的,然后就會經(jīng)歷完整的 TCP 四次揮手,所以我們常說,調(diào)用 shutdown 是優(yōu)雅的關(guān)閉。
但是注意,shutdown 函數(shù)也可以指定「只關(guān)閉讀取方向,而不關(guān)閉發(fā)送方向」,但是這時候內(nèi)核是不會發(fā)送 FIN 報文的,因為發(fā)送 FIN 報文是意味著我方將不再發(fā)送任何數(shù)據(jù),而shutdown 如果指定「不關(guān)閉發(fā)送方向」,就意味著 socket 還有發(fā)送數(shù)據(jù)的能力,所以內(nèi)核就不會發(fā)送 FIN。
什么情況會出現(xiàn)三次揮手?當(dāng)被動關(guān)閉方(上圖的服務(wù)端)在 TCP 揮手過程中,「沒有數(shù)據(jù)要發(fā)送」并且「開啟了 TCP 延遲確認(rèn)機(jī)制」,那么第二和第三次揮手就會合并傳輸,這樣就出現(xiàn)了三次揮手。
然后因為 TCP 延遲確認(rèn)機(jī)制是默認(rèn)開啟的,所以導(dǎo)致我們抓包時,看見三次揮手的次數(shù)比四次揮手還多。
什么是 TCP 延遲確認(rèn)機(jī)制?當(dāng)發(fā)送沒有攜帶數(shù)據(jù)的 ACK,它的網(wǎng)絡(luò)效率也是很低的,因為它也有 40 個字節(jié)的 IP 頭 和 TCP 頭,但卻沒有攜帶數(shù)據(jù)報文。
為了解決 ACK 傳輸效率低問題,所以就衍生出了TCP 延遲確認(rèn)。
TCP 延遲確認(rèn)的策略:
當(dāng)有響應(yīng)數(shù)據(jù)要發(fā)送時,ACK 會隨著響應(yīng)數(shù)據(jù)一起立刻發(fā)送給對方當(dāng)沒有響應(yīng)數(shù)據(jù)要發(fā)送時,ACK 將會延遲一段時間,以等待是否有響應(yīng)數(shù)據(jù)可以一起發(fā)送如果在延遲等待發(fā)送 ACK 期間,對方的第二個數(shù)據(jù)報文又到達(dá)了,這時就會立刻發(fā)送 ACK延遲等待的時間是在 Linux 內(nèi)核中定義的,如下圖:
關(guān)鍵就需要 HZ 這個數(shù)值大小,HZ 是跟系統(tǒng)的時鐘頻率有關(guān),每個操作系統(tǒng)都不一樣,在我的 Linux 系統(tǒng)中 HZ 大小是 1000,如下圖:
知道了 HZ 的大小,那么就可以算出:
最大延遲確認(rèn)時間是 200 ms (1000/5)最短延遲確認(rèn)時間是 40 ms (1000/25)怎么關(guān)閉 TCP 延遲確認(rèn)機(jī)制?如果要關(guān)閉 TCP 延遲確認(rèn)機(jī)制,可以在 Socket 設(shè)置里啟用 TCP_QUICKACK,啟用TCP_QUICKACK,就相當(dāng)于關(guān)閉 TCP 延遲確認(rèn)機(jī)制。
// 1 表示開啟 TCP_QUICKACK,即關(guān)閉 TCP 延遲確認(rèn)機(jī)制int value = 1;setsockopt(socketfd, IPPROTO_TCP, TCP_QUICKACK, (char*)& value, sizeof(int));實驗驗證
實驗一
接下來,來給大家做個實驗,驗證這個結(jié)論:
當(dāng)被動關(guān)閉方(上圖的服務(wù)端)在 TCP 揮手過程中,「沒有數(shù)據(jù)要發(fā)送」并且「開啟了 TCP 延遲確認(rèn)機(jī)制」,那么第二和第三次揮手就會合并傳輸,這樣就出現(xiàn)了三次揮手。
服務(wù)端的代碼如下,做的事情很簡單,就讀取數(shù)據(jù),然后當(dāng) read 返回 0 的時候,就馬上調(diào)用 close 關(guān)閉連接。因為 TCP 延遲確認(rèn)機(jī)制是默認(rèn)開啟的,所以不需要特殊設(shè)置。
#include 客戶端代碼如下,做的事情也很簡單,與服務(wù)端連接成功后,就發(fā)送數(shù)據(jù)給服務(wù)端,然后睡眠一秒后,就調(diào)用 close 關(guān)閉連接,所以客戶端是主動關(guān)閉方: #include 編譯服務(wù)端和客戶端的代碼: 先啟用服務(wù)端: 然后用 tcpdump 工具開始抓包,命令如下: tcpdump -i lo tcp and port 8888 -s0 -w /home/tcp_close.pcap 然后啟用客戶端,可以看到,與服務(wù)端連接成功后,發(fā)完數(shù)據(jù)就退出了。 此時,服務(wù)端的輸出: 接下來,我們來看看抓包的結(jié)果。 可以看到,TCP 揮手次數(shù)是 3 次。 所以,下面這個結(jié)論是沒問題的。 結(jié)論:當(dāng)被動關(guān)閉方(上圖的服務(wù)端)在 TCP 揮手過程中,「沒有數(shù)據(jù)要發(fā)送」并且「開啟了 TCP 延遲確認(rèn)機(jī)制(默認(rèn)會開啟)」,那么第二和第三次揮手就會合并傳輸,這樣就出現(xiàn)了三次揮手。 實驗二 我們再做一次實驗,來看看關(guān)閉 TCP 延遲確認(rèn)機(jī)制,會出現(xiàn)四次揮手嗎? 客戶端代碼保持不變,服務(wù)端代碼需要增加一點東西。 在上面服務(wù)端代碼中,增加了打開了 TCP_QUICKACK (快速應(yīng)答)機(jī)制的代碼,如下: 編譯好服務(wù)端代碼后,就開始運行服務(wù)端和客戶端的代碼,同時用 tcpdump 進(jìn)行抓包。 抓包的結(jié)果如下,可以看到是四次揮手。 所以,當(dāng)被動關(guān)閉方(上圖的服務(wù)端)在 TCP 揮手過程中,「沒有數(shù)據(jù)要發(fā)送」,同時「關(guān)閉了 TCP 延遲確認(rèn)機(jī)制」,那么就會是四次揮手。 設(shè)置 TCP_QUICKACK 的代碼,為什么要放在 read 返回 0 之后?
我也是多次實驗才發(fā)現(xiàn),在 bind 之前設(shè)置 TCP_QUICKACK 是不生效的,只有在 read 返回 0 的時候,設(shè)置 TCP_QUICKACK 才會出現(xiàn)四次揮手。
網(wǎng)上查了下資料說,設(shè)置 TCP_QUICKACK 并不是永久的,所以每次讀取數(shù)據(jù)的時候,如果想要立刻回 ACK,那就得在每次讀取數(shù)據(jù)之后,重新設(shè)置 TCP_QUICKACK。
而我這里的實驗,目的是為了當(dāng)收到客戶端的 FIN 報文(第一次揮手)后,立馬回 ACK 報文,所以就在 read 返回 0 的時候,設(shè)置 TCP_QUICKACK。
當(dāng)然,實際應(yīng)用中,沒人會在我這個位置設(shè)置 TCP_QUICKACK,因為操作系統(tǒng)都通過 TCP 延遲確認(rèn)機(jī)制幫我們把四次揮手優(yōu)化成了三次揮手了,這本來就是一件好事呀。
總結(jié)當(dāng)被動關(guān)閉方在 TCP 揮手過程中,如果「沒有數(shù)據(jù)要發(fā)送」,同時「沒有開啟 TCP_QUICKACK(默認(rèn)情況就是沒有開啟,沒有開啟 TCP_QUICKACK,等于就是在使用 TCP 延遲確認(rèn)機(jī)制)」,那么第二和第三次揮手就會合并傳輸,這樣就出現(xiàn)了三次揮手。
標(biāo)簽:
- 訊息:美團(tuán)二面:TCP 四次揮手,可以變成三次嗎?
- 當(dāng)前短訊!阿里一面:HTTP 1.0 和 HTTP 1.1 有什么區(qū)別?
- 每日熱門:酒店Wi-Fi支持遠(yuǎn)程工作的三種方式
- 實時:為什么需要NQA?NQA到底為何物?一文告訴你!
- 世界快看:為了提升網(wǎng)絡(luò)可靠性,你知道OTN光層保護(hù)有多努力嗎?
- 當(dāng)前滾動:靈魂拷問 TCP ,你要投降了嗎?
- 環(huán)球資訊:數(shù)字化轉(zhuǎn)型浪潮下,企業(yè)IT架構(gòu)應(yīng)該如何隨需而變? 原創(chuàng)
- 每日時訊!5G賦能于AI企業(yè)
- 機(jī)械革命無界14輕薄本正式發(fā)布 機(jī)身采用高奢感極強(qiáng)的銀色
- 頭條:5G網(wǎng)絡(luò)的優(yōu)勢及面臨的主要問題