【Java核心面試寶典】Day19、你猜HTTP協議會有什么面試題？

Hello，你好呀，我是灰小猿！一個超會寫bug的程序猿！

用堅持締造技術、用指尖敲動未來！

和很多小伙伴們一樣，我也是一名奔波在Java道路上的“創造者”。也想靠技術來改未來，改變世界！因為我們堅信每一次敲動鍵盤都能讓生活變得更智能、世界變得更有趣！

在此專欄《Java核心面試寶典》記錄我們備戰夢想的【day 19】！

HTTP和HTTPS大家都知道吧？那你知道他們的連接方式、區別、加密方式等等嗎？那今天這篇我就帶大家來總結一下這其中會有哪些常見的面試題呢？

一、HTTP和HTTPS的工作方式【建立連接的過程】

HTTP（超文本傳輸協議） 是一種簡單的請求-響應協議。被用于在web瀏覽器和網站服務器之間傳遞消息，HTTP使用TCP協議作為它的支撐運輸層協議，其默認工作在TCP協議的80端口，HTTP客戶機發起一個與服務器的TCP連接，一旦連接建立，瀏覽器和服務器進程就可以通過套接字接口訪問TCP，客戶機從套接字接口發送HTTP請求報文和接收HTTP響應報文，類似的，服務器也是從套接字接口接收HTTP請求報文和發送HTTP響應報文。其通信內容以明文的形式發送，不通過任何形式的數據加密，當通信結束時，客戶機和服務器關閉連接。

HTTPS是以安全為目的的HTTP協議，在HTTP協議的基礎上，通過傳輸加密和身份認證的方式保證了數據傳輸的安全性，其具體的工作流程是這樣的：

客戶端發起一個HTTPS請求，并連接到服務器的443端口，發送的信息主要包括自身所支持的算法列表和密匙長度。

服務器端將自身所支持的所有加密算法與客戶端的算法列表進行對比并選擇一種支持的加密算法，然后將它和其他密匙組件一起發送給客戶端。

服務器向客戶端發送一個包含數字證書的報文，該數字證書中包含證書的頒發機構、過期時間、服務端的公鑰等信息。

最后服務端發送一個完成報文通知客戶端 SSL 的第一階段已經協商完成。

SSL第一次協商完成后，客戶端發送一個回應報文，報文中包含一個客戶端生成的隨機密碼串，稱為pre_master_secre，并且該報文是經過證書中的公鑰加密過的。

緊接著客戶端會發送一個報文提示服務端在此之后的報文是采用pre_master_secre 加密的。

客戶端向服務端發送一個finish 報文，這次握手中包含第一次握手至今所有報文的整體校驗值，最終協商是否完成取決于服務端能否成功解密。

服務端同樣發送與第 ⑥ 步中相同作用的報文，已讓客戶端進行確認，最后發送 finish 報文告訴客戶端自己能夠正確解密報文。

當服務端和客戶端的 finish 報文交換完成之后，SSL 連接就算建立完成了，之后就進行和 HTTP 相同的通信過程，唯一不同的是在 HTTPS 通信過程中并不是采用明文傳輸，而是采用對稱加密的方式，其中對稱密鑰已經在 SSL 的建立過程中協商好了。

二、說一說HTTPS和HTTP的區別？

HTTP采用明文的形式發送數據，數據不安全；

HTTPS采用對稱加密算法對傳輸的報文進行加密，保證了數據的安全性。

HTTP和HTTPS使用不同的連接方式，所使用端口也是不一樣的，HTTP使用的端口是80端口，HTTPS使用的端口是443。

HTTPS需要向數字認證機構申請證書，一般是需要一定費用的、

HTTP比HTTPS響應速度快，原因是HTTP采用3次握手建立連接，客戶端和服務器需要握手3次，而HTTPS除了需要3次握手之外，還需要經歷SSL的協商過程。

三、HTTPS的加密方式是怎樣的？

HTTPS采用對稱和非對稱相結合的方式，首先使用SSL/TLS協議進行加密傳輸，

為了彌補非對稱加密的不足，HTTPS采用證書來進一步加強非對稱加密的安全性。通過非對稱加密，客戶端和服務器協商好進行通信傳輸的對稱密匙，后續的所有信息通過該對稱密匙進行加密解密，完成整個HTTPS的流程。

所以簡單來說就是： HTTPS首先通過非對稱加密算法將用于通信加密的對稱加密密匙傳輸給對方，然后接下來的通信就使用對稱加密了。

四、客戶端為什么信任第三方證書？

假設中間人篡改了證書原文，由于他沒有 CA 機構的私鑰，所以無法得到此時加密后的簽名，因此無法篡改簽名。客戶端瀏覽器收到該證書后會發現原文和簽名解密后的值不一致，則說明證書被中間人篡改，證書不可信，從而終止向服務器傳輸信息。上述過程說明證書無法被篡改，

我們考慮更嚴重的情況，例如中間人拿到了 CA 機構認證的證書，它想竊取網站 A 發送給客戶端的信息，于是它成為中間人攔截到了 A 傳給客戶端的證書，然后將其替換為自己的證書。此時客戶端瀏覽器收到的是被中間人掉包后的證書，但由于證書里包含了客戶端請求的網站信息，因此客戶端瀏覽器只需要把證書里的域名與自己請求的域名比對一下就知道證書有沒有被掉包了。

五、HTTP/1.1和HTTP/1.0的區別？

主要區別如下：

緩存處理： 在 HTTP/1.0 中主要使用 header 里的 if-modified-Since, Expries 來做緩存判斷的標準。而 HTTP/1.1 請求頭中添加了更多與緩存相關的字段，從而支持更為靈活的緩存策略，例如 Entity-tag, If-Unmodified-Since, If-Match, If-None-Match 等可供選擇的緩存頭來控制緩存策略。

節約帶寬： 當客戶端請求某個資源時，HTTP/1.0 默認將該資源相關的整個對象傳送給請求方，但很多時候可能客戶端并不需要對象的所有信息。而在 HTTP/1.1 的請求頭中引入了 range 頭域，它允許只請求部分資源，其使得開發者可以多線程請求某一資源，從而充分的利用帶寬資源，實現高效并發。

錯誤通知的管理： HTTP/1.1 在 1.0 的基礎上新增了 24 個錯誤狀態響應碼，例如 414 表示客戶端請求中所包含的 URL 地址太長，以至于服務器無法處理；410 表示所請求的資源已經被永久刪除。

Host 請求頭： 早期 HTTP/1.0 中認為每臺服務器都綁定一個唯一的 IP 地址并提供單一的服務，請求消息中的 URL 并沒有傳遞主機名。而隨著虛擬主機的出現，一臺物理服務器上可以存在多個虛擬主機，并且它們共享同一個 IP 地址。為了支持虛擬主機，HTTP/1.1 中添加了 host 請求頭，請求消息和響應消息中應聲明這個字段，若請求消息中缺少該字段時服務端會響應一個 404 錯誤狀態碼。

長連接： HTTP/1.0 默認瀏覽器和服務器之間保持短暫連接，瀏覽器的每次請求都需要與服務器建立一個 TCP 連接，服務器完成后立即斷開 TCP 連接。HTTP/1.1 默認使用的是持久連接，其支持在同一個 TCP 請求中傳送多個 HTTP 請求和響應。此之前的 HTTP 版本的默認連接都是使用非持久連接，如果想要在舊版本的 HTTP 協議上維持持久連接，則需要指定 Connection 的首部字段的值為 Keep-Alive。

六、HTTP/1.X 和 HTTP/2.0 的區別知道嗎？

相比于 HTTP/1.X 的文本（字符串）傳送， HTTP/2.0 采用二進制傳送。客戶端和服務器傳輸數據時把數據分成幀，幀組成了數據流，流具有流 ID 標識和優先級，通過優先級以及流依賴能夠一定程度上解決關鍵請求被阻塞的問題。

HTTP/2.0 支持多路復用。因為流 ID 的存在， 通過同一個 HTTP 請求可以實現多個 HTTP 請求傳輸，客戶端和服務器可以通過流 ID 來標識究竟是哪個流從而定位到是哪個 HTTP 請求。

HTTP/2.0 頭部壓縮。HTTP/2.0 通過 gzip 和 compress 壓縮頭部然后再發送，同時通信雙方會維護一張頭信息表，所有字段都記錄在這張表中，在每次 HTTP 傳輸時只需要傳頭字段在表中的索引即可，大大減小了重傳次數和數據量。

HTTP/2.0 支持服務器推送。 服務器在客戶端未經請求許可的情況下，可預先向客戶端推送需要的內容，客戶端在退出服務時可通過發送復位相關的請求來取消服務端的推送。

七、HTTP/3了解嗎？

HTTP/3之所以會出現，是因為HTTP/2存在一定的弊端，

我們知道，傳統 Web 平臺的數據傳輸都基于 TCP 協議，而 TCP 協議在創建連接之前不可避免的需要三次握手，如果需要提高數據交互的安全性，即增加傳輸層安全協議（TLS），還會增加更多的握手次數。 HTTP 從 1.0 到 2.0，其傳輸層都是基于 TCP 協議的。即使是帶來巨大性能提升的 HTTP/2，也無法完全解決 TCP 協議存在的固有問題（慢啟動，擁塞窗口尺寸的設置等）。此外，HTTP/2 多路復用只是減少了連接數，其隊頭的擁塞問題并沒有完全解決，倘若 TCP 丟包率過大，則 HTTP/2 的表現將不如 HTTP/1.1。

HTTP/3則是在QUIC（快速UDP網絡連接）的基礎上建立起來的，

QUIC的特點是： 低延遲連接、能夠避免HTTP/2的對頭阻塞問題、傳輸的報文是經過加密和認證的、具有向前糾錯機制，

HTTP/3的底層使用UDP進行數據傳輸，上層仍然使用HTTP/2。在 UDP 與 HTTP/2 之間存在一個 QUIC 層，其中 TLS 加密過程在該層進行處理。HTTP/3 主要有以下幾個特點：

使用 UDP 作為傳輸層進行通信；

在 UDP 之上的 QUIC 協議保證了 HTTP/3 的安全性。QUIC在建立連接的過程中就完成了 TLS 加密握手；

建立連接快，正常只需要 1 RTT即可建立連接。如果有緩存之前的會話信息，則直接驗證和建立連接，此過程 0 RTT。建立連接時，也可以帶有少量業務數據；

不和具體底層連接綁定，QUIC 為每個連接的兩端分別分配了一個唯一 ID，上層連接只認這對邏輯ID。網絡切換或者斷連時，只需要繼續發送數據包即可完成連接的建立；

使用 QPACK 進行頭部壓縮，因為 在 HTTP/2 中的HPACK 要求傳輸過程有序，這會導致隊頭阻塞，而 QPACK 不存在這個問題。

最后用這個圖來表示HTTP的三次發展變化：

今日總結

今天的題目主要是關于HTTP協議的，理論性比較強，但是需要記憶的東西還是比較多的，包括HTTP和HTTPS的工作方式、區別、HTTPS的加密方式等。

如果小伙伴們有遇到其他相關的面試題，歡迎在評論區留言提出，我會把大家提出的總結到文章內, 歡迎小伙伴們一起評論區打卡學習！小伙伴們可也在左方加我好友一起探討學習！

我是灰小猿，我們下期見！

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。