圖解HTTP讀書筆記(一)

時間 2019-12-07

標籤圖解 http 讀書筆記欄目 HTTP/TCP 简体版

原文原文鏈接

使用HTTP訪問web

輸入URL時頁面是如何呈現的

HTTP被譯爲超文本傳輸協議

TCP/IP協議族

TCP/IP是互聯網相關的各種協議族總稱

TCP/IP的分層管理:應用層 . 傳輸層 . 網絡層 . 數據鏈路層

把TCP/IP層次化的好處：想從新改動設計時，不用修改整個協議，而修改對應的層。web

應用層
決定了向用戶提供應用服務時通訊的活動，HTTP協議處於這一層瀏覽器

傳輸層
傳輸層對上層應用層，提供處於網絡鏈接中的兩臺計算楊之間的數據傳輸安全

網絡層
網絡層用來處理在網絡上流動的數據包，數據包是網絡傳輸的最小數據單但，該層規定了經過怎樣的路徑到達對方計算機。服務器

鏈路層
用來處理鏈接網絡的硬件部分。網絡

TCP/IP通訊傳輸流

利用 TCP/IP 協議族進行網絡通訊時，會經過分層順序與對方進行通信。發送端從應用層往下走，接收端則往應用層往上走。
咱們用 HTTP 舉例來講明，首先做爲發送端的客戶端在應用層（HTTP 協議）發出一個想看某個 Web 頁面的 HTTP 請求
接着，爲了傳輸方便，在傳輸層（TCP 協議）把從應用層處收到的數據（HTTP 請求報文）進行分割，並在各個報文上打上標記序號及端口號後轉發給網絡層。
在網絡層（IP 協議），增長做爲通訊目的地的 MAC 地址後轉發給鏈路層。這樣一來，發往網絡的通訊請求就準備齊全了。
接收端的服務器在鏈路層接收到數據，按序往上層發送，一直到應用層。當傳輸到應用層，才能算真正接收到由客戶端發送過來的 HTTP 請求。less

發送端在層與層之間傳輸數據時，每通過一層時一定會被打上一個該層所屬的首部信息。反之，接收端在層與層傳輸數據時，每通過一層時會把對應的首部消去。
這種把數據信息包裝起來的作法稱爲封裝（encapsulate）。網站

與HTTP關係密切的協議：IP、TCP、DNS

IP協議

把各類數據包傳輸給對方，確保傳輸到對方最重要的兩個條件是IP地址和MAC地址
ARP協議可將IP地址解析爲MAC地址編碼

TCP協議:確保可靠性

TCP位於傳輸層，提供可靠的字節流服務，就是將大塊數據分割成以報文段爲單位的數據包進行管理，並且TCP協議最終可確認數據是否送達對方，採用的是三次握手策略：
握手過程當中使用了 TCP 的標誌（flag） —— SYN（synchronize）和 ACK（acknowledgement）spa

若在握手過程當中某個階段莫名中斷，TCP 協議會再次以相同的順序發送相同的數據包。.net

DNS協議:負責域名解析

用戶一般使用主機名或域名來訪問對方的計算機，而不是直接經過 IP 地址訪問。由於與 IP 地址的一組純數字相比，用字母配合數字的表示形式來指定計算機名更符合人類的記憶習慣。
DNS 協議提供經過域名查找 IP 地址，或逆向從 IP 地址反查域名的服務

各類協議與HTTP協議的關係

URI與URL

URI 用字符串標識某一互聯網資源，而 URL 表示資源的地點（互聯網上所處的位置）。可見 URL 是 URI 的子集
URI格式：

簡單的HTTP協議

HTTP 協議規定，請求從客戶端發出，最後服務器端響應該請求並返回。換句話說，確定是先從客戶端開始創建通訊的，服務器端在沒有接收到請求以前不會發送響應。
具體實例：

GET /index.htm HTTP/1.1
Host: hackr.jp

起始行開頭的GET表示請求訪問服務器的類型，稱爲方法（method）。隨後的字符串 /index.htm 指明瞭請求訪問的資源對象，也叫作請求 URI（request-URI）。最後的 HTTP/1.1，即 HTTP 的版本號，用來提示客戶端使用的 HTTP 協議功能。綜合來看，這段請求內容的意思是：請求訪問某臺 HTTP 服務器上的 /index.htm 頁面資源。

請求報文

響應報文

HTTP是不保存狀態的協議

HTTP 是一種不保存狀態，即無狀態（stateless）協議。HTTP 協議自身不對請求和響應之間的通訊狀態進行保存。也就是說在 HTTP 這個級別，協議對於發送過的請求或響應都不作持久化處理

但是，隨着 Web 的不斷髮展，因無狀態而致使業務處理變得棘手的狀況增多了。好比，用戶登陸到一家購物網站，即便他跳轉到該站的，其餘頁面後，也須要能繼續保持登陸狀態。針對這個實例，網站爲了可以掌握是誰送出的請求，須要保存用戶的狀態。
因而引入了 Cookie 技術。有了 Cookie 再用 HTTP 協議通訊，就能夠管理狀態了

告知服務器意圖的 HTTP 方法

GET方法

GET 方法用來請求訪問已被 URI 識別的資源。指定的資源經服務器端解析後返回響應內容。

使用 GET 方法的請求·響應的例子

POST方法

POST 方法用來傳輸實體的主體

POST 方法的請求·響應的例子

PUT方法

PUT 方法用來傳輸文件。就像 FTP 協議的文件上傳同樣，要求在請求報文的主體中包含文件內容，而後保存到請求 URI 指定的位置
可是，鑑於 HTTP/1.1 的 PUT 方法自身不帶驗證機制，任何人均可以上傳文件 , 存在安全性問題，所以通常的 Web 網站不使用該方法

使用 PUT 方法的請求·響應的例子

響應的意思實際上是請求執行成功了，但無數據返回

DELETE方法

DELETE 方法用來刪除文件，是與 PUT 相反的方法。DELETE 方法按請求 URI 刪除指定的資源，可是，HTTP/1.1 的 DELETE 方法自己和 PUT 方法同樣不帶驗證機制，因此通常的 Web 網站也不使用 DELETE 方法

使用 DELETE 方法的請求·響應的例子

HEAD方法

HEAD 方法和 GET 方法同樣，只是不返回報文主體部分。用於確認 URI 的有效性及資源更新的日期時間等

和 GET 同樣，但不返回報文主體
使用 HEAD 方法的請求·響應的例子

OPTIONS方法

OPTIONS 方法用來查詢針對請求 URI 指定的資源支持的方法。

使用 OPTIONS 方法的請求·響應的例子

CONNECT方法

CONNECT 方法要求在與代理服務器通訊時創建隧道，實現用隧道協議進行 TCP 通訊，議把通訊內容加密後經網絡隧道傳輸

使用 CONNECT 方法的請求·響應的例子

HTTP/1.0 和 HTTP/1.1 支持的方法

持久鏈接節省通訊量

HTTP 協議的初始版本中，每進行一次 HTTP 通訊就要斷開一次 TCP 鏈接。

以當年的通訊狀況來講，由於都是些容量很小的文本傳輸，因此即便這樣也沒有多大問題。可隨着 HTTP 的普及，文檔中包含大量圖片的狀況多了起來。
好比，使用瀏覽器瀏覽一個包含多張圖片的 HTML 頁面時，在發送請求訪問 HTML 頁面資源的同時，也會請求該 HTML 頁面裏包含的其餘資源。所以，每次的請求都會形成無謂的 TCP 鏈接創建和斷開，增長通訊量的開銷。

持久鏈接的特色是，只要任意一端沒有明確提出斷開鏈接，則保持 TCP 鏈接狀態。

持久鏈接的好處在於減小了 TCP 鏈接的重複創建和斷開所形成的額外開銷，減輕了服務器端的負載。另外，減小開銷的那部分時間，使 HTTP 請求和響應可以更早地結束，這樣 Web 頁面的顯示速度也就相應提升了。

管線化

持久鏈接使得多數請求以管線化（pipelining）方式發送成爲可能。從前發送請求後需等待並收到響應，才能發送下一個請求。管線化技術出現後，不用等待響應亦可直接發送下一個請求。
這樣就可以作到同時並行發送多個請求，而不須要一個接一個地等待響應了

不等待響應，直接發送下一個請求
好比，當請求一個包含 10 張圖片的 HTML Web 頁面，與挨個鏈接相比，用持久鏈接可讓請求更快結束。而管線化技術則比持久鏈接還要快。請求數越多，時間差就越明顯

使用 Cookie 的狀態管理

若是讓服務器管理所有客戶端狀態則會成爲負擔

保留無狀態協議這個特徵的同時又要解決相似的矛盾問題，因而引入了 Cookie 技術。Cookie 技術經過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態
沒有 Cookie 信息狀態下的請求

請求報文（沒有 Cookie 信息的狀態）

GET /reader/ HTTP/1.1 
Host: hackr.jp 
首部字段內沒有Cookie的相關信息

響應報文（服務器端生成 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

存有 Cookie 信息狀態的請求

請求報文（自動發送保存着的 Cookie 信息）

GET /image/ HTTP/1.1 
Host: hackr.jp 
Cookie: sid=1342077140226724

HTTP 報文內的 HTTP 信息

請求報文及響應報文的結構

請求報文：

響應報文：

實例

編碼提高傳輸速率

HTTP 在傳輸數據時能夠按照數據原貌直接傳輸，但也能夠在傳輸過程中經過編碼提高傳輸速率，可是，編碼的操做須要計算機來完成，所以會消耗更多的 CPU 等資源

報文主體和實用主體的差別
一般，報文主體等於實體主體。只有當傳輸中進行編碼操做時，實體主體的內容發生變化，才致使它和報文主體產生差別

壓縮傳輸的內容編碼

向待發送郵件內增長附件時，爲了使郵件容量變小，咱們會先用 ZIP 壓縮文件以後再添加附件發送。HTTP 協議中有一種被稱爲內容編碼的功能也能進行相似的操做
內容編碼指明應用在實體內容上的編碼格式，並保持實體信息原樣壓縮。內容編碼後的實體由客戶端接收並負責解碼

常見的內容編碼有如下幾種：
gzip
compress(UNIX系統的標準壓縮)
deflate(zlib)
indenity(不進行編碼)

分割發送的分塊傳輸編碼

在 HTTP 通訊過程當中，請求的編碼實體資源還沒有所有傳輸完成以前，瀏覽器沒法顯示請求頁面。在傳輸大容量數據時，經過把數據分割成多塊，可以讓瀏覽器逐步顯示頁面。

分塊傳輸編碼會將實體主體分紅多個部分（塊）。每一塊都會用十六進制來標記塊的大小，而實體主體的最後一塊會使用「0(CR+LF)」來標記。

發送多種數據的多部分對象集合

咱們能夠在郵件裏寫入文字並添加多份附件，這是由於採用了 MIME，它容許郵件處理文本、圖片、視頻等多個不一樣類型的，發送的一份報文主體內可含有多類型實體，多部分對象集合包含的對象以下：
multipart/form-data
multipart/byteranges

獲取部份內容的範圍請求

因爲之前網速很慢下載一個東西很難，如果中間中斷了重頭開始的話又要等好久，因此出現了可恢復機制:能從以前下載中斷處恢復下載。
實例：

內容協商返回最合適的內容

內容協商的定義:內容協商機制是指客戶端和服務器端就響應的資源內容進行交涉，然後提供給客戶端最爲適合的資
同一個 Web 網站有可能存在着多份相同內容的頁面。好比英語版和中文版的 Web 頁面，它們內容上雖相同，但使用的語言卻不一樣
當瀏覽器的默認語言爲英語或中文，訪問相同 URI 的 Web 頁面時，則會顯示對應的英語版或中文版的 Web 頁面。這樣的機制稱爲內容協商

內容協商有三種類型：
服務端驅動（選擇出來的內容可能會不太符合用戶的需求）
客戶端驅動
服務端與客戶端共同驅動（稱爲透明協商）

返回結果的HTTP狀態碼

HTTP 狀態碼負責表示客戶端 HTTP 請求的返回結果、標記服務器端的處理是否正常、通知出現的錯誤等工做。

狀態碼類型

2XX成功

2XX 的響應結果代表請求被正常處理了

200OK

表示從客戶端發來的請求在服務器端被正常處理了

204 NOT CONTENT

該狀態碼錶明服務器接收的請求已成功處理，但在返回的響應報文中不含實體的主體部分
返回 204 響應，那麼瀏覽器顯示的頁面不發生更新

206 Partial Content

該狀態碼錶示客戶端進行了範圍請求，而服務器成功執行了這部分的 GET 請求

3XX重定向

3XX 響應結果代表瀏覽器須要執行某些特殊的處理以正確處理請求

301 Moved Permanently

永久性重定向。該狀態碼錶示請求的資源已被分配了新的 URI，之後應使用資源如今所指的 URI
像下方給出的請求 URI，當指定資源路徑的最後忘記添加斜槓「/」，就會產生 301 狀態碼。

http://example.com/sample

302 Found

臨時性重定向。該狀態碼錶示請求的資源已被分配了新的 URI，但願用戶（本次）能使用新的 URI 訪問
和 301 Moved Permanently 狀態碼類似，但 302 狀態碼錶明的資源不是被永久移動，只是臨時性質的

303 See Other

該狀態碼錶示因爲請求對應的資源存在着另外一個 URI，應使用 GET 方法定向獲取請求的資源。
303 狀態碼和 302 Found 狀態碼有着相同的功能，但 303 狀態碼明確表示客戶端應當採用 GET 方法獲取資源
當 30一、30二、303 響應狀態碼返回時，幾乎全部的瀏覽器都會把 POST 改爲 GET，並刪除請求報文內的主體，以後請求會自動再次發送
30一、302 標準是禁止將 POST 方法改變成 GET 方法的，但實際使用時你們都會這麼作