初识HTTP——基于《图解HTTP》
文章目錄
- 一、寫在開始
- 二、了解Web及網絡基礎
- 2.1 網絡基礎TCP/IP
- 2.1.1 TCP/IP協議族
- 2.1.2 TCP/IP的分層管理
- 2.1.3 TCP/IP通信傳輸流
- 2.2 與HTTP關系密切的協議：IP、TCP和DNS
- 2.2.1 負責傳輸的IP協議
- 2.2.2 確保可靠性的TCP協議
- 2.3 負責域名解析的DNS服務
- 2.4 各種協議與HTTP協議的關系
- 2.5 URI和URL
- 2.5.1 統一資源標識符
- 2.5.2 URI格式
- 三、 簡單的HTTP協議
- 3.1 HTTP協議用于客戶端和服務端之間的通信
- 3.2 通過請求和相應交換達成通信
- 3.3 HTTP是不保存狀態的協議
- 3.4 請求URI定位資源
- 3.5告知服務器意圖的HTTP方法
- 3.5.1 GET：獲取資源
- 3.5.2 POST：傳輸實體主體
- 3.5.3 PUT：傳輸文件
- 3.5.4 HEAD：獲得報文首部
- 3.5.5 DELETE：刪除文件
- 3.5.6 OPTIONS：詢問支持的方法
- 3.5.7 TARCE：追蹤路徑
- 3.5.8 CONNECT：要求用隧道協議連接代理
- 3.6 使用方法下達命令
- 3.7 持久連接節省通信量
- 3.7.1 持久連接
- 3.7.2 管線化
- 3.8 使用Cookie的狀態管理
- 四、 HTTP報文內的HTTP信息
- 4.1 HTTP報文
- 4.2 請求報文和響應報文的結構
- 4.3 編碼提升傳輸速率
- 4.3.1 報文主體和實體主體的差異
- 4.3.2 壓縮傳輸的內容編碼
- 4.3.3 分割發送的分塊傳輸編碼
- 4.4 發送多種數據的多部分對象集合
- 4.5 獲取部分內容的范圍請求
- 4.6 內容協商返回最合適的內容
- 五、 返回結果的HTTP狀態碼
- 5.1 狀態碼告知從服務器端返回的請求結果
- 5.2 2XX成功
- 5.2.1 200 OK
- 5.2.2 204 No Content
- 5.2.3 206 Partial Content
- 5.3 3XX重定向
- 5.3.1 301 Moved Permanently
- 5.3.2 302 Found
- 5.3.3 3.3 See Other
- 5.3.4 304 Not Modified
- 5.3.5 307 Temporary Redirect
- 5.4 4XX客戶端錯誤
- 5.4.1 400 Bad Request
- 5.4.2 401 Unauthorized
- 5.4.3 403 Forbidden
- 5.4.4 404 Not Found
- 5.5 5XX服務器錯誤
- 5.5.1 500 Internal Server Error
- 5.5.2 503 Service Unavailable
- 5.6 狀態碼和狀況不一致
一、寫在開始
本科學習中沒有深入學習過HTTP的相關內容，這塊對我自己來說就是一個空的知識短板。打算利用這兩天時間，初步理解HTTP的有關內容。
學習參考的是《圖解HTTP》一書。
二、了解Web及網絡基礎
當在瀏覽器的地址欄上輸入一串URL時，可以看到對應的Web頁面。Web頁面不能憑空顯示出來。根據Web瀏覽器地址欄中指定的URL，Web瀏覽器從Web服務器端獲取文件資源等信息，從而顯示出web頁面。
像這種通過發送請求獲取資源的Web瀏覽器等，都可以稱為客戶端（client）。
Web使用一種名為HTTP（HyperText Transfer Protocol，超文本傳輸協議）的協議作為規范，完成從客戶端到服務端等一系列運作流程。
2.1 網絡基礎TCP/IP
通常使用的網絡是在TCP/IP協議族的基礎上運作的，而HTTP屬于它內部的一個子集。
2.1.1 TCP/IP協議族
協議： 計算機與網絡設備要互相通信，雙方就必須基于想用的方法。比如，如何探測到通信目標、由哪一邊先發起通信、使用哪種語言進行通信、怎樣結束通信等規則都需要事先確定。不同的硬件、操作系統之間的通信，所有的這一切都需要一種規則。這種規則就是協議。
協議中存在各式各樣的內容。從電纜的規格到IP地址的選定方法、尋找異地用戶的方法、雙方建立通信的順序，以及Web頁面顯示需要處理的步驟，等等。
像這樣把與互聯網相關聯的協議集合起來總稱為TCP/IP。
2.1.2 TCP/IP的分層管理
TCP/IP協議族里重要的一點就是分層。TCP/IP協議族按層次分別分為以下四層：
TCP/IP協議族內預設了各類通用的應用服務，比如FTP、DNS就是其中兩類。
HTTP協議也處于該層
在傳輸層有兩個性質不同的協議：TCP（傳輸控制協議）和UDP（用戶數據報協議）。
該層規定了通過怎樣的路徑（所謂的傳輸路線）到達對方計算機，并報數據寶傳送給對方。
與對方計算機之間通過多臺計算機或者網絡設備進行傳輸時，網絡層所起的作用就是在眾多的選項中選擇一條傳輸路線。
包括操作系統、硬件的設備驅動、NIC（Network Interface Card，網絡適配器，即網卡），及光纖等。硬件上的范疇均在鏈路層作用范圍之內。
TCP/IP層次化的好處：
如果互聯網只由一個協議統籌，某個地方需要修改設計時候，就必須報所有的部分整體替換掉。而分層后只需要把變動的層替換掉即可，把各層之間的接口部分規劃好之后，每個層次內部的設計就能夠自由改動了。
層次化后，設計也變得相對簡單了。處于應用層上的應用可以只考慮分配給自己的任務。
2.1.3 TCP/IP通信傳輸流
利用TCP/IP協議族進行網絡通信時，會通過分層順序與對方進行通信 。發送端從應用層往下走，接收端則往應用層往上走。
舉個例子：
作為發送端的客戶端在應用層（HTTP協議）發出一個想看某個Web頁面的HTTP請求。
接著，為了傳輸方便，在傳輸層（TCP協議）吧應用層收到的數據（HTTP請求報文）進行分割，并在各個保溫上打上標記序號及端口號后轉發給網絡層。
在網絡層（IP協議），增加作為通信目的地的MAC地址后轉發給鏈路層。這樣，發往網絡的通信請求就準備齊全了。
接收端的服務器在鏈路層接收到數據，按順序往上層發送，一直到應用層，當傳輸到應用層，才能算真正接受到由客戶端發送過來的HTTP請求。
- 封裝： 發送端在層與層之間傳輸數據時，每經過一層必定會被打上一個該層所屬的首部信息。反之，接收端在層與層傳輸數據時，每經過一層時，會把對應的首部消去。這種吧數據信息包裝起來的做法稱為封裝。
2.2 與HTTP關系密切的協議：IP、TCP和DNS
2.2.1 負責傳輸的IP協議
IP網際協議位于網絡層，其作用是把各種數據包傳送給對方。而要保證確實傳送到對方那里，則需要滿足各類條件。其中兩個重要的條件是IP地址和MAC地址。
- IP地址： 指明了節點被分配到的地址。
- MAC地址： 指網卡所屬的固定地址。
IP地址可以和MAC地址進行配對。IP地址可以變換，但是MAC地址基本上不會更改。
使用ARP協議憑借MAC地址進行通信
IP間的通信依賴MAC地址。在網絡上，通信的雙方在同一局域網內的情況很少，通常經過多臺計算機和網絡設備中轉才能連接到對方。而在進行中轉時，會利用下一站中轉設備的MAC地址來搜索下一個中轉目標。這時，會采用ARP協議（Address Resolution Protocol）。
- ARP協議：ARP是一種用以解析地址的協議，根據通信方的IP地址就可以反查出對應的MAC地址。
沒有人能過全面掌握互聯網中的傳輸狀況
- 路由選擇（routing）： 在到達通信目標前的中轉過程中，那些計算機和路由器等網絡設備只能獲悉很粗略的傳輸路線，這種機制稱為路由選擇。
可以理解為快遞公司的送貨過程，有中轉站與集散中心等。
2.2.2 確保可靠性的TCP協議
按層次分，TCP位于傳輸層，提供可靠的字節流服務。
- 字節流服務（Byte Stream Service）：為了傳輸方便，將大塊數據分割成以報文段（segment)為單位的數據包進行管理。而可靠的傳輸服務是指，能夠把數據準確可靠地傳給對方。一言以蔽之，TCP協議為了更容易傳送大數據才把數據分割，而且TCP協議能過確認數據最終是否送達到對方。
確保數據能夠到達目標
為了準確無誤的將數據送達目標處，TCP協議采用了三次握手策略。用TCP協議把數據包送出去后，TCP不會對傳送后的情況置之不理，他一定會像對方確認是否發送成功。握手過程中使用了TCP的標志（flag）——SYN（synchronize）和ACK(acknowledgement）。
發送端首先發送一個帶SYN標志的數據包給對方。接收端收到后，回傳一個帶有SYN/ACK標志的數據包以示傳達確認信息。最后發送端再回傳一個帶ACK標志的數據包，代表“握手”結束。
若在我收過程中某個階段莫名中斷，TCP協議會再次以相同的順序發送相同的數據包。除了上述三次握手，TCP協議還有其他各種手段來保證通信的可靠性。
2.3 負責域名解析的DNS服務
DNS（Domain Name System）服務是和HTTP協議一樣位于應用層的協議。它提供域名到IP抵制之間的解析服務。
用戶通常使用主機名或域名來訪問對方的計算機，而不是直接通過IP地址訪問。
2.4 各種協議與HTTP協議的關系
圖片來自圖解HTTP
2.5 URI和URL
與URI（統一資源標識符）相比，更熟悉的是URL（統一資源定位符）。
2.5.1 統一資源標識符
URI是Uniform Resource Identifier的縮寫。
Uniform
規定統一的格式可方便處理多種不同類型的資源，而不用根據上下文環境來識別資源指定的訪問方式。另外，加入新增的協議方案也更容易。
Resource
資源的定義是"可標識的任何東西"。除了文檔文件、圖像或服務等能夠區別于其他類型的，全部可作為資源。另外，資源不僅可以是單一的，也可以是多數的集合。
Identitier
表示可標識的對象，也稱標識符。
綜上所述，URI就是由某個協議方案表示的資源的定位標識符。協議方案是指訪問資源所用的協議類型名稱。
采用HTTP協議時，協議方案就是http。除此之外，還有ftp、mailto、telnet、file等。標準的URI協議方案有30多種。
URI用字符串標識某一互聯網資源，而URL標識資源的地點（互聯網上所處的位置）。可見URL是URI的子集
URI的例子
2.5.2 URI格式
表示指定的URI，要是用涵蓋全部必要信息的絕對URI、絕對URL以及相對URL。
- 相對URL：是指從瀏覽器中基本URI處指定的URL，形如/image/logo.gif
絕對URI的例子：
使用http:或https：等協議方案名獲取訪問資源時，要制定協議類型。不區分大小寫，最后附一個冒號。
- 登錄信息（認證）：指定用戶名和密碼作為從服務器端獲取資源時必要的登錄信息（身份認證），可選。
- 服務器地址：使用絕對URI必須指定待訪問的服務器地址。地址可以是類似hackr.jp這種DNS可解析的名稱。
- 服務器端口號：指定服務器連接的網絡端口號。此項可選，省略則自動使用默認端口。
- 帶層次的文件路徑：指定服務器上的文件路徑來定位特指的資源。這與UNIX系統的文件目錄結構類似。
- 查詢字符串：對已指定的文件路徑內的資源，可以用查詢字符串傳入任意參數，可選
- 片段標識符：使用片段標識符通常可標記出以獲取資源文件中的子資源（文檔內的某個位置），可選。
三、 簡單的HTTP協議
使用HTTP/1.1版本，記錄理解HTTP協議的基礎
3.1 HTTP協議用于客戶端和服務端之間的通信
HTTP協議和TCP/IP協議族內的其他眾多的協議相同，用于客戶端和服務端之間的通信。
- 客戶端：請求訪問文本或圖像等資源的一端。
- 服務端：提供資源響應的一端。
在兩臺計算機之間使用HTTP協議通信時，在一條通信線路上，必定有一端時客戶端，另一端時服務端。
3.2 通過請求和相應交換達成通信
請求必定由客戶端發出，而服務端回復響應。
簡單的舉例（圖片來自《圖解HTTP》）
起始行開頭的GET表示請求訪問服務器的類型，成為方法（method）。隨后的字符串/index.htm 指明了請求訪問的資源對象，也叫做請求URI。最后HTTP/1.1，即HTTP的版本號，用來提示客戶端使用的HTTP協議功能。
綜合來看，這段請求內容的意思是：請求訪問某臺HTTP服務器上的/index.htm頁面資源。
接收到請求的服務器，會將請求內容的處理結果以響應的形式返回。
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）和原因短語（response-phrase）。下一行顯示了創建響應的日期時間，是首部字段（header field）內的一個屬性。
接著以一空行分割，之后的內容成為資源實體的主體（entity body）。
-
請求報文：由請求方法、請求URI、協議版本、可選的請求首部字段和內容實體構成。
-
響應報文：由協議版本、狀態碼（表示請求成功或失敗的數字代碼）、用以解釋狀態碼的原因短語、可選的響應首部字段以及實體主體構成。
3.3 HTTP是不保存狀態的協議
HTTP是一種不保存狀態，即無狀態（stateless）協議。HTTP協議自身不對請求和響應之間的通信狀態進行保存。也就是說，在HTTP這個級別，協議對于發送過的請求或響應都不做持久化處理。
使用HTTP協議，每當有新的請求發送時，就會有對應的新響應產生。協議本身并不保留之前一切的請求或響應報文的信息。這是為了更快地處理大量事務，確保協議的可伸縮性，而特意把HTTP協議涉及成如此簡單的。
HTTP/1.1雖然是無狀態協議，但為了實現期望的保持狀態功能，于是引入了Cookie技術。有了Cookie再用HTTP協議通信，就可以管理狀態了。
3.4 請求URI定位資源
HTTP協議使用URI定位互聯網上的資源。正是URI的特定功能，在互聯網上任意位置的資源都能訪問。
當客戶端請求訪問資源而發送請求時，URI需要將作為請求報文中的請求URI包含在內。指定請求URI的方式有很多。
- URI為完整的請求URI
- 在首部字段Host中寫明網絡域名或IP地址
除此之外，如果不是訪問特定資源而是對服務器本身發起請求，可以用一個*來代替請求URI。下面這個例子是查詢HTTP服務端支持的HTTP方法種類
OPTIONS * HTTP/1.13.5告知服務器意圖的HTTP方法
3.5.1 GET：獲取資源
GET方法用來請求訪問已被URI識別的資源。指定的資源經服務器端解析后返回響應內容。也就是說，如果請求的資源時文本，那就保持原樣返回；
如果像CGI那樣的程序，則返回經過執行后的輸出結果。
3.5.2 POST：傳輸實體主體
POST方法用來傳輸實體的主體
雖然用GET方法也可以傳輸實體主體，但是一般不用GET方法進行傳輸，而是用POST方法。雖說POST的功能與GET很相似，但是POST的主要目的并不是獲取響應內容的主體。
3.5.3 PUT：傳輸文件
PUT方法用于傳輸文件
就像FTP協議的文件上傳一樣，要求在請求報文的主體中包含文件內容，然后保存到請求URI指定的位置。
3.5.4 HEAD：獲得報文首部
HEAD和GET方法一樣，只是不返回報文主體部分。用于確認URI的有效性及資源更新的日期時間等。
#請求 HEAD /index.html/ HTTP/1.1 Host: www.hackr.jp #響應 # 返回index.html有關的響應首部3.5.5 DELETE：刪除文件
DELETE方法用來刪除文件，是與PUT相反。
DELETE方法按請求URI刪除指定的資源。
3.5.6 OPTIONS：詢問支持的方法
OPTIONS方法用來查詢針對請求URI指定的資源支持的方法
#請求 OPTIONS * HTTP/1.1 Host: www.hackr.jp #響應 HTTP/1.1 200 OK Allow: GET,POST,HEAD,OPTIONS #（返回服務器支持的方法）3.5.7 TARCE：追蹤路徑
TRACE方法是讓Web服務器端將之前的請求通信還回給客戶端的方法。不常用
3.5.8 CONNECT：要求用隧道協議連接代理
CONNECT 方法要求在代理服務器通信時建立隧道，實現用隧道協議進行TCP通信。
主要使用SSL和TLS協議把通信內容加密后經網絡隧道傳輸。
格式
3.6 使用方法下達命令
向請求URI指定的資源發送請求報文時，采用稱為方法的命令。
方法的作用在于：可以指定請求的資源按期望產生某種行為。
方法用GET、POST、HEAD等
下面列出了1.0和1.1支持的方法。
| GET | 獲取資源 | 1.0/1.1 |
| POST | 傳輸實體主體 | 1.0/1.1 |
| PUT | 傳輸文件 | 1.0/1.1 |
| HEAD | 獲得報文首部 | 1.0/1.1 |
| DELETE | 刪除文件 | 1.0/1.1 |
| OPTIONS | 詢問支持的方法 | 1.1 |
| TRACE | 追蹤路徑 | 1.1 |
| CONNECT | 要求用隧道協議連接代理 | 1.1 |
| LINK | 建立和資源之間的聯系 | 1.0 |
| UNLINE | 斷開連接關系 | 1.0 |
3.7 持久連接節省通信量
HTTP初始版本中，沒進行一次HTTP通信就要斷開一次TCP連接。
3.7.1 持久連接
持久連接的特點是：只要任意一端沒有明確的提出斷開連接，則保持TCP連線狀態。
在HTTP/1.1中，所有的連接默認都是持久連接。
3.7.2 管線化
持久連接使得多數請求一管線化方式發送成為可能。
從前發送請求后需要等待并收到響應，才能發送下一個請求。
管線化技術出現后，不用等待響應亦可發送下一個請求。
3.8 使用Cookie的狀態管理
HTTP是無狀態協議，它不對之前發生過的請求和響應的狀態進行管理。由于不必保存狀態，自然可減少服務器的CPU及內存資源的消耗。
Cookie技術通過在請求和響應報文中寫入Cookie信息來控制客戶端的狀態。
四、 HTTP報文內的HTTP信息
4.1 HTTP報文
- HTTP報文：用于HTTP協議交互的信息被稱為HTTP報文
- 請求報文：請求端的HTTP報文
- 響應報文：響應端的HTTP報文
HTTP報文本身是由多行數據構成的字符串文本。
HTTP報文大致可分為報文首部和報文主體兩塊。
4.2 請求報文和響應報文的結構
包含用于請求的方法，請求的URI和HTTP版本
包含表明響應結果的狀態碼，原因短語和HTTP版本
包含表示請求和響應的各種條件和屬性的各類首部。
一般有4中：通用首部、請求首部、響應首部和實體首部
可能包含HTTP的RFC里未定義的首部（Cookie等）
4.3 編碼提升傳輸速率
HTTP在傳輸數據時可以按照數據原貌直接傳輸，但是也可以在傳輸過程中通過編碼提升速率。
4.3.1 報文主體和實體主體的差異
- 報文
是HTTP通信中的基本單位，由8位組字節流組成，通過HTTP通信傳輸 - 實體
作為請求或相應有效載荷數據被傳輸，其內容由實體首部和實體主體組成。
HTTP報文的主體用于傳輸請求或響應的實體主體。
通常，報文主體等于實體主體。只有當傳輸中進行編碼操作時，實體主體內容發生變化，才導致它和報文主體產生差異
4.3.2 壓縮傳輸的內容編碼
內容編碼指：應用在實體內容的編碼格式，并保持實體信息原樣壓縮。內容編碼后的實體由客戶端接收并負責解碼。
主要有以下幾種：
- gzip（GNU zip）
- compress（UNIX系統的標準壓縮）
- deflate（zlib）
- identity（不進行編碼）
4.3.3 分割發送的分塊傳輸編碼
在傳輸大容量數據時，通常把數據分割成多塊，能夠讓瀏覽器逐步顯示頁面。
4.4 發送多種數據的多部分對象集合
HTTP協議中也采納了多部分對象集合，發送的一份報文主體內可含有多類型主體。通常是在圖片或文本文件等上傳時使用。
4.5 獲取部分內容的范圍請求
為了實現可恢復的機制，即繼續上次下載圖片的位置繼續下載，要實現該功能需要制定下載的實體范圍。
指定范圍發送的請求叫做范圍請求。
對一份10000字節大小的資源，可以請求500–10000字節內的資源。
執行范圍請求時，會用到首部字段Range來制定資源的byte范圍。
格式如下：
- 5001-10000字節
- 從5001字節之后全部的
- 從一開始到3000字節和5000-7000字節多范圍
針對范圍請求，響應會返回狀態碼為206 Partial Content的響應報文。
對于多重范圍的范圍請求，響應會在首部字段Content-Type表明multipart/byteranges 后返回響應報文。
如果服務器端無法響應范圍請求，則會返回狀態碼200 OK 和完整地實體內容。
4.6 內容協商返回最合適的內容
當瀏覽器默認語言為英文或中文，訪問相同的URI的web頁面時，則會顯示對應的英語版或中文版的Web頁面。這樣的機制稱為內容協商。
內容協商機制是指客戶端和服務端就響應的資源內容進行交涉，然后提供給客戶端最為合適的資源。
主要有以下3種類型：
- 服務器驅動協商
由服務器端進行內容協商。 - 客戶端驅動協商
由客戶端進行內容協商的方式 - 透明協商
是服務器驅動和客戶端驅動的結合體，是由服務端和客戶端各自進行內容協商的一種方法。
五、 返回結果的HTTP狀態碼
HTTP狀態碼負責表示客戶端HTTP請求的返回結果、標記服務器端的處理是否正常、通知出現的錯誤等工作。
5.1 狀態碼告知從服務器端返回的請求結果
狀態碼的職責是當客戶端向服務器端發送請求時，描述返回的請求結果。
相應類別分為以下五種：
| 1XX | Information（信息性狀態碼） | 接收的請求正在處理 |
| 2XX | Success（成功狀態碼） | 請求正常處理完畢 |
| 3XX | Redirection（重定向狀態碼） | 需要進行附加操作以完成請求 |
| 4XX | Client Error（客戶端錯誤狀態碼） | 服務器無法處理請求 |
| 5XX | Server Error（服務器錯誤狀態碼） | 服務器處理請求出錯 |
5.2 2XX成功
5.2.1 200 OK
表示從客戶端發來的請求在服務器端被正常處理了。
5.2.2 204 No Content
表示服務器接收的請求已成功處理，但是再返回的響應報文中不包含實體的主體部分。另外，也不允許返回任何實體的主體。
一般在只需要從客戶端往服務器發送信息，而對客戶端不需要發送新信息內容的情況下使用。
5.2.3 206 Partial Content
表示客戶端進行了范圍請求，而服務器成功執行了這部分的GET請求。
5.3 3XX重定向
3XX響應結果表明瀏覽器需要執行某些特殊的處理以正確處理請求。
5.3.1 301 Moved Permanently
永久性重定向。該狀態碼表示請求的資源已被分配了新的URI，以后應使用資源現在所指的URI。
5.3.2 302 Found
臨時重定向。該狀態碼表示請求的資源已被分配了新的URI，希望用戶（本次）使用新的URI訪問。
和301很相似，但是302代表的是資源不是被永久移動，只是臨時性質的。
5.3.3 3.3 See Other
表示由于請求對應的資源存在著另一個URI，應使用GET方法定向獲取請求的資源。
302與303有相同的功能，但是303狀態碼明確表示客戶端應采用GET方法獲取資源，這個與302不同。
5.3.4 304 Not Modified
表示客戶端發送附帶條件的請求時，服務端允許請求訪問資源，但未滿足條件的情況。304狀態碼返回時，不包含任何響應的主體部分。和重定向沒有任何關系。
5.3.5 307 Temporary Redirect
臨時重定向。
5.4 4XX客戶端錯誤
5.4.1 400 Bad Request
該狀態碼表示請求報文中存在語法錯誤。瀏覽器會想200 OK一樣對待該狀態碼。
5.4.2 401 Unauthorized
該狀態碼表示發送的請求需要有通過HTTP認證的認證信息。
5.4.3 403 Forbidden
該狀態碼表明對請求資源的訪問被服務器拒絕了。
未獲得文件系統的訪問授權，訪問權限出現某些問題等列舉的情況都可能是發生403的原因。
5.4.4 404 Not Found
該狀態碼表明服務器上無法找到請求的資源，也可以在服務器端拒絕請求且不想說明理由時使用。
5.5 5XX服務器錯誤
5.5.1 500 Internal Server Error
該狀態碼表明服務器端在執行請求時發生了錯誤。也有可能是Web應用存在bug或臨時性故障。
5.5.2 503 Service Unavailable
該狀態碼表明服務器暫時處于超負載或正在進行停機維護，現在無法處理請求。
5.6 狀態碼和狀況不一致
不少返回的狀態碼響應都是錯誤的。比如Web應用程序內部發生錯誤，狀態碼依然返回200 OK，這種情況也經常遇到。
總結
以上是生活随笔為你收集整理的初识HTTP——基于《图解HTTP》的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 什么？30秒生成一个logo
- 下一篇： XSS原理dvwaxssvalidato