54、瀏覽器在與服務(wù)器建立了一個(gè) TCP 連接后是否會(huì)在一個(gè) HTTP 請(qǐng)求完成后斷開(kāi)？什么情況下會(huì)斷開(kāi)？

在 HTTP／1．0 中，一個(gè)服務(wù)器在發(fā)送完一個(gè) HTTP 響應(yīng)后，會(huì)斷開(kāi) TCP 鏈接。但是這樣每次請(qǐng)求都會(huì)重新建立和斷開(kāi) TCP 連接，代價(jià)過(guò)大。所以雖然標(biāo)準(zhǔn)中沒(méi)有設(shè)定，某些服務(wù)器對(duì) Connection： keep－alive 的 Header 進(jìn)行了支持。意思是說(shuō)，完成這個(gè) HTTP 請(qǐng)求之后，不要斷開(kāi) HTTP 請(qǐng)求使用的 TCP 連接。這樣的好處是連接可以被重新使用，之后發(fā)送 HTTP 請(qǐng)求的時(shí)候不需要重新建立 TCP 連接，以及如果維持連接，那么 SSL 的開(kāi)銷(xiāo)也可以避免。

持久連接：既然維持 TCP 連接好處這么多，HTTP／1．1 就把 Connection 頭寫(xiě)進(jìn)標(biāo)準(zhǔn)，并且默認(rèn)開(kāi)啟持久連接，除非請(qǐng)求中寫(xiě)明 Connection： close，那么瀏覽器和服務(wù)器之間是會(huì)維持一段時(shí)間的 TCP 連接，不會(huì)一個(gè)請(qǐng)求結(jié)束就斷掉。

默認(rèn)情況下建立 TCP 連接不會(huì)斷開(kāi)，只有在請(qǐng)求報(bào)頭中聲明 Connection： close 才會(huì)在請(qǐng)求完成后關(guān)閉連接。

55、三次握手相關(guān)內(nèi)容

三次握手（Three－way Handshake）其實(shí)就是指建立一個(gè)TCP連接時(shí)，需要客戶(hù)端和服務(wù)器總共發(fā)送3個(gè)包。進(jìn)行三次握手的主要作用就是為了確認(rèn)雙方的接收能力和發(fā)送能力是否正常、指定自己的初始化序列號(hào)為后面的可靠性傳送做準(zhǔn)備。實(shí)質(zhì)上其實(shí)就是連接服務(wù)器指定端口，建立TCP連接，并同步連接雙方的序列號(hào)和確認(rèn)號(hào)，交換TCP窗口大小信息。

第一種回答

剛開(kāi)始客戶(hù)端處于 Closed 的狀態(tài)，服務(wù)端處于 Listen 狀態(tài)，進(jìn)行三次握手：

第一次握手：客戶(hù)端給服務(wù)端發(fā)一個(gè) SYN 報(bào)文，并指明客戶(hù)端的初始化序列號(hào) ISN（c）。此時(shí)客戶(hù)端處于 SYN＿SEND 狀態(tài)。

首部的同步位SYN＝1，初始序號(hào)seq＝x，SYN＝1的報(bào)文段不能攜帶數(shù)據(jù)，但要消耗掉一個(gè)序號(hào)。

第二次握手：服務(wù)器收到客戶(hù)端的 SYN 報(bào)文之后，會(huì)以自己的 SYN 報(bào)文作為應(yīng)答，并且也是指定了自己的初始化序列號(hào) ISN（s）。同時(shí)會(huì)把客戶(hù)端的 ISN ＋ 1 作為ACK 的值，表示自己已經(jīng)收到了客戶(hù)端的 SYN，此時(shí)服務(wù)器處于 SYN＿RCVD 的狀態(tài)。

在確認(rèn)報(bào)文段中SYN＝1，ACK＝1，確認(rèn)號(hào)ack＝x＋1，初始序號(hào)seq＝y(tǒng)。

第三次握手：客戶(hù)端收到 SYN 報(bào)文之后，會(huì)發(fā)送一個(gè) ACK 報(bào)文，當(dāng)然，也是一樣把服務(wù)器的 ISN ＋ 1 作為 ACK 的值，表示已經(jīng)收到了服務(wù)端的 SYN 報(bào)文，此時(shí)客戶(hù)端處于 ESTABLISHED 狀態(tài)。服務(wù)器收到 ACK 報(bào)文之后，也處于 ESTABLISHED 狀態(tài)，此時(shí)，雙方已建立起了連接。

確認(rèn)報(bào)文段ACK＝1，確認(rèn)號(hào)ack＝y(tǒng)＋1，序號(hào)seq＝x＋1（初始為seq＝x，第二個(gè)報(bào)文段所以要＋1），ACK報(bào)文段可以攜帶數(shù)據(jù)，不攜帶數(shù)據(jù)則不消耗序號(hào)。

發(fā)送第一個(gè)SYN的一端將執(zhí)行主動(dòng)打開(kāi)（active open），接收這個(gè)SYN并發(fā)回下一個(gè)SYN的另一端執(zhí)行被動(dòng)打開(kāi)（passive open）。

在socket編程中，客戶(hù)端執(zhí)行connect（）時(shí)，將觸發(fā)三次握手。

第二種回答初始狀態(tài)：客戶(hù)端處于 closed（關(guān)閉）狀態(tài)，服務(wù)器處于 listen（監(jiān)聽(tīng)） 狀態(tài)。第一次握手：客戶(hù)端發(fā)送請(qǐng)求報(bào)文將 SYN ＝ 1同步序列號(hào)和初始化序列號(hào)seq ＝ x發(fā)送給服務(wù)端，發(fā)送完之后客戶(hù)端處于SYN＿Send狀態(tài)。（驗(yàn)證了客戶(hù)端的發(fā)送能力和服務(wù)端的接收能力）第二次握手：服務(wù)端受到 SYN 請(qǐng)求報(bào)文之后，如果同意連接，會(huì)以自己的同步序列號(hào)SYN（服務(wù)端） ＝ 1、初始化序列號(hào) seq ＝ y和確認(rèn)序列號(hào)（期望下次收到的數(shù)據(jù)包）ack ＝ x＋ 1 以及確認(rèn)號(hào)ACK ＝ 1報(bào)文作為應(yīng)答，服務(wù)器為SYN＿Receive狀態(tài)。（問(wèn)題來(lái)了，兩次握手之后，站在客戶(hù)端角度上思考：我發(fā)送和接收都o(jì)k，服務(wù)端的發(fā)送和接收也都o(jì)k。但是站在服務(wù)端的角度思考：哎呀，我服務(wù)端接收ok，但是我不清楚我的發(fā)送ok不ok呀，而且我還不知道你接受能力如何呢？所以老哥，你需要給我三次握手來(lái)傳個(gè)話告訴我一聲。你要是不告訴我，萬(wàn)一我認(rèn)為你跑了，然后我可能出于安全性的考慮繼續(xù)給你發(fā)一次，看看你回不回我。）第三次握手：客戶(hù)端接收到服務(wù)端的 SYN ＋ ACK之后，知道可以下次可以發(fā)送了下一序列的數(shù)據(jù)包了，然后發(fā)送同步序列號(hào) ack ＝ y ＋ 1和數(shù)據(jù)包的序列號(hào) seq ＝ x ＋ 1以及確認(rèn)號(hào)ACK ＝ 1確認(rèn)包作為應(yīng)答，客戶(hù)端轉(zhuǎn)為established狀態(tài)。（分別站在雙方的角度上思考，各自ok）

56、為什么需要三次握手，兩次不行嗎？

弄清這個(gè)問(wèn)題，我們需要先弄明白三次握手的目的是什么，能不能只用兩次握手來(lái)達(dá)到同樣的目的。

第一次握手：客戶(hù)端發(fā)送網(wǎng)絡(luò)包，服務(wù)端收到了。這樣服務(wù)端就能得出結(jié)論：客戶(hù)端的發(fā)送能力、服務(wù)端的接收能力是正常的。第二次握手：服務(wù)端發(fā)包，客戶(hù)端收到了。這樣客戶(hù)端就能得出結(jié)論：服務(wù)端的接收、發(fā)送能力，客戶(hù)端的接收、發(fā)送能力是正常的。不過(guò)此時(shí)服務(wù)器并不能確認(rèn)客戶(hù)端的接收能力是否正常。第三次握手：客戶(hù)端發(fā)包，服務(wù)端收到了。這樣服務(wù)端就能得出結(jié)論：客戶(hù)端的接收、發(fā)送能力正常，服務(wù)器自己的發(fā)送、接收能力也正常。

因此，需要三次握手才能確認(rèn)雙方的接收與發(fā)送能力是否正常。

試想如果是用兩次握手，則會(huì)出現(xiàn)下面這種情況：

如客戶(hù)端發(fā)出連接請(qǐng)求，但因連接請(qǐng)求報(bào)文丟失而未收到確認(rèn)，于是客戶(hù)端再重傳一次連接請(qǐng)求。后來(lái)收到了確認(rèn)，建立了連接。數(shù)據(jù)傳輸完畢后，就釋放了連接，客戶(hù)端共發(fā)出了兩個(gè)連接請(qǐng)求報(bào)文段，其中第一個(gè)丟失，第二個(gè)到達(dá)了服務(wù)端，但是第一個(gè)丟失的報(bào)文段只是在某些網(wǎng)絡(luò)結(jié)點(diǎn)長(zhǎng)時(shí)間滯留了，延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)服務(wù)端，此時(shí)服務(wù)端誤認(rèn)為客戶(hù)端又發(fā)出一次新的連接請(qǐng)求，于是就向客戶(hù)端發(fā)出確認(rèn)報(bào)文段，同意建立連接，不采用三次握手，只要服務(wù)端發(fā)出確認(rèn)，就建立新的連接了，此時(shí)客戶(hù)端忽略服務(wù)端發(fā)來(lái)的確認(rèn)，也不發(fā)送數(shù)據(jù)，則服務(wù)端一致等待客戶(hù)端發(fā)送數(shù)據(jù)，浪費(fèi)資源。

57、什么是半連接隊(duì)列？

服務(wù)器第一次收到客戶(hù)端的 SYN 之后，就會(huì)處于 SYN＿RCVD 狀態(tài)，此時(shí)雙方還沒(méi)有完全建立其連接，服務(wù)器會(huì)把此種狀態(tài)下請(qǐng)求連接放在一個(gè)隊(duì)列里，我們把這種隊(duì)列稱(chēng)之為半連接隊(duì)列。

當(dāng)然還有一個(gè)全連接隊(duì)列，就是已經(jīng)完成三次握手，建立起連接的就會(huì)放在全連接隊(duì)列中。如果隊(duì)列滿了就有可能會(huì)出現(xiàn)丟包現(xiàn)象。

這里在補(bǔ)充一點(diǎn)關(guān)于SYN－ACK 重傳次數(shù)的問(wèn)題：服務(wù)器發(fā)送完SYN－ACK包，如果未收到客戶(hù)確認(rèn)包，服務(wù)器進(jìn)行首次重傳，等待一段時(shí)間仍未收到客戶(hù)確認(rèn)包，進(jìn)行第二次重傳。如果重傳次數(shù)超過(guò)系統(tǒng)規(guī)定的最大重傳次數(shù)，系統(tǒng)將該連接信息從半連接隊(duì)列中刪除。注意，每次重傳等待的時(shí)間不一定相同，一般會(huì)是指數(shù)增長(zhǎng)，例如間隔時(shí)間為 1s，2s，4s，8s．．．．．．

58、 ISN（Initial Sequence Number）是固定的嗎？

當(dāng)一端為建立連接而發(fā)送它的SYN時(shí)，它為連接選擇一個(gè)初始序號(hào)。ISN隨時(shí)間而變化，因此每個(gè)連接都將具有不同的ISN。ISN可以看作是一個(gè)32比特的計(jì)數(shù)器，每4ms加1 。這樣選擇序號(hào)的目的在于防止在網(wǎng)絡(luò)中被延遲的分組在以后又被傳送，而導(dǎo)致某個(gè)連接的一方對(duì)它做錯(cuò)誤的解釋。

三次握手的其中一個(gè)重要功能是客戶(hù)端和服務(wù)端交換 ISN（Initial Sequence Number），以便讓對(duì)方知道接下來(lái)接收數(shù)據(jù)的時(shí)候如何按序列號(hào)組裝數(shù)據(jù)。如果 ISN 是固定的，攻擊者很容易猜出后續(xù)的確認(rèn)號(hào)，因此 ISN 是動(dòng)態(tài)生成的。

59、 三次握手過(guò)程中可以攜帶數(shù)據(jù)嗎？

其實(shí)第三次握手的時(shí)候，是可以攜帶數(shù)據(jù)的。但是，第一次、第二次握手不可以攜帶數(shù)據(jù)

為什么這樣呢？大家可以想一個(gè)問(wèn)題，假如第一次握手可以攜帶數(shù)據(jù)的話，如果有人要惡意攻擊服務(wù)器，那他每次都在第一次握手中的 SYN 報(bào)文中放入大量的數(shù)據(jù)。因?yàn)楣�擊者根本就不理服�?wù)器的接收、發(fā)送能力是否正常，然后瘋狂著重復(fù)發(fā) SYN 報(bào)文的話，這會(huì)讓服務(wù)器花費(fèi)很多時(shí)間、內(nèi)存空間來(lái)接收這些報(bào)文。

也就是說(shuō)，第一次握手不可以放數(shù)據(jù)，其中一個(gè)簡(jiǎn)單的原因就是會(huì)讓服務(wù)器更加容易受到攻擊了。而對(duì)于第三次的話，此時(shí)客戶(hù)端已經(jīng)處于 ESTABLISHED 狀態(tài)。對(duì)于客戶(hù)端來(lái)說(shuō)，他已經(jīng)建立起連接了，并且也已經(jīng)知道服務(wù)器的接收、發(fā)送能力是正常的了，所以能攜帶數(shù)據(jù)也沒(méi)啥毛病。

60、SYN攻擊是什么？

服務(wù)器端的資源分配是在二次握手時(shí)分配的，而客戶(hù)端的資源是在完成三次握手時(shí)分配的，所以服務(wù)器容易受到SYN洪泛攻擊。SYN攻擊就是Client在短時(shí)間內(nèi)偽造大量不存在的IP地址，并向Server不斷地發(fā)送SYN包，Server則回復(fù)確認(rèn)包，并等待Client確認(rèn)，由于源地址不存在，因此Server需要不斷重發(fā)直至超時(shí)，這些偽造的SYN包將長(zhǎng)時(shí)間占用未連接隊(duì)列，導(dǎo)致正常的SYN請(qǐng)求因?yàn)殛?duì)列滿而被丟棄，從而引起網(wǎng)絡(luò)擁塞甚至系統(tǒng)癱瘓。SYN 攻擊是一種典型的 DoS／DDoS 攻擊。

檢測(cè) SYN 攻擊非常的方便，當(dāng)你在服務(wù)器上看到大量的半連接狀態(tài)時(shí)，特別是源IP地址是隨機(jī)的，基本上可以斷定這是一次SYN攻擊。在 Linux／Unix 上可以使用系統(tǒng)自帶的 netstats 命令來(lái)檢測(cè) SYN 攻擊。

netstat －n －p TCP ｜ grep SYN＿RECV

復(fù)制代碼

常見(jiàn)的防御 SYN 攻擊的方法有如下幾種：

縮短超時(shí)（SYN Timeout）時(shí)間增加最大半連接數(shù)過(guò)濾網(wǎng)關(guān)防護(hù)SYN cookies技術(shù)

61、 四次揮手相關(guān)內(nèi)容

建立一個(gè)連接需要三次握手，而終止一個(gè)連接要經(jīng)過(guò)四次揮手（也有將四次揮手叫做四次握手的）。這由TCP的半關(guān)閉（half－close）造成的。所謂的半關(guān)閉，其實(shí)就是TCP提供了連接的一端在結(jié)束它的發(fā)送后還能接收來(lái)自另一端數(shù)據(jù)的能力。

TCP 的連接的拆除需要發(fā)送四個(gè)包，因此稱(chēng)為四次揮手（Four－way handshake），客戶(hù)端或服務(wù)器均可主動(dòng)發(fā)起揮手動(dòng)作。

第一種回答

剛開(kāi)始雙方都處于 ESTABLISHED 狀態(tài)，假如是客戶(hù)端先發(fā)起關(guān)閉請(qǐng)求。四次揮手的過(guò)程如下：

第一次揮手：客戶(hù)端發(fā)送一個(gè) FIN 報(bào)文，報(bào)文中會(huì)指定一個(gè)序列號(hào)。此時(shí)客戶(hù)端處于 FIN＿WAIT1 狀態(tài)。即發(fā)出連接釋放報(bào)文段（FIN＝1，序號(hào)seq＝u），并停止再發(fā)送數(shù)據(jù)，主動(dòng)關(guān)閉TCP連接，進(jìn)入FIN＿WAIT1（終止等待1）狀態(tài)，等待服務(wù)端的確認(rèn)。第二次揮手：服務(wù)端收到 FIN 之后，會(huì)發(fā)送 ACK 報(bào)文，且把客戶(hù)端的序列號(hào)值 ＋1 作為 ACK 報(bào)文的序列號(hào)值，表明已經(jīng)收到客戶(hù)端的報(bào)文了，此時(shí)服務(wù)端處于 CLOSE＿WAIT 狀態(tài)。即服務(wù)端收到連接釋放報(bào)文段后即發(fā)出確認(rèn)報(bào)文段（ACK＝1，確認(rèn)號(hào)ack＝u＋1，序號(hào)seq＝v），服務(wù)端進(jìn)入CLOSE＿WAIT（關(guān)閉等待）狀態(tài)，此時(shí)的TCP處于半關(guān)閉狀態(tài)，客戶(hù)端到服務(wù)端的連接釋放�？蛻�(hù)端收到服務(wù)端的確認(rèn)后，進(jìn)入FIN＿WAIT2（終止等待2）狀態(tài)，等待服務(wù)端發(fā)出的連接釋放報(bào)文段。第三次揮手：如果服務(wù)端也想斷開(kāi)連接了，和客戶(hù)端的第一次揮手一樣，發(fā)給 FIN 報(bào)文，且指定一個(gè)序列號(hào)。此時(shí)服務(wù)端處于 LAST＿ACK 的狀態(tài)。即服務(wù)端沒(méi)有要向客戶(hù)端發(fā)出的數(shù)據(jù)，服務(wù)端發(fā)出連接釋放報(bào)文段（FIN＝1，ACK＝1，序號(hào)seq＝w，確認(rèn)號(hào)ack＝u＋1），服務(wù)端進(jìn)入LAST＿ACK（最后確認(rèn)）狀態(tài)，等待客戶(hù)端的確認(rèn)。第四次揮手：客戶(hù)端收到 FIN 之后，一樣發(fā)送一個(gè) ACK 報(bào)文作為應(yīng)答，且把服務(wù)端的序列號(hào)值 ＋1 作為自己 ACK 報(bào)文的序列號(hào)值，此時(shí)客戶(hù)端處于 TIME＿WAIT 狀態(tài)。需要過(guò)一陣子以確保服務(wù)端收到自己的 ACK 報(bào)文之后才會(huì)進(jìn)入 CLOSED 狀態(tài)，服務(wù)端收到 ACK 報(bào)文之后，就處于關(guān)閉連接了，處于 CLOSED 狀態(tài)。即客戶(hù)端收到服務(wù)端的連接釋放報(bào)文段后，對(duì)此發(fā)出確認(rèn)報(bào)文段（ACK＝1，seq＝u＋1，ack＝w＋1），客戶(hù)端進(jìn)入TIME＿WAIT（時(shí)間等待）狀態(tài)。此時(shí)TCP未釋放掉，需要經(jīng)過(guò)時(shí)間等待計(jì)時(shí)器設(shè)置的時(shí)間2MSL后，客戶(hù)端才進(jìn)入CLOSED狀態(tài)。

收到一個(gè)FIN只意味著在這一方向上沒(méi)有數(shù)據(jù)流動(dòng)�？蛻�(hù)端執(zhí)行主動(dòng)關(guān)閉并進(jìn)入TIME＿WAIT是正常的，服務(wù)端通常執(zhí)行被動(dòng)關(guān)閉，不會(huì)進(jìn)入TIME＿WAIT狀態(tài)。

在socket編程中，任何一方執(zhí)行close（）操作即可產(chǎn)生揮手操作。

第二種回答初始化狀態(tài)：客戶(hù)端和服務(wù)端都在連接狀態(tài)，接下來(lái)開(kāi)始進(jìn)行四次分手?jǐn)嚅_(kāi)連接操作。第一次分手：第一次分手無(wú)論是客戶(hù)端還是服務(wù)端都可以發(fā)起，因?yàn)?TCP 是全雙工的。“

假如客戶(hù)端發(fā)送的數(shù)據(jù)已經(jīng)發(fā)送完畢，發(fā)送FIN ＝ 1 告訴服務(wù)端，客戶(hù)端所有數(shù)據(jù)已經(jīng)全發(fā)完了，服務(wù)端你可以關(guān)閉接收了，但是如果你們服務(wù)端有數(shù)據(jù)要發(fā)給客戶(hù)端，客戶(hù)端照樣可以接收的。此時(shí)客戶(hù)端處于FIN ＝ 1等待服務(wù)端確認(rèn)釋放連接狀態(tài)。

第二次分手：服務(wù)端接收到客戶(hù)端的釋放請(qǐng)求連接之后，知道客戶(hù)端沒(méi)有數(shù)據(jù)要發(fā)給自己了，然后服務(wù)端發(fā)送ACK ＝ 1告訴客戶(hù)端收到你發(fā)給我的信息，此時(shí)服務(wù)端處于 CLOSE＿WAIT 等待關(guān)閉狀態(tài)。（服務(wù)端先回應(yīng)給客戶(hù)端一聲，我知道了，但服務(wù)端的發(fā)送數(shù)據(jù)能力即將等待關(guān)閉，于是接下來(lái)第三次就來(lái)了。）第三次分手：此時(shí)服務(wù)端向客戶(hù)端把所有的數(shù)據(jù)發(fā)送完了，然后發(fā)送一個(gè)FIN ＝ 1，用于告訴客戶(hù)端，服務(wù)端的所有數(shù)據(jù)發(fā)送完畢，客戶(hù)端你也可以關(guān)閉接收數(shù)據(jù)連接了。此時(shí)服務(wù)端狀態(tài)處于LAST＿ACK狀態(tài)，來(lái)等待確認(rèn)客戶(hù)端是否收到了自己的請(qǐng)求。（服務(wù)端等客戶(hù)端回復(fù)是否收到呢，不收到的話，服務(wù)端不知道客戶(hù)端是不是掛掉了還是咋回事呢，所以服務(wù)端不敢關(guān)閉自己的接收能力，于是第四次就來(lái)了。）第四次分手：此時(shí)如果客戶(hù)端收到了服務(wù)端發(fā)送完的信息之后，就發(fā)送ACK ＝ 1，告訴服務(wù)端，客戶(hù)端已經(jīng)收到了你的信息。有一個(gè) 2 MSL 的延遲等待。

62、揮手為什么需要四次？

第一種回答

因?yàn)楫?dāng)服務(wù)端收到客戶(hù)端的SYN連接請(qǐng)求報(bào)文后，可以直接發(fā)送SYN＋ACK報(bào)文。其中ACK報(bào)文是用來(lái)應(yīng)答的，SYN報(bào)文是用來(lái)同步的。但是關(guān)閉連接時(shí)，當(dāng)服務(wù)端收到FIN報(bào)文時(shí)，很可能并不會(huì)立即關(guān)閉SOCKET，所以只能先回復(fù)一個(gè)ACK報(bào)文，告訴客戶(hù)端，＂你發(fā)的FIN報(bào)文我收到了＂。只有等到我服務(wù)端所有的報(bào)文都發(fā)送完了，我才能發(fā)送FIN報(bào)文，因此不能一起發(fā)送。故需要四次揮手。

第二種回答

任何一方都可以在數(shù)據(jù)傳送結(jié)束后發(fā)出連接釋放的通知，待對(duì)方確認(rèn)后進(jìn)入半關(guān)閉狀態(tài)。當(dāng)另一方也沒(méi)有數(shù)據(jù)再發(fā)送的時(shí)候，則發(fā)出連接釋放通知，對(duì)方確認(rèn)后就完全關(guān)閉了TCP連接。舉個(gè)例子：A 和 B 打電話，通話即將結(jié)束后，A 說(shuō)“我沒(méi)啥要說(shuō)的了”，B回答“我知道了”，但是 B 可能還會(huì)有要說(shuō)的話，A 不能要求 B 跟著自己的節(jié)奏結(jié)束通話，于是 B 可能又巴拉巴拉說(shuō)了一通，最后 B 說(shuō)“我說(shuō)完了”，A 回答“知道了”，這樣通話才算結(jié)束。

63、2MSL等待狀態(tài)？

TIME＿WAIT狀態(tài)也成為2MSL等待狀態(tài)。每個(gè)具體TCP實(shí)現(xiàn)必須選擇一個(gè)報(bào)文段最大生存時(shí)間MSL（Maximum Segment Lifetime），它是任何報(bào)文段被丟棄前在網(wǎng)絡(luò)內(nèi)的最長(zhǎng)時(shí)間。這個(gè)時(shí)間是有限的，因?yàn)門(mén)CP報(bào)文段以IP數(shù)據(jù)報(bào)在網(wǎng)絡(luò)內(nèi)傳輸，而IP數(shù)據(jù)報(bào)則有限制其生存時(shí)間的TTL字段。

對(duì)一個(gè)具體實(shí)現(xiàn)所給定的MSL值，處理的原則是：當(dāng)TCP執(zhí)行一個(gè)主動(dòng)關(guān)閉，并發(fā)回最后一個(gè)ACK，該連接必須在TIME＿WAIT狀態(tài)停留的時(shí)間為2倍的MSL。這樣可讓TCP再次發(fā)送最后的ACK以防這個(gè)ACK丟失（另一端超時(shí)并重發(fā)最后的FIN）。

這種2MSL等待的另一個(gè)結(jié)果是這個(gè)TCP連接在2MSL等待期間，定義這個(gè)連接的插口（客戶(hù)的IP地址和端口號(hào)，服務(wù)器的IP地址和端口號(hào)）不能再被使用。這個(gè)連接只能在2MSL結(jié)束后才能再被使用。

64、四次揮手釋放連接時(shí)，等待2MSL的意義？

MSL是Maximum Segment Lifetime的英文縮寫(xiě)，可譯為“最長(zhǎng)報(bào)文段壽命”，它是任何報(bào)文在網(wǎng)絡(luò)上存在的最長(zhǎng)時(shí)間，超過(guò)這個(gè)時(shí)間報(bào)文將被丟棄。

為了保證客戶(hù)端發(fā)送的最后一個(gè)ACK報(bào)文段能夠到達(dá)服務(wù)器。因?yàn)檫@個(gè)ACK有可能丟失，從而導(dǎo)致處在LAST－ACK狀態(tài)的服務(wù)器收不到對(duì)FIN－ACK的確認(rèn)報(bào)文。服務(wù)器會(huì)超時(shí)重傳這個(gè)FIN－ACK，接著客戶(hù)端再重傳一次確認(rèn)，重新啟動(dòng)時(shí)間等待計(jì)時(shí)器。最后客戶(hù)端和服務(wù)器都能正常的關(guān)閉。假設(shè)客戶(hù)端不等待2MSL，而是在發(fā)送完ACK之后直接釋放關(guān)閉，一但這個(gè)ACK丟失的話，服務(wù)器就無(wú)法正常的進(jìn)入關(guān)閉連接狀態(tài)。

兩個(gè)理由保證客戶(hù)端發(fā)送的最后一個(gè)ACK報(bào)文段能夠到達(dá)服務(wù)端。這個(gè)ACK報(bào)文段有可能丟失，使得處于LAST－ACK狀態(tài)的B收不到對(duì)已發(fā)送的FIN＋ACK報(bào)文段的確認(rèn)，服務(wù)端超時(shí)重傳FIN＋ACK報(bào)文段，而客戶(hù)端能在2MSL時(shí)間內(nèi)收到這個(gè)重傳的FIN＋ACK報(bào)文段，接著客戶(hù)端重傳一次確認(rèn)，重新啟動(dòng)2MSL計(jì)時(shí)器，最后客戶(hù)端和服務(wù)端都進(jìn)入到CLOSED狀態(tài)，若客戶(hù)端在TIME－WAIT狀態(tài)不等待一段時(shí)間，而是發(fā)送完ACK報(bào)文段后立即釋放連接，則無(wú)法收到服務(wù)端重傳的FIN＋ACK報(bào)文段，所以不會(huì)再發(fā)送一次確認(rèn)報(bào)文段，則服務(wù)端無(wú)法正常進(jìn)入到CLOSED狀態(tài)。防止“已失效的連接請(qǐng)求報(bào)文段”出現(xiàn)在本連接中。客戶(hù)端在發(fā)送完最后一個(gè)ACK報(bào)文段后，再經(jīng)過(guò)2MSL，就可以使本連接持續(xù)的時(shí)間內(nèi)所產(chǎn)生的所有報(bào)文段都從網(wǎng)絡(luò)中消失，使下一個(gè)新的連接中不會(huì)出現(xiàn)這種舊的連接請(qǐng)求報(bào)文段。

65、為什么TIME＿WAIT狀態(tài)需要經(jīng)過(guò)2MSL才能返回到CLOSE狀態(tài)？

第一種回答

理論上，四個(gè)報(bào)文都發(fā)送完畢，就可以直接進(jìn)入CLOSE狀態(tài)了，但是可能網(wǎng)絡(luò)是不可靠的，有可能最后一個(gè)ACK丟失。所以TIME＿WAIT狀態(tài)就是用來(lái)重發(fā)可能丟失的ACK報(bào)文。

第二種回答

對(duì)應(yīng)這樣一種情況，最后客戶(hù)端發(fā)送的ACK ＝ 1給服務(wù)端的過(guò)程中丟失了，服務(wù)端沒(méi)收到，服務(wù)端怎么認(rèn)為的？我已經(jīng)發(fā)送完數(shù)據(jù)了，怎么客戶(hù)端沒(méi)回應(yīng)我？是不是中途丟失了？然后服務(wù)端再次發(fā)起斷開(kāi)連接的請(qǐng)求，一個(gè)來(lái)回就是2MSL。

客戶(hù)端給服務(wù)端發(fā)送的ACK ＝ 1丟失，服務(wù)端等待 1MSL沒(méi)收到，然后重新發(fā)送消息需要1MSL。如果再次接收到服務(wù)端的消息，則重啟2MSL計(jì)時(shí)器，發(fā)送確認(rèn)請(qǐng)求。客戶(hù)端只需等待2MSL，如果沒(méi)有再次收到服務(wù)端的消息，就說(shuō)明服務(wù)端已經(jīng)接收到自己確認(rèn)消息；此時(shí)雙方都關(guān)閉的連接，TCP 四次分手完畢

66、TCP粘包問(wèn)題是什么？你會(huì)如何去解決它？

TCP粘包是指發(fā)送方發(fā)送的若干包數(shù)據(jù)到接收方接收時(shí)粘成一包，從接收緩沖區(qū)看，后一包數(shù)據(jù)的頭緊接著前一包數(shù)據(jù)的尾。

由TCP連接復(fù)用造成的粘包問(wèn)題。因?yàn)門(mén)CP默認(rèn)會(huì)使用Nagle算法，此算法會(huì)導(dǎo)致粘包問(wèn)題。只有上一個(gè)分組得到確認(rèn)，才會(huì)發(fā)送下一個(gè)分組；收集多個(gè)小分組，在一個(gè)確認(rèn)到來(lái)時(shí)一起發(fā)送。數(shù)據(jù)包過(guò)大造成的粘包問(wèn)題。流量控制，擁塞控制也可能導(dǎo)致粘包。接收方不及時(shí)接收緩沖區(qū)的包，造成多個(gè)包接收

解決：

Nagle算法問(wèn)題導(dǎo)致的，需要結(jié)合應(yīng)用場(chǎng)景適當(dāng)關(guān)閉該算法尾部標(biāo)記序列。通過(guò)特殊標(biāo)識(shí)符表示數(shù)據(jù)包的邊界，例如， ，或者一些隱藏字符。頭部標(biāo)記分步接收。在TCP報(bào)文的頭部加上表示數(shù)據(jù)長(zhǎng)度。應(yīng)用層發(fā)送數(shù)據(jù)時(shí)定長(zhǎng)發(fā)送。結(jié)語(yǔ)

嗯，到這里就結(jié)束了。

PDF還沒(méi)更新哈，還是上次的，下篇更完再出 PDF 版本好了，哈哈。