圖解HTTP後的一些總結

摘要： HTTP 圖解筆記 一 .簡單瞭解 1.1HTTP背景 1.1.1 HTTP的誕生 1989 年 3 月，網際網路還只屬於少數人。在這一網際網路的黎明期， HTTP 誕生了。 CERN（歐洲核子研究組織）的蒂姆 • 伯納斯 - 李（Tim BernersLee） 博士提出了...

HTTP 圖解筆記

一 .簡單瞭解

1.1HTTP背景

1.1.1 HTTP的誕生

1989 年 3 月，網際網路還只屬於少數人。在這一網際網路的黎明期， HTTP 誕生了。

CERN（歐洲核子研究組織）的蒂姆 • 伯納斯 - 李（Tim BernersLee） 博士提出了一種能讓遠隔兩地的研究者們共享知識的設想。

最初設想的基本理念是：藉助多文件之間相互關聯形成的超文字 （HyperText），連成可相互參閱的 WWW（World Wide Web，萬維 網）。

現在已提出了 3 項 WWW 構建技術，分別是：把 SGML（Standard Generalized Markup Language，標準通用標記語言）作為頁面的文字標 記語言的 HTML（HyperText Markup Language，超文字標記語言）； 作為文件傳遞協議的 HTTP ；指定文件所在地址的 URL（Uniform Resource Locator，統一資源定位符）。

1.1.2 HTTP的版本資訊

• HTTP/0.9
  HTTP 於 1990 年問世。那時的 HTTP 並沒有作為正式的標準被建立。 現在的 HTTP 其實含有 HTTP1.0 之前版本的意思，因此被稱為 HTTP/0.9。
• HTTP/1.0
  HTTP 正式作為標準被公佈是在 1996 年的 5 月，版本被命名為 HTTP/1.0，並記載於 RFC1945。雖說是初期標準，但該協議標準至今 仍被廣泛使用在伺服器端。
• HTTP/1.1
  1997 年 1 月公佈的 HTTP/1.1 是目前主流的 HTTP 協議版本。當初的 標準是 RFC2068，之後釋出的修訂版 RFC2616 就是當前的最新版 本。

1.2 網路的基礎TCP/IP

要想要了解HTTP，首先需要了解TCP/IP協議族。通常我們使用的網路是在TCP/IP協議族的基礎上運作的，而HTTP只是其內部子集。

1.2.1 何為協議

計算機與網路裝置要相互通訊，雙方就必須基於相同的方法。比如， 如何探測到通訊目標、由哪一邊先發起通訊、使用哪種語言進行通 信、怎樣結束通訊等規則都需要事先確定。不同的硬體、作業系統之 間的通訊，所有的這一切都需要一種規則。而我們就把這種規則稱為 協議（protocol）。

TCP/IP 是網際網路相關的各類協議族的總稱

1.2.1 TCP/IP的分成管理

TCP/IP協議族按層次分別分為以下4層：應用層，傳輸層，網路層和資料鏈路層。將各個層次分開後，當某個地方需要修改時，不需要整體都替換掉，只需要把變動的層次替換即可。

各層次功能作用如下：

• 應用層
  應用層決定了向用戶提供應用服務時通訊的活動。
  TCP/IP 協議族內預存了各類通用的應用服務。比如，FTP（File Transfer Protocol，檔案傳輸協議）和 DNS（Domain Name System，域名系統）服務就是其中兩類。
  HTTP 協議也處於該層。
• 傳輸層
  傳輸層對上層應用層，提供處於網路連線中的兩臺計算機之間的資料傳輸。
  在傳輸層有兩個性質不同的協議：TCP（Transmission Control Protocol，傳輸控制協議）和 UDP（User Data Protocol，使用者資料報協議）。
• 網路層（又名網路互連層）
  網路層用來處理在網路上流動的資料包。資料包是網路傳輸的最小資料單位。該層規定了通過怎樣的路徑（所謂的傳輸路線）到達對方計 算機，並把資料包傳送給對方。
  與對方計算機之間通過多臺計算機或網路裝置進行傳輸時，網路層所 起的作用就是在眾多的選項內選擇一條傳輸路線

• 鏈路層（又名資料鏈路層，網路介面層）

  用來處理連線網路的硬體部分。包括控制作業系統、硬體的裝置驅動、NIC（Network Interface Card，網路介面卡，即網絡卡），及光纖等物理可見部分（還包括聯結器等一切傳輸媒介）。硬體上的範疇均在 鏈路層的作用範圍之內。

  

傳送端在層與層之間傳輸資料時，每經過一層時必定會被打上一個該 層所屬的首部資訊。反之，接收端在層與層傳輸資料時，每經過一層 時會把對應的首部消去。

這種把資料資訊包裝起來的做法稱為封裝（encapsulate）。

1.3 HTTP密切相關的協議：IP、TCP和DNS

1.3.1 負責傳輸的IP協議

IP（Internet Protocol）網際協議位於網路層，幾乎所有使用網路的系統都會使用到IP協議。在TCP/IP協議族中IP就指的是網際協議。需要注意的是： IP協議與IP地址並非同一種東西

IP協議的作用是把各種資料包傳輸給對方，然而，需要保證確實傳送到對方那裡，這需要滿足各類條件。在這其中，最重要的兩個條件莫過於IP地址與MAC地址（Media Access Control Address）。IP地址指明瞭節點被分配到的地址，MAC地址則是網絡卡所屬的固定地址。IP地址可以和MAC地址進行配對。IP地址可變換，但是MAC地址基本上不會更改。傳輸過程如下：

IP 間的通訊依賴 MAC 地址。在網路上，通訊的雙方在同一區域網 （LAN）內的情況是很少的，通常是經過多臺計算機和網路裝置中轉 才能連線到對方。而在進行中轉時，會利用下一站中轉裝置的 MAC 地址來搜尋下一個中轉目標。這時，會採用 ARP 協議（Address Resolution Protocol）。ARP 是一種用以解析地址的協議，根據通訊方 的 IP 地址就可以反查出對應的 MAC 地址。

1.3.2 確保可靠性的TCP協議

I按層次劃分，TCP屬於傳輸層，提供可靠的位元組流服務。

• 位元組流服務：
  所謂的位元組流服務（Byte Stream Service）是指，為了方便傳輸，將大塊資料分割成以報文段（segment）為單位的資料包進行管理。而可靠的傳輸服務是指，能夠把資料準確可靠地傳給對方。
• TCP
  TCP 協議為了更容易傳送大資料才把資料分割，而且 TCP 協議能夠 確認資料最終是否送達到對方。
• 三次握手
  為了準確無誤地將資料送達目標處，TCP 協議採用了三次握手 （three-way handshaking）策略；在使用TCP協議把資料包傳送出去後，TCP一定會想對方確認是否成功送達。在三次握手的過程中，使用了TCP的標誌（flag） ---- SYN(synchronize) 和 ACK(acknowledgement)。 過程如下：

傳送端首先發送一個帶 SYN 標誌的資料包給對方。接收端收到後， 回傳一個帶有 SYN/ACK 標誌的資料包以示傳達確認資訊。最後，發 送端再回傳一個帶 ACK 標誌的資料包，代表“握手”結束。

若在握手過程中某個階段莫名中斷，TCP 協議會再次以相同的順序發 送相同的資料包

當然，除了三次握的協議，TCP協議同時還有其他的各種手段來保證通訊的可靠性。

1.3.2 負責域名解析的DNS服務

DNS（Domain Name System）服務是和 HTTP 協議一樣位於應用層的協議。它提供域名到 IP 地址之間的解析服務。一張圖瞭解DNS解析：

再知道以上協議後，總結一下:

1.4 URL與URI

• URL：我們平時上網時輸入的網址
• URI：統一資源識別符號（Uniform Resource Identifier）
  URI 用字串標識某一網際網路資源，而 URL 表示資源的地點（互聯 網上所處的位置）。可見 URL 是 URI 的子集。

表示指定的 URI，要使用涵蓋全部必要資訊的絕對 URI、絕對 URL 以 及相對 URL。相對 URL，是指從瀏覽器中基本 URI 處指定的 URL， 形如 /image/logo.gif。

讓我們先來了解一下絕對 URI 的格式。

在上面圖片中，登入資訊（認證）意思為：指定使用者名稱和密碼作為伺服器端獲取資源時必要的登入資訊。所以此項為可選項。

二.簡單的HTTP協議

在使用HTTP協議時，必有一端為客戶端一端為伺服器端，請求必定由客戶端發出，伺服器端進行回覆相應。

2.1 客戶端與伺服器端之間的通訊

2.1.1 客戶端請求

首先展示一個基本的請求示例：

GET /index.htm HTTP/1.1
Host:hackr.jp

分析一波：

首行GET表示請求訪問伺服器的型別，統稱為方法（method），隨後的/index.html指明瞭請求訪問的資源物件，也叫作 請求URL(request=URL) 。最後的HTTP/1.1 即為使用的HTTP版本

再來看一個POST請求的示例：

POST /form/entryHTTP/1.1
Host:hackr.jp
Connection:keep-alive
Content-Type:application/x-www-form-urlencoded
Content_Length:16
name=ueno&age=37

分析一波：

前一行同如上分析，中間四行為請你去的首部欄位（以後會講到），最後一行為post請求的內容實體。

2.1.1 伺服器端返回

先看一個例子：

HTTP/1.1 200 OK
Date Tue,10 Jul 2018 06:50:15 GMT
Content-Length:362
Content-Type: text/html

<html>
//.......

解釋：

在起始行開頭的 HTTP/1.1 表示伺服器對應的 HTTP 版本。

緊挨著的 200 OK 表示請求的處理結果的狀態碼（status code）和原因 短語（reason-phrase）。下一行顯示了建立響應的日期時間，是首部 欄位（header field）內的一個屬性。

接著以一空行分隔，之後的內容稱為資源實體的主體（entity body）。

2.2 HTTP是不儲存狀態的協議

HTTP 是一種不儲存狀態，即無狀態（stateless）協議。HTTP 協議自 身不對請求和響應之間的通訊狀態進行儲存。也就是說在 HTTP 這個 級別，協議對於傳送過的請求或響應都不做持久化處理。

HTTP/1.1 雖然是無狀態協議，但為了實現期望的保持狀態功能，於 是引入了 Cookie 技術。有了 Cookie 再用 HTTP 協議通訊，就可以管 理狀態了。有關 Cookie 的詳細內容稍後講解。

2.3 告知伺服器意圖的HTTP方法

• GET 獲取資源
  GET方法用來其你去已被URI四倍的資源。指定的資源經伺服器端解析後返回響應內容。簡而言之，如果是靜態資源，則保持原樣返回；如果是CGI（Common Gateway Interface，通用閘道器介面）那樣的程式，則返回經過執行後的輸出結果。
• POST 傳輸實體主體
  雖然用 GET 方法也可以傳輸實體的主體，但一般不用 GET 方法進行 傳輸，而是用 POST 方法。雖說 POST 的功能與 GET 很相似，但 POST 的主要目的並不是獲取響應的主體內容 。
• PUT 傳輸檔案
  PUT方法用來傳輸檔案，就像FTP】協議的檔案上傳一樣，要求在請求報文的主體中包含檔案內容，然後儲存到請求URI指定的位置。 注意： 由於HTTP/1,1 的PUT方法自身不帶有驗證機制，任何人哦度看可以上傳檔案，存在安全性問題，因此一般網站都不採用該方法。若配合Web應用程式的驗證機制，或者架構設計採用REST（REpresentational State Transfer，表徵狀態轉移）標準的同類Web網站，就可能會開放使用PUT方法。
• HEAD 獲得報文的首部
  HEAD 方法和 GET 方法一樣，只是不返回報文主體部分。用於確認 URI 的有效性及資源更新的日期時間等。
• DELETE 刪除檔案
  DELETE 方法用來刪除檔案，是與 PUT 相反的方法。DELETE 方法按 請求 URI 刪除指定的資源。 注意： 原因通 PUT 方法一樣，很少使用到，
• OPTIONS：詢問支援的方法
  OPTIONS 方法用來查詢針對請求 URI 指定的資源支援的方法。
• TRACE：追蹤路徑
  TRACE 方法是讓 Web 伺服器端將之前的請求通訊環回給客戶端的方 法。 TRACE 方法本來就不怎麼常用，再加上它容易引發 XST（Cross-Site Tracing，跨站追蹤）攻擊，通常就更不會用到了。
• CONNECT：要求用隧道協議連線代理
  CONNECT 方法要求在與代理伺服器通訊時建立隧道，實現用隧道協議進行 TCP 通訊。主要使用 SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協議把通訊內容加密後經網路隧道傳輸。

在以往的版本中，還存在著LINK和UNLINK兩種方法，分別作用於建立和資源之間的聯絡與斷開連線關係，但是在HTTP/1.1中被廢棄，不再支援，所以不討論。

2.4 持久連線與管線化

在傳統的HTTP協議中，每進行一次HTTP通訊就要斷開一次TCP連線，當一個頁面有大量請求時，每一次請求都會造成無謂的TCP連線的建立與斷開，增加了通訊的開銷。

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

當解決持久連線問題後，人們發現，以前傳送請求後需要等待並收到相應才能傳送下一個請求，但當持久連接出現後，使得管線化成為了可能，不用等待響應即可傳送下一個請求。

三.HTTP報文內的HTTP資訊

使用者HTTP協議互動的資訊被稱為HTTP報文。請求端（客戶端）的HTTP報文叫做請求報文，響應端（伺服器端）的叫做響應報文。

3.1 編碼提升傳輸速率

3.1.1 報文主體和實體主體的差異

在提及編碼之前，需要先理解報文主題和實體主題之間的差距

• 報文（message）
  是 HTTP 通訊中的基本單位，由 8 位組位元組流（octet sequence， 其中 octet 為 8 個位元）組成，通過 HTTP 通訊傳輸。
• 實體（entity）
  作為請求或響應的有效載荷資料（補充項）被傳輸，其內容由實 體首部和實體主體組成。

HTTP 報文的主體用於傳輸請求或響應的實體主體。

通常，報文主體等於實體主體。只有當傳輸中進行編碼操作時，實體 主體的內容發生變化，才導致它和報文主體產生差異。 報文和實體這兩個術語在之後會經常出現，請事先理解兩者的差異。

3.1.2 壓縮傳輸的內容編碼

內容編碼指明應用在實體內容上的編碼格式，並保持實體資訊原樣壓縮。內容編碼後的實體由客戶端接收並負責解碼。

常用的內容編碼有以下幾種：

1. gzip （GNU zip）
2. conpress （UNIX 系統的標準亞索）
3. deflate （zlib）
4. identity（不進行編碼）

3.1.3 分割傳送的分塊傳輸編碼

在HTTP通訊過程中，請求的編碼實體資源尚未全部傳輸完成之前，瀏覽器是無法顯示頁面的。在傳輸大容量資料時，通過把資料分割成多塊，能夠讓瀏覽器逐步顯示頁面。這種把實體主體分塊的功能稱為分塊傳輸編碼（Chunked Transfer Coding）

分塊傳輸編碼會將實體主體分成多個部分（塊）。每一塊都會用十六 進位制來標記塊的大小，而實體主體的最後一塊會使用“0(CR+LF)”來標 記。

3.2 傳送多種資料的多部分物件集合

HTTP 協議中也採納了多部分物件集合，傳送的一份報文主 體內可含有多型別實體。通常是在圖片或文字檔案等上傳時使用。

多部分物件集合包含的物件如下。

• multipart/form-data

  在 Web 表單檔案上傳時使用。

Content-Type: multipart/form-data; boundary=AaB03x 
--AaB03x 
Content-Disposition: form-data; name="field1"
Joe Blow 
--AaB03x 
Content-Disposition: form-data; name="pics"; filename="file1.txt" Content-Type: text/plain
...（file1.txt的資料）... 
--AaB03x--

• multipart/byteranges

  狀態碼 206（Partial Content，部分內容）響應報文包含了多個範 圍的內容時使用。

HTTP/1.1 206 Partial Content 
Date: Fri, 13 Jul 2012 02:45:26 GMT 
Last-Modified: Fri, 31 Aug 2007 02:02:20 GMT 
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES
Content-Type: application/pdf 
Content-Range: bytes 500-999/8000
...（範圍指定的資料）... 
--THIS_STRING_SEPARATES 
Content-Type: application/pdf 
Content-Range: bytes 7000-7999/8000

...（範圍指定的資料）... 
--THIS_STRING_SEPARATES--

在 HTTP 報文中使用多部分物件集合時，需要在首部欄位里加上 Content-type。有關這個首部欄位，我們稍後講解。

使用 boundary 字串來劃分多部分物件集合指明的各類實體。在 boundary 字串指定的各個實體的起始行之前插入“--”標記（例如：-AaB03x、--THIS_STRING_SEPARATES），而在多部分物件集合對應的字串的最後插入“--”標記（例如：--AaB03x--、-THIS_STRING_SEPARATES--）作為結束。

3.2 獲取部分內容的範圍請求

在原來，下載一樣檔案的過程中，如果出現網路錯誤導致下載失敗，往往需要重頭開始。為了解決這個問題，需要一種可恢復的機制。所謂恢復值得能從之前下載中斷處恢復下載。如圖：

執行範圍請求時，會用到首部欄位Range來指定資源的byte範圍。byte範圍的指定形式如下：

• 5001~10000位元組

Range:byte=5001-10000

• 從5001位元組之後全部的

Range:byte=5001-

• 從一開始到3000位元組和5000-7000位元組的多重範圍

Range:byte=-3000,5000~7000

四.返回結果的HTTP狀態碼

狀態碼的類別：

狀態碼	類別	原因短語
1XX	Informational（資訊性狀態碼）	接收的請求正在處理
2XX	Success（成功狀態碼）	請求正常處理完畢
3XX	Redirection（重定向狀態碼）	所需要進行附加操作以完成請求
4XX	Client Error（客戶端錯誤狀態碼）	伺服器無法處理請求
5XX	Server Error（伺服器錯誤狀態碼）	伺服器處理請求出現錯誤

4.1 2XX成功

200 OK

表示從客戶端發來的請求在發伺服器端被正常處理了。

204 NO Content

該狀態碼代表伺服器接受的請求已成功處理，但在返回的響應報文中不含實體的主體部分，另外也不允許返回任何實體的主體。

206 Partial Content

該狀態碼錶示客戶端進行了範圍請求，而伺服器成功執行了這部分的GET請求。響應報文中包含由Content-Range指定範圍的實體內容。

4.2 3XX 重定向

3XX響應結果表明瀏覽器需要自行某些特殊的處理以正確處理請求。

301 Moved Permanently

永久性重定向。該狀態碼錶示請求的資源已被分配了新的URI，以後應使用資源現在所指的URI。

302 Found

臨時性重定向。該狀態碼錶示請求的資源已被分配了新的 URI，希望 使用者（本次）能使用新的 URI 訪問。

303 See Other

該狀態碼錶示由於請求對應的資源存在著另一個 URI，應使用 GET 方法定向獲取請求的資源。

當 301、302、303 響應狀態碼返回時，幾乎所有的瀏覽器都會把 POST 改成 GET，並刪除請求報文內的主體，之後請求會自動再次 傳送。

301、302 標準是禁止將 POST 方法改變成 GET 方法的，但實際使 用時大家都會這麼做。

304 Not Modified

該狀態碼錶示客戶端傳送 附帶條件 的請求時，伺服器端允許請求訪 問資源，但未滿足條件的情況。304 狀態碼返回時，不包含任何響應 的主體部分。304 雖然被劃分在 3XX 類別中，但是和重定向沒有關 系。

附帶條件的請求是指採用 GET 方法的請求報文中包含 If-Match，If-ModifiedSince，If-None-Match，If-Range，If-Unmodified-Since 中任一首部。

307 Temporary Redirect

臨時重定向。該狀態碼與 302 Found 有著相同的含義。儘管 302 標準禁止 POST 變換成 GET，但實際使用時大家並不遵守。

307 會遵照瀏覽器標準，不會從 POST 變成 GET。但是，對於處理響 應時的行為，每種瀏覽器有可能出現不同的情況。

4.3 4XX 客戶端錯誤

4XX 的響應結果表明客戶端是發生錯誤的原因所在。

400 Bad Request

該狀態碼錶示請求報文中存在語法錯誤。當錯誤發生時，需修改請求 的內容後再次傳送請求。另外，瀏覽器會像 200 OK 一樣對待該狀態 碼。

401 Unauthorized

該狀態碼錶示傳送的請求需要有通過 HTTP 認證（BASIC 認證、 DIGEST 認證）的認證資訊。另外若之前已進行過 1 次請求，則表示使用者認證失敗。

返回含有 401 的響應必須包含一個適用於被請求資源的 WWWAuthenticate 首部用以質詢（challenge）使用者資訊。當瀏覽器初次接收 到 401 響應，會彈出認證用的對話視窗。

403 Forbidden

該狀態碼錶明對請求資源的訪問被伺服器拒絕了。伺服器端沒有必要 給出拒絕的詳細理由，但如果想作說明的話，可以在實體的主體部分對原因進行描述，這樣就能讓使用者看到了。

404 Not Found

該狀態碼錶明伺服器上無法找到請求的資源。除此之外，也可以在伺服器端拒絕請求且不想說明理由時使用。

4.4 5XX 伺服器錯誤

5XX 的響應結果表明伺服器本身發生錯誤。

500 Internal Server Error

該狀態碼錶明伺服器端在執行請求時發生了錯誤。也有可能是 Web 應用存在的 bug 或某些臨時的故障。

503 Service Unavailable

該狀態碼錶明伺服器暫時處於超負載或正在進行停機維護，現在無法 處理請求。如果事先得知解除以上狀況需要的時間，最好寫入 RetryAfter 首部欄位再返回給客戶端。

五. 與HTTP協作的Web伺服器

代理

代理伺服器的基本行為就是接收客戶端傳送的請求後轉發給其他服務 器。代理不改變請求 URI，會直接傳送給前方持有資源的目標服務 器。

在 HTTP 通訊過程中，可級聯多臺代理伺服器。請求和響應的轉發會 經過數臺類似鎖鏈一樣連線起來的代理伺服器。轉發時，需要附加 Via 首部欄位以標記出經過的主機資訊。

使用代理伺服器的理由有：利用快取技術（稍後講解）減少網路頻寬 的流量，組織內部針對特定網站的訪問控制，以獲取訪問日誌為主要 目的，等等。

代理有多種使用方法，按兩種基準分類。一種是是否使用快取，另一 種是是否會修改報文。

• 快取代理
  

  代理轉發響應時，快取代理（Caching Proxy）會預先將資源的副本 （快取）儲存在代理伺服器上。

  當代理再次接收到對相同資源的請求時，就可以不從源伺服器那裡獲 取資源，而是將之前快取的資源作為響應返回。

• 透明代理
  轉發請求或響應時，不對報文做任何加工的代理型別被稱為透明代理 （Transparent Proxy）。反之，對報文內容進行加工的代理被稱為非透明代理。

閘道器

png)

閘道器的工作機制和代理十分相似。而閘道器能使通訊線路上的伺服器提 供非 HTTP 協議服務。

利用閘道器能提高通信的安全性，因為可以在客戶端與閘道器之間的通訊 線路上加密以確保連線的安全。比如，閘道器可以連線資料庫，使用 SQL 語句查詢資料。另外，在 Web 購物網站上進行信用卡結算時， 閘道器可以和信用卡結算系統聯動。

隧道

隧道可按要求建立起一條與其他伺服器的通訊線路，屆時使用 SSL 等 加密手段進行通訊。隧道的目的是確保客戶端能與伺服器進行安全的 通訊。

隧道本身不會去解析 HTTP 請求。也就是說，請求保持原樣中轉給之 後的伺服器。隧道會在通訊雙方斷開連線時結束。

六. HTTP首部

HTTP 首部欄位根據實際用途被分為以下 4 種類型：

• 通用首部欄位（General Header Fields）
  請求報文響應報文兩方都會使用的首部
• 請求首部欄位（Request Header Fields）
  從客戶端想伺服器端傳送請求報文時使用的首部。補充了請求的附加內容、客戶端資訊、響應內容相關優先順序等資訊。
• 響應首部欄位（Response Header Fields）
  從伺服器端向客戶端返回響應報文時使用的首部。補充了響應的附加 內容，也會要求客戶端附加額外的內容資訊。
• 實體首部欄位（Entity Header Fields）
  針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體有關的資訊。

6.1 首部欄位一覽

通用首部欄位

請求首部欄位

響應首部欄位

實體首部欄位

七. HTTPS

傳統HTTP的缺點

• 通訊過程中使用明文（不加密），內容可能會被竊聽

  現如今的各種抓包工具Fidder、Wireshark。等等都可以拿到請求資料。

  • 機密處理防止監聽
    由於HTTP協議中沒有加密機制，但可以通過和 SSL（Secure Socket Layer，安全套接層）或 TLS（Transport Layer Security，安全層傳輸協議）的組合使用， 加密 HTTP 的通訊內容。
    用 SSL 建立安全通訊線路之後，就可以在這條線路上進行 HTTP 通訊了。與 SSL 組合使用的 HTTP 被稱為 HTTPS（HTTP Secure，超文字傳輸安全協議）或 HTTP over SSL。
  • 對內容加密
    但由於該方式不同於 SSL 或 TLS 將整個通訊線路加密 處理，所以內容仍有被篡改的風險。稍後我們會加以說明。

• 不驗證通訊方的身份，因此有可能遭遇偽裝

  • 任何人都可以傳送請求，容易遭受DOS攻擊

  • 使用檢視對手的證書

    證書由值得信任的第三方機構頒發，用以證明伺服器和客戶端是 實際存在的。另外，偽造證書從技術角度來說是異常困難的一件 事。所以只要能夠確認通訊方（伺服器或客戶端）持有的證書， 即可判斷通訊方的真實意圖，通過使用證書，以證明通訊方就是意料中的伺服器。這對使用者 個人來講，也減少了個人資訊洩露的危險性。

    另外，客戶端持有證書即可完成個人身份的確認，也可用於對 Web 網站的認證環節。

    

• 無法證明報文的完整性，所以有可能以遭篡改

  • 接收到的內容可能有誤
    從某個 Web 網站上下載內容，是無法確定客戶端下載的 檔案和伺服器上存放的檔案是否前後一致的。檔案內容在傳輸途 中可能已經被篡改為其他的內容。即使內容真的已改變，作為接 收方的客戶端也是覺察不到的，類似於這種攻擊稱為中間人攻擊（Main-in-the-Middle attack，MITM）
  • 防止篡改的辦法
    雖然有使用 HTTP 協議確定報文完整性的方法，但事實上並不便 捷、可靠。其中常用的是 MD5 和 SHA-1 等雜湊值校驗的方法， 以及用來確認檔案的數字簽名方法。但這也不是萬能的辦法，因為存在可能MD5本身被篡改的可能。

HTTP+加密+認證+完整性保護=HTTPS

需要注意的是，HTTPS並非是應用層的一種新協議。只是HTTP通訊介面部分用SSL和TLS協議代替而已。可以說HTTPS是身披SSL外殼的HTTP。通常HTTP直接和TCP通訊。當使用SSL時，則演變成先和SSL通訊，再由SSL和TCP通訊。

當使用了SSL後，HTTP就擁有了HTTPS的加密，證書和完整性保護這些功能。

加密技術

SSL 採用一種 叫做公開金鑰加密（Public-key cryptography）的加密處理方式。近代的加密方法中加密演算法是公開的，而金鑰卻是保密的。通過這種 方式得以保持加密方法的安全性。

加密和解密都會用到金鑰。沒有金鑰就無法對密碼解密，反過來說， 任何人只要持有金鑰就能解密了。加密和解密同用一個金鑰的方式稱為共享金鑰加密（Common key crypto system），也被叫做對稱金鑰加密。如果金鑰被攻擊者獲得，那加密也 就失去了意義。所以如何傳遞金鑰則很重要。

解決傳遞金鑰的問題

• 使用兩把金鑰的公開金鑰加密
  公開金鑰加密方式很好地解決了共享金鑰加密的困難。
  公開金鑰加密使用一對非對稱的金鑰。一把叫做私有金鑰 （private key），另一把叫做公開金鑰（public key）。顧名思 義，私有金鑰不能讓其他任何人知道，而公開金鑰則可以隨意發 布，任何人都可以獲得。
  使用公開金鑰加密方式，傳送密文的一方使用對方的公開金鑰進 行加密處理，對方收到被加密的資訊後，再使用自己的私有金鑰 進行解密。利用這種方式，不需要傳送用來解密的私有金鑰，也 不必擔心金鑰被攻擊者竊聽而盜走。
  另外，要想根據密文和公開金鑰，恢復到資訊原文是異常困難 的，因為解密過程就是在對離散對數進行求值，這並非輕而易舉 就能辦到。退一步講，如果能對一個非常大的整數做到快速地因 式分解，那麼密碼破解還是存在希望的。但就目前的技術來看是 不太現實的。

• HTTPS 採用混合加密機制

  HTTPS 採用共享金鑰加密和公開金鑰加密兩者並用的混合加密機制。若金鑰能夠實現安全交換，那麼有可能會考慮僅使用公開 金鑰加密來通訊。但是公開金鑰加密與共享金鑰加密相比，其處理速度要慢。

  所以應充分利用兩者各自的優勢，將多種方法組合起來用於通訊。在交換金鑰環節使用公開金鑰加密方式，之後的建立通訊交 換報文階段則使用共享金鑰加密方式。

  

證明公開金鑰正確性的證書

遺憾的是，公開金鑰加密方式還是存在一些問題的。那就是無法證明 公開金鑰本身就是貨真價實的公開金鑰。為了解決上述問題，可以使用由數字證書認證機構（CA，Certificate Authority）和其相關機關頒發的公開金鑰證書。