《圖解HTTP》核心知識總結

HTTP協議的簡介

HTTP是超文本傳輸協議，用於客戶端和服務器端之間的通訊，屬於TCP/IP中的應用層。

HTTP協議的基礎知識

客戶端和服務器端

客戶端是服務請求方，服務器端是服務提供方。

URI和URL

URI:URI是統一資源標識符；

URL:是統一資源定位器;

URI的格式(瞭解便可)
[scheme:][//user:password@]host[:port][/path][?query][#fragment]
如上是URI的具體格式，下面介紹其意義：

• scheme::是協議方案，好比http:,https:,file:等,此項可選可不選
• [//[user:password@]:指定用戶名和密碼做爲從服務器獲取資源時必要的登錄信息，此項是可選項
• host:服務器地址，例如www.runoob.com
• [:port]：服務器端口號,例如：8080，此項是可選項
• [/path]:指定服務器上的文件路徑來定位特指的資源
• [?query]:查詢字符串，例如?id=123&pas=123
• [#fragment]:片斷標識符

DNS

見DNS基礎知識

HTTP的特色

HTTP經過請求和響應來達成通訊

如圖：

HTTP 是無狀態協議

HTTP 是無狀態協議，它不對以前發生過的請求和響應的狀態進行管理。也就是說，沒法根據以前的狀態進行本次的請求處理。

假設要求登陸認證的 Web 頁面自己沒法進行狀態的管理（不記錄已 登陸的狀態），那麼每次跳轉新頁面不是要再次登陸，就是要在每次 請求報文中附加參數來管理登陸狀態。

HTTP使用 Cookie 的狀態管理，Cookie 技術經過在請求和響應報文中寫入 Cookie 信 息來控制客戶端的狀態。

Cookie 會根據從服務器端發送的響應報文內的一個叫作 Set-Cookie 的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入 Cookie 值後發送出 去。服務器端發現客戶端發送過來的 Cookie 後，會去檢查到底是從哪一 個客戶端發來的鏈接請求，而後對比服務器上的記錄，最後獲得以前 的狀態信息。

以下圖：

HTTP報文

HTTP報文是HTTP請求和響應的單位。用於請求的報文叫作請求報文，而用於響應的報文叫作 響應報文。

報文的結構如圖

報文主體和實體主體的差別 :
實體做爲請求或響應的有效載荷數據（補充項）被傳輸，其內容由實體首部和實體主體組成。HTTP 報文的主體用於傳輸請求或響應的實體主體。 一般，報文主體等於實體主體。只有當傳輸中進行編碼操做時，實體 主體的內容發生變化，才致使它和報文主體產生差別

HTTP首部字段的結構

首部字段名: 字段值

若是有多個值，則首部字段名: 字段值1, 字段值2

若是HTTP首部字段重複了會如何？
當HTTP報文首部中出現中出現了兩個或兩個以上具備相同首部字段名時會怎麼樣？這種狀況 在規範中還沒有明確，根據瀏覽器內部處理邏輯的不一樣，結果可能並不一致。

HTTP首部字段分爲四個部分：

• 通用首部字段：請求報文和響應報文兩方都會使用的首部字段
• 請求首部字段：從客戶端向服務器端發送請求報文時使用的首部。補充了請求的附加內容、客戶端信息、響應內容相關優先級等信息。
• 響應首部字段：從服務器端向客戶端返回響應報文時使用的首部。補充了響應的附加內容，也會爲客戶端附加額外的內容信息
• 實體首部字段：針對請求報文和響應報文的實體部分使用的首部。補充了資源內容的更新時間等與實體有關的信息

實例分析

如今以請求菜鳥教程的報文爲例來進行分析：

請求報文

GET /HTTP/1.1        //請求行
Host: www.runoob.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2 Accept-Encoding: gzip, deflate, br Referer: https://cn.bing.com/ Connection: keep-alive Cookie: Hm_lvt_3eec0b7da6548cf07db3bc477ea905ee=1554627142,1556799533; _ga=GA1.2.579069872.1554627144; Hm_lpvt_3eec0b7da6548cf07db3bc477ea905ee=1556799533; _gid=GA1.2.1514513796.1556799533; _gat_gtag_UA_84264393_2=1 Upgrade-Insecure-Requests: 1 Cache-Control: max-age=0 複製代碼

響應報文

HTTP/1.1 200 OK      //狀態行
Server: Tengine
Content-Type: text/html
Content-Length: 150124
Connection: keep-alive
Date: Thu, 02 May 2019 09:27:08 GMT
Content-Encoding: gzip
Vary: Accept-Encoding
X-M-Log: QNM:xs446;QNM3:1
X-M-Reqid: jVAAADsHtCKO05oV
X-Powered-By: HHVM/3.28.1
X-Qnm-Cache: Hit
Ali-Swift-Global-Savetime: 1556270140
Via: cache16.l2cn1807[0,200-0,H], cache37.l2cn1807[1,0], cache9.cn1066[0,200-0,H], cache5.cn1066[1,0]
Age: 10328
X-Cache: HIT TCP_MEM_HIT dirn:11:466942761
X-Swift-SaveTime: Thu, 02 May 2019 10:36:54 GMT
X-Swift-CacheTime: 86400
Timing-Allow-Origin: *
EagleId: db971b1915567995564074785e
複製代碼

請求行和狀態行

請求行：請求行中包含用於請求的方法，請求的URI和HTTP版本
狀態行：狀態行包含響應結果的狀態碼，緣由短語和HTTP版本

在請求報文中GET /HTTP/1.1是請求行，其中GET表明請求的方法，/HTTP/1.1表明HTTP版本，在這個請求中未出現請求的URI。

在響應報文中HTTP/1.1 200 OK是狀態行，其中HTTP/1.1是請求的版本，200是響應結果的狀態碼，而OK 則是緣由短語。

請求的方法

GET：GET方法用來訪問以被URI識別的資源。指定的資源經服務器解析後返回響應的內容。以下圖

POST: POST方法用來傳輸實體的主體。以下圖

其餘方法如PUT HEAD DELETE OPTIONS TRACE CONNECT通常不使用。下面簡單介紹一下：

方法	做用	不使用的緣由
PUT	用來傳輸文件	PUT方法不採用任何驗證機制，存在安全問題
HEAD	和GET方法同樣，不過只返回響應首部	---
DELETE	用來刪除文件	DELETE不採用任何驗證機制，存在安全問題
OPTIONS	查詢針對請求URI指定的資源支持的方法	----
TRACE	讓WEB服務器端將以前的請求通訊返回給客戶端	容易引起跨站追蹤（XST）攻擊
CONNECT	要求在與代理服務器通訊時創建隧道，實現用隧道協議進行TCP通訊	----

狀態碼

2XX

200 ok

表示從客戶端發來的請求在服務器端被正常處理了

204 Not Content

該狀態碼錶明服務器接收的請求已經被成功處理，可是返回的響應報文中不包含實體的主體部分

206 Partial Content

該狀態碼錶示客戶端進行了範圍請求，而服務器成功執行了這部分的GET請求

3XX

301 Moved Permanently

永久性重定向，該狀態碼錶示請求的資源已被分配到新的URI，之後應該 使用如今所指的URI。

302 Found

臨時重定向。該狀態碼代表請求的資源已被分配了新的URI，但願用戶本次能使用新的URI訪問。

303 See Other

該狀態碼錶示因爲請求資源存在另外一個URI，應該使用GET方法定向獲取請求的資源

304 Not Modified

該狀態碼錶示客戶端發送附帶條件請求時，服務器端容許請求訪問資源，但由於請求未知足條件的狀況後， 直接返回304.

307 Temporary Redirect

臨時重定向，和302類似。可是307不會從Post變成GET

4XX

400 Bad Request

該狀態碼錶示請求報文中存在語法錯誤。當錯誤發生時，須要修改請求的內容後再次發送請求

401 Unauthorized

該狀態碼錶示發送的請求須要經過HTTP認證的認證信息。另外若以前已經進行過一次請求，則表示用戶認證失敗

403 Forbidden

該狀態碼代表對請求資源的訪問被服務器拒絕了

404 Not Found

該狀態碼代表服務器上沒法找到請求的資源

5XX

500 Internal Server Error

該主題碼錶示服務器在執行請求時發生了錯誤

503 Service Unavailable

該狀態碼代表服務器暫時處於超負載或正在進行停機維護，如今沒法處理請求。

HTTP全部的首部字段

HTTP/1.1定義了以下47種首部地段，以下

通用首部字段：

請求首部字段：

響應首部字段：

實體首部字段：

非HTTP/1.1首部字段（不屬於47種中的字段）:Cookie、 Set-Cookie、 Content-Disposition等。

端到端首部和逐跳首部

HTTP將使用 緩存代理和非緩存代理 的首部字段分紅兩種類型：端到端首部（End-to-end Header）、逐跳首部(Hop-by-hop Header)

緩存代理
代理轉發響應時，緩存代理（Caching Proxy）會預先將資源的副本 （緩存）保存在代理服務器上。 當代理再次接收到對相同資源的請求時，就能夠不從源服務器那裏獲 取資源，而是將以前緩存的資源做爲響應返回。
透明代理
轉發請求或響應時，不對報文作任何加工的代理類型被稱爲透明代理 （Transparent Proxy）。反之，對報文內容進行加工的代理被稱爲非 透明代理。

注意：這裏的非緩存代理不等於透明代理；它們劃分的標準不同。`緩存代理`和`非緩存代理`是經過是否使用緩存來劃分的；而`透明代理`和`非透明代理`是經過是否會修改報文來劃分。

端到端首部：分在此類別中的首部會轉發給請求/響應對應的最終接收目標(即全程有效)，且必須保存在由緩存生成的響應中，另外規定它必須被轉發

逐跳首部：分在此類別的首部只對單次轉發有效，會由於經過緩存或代理而再也不轉發。在HTTP/1.1和之後版本中，若是要使用逐跳首部，須要經過Connection首部字段

逐跳首部字段爲：

• Connection
• Keep-Alive(新增字段，可忽略)
• Proxy-Authenticate
• Proxy-Authorization
• Trailer
• TE
• Transfer-Encoding
• Upgrade

其餘字段都爲端到端首部

通用首部字段

在實例的請求報文中出現的通用首部

Connection: keep-alive
Cache-Control: max-age=0
複製代碼

在實例的響應報文中出現的通用首部

Connection: keep-alive
Date: Thu, 02 May 2019 09:27:08 GMT
Via: cache16.l2cn1807[0,200-0,H], cache37.l2cn1807[1,0], cache9.cn1066[0,200-0,H], cache5.cn1066[1,0]
複製代碼

Cache-Control

經過指定首部字段Cathe-Control的指令，就能夠操做緩存的工做機制，如圖：

請求報文中Cache-Control: max-age=0表示緩存服務器一般須要將請求轉發給源服務器。

Connection

Connection的做用：

1. 控制再也不轉發給代理的首部字段
2. 管理持久化鏈接

控制再也不轉發給代理的首部字段

代理服務器的基本行爲就是接收客戶端發送的請求後轉發給其餘服務器。代理不改變請求 URI，會直接發送給前方持有資源的目標服務器。上面介紹的緩存代理是代理服務器做用的一種。

管理持久化鏈接

Connection: close //代表服務器想斷開鏈接
Connection: Keep-Alive //保持持久化鏈接（默認）
複製代碼

Via

用來追蹤客戶端與服務器端之間的請求和響應報文的傳輸路徑。
如Via: cache16.l2cn1807[0,200-0,H], cache37.l2cn1807[1,0], cache9.cn1066[0,200-0,H], cache5.cn1066[1,0]

Date

首部字段Date代表建立HTTP報文的時間，如Date: Thu, 02 May 2019 09:27:08 GMT就表示建立報文的時間爲2019年5月2日，星期二。

Pragma

Pragma是歷史遺留字段，僅做爲與HTTP/1.0的向後兼容而定義。

Trailer

用來講明在報文主體後記錄了哪些首部字段

Transfer-Encoding

規定傳輸報文主體時採用的編碼方式（僅對分塊傳輸編碼有效）

Upgrade

用來檢測HTTP協議及其餘協議是否可以使用更高的版本進行通訊。

Warning

告訴用戶一些與緩存有關的問題的警告

請求首部字段

請求報文（去除了通用首部字段）

Host: www.runoob.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate, br
Referer: https://cn.bing.com/
Cookie: Hm_lvt_3eec0b7da6548cf07db3bc477ea905ee=1554627142,1556799533; _ga=GA1.2.579069872.1554627144; Hm_lpvt_3eec0b7da6548cf07db3bc477ea905ee=1556799533; _gid=GA1.2.1514513796.1556799533; _gat_gtag_UA_84264393_2=1
Upgrade-Insecure-Requests: 1 
Cache-Control: max-age=0
複製代碼

Host

告訴服務器請求的資源所處的互聯網主機名和端口號，如Host: www.runoob.com。Host是惟一必須包含在請求內的首部字段

User-Agent

用來將建立請求的瀏覽器和用戶代理名稱等信息傳達給服務器。

例如上面的請求首部:
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0

Accept

通知服務器能夠處理的媒體類型及媒體類型的相對優先級

例如Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

媒體類型

文本文件

text/html, text/plain, text/css ... application/xhtml+xml, application/xml ...

圖片文件

image/jpeg, image/gif, image/png ...

視頻文件

video/mpeg, video/quicktime ...

應用程序使用的二進制文件

application/octet-stream, application/zip

優先級

使用q=來額外表示權重值，用;進行分隔。權重值的範圍是0~1（可精確到小數點後3位），且1爲最大值。不指定 權重值時，默認權重爲q=1.0.當服務器提供多個內容時會首先返回權重值最高的媒體類型。

Accept-Charset

Accept-Charset首部字段可用來通知服務器用戶代理支持的字符集及字符集的相對優先順序。另外可一次性指定多種字符集。與首部字段 Accept相同的可用權重q值來表示相對優先級

Accept-Encoding

Accept-Encoding首部字段用來告知服務器用戶代理支持的內容編碼及內容編碼的優先級順序。可一次性指定多種內容編碼，可用權重q來指定優先級 例如Accept-Encoding: gzip, deflate, br

Accept-Language

首部字段Accept-Language用來告訴服務器用戶代理可以處理的語言，能夠指定多個語言，可使用q來決定優先級。 例如Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2

Authorization

用來告訴服務器，用戶代理的認證信息

Expect

告知服務器指望出現某種特定的行爲

From

告訴服務器使用用戶代理的用戶的電子郵箱地址

If-Match

告訴服務器匹配資源所用的實體標記（ETag）值，服務器會對比If-Match的字段值和資源的ETag值，僅 當二者一致時才執行請求.反之則返回狀碼412

If-Modified-Since

告訴服務器若If-Modified-Since字段值早於資源更新的時間，則但願能處理該請求。 反之若是在If-Modified-Since指定的時間日期以後，若是請求的資源都沒有更新，則 返回的狀態碼 304

If-None-Match

與If-Match相反

If-Range

告訴服務器若指定的If-Range字段值（ETag值或者時間）和請求資源的ETag值或時間相一致時，則做爲範圍請求處理。 反之，則返回全體資源。如圖：

If-Unmodified-Since

與If-Modified-Since做用相反

Range

對於只需獲取部分資源的範圍請求，包含首部字段Range便可告知服務器資源的指定範圍。 接收到附帶Range首部字段請求的服務器，會在處理請求以後返回206.沒法處理該範圍的 請求時，則會返回200的響應及所有資源。

Referer

告訴服務器請求的原始URI

例如：Referer: https://cn.bing.com/說明我是從微軟必應請求的

Upgrade-Insecure-Requests

Upgrade-Insecure-Requests是一個請求首部，用來向服務器端發送信號，表示客戶端優先選擇加密及帶有身份驗證的響應。不屬於47種報文首部字段。

TE

告訴服務器，客戶端可以處理的傳輸編碼方式及相對優先級

Transfer-Encoding,TE,Content-Encoding,Accept-Encoding四個首部字段的區別

• Transfer-Encoding：用於指定傳輸報文主體時使用的編碼方式，屬於逐跳首部，即只在兩個節點間有效。
• TE：用於告知服務器客戶端可以處理的編碼方式和相對優先級，屬於逐跳首部，即只在兩個節點間有效。
• Content-Encoding：用於指定報文主體已經採用的編碼方式，屬於端到端首部，即在整個傳輸過程當中有效。
• Accept-Encoding：用於告知服務器客戶端可以處理的編碼方式和相對優先級，屬於端到端首部，即在整個傳輸過程當中有效。

很顯然，Transfer-Encoding和TE是一組，Content-Encoding和Accept-Encoding是一組。 根本區別在於，Content-Encoding和Accept-Encoding限制的是報文主體在整個傳輸過程當中使用的編碼方式，全局有效；Transfer-Encoding和TE限制的是報文主體在兩個節點間（源服務器和代理服務器之間、代理服務器和客戶端之間等）傳輸時使用的編碼方式，只在兩節點間有效。

轉自區分Transfer-Encoding,TE,Content-Encoding,Accept-Encoding四個首部字段

響應首部字段

響應報文

Server: Tengine
Vary: Accept-Encoding
X-M-Log: QNM:xs446;QNM3:1
X-M-Reqid: jVAAADsHtCKO05oV
X-Powered-By: HHVM/3.28.1
X-Qnm-Cache: Hit
Ali-Swift-Global-Savetime: 1556270140
Age: 10328
X-Cache: HIT TCP_MEM_HIT dirn:11:466942761
X-Swift-SaveTime: Thu, 02 May 2019 10:36:54 GMT
X-Swift-CacheTime: 86400
Timing-Allow-Origin: *
EagleId: db971b1915567995564074785e
複製代碼

Accept-Ranges

首部字段Accept-Ranges是用來告訴客戶端服務器是否能處理範圍請求，以指定獲取服務器端 某個部分的資源。能夠指定的值爲bytes(表示接受範圍請求)和none（表示不接受範圍請求）.

Age

告訴客戶端，源服務器在多久前建立了響應。字段值的單位爲秒。

ETag

主要用於檢驗緩存是否改變。它告訴客戶端實體標識，是一種可將資源以字符串的形式作惟一標識的方式。服務器會爲每份資源分配對應的ETag值

另外當資源更新時，ETag值也須要更新。當資源被緩存時，就會被分配惟一的標識。若在下載過程當中 出現鏈接的中斷，再鏈接的狀況，都會依照ETag值來指定資源。

ETag中有強ETag值和弱ETag值

強ETag值，不管實體發生多麼細微的變化都會改變其值。

弱ETag值，只用於提示資源是否相同。只有資源發生了根本改變，產生差別時纔會改變ETag值。這時， 會在字段值最開始處附加 W/

Location

將響應接受方引領到某個與請求URI位置不一樣的資源。基本上，該字段會配合3XX的響應，提供重定向的URI。

Proxy-Authenticate

會把由代理服務器所要求的認證信息發生給客戶端

Retry-After

告訴客戶端應該在多久以後再發送請求。主要配合狀態碼503響應或3xx響應一塊兒使用。字段值能夠指定爲具體的日期時間，也能夠是建立響應後的秒數

Server

告訴客戶端當前服務器上安裝的HTTP服務器應用程序的信息

Vary

對緩存進行控制。具體見這裏

WWW-Authenticate

用於HTTP訪問認證

實體首部字段

Allow

告訴客戶端支持的請求方法

Content-Encoding

告知客戶端服務器對實體的主體部分選用的內容編碼方式。內容編碼是指在不丟失實體信息的前提下所進行的壓縮

主要採用如下4種內容編碼的方式

• gzip
• compress
• deflate
• identity

Content-Language

告訴客戶端，實體使用的語言

Content-Length

代表實體主體部分的大小，單位是字節。對實體主體進行內容編碼傳輸時，不能再使用Content-Length 首部字段

Content-Location

給出報文主體部分相對應的URI。和首部字段Location不一樣，Content-Location表示的是報文主體返回資源對應的URI

Content-MD5

首部字段 Content-MD5 是一串由 MD5 算法生成的值，其目的在於檢 查報文主體在傳輸過程當中是否保持完整，以及確認傳輸到達。

Content-Range

針對範圍請求，返回響應時使用的首部字段Content-Range，能告訴客戶端做爲響應返回的實體的哪一個部分 符合範圍請求。字段值以字節爲單位，表示當前發送部分及整個實體大小。

Content-Type

說明實體主體內對象的媒體類型，和首部字段Accept同樣，字段值用type/subtype形式賦值

Http Header裏的Content-Type通常有這三種：

• application/x-www-form-urlencoded：數據被編碼爲名稱/值對(這是標準的編碼格式)。
• multipart/form-data： 數據被編碼爲一條消息，頁上的每一個控件對應消息中的一個部分。
• text/plain： 數據以純文本形式(text/json/xml/html)進行編碼，其中不含任何控件或格式字符(postman軟件裏標的是RAW)

form的enctype屬性爲編碼方式，經常使用有兩種：application/x-www-form-urlencoded和multipart/form-data，默認爲application/x-www-form-urlencoded。
當action爲get時候，瀏覽器用x-www-form-urlencoded的編碼方式把form數據轉換成一個字串（name1=value1&name2=value2...），而後把這個字串追加到url後面，用?分割，加載這個新的url。
當action爲post時候，瀏覽器把form數據封裝到http body中，而後發送到server。 若是沒有type=file的控件，用默認的application/x-www-form-urlencoded就能夠了。 可是若是有type=file的話，就要用到multipart/form-data了。
當action爲post且Content-Type類型是multipart/form-data，瀏覽器會把整個表單以控件爲單位分割，併爲每一個部分加上Content-Disposition(form-data或者file),Content-Type(默認爲text/plain),name(控件name)等信息，並加上分割符。

轉自Http Header裏的Content-Type

Expires

會將資源失效的日期告訴客戶端

Last-Modified

指明資源最終修改的時間

爲Cookie服務的首部字段

Set-Cookie

開始狀態管理所使用的Cookie信息（響應首部字段）

Cookie

告訴服務器，當客戶端想獲取HTTP狀態管理支持時，就會在請求中包含從服務器接受到的Cookie。接收到多個 Cookie時，同時能夠以多個Cookie形式發送

其餘首部字段

HTTP首部字段是能夠自行擴展的。因此在WEB服務器和瀏覽器應用上，會出現各類非標準的首部字段

X-Frame-Options

屬於響應首部，用於控制網站內容在其餘web網站的Frame標籤內的顯示問題。其主要目的是爲了防止 點擊劫持攻擊

有兩個可指定的字段值 DENY:拒絕 SAMEORIGIN:僅在同源域名下的頁面匹配時許可

X-XSS-Protection

屬於響應首部，它是針對跨站腳本攻擊（XSS）的一種對策，用於控制瀏覽器XSS防禦機制開關。

字段值： 0：將XSS過濾設置爲無效狀態 1：將XSS過濾設置爲有效狀態

DNT

屬於請求字段，意味拒絕我的信息被採集，是表示拒絕被精準廣告追蹤的一種方法

字段值 0：贊成被追蹤 1：拒絕被追蹤

P3P

屬於響應首部，經過利用 P3P（The Platform for Privacy Preferences，在線隱私偏好平臺）技術，可讓 Web 網站上 的我的隱私變成一種僅供程序可理解的形式，以達到保護用戶隱私的 目的。

協議中對X-前綴的廢除

在HTTP等多種協議中，經過給非標準參數加上前綴X-，來區別於標準參數，並使那些非標準參數做爲擴展變成可能（如上面的響應首部）。可是這種簡單粗暴的作法沒有任何好處，所以被提議中止。然而對已經在使用中的X-前綴來講，不該該要求其變動。

HTTP的缺點

• 通訊使用明文（不加密），內容可能被竊聽
• 不驗證通訊方的身份，所以有可能遭受假裝
• 沒法證實報文的完整性，因此內容可能被篡改

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

HTTPS 並不是是應用層的一種新協議。只是 HTTP 通訊接口部分用 SSL（Secure Socket Layer）和 TLS（Transport Layer Security）協議代 替而已。 一般，HTTP 直接和 TCP 通訊。當使用 SSL 時，則演變成先和 SSL 通 信，再由 SSL 和 TCP 通訊了。簡言之，所謂 HTTPS，其實就是身披 SSL 協議這層外殼的 HTTP

在採用 SSL 後，HTTP 就擁有了 HTTPS 的加密、證書和完整性保護 這些功能。

SSL 是獨立於 HTTP 的協議，因此不光是 HTTP 協議，其餘運行在應 用層的 SMTP 和 Telnet 等協議都可配合 SSL 協議使用。能夠說 SSL 是 當今世界上應用最爲普遍的網絡安全技術。

加密

加密和解密同用一個密鑰的方式稱爲共享密鑰加密（Common key crypto system），也被叫作對稱密鑰加密

共享密鑰加密的困境

以共享密鑰方式加密時必須將密鑰也發給對方。可究竟怎樣才能 安全地轉交？在互聯網上轉發密鑰時，若是通訊被監聽那麼密鑰 就可會落入攻擊者之手，同時也就失去了加密的意義。另外還得 設法安全地保管接收到的密鑰。

公開密鑰加密使用一對非對稱的密鑰。一把叫作私有密鑰 （private key），另外一把叫作公開密鑰（public key）。顧名思 義，私有密鑰不能讓其餘任何人知道，而公開密鑰則能夠隨意發 布，任何人均可以得到。

HTTPS 採用混合加密機制

HTTPS 採用共享密鑰加密和公開密鑰加密二者並用的混合加密 機制。若密鑰可以實現安全交換，那麼有可能會考慮僅使用公開 密鑰加密來通訊。

可是公開密鑰加密與共享密鑰加密相比，其處 理速度要慢。 因此應充分利用二者各自的優點，將多種方法組合起來用於通 信。在交換密鑰環節使用公開密鑰加密方式，以後的創建通訊交 換報文階段則使用共享密鑰加密方式。

證實公開密鑰正確性的證書

遺憾的是，公開密鑰加密方式仍是存在一些問題的。那就是沒法證實 公開密鑰自己就是貨真價實的公開密鑰。好比，正準備和某臺服務器 創建公開密鑰加密方式下的通訊時，如何證實收到的公開密鑰就是原 本預想的那臺服務器發行的公開密鑰。或許在公開密鑰傳輸途中，真 正的公開密鑰已經被攻擊者替換掉了。

爲了解決上述問題，可使用由數字證書認證機構（CA，Certificate Authority）和其相關機關頒發的公開密鑰證書

服務器會將這份由數字證書認證機構頒發的公鑰證書發送給客戶端， 以進行公開密鑰加密方式通訊。

公鑰證書也可叫作數字證書或直接稱 爲證書。 接到證書的客戶端可以使用數字證書認證機構的公開密鑰，對那張證書 上的數字簽名進行驗證，一旦驗證經過，客戶端即可明確兩件事：

• 認證服務器的公開密鑰的是真實有效的數字證書認證機構。
• 服務器的公開密鑰是值得信賴的。

此處認證機關的公開密鑰必須安全地轉交給客戶端。使用通訊方式 時，如何安全轉交是一件很困難的事，所以，多數瀏覽器開發商發佈 版本時，會事先在內部植入經常使用認證機關的公開密鑰。

HTTPS 的通訊步驟

• 步驟 1： 客戶端經過發送 Client Hello 報文開始 SSL 通訊。報文中包 含客戶端支持的 SSL 的指定版本、加密組件（Cipher Suite）列表（所 使用的加密算法及密鑰長度等）。
• 步驟 2： 服務器可進行 SSL 通訊時，會以 Server Hello 報文做爲應 答。和客戶端同樣，在報文中包含 SSL 版本以及加密組件。服務器的 加密組件內容是從接收到的客戶端加密組件內篩選出來的。
• 步驟 3： 以後服務器發送 Certificate 報文。報文中包含公開密鑰證 書。
• 步驟 4： 最後服務器發送 Server Hello Done 報文通知客戶端，最初階 段的 SSL 握手協商部分結束。
• 步驟 5： SSL 第一次握手結束以後，客戶端以 Client Key Exchange 報 文做爲迴應。報文中包含通訊加密中使用的一種被稱爲 Pre-master secret 的隨機密碼串。該報文已用步驟 3 中的公開密鑰進行加密。
• 步驟 6： 接着客戶端繼續發送 Change Cipher Spec 報文。該報文會提 示服務器，在此報文以後的通訊會採用 Pre-master secret 密鑰加密。
• 步驟 7： 客戶端發送 Finished 報文。該報文包含鏈接至今所有報文的 總體校驗值。此次握手協商是否可以成功，要以服務器是否可以正確 解密該報文做爲斷定標準。
• 步驟 8： 服務器一樣發送 Change Cipher Spec 報文。
• 步驟 9： 服務器一樣發送 Finished 報文。
• 步驟 10： 服務器和客戶端的 Finished 報文交換完畢以後，SSL 鏈接 就算創建完成。固然，通訊會受到 SSL 的保護。今後處開始進行應用 層協議的通訊，即發送 HTTP 請求。
• 步驟 11： 應用層協議通訊，即發送 HTTP 響應。
• 步驟 12： 最後由客戶端斷開鏈接。斷開鏈接時，發送 close_notify 報 文。上圖作了一些省略，這步以後再發送 TCP FIN 報文來關閉與 TCP 的通訊。 在以上流程中，應用層發送數據時會附加一種叫作 MAC（Message Authentication Code）的報文摘要。MAC 可以查知報文是否遭到篡 改，從而保護報文的完整性。

SSL 和 TLS HTTPS 使用 SSL（Secure Socket Layer） 和 TLS（Transport Layer Security）這兩個協議。 SSL 技術最初是由瀏覽器開發商網景通訊公司率先倡導的，開發 過 SSL3.0 以前的版本。目前主導權已轉移到 IETF（Internet Engineering Task Force，Internet 工程任務組）的手中。 IETF 以 SSL3.0 爲基準，後又制定了 TLS1.0、TLS1.1 和 TLS1.2。TSL 是以 SSL 爲原型開發的協議，有時會統一稱該協議 爲 SSL。當前主流的版本是 SSL3.0 和 TLS1.0。 因爲 SSL1.0 協議在設計之初被發現出了問題，就沒有實際投入 使用。SSL2.0 也被發現存在問題，因此不少瀏覽器直接廢除了 該協議版本。