《圖解HTTP》學習筆記（二）：簡單的HTTP協議

時間 2019-12-11

標籤圖解HTTP 學習筆記簡單 http 協議欄目 HTTP/TCP 简体版

原文原文鏈接

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

請求訪問文本或圖像等資源的一端稱做爲客戶端，而提供資源的一端稱做爲服務端。
在一條HTTP通訊線路上，客戶端和服務端是肯定，必須有一端是客戶端和有一端是服務端。實際狀況中，客戶端、服務端的角色可能會互換，可是從僅從一條通訊線路上說，這兩端是肯定的。
HTTP是不保存狀態的協議HTTP協議自身不對請求和響應之間的通訊狀態進行保存。

簡單的http協議

通訊是從客戶端開始創建的，客戶端向服務端發送請求，服務端響應請求而且返回數據。那麼就是經過請求和響應的交換達成通訊。
客戶端發送請求的例子：html
```
GET /index.html HTTP/1.1
  HOST: hackr.jp
```
GET表示請求的方式、方法（method），/index.html表示請求指定資源，稱爲URI（request-URI），最後HTTP/1.1表示客戶端使用的協議版本。git

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

服務器響應的例子：安全

HTTP/1.1 200 ok
Date: Tue, 10 Jul 2012 06:50:15 GMT
Content-Length: 363
Content-Type: text/html

<html>
...

HTTP/1.1：服務器的協議版本服務器

200 ok：響應的狀態碼和緣由短語（簡短的解釋）
Date: Tue, 10 Jul 2012 06:50:15 GMT：建立響應的時間
下面就是首部字段，而後空一行就是內容實體。cookie

告知服務器意圖的HTTP方法

GET 獲取資源

GET方法用來請求已被已被URI識別（存在的）的資源。指定的資源經服務器解析後返回響應內容。網絡

POST 傳輸實體主體

向服務器傳輸主體，POST的主要目的並非獲取響應的主體內容。加密

PUT 傳輸文件
HEAD 獲取報文的首部

與GET相似，只是響應不會返回報文主體部分，只有頭部。spa

DELETE 刪除文件
OPTIONS 詢問支持的方法

用來查詢針對請求URI指定的資源支持的方法。
好比：代理

// 請求
OPTIONS * HTTP/1.1
Host: www.hackr.jp
// 響應
HTTP/1.1 200 OK
Allow: GET,POST,HEAD,OPTIONS

TRACE 追蹤路徑

客戶端經過TRACE方法能夠查詢發出去的請求是怎麼被加工修改、篡改的。一個請求想要鏈接到原目標服務器可能經過代理中轉，TRACE方法就是用來確認鏈接過程當中發生的一系列的操做。可是TRACE方法原本不怎麼經常使用，在加上它容易引起XST（Cross-Site Tracing，跨站追蹤）攻擊，一般就更不會使用了

CONNECT 要求用隧道協議鏈接代理

要求在與代理服務器通訊時創建隧道，實現用隧道協議進行TCP通訊。主要使用SSL（Secure Sockets Layer，安全套裝層）和TSL（Transport Layer Security，傳輸層安全）協議把通訊內容加密後經網絡隧道傳輸。

持久鏈接節省通訊量

HTTP初期的版本中，每進行一次通訊就要斷開一次TCP鏈接，以當年通訊狀況來講，由於都是容量小的文本傳輸，因此即便這樣也沒有什麼問題，可是如今來看，文檔中包含大量的圖片是很日常的需求，因此這種通訊一次就斷掉的方法就不可取了。

爲解決以上TCP通訊問題，HTTP/1.1和一部分HTTP/1.0想出了持久鏈接（HTTP Persistent Connections，也稱爲HTTP keep-alive或HTTP connection reuse）的方法。持久鏈接的特色是，只要任意一方沒有提出明確的斷開鏈接，則保持TCP鏈接狀態。

在HTTP/1.1中，全部的默認鏈接都是持久鏈接，在HHTP/1.0中並無標準化。客戶端和服務端須要同時支持持久化才行。

使用Cookie的狀態管理

HTTP是無狀態協議，它不對以前發生過的請求和響應的狀態進行管理。也正是由於這一特性，天然能夠減小服務器的CPU及內存資源的消耗。從另外一側面來講，也正是HTTP協議本事是很是簡單的，因此纔會被應用在各類場景中。
須要記錄狀態的場景：假設要求登陸認證的Web頁面自己沒法進行狀態管理（不記錄的狀態），那麼每次跳轉新頁面就要再次登陸，或者要在每次請求報文中附加參數來管理登陸狀態。

在保留無狀態這個特性的同是又要解決相似的矛盾問題，因而引入了Cookie技術。Cookie是經過在請求和響應報文中寫入Cookie信息來控制客戶端的狀態。
Cookie 會根據從服務端發送的響應報文內的一個叫作Set-Cookie的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入Cookie值後發送出去。服務器端發現客戶端發過來的請求中包含Cookie信息，拿着Cookie信息去服務器上的記錄對比，來肯定是哪個客戶端，作相應的操做。

相應的頭部：

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

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

2.響應報文（服務器生成Cookie信息）

HTTP/1.1 200 OK
Date: Thu, 12 Jul 2012 07:12:20 GMT
Server: Apache
<Set-Cookie: sid=1123423543234325; path=/; expires=Wed,10-Oct-12 07:12:20 
GMT>
Content-Type: text/plain; charset=UTF-8

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

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

github 歡迎Star，歡迎討論

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。