Session和cookie應(yīng)該如何去選擇適用場(chǎng)景?
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è)話(huà)告訴我一聲。你要是不告訴我,萬(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ì)列滿(mǎn)了就有可能會(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ù)的話(huà),如果有人要惡意攻擊服務(wù)器,那他每次都在第一次握手中的 SYN 報(bào)文中放入大量的數(shù)據(jù)。因?yàn)楣粽吒揪筒焕矸⻊?wù)器的接收、發(fā)送能力是否正常,然后瘋狂著重復(fù)發(fā) SYN 報(bào)文的話(huà),這會(huì)讓服務(wù)器花費(fèi)很多時(shí)間、內(nèi)存空間來(lái)接收這些報(bào)文。
也就是說(shuō),第一次握手不可以放數(shù)據(jù),其中一個(gè)簡(jiǎn)單的原因就是會(huì)讓服務(wù)器更加容易受到攻擊了。而對(duì)于第三次的話(huà),此時(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ì)列滿(mǎn)而被丟棄,從而引起網(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ù)是否收到呢,不收到的話(huà),服務(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 打電話(huà),通話(huà)即將結(jié)束后,A 說(shuō)“我沒(méi)啥要說(shuō)的了”,B回答“我知道了”,但是 B 可能還會(huì)有要說(shuō)的話(huà),A 不能要求 B 跟著自己的節(jié)奏結(jié)束通話(huà),于是 B 可能又巴拉巴拉說(shuō)了一通,最后 B 說(shuō)“我說(shuō)完了”,A 回答“知道了”,這樣通話(huà)才算結(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丟失的話(huà),服務(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 版本好了,哈哈。
發(fā)表評(píng)論
請(qǐng)輸入評(píng)論內(nèi)容...
請(qǐng)輸入評(píng)論/評(píng)論長(zhǎng)度6~500個(gè)字
最新活動(dòng)更多
-
10月31日立即下載>> 【限時(shí)免費(fèi)下載】TE暖通空調(diào)系統(tǒng)高效可靠的組件解決方案
-
即日-11.13立即報(bào)名>>> 【在線會(huì)議】多物理場(chǎng)仿真助跑新能源汽車(chē)
-
11月28日立即報(bào)名>>> 2024工程師系列—工業(yè)電子技術(shù)在線會(huì)議
-
12月19日立即報(bào)名>> 【線下會(huì)議】OFweek 2024(第九屆)物聯(lián)網(wǎng)產(chǎn)業(yè)大會(huì)
-
即日-12.26火熱報(bào)名中>> OFweek2024中國(guó)智造CIO在線峰會(huì)
-
即日-2025.8.1立即下載>> 《2024智能制造產(chǎn)業(yè)高端化、智能化、綠色化發(fā)展藍(lán)皮書(shū)》
推薦專(zhuān)題
- 1 【一周車(chē)話(huà)】沒(méi)有方向盤(pán)和踏板的車(chē),你敢坐嗎?
- 2 特斯拉發(fā)布無(wú)人駕駛車(chē),還未迎來(lái)“Chatgpt時(shí)刻”
- 3 特斯拉股價(jià)大跌15%:Robotaxi離落地還差一個(gè)蘿卜快跑
- 4 馬斯克給的“驚喜”夠嗎?
- 5 打完“價(jià)格戰(zhàn)”,大模型還要比什么?
- 6 馬斯克致敬“國(guó)產(chǎn)蘿卜”?
- 7 神經(jīng)網(wǎng)絡(luò),誰(shuí)是盈利最強(qiáng)企業(yè)?
- 8 比蘋(píng)果偉大100倍!真正改寫(xiě)人類(lèi)歷史的智能產(chǎn)品降臨
- 9 諾獎(jiǎng)進(jìn)入“AI時(shí)代”,人類(lèi)何去何從?
- 10 Open AI融資后成萬(wàn)億獨(dú)角獸,AI人才之爭(zhēng)開(kāi)啟
- 高級(jí)軟件工程師 廣東省/深圳市
- 自動(dòng)化高級(jí)工程師 廣東省/深圳市
- 光器件研發(fā)工程師 福建省/福州市
- 銷(xiāo)售總監(jiān)(光器件) 北京市/海淀區(qū)
- 激光器高級(jí)銷(xiāo)售經(jīng)理 上海市/虹口區(qū)
- 光器件物理工程師 北京市/海淀區(qū)
- 激光研發(fā)工程師 北京市/昌平區(qū)
- 技術(shù)專(zhuān)家 廣東省/江門(mén)市
- 封裝工程師 北京市/海淀區(qū)
- 結(jié)構(gòu)工程師 廣東省/深圳市