了解 Web 及網(wǎng)絡(luò)基礎(chǔ)

根據(jù) Web瀏覽器地址欄中指定的 URL，Web瀏覽器從Web服務(wù)器端獲取文件資源（resource）等信息，從而顯示出 Web 頁面。

通過發(fā)送請求獲取服務(wù)器資源的 Web 瀏覽器等，都可稱為客戶端（client）。

Web 使用一種名為 HTTP（HyperText Transfer Protocol，超文本傳輸協(xié)議）的協(xié)議作為規(guī)范完成從客戶端到服務(wù)器端等一系列運作流程。

HTTP 的誕生

現(xiàn)在已提出了 3 項 WWW （World Wide Web，萬維網(wǎng)）構(gòu)建技術(shù)，分別是：把 SGML（Standard Generalized Markup Language，標準通用標記語言）作為頁面的文本標記語言的 HTML（HyperText Markup Language，超文本標記語言）； 作為文檔傳遞協(xié)議的 HTTP ；指定文檔所在地址的 URL（Uniform 12 Resource Locator，統(tǒng)一資源定位符）。 WWW 這一名稱，是 Web 瀏覽器當年用來瀏覽超文本的客戶端應(yīng)用程序時的名稱?，F(xiàn)在則用來表示這一系列的集合，也可簡稱為 Web。

HTTP/1.0雖說是初期標準，但該協(xié)議標準至今仍被廣泛使用在服務(wù)器端。HTTP/1.1 是目前主流的 HTTP 協(xié)議版本

網(wǎng)絡(luò)基礎(chǔ) TCP/IP

HTTP 屬于TCP/IP內(nèi)部的一個子集。與互聯(lián)網(wǎng)相關(guān)聯(lián)的協(xié)議集合起來總稱為 TCP/IP

分層

TCP/IP 協(xié)議族按層次分別分為以下 4 層：應(yīng)用層、傳輸層、網(wǎng)絡(luò)層和數(shù)據(jù)鏈路層。

應(yīng)用層決定了向用戶提供應(yīng)用服務(wù)時通信的活動。

傳輸層對上層應(yīng)用層，提供處于網(wǎng)絡(luò)連接中的兩臺計算機之間的數(shù)據(jù)傳輸。在傳輸層有兩個性質(zhì)不同的協(xié)議：TCP（Transmission Control Protocol，傳輸控制協(xié)議）和 UDP（User Data Protocol，用戶數(shù)據(jù)報協(xié)議）。

網(wǎng)絡(luò)層（又名網(wǎng)絡(luò)互連層）用來處理在網(wǎng)絡(luò)上流動的數(shù)據(jù)包。數(shù)據(jù)包是網(wǎng)絡(luò)傳輸?shù)淖钚?shù)據(jù)單位。該層規(guī)定了通過怎樣的路徑（所謂的傳輸路線）到達對方計算機，并把數(shù)據(jù)包傳送給對方。與對方計算機之間通過多臺計算機或網(wǎng)絡(luò)設(shè)備進行傳輸時，網(wǎng)絡(luò)層所起的作用就是在眾多的選項內(nèi)選擇一條傳輸路線。

鏈路層（又名數(shù)據(jù)鏈路層，網(wǎng)絡(luò)接口層）用來處理連接網(wǎng)絡(luò)的硬件部分。包括控制操作系統(tǒng)、硬件的設(shè)備驅(qū)動、NIC（Network Interface Card，網(wǎng)絡(luò)適配器，即網(wǎng)卡），及光纖等物理可見部分（還包括連接器等一切傳輸媒介）。硬件上的范疇均在鏈路層的作用范圍之內(nèi)。

利用 TCP/IP 協(xié)議族進行網(wǎng)絡(luò)通信時，會通過分層順序與對方進行通信。發(fā)送端從應(yīng)用層往下走，接收端則往應(yīng)用層往上走。

發(fā)送端在層與層之間傳輸數(shù)據(jù)時，每經(jīng)過一層時必定會被打上一個該層所屬的首部信息。反之，接收端在層與層傳輸數(shù)據(jù)時，每經(jīng)過一層時會把對應(yīng)的首部消去。 這種把數(shù)據(jù)信息包裝起來的做法稱為封裝（encapsulate）。

IP、TCP 和 DNS

IP（Internet Protocol）網(wǎng)際協(xié)議位于網(wǎng)絡(luò)層。TCP/IP 協(xié)議族中的 IP 指的就是網(wǎng)際協(xié)議 “IP”其實是一種協(xié)議的名稱。

IP 協(xié)議的作用是把各種數(shù)據(jù)包傳送給對方。而要保證確實傳送到對方 那里，則需要滿足各類條件。其中兩個重要的條件是 IP 地址和 MAC 地址（Media Access Control Address）。 IP 地址指明了節(jié)點被分配到的地址，MAC 地址是指網(wǎng)卡所屬的固定 地址。IP 地址可以和 MAC 地址進行配對。IP 地址可變換，但 MAC 地址基本上不會更改。

使用 ARP 協(xié)議憑借 MAC 地址進行通信

ARP是一種用以解析地址的協(xié)議，根據(jù)通信方的 IP 地址就可以反查出對應(yīng)的 MAC 地址。

TCP 協(xié)議

TCP 位于傳輸層，提供可靠的字節(jié)流服務(wù)。 所謂的字節(jié)流服務(wù)（Byte Stream Service）是指，為了方便傳輸，將大塊數(shù)據(jù)分割成以報文段（segment）為單位的數(shù)據(jù)包進行管理。而可靠的傳輸服務(wù)是指，能夠把數(shù)據(jù)準確可靠地傳給對方。TCP 協(xié)議為了更容易傳送大數(shù)據(jù)才把數(shù)據(jù)分割，而且 TCP 協(xié)議能夠確認數(shù)據(jù)最終是否送達到對方。

確保數(shù)據(jù)能到達目標

為了準確無誤地將數(shù)據(jù)送達目標處，TCP 協(xié)議采用了三次握手（three-way handshaking）策略。用 TCP 協(xié)議把數(shù)據(jù)包送出去后，TCP 不會對傳送后的情況置之不理，它一定會向?qū)Ψ酱_認是否成功送達。握手過程中使用了 TCP 的標志（flag） —— SYN（synchronize） 和 ACK（acknowledgement）。 發(fā)送端首先發(fā)送一個帶 SYN 標志的數(shù)據(jù)包給對方。接收端收到后，回傳一個帶有 SYN/ACK 標志的數(shù)據(jù)包以示傳達確認信息。最后，發(fā)送端再回傳一個帶 ACK 標志的數(shù)據(jù)包，代表“握手”結(jié)束。 若在握手過程中某個階段莫名中斷，TCP 協(xié)議會再次以相同的順序發(fā)送相同的數(shù)據(jù)包。除了上述三次握手，TCP 協(xié)議還有其他各種手段來保證通信的可靠性。

DNS

DNS（Domain Name System）服務(wù)是和 HTTP 協(xié)議一樣位于應(yīng)用層的協(xié)議。它提供域名到 IP 地址之間的解析服務(wù)。 計算機既可以被賦予IP地址，也可以被賦予主機名和域名。

用戶通常使用主機名或域名來訪問對方的計算機，而不是直接通過 IP 地址訪問。DNS 協(xié)議提供通過域名查找 IP 地址，或逆向從IP 地址反查域名的服務(wù)。

URI 和 URL

URL（Uniform Resource Locator，統(tǒng)一資源定位符）正是使用 Web 瀏覽器等 訪問 Web 頁面時需要輸入的網(wǎng)頁地址。

URI 是 Uniform Resource Identifier 的縮寫，統(tǒng)一資源標識符。

URI 就是由某個協(xié)議方案表示的資源的定位標識符。協(xié)議方案是指訪問資源所使用的協(xié)議類型名稱。 采用 HTTP 協(xié)議時，協(xié)議方案就是 http。除此之外，還有 ftp、 25 mailto、telnet、file 等。標準的 URI 協(xié)議方案有 30 種左右。

URI 用字符串標識某一互聯(lián)網(wǎng)資源，而 URL表示資源的地點（互聯(lián)網(wǎng)上所處的位置）。可見 URL是 URI 的子集。

URL 一定是 URI
URN + URL 就是 URI

URN：統(tǒng)一資源名稱

絕對 URI 的格式

登錄信息（認證）此項是可選項。

服務(wù)器地址 使用絕對 URI 必須指定待訪問的服務(wù)器地址。地址可以是類似 hackr.jp 這種 DNS 可解析的名稱，或是 192.168.1.1 這類 IPv4 地址名，還可以是 [0:0:0:0:0:0:0:1] 這樣用方括號括起來的 IPv6 地址名。

服務(wù)器端口號 此項也是可選項，若用戶省略則自動使用默認端口號。

帶層次的文件路徑 指定服務(wù)器上的文件路徑來定位特指的資源。這與 UNIX 系統(tǒng)的文件目錄結(jié)構(gòu)相似。

查詢字符串 針對已指定的文件路徑內(nèi)的資源，可以使用查詢字符串傳入任意參數(shù)。此項可選。

片段標識符 使用片段標識符通?？蓸擞洺鲆勋@取資源中的子資源（文檔內(nèi)的某個位置）。但在 RFC 中并沒有明確規(guī)定其使用方法。該項也為可選項。

簡單的 HTTP 協(xié)議

? HTTP 協(xié)議用于客戶端和服務(wù)器端之間的通信

請求訪問文本或圖像等資源的一端稱為客戶端，而提供資源響應(yīng)的一端稱為服務(wù)器端。有時候，按實際情況，兩臺計算機作為客戶端和服務(wù)器端的角色有可 能會互換。但就僅從一條通信路線來說，服務(wù)器端和客戶端的角色是確定的，而用 HTTP 協(xié)議能夠明確區(qū)分哪端是客戶端，哪端是服務(wù)器端。

通過請求和響應(yīng)的交換達成通信

HTTP 協(xié)議規(guī)定，請求從客戶端發(fā)出，最后服務(wù)器端響應(yīng)該請求并返回?？隙ㄊ窍葟目蛻舳碎_始建立通信的，服務(wù)器端在沒有接收到請求之前不會發(fā)送響應(yīng)。

請求報文是由請求方法、請求 URI、協(xié)議版本、可選的請求首部字段和內(nèi)容實體構(gòu)成的

響應(yīng)報文基本上由協(xié)議版本、狀態(tài)碼（表示請求成功或失敗的數(shù)字代 碼）、用以解釋狀態(tài)碼的原因短語、可選的響應(yīng)首部字段以及實體主體構(gòu)成。

HTTP 是不保存狀態(tài)的協(xié)議

HTTP 是一種不保存狀態(tài)，即無狀態(tài)（stateless）協(xié)議。也就是說在 HTTP 這個級別，協(xié)議對于發(fā)送過的請求或響應(yīng)都不做持久化處理。

協(xié)議本身并不保留之前一切的請求或響應(yīng)報文的信息。

但為了實現(xiàn)期望的保持狀態(tài)功能，于是引入了 Cookie 技術(shù)。有了 Cookie 再用 HTTP 協(xié)議通信，就可以管理狀態(tài)了。

請求 URI 定位資源

指定請求 URI 的方式有很多。

除此之外，如果不是訪問特定資源而是對服務(wù)器本身發(fā)起請求，可以用一個 * 來代替請求URI。

告知服務(wù)器意圖的 HTTP 方法

GET ：獲取資源

GET 方法用來請求訪問已被 URI 識別的資源。指定的資源經(jīng)服務(wù)器端解析后返回響應(yīng)內(nèi)容。也就是說，如果請求的資源是文本，那就保持原樣返回；如果是像 CGI（Common Gateway Interface，通用網(wǎng)關(guān)接口）那樣的程序，則返回經(jīng)過執(zhí)行后的輸出結(jié)果。

POST：傳輸實體主體

POST 方法用來傳輸實體的主體。 雖然用 GET 方法也可以傳輸實體的主體，但一般不用 GET 方法進行傳輸，而是用 POST 方法。雖說 POST 的功能與 GET 很相似，但 POST 的主要目的并不是獲取響應(yīng)的主體內(nèi)容。

PUT：傳輸文件

PUT 方法用來傳輸文件。就像 FTP 協(xié)議的文件上傳一樣，要求在請求報文的主體中包含文件內(nèi)容，然后保存到請求 URI 指定的位置。但是，鑒于 HTTP/1.1 的 PUT 方法自身不帶驗證機制，任何人都可以上傳文件 , 存在安全性問題，因此一般的 Web 網(wǎng)站不使用該方法。若配合 Web 應(yīng)用程序的驗證機制，或架構(gòu)設(shè)計采用 REST（REpresentational State Transfer，表征狀態(tài)轉(zhuǎn)移）標準的同類 Web 網(wǎng)站，就可能會開放使用 PUT 方法。

HEAD：獲得報文首部

HEAD 方法和 GET 方法一樣，只是不返回報文主體部分。用于確認 URI 的有效性及資源更新的日期時間等。

DELETE：刪除文件

DELETE 方法用來刪除文件，是與 PUT 相反的方法。DELETE 方法按 請求 URI 刪除指定的資源。 但是，HTTP/1.1 的 DELETE 方法本身和 PUT 方法一樣不帶驗證機制，所以一般的 Web 網(wǎng)站也不使用 DELETE 方法。當配合 Web 應(yīng)用 程序的驗證機制，或遵守 REST 標準時還是有可能會開放使用的。

OPTIONS：詢問支持的方法

OPTIONS 方法用來查詢針對請求 URI 指定的資源支持的方法。

TRACE：追蹤路徑

TRACE 方法是讓 Web 服務(wù)器端將之前的請求通信環(huán)回給客戶端的方法。發(fā)送請求時，在 Max-Forwards 首部字段中填入數(shù)值，每經(jīng)過一個服務(wù)器端就將該數(shù)字減 1，當數(shù)值剛好減到 0 時，就停止繼續(xù)傳輸，最后接收到請求的服務(wù)器端則返回狀態(tài)碼 200 OK 的響應(yīng)。

客戶端通過 TRACE 方法可以查詢發(fā)送出去的請求是怎樣被加工修改 / 篡改的。這是因為，請求想要連接到源目標服務(wù)器可能會通過代理中轉(zhuǎn)，TRACE方法就是用來確認連接過程中發(fā)生的一系列操作。 但是，TRACE 方法本來就不怎么常用，再加上它容易引發(fā) XST（Cross-Site Tracing，跨站追蹤）攻擊，通常就更不會用到了。

CONNECT：要求用隧道協(xié)議連接代理

CONNECT方法要求在與代理服務(wù)器通信時建立隧道，實現(xiàn)用隧道協(xié)議進行 TCP 通信。主要使用 SSL（Secure Sockets Layer，安全套接 層）和 TLS（Transport Layer Security，傳輸層安全）協(xié)議把通信內(nèi)容加密后經(jīng)網(wǎng)絡(luò)隧道傳輸。

使用方法下達命令

向請求 URI 指定的資源發(fā)送請求報文時，采用稱為方法的命令。

方法的作用在于，可以指定請求的資源按期望產(chǎn)生某種行為。方法中有 GET、POST 和 HEAD 等。

持久連接節(jié)省通信量

HTTP 協(xié)議的初始版本中，每進行一次 HTTP 通信就要斷開一次 TCP 連接。

持久連接的特點是，只要任意一端沒有明確提出斷開連接，則保持 TCP 連接狀態(tài)。

持久連接的好處在于減少了 TCP 連接的重復(fù)建立和斷開所造成的額外開銷，減輕了服務(wù)器端的負載。另外，減少開銷的那部分時間，使 HTTP 請求和響應(yīng)能夠更早地結(jié)束，這樣 Web 頁面的顯示速度也就相應(yīng)提高了。

在 HTTP/1.1 中，所有的連接默認都是持久連接，但在 HTTP/1.0 內(nèi)并未標準化。雖然有一部分服務(wù)器通過非標準的手段實現(xiàn)了持久連接，但服務(wù)器端不一定能夠支持持久連接。毫無疑問，除了服務(wù)器端，客戶端也需要支持持久連接。

使用 Cookie 的狀態(tài)管理

無狀態(tài)協(xié)議當然也有它的優(yōu)點，不必保存狀態(tài)，可以減少服務(wù)器的 CPU 及內(nèi)存資源的消耗。

Cookie 技術(shù)通過在請求和響應(yīng)報文中寫入 Cookie 信息來控制客戶端的狀態(tài)。 Cookie 會根據(jù)從服務(wù)器端發(fā)送的響應(yīng)報文內(nèi)的一個叫做 Set-Cookie 的 首部字段信息，通知客戶端保存 Cookie。當下次客戶端再往該服務(wù)器 發(fā)送請求時，客戶端會自動在請求報文中加入 Cookie 值后發(fā)送出去。 服務(wù)器端發(fā)現(xiàn)客戶端發(fā)送過來的 Cookie 后，會去檢查究竟是從哪一個客戶端發(fā)來的連接請求，然后對比服務(wù)器上的記錄，最后得到之前的狀態(tài)信息。

HTTP 報文內(nèi)的 HTTP 信息

HTTP 報文

用于 HTTP 協(xié)議交互的信息被稱為 HTTP 報文。請求端（客戶端）的 HTTP 報文叫做請求報文，響應(yīng)端（服務(wù)器端）的叫做響應(yīng)報文。

HTTP 報文大致可分為報文首部和報文主體兩塊。兩者由最初出現(xiàn)的空行（CR+LF）來劃分。通常，并不一定要有報文主體。

請求報文及響應(yīng)報文的結(jié)構(gòu)

請求行 包含用于請求的方法，請求 URI 和 HTTP 版本。

狀態(tài)行 包含表明響應(yīng)結(jié)果的狀態(tài)碼，原因短語和 HTTP 版本。

首部字段 包含表示請求和響應(yīng)的各種條件和屬性的各類首部。一般有 4 種首部，分別是：通用首部、請求首部、響應(yīng)首部和實體首部?？赡馨?HTTP 的 RFC 里未定義的首部（Cookie 等）。

編碼提升傳輸速率

HTTP 在傳輸數(shù)據(jù)時可以按照數(shù)據(jù)原貌直接傳輸，但也可以在傳輸過程中通過編碼提升傳輸速率，但是會消耗更多的 CPU 等資源。

報文主體和實體主體的差異

報文（message） 是 HTTP 通信中的基本單位，由 8 位組字節(jié)流（octet sequence， 其中 octet 為 8 個比特）組成，通過 HTTP 通信傳輸。

實體（entity） 作為請求或響應(yīng)的有效載荷數(shù)據(jù)（補充項）被傳輸，其內(nèi)容由實體首部和實體主體組成。

HTTP 報文的主體用于傳輸請求或響應(yīng)的實體主體。通常，報文主體等于實體主體。只有當傳輸中進行編碼操作時，實體主體的內(nèi)容發(fā)生變化，才導致它和報文主體產(chǎn)生差異。

壓縮傳輸?shù)膬?nèi)容編碼

內(nèi)容編碼指明應(yīng)用在實體內(nèi)容上的編碼格式，并保持實體信息原樣壓縮。內(nèi)容編碼后的實體由客戶端接收并負責解碼

常用的內(nèi)容編碼有以下幾種。 gzip（GNU zip） compress（UNIX 系統(tǒng)的標準壓縮） deflate（zlib） identity（不進行編碼）

分割發(fā)送的分塊傳輸編碼

在 HTTP 通信過程中，請求的編碼實體資源尚未全部傳輸完成之前，瀏覽器無法顯示請求頁面。在傳輸大容量數(shù)據(jù)時，通過把數(shù)據(jù)分割成多塊，能夠讓瀏覽器逐步顯示頁面。 這種把實體主體分塊的功能稱為分塊傳輸編碼（Chunked Transfer Coding）。

分塊傳輸編碼會將實體主體分成多個部分（塊）。每一塊都會用十六進制來標記塊的大小，而實體主體的最后一塊會使用“0(CR+LF)”來標記。使用分塊傳輸編碼的實體主體會由接收的客戶端負責解碼，恢復(fù)到編碼前的實體主體。 HTTP/1.1 中存在一種稱為傳輸編碼（Transfer Coding）的機制，它可以在通信時按某種編碼方式傳輸，但只定義作用于分塊傳輸編碼中。

發(fā)送多種數(shù)據(jù)的多部分對象集合

MIME（Multipurpose Internet Mail Extensions，多用途因特網(wǎng)郵件擴展）機制，它允許郵件處理文本、圖片、視頻等多個不同類型的數(shù)據(jù)。例如，圖片等二進制數(shù)據(jù)以 ASCII 碼字符串編碼的方式指明， 就是利用 MIME 來描述標記數(shù)據(jù)類型。而在 MIME 擴展中會使用一種稱為多部分對象集合（Multipart）的方法，來容納多份不同類型的數(shù)據(jù)。

HTTP 協(xié)議中也采納了多部分對象集合，發(fā)送的一份報文主 體內(nèi)可含有多類型實體。通常是在圖片或文本文件等上傳時使用。在 HTTP 報文中使用多部分對象集合時，需要在首部字段里加上 Content-type。

多部分對象集合的每個部分類型中，都可以含有首部字段。另外，可以在某個部分中嵌套使用多部分對象集合。

獲取部分內(nèi)容的范圍請求

要實現(xiàn)從之前下載中斷處恢復(fù)下載的功能需要指定下載的實體范圍。像這樣，指定范圍發(fā)送的請求叫做范圍請求（Range Request）。

執(zhí)行范圍請求時，會用到首部字段 Range 來指定資源的 byte 范圍。

針對范圍請求，響應(yīng)會返回狀態(tài)碼為 206 Partial Content 的響應(yīng)報文。另外，對于多重范圍的范圍請求，響應(yīng)會在首部字段 ContentType 標明 multipart/byteranges 后返回響應(yīng)報文。如果服務(wù)器端無法響應(yīng)范圍請求，則會返回狀態(tài)碼 200 OK 和完整的實體內(nèi)容。

返回結(jié)果的 HTTP 狀態(tài)碼

??? 狀態(tài)碼的職責是當客戶端向服務(wù)器端發(fā)送請求時，描述返回的請求結(jié)果。

??? 狀態(tài)碼如 200 OK，以 3 位數(shù)字和原因短語組成。

2XX 成功

200 OK

表示從客戶端發(fā)來的請求在服務(wù)器端被正常處理了。

204 No Content

該狀態(tài)碼代表服務(wù)器接收的請求已成功處理，但在返回的響應(yīng)報文中不含實體的主體部分。另外，也不允許返回任何實體的主體。比如，當從瀏覽器發(fā)出請求處理后，返回 204 響應(yīng)，那么瀏覽器顯示的頁面不發(fā)生更新。

一般在只需要從客戶端往服務(wù)器發(fā)送信息，而對客戶端不需要發(fā)送新信息內(nèi)容的情況下使用。

206 Partial Content

該狀態(tài)碼表示客戶端進行了范圍請求，而服務(wù)器成功執(zhí)行了這部分的 GET 請求。響應(yīng)報文中包含由 Content-Range 指定范圍的實體內(nèi)容。

3XX 重定向

301 Moved Permanently

永久性重定向。該狀態(tài)碼表示請求的資源已被分配了新的 URI，以后 應(yīng)使用資源現(xiàn)在所指的 URI。也就是說，如果已經(jīng)把資源對應(yīng)的 URI 保存為書簽了，這時應(yīng)該按 Location 首部字段提示的 URI 重新保存。

302 Found

臨時性重定向。該狀態(tài)碼表示請求的資源已被分配了新的 URI，希望用戶（本次）能使用新的 URI 訪問。

303 See Other

該狀態(tài)碼表示由于請求對應(yīng)的資源存在著另一個 URI，應(yīng)使用 GET 方法定向獲取請求的資源。

303 狀態(tài)碼和 302 Found 狀態(tài)碼有著相同的功能，但 303 狀態(tài)碼明確表示客戶端應(yīng)當采用 GET 方法獲取資源，這點與 302 狀態(tài)碼有區(qū)別。

（當 301、302、303 響應(yīng)狀態(tài)碼返回時，幾乎所有的瀏覽器都會把POST改成GET，并刪除請求報文內(nèi)的主體，之后請求會自動再次發(fā)送。301、302 標準是禁止將 POST 方法改變成GET方法的，但實際使用時大家都會這么做。）

304 Not Modified

該狀態(tài)碼表示客戶端發(fā)送附帶條件的請求時，服務(wù)器端允許請求訪問資源，但未滿足條件的情況。和重定向沒有關(guān)系。

307 Temporary Redirect

臨時重定向。該狀態(tài)碼與 302 Found 有著相同的含義。盡管 302 標準禁止 POST 變換成 GET，但實際使用時大家并不遵守。 307 會遵照瀏覽器標準，不會從 POST 變成 GET。但是，對于處理響應(yīng)時的行為，每種瀏覽器有可能出現(xiàn)不同的情況。

4XX 客戶端錯誤

400 Bad Request

該狀態(tài)碼表示請求報文中存在語法錯誤。

當錯誤發(fā)生時，需修改請求的內(nèi)容后再次發(fā)送請求。另外，瀏覽器會像 200 OK 一樣對待該狀態(tài)碼。

401 Unauthorized

該狀態(tài)碼表示發(fā)送的請求需要有通過 HTTP 認證（BASIC 認證、DIGEST 認證）的認證信息。另外若之前已進行過1次請求，則表示用戶認證失敗。

403 Forbidden

該狀態(tài)碼表明對請求資源的訪問被服務(wù)器拒絕了?？赡芪传@得文件系統(tǒng)的訪問授權(quán)，訪問權(quán)限出現(xiàn)某些問題

404 Not Found

該狀態(tài)碼表明服務(wù)器上無法找到請求的資源

5XX 服務(wù)器錯誤

500 Internal Server Error

該狀態(tài)碼表明服務(wù)器端在執(zhí)行請求時發(fā)生了錯誤

503 Service Unavailable

該狀態(tài)碼表明服務(wù)器暫時處于超負載或正在進行停機維護，現(xiàn)在無法處理請求。（如果事先得知解除以上狀況需要的時間，最好寫入 RetryAfter 首部字段再返回給客戶端。）

狀態(tài)碼和狀況的不一致

不少返回的狀態(tài)碼響應(yīng)都是錯誤的文章來源地址http://www.zghlxwxcb.cn/news/detail-787576.html

到了這里，關(guān)于計算機網(wǎng)絡(luò)夯實之路-HTTP詳解的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！