HTTP是一種能夠獲取如HTML這樣網(wǎng)絡(luò)資源的協(xié)議碉就。它是Web上數(shù)據(jù)交換的基礎(chǔ)平绩，是一種client-server協(xié)議，也就是說請求通常是由像瀏覽器這樣的接受方發(fā)起的考传。一個完整的web文檔是由不同的子文檔重新組建而成的，像是文本前联、布局描述、圖片娶眷、視頻似嗤、腳本等等。
基于HTTP的組件系統(tǒng)
HTTP是一個client-server協(xié)議：請求通過一個實體被發(fā)出届宠，實體也就是用戶代理烁落。大多數(shù)情況下，這個用戶代理都是指瀏覽器豌注，當然它也可能是任何東西伤塌，比如一個爬取網(wǎng)頁來生成和維護搜索引擎索引的機器。
每一個發(fā)送到服務(wù)器的請求轧铁，都會被服務(wù)器處理并且返回一個消息每聪，也就是response。在client與server之間齿风，還有許許多多的被稱為proxies的實體药薯，他們的作用與表現(xiàn)各不相同，比如有些是網(wǎng)關(guān)救斑，還有些是caches等童本。
實際上，在一個瀏覽器和處理請求的服務(wù)器之間脸候，還有計算機穷娱、路由器、調(diào)制解調(diào)器等等許多實體运沦。由于Web的層次設(shè)計泵额，那些在網(wǎng)絡(luò)層和傳輸層都不可見了。HTTP是在最上層應(yīng)用層中的携添，雖然下面的層次對分析網(wǎng)絡(luò)問題非常重要梯刚，但是對HTTP的描述來說，這些大多數(shù)都是不相關(guān)的薪寓。
客戶端：user-agent
嚴格意義來說亡资，user-agent就是任何能夠為用戶發(fā)起行為的工具。但實際上向叉，這個角色通常都是由瀏覽器來扮演锥腻。
對于發(fā)起請求來說，瀏覽器總是作為發(fā)起一個請求的實體母谎，而永遠不是服務(wù)器（雖然一些機制已經(jīng)能夠模擬服務(wù)器發(fā)起請求的消息了）瘦黑。
要渲染出一個網(wǎng)頁，瀏覽器首先要發(fā)送第一個請求來獲取這個頁面的HTML文檔，再解析它并根據(jù)文檔中的資源信息發(fā)送其他的請求來獲取腳本信息幸斥，或者CSS來進行頁面布局渲染匹摇，還有一些其它的頁面資源（如圖片和視頻等）。然后甲葬，它把這些資源結(jié)合到一起廊勃，展現(xiàn)出來一個完整的文檔，也就是網(wǎng)頁经窖。打開一個網(wǎng)頁后坡垫，瀏覽器還可以根據(jù)腳本內(nèi)容來獲取更多的資源來更新網(wǎng)頁。
一個網(wǎng)頁就是一個超文本文檔画侣，也就是說有一部分顯示的文本可能是鏈接冰悠，啟動它（通常是鼠標的點擊）就可以獲取一個新的網(wǎng)頁。網(wǎng)頁使得用戶可以控制它的user-agent來導航Web配乱。瀏覽器來負責翻譯HTTP請求的命令溉卓，并翻譯HTTP的返回消息讓用戶能明白返回消息的內(nèi)容。
Web服務(wù)端
在上述通信過程的另一端搬泥，就是一個Web Server來服務(wù)并提供客戶端請求的文檔的诵。Server只是虛擬意義上：它可以是許多共同分擔負載（負載平衡）的一組服務(wù)器組成的計算機群，也可以是一種復雜的軟件佑钾，通過向其他計算機發(fā)起請求來獲取部分或全部資源的軟件西疤。
Server不再只是一個單獨的機器，它可以是在同一個機器上裝載的許多服務(wù)之一休溶。在HTTP/1.1和Host頭部中代赁，它們甚至可以共享同一個IP地址。
Proxies
在瀏覽器和服務(wù)器之間兽掰，有許多計算機和其他設(shè)備轉(zhuǎn)發(fā)了HTTP的消息芭碍。因為Web棧層次結(jié)構(gòu)的原因，它們大多數(shù)都出現(xiàn)在傳輸層孽尽、網(wǎng)絡(luò)層和物理層上窖壕，對于HTTP的應(yīng)用層來說就是透明的（雖然它們可能會對應(yīng)用層的性能有重要影響）。而還有一部分表現(xiàn)在應(yīng)用層上的杉女，就叫做proxies了瞻讽。Proxies既可以表現(xiàn)得透明，又可以不透明（看請求是否通過它們）熏挎，主要表現(xiàn)在這幾個功能上：
·緩存（可以是公開的或是私有的速勇，像瀏覽器的緩存）
·過濾（像反病毒掃描，家長監(jiān)護）
·負載均衡坎拐，讓多個服務(wù)器服務(wù)不同的請求
·對不同資源的權(quán)限控制
·登陸烦磁，允許存儲歷史信息
HTTP 的基本性質(zhì)
HTTP 是簡單的
即便在HTTP/2中把HTTP消息封裝到了frames中养匈，HTTP大體上還是被設(shè)計成可讀的而且簡單的。HTTP的消息能夠讓人讀懂且明白它的意思都伪，還允許簡單的測試呕乎，放低了門檻，更有利于新來者了解陨晶。
HTTP 是可擴展的
在HTTP/1中就出現(xiàn)了, HTTP headers讓協(xié)議擴展變得非常容易猬仁。只要服務(wù)端和客戶端在新的headers上語義達成一致，新的功能就可以輕松地被加進來珍逸。
HTTP 是無狀態(tài)逐虚，有會話的
HTTP是無狀態(tài)的：在同一個連接中聋溜，兩個成功執(zhí)行的請求之間是沒有關(guān)系的谆膳。這就帶來了一個問題，用戶沒辦法在一個網(wǎng)站進行連續(xù)的交互撮躁，比如在一個電商網(wǎng)站里漱病，用戶把某個商品加入了購物車中，換了一個頁面后再次添加商品把曼，兩次添加商品的請求沒有聯(lián)系杨帽，瀏覽器無法知道最終用戶都選擇了哪些商品。而用HTTP的頭部擴展嗤军，HTTP Cookies就可以解決這個問題注盈。把Cookies添加到頭部中，創(chuàng)建一個會話來讓每次請求都能共享相同的上下文信息叙赚，相同的狀態(tài)老客。
而HTTP的核心是無狀態(tài)的，cookies的使用可以創(chuàng)建有狀態(tài)的會話震叮。
HTTP 和連接
一個連接是由傳輸層來控制的胧砰，基本不屬于HTTP的范圍內(nèi)。然而HTTP并不需要下面?zhèn)鬏攲拥膮f(xié)議是面向連接的苇瓣，它只需要它是可靠的尉间，就是說不能丟失消息（至少沒有錯誤）。在因特網(wǎng)兩個最常用的傳輸層協(xié)議中击罪，TCP是可靠的哲嘲，而UDP不是。因此媳禁，HTTP依賴于TCP進行消息傳遞撤蚊，雖然TCP是面向連接的，但這并不是必須的损话。
HTTP/1.0曾經(jīng)為每一個請求/回應(yīng)交換都打開一個TCP連接侦啸，導致了2個缺點：打開一個連接需要多次的消息往返因此很慢槽唾。但是當多個消息周期性的發(fā)送時，這就變得更加高效：暖連接比冷連接更高效光涂。
為了減少這些負擔庞萍，HTTP/1.1引入了流水線的概念（已被證明很難實現(xiàn)）和持久連接的概念：下層的TCP連接可以通過Connection頭部來被部分地控制。HTTP/2則發(fā)展的更多忘闻，通過一個連接多個消息的方式來讓這個連接始終保持為暖連接钝计。
為了更好的適合HTTP，設(shè)計一種更好的傳輸層協(xié)議就一直在進行中齐佳。Google就研發(fā)了一種以UDP為基礎(chǔ)私恬，能提供更可靠更有效傳輸層協(xié)議的QUIC。
HTTP 能控制什么
多年以來炼吴，HTTP良好的擴展性控制著越來越多Web的功能本鸣。緩存和認證方式很早就可以由HTTP來控制了。另一方面硅蹦，對同源同域的限制到2010年才有所改變荣德。
下面就是可以用HTTP來控制的常見特性。
·緩存
文檔怎么緩存能夠通過HTTP來控制童芹。服務(wù)端能告訴代理和客戶端什么需要被緩存涮瞻，緩存多久儡首，而客戶端能夠命令中間緩存代理來忽略存儲的文檔佛嬉。
·開放同源限制
為了防止網(wǎng)絡(luò)窺聽和其它的隱私泄漏话侧，瀏覽器強制對Web網(wǎng)站做了分割限制陌粹。只有來自于相同來源的網(wǎng)頁才能夠獲取網(wǎng)站的全部信息京景。這樣的限制有時反而成了負擔步做，HTTP可以通過修改頭部來開放這樣的限制妒御，因此web文檔可以是由不同域下的信息拼接成的（在某些情況下讯榕，這樣做還有安全因素考慮在里面）久锥。
·認證
一些頁面能夠被保護起來家淤，僅讓特定的用戶進行訪問∩桑基本的認證功能可以直接通過HTTP提供絮重，使用Authenticate相似的頭部就可以，或者用HTTP cookies來設(shè)定指定的會話歹苦。
·代理
服務(wù)端和客戶端通常都處在內(nèi)部網(wǎng)上青伤，彼此的真實地址都是不可見隱藏的。HTTP請求就要通過代理穿過網(wǎng)絡(luò)障礙殴瘦。不是所有的代理都是HTTP代理的狠角，像一些用SOCKS協(xié)議的代理就運作在更底層（一些其它的協(xié)議，像ftp也能夠被它們處理）
·會話
Cookies用一個服務(wù)端的狀態(tài)連接起了每一個請求蚪腋。這就創(chuàng)建了會話丰歌，雖然基本的HTTP是無狀態(tài)協(xié)議姨蟋。這很有用，不僅是因為能用到購物車這樣的電商業(yè)務(wù)上立帖，更是因為眼溶，它使得任何網(wǎng)站都能夠配置頁面展現(xiàn)的東西了。
HTTP 流
當客戶端想要和服務(wù)端進行信息交互時（服務(wù)端是指作為最終的服務(wù)器晓勇，或者是作為中間代理）堂飞，過程表現(xiàn)為下面的幾步：
1.打開一個TCP連接（或者重用之前的一個）：TCP連接用來發(fā)送一條或多條請求，當然也用來接受回應(yīng)消息绑咱〈律福客戶端可能重用一個已經(jīng)存在的連接，或者也可能重開幾個新的與服務(wù)端的TCP連接描融。
2.發(fā)送一個HTTP報文：HTTP報文（在HTTP/2之前）是語義可讀的铝噩。在HTTP/2中，這些簡單的消息被封裝在了幀中稼稿，這使得報文不可能被直接讀出來薄榛，但是規(guī)則仍舊是相同的讳窟。
GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: fr
3.讀取服務(wù)端返回的報文：
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)
4.關(guān)閉連接或者為以后的請求重用連接让歼。
當HTTP流水線啟動時，請求都可以不用等待第一個請求的成功回應(yīng)就被發(fā)送丽啡。然而HTTP流水線已經(jīng)被證明很難在現(xiàn)有的網(wǎng)絡(luò)中實現(xiàn)谋右，因為現(xiàn)有的網(wǎng)絡(luò)中有很多老舊的軟件與現(xiàn)代版本的軟件共存。因此HTTP流水線已經(jīng)被在有多請求下表現(xiàn)得更穩(wěn)健的HTTP/2的幀所取代补箍。
HTTP 報文
HTTP/1.1和更早的HTTP報文都是語義可讀的改执。在HTTP/2中，這些報文被嵌入到了一個新的二進制結(jié)構(gòu)中－幀坑雅。幀可以允許實現(xiàn)很多優(yōu)化辈挂，如復用和報文頭部的壓縮。即使只有原始HTTP報文的一部分以這種HTTP/2版本的方式發(fā)送出來裹粤，每個報文的語義依舊不變终蒂，客戶端會重組原始的HTTP/1.1請求。因此用HTTP/1.1格式來考慮HTTP/2報文仍舊很有效遥诉。
有兩種HTTP報文的類型拇泣，請求與回應(yīng)，每種都有其特定的格式矮锈。
請求
請求由下面的元素組成：
·一個HTTP的method霉翔，經(jīng)常是由一個動詞像GET, POST 或者一個名詞像OPTIONS，HEAD來定義客戶端的動作行為的苞笨。通痴洌客戶端的操作都是獲取資源（用GET方法）或者發(fā)送一個HTML form表單的值（用POST方法）子眶，雖然在一些情況下也會有其他的操作。
·要獲取的資源的路徑序芦，通常是上下文中就很明顯的元素資源的URL壹店，它沒有protocol （http://），domain（developer.mozilla.org）芝加，或是TCP的port（HTTP是80端口）硅卢。
·HTTP協(xié)議的版本號。
·為服務(wù)端表達其他信息的可選擇性的headers藏杖。
·對于一些像POST這樣的方法将塑，報文的body就包含了發(fā)送的資源，這個body與回應(yīng)報文的body類似蝌麸。
回應(yīng)
回應(yīng)報文包含了下面的元素：
·HTTP的版本號点寥。
·一個狀態(tài)碼（status code），來告知對應(yīng)的請求發(fā)送成功或失敗来吩，以及失敗的原因敢辩。
·一個狀態(tài)信息，這個信息是非權(quán)威的狀態(tài)碼描述信息弟疆，也就是說可以由服務(wù)端自行設(shè)定的戚长。
·HTTP headers，與請求的很像怠苔。
·可選的同廉，但是比在請求報文中更加常見地包含獲取資源的body。
總結(jié)
HTTP是很簡單可擴展的一種協(xié)議柑司。結(jié)合了輕松添加頭部信息能力的Client-server結(jié)構(gòu)使得HTTP可以和Web的功能擴充一同發(fā)展迫肖。
即使HTTP/2為了提高性能把HTTP報文嵌到幀中這一舉措增加了復雜度，但是從Web應(yīng)用的角度來看攒驰，報文的基本結(jié)構(gòu)是沒有變化的蟆湖，從HTTP/1.0發(fā)布起就是相同的。會話流依舊很簡單玻粪，用一個簡單的 HTTP message monitor就可以查看它和debug隅津。
摘自 MDN->Web 技術(shù)文檔->HTTP->HTTP概述
