轉(zhuǎn)載自 github：Interview-Notebook，有刪減和改動(dòng)
參考：《圖解 HTTP》
一 、基礎(chǔ)概念
Web 基礎(chǔ)
- HTTP（HyperText Transfer Protocol，超文本傳輸協(xié)議）。
- WWW（World Wide Web）的三種技術(shù)：HTML、HTTP、URL。
- RFC（Request for Comments，征求修正意見書），互聯(lián)網(wǎng)的設(shè)計(jì)文檔。
URL
- URI（Uniform Resource Indentifier，統(tǒng)一資源標(biāo)識(shí)符）
- URL（Uniform Resource Locator，統(tǒng)一資源定位符）
- URN（Uniform Resource Name，統(tǒng)一資源名稱），例如 urn:isbn:0-486-27557-4 。
URI 包含 URL 和 URN，目前 WEB 只有 URL 比較流行，所以見到的基本都是 URL。
請(qǐng)求和響應(yīng)報(bào)文
1. 請(qǐng)求報(bào)文
2. 響應(yīng)報(bào)文
二、HTTP 方法
客戶端發(fā)送的 請(qǐng)求報(bào)文 第一行為請(qǐng)求行，包含了方法字段。
GET
獲取資源
當(dāng)前網(wǎng)絡(luò)請(qǐng)求中，絕大部分使用的是 GET 方法。
HEAD
獲取報(bào)文首部
和 GET 方法一樣，但是不返回報(bào)文實(shí)體主體部分。
主要用于確認(rèn) URL 的有效性以及資源更新的日期時(shí)間等。
POST
傳輸實(shí)體主體
POST 主要用來(lái)傳輸數(shù)據(jù)，而 GET 主要用來(lái)獲取資源。
更多 POST 與 GET 的比較請(qǐng)見第八章。
PUT
上傳文件
由于自身不帶驗(yàn)證機(jī)制，任何人都可以上傳文件，因此存在安全性問(wèn)題，一般不使用該方法。
PUT /new.html HTTP/1.1
Host: example.com
Content-type: text/html
Content-length: 16
<p>New File</p>
PATCH
對(duì)資源進(jìn)行部分修改
PUT 也可以用于修改資源，但是只能完全替代原始資源，PATCH 允許部分修改。
PATCH /file.txt HTTP/1.1
Host: www.example.com
Content-Type: application/example
If-Match: "e0023aa4e"
Content-Length: 100
[description of changes]
DELETE
刪除文件
與 PUT 功能相反，并且同樣不帶驗(yàn)證機(jī)制。
DELETE /file.html HTTP/1.1
OPTIONS
查詢支持的方法
查詢指定的 URL 能夠支持的方法。
會(huì)返回 Allow: GET, POST, HEAD, OPTIONS 這樣的內(nèi)容。
CONNECT
要求用隧道協(xié)議連接代理
要求在與代理服務(wù)器通信時(shí)建立隧道，使用 SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協(xié)議把通信內(nèi)容加密后經(jīng)網(wǎng)絡(luò)隧道傳輸。
CONNECT www.example.com:443 HTTP/1.1
TRACE
追蹤路徑
服務(wù)器會(huì)將通信路徑返回給客戶端。
發(fā)送請(qǐng)求時(shí)，在 Max-Forwards 首部字段中填入數(shù)值，每經(jīng)過(guò)一個(gè)服務(wù)器就會(huì)減 1，當(dāng)數(shù)值為 0 時(shí)就停止傳輸。
通常不會(huì)使用 TRACE，并且它容易受到 XST 攻擊（Cross-Site Tracing，跨站追蹤），因此更不會(huì)去使用它。
三、HTTP 狀態(tài)碼
服務(wù)器返回的 響應(yīng)報(bào)文 中第一行為狀態(tài)行，包含了狀態(tài)碼以及原因短語(yǔ)，用來(lái)告知客戶端請(qǐng)求的結(jié)果。
| 狀態(tài)碼 | 類別 | 原因短語(yǔ) |
|---|---|---|
| 1XX | Informational（信息性狀態(tài)碼） | 接收的請(qǐng)求正在處理 |
| 2XX | Success（成功狀態(tài)碼） | 請(qǐng)求正常處理完畢 |
| 3XX | Redirection（重定向狀態(tài)碼） | 需要進(jìn)行附加操作以完成請(qǐng)求 |
| 4XX | Client Error（客戶端錯(cuò)誤狀態(tài)碼） | 服務(wù)器無(wú)法處理請(qǐng)求 |
| 5XX | Server Error（服務(wù)器錯(cuò)誤狀態(tài)碼） | 服務(wù)器處理請(qǐng)求出錯(cuò) |
1XX 信息
- 100 Continue ：表明到目前為止都很正常，客戶端可以繼續(xù)發(fā)送請(qǐng)求或者忽略這個(gè)響應(yīng)。
2XX 成功
200 OK
204 No Content ：請(qǐng)求已經(jīng)成功處理，但是返回的響應(yīng)報(bào)文不包含實(shí)體的主體部分。一般在只需要從客戶端往服務(wù)器發(fā)送信息，而不需要返回?cái)?shù)據(jù)時(shí)使用。
206 Partial Content ：表示客戶端進(jìn)行了范圍請(qǐng)求。響應(yīng)報(bào)文包含由 Content-Range 指定范圍的實(shí)體內(nèi)容。
3XX 重定向
301 Moved Permanently ：永久性重定向
302 Found ：臨時(shí)性重定向
303 See Other ：和 302 有著相同的功能，但是 303 明確要求客戶端應(yīng)該采用 GET 方法獲取資源。
注：雖然 HTTP 協(xié)議規(guī)定 301、302 狀態(tài)下重定向時(shí)不允許把 POST 方法改成 GET 方法，但是大多數(shù)瀏覽器都會(huì)在 301、302 和 303 狀態(tài)下的重定向把 POST 方法改成 GET 方法。
304 Not Modified ：如果請(qǐng)求報(bào)文首部包含一些條件，例如：If-Match，If-ModifiedSince，If-None-Match，If-Range，If-Unmodified-Since，如果不滿足條件，則服務(wù)器會(huì)返回 304 狀態(tài)碼。
307 Temporary Redirect ：臨時(shí)重定向，與 302 的含義類似，但是 307 要求瀏覽器不會(huì)把重定向請(qǐng)求的 POST 方法改成 GET 方法。
4XX 客戶端錯(cuò)誤
400 Bad Request ：請(qǐng)求報(bào)文中存在語(yǔ)法錯(cuò)誤。
401 Unauthorized ：該狀態(tài)碼表示發(fā)送的請(qǐng)求需要有認(rèn)證信息（BASIC 認(rèn)證、DIGEST 認(rèn)證）。如果之前已進(jìn)行過(guò)一次請(qǐng)求，則表示用戶認(rèn)證失敗。
403 Forbidden ：請(qǐng)求被拒絕，服務(wù)器端沒(méi)有必要給出拒絕的詳細(xì)理由。
404 Not Found
5XX 服務(wù)器錯(cuò)誤
500 Internal Server Error ：服務(wù)器正在執(zhí)行請(qǐng)求時(shí)發(fā)生錯(cuò)誤。
503 Service Unavilable ：服務(wù)器暫時(shí)處于超負(fù)載或正在進(jìn)行停機(jī)維護(hù)，現(xiàn)在無(wú)法處理請(qǐng)求。
四、HTTP 首部
有 4 種類型的首部字段：通用首部字段、請(qǐng)求首部字段、響應(yīng)首部字段和實(shí)體首部字段。
各種首部字段及其含義如下（不需要全記，僅供查閱）：
通用首部字段
| 首部字段名 | 說(shuō)明 |
|---|---|
| Cache-Control | 控制緩存的行為 |
| Connection | 控制不再轉(zhuǎn)發(fā)給代理的首部字段、管理持久連接 |
| Date | 創(chuàng)建報(bào)文的日期時(shí)間 |
| Pragma | 報(bào)文指令 |
| Trailer | 報(bào)文末端的首部一覽 |
| Transfer-Encoding | 指定報(bào)文主體的傳輸編碼方式 |
| Upgrade | 升級(jí)為其他協(xié)議 |
| Via | 代理服務(wù)器的相關(guān)信息 |
| Warning | 錯(cuò)誤通知 |
請(qǐng)求首部字段
| 首部字段名 | 說(shuō)明 |
|---|---|
| Accept | 用戶代理可處理的媒體類型 |
| Accept-Charset | 優(yōu)先的字符集 |
| Accept-Encoding | 優(yōu)先的內(nèi)容編碼 |
| Accept-Language | 優(yōu)先的語(yǔ)言（自然語(yǔ)言） |
| Authorization | Web 認(rèn)證信息 |
| Expect | 期待服務(wù)器的特定行為 |
| From | 用戶的電子郵箱地址 |
| Host | 請(qǐng)求資源所在服務(wù)器 |
| If-Match | 比較實(shí)體標(biāo)記（ETag） |
| If-Modified-Since | 比較資源的更新時(shí)間 |
| If-None-Match | 比較實(shí)體標(biāo)記（與 If-Match 相反） |
| If-Range | 資源未更新時(shí)發(fā)送實(shí)體 Byte 的范圍請(qǐng)求 |
| If-Unmodified-Since | 比較資源的更新時(shí)間（與 If-Modified-Since 相反） |
| Max-Forwards | 最大傳輸逐跳數(shù) |
| Proxy-Authorization | 代理服務(wù)器要求客戶端的認(rèn)證信息 |
| Range | 實(shí)體的字節(jié)范圍請(qǐng)求 |
| Referer | 對(duì)請(qǐng)求中 URI 的原始獲取方 |
| TE | 傳輸編碼的優(yōu)先級(jí) |
| User-Agent | HTTP 客戶端程序的信息 |
響應(yīng)首部字段
| 首部字段名 | 說(shuō)明 |
|---|---|
| Accept-Ranges | 是否接受字節(jié)范圍請(qǐng)求 |
| Age | 推算資源創(chuàng)建經(jīng)過(guò)時(shí)間 |
| ETag | 資源的匹配信息 |
| Location | 令客戶端重定向至指定 URI |
| Proxy-Authenticate | 代理服務(wù)器對(duì)客戶端的認(rèn)證信息 |
| Retry-After | 對(duì)再次發(fā)起請(qǐng)求的時(shí)機(jī)要求 |
| Server | HTTP 服務(wù)器的安裝信息 |
| Vary | 代理服務(wù)器緩存的管理信息 |
| WWW-Authenticate | 服務(wù)器對(duì)客戶端的認(rèn)證信息 |
實(shí)體首部字段
| 首部字段名 | 說(shuō)明 |
|---|---|
| Allow | 資源可支持的 HTTP 方法 |
| Content-Encoding | 實(shí)體主體適用的編碼方式 |
| Content-Language | 實(shí)體主體的自然語(yǔ)言 |
| Content-Length | 實(shí)體主體的大小 |
| Content-Location | 替代對(duì)應(yīng)資源的 URI |
| Content-MD5 | 實(shí)體主體的報(bào)文摘要 |
| Content-Range | 實(shí)體主體的位置范圍 |
| Content-Type | 實(shí)體主體的媒體類型 |
| Expires | 實(shí)體主體過(guò)期的日期時(shí)間 |
| Last-Modified | 資源的最后修改日期時(shí)間 |
五、具體應(yīng)用
Cookie
HTTP 協(xié)議是無(wú)狀態(tài)的，主要是為了讓 HTTP 協(xié)議盡可能簡(jiǎn)單，使得它能夠處理大量事務(wù)。HTTP/1.1 引入 Cookie 來(lái)保存狀態(tài)信息。
Cookie 是服務(wù)器發(fā)送給客戶端的數(shù)據(jù)，該數(shù)據(jù)會(huì)被保存在瀏覽器中，并且客戶端的下一次請(qǐng)求報(bào)文會(huì)包含該數(shù)據(jù)。通過(guò) Cookie 可以讓服務(wù)器知道兩個(gè)請(qǐng)求是否來(lái)自于同一個(gè)客戶端，從而實(shí)現(xiàn)保持登錄狀態(tài)等功能。
1. 創(chuàng)建過(guò)程
服務(wù)器發(fā)送的響應(yīng)報(bào)文包含 Set-Cookie 字段，客戶端得到響應(yīng)報(bào)文后把 Cookie 內(nèi)容保存到瀏覽器中。
HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry
[page content]
客戶端之后發(fā)送請(qǐng)求時(shí)，會(huì)從瀏覽器中讀出 Cookie 值，在請(qǐng)求報(bào)文中包含 Cookie 字段。
GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry
2. 分類
- 會(huì)話期 Cookie：瀏覽器關(guān)閉之后它會(huì)被自動(dòng)刪除，也就是說(shuō)它僅在會(huì)話期內(nèi)有效。
- 持久性 Cookie：指定一個(gè)特定的過(guò)期時(shí)間（Expires）或有效期（Max-Age）之后就成為了持久性的 Cookie。
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
3. Set-Cookie
| 屬性 | 說(shuō)明 |
|---|---|
| NAME=VALUE | 賦予 Cookie 的名稱和其值（必需項(xiàng)） |
| expires=DATE | Cookie 的有效期（若不明確指定則默認(rèn)為瀏覽器關(guān)閉前為止） |
| path=PATH | 將服務(wù)器上的文件目錄作為 Cookie 的適用對(duì)象（若不指定則默認(rèn)為文檔所在的文件目錄） |
| domain=域名 | 作為 Cookie 適用對(duì)象的域名（若不指定則默認(rèn)為創(chuàng)建 Cookie 的服務(wù)器的域名） |
| Secure | 僅在 HTTPs 安全通信時(shí)才會(huì)發(fā)送 Cookie |
| HttpOnly | 加以限制，使 Cookie 不能被 JavaScript 腳本訪問(wèn) |
4. Session 和 Cookie 區(qū)別
Session 是服務(wù)器用來(lái)跟蹤用戶的一種手段，每個(gè) Session 都有一個(gè)唯一標(biāo)識(shí)：Session ID。當(dāng)服務(wù)器創(chuàng)建了一個(gè) Session 時(shí)，給客戶端發(fā)送的響應(yīng)報(bào)文包含了 Set-Cookie 字段，其中有一個(gè)名為 sid 的鍵值對(duì)，這個(gè)鍵值對(duì)就是 Session ID。客戶端收到后就把 Cookie 保存在瀏覽器中，并且之后發(fā)送的請(qǐng)求報(bào)文都包含 Session ID。HTTP 就是通過(guò) Session 和 Cookie 這兩種方式一起合作來(lái)實(shí)現(xiàn)跟蹤用戶狀態(tài)的，Session 用于服務(wù)器端，Cookie 用于客戶端。
5. 瀏覽器禁用 Cookie 的情況
會(huì)使用 URL 重寫技術(shù)，在 URL 后面加上 sid=xxx 。
6. 使用 Cookie 實(shí)現(xiàn)用戶名和密碼的自動(dòng)填寫
網(wǎng)站腳本會(huì)自動(dòng)從保存在瀏覽器中的 Cookie 讀取用戶名和密碼，從而實(shí)現(xiàn)自動(dòng)填寫。
但是如果 Set-Cookie 指定了 HttpOnly 屬性，就無(wú)法通過(guò) Javascript 腳本獲取 Cookie 信息，這是出于安全性考慮。
緩存
1. 優(yōu)點(diǎn)
- 降低服務(wù)器的負(fù)擔(dān)；
- 提高響應(yīng)速度（緩存資源比服務(wù)器上的資源離客戶端更近）。
2. 實(shí)現(xiàn)方法
- 讓代理服務(wù)器進(jìn)行緩存；
- 讓客戶端瀏覽器進(jìn)行緩存。
3. Cache-Control 字段
HTTP 通過(guò) Cache-Control 首部字段來(lái)控制緩存。
Cache-Control: private, max-age=0, no-cache
4. no-cache 指令
該指令出現(xiàn)在請(qǐng)求報(bào)文的 Cache-Control 字段中，表示緩存服務(wù)器需要先向原服務(wù)器驗(yàn)證緩存資源是否過(guò)期；
該指令出現(xiàn)在響應(yīng)報(bào)文的 Cache-Control 字段中，表示緩存服務(wù)器在進(jìn)行緩存之前需要先驗(yàn)證緩存資源的有效性。
5. no-store 指令
該指令表示緩存服務(wù)器不能對(duì)請(qǐng)求或響應(yīng)的任何一部分進(jìn)行緩存。
no-cache 不表示不緩存，而是緩存之前需要先進(jìn)行驗(yàn)證，no-store 才是不進(jìn)行緩存。
6. max-age 指令
該指令出現(xiàn)在請(qǐng)求報(bào)文的 Cache-Control 字段中，如果緩存資源的緩存時(shí)間小于該指令指定的時(shí)間，那么就能接受該緩存。
該指令出現(xiàn)在響應(yīng)報(bào)文的 Cache-Control 字段中，表示緩存資源在緩存服務(wù)器中保存的時(shí)間。
Expires 字段也可以用于告知緩存服務(wù)器該資源什么時(shí)候會(huì)過(guò)期。在 HTTP/1.1 中，會(huì)優(yōu)先處理 Cache-Control : max-age 指令；而在 HTTP/1.0 中，Cache-Control : max-age 指令會(huì)被忽略掉。
持久連接
當(dāng)瀏覽器訪問(wèn)一個(gè)包含多張圖片的 HTML 頁(yè)面時(shí)，除了請(qǐng)求訪問(wèn) HTML 頁(yè)面資源，還會(huì)請(qǐng)求圖片資源，如果每進(jìn)行一次 HTTP 通信就要斷開一次 TCP 連接，連接建立和斷開的開銷會(huì)很大。持久連接只需要建立一次 TCP 連接就能進(jìn)行多次 HTTP 通信。
持久連接需要使用 Connection 首部字段進(jìn)行管理。HTTP/1.1 開始 HTTP 默認(rèn)是持久化連接的，如果要斷開 TCP 連接，需要由客戶端或者服務(wù)器端提出斷開，使用 Connection : close；而在 HTTP/1.1 之前默認(rèn)是非持久化連接的，如果要維持持續(xù)連接，需要使用 Connection : Keep-Alive。
管線化處理
HTTP/1.1 支持管線化處理，可以同時(shí)發(fā)送多個(gè)請(qǐng)求和響應(yīng)，而不需要發(fā)送一個(gè)請(qǐng)求然后等待響應(yīng)之后再發(fā)下一個(gè)請(qǐng)求。
編碼
編碼（Encoding）主要是為了對(duì)實(shí)體進(jìn)行壓縮。常用的編碼有：gzip、compress、deflate、identity，其中 identity 表示不執(zhí)行壓縮的編碼格式。
分塊傳輸編碼
Chunked Transfer Coding，可以把數(shù)據(jù)分割成多塊，讓瀏覽器逐步顯示頁(yè)面。
多部分對(duì)象集合
一份報(bào)文主體內(nèi)可含有多種類型的實(shí)體同時(shí)發(fā)送，每個(gè)部分之間用 boundary 字段定義的分隔符進(jìn)行分隔，每個(gè)部分都可以有首部字段。
例如，上傳多個(gè)表單時(shí)可以使用如下方式：
Content-Type: multipart/form-data; boundary=AaB03x
--AaB03x
Content-Disposition: form-data; name="submit-name"
Larry
--AaB03x
Content-Disposition: form-data; name="files"; filename="file1.txt"
Content-Type: text/plain
... contents of file1.txt ...
--AaB03x--
范圍請(qǐng)求
如果網(wǎng)絡(luò)出現(xiàn)中斷，服務(wù)器只發(fā)送了一部分?jǐn)?shù)據(jù)，范圍請(qǐng)求使得客戶端能夠只請(qǐng)求未發(fā)送的那部分?jǐn)?shù)據(jù)，從而避免服務(wù)器端重新發(fā)送所有數(shù)據(jù)。
在請(qǐng)求報(bào)文首部中添加 Range 字段指定請(qǐng)求的范圍，請(qǐng)求成功的話服務(wù)器發(fā)送 206 Partial Content 狀態(tài)。
GET /z4d4kWk.jpg HTTP/1.1
Host: i.imgur.com
Range: bytes=0-1023
HTTP/1.1 206 Partial Content
Content-Range: bytes 0-1023/146515
Content-Length: 1024
...
(binary content)
內(nèi)容協(xié)商
通過(guò)內(nèi)容協(xié)商返回最合適的內(nèi)容，例如根據(jù)瀏覽器的默認(rèn)語(yǔ)言選擇返回中文界面還是英文界面。
涉及以下首部字段：Accept、Accept-Charset、Accept-Encoding、Accept-Language、Content-Language。
虛擬主機(jī)
HTTP/1.1 使用虛擬主機(jī)技術(shù)，使得一臺(tái)服務(wù)器擁有多個(gè)域名，并且在邏輯上可以看成多個(gè)服務(wù)器。
使用 Host 首部字段進(jìn)行處理。
通信數(shù)據(jù)轉(zhuǎn)發(fā)
1. 代理
代理服務(wù)器接受客戶端的請(qǐng)求，并且轉(zhuǎn)發(fā)給其它服務(wù)器。
使用代理的主要目的是：緩存、網(wǎng)絡(luò)訪問(wèn)控制以及訪問(wèn)日志記錄。
代理服務(wù)器分為正向代理和反向代理兩種，用戶察覺得到正向代理的存在，而反向代理一般位于內(nèi)部網(wǎng)絡(luò)中，用戶察覺不到。
2. 網(wǎng)關(guān)
與代理服務(wù)器不同的是，網(wǎng)關(guān)服務(wù)器會(huì)將 HTTP 轉(zhuǎn)化為其它協(xié)議進(jìn)行通信，從而請(qǐng)求其它非 HTTP 服務(wù)器的服務(wù)。
3. 隧道
使用 SSL 等加密手段，為客戶端和服務(wù)器之間建立一條安全的通信線路。隧道本身不去解析 HTTP 請(qǐng)求。
六、HTTPs
HTTP 有以下安全性問(wèn)題：
- 使用明文進(jìn)行通信，內(nèi)容可能會(huì)被竊聽；
- 不驗(yàn)證通信方的身份，通信方的身份有可能遭遇偽裝；
- 無(wú)法證明報(bào)文的完整性，報(bào)文有可能遭篡改。
HTTPs 并不是新協(xié)議，而是 HTTP 先和 SSL（Secure Sockets Layer）通信，再由 SSL 和 TCP 通信。也就是說(shuō) HTTPs 使用了隧道進(jìn)行通信。
通過(guò)使用 SSL，HTTPs 具有了加密、認(rèn)證和完整性保護(hù)。
加密
1. 對(duì)稱密鑰加密
對(duì)稱密鑰加密（Symmetric-Key Encryption），加密的加密和解密使用同一密鑰。
- 優(yōu)點(diǎn)：運(yùn)算速度快；
- 缺點(diǎn)：密鑰容易被獲取。
2. 公開密鑰加密
公開密鑰加密（Public-Key Encryption），也稱為非對(duì)稱密鑰加密，使用一對(duì)密鑰用于加密和解密，分別為公開密鑰和私有密鑰。公開密鑰所有人都可以獲得，通信發(fā)送方獲得接收方的公開密鑰之后，就可以使用公開密鑰進(jìn)行加密，接收方收到通信內(nèi)容后使用私有密鑰解密。
- 優(yōu)點(diǎn)：更為安全；
- 缺點(diǎn)：運(yùn)算速度慢；
3. HTTPs 采用的加密方式
HTTPs 采用混合的加密機(jī)制，使用公開密鑰加密用于傳輸對(duì)稱密鑰，之后使用對(duì)稱密鑰加密進(jìn)行通信。（下圖中的 Session Key 就是對(duì)稱密鑰）
認(rèn)證
通過(guò)使用 證書 來(lái)對(duì)通信方進(jìn)行認(rèn)證。
數(shù)字證書認(rèn)證機(jī)構(gòu)（CA，Certificate Authority）是客戶端與服務(wù)器雙方都可信賴的第三方機(jī)構(gòu)。服務(wù)器的運(yùn)營(yíng)人員向 CA 提出公開密鑰的申請(qǐng)，CA 在判明提出申請(qǐng)者的身份之后，會(huì)對(duì)已申請(qǐng)的公開密鑰做數(shù)字簽名，然后分配這個(gè)已簽名的公開密鑰，并將該公開密鑰放入公開密鑰證書后綁定在一起。
進(jìn)行 HTTPs 通信時(shí)，服務(wù)器會(huì)把證書發(fā)送給客戶端，客戶端取得其中的公開密鑰之后，先進(jìn)行驗(yàn)證，如果驗(yàn)證通過(guò)，就可以開始通信。
使用 OpenSSL 這套開源程序，每個(gè)人都可以構(gòu)建一套屬于自己的認(rèn)證機(jī)構(gòu)，從而自己給自己頒發(fā)服務(wù)器證書。瀏覽器在訪問(wèn)該服務(wù)器時(shí)，會(huì)顯示“無(wú)法確認(rèn)連接安全性”或“該網(wǎng)站的安全證書存在問(wèn)題”等警告消息。
完整性
SSL 提供報(bào)文摘要功能來(lái)驗(yàn)證完整性。
七、Q and A
Get 請(qǐng)求和 Post 請(qǐng)求的區(qū)別
- 參數(shù)傳遞：GET 的參數(shù)只能帶在URL后面，URL有長(zhǎng)度限制，一般為2048個(gè)字符。POST 請(qǐng)求參數(shù)在 body 中，長(zhǎng)度無(wú)明確規(guī)定的限制。GET 因?yàn)閰?shù)在URL中可見，安全性較差。
- 冪等性：GET 是冪等的，POST 不是冪等的。引入冪等主要是為了處理同一個(gè)請(qǐng)求重復(fù)發(fā)送的情況，比如在請(qǐng)求響應(yīng)前失去連接，如果方法是冪等的，就可以放心地重發(fā)一次請(qǐng)求。GET后退按鈕/刷新無(wú)害，POST數(shù)據(jù)會(huì)被重新提交（瀏覽器應(yīng)該告知用戶數(shù)據(jù)會(huì)被重新提交）。
- 可緩存性：GET 是可被緩存的，POST是不可被緩存的。
- GET 不可指定編碼類型（只允許ASCII字符），POST 可以指定編碼類型，也允許二進(jìn)制數(shù)據(jù)。
- GET產(chǎn)生一個(gè)TCP數(shù)據(jù)包；POST產(chǎn)生兩個(gè)TCP數(shù)據(jù)包。對(duì)于GET方式的請(qǐng)求，瀏覽器會(huì)把http header和data一并發(fā)送出去，服務(wù)器響應(yīng)200（返回?cái)?shù)據(jù)）； 而對(duì)于POST，瀏覽器先發(fā)送header，服務(wù)器響應(yīng)100 continue，瀏覽器再發(fā)送data，服務(wù)器響應(yīng)200 ok（返回?cái)?shù)據(jù)）。
