《圖解HTTP》筆記

時間 2020-05-07

原文原文鏈接

1、背景

最近項目採用的HTTP協議傳輸，我從未涉及過HTTP的基礎理論知識，所以在網上找到一本也很意思的《圖解HTTP》，它的圖文並茂生動形象解釋了HTTP的基礎知識，不會一味的枯燥無味，對咱們這種小白喜歡看書犯困來講，很是的友好，《圖解HTTP》共分爲11章，如下內容分享讀書筆記。瀏覽器

2、圖解HTTP

第1章瞭解Web及網絡基礎

本章概述了Web是創建在何種技術之上，以及HTTP協議是如何誕生併發在的。安全

Web 和HTTP的誕生

1989年3月，爲知識共享而規劃Web，隨着Web的誕生，HTTP協議也就誕生了，只是那時候還不成熟，而且在這以後的好久都不成熟，直到1996年5月發展正式標準版本HTTP/1.0，1997年1月公佈HTTP/1.1是目前主流的HTTP協議版本。服務器

網絡基礎TCP/IP

1. TCP/IP協議族，包括IEEE 802.3 、ICMP 、IP、PPPoE、DNS、UDP、SNMP、FTP、HTTP、FDDI、TCP等協議。cookie

2. TCP/IP協議族的按層次分4層：應用層（FTP、DNS、HTTP）、傳輸層（TCP、UDP）、網絡層（IP）和數據鏈路層（NIC(Network Interface Card)網卡，光纖等物理設備）。網絡

3. TCP/IP協議族各層的做用:session

l 應用層決定了向用戶提供應用服務時通訊的活動。併發

l 傳輸層對上層應用層，提供處於網絡鏈接中的兩臺計算機之間的數據傳輸。異步

l 網絡層（又名網絡互連層）用來處理在網絡上流動的數據包。性能

l 鏈路層（又名數據鏈路層，網絡接口層）用來處理鏈接網絡的硬件部分。學習

4. TCP/IP通訊傳輸流

如圖所示，利用TCP/IP協議族進行網絡通訊時，會經過分層順序與對方進行通訊。發送端從應用層往下走，接收端則往應用層往上走。

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

①負責傳輸的IP協議

a. IP協議的做用是把各類數據包傳送給對方。

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

② TCP協議採用了三次握手（three-way handshaking）策略（三次握手四次揮手）

③負責域名解析的DNS服務

6. URl（Uniform Resource Identifier，統一資源標識符）和URLUniform Resource Locator，統一資源定位符）

URL格式：

7. 專業詞全稱：TCP（Transmission Control Protocol，傳輸控制協議）和UDP（User Data Protocol，用戶數據報協議）

第2章簡單HTTP協議

本章針對HTTP協議結構講解，主要使用HTTP1.1，理解HTTP協議的基礎了。

HTTP協議用於客戶端和服務器端之間的通訊

1. 客戶端發送request請求，服務端迴應respons；

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

b. HTTP通訊過程包括從客戶端發往服務器端的請求（Request）及從服務器端返回客戶端的響應（Response）。

2. 請求報文構成和響應報文構成

3. HTTP是不保存狀態的協議，Cookie技術經過在請求和響應報文中寫入Cookie信息來控制客戶端的狀態。

4. HTTP的客戶端請求方法，包括：GET、POST、PUT、HEAD、DELETE和不經常使用的OPTIONS、TRACE、CONNECT

5. 持久鏈接指的是，爲了解決TCP的三次握手和四次揮手耗時問題，即在第一次創建好鏈接後，在沒有斷開參數的狀況下，HTTP請求仍在第一次建立的鏈接裏面發送消息；

第3章 HTTP報文內的HTTP信息

本章主要了解一下請求和響應是怎麼運做的以及HTTP報文是什麼樣的。

1. HTTP報文：用於HTTP協議交互的信息。請求端（客戶端）的HTTP報文叫作請求報文，響應端（服務器）的叫作響應報應。

2. 請求報文和響應報文的結構以及實例：

3. HTTP報文的主體用於傳輸請求或響應的實體主體。

4. 編碼提高傳輸速率；

除此以外，還能夠把數據包分爲多個部分傳輸，在報文首部中加以區分，以及不一樣瀏覽器，相應不一樣的返回報文；

第4章返回結果的HTTP狀態碼

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

2. 2XX成功

l 200 OK（請求正常處理）

l 204 No Content（請求處理成功，沒有資源可返回）

l 206 Partial Content（範圍請求）

3. 3XX重定向

l 301 Moved Permanently（永久性重定向）

l 302 Found（臨時性重定向）

l 303 See Other

l 304 Not Modified

l 307 Temporary Redirect（臨時重定向）

4. 4XX客戶端錯誤

l 400 Bad Request（請求報文中存在語法錯誤）

l 401 Unauthorized（發送的請求須要有經過HTTP認證）

l 403 Forbidden（請求資源的訪問被服務器拒絕）

l 404 Not Found（服務器上沒法找到請求的資源）

5. 5XX服務器錯誤

l 500 Internal Server Error（服務器端在執行請求時發生了錯誤）

l 503 Service Unavailable（服務器暫時處於超負載或正在進行停機維護，如今沒法處理請求。）

第5章與HTTP協做的Web服務器

1. 一臺Web服務器可搭建多個獨立域名的Web網站，也可做爲通訊路徑上的中轉服務器提高傳輸效率。

2. HTTP通訊時，除客戶端和服務器之外，還有一些用於通訊數據轉發的應用程序，例如代理、網關和隧道。

第6章 HTTP首部

在第三章簡單介紹了HTTP的報文信息，也簡單介紹HTTP首部，本章詳細講解HTTP首部的結構，以及首部中各字段的用法。

這章能夠當作手冊使用，當遇到須要時具體查詢。

第7章確保Web安全的HTTPS

HTTP爲何不安全

經過前面幾章學習，知道了HTTP的優點，第七章說說HTTP的缺點以及如何解決這些缺點。

1. 通訊使用明文（不加密），內容可能會被竊聽；

2. 不驗證通訊方的身份，所以有可能遭遇假裝；

3. 沒法證實報文的完整性，因此有可能已遭篡改；

HTTPS是什麼

HTTP+加密+認證+完整性保護=HTTPS

HTTPS如何保證安全

1. 服務端在數字證書認證機構把本身的公鑰經過認證機構的私鑰加密得到服務器本身的公鑰證書；

2. 客戶端拿到第1步服務器的公鑰證書後，使用認證機構提供的公鑰，向認證機構驗證公鑰證書上的數字簽名，以確認服務器的公開密鑰的真實性；

3. 客戶端使用服務端的公開密鑰對報文加密發送；

4. 服務端用私有密鑰對報文解密；

第8章確認訪問用戶身份的認證

Web頁面只想特定的人瀏覽，須要加入權限認證功能，本章講解HTTP使用4種的認證方式。

BASIC認證（基本認證）

1. 客戶端請求；

2. 服務端返回401狀態碼；

3. 客戶端用Base64編碼發送用戶ID和密碼；

4. 服務端認證成功返回200；

DIGEST認證（摘要認證）

1. 客戶端發送請求

2. 服務端返回401+質詢碼（一般爲隨機數，實際依賴服務端實現）

3. 客戶端在請求首部Authorization信息中加入用戶名密碼等信息，以及經過質詢碼計算出的響應碼（計算方法比較複雜，具體詳見RFC2617）

4. 服務端認證成功返回200；

SSL客戶端認證

結合第七章HTTPS的安全性來說，SSL須要購買證書。
SSL的認證是保證通信過程的安全，防止經過form表單提交的密碼等信息被監聽。

FormBase認證（基於表單認證）

這是咱們最經常使用的，就是用戶名密碼登陸認證；

1. 客戶端發送用戶名密碼；

2. 服務端驗證經過，在服務端保存的sessionID，用於表示是哪一個客戶端，並將sessionID發送給客戶端；

3. 客戶端收到sessionID保存到cookie中，下次請求直接發送cookie中的sessionID，而不用在輸入密碼了。（若是別人知道你的sessionID，也就能夠經過該sessionID獲取你的信息了，因此，sessionID大多都有過時時間）。

第9章基於HTTP的功能追加協議

HTTP協議自HTTP/1.1以後，這麼多年一直都在用1.1版本，第九章主要講在HTTP協議基礎之上的改進。

SPDY

Google在2010年發佈了SPDY，解決HTTP的性能瓶頸，縮短Web頁面的加載時間（50%）。

HTTP的瓶頸在於每次請求，頁面都要總體刷新一遍，有時僅僅在於只改動一點點。基於此，有了Ajax技術。

Ajax（Asynchronous JavaScript and XML，異步JS和XML），本質值客戶端局部請求服務端，從而局部刷新頁面，提升使用體驗。
Comet，與Ajax相反，Comet是服務端向客戶端發送變化的數據。
SPDY是在會話層的網絡協議，HTTP是在應用層。具體對協議作了一些改動從而提升性能。