《圖解 HTTP》讀書筆記（未完待續）

時間 2020-02-05

原文原文鏈接

ARP 協議（Address Resolution Protocol）一種以解析地址的協議，根據通訊雙方的 IP 地址就能夠查出對應的 MAC 地址。
MAC（ Media Access Control Address）地址是指網卡所屬的固定的地址
MIME，多部分對象集合（Multipurpose Internet Mail Extensions，多用途因特網郵件擴展），它是一種容許處理文本、圖片、視頻等多種不一樣類型的數據。瀏覽器

第一章：瞭解 Web 及網絡基礎

在瀏覽器地址欄輸入 URL 時，能夠看到 Web 頁面。固然 Web 頁面是不能憑空顯示出來，它須要根據指定的 URL 到服務器獲取文件資源，而後讓瀏覽器顯示 Web 頁面。緩存

Web 使用一種名爲 HTTP 的協議做爲規範。HTTP 全稱 HyperText Transfer Protocol，超文本傳輸協議。安全

網絡基礎 TCP/IP

TCP/IP 協議族

什麼是協議？
定義如何探測到通訊目標，由哪一方發起通訊，使用什麼語言通訊，怎樣結束通訊，不一樣的硬件、操做系統之間的通訊的規則。服務器

TCP/IP 是互聯網相關的各種協議族的總稱，包括各式內容，從電纜規格到 IP 地址的選定方法、尋找異地用戶的方法、雙方創建通訊的順序、以及 Web 頁面顯示須要處理的步驟等網絡

TCP/IP 的分層管理

TCP/IP 協議族分爲4層：應用層、傳輸層、網絡層和數據鏈路層
做用:ide

應用層：決定了向用戶提供應用服務時通訊的活動，HTTP 協議也處於該層
傳輸層：對上層應用層，提供處於網絡鏈接中的兩臺計算機之間的數據傳輸
網絡層：又名網絡互聯層，用來處理在網絡上流動的數據包
鏈路層：又名數據鏈路層、網絡接口層，用來處理鏈接網絡硬件部分（屬於硬件範圍）

TCP/IP 通訊傳輸流

利用 TCP/IP 協議族進行網絡通訊時，發送端（客戶端）從應用層往下走，接收端（服務端）從鏈路層網上走網站

用 HTTP 舉例：編碼

應用層（發送端）發送 HTTP 請求
傳輸層（TCP協議）把從應用層接收到的數據（HTTP報文）進行分割，並在各個報文上打上標記序號及端口號後發給網絡層
在網絡層（IP協議）增長做爲通訊目的的 MAC 地址後轉發給鏈路層（發往網絡的通訊請求就準備齊全了）
接收端在鏈路層接收到數據，按序網上層發送，達到應用層後，才能算真正接收到發送端發過來的請求

發送端在每層之間傳輸時，會打上該層所屬的首部信息；接收端在曾與層之間傳輸時，每通過一層會刪除對應的首部信息。
這種把數據包轉起來的作法叫作封裝

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

負責傳輸的 IP 協議

TCP/IP 協議族中的 IP 指的是網際協議。IP 協議的做用是把各類數據包傳送給對方，要保證確實傳送到對方哪裏，須要知足各種條件。其中兩個重要條件是 IP 地址和 MAC 地址（Media Access Control Address）。加密

IP 地址指明瞭節點被分配到的地址，MAC 地址是指網卡所屬的固定的地址。IP 地址能夠和 MAC 地址進行配對。IP 地址可變換，MAC 地址基本不會變。spa

使用 ARP 協議憑藉 MAC 地址進行通訊

IP 間的通訊依賴 MAC 地址。在網絡上，一般是通過多臺計算機和網絡設備中轉才能鏈接到對方，在中轉時，會利用下一站中轉設備的 MAC 地址來搜索下一個中轉目標，這是會採用 ARP 協議
（Address Resolution Protocol）。ARP 協議是一種以解析地址的協議，根據通訊雙方的 IP 地址就能夠查出對應的 MAC 地址。

確保可靠的 TCP 協議

TCP 協議位於傳輸層，提供可靠的字節流服務，所謂字節流服務是將大塊數據分割層以報文段爲單位的數據包進行管理，方便傳輸。

爲了確保準確無誤的送達目的地，TCP 採用三次握手策略，數據發送出去以後，必定的會向對方確認是否成功送達。握手的過程當中採用 TCP 的標誌——SYN（synchronize）和 ACK（acknowledgement）。

發送端首先發送一個帶 SYN 標誌的數據包給對方；接收端收到後，回傳一個帶有 SYN/ACK 標誌的數據包以示表達確認信息，最後發送端在回傳一個帶 ACK 標誌的數據包，表明握手結束。

若是某個階段莫名結束，TCP 協議會再次以相同順序發送相同的數據包。

負責域名解析的 DNS 服務

DNS（Domain Name System）服務是和 HTTP 協議同樣位於應用層的協議。它提供域名到 IP 地址之間的解析服務。

用戶一般經過域名來訪問網站，相比於 IP 地址，域名更符合人類的記憶習慣。DNS 服務便應運而生，逆向從 IP 地址反查域名服務。

各協議與 HTTP 協議的關係

URI 和 URL

URI（Uniform Resource Identifier）統一資源標識符
URL（Uniform Resource Locator）統一資源定位符

登陸信息：指定用戶名和密碼做爲服務器端獲取資源時必要的登陸信息（可選）
服務器地址：必須指定待訪問的服務器地址
服務器端口號：指定服務器鏈接的網絡端口號（可選，省略的話使用默認端口號）
帶層次的文件路徑：指定服務器上的文件路徑來定位特指的資源
查詢字符串：針對已指定的文件路徑內的資源，可使用查詢字符串傳入任意參數（可選）
片段標識符：使用片斷標識符一般可標記出以獲取資源中的資資源（可選）

第二章：簡單的 HTTP 協議

請求訪問文本或圖像等資源的一端稱爲客戶端，提供資源響應的一端稱爲服務器端。

HTTP 協議規定，請求從客戶端發出，服務端響應該請求並返回。

請求報文是由請求方法、請求URI、協議版本、可選的請求首部字段和內容實體構成的。

響應報文基本上由協議版本、狀態碼（表示成功或失敗的代碼）、以及解釋狀態碼的緣由短語、可選的響應首部字段以及實體主體構成。

HTTP 不保存狀態協議

HTTP 是一種不保存狀態，即無狀態協議。它自身不具有保存以前發送過的請求或響應的功能，爲了實現保持狀態的功能，引入了 Cookie 技術。

告知服務器意圖的 HTTP 方法

方法	用途	備註
GET	獲取資源
POST	傳輸實體主體
PUT	傳輸文件
HEAD	獲取報文首部
DELETE	刪除文件	響應返回的狀態碼是 204
OPTIONS	詢問支持的方法
TRACE	追蹤路徑
CONNECT	要求用隧道協議鏈接代理

向請求 URI 指定的資源發送請求報文時，採用稱爲方法的命令。方法名要用大寫字母。

持久鏈接節省通訊量

在 HTTP 初始版本中，因爲傳輸數據容量比較小，每進行一次 HTTP 通訊就要斷開一次 TCP 鏈接；
隨着 HTTP 普及，傳輸數據愈來愈大，未解決 TCP 鏈接問題，引入了持久鏈接（HTTP Persistent Connections，也成爲 HTTP keep-alive 或 HTTP connection reuse），特色是：只要任意一端沒有明確提出斷開鏈接，則保持 TCP 鏈接狀態。

管線化

持久化鏈接是的多數請求以管線化方式發送稱爲可能，能夠同時並行發送多個請求，而不須要一個接一個等待響應。

使用 Cookie 的狀態管理

Cookie 技術經過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態。
服務器在接受到請求後，在響應報文內加入 Set-Cookie，通知客戶端保存 Cookie，當下次在發送請求時，會在請求報文中加入 Cookie 後發送出去。服務器在根據發送過來的 Cookie 去對比，從而保存狀態信息。

第三章：HTTP 報文內的 HTTP 信息

用於 HTTP 協議交互的信息被稱爲 HTTP 報文，請求端（客戶端）的報文叫作請求報文，響應端（服務端）的叫作響應報文。

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

HTTP 報文大體可分爲報文首部和報文主體，二者之間由空行（CR+LF）來劃分。
請求報文

響應報文

請求行：包含用於請求的方法，請求 URI 和 HTTP 版本
狀態行：包含代表響應結果的狀態碼，緣由短語和 HTTP 版本
首部字段：包含代表請求和響應的各類條件和屬性的各種首部，通常有4種首部：通用首部、請求首部、響應首部、實體首部
其餘：可能包含 HTTP 的 RFC 裏未定義的首部，如：Cookie

編碼提高傳輸速率

HTTP 在傳輸數據時能夠按照數據原貌直接傳輸，也能夠在傳輸時經過編碼提高傳輸速率，但這樣會消耗更多的 CPU 等資源

報文主體和實體主體的差別

報文：是 HTTP 通訊中的基本單位，由8位組字節流（octet sequence，其中 octet 爲8個比特）組成，經過 HTTP 通訊傳輸。
實體：做爲請求或響應的有效載荷數據（補充項）被傳輸，其內容由實體首部和實體主體組成。

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

壓縮傳輸的內容編碼

內容編碼指明應用在實體內容上的編碼格式，並保存實體信息原樣壓縮。內容編碼後的實體由客戶端接收並負責編碼。

經常使用的內容編碼

gzip(GNU zip)
compress(UNIX 系統的標準壓縮)
deflate(zlib)
identity(不進行編碼)

分割發送的分塊傳輸編碼

在 HTTP 通訊過程當中，在傳輸大容量數據時，經過把數據分割成多塊，可以讓瀏覽器逐步顯示頁面的功能稱爲分塊傳輸編碼（Chunked Transfer Coding）。

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

HTTP 協議採用了多部分對象集合——MIME機制（Multipurpose Internet Mail Extensions，多用途因特網郵件擴展），它是一種容許處理文本、圖片、視頻等多種不一樣類型的數據。

在 HTTP 報文中使用多部分對象集合時，須要在首部字段里加上 Content-type，使用 boundary 字符串來劃分各個實體的起始行，須要在起始行前插入 "--" 標記，，最後以 "--" 結束。

獲取部份內容的範圍請求

指定範圍發送的請求叫作範圍請求

執行範圍請求會用到首部字段 Range 來指定資源的 byte 範圍

請求：
Range: bytes = 5001-10000

響應：
Content-Range: bytes 5001-10000/10000

針對範圍請求，響應會返回狀態碼爲 206 Partial Content 的響應報文，若是服務器沒法響應範圍請求，則會返回狀態碼 200 OK 和完成的實體內容。

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

同一個 Web 網站可能會存在多份相同內容的頁面，好比英文版和中文版，當瀏覽器默認語言爲中文時，訪問 URI 的 Web 頁面時，則會顯示中文版的 Web 頁面，這種機制稱爲內容協商（Content Negotiation）。

內容協商機制會在請求報文中用到下面首部字段：

Accept
Accept-Charset
Accept-Encoding
Accept-Language
Content-Language

內容協商技術有3種類型：

服務器驅動協商：由服務器端進行內容協商。以請求的首部字段爲參考，在服務端自動處理。
客戶端驅動協商：由客戶端進行內容協商。用戶利用瀏覽器提供的可選項列表手動選擇；還能夠利用 JavaScript 腳本在 Web 頁面上自動進行選擇。
透明協商：是服務器驅動和客戶端驅動的結合體，是由服務器端和客戶端各自進行內容協商的一種方法。

第四章：返回結果的 HTTP 狀態碼

狀態碼告知從服務器端返回的請求結果

狀態碼的職責是當客戶端向服務器端發送請求時，描述返回的請求結果。
狀態碼由三位數字和緣由短語組成，其中數字第一位指定了相應類別，後兩位無分類。

	類別	緣由短語
1XX	Informational(信息性狀態碼)	接收的請求正在處理
2XX	Success(成功狀態碼)	請求正常處理完畢
3XX	Redirection(重定向狀態碼)	須要進行附加操做以完成請求
4XX	Client Error(客戶端錯誤狀態碼)	服務器沒法處理請求
5XX	Server Error(服務器錯誤狀態碼)	服務器處理請求出錯

狀態碼

2XX 成功：表示請求被正常處理了
- 200 OK 表示從客戶端發來的請求在服務器端被正常處理了。
- 204 No Content 請求處理成功，返回的響應報文中不含實體的主體部分
- 206 Partial Content 表示客戶端進行範圍請求
3XX 重定向：代表瀏覽器須要執行某些特殊處理以正確處理請求
- 301 Moved Permanently 永久重定向
- 302 Found 臨時重定向
- 303 See Other 表示因爲請求對應的資源存在着另外一個 URI，應使用 GET 方法定向獲取請求的資源
- 304 Not Modified 表示客戶端發送附帶條件的請求，服務器端容許請求訪問資源，但因發生請求未知足條件的狀況後，直接返回 304 Not Modified。304 狀態碼返回時，不包含任何響應的主體部分，304 雖然被劃分在 3XX 類別中，但和重定向沒有關係
- 307 Temporary Redirect 臨時重定向，和 302 差很少，它不會把 POST 變成 GET
4XX 客戶端錯誤：代表客戶端發生錯誤的緣由所在
- 400 Bad Request：表示請求報文中存在語法錯誤
- 401 Unauthorized：表示發送的請求須要有經過 HTTP 認證的認證信息
- 403 Forbidden：表示請求資源被服務器拒絕了
- 400 Not Found：表示服務器上沒法找到請求資源
5XX 服務器錯誤：代表服務器自己發生錯誤
- 500 Internal Server Error：表示服務器在執行請求時發生了錯誤
- 503 Serveice Unavailable：表示服務器暫時處於超負荷或正在停機維護，沒法處理請求。

第五章：與 HTTP 協做的 Web 服務器

HTTP/1.1 容許一臺 HTTP 服務器搭建多個 Web 站點
在互聯網上，域名經過 DNS 服務映射到 IP 地址以後訪問目標網站，在相同 IP 下，發送 HTTP 請求時，必須在 Host 首部內完整指定主機名和域名的 URI

通訊數據轉發程序：代理、網關、隧道

代理：是一種有轉發功能的應用程序，它扮演了位於服務器和客戶端「中間人」的角色
網關：網關是轉發其餘服務器通訊數據的服務器，接受從客戶端發來的請求時，它就像本身擁有資源的源服務器同樣對請求進行處理
隧道：相隔甚遠的客戶端和服務器二者之間進行中轉，並保持雙方通訊鏈接的應用程序

代理

使用代理服務器的理由：利用緩存技術減小網絡帶寬的流量，組織內部針對特定網站的訪問控制，以獲取訪問日誌爲主要目的

緩存代理：代理轉發時，緩存代理會預先將資源的副本緩存到代理服務器上，當代理再次接收到相同資源的請求時，就能夠不從源服務器那裏獲取資源，而是將緩存的資源做爲響應返回

透明代理：轉發請求或響應時，不對報文作任何加工的代理類型稱爲透明代理

網關：

網關能使通訊線路上的服務器提供非 HTTP 協議服務。
利用網關能提升通訊的安全性

隧道

隧道的目的是確保客戶端能與服務器進行安全的通訊，隧道自己不會去解析 HTTP 請求，隧道會在通訊雙方斷開鏈接時結束

保存資源的緩存

緩存是指代理服務器或客戶端本地磁盤內保存的資源副本。利用緩存可減小對源服務器的訪問，所以也節省了通訊流量和通訊時間。

緩存的有效期

緩存服務器內緩存室友有效期的，若是資源更新，緩存就沒有用了，須要從新獲取新的資源
客戶端的緩存同緩存服務器同樣

第六章：HTTP 首部

HTTP 協議的請求和響應報文中必須一定包含 HTTP 首部。首部內容爲請求或響應所須要的信息

HTTP 請求報文由方法、URI、HTTP 版本、HTTP 首部字段等部分構成
HTTP 響應報文由 HTTP 版本、狀態碼、HTTP 首部字段組成

HTTP 首部字段

HTTP 首部字段是構成 HTTP 報文的要素之一。使用首部字段是爲了給瀏覽器和服務器提供報文主體大小、所使用的語言、認證信息等內容。

4種 HTTP 首部字段類型

通用首部字段：請求報文和響應報文都會使用的首部
請求首部字段：從客戶端向服務器端發送請求報文時使用的首部
響應首部字段：從服務器端向客戶端返回響應報文時使用的首部
實體首部字段：針對請求報文和響應報文的實體部分使用的首部

通用首部字段

首部字段名	說明
Cache-Control	控制緩存的行爲
Connection	逐跳首部、鏈接的管理
Date	建立報文的日期時間
Pragma	報文指令
Trailer	報文末端的首部一覽
Transfer-Encoding	指定報文主體的傳輸編碼方式
Upgrade	升級爲其餘協議
Via	代理服務器的相關信息
Warning	錯誤通知

請求首部字段

首部字段名	說明
Accept	用戶代理可處理的媒體類型
Accept-Charset	優先的字符集
Accept-Encoding	優先的內容編碼
Accept-Language	優先的語言（天然語言）
Authorization	Web 認證信息
Expect	期待服務器的特定行爲
From	用戶的電子郵箱地址
Host	請求資源所在的服務器
If-Match	比較實體標記（ETag）
If-Modified-Since	比較資源的更新時間
If-None-Match	比較實體標記（與If-Match相反）
If-Range	資源未更新時發送實體 Byte 的範圍請求
If-Unmodified-Since	比較資源的更新時間（與 If-Modified-Since 相反）
Max-Forwards	最大傳輸逐跳數
Proxy-Authorization	代理服務器要求客戶端的認證信息
Range	實體的字節範圍
Referer	對請求中 URI 的原始獲取方
TE	傳輸編碼的優先級
User-Agent	HTTP 客戶端程序的信息

響應首部字段

首部字段名	說明
Accept-Ranges	是否接收字節範圍請求
Age	推算資源建立通過時間
ETag	資源的匹配信息
Location	令客戶端重定向至指定 URI
Proxy-Authenticate	代理服務器對客戶端的認證信息
Retry-After	對再次發起請求的時機要求
Server	HTTP 服務器的安裝信息
Vary	代理服務器緩存的管理信息
WWW-Authenticate	服務器對客戶端的認證信息

實體首部字段

首部字段名	說明
Allow	資源可支持的 HTTP方法
Content-Encoding	實體主體適用的編碼方式
Content-Language	實體主體的天然語言
Content-Length	實體主體的大小（單位：字節）
Content-Location	替代對應資源的 URI
Content-MD5	實體主體的報文摘要
Content-Range	實體主體的位置範圍
Content-Type	實體主體的媒體類型
Expires	實體主體過時的日期時間
Last-Modified	資源的最後修改日期時間