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

正經回答：

握手：TCP連接

揮手：TCP斷開

三次握手：

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

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

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

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

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

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

三次握手理論流程：

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

四次揮手：

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

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

四次揮手理論流程

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

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

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

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

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

深入追問：

追問1：為什么連接的時候是三次握手，關閉的時候卻是四次握手？

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

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

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

若一連發(fā)送10個探測報文仍然沒反應，服務器就認為客戶端出了故障，接著就關閉連接。

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

正經回答：

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

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

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

正經回答：

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

GET比POST更不安全，因為參數(shù)直接暴露在URL上，所以不能用來傳遞敏感信息。而POST數(shù)據不會顯示在URL中。是放在Request body中。

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

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

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

GET請求會被瀏覽器主動緩存，而POST不會，除非手動設置。

GET在瀏覽器回退時是無害的，而POST會再次提交請求。

深入追問：

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

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

萬維網：簡稱WWW，是World Wide Web的簡稱，也稱為Web、3W等

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

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

• 舉個例子吧：

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

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

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

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

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

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

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

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

其實在Web中啊，還有另一個重要的角色：運輸公司。

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

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

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

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

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

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

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

嗯嗯，是這樣的，GET請求時產生一個TCP數(shù)據包；POST請求時產生兩個TCP數(shù)據包。

• GET：瀏覽器會把http header和data一并發(fā)送出去，服務器響應200（返回數(shù)據）；
• POST：瀏覽器先發(fā)送header，服務器響應100 continue，瀏覽器再發(fā)送data，服務器響應200 OK（返回數(shù)據）。

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

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

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

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

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

總結

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

最新評論