HTTP協議及HTTPS

pre:先發一些參考文檔：

HTTP/1.1 RFC2616中英文版

http長鏈接短鏈接及輪詢

1、HTTP協議簡介

HTTP(HyperText Transfer Protocol，超文本傳輸協議)是基於可靠傳輸的應用層協議，在互聯網上應用很是普遍。絕大部分網絡請求都是基於HTTP，乃至當前應用普遍的音視頻傳輸，也有很大一部分是基於HTTP。

• 注：（對於此處的可靠傳輸，是因爲HTTP假定其下層協議提供的數據傳輸可靠，一般在網絡應用中是基於TCP協議，但實際上HTTP並未指定必須基於TCP傳輸）
• 注：（對於此處的應用層協議，是因爲HTTP只規定客戶端和服務器之間的通訊方式，默認使用80端口，但並未規定具體的鏈接方式，也未指定數據包如何傳輸。因此，所謂的「HTTP鏈接」都是通俗而又錯誤的說法，由於HTTP未指定如何創建鏈接，如何斷開鏈接。對於一個應用層協議來講，咱們應該關注的是HTTP請求及HTTP響應，鏈接是傳輸層應該關注的事情。）

2、HTTP協議演變

• 前身：1960年Ted Nelson構思的經過計算機處理文本信息的方法，即hypertext。
• HTTP/0.9於1990年正式發佈，用於網絡上原始數據傳輸。
• HTTP/1.0於1996年在RFC 1945中提出，容許消息以類MIME格式傳送，但對分層代理、緩存、持久鏈接、鏈接複用、虛擬主機需求等無規定。
• HTTP/1.1於1999年在RFC 2616中提出，主要是對HTTP/1.0中的一些問題進行了優化。好比默認使用持久鏈接及鏈接複用，緩存處理，帶寬優化及網絡鏈接使用，錯誤通知，消息發送，互聯網IP維護，安全性等。
• HTTP/2於2015年在RFC 7540中提出，是基於Google提出的SPDY協議進行了進一步開發和完善。主流瀏覽器支持良好，主要在減小網絡延遲方面擁有更好的特性。在各個網絡應用場景中，（雖然HTTP/2未強制要求數據加密），但各個客戶端均採用只支持經過TLS加密的方式，致使HTTP/2實際上基於HTTPS(Hypertext Transfer Protocol Secure, HTTP over TLS)成爲一個業內事實標準。

當前使用狀況：聽說，HTTP/1.0仍舊在一些古老的網絡設備（尤爲是代理服務器）上使用；HTTP/1.1的使用在互聯網應用中佔據了大部分，在服務器上的部署尤其普遍；HTTP/2的使用主要是在網頁請求上，有統計數據稱截至2018年大約40%~50%的網站使用了HTTP/2。

3、HTTP請求及響應

3.1 請求REQUEST

圖1、HTTP請求消息結構

• 第一部分：請求行，用來講明請求方法類型、要訪問的資源及所使用的HTTP版本【必須】；
• 第二部分：請求頭部，緊接着請求行以後的部分，用來記錄服務器所需信息【必須】；
• 第三部分：空行，請求頭部後面的空行【必須】；
• 第四部分：主體，自定義【非必須】

HTTP/1.1規定了8種請求方法（其中GET/HEAD兩種爲服務器必須支持的），以下所示。「請求request」是指由客戶端向服務器發起的一種通訊方式。此外，服務器能夠擴展自定義方法：

方法名稱	註釋
GET	向服務器上指定的資源發出「顯示」請求，只用於讀取數據。服務器會返回HEADER和BODY【必須實現】
HEAD	向服務器上指定資源發出「顯示」請求，僅用於讀取。服務器只返回元數據，不包括資源的本文部分【必須實現】
POST	向指定資源提交數據，請求服務器進行處理（例如提交表單或者上傳文件）。數據被包含在請求本文中。這個請求可能會建立新的資源或修改現有資源，或兩者皆有
PUT	向指定資源位置上傳其最新內容
DELETE	請求服務器刪除Request-URI所標識的資源
TRACE	回顯服務器收到的請求，主要用於測試或診斷
OPTIONS	使服務器傳回該資源所支持的全部HTTP請求方法。用'*'來代替資源名稱，向Web服務器發送OPTIONS請求，能夠測試服務器功能是否正常運做
CONNECT	HTTP/1.1協議中預留給可以將鏈接改成管道方式的代理服務器。一般用於SSL加密服務器的連接（經由非加密的HTTP代理服務器）

3.2 響應RESPONSE

圖2、HTTP響應消息格式

• 第一部分：狀態行，包括HTTP版本號，狀態碼，狀態消息【必須】；
• 第二部分：響應報頭，用來講明客戶端解析響應時要使用的一些信息【必須】；
• 第三部分：空行，消息報頭後的空行【必須】；
• 第四部分：響應實體，服務器返回的消息主體【非必須】

3.3 狀態碼

全部的狀態碼都是三位數字，有對應的狀態消息。除了RFC 2616中規定的狀態消息，開發人員仍能夠自定義某個狀態碼對應的消息內容，不過服務端和客戶端須要約定好。

• 1xx消息——請求已被服務器接收，繼續處理
• 2xx成功——請求已成功被服務器接收、理解、並接受
• 3xx重定向——須要後續操做才能完成這一請求
• 4xx請求錯誤——請求含有詞法錯誤或者沒法被執行
• 5xx服務器錯誤——服務器在處理某個正確請求時發生錯誤

具體狀態碼信息——紅色和橙色爲錯誤狀態碼，加粗爲經常使用狀態碼

狀態碼	狀態消息(緣由)	備註
100	Continue	繼續
101	Switching Protocols	協議切換，服務端建議客戶端更換協議
102	Processing	處理中，防止客戶端超時
200	OK	成功返回
201	Created	當前請求已經被實現且有一個新資源已經根據請求須要被創立
202	Accepted	服務器已接受請求，但還沒有處理。最終該請求可能會也可能不會被執行，而且可能在處理髮生時被禁止
203	Non-Authoritative Information	未認證信息，服務器是一個轉換代理服務器，以200 OK狀態碼爲起源，但迴應了原始響應的修改版本
204	No Content	服務器成功處理請求，沒有返回任何內容
205	Reset Content	服務器成功處理了請求，但沒有返回任何內容。與204響應不一樣，此響應要求請求者重置文檔視圖
206	Partial Content	服務器已經成功處理了部分GET請求。用於斷點續傳之類的
207	Multi-Status	表明以後的消息體將是一個XML消息，而且可能依照以前子請求數量的不一樣，包含一系列獨立的響應代碼
208	Already Reported	DAV綁定的成員已經在（多狀態）響應以前的部分被列舉，且未被再次包含
226	IM Used	服務器已經知足了對資源的請求，對實體請求的一個或多個實體操做的結果表示
300	Multiple Choices	被請求的資源在服務器上有一系列可供選擇的資源，除非請求爲HEAD請求，不然響應實體中應包括資源特性及地址的列表。服務器亦能夠指定首選的資源。響應可緩存
301	Moved Permanently	資源被永久移動到新位置。除非是HEAD請求，不然響應實體中應包含新URI的超連接及簡短說明。若是不是GET/HEAD請求，瀏覽器應禁止自動重定向。響應可緩存
302	Found	臨時重定向(本次)。除非是HEAD請求，不然響應實體內應包含新的URI及簡短說明。若是不是GET/HEAD請求，瀏覽器應禁止自動重定向。響應通常不可緩存
303	See Other	對應請求的響應能夠重定向到另外一個URI，相似302，主要爲了容許由腳本激活的POST請求輸出重定向到新資源。303響應禁止被緩存
304	Not Modified	表示資源在由請求頭中的If-Modified-Since或If-None-Match參數指定的這一版本以後，不曾被修改
305	Use Proxy	被請求的資源必須經過指定的代理才能被訪問
306	Switch Proxy	目前新規範不使用該狀態碼
307	Temporary Redirect	在這種狀況下，本次請求應該用另外一個URI重複，但後續的請求應仍使用原始的URI。與302相反，當從新發出原始請求時，不容許更改請求方法
308	Permanent Redirect	本次請求和後續請求都應用另外一個URI重複或替換
400	Bad Request	客戶端錯誤致使錯誤的請求
401	Unauthorized	用戶的請求未經過認證（所請求資源需認證）
402	Payment Required	通常不用。預留用來讓請求人員付費的
403	Forbidden	服務器已理解請求但拒絕執行，能夠在響應實體中描述拒絕緣由。不建議重複該請求
404	Not Found	請求失敗，或所請求資源未在服務器上發現，但容許後續請求
405	Method Not Allowed	請求方法與所對應的資源不匹配。好比用GET請求某個需POST的表單資源
406	Not Acceptable	請求的資源的內容特性沒法知足請求頭中的條件，於是沒法生成響應實體，該請求不可接受
407	Proxy Authentication Required	客戶端需先在代理服務器上進行身份驗證
408	Request Timeout	請求超時，超過服務器等待時間
409	Conflict	存在衝突沒法處理該請求，好比多個同步更新的編輯請求
410	Gone	通常不用，表示該資源再也不可用
411	Length Required	客戶端請求未標明Content-Length
412	Precondition Failed	服務器在驗證在請求的頭字段中給出先決條件時，沒能知足其中的一個或多個
413	Request Entity Too Large	因爲請求提交的實體數據大小超服務器預期，因此拒絕響應。若允許客戶端重試，響應中應攜帶Retry-After
414	Request-URI Too Long	因爲請求的URI長度超出服務器解釋長度而拒絕響應
415	Unsupported Media Type	請求中提交的某資源格式，不符合服務器指定的格式
416	Requested Range Not Satisfiable	服務器未涵蓋客戶端請求所要求的資源範圍
417	Expectation Failed	請求中期待的資源沒法被服務器知足
420	Enhance Your Caim	Twitter Search與Trends API在客戶端被限速的狀況下返回
421	Misdirected Request	服務器沒法產生響應（例如由於鏈接重用）
422	Unprocessable Entity	請求格式正確但有語義錯誤
423	Locked	當前資源被鎖定
424	Failed Dependency	因爲以前某個請求錯誤，致使當前請求失敗
425	Unordered Collection	目前未使用的狀態碼
426	Upgrade Required	客戶端應當切換到TLS/1.0，並在HTTP/1.1 Upgrade header中給出
428	Precondition Required	原服務器要求該請求知足必定條件，防止「未更新」，即客戶端所操做資源與第三方改寫發生衝突
429	Too Many Requests	客戶端在某段時間內發送請求過多
431	Request Header Fields Too Large	請求頭部中一個或多個字段過大
444	No Response	Nginx上HTTP擴展，服務端主動關閉鏈接
450	Blocked by Windows Parental Controls	Microsoft擴展，用於信息和測試
451	Unavailable For Legal Reasons	該訪問因法律的要求而被拒絕
494	Request Header Too Large	431碼提出前用於Nginx服務器
500	Internal Server Error	服務器發生不可預期的錯誤
501	Not Implemented	服務器不支持當前請求所須要的某個功能
502	Bad Gateway	做爲網關或者代理工做的服務器嘗試執行請求時，從上游服務器接收到無效的響應
503	Server Unavailable	服務器臨時維護或過載致使沒法處理請求，暫時的，響應中應包含Retry-After
504	Gateway Timeout	做爲網關或者代理工做的服務器嘗試執行請求時，未能及時從上游服務器或輔助服務器收到響應
505	HTTP Version Not Supported	服務器不支持當前請求中的HTTP版本
506	Variant Also Negotiates	服務器存在內部配置錯誤
507	Insufficient Storage	服務器沒法存儲完成請求所必須的內容。這個情況被認爲是臨時的
508	Loop Detected	服務器在處理請求時陷入死循環
510	Not Extended	服務器未支持獲取該請求資源時所需策略
511	Network Authentication Required	客戶端須要進行身份驗證才能得到網絡訪問權限，旨在限制用戶羣訪問特定網絡

4、HTTP請求流程解析

• 客戶端與服務器創建TCP鏈接
• 客戶端發送HTTP請求
• 服務器接收請求，定位資源，構建響應，經過TCP通道返回響應
• 按需關閉或保持TCP鏈接（keep-alive則不會此時關閉）
• 客戶端解析請求

5、HTTP中的緩存

單獨把緩存機制做爲一個模塊列出來，是由於在HTTP請求和響應中，使用緩存技術實在太常見&&重要了！！HTTP中的緩存主要爲了(在合理場景下）儘量減小發送請求和發送完整的響應，這對於減輕服務器的負載以及節省客戶端帶寬有很重要的做用。

HTTP中緩存機制須要下降語義透明性要求。但這要求在整個請求——緩存——響應的結構中，客戶端始終可以發現任何語義透明性的潛在放鬆規則。（總之就是，無論下降語義透明性是由客戶端/緩存/服務器中任意一方執行，最終客戶端都知道。）設計HTTP緩存機制中各端的時候，必須嚴格遵照。

• 緩存基本機制——用於響應的緩存必須是最新的，等價於當前服務器應該給出的響應。若緩存模塊此時沒法與服務器通訊，除非已緩存的響應肯定是請求所需，不然應返回一個錯誤或警告；若緩存模塊從服務器接收到某個已過時的響應，應直接轉發給客戶端（不添加警告，但也不移除已有警告），且不會由於響應過時而向服務器重複該請求。警告在某個響應既不是最新獲取，也不在保鮮期內時必須添加。Cache-control字段是用於服務器或客戶端給緩存模塊顯式的指令。在緩存機制中，客戶端能夠顯式要求不使用緩存，但是設置某個響應的最大保鮮期，能夠顯式要求緩存模塊定時驗證某個請求，等等。
• 緩存過時——緩存機制是指在保鮮期內由緩存模塊代替源服務器向客戶端返回某個請求的響應。服務器能夠指定某個請求的顯式過時時間，能夠強制緩存模塊老是不斷驗證該緩存項，但只做用於服務器緩存模塊而非用戶代理。除了顯式的過時時間，還能夠用啓發式過時時間算法。
• 驗證模型——是指緩存模塊利用超過保鮮期的緩存項做爲響應以前，應利用緩存驗證器向源服務器或擁有最新響應的中間緩存對此內容進行驗證。驗證時無需重傳整個響應內容。
• 構建響應——有時候緩存模塊是簡單轉發源服務器的響應，但有時候須要根據必定規則構建響應。
• 標記緩存無效——若是源服務器上某資源已變動，須要使用「invalidate an entity」來讓緩存刪除某個實體，或標記爲無效
• 強制寫經過——除了GET/HEAD外，全部對源服務器資源的操做都須要先通過緩存模塊對源服務器的寫操做，不過此時緩存模塊能夠先發一個100響應。
• 緩存替換——接收到服務端響應的一個新的可緩存資源，除非其Date域值比當前緩存的更舊，不然應替換緩存內容。