【白話科普】上網時遇到的 404 是什麼意思？

隨着網絡時代的發展與進步，咱們的學習工做和生活早已離不開互聯網，智能家居、網上購物、平常出行都須要互聯網的支持。互聯網切切實實地給生活帶來了諸多便利。

那你們有沒有碰到過這麼一個狀況呢？當咱們在使用手機或者電腦瀏覽一些信息的時候，或者在搜索引擎中搜索資料，點擊搜索結果跳轉後，瀏覽器跳出一個 404 Not Found 的空白頁。

相信各位老網民都很熟悉「404」這個數字了，這個錯誤代碼表明着服務器未找到文件，一般出訪問的頁面已經被更改或者移除，或是輸入了錯誤的訪問地址錯誤。

那爲何用 404 而不是其餘的數字來表明訪問資源不存在呢？互聯網上對 404 的誕生有這麼一個「傳說」。據傳在第三次科技革命前，整個互聯網的形態就像是一個大型的中央數據庫，並設置在一個叫 404 的房間裏。那個時候，全部的互聯網訪問請求都由人工手動完成，若在 404 房間中沒有找到請求者所須要的文件，或是因爲請求者寫錯了文件編號，工做人員就會返回一個「Room 404 : File Not Found」的信息。

固然，經實際考證後發現傳說中的 Room 404 其實並不存在，而 404 的真正來源則要從互聯網之本 -HTTP 協議提及。

狀態碼的由來

衆所周知，互聯網的創建打破了地域限制，經過瀏覽器與服務器之間的交流讓咱們足不出戶知天下。而瀏覽器與服務器之間的交流則是經過 HTTP 協議。

HTTP（Hypertext Transfer Protocol），超文本傳輸協議，它是應用層協議。因爲其簡捷、快速的方式，適用於分佈式和合做式超媒體信息系統。自 1990 年起應用於萬維網（WWW）全球信息服務系統。

用戶上網的過程，就是瀏覽器經過 HTTP 協議向服務端發送請求，而後將服務端主機上的內容顯示到本地。

支撐着 HTTP 協議工做的是 TCP/IP 協議這個模範打工人，它負責了底層的數據傳輸工做。單從這一點上來看，所謂的「超文本傳輸協議」其實和傳輸沒什麼聯繫，有點名存實亡。那爲何 HTTP 還被稱爲傳輸協議呢？答案就是它是傳輸報文內容的。

HTTP 協議在規範文檔裏詳細定義了報文的格式，規定了組成部分，解析規則，還有處理策略，因此能夠在 TCP/IP 層之上實現除了數據傳輸外，更靈活豐富的功能。

TCP 的協議報文，在實際要傳輸的數據以前附加了一個 20 字節的頭部數據，存儲 TCP 協議必須的額外信息，例如發送方的端口號、接收方的端口號、包序號、標誌位等等。有了這個附加的 TCP 頭，數據包纔可以正確傳輸，到了目的地後把頭部去掉，就能夠拿到真正的數據。

HTTP 協議也須要在實際傳輸的數據前附加這類頭數據，不過與 TCP 不一樣的是，它是一個「純文本」的協議，頭數據都是 ASCII 碼的文本，能夠很容易地用肉眼閱讀，不用藉助程序解析也可以看懂。

HTTP 協議的請求報文和響應報文的結構基本相同，主要由三大部分組成：

• 狀態行（status line）：描述響應的基本信息，也就是服務器響應的狀態；
• 頭部字段集合（header）：使用 key-value 形式更詳細地說明報文；
• 消息正文（entity）：實際響應的數據，它不必定是純文本，能夠是圖片、視頻等二進制數據。

其中狀態行和頭部字段常常又合稱爲「響應頭」，消息正文又稱爲「實體」，與「header」對應，不少時候直接稱爲「body」。

HTTP 協議規定報文必須有 header，但能夠沒有 body，且在 header 以後必需要有一個「空行」，也就是「CRLF」，十六進制的「0D0A」。

以又拍雲存儲接口文件上傳完畢後返回的響應報頭爲例，第一行「HTTP/2 200 OK」爲狀態行，由三部分構成：

• 版本號：表示報文使用的 HTTP 協議版本，上圖中版本爲 HTTP/2；
• 狀態碼：一個三位數，用代碼的形式表示處理的結果，好比 200 是成功，404 是資源不存在；
• 緣由短語：做爲數字狀態碼補充，是狀態碼的簡短文字描述，例如「OK」「Not Found」。

然後面的「Content-Type」、「Connection」等等都屬於 header，報文的最後是一個空白行結束，沒有 body。

多數狀況下 HTTP 報文只有 header 沒有 body。雖然 HTTP 協議對 header 的大小沒有作限制，但由於頭部太大可能會佔用大量的服務器資源，影響運行效率。所以各個 Web 服務器都不容許過大的請求頭。即使如此不少時候互聯網上依然是不少大頭在跑來跑去。

爲了儘量減小「大頭」佔用的資源，減小檢測錯誤地址訪問的時間，網站通常選擇狀態碼來負擔這個責任，由於數字比起文字可以更好地減少 HTTP 報文頭部體積。

響應報文可讓客戶端快速地經過狀態碼知道請求是否被正確處理，讓服務端能夠經過狀態碼選擇最恰當的狀態處理請求回覆客戶端。同時經過各種狀態碼，讓服務端明確告知客戶端響應狀態，讓客戶端明確本身的下一步操做。

目前 RFC 標準裏總共有 41 個狀態碼，並容許自行擴展。Apache、Nginx 等 Web 服務器都定義了一些專有的狀態碼。在開發 Web 應用的時候，咱們也能夠在不衝突前提下設置本身的專有狀態碼。

常見狀態碼

接下來，咱們詳說一下常見的各個狀態碼都表明着什麼？

狀態碼的意義在於表達 HTTP 數據處理的「狀態」，客戶端能夠依據代碼適時轉換處理狀態，通常是一個十進制數字，而 RFC 標準裏規定的狀態碼是三位數，取值範圍從 000 到 999。常見的狀態碼有必定的設計格式，被分紅了五類，用數字的第一位表示分類，而 0~99 不用，這樣狀態碼的實際可用範圍就大大縮小了，由 000~999 變成了 100~599。

1xx

1×× 類狀態碼屬於提示信息，是協議處理的中間狀態，實際可以用到的時候不多。

咱們偶爾可以見到的是 「101 Switching Protocols」。它的意思是客戶端使用 Upgrade 頭字段，要求在 HTTP 協議的基礎上改成其餘的協議繼續通訊，好比 WebSocket。而若是服務器也贊成變動協議，就會發送狀態碼 101，但這以後的數據傳輸就不會再使用 HTTP 了。

此外還有 「100 Continue」 。表示目前爲止一切正常, 客戶端應該繼續請求, 若是已完成請求則忽略。通常出如今文件上傳中。

2xx

2×× 類狀態碼錶示服務器收到併成功處理了客戶端的請求，這也是客戶端最願意看到的狀態碼。

「200 OK」是最多見的成功狀態碼，表示一切正常，服務器如客戶端所指望的那樣返回了處理結果。

「204 No Content」是另外一個很常見的成功狀態碼，它的含義與「200 OK」基本相同，但響應頭後沒有 body 數據。

「206 Partial Content」 通常用於分塊下載或斷點續傳的基礎，在客戶端發送「範圍請求」、要求獲取資源的部分數據時出現，它與 200 同樣，也是服務器成功處理了請求，但 body 裏的數據不是資源的所有，而是其中的一部分。狀態碼 206 一般還會伴隨着頭字段「Content-Range」，表示響應報文裏 body 數據的具體範圍，供客戶端確認，例如「Content-Range: bytes 0-66/888」，意思是這次獲取的是總計 888 個字節的前 66 個字節。

3xx

3×× 類狀態碼錶示客戶端請求的資源發生了變更，客戶端必須用新的 URI 從新發送請求獲取資源，也就是一般所說的「重定向」，包括「著名」的 30一、302 跳轉。

「301 Moved Permanently」俗稱「永久重定向」，含義是這次請求的資源已經不存在了，須要改用新的 URI 再次訪問。與它相似的是「302 Found」，曾經的描述短語是「Moved Temporarily」，俗稱「臨時重定向」，意思是請求的資源還在，但須要暫時用另外一個 URI 來訪問。

「304 Not Modified」 是一個比較有意思的狀態碼，它用於 If-Modified-Since 等條件請求，表示資源未修改，用於緩存控制。它不具備一般的跳轉含義，但能夠理解成「重定向已到緩存的文件」（即「緩存重定向」）。

4xx

4××類狀態碼錶示客戶端發送的請求報文有誤，服務器沒法處理，它是具備真正的「錯誤碼」含義的狀態碼了。

「400 Bad Request」是一個通用的錯誤碼，表示請求報文有錯誤，但具體是數據格式錯誤、缺乏請求頭或者仍是其餘錯誤則不會明確指示，所以在 Web 開發時通常會盡可能避免給客戶端返回 400，使用其餘更有明確含義的狀態碼。

「403 Forbidden」實際上不是客戶端的請求出錯，而是表示服務器禁止訪問資源。緣由可能多種多樣，例如信息敏感、法律禁止等。

「404 Not Found」多是咱們最常看到的一個狀態碼，它通常指資源在本服務器上未找到，因此沒法提供給客戶端。

4×× 裏剩下的一些代碼較明確地說明了錯誤的緣由，都很好理解，開發中經常使用的有：

• 405 Method Not Allowed：不容許使用某些方法操做資源，例如不容許 POST 只能 GET；
• 406 Not Acceptable：資源沒法知足客戶端請求的條件，例如請求中文但只有英文；
• 408 Request Timeout：請求超時，服務器等待了過長的時間；
• 409 Conflict：多個請求發生了衝突，能夠理解爲多線程併發時的競態；
• 413 Request Entity Too Large：請求報文裏的 body 太大；
• 414 Request-URI Too Long：請求行裏的 URI 太大；
• 429 Too Many Requests：客戶端發送了太多的請求，觸發了服務器的限制；
• 431 Request Header Fields Too Large：請求頭某個字段或整體太大。

5xx

5×× 類狀態碼錶示客戶端請求報文正確，但服務器在處理時內部發生了錯誤，沒法返回應有的響應數據，是服務器端的「錯誤碼」。

「500 Internal Server Error」 與 400 相似，也是一個通用的錯誤碼，服務器究竟發生了什麼錯誤咱們是不知道的。不過和 400 的響應相反，開發人員一般不會把服務器內部的出錯詳細信息返回給訪問端。雖然不利於調試，但可以防止黑客的窺探或者分析。

「501 Not Implemented」 表示客戶端請求的功能還不支持，相似於「即將開業，敬請期待」的意思。

「502 Bad Gateway」 一般是服務器做爲網關或者代理時返回的錯誤碼，表示服務器自身工做正常，訪問後端服務器時發生了錯誤，但具體的錯誤緣由也是不知道的。

「503 Service Unavailable」表示服務器當前很忙，暫時沒法響應服務，咱們上網時有時候遇到的「網絡服務正忙，請稍後重試」的提示信息就是狀態碼 503。

如何處理 404

回到咱們開頭所說的 404 問題。在實際業務中，不免會碰到輸入了錯誤連接地址訪問到不存在的資源，或者服務器突發故障沒法訪問的狀況。但 Web 服務器默認提供的錯誤響應頁面，不管 Nginx、Apache 或者是 IIS，都不是十分美觀，頁面簡陋、呆板，且對用戶不友好，沒法給用戶提供直觀明瞭的信息，形成用戶使用體驗的降低。

所以，不少開發者均使用自定義錯誤頁面的方式，來加強戶體驗，避免用戶流失。以 404 舉例來講，自定義 404 頁面通用的作法是在頁面中放置網站快速導航連接、搜索框以及網站提供的特點服務，這樣能夠有效的幫助用戶訪問站點並獲取須要的信息。

例如不少開發者會使用騰訊公益提供的「寶貝回家 - 公益 404 項目」，開發者能夠在自定義的 404 界面中引用一段代碼，當用戶訪問到 404 的資源，網頁會顯示訪問資源不存在，同時加載一些失蹤兒童的信息，經過互聯網來迅速傳播失蹤兒童信息，從而提升找回失蹤兒童的機率。這種操做讓科技充滿了溫度，體現了人文關懷，正是科技的浪漫所在。

若是你不知道如何自定義錯誤響應頁，可是又很想擁有。你能夠看一下又拍雲的 CDN 、或者雲存儲服務的自定義頁面功能。它能夠幫助你快速的配置 4XX、5XX 的錯誤響應頁。只須要打開控制檯，就能夠根據本身的需求配置錯誤響應也和錯誤響應圖，很是方便好用。

除此以外，還能夠經過邊緣規則，讓不一樣錯誤碼對應不一樣的網址跳轉、URL 改寫等網頁引導操做。

推薦閱讀

【白話科普】聊聊 DNS 的那些小知識

聊聊 HTTP 常見的請求方式