讀《圖解HTTP》記錄
上一篇 讀書筆記_圖解HTTP(一) Web及網(wǎng)絡基礎
- HTTP協(xié)議用于客戶端和服務端之間通信
一般由客戶端首先發(fā)起供炎，由服務端響應 - 通過請求和響應的交換達成通信
- HTTP是不保存狀態(tài)的協(xié)議(無狀態(tài))
后續(xù)引入了Cookie技術到旦，就可以管理狀態(tài)了
HTTP方法
- GET
GET請求用于訪問資源 - POST
POST請求用于傳輸實體的主體 - PUT
PUT方法用于傳輸文件嘁圈。由于HTTP/1.1的PUT方法不帶驗證機制咒程，任何人都能上傳文件蜈出，存在安全性問題欠橘，因此一般的Web網(wǎng)站不使用該方法。 - HEAD 獲得報文首部
和GET方法一樣秸谢，只是不返回報文主體部分。用于確認URI的有效性以及資源更新的時間日期等霹肝。 -
DELETE：刪除文件
DELETE 方法用來刪除文件估蹄，是與 PUT 相反的方法。DELETE 方法按 請求 URI 刪除指定的資源阿迈。
Http支持的方法
持久連接節(jié)省通信量
-
持久連接
之前每次進行HTTP請求的時候元媚，都要先建立TCP連接，然后結束之后再斷開TCP連接。這樣如果在同一份HTML文檔中有大量的圖片等資源刊棕，就會建立和斷開多次TCP連接炭晒，造成資源的浪費。HTTP1.1和一部分HTTP1.0想出了持久連接甥角。持久連接的特點：只要任意一端沒有明確斷開連接网严，就保持TCP的鏈接狀態(tài)。這樣不會因為頻繁的建立和斷開TCP連接咋造成額外的開銷嗤无，減輕了服務器的負載震束。同時減少了HTTP請求和響應的時間。
持久化連接 -
管線化
持久連接使得多數(shù)請求以管線化方式發(fā)送成為可能当犯。從以前發(fā)送請求需要等待并收到響應垢村，才能發(fā)送下一個請求。管線化技術出現(xiàn)后嚎卫，就不用等待響應嘉栓，直接可以發(fā)送下一個請求了。管線化技術比持久化連接更快拓诸。
管線化
使用Cookie的狀態(tài)管理
Cookie技術通過在請求和響應報文中寫入Cookie信息來控制客戶端的狀態(tài)侵佃。
Cookie會根據(jù)從服務器端發(fā)送的響應報文內(nèi)一個叫Set-Cookie的首部字段信息，通知客戶端保存Cookie奠支。當下次客戶端再往該服務器發(fā)送請求時馋辈，客戶端自動會在請求報文中加入Cookie值后發(fā)送出去。
服務端發(fā)現(xiàn)客戶端發(fā)過來的Cookie后倍谜，會去檢查到底是從那個客戶端發(fā)過來的連接請求迈螟，然后對比服務器上的記錄，最后得到之前的狀態(tài)信息枢劝。
HTTP請求報文和響應報如下
1井联、請求報文(沒有Cookie信息的狀態(tài))
GET /reader/ HTTP/1.1
Host: hackr.jp *
首部字段內(nèi)沒有Cookie的相關信息
2、響應報文(服務器端生成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
3您旁、請求報文(自動發(fā)送保存著的Cookie信息)
GET /image/ HTTP/1.1
Host: hackr.jp
Cookie: sid=1342077140226724
HTTP請求報文以及響應報文
- 請求行
包含請求的方法烙常，請求的URI和HTTP版本。 - 狀態(tài)行
包含表明響應結果的狀態(tài)碼鹤盒，原因短語和Http版本蚕脏。 - 首部字段
包含表示請求和響應的各種條件和屬性的各類首部。
一般有4種首部：通用首部侦锯、請求首部驼鞭、響應首部和實體首部 - 其他
可能包含HTTP的RFC里未定義的額首部(Cookie等)
編碼提升傳輸速率
- 報文
是HTTP通信中的基本單位，由8位組字節(jié)流組成尺碰，通過HTTP通信傳輸挣棕。 - 實體
作為請求或響應的有效載荷數(shù)據(jù)被傳輸译隘，其內(nèi)容由實體首部和實體主體組成
Http報文的主體用于傳輸請求或響應的實體數(shù)體。
通常洛心，報文主體等于實體主體固耘。只有當傳輸中進行編碼操作時，實體 主體的內(nèi)容發(fā)生變化词身，才導致它和報文主體產(chǎn)生差異厅目。
1、壓縮傳輸?shù)膬?nèi)容編碼
HTTP 協(xié)議中有一種被稱為內(nèi)容編碼的功能來完成壓縮后傳輸?shù)牟僮鳌?br> 內(nèi)容編碼指明應用在實體內(nèi)容上的編碼格式法严，并保持實體信息原樣壓縮损敷。內(nèi)容編碼后由實體客戶端接收并負責解碼。
常用的內(nèi)容編碼有以下幾種深啤。
- gzip（GNU zip）
- compress（UNIX 系統(tǒng)的標準壓縮）
- deflate（zlib）
- identity（不進行編碼）
由服務器將要傳輸?shù)膬?nèi)容進行壓縮拗馒，然后傳遞給客戶端，并且告訴客戶端編碼格式溯街，由客戶端接收后瘟忱，再解壓縮，拿到原來的內(nèi)容苫幢。
2、分隔發(fā)送的分塊傳輸編碼
在Http通信過程中垫挨，請求的編碼實體資源在尚未全部傳輸完成之前韩肝，瀏覽器無法顯示請求頁面。在傳輸大內(nèi)容數(shù)據(jù)時,通過把數(shù)據(jù)分隔成多塊九榔，能過讓瀏覽器逐步顯示頁面哀峻。
這種把實體主體分塊的功能稱為分塊傳輸編碼。
分塊傳輸編碼會將實體主體分成多個部分（塊）哲泊。每一塊都會用十六 進制來標記塊的大小剩蟀，而實體主體的最后一塊會使用“0(CR+LF)”來標 記。
使用分塊傳輸編碼的實體主體會由接收的客戶端負責解碼切威，恢復到編 碼前的實體主體育特。
發(fā)送多種數(shù)據(jù)的多部分對象集合
在http協(xié)議中發(fā)送的一份報文主體內(nèi)，可包含多類型實體(圖片先朦，文件等)缰冤。通常在圖片或者文本文件上傳時使用。多部分對象集合包含的對象如下：
- multipart/form-data
在 Web 表單文件上傳時使用喳魏。 - multipart/byteranges 狀態(tài)碼 206（Partial Content棉浸，部分內(nèi)容）響應報文包含了多個范 圍的內(nèi)容時使用。
在http報文中使用多部分對象集合時刺彩，需要在首部字段加上Content-type.
關于范圍內(nèi)容的說明
在下載大文件過程中迷郑，網(wǎng)絡中斷枝恋，需要重頭重新下載。則還是很需要一種可以恢復的機制嗡害，從斷開出恢復下載焚碌。像這種，需要發(fā)送范圍請求就漾，只請求目標資源中的一部分呐能。執(zhí)行范圍請求時，回用到首部字段Range來指定資源的byte范圍抑堡。
byte范圍的指定形式如下摆出。
- 5001~10000字節(jié)
Range: bytes=5001-10000 - 從 5001 字節(jié)之后全部的
Range: bytes=5001- - 從一開始到 3000 字節(jié)和 5000~7000 字節(jié)的多重范圍
Range: bytes=-3000, 5000-7000
針對范圍請求，響應會返回206的狀態(tài)嗎報文首妖。對于多重范圍的范圍請求偎漫，響應會在不受字段Content-Type表明multipart/byteranges后返回響應報文。
如果服務器端無法響應范圍請求有缆，則會返回狀態(tài)碼200 OK和完整的實體內(nèi)容象踊。
HTTP的響應狀態(tài)碼
狀態(tài)碼如200 OK,以3位數(shù)字和短語組成，第一位數(shù)字指定了響應類別棚壁。分為一下五種杯矩。
| 類別 | 原因短語 | |
|---|---|---|
| 1xx | Informational(信息性狀態(tài)碼) | 接受的請求正在處理 |
| 2xx | Success(成功狀態(tài)碼) | 請求正常處理完畢 |
| 3xx | Redirection(重定向狀態(tài)碼) | 需要進行附加操作以完成請求 |
| 4xx | Client Error(客戶端錯誤代碼) | 服務器無法處理的請求 |
| 5xx | Server Error(服務器錯誤狀態(tài)碼) | 服務器處理請求出錯 |
常用狀態(tài)碼
1XX
1xx表示臨時性消息
- 100
比如，客戶端上傳大數(shù)據(jù)時袖外，分段上傳史隆，這時候加一個請求頭，說我這邊還有數(shù)據(jù)會繼續(xù)上傳曼验，如果你接收完了泌射，返回一個100，告訴客戶端鬓照，這次上傳的成功了熔酷，繼續(xù)上傳吧。 - 101
比如客戶端想問問服務器支持不支持http2的請求豺裆，服務器返回101拒秘，表示支持，這時候留储，客戶端以后的請求就可以用http2了翼抠。
正在切換協(xié)議
2XX
2xx的響應結果表明請求被正常處理了。
- 200 OK
表示從客戶端發(fā)來的請求在服務器端被正常處理了获讳。
在響應報文內(nèi)阴颖，隨狀態(tài)碼一起返回的信息會因方法的不同而發(fā)生改 變。比如丐膝，使用 GET 方法時量愧，對應請求資源的實體會作為響應返 回钾菊；而使用 HEAD 方法時，對應請求資源的實體首部不隨報文主體 作為響應返回（即在響應中只返回首部偎肃，不會返回實體的主體部 分）煞烫。 - 204 No Content
服務器接收的請求已經(jīng)成功處理，但是在返回的響應報文中不含實體的主體部分累颂。另外滞详，也不允許返回任何實體的主體。
一般在只需要從客戶端往服務器發(fā)送信息紊馏，而對客戶端不需要發(fā)送新信息內(nèi)容的情況下使用料饥。 - 206 Partial Content
客戶端進行了范圍請求，而服務器成功執(zhí)行了這部分的GET請求朱监。響應報文中包含由Content-Range指定范圍的實體內(nèi)容岸啡。
3XX
3xx的響應結果表明瀏覽器需要執(zhí)行某些特殊的處理以正確處理該請求。
就是重定向到某個其他的地址赫编，比如
- 307
在瀏覽器輸入http://www.baidu.com/巡蘸，然后瀏覽器會定位到https://www.baidu.com/，這時候你看code碼就是307擂送。 - 304
在瀏覽器輸入http://www.reibang.com/p/6b03753de31c 悦荒，然后再刷新一下，在看一下code碼嘹吨，返回的一堆請求里會有幾個304逾冬，表示這些數(shù)據(jù)沒有改變。
4XX 客戶端錯誤
4XX 的響應結果表明客戶端是發(fā)生錯誤的原因所在躺苦。
400 Bad Request
表示請求報文中存在語法錯誤。當錯誤發(fā)生時产还，需修改請求的內(nèi)容后再次發(fā)送請求匹厘。另外，瀏覽器會像 200 OK 一樣對待該狀態(tài)碼脐区。401 Unauthorized
該狀態(tài)碼表示發(fā)送的請求需要通過HTTP認證(BASIC認證愈诚、DIGEST認證)的認證信息。如果之前已經(jīng)進行過一次請求牛隅，就表示認證失敗炕柔。
返回含有 401 的響應必須包含一個適用于被請求資源的 WWWAuthenticate 首部用以質(zhì)詢（challenge）用戶信息。當瀏覽器初次接收 到 401 響應媒佣，會彈出認證用的對話窗口匕累。403 Forbidden
該狀態(tài)碼表明對請求資源的訪問被服務器拒絕了。服務器端沒有必要 給出拒絕的詳細理由默伍，但如果想作說明的話欢嘿，可以在實體的主體部分對原因進行描述衰琐，這樣就能讓用戶看到了。
未獲得文件系統(tǒng)的訪問授權炼蹦，訪問權限出現(xiàn)某些問題（從未授權的發(fā) 送源 IP 地址試圖訪問）等列舉的情況都可能是發(fā)生 403 的原因羡宙。404 Not Found
該狀態(tài)碼表明服務器上無法找到請求的資源。除此之外掐隐，也可以在服 務器端拒絕請求且不想說明理由時使用狗热。
5XX 服務器錯誤
5XX 的響應結果表明服務器本身發(fā)生錯誤。
500 Internal Server Error
該狀態(tài)碼表明服務器端在執(zhí)行請求時發(fā)生了錯誤虑省。也有可能是 Web 應用存在的 bug 或某些臨時的故障匿刮。503 Service Unavailable
該狀態(tài)碼表示服務器暫時處于超負載或正在進行停機維護，現(xiàn)在無法處理請求慷妙。如果事先得知接觸以上狀況需要的時間僻焚，最好寫入RetryAfter首部字段再返回給客戶端。
