你必須知道的HTTP基本概念

時間 2019-12-06

標籤必須知道 http 基本概念欄目 HTTP/TCP 简体版

原文原文鏈接

文章首發於：dunizb.com
原文鏈接：dunizb.com/2017/12/08/…html

從本文你將看到：HTTP是幹嗎用的？怎樣和服務器通訊？HTTP的基本性質？HTTP能控制什麼？基於HTTP三大組件系統？HTTP 和 TCP 之間的關係？HTTP 協議如何使用 TCP 鏈接？java

本文沒什麼高深的東西，就是把一些概念整理了一下，大牛能夠飄過，不喜勿噴web

1、什麼是HTTP

HTTP是幹嗎用的？瀏覽器

HTTP學名叫作超文本傳輸協議，是一個網絡協議。緩存

是專門用來幫你傳輸諸如 HTML 的超媒體文檔等 Web 內容滴。由於 HTML 自己就是超文本標記語言，HTML 中不只有文本還有圖片、音視頻等內容，因此用來傳輸它的協議固然就叫超文本傳輸協議了。安全

好比你訪問俺的博客的主頁，瀏覽器地址欄會出現以下的網址：http://dunizb.com/，加了粗體的部分就是指 HTTP 協議。大部分網站都是經過 HTTP 協議來傳輸 Web 頁面、以及 Web 頁面上包含的各類東東（圖片、CSS 樣式、JS 腳本）。bash

它基於 TCP/IP 的應用層協議。它被設計用於Web瀏覽器和Web服務器之間的通訊，但它也能夠用於其餘目的。服務器

它是 Web 上數據交換的基礎，是一種 client-server 協議，也就是說請求一般是由像瀏覽器這樣的接受方發起的。一個完整的 web文檔是由不一樣的子文檔從新組建而成的，像是文本、佈局描述、圖片、視頻、腳本等等。cookie

怎樣和服務器通訊？網絡

HTTP遵循經典的客戶端-服務端模型，客戶端打開一個鏈接以發出請求，而後等待它收到服務器端響應。 HTTP是無狀態協議，意味着服務器不會在兩個請求之間保留任何數據（狀態）。
客戶端和服務端經過交換各自的消息（與數據流正好相反）來進行交互。一般由像瀏覽器這樣的客戶端發出的消息叫作 requests，那麼被服務端迴應的消息就叫作 responses。

HTTP 被設計於上20世紀90年代初期，是一種可擴展性的協議。它是應用層的協議，雖然理論上它能夠經過任何可靠的傳輸協議來發送，可是它仍是經過 TCP，或者是 TLS－加密的TCP鏈接來發送。由於它很好的擴展性，時至今日它不只被用來傳輸超文本文檔，還用來傳輸圖片、視頻或者向服務器發送如 HTML 表單這樣的信息。HTTP 還能夠根據網頁需求，來獲取部分web文檔的內容來更新網頁。

HTTP遵循經典的客戶端-服務端模型，客戶端打開一個鏈接以發出請求，而後等待它收到服務器端響應。 HTTP是無狀態協議，意味着服務器不會在兩個請求之間保留任何數據（狀態）。雖然一般基於TCP / IP層，但能夠在任何可靠的傳輸層上使用;也就是說，一個不會靜默丟失消息的協議，如UDP。

2、HTTP的基本性質

總述：HTTP是簡單的、可擴展、無狀態的

HTTP 是簡單的

即使在HTTP/2中把HTTP消息封裝到了frames中，HTTP大致上仍是被設計成可讀的並且簡單的。HTTP的消息可以讓人讀懂且明白它的意思，還容許簡單的測試，放低了門檻，更有利於新來者瞭解。

HTTP 是可擴展的

在HTTP/1中就出現了, HTTP headers 讓協議擴展變得很是容易。只要服務端和客戶端在新的headers上語義達成一致，新的功能就能夠輕鬆地被加進來。

HTTP 是無狀態，有會話的

HTTP是無狀態的：在同一個鏈接中，兩個成功執行的請求之間是沒有關係的。這就帶來了一個問題，用戶沒辦法在一個網站進行連續的交互，好比在一個電商網站裏，用戶把某個商品加入了購物車中，換了一個頁面後再次添加商品，兩次添加商品的請求沒有聯繫，瀏覽器沒法知道最終用戶都選擇了哪些商品。而用HTTP的頭部擴展，HTTP Cookies就能夠解決這個問題（將在後面介紹）。把Cookies添加到頭部中，建立一個會話來讓每次請求都能共享相同的上下文信息，相同的狀態。而HTTP的核心是無狀態的，cookies的使用能夠建立有狀態的會話。

3、HTTP能控制什麼

多年以來，HTTP良好的擴展性控制着愈來愈多Web的功能。緩存和認證方式很早就能夠由HTTP來控制了。另外一方面，對同源同域的限制到2010年纔有所改變。

下面就是能夠用HTTP來控制的常見特性。

緩存

文檔怎麼緩存可以經過HTTP來控制。服務端能告訴代理和客戶端什麼須要被緩存，緩存多久，而客戶端可以根據請求條件首部字段（如If-Modified-Since、If-Match等）來忽略存儲的文檔。

開放同源限制

爲了防止網絡窺聽和其它的隱私泄漏，瀏覽器強制對Web網站作了分割限制。只有來自於相同來源的網頁纔可以獲取網站的所有信息。這樣的限制有時反而成了負擔，HTTP能夠經過修改頭部來開放這樣的限制，所以web文檔能夠是由不一樣域下的信息拼接成的（在某些狀況下，這樣作還有安全因素考慮在裏面）。

認證

一些頁面可以被保護起來，僅讓特定的用戶進行訪問。基本的認證功能能夠直接經過HTTP提供，使用Authenticate類似的頭部就能夠，或者用HTTP cookies來設定指定的會話。

代理和隧道

一般狀況下，服務器和/或客戶端是處於內網的，對其它（外網）隱藏其真實 IP 地址。所以 HTTP 請求就要經過代理越過這個網絡屏障。但並不是全部的代理都是 HTTP 代理。例如，SOCKS協議的代理就運做在更底層。一些像 ftp 其它的協議也可以被它們處理。

Cookies Cookies用一個服務端的狀態鏈接起了每個請求。這就建立了會話，雖然基本的HTTP是無狀態協議。這頗有用，不只是由於能用到購物車這樣的電商業務上，更是由於，它使得任何網站都可以配置頁面展示的東西了。

4、基於HTTP三大組件系統

客戶端：user-agent

嚴格意義來講，user-agent 就是任何可以爲用戶發起行爲的工具。但實際上，這個角色一般都是由瀏覽器來扮演。對於發起請求來講，瀏覽器老是做爲發起一個請求的實體，而永遠不是服務器（雖然一些機制已經可以模擬服務器發起請求的消息了）。

Web服務端

在上述通訊過程的另外一端，就是一個Web Server來服務並提供客戶端請求的文檔。Server只是虛擬意義上：它能夠是許多共同分擔負載（負載平衡）的一組服務器組成的計算機羣，也能夠是一種複雜的軟件，經過向其餘計算機發起請求來獲取部分或所有資源的軟件。

Server再也不只是一個單獨的機器，它能夠是在同一個機器上裝載的許多服務之一。在HTTP/1.1和Host頭部中，它們甚至能夠共享同一個IP地址。

Proxies 代理

在瀏覽器和服務器之間，有許多計算機和其餘設備轉發了HTTP的消息。由於Web棧層次結構的緣由，它們大多數都出如今傳輸層、網絡層和物理層上，對於HTTP的應用層來講就是透明的（雖然它們可能會對應用層的性能有重要影響）。而還有一部分表如今應用層上的，就叫作proxies了。Proxies既能夠表現得透明，又能夠不透明（看請求是否經過它們），主要表如今這幾個功能上：

緩存（能夠是公開的或是私有的，像瀏覽器的緩存）
過濾（像反病毒掃描，家長監護）
負載均衡，讓多個服務器服務不一樣的請求
對不一樣資源的權限控制
登錄，容許存儲歷史信息

每個發送到服務器的請求，都會被服務器處理而且返回一個消息，也就是response。在client與server之間，還有許許多多的被稱爲proxies的實體，他們的做用與表現各不相同，好比有些是網關，還有些是caches等。

實際上，在一個瀏覽器和處理請求的服務器之間，還有計算機、路由器、調制解調器等等許多實體。因爲Web的層次設計，那些在網絡層和傳輸層都不可見了。HTTP是在最上層應用層中的，雖然下面的層次對分析網絡問題很是重要，可是對HTTP的描述來講，這些大多數都是不相關的。

5、HTTP 和 TCP 之間的關係

前面說過，HTTP是基於 TCP/IP 的，簡單地說，TCP 協議是 HTTP 協議的基石——HTTP 協議須要依靠 TCP 協議來傳輸數據。

在網絡分層模型中，TCP 被稱爲「傳輸層協議」，而 HTTP 被稱爲「應用層協議」。有不少常見的應用層協議是以 TCP 爲基礎的，好比「FTP、SMTP、POP、IMAP」等。

TCP 被稱爲「面向鏈接」的傳輸層協議。關於它的具體細節，俺就不展開了（不然篇幅又失控了）。你只需知道：傳輸層主要有兩個協議，分別是 TCP 和 UDP。TCP 比 UDP 更可靠。你能夠把 TCP 協議想象成某個水管，發送端這頭進水，接收端那頭就出水。而且 TCP 協議可以確保，先發送的數據先到達（與之相反，UDP 不保證這點）。

6、HTTP 協議如何使用 TCP 鏈接？

HTTP 對 TCP 鏈接的使用，分爲兩種方式：俗稱「短鏈接」和「長鏈接」（「長鏈接」又稱「持久鏈接」，洋文叫作「Keep-Alive」或「Persistent Connection」）

假設有一個網頁，裏面包含好多圖片，還包含好多外部的 CSS 文件和 JS 文件。在「短鏈接」的模式下，瀏覽器會先發起一個 TCP 鏈接，拿到該網頁的 HTML 源代碼（拿到 HTML 以後，這個 TCP 鏈接就關閉了）。而後，瀏覽器開始分析這個網頁的源碼，知道這個頁面包含不少外部資源（圖片、CSS、JS）。而後針對每個外部資源，再分別發起一個個 TCP 鏈接，把這些文件獲取到本地（一樣的，每抓取一個外部資源後，相應的 TCP 就斷開）相反，若是是「長鏈接」的方式，瀏覽器也會先發起一個 TCP 鏈接去抓取頁面。可是抓取頁面以後，該 TCP 鏈接並不會當即關閉，而是暫時先保持着（所謂的「Keep-Alive」）。而後瀏覽器分析 HTML 源碼以後，發現有不少外部資源，就用剛纔那個 TCP 鏈接去抓取此頁面的外部資源。

在 HTTP 1.0 版本，默認使用的是「短鏈接」（那時候是 Web 誕生初期，網頁相對簡單，「短鏈接」的問題不大）.

到了1995年末開始制定 HTTP 1.1 草案的時候，網頁已經開始變得複雜（網頁內的圖片、腳本愈來愈多了）。這時候再用短鏈接的方式，效率過低下了（由於創建 TCP 鏈接是有「時間成本」和「CPU 成本」滴）。因此，在 HTTP 1.1 中，默認採用的是「Keep-Alive」的方式。

7、一些術語

資源（resource）

Web資源是使用URL指向的Web內容。

內容能夠是靜態的，如：文本文件、HTML文件、JPEG文件。
或者是動態的內容。如：攝像頭的實時採集軟件生成的動態影像，用戶填寫的電子網站訂單。

資源類型

Web服務器會爲全部HTTP資源賦予一個類型，以便於HTTP軟件處理消息主體。如，用 text/html 標記 html。能夠再看兩個案例：

text/plain :ASCII文本文檔
image/jpeg :JPEG版本的圖片

很是多的資源類型和文本標記的對應關係，一塊兒構成了一個超長的清單，而且由RFC 2045標準化。此標準被稱爲MIME。MIME是Multipurpose Internet Mail Extension的縮寫。雖然名稱很長，可是含義簡單，就是用來指定消息內的實體類型的。之因此有Mail字樣，是由於最初設計是爲了Mail的異構系統交換文檔的。

資源標示符

URL是一種資源位置標示方法。URL描述了一個資源在服務器上的位置。這就是一個合法的URL：http://example.com/part/index.htm。

第一部分：方案(scheme)。指明瞭訪問資源所使用的協議類型。這部分一般是HTTP協議(http://)。
第二部分：服務器地址(好比，example.com）。
其他部分指定了Web服務器上的某個資源(好比，/part/index.htm)。

當在地址欄輸入此資源名並回車後，用戶代理會把URL解析，把必要的信息以HTTP協議的要求，打入請求消息內。以http://www.example.com/index.html，變成

GET index.html HTTP/1.1
host:www.example.com
空行
複製代碼

打開到www.example.com的tcp鏈接，併發送此請求消息給服務器，而後等待服務器響應並解析顯示給用戶。

更多URL、URI、URN詳細推薦閱讀：《你知道URL、URI和URN三者之間的區別嗎？》

HTTP事務

一個HTTP事務由一條請求消息和一個響應消息構成。

HTTP方法

HTTP支持幾種不一樣的請求命令，這些命令被稱爲HTTP方法(HTTP method)。每條HTTP請求報文都包含一個方法。

狀態碼

每條HTTP響應消息返回時都會攜帶一個狀態碼。狀態碼是一個三位數字的代碼，告知客戶端請求是否成功，或者是須要採起其餘行動。

消息

從Web客戶端發往Web服務器的HTTP報文稱爲請求消息。從服務器發往客戶端的消息稱爲響應消息。HTTP報文包括三部分：

起始行
首部字段 
主體
複製代碼

如發送一個hello.htm 的資源給客戶端，請求消息是：

GET /hello.html HTTP/1.1
複製代碼

請求消息只有起始行，指明使用的HTTP方法、資源的URL，以及協議的版本。沒有首部字段和主體。

響應消息爲：

HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: text/html; charset=utf-8
Content-Length: 22
ETag: W/"16-FmHX0hamHjYkHeAP/7PfzA"
Date: Thu, 03 Dec 2015 09:54:01 GMT
Connection: close

<h1>Hello, World!</h1>
複製代碼

這個消息第一行爲起始行，指明協議版本、狀態碼（200表示成功）和狀態說明（OK）。接下來一直到空行之間都是首部字段，用來講明服務器、資源類型、內容長度、生成文檔時間等。空行後就是主體，這裏就是一個html文件的內容。實際上，主體能夠承載任何內容，而不限於文本。