你好，我是 HTTP —— HTTP 基礎介紹

時間 2020-04-01

標籤你好 http 基礎介紹欄目 HTTP/TCP 简体版

原文原文鏈接

在瀏覽器打開一個網頁，咱們每每會在地址欄的開頭看到 "http" 或者是 "https", 那這究竟是什麼呢？html

還有一些狀況下，咱們打開某個網頁，顯示的是「404 Not Found」或者 "500 Server Error" 之類的，並無指望的內容，這些又表明什麼呢？nginx

上面所提到的，都和一個叫 HTTP 的同窗有關。數據庫

本期節目，讓咱們走近 HTTP.後端

HTTP 的學名是 Hyper Text Transfer Protocol, 翻譯成中文就是「超文本傳輸協議」，看到這裏，可能有點輪廓了，它是和傳輸相關的。瀏覽器

這個超文本傳輸協議定義了 Web 客戶端向服務器請求頁面的方式，也定義了 Web 服務器向客戶傳送頁面的方式。也就是說，在瀏覽器中打開的網頁，都是基於 HTTP 這個協議來傳輸的。安全

HTTP 是經過客戶端的請求和服務端的響應，來達成通訊的。bash

下面咱們把鏡頭對準客戶端，看看它是如何請求的。服務器

請求報文

客戶端的請求信息要發給服務端，告訴服務端我須要什麼樣的數據。這裏的請求信息，稱之爲請求報文。cookie

請求報文由請求行，首部行和請求實體組成，請求行和首部行的每一行由回車換行符結束，首部行的下一行還有一組回車換行，緊跟着是請求實體。網絡

GET

舉個栗子，好比要取得網址 www.somesite.com/list/people 的資源，基本的請求報文以下：

GET /list/people HTTP/1.1
Host: www.somesite.com
Connection: close
User-Agent: Mozilla/5.0
Accept-Language: en

複製代碼

上面的第一行即爲請求行，其中 GET 表明的是請求方法；/list/people 是請求資源的 URI；而 HTTP/1.1 則是該請求的 HTTP 版本號，表明該請求是基於 HTTP 1.1 版本的。

接下來從 Host 逐行往下到 Accept-Language，都屬於 HTTP 請求報文的首部行。

Host 代表了資源所在主機；Connection: close 告訴服務器沒必要採用持續鏈接（下面會提到），服務器在發送完響應信息後會關閉此次鏈接，此處如果 Connection: keep-alive 則代表要採用持續鏈接；User-Agent 指明瞭發送請求瀏覽器的類型；Accept-Language: en 表明瀏覽器指望該資源的英語版本，若服務器沒有英語版本，則返回默認的版本。首部行字段有個細節，就是每一個字段的冒號以後，都有一個空格。

這個示例裏面的請求首部行只是幾個常見的字段，在真實的請求當中，確定會有更多的字段。

在請求行和首部行的末尾都有回車換行符，即 \r\n, 因此咱們能看到上面的請求都是一行行分開的。在首部行的末尾的下一行，還有一組回車換行符，若請求存在請求實體將與首部行有一行的間隔。

從請求行的方法字段咱們可知，這是一個 GET 請求，而 GET 請求是沒有請求實體的。因此上面的報文只有請求行和首部行。

POST

假如是一個 POST 請求，向服務器上傳一些信息，那麼請求報文多是這樣的：

POST /list/people HTTP/1.1
Host: www.somesite.com
Connection: close
User-Agent: Mozilla/5.0
Accept-Language: en
Content-Type: application/x-www-form-urlencoded
Content-Length: 16

name=jack&age=18
複製代碼

上面的 name=jack&age=18是該次 POST 請求傳送給服務器的數據，也就是請求報文的請求實體。肉眼可見，請求實體與首部行相隔一行。

收到客戶端瀏覽器的請求以後，服務器固然要給人家一個答覆。這個答覆就是服務器的響應報文。

響應報文

和請求報文相似，響應報文由狀態行，首部行和實體組成。

話很少說，舉個栗子，

HTTP/1.1 200 OK
Connection: close
Date: Thu, 26 Mar 2020 08:39:52 GMT
Server: nginx/1.15.10
Last-Modified: Sat, 21 Mar 2020 13:23:02 GMT
Content-Length: 215
Content-Type: text/html

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>HTTP Respose</title>
</head>
<body>
  <h1>Heelo</h1>
</body>
</html>
複製代碼

上面報文的第一行即爲響應報文的狀態行，狀態行包括三個字段：協議版本字段，狀態碼以及狀態信息。其中 HTTP/1.1 代表了協議及其版本；200 即爲狀態碼，常見的狀態碼還有 404， 301 等；OK 是狀態信息，表示請求和響應都沒問題。像狀態碼 404 對應的狀態信息是 Not Found, 表示服務器找不到該資源；301 則對應 Moved Permanently, 代表該資源已經被永久移動到新的 URI, 返回信息中也會包含新的 URI.

狀態行以後，就是響應報文的首部行。其中 Date 表示服務器產生併發送該響應報文的時間；Server 和請求報文中的 User-Agent 相似，在這裏代表響應來自 Nginx 服務器；Last-Modified 表示資源最後一次修改的時間；Cotent-Length 表示資源的字節數，Content-Type 表示資源的類型。

首部行以後，即是響應實體。和請求報文同樣，首部行與實體相隔一行。這裏能夠看到，返回給客戶端的資源是 HTML 文檔。

無狀態和 Cookie

HTTP 是無狀態的，也就是說 HTTP 不對客戶端和服務器的通訊狀態進行保存，魚還有七秒鐘記憶，這貨更狠，直接沒有記憶力。就算某個客戶端在幾秒鐘內就進行了第二次請求，服務器也不會由於剛剛已經發送過一樣的內容而中止響應，而是照發一次，由於它並不記得第一次請求。

HTTP 這種無狀態的特性，簡化了 HTTP 服務器的設計，而且容許工程師去開發能夠同時處理數以千計的 TCP 鏈接的高性能 Web 服務器。

—— 《計算機網絡——自頂向下方法》

可是假如用戶登陸了一個站點，須要進行一些登陸以後才能作的操做，而服務器保持無狀態，徹底記不得用戶曾經登陸過，那用戶只能不停地登陸直到砸鍵盤。

爲了給 HTTP 添加狀態，大多數站點都使用了 Cookie.

例如，用戶發起登陸請求，服務器發送給客戶端的響應報文會包含一個 Set-Cookie 的首部行，字段值能夠爲服務器給改用戶分配的 ID，好比說 uuid=9527。瀏覽器收到這樣的響應，會在瀏覽器的 cookie 裏添加這個信息。而且，在後續的請求中，在請求行會添加一個 Cookie 字段，來讓服務器知道，這些請求都發自已登陸的用戶 9527。這樣一來，就在 HTTP 中添加了狀態，讓服務器能夠識別用戶。

Cookie 技術一共有 4 個組件：

在響應報文中的一個首部行
在客戶端保存的 Cookie
在請求報文中的一個首部行
在 Web 站點後端的一個數據庫

非持久鏈接和持久鏈接

非持久鏈接

初始版本中，每請求一次就要斷開一次鏈接，這就是非持久鏈接。由於早期通訊，都是體積很小的文本傳輸。非持久鏈接尚可勝任。

但隨着技術的發展，文檔中可能包含大量圖片或其餘資源。若仍是採用非持久鏈接，每請求一張圖片，都要創建一次 TCP 鏈接。

假若有一個網頁有十張圖片，第一次請求獲得網頁的 HTML 文檔，文檔裏面包含了十張圖片的 URL. 接下來就是請求十張圖片，每張圖片就要一次請求，整個文檔加載下來，就是十一個請求。假如成百上千人同時請求這個網頁，服務器哪頂得住。

持久鏈接

HTTP 1.1 和部分 HTTP 1.0 實現了持久鏈接，即未聲明鏈接斷開，則保持鏈接。這樣一來，就大大減小了沒必要要的鏈接創建和斷開所形成的花銷。請求包含十張圖片的網頁，從發起請求開始，保持鏈接打開，HTML 文檔及其所包含的十張圖片均可以在一個鏈接內傳送完成。

持久鏈接使得管線化請求成爲可能，即在一個鏈接中，沒必要等待上一個請求收到響應，便可發送下一個請求，至關於有多個並行的請求，這樣一來，使頁面的內容加載得更快。

HTTP 1.1 默認就是持久鏈接，客戶端會在持久鏈接上持續發送請求，若服務器想要斷開鏈接，則設定響應報文首部行的 Connection 字段值爲 Close.

HTTP 1.1 以前默認都是非持久鏈接，若要開啓持久鏈接，須要設置請求和響應報文首部行的 Connection 字段的值爲 Keep-Alive.

HTTP 和 HTTPS

在瀏覽器的地址欄，除了 " http " 開頭，如今更爲常見的是 "https" 開頭的網址。那這個 HTTPS 是什麼呢？它和 HTTP 有什麼關係？

簡單來講，HTTPS 就是安全的 HTTP. 它的全稱是 HTTP Secure, 即超文本安全傳輸協議。

HTTP 的缺陷

HTTP 的安全性並很差，主要有如下幾點：

通訊使用明文，可能會被竊聽
不驗證通訊方的身份，可能遭遇假裝
沒法驗證報文的完整性，報文可能遭到篡改

要解決這些問題，就須要安全的 HTTP，即 HTTPS.

HTTPS

HTTP 中沒有加密機制，但能夠經過和 SSL (Secure Socket Layer, 安全套接層) 或 TLS (Transport Layer Security, 安全傳輸層協議) 的組合使用，來加密通訊內容，這就是 HTTPS，所以 HTTPS 又稱爲 HTTP over SSL 或 HTTP over TLS.

這裏拿 SSL 來舉例。

用 SSL 創建安全的通訊線路以後，就能夠在這條線路上進行通訊，這是對通訊的線路進行加密。

使用 SSL 還能夠確認通訊方的身份，SSL 對通訊方的確認是經過一種叫作證書的手段。證書由權威的第三方頒發，用以證實通訊雙方是是實際存在的，是可信賴的。而在技術上來講，僞造證書是及其困難的。有時候，咱們訪問某個網頁，瀏覽器會顯示「此網站的安全證書存在問題」，這就是 SSL 對服務器證書的確認。

在基於 SSL 的通訊過程當中，應用層發送數據時會附帶一種叫作 MAC (Message Authentication Code) 的報文摘要，這種報文摘要可以檢查報文是否遭到篡改，從而來保證報文的完整性。

要注意，HTTPS 並非一種新的協議，它只是通訊接口部分被 SSL 替代的 HTTP.

此外，HTTP 的 URL 由 http:// 開頭，默認端口是 80，而 HTTPS 的 URL 由 https:// 開頭，默認端口爲 443.

既然說 HTTPS 有着良好的安全性，那麼應該全部的現代站點都要應用 HTTPS 纔是，但咱們上網的時候，發現很多站點仍是用的 HTTP，這是爲何呢？