面試官：今天要不來聊聊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專案】 持續高強度更新中！求star
原創不易！！求三連！！