圖文詳解互聯網根基之HTTP
這是本人對《圖解HTTP》和《HTTP權威指南》閱讀後總結的你們經常使用的、重要的知識點，前端、後端同窗居家必備！javascript
1、概述
HTTP是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫。css
HTTP是一個應用層協議，由請求和響應構成，是一個標準的客戶端服務器模型。HTTP是一個無狀態的協議。html
在Internet中全部的傳輸都是經過TCP/IP進行的。HTTP協議做爲TCP/IP模型中應用層的協議也不例外。HTTP協議一般承載於TCP協議之上，有時也承載於TLS或SSL協議層之上，這個時候，就成了咱們常說的HTTPS。以下圖所示：前端
HTTP默認的端口號爲80，HTTPS的端口號爲443。 vue
瀏覽網頁是HTTP的主要應用，可是這並不表明HTTP就只能應用於網頁的瀏覽。HTTP是一種協議，只要通訊的雙方都遵照這個協議，HTTP就能有用武之地。好比我們經常使用的微信、QQ這些軟件，都會使用HTTP協議(還包括其餘的協議)。即將到來的HTTP2和HTTP3也是基於或兼容HTTP協議的。 java
它的發展是萬維網協會（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來說解。android
2、網絡基礎TCP/IP
2.1 TCP/IP
爲了理解 HTTP，咱們有必要事先了解一下 TCP/IP 協議族。 一般使用的網絡（包括互聯網）是在 TCP/IP 協議族的基礎上運做 的。而 HTTP 屬於它內部的一個子集。 接下來，咱們僅介紹理解 HTTP 所需掌握的 TCP/IP 協議族的概要。 若想進一步學習有關 TCP/IP 的知識，請參考其餘講解 TCP/IP 的專業書籍。程序員
TCP/IP 是互聯網相關的各種協議族的總稱。web
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 和 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 個用於嵌入的圖片。若是每一個事務都須要（串行地建 立）一條新的鏈接，那麼鏈接時延和慢啓動時延就會疊加起來。
解決方案有：
- 並行鏈接 經過多條 TCP 鏈接發起併發的 HTTP 請求。
- 持久鏈接 重用 TCP 鏈接，以消除鏈接及關閉時延。
- 管道化鏈接 經過共享的 TCP 鏈接發起併發的 HTTP 請求。
3、HTTP連接
3.1 連接特性
HTTP協議永遠都是客戶端發起請求，服務器回送響應。這樣就限制了使用HTTP協議，沒法實如今客戶端沒有發起請求的時候，服務器將消息推送給客戶端。
HTTP協議的主要特色可歸納以下：
- 支持客戶/服務器模式。支持基本認證和安全認證。
- 簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。
- 靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
- 高效：HTTP 0.9和1.0使用非持續鏈接：限制每次鏈接只處理一個請求，服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。HTTP 1.1使用持續鏈接：沒必要爲每一個web對象建立一個新的鏈接，一個鏈接能夠傳送多個對象，採用這種方式能夠節省傳輸時間。
- 無狀態：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、工做流程
4.1 HTTP工做流
一次HTTP操做稱爲一個事務，其工做過程可分爲四步：
- 首先客戶機與服務器須要創建鏈接。只要單擊某個超級連接，HTTP的工做開始。
- 創建鏈接後，客戶機發送一個請求給服務器，請求方式的格式爲：統一資源標識符（URL）、協議版本號，後邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。
- 服務器接到請求後，給予相應的響應信息，其格式爲一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，後邊是MIME信息包括服務器信息、實體信息和可能的內容。
- 客戶端接收服務器所返回的信息經過瀏覽器顯示在用戶的顯示屏上，而後客戶機與服務器斷開鏈接。
- 若是在以上過程當中的某一步出現錯誤，那麼產生錯誤的信息將返回到客戶端，有顯示屏輸出。對於用戶來講，這些過程是由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 值後發送出去。
5、HTTP消息體結構
5.1 客戶端請求消息
三個部分分別是：狀態行、消息報頭、響應正文(報文主體), 一般, 不必定要有報文主體。
客戶端發送一個HTTP請求到服務器的請求消息包括如下格式：請求行（request line）、請求頭部（header）、空行（即回車+換行，又叫CR+LF）、請求數據四個部分組成，下圖給出了請求報文的通常格式。
例如：
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.
6、頭域 （Header頭）
每一個頭域由一個域名，冒號（:）和域值三部分組成。域名是大小寫無關的，域值前能夠添加任何數量的空格符，頭域能夠被擴展爲多行，在每行開始處，使用至少一個空格或製表符。
6.一、請求信息：
發出的請求信息格式以下：
- 請求行，例如GET /images/logo.gif HTTP/1.1，表示從/images目錄下請求logo.gif這個文件。
- （請求）頭，例如Accept-Language: en
- 空行
- 可選的消息體 請求行和標題必須以<CR><LF>做爲結尾（也就是，回車而後換行）。空行內必須只有<CR><LF>而無其餘空格。在HTTP/1.1協議中，全部的請求頭，除post外，都是可選的。
6.二、請求方法
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的區別：
- GET提交的數據會放在URL以後，以?分割URL和傳輸數據，參數之間以&相連，如EditPosts.aspx?name=test1&id=123456. POST方法是把提交的數據放在HTTP包的Body中。
- GET提交的數據大小有限制，最多隻能有1024字節（由於瀏覽器對URL的長度有限制），而POST方法提交的數據沒有限制。
- GET方式須要使用Request.QueryString來取得變量的值，而POST方式經過Request.Form來獲取變量的值。
- GET方式提交數據，會帶來安全問題，好比一個登陸頁面，經過GET方式提交數據時，用戶名和密碼將出如今URL上，若是頁面能夠被緩存或者其餘人能夠訪問這臺機器，就能夠從歷史記錄得到該用戶的帳號和密碼。
6.三、響應消息和狀態碼
客戶端向服務器發送一個請求，服務器以一個狀態行做爲響應，響應的內容包括：消息協議的版本、成功或者錯誤編碼、服務器信息、實體元信息以及必要的實體內容。根據響應類別的類別，服務器響應裏能夠含實體內容，但不是全部的響應都有實體內容。
響應頭第一行也稱爲狀態行，格式以下（下圖中紅線標出的那行）：HTTP-Version 空格 Status-Code 空格 Reason-Phrase CRLFHTTP-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種類型：
| 分類 | 分類描述 |
|---|---|
| 1** | 信息，服務器收到請求，須要請求者繼續執行操做 |
| 2** | 成功，操做被成功接收並處理 |
| 3** | 重定向，須要進一步的操做以完成請求 |
| 4** | 客戶端錯誤，請求包含語法錯誤或沒法完成請求 |
| 5** | 服務器錯誤，服務器在處理請求的過程當中發生了錯誤 |
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.四、響應頭域
服務器須要傳遞許多附加信息，這些信息不能全放在狀態行裏。所以，須要另行定義響應頭域，用來描述這些附加信息。響應頭域主要描述服務器的信息和Request-URI的信息。
6.五、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 協議及其餘協議是否可以使用更高的版本進行通訊，參數值可用來指定不一樣的通訊協議。
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.六、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 四、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.五、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 |
| application/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 |
7、解決HTTP無狀態的問題
7.一、經過Cookies保存狀態信息
經過Cookies，服務器就能夠清楚的知道多個請求來自同一個客戶端。
Session機制是一種服務器端的機制，服務器使用一種相似於散列表的結構（也可能就是使用散列表）來保存信息。
當程序須要爲某個客戶端的請求建立一個session的時候，服務器首先檢查這個客戶端的請求裏是否已包含了一個session標識 - 稱爲 session id，若是已包含一個session id則說明之前已經爲此客戶端建立過session，服務器就按照session id把這個 session檢索出來使用（若是檢索不到，可能會新建一個），若是客戶端請求不包含session id，則爲此客戶端建立一個session而且生成一個與此session相關聯的session id，session id的值應該是一個既不會重複，又不容易被找到規律以仿造的字符串，這個session id將被在本次響應中返回給客戶端保存。
Session的實現方式：
一、使用Cookie來實現:
服務器給每一個Session分配一個惟一的JSESSIONID，並經過Cookie發送給客戶端。
當客戶端發起新的請求的時候，將在Cookie頭中攜帶這個JSESSIONID。這樣服務器可以找到這個客戶端對應的Session。
二、使用URL回寫來實現URL回寫是指服務器在發送給瀏覽器頁面的全部連接中都攜帶JSESSIONID的參數，這樣客戶端點擊任何一個連接都會把JSESSIONID帶會服務器。若是直接在瀏覽器輸入服務端資源的url來請求該資源，那麼Session是匹配不到的。Tomcat對Session的實現，是一開始同時使用Cookie和URL回寫機制，若是發現客戶端支持Cookie，就繼續使用Cookie，中止使用URL回寫。若是發現Cookie被禁用，就一直使用URL回寫。jsp開發處理到Session的時候，對頁面中的連接記得使用response.encodeURL() 。
Cookie和Session有如下明顯的不一樣點：
- Cookie將狀態保存在客戶端，Session將狀態保存在服務器端；
- Cookies是服務器在本地機器上存儲的小段文本並隨每個請求發送至同一個服務器。Cookie最先在RFC2109中實現，後續RFC2965作了加強。網絡服務器用HTTP頭向客戶端發送cookies，在客戶終端，瀏覽器解析這些cookies並將它們保存爲一個本地文件，它會自動將同一服務器的任何請求縛上這些cookies。Session並無在HTTP的協議中定義；
- Session是針對每個用戶的，變量的值保存在服務器上，用一個sessionID來區分是哪一個用戶session變量,這個值是經過用戶的瀏覽器在訪問的時候返回給服務器，當客戶禁用cookie時，這個值也可能設置爲由get來返回給服務器；
- 就安全性來講：當你訪問一個使用session 的站點，同時在本身機子上創建一個cookie，建議在服務器端的SESSION機制更安全些。由於它不會任意讀取客戶存儲的信息。
7.三、經過表單變量保持狀態
除了Cookies以外，還能夠使用表單變量來保持狀態，好比Asp.net就經過一個叫ViewState的Input=「hidden」的框來保持狀態,好比:
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUKMjA0OTM4MTAwNGRkXUfhlDv1Cs7/qhBlyZROCzlvf5U=" />
這個原理和Cookies大同小異，只是每次請求和響應所附帶的信息變成了表單變量。
7.四、經過QueryString保持狀態
QueryString經過將信息保存在所請求地址的末尾來向服務器傳送信息，一般和表單結合使用，一個典型的QueryString好比:www.xxx.com/xxx.aspx?var1=value&var2=value2
8、使用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
9、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
10、緩存的實現原理
WEB緩存(cache)位於Web服務器和客戶端之間。
緩存會根據請求保存輸出內容的副本，例如html頁面，圖片，文件，當下一個請求來到的時候：若是是相同的URL，緩存直接使用副本響應訪問請求，而不是向源服務器再次發送請求。
HTTP協議定義了相關的消息頭來使WEB緩存儘量好的工做。
10.一、緩存的優勢
減小相應延遲：由於請求從緩存服務器（離客戶端更近）而不是源服務器被相應，這個過程耗時更少，讓web服務器看上去相應更快。
減小網絡帶寬消耗：當副本被重用時會減低客戶端的帶寬消耗；客戶能夠節省帶寬費用，控制帶寬的需求的增加並更易於管理。
10.二、客戶端緩存生效的常見流程
服務器收到請求時，會在200OK中回送該資源的Last-Modified和ETag頭，客戶端將該資源保存在cache中，並記錄這兩個屬性。當客戶端須要發送相同的請求時，會在請求中攜帶If-Modified-Since和If-None-Match兩個頭。兩個頭的值分別是響應中Last-Modified和ETag頭的值。服務器經過這兩個頭判斷本地資源未發生變化，客戶端不須要從新下載，返回304響應。
10.三、Web緩存機制
HTTP/1.1中緩存的目的是爲了在不少狀況下減小發送請求，同時在許多狀況下能夠不須要發送完整響應。前者減小了網絡迴路的數量；HTTP利用一個「過時（expiration）」機制來爲此目的。後者減小了網絡應用的帶寬；HTTP用「驗證（validation）」機制來爲此目的。
HTTP定義了3種緩存機制：
- Freshness：容許一個迴應消息能夠在源服務器不被從新檢查，而且能夠由服務器和客戶端來控制。例如，Expires迴應頭給了一個文檔不可用的時間。Cache-Control中的max-age標識指明瞭緩存的最長時間；
- Validation：用來檢查以一個緩存的迴應是否仍然可用。例如，若是一個迴應有一個Last-Modified迴應頭，緩存可以使用If-Modified-Since來判斷是否已改變，以便判斷根據狀況發送請求；
- Invalidation：在另外一個請求經過緩存的時候，經常有一個反作用。例如，若是一個URL關聯到一個緩存迴應，可是其後跟着POST、PUT和DELETE的請求的話，緩存就會過時。
11、HTTP應用
11.一、斷點續傳的實現原理
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.二、多線程下載的原理
下載工具開啓多個發出HTTP請求的線程；
每一個http請求只請求資源文件的一部分：Content-Range: bytes 20000-40000/47000；
合併每一個線程下載的文件。
11.三、http代理
http代理服務器
代理服務器英文全稱是Proxy Server，其功能就是代理網絡用戶去取得網絡信息。形象的說：它是網絡信息的中轉站。
代理服務器是介於瀏覽器和Web服務器之間的一臺服務器，有了它以後，瀏覽器不是直接到Web服務器去取回網頁而是向代理服務器發出請求，Request信號會先送到代理服務器，由代理服務器來取回瀏覽器所須要的信息並傳送給你的瀏覽器。
並且，大部分代理服務器都具備緩衝的功能，就好象一個大的Cache，它有很大的存儲空間，它不斷將新取得數據儲存到它本機的存儲器上，若是瀏覽器所請求的數據在它本機的存儲器上已經存在並且是最新的，那麼它就不從新從Web服務器取數據，而直接將存儲器上的數據傳送給用戶的瀏覽器，這樣就能顯著提升瀏覽速度和效率。更重要的是：Proxy Server(代理服務器)是Internet鏈路級網關所提供的一種重要的安全功能，它的工做主要在開放系統互聯(OSI)模型的對話層。
http代理服務器的主要功能：
- 突破自身IP訪問限制，訪問國外站點。如：教育網、169網等網絡用戶能夠經過代理訪問國外網站；
- 訪問一些單位或團體內部資源，如某大學FTP(前提是該代理地址在該資源的容許訪問範圍以內)，使用教育網內地址段免費代理服務器，就能夠用於對教育 網開放的各種FTP下載上傳，以及各種資料查詢共享等服務；
- 突破中國電信的IP封鎖：中國電信用戶有不少網站是被限制訪問的，這種限制是人爲的，不一樣Serve對地址的封鎖是不一樣的。因此不能訪問時能夠換一個國外的代理服務器試試；
- 提升訪問速度：一般代理服務器都設置一個較大的硬盤緩衝區，當有外界的信息經過時，同時也將其保存到緩衝區中，當其餘用戶再訪問相同的信息時，則直接由緩衝區中取出信息，傳給用戶，以提升訪問速度；
- 隱藏真實IP：上網者也能夠經過這種方法隱藏本身的IP，免受攻擊。
對於客戶端瀏覽器而言，http代理服務器至關於服務器。
而對於Web服務器而言，http代理服務器又擔當了客戶端的角色。
11.四、虛擬主機
虛擬主機：是在網絡服務器上劃分出必定的磁盤空間供用戶放置站點、應用組件等，提供必要的站點功能與數據存放、傳輸功能。
所謂虛擬主機，也叫「網站空間」就是把一臺運行在互聯網上的服務器劃分紅多個「虛擬」的服務器，每個虛擬主機都具備獨立的域名和完整的Internet服務器（支持WWW、FTP、E-mail等）功能。一臺服務器上的不一樣虛擬主機是各自獨立的，並由用戶自行管理。但一臺服務器主機只可以支持必定數量的虛擬主機，當超過這個數量時，用戶將會感到性能急劇降低。
虛擬主機的實現原理:
虛擬主機是用同一個WEB服務器，爲不一樣域名網站提供服務的技術。Apache、Tomcat等都可經過配置實現這個功能。
相關的HTTP消息頭：Host。
例如：Host: www.baidu.com
客戶端發送HTTP請求的時候，會攜帶Host頭，Host頭記錄的是客戶端輸入的域名。這樣服務器能夠根據Host頭確認客戶要訪問的是哪個域名。
12、HTTP的缺點
- 通訊使用明文，內容可被竊聽
- 不驗證通訊方的身份
- 任何人能夠發起請求，全部人接收響應
- 沒法斷定請求是來自哪裏
-
沒法證實報文的完整性
如上圖中間人攻擊。
十3、HTTPS傳輸協議原理
HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全爲目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，所以加密的詳細內容請看SSL。
HTTP+ 加密 + 認證 + 完整性保護=HTTPS。
13.一、兩種基本的加解密算法類型
對稱加密：密鑰只有一個，加密解密爲同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES等。
非對稱加密：密鑰成對出現（且根據公鑰沒法推知私鑰，根據私鑰也沒法推知公鑰），加密解密使用不一樣密鑰（公鑰加密須要私鑰解密，私鑰加密須要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。
13.二、HTTPS通訊過程
13.三、HTTPS通訊的優缺點
客戶端產生的密鑰只有客戶端和服務器端能獲得；
加密的數據只有客戶端和服務器端才能獲得明文；
客戶端到服務端的通訊是安全的。
可是HTTPS速度較HTTP慢：
- 通訊慢
- 佔用大量CPU資源，致使處理速度變慢
十4、Websocket
Web 瀏覽器與 Web 服務器之間全雙工通訊標準
不論服務器仍是客戶端，任意一方均可直接向對方發送報文
在HTTP協議基礎上進行握手
- 推送功能：服務器可直接發送數據，沒必要等待請求。
- 減小通訊量：創建起 WebSocket 鏈接，一直保持鏈接狀態
十5、Web攻擊
對 Web 應用的攻擊模式有主動攻擊和被動攻擊。
15.1 主動攻擊
經過直接訪問Web傳入攻擊代碼，直接針對服務器上的資源進行攻擊從而訪問資源。
SQL注入攻擊
針對 Web 應用使用的數據庫，經過運行非法的 SQL而產生的攻擊
- OS命令攻擊
經過 Web 應用，執行非法的操做系統命令達到攻擊的目的
15.2 被動攻擊
利用圈套策略執行攻擊代碼的攻擊模式，不直接對web訪問進行攻擊
XSS跨站腳本攻擊CSRF跨站點請求僞造- HTTP 首部注入攻擊
- 1. 互聯網協議詳解
- 2. 圖解HTTP之HTTPS詳解
- 3. 圖解HTTP之HTTP報文
- 4. 圖解HTTP：網絡基礎
- 5. Docker之八----容器之間互聯與網絡模式詳解
- 6. 互聯網之父
- 7. 詳解互聯網APP架構
- 8. 網絡互聯參考模型（詳解）
- 9. 詳解互聯網APP架構2.0
- 10. 互聯網專業術語詳解
- 更多相關文章...
- • *.hbm.xml映射文件詳解 - Hibernate教程
- • ARP報文格式詳解 - TCP/IP教程
- • 互聯網組織的未來：剖析GitHub員工的任性之源
- • Flink 數據傳輸及反壓詳解
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 互聯網協議詳解
- 2. 圖解HTTP之HTTPS詳解
- 3. 圖解HTTP之HTTP報文
- 4. 圖解HTTP：網絡基礎
- 5. Docker之八----容器之間互聯與網絡模式詳解
- 6. 互聯網之父
- 7. 詳解互聯網APP架構
- 8. 網絡互聯參考模型（詳解）
- 9. 詳解互聯網APP架構2.0
- 10. 互聯網專業術語詳解