簡介

HTTP協議(超文本傳輸協議HyperText Transfer Protocol)，它是基於TCP協議的應用層傳輸協議，簡單來說就是客戶端和服務端進行數據傳輸的一種規則。

注意：客戶端與伺服器的角色不是固定的，一端充當客戶端，也可能在某次請求中充當伺服器。這取決與請求的發起端。HTTP協議屬於應用層，建立在傳輸層協議TCP之上。客戶端通過與伺服器建立TCP連接，之後發送HTTP請求與接收HTTP響應都是通過訪問Socket介面來調用TCP協議實現。

HTTP 是一種無狀態 (stateless) 協議, HTTP協議本身不會對發送過的請求和相應的通信狀態進行持久化處理。這樣做的目的是為了保持HTTP協議的簡單性，從而能夠快速處理大量的事務, 提高效率。

然而，在許多應用場景中，我們需要保持用戶登錄的狀態或記錄用戶購物車中的商品。由於HTTP是無狀態協議，所以必須引入一些技術來記錄管理狀態，例如Cookie。

正文

HTTP URL

HTTP URL 包含了用於查找某個資源的詳細信息, 格式如下:

http://host[":"port][abs_path]

HTTP請求

下圖是在網上找的一張圖，覺得能很好的表達HTTP請求的所發送的數據格式。

由上圖可以看到，http請求由請求行，消息報頭，請求正文三部分構成。

HTTP請求狀態行

請求行由請求Method, URL 欄位和HTTP Version三部分構成, 總的來說請求行就是定義了本次請求的請求方式, 請求的地址, 以及所遵循的HTTP協議版本例如：

GET /example.html HTTP/1.1 (CRLF)

HTTP協議的方法有： GET： 請求獲取Request-URI所標識的資源 POST： 在Request-URI所標識的資源後增加新的數據 HEAD： 請求獲取由Request-URI所標識的資源的響應消息報頭 PUT： 請求伺服器存儲或修改一個資源，並用Request-URI作為其標識 DELETE： 請求伺服器刪除Request-URI所標識的資源 TRACE： 請求伺服器回送收到的請求信息，主要用於測試或診斷 CONNECT： 保留將來使用 OPTIONS： 請求查詢伺服器的性能，或者查詢與資源相關的選項和需求

HTTP請求頭

消息報頭由一系列的鍵值對組成，允許客戶端向伺服器端發送一些附加信息或者客戶端自身的信息，主要包括：

HTTP請求正文

只有在發送POST請求時才會有請求正文，GET方法並沒有請求正文。

HTTP請求報文

HTTP響應

與HTTP請求類似，先上一張圖：

HTTP響應也由三部分組成，包括狀態行，消息報頭，響應正文。

HTTP響應狀態行

狀態行也由三部分組成，包括HTTP協議的版本，狀態碼，以及對狀態碼的文本描述。例如：

HTTP/1.1 200 OK （CRLF）

HTTP響應狀態碼

狀態代碼有三位數字組成，第一個數字定義了響應的類別，且有五種可能取值： 1xx：指示信息 - 表示請求已接收，繼續處理 2xx：成功 - 表示請求已被成功接收、理解、接受 3xx：重定向 - 要完成請求必須進行更進一步的操作 4xx：客戶端錯誤 - 請求有語法錯誤或請求無法實現 * 5xx：伺服器端錯誤 - 伺服器未能實現合法的請求

常見狀態代碼、狀態描述、說明： 200： OK - 客戶端請求成功 400： Bad Request - 客戶端請求有語法錯誤，不能被伺服器所理解 401： Unauthorized - 請求未經授權，這個狀態代碼必須和WWW-Authenticate報頭域一起使用 403： Forbidden - 伺服器收到請求，但是拒絕提供服務 404： Not Found - 請求資源不存在，eg：輸入了錯誤的URL 500： Internal Server Error - 伺服器發生不可預期的錯誤 * 503： Server Unavailable - 伺服器當前不能處理客戶端的請求，一段時間後,可能恢復正常

HTTP響應狀態碼說明

HTTP響應報文

HTTP協議詳解

HTTP的五大特點

  1. 支持客戶/伺服器模式。
  2. 簡單快速：客戶向伺服器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與伺服器聯繫的類型不同。由於HTTP協議簡單，使得HTTP伺服器的程序規模小，因而通信速度很快。
  3. 靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
  4. 無連接：無連接的含義是限制每次連接只處理一個請求。伺服器處理完客戶的請求，並收到客戶的應答後，即斷開連接。採用這種方式可以節省傳輸時間。早期這麼做的原因是請求資源少，追求快。後來通過Connection: Keep-Alive實現長連接
  5. 無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在伺服器不需要先前信息時它的應答就較快。

非持久連接和持久連接

在實際的應用中，客戶端往往會發出一系列請求，接著伺服器端對每個請求進行響應。對於這些請求|響應，如果每次都經過一個單獨的TCP連接發送，稱為非持久連接。反之，如果每次都經過相同的TCP連接進行發送，稱為持久連接。

非持久連接在每次請求|響應之後都要斷開連接，下次再建立新的TCP連接，這樣就造成了大量的通信開銷。例如前面提到的往返時間(RTT) 就是在建立TCP連接的過程中的代價。

非持久連接給伺服器帶來了沉重的負擔，每台伺服器可能同時面對數以百計甚至更多的請求。持久連接就是為了解決這些問題，其特點是一直保持TCP連接狀態，直到遇到明確的中斷要求之後再中斷連接。持久連接減少了通信開銷，節省了通信量。

HTTP和HTTPS

HTTP的不足

  • 通信使用明文(不加密),內容可能會被竊聽
  • 不驗證通信方的身份,因此有可能遭遇偽裝
  • 無法證明報文的完整性,所以有可能已遭篡改

HTTPS介紹

HTTP 協議中沒有加密機制,但可以通 過和 SSL(Secure Socket Layer, 安全套接層 )或 TLS(Transport Layer Security, 安全層傳輸協議)的組合使用,加密 HTTP 的通信內容。屬於通信加密，即在整個通信線路中加密。

HTTP + 加密 + 認證 + 完整性保護 = HTTPS（HTTP Secure ）

HTTPS 採用共享密鑰加密（對稱）和公開密鑰加密（非對稱）兩者並用的混合加密機制。若密鑰能夠實現安全交換,那麼有可能會考慮僅使用公開密鑰加密來通信。但是公開密鑰加密與共享密鑰加密相比,其處理速度要慢。

所以應充分利用兩者各自的優勢, 將多種方法組合起來用於通信。 在交換密鑰階段使用公開密鑰加密方式,之後的建立通信交換報文階段 則使用共享密鑰加密方式。

HTTPS握手過程的簡單描述如下：

  1. 瀏覽器將自己支持的一套加密規則發送給網站。 伺服器獲得瀏覽器公鑰
  2. 網站從中選出一組加密演算法與HASH演算法，並將自己的身份信息以證書的形式發回給瀏覽器。證書裡面包含了網站地址，加密公鑰，以及證書的頒發機構等信息。 瀏覽器獲得伺服器公鑰
  3. 獲得網站證書之後瀏覽器要做以下工作： (a). 驗證證書的合法性（頒發證書的機構是否合法，證書中包含的網站地址是否與正在訪問的地址一致等），如果證書受信任，則瀏覽器欄裡面會顯示一個小鎖頭，否則會給出證書不受信的提示。

    (b). 如果證書受信任，或者是用戶接受了不受信的證書，瀏覽器會生成一串隨機數的密碼（接下來通信的密鑰），並用證書中提供的公鑰加密（共享密鑰加密）。

    (c) 使用約定好的HASH計算握手消息，並使用生成的隨機數對消息進行加密，最後將之前生成的所有信息發送給網站。 瀏覽器驗證 -> 隨機密碼 伺服器的公鑰加密 -> 通信的密鑰 通信的密鑰 -> 伺服器
  4. 網站接收瀏覽器發來的數據之後要做以下的操作： (a). 使用自己的私鑰將信息解密取出密碼，使用密碼解密瀏覽器發來的握手消息，並驗證HASH是否與瀏覽器發來的一致。 (b). 使用密碼加密一段握手消息，發送給瀏覽器。 伺服器用自己的私鑰解出隨機密碼 -> 用密碼解密握手消息（共享密鑰通信）-> 驗證HASH與瀏覽器是否一致（驗證瀏覽器） HTTPS的不足
  5. 加密解密過程複雜，導致訪問速度慢
  6. 加密需要認向證機構付費
  7. 整個頁面的請求都要使用HTTPS

歡迎關注技術公眾號： 零壹技術棧

weixin.qq.com/r/VDgkPNH (二維碼自動識別)

本帳號將持續分享後端技術乾貨，包括虛擬機基礎，多線程編程，高性能框架，非同步、緩存和消息中間件，分散式和微服務，架構學習和進階等學習資料和文章。


推薦閱讀：
相关文章