TCP/IP基礎總結性學習（2）

簡單的HTTP協議

一.HTTP 協議用於客戶端和服務器端之間的通訊

• 客戶端和服務器的定義：請求訪問文本或圖像等資源的一端稱爲客戶端，而提供資源響應的一 端稱爲服務器端。在兩臺計算機之間使用 HTTP 協議通訊時，在一條通訊線路上一定有 一端是客戶端，另外一端則是服務器端。

---

二.經過請求和響應的交換達成：

• HTTP 協議規定，請求從客戶端發出，最後服務器端響應該請求並返回。換句話說，確定是先從客戶端開始創建通訊的，服務器端在沒有接收到請求以前不會發送響應。
• 通訊請求和響應實例：

1.請求報文中的內容(意思是：請求訪問某臺 HTTP 服務器上的 /index.htm 頁面資源)：
GET /index.htm
HTTP/1.1 Host: hackr.jp

.
（起始行開頭的GET表示請求訪問服務器的類型，稱爲方法 （method）;字符串 /index.htm 指明瞭請求訪問的資源對象， 也叫作請求 URI（request-URI）; HTTP/1.1，即 HTTP 的版本號，用來提示客戶端使用的 HTTP 協議功能。 請求報文是由請求方法、請求 URI、協議版本、可選的請求首部字段和內容實體構成的。）

2.響應報文中的內容：

（在起始行開頭的 HTTP/1.1 表示服務器對應的 HTTP 版本。 緊挨着的 200 OK 表示請求的處理結果的狀態碼（status code）和緣由 短語（reason-phrase）。下一行顯示了建立響應的日期時間，是首部 字段（header field）內的一個屬性。 接着以一空行分隔，以後的內容稱爲資源實體的主體（entity body）。響應報文基本上由協議版本、狀態碼（表示請求成功或失敗的數字代碼）、用以解釋狀態碼的緣由短語、可選的響應首部字段以及實體主體構成。）

---

三.HTTP 是不保存狀態的協議:

• HTTP 是一種不保存狀態，即無狀態（stateless）協議。HTTP 協議自 身不對請求和響應之間的通訊狀態進行保存。

做用：爲了更快地處理大量事務，確保協議的可伸縮性，而特地把 HTTP 協議設計成如此簡單的。
侷限：隨着 Web 的不斷髮展，因無狀態而致使業務處理變得棘手的狀況增多了。好比，用戶登陸到一家購物網站，即便他跳轉到該站的其餘頁面後，也須要能繼續保持登陸狀態。
解決方案：HTTP/1.1 雖然是無狀態協議，但爲了實現指望的保持狀態功能，因而引入了 Cookie 技術（後面文章會詳談）。有了 Cookie 再用 HTTP 協議通訊，就能夠管理狀態了。

---

四.請求 URI 定位資源：

• HTTP 協議使用 URI 定位互聯網上的資源。正是由於 URI 的特定功能，在互聯網上任意位置的資源都能訪問到。

• 圖：以 http://hackr .jp/index.htm 做爲請求的例子

• 除此以外，若是不是訪問特定資源而是對服務器自己發起請求，能夠 用一個 * 來代替請求 URI。下面這個例子是查詢 HTTP 服務器端支持 的 HTTP 方法種類。

---

五.告知服務器意圖的 HTTP 方法

1.GET ：獲取資源

• GET 方法用來請求訪問已被 URI 識別的資源。指定的資源經服務器端解析後返回響應內容。也就是說，若是請求的資源是文本，那就保持原樣返回；若是是像 CGI（Common Gateway Interface，通用網關接口）那樣的程序，則返回通過執行後的輸出結果。
• 使用 GET 方法的請求-響應的例子:

2.POST：傳輸實體主體

• 雖然用 GET 方法也能夠傳輸實體的主體，但通常不用 GET 方法進行傳輸，而是用 POST 方法。雖然說 POST 的功能與 GET 很類似，但 POST 的主要目的並非獲取響應的主體內容,而是告知其響應結果。

• 使用 POST 方法的請求·響應的例子

3.PUT：傳輸文件

• 就像 FTP 協議的文件上傳同樣，要求在請求報文的主體中包含文件內容，而後保存到請求 URI 指定的位置。可是，鑑於 HTTP/1.1 的 PUT 方法自身不帶驗證機制，任何人均可以 上傳文件 , 存在安全性問題，所以通常的 Web 網站不使用該方法。若 配合 Web 應用程序的驗證機制，或架構設計採用 REST（REpresentational State Transfer，表徵狀態轉移）標準的同類 Web 網站，就可能會開放使用 PUT 方法。

• 使用 PUT 方法的請求·響應的例子：

// 響應1的意思實際上是請求執行成功了，但無數據返回

4.HEAD：得到報文首部

• HEAD 方法和 GET 方法同樣，只是不返回報文主體部分。用於確認 URI 的有效性及資源更新的日期時間等。

• 使用 HEAD 方法的請求·響應的例子：

5.DELETE：刪除文件

• DELETE 方法用來刪除文件，是與 PUT 相反的方法。DELETE 方法按 請求 URI 刪除指定的資源。 可是，HTTP/1.1 的 DELETE 方法自己和 PUT 方法同樣不帶驗證機制，因此通常的 Web 網站也不使用 DELETE 方法。當配合 Web 應用 程序的驗證機制，或遵照 REST 標準時仍是有可能會開放使用的。

• 使用 DELETE 方法的請求·響應的例子：

6.OPTIONS：詢問支持的方法

• OPTIONS 方法用來查詢針對請求 URI 指定的資源支持的方法。

• 使用 OPTIONS 方法的請求·響應的例子：

7.TRACE：追蹤路徑

• TRACE 方法是讓 Web 服務器端將以前的請求通訊環回給客戶端的方法。發送請求時，在 Max-Forwards 首部字段中填入數值，每通過一個服務器端就將該數字減 1，當數值恰好減到 0 時，就中止繼續傳輸，最後接收到請求的服務器端則返回狀態碼 200 OK 的響應。 客戶端經過 TRACE 方法能夠查詢發送出去的請求是怎樣被加工修改 / 篡改的。這是由於，請求想要鏈接到源目標服務器可能會經過代理 中轉，TRACE 方法就是用來確認鏈接過程當中發生的一系列操做。 可是，TRACE 方法原本就不怎麼經常使用，再加上它容易引起 XST（Cross-Site Tracing，跨站追蹤）攻擊，一般就更不會用到了。

• 使用 TRACE 方法的請求·響應的例子：

8.CONNECT：要求用隧道協議鏈接代理

• CONNECT 方法要求在與代理服務器通訊時創建隧道，實現用隧道協議進行 TCP 通訊。主要使用 SSL（Secure Sockets Layer，安全套接 層）和 TLS（Transport Layer Security，傳輸層安全）協議把通訊內容加密後經網絡隧道傳輸。
• CONNECT 方法的格式以下所示

• 使用 CONNECT 方法的請求·響應的例子：

總結：

---

五.持久鏈接節省通訊量

1.短鏈接：HTTP 協議的初始版本中，每進行一次 HTTP 通訊就要斷開一次 TCP 鏈接。

2.持久鏈接的特色是:只要任意一端 沒有明確提出斷開鏈接，則保持 TCP 鏈接狀態。
持久鏈接的好處:減小了 TCP 鏈接的重複創建和斷開所形成的額外開銷，減輕了服務器端的負載。另外，減小開銷的那部分時間，使 HTTP 請求和響應可以更早地結束，這樣 Web 頁面的顯示速度也就相應提升了。

3.管線化：持久鏈接使得多數請求以管線化（pipelining）方式發送成爲可能。從前發送請求後需等待並收到響應，才能發送下一個請求。管線化技術出現後，不用等待響應亦可直接發送下一個請求。而管線化技術則比持久鏈接還要快。請求數越多，時間差就越明顯

六.Cookie 技術
1.引入起因：HTTP協議保留無狀態協議這個特徵的同時又要解決相似的矛盾問題，因而引入了 Cookie 技術。
2.工做原理：Cookie 技術經過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態。Cookie 會根據從 端發送的響應報文內的一個叫作 Set-Cookie 的首部字段信息，通知客戶端保存 Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入 Cookie 值後發送出去。服務器端發現客戶端發送過來的 Cookie 後，會去檢查到底是從哪個客戶端發來的鏈接請求，而後對比服務器上的記錄，最後獲得以前的狀態信息。
3.圖例：
發生 Cookie 交互的情景：

HTTP請求報文和響應報文的內容以下：