簡述HTTP
HyperText Transfer Protocol(HTTP)
HTTP是一個用於傳輸超媒體文檔（hypermedia documents）的應用層協議，其主要使用場景是網絡瀏覽器和網絡服務器之間進行通訊。html
1. 信息內容：Web Page
瀏覽器中顯示的頁面叫作網頁(Web Page)，其一般由以下兩部分構成：數據庫
-
HTML文件，描述對象和佈局等信息瀏覽器
-
對象，單個頁面中可能包含多個對象，這些對象能夠是圖片、文件、視頻等。對象可能以URL形式給出緩存
1.1 Hypertext Markup Language(HTML)
Hyper means over or above , 即"超"的意思。所謂超媒體、超文本，意指包括但不限於的意思。典型的超媒體文檔類型爲HTML。服務器
HTML是一種用於建立網頁的標準標記語言，和CSS、JavaScript一塊兒構建了萬維網（World Wide Web, WWW）的基礎。一般咱們能夠按以下形式來理解三者的關係：網絡
- HTML結構化元素：經過標記符號來標記要顯示的網頁中的各個基本元素如文字、圖片甚至音視頻等
- CSS呈現形式：定義不一樣呈現方式如字體、顏色、邊距等
- JavaScript負責界面功能：定義不一樣組件的行爲，造成交互
1.2 Uniform Resource Locator(URL)
Uniform Resource Identifier(URI) 是一個由字符組成的字符串，用於標示具體資源。URI表明的是一種象徵，象徵着網絡中每個資源都有惟一的標識符以便於訪問。URL是URI的一種常見形式，另外一種還有Uniform Resource Name(URN），二者區別是：併發
-
URN 相似於人名，標示一個資源名稱less
-
URL 相似於地址，標示如何找到該資源ide
以http://www.someSchool.edu/someDepartment/picture.gif爲例，URL一般由兩部分組成：高併發
- 存儲對象的主機名，
www.someSchool.edu - 主機中對象的具體路徑,
/someDepartment/picture.gif
2. 通訊流(flow)
HTTP使用TCP做爲傳輸協議，Server與Client交互過程當中會創建TCP鏈接，但並不會保存任何Client的狀態信息，所以HTTP也成爲無狀態(stateless)協議。
計算機相互之間進行通信一般有兩種方式：
-
請求響應（request-response）
向對端主機發送請求後需等待響應，這類通訊過程就是由一系列的單次通訊構成，典型應用如網頁瀏覽
-
單向（one-way ）
向對端主機發送消息後無需等待回覆，典型應用如郵件
2.1 TCP
如前文所述，HTTP通訊方式屬於請求響應類型，所以單次通訊流程一般爲：
- 創建TCP鏈接
- 發送HTTP消息（message, 應用層信息單元）
- 讀取服務器響應
- 關閉TCP鏈接
因爲HTTP爲無狀態協議（即每次通訊間無關聯），所以一般來說，HTTP每次通訊都是使用獨立TCP鏈接的。大部分網絡應用中，client和server會在必定時間內通訊屢次，從每次request和response是否經過同一TCP連接發送的角度來看，能夠劃分爲兩種：
- 短鏈接（non-persistent connections），每一個request/response對均使用單獨TCP連接
- 長鏈接（persistent connections），每一個request/response對均使用同一TCP連接
在HTTP 0.9和1.0中，鏈接均會在單詞請求響應後關閉，而TCP鏈接的創建和消亡須要通過三路握手、四路斷開，所以須要必定額外時間開銷。有鑑於此，從HTTP 1.1開始，全部鏈接默認爲長鏈接。更進一步地，若是沒必要每一個單次通訊都需等待響應後才能繼續下一個通訊，則能夠實現流水線技術，提升併發量。
2.2 Message格式
解決了鏈接的問題，剩下的就是消息格式了。前面提過，通訊的基礎是有效的轉換和逆轉換，轉換須要規則，規則就是協議。對於HTTP而言，存在兩種規則，分別爲request和response。
HTTP 1.1及以前版本中，message均是可讀性強字符。在HTTP 2中，這些消息將被先封裝至二進制結構frame中，並經過frame header進行其餘如複用等配置。
2.2.1 Request
先放一個示例：
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr
(data data data data data ...) 複製代碼
能夠看出，組成元素均爲可讀性強的ASCII字符，具體格式則可進一步細分爲以下結構:
2.2.2 Response
HTTP/1.1 200 OK
Connection: close
Date: Tue, 09 Aug 2011 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 09 Aug 2011 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html
(data data data data data ...) 複製代碼
3. 字段定義
3.1 Request methods
HTTP請求中定義了method字段以標明但願在URL上執行的操做，而該資源將如何呈現、是否已存在或將被動態建立，均基於服務器的實現自己。主流應用中，一般會選擇實現以下方法：
-
GET
請求所需資源，該請求除獲取數據外不該產生其餘效果
-
HEAD
功能與GET至關，區別在於響應中不包括具體數據，即不含response body。能夠理解爲GET的輕量級，只查看元信息而不實際獲取。
-
POST
將請求body中內容推送至服務器，或是存儲在URI指定的資源下，或是其餘實現形式
-
PUT
將請求body中內容存儲至服務器中URI指定位置，如該URI已有資源，將被修改；如無資源，則將建立
-
DELETE
刪除服務器中指定資源
-
TRACE
告知服務器回傳所收請求，以便客戶端確認鏈路中是否發生修改行爲
-
OPTIONS
返回服務器在指定URL上所支持的方法，如URL爲'*'，則查詢對象爲服務器自己
-
CONNECT
告知服務器去返回指定URL，並將其獲取到的Response轉發回請求客戶端，至關於代理，網頁開發中並不經常使用，僅預留作管理
-
PATCH
對資源進行局部修改操做
| HTTP Method | RFC | Request Has Body | Response Has Body | Safe | Idempotent | Cacheable |
|---|---|---|---|---|---|---|
| GET | RFC 7231 | Optional | Yes | Yes | Yes | Yes |
| HEAD | RFC 7231 | No | No | Yes | Yes | Yes |
| POST | RFC 7231 | Yes | Yes | No | No | Yes |
| PUT | RFC 7231 | Yes | Yes | No | Yes | No |
| DELETE | RFC 7231 | No | Yes | No | Yes | No |
| CONNECT | RFC 7231 | Yes | Yes | No | No | No |
| OPTIONS | RFC 7231 | Optional | Yes | Yes | Yes | No |
| TRACE | RFC 7231 | No | Yes | Yes | Yes | No |
| PATCH | RFC 5789 | Yes | Yes | No | No | No |
3.2 Status codes
自HTTP 1.0開始，響應以狀態行開始，而狀態行中進一步包含了一個狀態碼（status code）及對應的文字說明。狀態碼分爲五類，爲了便於管理和更加直觀表示，第一個數字用於標示響應的類型。
-
1xx Informational responses
標明請求已被接收並解析，經常使用於服務器需較長時間處理請求時告知客戶端正在處理，且客戶端需等待最終的回覆。
- 100 Continue
- 101 Switching Protocols
- 102 Processing
- 103 Early Hints
-
2xx Success
標明請求已被接收、解析且已生效。
- 200 OK
- 201 Created
- 202 Accepted
- 203 Non-Autoritative Information (Since HTTP/1.1)
- 204 No Content
- 205 Reset Content
- 206 Partial Content
- 207 Multi-Status
- 208 Already Reported
- 226 IM Used
-
3xx Redirection
標明客戶端須要採起額外措施來完成整個請求，一般用於URL重定向。
- 300 Multiple Choices
- 301 Moved Permanently
- 302 Found
- 303 See Other
- 304 Not Modified
- 305 Use Proxy
- 306 Switch Proxy
- 307 Temporary Redirect
- 308 Permanent Redirect
-
4xx Client errors
標明可能由客戶端引起的錯誤，除HEAD方法外，其他狀況中這類Response將會在Body中包含錯誤狀況的詳細說明，以及是臨時或永久情況。
- 400 Bad Request
- 401 Unauthorized
- 402 Payment Required
- 403 Forbidden
- 404 Not Found
- 405 Method Not Allowed
- 406 Not Acceptable
- 407 Proxy Authentication
- 408 Request Timeout
- 409 Conflict
- 410 Gone
- 411 Length Required
- 412 Precondition Failed
- 413 Payload Too Large
- 414 URI Too Long
- 415 Unsupported Media Type
- 416 Range Not Satisfiable
- 417 Expectation Failed
- 418 I'm a teapot
- 421 Misdirected Request
- 422 Unprocessable Entity
- 423 Locked
- 424 Failed Dependency
- 426 Upgrade Required
- 428 Precondition Required
- 429 Too Many Requests
- 431 Request Header Fields Too Large
- 451 Unavailable For Legal Reasons
-
5xx Server error
標明可能由服務器自己引起的錯誤。
- 500 Internal Server Error
- 501 Not Implemented
- 502 Bad Gateway
- 503 Service Unavailable
- 504 Gateway Timeout
- 505 HTTP Version Not Supported
- 506 Variant Also Negotiates
- 507 Insufficient Storage
- 508 Loop Detected
- 510 Not Extended
- 511 Network Authentication Required
4. 高級控制
4.1 Cache
所謂緩存（Cache），就是指相比服務器自己，在更靠近客戶端的鏈路中設置一個額外的服務器副本。簡單來看，緩存技術有兩大優點：
- 經過分流，下降了服務器自己負載，提升總體併發
- 縮短鏈路帶寬、長度，下降傳輸引起的延時
所以，緩存技術本質上是下降了單次請求的響應時長，從而提高網絡體驗。
The Conditional GET
然而大部分時候，副本帶來了高可靠性，也帶來了同步問題。實際服務器中內容可能隨時間推移會發生修改，此時副本服務器中的數據就是相對過時了的，那麼必要的同步就勢在必行。
什麼是必要的同步，就是隻有比較數據後發現有更新才進行同步，不然只是無謂的拷貝，佔用帶寬。判斷數據是否發生更新能夠從數據自己出發，也能夠只從數據標籤即元數據出發，只要記錄的數據最後更新時間一致，就能夠斷定數據沒必要更新，不然，就有更新的必要了。HTTP中這種機制叫作conditional GET，而更新的時間，就是經過Request中的If-modified-since字段給出。
GET /fruit/kiwi.gif HTTP/1.1
Host: www.exotiquecuisine.com
If-modified-since: Web, 7 Sep 2011 09:23:24
複製代碼
4.2 Session and Cookie
前面提到，HTTP是無狀態協議，就是說HTTP服務器不會在多個請求之間維護用戶信息。但實際應用中，又每每存在這種剛性需求，典型的如購物、新聞瀏覽等。爲了實現賓至如歸的錯覺，增長用戶的黏度，HTTP採用了會話（Session）和Cookie技術。
會話，至關於一次對話。一次對話確定包括至少一次交互，一樣一次會話也至少包括一個請求響應對。所以會話就是由一系列的請求響應對組成。要想在一系列動做中保持某種狀態，比較通用的方法就是在動做以外，維護一個變量或者文件，而Cookie的組成元素中，文件就是重要的一環。
Cookie
Cookie技術由四大組件組成：
- Response中Cookie header line用於返回服務器爲用戶所分配的Cookie ID
- Request中Cookie header line用於告知服務器請求來自於哪個爲用戶的Cookie ID
- 用戶客戶端上本地存儲維護的Cookie文件，記錄用戶行爲
- 網站自己的後臺數據庫，保存了用戶與Cookie ID間映射關係等數據
Cookie的具體使用過程如上圖所示，總的來說，就是經過獨立第三發信息（Cookie ID、數據庫、Cookie文件）來記錄用戶信息，並在會話中相關請求響應對中標記，保持服務器與客戶端間的同步，實現狀態維護。
5. 小結
本篇概述了HTTP的大部份內容，若有興趣進一步學習研究，可參考相關Spec.
-
每一个你不满意的现在，都有一个你没有努力的曾经。