HTTP在通信中扮演的角色

  瞭解完網絡中信息傳輸的基本流程之後，我們來看一下HTTP協議在這個流程中扮演的角色，HTTP協議又是如何連接客戶端與服務器的。

客戶端與服務端之間的通信

客戶端：請求訪問資源的一端。
服務端：提供資源響應的一端。
HTTP協議用於客戶端與服務端之間的通信。並且對於一次通信而言，HTTP協議能夠明確區分哪端是客戶端，哪端是服務端。

下面是客戶端發送給HTTP服務端的請求報文中的內容

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

GET 表示請求訪問服務器的類型，稱爲方法（method）。/index.htm 指明瞭請求的資源對象。也叫做請求的URI（request-URI）。最後的HTTP/1.1，表示HTTP的版本號。這段請求內容的意思是：請求訪問某臺HTTP服務器上的/index.htm頁面資源。
請求報文是由請求方法，請求URI，協議版本，可選的請求首部字段和內容實體構成。
然後再一起來看一下響應報文的主要內容：

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

開頭的HTTP/1.1表示服務器對應的HTTP版本。緊挨着的200 OK表示請求的處理結果的狀態碼（status code）和原因短語（reson-phrase）。下面一行顯示了創建響應的日期時間，是首部段（header field）內的一個屬性。之後的內容稱爲資源實體的主體。

不保存狀態的HTTP協議

HTTP是一種不保存狀態，即無狀態（stateless）協議。HTTP協議自身不對請求和響應之間的通信狀態進行保存。也就是說在HTTP這個級別，協議對於發送過的請求或響應都不做持久化處理（快速處理大量事務，確保協議的可伸縮性）。HTTP/1.1雖然是無狀態協議，但爲了實現期望的保持狀態功能，於是引入了Cookie技術。

HTTP協議中請求服務器的方法

• GET：獲取資源
     GET方法用來訪問已被URI識別的資源。指定的資源經服務器端解析後返回響應內容。
• POST：傳輸實體主體
    POST方法用來傳輸實體的主體。雖然GET方法也可以傳輸實體主體，但一般不用GET方法進行傳輸，而是用POST方法。POST的功能和GET很相似，但POST的主要目的並不是獲取響應的主體內容。
• PUT：傳輸文件
  PUT方法用來傳輸文件。像FTP協議的文件一樣，要求在請求報文的主體中包含文件內容，然後保存到請求URI指定的位置。但是，鑑於HTTP/1.1的PUT方法自身不帶驗證機制，任何人都可以上傳文件，存在安全性問題，因此一般的Web網站不使用該方法。使用時需配合Web應用程序的驗證機制，或架構設計採用REST（Representational State Transfer，表徵狀態轉移）標準的同類Web網站。
• HEAD：HEAD方法和GET方法一樣，只是不返回報文主體部分。用於確認URI的有效性及資源更新的日期時間等。
• DELETE：刪除文件。DELETE方法按請求URI刪除指定的資源。與PUT方法類型。作用不一樣而已。
• OPTIONS：OPTIONS方法用來查詢針對請求URI指定的資源支持的方法。
• TRACES：追蹤路徑。TRACE方法是讓Web服務器端將之前的請求通信返回給客戶端的方法。客戶端通過TRACE方法可以查詢發送出去的請求時怎樣被加工修改／篡改的。
  因爲請求想要連接到源目標服務器可能會通過代理中轉，TRACE方法就是用來確認連接過程中發生的一系列操作。
• CONNECT：要求用隧道協議連接代理。CONNECT方法要求在與代理服務器通信時建立隧道，實現用隧道協議進行TCP通信，主要使用SSL（Secure Sockets Layer,安全套接層）和TLS（Transport Layer Security 傳輸層安全）協議把通信內容加密後經網絡隧道傳輸。

持久連接

HTTP協議的初始版本中，每進行一次HTTP通信就要斷開TCP連接。這樣每次請求都會造成無謂的TCP連接建立和斷開，增加通信量的開銷。
- 持久連接（HTTP Persistent Connections 也稱爲HTTP keep-alive 或 HTTP connection reuse）的方法。持久連接的特點是隻要任意一端沒有明確提出斷開連接，則保持TCP連接狀態。持久連接的好處在於減少了TCP連接的重複建立和斷開所造成的額外開銷，減輕了服務器端的負載。
- 管線化（pipelining） 持久連接使得多數請求以管線化方式發送成爲可能。管線化技術出現後，不用等待響應亦可直接發送下一個請求。

使用Cookie的狀態管理

HTTP是無狀態協議，它不對之前的請求和響應的狀態進行管理。通俗一點說就是，無法根據之前的狀態進行本次的請求處理。在保留無狀態這個特徵的同時又要解決類似的矛盾問題，於是引入了Cookie技術。Cookie技術通過在請求和響應報文中寫入Cookie信息來控制客戶端的狀態。
Cookie會根據從服務器端發送的響應報文內的一個叫做Set-Cookie的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入Cookie值後發送出去。服務器端發現客戶端發送過來的Cookie後，會去檢查究竟是從哪一個客戶端發來的連接請求，然後對比服務器上的記錄，最後得到之前的狀態信息。
- 響應報文的內容：

HTTP/1.1 200K
Date: Thu,12 Jul 2012 07:12:20 GMT
Server: Apache
<Set-Cookie:sid=134207714026724;path=/;expire=Wed,10-Oct 12 07:12:20 GMT>
Content-Type: text/plain; charset=UTF-8

• 請求報文內容

GET /image/ HTTP/1.1
Host: hacker.jp
Cookie: sid=134207714026724