《面試官不講武德》對Java初級程序猿死命摩擦Http協議

時間 2020-12-21

標籤 javascript java 程序員面試瀏覽器安全服務器 cookie 網絡併發欄目 Java 简体版

原文原文鏈接

前言

我被Hr領進了一個小黑屋，讓我在這裏等面試官，過來一會，一位穿着拖鞋的中年男子走了進來，看着他絕頂聰明的髮際線，知道這確定是位大佬，我內心倍感到了壓力；javascript

面試官果真不是蓋的，剛坐下後就開始當即暴力輸出了java

面試官：我看你簡歷上寫了熟悉Http協議，當咱們使用瀏覽器訪問網址: `https://silently9527.cn`會發生什麼？

我：（這尼瑪就是怕被搞事情因此沒寫精通，這也被搞。會發生什麼，固然是展現出網頁啊，大腦飛速旋轉，脖子快斷的時候，終於想到面試官可能想要問什麼了）程序員

我：英俊瀟灑的面試官，你好！面試

首先瀏覽器會去訪問DNS服務器，查詢到域名對應的ip地址是多少，而後瀏覽器再去訪問這個ip地址；若是還要往底層在說的話，就會涉及到tcp/ip的分層，我仍是來畫張圖吧。瀏覽器

服務器返回資源的過程也是相似的方式安全

面試官：你剛纔有談到tcp/ip的分層，能詳細說下嗎?

我：（還好前前大學女朋友沒把我當年上課的筆記給扔掉，恰好昨晚找回來溫習了一下，溫故而知新！只是筆記而已，你們別想歪了！）
插圖服務器

我：TCP/IP協議族分爲4層：應用層、傳輸層、網絡層、數據鏈路層cookie

應用層：主要是與應用通訊使用到的協議，好比：FTP、DNS、HTTP
傳輸層：爲應用層提供在兩臺機器之間數據傳輸，有兩種協議：TCP、UDP
網絡層：兩臺機器之間在傳輸的過程當中會通過多個路由器有多條路線，網絡層主要是從中選擇一條路線
數據鏈路層：用來處理鏈接網絡的硬件部分，好比說網卡、設備驅動等

面試官：在tcp/ip的分層裏面，當客戶端發起http請求到達服務端的過程當中，數據包的封裝以及解包的過程是怎樣的？

我：在這個分層中，每次網絡請求都會按照分層的順序與對方進行通訊，發送端從應用層往下走，接收端從數據鏈路層往上走；以Http來舉例的話：網絡

客戶端在應用層（Http協議）發起一個HTTP請求
在傳輸層（TCP協議）把從應用層收到的Http請求數據包分隔成小的數據包，並打好序
網絡層（IP協議）收到數據包後選擇發送路徑
服務器收到數據後按照順序往上發送，直到應用層收到數據

在發送方每通過一層，就會被加上該層的首部信息，當接收方接受到數據後，在每個層會去掉對應的首部信息併發

面試官：TCP如何保證數據可靠到達目的地？

我：TCP協議採用的三次握手策略

第一次握手：創建鏈接時，客戶端發送 syn 包(syn=j)到服務器，並進入 SYN_SEND 狀態，等待服務器確認；
第二次握手：服務器收到 syn 包，必須確認客戶的 SYN（ack=j+1），同時本身也發送一個 SYN 包（syn=k），即 SYN+ACK 包，此時服務器進入 SYN_RECV 狀態；
第三次握手：客戶端收到服務器的 SYN＋ACK 包，向服務器發送確認包 ACK(ack=k+1)，此包發送完畢，客戶端和服務器進入 ESTABLISHED 狀態，完成三次握手。

面試官：爲何是三次握手，而不是兩次或者4次呢？

我：假如說是兩次握手，若是客戶端本身處理異常或者是服務器返回的ack消息丟失，那麼客服端會認爲鏈接創建失敗，再次從新發送請求創建鏈接，可是服務端卻無感知，覺得鏈接以及正常創建，致使服務器創建無用的鏈接，浪費資源

假如四次握手，若是三次已經足夠，那就不須要四次了。若是四次的話，最後一個ACK丟失，那麼又會出現兩次握手的問題。

面試官：居然都到說了三次握手，那就說說四次揮手吧？

我：

客戶端向服務器發送FIN但願斷開鏈接請求。
服務器向客戶端發送ACK，表示贊成釋放鏈接。
服務器向客戶端發送一個FIN表示但願斷開鏈接。
客戶端向服務器返回一個ACK表示贊成釋放鏈接。

面試官：爲何斷開鏈接須要四次而不是三次呢？

我：由於當服務器收到客戶端斷開鏈接的請求後，服務器不能當即斷開鏈接，由於可能服務器端還有數據未發送完成，因此只能回覆一個ACK表示我已收到消息；等服務器端數據發送完成以後再發送一個FIN但願端開鏈接的消息，客戶端回覆ACK以後，就能夠安全斷開了

面試官：爲何說Http協議無狀態協議？怎麼解決Http協議無狀態？

我：自己HTTP協議是不保存狀態的，自身不對請求和響應直接的通訊狀態進行保存，因此是無狀態的協議。由於在有些場景下咱們須要保存用戶的登陸信息，因此引入了cookie來管理狀態。客戶端第一次請求服務器的時候，服務器會生成cookie添加在響應頭裏面，之後客戶端的每次請求都會帶上這個cookie信息。

面試官：Cookie與Session有什麼區別？

我：

Cookie是有服務器生成，寫入到請求的響應頭中，瀏覽器會保存；服務器經過Set-Cookie字段向客戶端設置Cookie，屬性：
1. Name=value 設置cookie的名字和值
2. expires 設置Cookie的有效期
3. domain=域名表示只能在哪一個域名下生效
4. secure表示只能在Https的通訊時才發送cookie
5. HttpOnly 表示不能被javascript訪問
Session也是服務器生成的，表示服務器中的一片內存，每一個客服端對應一個Session，客戶端之間的Session相互獨立；每次客戶端發起請求，都會帶上Cookie，Cookie裏面通常都會有一個JSESSIONID，服務器就是經過這個JESSIONID來找到客戶端對應Session，因此通常用戶的登陸信息都會存放在Session；這樣也解決了Http協議無狀態的問題

面試官：Http協議中有那些請求方式？如何選擇使用什麼方法？

我：

GET : 獲取資源; 因此查詢操做通常用GET
POST: 傳輸實體主體, 建立更新操做用POST
PUT: 傳輸文件
HEAD: 獲取報文首部，若是想要查詢某個請求的頭信息能夠用這個方法
DELETE: 刪除資源，因此刪除操做用DELETE
OPTIONS: 詢問服務器支持哪些方法，響應頭中返回 Allow: GET,POST,HEAD
TRACE: 追蹤路徑;在請求頭中在Max-Forwards字段設置數字，每通過一個服務器該數字就減一，當到0的時候就直接返回，通常經過該方法檢查請求發送出去是否被篡改

面試官：Http如何實現持久鏈接的呢？

我：（毛線啊，我只是個來面試Java的初級程序員，幹嗎要反覆拿Http來摩擦我呢？！不過沒事，我皮的很，這道題我又會）
我：在HTTP協議的早期，每進行一次HTTP通訊就要斷開一次tcp鏈接，當時傳輸的內容少還能接受，如今每一個網頁通常的會包含大量的圖片，每次請求都會形成TCP鏈接的鏈接和斷開，增長通訊的開銷。

爲了解決這個問題因此想出了持久鏈接的方法，也叫作keep-alive，只要一端沒有提出斷開鏈接就會一直保持TCP鏈接的狀態。持久化鏈接使的客戶端能夠同時併發發送多個請求，不用一個接着一個的等待響應。

面試官：大文件的斷點續傳是如何實現的呢？

我：HTTP請求頭有個Range字段；咱們下載文件的時候若是遇到網絡中斷，若是重頭開始下載會浪費時間，因此咱們能夠從上一次中斷處繼續開始下載；具體的操做：

Range: bytes=5001-10000

或者指定5001之後的全部數據

Range: bytes=5001-

響應返回的狀態碼是206

面試官：剛纔你有提到狀態碼，那常見Http協議狀態碼有哪些？

我：（面試官我簡歷上忘記寫了，我曾經是學霸，記憶力好，背書沒輸過）

我：HTTP的狀態碼主要分爲了四類：

2xx: 成功狀態碼，表示請求正常處理完畢
3xx: 重定向狀態碼，表示須要附加操做才能完成成請求
4xx: 客戶端錯誤狀態碼
5xx: 服務器錯誤狀態碼

常見的狀態碼有： 200（請求正常處理完成）、204（請求處理成功，可是沒有資源返回）、206（表示客戶端進行了範圍請求，響應報文中包含了Content-Range）、301（永久性重定向，請求的資源以及被分配到了新的地址）、302（臨時重定向，但願用戶而且請求新地址）、400（客戶端請求報文出現錯誤，一般是參數錯誤）、401（客戶端未認證錯誤）、403（沒有權限訪問該資源）、404（未找到請求的資源）、405（不支持該請求方法，若是服務器支持GET，客戶端用POST請求就會出現這個錯誤碼）、500（服務器異常）、503（服務器不能提供服務）

我：（這我都能記住，是否是的給我點個贊）（已瘋狂暗示兄弟們點贊，不要白嫖哦）