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

weixin_34402408發表於2017-10-18
圖解HTTP筆記協議

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

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

簡單的http協議

  • 通訊是從客戶端開始建立的，客戶端向服務端傳送請求，服務端響應請求並且返回資料。那麼就是通過請求和響應的交換達成通訊。

  • 客戶端傳送請求的例子：

      GET /index.html HTTP/1.1
  HOST: hackr.jp

    GET表示請求的方式、方法（method），/index.html表示請求指定資源，稱為URI（request-URI），最後HTTP/1.1表示客戶端使用的協議版本。

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

  • 伺服器響應的例子：

    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： 建立響應的時間
    下面就是首部欄位，然後空一行就是內容實體。

告知伺服器意圖的HTTP方法

  • GET 獲取資源

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

  • POST 傳輸實體主體

    向伺服器傳輸主體，POST的主要目的並不是獲取響應的主體內容。

  • PUT 傳輸檔案

  • HEAD 獲取報文的首部

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

  • 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連線，以當年通訊情況來說，因為都是容量小的文字傳輸，所以即使這樣也沒有什麼問題，但是現在來看，文件中包含大量的圖片是很平常的需求，所以這種通訊一次就斷掉的方法就不可取了。

4061613-5475b7563c95d190.png
連線一次斷開一次.png

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

    4061613-54b7485ece335706.png
    持續連線.png

在HTTP/1.1中，所有的預設連線都是持久連線，在HHTP/1.0中並沒有標準化。客戶端和服務端需要同時支援持久化才行。

使用Cookie的狀態管理

  • HTTP是無狀態協議，它不對之前發生過的請求和響應的狀態進行管理。也正是因為這一特性，自然可以減少伺服器的CPU及記憶體資源的消耗。從另一側面來說，也正是HTTP協議本事是非常簡單的，所以才會被應用在各種場景中。

  • 需要記錄狀態的場景：假設要求登入認證的Web頁面本身無法進行狀態管理（不記錄的狀態），那麼每次跳轉新頁面就要再次登入，或者要在每次請求報文中附加引數來管理登入狀態。

    4061613-aced9370e8db0a03.png
    如果讓伺服器管理全部客戶端狀態則會成為負擔

  • 在保留無狀態這個特性的同是又要解決類似的矛盾問題，於是引入了Cookie技術。Cookie是通過在請求和響應報文中寫入Cookie資訊來控制客戶端的狀態。

  • Cookie 會根據從服務端傳送的響應報文內的一個叫做Set-Cookie的首部欄位資訊，通知客戶端儲存Cookie。當下次客戶端再往該伺服器傳送請求時，客戶端會自動在請求報文中加入Cookie值後傳送出去。伺服器端發現客戶端發過來的請求中包含Cookie資訊，拿著Cookie資訊去伺服器上的記錄對比，來確定是哪一個客戶端，做相應的操作。

  • 4061613-b20afc3bdf94b335.png
    沒有Cookie.png
  • 4061613-b392b8d06a86b03a.png
    第二次請求帶Cookie.png

相應的頭部：

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，歡迎討論

相關文章