面試官問我HTTP,我真的是

語言: CN / TW / HK

面試官 今天要不來聊聊HTTP吧?

候選者 :嗯,HTTP「協議」是客戶端和伺服器「互動」的一種通迅的格式

候選者 :所謂的「協議」實際上就是雙方約定好的「格式」,讓雙方都能看得懂的東西而已

候選者 :所謂的互動實際上就是「請求」和「響應」

面試官 那你知道HTTP各個版本之間的區別嗎?

候選者 :HTTP1.0預設是短連線,每次與伺服器互動,都需要新開一個連線

候選者 :HTTP1.1版本最主要的是「預設持久連線」。只要客戶端服務端沒有斷開TCP連線,就一直保持連線,可以傳送多次HTTP請求。

候選者 :其次就是「斷點續傳」(Chunked transfer-coding)。利用HTTP訊息頭使用分塊傳輸編碼,將實體主體分塊進行傳輸

候選者 :HTTP/2不再以文字的方式傳輸,採用「二進位制分幀層」,對頭部進行了「壓縮」,支援「流控」,最主要就是HTTP/2是支援「多路複用」的(通過單一的TCP連線「並行」發起多個的請求和響應訊息)

面試官 :嗯,稍微打斷下。 我知道HTTP1.1版本有個管線化(pipelining)理論,但預設是關閉的。管線化這個跟HTTP/2的「多路複用」是很類似的,它們有什麼區別呀?

候選者 :HTTP1.1提出的「管線化」只能「序列」(一個響應必須完全返回後,下一個請求才會開始傳輸)

候選者 :HTTP/2多路複用則是利用「分幀」資料流,把HTTP協議分解為「互不依賴」的幀(為每個幀「標序」傳送,接收回來的時候按序重組),進而可以「亂序」傳送避免「一定程度上」的隊首阻塞問題

候選者 :但是,無論是HTTP1.1還是HTTP/2,response響應的「處理順序」總是需要跟request請求順序保持一致的。假如某個請求的response響應慢了,還是同樣會有阻塞的問題。

候選者 :這受限於HTTP底層的傳輸協議是TCP,沒辦法完全解決「線頭阻塞」的問題

面試官 :哦,好的。

候選者 :HTTP/3 跟前面版本最大的區別就是:HTTP1.x和HTTP/2底層都是TCP,而HTTP/3底層是UDP。使用HTTP/3能夠減少RTT「往返時延」(TCP三次握手,TLS握手)

面試官 你瞭解HTTPS的過程嗎?

候選者 :嗯啊,HTTPS在我的理解下,就是「安全」的HTTP協議(客戶端與服務端的傳輸鏈路中進行加密)

候選者 :HTTPS首先要解決的是:認證的問題

候選者 :客戶端是需要確切地知道服務端是不是「真實」,所以在HTTPS中會有一個角色:CA(公信機構)

候選者 :服務端在使用HTTPS前,需要去認證的CA機構申請一份「數字證書」。數字證書裡包含有證書持有者、證書有效期、「伺服器公鑰」等資訊

候選者 :CA機構也有自己的一份公私鑰,在釋出數字證書之前,會用自己的「私鑰」對這份數字證書進行加密

候選者 :等到客戶端請求伺服器的時候,服務端返回證書給客戶端。客戶端用CA的公鑰對證書解密(因為CA是公信機構,會內建到瀏覽器或作業系統中,所以客戶端會有公鑰)。這個時候,客戶端會判斷這個「證書是否可信/有無被篡改」

候選者 :私鑰加密,公鑰解密我們叫做「數字簽名」(這種方式可以檢視有無被篡改)

候選者 :到這裡,就解決了「認證」的問題,至少客戶端能保證是在跟「真實的伺服器」進行通訊。

候選者 :解決了「認證」的問題之後,就要解決「保密」問題,客戶端與伺服器的通訊內容在傳輸中不會洩露給第三方

候選者 :客戶端從CA拿到數字證書後,就能拿到服務端的公鑰

候選者 :客戶端生成一個Key作為「對稱加密」的祕鑰,用服務端的「公鑰加密」傳給服務端

候選者 :服務端用自己的「私鑰解密」客戶端的資料,得到對稱加密的祕鑰

候選者 :之後客戶端與服務端就可以使用「對稱加密的祕鑰」愉快地傳送和接收訊息

面試官 :瞭解了

歡迎關注我的微信公眾號【 Java3y 】來聊聊Java面試,對線面試官系列持續更新中!

【對線面試官+從零編寫Java專案】 持續高強度更新中!求star

原創不易!!求三連!!