本系列翻譯自：https://developer.mozilla.org/en-US/docs/Web/HTTP
注：翻譯水平有限，翻譯水平有限，如果有不理解或者紕漏之處，還請參考火狐原文 ：https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview；
HTTP 是一種允許用戶獲取資源（比如HTML文檔）的協(xié)議，它是任何web端（基于client-server模式）數(shù)據(jù)交換基礎，這意味著請求由接收者發(fā)起，通常是Web瀏覽器；一個完整的文檔是由許多子元素構成的，比如文本，layout布局，圖片，視頻，腳本等。
客戶端和服務器通過交換單個消息（而不是數(shù)據(jù)流）進行通信?？蛻魴C發(fā)送消息，通常是Web瀏覽器來發(fā)送，這稱為請求，服務器發(fā)送響應的消息稱為響應。
HTTP誕生于1990s，它具有可拓展性，是應用層協(xié)議并且使用 TCP或者 TLS-encrypted建立TCP連接，由于它的可拓展性，它不僅用于獲取超文本文檔，還可以獲取圖像和視頻，或?qū)?nèi)容發(fā)布到服務器，比如HTML表單，HTTP還可以按需更新Web頁面。
HTTP的基本構成
HTTP是client-server協(xié)議：請求由一個代理發(fā)送，比如web瀏覽器，但也可以是其他的，比如一個可以搜索的機器人，類似爬蟲。每個單獨的請求都會被發(fā)送到服務端，然后服務端處理，返回一個結果，這個就是響應。在這個請求和響應之間，有許多實體，統(tǒng)稱為代理，它執(zhí)行不同的操作并充當網(wǎng)關或緩存，比如：
在現(xiàn)實中，有許許多多的電腦在處理基于瀏覽器和服務端直接的請求：許多路由器和貓，感謝網(wǎng)絡七層協(xié)議，HTTP協(xié)議處于頂層的應用層，其他協(xié)議層被封裝在了HTTP協(xié)議之下，盡管對于診斷網(wǎng)絡故障是有積極作用的，但是我們這里并不會展開介紹。
Client: the user-agent 客戶端
user-agent，即客戶端時刻代表著用戶的利益，這個角色大多數(shù)情況下由web瀏覽器擔任；還有一些是工程師的調(diào)試工具，用于開發(fā)web應用。
瀏覽器永遠是請求的發(fā)起方，它不會是服務端（盡管多年來增加了一些機制來模擬服務器發(fā)起的消息），為了展現(xiàn)一個網(wǎng)頁，瀏覽器發(fā)送一個最原始的請求來獲取HTML文檔，然后對其進行解析，當然還會繼續(xù)發(fā)送額外的請求來完善網(wǎng)頁，如css，腳本等靜態(tài)資源，最終呈現(xiàn)出一個完整的網(wǎng)頁。一個web頁面是一個超文本文檔，這意味著里面可能會包含其他鏈接，這些鏈接可能會導致重定向或者頁面跳轉(zhuǎn)。
The Web server 服務端
與客戶端對應的一端是服務端，服務端是為客戶端而服務的，比如響應一個文檔。事實上服務端只有一個，它是一些子服務的集合，利用負載均衡等策略形成一個系統(tǒng)。一個服務不一定只是一個主機，它可能是由若干個服務器組成的，通過HTTP/1.1和請求頭交流，甚至共用同一個ip地址。
Proxies 代理
在瀏覽器和服務端之間有大量的主機中繼HTTP消息，由于web協(xié)議的結構，這些代理會對性能產(chǎn)生重大影響，它們發(fā)揮著許多作用：
- 緩存
- 過濾
- 負載均衡
- 日志
HTTP協(xié)議的基本面
1.HTTP 是簡單的
盡管HTTP/2中引入了跟多的復雜的內(nèi)容，但是HTTP協(xié)議是易于理解的和可讀的；
2.HTTP 是易拓展的
HTTP header頭在HTTP/1.0中已經(jīng)引入，請求頭使得這個協(xié)議更加容易拓展，客戶端和服務端之間如果添加一個新功能甚至可以通過header頭引入。
3.HTTP 是無狀態(tài)的，但不是非會話
對于兩個被執(zhí)行成功的請求來說，它們直接是沒有任何聯(lián)系的；那么問題就來了，假如一個用戶正嘗試與某個頁面交互，比如使用電子商務網(wǎng)站的購物車，由于HTTP本身是無狀態(tài)的，所以HTTP cookie就登場了，cookie可以作為有狀態(tài)的會話，配合header頭可以達到這一目的，使用session使得每個http請求可以共享同一個上下文或者狀態(tài)類型的數(shù)據(jù)。
4.HTTP 和連接
請求連接在傳輸層進行控制，所以根本超出了HTTP協(xié)議的范圍。HTTP協(xié)議不要求傳輸層作為連接基礎是必須的，它是可靠的即可，或者不會丟失消息也行。作為最常用的兩種傳輸層協(xié)議，TCP是可靠的，而UDP則不是。HTTP依賴于TCP標準，這是基于連接的，盡管并不總是需要連接；HTTP/1.0為每個請求/響應都建立了一個連接，但有兩個缺陷：打開一個連接需要三次握手所以導致變慢，但是當多個消息被發(fā)送時效率將會更高，并且熱連接比冷連接更高效。
為了解決這些缺陷，HTTP/1.1引入了流水線并且實現(xiàn)了持久連接：底層的TCP連接可以使用Connection header頭來控制，HTTP/2則更進一步，可以在單個連接上重復發(fā)送消息，使得傳輸效率變得更高。讓傳輸層協(xié)議更加適用于HTTP協(xié)議的實驗仍然在推進中，比如谷歌的QUIC計劃，它將使得UPD在傳輸層變得更加可靠。
HTTP可以控制什么
隨著時間的推移，HTTP的這種可擴展性允許Web的更多控制。緩存或者鑒權被納入到了HTTP中；
下面是HTTP可控制的范圍：
Cache
如何緩存是可以被HTTP協(xié)議所控制的。服務端可以指定代理或者客戶端緩存什么，以及緩存多久，客戶端則可以指定代理忽略哪些緩存。
Relaxing the origin constraint
為了防止隱私泄露，web瀏覽器有很嚴格的隔離機制，盡管這樣的約束對于服務端來說是一種負擔，但是HTTP請求頭則可以在服務端放開這種嚴格的約束，使得文檔資源可以從不同的域名下拼湊起來。
Authentication
一些網(wǎng)頁只能讓指定的用戶查看，所以HTTP提供了基礎認證，或者使用WWW-Authenticate
，或者是類似的請求頭，或者使用特殊的HTTP cookies；
Proxy and tunneling
服務端或客戶端經(jīng)常被保護在內(nèi)部網(wǎng)絡中并且隱藏真實的ip地址；HTTP請求往往是通過代理越過這層障礙從而得到訪問。不是所有的代理都是HTTP代理，如，SOCKS協(xié)議往往在較低的級別工作，或者如FTP協(xié)議，可以直接處理這些代理。
Sessions
使用HTTP cookies可以讓你你將請求和服務端聯(lián)系起來，這需要創(chuàng)建session，即會話，盡管HTTP是一個無狀態(tài)的請求；
HTTP flow（工作流程）
當客戶端想訪問服務端時，無論是終極服務端還是中間代理，都必須經(jīng)過以下幾步：
- 打開TCP連接：TCP連接用于發(fā)送一個或幾個請求并且收取響應?？蛻舳丝赡軙蜷_一個新連接，則會重復使用已存在的連接或者重新打開新連接。
-
- 發(fā)送HTTP消息請求：HTTP 消息是可閱讀的；在HTTP/2中，這些易讀的消息被封裝起來了，使得它們不可以被直接閱讀，但是可讀性（
human-readable）原則是沒有改變的。如下：
GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: fr - 發(fā)送HTTP消息請求：HTTP 消息是可閱讀的；在HTTP/2中，這些易讀的消息被封裝起來了，使得它們不可以被直接閱讀，但是可讀性（
-
3.讀取服務端的響應消息
HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html
<!DOCTYPE html... (here comes the 29769 bytes of the requested web page) - 關閉或者重用連接
如果HTTP工作流被激活，多個請求的響應不需要是有序的，即不需要等待第一個請求的響應，第二請求才得到響應；HTTP工作流機制已經(jīng)被證實是無法被應用在已存在的舊軟件中，并且HTTP/2將會舍棄這種管道機制，使得請求更加穩(wěn)?。?/p>
HTTP 消息
HTTP/1.1 和更早的HTTP 消息是可閱讀的，而在HTTP/2中，這些消息已經(jīng)納入到了二進制結構中，使得消息頭被壓縮或者復用。對于請求和響應都有其自己的消息格式：
Requests
請求頭包含這些元素：
Method： 請求方法（HTTP method），通常有這么幾種類型：
GET，POST，OPTIONS，HEAD，定義了客戶端想進行哪種操作，假如用戶想要獲取信息則使用GET請求，假如用戶想要提交表單信息，則使用POST請求；Path：請求路徑，反映了資源，請求端口，域名信息；
version of the HTTP protocol：請求版本；
Headers：可選的請求頭傳達了一些發(fā)送給服務端的信息；
或一個消息體，對于像POST這樣的方法，類似于響應中包含資源的方法。
Responses
請求頭包含一下元素：
- version of the HTTP protocol：協(xié)議版本
- Status Code：響應碼，表示請求是否成功處理等。
- Status Message：響應碼說明
- HTTP headers，類似于請求頭
Conclusion
HTTP是一個可拓展的協(xié)議，使用客戶端-服務端模式，結合了請求頭。雖然HTTP / 2增加了一些復雜性，通過在幀中嵌入HTTP消息來提高性能，但是HTTP / 1的基本結構保持不變。會話流仍然很簡單，允許它進行調(diào)查，并通過一個簡單的HTTP消息監(jiān)視器（ HTTP message monitor）進行調(diào)試。
