第 2章簡單的HTTP協議

時間 2019-11-11

標籤簡單 http 協議欄目 HTTP/TCP 简体版

原文原文鏈接

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

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

2.2 請求報文和響應報文

下面則是從客戶端發送給某個 HTTP 服務器端的請求報文中的內容瀏覽器

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

請求報文是由請求方法、請求 URI、協議版本、可選的請求首部字段和內容實體構成的。安全

響應報文基本上由協議版本、狀態碼(表示請求成功或失敗的數字代碼)、用以解釋狀態碼的緣由短語、可選的響應首部字段以及實體主體構成。服務器

HTTP/1.1 200 OK
Date: Tue, 10 Jul 2012 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)。 url

2.5 告知服務器意圖的 HTTP 方法

GET: 獲取資源 方法用來請求訪問已被 URI 識別的資源。指定的資源經服務器端解析後返回響應內容。也就是說,若是請求的資源是文本,那就保持原樣返回 spa

POST:傳輸實體主體雖然用 GET 方法也能夠傳輸實體的主體,但通常不用 GET 方法進行傳輸,而是用 POST 方法。雖然說 POST 的功能與 GET 很類似,但 POST 的主要目的並非獲取響應的主體內容 PS(主要用Post傳實體是由於實體不用跟在url後面吧) code

PUT:傳輸文件 PUT 方法用來傳輸文件。就像 FTP 協議的文件上傳同樣,要求在請求報文的主體中包含文件內容,而後保存到請求 URI 指定的位置 (可是,鑑於 HTTP/1.1 的 PUT 方法自身不帶驗證機制,任何人均可以上傳文件 , 存在安全性問題,所以通常的 Web 網站不使用該方法 ) htm

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

DELETE:刪除文件 DELETE 方法用來刪除文件,是與 PUT 相反的方法。DELETE 方法按請求 URI 刪除指定的資源 ( 圖片

可是,HTTP/1.1 的 DELETE 方法自己和 PUT 方法同樣不帶驗證機制,因此通常的 Web 網站也不使用 DELETE 方法。當配合 Web 應用程序的驗證機制,或遵照 REST 標準時仍是有可能會開放使用的。 )

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

TRACE:追蹤路徑方法是讓 Web 服務器端將以前的請求通訊環回給客戶端的方法。可是,TRACE 方法原本就不怎麼經常使用,再加上它容易引起 XST(Cross-Site Tracing,跨站追蹤)攻擊,通常就更不會用到了。

向請求 URI 指定的資源發送請求報文時,採用稱爲方法的命令。方法的做用在於,能夠指定請求的資源定期望產生某種行爲。方法中有 GET、POST 和 HEAD 等。

2.7 持久鏈接節省通訊量

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

好比,使用瀏覽器瀏覽一個包含多張圖片的 HTML 頁面時,在發送請求訪問 HTML 頁面資源的同時,也會請求該 HTML 頁面裏包含的其餘資源。所以,每次的請求都會形成無謂的 TCP 鏈接創建和斷開,增長通訊量的開銷。

2.7.1 持久鏈接

爲解決上述 TCP 鏈接的問題,HTTP/1.1 和一部分的 HTTP/1.0 想出了持久鏈接(HTTP Persistent Connections,也稱爲 HTTP keep-alive 或 HTTP connection reuse)的方法。持久鏈接的特色是,只要任意一端沒有明確提出斷開鏈接,則保持 TCP 鏈接狀態。

持久鏈接的好處在於減小了 TCP 鏈接的重複創建和斷開所形成的額外開銷,減輕了服務器端的負載。另外,減小開銷的那部分時間,使 HTTP 請求和響應可以更早地結束,這樣 Web 頁面的顯示速度也就相應提升了。

在 HTTP/1.1 中,全部的鏈接默認都是持久鏈接,但在 HTTP/1.0 內並未標準化。雖然有一部分服務器經過非標準的手段實現了持久鏈接,但服務器端不必定可以支持持久鏈接。毫無疑問,除了服務器端,客戶端也需要支持持久鏈接。

2.7.2 管線化

持久鏈接使得多數請求以管線化(pipelining)方式發送成爲可能。從前發送請求後需等待並收到響應,才能發送下一個請求。管線化技術出現後,不用等待響應亦可直接發送下一個請求。

這樣就可以作到同時並行發送多個請求,而不須要一個接一個地等待響應了。

2.8 使用 Cookie 的狀態管理

HTTP 是無狀態協議,它不對以前發生過的請求和響應的狀態進行管理。

保留無狀態協議這個特徵的同時又要解決相似的矛盾問題,因而引入了 Cookie 技術。Cookie 技術經過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態。

Cookie 會根據從服務器端發送的響應報文內的一個叫作 Set-Cookie 的首部字段信息,通知客戶端保存 Cookie。當下次客戶端再往該服務器發送請求時,客戶端會自動在請求報文中加入 Cookie 值後發送出去。

服務器端發現客戶端發送過來的 Cookie 後,會去檢查到底是從哪個客戶端發來的鏈接請求,而後對比服務器上的記錄,最後獲得以前的狀態信息。

1. 請求報文(沒有 Cookie 信息的狀態)

GET /reader/ HTTP/1.1
Host: hackr.jp 
*首部字段內沒有Cookie的相關信息

2. 響應報文(服務器端生成 Cookie 信息)

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

3. 請求報文(自動發送保存着的 Cookie 信息)

GET /image/ HTTP/1.1
Host: hackr.jp
Cookie: sid=1342077140226724

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。

第 2章 簡單的HTTP協議