簡述HTTP

SniperPan發表於2018-01-12
HTTP

HyperText Transfer Protocol(HTTP)

HTTP是一個用於傳輸超媒體文件（hypermedia documents）的應用層協議，其主要使用場景是網路瀏覽器和網路伺服器之間進行通訊。

簡述HTTP

1. 資訊內容：Web Page

瀏覽器中顯示的頁面叫做網頁(Web Page)，其通常由如下兩部分構成：

  • HTML檔案，描述物件和佈局等資訊

  • 物件，單個頁面中可能包含多個物件，這些物件可以是圖片、檔案、視訊等。物件可能以URL形式給出

1.1 Hypertext Markup Language(HTML)

Hyper means over or above , 即"超"的意思。所謂超媒體、超文字，意指包括但不限於的意思。典型的超媒體文件型別為HTML。

HTML是一種用於建立網頁的標準標記語言，和CSS、JavaScript一起構建了全球資訊網（World Wide Web, WWW）的基礎。通常我們可以按如下形式來理解三者的關係：

簡述HTTP

  • HTML結構化元素：通過標記符號來標記要顯示的網頁中的各個基本元素如文字、圖片甚至音視訊等
  • CSS呈現形式：定義不同呈現方式如字型、顏色、邊距等
  • JavaScript負責介面功能：定義不同元件的行為，形成互動

1.2 Uniform Resource Locator(URL)

Uniform Resource Identifier(URI) 是一個由字元組成的字串，用於標示具體資源。URI代表的是一種象徵，象徵著網路中每一個資源都有唯一的識別符號以便於訪問。URL是URI的一種常見形式，另一種還有Uniform Resource Name(URN），兩者區別是：

  • URN 類似於人名，標示一個資源名稱

  • URL 類似於地址，標示如何找到該資源

以http://www.someSchool.edu/someDepartment/picture.gif為例，URL通常由兩部分組成：

  • 儲存物件的主機名， www.someSchool.edu
  • 主機中物件的具體路徑, /someDepartment/picture.gif

2. 通訊流(flow)

HTTP使用TCP作為傳輸協議，Server與Client互動過程中會建立TCP連線，但並不會儲存任何Client的狀態資訊，因此HTTP也成為無狀態(stateless)協議。

計算機相互之間進行通訊通常有兩種方式：

  • 請求響應（request-response）

    向對端主機傳送請求後需等待響應，這類通訊過程就是由一系列的單次通訊構成，典型應用如網頁瀏覽

  • 單向（one-way ）

    向對端主機傳送訊息後無需等待回覆，典型應用如郵件

2.1 TCP

如前文所述，HTTP通訊方式屬於請求響應型別，因此單次通訊流程通常為：

  • 建立TCP連線
  • 傳送HTTP訊息（message, 應用層資訊單元）
  • 讀取伺服器響應
  • 關閉TCP連線

由於HTTP為無狀態協議（即每次通訊間無關聯），因此通常來講，HTTP每次通訊都是使用獨立TCP連線的。大部分網路應用中，client和server會在一定時間內通訊多次，從每次request和response是否通過同一TCP連結傳送的角度來看，可以劃分為兩種：

  • 短連線（non-persistent connections），每個request/response對均使用單獨TCP連結
  • 長連線（persistent connections），每個request/response對均使用同一TCP連結

在HTTP 0.9和1.0中，連線均會在單詞請求響應後關閉，而TCP連線的建立和消亡需要經過三路握手、四路斷開，因此需要一定額外時間開銷。有鑑於此，從HTTP 1.1開始，所有連線預設為長連線。更進一步地，如果不必每個單次通訊都需等待響應後才能繼續下一個通訊，則可以實現流水線技術，提高併發量。

簡述HTTP

2.2 Message格式

解決了連線的問題，剩下的就是訊息格式了。前面提過，通訊的基礎是有效的轉換和逆轉換，轉換需要規則，規則就是協議。對於HTTP而言，存在兩種規則，分別為request和response。

HTTP 1.1及之前版本中，message均是可讀性強字元。在HTTP 2中，這些訊息將被先封裝至二進位制結構frame中，並通過frame header進行其他如複用等配置。

2.2.1 Request

先放一個示例：

GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr

(data data data data data ...)
複製程式碼

可以看出，組成元素均為可讀性強的ASCII字元，具體格式則可進一步細分為如下結構:

簡述HTTP

2.2.2 Response
HTTP/1.1 200 OK
Connection: close
Date: Tue, 09 Aug 2011 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 09 Aug 2011 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html

(data data data data data ...)
複製程式碼

簡述HTTP

3. 欄位定義

3.1 Request methods

HTTP請求中定義了method欄位以標明希望在URL上執行的操作，而該資源將如何呈現、是否已存在或將被動態建立，均基於伺服器的實現本身。主流應用中，通常會選擇實現如下方法：

  • GET

    請求所需資源，該請求除獲取資料外不應產生其他效果

  • HEAD

    功能與GET相當，區別在於響應中不包括具體資料，即不含response body。可以理解為GET的輕量級，只檢視元資訊而不實際獲取。

  • POST

    將請求body中內容推送至伺服器，或是儲存在URI指定的資源下，或是其他實現形式

  • PUT

    將請求body中內容儲存至伺服器中URI指定位置，如該URI已有資源，將被修改；如無資源，則將建立

  • DELETE

    刪除伺服器中指定資源

  • TRACE

    告知伺服器回傳所收請求，以便客戶端確認鏈路中是否發生修改行為

  • OPTIONS

    返回伺服器在指定URL上所支援的方法，如URL為'*'，則查詢物件為伺服器本身

  • CONNECT

    告知伺服器去返回指定URL，並將其獲取到的Response轉發回請求客戶端，相當於代理，網頁開發中並不常用，僅預留做管理

  • PATCH

    對資源進行區域性修改操作

HTTP Method RFC Request Has Body Response Has Body Safe Idempotent Cacheable
GET RFC 7231 Optional Yes Yes Yes Yes
HEAD RFC 7231 No No Yes Yes Yes
POST RFC 7231 Yes Yes No No Yes
PUT RFC 7231 Yes Yes No Yes No
DELETE RFC 7231 No Yes No Yes No
CONNECT RFC 7231 Yes Yes No No No
OPTIONS RFC 7231 Optional Yes Yes Yes No
TRACE RFC 7231 No Yes Yes Yes No
PATCH RFC 5789 Yes Yes No No No

3.2 Status codes

自HTTP 1.0開始，響應以狀態行開始，而狀態行中進一步包含了一個狀態碼（status code）及對應的文字說明。狀態碼分為五類，為了便於管理和更加直觀表示，第一個數字用於標示響應的型別。

  • 1xx Informational responses

    標明請求已被接收並解析，常用於伺服器需較長時間處理請求時告知客戶端正在處理，且客戶端需等待最終的回覆。

    • 100 Continue
    • 101 Switching Protocols
    • 102 Processing
    • 103 Early Hints

  • 2xx Success

    標明請求已被接收、解析且已生效。

    • 200 OK
    • 201 Created
    • 202 Accepted
    • 203 Non-Autoritative Information (Since HTTP/1.1)
    • 204 No Content
    • 205 Reset Content
    • 206 Partial Content
    • 207 Multi-Status
    • 208 Already Reported
    • 226 IM Used

  • 3xx Redirection

    標明客戶端需要採取額外措施來完成整個請求，通常用於URL重定向。

    • 300 Multiple Choices
    • 301 Moved Permanently
    • 302 Found
    • 303 See Other
    • 304 Not Modified
    • 305 Use Proxy
    • 306 Switch Proxy
    • 307 Temporary Redirect
    • 308 Permanent Redirect

  • 4xx Client errors

    標明可能由客戶端引發的錯誤，除HEAD方法外，其餘情況中這類Response將會在Body中包含錯誤情況的詳細說明，以及是臨時或永久狀況。

    • 400 Bad Request
    • 401 Unauthorized
    • 402 Payment Required
    • 403 Forbidden
    • 404 Not Found
    • 405 Method Not Allowed
    • 406 Not Acceptable
    • 407 Proxy Authentication
    • 408 Request Timeout
    • 409 Conflict
    • 410 Gone
    • 411 Length Required
    • 412 Precondition Failed
    • 413 Payload Too Large
    • 414 URI Too Long
    • 415 Unsupported Media Type
    • 416 Range Not Satisfiable
    • 417 Expectation Failed
    • 418 I'm a teapot
    • 421 Misdirected Request
    • 422 Unprocessable Entity
    • 423 Locked
    • 424 Failed Dependency
    • 426 Upgrade Required
    • 428 Precondition Required
    • 429 Too Many Requests
    • 431 Request Header Fields Too Large
    • 451 Unavailable For Legal Reasons

  • 5xx Server error

    標明可能由伺服器本身引發的錯誤。

    • 500 Internal Server Error
    • 501 Not Implemented
    • 502 Bad Gateway
    • 503 Service Unavailable
    • 504 Gateway Timeout
    • 505 HTTP Version Not Supported
    • 506 Variant Also Negotiates
    • 507 Insufficient Storage
    • 508 Loop Detected
    • 510 Not Extended
    • 511 Network Authentication Required

4. 高階控制

4.1 Cache

簡述HTTP

所謂快取（Cache），就是指相比伺服器本身，在更靠近客戶端的鏈路中設定一個額外的伺服器副本。簡單來看，快取技術有兩大優勢：

  • 通過分流，降低了伺服器本身負載，提高整體併發
  • 縮短鏈路頻寬、長度，降低傳輸引發的延時

因此，快取技術本質上是降低了單次請求的響應時長，從而提升網路體驗。

The Conditional GET

然而大部分時候，副本帶來了高可靠性，也帶來了同步問題。實際伺服器中內容可能隨時間推移會發生修改，此時副本伺服器中的資料就是相對過期了的，那麼必要的同步就勢在必行。

什麼是必要的同步，就是隻有比較資料後發現有更新才進行同步，否則只是無謂的拷貝，佔用頻寬。判斷資料是否發生更新可以從資料本身出發，也可以只從資料標籤即後設資料出發，只要記錄的資料最後更新時間一致，就可以判定資料不必更新，否則，就有更新的必要了。HTTP中這種機制叫做conditional GET，而更新的時間，就是通過Request中的If-modified-since欄位給出。

GET /fruit/kiwi.gif HTTP/1.1
Host: www.exotiquecuisine.com
If-modified-since: Web, 7 Sep 2011 09:23:24
複製程式碼

4.2 Session and Cookie

前面提到，HTTP是無狀態協議，就是說HTTP伺服器不會在多個請求之間維護使用者資訊。但實際應用中，又往往存在這種剛性需求，典型的如購物、新聞瀏覽等。為了實現賓至如歸的錯覺，增加使用者的黏度，HTTP採用了會話（Session）和Cookie技術。

會話，相當於一次對話。一次對話肯定包括至少一次互動，同樣一次會話也至少包括一個請求響應對。因此會話就是由一系列的請求響應對組成。要想在一系列動作中保持某種狀態，比較通用的方法就是在動作之外，維護一個變數或者檔案，而Cookie的組成元素中，檔案就是重要的一環。

Cookie

Cookie技術由四大元件組成：

  • Response中Cookie header line用於返回伺服器為使用者所分配的Cookie ID
  • Request中Cookie header line用於告知伺服器請求來自於哪一個為使用者的Cookie ID
  • 使用者客戶端上本地儲存維護的Cookie檔案，記錄使用者行為
  • 網站本身的後臺資料庫，儲存了使用者與Cookie ID間對映關係等資料

簡述HTTP

Cookie的具體使用過程如上圖所示，總的來講，就是通過獨立第三發資訊（Cookie ID、資料庫、Cookie檔案）來記錄使用者資訊，並在會話中相關請求響應對中標記，保持伺服器與客戶端間的同步，實現狀態維護。

5. 小結

本篇概述了HTTP的大部分內容，如有興趣進一步學習研究，可參考相關Spec.

相關文章