面試官：今天要不來聊聊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
原創不易！！求三連！！
更多的文章可往：文章的目錄導航