字節(jié)一面:TCP 三次握手,問的好細(xì)!
大家好,我是小林。
有位讀者在面試字節(jié)時(shí),被問到這么個(gè)問題:
概括起來(lái),是這兩個(gè)問題:
TCP 三次握手中,客戶端收到的第二次握手中 ack 確認(rèn)號(hào)不是自己期望的,會(huì)發(fā)生什么?是直接丟棄 or 回 RST 報(bào)文?
什么情況下會(huì)收到不正確的 ack(第二次握手中的 ack) 呢?
問題解答
不賣關(guān)子,直接說(shuō)這個(gè)問題,是回 RST 報(bào)文。過(guò)程如下圖:
三次握手避免歷史連接
當(dāng)客戶端連續(xù)發(fā)送多次建立連接的 SYN 報(bào)文,然后在網(wǎng)絡(luò)擁堵的情況,就會(huì)發(fā)生客戶端收到不正確的 ack 的情況。具體過(guò)程如下:
- 客戶端先發(fā)送了 SYN(seq = 90) 報(bào)文,但是被網(wǎng)絡(luò)阻塞了,服務(wù)端并沒有收到,接著客戶端又重新發(fā)送了 SYN(seq = 100) 報(bào)文,注意不是重傳 SYN,重傳的 SYN 的序列號(hào)是一樣的。
- 「舊 SYN 報(bào)文」比「最新的 SYN 」 報(bào)文早到達(dá)了服務(wù)端,那么此時(shí)服務(wù)端就會(huì)回一個(gè) SYN + ACK 報(bào)文給客戶端,此報(bào)文的確認(rèn)號(hào)是 91(90+1)。
- 客戶端收到后,發(fā)行自己期望收到的確認(rèn)號(hào)應(yīng)該是 100+1,而不是 90 + 1,于是就會(huì)回 RST 報(bào)文。
- 服務(wù)端收到 RST 報(bào)文后,就會(huì)中止連接。
- 后續(xù)最新的 SYN 抵達(dá)了服務(wù)端后,客戶端與服務(wù)端就可以正常的完成三次握手了。
上述中的「舊 SYN 報(bào)文」稱為歷史連接,TCP 使用三次握手建立連接的最主要原因就是防止「歷史連接」初始化了連接。
我們也可以從 RFC 793 知道 TCP 連接使用三次握手的首要原因:
The principle reason for the three-way handshake is to prevent old duplicate connection initiations from causing confusion.
簡(jiǎn)單來(lái)說(shuō),三次握手的首要原因是為了防止舊的重復(fù)連接初始化造成混亂。RFC 給出的三次握手防止歷史連接的案例圖如下:
RFC 793
如果是兩次握手連接,就無(wú)法阻止歷史連接,那為什么 TCP 兩次握手為什么無(wú)法阻止歷史連接呢?
我先直接說(shuō)結(jié)論,主要是因?yàn)樵趦纱挝帐值那闆r下,「被動(dòng)發(fā)起方」沒有中間狀態(tài)給「主動(dòng)發(fā)起方」來(lái)阻止歷史連接,導(dǎo)致「被動(dòng)發(fā)起方」可能建立一個(gè)歷史連接,造成資源浪費(fèi)。
你想想,兩次握手的情況下,「被動(dòng)發(fā)起方」在收到 SYN 報(bào)文后,就進(jìn)入 ESTABLISHED 狀態(tài),意味著這時(shí)可以給對(duì)方發(fā)送數(shù)據(jù)給,但是「主動(dòng)發(fā)」起方此時(shí)還沒有進(jìn)入 ESTABLISHED 狀態(tài),假設(shè)這次是歷史連接,主動(dòng)發(fā)起方判斷到此次連接為歷史連接,那么就會(huì)回 RST 報(bào)文來(lái)斷開連接,而「被動(dòng)發(fā)起方」在第一次握手的時(shí)候就進(jìn)入 ESTABLISHED 狀態(tài),所以它可以發(fā)送數(shù)據(jù)的,但是它并不知道這個(gè)是歷史連接,它只有在收到 RST 報(bào)文后,才會(huì)斷開連接。
兩次握手無(wú)法阻止歷史連接
可以看到,上面這種場(chǎng)景下,「被動(dòng)發(fā)起方」在向「主動(dòng)發(fā)起方」發(fā)送數(shù)據(jù)前,并沒有阻止掉歷史連接,導(dǎo)致「被動(dòng)發(fā)起方」建立了一個(gè)歷史連接,又白白發(fā)送了數(shù)據(jù),妥妥地浪費(fèi)了「被動(dòng)發(fā)起方」的資源。
因此,要解決這種現(xiàn)象,最好就是在「被動(dòng)發(fā)起方」發(fā)送數(shù)據(jù)前,也就是建立連接之前,要阻止掉歷史連接,這樣就不會(huì)造成資源浪費(fèi),而要實(shí)現(xiàn)這個(gè)功能,就需要三次握手。
源碼分析
我說(shuō)回 RST 就回 RST 嗎?當(dāng)然不是了,肯定得用源碼證明我說(shuō)的這個(gè)結(jié)論。
聽到要源碼分析,可能有的同學(xué)就慫了。
其實(shí)要分析我們今天這個(gè)問題,只要懂 if else 就行了,我也會(huì)用中文來(lái)表述代碼的邏輯,所以單純看我的文字也是可以的。
這次我們重點(diǎn)分析的是,在 SYN_SENT 狀態(tài)下,收到不正確的確認(rèn)號(hào)的 syn+ack 報(bào)文是如何處理的。
處于 SYN_SENT 狀態(tài)下的客戶端,在收到服務(wù)端的 syn+ack 報(bào)文后,最終會(huì)調(diào)用 tcp_rcv_state_process,在這里會(huì)根據(jù) TCP 狀態(tài)做對(duì)應(yīng)的處理,這里我們只關(guān)注 SYN_SENT 狀態(tài)。
可以看到,接下來(lái),會(huì)繼續(xù)調(diào)用 tcp_rcv_synsent_state_process 函數(shù)。
從上面的函數(shù),就可以得知了,客戶端在 SYN_SENT 狀態(tài)下,收到不正確的確認(rèn)號(hào)的 syn+ack 報(bào)文會(huì)回 RST 報(bào)文。
小結(jié)
TCP 三次握手中,客戶端收到的第二次握手中 ack 確認(rèn)號(hào)不是自己期望的,會(huì)發(fā)生什么?是直接丟棄 or 回 RST 報(bào)文?
回 RST 報(bào)文。
什么情況下會(huì)收到不正確的 ack(第二次握手中的 ack) 呢?
當(dāng)客戶端發(fā)起多次 SYN 報(bào)文,然后網(wǎng)絡(luò)擁堵的情況下,「舊的 SYN 報(bào)文」比「新的 SYN 報(bào)文」早抵達(dá)服務(wù)端,此時(shí)服務(wù)端就會(huì)按照收到的「舊的 SYN 報(bào)文」回復(fù) syn+ack 報(bào)文,而此報(bào)文的確認(rèn)號(hào)并不是客戶端期望收到的,于是客戶端就會(huì)回 RST 報(bào)文。