HTTP
http，基于tcp協(xié)議，位于網(wǎng)絡(luò)分層模型的應(yīng)用層，tcp則是位于傳輸層，所以說(shuō)http是tcp的上層協(xié)議。
傳輸?shù)幕締挝唬簣?bào)文（由8位組字節(jié)流組成）。
絕對(duì)URI格式：
報(bào)文格式：
報(bào)文首部：
報(bào)文主體：請(qǐng)求報(bào)文一般為空（POST方法時(shí)不為空），在響應(yīng)報(bào)文中則指的是所請(qǐng)求的資源內(nèi)容
請(qǐng)求行：請(qǐng)求方法+URI+協(xié)議版本（GET /index.htm HTTP/1.1）
- 請(qǐng)求方法：
- GET：用于獲取資源
- POST：用于傳輸實(shí)體主體
- PUT：用于傳輸文件（出于安全考慮，一般不使用，除非web架構(gòu)存在安全驗(yàn)證機(jī)制）
- DELETE：用于刪除文件（與PUT相反的方法，安全問(wèn)題一樣存在）
- HEAD：與GET方法一樣，但是不返回報(bào)文主體部分，用于確認(rèn)資源有效性等
- OPTIONS：用于詢問(wèn)支持的方法
- TRACE：路徑追蹤，發(fā)送請(qǐng)求時(shí)，加入Max-Forwards字段及其值，每經(jīng)過(guò)一次服務(wù)器，字段值減1，數(shù)值為0時(shí)，停止傳輸，由最后收到請(qǐng)求的服務(wù)器返回200 OK的響應(yīng)
- CONNECT：要求在與代理服務(wù)器建立隧道通信，實(shí)現(xiàn)用隧道進(jìn)行TCP通信，HTTPS通信時(shí)用到
狀態(tài)行：版本協(xié)議+狀態(tài)碼+原因短語(yǔ)（HTTP/1.1 200 OK）
- 狀態(tài)碼類(lèi)別：
| 類(lè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ò) |
- 常見(jiàn)狀態(tài)碼：
- 200 OK ：請(qǐng)求被正常處理
- 204 No Content：請(qǐng)求處理成功。但是沒(méi)有資源返回
- 206 Partial Content：客戶端進(jìn)行范圍請(qǐng)求時(shí)，服務(wù)器成功執(zhí)行這部分請(qǐng)求。響應(yīng)報(bào)文中包含由Content-Range指定范圍的內(nèi)容實(shí)體
- 301 Moved Permanently：資源的URI進(jìn)行了永久性的更換
- 302 Found：資源URI進(jìn)行了臨時(shí)性更換
- 303 See Other：與302相同的功能，區(qū)別是要求客戶端采用GET方法進(jìn)行資源請(qǐng)求
- 304 Not Modified：客戶端進(jìn)行附加條件的請(qǐng)求（If-Match、If-Range），服務(wù)器允許請(qǐng)求資源，但條件未滿足情況，表示服務(wù)器資源未改變，可直接使用未過(guò)期緩存，雖被劃分到3xx類(lèi)別，但與重定向沒(méi)有關(guān)系
- 307 Temporary Redirect：與302含義相同，302禁止POST變成GET，但大家可能不遵守，307會(huì)遵照瀏覽器標(biāo)準(zhǔn)，不會(huì)從POST變GET
- 400 Bad Request：請(qǐng)求報(bào)文存在語(yǔ)法錯(cuò)誤
- 401 Unauthorized：需要進(jìn)行HTTP認(rèn)證，若之前已經(jīng)進(jìn)行過(guò)1次請(qǐng)求，表示認(rèn)證失敗
- 403 Forbidden：訪問(wèn)被拒絕
- 404 Not Found：無(wú)法找到請(qǐng)求的資源，服務(wù)器拒絕請(qǐng)求時(shí)不想解釋也可能會(huì)用
- 500 Internal Server Error：服務(wù)器在執(zhí)行請(qǐng)求時(shí)發(fā)生錯(cuò)誤，可能存在一些BUG或者臨時(shí)的故障
- 503 Service Unavailable：服務(wù)器超負(fù)載或進(jìn)行停機(jī)維護(hù)
請(qǐng)求首部字段、響應(yīng)首部字段、通用首部字段，這3個(gè)首部字段的字段說(shuō)明放置本文的最后，下面是Cookie
COOKIE：HTTP協(xié)議是一種無(wú)狀態(tài)協(xié)議，也就是在HTTP級(jí)別，協(xié)議對(duì)于發(fā)送過(guò)的請(qǐng)求和響應(yīng)都不做持久化處理。于是為了管理用戶狀態(tài)（如登錄狀態(tài)），引入了Cookie，web瀏覽器會(huì)將一些數(shù)據(jù)臨時(shí)寫(xiě)入用戶計(jì)算機(jī)，當(dāng)用戶再次訪問(wèn)時(shí)，將讀取之前存放的Cookie進(jìn)行通訊，在報(bào)文首部字段中，Cookie的首部字段為：
| 首部字段名 | 說(shuō)明 | 首部類(lèi)型 |
|---|---|---|
| Set-Cookie | 開(kāi)始狀態(tài)管理所使用的Cookie信息 | 響應(yīng)首部字段 |
| Cookie | 服務(wù)器接收到的Cookie信息 | 請(qǐng)求首部字段 |
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) |
示例：
Set-Cookie:status=enable; expires=true; 05 Jul 2011 07:26:31 GMT; paht=/; domain=.hackr.jp;
Cookie:status=enable
用戶身份認(rèn)證
- BASIC認(rèn)證（基本認(rèn)證）
- 認(rèn)證不夠便捷靈活，安全等級(jí)不夠，不常用
- DIGEST認(rèn)證（摘要認(rèn)證）
- 缺點(diǎn)與BASIC認(rèn)證一樣，不常用
- SSL客戶端認(rèn)證
- 通過(guò)第三方認(rèn)證機(jī)構(gòu)頒發(fā)證書(shū)進(jìn)行認(rèn)證，需要維護(hù)費(fèi)用
- 一般都是通過(guò)雙因素認(rèn)證，不止證書(shū)認(rèn)證，還包括了基于表單認(rèn)證
- FromBase認(rèn)證（基于表單認(rèn)證）
- 并非HTTP協(xié)議中定義的。即是用戶、密碼登錄的認(rèn)證。比較靈活，其安全等級(jí)由Web服務(wù)端的架構(gòu)安全性能決定，是大多數(shù)采用的方法
HTTPS
HTTP的缺點(diǎn)：
- 明文通信，內(nèi)容可能被竊聽(tīng)
- 無(wú)身份驗(yàn)證，可能遭遇偽裝
- 無(wú)驗(yàn)證報(bào)文完整性，可能遭篡改
HTTPS是身披SSL的HTTP
HTTPS=HTTP+加密+認(rèn)證+完整性保護(hù)
- 加密
- 共享密鑰加密：又稱對(duì)稱加密。用同一個(gè)密鑰進(jìn)行加密和解密，難點(diǎn)是如何將密鑰安全的送到對(duì)方手上
- 公開(kāi)密鑰加密：使用一對(duì)非對(duì)稱密鑰進(jìn)行加密。分為公鑰和私鑰，公鑰可公開(kāi)發(fā)布，私鑰為私自持有。通訊時(shí)，請(qǐng)求端通過(guò)公鑰加密，響應(yīng)端通過(guò)私鑰解密。
- 混合加密：公開(kāi)密鑰加密比共享密鑰加密過(guò)程更為復(fù)雜，所以處理速度要更慢。綜合2種的優(yōu)缺點(diǎn)，HTTPS采用混合加密，先通過(guò)公開(kāi)密鑰加密
方式進(jìn)行共享密鑰的交換，然后用交換后的共享密鑰進(jìn)行加密通信。
- 認(rèn)證
公開(kāi)密鑰加密，依然存在問(wèn)題，就是無(wú)法確保用戶拿到的公鑰是發(fā)布者實(shí)際發(fā)布的公鑰，于是有了第三方認(rèn)證機(jī)構(gòu)，可對(duì)發(fā)布的公鑰進(jìn)行數(shù)字認(rèn)證頒發(fā)數(shù)字認(rèn)證證書(shū)（EV SSL證書(shū)），但是向認(rèn)證機(jī)構(gòu)申請(qǐng)證書(shū)是需要費(fèi)用的
認(rèn)證過(guò)程：
HTTPS的安全通信過(guò)程：
- 客戶端通過(guò)發(fā)送Client Hello報(bào)文開(kāi)始SSL通信。報(bào)文中包含客戶端支持的SSL的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長(zhǎng)度等）。
- 服務(wù)器可進(jìn)行SSL通信時(shí)，會(huì)以Server Hello 報(bào)文作為應(yīng)答。和客戶端一樣，在報(bào)文中包含SSL版本以及加密組件。服務(wù)器的加密組件內(nèi)容是從接受到的客戶端加密組件內(nèi)篩選出來(lái)的。
- 之后服務(wù)器發(fā)送Certificate報(bào)文。報(bào)文中包含公開(kāi)密鑰證書(shū)。
- 最后服務(wù)器發(fā)送Server Hello Done報(bào)文通知客戶端，最初階段的SSL握手協(xié)商部分結(jié)束。
- SSL第一次握手結(jié)束之后，客戶端以Client Key Exchange報(bào)文作為回應(yīng)。報(bào)文中包含通信加密中使用的一種被稱為Pre-master secret的隨機(jī)密碼串。該報(bào)文已用步驟3中的公鑰進(jìn)行加密。
- 接著客戶端繼續(xù)發(fā)送Change Cipher Spec報(bào)文。該報(bào)文會(huì)提示服務(wù)器，在此報(bào)文之后的通信會(huì)采用Pre-master secret密鑰加密。
- 客戶端發(fā)送Finish報(bào)文。該報(bào)文包含連接至今全部報(bào)文的整體校驗(yàn)值。這次握手協(xié)商是否能夠成功，要以服務(wù)器是否能夠正確解密該報(bào)文作為判定標(biāo)準(zhǔn)。
- 服務(wù)器同樣發(fā)送Change Cipher Spec報(bào)文。
- 服務(wù)器同樣發(fā)送Finished報(bào)文。
- 服務(wù)器和客戶端的Finished報(bào)文交換完畢之后。SSL連接就算建立完成。當(dāng)然，通信會(huì)受到SSL的保護(hù)。從此處開(kāi)始進(jìn)行應(yīng)用層協(xié)議的通信，即發(fā)送HTTP請(qǐng)求。
- 應(yīng)用層協(xié)議通信，即發(fā)送HTTP響應(yīng)。
- 最后由客戶端斷開(kāi)連接。斷開(kāi)連接時(shí)，發(fā)送close_notify報(bào)文。上圖做了一些省略，這步之后再發(fā)送TCP FIN報(bào)文來(lái)關(guān)閉與TCP的通信。
- 完整性
在以上流程中，應(yīng)用層發(fā)送數(shù)據(jù)時(shí)會(huì)附加一種叫做MAC（Message Authentication Code）的報(bào)文摘要。MAC能夠查知報(bào)文是否遭到篡改，從而保護(hù)報(bào)文的完整性。
SSL和TLS：TLS是以SSL為原型開(kāi)發(fā)的協(xié)議，目前主流版本是SSL3.0和TLS1.0
HTTP的追加功能協(xié)議和HTTP2.0
SPDY
Google在2010年發(fā)布，旨在消除HTTP的瓶頸
- 一條連接上只可發(fā)送一個(gè)請(qǐng)求
- 請(qǐng)求只能從客戶端開(kāi)始。客戶端不可以接收除響應(yīng)以外的指令
- 請(qǐng)求/響應(yīng)首部未經(jīng)壓縮就發(fā)送。首部信息越多延遲越大
- 發(fā)送冗長(zhǎng)的首部。每次互相發(fā)送相同的首部造成的浪費(fèi)較多
- 可任意選擇數(shù)據(jù)壓縮格式。非強(qiáng)制壓縮發(fā)送
SPDY沒(méi)有完全改寫(xiě)HTTP協(xié)議，而是在TCP/IP的應(yīng)用層與傳輸層之間通過(guò)新加會(huì)話層的形式運(yùn)作，考慮到安全問(wèn)題，并規(guī)定通信中使用SSL。
SPDY設(shè)計(jì)
從而獲得了以下功能
- 多路復(fù)用流
通過(guò)單一的TCP連接，可以無(wú)限制處理多個(gè)HTTP請(qǐng)求。所有請(qǐng)求的處理都在一條TCP連接上完成，因此TCP的處理效率得到提高 - 賦予請(qǐng)求優(yōu)先級(jí)
SPDY不僅可以無(wú)限制地并發(fā)處理請(qǐng)求，還可以給請(qǐng)求逐個(gè)分配優(yōu)先級(jí)順序。這樣主要是為了在發(fā)送多個(gè)請(qǐng)求時(shí)，解決因帶寬低而導(dǎo)致響應(yīng)變慢的問(wèn)題 - 壓縮HTTP首部
壓縮HTTP請(qǐng)求和響應(yīng)的首部。這樣一來(lái)，通信產(chǎn)生的數(shù)據(jù)包流量和發(fā)送的字節(jié)數(shù)就更少了 - 推送功能
支持服務(wù)器主動(dòng)向客戶端推送數(shù)據(jù)的功能。這樣，服務(wù)器可直接發(fā)送數(shù)據(jù)，而不必等待客戶端的請(qǐng)求 - 服務(wù)器提示功能
服務(wù)器可以主動(dòng)提示客戶端請(qǐng)求所需的資源。由于在客戶端發(fā)現(xiàn)資源之前就可以獲知資源的存在，因此在資源已緩存等情況下，可以避免發(fā)送不必要的請(qǐng)求
全雙工通信的WebSocket
不同于SPDY，WebSocket是應(yīng)用層的另一種協(xié)議，替代了HTTP協(xié)議，具有以下特點(diǎn)：
- 推送功能
支持由服務(wù)器向客戶端推送數(shù)據(jù)的推送功能。這樣，服務(wù)器可直接發(fā)送數(shù)據(jù)，而不必等待客戶端的請(qǐng)求 - 減少通信量
只要建立起WebSocket連接，就希望一直保持連接狀態(tài)。和HTTP相比，不但每次連接時(shí)的總開(kāi)銷(xiāo)減少，而且由于WebSocket的首部信息很小，通信量也相應(yīng)減少了
為了實(shí)現(xiàn)WebSocket通信，在HTTP連接建立之后，需要完成一次”握手”（Handshaking）的步驟
- 握手·請(qǐng)求
為了實(shí)現(xiàn)WebSocket通信，需要用到HTTP的Upgrade首部字段，告知服務(wù)器通信協(xié)議發(fā)生改變
GET /chat HTTP/1.1
HOST：server.example.com
Upgrade：websocket
Connection：Upgrade
Sec-WebSocket-Key：dGH1IHNhbXBsZSBub25jZQ==
Origin：http://example.com
Sec-WebSocket-Protocol：chat，superchat
Sec-WebSocket-Version：13
Sec-WebSocket-Key字段記錄著握手過(guò)程中必不可少的鍵值。
Sec-WebSocket-Protocol中記錄使用的子協(xié)議。
子協(xié)議按WebSocket協(xié)議標(biāo)準(zhǔn)在連接分開(kāi)使用時(shí)，定義那些連接的名稱。
- 握手·響應(yīng)
對(duì)于之前的請(qǐng)求，返回狀態(tài)碼101 Switching Protocols的響應(yīng)。
HTTP/1.1 101 Switching Protocols
Upgrade：websocket
Connection：Upgrade
Sec-WebSocket-Accept：s3pPLMBiTxaQ9kYGzzhZRbk+XOo=
Sec-WebSocket-Protocol：chat
Sec-WebSocket-Accept的字段值由握手中的Sec-WebSocket-Key字段值生成
成功握手確立WebSocket連接之后，通信不再使用HTTP的數(shù)據(jù)幀，而采用WebSocket獨(dú)立的數(shù)據(jù)幀。
WebSocket通信流程：
HTTP2.0
協(xié)議基礎(chǔ)
- SPDY
- HTTP Speed+Mobility
由微軟公司起草，用于改善并提高移動(dòng)端通信時(shí)的通信速度和性能標(biāo)準(zhǔn)。它建立在Google公司提出的SPDY與WebSocket的基礎(chǔ)之上 - NetWork+Friendly HTTP Ugrade
主要是在移動(dòng)端通信時(shí)改善HTTP性能的標(biāo)準(zhǔn)
HTTP/2.0圍繞著主要的7項(xiàng)技術(shù)進(jìn)行討論，大都傾向于采用以下協(xié)議技術(shù)。
| 壓縮 | SPDY、Friendly |
| 多路復(fù)用 | SPDY |
| TLS義務(wù)化 | Speed+Mobility |
| 協(xié)商 | Speed+Mobility、Friendly |
| 客戶端拉拽（Client Pull）/服務(wù)器推送（Server Push） | Speed+Mobility |
| 流量控制 | SPDY |
| WebSocket | Speed+Mobility |
附
請(qǐng)求首部字段：
| 首部字段名 | 說(shuō)明 |
|---|---|
| Accept | 用戶代理可處理的媒體類(lèi)型 |
| 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)證信息 |
通用首部字段：
| 首部字段名 | 說(shuō)明 |
|---|---|
| Cache-Control | 控制緩存的行為 |
| Connection | 逐跳首部、連接的管理 |
| 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ò)誤通知 |
實(shí)體首部字段：
| 首部字段名 | 說(shuō)明 |
|---|---|
| Allow | 資源可支持的HTTP方法 |
| Content-Encoding | 實(shí)體主體適用的編碼方式 |
| Content-Language | 實(shí)體主體的自然語(yǔ)言 |
| Content-Length | 實(shí)體主體的大小（單位：字節(jié)） |
| Content-Location | 替代對(duì)應(yīng)資源的URI |
| Content-MD5 | 實(shí)體主體的報(bào)文摘要 |
| Content-Range | 實(shí)體主體的位置范圍 |
| Content-Type | 實(shí)體主體的媒體類(lèi)型 |
| Expires | 實(shí)體主體過(guò)期的日期時(shí)間 |
| Last-Modified | 資源的最后修改日期時(shí)間 |
