面試官問我HTTP，我真的是

面試官：今天要不來聊聊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面試，對線面試官系列持續更新中！

原創不易！！求三連！！