本文以總結的形式，先大體介紹TCP／IP協議整體組成，再擇其應用層上的HTTP協議進行詳細總結，繼而拓展知識點講解加密學，過渡到HTTPS協議的學習，除去網路知識必備掌握的三次握手、四次揮手，另需瞭解基於SSL/TLS的握手，也是重要的一個環節。

本文涉及到的知識點如下：

• 網路基礎TCP/IP
• HTTP協議基礎與重點
• 加密與簽名
• HTTPS協議（基於SSL/TLS的握手）

一. 網路基礎TCP/IP

在正式介紹HTTP網路知識之前，先追其根源—–TCP/IP協議族，通常使用的網路是在TCP/IP協議族的基礎上運作的，而HTTP屬於它內部的一個子集，所以先了解有關TCP/IP有關知識，為HTTP做鋪墊。

1. TCP/IP協議分層管理

（1）協議（protocal）

計算機與網路相互通訊，雙方必須基於相同的方法，例如由哪一方先發起通訊、使用哪種語言進行通訊、如何結束通訊等都需要事先規定。不同的硬體、OS之間的通訊都需要一種規則，就是協議（protocal）。

（2）TCP/IP協議定義

協議中存在各種內容，例如從電纜規格到IP地址的選定方法、雙方建立通訊的順序，以及web頁面顯示需要處理的步驟等。以上這種與網際網路相關聯的協議集合起來總稱為 TCP/IP。（有的說法是TCP/IP是指TCP和IP這兩種協議，還有一種說法是TCP/IP是在IP協議的通訊過程中使用的協議族的統稱）

（3）分層管理

TCP/IP協議族裡重要的一點是分層，可分為：應用層、傳輸層、網路層、資料鏈路層。

其實層次化是有它的好處，如果網際網路只有一個協議統籌，某個地方需要改動時需要將所有部分換掉，而分層之後只需替換變動層即可。每一層也只需考慮自己的任務即可。

• 應用層：應用層決定了向用戶提供應用服務時通訊的活動。

TCP/IP協議族內預存了各類通用的應用服務，例如FTP（File Transfer Protocol檔案傳輸協議）和DNS（Domain Name System域名系統）服務就是其中兩類，HTTP協議也處於改層。

• 傳輸層：傳輸層對上層應用層，提供處於網路連線中的兩臺計算機之間的資料傳輸。

在傳輸層有兩個性質不同的協議：TCP（Transmission Control Protocol傳輸控制協議）和UDP

• 網路層（網路互連層）：網路層用來處理在網路上流動的資料包。資料包是網路傳輸的最小資料單位。該層規定了通過怎樣的路徑（傳輸路線）到達對方計算機，並把資料包傳送給對方。

與對方計算機之間通過多臺計算機或網路裝置進行傳輸時，網路層所起作用就是在眾多選項內選擇一條傳輸路線。

• 鏈路層（網路介面層）：用來處理連線網路的硬體部分。包括控制作業系統、硬體的裝置驅動、網絡卡，以及光纖等物流可見部分。硬體上的範疇均在鏈路層的作用範圍內。

2. TCP/IP通訊傳輸流

利用TCP/IP協議族進行網路通訊時，會通過分層順序與對方進行通訊。傳送端的順序從應用層往下走，接收端則往應用層上走。

舉個HTTP的例子：作為傳送端的客戶端在應用層（HTTP協議）發出一個想看某個Web頁面的HTTP請求。

• 為了傳輸方便，在傳輸層（TCP協議）把應用層處收到的資料（HTTP請求報文）進行分割，並在各個報文上打上標記序號及埠號後轉發給網路層。

• 在網路層（IP協議），增加作為通訊目的地的MAC地址後轉發給鏈路層。這樣傳送網路的通訊請求就準備完全了。

• 接收端的伺服器在鏈路層接收到資料，按序往上層傳送，一直到應用層。當傳輸層到應用層，才算真正接收到由客戶端傳送過來的HTTP請求。

傳送端在層與層之間傳輸資料時，每經過一層時必定會被打上一個該層所屬的首部資訊。反之，接收端在層與層傳輸資料時，每經過一層時會把對應的首部消去。

這種包裝資料資訊的行為稱為封裝（encapsulate）

3. 與HTTP關係密切的協議：IP、TCP和DNS

（1）負責傳輸的IP協議

定義作用

• 定義： IP（Internet Protocol）網際協議位於網路層。IP佔據了TCP/IP協議族的“一半”，可見其重要性，切勿將IP同IP地址搞混，“IP”是一種協議的名稱。

• 作用：把各種資料包傳送給對方。要保證確實傳送到對方那裡，需滿足各類條件，其中兩個重要的條件：（IP地址可以和MAC地址進行配對，IP地址可變換，但MAC地址基本上不會改變。）

  • IP地址：指明節點被分配的位置。
  • MAC地址（Media Access Control Address）：指網絡卡所屬的固定地址。

使用ARP協議憑藉MAC地址進行通訊

IP間的通訊依賴MAC地址。在網路上，通訊的雙方在同一區域網（LAN）內的情況很少，通常是經過多臺計算機和網路裝置中轉才能連線到對方。

在進行中轉時，會利用下一站中轉裝置的MAC地址來搜尋下一個中轉目標。這時會採用ARP協議（Address Resolution Protocol），它是一種用以解析地址的協議，根據通訊方的IP地址就可以反查出對應的MAC地址。

無法全面掌握網際網路中的傳輸狀況

在到達通訊目標前的中轉過程中，那些計算機和路由器等網路裝置只能獲悉很粗略的傳輸路線。

這種機制稱為路由選擇（rounting），有點像快遞送貨，寄快遞時把貨物送到集散中心，即可知道是否肯收件，接著檢查送達地址，明確下一站送達的集散中心，下一個集散中心再判斷是否能送達目的地。（其中的中轉過程無法掌握，所以無法掌握網際網路中的細節。）

（2）確保可靠性的TCP協議

TCP位於傳輸層，提供可靠的位元組流服務（Byte Stream Service）。

• 位元組流服務：為了方便傳輸，將大塊資料分割以報文段（segment）為單位的資料包進行管理。
• 可靠的傳輸服務：能夠把資料準確可靠地傳給對方。

TCP協議為了更容易傳送大資料才把資料分割，而且TCP協議能夠確認資料最終是否送達到對方。

確保資料能到達目標

為了準確無誤地將資料送達目標處，TCP協議採用了三次握手（three-way handshaking）策略。用TCP協議將資料包送出去後，TCP一定會向對方確認是否成功送達。若在握手過程中某個階段莫名中斷，TCP協議會再次以相同的順序傳送相同的順序包。

握手過程

• 定義：三次握手，是指建立一個TCP連線時，需要客戶端和伺服器總共傳送3個包。
• 目的：是連線伺服器指定埠，建立TCP連線,並同步連線雙方的序列號和確認號並交換 TCP 視窗大小資訊

在socket程式設計中，客戶端執行connect()時，將觸發三次握手。

• 第一次握手：建立連線時，客戶端傳送syn包(syn=j)到伺服器，並進入SYN_SEND狀態，等待伺服器確認；

• 第二次握手：伺服器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也傳送一個SYN包（syn=k），即SYN+ACK包，此時伺服器進入SYN_RECV狀態；

• 第三次握手：客戶端收到伺服器的SYN＋ACK包，向伺服器傳送確認包ACK(ack=k+1)，此包傳送完畢，客戶端和伺服器進入ESTABLISHED狀態，完成三次握手。完成三次握手，客戶端與伺服器開始傳送資料。

（3）負責域名解析的DNS服務

DNS（Domain Name System）服務是和HTTP協議一樣位於應用層的協議，它提供域名到IP地址之間的解析服務。                     

計算機不僅可以被賦予IP地址，也可以被賦予主機名和域名。例如 www.baidu.com。使用者經常使用這種方式來訪問對方計算機，但要讓計算機去理解名稱就顯得困難，因此DNS服務應運而生，DNS協議提供通過域名查詢IP地址，或逆向從IP地址反查域名的服務。     

4. 各種協議與HTTP協議的關係

這張圖是客戶端向伺服器請求資源時的過程，在HTTP通訊過程中包含了IP協議、TCP協議、DNS服務，發揮著各自的作用，檢視下圖。

二. Http協議

1. 基本概念

（1）HTTP協議及特點

• 協議：指計算機通訊網路中兩臺計算機之間進行通訊所必須共同遵守的規定或規則。

• HTTP協議：超文字傳輸協議（HTTP）是一種通訊協議，它允許將超文字標記語言（HTML）文件從Web伺服器傳送到客戶端的瀏覽器。

如上圖，其實HTTP協議是基於TCP/IP協議來傳遞資料，從伺服器端獲取到資料，是C/S架構——客戶端到服務端通訊的介面。瀏覽器作為HTTP協議下的客戶端，通過URL傳送請求到服務端，服務端做出響應將內容返回給瀏覽器顯示，這就是一個基本的C/S架構的HTTP協議。

HTTP協議特點：

• 支援客戶/伺服器模式。
• 簡單快速：客戶向伺服器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、 HEAD、POST。每種方法規定了客戶與伺服器聯絡的型別不同。 由於HTTP協議簡單，使得HTTP伺服器的程式規模小，因而通訊速度很快。
• 靈活： HTTP允許傳輸任意型別的資料物件。正在傳輸的型別由Content-Type加以標記。
• 無連線： 無連線的含義是限制每次連線只處理一個請求。伺服器處理完客戶的請求， 並收到客戶的應答後，即斷開連線。採用這種方式可以節省傳輸時間。限制地每次連線只處理一個請求，處理完請求後收到客戶端應答從而斷開連線。採用這種方式可節省傳輸時間。
• 無狀態： HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。 缺少狀態意味著如果後續處理需要前面的資訊，則它必須重傳，這樣可能導致每 次連線傳送的資料量增大。另一方面，在伺服器不需要先前資訊時它的應答就較快。

（2） Http 版本區別

（3）HTTP請求報文和響應報文

HTTP請求報文主要由請求行、請求頭、空行、請求正文（GET方式無請求正文）4部分組成。

• 請求行：由請求方法、URL和協議版本3部分組成。
• 請求頭：為請求報文新增一些資訊，由“名／值”組成。
• 空行：請求頭的最後會有一個空行，代表請求頭部結束，接下來為請求正文。此部分不可少。
• 請求正文

HTTP響應報文主要由狀態行、響應頭、空行、響應正文4部分組成。

• 狀態行：由狀態碼、狀態碼描述和協議版本3部分組成。
• 響應頭：為響應報文新增一些資訊，由“名／值”組成。
• 空行：頭的最後會有一個空行，代表響應頭部結束，接下來為響應正文。此部分不可少。
• 響應正文

（4） Http的請求方式總結

HEAD、GET、OPTIONS和TRACE是安全的方法，因為它們只從伺服器獲得資源而不對伺服器做任何修改，但是前三個在使用者端不安全，POST相對安全，但POST會影響伺服器的資源。TRACE方法對於服務端盒使用者端一定是安全的。

（5）  請求頭資訊

（6）  響應頭資訊

.
（7） 狀態碼資訊

HTTP狀態碼分類

較常用狀態碼

• 200 - 請求成功
• 301 - 資源（網頁等）被永久轉移到其它URL
• 404 - 請求的資源（網頁等）不存在
• 500 - 內部伺服器錯誤

2. Http請求方式Get和Post的區別

安全冪等性質

• GET一般用於獲取或者查詢資源資訊，這就意味著它是冪等的（對同一個URL的多次請求返回同樣的結果）和安全的（沒有修改資源的狀態）
• POST一般用於更新資源資訊，既不是安全，也非冪等。

引數存放位置

• GET方法中，客戶端把要傳送的資料新增到URL後面（即把資料放到HTTP協議頭中，GET是通過URL請求資料的），使用“？”連線，引數之間使用“&”連線。注意：HTTP協議中並沒有對URL長度進行限制，但是瀏覽器和伺服器會對其限制！（面試中經常會問到URL長度限制問題，一定要明白協議中並未對此規定！）
• POST是將需要傳遞的資料放到HTTP請求報文的訊息體中（同樣，協議未對此部分大小進行限制），不過傳送的資料量比GET更大且安全性更高（若不對資料進行加密，可使用抓包軟體進行獲取）。

瀏覽器快取

• GET請求的資料會被瀏覽器快取起來，留下歷史記錄。
• POST提交的資料不會。

3. 為什麼HTTP是無狀態的？如何保持狀態？

HTTP無狀態：是指協議對於事務處理沒有記憶能力，不能儲存每次客戶端提交的資訊，即當伺服器返回應答後，此次事務的所有訊息會被丟掉。即使客戶端發來一個新的相同的請求，伺服器無法知道它是否與上次請求有聯絡。

舉個例子：一個包含多個圖片的網頁瀏覽步驟：

• 建立連線，客戶端傳送一個網頁請求，服務端返回一個HTML頁面（一個純文字頁面），關閉連線。
• 瀏覽器解析HTML檔案，遇到圖片標記得到URL，此時客戶端和伺服器再建立連線，客戶端傳送一個圖片請求，伺服器返回圖片應答，關閉連線。（涉及到無狀態定義，對於伺服器而言，即使是同一個客戶端請求，無記憶能力無法識別）

優缺點

• 優點：伺服器不用為每個客戶端連線分配記憶體來記憶大量狀態，也不用在客戶端失去連線時去清除記憶體，節省伺服器端資源。
• 缺點： 如果後續處理需要前面的資訊，客戶端必須重傳，可能導致每次連線傳送的資料量增大。

解決辦法

針對這些問題，可以採用會話跟蹤技術，即把狀態儲存在伺服器，只發送回一個識別符號，瀏覽器在下次提交中把這個識別符號傳送過來，這樣可以定位儲存在伺服器上的狀態資訊。技術有以下：

• COOKIE
• SESSION
• URL重寫
• 作為隱藏域嵌入HTML表單中

4. cookie與session

（1）Cookie

定義

Cookie技術是客戶端的解決方案，由伺服器傳送給客戶端的特殊資訊，存放在response的header中，這些資訊以文字檔案方式存放在客戶端，由客戶端每次向伺服器傳送請求時帶上，此時是存放在request的header中。

如下圖，Cookie的設定可分為以下幾個步驟：

• 客戶端向服務端Request請求。
• 伺服器在response的header中設定Cookie，傳送給客戶端。
• 客戶端會將請求request和Cookie一起打包傳送給服務端。
• 服務端會根據Cookie判斷將response返回給客戶端。

因為HTTP協議“無狀態”的特點，在請求完畢後會關閉連線，再次交換資料需要建立新的連線，無法跟蹤會話。Cookie機制的引入正好彌補了HTTP協議“無狀態”的缺陷。

工作原理

由於HTTP協議是“無狀態”的，所以伺服器無法從網路上獲取使用者的真實身份。

解決辦法：此時客戶端給服務端發一個“通行證”，它是一個唯一的標識，無論哪個使用者訪問伺服器需要帶上此標識，這樣伺服器即可辨識使用者，這也就是Cookie的原理—–個人身份標識。

總結

在客戶端向服務端請求時，若伺服器要記錄該使用者資訊，就傳送一個攜帶cookie的response，客戶端會保留此cookie，當客戶端需要再次請求時，將請求URL和Cookie資訊一同打包傳送給服務端，此時伺服器即可根據cookie辨認狀態再做出響應（也可修改）。

總而言之，Cookie就是使用者識別標誌，儲存在客戶端！

（2）session

定義

Session是另一種記錄客戶狀態的機制，不同的是Cookie儲存在客戶端瀏覽器中，而Session儲存在伺服器行。客戶端瀏覽器訪問的時候，伺服器把客戶端資訊以某種形式記錄在伺服器上。

注意：當客戶端瀏覽器再次請求伺服器時是不需要攜帶資訊的，在伺服器上已有記錄。

工作原理

• 在服務端執行程式時建立Session
• 在建立Session的同時，伺服器會為該Session生成唯一的Session ID
• 在Session被建立後，可以呼叫相關方法往Session中新增內容，注意傳送到客戶端的只有Session ID
• 當客戶端再次傳送請求時，會將Session ID帶上，伺服器接受到請求之後就會依據ID確認使用者身份，找到相應的Session。

（3）兩者的區別

• 存放位置不同
  
  • Cookie：儲存在客戶端；
  • Session：儲存在服務端；
• 存取方式不同
  
  • Cookie：只能儲存ASCII碼字串；
  • Session：可儲存任何資料；
• 安全性（隱私策略）不同
  
  • Cookie：由於它存放在瀏覽器中，所以對客戶端是可見的，客戶端的程式有可能修改內容；
  • Session：存放在服務端，不存在敏感資訊洩露；
• 有效期不同
  
  • Cookie：客戶端一般設定有效期較長，這樣可儲存較長時間；
  • Session：設定成-1後，在使用者關閉瀏覽器後，session就會失效；
• 對伺服器造成的壓力不同
  
  • Cookie：儲存在客戶端，不佔用伺服器記憶體；
  • Session：由於它存放在服務端，多個使用者併發訪問伺服器時，會產生多個session，十分消耗記憶體；

5. HTTP的短連線和長連線的原理

在HTTP1.0中預設採用的是短連線，即瀏覽器和伺服器每進行一次HTTP操作需要進行一次連線，任務結束時中斷。若客戶端訪問的某個HTML或其他型別的Web中又包含其他Web資源，例如JS檔案、影象檔案、CSS檔案，那麼每次遇到以一個Web資源都會建立一個HTTP會話，進行三次握手，十分耗費資源。因此，通過在Request中增加“Connection：keep-alive”可支援長連線。

當HTTP採用長連線時的資料互動流程如下：

• 客戶端發出request，其中該版本號為1.0，並且在request中包含了一個header：“Connection：keep-alive”。
• 伺服器收到該請求的長連線後，將會在response加上“Connection：keep-alive”，同時不會關閉已建立的TCP連線。
• 同時，客戶端收到response中的header，發現是一個長連線，同樣不會關閉已建立的TCP連線。

在HTTP1.1起，預設使用長連線，來保持連線特性，即在請求頭和響應頭中預設加入“Connection：keep-alive” 。HTTP長連線利用同一個TCP連線處理多個HTTP請求和響應。

Keep-Alive不會永久保持連線，有一個保持時間，可以在不同的伺服器中設定時間，實現長連線要求客戶端和伺服器都支援長連線。

三. 加密與簽名

在講解HTTPS之前需要了解一些預備知識，即加密與簽名。

1. 密碼學

如果不對傳輸資料進行加密，很容易被第三方竊取或篡改，所以加密是保護資料的措施。最常見的就是對資料進行MD5加密，獲取資料後再將其解密。

（1）組成

因此，加密包含演算法和金鑰這兩個元素，兩者結合會使原有資料加密為明文，而加密分為以下兩個部分：

• 對稱加密

  • 定義：加密資料用的金鑰，跟解密資料用的金鑰是一樣的。
  • 優勢：此定義決定了它的特點：加密和解密過程效率非常高
  • 劣勢：但是缺點也很明顯，即雙方執同一個金鑰，必須要確保金鑰的安全性，帶來的技術成本很高。

• 不對稱加密：其中含有兩個金鑰，一個是一方保管的私有金鑰，另一個是雙方公有的公有金鑰。這種方式決定了傳送祕文的一方先獲取對方的公有金鑰，通過演算法進行處理，對方收到加密資料後，使用自己的私有金鑰進行解密。

（2）數字證書

定義：數字證書就是網際網路通訊中標誌通訊各方身份的一串數字。

產生的原因：請求方如何確定它想要的公鑰未經過第三方篡改，一定是從目標主機而來的？此時需要一個權威機構來發放金鑰，來解決數字證書的安全問題。

頒發過程：首先使用者要產生自己的金鑰，和公有金鑰一起交給認證中心，認證中心核實身份之後會將確認中心發給使用者，會頒發一個數字證書，含有金鑰資訊。

2. 金鑰

（1）定義

金鑰是一種引數，它是在使用密碼cipher演算法過程中輸入的引數。同一個明文在相同的密碼演算法和不同的金鑰計算下會產生不同的密文。金鑰才是決定加密資料是否安全的重要引數。

（2）明文到密文的加密過程

（3）金鑰組成

• 對稱金鑰

  • 定義：又稱為共享金鑰加密，對稱金鑰在加密、解密過程中使用的金鑰相同，常見對稱加密演算法有：DES、3DES、AES、RC5、RC6。
  • 優點：計算速度快；
  • 缺點：金鑰需要在通訊的兩端共享，存在安全性問題；

• 不對稱金鑰

  • 定義：又稱為公開金鑰加密。服務端會生成一對金鑰，一個私鑰儲存在服務端，僅自己知道，另一個公鑰可以自由釋出供任何人使用。常見的是RSA演算法。
  • 優點：無需在客戶端和服務端之間共享金鑰，只要私鑰不發給任何使用者，即使公鑰在網路上被截獲，也無法破解資料。

（4）RSA加密簡單過程

• 服務端生成配對的公鑰和私鑰；
• 金鑰儲存在服務端，公鑰傳送給客戶端；
• 客戶端使用公鑰加密明文傳輸給服務端；
• 服務端使用私鑰解密密文得到明文。

3. 數字簽名

首先思考一個問題：瀏覽器和伺服器直接傳輸資料時，有可能被黑客篡改，如何保證資料安全性？需要引出此部分核心——數字簽名。

（1）定義

數字簽名是用於驗證傳輸內容是否是真實伺服器傳送的資料，是否被篡改過，主要驗證這兩件事，是非對稱加密的一種應用場景，但它是反過來用祕鑰加密，通過與之配對的公鑰解密。

（2）加密過程

• 第一步：檢視上圖，服務端將報文進行雜湊處理後生成摘要資訊，摘要資訊使用私鑰加密之後才會生成簽名，而服務端將簽名連同報文一起傳送給客戶端。

• 第二步：檢視上圖，客戶端接收到資料後，把簽名提取出來用公鑰解密，如果能正常將Digest2 解密出來，即可確認是對方發的。
• 第三步：客戶端把報文Text提取出來做同樣的雜湊出來，得到的摘要資訊Digest1，再與之前解密出來的Digest2 對比。

四. HTTPS（TLS與SSL握手）

1. HTTP的缺點

在瞭解HTTP特點之後，不可忽視的是它的不足之處：

• 通訊使用明文（不加密），內容可能被監聽；
• 不驗證通訊方的身份，有可能遭遇偽裝；
• 無法證明報文的完整性，有可能已遭篡改；

以上三個問題不僅在HTTP上出現，其它未加密的協議也存在這些問題。除此之外，還有其它的缺點。

（1）通訊使用明文可能會被竊聽

由於HTTP本身不具備加密功能，所以無法做到對通訊整體（使用HTTP協議通訊的請求和響應的內容）進行加密，即HTTP報文使用明文的方式傳送。

TCP/IP是可能被竊聽的網路

按照TCP/IP 協議族的工作機制，通訊內容在所有的通訊線路上都有可能遭到窺視。

加密處理防止被竊聽

防止竊聽保護資訊的幾種對策中，最為普及的就是加密技術，加密物件有以下幾個：

• 通訊的加密： HTTP協議中沒有加密機制，可以通過SSL（Secure Socket Layer安全套接層）或TLS（Transport Layer Security安全傳輸層協議）的組合使用，加密HTTP的通訊內容。用SSL建立安全通訊線路之後，就可以在這條線路上進行HTTP通訊。與SSL組合使用的HTTP被稱為HTTPS。

• 內容的加密：對HTTP協議傳輸內容本身加密。客戶端需要對HTTP報文進行加密處理後再發送請求。為了做到有效的內容加密，前提是客戶端和伺服器同時具備加密和解密機制。（該方法不同於SSL或TLS將整個通訊線路加密處理，所以內容有篡改的風險，後續講解）

（2）不驗證通訊方的身份可能遭遇偽裝

在HTTP協議通訊時，由於不存在確認通訊方的處理步驟，任何人都可以發起請求，伺服器只有收到請求，不論是誰都返回響應，因此存在以下隱患：

• 無法確定請求傳送至目標的Web伺服器是否是真實返回響應的伺服器。（可能是偽裝的）
• 無法確定響應返回到客戶端是否是真實接收響應的客戶端。（可能是偽裝的）
• 無法確定正在通訊的對方是否具備訪問許可權。因為某些Web伺服器儲存重要資訊，只想發給特定使用者通訊的許可權。
• 無法判定請求出處。
• 即使是無意義的請求也會照單全收。無法阻止海量請求下的DoS攻擊。

查明對手的證書

雖然HTTP協議無法確定通訊方，但是使用SSL可以。SSL不僅提供加密處理，還使用了一種被稱為證書的手段，可用於確定方。

通過使用證書，來證明通訊方就是意料中的伺服器，這對使用者個人來講減少了資訊洩露的危險。另外客戶端持有證書即可完成個人身份驗證，可用於Web認證環節。

（3）無法證明報文完整性，可能已遭篡改

由於HTTP協議無法證明通訊報文的完整性，即使請求或響應內容遭到篡改，也沒有辦法獲悉。

像這樣，請求或響應在傳輸途中，遭攻擊者攔截並篡改內容的攻擊稱為中間人攻擊（Man-in-the-Middle attack）

如何防止篡改

雖然有使用HTTP協議確定報文完整性的方法，事實上並不可靠，常用的是MD5（單向函式生成的雜湊值）和SHA-1等雜湊值校驗方法，及用來確認檔案的數字簽名方法。可惜的是如果MD5本身被改寫，使用者沒有辦法意識到。

為了有效防止以上這些弊端，需要使用到HTTPS。SSL提供認證和加密處理及摘要功能。僅靠HTTP確保完整性是非常困難的，因此通過和其他協議組合來實現此目標。

2. HTTPS = HTTP + 加密 + 認證 + 完整性保護

（1）定義

HTTPS並非是應用層的一種新協議，只是HTTP通訊介面部分用SSL（Secure Socket Layer）和TLS（Transport Layer Security）協議代替而已。通過在TCP和HTTP之間加入TLS來加密，由此保證資料傳輸的安全性。HTTPS就是身披SSL協議這串外殼的HTTP。

（2）SSL/TLS協議

SSL協議是一種安全傳輸協議，TLS是SSL v3.0的升級版。

（3）HTTPS層次圖

檢視HTTPS層次圖，最底層是NetWork，依次往上是網路層、傳輸層、應用層。

傳輸層上面夾著TLS層，它就是安全傳輸協議在現實中的應用版，其中最上方的3個綠色小方框組成了TLS協議。上圖類似於TCP/IP模型，只是多了一層TLS層，用來加密資料。

（4）HTTPS架構圖

檢視HTTPS架構圖，其實HTTPS協議就是在HTTP基礎上加上了加密、驗證以及資料的保護。在使用HTTPS通訊時，使用的是 https://

（注意：HTTPS並非是新協議，他只是HTTP通訊介面中加了一個SSL協議）

在HTTPS通訊時會先和SSL層建立通訊，然後SSL層再和傳輸層中的TCP通訊。所以HTTPS就是披了一層SSL外殼的HTTP協議

（5）HTTPS傳輸速度

SSL的慢可歸於以下兩點：一是通訊慢，一是由於大量消耗CPU及記憶體等資源，導致處理速度變慢。

• 通訊慢：同HTTP協議相比，網路負載會變慢，因為除去TCP連線、HTTP請求與響應外，還必須處理SSL、TSL通訊，導致通訊量的增加。
• SSL必須進行加密處理：在伺服器端和客戶端都要通過加密、解密進行資料的安全處理，因此從結果而言，比起HTTP會更多地消耗伺服器和客戶端的硬體資源，導致負載增強。

綜合以上因素，只有在處理敏感資訊時才使用HTTPS加密通訊。

3. TLS與SSL握手過程

檢視上圖，TLS與SSL握手過程可以總結以下5個步驟：

（1）客戶端發起請求

首先客戶端會將它支援的協議版本、加密壓縮演算法，並生成一個隨機數（握手過程的第一個隨機數）一起傳送給服務端。注意：此隨機數與後續服務端產生的隨機數會組成金鑰。

（2）伺服器迴應

當服務端收到客戶端 hello的請求後，會確定加密的協議演算法，也會生成自己的一個隨機數（握手過程的第二個隨機數），連同證書一起傳送給客戶端。注意，至此客戶端和服務端都擁有了兩個隨機數（Random1+ Random2），這兩個隨機數會在後續生成對稱祕鑰時用到。

（3）客戶端驗證證書

當客戶端再次迴應時，首先對服務端發來的證書進行驗證，驗證完畢後會再次產生一個隨機數（握手過程的第三個隨機數），此隨機數是使用證書中公鑰加密的，通知服務端編碼已改變、握手結束。

（4）生成金鑰

服務端接收到金鑰之後，用私鑰對這加密的資料進行解密並驗證，驗證完畢後向客戶端發出通知確認編碼改變、握手結束。

（5）客戶端傳送資料

客戶端收到服務端發來的通知確認後，可以和服務端進行HTTPS安全的訊息通訊了。

注意

由於SSL協議在握手階段使用的是非對稱加密，一般是RSA加密演算法，所以需知隨機數是不能隨意破解的，它是安全性的保證。

4. 再論TLS與SSL握手過程

以上第3點對TLS與SSL握手過程的總結適合新手初次學習，而此部分就正式地去介紹其細節，檢視以下時序圖：

(1)client_hello

客戶端發起請求，以明文傳輸請求資訊，包含版本資訊，加密套件候選列表，壓縮演算法候選列表，隨機數，擴充套件欄位等資訊：

• 支援的最高TSL協議版本version；
• 客戶端支援的加密套件 cipher suites 列表， 每個加密套件對應前面 TLS 原理中的四個功能的組合：認證演算法 Au (身份驗證)、金鑰交換演算法 KeyExchange(金鑰協商)、對稱加密演算法 Enc (資訊加密)和資訊摘要 Mac(完整性校驗)；
• 支援的壓縮演算法；
• 擴充套件欄位 extensions；
• 隨機數 random_C（此過程的第一個隨機數），用於後續的金鑰的生成；

(2)server_hello + server_certificate + sever_hello_done

• server_hello：服務端返回協商的資訊結果，包括選擇使用的協議版本 version，選擇的加密套件 cipher suite，選擇的壓縮演算法 compression method、隨機數 random_S（此過程的第二個隨機數） 等，其中隨機數用於後續的金鑰協商;
• server_certificates： 伺服器端配置對應的證書鏈，用於身份驗證與金鑰交換;
• server_hello_done：通知客戶端 server_hello 資訊傳送結束;

(3)證書校驗

客戶端驗證證書的合法性，如果驗證通過才會進行後續通訊，否則根據錯誤情況不同做出提示和操作，合法性驗證包括如下：

• 證書鏈的可信性 trusted certificate path，方法如前文所述;
• 證書是否吊銷 revocation，有兩類方式離線 CRL 與線上 OCSP，不同的客戶端行為會不同;
• 有效期 expiry date，證書是否在有效時間範圍;
• 域名 domain，核查證書域名是否與當前的訪問域名匹配，匹配規則後續分析;

(4)client_key_exchange + change_cipher_spec + encrypted_handshake_message

• client_key_exchange：合法性驗證通過之後，客戶端計算產生隨機數字 Pre-master（此過程的第三個隨機數），並用證書公鑰加密，傳送給伺服器。

此時客戶端已經獲取全部的計算協商金鑰需要的資訊：兩個明文隨機數 random_C 和 random_S 與自己計算產生的 Pre-master，計算得到協商金鑰。

• change_cipher_spec：客戶端通知伺服器後續的通訊都採用協商的通訊金鑰和加密演算法進行加密通訊。

• encrypted_handshake_message：，結合之前所有通訊引數的 hash 值與其它相關資訊生成一段資料，採用協商金鑰 session secret 與演算法進行加密，然後傳送給伺服器用於資料與握手驗證。

(5) change_cipher_spec + encrypted_handshake_message

• 伺服器用私鑰解密加密的 Pre-master 資料，基於之前交換的兩個明文隨機數 random_C 和 random_S，計算得到協商金鑰

enc_key=Fuc(random_C, random_S, Pre-Master)

• 1

• 計算之前所有接收資訊的 hash 值，然後解密客戶端傳送的 encrypted_handshake_message，驗證資料和金鑰正確性。

• change_cipher_spec： 驗證通過之後，伺服器同樣傳送 change_cipher_spec 以告知客戶端後續的通訊都採用協商的金鑰與演算法進行加密通訊。

• encrypted_handshake_message： 伺服器也結合所有當前的通訊引數資訊生成一段資料並採用協商金鑰 session secret 與演算法加密併發送到客戶端。

(6)握手結束

客戶端計算所有接收資訊的 hash 值，並採用協商金鑰解密 encrypted_handshake_message，驗證伺服器傳送的資料和金鑰，驗證通過則握手完成。

(7)加密通訊

開始使用協商金鑰與演算法進行加密通訊。

注意：

伺服器也可以要求驗證客戶端，即雙向認證，可以在過程2要傳送 client_certificate_request 資訊，客戶端在過程4中先發送 client_certificate與certificate_verify_message 資訊，證書的驗證方式基本相同，certificate_verify_message 是採用client的私鑰加密的一段基於已經協商的通訊資訊得到資料，伺服器可以採用對應的公鑰解密並驗證。

後續相關知識還有：為了加快建立握手的速度，減少協議帶來的效能降低和資源消耗(具體分析在後文)，TLS 協議有兩類會話快取機制：會話標識 session ID 與會話記錄 session ticket。可檢視以下連結。

5. 總結

HTTPS實際上就是在TCP層與HTTP層之間加入了SSL/TLS來為上層的安全保駕護航，主要用到對稱加密、非對稱加密、證書等技術進行客戶端與伺服器的資料加密傳輸，最終達到保證整個通訊的安全性。