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 也被發現存在問題，所以很多瀏覽器直接廢除了 該協議版本。