碼上快樂

相關內容    簡體    繁體

圖文詳解互聯網根基之HTTP

本文轉載自   查看原文   2019-03-30 20:58   1179 

這是本人對《圖解HTTP》和《HTTP權威指南》閱讀后總結的大家常用的、重要的知識點，前端、后端同學居家必備！

一、概述

HTTP是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫。

HTTP是一個應用層協議，由請求和響應構成，是一個標准的客戶端服務器模型。HTTP是一個無狀態的協議。

在Internet中所有的傳輸都是通過TCP/IP進行的。HTTP協議作為TCP/IP模型中應用層的協議也不例外。HTTP協議通常承載於TCP協議之上，有時也承載於TLS或SSL協議層之上，這個時候，就成了我們常說的HTTPS。如下圖所示：


 

HTTP默認的端口號為80，HTTPS的端口號為443。

瀏覽網頁是HTTP的主要應用，但是這並不代表HTTP就只能應用於網頁的瀏覽。HTTP是一種協議，只要通信的雙方都遵守這個協議，HTTP就能有用武之地。比如咱們常用的微信、QQ這些軟件，都會使用HTTP協議(還包括其他的協議)。即將到來的HTTP2和HTTP3也是基於或兼容HTTP協議的。

它的發展是萬維網協會（World Wide Web Consortium）和Internet工作小組IETF（Internet Engineering Task Force）合作的結果，（他們）最終發布了一系列的RFC，RFC 1945定義了HTTP/1.0版本。其中最著名的就是RFC 2616。RFC 2616定義了今天普遍使用的一個版本——HTTP 1.1。我今天主要圍繞HTTP/1.1來講解。

二、網絡基礎TCP/IP

2.1 TCP/IP

為了理解 HTTP，我們有必要事先了解一下 TCP/IP 協議族。 通常使用的網絡（包括互聯網）是在 TCP/IP 協議族的基礎上運作 的。而 HTTP 屬於它內部的一個子集。 接下來，我們僅介紹理解 HTTP 所需掌握的 TCP/IP 協議族的概要。 若想進一步學習有關 TCP/IP 的知識，請參考其他講解 TCP/IP 的專業書籍。

TCP/IP 是互聯網相關的各類協議族的總稱。

2.2 TCP/IP分層

  • 應用層

決定了向用戶提供應用服務時通信的活動,如HTTP、FTP協議、DNS服務、

  • 傳輸層

提供處於網絡連接中的兩台計算機之間的數據傳輸。TCP、UDP協議

  • 網絡層

處理在網絡上流動的數據包。數據包是網絡傳輸的最小數據單位。

  • 鏈路層

處理連接網絡的硬件部分。包括控制操作系統、硬件的設備驅
動、網絡適配器,及光纖等物理可見部分

2.3 傳輸

  • 傳輸流

　　IP 間的通信依賴 MAC 地址。在網絡上，通信的雙方在同一局域網 （LAN）內的情況是很少的，通常是經過多台計算機和網絡設備中轉 才能連接到對方。而在進行中轉時，會利用下一站中轉設備的 MAC 地址來搜索下一個中轉目標。這時，會采用 ARP 協議（Address Resolution Protocol）。ARP 是一種用以解析地址的協議，根據通信方 的 IP 地址就可以反查出對應的 MAC 地址。

 

  • 封裝

    數據在層與層之間傳輸時，每經過一層時必定會被打上一個該層所屬的首部信息，並在接收端逐層消去。


　　這種把數據信息包裝起來的做法稱為封裝。

2.4 協議

  • IP 協議（傳輸）

    位於網絡層，利用IP地址(可變)和MAC地址（網卡固定地址）把各種數據包准確傳送給對方，使用ARP協議憑借 MAC 地址進行通信。

  • TCP協議（確保准確性）

    位於傳輸層，將大塊數據分割成以報文段（segment）為單位的數據包進行管理。

    TCP可以采用三次握手策略，確保將數據送達目標，若握手過程莫名中斷，TCP協議會再次以相同的順序發送相同的數據包。

  • URI解析

　　　先說下URI和URL：URL（Uniform Resource Locator,統一資源定位符） 是URI（Universal Resource Identifier）的子集，比如身份證ID是URI的實例。協議類型://地球/中國/浙江省/杭州市/西湖區/某大學/1號宿舍樓/1號寢/張三也能唯一的表示一個實體，所以它也是URI的實例。URL一般表示為:

  • DNS 服務（域名解析）

　　　位於應用層，提供域名到 IP 地址之間的解析服務

 

這是完整的網頁請求流程。

 

2.5 TCP鏈接

世界上幾乎所有的 HTTP 通信都是由 TCP/IP 承載的，TCP/IP 是全球計算機及網絡設備都在使用的一種常用的分組交換網絡分層協議集。客戶端應用程序可以打開一 條 TCP/IP 連接，連接到可能運行在世界任何地方的服務器應用程序。一旦連接建 立起來了，在客戶端和服務器的計算機之間交換的報文就永遠不會丟失、受損或 失序。 HTTP 連接實際上就是 TCP 連接及其使用規則。 TCP 連接是因特網上的可靠連接。 要想正確、快速地發送數據，就需要了解 TCP 的一些基本知識。

如上圖，HTTP 和 HTTPS 網絡協議棧。HTTP 要傳送一條報文時，會以流的形式將報文數據的內容通過一條打開的 TCP 連 接按序傳輸。TCP 收到數據流之后，會將數據流砍成被稱作段的小數據塊，並將段 封裝在 IP 分組中，通過因特網進行傳輸。

在任意時刻計算機都可以有幾條 TCP 連接處於打開狀態。TCP 是通過端口號來保持 所有這些連接持續不斷地運行。 端口號和雇員使用的電話分機號很類似。就像公司的總機號碼能將你接到前台，而 分機號可以將你接到正確的雇員位置一樣，IP 地址可以將你連接到正確的計算機， 而端口號則可以將你連接到正確的應用程序上去。TCP 連接是通過 4 個值來識別的：

< 源 IP 地址、源端口號、目的 IP 地址、目的端口號 >

這 4 個值一起唯一地定義了一條連接。兩條不同的 TCP 連接不能擁有 4 個完全相同 的地址組件值（但不同連接的部分組件可以擁有相同的值）。

TCP連接值信息如上圖。

有些連接共享了相同的目的端口號（C 和 D 都使用目的端口號 80）。有些連 接使用了相同的源 IP 地址（B 和 C）。有些使用了相同的目的 IP 地址（A 和 B，C 和 D）。

TCP 客戶端和服務器是如何通過 TCP 套接字接口進行通信。

2.6 時延控制

  • TCP慢啟動

TCP 數據傳輸的性能還取決於 TCP 連接的使用期（age）。TCP 連接會隨着時間進行 自我“調諧”，起初會限制連接的最大速度，如果數據成功傳輸，會隨着時間的推移 提高傳輸的速度。這種調諧被稱為 TCP 慢啟動（slow start），用於防止因特網的突 然過載和擁塞。為優化慢啟動問題，稍后會介紹這些 HTTP“持久連接”。

  • 握手：

　　建立一條新的 TCP 連接時，甚至是在發送任意數據之前，TCP 軟件之間會交換一系 列的 IP 分組，對連接的有關參數進行溝通（參見圖 4-8）。如果連接只用來傳送少量 數據，這些交換過程就會嚴重降低 HTTP 的性能。HTTP 程序員永遠不會看到這些分組——這些分組都由 TCP/IP 軟件管理，對其是不 可見的。HTTP 程序員看到的只是創建 TCP 連接時存在的時延。

  • 延遲確認

　　由於因特網自身無法確保可靠的分組傳輸（因特網路由器超負荷的話，可以隨意丟 棄分組），所以 TCP 實現了自己的確認機制來確保數據的成功傳輸。延遲確認算法會在一個特定的窗口時間（通常是 100 ～ 200 毫 秒）內將輸出確認存放在緩沖區中，以尋找能夠捎帶它的輸出數據分組。如果在那 個時間段內沒有輸出數據分組，就將確認信息放在單獨的分組中傳送。

  • TCP_NODELAY

　　TCP 有一個數據流接口，應用程序可以通過它將任意尺寸的數據放入 TCP 棧中—— 即使一次只放一個字節也可以！但是，每個 TCP 段中都至少裝載了 40 個字節的標 記和首部，所以如果 TCP 發送了大量包含少量數據的分組，網絡的性能就會嚴重 下降。Nagle 算法會引發幾種 HTTP 性能問題。首先，小的 HTTP 報文可能無法填滿一個 分組，可能會因為等待那些永遠不會到來的額外數據而產生時延。其次，Nagle 算 法與延遲確認之間的交互存在問題——Nagle 算法會阻止數據的發送，直到有確認 分組抵達為止，但確認分組自身會被延遲確認算法延遲 100 ～ 200 毫秒。7 HTTP 應用程序常常會在自己的棧中設置參數 TCP_NODELAY，禁用 Nagle 算法， 提高性能。如果要這么做的話，一定要確保會向 TCP 寫入大塊的數據，這樣就不會 產生一堆小分組了。

  • TIME_WAIT累積與端口耗盡

　　大多數遇到性能基准問題的人最終都會碰到這個問題，而且性能都會變 得出乎意料地差，所以這個問題值得特別關注。當某個 TCP 端點關閉 TCP 連接時，會在內存中維護一個小的控制塊，用來記錄最 近所關閉連接的 IP 地址和端口號。這類信息只會維持一小段時間，通常是所估計的 最大分段使用期的兩倍（稱為 2MSL，通常為 2 分鍾 ）左右，以確保在這段時間內 不會創建具有相同地址和端口號的新連接。實際上，這個算法可以防止在兩分鍾內 創建、關閉並重新創建兩個具有相同 IP 地址和端口號的連接。

　　客戶端每次連接到服務器上去時，都會獲得一個新的源端口，以實現連接的唯一性。 但由於可用源端口的數量有限（比如，65535 個），而且在 2MSL 秒（比如，120 秒）內連接是無法重用的，連接率就被限制在了 60 000/120=500 次 / 秒。如果再不 斷進行優化，並且服務器的連接率不高於 500 次 / 秒，就可確保不會遇到 TIME_ WAIT 端口耗盡問題。要修正這個問題，可以增加客戶端負載生成機器的數量，或 者確保客戶端和服務器在循環使用幾個虛擬 IP 地址以增加更多的連接組合。

　　即使沒有遇到端口耗盡問題，也要特別小心有大量連接處於打開狀態的情況，或為處於等待狀態的連接分配了大量控制塊的情況。在有大量打開連接或控制塊的情況 下，有些操作系統的速度會嚴重減緩。

  • 串行事務處理時延

　　瀏覽器需要發起 4 個 HTTP 事務來顯示此頁面： 1 個用於頂層的 HTML 頁面，3 個用於嵌入的圖片。如果每個事務都需要（串行地建 立）一條新的連接，那么連接時延和慢啟動時延就會疊加起來。

　　解決方案有：

  1. 　　　　並行連接 通過多條 TCP 連接發起並發的 HTTP 請求。
  2. 　　　　持久連接 重用 TCP 連接，以消除連接及關閉時延。
  3. 　　　　管道化連接 通過共享的 TCP 連接發起並發的 HTTP 請求。

三、HTTP鏈接

3.1 鏈接特性

HTTP協議永遠都是客戶端發起請求，服務器回送響應。這樣就限制了使用HTTP協議，無法實現在客戶端沒有發起請求的時候，服務器將消息推送給客戶端。

HTTP協議的主要特點可概括如下：

  1. 支持客戶/服務器模式。支持基本認證和安全認證。
  2. 簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯系的類型不同。由於HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快。
  3. 靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
  4. 高效：HTTP 0.9和1.0使用非持續連接：限制每次連接只處理一個請求，服務器處理完客戶的請求，並收到客戶的應答后，即斷開連接。HTTP 1.1使用持續連接：不必為每個web對象創建一個新的連接，一個連接可以傳送多個對象，采用這種方式可以節省傳輸時間。
  5. 無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味着如果后續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。

無狀態協議：

協議的狀態是指下一次傳輸可以“記住”這次傳輸信息的能力。

http是不會為了下一次連接而維護這次連接所傳輸的信息,為了保證服務器內存。

比如客戶獲得一張網頁之后關閉瀏覽器，然后再一次啟動瀏覽器，再登陸該網站，但是服務器並不知道客戶關閉了一次瀏覽器。

由於Web服務器要面對很多瀏覽器的並發訪問，為了提高Web服務器對並發訪問的處理能力，在設計HTTP協議時規定Web服務器發送HTTP應答報文和文檔時，不保存發出請求的Web瀏覽器進程的任何狀態信息。這有可能出現一個瀏覽器在短短幾秒之內兩次訪問同一對象時，服務器進程不會因為已經給它發過應答報文而不接受第二期服務請求。由於Web服務器不保存發送請求的Web瀏覽器進程的任何信息，因此HTTP協議屬於無狀態協議（Stateless Protocol）。

HTTP協議是無狀態的和Connection: keep-alive的區別：

無狀態是指協議對於事務處理沒有記憶能力，服務器不知道客戶端是什么狀態。從另一方面講，打開一個服務器上的網頁和你之前打開這個服務器上的網頁之間沒有任何聯系。

HTTP是一個無狀態的面向連接的協議，無狀態不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是必須是UDP協議（無連接），如HTTP/3將TCP替換成UDP實現高速、穩定的傳輸。


從HTTP/1.1起，默認都開啟了Keep-Alive，保持連接特性，簡單地說，當一個網頁打開完成后，客戶端和服務器之間用於傳輸HTTP數據的TCP連接不會關閉，如果客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立的連接。
Keep-Alive不會永久保持連接，它有一個最大空閑的保持時間，即鏈接空閑無操作時到達一定時間會自動斷開，可以在不同的服務器軟件（如Nginx/Apache）中設定這個時間。如果鏈接有活動，那么鏈接的保持時間會被延長（相當於給會話續租）。

四、工作流程

4.1 HTTP工作流

一次HTTP操作稱為一個事務，其工作過程可分為四步：

  1. 首先客戶機與服務器需要建立連接。只要單擊某個超級鏈接，HTTP的工作開始。
  2. 建立連接后，客戶機發送一個請求給服務器，請求方式的格式為：統一資源標識符（URL）、協議版本號，后邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。
  3. 服務器接到請求后，給予相應的響應信息，其格式為一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，后邊是MIME信息包括服務器信息、實體信息和可能的內容。
  4. 客戶端接收服務器所返回的信息通過瀏覽器顯示在用戶的顯示屏上，然后客戶機與服務器斷開連接。
  5. 如果在以上過程中的某一步出現錯誤，那么產生錯誤的信息將返回到客戶端，有顯示屏輸出。對於用戶來說，這些過程是由HTTP自己完成的，用戶只要用鼠標點擊，等待信息顯示就可以了。

 

 

 

HTTP是基於傳輸層的TCP協議，而TCP是一個端到端的面向連接的協議。所謂的端到端可以理解為進程到進程之間的通信。所以HTTP在開始傳輸之前，首先需要建立TCP連接，而TCP連接的過程需要所謂的“三次握手”。下圖所示TCP連接的三次握手。
在TCP三次握手之后，建立了TCP連接，此時HTTP就可以進行傳輸了。一個重要的概念是面向連接，既HTTP在傳輸完成之間並不斷開TCP連接。在HTTP1.1中(通過Connection頭設置)這是默認行為。

 

4.2 持久鏈接（又稱“長鏈接”）

HTTP 協議的初始版本中，每進行一次 HTTP 通信就要斷開一次 TCP 連接。HTTP/1.1想出了 持久連接（HTTP Persistent Connections，也稱為 HTTP keep-alive 或 HTTP connection reuse）的方法。持久連接的特點是，只要任意一端沒有明確提出斷開連接，則保持 TCP 連接狀態。 

 

這樣的話使用瀏覽器瀏覽一個包含多張圖片的 HTML頁面時，在發送請求訪問 HTML頁面資源的同時，也會請求該 HTML頁面里包含的 其他資源。因此，每次的請求都會造成無謂的 TCP 連接建立和斷 開，增加通信量的開銷。

 

4.3 管線化

持久連接使得多數請求以管線化（pipelining）方式發送成為可能。從 前發送請求后需等待並收到響應，才能發送下一個請求。管線化技術 出現后，不用等待響應亦可直接發送下一個請求。

4.4 狀態保持之Cookie

HTTP 是無狀態協議，它不對之前發生過的請求和響應的狀態進行管理。保留無狀態協議這個特征的同時又要解決類似的矛盾問題，於是引入 了 Cookie 技術。Cookie 技術通過在請求和響應報文中寫入 Cookie 信 息來控制客戶端的狀態。 Cookie 會根據從服務器端發送的響應報文內的一個叫做 Set-Cookie 的 首部字段信息，通知客戶端保存 Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中攜帶Cookie 值后發送出去。

 

五、HTTP消息體結構

5.1 客戶端請求消息

我們來看一下請求報文和響應報文的結構。 

 

三個部分分別是：狀態行、消息報頭、響應正文(報文主體), 通常, 不一定要有報文主體。

客戶端發送一個HTTP請求到服務器的請求消息包括以下格式：請求行（request line）、請求頭部（header）、空行（即回車+換行，又叫CR+LF）、請求數據四個部分組成，下圖給出了請求報文的一般格式。

2012072810301161

例如：

 

5.2 服務器響應消息

HTTP響應也由四個部分組成，分別是：狀態行、消息報頭、空行和響應正文。

 

 

5.3 舉例

下面實例是一點典型的使用GET來傳遞數據的實例：

客戶端請求：

GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi

 

服務端響應:

HTTP/1.1200 OK
Date: Mon, 27 Jul 200912:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 200919:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain

 

輸出結果：

Hello World! My payload includes a trailing CRLF.

 

 

 六、頭域 （Header頭）

每個頭域由一個域名，冒號（:）和域值三部分組成。域名是大小寫無關的，域值前可以添加任何數量的空格符，頭域可以被擴展為多行，在每行開始處，使用至少一個空格或制表符。

 

6.1、請求信息：

發出的請求信息格式如下：

  • 請求行，例如GET /images/logo.gif HTTP/1.1，表示從/images目錄下請求logo.gif這個文件。
  • （請求）頭，例如Accept-Language: en
  • 空行
  • 可選的消息體　請求行和標題必須以<CR><LF>作為結尾（也就是，回車然后換行）。空行內必須只有<CR><LF>而無其他空格。在HTTP/1.1協議中，所有的請求頭，除post外，都是可選的。
 
 

6.2、請求方法

HTTP/1.1協議中共定義了9種方法（有時也叫“動作”）來表明Request-URI指定的資源的不同操作方式：

根據HTTP標准，HTTP請求可以使用多種請求方法。

HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。

HTTP1.1新增了6種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT，PATCH 方法。

序號 方法 描述
1 GET 向特定的資源發出請求。注意：GET方法不應當被用於產生“副作用”的操作中，即應滿足等冪性（使用相同參數調用一次或者多次，其造成的后果是一樣的），例如在web app.中。其中一個原因是GET可能會被網絡蜘蛛等隨意訪問。
2 HEAD 向服務器索要與GET請求相一致的響應，只不過響應體將不會被返回。這一方法可以在不必傳輸整個響應內容的情況下，就可以獲取包含在響應消息頭中的元信息。該方法常用於測試超鏈接的有效性，是否可以訪問，以及最近是否更新。
3 POST 向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。
4 PUT 從客戶端向服務器傳送的數據取代指定的文檔的內容。
5 DELETE 請求服務器刪除Request-URI所標識的資源
6 CONNECT HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器。
7 OPTIONS 返回服務器針對特定資源所支持的HTTP請求方法。也可以利用向Web服務器發送'*'的請求來測試服務器的功能性。
8 TRACE 回顯服務器收到的請求，主要用於測試或診斷。　　　　　　
9 PATCH 用來將局部修改應用於某一資源，添加於規范RFC5789

 

方法名稱是區分大小寫的。當某個請求所針對的資源不支持對應的請求方法的時候，服務器應當返回狀態碼405（Method Not Allowed）；當服務器不認識或者不支持對應的請求方法的時候，應當返回狀態碼501（Not Implemented）。

HTTP服務器至少應該實現GET和HEAD方法，其他方法都是可選的。此外，除了上述方法，特定的HTTP服務器還能夠擴展自定義的方法。

GET和POST的區別：

  1. GET提交的數據會放在URL之后，以?分割URL和傳輸數據，參數之間以&相連，如EditPosts.aspx?name=test1&id=123456. POST方法是把提交的數據放在HTTP包的Body中。
  2. GET提交的數據大小有限制，最多只能有1024字節（因為瀏覽器對URL的長度有限制），而POST方法提交的數據沒有限制。
  3. GET方式需要使用Request.QueryString來取得變量的值，而POST方式通過Request.Form來獲取變量的值。
  4. GET方式提交數據，會帶來安全問題，比如一個登錄頁面，通過GET方式提交數據時，用戶名和密碼將出現在URL上，如果頁面可以被緩存或者其他人可以訪問這台機器，就可以從歷史記錄獲得該用戶的賬號和密碼。

6.3、響應消息和狀態碼

客戶端向服務器發送一個請求，服務器以一個狀態行作為響應，響應的內容包括：消息協議的版本、成功或者錯誤編碼、服務器信息、實體元信息以及必要的實體內容。根據響應類別的類別，服務器響應里可以含實體內容，但不是所有的響應都有實體內容。

響應頭第一行也稱為狀態行，格式如下（下圖中紅線標出的那行）：
HTTP-Version 空格 Status-Code 空格 Reason-Phrase CRLF
HTTP-Version表示HTTP版本，例如為HTTP/1.1。Status-Code是結果代碼，用三個數字表示。Reason-Phrase是個簡單的文本描述，解釋Status-Code的具體原因。Status-Code用於機器自動識別，Reason-Phrase用於人工理解。Status-Code的第一個數字代表響應類別，可能取5個不同的值。后兩個數字沒有分類作用。Status-Code的第一個數字代表響應的類別，后續兩位描述在該類響應下發生的具體狀況，具體請參見：HTTP狀態碼 。

 

 

無論你何時瀏覽一個網頁，你都會通過一個使用HTTP協議的服務器來獲取所請求的數據。在你請求的網頁顯示在瀏覽器之前，支配網頁的網站服務器會返回一個包含有狀態碼的HTTP頭文件。這個狀態碼提供了有關所請求網頁的相關條件信息。如果一切正常，一個標准網頁會收到一條諸如200的狀態碼。當然我們的目的不是去研究200響應碼，而是去探討那些代表出現錯誤信息的服務器頭文件響應碼，例如表示“未找到指定網頁”的404碼。

HTTP狀態碼分類

HTTP狀態碼由三個十進制數字組成，第一個十進制數字定義了狀態碼的類型，后兩個數字沒有分類的作用。HTTP狀態碼共分為5種類型：

HTTP狀態碼分類
分類 分類描述
1** 信息，服務器收到請求，需要請求者繼續執行操作
2** 成功，操作被成功接收並處理
3** 重定向，需要進一步的操作以完成請求
4** 客戶端錯誤，請求包含語法錯誤或無法完成請求
5** 服務器錯誤，服務器在處理請求的過程中發生了錯誤

 

HTTP狀態碼列表:

HTTP狀態碼列表
狀態 碼   狀態碼英文名稱  中文描述
100 Continue 繼續。客戶端應繼續其請求
101 Switching Protocols 切換協議。服務器根據客戶端的請求切換協議。只能切換到更高級的協議，例如，切換到HTTP的新版本協議
 
200 OK 請求成功。一般用於GET與POST請求
201 Created 已創建。成功請求並創建了新的資源
202 Accepted 已接受。已經接受請求，但未處理完成
203 Non-Authoritative Information 非授權信息。請求成功。但返回的meta信息不在原始的服務器，而是一個副本
204 No Content 無內容。服務器成功處理，但未返回內容。在未更新網頁的情況下，可確保瀏覽器繼續顯示當前文檔
205 Reset Content 重置內容。服務器處理成功，用戶終端（例如：瀏覽器）應重置文檔視圖。可通過此返回碼清除瀏覽器的表單域
206 Partial Content 部分內容。服務器成功處理了部分GET請求
 
300 Multiple Choices 多種選擇。請求的資源可包括多個位置，相應可返回一個資源特征與地址的列表用於用戶終端（例如：瀏覽器）選擇
301 Moved Permanently 永久移動。請求的資源已被永久的移動到新URI，返回信息會包括新的URI，瀏覽器會自動定向到新URI。今后任何新的請求都應使用新的URI代替
302 Found 臨時移動。與301類似。但資源只是臨時被移動。客戶端應繼續使用原有URI
303 See Other 查看其它地址。與301類似。使用GET和POST請求查看
304 Not Modified 未修改。所請求的資源未修改，服務器返回此狀態碼時，不會返回任何資源。客戶端通常會緩存訪問過的資源，通過提供一個頭信息指出客戶端希望只返回在指定日期之后修改的資源
305 Use Proxy 使用代理。所請求的資源必須通過代理訪問
306 Unused 已經被廢棄的HTTP狀態碼
307 Temporary Redirect 臨時重定向。與302類似。使用GET請求重定向
 
400 Bad Request 客戶端請求的語法錯誤，服務器無法理解
401 Unauthorized 請求要求用戶的身份認證
402 Payment Required 保留，將來使用
403 Forbidden 服務器理解請求客戶端的請求，但是拒絕執行此請求
404 Not Found 服務器無法根據客戶端的請求找到資源（網頁）。通過此代碼，網站設計人員可設置"您所請求的資源無法找到"的個性頁面
405 Method Not Allowed 客戶端請求中的方法被禁止
406 Not Acceptable 服務器無法根據客戶端請求的內容特性完成請求
407 Proxy Authentication Required 請求要求代理的身份認證，與401類似，但請求者應當使用代理進行授權
408 Request Time-out 服務器等待客戶端發送的請求時間過長，超時
409 Conflict 服務器完成客戶端的PUT請求是可能返回此代碼，服務器處理請求時發生了沖突
410 Gone 客戶端請求的資源已經不存在。410不同於404，如果資源以前有現在被永久刪除了可使用410代碼，網站設計人員可通過301代碼指定資源的新位置
411 Length Required 服務器無法處理客戶端發送的不帶Content-Length的請求信息
412 Precondition Failed 客戶端請求信息的先決條件錯誤
413 Request Entity Too Large 由於請求的實體過大，服務器無法處理，因此拒絕請求。為防止客戶端的連續請求，服務器可能會關閉連接。如果只是服務器暫時無法處理，則會包含一個Retry-After的響應信息
414 Request-URI Too Large 請求的URI過長（URI通常為網址），服務器無法處理
415 Unsupported Media Type 服務器無法處理請求附帶的媒體格式
416 Requested range not satisfiable 客戶端請求的范圍無效
417 Expectation Failed 服務器無法滿足Expect的請求頭信息
 
500 Internal Server Error 服務器內部錯誤，無法完成請求
501 Not Implemented 服務器不支持請求的功能，無法完成請求
502 Bad Gateway 作為網關或者代理工作的服務器嘗試執行請求時，從遠程服務器接收到了一個無效的響應
503 Service Unavailable 由於超載或系統維護，服務器暫時的無法處理客戶端的請求。延時的長度可包含在服務器的Retry-After頭信息中
504 Gateway Time-out 充當網關或代理的服務器，未及時從遠端服務器獲取請求
505 HTTP Version not supported 服務器不支持請求的HTTP協議的版本，無法完成處理

 

一般來說，http code小於400的表示正常，其他則表示有問題需要處理。

 

6.4、響應頭域

服務器需要傳遞許多附加信息，這些信息不能全放在狀態行里。因此，需要另行定義響應頭域，用來描述這些附加信息。響應頭域主要描述服務器的信息和Request-URI的信息。

 
 

6.5、HTTP常見的請求頭

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

If-Modified-Since：把瀏覽器端緩存頁面的最后修改時間發送到服務器去，服務器會把這個時間與服務器上實際文件的最后修改時間進行對比。如果時間一致，那么返回304，客戶端就直接使用本地緩存文件。如果時間不一致，就會返回200和新的文件內容。客戶端接到之后，會丟棄舊文件，把新文件緩存起來，並顯示在瀏覽器中。

例如：If-Modified-Since: Thu, 09 Feb 2012 09:07:57 GMT

If-None-Match：If-None-Match和ETag一起工作，工作原理是在HTTP Response中添加ETag信息。 當用戶再次請求該資源時，將在HTTP Request中加入If-None-Match信息(ETag的值)。如果服務器驗證資源的ETag沒有改變（該資源沒有更新），將返回一個304狀態告訴客戶端使用本地緩存文件。否則將返回200狀態和新的資源和Etag.使用這樣的機制將提高網站的性能。例如: If-None-Match: "03f2b33c0bfcc1:0"。

Pragma：指定“no-cache”值表示服務器必須返回一個刷新后的文檔，即使它是代理服務器而且已經有了頁面的本地拷貝；在HTTP/1.1版本中，它和Cache-Control:no-cache作用一模一樣。Pargma只有一個用法， 例如： Pragma: no-cache
注意: 在HTTP/1.0版本中，只實現了Pragema:no-cache, 沒有實現Cache-Control

Cache-Control：指定請求和響應遵循的緩存機制。緩存指令是單向的（響應中出現的緩存指令在請求中未必會出現），且是獨立的（在請求消息或響應消息中設置Cache-Control並不會修改另一個消息處理過程中的緩存處理過程）。請求時的緩存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached，響應消息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage。

Cache-Control:Public 可以被任何緩存所緩存
Cache-Control:Private 內容只緩存到私有緩存中
Cache-Control:no-cache 所有內容都不會被緩存
Cache-Control:no-store 用於防止重要的信息被無意的發布。在請求消息中發送將使得請求和響應消息都不使用緩存。
Cache-Control:max-age 指示客戶機可以接收生存期不大於指定時間（以秒為單位）的響應。
Cache-Control:min-fresh 指示客戶機可以接收響應時間小於當前時間加上指定時間的響應。
Cache-Control:max-stale 指示客戶機可以接收超出超時期間的響應消息。如果指定max-stale消息的值，那么客戶機可以接收超出超時期指定值之內的響應消息。

Accept：瀏覽器端可以接受的MIME類型。例如：Accept: text/html 代表瀏覽器可以接受服務器回發的類型為 text/html 也就是我們常說的html文檔，如果服務器無法返回text/html類型的數據，服務器應該返回一個406錯誤(non acceptable)。通配符 * 代表任意類型，例如 Accept: / 代表瀏覽器可以處理所有類型，(一般瀏覽器發給服務器都是發這個)。

Accept-Encoding：瀏覽器申明自己可接收的編碼方法，通常指定壓縮方法，是否支持壓縮，支持什么壓縮方法（gzip，deflate）;Servlet能夠向支持gzip的瀏覽器返回經gzip編碼的HTML頁面。許多情形下這可以減少5到10倍的下載時間。例如： Accept-Encoding: gzip, deflate。如果請求消息中沒有設置這個域，服務器假定客戶端對各種內容編碼都可以接受。

Accept-Language：瀏覽器申明自己接收的語言。語言跟字符集的區別：中文是語言，中文有多種字符集，比如big5，gb2312，gbk等等；例如：Accept-Language: en-us。如果請求消息中沒有設置這個報頭域，服務器假定客戶端對各種語言都可以接受。

Accept-Charset：瀏覽器可接受的字符集。如果在請求消息中沒有設置這個域，缺省表示任何字符集都可以接受。

User-Agent：告訴HTTP服務器，客戶端使用的操作系統和瀏覽器的名稱和版本。
例如： User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; CIBA; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; InfoPath.2; .NET4.0E)。

Content-Type：例如：Content-Type: application/x-www-form-urlencoded。

Referer：包含一個URL，用戶從該URL代表的頁面出發訪問當前請求的頁面。提供了Request的上下文信息的服務器，告訴服務器我是從哪個鏈接過來的，比如從我主頁上鏈接到一個朋友那里，他的服務器就能夠從HTTP Referer中統計出每天有多少用戶點擊我主頁上的鏈接訪問他的網站。
例如: Referer:http://translate.google.cn/?hl=zh-cn&tab=wT

Connection：
例如：Connection: keep-alive 當一個網頁打開完成后，客戶端和服務器之間用於傳輸HTTP數據的TCP連接不會關閉，如果客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立的連接。HTTP 1.1默認進行持久連接。利用持久連接的優點，當頁面包含多個元素時（例如Applet，圖片），顯著地減少下載所需要的時間。要實現這一點，Servlet需要在應答中發送一個Content-Length頭，最簡單的實現方法是：先把內容寫入ByteArrayOutputStream，然后在正式寫出內容之前計算它的大小。
Connection: close 代表一個Request完成后，客戶端和服務器之間用於傳輸HTTP數據的TCP連接會關閉，當客戶端再次發送Request，需要重新建立TCP連接。

Host：（發送請求時，該頭域是必需的）主要用於指定被請求資源的Internet主機和端口號，它通常從HTTP URL中提取出來的。HTTP/1.1請求必須包含主機頭域，否則系統會以400狀態碼返回。
例如: 我們在瀏覽器中輸入：http://www.guet.edu.cn/index.html，瀏覽器發送的請求消息中，就會包含Host請求頭域：Host：http://www.guet.edu.cn，此處使用缺省端口號80，若指定了端口號，則變成：Host：指定端口號。

Cookie：最重要的請求頭之一, 將cookie的值發送給HTTP服務器。

Content-Length：表示請求消息正文的長度。例如：Content-Length: 38。

Authorization：授權信息，通常出現在對服務器發送的WWW-Authenticate頭的應答中。主要用於證明客戶端有權查看某個資源。當瀏覽器訪問一個頁面時，如果收到服務器的響應代碼為401（未授權），可以發送一個包含Authorization請求報頭域的請求，要求服務器對其進行驗證。

UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE瀏覽器所發送的非標准的請求頭，表示屏幕大小、顏色深度、操作系統和CPU類型。

From：請求發送者的email地址，由一些特殊的Web客戶程序使用，瀏覽器不會用到它。

Range：可以請求實體的一個或者多個子范圍。例如，
表示頭500個字節：bytes=0-499
表示第二個500字節：bytes=500-999
表示最后500個字節：bytes=-500
表示500字節以后的范圍：bytes=500-
第一個和最后一個字節：bytes=0-0,-1
同時指定幾個范圍：bytes=500-600,601-999
但是服務器可以忽略此請求頭，如果無條件GET包含Range請求頭，響應會以狀態碼206（PartialContent）返回而不是以200（OK）。

Upgrade：檢測 HTTP 協議及其他協議是否可使用更高的版本進行通信，參數值可用來指定不同的通信協議。

Via: 使用首部字段 Via 是為了追蹤客戶端與服務器之間的請求和響應報文的傳輸路徑。 

Accept-Charset: 首部字段可用來通知服務器用戶代理支持的字符集及 字符集的相對優先順序。另外，可一次性指定多種字符集。與首部字 段 Accept 相同的是可用權重 q 值來表示相對優先級。

Accept-Encoding: 首部字段用來告知服務器用戶代理支持的內容編碼及 內容編碼的優先級順序。可一次性指定多種內容編碼。如deflate（即zlib格式）、gzip、compress。

If-Match: 

還可以使用星號（*）指定 If-Match 的字段值。針對這種情況，服務 器將會忽略 ETag 的值，只要資源存在就處理請求。

If-Range:

Max-Forwards: 每次轉發數值減 1。當數值變 0 時返回響應. 

 

User-Agent: 用於傳達瀏覽器的種類.

Age: 首部字段 Age 能告知客戶端，源服務器在多久前創建了響應。字段值 的單位為秒。

ETag: 當資源更新時，ETag 值也需要更新。生成 ETag 值時，並沒有統一的算法規則，而僅僅是由服務器來分配。

DNT: Do Not Track 的簡 稱，意為拒絕個人信息被收集，是表示拒絕被精准廣告追蹤的一種方 法。 首部字段 DNT 可指定的字段值如下。 0 ：同意被追蹤 1 ：拒絕被追蹤

 

Upgrade: 用於檢測 HTTP 協議及其他協議是否可使用更高的 版本進行通信，其參數值可以用來指定一個完全不同的通信協議。

 

6.6、HTTP常見的響應頭

Allow：服務器支持哪些請求方法（如GET、POST等）。

Date：表示消息發送的時間，時間的描述格式由rfc822定義。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時間表示世界標准時，換算成本地時間，需要知道用戶所在的時區。你可以用setDateHeader來設置這個頭以避免轉換時間格式的麻煩

Expires：指明應該在什么時候認為文檔已經過期，從而不再緩存它，重新從服務器獲取，會更新緩存。過期之前使用本地緩存。HTTP1.1的客戶端和緩存會將非法的日期格式（包括0）看作已經過期。eg：為了讓瀏覽器不要緩存頁面，我們也可以將Expires實體報頭域，設置為0。
例如: Expires: Tue, 08 Feb 2022 11:35:14 GMT

P3P：用於跨域設置Cookie, 這樣可以解決iframe跨域訪問cookie的問題
例如: P3P: CP=CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR

Set-Cookie：非常重要的header, 用於把cookie發送到客戶端瀏覽器，每一個寫入cookie都會生成一個Set-Cookie。
例如: Set-Cookie: sc=4c31523a; path=/; domain=.acookie.taobao.com

ETag：和If-None-Match 配合使用。

Last-Modified：用於指示資源的最后修改日期和時間。Last-Modified也可用setDateHeader方法來設置。

Content-Type：WEB服務器告訴瀏覽器自己響應的對象的類型和字符集。Servlet默認為text/plain，但通常需要顯式地指定為text/html。由於經常要設置Content-Type，因此HttpServletResponse提供了一個專用的方法setContentType。可在web.xml文件中配置擴展名和MIME類型的對應關系。
例如:Content-Type: text/html;charset=utf-8
　　 Content-Type:text/html;charset=GB2312
　　 Content-Type: image/jpeg

媒體類型的格式為：大類/小類，比如text/html。
IANA(The Internet Assigned Numbers Authority，互聯網數字分配機構)定義了8個大類的媒體類型，分別是:
application— (比如: application/vnd.ms-excel.)
audio (比如: audio/mpeg.)
image (比如: image/png.)
message (比如,:message/http.)
model(比如:model/vrml.)
multipart (比如:multipart/form-data.)
text(比如:text/html.)
video(比如:video/quicktime.)

Content-Range：用於指定整個實體中的一部分的插入位置，他也指示了整個實體的長度。在服務器向客戶返回一個部分響應，它必須描述響應覆蓋的范圍和整個實體長度。一般格式：Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-length。
例如，傳送頭500個字節次字段的形式：Content-Range:bytes0-499/1234如果一個http消息包含此節（例如，對范圍請求的響 應或對一系列范圍的重疊請求），Content-Range表示傳送的范圍。

Content-Length：指明實體正文的長度，以字節方式存儲的十進制數字來表示。在數據下行的過程中，Content-Length的方式要預先在服務器中緩存所有數據，然后所有數據再一股腦兒地發給客戶端。只有當瀏覽器使用持久HTTP連接時才需要這個數據。如果你想要利用持久連接的優勢，可以把輸出文檔寫入ByteArrayOutputStram，完成后查看其大小，然后把該值放入Content-Length頭，最后通過byteArrayStream.writeTo(response.getOutputStream()發送內容。
例如: Content-Length: 19847

Content-Encoding：WEB服務器表明自己使用了什么壓縮方法（gzip，deflate）壓縮響應中的對象。只有在解碼之后才可以得到Content-Type頭指定的內容類型。利用gzip壓縮文檔能夠顯著地減少HTML文檔的下載時間。Java的GZIPOutputStream可以很方便地進行gzip壓縮，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet應該通過查看Accept-Encoding頭（即request.getHeader("Accept-Encoding")）檢查瀏覽器是否支持gzip，為支持gzip的瀏覽器返回經gzip壓縮的HTML頁面，為其他瀏覽器返回普通頁面。
例如：Content-Encoding：gzip

Content-Language：WEB服務器告訴瀏覽器自己響應的對象所用的自然語言。例如： Content-Language:da。沒有設置該域則認為實體內容將提供給所有的語言閱讀。

Server：指明HTTP服務器用來處理請求的軟件信息。例如：Server: Microsoft-IIS/7.5、Server：Apache-Coyote/1.1。此域能包含多個產品標識和注釋，產品標識一般按照重要性排序。

X-AspNet-Version：如果網站是用ASP.NET開發的，這個header用來表示ASP.NET的版本。
例如: X-AspNet-Version: 4.0.30319

X-Powered-By：表示網站是用什么技術開發的。
例如： X-Powered-By: ASP.NET

Connection：
例如：Connection: keep-alive 當一個網頁打開完成后，客戶端和服務器之間用於傳輸HTTP數據的TCP連接不會關閉，如果客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立的連接。
Connection: close 代表一個Request完成后，客戶端和服務器之間用於傳輸HTTP數據的TCP連接會關閉，當客戶端再次發送Request，需要重新建立TCP連接。

Location：用於重定向一個新的位置，包含新的URL地址。表示客戶應當到哪里去提取文檔。Location通常不是直接設置的，而是通過HttpServletResponse的sendRedirect方法，該方法同時設置狀態代碼為302。Location響應報頭域常用在更換域名的時候。

Refresh：表示瀏覽器應該在多少時間之后刷新文檔，以秒計。除了刷新當前文檔之外，你還可以通過setHeader("Refresh", "5; URL=http://host/path")讓瀏覽器讀取指定的頁面。注意這種功能通常是通過設置HTML頁面HEAD區的<META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://host/path">實現，這是因為，自動刷新或重定向對於那些不能使用CGI或Servlet的HTML編寫者十分重要。但是，對於Servlet來說，直接設置Refresh頭更加方便。注意Refresh的意義是“N秒之后刷新本頁面或訪問指定頁面”，而不是“每隔N秒刷新本頁面或訪問指定頁面”。因此，連續刷新要求每次都發送一個Refresh頭，而發送204狀態代碼則可以阻止瀏覽器繼續刷新，不管是使用Refresh頭還是<META HTTP-EQUIV="Refresh" ...>。注意Refresh頭不屬於HTTP 1.1正式規范的一部分，而是一個擴展，但Netscape和IE都支持它。

WWW-Authenticate：該響應報頭域必須被包含在401（未授權的）響應消息中，客戶端收到401響應消息時候，並發送Authorization報頭域請求服務器對其進行驗證時，服務端響應報頭就包含該報頭域。
eg：WWW-Authenticate:Basic realm="Basic Auth Test!" //可以看出服務器對請求資源采用的是基本驗證機制。

6.7 HTTP content-type 對照表

Content-Type，內容類型，一般是指網頁中存在的Content-Type，用於定義網絡文件的類型和網頁的編碼，決定瀏覽器將以什么形式、什么編碼讀取這個文件，這就是經常看到一些Asp網頁點擊的結果卻是下載到的一個文件或一張圖片的原因。

文件擴展名 Content-Type(Mime-Type) 文件擴展名 Content-Type(Mime-Type)
.*（ 二進制流，不知道下載文件類型） application/octet-stream .tif image/tiff
.001 application/x-001 .301 application/x-301
.323 text/h323 .906 application/x-906
.907 drawing/907 .a11 application/x-a11
.acp audio/x-mei-aac .ai application/postscript
.aif audio/aiff .aifc audio/aiff
.aiff audio/aiff .anv application/x-anv
.asa text/asa .asf video/x-ms-asf
.asp text/asp .asx video/x-ms-asf
.au audio/basic .avi video/avi
.awf application/vnd.adobe.workflow .biz text/xml
.bmp application/x-bmp .bot application/x-bot
.c4t application/x-c4t .c90 application/x-c90
.cal application/x-cals .cat application/vnd.ms-pki.seccat
.cdf application/x-netcdf .cdr application/x-cdr
.cel application/x-cel .cer application/x-x509-ca-cert
.cg4 application/x-g4 .cgm application/x-cgm
.cit application/x-cit .class java/*
.cml text/xml .cmp application/x-cmp
.cmx application/x-cmx .cot application/x-cot
.crl application/pkix-crl .crt application/x-x509-ca-cert
.csi application/x-csi .css text/css
.cut application/x-cut .dbf application/x-dbf
.dbm application/x-dbm .dbx application/x-dbx
.dcd text/xml .dcx application/x-dcx
.der application/x-x509-ca-cert .dgn application/x-dgn
.dib application/x-dib .dll application/x-msdownload
.doc application/msword .dot application/msword
.drw application/x-drw .dtd text/xml
.dwf Model/vnd.dwf .dwf application/x-dwf
.dwg application/x-dwg .dxb application/x-dxb
.dxf application/x-dxf .edn application/vnd.adobe.edn
.emf application/x-emf .eml message/rfc822
.ent text/xml .epi application/x-epi
.eps application/x-ps .eps application/postscript
.etd application/x-ebx .exe application/x-msdownload
.fax image/fax .fdf application/vnd.fdf
.fif application/fractals .fo text/xml
.frm application/x-frm .g4 application/x-g4
.gbr application/x-gbr . application/x-
.gif image/gif .gl2 application/x-gl2
.gp4 application/x-gp4 .hgl application/x-hgl
.hmr application/x-hmr .hpg application/x-hpgl
.hpl application/x-hpl .hqx application/mac-binhex40
.hrf application/x-hrf .hta application/hta
.htc text/x-component .htm text/html
.html text/html .htt text/webviewhtml
.htx text/html .icb application/x-icb
.ico image/x-icon .ico application/x-ico
.iff application/x-iff .ig4 application/x-g4
.igs application/x-igs .iii application/x-iphone
.img application/x-img .ins application/x-internet-signup
.isp application/x-internet-signup .IVF video/x-ivf
.java java/* .jfif image/jpeg
.jpe image/jpeg .jpe application/x-jpe
.jpeg image/jpeg .jpg image/jpeg
.jpg application/x-jpg .js application/x-javascript
.jsp text/html .la1 audio/x-liquid-file
.lar application/x-laplayer-reg .latex application/x-latex
.lavs audio/x-liquid-secure .lbm application/x-lbm
.lmsff audio/x-la-lms .ls application/x-javascript
.ltr application/x-ltr .m1v video/x-mpeg
.m2v video/x-mpeg .m3u audio/mpegurl
.m4e video/mpeg4 .mac application/x-mac
.man application/x-troff-man .math text/xml
.mdb application/msaccess .mdb application/x-mdb
.mfp application/x-shockwave-flash .mht message/rfc822
.mhtml message/rfc822 .mi application/x-mi
.mid audio/mid .midi audio/mid
.mil application/x-mil .mml text/xml
.mnd audio/x-musicnet-download .mns audio/x-musicnet-stream
.mocha application/x-javascript .movie video/x-sgi-movie
.mp1 audio/mp1 .mp2 audio/mp2
.mp2v video/mpeg .mp3 audio/mp3
.mp4 video/mpeg4 .mpa video/x-mpg
.mpd application/vnd.ms-project .mpe video/x-mpeg
.mpeg video/mpg .mpg video/mpg
.mpga audio/rn-mpeg .mpp application/vnd.ms-project
.mps video/x-mpeg .mpt application/vnd.ms-project
.mpv video/mpg .mpv2 video/mpeg
.mpw application/vnd.ms-project .mpx application/vnd.ms-project
.mtx text/xml .mxp application/x-mmxp
.net image/pnetvue .nrf application/x-nrf
.nws message/rfc822 .odc text/x-ms-odc
.out application/x-out .p10 application/pkcs10
.p12 application/x-pkcs12 .p7b application/x-pkcs7-certificates
.p7c application/pkcs7-mime .p7m application/pkcs7-mime
.p7r application/x-pkcs7-certreqresp .p7s application/pkcs7-signature
.pc5 application/x-pc5 .pci application/x-pci
.pcl application/x-pcl .pcx application/x-pcx
.pdf application/pdf .pdf application/pdf
.pdx application/vnd.adobe.pdx .pfx application/x-pkcs12
.pgl application/x-pgl .pic application/x-pic
.pko application/vnd.ms-pki.pko .pl application/x-perl
.plg text/html .pls audio/scpls
.plt application/x-plt .png image/png
.png application/x-png .pot application/vnd.ms-powerpoint
.ppa application/vnd.ms-powerpoint .ppm application/x-ppm
.pps application/vnd.ms-powerpoint .ppt application/vnd.ms-powerpoint
.ppt application/x-ppt .pr application/x-pr
.prf application/pics-rules .prn application/x-prn
.prt application/x-prt .ps application/x-ps
.ps application/postscript .ptn application/x-ptn
.pwz application/vnd.ms-powerpoint .r3t text/vnd.rn-realtext3d
.ra audio/vnd.rn-realaudio .ram audio/x-pn-realaudio
.ras application/x-ras .rat application/rat-file
.rdf text/xml .rec application/vnd.rn-recording
.red application/x-red .rgb application/x-rgb
.rjs application/vnd.rn-realsystem-rjs .rjt application/vnd.rn-realsystem-rjt
.rlc application/x-rlc .rle application/x-rle
.rm application/vnd.rn-realmedia .rmf application/vnd.adobe.rmf
.rmi audio/mid .rmj application/vnd.rn-realsystem-rmj
.rmm audio/x-pn-realaudio .rmp application/vnd.rn-rn_music_package
.rms application/vnd.rn-realmedia-secure .rmvb application/vnd.rn-realmedia-vbr
.rmx application/vnd.rn-realsystem-rmx .rnx application/vnd.rn-realplayer
.rp image/vnd.rn-realpix .rpm audio/x-pn-realaudio-plugin
.rsml application/vnd.rn-rsml .rt text/vnd.rn-realtext
.rtf application/msword .rtf application/x-rtf
.rv video/vnd.rn-realvideo .sam application/x-sam
.sat application/x-sat .sdp application/sdp
.sdw application/x-sdw .sit application/x-stuffit
.slb application/x-slb .sld application/x-sld
.slk drawing/x-slk .smi application/smil
.smil application/smil .smk application/x-smk
.snd audio/basic .sol text/plain
.sor text/plain .spc application/x-pkcs7-certificates
.spl application/futuresplash .spp text/xml
.ssm application/streamingmedia .sst application/vnd.ms-pki.certstore
.stl application/vnd.ms-pki.stl .stm text/html
.sty application/x-sty .svg text/xml
.swf application/x-shockwave-flash .tdf application/x-tdf
.tg4 application/x-tg4 .tga application/x-tga
.tif image/tiff .tif application/x-tif
.tiff image/tiff .tld text/xml
.top drawing/x-top .torrent application/x-bittorrent
.tsd text/xml .txt text/plain
.uin application/x-icq .uls text/iuls
.vcf text/x-vcard .vda application/x-vda
.vdx application/vnd.visio .vml text/xml
.vpg application/x-vpeg005 .vsd application/vnd.visio
.vsd application/x-vsd .vss application/vnd.visio
.vst application/vnd.visio .vst application/x-vst
.vsw application/vnd.visio .vsx application/vnd.visio
.vtx application/vnd.visio .vxml text/xml
.wav audio/wav .wax audio/x-ms-wax
.wb1 application/x-wb1 .wb2 application/x-wb2
.wb3 application/x-wb3 .wbmp image/vnd.wap.wbmp
.wiz application/msword .wk3 application/x-wk3
.wk4 application/x-wk4 .wkq application/x-wkq
.wks application/x-wks .wm video/x-ms-wm
.wma audio/x-ms-wma .wmd application/x-ms-wmd
.wmf application/x-wmf .wml text/vnd.wap.wml
.wmv video/x-ms-wmv .wmx video/x-ms-wmx
.wmz application/x-ms-wmz .wp6 application/x-wp6
.wpd application/x-wpd .wpg application/x-wpg
.wpl application/vnd.ms-wpl .wq1 application/x-wq1
.wr1 application/x-wr1 .wri application/x-wri
.wrk application/x-wrk .ws application/x-ws
.ws2 application/x-ws .wsc text/scriptlet
.wsdl text/xml .wvx video/x-ms-wvx
.xdp application/vnd.adobe.xdp .xdr text/xml
.xfd application/vnd.adobe.xfd .xfdf application/vnd.adobe.xfdf
.xhtml text/html .xls application/vnd.ms-excel
.xls application/x-xls .xlw application/x-xlw
.xml text/xml .xpl audio/scpls
.xq text/xml .xql text/xml
.xquery text/xml .xsd text/xml
.xsl text/xml .xslt text/xml
.xwd application/x-xwd .x_b application/x-x_b
.sis application/vnd.symbian.install .sisx application/vnd.symbian.install
.x_t application/x-x_t .ipa application/vnd.iphone
.apk application/vnd.android.package-archive .xap application/x-silverlight-app

七、解決HTTP無狀態的問題

7.1、通過Cookies保存狀態信息

通過Cookies，服務器就可以清楚的知道多個請求來自同一個客戶端。

 
7.2、通過Session保存狀態信息

Session機制是一種服務器端的機制，服務器使用一種類似於散列表的結構（也可能就是使用散列表）來保存信息。
當程序需要為某個客戶端的請求創建一個session的時候，服務器首先檢查這個客戶端的請求里是否已包含了一個session標識 - 稱為 session id，如果已包含一個session id則說明以前已經為此客戶端創建過session，服務器就按照session id把這個 session檢索出來使用（如果檢索不到，可能會新建一個），如果客戶端請求不包含session id，則為此客戶端創建一個session並且生成一個與此session相關聯的session id，session id的值應該是一個既不會重復，又不容易被找到規律以仿造的字符串，這個session id將被在本次響應中返回給客戶端保存。

Session的實現方式：
1、使用Cookie來實現:

服務器給每個Session分配一個唯一的JSESSIONID，並通過Cookie發送給客戶端。
當客戶端發起新的請求的時候，將在Cookie頭中攜帶這個JSESSIONID。這樣服務器能夠找到這個客戶端對應的Session。

 

 
122202523952651.png

2、使用URL回寫來實現
URL回寫是指服務器在發送給瀏覽器頁面的所有鏈接中都攜帶JSESSIONID的參數，這樣客戶端點擊任何一個鏈接都會把JSESSIONID帶會服務器。如果直接在瀏覽器輸入服務端資源的url來請求該資源，那么Session是匹配不到的。
Tomcat對Session的實現，是一開始同時使用Cookie和URL回寫機制，如果發現客戶端支持Cookie，就繼續使用Cookie，停止使用URL回寫。如果發現Cookie被禁用，就一直使用URL回寫。jsp開發處理到Session的時候，對頁面中的鏈接記得使用response.encodeURL() 。

Cookie和Session有以下明顯的不同點：

  1. Cookie將狀態保存在客戶端，Session將狀態保存在服務器端；
  1. Cookies是服務器在本地機器上存儲的小段文本並隨每一個請求發送至同一個服務器。Cookie最早在RFC2109中實現，后續RFC2965做了增強。網絡服務器用HTTP頭向客戶端發送cookies，在客戶終端，瀏覽器解析這些cookies並將它們保存為一個本地文件，它會自動將同一服務器的任何請求縛上這些cookies。Session並沒有在HTTP的協議中定義；
  2. Session是針對每一個用戶的，變量的值保存在服務器上，用一個sessionID來區分是哪個用戶session變量,這個值是通過用戶的瀏覽器在訪問的時候返回給服務器，當客戶禁用cookie時，這個值也可能設置為由get來返回給服務器；
  3. 就安全性來說：當你訪問一個使用session 的站點，同時在自己機子上建立一個cookie，建議在服務器端的SESSION機制更安全些。因為它不會任意讀取客戶存儲的信息。

7.3、通過表單變量保持狀態

除了Cookies之外，還可以使用表單變量來保持狀態，比如Asp.net就通過一個叫ViewState的Input=“hidden”的框來保持狀態,比如:

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUKMjA0OTM4MTAwNGRkXUfhlDv1Cs7/qhBlyZROCzlvf5U=" />

這個原理和Cookies大同小異，只是每次請求和響應所附帶的信息變成了表單變量。

7.4、通過QueryString保持狀態

QueryString通過將信息保存在所請求地址的末尾來向服務器傳送信息，通常和表單結合使用，一個典型的QueryString比如:www.xxx.com/xxx.aspx?var1=value&var2=value2

 

八、使用telnet進行http測試

在Windows下，可使用命令窗口進行http簡單測試。輸入cmd進入命令窗口，在命令行鍵入如下命令后按回車：
telnet www.baidu.com 80
而后在窗口中按下"Ctrl+]"后按回車可讓返回結果回顯。
接着開始發請求消息，例如發送如下請求消息請求baidu的首頁消息，使用的HTTP協議為HTTP/1.1：
GET /index.html HTTP/1.1
注意：copy如上的消息到命令窗口后需要按兩個回車換行才能得到響應的消息，第一個回車換行是在命令后鍵入回車換行，是HTTP協議要求的。第二個是確認輸入，發送請求。

 
 

可看到，當采用HTTP/1.1時，連接不是在請求結束后就斷開的。若采用HTTP1.0，在命令窗口鍵入：
GET /index.html HTTP/1.0
此時可以看到請求結束之后馬上斷開。
讀者還可以嘗試在使用GET或POST等時，帶上頭域信息，例如鍵入如下信息：
GET /index.html HTTP/1.1
connection: close
Host: www.baidu.com

九、URL詳解

URL(Uniform Resource Locator) 地址用於描述一個網絡上的資源， 基本格式如下
schema://host[:port#]/path/.../[;url-params][?query-string][#anchor]
　　scheme 指定低層使用的協議(例如：http, https, ftp)
　　host HTTP服務器的IP地址或者域名
　　port# HTTP服務器的默認端口是80，這種情況下端口號可以省略。如果使用了別的端口，必須指明，例如 http://www.cnblogs.com:8080/
　　path 訪問資源的路徑
　　url-params
　　query-string 發送給http服務器的數據
　　anchor- 錨

URL 的一個例子：

http://www.mywebsite.com/sj/test;id=8079?name=sviergn&x=true#stuff

Schema: http
host: www.mywebsite.com
path: /sj/test
URL params: id=8079
Query String: name=sviergn&x=true
Anchor: stuff

十、緩存的實現原理

WEB緩存(cache)位於Web服務器和客戶端之間。
緩存會根據請求保存輸出內容的副本，例如html頁面，圖片，文件，當下一個請求來到的時候：如果是相同的URL，緩存直接使用副本響應訪問請求，而不是向源服務器再次發送請求。
HTTP協議定義了相關的消息頭來使WEB緩存盡可能好的工作。

10.1、緩存的優點

減少相應延遲：因為請求從緩存服務器（離客戶端更近）而不是源服務器被相應，這個過程耗時更少，讓web服務器看上去相應更快。
減少網絡帶寬消耗：當副本被重用時會減低客戶端的帶寬消耗；客戶可以節省帶寬費用，控制帶寬的需求的增長並更易於管理。

10.2、客戶端緩存生效的常見流程

服務器收到請求時，會在200OK中回送該資源的Last-Modified和ETag頭，客戶端將該資源保存在cache中，並記錄這兩個屬性。當客戶端需要發送相同的請求時，會在請求中攜帶If-Modified-Since和If-None-Match兩個頭。兩個頭的值分別是響應中Last-Modified和ETag頭的值。服務器通過這兩個頭判斷本地資源未發生變化，客戶端不需要重新下載，返回304響應。

10.3、Web緩存機制

HTTP/1.1中緩存的目的是為了在很多情況下減少發送請求，同時在許多情況下可以不需要發送完整響應。前者減少了網絡回路的數量；HTTP利用一個“過期（expiration）”機制來為此目的。后者減少了網絡應用的帶寬；HTTP用“驗證（validation）”機制來為此目的。
HTTP定義了3種緩存機制：

  1. Freshness：允許一個回應消息可以在源服務器不被重新檢查，並且可以由服務器和客戶端來控制。例如，Expires回應頭給了一個文檔不可用的時間。Cache-Control中的max-age標識指明了緩存的最長時間；
  2. Validation：用來檢查以一個緩存的回應是否仍然可用。例如，如果一個回應有一個Last-Modified回應頭，緩存能夠使用If-Modified-Since來判斷是否已改變，以便判斷根據情況發送請求；
  3. Invalidation：在另一個請求通過緩存的時候，常常有一個副作用。例如，如果一個URL關聯到一個緩存回應，但是其后跟着POST、PUT和DELETE的請求的話，緩存就會過期。

十一、HTTP應用

11.1、斷點續傳的實現原理

HTTP協議的GET方法，支持只請求某個資源的某一部分；
206 Partial Content 部分內容響應；
Range 請求的資源范圍；
Content-Range 響應的資源范圍；
在連接斷開重連時，客戶端只請求該資源未下載的部分，而不是重新請求整個資源，來實現斷點續傳。
分塊請求資源實例：
Eg1：Range: bytes=306302- ：請求這個資源從306302個字節到末尾的部分；
Eg2：Content-Range: bytes 306302-604047/604048：響應中指示攜帶的是該資源的第306302-604047的字節，該資源共604048個字節；
客戶端通過並發的請求相同資源的不同片段，來實現對某個資源的並發分塊下載。從而達到快速下載的目的。目前流行的FlashGet和迅雷基本都是這個原理。

11.2、多線程下載的原理

下載工具開啟多個發出HTTP請求的線程；
每個http請求只請求資源文件的一部分：Content-Range: bytes 20000-40000/47000；
合並每個線程下載的文件。

11.3、http代理

http代理服務器

代理服務器英文全稱是Proxy Server，其功能就是代理網絡用戶去取得網絡信息。形象的說：它是網絡信息的中轉站。
代理服務器是介於瀏覽器和Web服務器之間的一台服務器，有了它之后，瀏覽器不是直接到Web服務器去取回網頁而是向代理服務器發出請求，Request信號會先送到代理服務器，由代理服務器來取回瀏覽器所需要的信息並傳送給你的瀏覽器。
而且，大部分代理服務器都具有緩沖的功能，就好象一個大的Cache，它有很大的存儲空間，它不斷將新取得數據儲存到它本機的存儲器上，如果瀏覽器所請求的數據在它本機的存儲器上已經存在而且是最新的，那么它就不重新從Web服務器取數據，而直接將存儲器上的數據傳送給用戶的瀏覽器，這樣就能顯著提高瀏覽速度和效率。更重要的是：Proxy Server(代理服務器)是Internet鏈路級網關所提供的一種重要的安全功能，它的工作主要在開放系統互聯(OSI)模型的對話層。

http代理服務器的主要功能：

  1. 突破自身IP訪問限制，訪問國外站點。如：教育網、169網等網絡用戶可以通過代理訪問國外網站；
  2. 訪問一些單位或團體內部資源，如某大學FTP(前提是該代理地址在該資源的允許訪問范圍之內)，使用教育網內地址段免費代理服務器，就可以用於對教育 網開放的各類FTP下載上傳，以及各類資料查詢共享等服務；
  3. 突破中國電信的IP封鎖：中國電信用戶有很多網站是被限制訪問的，這種限制是人為的，不同Serve對地址的封鎖是不同的。所以不能訪問時可以換一個國外的代理服務器試試；
  4. 提高訪問速度：通常代理服務器都設置一個較大的硬盤緩沖區，當有外界的信息通過時，同時也將其保存到緩沖區中，當其他用戶再訪問相同的信息時，則直接由緩沖區中取出信息，傳給用戶，以提高訪問速度；
  5. 隱藏真實IP：上網者也可以通過這種方法隱藏自己的IP，免受攻擊。

對於客戶端瀏覽器而言，http代理服務器相當於服務器。
而對於Web服務器而言，http代理服務器又擔當了客戶端的角色。

11.4、虛擬主機

虛擬主機：是在網絡服務器上划分出一定的磁盤空間供用戶放置站點、應用組件等，提供必要的站點功能與數據存放、傳輸功能。
所謂虛擬主機，也叫“網站空間”就是把一台運行在互聯網上的服務器划分成多個“虛擬”的服務器，每一個虛擬主機都具有獨立的域名和完整的Internet服務器（支持WWW、FTP、E-mail等）功能。一台服務器上的不同虛擬主機是各自獨立的，並由用戶自行管理。但一台服務器主機只能夠支持一定數量的虛擬主機，當超過這個數量時，用戶將會感到性能急劇下降。

虛擬主機的實現原理:

虛擬主機是用同一個WEB服務器，為不同域名網站提供服務的技術。Apache、Tomcat等均可通過配置實現這個功能。
相關的HTTP消息頭：Host。
例如：Host: www.baidu.com
客戶端發送HTTP請求的時候，會攜帶Host頭，Host頭記錄的是客戶端輸入的域名。這樣服務器可以根據Host頭確認客戶要訪問的是哪一個域名。

十二、HTTP的缺點

  • 通信使用明文，內容可被竊聽
  • 不驗證通信方的身份
    • 任何人可以發起請求，所有人接收響應
    • 無法判定請求是來自哪里

  • 無法證明報文的完整性

 　　如上圖中間人攻擊。

十三、HTTPS傳輸協議原理

HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容請看SSL。

HTTP+ 加密 + 認證 + 完整性保護=HTTPS。

13.1、兩種基本的加解密算法類型

對稱加密：密鑰只有一個，加密解密為同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES等。
非對稱加密：密鑰成對出現（且根據公鑰無法推知私鑰，根據私鑰也無法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。

13.2、HTTPS通信過程

 
 

13.3、HTTPS通信的優缺點

客戶端產生的密鑰只有客戶端和服務器端能得到；
加密的數據只有客戶端和服務器端才能得到明文；
客戶端到服務端的通信是安全的。

但是HTTPS速度較HTTP慢：

  1. 通信慢
  2. 占用大量CPU資源，導致處理速度變慢

十四、Websocket

Web 瀏覽器與 Web 服務器之間全雙工通信標准

不論服務器還是客戶端，任意一方都可直接向對方發送報文

在HTTP協議基礎上進行握手


 
 
  • 推送功能：服務器可直接發送數據，不必等待請求。
  • 減少通信量：建立起 WebSocket 連接，一直保持連接狀態

十五、Web攻擊

對 Web 應用的攻擊模式有主動攻擊和被動攻擊。

15.1 主動攻擊

通過直接訪問Web傳入攻擊代碼，直接針對服務器上的資源進行攻擊從而訪問資源。

  • SQL注入攻擊

針對 Web 應用使用的數據庫，通過運行非法的 SQL而產生的攻擊

  • OS命令攻擊
    通過 Web 應用，執行非法的操作系統命令達到攻擊的目的

15.2 被動攻擊

利用圈套策略執行攻擊代碼的攻擊模式，不直接對web訪問進行攻擊

  • XSS跨站腳本攻擊
  • CSRF跨站點請求偽造
  • HTTP 首部注入攻擊

 


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 互聯網基礎協議 - HTTP 什么是互聯網？互聯網如何運作？ 互聯網和互聯網的組成 互聯網年鑒 互聯網從此沒有 BAT 工業互聯網 在互聯網隨波逐流（一） 互聯網的組成 虛擬互聯網 互聯網支付系統整體架構詳解（轉）
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM