計網學習筆記(12)- HTTP

weixin_34107955發表於2017-12-14

一、HTTP

超文字傳輸協議(HyperText Transfer Protocol,HTTP)是一種面向事務,用於分散式、協作式和超媒體資訊系統的應用層協議。HTTP 是全球資訊網的資料通訊的基礎。設計 HTTP 最初的目的是為了提供一種釋出和接收 HTML 頁面的方法。通過 HTTP 或者 HTTPS 協議請求的資源由統一資源識別符號(Uniform Resource Identifiers,URI)來標識。

通過使用網頁瀏覽器、網路爬蟲或者其它的工具,客戶端發起一個 HTTP 請求到伺服器上指定埠(預設埠為 80)。我們稱這個客戶端為使用者代理程式(user agent)。應答的伺服器上儲存著一些資源,比如 HTML 檔案和影象。我們稱這個應答伺服器為源伺服器(origin server)。在使用者代理和源伺服器中間可能存在多個 “中間層”,比如代理伺服器、閘道器或者隧道(tunnel)。

HTTP 協議中,並沒有規定必須使用它或它支援的層。事實上,HTTP 可以在任何網際網路協議上,或其他網路上實現。HTTP 假定其下層協議提供可靠的傳輸。因此,任何能夠提供這種保證的協議都可以被其使用。因此也就是其在 TCP/IP 協議族使用 TCP 作為其傳輸層。

通常,由 HTTP 客戶端發起一個請求,建立一個到伺服器指定埠(預設是 80 埠)的 TCP 連線。HTTP 伺服器則在那個埠監聽客戶端的請求。一旦收到請求,伺服器會向客戶端返回一個狀態,比如 "HTTP/1.1 200 OK",以及返回的內容,如請求的檔案、錯誤訊息、或者其它資訊。

1. HTTP 主要特點
  • HTTP 是面向事務的客戶伺服器協議。

  • HTTP 1.0 協議是無狀態的 (stateless)。

  • HTTP 協議本身也是無連線的,雖然它使用了面向連線的 TCP 向上提供的服務。

2. 報文格式

HTTP 報文是面向文字的,報文中的每一個欄位都是一些 ASCII 碼串,各個欄位的長度是不確定的。

HTTP 協議的請求方法有 GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。

  1. GET:當客戶端要從伺服器中讀取某個資源時,使用 GET 方法。GET 方法要求伺服器將 URL 定位的資源放在響應報文的部分,回送給客戶端,即向伺服器請求某個資源。使用 GET 方法時,請求引數和對應的值附加在 URL 後面,利用一個問號 (“?”) 代表 URL 的結尾與請求引數的開始,傳遞引數長度受限制。例如,/index.jsp?id=100&op=bind。GET 方式的請求一般不包含”請求內容”部分,請求資料以地址的形式表現在請求行,所以我們可以把請求結果以連結的形式傳送給他人。這種方式不適合傳送私密資料。另外,由於不同的瀏覽器對地址的字元限制也有所不同,一般最多隻能識別 1024 個字元,所以如果需要傳送大量資料的時候,也不適合使用 GET 方式。

  2. POST:當客戶端給伺服器提供資訊較多時可以使用 POST 方法,POST 方法向伺服器提交資料,比如完成表單資料的提交,將資料提交給伺服器處理。GET 一般用於獲取或查詢資源資訊,POST 會附帶使用者資料,一般用於更新資源資訊。POST 方法將請求引數封裝在 HTTP 請求資料中,以名稱 - 值的形式出現,可以傳輸大量資料,而且也不會顯示在 URL 中。

  3. HEAD:與 GET 方法一樣,都是向伺服器發出指定資源的請求。只不過伺服器將不傳回資源的本文部分。它的好處在於,使用這個方法可以在不必傳輸全部內容的情況下,就可以獲取其中“關於該資源的資訊”(元資訊或稱後設資料,當前頁面的狀態)。

3. 請求報文格式如下:

HTTP 響應報文由四個部分組成,分別是:請求行、請求頭、空行、請求體。

7182360-05e5f7f7f5cf8dca.png
請求報文格式
GET / HTTP/1.1(請求行)

Host: www.google.com(請求頭)
(空行)
3.1 請求行

以方法欄位開始,後面分別是 URL 欄位和 HTTP 協議版本欄位,並以 < CR><LF> 結尾。

3.2 請求頭部

由關鍵字/值對組成,每行一對,關鍵字和值用英文冒號 “:” 分隔。請求頭部通知伺服器有關於客戶端請求的資訊,典型的請求頭有:

  • User-Agent:產生請求的瀏覽器型別。

  • Accept:客戶端可識別的內容型別列表。

  • Host:請求的主機名,允許多個域名同處一個 IP 地址,即虛擬主機。

在 HTTP/1.1 協議中,所有的請求頭,除 Host 外,都是可選的。

3.3 空行

最後一個請求頭之後是一個空行,傳送回車符 <CR> 和換行符 <LF>,通知伺服器以下不再有請求頭。必須只有 <CR><LF> 而無其他空格。

3.4 請求資料

請求資料不在 GET 方法中使用,而是在 POST 方法中使用。POST 方法適用於需要客戶填寫表單的場合。與請求資料相關的最常使用的請求頭是 Content-TypeContent-Length

4. 響應報文格式如下:

HTTP 響應報文由三個部分組成,分別是:狀態行、響應頭部、響應包體。

7182360-e0f548afd295c80d.png
響應報文格式
HTTP/1.1 200 OK(狀態行)

Content-Length: 3059(響應頭部)
Server: GWS/2.0
Date: Sat, 11 Jan 2003 02:44:04 GMT
Content-Type: text/html
Cache-control: private
Set-Cookie: PREF=ID=73d4aef52e57bae9:TM=1042253044:LM=1042253044:S=SMCc_HRPCQiqy
X9j; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com
Connection: keep-alive
(緊跟著一個空行,並且由HTML格式的文字組成了Google的主頁)
4.1 狀態行

狀態行由 HTTP 協議版本欄位、狀態碼和狀態碼的描述文字 3 個部分組成,它們之間使用空格隔開。

4.2 響應頭部

例如:

  • Location:Location 響應報頭域用於重定向接受者到一個新的位置。例如:客戶端所請求的頁面已不存在原先的位置,為了讓客戶端重定向到這個頁面新的位置,伺服器端可以發回 Location 響應報頭後使用重定向語句,讓客戶端去訪問新的域名所對應的伺服器上的資源。

  • Server:Server 響應報頭域包含了伺服器用來處理請求的軟體資訊及其版本。它和 User-Agent 請求報頭域是相對應的,前者傳送伺服器端軟體的資訊,後者傳送客戶端軟體(瀏覽器)和作業系統的資訊。

  • Connection:連線方式。

4.3 空行

最後一個響應頭部之後是一個空行,傳送回車符 <CR> 和換行符 <LF>,通知伺服器以下不再有響應頭部。

4.4 響應包體

伺服器返回給客戶端的文字資訊。

二、HTTP 狀態碼

  • 1xx 訊息 —— 請求已被伺服器接收,繼續處理

  • 2xx 成功 —— 請求已成功被伺服器接收、理解、並接受

  • 3xx 重定向 —— 需要後續操作才能完成這一請求

  • 4xx 請求錯誤 —— 請求含有詞法錯誤或者無法被執行

  • 5xx 伺服器錯誤 —— 伺服器在處理某個正確請求時發生錯誤

1xx:訊息
100 Continue
伺服器僅接收到部分請求,但是一旦伺服器並沒有拒絕該請求,客戶端應該繼續傳送其餘的請求。
101 Switching Protocols
伺服器轉換協議:伺服器將遵從客戶的請求轉換到另外一種協議。
2xx:成功
200 OK
請求成功(其後是對GET和POST請求的應答文件。)
201 Created
請求被建立完成,同時新的資源被建立。
202 Accepted
供處理的請求已被接受,但是處理未完成。
203 Non-authoritative Information
文件已經正常地返回,但一些應答頭可能不正確,因為使用的是文件的拷貝。
204 No Content
沒有新文件。瀏覽器應該繼續顯示原來的文件。如果使用者定期地重新整理頁面,而Servlet可以確定使用者文件足夠新,這個狀態程式碼是很有用的。
205 Reset Content
沒有新文件。但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容。
206 Partial Content
客戶傳送了一個帶有Range頭的GET請求,伺服器完成了它。
3xx:重定向
300 Multiple Choices
多重選擇。連結列表。使用者可以選擇某連結到達目的地。最多允許五個地址。
301 Moved Permanently
所請求的頁面已經轉移至新的url。
302 Found
所請求的頁面已經臨時轉移至新的url。
303 See Other
所請求的頁面可在別的url下被找到。
304 Not Modified
未按預期修改文件。客戶端有緩衝的文件併發出了一個條件性的請求(一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文件)。伺服器告訴客戶,原來緩衝的文件還可以繼續使用。
305 Use Proxy
客戶請求的文件應該通過Location頭所指明的代理伺服器提取。
306 Unused
此程式碼被用於前一版本。目前已不再使用,但是程式碼依然被保留。
307 Temporary Redirect
被請求的頁面已經臨時移至新的url。
4xx:客戶端錯誤
400 Bad Request
伺服器未能理解請求。
401 Unauthorized
被請求的頁面需要使用者名稱和密碼。
401.1
登入失敗。
401.2
伺服器配置導致登入失敗。
401.3
由於 ACL 對資源的限制而未獲得授權。
401.4
篩選器授權失敗。
401.5
ISAPI/CGI 應用程式授權失敗。
401.7
訪問被 Web 伺服器上的 URL 授權策略拒絕。這個錯誤程式碼為 IIS 6.0 所專用。
402 Payment Required
此程式碼尚無法使用。
403 Forbidden
對被請求頁面的訪問被禁止。
403.1
執行訪問被禁止。
403.2
讀訪問被禁止。
403.3
寫訪問被禁止。
403.4
要求 SSL。
403.5
要求 SSL 128。
403.6
IP 地址被拒絕。
403.7
要求客戶端證書。
403.8
站點訪問被拒絕。
403.9
使用者數過多。
403.10
配置無效。
403.11
密碼更改。
403.12
拒絕訪問對映表。
403.13
客戶端證書被吊銷。
403.14
拒絕目錄列表。
403.15
超出客戶端訪問許可。
403.16
客戶端證書不受信任或無效。
403.17
客戶端證書已過期或尚未生效。
403.18
在當前的應用程式池中不能執行所請求的 URL。這個錯誤程式碼為 IIS 6.0 所專用。
403.19
不能為這個應用程式池中的客戶端執行 CGI。這個錯誤程式碼為 IIS 6.0 所專用。
403.20
Passport 登入失敗。這個錯誤程式碼為 IIS 6.0 所專用。
404 Not Found
伺服器無法找到被請求的頁面。
404.0
(無)–沒有找到檔案或目錄。
404.1
無法在所請求的埠上訪問 Web 站點。
404.2
Web 服務擴充套件鎖定策略阻止本請求。
404.3
MIME 對映策略阻止本請求。
405 Method Not Allowed
請求中指定的方法不被允許。
406 Not Acceptable
伺服器生成的響應無法被客戶端所接受。
407 Proxy Authentication Required
使用者必須首先使用代理伺服器進行驗證,這樣請求才會被處理。
408 Request Timeout
請求超出了伺服器的等待時間。
409 Conflict
由於衝突,請求無法被完成。
410 Gone
被請求的頁面不可用。
411 Length Required
"Content-Length" 未被定義。如果無此內容,伺服器不會接受請求。
412 Precondition Failed
請求中的前提條件被伺服器評估為失敗。
413 Request Entity Too Large
由於所請求的實體的太大,伺服器不會接受請求。
414 Request-url Too Long
由於url太長,伺服器不會接受請求。當post請求被轉換為帶有很長的查詢資訊的get請求時,就會發生這種情況。
415 Unsupported Media Type
由於媒介型別不被支援,伺服器不會接受請求。
416 Requested Range Not Satisfiable
伺服器不能滿足客戶在請求中指定的Range頭。
417 Expectation Failed
執行失敗。
423
鎖定的錯誤。
5xx:伺服器錯誤
500 Internal Server Error
請求未完成。伺服器遇到不可預知的情況。
500.12
應用程式正忙於在 Web 伺服器上重新啟動。
500.13
Web 伺服器太忙。
500.15
不允許直接請求 Global.asa。
500.16
UNC 授權憑據不正確。這個錯誤程式碼為 IIS 6.0 所專用。
500.18
URL 授權儲存不能開啟。這個錯誤程式碼為 IIS 6.0 所專用。
500.100
內部 ASP 錯誤。
501 Not Implemented
請求未完成。伺服器不支援所請求的功能。
502 Bad Gateway
請求未完成。伺服器從上游伺服器收到一個無效的響應。
502.1
CGI 應用程式超時。 ·
502.2
CGI 應用程式出錯。
503 Service Unavailable
請求未完成。伺服器臨時過載或當機。
504 Gateway Timeout
閘道器超時。
505 HTTP Version Not Supported
伺服器不支援請求中指明的HTTP協議版本。

三、HTTP 持久連線

HTTP 持久連線(HTTP persistent connection,也稱作 HTTP keep-alive 或 HTTP connection reuse)。是使用同一個 TCP 連線來傳送和接收多個 HTTP 請求/應答,而不是為每一個新的請求或應答開啟新的連線的方法。

HTTP 1.1 中 所有的連線預設都是持續連線,除非特殊宣告不支援。HTTP 持久連線不使用獨立的 keepalive 資訊,而是僅僅允許多個請求使用單個連線。然而,Apache 2.0 httpd 的預設連線過期時間是僅僅 15 秒,對於 Apache 2.2 只有 5 秒。短的過期時間的優點是能夠快速的傳輸多個 web 頁元件,而不會繫結多個伺服器程式或執行緒太長時間。

7182360-ec6d62f01e7fd14a.png
優點:
  1. 較少的 CPU 和記憶體的使用(由於同時開啟的連線的減少了)

  2. 允許請求和應答的 HTTP 管線化

  3. 降低擁塞控制 (TCP 連線減少了)

  4. 減少了後續請求的延遲(無需再進行握手)

  5. 報告錯誤無需關閉 TCP 連線

缺點:

對於現在的廣泛普及的寬頻連線來說,Keep-Alive 也許並不像以前一樣有用。web 伺服器會保持連線若干秒(Apache 中預設 15 秒),這與提高的效能相比也許會影響效能。對於單個檔案被不斷請求的服務(例如圖片存放網站),Keep-Alive 可能會極大的影響效能,因為它在檔案被請求之後還保持了不必要的連線很長時間。

四、代理伺服器

代理伺服器 (proxy server) 又稱為全球資訊網快取記憶體 (Web cache),它代表瀏覽器發出 HTTP 請求。全球資訊網快取記憶體把最近的一些請求和響應暫存在本地磁碟中。當與暫時存放的請求相同的新請求到達時,全球資訊網快取記憶體就把暫存的響應傳送出去,而不需要按 URL 的地址再去網際網路訪問該資源。

作用:資訊快取、資訊轉發、共享 IP 地址。

優點:使用快取記憶體可減少訪問網際網路伺服器的時延。

代理伺服器的作用主要有以下4個。
  • 代理伺服器提供遠端資訊本地快取功能,減少資訊的重複傳輸。

  • 所有使用代理伺服器的使用者都必須通過代理伺服器訪問遠端站點,因此在代理伺服器上就可以設定相應的限制,以過濾或遮蔽掉某些資訊。因此代理伺服器可以起到防火牆的作用。

  • 通過代理伺服器可訪問一些不能直接訪問的網站。網際網路上有許多開放的代理伺服器,客戶在訪問許可權受到限制時,而這些代理伺服器的訪問許可權是不受限制的,剛好代理伺服器在客戶的訪問範圍之內,那麼客戶通過代理伺服器訪問目標網站就成為可能。

  • 安全性得到提高。無論是上聊天室還是瀏覽網站,目的網站只能知道你來自於代理伺服器,而你的真實IP地址就無法測知。

不包含資訊加解密,通常要使用專用的加密軟體及加密演算法來完成。

相關文章