【圖解HTTP】第二章簡單的http協議

時間 2019-11-17

標籤圖解HTTP 第二簡單 http 協議欄目 HTTP/TCP 简体版

原文原文鏈接

簡單的HTTP協議

針對HTTP協議結構進行講解，主要使用HTTP/1.1版本。html

HTTP協議用於客戶端和服務器端之間的通訊
經過請求和響應的交換達成通訊(從客戶端開始創建通訊，服務器端在沒有接收到請求以前不會發送響應)
http是不保存狀態的協議
請求uri定位資源
告知服務器意圖的http方法
使用方法下達命令
持久鏈接節省通訊量
使用cookie的狀態管理

如今看一個具體的示例瀏覽器

從客戶端發送給某個HTTP服務器端的請求報文中的內容安全

GET /index.html HTTP/1.1服務器

Host: hackr.jpcookie

起始行開頭的GET表示請求訪問服務器的類型，成爲方法(method)。網絡

/index.html指明瞭請求訪問的資源對象，也叫作請求URIless

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

接收到請求的服務器，會將請求內容的處理結果以響應的形式返回。加密

HTTP/1.1 200 OKspa

Date:Tue, 10 Jul 2012 06:50:15 GMT

Content-Length: 362

Content-Type: text/html

<html>

... ...

200 OK表示請求的處理結果的狀態碼(status code)和緣由短語(reason-phrase)

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

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

爲了更快地處理大量事務、確保協議的可伸縮性，而特地把HTTP協議設計成如此簡單的。

爲了實現保持狀態功能，因而引入了Cookie技術。有了Cookie再用HTTP協議通訊，就能夠管理狀態了。

有關Cookie隨後講解。

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

URI須要做爲請求報文中的請求URI。指定請求URI的方式有多種。

以http://hackr.jp/index.html做爲請求的例子

URI爲完整的請求URI: GET http://hackr.jp/index.htm HTTP/1.1

在首部字段Host中寫明網絡域名或IP地址:

GET /index.htm HTTP/1.1

Host: hackr.jp

若是不是訪問特定資源而是對服務器自己發起請求，能夠用一個*來代替請求URI。

查詢HTTP服務器端支持的HTTP方法種類

OPTIONS * HTTP/1.1

介紹HTTP/1.1中可以使用的方法

GET:獲取資源

　　GET方法用來請求訪問已被URI識別的資源。指定的資源經服務器端解析後返回響應內容。

POST：傳輸實體主體

　　POST方法用來傳輸實體的主體

　　雖然GET方法也能夠傳輸實體的主體，可是通常不用GET方法進行傳輸，而是用POST方法。

PUT:傳輸文件

PUT方法用來傳輸文件，要求在請求報文的主體中包含文件內容，而後保存到請求URI指定的位置。

可是，PUT方法不帶驗證機制，存在安全性問題，通常的Web網站不使用該方法。

HEAD：得到報文首部

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

DELETE：刪除文件

與PUT相反，DELETE方法按請求URI刪除指定的資源。DELETE也不帶驗證機制，當配合Web應用程序的驗證機制，或遵照REST標準時仍是有可能會開放使用的。

OPTIONS：詢問支持的方法

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

TRACE：追蹤路徑

TRACE方法是讓Web服務器端將以前的請求通訊環回給客戶端的方法。

客戶端經過TRACE方法能夠查詢發送出去的請求是怎樣被加工修改/篡改的。

TRACE方法不經常使用,它容易引起XST(Cross-Sitr Tracing,跨站追蹤)攻擊.

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

CONNECT方法要求與代理服務器通訊時創建隧道，實現用隧道協議進行TCP通訊。主要使用SSL(Secure Sockets Layer,安全套接層)

和TLS(Transport Layer Security,傳輸層安全)協議把通訊內容加密後經網絡隧道傳輸。

CONNECT方法的格式以下

CONNECT 代理服務器名:端口號 HTTP版本

向請求URI指定的資源發送請求報文時，採用稱爲方法的命令。

方法的做用在於，能夠指定請求的資源定期望產生某種行爲，方法中有GET、POST和HEAD等。

持久鏈接節省通訊量

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

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

持久鏈接

爲解決上面的TCP鏈接問題，能夠利用持久鏈接(HTTP Persistent Connection,也稱爲HTTP keep-alive或HTTP connection reuse)的方法。持久鏈接的特色是，只要任意一端沒有明確提出斷開鏈接，則保持TCP鏈接狀態。

持久鏈接的好處在於減小了TCP鏈接的重複創建和斷開所形成的額外開銷，減輕了服務器端的負載。

管線化

持久鏈接使得多數請求以管線化(pipelining)方式發送成爲可能。從前發送請求後需等待並收到響應，才能發送下一個請求。管線化技術出現後，不用等待亦可直接發送下一個請求。這樣就可以作到同時並行發送多個請求，而不須要一個接一個地等待響應了。

Cookie技術經過在請求和響應報文中寫入Cookie信息來控制客戶端狀態。

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

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

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

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

相關標籤/搜索

每日一句

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

【圖解HTTP】第二章 簡單的http協議

簡單的HTTP協議

【圖解HTTP】第二章簡單的http協議