1. URL 和 URI

與 URI（Uniform Resource Identifier，統一資源識別符號） 相比，我們更熟悉 URL（UniformResource Locator，統一資源定位符），URL正是使用 Web 瀏覽器等訪問 Web 頁面時需要輸入的網頁地址，

每個URL地址由兩部分組成：存放物件的服務器主機名和物件的路徑名，

1.1 統一資源識別符號

URI 是 Uniform Resource Identifier 的縮寫，RFC2396 分別對這 3 個單詞進行了如下定義，

• Uniform：規定統一的格式可方便處理多種不同型別的資源，而不用根據背景關系環境來識別資源指定的訪問方式，另外，加入新增的協議方案（如http: 或 ftp:）也更容易，
• Resource：資源的定義是“可標識的任何東西”，另外，資源不僅可以是單一的，也可以是多數的集合體，
• Identifier：表示可標識的物件，也稱為識別符號，

URI 可以用字串標識某一互聯網資源，而 URL表示資源的地點（互聯網上所處的位置），可見 URL是 URI 的子集，

1.2 URL格式

• 登錄資訊（認證）：指定用戶名和密碼作為從服務器端獲取資源時必要的登錄資訊（身份認證），此項是可選項，
• 服務器地址：使用絕對 URI 必須指定待訪問的服務器地址，地址可以是類似hackr.jp 這種 DNS 可決議的名稱，或是 192.168.1.1 這類 IPv4 地址名，還可以是 [0:0:0:0:0:0:0:1] 這樣用方括號括起來的 IPv6 地址名，
• 服務器埠號：指定服務器連接的網路埠號，此項也是可選項，若用戶省略則自動使用默認埠號，
• 帶層次的檔案路徑：指定服務器上的檔案路徑來定位特指的資源，這與 UNIX 系統的檔案目錄結構相似，
• 查詢字串：針對已指定的檔案路徑內的資源，可以使用查詢字串傳入任意引數，此項可選，
• 片段識別符號：使用片段識別符號通常可標記出已獲取資源中的子資源（檔案內的某個位置），但在 RFC 中并沒有明確規定其使用方法，該項也為可選項，

2. HTTP報文

HTTP 報文是在 HTTP 應用程式之間發送的資料塊，這些資料塊以一些文本形式的元資訊（meta-information）開頭，這些資訊描述了報文的內容及含義，后面跟著可選的資料部分，這些報文在客戶端、服務器和代理之間流動，

2.1 報文的組成部分

HTTP 報文是簡單的格式化資料塊，每條報文都包含一條來自客戶端的請求，或者一條來自服務器的回應，它們由三個部分組成：對報文進行描述的起始行（start line）、包含屬性的首部（header）塊，以及可選的、包含資料的主體（body）部分，

2.1.1 起始行

所有的 HTTP 報文都以一個起始行作為開始，

• 請求行
  • 請求報文請求服務器對資源進行一些操作，請求報文的起始行，或稱為請求行，包含了一個方法和一個請求 URL，還包含 HTTP 的版本號，
• 回應行
  • 回應報文承載了狀態資訊和操作產生的所有結果資料，將其回傳給客戶端，回應報文的起始行，或稱為回應行，
  • 包含了回應報文使用的 HTTP 版本、數字狀態碼，以及描述操作狀態的文本形式的原因短語，

2.1.2 首部

跟在起始行后面的就是零個、一個或多個 HTTP 首部欄位，HTTP 首部欄位向請求和回應報文中添加了一些附加資訊，本質上來說，它們只是一些名 / 值對（鍵值對）的串列，

HTTP 規范定義了幾種首部欄位，應用程式也可以隨意發明自己所用的首部，HTTP首部可以分為以下五類，

• 通用首部：既可以出現在請求報文中，也可以出現在回應報文中， 不論報文是何型別，都為其提供一些有用資訊，

  • 

• 請求首部：提供更多有關請求的資訊，

  • 

• 回應首部：提供更多有關回應的資訊，

  • 

• 物體首部：描述主體的長度和內容，或者資源自身，

  • 

• 擴展首部：規范中沒有定義的新首部，

2.1.3 物體的主體部分

HTTP 報文的第三部分是可選的物體主體部分，她與首部之間有一個空行，物體的主體是 HTTP 報文的負荷，就是 HTTP 要傳輸的內容，

HTTP 報文可以承載很多型別的數字資料：圖片、視頻、HTML 檔案、軟體應用程式、信用卡事務、電子郵件等，

2.2 HTTP 方法

• GET：獲取資源
  • GET 方法用來請求訪問已被 URI 識別的資源，指定的資源經服務器端決議后回傳回應內容，
• POST：傳輸物體主體
  • POST 方法用來傳輸物體的主體，資料就放在報?的 body ?，
• PUT：傳輸檔案
  • PUT 方法用來傳輸檔案，就像 FTP 協議的檔案上傳一樣，要求在請求報文的主體中包含檔案內容，然后保存到請求 URI 指定的位置，
  • 但是，鑒于 HTTP/1.1 的 PUT 方法自身不帶驗證機制，任何人都可以上傳檔案 , 存在安全性問題，因此一般的 Web 網站不使用該方法，或者要進行密碼驗證之后可以上傳，
• HEAD：獲得報文首部
  • HEAD 方法和 GET 方法一樣，只是不回傳報文主體部分，用于確認URI 的有效性及資源更新的日期時間等，
• DELETE：洗掉檔案
  • DELETE 方法用來洗掉檔案，是與 PUT 相反的方法，DELETE 方法按請求 URI 洗掉指定的資源，
  • 和PUT一樣不帶驗證機制所以存在安全問題，
• OPTIONS：詢問支持的方法
  • OPTIONS 方法用來查詢針對請求 URI 指定的資源支持的方法，就是查詢某個資源可以使用什么方法，回傳GET、POST等，
• TRACE：追蹤路徑
  • TRACE 方法是讓 Web 服務器端將之前的請求通信環回給客戶端的方法，
• CONNECT：要求用隧道協議連接代理
  • CONNECT 方法要求在與代理服務器通信時建立隧道，實作用隧道協議進行 TCP 通信，主要使用 SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協議把通信內容加密后經網路隧道傳輸，

2.3 HTTP 狀態碼

狀態碼的職責是當客戶端向服務器端發送請求時，描述回傳的請求結果，借助狀態碼，用戶可以知道服務器端是正常處理了請求，還是出現了錯誤，

這里僅介紹幾種常見的狀態碼

• 2XX 成功：2XX 的回應結果表明請求被正常處理了，
  • 200 OK：表示從客戶端發來的請求在服務器端被正常處理了，
  • 204 No Content：該狀態碼代表服務器接收的請求已成功處理，但在回傳的回應報文中不含物體的主體部分，
  • 206 Partial Content：該狀態碼表示客戶端進行了范圍請求（只要其中一部分），而服務器成功執行了這部分的GET 請求，
• 3XX 重定向：3XX 回應結果表明瀏覽器需要執行某些特殊的處理以正確處理請求，
  • 301 Moved Permanently：永久性重定向，該狀態碼表示請求的資源已被分配了新的 URI，以后應使用資源現在所指的 URI，
  • 302 Found：臨時性重定向，該狀態碼表示請求的資源已被分配了新的 URI，希望用戶（本次）能使用新的 URI 訪問，
  • 303 See Other：該狀態碼表示由于請求對應的資源存在著另一個 URI，應使用 GET方法定向獲取請求的資源，
  • 304 Not Modified：該狀態碼表示客戶端發送附帶條件的請求時，服務器端允許請求訪問資源，但不存在滿足條件的情況，
  • 307 Temporary Redirect：臨時重定向，該狀態碼與 302 Found 有著相同的含義，
• 4XX 客戶端錯誤：4XX 的回應結果表明客戶端是發生錯誤的原因所在，
  • 400 Bad Request：該狀態碼表示請求報文中存在語法錯誤，當錯誤發生時，需修改請求的內容后再次發送請求，
  • 401 Unauthorized：該狀態碼表示發送的請求需要有通過 HTTP 認證（BASIC 認證、DIGEST 認證）的認證資訊，
  • 403 Forbidden：該狀態碼表明對請求資源的訪問被服務器拒絕了，
  • 404 Not Found：該狀態碼表明服務器上無法找到請求的資源，
• 5XX 服務器錯誤：5XX 的回應結果表明服務器本身發生錯誤，
  • 500 Internal Server Error：該狀態碼表明服務器端在執行請求時發生了錯誤，
  • 503 Service Unavailable：該狀態碼表明服務器暫時處于超負載或正在進行停機維護，現在無法處理請求，

3. HTTP 連接

HTTP 連接的性能很大程度上取決于TCP連接的性能，此處暫不考慮TCP的種種具體實作，只要知道TCP的連接和斷開連接都存在時延，如果只對連接進行簡單的管理，TCP 的性能時延可能會疊加起來，

例如， 假設有一個包含了 3 個嵌入圖片的 Web 頁面，瀏覽器需要發起 4 個 HTTP 事務來顯示此頁面：1 個用于頂層的 HTML 頁面，3 個用于嵌入的圖片，如果每個事務都需要（串行地建立）一條新的連接，那么連接時延和慢啟動時延就會疊加起來，

所以提供了一些方法可以提高HTTP的連接性能：

• 并行連接：通過多條 TCP 連接發起并發的 HTTP 請求，
• 持久連接：重用 TCP 連接，以消除連接及關閉時延，
• 管道化連接：通過共享的 TCP 連接發起并發的 HTTP 請求，
• 復用的連接：交替傳送請求和回應報文（實驗階段），

以下會進行詳細介紹：

3.1 并行連接

HTTP 允許客戶端打開多條連接，并行地執行多個 HTTP 事務，在這個例子中，并行加載了四幅嵌入式圖片，每個事務都有自己的 TCP 連接，

并行連接可能會提高頁面的加載速度

• 包含嵌入物件的組合頁面如果能（通過并行連接）克服單條連接的空載時間和帶寬限制，加載速度也會有所提高，
• 時延可以重疊起來，而且如果單條連接沒有充分利用客戶端的因特網帶寬，可以將未用帶寬分配來裝載其他物件，

并行連接不一定更快

• 客戶端的網路帶寬不足時，大部分的時間可能都是用來傳送資料的，
• 打開大量連接會消耗很多記憶體資源，從而引發自身的性能問題，

實際上，瀏覽器確實使用了并行連接，但它們會將并行連接的總數限制為一個較小的值（通常是 4 個），服務器可以隨意關閉來自特定客戶端的超量連接，

3.2 持久連接

Web 客戶端經常會打開到同一個站點的連接，因此，初始化了對某服務器 HTTP 請求的應用程式很可能會在不久的將來對那臺服務器發起更多的請求，這種性質被稱為站點區域性（site locality）

因此，HTTP/1.1（以及 HTTP/1.0 的各種增強版本）允許 HTTP 設備在事務處理結束之后將 TCP 連接保持在打開狀態，以便為未來的 HTTP 請求重用現存的連接，在事務處理結束之后仍然保持在打開狀態的 TCP 連接被稱為持久連接，非持久連接會在每個事務結束之后關閉，持久連接會在不同事務之間保持打開狀態，直到客戶端或服務器決定將其關閉為止，

重用已對目標服務器打開的空閑持久連接，就可以避開緩慢的連接建立階段，而且，已經打開的連接還可以避免慢啟動的擁塞適應階段，以便更快速地進行資料的傳輸，

并行連接的缺點

• 每個事務都會打開 / 關閉一條新的連接，會耗費時間和帶寬，
• 由于 TCP 慢啟動特性的存在，每條新連接的性能都會有所降低，
• 可打開的并行連接數量實際上是有限的，

持久連接的缺點

• 如果對于持久連接管理不妥，就會累積出大量的空閑連接，耗費本地以及遠程客戶端和服務器上的資源，

持久連接與并行連接配合使用可能是最高效的方式，現在，很多 Web 應用程式都會打開少量的并行連接，其中的每一個都是持久連接，

3.2.1 HTTP/1.0+ keep-alive連接

• 實作 HTTP/1.0 keep-alive 連接的客戶端可以通過包含 Connection: Keep-Alive 首部請求將一條連接保持在打開狀態，
  • keep-Alive 首部只是請求將連接保持在活躍狀態，發出 keep-alive 請求之后，客戶端和服務器并不一定會同意進行 keep-alive 會話，它們可以在任意時刻關閉空閑的 keep-alive 連接，并可隨意限制 keep-alive 連接所處理事務的數量，
• 對于那些不理解 Connection 首部，而且不知道在沿著轉發鏈路將其發送出去之前，應該將該首部洗掉的代理，會出現啞代理的情況，
  • Web 客戶端向代理發送了一條報文，其中包含了 Connection:Keep-Alive 首部，如果可能的話請求建立一條 keep-alive 連接，客戶端等待回應，以確定對方是否認可它對 keep-alive 信道的請求，
  • 啞代理收到了這條 HTTP 請求，但它并不理解 Connection 首部（只是將其作為一個擴展首部對待）因此只是沿著轉發鏈路將報文一字不漏地發送給服務器，但 Connection 首部是個逐跳首部，只適用于單條傳輸鏈路，不應該沿著傳輸鏈路向下傳輸，
  • Web 服務器收到經過代理轉發的 Connection: Keep-Alive 首部時，會誤以為代理希望進行 keep-alive 對話，
  • 同樣客戶端也會接收到代理直接回應回來的Keep-Alive
  • 所以客戶端和服務器都會和代理建立起keepAlive連接，但是代理并不知道這是什么東西，只會在每次連接結束之后關閉連接，
  • 為避免此類代理通信問題的發生，現代的代理都絕不能轉發 Connection 首部和所有名字出現在 Connection 值中的首部，
• 為解決該問題，又引入了一個名為Proxy-Connection 的新首部，
  • 瀏覽器會向代理發送非標準的 Proxy-Connection 擴展首部，而不是官方支持的著名的 Connection 首部，如果代理是盲中繼，它會將無意義的 Proxy-Connection 首部轉發給 Web 服務器，服務器會忽略此首部，
  • 如果代理是個聰明的代理（能夠理解持久連接的握手動作），就用一個 Connection 首部取代無意義的 Proxy-Connection 首部，然后將其發送給服務器，

3.2.2 HTTP/1.1持久連接

HTTP/1.1 逐漸停止了對 keep-alive 連接的支持，用一種名為持久連接（persistentconnection）的改進型設計取代了它，

與 HTTP/1.0+ 的 keep-alive 連接不同，HTTP/1.1 持久連接在默認情況下是激活的，如果要在事務處理結束之后將連接關閉，HTTP/1.1 應用程式必須向報文中顯式地添加一個 Connection:close 首部，

3.3 管道化連接

HTTP/1.1 允許在持久連接上可選地使用請求管道，這是相對于 keep-alive 連接的又一性能優化，

在回應到達之前，可以將多條請求放入佇列，當第一條請求通過網路流向地球另一端的服務器時，第二條和第三條請求也可以開始發送了，在高時延網路條件下，這樣做可以降低網路的環回時間，提高性能，

對管道化連接有幾條限制

• 如果 HTTP 客戶端無法確認連接是持久的，就不應該使用管道，
• 必須按照與請求相同的順序回送 HTTP 回應，
• HTTP 客戶端必須做好連接會在任意時刻關閉的準備，還要準備好重發所有未完成的管道化請求，
• HTTP 客戶端不應該用管道化的方式發送會產生副作用的請求（例如POST請求，無法安全的重試，可能造成表單重復提交等），

3.4 關閉連接的奧秘

所有 HTTP 客戶端、服務器或代理都可以并且可能在任意時刻關閉一條 TCP 傳輸連接，

每條 HTTP 回應都應該有精確的 Content-Length 首部，用以描述回應主體的尺寸，客戶端或代理收到一條隨連接關閉而結束的 HTTP 回應之后就應該根據 Content-Length 和接收到的主題校驗資料的正確性，

即使在非錯誤情況下，連接也可以在任意時刻關閉，HTTP 應用程式要做好正確處理非預期關閉的準備，如果在客戶端執行事務的程序中，傳輸連接關閉了，那么，除非事務處理會帶來一些副作用，否則客戶端就應該重新打開連接，并重試一次，

有些事務，比如 GET 一個靜態的 HTML 頁面，可以反復執行多次，也不會有什么變化，而其他一些事務，比如向一個在線書店 POST 一張訂單，就不能重復執行，不然會有下多張訂單的危險，

如果一個事務，不管是執行一次還是很多次，得到的結果都相同，這個事務就是冪等的，

4. 與 HTTP 協作的 Web 服務器

4.1 代理

代理是一種有轉發功能的應用程式，它扮演了位于服務器和客戶端“中間人”的角色，接收由客戶端發送的請求并轉發給服務器，同時也接收服務器回傳的回應并轉發給客戶端，

使用代理服務器的理由：

• 利用快取技術減少網路帶寬的流量，
• 組織內部針對特定網站的訪問控制，以獲取訪問日志為主要目的，

快取代理：代理轉發回應時，快取代理（Caching Proxy）會預先將資源的副本（快取）保存在代理服務器上，當代理再次接收到對相同資源的請求時，就可以不從源服務器那里獲取資源，而是將之前快取的資源作為回應回傳，

透明代理：轉發請求或回應時，不對報文做任何加工的代理型別被稱為透明代理（Transparent Proxy），反之，對報文內容進行加工的代理被稱為非透明代理，

4.2 網關

網關的作業機制和代理十分相似，而網關能使通信線路上的服務器提供非 HTTP 協議服務，網關類似提供了一個翻譯器的功能，

網關是資源和應用程式之間的粘合劑，應用程式可以（通過 HTTP 或其他已定義的介面）請求網關來處理某條請求，網關可以提供一條回應，網關可以向資料庫發送查詢陳述句，或者生成動態的內容，就像一個門一樣：進去一條請求，出來一個回應，

利用網關能提高通信的安全性，因為可以在客戶端與網關之間的通信線路上加密以確保連接的安全，然后由網關解密之后向服務器發送HTTP請求，

4.3 隧道

Web 隧道可以通過 HTTP 應用程式訪問使用非 HTTP 協議的應用程式，

Web 隧道允許用戶通過 HTTP 連接發送非 HTTP 流量，這樣就可以在 HTTP 上捎帶其他協議資料了，使用 Web 隧道最常見的原因就是要在 HTTP 連接中嵌入非 HTTP流量，這樣，這類流量就可以穿過只允許 Web 流量通過的防火墻了，

最初開發 Web 隧道是為了通過防火墻來傳輸加密的 SSL 流量，很多組織都會將所有流量通過分組過濾路由器和代理服務器以隧道方式傳輸，以提升安全性，但有些協議，比如加密 SSL，其資訊是加密的，無法通過傳統的代理服務器轉發，隧道會通過一條 HTTP 連接來傳輸 SSL 流量，以穿過埠 80 的 HTTP 防火墻，

簡單來說就是，隧道可按要求建立起一條與其他服務器的通信線路，屆時使用 SSL等加密手段進行通信，隧道的目的是確保客戶端能與服務器進行安全的通信，

4.4 快取

快取是指代理服務器或客戶端本地磁盤內保存的資源副本，利用快取可減少對源服務器的訪問，因此也就節省了通信流量和通信時間，

快取不僅可以存在于快取服務器內，還可以存在客戶端瀏覽器中，瀏覽器快取如果有效，就不必再向服務器請求相同的資源了，可以直接從本地磁盤內讀取，

另外，當判定快取過期后，會向源服務器確認資源的有效性，若判斷瀏覽器快取失效，瀏覽器會再次請求新資源，

5. 識別、認證與安全

5.1 識別

HTTP 最初是一個匿名、無狀態的請求 / 回應協議，服務器處理來自客戶端的請求，然后向客戶端回送一條回應，Web 服務器幾乎沒有什么資訊可以用來判定是哪個用戶發送的請求，也無法記錄來訪用戶的請求序列，

產生如下幾種用戶識別機制

• 利用HTTP 請求首部來承載用戶相關資訊，例如下圖
  • 
• 利用客戶端 IP 地址作為一種標識形式，
• 通過用戶名和密碼進行認證（登錄）來顯式地詢問用戶是誰，登錄完成之后，用 www-Authenticate 首部和 Authorization 首部向 Web 站點傳送用戶的相關資訊，
• 有些 Web 站點會為每個用戶生成特定版本的 URL 來追蹤用戶的身份，改動后包含了用戶狀態資訊的 URL 被稱為胖 URL（fat URL），
• 利用cookie，以下詳談，

5.1.1 cookie

cookie 是當前識別用戶，實作持久會話的最好方式，Cookie 技術通過在請求和回應報文中寫入 Cookie 資訊來控制客戶端的狀態，

可以籠統地將 cookie 分為兩類：

• 會話 cookie： 是一種臨時 cookie，它記錄了用戶訪問站點時的設定和偏好，用戶退出瀏覽器時，會話cookie 就被洗掉了，
• 持久 cookie： 生存時間更長一些；它們存盤在硬碟上，瀏覽器退出，計算機重啟時它們仍然存在，通常會用持久 cookie 維護某個用戶會周期性訪問的站點的組態檔或登錄名，

Cookie 會根據從服務器端發送的回應報文內的一個叫做 Set-Cookie 的首部欄位資訊，通知客戶端保存 Cookie，當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入 Cookie 值后發送出去，

服務器端發現客戶端發送過來的 Cookie 后，會去檢查究竟是從哪一個客戶端發來的連接請求，然后對比服務器上的記錄，最后得到之前的狀態資訊，

cookie 和 session 的區別

• cookie資料存放在客戶的瀏覽器上，session資料放在服務器上，
• cookie不是很安全，別人可以分析存放在本地的cookie并進行cookie欺騙考慮到安全應當使用session，
• session會在一定時間內保存在服務器上，當訪問增多，會比較占用你服務器的性能，考慮到減輕服務器性能方面，應當使用cookie，
• 單個cookie保存的資料不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie，session物件沒有對存盤的資料量的限制，其中可以保存更為復雜的資料型別，

5.2 認證

認證就是要給出一些身份證明，

HTTP 定義了兩個官方的認證協議：基本認證和摘要認證，今后人們可以隨意設計一些使用 HTTP 質詢 / 回應框架的新協議，

HTTP 提供了一個原生的質詢 / 回應（challenge/response）框架，Web 應用程式收到一條 HTTP 請求報文時，服務器沒有按照請求執行動作，而是以一個“認證質詢”進行回應，要求用戶提供一些保密資訊來說明他是誰，從而對其進行質詢，

1. 服務器對用戶進行質詢時，會回傳一條 401 Unauthorized 回應，并在 WWW-Authenticate首部說明如何以及在哪里進行認證，
2. 當客戶端授權服務器繼續處理時，會重新發送請求，但會在 Authorization 首部附上加密的密碼和其他一些認證引數，
3. 授權請求成功完成時，服務器會回傳一個正常的狀態碼（比如，200 OK）；對高級認證演算法來說，可能還會在 Authentication-Info 首部附加一些額外的資訊（，

• 基本認證

  • 基本認證的程序
    • 在基本認證中，Web 服務器可以拒絕一個事務，質詢客戶端，請用戶提供有效的用戶名和密碼，
    • 服務器會回傳 401 狀態碼，而不是 200 狀態碼來初始化認證質詢，并用 WWW-Authenticate 回應首部指定要訪問的安全域，
    • 瀏覽器收到質詢時，會打開一個對話框，請求用戶輸入這個域的用戶名和密碼，然后將用戶名和密碼稍加擾碼，再用 Authorization 請求首部回送給服務器，
  • 中間的代理服務器也可以實作認證功能，通過代理服務器提供對某組織內部資源的統一訪問控制是一種很便捷的方式，代理認證的步驟與 Web 服務器身份驗證的步驟相同，但首部和狀態碼都有所不同，
  • 基本認證簡單便捷，但并不安全（例如，發送賬戶密碼很容易解碼得到），只能用它來防止非惡意用戶無意間進行的訪問，或將其與 SSL 這樣的加密技術配合使用，

• 摘要認證

  • 摘要認證主要是對基本認證的改進，但還沒被廣泛使用，
  • 客戶端不會發送密碼，而是會發送一個“指紋”或密碼的“摘要”，這是密碼的不可逆擾碼，
  • 用亂數防止截獲摘要，并一遍遍地重放給服務器，
  • 摘要認證的握手機制

6. HTTPS

使用 HTTPS 時，所有的 HTTP 請求和回應資料在發送到網路之前，都要進行加密，HTTPS 在 HTTP 下面提供了一個傳輸級的密碼安全層——可以使用SSL，也可以使用其后繼者——傳輸層安全（Transport Layer Security，TLS），

在對HTTPS進行討論之前，先介紹幾個術語：

• 密碼：對文本進行編碼，使偷窺者無法識別的演算法，
• 密鑰：改變密碼行為的數字化引數，
• 對稱密鑰加密系統：編 / 解碼使用相同密鑰的演算法，
  • 每次發送密文的同時會把密鑰也一起發送，給對方解密，
• 不對稱密鑰加密系統：編 / 解碼使用不同密鑰的演算法，
  • 一把叫做私有密鑰（private key），另一把叫做公開密鑰（public key），顧名思義，私有密鑰不能讓其他任何人知道，而公開密鑰則可以隨意發布，任何人都可以獲得，
  • 發送密文的一方使用對方的公開密鑰進行加密處理，對方收到被加密的資訊后，再使用自己的私有密鑰進行解密，這樣就不需要將密鑰傳輸給對方
• 公開密鑰加密系統：一種能夠使數百萬計算機便捷地發送機密報文的系統，
• 數字簽名：用來驗證報文未被偽造或篡改的校驗和，
• 數字證書：由一個可信的組織驗證和簽發的識別資訊，
  • 可以對公有密鑰頒發證書，保證公有密鑰是目標服務器的密鑰，

6.1 RSA 演算法的 TLS 握手

傳統的 TLS 握?基本都是使? RSA 演算法來實作密鑰交換的，在將 TLS 證書部署服務端時，證書?件中包含?對公私鑰，其中公鑰會在 TLS 握?階段傳遞給客戶端，私鑰則?直留在服務端，?定要確保私鑰不能被竊取，

在 RSA 密鑰協商演算法中，客戶端會?成隨機密鑰，并使?服務端的公鑰加密后再傳給服務端，根據?對稱加密演算法，公鑰加密的訊息僅能通過私鑰解密，這樣服務端解密后，雙?就得到了相同的密鑰，再用它加密應?訊息，

第一次握手

客戶端?先會發?個「Client Hello」訊息，訊息??有客戶端使?的 TLS 版本號、?持的密碼套件串列，以及?成的客戶端亂數（Client Random），這個亂數會被服務端保留，它是?成對稱加密密鑰的材料之?，

第?次握?

當服務端收到客戶端的「Client Hello」訊息后，會確認 TLS 版本號是否?持，和從密碼套件串列中選擇?個密碼套件，以及?成服務端亂數（Server Random），

接著，回傳「Server Hello」訊息，訊息??有服務器確認的 TLS 版本號，也給出了亂數（Server Random），和選擇的密碼套件，

然后，服務端為了證明??的身份，會發送「Server Certificate」給客戶端，這個訊息?含有數字證書，

數字證書是什么？

• ?個數字證書通常包含了:
  • 公鑰；
  • 持有者資訊；
  • 證書認證機構（CA）的資訊；
  • CA 對這份?件的數字簽名及使?的演算法；
  • 證書有效期；
  • 還有?些其他額外資訊
• 數字證書簽發流程
  • ?先 CA 會把持有者的公鑰、?途、頒發者、有效時間等資訊打成?個包，然后對這些資訊進? Hash 計算，得到?個 Hash 值；
  • 然后 CA 會使???的私鑰將該 Hash 值加密，?成 Certificate Signature，也就是 CA 對證書做了簽名；
  • 最后將 Certificate Signature 添加在?件證書上，形成數字證書；
• 數字證書驗證程序
  • ?先客戶端會使?同樣的 Hash 演算法獲取該證書的 Hash 值 H1；
  • 通常瀏覽器和作業系統中集成了 CA 的公鑰資訊，瀏覽器收到證書后可以使? CA 的公鑰解密 CertificateSignature 內容，得到?個 Hash 值 H2 ；
  • 最后?較 H1 和 H2，如果值相同，則為可信賴的證書，否則則認為證書不可信，

第三次握手

客戶端驗證完證書后，認為可信則繼續往下?，接著，客戶端就會?成?個新的亂數 (pre-master)，?服務器的 RSA 公鑰加密該亂數，通過「Change Cipher Key Exchange」訊息傳給服務端，

服務端收到后，? RSA 私鑰解密，得到客戶端發來的亂數 (pre-master)，

客戶端和服務端雙?都共享了三個亂數，分別是 Client Random、Server Random、pre-master，于是，雙?根據已經得到的三個亂數，?成會話密鑰（Master Secret），也就是對稱密鑰，?于對后續的 HTTP請求/回應的資料加解密，

?成完會話密鑰后，然后客戶端發?個「Change Cipher Spec」，告訴服務端開始使?加密?式發送訊息，

然后，客戶端再發?個「Encrypted Handshake Message（Finishd）」訊息，把之前所有發送的資料做個摘要，再?會話密鑰（master secret）加密?下，讓服務器做個驗證，驗證加密通信是否可?和之前握?資訊是否有被中途篡改過，

在發送「Change Cipher Spec」之前傳輸的 TLS 握?資料都是明?，之后都是對稱密鑰加密的密?，

第四次握?

服務器也是同樣的操作，發「Change Cipher Spec」和「Encrypted Handshake Message」訊息，如果雙?都驗證加密和解密沒問題，那么握?正式完成，

最后，就?「會話密鑰」加解密 HTTP 請求和回應了，

RSA 演算法的缺陷

使? RSA 密鑰協商演算法的最?問題是不?持前向保密，因為客戶端傳遞亂數（?于?成對稱加密密鑰的條件之?）給服務端時使?的是公鑰加密的，服務端收到到后，會?私鑰解密得到亂數，所以?旦服務端的私鑰泄漏了，過去被第三?截獲的所有 TLS 通訊密?都會被破解，

6.2 ECDHE 演算法的 TLS 握手程序

第一次握手

客戶端?先會發?個「Client Hello」訊息，訊息??有客戶端使?的 TLS 版本號、?持的密碼套件串列，以及?成的亂數（Client Random），這和上面利用RSA演算法的程序相同，

第?次握?

服務端收到客戶端的訊息之后會回傳「Server Hello」訊息，訊息?有服務器確認的 TLS 版本號，也給出了?個亂數（Server Random），然后從客戶端的密碼套件串列選擇了?個合適的密碼套件，

接著，服務端為了證明??的身份，發送「Certificate」訊息，會把證書也發給客戶端，

因為服務端選擇了 ECDHE 密鑰協商演算法，所以會在發送完證書后，發送「Server Key Exchange」訊息，

這個程序服務器做了三件事：

• 選擇了橢圓曲線，選好了橢圓曲線相當于橢圓曲線基點也定好了，這些都會公開給客戶端；
• ?成亂數作為服務端橢圓曲線的私鑰，保留到本地；
• 根據基點和私鑰計算出服務端的橢圓曲線公鑰，這個會公開給客戶端，

為了保證這個橢圓曲線的公鑰不被第三?篡改，服務端會? RSA 簽名演算法給服務端的橢圓曲線公鑰做個簽名，

隨后，就是「Server Hello Done」訊息，?此，TLS 兩次握?就已經完成了，?前客戶端和服務端通過明?共享了這?個資訊：Client Random、Server Random 、使?的橢圓曲線、橢圓曲線基點、服務端橢圓曲線的公鑰，

第三次握手

客戶端收到了服務端的證書后，?然要校驗證書是否合法，確認證書的真實性，再?證書的公鑰驗證簽名，這樣就能確認服務端的身份，

之后，客戶端會?成?個亂數作為客戶端橢圓曲線的私鑰，然后再根據服務端前?給的資訊，?成客戶端的橢圓曲線公鑰，然后?「Client Key Exchange」訊息發給服務端，

至此，所有的資訊都已經共享，最終的會話密鑰，就是?「客戶端亂數 + 服務端亂數 + x（ECDHE 演算法算出的共享密鑰） 」三個材料?成的，

算好會話密鑰后，客戶端會發?個「Change Cipher Spec」訊息，告訴服務端后續改?對稱演算法加密通信，

接著，客戶端會發「Encrypted Handshake Message」訊息，把之前發送的資料做?個摘要，再?對稱密鑰加密?下，讓服務端做個驗證，驗證下本次?成的對稱密鑰是否可以正常使?，

第四次握?

最后，服務端也會有?個同樣的操作，發「Change Cipher Spec」和「Encrypted Handshake Message」訊息，如果雙?都驗證加密和解密沒問題，那么握?正式完成，于是，就可以正常收發加密的 HTTP 請求和回應了，

6.3 HTTP 與 HTTPS 有哪些區別？

1. HTTP 是超?本傳輸協議，資訊是明?傳輸，存在安全?險的問題，HTTPS 則解決 HTTP 不安全的缺陷，在TCP 和 HTTP ?絡層之間加?了 SSL/TLS 安全協議，使得報?能夠加密傳輸，
2. HTTP 連接建?相對簡單， TCP 三次握?之后便可進? HTTP 的報?傳輸，? HTTPS 在 TCP 三次握?之后，還需進? SSL/TLS 的握?程序，才可進?加密報?傳輸，
3. HTTP 的端?號是 80，HTTPS 的端?號是 443，
4. HTTPS 協議需要向 CA（證書權威機構）申請數字證書，來保證服務器的身份是可信的，

7. HTTP/1.1、HTTP/2、HTTP/3 演變

HTTP/1.1 相? HTTP/1.0 性能上的改進：

• 使? TCP ?連接的?式改善了 HTTP/1.0 短連接造成的性能開銷，
• ?持管道化?絡傳輸，只要第?個請求發出去了，不必等其回來，就可以發第?個請求出去，可以減少整體的回應時間，

HTTP/1.1 的缺陷

• 請求 / 回應頭部（Header）未經壓縮就發送，?部資訊越多延遲越?，只能壓縮 Body 的部分；
• 發送冗?的?部，每次互相發送相同的?部造成的浪費較多；
• 服務器是按請求的順序回應的，如果服務器回應慢，會招致客戶端?直請求不到資料，也就是隊頭阻塞，沒有請求優先級控制；
• 請求只能從客戶端開始，服務器只能被動回應，

HTTP/1.1 的優化

• 使用快取，減少發送HTTP請求，
• 減少重定向次數，將重定向交給代理，
• 合并請求，將一些小請求合并成一個大請求，
• 延遲放松請求，對于一些暫時用不到的請求延遲發送，
• 壓縮回應的資源

HTTP/2 相? HTTP/1.1 性能上的改進：

• 頭部壓縮

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

• ?進制格式

  • HTTP/2 不再像 HTTP/1.1 ?的純?本形式的報?，?是全?采?了?進制格式，頭資訊和資料體都是?進制，并且統稱為幀（frame）：頭資訊幀和資料幀，增加了資料傳輸的效率，

• 資料流

  • HTTP/2 的資料包不是按順序發送的，同?個連接??連續的資料包，可能屬于不同的回應，因此，必須要對資料包做標記，指出它屬于哪個回應，
  • 客戶端還可以指定資料流的優先級，優先級?的請求，服務器就先回應該請求，

• 多路復?

  • HTTP/2 是可以在?個連接中并發多個請求或回應，?不?按照順序??對應，
  • 降低了延遲，?幅度提?了連接的利?率，

• 服務器推送

  • HTTP/2 還在?定程度上改善了傳統的「請求 - 應答」?作模式，服務不再是被動地回應，也可以主動向客戶端發送訊息，

HTTP/2 的缺陷

• 多個 HTTP 請求在復??個 TCP 連接，下層的 TCP 協議是不知道有多少個 HTTP 請求的，所以?旦發?了丟包現象，就會觸發 TCP 的重傳機制，這樣在?個 TCP 連接中的所有的 HTTP 請求都必須等待這個丟了的包被重傳回來，

HTTP / 3 的改進

• 由于是基于 TCP 傳輸層的問題，所以 HTTP/3 把 HTTP 下層的 TCP 協議改成了 UDP！
• 基于 UDP 的 QUIC 協議 可以實作類似 TCP 的可靠性傳輸，

參考文獻

《圖解HTTP》
《HTTP權威指南》
《計算機網路-自頂向下方法》
https://mp.weixin.qq.com/s/bUy220-ect00N4gnO0697A