《圖解 HTTP》摘要一

Felix_CAI發表於2020-05-02

圖解HTTP

學習過程對書本的內容的摘要以及總結，逐步完善，帶有個人理解成分。

Web 及網路基礎

使用 HTTP 協議訪問 Web

客戶端：通過獲取請求獲取服務資源的 Web 瀏覽器等
HTTP 全稱：HtyperText Transfer Protocol
WWW 全稱：Wrold Wide Web
SGML 標準通用標記語言全稱：Standard Generalized Markup Language

網路基礎 TCP/IP

TCP/IP 協議族，或指TCP、IP
協議族常見協議：TCP、UDP、IP、PPPoE、DNS、SNMP、ICMP 等

TCP/IP 的分層管理

分為四層：應用層、傳輸層、網路層、資料鏈路層

應用層

決定了向使用者提供應用服務時通訊的活動
預存了各類通用的應用服務。如：DNS、FTP
HTTP 協議也在該層

傳輸層

對上層應用層，提供處於網路連線中的兩臺計算機之間的資料傳輸協議
TCP、UDP在其中

網路層（網路互連層）

處理網路上的流動資料包。
資料包：網路傳輸的最小單位。
規定了通過了怎樣的傳輸路徑（傳輸路線）到達對方的計算機，並把資料包給對方。

鏈路層（資料鏈路層、網路介面層）

處理連線網路的硬體部分。
例如：控制作業系統、硬體的裝置驅動、光纖等，硬體範圍。

TCP/IP 通訊傳輸流

傳送端：應用層往下走。接受端相反
傳送端：層與層之間傳輸資料的時候會把對應的首部資訊打上。反之消去首部。
把資料包裝起來的做法叫封裝。

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

負責傳輸的 IP 協議

IP：Internet Protocol 位於網路層的網際協議。
把各自資料包傳送給對方。
要保證確實傳輸到對方那裡，需要滿足各類條件。其中兩個重要的是：IP 地址和 MAC 地址（Media Access Control Address）。IP 地址指明瞭節點被分配的地址，MAC 地址是指網路卡所屬的固定地址。
IP 地址可和 MAC 地址相互匹配，IP 地址可變換， MAC 地址基本上不會更改。

使用ARP協議（Address Resolution Protrocol）協議

是一種用以解析地址的協議。
根據通訊方的IP地址就可以反查出對應的 MAC 地址。

確保可靠性的 TCP 協議

位於傳輸層，提供可靠的位元組流服務。
位元組流服務：為方便傳輸，將大塊的資料分割成報文段（segment）為單位的資料包進行管理。（為了傳輸大資料才將資料進行分割）
可靠的服務：把資料準確的傳輸給對方。
確保能到達目標。
- 採用三次握手策略（three-way handshaking）策略。
- 使用了 TCP 標誌：(flag)—SYN(synchronize) 和 ACK(ackonwledgement)

負責域名解析的 DNS 服務

DNS（Domain Name System）是位於應用層的協議。同 HTTP 一樣。
提供域名到 IP 地址之間的解析服務。可逆向查詢。
計算機可被賦予 IP 地址，也可被賦予主機名和域名。通常用主機名或域名，因為符合人類記憶習慣。

各種服務與 HTTP 協議的關係

想想想想

URI 和 URL

URI：Uniform Resource Identifier 統一資源識別符號。
- Uniform 規定統一的格式，方便處理多種不同型別的資源。
- Resource 資源的定義是“可標識的任何東西”。除文件檔案、圖形或服務等能夠區別與其他的，全部可做資源。資源不僅可單一，也可以是多數的集合體。
- Identifier 表示可標識的物件。也稱識別符號。
- 就是由某個協議方案表示的資源定位符。協議方案是指訪問資源時使用的協議的型別名稱。例如：採用 HTTP 協議的時候，協議方案就是 http。除此之外，還有ftp、file等30多種。

URI 用字串標識著某一網際網路資源，URL 表示資源的地點。

可見，URL 是 URI 的子集。

URL：Uniform Resource Locator 統一資源定位符。

URI 格式

表示指定的 URL ，要使用涵蓋全部必要資訊的 絕對 URL 、絕對 URL 以及相對 URL 以及相對 URL 。相對 URL ，是指從瀏覽器中基本 URL 處指定的 URL，形如 /image/logo.gif

絕對 URL 的格式：

http:// user:pass @ www. exanple.jp: 80 / dir/index.htm ? uid=1 # ch1

http:// 協議方案名。不區分大小寫。
user:pass 登入資訊（認證）。可選資訊。
www. exanple.jp: 伺服器地址。
- 使用絕對的URL必須指定待訪問的伺服器地址。
- 地址可以是類似 hackr.jp 這種DNS 可解析的名稱，也可以是 192.168.1.1 這種類似 IPv4 地址名，還可以是 [0:0:0:0:0:0:0:1]這種方括號括起來的 IPv6 地址名。
80 伺服器埠號。可選項。省略則使用預設的埠號。
dir/index.htm 帶層次的檔案路徑。與 UNIX 系統的檔案目錄結構類似。
uid=1 查詢字串。針對已指定的檔案路徑內的資源。可選。
ch1 片段識別符號。通常可標記出已獲取資源的子資源。可選。 RFC 中沒有規定其使用方法。

RFC（Request for COmments）徵求修正意見書

制定 HTTP 協議技術標準的文件。

簡單的 HTTP 協議

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

必定是一端擔任客戶端角色，另一端擔任伺服器角色。

通過請求和響應的交換達成通訊

請求必定由客戶端發出，服務端回覆

例項：

客戶端發給某個伺服器的請求報文中的內容。

GET /index.htm HTTP/1.1

Host : hacker.jp

GET 請求訪問伺服器的型別，稱為方法(method)。
/index.htm 指明瞭訪問的資源物件。稱為請求URI(request-URI)。
HTTP/1.1 是 HTTP 的版本號。

意思是：請求訪問某臺 HTTP 伺服器上的 /index/htm 頁面資源

// 伺服器
HTTP/1.1 200 OK
Date: Tue, 1 Jan 2020 08:00:01 GMT
Content-Length: 362
Content-Type: text/html

...

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

HTTP/1.1 表示服務對應的 HTTP 版本。
200 OK 表示請求的處理結果的狀態碼(status code)和原因短語(reason-phrase)。
下一行顯示響應的時間，是首部欄位(header field)內的一個屬性。
接下來，空一行 分隔，之後的內容稱為資源實體的主體(enntity field)
GMT 是響應首部欄位。

HTTP 是不儲存狀態的協議

無狀態協議(stateless)
HTTP 這個級別，協議對於傳送請求或響應都不做持久化處理。
每當有新的請求，即產生新的響應，不儲存之前的響應報文資訊。
為了保持狀態，引入 Cookie 技術。

請求 URL 定位資源

型別很多種。。。

如果不是訪問特定的資源，而是對伺服器本身發起請求，可以用一個 * 來代替請求URI。例如：

OPTIONS * HTTP/1.1

告知伺服器意圖的 HTTP 方法

GET ：獲取資源

GET 方法用來請求訪問已被 URI 識別的資源。
指定的資源經服務端解析後返回響應內容。如果請求資源是文字，那就保持原樣返回；如果是像 CGI(Common Gateway Interface) 通用閘道器介面那樣的程式，則返回經過執行後的輸出結果。

例子：

請求	Get /index.html http/1.1
響應	返回 index.html 的頁面資源

請求	Get /index.html http/1.1 Host: www.hackr. jp if-modified-since: thu, 1 jan 2020 08:20:01 gmt
響應	僅返回2020年1月1日8點20分以後更新過的index頁面資源。

POST：傳輸實體主體

用來傳輸實體的主體。

例子：

請求	post /submit.cgi http/1.1 Host: www.hackr. jp content-length:1560（1560位元組的資料）
響應	返回 submit.cgi 接收資料的處理結果

PUT：傳輸檔案

傳輸檔案，像 FTP 一樣。
要求在請求報文主體中包含檔案內容，然後儲存到請求 URI 制定的位置。
HTTP/1.1 自身不帶驗證機制。存在安全問題，一般不用。
若配合 Web 應用程式的驗證機制，或採用 REST(REpresentational State Transfer，表徵狀態轉移) 標準的同類 Web 網站，可能會使用。

例子：

請求	put /example.html http/1.1 host: www.hackr .jp content-type: text/html content-length: 1560 (1560位元組的資料)
響應	響應返回狀態碼 204 Not Content （比如：該 html 已存在於伺服器上）

HEAD：獲得報文首部

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

例子：

請求	head /index.html http/1.1 host: www.hackr .jsp
響應	返回 index.html有關的響應首部

DELETE：刪除檔案

用來刪除檔案，是與 PUT 相反的方法。
但是和 HTTP/1.1 一樣，不帶驗證機制，所以一般的 Web 網站也不使用 DELETE 方法。
當配合 Web 應用程式的驗證機制，或遵循 REST 標準時還是有可能會開放使用。

例子：

請求	DELETE /example.html HTTP/1.1
響應	響應返回狀態碼 204 No Content （比如：該 html 已從該伺服器上刪除）

OPTIONS：詢問支援的方法

例子：

請求	OPTIONS * HTTP/1.1 Host:www.hackr .jp
響應	HTTP/1.1 200 OK Allow: GET, POST, HEAD, OPTIONS（返回伺服器支援的方法）

TRACE：追蹤路徑

讓 Web 伺服器端將之前的請求通過通訊迴環給客戶端的方法。
在 Max-Forwards 首部欄位中填入數值，每經過一個伺服器就將該數字減1，當數字減到 0 時，就返回狀態碼 200 OK 的響應。
客戶端通過 TRACE 方法查詢傳送出去的請求是怎樣被加工修改/篡改的。因為請求連線到源目標伺服器可能會通過代理中轉，TRACE 方法就是用來確認連線過程中發生的一系列操作。
不常用。易引發 XST（Cross-Site Tracing，跨站追蹤）攻擊。

例子：

請求	TRACE / HTTP/1.1 Host: hackr.jp Max-Forwards:2
響應	HTTP/1.1 200 OK Content-Type: message/http TRACE / HTTP/1.1 Host: hackr.jp Max-Forwards:2 （返回響應包含的請求內容）

CONNECT：要求要用隧道協議連線代理

要求在與代理伺服器通訊時建立隧道，實現用隧道協議進行 TCP 通訊。
主要使用 SSL (Secure Sockets Layer，安全套接層) 和 TLS（Transport Layer Security，傳輸層安全）協議把通訊內容加密後經網路隧道傳輸。
語法格式：CONNECT 代理服務名：埠號 HTTP版本

例子：

請求	CONNECT proxy.hackr.jp:8080 HTTP/1.1 Host: proxy.hackr.jp
響應	HTTP/1.1 200 OK（之後進入網路隧道）

使用方法下達命令

向請求 URI 制定的資源傳送請求報文時，採用成為方法的命令。
方法的作用在於，可以指定請求的資源按期望產生某種行為。方法中有 GET、POST 和 HEAD 等。

支援的方法

方法	說明	支援的 HTTP 協議版本
GET	獲取資源	1.0、1.1
POST	傳輸實體主體	1.0、1.1
PUT	傳輸檔案	1.0、1.1
HEAD	獲取報文首部	1.0、1.1
DELETE	刪除檔案	1.0、1.1
OPTIONS	詢問支援的方法	1.1
TRACE	追蹤路徑	1.1
CONNECT	要求用隧道協議連線代理	1.1
LINK	建立和資源之間的聯絡	1.0
UNLINE	斷開連線關係	1.0

持久連線節省通訊量

之前的情況：每進行一次 HTTP 通訊就要斷開一次 TCP 連線。

持久連線

持久連線（HTTP Persistent Connections）,也稱為 HTTP keep-alive 或 HTTP connection reuse。
特點：只要任意一端沒有明確提出斷開連線，則保持 TCP 連線狀態。
在 HTTP/1.1 中所有的連線預設都是持久連線。

管線化

使用管線化技術，不用等待響應即可直接傳送下一個請求

HTTP 協議，無協議也有好處，簡單才會被更多的應用。

Cookie 技術：通過在請求和響應報文中寫入 Cookie 資訊來控制客戶端的狀態。

Cookie 會根據從伺服器端傳送的響應報文內的一個叫 Set-Cookie 的首部欄位資訊，通知客戶端儲存 Cookie。

下次再客戶端再往該伺服器傳送請求時，客戶端會自動再請求報文中加入 Cookie 值後傳送出去。

HTTP 請求報文和響應報文內容如下：

1.請求報文（沒有 Cookie 資訊的狀態）

GET /reader/ HTTP/1.1

Host: hackr.jp

首部欄位內沒有 Cookie 的相關資訊

2.響應報文（伺服器端生成 Cookie 資訊)

HTTP /1.1 200 OK

Date: Tue, 1 Jan 2020 08:10:01 GMT

Sever: Apache

<Set-Cookie:sid=13420770140226734; pa+10-jan-11 08:10:01 GMT>

content-Type: text/plain; charaset=UTF-8

3.請求報文

GET /image/ HTTP/1.1