??大家好，我是陳哈哈，北漂五年，認識我的朋友們知道，我是非科班出身，半路出家，大學也很差！這種背景來北漂，你都不知道你會經歷什么🙃🙃，

??不敢茍同，相信大家和我一樣，都有一個大廠夢，作為一名資深Java選手，深知面試重要性，接下來我準備用100天時間，基于Java崗面試中的高頻面試題，以每日3題的形式，帶你過一遍熱門面試題及恰如其分的解答，當然，我不會太深入，因為我怕記不住！！

??因此，不足的地方希望各位在評論區補充疑惑、見解以及面試中遇到的奇葩問法，希望這100天能夠讓我們有質的飛越，一起沖進大廠！！，讓我們一起學（juan）起來！！！

坐標：普陀山

??本欄目Java開發崗高頻面試題主要出自以下各技術堆疊：Java基礎知識、集合容器、并發編程、JVM、Spring全家桶、MyBatis等ORMapping框架、MySQL資料庫、Redis快取、RabbitMQ訊息佇列、Linux操作技巧等，

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

正經回答：

握手：TCP連接
揮手：TCP斷開

三次握手：

??首先，三次握手的本質是確認通信雙方（Client端、Server端）收發資料的能力；

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

注：剛開始客戶端處于 Closed 的狀態，服務端處于 Listen 狀態，

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

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

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

三次握手理論流程：

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

四次揮手：

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

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

四次揮手理論流程

• 中斷連接端可以是客戶端，也可以是服務器端，
• 第一次揮手：客戶端發送一個FIN=M，用來關閉客戶端到服務器端的資料傳送，客戶端進入FIN_WAIT_1狀態，意思是說"我客戶端沒有資料要發給你了"，但是如果你服務器端還有資料沒有發送完成，則不必急著關閉連接，可以繼續發送資料，
• 第二次揮手：服務器端收到FIN后，先發送ack=M+1，告訴客戶端，你的請求我收到了，但是我還沒準備好，請繼續你等我的訊息，這個時候客戶端就進入FIN_WAIT_2 狀態，繼續等待服務器端的FIN報文，
• 第三次揮手：當服務器端確定資料已發送完成，則向客戶端發送FIN=N報文，告訴客戶端，好了，我這邊資料發完了，準備好關閉連接了，服務器端進入LAST_ACK狀態，
• 第四次揮手：客戶端收到FIN=N報文后，就知道可以關閉連接了，但是他還是不相信網路，怕服務器端不知道要關閉，所以發送ack=N+1后進入TIME_WAIT狀態，如果Server端沒有收到ACK則可以重傳，服務器端收到ACK后，就知道可以斷開連接了，客戶端等待了2MSL后依然沒有收到回復，則證明服務器端已正常關閉，那好，我客戶端也可以關閉連接了，最終完成了四次握手，

深入追問：

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

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

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

??TCP還設有一個保活計時器，顯然，客戶端如果出現故障，服務器不能一直等下去，白白浪費資源，服務器每收到一次客戶端的請求后都會重新復位這個計時器，時間通常是設定為2小時，若兩小時還沒有收到客戶端的任何資料，服務器就會發送一個探測報文段，以后每隔75秒鐘發送一次，
??若一連發送10個探測報文仍然沒反應，服務器就認為客戶端出了故障，接著就關閉連接，

面試題2：常見的HTTP狀態碼有哪些？

正經回答：

??HTTP狀態碼表示客戶端HTTP請求的回傳結果、標識服務器處理是否正常、表明請求出現的錯誤等，

狀態碼的類別：

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

正經回答：

1. GET請求在URL中傳送的引數是有長度限制的，而POST沒有，
2. GET比POST更不安全，因為引數直接暴露在URL上，所以不能用來傳遞敏感資訊，而POST資料不會顯示在URL中，是放在Request body中，
3. 對引數的資料型別，GET只接受ASCII字符，而POST沒有限制，
4. GET請求引數會被完整保留在瀏覽器歷史記錄里；相反，POST請求引數也不會被瀏覽器保留，
5. GET請求只能進行url編碼（application/x-www-form-urlencoded），而POST支持多種編碼方式，
6. GET請求會被瀏覽器主動快取，而POST不會，除非手動設定，
7. GET在瀏覽器回退時是無害的，而POST會再次提交請求，

深入追問：

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

??其實吧，GET和POST在本質上沒有區別，都是HTTP協議中的兩種發送請求的方法，而HTTP呢，是基于TCP/IP的關于資料如何在萬維網中如何通信的協議，

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

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

??GET和POST能做的事情是一樣一樣的，你要給GET加上request body，給POST帶上url引數，技術上是完全行的通的，

• 舉個例子吧：

??TCP就像汽車，我們用TCP來運輸資料，它很可靠，從來不會發生丟件少件的現象，

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

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

??HTTP規定，當執行GET請求的時候，要給汽車貼上GET的標簽（設定method為GET），而且要求把傳送的資料放在車頂上（url中）以方便記錄，

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

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

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

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

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

??不同的瀏覽器Client端（發起http請求）和服務器server端（接受http請求）就是不同的運輸公司，

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

??業界不成文的規定是：（大多數）瀏覽器通常都會限制url長度在2K個位元組，而（大多數）服務器最多處理64K大小的url，

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

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

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

追問3：那么你知道Get、Post請求發送的資料包有什么不同嗎？

嗯嗯，是這樣的，GET請求時產生一個TCP資料包；POST請求時產生兩個TCP資料包，

• GET：瀏覽器會把http header和data一并發送出去，服務器回應200（回傳資料）；
• POST：瀏覽器先發送header，服務器回應100 continue，瀏覽器再發送data，服務器回應200 OK（回傳資料），

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

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

1. GET與POST都有自己的語意，不能隨便混用，
2. 據研究，在網路環境好的情況下，發一次包的時間和發兩次包的時間差別基本可以無視，而在網路環境差的情況下，兩次包的TCP在驗證資料包完整性上，有非常大的優點，
3. 并不是所有瀏覽器都會在POST中發送兩次包，Firefox就只發送一次，我去年用Chrome瀏覽器測驗發現也是只發送一次，所以我認為Get、POST性能差可以人為忽略，

每日小結

??今天我們復習了面試中常考的網路編程類的三個問題，你做到心中有數了么？對了，如果你的朋友也在準備面試，請將這個系列扔給他，如果他認真對待，肯定會感謝你的！！好了，今天就到這里，學廢了的同學，記得在評論區留言：打卡，，給同學們以激勵，