如果和我一樣赖钞，對網(wǎng)絡(luò)毫無概念腰素，并且想去了解HTTP，建議看下HTTP圖解這一本書雪营，很不錯弓千，包含大量的圖畫幫助我們理解HTTP，不會那么枯燥献起，講的很清晰洋访。非常棒的一本書
本篇筆記大部分使用此書原文和原圖，提取了個人覺得比較重要的知識點谴餐，供后期自己回顧學(xué)習(xí)使用
請求報文構(gòu)成
請求報文是由請求方法姻政、請求 URI、協(xié)議版本岂嗓、可選的請求首部字
段和內(nèi)容實體構(gòu)成的扶歪。
請求響應(yīng),響應(yīng)報文
HTTP/1.1 200 OK
Date: Tue, 10 Jul 2012 06:50:15 GMT
Content-Length: 362
Content-Type: text/html
<html>
......
在起始行開頭的 HTTP/1.1 表示服務(wù)器對應(yīng)的 HTTP 版本。
緊挨著的 200 OK 表示請求的處理結(jié)果的狀態(tài)碼(status code)和原 因短語(reason-phrase)摄闸。下一行顯示了創(chuàng)建響應(yīng)的日期時間，是首部字 段(header field)內(nèi)的一個屬性妹萨。
接著以一空行分隔年枕，之后的內(nèi)容稱為資源實體的主體(entity body)。
響應(yīng)報文基本上由協(xié)議版本乎完、狀態(tài)碼(表示請求成功或失敗的數(shù)字 代碼)熏兄、用以解釋狀態(tài)碼的原因短語、可選的響應(yīng)首部字段以及實體主體構(gòu)成树姨。
HTTP 是不保存狀態(tài)的協(xié)議
HTTP 是一種不保存狀態(tài)摩桶，即無狀態(tài)(stateless)協(xié)議。HTTP 協(xié)議 自身不對請求和響應(yīng)之間的通信狀態(tài)進(jìn)行保存帽揪。也就是說在 HTTP 這個 級別硝清，協(xié)議對于發(fā)送過的請求或響應(yīng)都不做持久化處理。
使用 HTTP 協(xié)議转晰，每當(dāng)有新的請求發(fā)送時芦拿，就會有對應(yīng)的新響應(yīng)產(chǎn) 生士飒。協(xié)議本身并不保留之前一切的請求或響應(yīng)報文的信息。這是為了更快地處理大量事務(wù)蔗崎，確保協(xié)議的可伸縮性酵幕，而特意把 HTTP 協(xié)議設(shè)計成 如此簡單的。
隨著 Web 的不斷發(fā)展缓苛，因無狀態(tài)而導(dǎo)致業(yè)務(wù)處理變得棘手 的情況增多了芳撒。比如，用戶登錄到一家購物網(wǎng)站未桥，即使他跳轉(zhuǎn)到該站的 其他頁面后笔刹，也需要能繼續(xù)保持登錄狀態(tài)。針對這個實例钢属，網(wǎng)站為了能 夠掌握是誰送出的請求徘熔，需要保存用戶的狀態(tài)。
HTTP/1.1 雖然是無狀態(tài)協(xié)議淆党，但為了實現(xiàn)期望的保持狀態(tài)功能酷师， 于是引入了 Cookie 技術(shù)。有了 Cookie 再用 HTTP 協(xié)議通信染乌，就可以管 理狀態(tài)了山孔。
告知服務(wù)器意圖的 HTTP 方法
- GET :獲取資源
GET 方法用來請求訪問已被 URI 識別的資源。指定的資源經(jīng)服務(wù) 器端解析后返回響應(yīng)內(nèi)容荷憋。也就是說台颠，如果請求的資源是文本，那就保 持原樣返回;如果是像 CGI(Common Gateway Interface勒庄，通用網(wǎng)關(guān)接 口)那樣的程序串前，則返回經(jīng)過執(zhí)行后的輸出結(jié)果。
- POST:傳輸實體主體
POST 方法用來傳輸實體的主體实蔽。
雖然用 GET 方法也可以傳輸實體的主體荡碾，但一般不用 GET 方法進(jìn) 行傳輸，而是用 POST 方法局装。雖說 POST 的功能與 GET 很相似坛吁，但 POST 的主要目的并不是獲取響應(yīng)的主體內(nèi)容。
- PUT :傳輸文件
PUT 方法用來傳輸文件铐尚。就像 FTP 協(xié)議的文件上傳一樣拨脉，要求在 請求報文的主體中包含文件內(nèi)容，然后保存到請求 URI 指定的位置宣增。
但是玫膀，鑒于 HTTP/1.1 的 PUT 方法自身不帶驗證機(jī)制，任何人都可 以上傳文件 , 存在安全性問題爹脾，因此一般的 Web 網(wǎng)站不使用該方法匆骗。若 配合 Web 應(yīng)用程序的驗證機(jī)制劳景，或架構(gòu)設(shè)計采用 REST(REpresentational State Transfer，表征狀態(tài)轉(zhuǎn)移)標(biāo)準(zhǔn)的同類 Web 網(wǎng)站碉就，就可能會開放使 用 PUT 方法盟广。
- HEAD:獲得報文首部
HEAD 方法和 GET 方法一樣，只是不返回報文主體部分瓮钥。用于確認(rèn) URI 的有效性及資源更新的日期時間等筋量。
- DELETE:刪除文件
DELETE 方法用來刪除文件，是與 PUT 相反的方法碉熄。DELETE 方 法按請求 URI 刪除指定的資源桨武。
但是，HTTP/1.1 的 DELETE 方法本身和 PUT 方法一樣不帶驗證機(jī) 制锈津，所以一般的 Web 網(wǎng)站也不使用 DELETE 方法呀酸。當(dāng)配合 Web 應(yīng)用程 序的驗證機(jī)制，或遵守 REST 標(biāo)準(zhǔn)時還是有可能會開放使用的琼梆。
- OPTIONS:詢問支持的方法
OPTIONS 方法用來查詢針對請求 URI 指定的資源支持的方法性誉。
- TRACE:追蹤路徑，TRACE 方法是讓 Web 服務(wù)器端將之前的請求通信環(huán)回給客戶端的 方法茎杂，基本不用错览，容易引發(fā) XST (Cross-Site Tracing，跨站追蹤)攻擊
- CONNECT:要求用隧道協(xié)議連接代理
CONNECT 方法要求在與代理服務(wù)器通信時建立隧道煌往，實現(xiàn)用隧道 協(xié)議進(jìn)行 TCP 通信倾哺。主要使用 SSL(Secure Sockets Layer，安全套接 層)和 TLS(Transport Layer Security刽脖，傳輸層安全)協(xié)議把通信內(nèi)容加 密后經(jīng)網(wǎng)絡(luò)隧道傳輸羞海。
CONNECT 方法的格式如下所示。
CONNECT 代理服務(wù)器名:端口號 HTTP版本
HTTP/1.0 和 HTTP/1.1 支持的方法
持久連接節(jié)省通信量
HTTP 協(xié)議的初始版本中曲管，每進(jìn)行一次 HTTP 通信就要斷開一次 TCP 連接却邓。
以早起的通信情況來說，因為都是些容量很小的文本傳輸翘地，所以即 使這樣也沒有多大問題“┠唬可隨著 HTTP 的普及衙耕，文檔中包含大量圖片的 情況多了起來。
比如勺远，使用瀏覽器瀏覽一個包含多張圖片的 HTML 頁面時橙喘，在發(fā) 送請求訪問 HTML 頁面資源的同時，也會請求該 HTML 頁面里包含的 其他資源胶逢。因此厅瞎，每次的請求都會造成無謂的 TCP 連接建立和斷開饰潜， 增加通信量的開銷。
持久連接
為解決上述 TCP 連接的問題和簸，HTTP/1.1 和一部分的 HTTP/1.0 想出 了持久連接(HTTP Persistent Connections彭雾，也稱為 HTTP keep-alive 或 HTTP connection reuse)的方法。持久連接的特點是锁保，只要任意一端沒 有明確提出斷開連接薯酝，則保持 TCP 連接狀態(tài)。
持久連接的好處在于減少了 TCP 連接的重復(fù)建立和斷開所造成的 額外開銷爽柒，減輕了服務(wù)器端的負(fù)載吴菠。另外，減少開銷的那部分時間浩村，使 HTTP 請求和響應(yīng)能夠更早地結(jié)束做葵，這樣 Web 頁面的顯示速度也就相應(yīng) 提高了。
在 HTTP/1.1 中心墅，所有的連接默認(rèn)都是持久連接酿矢，但在 HTTP/1.0 內(nèi) 并未標(biāo)準(zhǔn)化。雖然有一部分服務(wù)器通過非標(biāo)準(zhǔn)的手段實現(xiàn)了持久連接嗓化，但服務(wù)器端不一定能夠支持持久連接棠涮。毫無疑問，除了服務(wù)器端刺覆，客戶 端也需要支持持久連接严肪。
管線化
持久連接使得多數(shù)請求以管線化(pipelining)方式發(fā)送成為可能。 從前發(fā)送請求后需等待并收到響應(yīng)谦屑，才能發(fā)送下一個請求驳糯。管線化技術(shù) 出現(xiàn)后，不用等待響應(yīng)亦可直接發(fā)送下一個請求氢橙。
這樣就能夠做到同時并行發(fā)送多個請求酝枢，而不需要一個接一個地等 待響應(yīng)了。
比如帘睦，當(dāng)請求一個包含 10 張圖片的 HTML Web 頁面，與挨個連接 相比坦康，用持久連接可以讓請求更快結(jié)束竣付。而管線化技術(shù)則比持久連接還 要快。請求數(shù)越多滞欠，時間差就越明顯古胆。
使用 Cookie 的狀態(tài)管理
如果讓服務(wù)器管理全部客戶端狀態(tài)則會成為負(fù)擔(dān)，于是引 入了 Cookie 技術(shù)筛璧。Cookie 技術(shù)通過在請求和響應(yīng)報文中寫入 Cookie 信 息來控制客戶端的狀態(tài)逸绎。
Cookie 會根據(jù)從服務(wù)器端發(fā)送的響應(yīng)報文內(nèi)的一個叫做 Set-Cookie 的首部字段信息惹恃，通知客戶端保存 Cookie。當(dāng)下次客戶端再往該服務(wù)器 發(fā)送請求時棺牧，客戶端會自動在請求報文中加入 Cookie 值后發(fā)送出去巫糙。
服務(wù)器端發(fā)現(xiàn)客戶端發(fā)送過來的 Cookie 后，會去檢查究竟是從哪 一個客戶端發(fā)來的連接請求陨帆，然后對比服務(wù)器上的記錄曲秉，最后得到之前 的狀態(tài)信息。
請求報文(沒有 Cookie 信息的狀態(tài))
GET /reader/ HTTP/1.1
Host: hackr.jp
* 首部字段內(nèi)沒有 Cookie 的相關(guān)信息
響應(yīng)報文(服務(wù)器端生成 Cookie 信息)
HTTP/1.1 200 OK
Date: Thu, 12 Jul 2012 07:12:20 GMT
Server: Apache
<Set-Cookie: sid=1342077140226724; path=/; expires=Wed, 10-Oct-12 07:12:20 GMT>
Content-Type: text/plain; charset=UTF-8
二次請求報文(自動發(fā)送保存著的 Cookie 信息)
GET /image/ HTTP/1.1
Host: hackr.jp
Cookie: sid=1342077140226724
