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

那大家有沒有碰到過這么一個情況呢？當我們在使用手機或者電腦瀏覽一些信息的時候，或者在搜索引擎中搜索資料，點擊搜索結果跳轉后，瀏覽器跳出一個 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 重新發送請求獲取資源，也就是通常所說的“重定向”，包括“著名”的 301、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 改寫等網頁引導操作。

總結

以上是生活随笔為你收集整理的【白话科普】上网时遇到的 404 是什么意思？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。