iwehdio的部落格園：https://www.cnblogs.com/iwehdio/

學習自：

• 你每天都在使用的HTTP協議，到底是什麼鬼？（這篇寫的好差）
• HTTP協議格式詳解
• 硬核！30 張圖解 HTTP 常見的面試題（寫得好）

什麼是HTTP？

• HTTP是超文字傳輸協議，HTTP是縮寫，它的全英文名是HyperText Transfer Protocol。
• 什麼是超文字呢？
  • 超文字指的是HTML，css，JavaScript和圖片等，HTTP的出現是為了接收和釋出HTML頁面，經過不斷的發展也可以用於接收一些音訊，視訊，檔案等內容。
• 請求訪問文字或圖片等資源的一方，我們叫做客戶端；負責接收，提供響應的一方稱為伺服器端。
• Client客戶端請求Server服務端，Server服務端響應給Client客戶端。一次請求和一次響應就達成了一次通訊。
• HTTP的特點：
  • HTTP都是由客戶端發起請求的，並且由伺服器端迴應響應訊息的。
  • 簡單快速，客戶端向伺服器端請求服務時，只需傳送請求方法和路徑。
  • 靈活，允許傳輸任何型別的資料物件，包括音訊，視訊，圖片，檔案等等。
  • 無狀態，就是說，每次HTTP請求都是獨立的，任何兩個請求之間沒有必然的聯絡。
  • 無連線的，每次伺服器在處理完客戶端的請求後，並收到客戶的應答後，就斷開了通訊，當客戶端再次傳送請求時就是一個新的連線。
• HTTP的缺點：
  • 明文傳輸。
  • 不安全。HTTP 的安全問題，可以用 HTTPS 的方式解決，也就是通過引入 SSL/TLS 層，增加了安全性。
• 無連線是HTTP/1.0版的主要缺點，每個TCP連線只能傳送一個請求，傳送資料完畢後，連線就關閉了，如果還要請求就必須要新建一個請求連線。
• HTTP1.1雖然是無狀態協議，但是為了實現期望的保持狀態功能，於是引入了Cookie技術，有了Cookie，和HTTP協議通訊，就可以管理狀態了。
• HTTP1.1版本是最流行的版本，可以持久連線，TCP連線預設不關閉，可以被多個請求複用，只有在一段時間內，沒有請求，才自動關閉（keep-alive）。

HTTP訊息結構

• 請求訊息：

  • 請求行。包括請求方式，請求URI和HTTP協議版本。
  • 請求頭。鍵值對格式的相關請求資訊。
  • 請求空行。
  • 訊息體。請求內容。

• 響應訊息：

  • 狀態行。包括HTTP協議版本，狀態碼和狀態訊息。
  • 響應頭。鍵值對格式的相關響應資訊。
  • 響應空行。
  • 響應體。響應內容。

• 狀態碼：HTTP協議的狀態碼由3位數字組成，第一個數字定義了響應的類別，共有5中類別：

  • 1xx: 指示資訊--表示請求已接收，繼續處理。
  • 2xx: 成功--表示請求已被成功接收、理解、接受。
  • 3xx: 重定向--要完成請求必須進行更進一步的操作。
  • 4xx: 客戶端錯誤--請求有語法錯誤或請求無法實現。
  • 5xx: 伺服器端錯誤--伺服器未能實現合法的請求。

• 請求方法：

  • HTTP定義了多種請求方法，來滿足各種需求。
  • HTTP/1.0定義了三種請求方法：GET、POST 和 HEAD。
  • 到了HTTP/1.1，新增了五種請求方法：OPTIONS、PUT、DELETE、TRACE 和 CONNECT。
  • 各個請求方法的具體功能如下：

  GET         請求指定的頁面資訊，並返回實體主體。
  HEAD        類似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭
  POST        向指定資源提交資料進行處理請求（例如提交表單或者上傳檔案）。資料被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。
  PUT         從客戶端向伺服器傳送的資料取代指定的文件的內容。
  DELETE      請求伺服器刪除指定的頁面。
  CONNECT     HTTP/1.1協議中預留給能夠將連線改為管道方式的代理伺服器。
  OPTIONS     允許客戶端檢視伺服器的效能。
  TRACE       回顯伺服器收到的請求，主要用於測試或診斷。
  

• 常見欄位：

  • 請求欄位：
    • Host：客戶端傳送請求時，用來指定伺服器的域名。
    • Connection：常用於客戶端要求伺服器使用 TCP 持久連線，以便其他請求複用。HTTP/1.1 版本的預設連線都是持久連線。
    • Accept：宣告自己可以接受哪些資料格式。
    • Accept-Encoding：說明自己可以接受哪些壓縮方法。
  • 響應欄位：
    • Content-Length：表明本次迴應的資料長度。
    • Content-Type：用於伺服器迴應時，告訴客戶端，本次資料是什麼格式。
    • Content-Encoding：說明資料的壓縮方法。

• GET與POST的區別：

  • 含義的不同：

    • GET請求是從伺服器請求URI獲取資源。
    • POST請求是往URI提交資料。

  • 請求引數的區別：

    • GET請求會把請求的引數拼接在URL後面，以?分隔，多個引數之間用&連線；如果是英文或數字，原樣傳送，如果是空格或中文，則用Base64編碼。
    • POST請求會把提交的資料放在請求體中，不會在URL中顯示出來。

  • 傳輸資料的大小：

    • GET: 瀏覽器和伺服器會限制URL的長度，所以傳輸的資料有限，一般是2K。
    • POST: 由於資料不是通過URL傳遞，所以一般可以傳輸較大量的資料。

  • 安全性：

    • GET: 請求引數在URL後面，可以直接看到。
    • POST: 請求引數在請求體裡面傳輸，無法直接拿到，相對GET安全性較高；但是通過抓包工具，還是可以看到請求引數的。

• 安全和冪等的概念：

  • 在 HTTP 協議裡，所謂的「安全」是指請求方法不會「破壞」伺服器上的資源。
  • 所謂的「冪等」，意思是多次執行相同的操作，結果都是「相同」的。
  • GET 方法就是安全且冪等的，因為它是「只讀」操作，無論操作多少次，伺服器上的資料都是安全的，且每次的結果都是相同的。
  • POST 因為是「新增或提交資料」的操作，會修改伺服器上的資源，所以是不安全的，且多次提交資料就會建立多個資源，所以不是冪等的。

HTTP效能

• HTTP 1.1協議是基於 TCP/IP，並且使用了「請求 - 應答」的通訊模式，所以效能的關鍵就在這兩點裡。

• 長連線：

  • 早期 HTTP/1.0 效能上的一個很大的問題，那就是每發起一個請求，都要新建一次 TCP 連線（三次握手），而且是序列請求，做了無畏的 TCP 連線建立和斷開，增加了通訊開銷。
  • 為了解決上述 TCP 連線問題，HTTP/1.1 提出了長連線的通訊方式，也叫持久連線。這種方式的好處在於減少了 TCP 連線的重複建立和斷開所造成的額外開銷，減輕了伺服器端的負載。
  • 持久連線的特點是，只要任意一端沒有明確提出斷開連線，則保持 TCP 連線狀態。

• 管道網路傳輸：

  • HTTP/1.1 採用了長連線的方式，這使得管道（pipeline）網路傳輸成為了可能。
  • 即可在同一個 TCP 連線裡面，客戶端可以發起多個請求，只要第一個請求發出去了，不必等其回來，就可以發第二個請求出去，可以減少整體的響應時間。
  • 舉例來說，客戶端需要請求兩個資源。以前的做法是，在同一個TCP連線裡面，先發送 A 請求，然後等待伺服器做出迴應，收到後再發出 B 請求。管道機制則是允許瀏覽器同時發出 A 請求和 B 請求。
  • 但是伺服器還是按照順序，先回應 A 請求，完成後再回應 B 請求。要是 前面的迴應特別慢，後面就會有許多請求排隊等著。這稱為「隊頭堵塞」。

• 隊頭阻塞：

  • 「請求 - 應答」的模式加劇了 HTTP 的效能問題。因為當順序傳送的請求序列中的一個請求因為某種原因被阻塞時，在後面排隊的所有請求也一同被阻塞了，會招致客戶端一直請求不到資料，這也就是「隊頭阻塞」。
  • 總之 HTTP/1.1 的效能一般般，後續的 HTTP/2 和 HTTP/3 就是在優化 HTTP 的效能。

HTTPS

• HTTP 與 HTTPS 有哪些區別？
  • HTTP 是超文字傳輸協議，資訊是明文傳輸，存在安全風險的問題。HTTPS 則解決 HTTP 不安全的缺陷，在 TCP 和 HTTP 網路層之間加入了 SSL/TLS 安全協議，使得報文能夠加密傳輸。
  • HTTP 連線建立相對簡單， TCP 三次握手之後便可進行 HTTP 的報文傳輸。而 HTTPS 在 TCP 三次握手之後，還需進行 SSL/TLS 的握手過程，才可進入加密報文傳輸。
  • HTTP 的埠號是 80，HTTPS 的埠號是 443。
  • HTTPS 協議需要向 CA（證書權威機構）申請數字證書，來保證伺服器的身份是可信的。
• HTTPS 解決了 HTTP 的哪些問題？
  • HTTP存在的安全問題：
    • 竊聽風險，比如通訊鏈路上可以獲取通訊內容。
    • 篡改風險，比如強制入垃圾廣告，視覺汙染。
    • 冒充風險，比如冒充淘寶網站。
  • 加入SSL/TSL協議後的HTTPS：
    • 資訊加密：互動資訊無法被竊取。
    • 校驗機制：無法篡改通訊內容，篡改了就不能正常顯示。
    • 身份證書：證明淘寶是真的淘寶網。
• HTTPS 是如何解決上面的三個風險的？
  • 混合加密的方式實現資訊的機密性，解決了竊聽的風險。
  • 摘要演算法的方式來實現完整性，它能夠為資料生成獨一無二的「指紋」，指紋用於校驗資料的完整性，解決了篡改的風險。
  • 將伺服器公鑰放入到數字證書中，解決了冒充的風險。

具體的加密方法和SSL/TLS 的建立過程之後再看。

HTTP協議演進

• HTTP/1.1 相比 HTTP/1.0 提高了什麼效能？

  • 使用 TCP 長連線的方式改善了 HTTP/1.0 短連線造成的效能開銷。
  • 支援 管道（pipeline）網路傳輸，只要第一個請求發出去了，不必等其回來，就可以發第二個請求出去，可以減少整體的響應時間。

• HTTP/1.1 還是有效能瓶頸：

  • 傳送冗長的首部。每次互相傳送相同的首部造成的浪費較多；
  • 伺服器是按請求的順序響應的，如果伺服器響應慢，會招致客戶端一直請求不到資料，也就是隊頭阻塞；
  • 沒有請求優先順序控制；
  • 請求只能從客戶端開始，伺服器只能被動響應。

• 針對HTTP/1.1 的效能瓶頸，HTTP/2 做了什麼優化？

  • HTTP/2 協議是基於 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。

  • 頭部壓縮：

    • HTTP/2 會壓縮頭（Header）如果你同時發出多個請求，他們的頭是一樣的或是相似的，那麼，協議會幫你消除重複的分。
    • 這就是所謂的 HPACK 演算法：在客戶端和伺服器同時維護一張頭資訊表，所有欄位都會存入這個表，生成一個索引號，以後就不傳送同樣欄位了，只發送索引號，這樣就提高速度了。

  • 二進位制格式：

    • 頭資訊和資料體都是二進位制，並且統稱為幀（frame）：頭資訊幀和資料幀。
    • 直接解析二進位制報文，增加了資料傳輸的效率。

  • 資料流：

    • HTTP/2 的資料包不是按順序傳送的，同一個連線裡面連續的資料包，可能屬於不同的迴應。因此，必須要對資料包做標記，指出它屬於哪個迴應。
    • 每個請求或迴應的所有資料包，稱為一個數據流（Stream）。
    • 每個資料流都標記著一個獨一無二的編號，其中規定客戶端發出的資料流編號為奇數， 伺服器發出的資料流編號為偶數。
    • 客戶端還可以指定資料流的優先順序。優先順序高的請求，伺服器就先響應該請求。

  • 多路複用：

    • HTTP/2 是可以在一個連線中併發多個請求或迴應，而不用按照順序一一對應。
    • 移除了 HTTP/1.1 中的序列請求，不需要排隊等待，也就不會再出現「隊頭阻塞」問題，降低了延遲，大幅度提高了連線的利用率。
    • 舉例來說，在一個 TCP 連線裡，伺服器收到了客戶端 A 和 B 的兩個請求，如果發現 A 處理過程非常耗時，於是就迴應 A 請求已經處理好的部分，接著迴應 B 請求，完成後，再回應 A 請求剩下的部分。

  • 伺服器推送：

    • HTTP/2 還在一定程度上改善了傳統的「請求 - 應答」工作模式，服務不再是被動地響應，也可以主動向客戶端傳送訊息。
    • 舉例來說，在瀏覽器剛請求 HTML 的時候，就提前把可能會用到的 JS、CSS 檔案等靜態資源主動發給客戶端，減少延時的等待，也就是伺服器推送（Server Push，也叫 Cache Push）。

• HTTP/2 有哪些缺陷？HTTP/3 做了哪些優化？

  • HTTP/2 主要的問題在於：多個 HTTP 請求在複用一個 TCP 連線，下層的 TCP 協議是不知道有多少個 HTTP 請求的。
  • 所以一旦發生了丟包現象，就會觸發 TCP 的重傳機制，這樣在一個 TCP 連線中的所有的 HTTP 請求都必須等待這個丟了的包被重傳回來。
    • 這都是基於 TCP 傳輸層的問題，所以 HTTP/3 把 HTTP 下層的 TCP 協議改成了 UDP。
    • UDP 傳送是不管順序，也不管丟包的，所以不會出現 HTTP/1.1 的隊頭阻塞 和 HTTP/2 的一個丟包全部重傳問題。
    • UDP 是不可靠傳輸的，但基於 UDP 的 QUIC 協議 可以實現類似 TCP 的可靠性傳輸。
    • QUIC 有自己的一套機制可以保證傳輸的可靠性的。當某個流發生丟包時，只會阻塞這個流，其他流不會受到影響。
  • TL3 升級成了最新的 1.3 版本，頭部壓縮演算法也升級成了 QPack。
  • HTTPS 要建立一個連線，要花費 6 次互動，先是建立三次握手，然後是 TLS/1.3 的三次握手。QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次互動合併成了 3 次，減少了互動次數。
  • QUIC 是新協議，對於很多網路裝置，根本不知道什麼是 QUIC，只會當做 UDP，這樣會出現新的問題。所以 HTTP/3 現在普及的進度非常的緩慢。