面試題1：說一下TCP連接的三次握手和四次揮手吧

正經(jīng)回答：

握手：TCP連接

揮手：TCP斷開

三次握手：

首先，三次握手的本質(zhì)是確認(rèn)通信雙方（Client端、Server端）收發(fā)數(shù)據(jù)的能力；

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

注：剛開始客戶端處于 Closed 的狀態(tài)，服務(wù)端處于 Listen 狀態(tài)。

三次握手（連接）流程白話文介紹：

我和女朋友養(yǎng)了一只信鴿來傳信，今天我要試一試好不好使，不好使晚上我就準(zhǔn)備吃燒烤。

• 第一次握手：我把信（第一封信）綁在鴿子腿上發(fā)給女朋友，如果女朋友收到了，就確定了我的發(fā)件能力和她的收件能力沒問題；
• 第二次握手：然后女朋友給我回信（第二封信），我如果收到了，說明我的收件能力和她的發(fā)件能力沒問題；
• 第三次握手：然而此時(shí)女朋友還不知道她的發(fā)件能力和我的收件能力是否正常；因此我還要給他發(fā)（第三封信）說明，收到后最終決定晚上去吃烤魚。信鴿：真tm累，你們手機(jī)都是假的吧。

三次握手理論流程：

• 第一次握手：客戶端將標(biāo)志位SYN置為1，隨機(jī)產(chǎn)生一個(gè)值seq=J，并將該數(shù)據(jù)包發(fā)送給服務(wù)器端，客戶端進(jìn)入SYN_SENT狀態(tài)，等待服務(wù)器端確認(rèn)。
• 第二次握手：服務(wù)器端收到數(shù)據(jù)包后由標(biāo)志位SYN=1知道客戶端請求建立連接，服務(wù)器端將標(biāo)志位SYN和ACK都置為1，ack=J+1，隨機(jī)產(chǎn)生一個(gè)值seq=K，并將該數(shù)據(jù)包發(fā)送給客戶端以確認(rèn)連接請求，服務(wù)器端進(jìn)入SYN_RCVD狀態(tài)。
• 第三次握手：客戶端收到確認(rèn)后，檢查ack是否為J+1，ACK是否為1，如果正確則將標(biāo)志位ACK置為1，ack=K+1，并將該數(shù)據(jù)包發(fā)送給服務(wù)器端，服務(wù)器端檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，客戶端和服務(wù)器端進(jìn)入ESTABLISHED狀態(tài)，完成三次握手，隨后客戶端與服務(wù)器端之間可以開始傳輸數(shù)據(jù)了。

四次揮手：

四次揮手即終止TCP連接，就是指斷開一個(gè)TCP連接時(shí)，需要客戶端和服務(wù)端總共發(fā)送4個(gè)包以確認(rèn)連接的斷開。在socket編程中，這一過程由客戶端或服務(wù)端任一方執(zhí)行close來觸發(fā)。

由于TCP連接是全雙工的，因此，每個(gè)方向都必須要單獨(dú)進(jìn)行關(guān)閉，這一原則是當(dāng)一方完成數(shù)據(jù)發(fā)送任務(wù)后，發(fā)送一個(gè)FIN來終止這一方向的連接，收到一個(gè)FIN只是意味著這一方向上沒有數(shù)據(jù)流動(dòng)了，即不會(huì)再收到數(shù)據(jù)了，但是在這個(gè)TCP連接上仍然能夠發(fā)送數(shù)據(jù)，直到這一方向也發(fā)送了FIN。首先進(jìn)行關(guān)閉的一方將執(zhí)行主動(dòng)關(guān)閉，而另一方則執(zhí)行被動(dòng)關(guān)閉。

四次揮手理論流程

中斷連接端可以是客戶端，也可以是服務(wù)器端。

第一次揮手：客戶端發(fā)送一個(gè)FIN=M，用來關(guān)閉客戶端到服務(wù)器端的數(shù)據(jù)傳送，客戶端進(jìn)入FIN_WAIT_1狀態(tài)。意思是說"我客戶端沒有數(shù)據(jù)要發(fā)給你了"，但是如果你服務(wù)器端還有數(shù)據(jù)沒有發(fā)送完成，則不必急著關(guān)閉連接，可以繼續(xù)發(fā)送數(shù)據(jù)。

第二次揮手：服務(wù)器端收到FIN后，先發(fā)送ack=M+1，告訴客戶端，你的請求我收到了，但是我還沒準(zhǔn)備好，請繼續(xù)你等我的消息。這個(gè)時(shí)候客戶端就進(jìn)入FIN_WAIT_2 狀態(tài)，繼續(xù)等待服務(wù)器端的FIN報(bào)文。

第三次揮手：當(dāng)服務(wù)器端確定數(shù)據(jù)已發(fā)送完成，則向客戶端發(fā)送FIN=N報(bào)文，告訴客戶端，好了，我這邊數(shù)據(jù)發(fā)完了，準(zhǔn)備好關(guān)閉連接了。服務(wù)器端進(jìn)入LAST_ACK狀態(tài)。

第四次揮手：客戶端收到FIN=N報(bào)文后，就知道可以關(guān)閉連接了，但是他還是不相信網(wǎng)絡(luò)，怕服務(wù)器端不知道要關(guān)閉，所以發(fā)送ack=N+1后進(jìn)入TIME_WAIT狀態(tài)，如果Server端沒有收到ACK則可以重傳。服務(wù)器端收到ACK后，就知道可以斷開連接了?？蛻舳说却?MSL后依然沒有收到回復(fù)，則證明服務(wù)器端已正常關(guān)閉，那好，我客戶端也可以關(guān)閉連接了。最終完成了四次握手。

深入追問：

追問1：為什么連接的時(shí)候是三次握手，關(guān)閉的時(shí)候卻是四次握手？

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

追問2：如果已經(jīng)建立了連接，但是客戶端突然出現(xiàn)故障了怎么辦？

TCP還設(shè)有一個(gè)?；钣?jì)時(shí)器，顯然，客戶端如果出現(xiàn)故障，服務(wù)器不能一直等下去，白白浪費(fèi)資源。服務(wù)器每收到一次客戶端的請求后都會(huì)重新復(fù)位這個(gè)計(jì)時(shí)器，時(shí)間通常是設(shè)置為2小時(shí)，若兩小時(shí)還沒有收到客戶端的任何數(shù)據(jù)，服務(wù)器就會(huì)發(fā)送一個(gè)探測報(bào)文段，以后每隔75秒鐘發(fā)送一次。

若一連發(fā)送10個(gè)探測報(bào)文仍然沒反應(yīng)，服務(wù)器就認(rèn)為客戶端出了故障，接著就關(guān)閉連接。

面試題2：常見的HTTP狀態(tài)碼有哪些？

正經(jīng)回答：

HTTP狀態(tài)碼表示客戶端HTTP請求的返回結(jié)果、標(biāo)識服務(wù)器處理是否正常、表明請求出現(xiàn)的錯(cuò)誤等。

狀態(tài)碼的類別：

面試題3：先說說GET和POST請求有哪些區(qū)別吧？

正經(jīng)回答：

GET請求在URL中傳送的參數(shù)是有長度限制的，而POST沒有。

GET比POST更不安全，因?yàn)閰?shù)直接暴露在URL上，所以不能用來傳遞敏感信息。而POST數(shù)據(jù)不會(huì)顯示在URL中。是放在Request body中。

對參數(shù)的數(shù)據(jù)類型，GET只接受ASCII字符，而POST沒有限制。

GET請求參數(shù)會(huì)被完整保留在瀏覽器歷史記錄里；相反，POST請求參數(shù)也不會(huì)被瀏覽器保留。

GET請求只能進(jìn)行url編碼（application/x-www-form-urlencoded），而POST支持多種編碼方式。

GET請求會(huì)被瀏覽器主動(dòng)緩存，而POST不會(huì)，除非手動(dòng)設(shè)置。

GET在瀏覽器回退時(shí)是無害的，而POST會(huì)再次提交請求。

深入追問：

追問1：那Get請求有Request body么？如果有的話參數(shù)可以像Post請求一樣放在里面么？

其實(shí)吧，GET和POST在本質(zhì)上沒有區(qū)別，都是HTTP協(xié)議中的兩種發(fā)送請求的方法。而HTTP呢，是基于TCP/IP的關(guān)于數(shù)據(jù)如何在萬維網(wǎng)中如何通信的協(xié)議。

萬維網(wǎng)：簡稱WWW，是World Wide Web的簡稱，也稱為Web、3W等

HTTP的底層是TCP/IP。所以GET和POST的底層也是TCP/IP，也就是說，GET/POST都是TCP鏈接。

GET和POST能做的事情是一樣一樣的。你要給GET加上request body，給POST帶上url參數(shù)，技術(shù)上是完全行的通的。

• 舉個(gè)例子吧：

TCP就像汽車，我們用TCP來運(yùn)輸數(shù)據(jù)，它很可靠，從來不會(huì)發(fā)生丟件少件的現(xiàn)象。

但是如果路上跑的全是看起來一模一樣的汽車，那這個(gè)世界看起來是一團(tuán)混亂，送急件的汽車可能被前面滿載貨物的汽車攔堵在路上，整個(gè)交通系統(tǒng)一定會(huì)癱瘓。

為了避免這種情況發(fā)生，交通規(guī)則HTTP誕生了。HTTP給汽車運(yùn)輸設(shè)定了好幾個(gè)服務(wù)類別，包括GET, POST, PUT等等，

HTTP規(guī)定，當(dāng)執(zhí)行GET請求的時(shí)候，要給汽車貼上GET的標(biāo)簽（設(shè)置method為GET），而且要求把傳送的數(shù)據(jù)放在車頂上（url中）以方便記錄。

如果是POST請求，就要在車上貼上POST的標(biāo)簽，并把貨物放在車廂里（request body中）。

當(dāng)然，你也可以在用GET的時(shí)往車廂內(nèi)偷偷藏點(diǎn)貨物，但這并不不光彩；也可以在POST的時(shí)候在車頂上也放一些數(shù)據(jù)，也會(huì)讓人覺得傻乎乎的。

HTTP只是個(gè)行為準(zhǔn)則，而GET和POST本質(zhì)上就是TCP鏈接，并無差別。但是由于HTTP的規(guī)定和瀏覽器/服務(wù)器的限制，導(dǎo)致他們在應(yīng)用過程中體現(xiàn)出一些不同。

追問2：那你剛才說的URL中傳送參數(shù)的長度限制在Get和Post中都是怎么樣的呢？

其實(shí)在Web中啊，還有另一個(gè)重要的角色：運(yùn)輸公司。

不同的瀏覽器Client端（發(fā)起http請求）和服務(wù)器server端（接受http請求）就是不同的運(yùn)輸公司。

雖然理論上，你可以在車頂上無限的堆貨物（url中無限加參數(shù)）。但是運(yùn)輸公司可不傻，裝貨和卸貨也是有很大成本的，他們會(huì)限制單次運(yùn)輸量來控制風(fēng)險(xiǎn)，數(shù)據(jù)量太大對瀏覽器和服務(wù)器都是很大負(fù)擔(dān)。

業(yè)界不成文的規(guī)定是：（大多數(shù)）瀏覽器通常都會(huì)限制url長度在2K個(gè)字節(jié)，而（大多數(shù)）服務(wù)器最多處理64K大小的url。

超過的部分，恕不處理。如果你用GET服務(wù)，在request body偷偷藏了數(shù)據(jù)，不同服務(wù)器的處理方式也是不同的，有些服務(wù)器會(huì)幫你卸貨，讀出數(shù)據(jù)，有些服務(wù)器直接忽略。

所以，雖然GET可以帶request body，卻不能保證一定能被接收到。

我之前處理過一個(gè)bug，用戶反應(yīng)查詢沒有響應(yīng)，同事查了日志后才發(fā)現(xiàn)有幾個(gè)參數(shù)都是undefined，很奇怪，最后發(fā)現(xiàn)原來是因?yàn)镚et請求第一個(gè)查詢參數(shù)太長了，導(dǎo)致URL后面的部分服務(wù)器無法接收 ，后來把請求改成post，將參數(shù)放在request body后就可以了。

追問3：那么你知道Get、Post請求發(fā)送的數(shù)據(jù)包有什么不同嗎？

嗯嗯，是這樣的，GET請求時(shí)產(chǎn)生一個(gè)TCP數(shù)據(jù)包；POST請求時(shí)產(chǎn)生兩個(gè)TCP數(shù)據(jù)包。

• GET：瀏覽器會(huì)把http header和data一并發(fā)送出去，服務(wù)器響應(yīng)200（返回?cái)?shù)據(jù)）；
• POST：瀏覽器先發(fā)送header，服務(wù)器響應(yīng)100 continue，瀏覽器再發(fā)送data，服務(wù)器響應(yīng)200 OK（返回?cái)?shù)據(jù)）。

就像是GET只需要汽車跑一趟就把貨送到了，而POST得跑兩趟，第一趟，先去和服務(wù)器打個(gè)招呼“老鐵，我等下要送一批貨來，你們準(zhǔn)備接收一下哈”，然后再回頭把貨送過去。

因?yàn)镻OST需要兩步，理論上時(shí)間上消耗的要多一點(diǎn)，看起來GET比POST更有效。但并不是，后來發(fā)現(xiàn)原來是個(gè)坑。在我看來：

1.GET與POST都有自己的語義，不能隨便混用。

2.據(jù)研究，在網(wǎng)絡(luò)環(huán)境好的情況下，發(fā)一次包的時(shí)間和發(fā)兩次包的時(shí)間差別基本可以無視。而在網(wǎng)絡(luò)環(huán)境差的情況下，兩次包的TCP在驗(yàn)證數(shù)據(jù)包完整性上，有非常大的優(yōu)點(diǎn)。

3.并不是所有瀏覽器都會(huì)在POST中發(fā)送兩次包，F(xiàn)irefox就只發(fā)送一次。我去年用Chrome瀏覽器測試發(fā)現(xiàn)也是只發(fā)送一次，所以我認(rèn)為Get、POST性能差可以人為忽略。

總結(jié)

本篇文章就到這里了，希望能給你帶來幫助，也希望您能夠多多關(guān)注腳本之家的更多內(nèi)容！

最新評論