HTTP協議詳解以及URL具體訪問過程

閱讀目錄

• 1、簡介
• 2、URI與URL
• 3、TCP握手連線以及斷開（擴充套件）
• 4、特點
• 5、HTTP請求
• 　　5.1、Request 訊息的結構
• 　　5.2、請求方法
• 　　5.3、http的無狀態以及建立連線方式
• 　　5.4、請求行
• 　　5.5、請求頭
• 　　5.6、請求主體
• 6、HTTP響應
• 　　6.1、Response 訊息的結構
• 　　6.2、響應行
• 　　6.3、響應頭
• 　　6.4、響應主體
• 7、HTTP請求詳細過程
• 　　7.1、輸入地址
• 　　7.2、瀏覽器查詢域名的IP
• 　　7.3、瀏覽器攜帶IP地址向Web伺服器發起HTTP請求
• 　　7.4、伺服器的永久重定向響應　
• 　　7.5、發出新的請求（重定向）
• 　　7.6、伺服器主機處理
• 　　7.7、Web應用伺服器處理http請求
• 　　7.8、瀏覽器處理並顯示html檔案
• 8、總結
• 9、參考文獻

回到頂部

1、簡介

　　1.1、HTTP協議是什麼？

　　即超文字傳輸協議（HTTP，HyperText Transfer Protocol)是網際網路上應用最為廣泛的一種網路協議，所有的WWW檔案都必須遵守這個標準。從網路參考模型來看，它是屬於應用層。它規定了計算機通訊網路中兩臺計算機之間進行通訊所必須共同遵守的規定或規則，它允許將超文字標記語言(HTML)文件從Web伺服器傳送到客戶端的瀏覽器。

　　簡單的來說，它就是基於應用層一個規範一個標準！通訊雙發都需要遵守這一準則，這就是http協議！

　　1.2、http簡史

　　設計HTTP最初的目的是為了提供一種釋出和接收HTML頁面的方法。1960年美國人Ted Nelson構思了一種通過計算機處理文字資訊的方法，並稱之為超文字（hypertext），這成為了HTTP超文字傳輸協議標準架構的發展根基。Ted Nelson組織協調全球資訊網協會（World Wide Web Consortium）和網際網路工程工作小組（Internet Engineering Task Force ）共同合作研究，最終釋出了一系列的RFC，其中著名的RFC 2616定義了HTTP 1.1，這也是我們現在最常用的版本，在此之前還存在HTTP 1.0版本以及HTTP 0.9版本

回到頂部

2、URI與URL

　　問：為什麼要區別URI與URL呢？

　　答：因為我看書看部落格資料都遇到過著兩個名詞，第一次遇到是在學習API的時候，那時候我是一臉懵逼，不是怎麼區分，感覺看過去都是一串網址呀！事實並非如此。

　　URI：統一資源標示符，只是標識資源在哪裡，這意味著存在多個URI可以指向該資源（例如：絕對與相對）【URI包含URL】

　　URI一般由三部分組成：
　　　　1. 訪問資源的命名機制。
　　　　2. 存放資源的主機名。
　　　　3. 資源自身的名稱，由路徑表示。

　　語法：[scheme:] scheme-specific-part

　　URI以scheme和冒號開頭。Scheme用大寫/小寫字母開頭，後面為空或者跟著更多的大寫/小寫字母、數字、加號、減號和點號。冒號把 scheme與scheme-specific-part分開了，並且scheme-specific-part的語法和語義（意思）由URI的名字空間決定。如下面的例子：
　　http://www.cnn.com，其中http是scheme，//www.cnn.com是 scheme-specific-part，並且它的scheme與scheme-specific-part被冒號分開了。

　　絕對與相對：

　　絕對的URI指以scheme（後面跟著冒號）開頭的URI。(例如：mailto:[email protected]、news:comp.lang.java.help和xyz: //whatever)；絕對的URI看作是以某種方式引用某種資源，而這種方式對識別符號出現的環境沒有依賴。

　　相對的URI不是以scheme（後面跟著冒號）開始的URI。(例如：articles/articles.html、img/aa.jpg)你可以把相對的URI看作是以某種方式引用某種資源，而這種方式依賴於識別符號出現的環境。（即你在html中引用圖片：./img/aa.jpg，那麼它依賴的就是http）

　　URL：統一資源定位符，是URI的子集；它除了標識資源的位置，還提供一種定位該資源的主要訪問機制(如其網路“位置”)。【即提供具體方式找到該資源（位置+方式）】

　　URL的格式由下列三部分組成：
　　　　1. 第一部分，是協議或稱為服務方式（指定低層使用的協議，例如：http, https, ftp)；
　　　　2. 第二部分，是存有該資源的主機IP地址（有時也包括埠號）；
　　 3. 第三部分，是主機資源的具體地址。如目錄和檔名等。

　　第一部分和第二部分之間用"：//"符號隔開，第二部分和第三部分用"/"符號隔開。第一部分和第二部分是不可缺少的，第三部分有時可以省略。

回到頂部

3、TCP握手連線以及斷開（擴充套件）

　　TCP通訊過程包括三個步驟：建立TCP連線通道，傳輸資料，斷開TCP連線通道。引用oneSong所畫的一張金典TCP通訊圖片

　　上圖中主要分為三部分：建立連線、傳輸資料、斷開連線。

　　建立連線：

　　三次握手即可建立TCP連線

　　1、第一次握手：客戶端傳送syn包(seq=x)到伺服器，並進入SYN_SEND狀態，等待伺服器確認；

　　2、第二次握手：伺服器收到syn包，必須確認客戶的SYN(ack=x+1)，同時自己也傳送一個SYN包(seq=y)，即SYN+ACK包，此時伺服器進入SYN_RECV狀態；

　　3、第三次握手：客戶端收到伺服器的SYN+ACK包，向伺服器傳送確認包ACK(ack=y+1)，此包傳送完畢，客戶端和伺服器進入ESTABLISHED狀態，完成三次握手。

　　握手過程中傳送的包裡不包含資料，三次握手完畢後，客戶端與伺服器才正式開始傳送資料。理想狀態下，TCP連線一旦建立，在通訊雙方中的任何一方主動關閉連線之前，TCP 連線都將被一直保持下去。

　　為什麼需要三次握手呢？

　　相互確認！（網上有很多解釋，這裡就不多講了）

　　資料傳輸：

　　建立好連線後，開始傳輸資料。TCP資料傳輸牽涉到的概念很多：超時重傳、快速重傳、流量控制、擁塞控制等等。（這一切都是為了提供可靠的位元組流服務）

　　斷開連線：

　　四次握手即可斷開TCP連線

　　1、第一次握手：主動關閉方傳送一個FIN，用來關閉主動方到被動關閉方的資料傳送，也就是主動關閉方告訴被動關閉方：我已經不會再給你發資料了(當然，在fin包之前傳送出去的資料，如果沒有收到對應的ack確認報文，主動關閉方依然會重發這些資料)，但此時主動關閉方還可以接受資料。

　　2、第二次握手：被動關閉方收到FIN包後，傳送一個ACK給對方，確認序號為收到序號+1(與SYN相同，一個FIN佔用一個序號)。

　　3、第三次握手：被動關閉方傳送一個FIN，用來關閉被動關閉方到主動關閉方的資料傳送，也就是告訴主動關閉方，我的資料也傳送完了，不會再給你發資料了。

　　4、第四次握手：主動關閉方收到FIN後，傳送一個ACK給被動關閉方，確認序號為收到序號+1，至此，完成四次揮手。

　　白話文：

　　1、第一次握手，瀏覽器對伺服器說：“煞筆，我不再給你發資料啦，但可以接受資料。”

　　2、第二次握手，伺服器對瀏覽器說：“騷貨，我知道啦！”

　　3、第三次握手，伺服器對瀏覽器說：“騷貨，我也不再給你發資料啦！”

　　4、第四次握手，瀏覽器對伺服器說：“煞筆，我知道啦！”

回到頂部

4、特點

HTTP協議永遠都是客戶端發起請求，伺服器回送響應。這樣就限制了使用HTTP協議，無法實現在客戶端沒有發起請求的時候，伺服器將訊息推送給客戶端。、

主要特點：

　　1、支援客戶/伺服器模式。一旦建立了運輸連線（這常常稱為建立了會話），瀏覽器端就向全球資訊網伺服器端傳送HTTP請求，伺服器收到請求後給出HTTP響應。
　　2、簡單快速：客戶向伺服器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與伺服器聯絡的型別不同。由於HTTP協議簡單，使得HTTP伺服器的程式規模小，因而通訊速度很快。
　　3、靈活：HTTP允許傳輸任意型別的資料物件。正在傳輸的型別由Content-Type加以標記。
　　4、HTTP 0.9和1.0使用非持續連線：限制每次連線只處理一個請求，伺服器處理完客戶的請求，並收到客戶的應答後，即斷開連線。HTTP 1.1使用持續連線：不必為每個web物件建立一個新的連線，一個連線可以傳送多個物件，採用這種方式可以節省傳輸時間。
　　5、無狀態：HTTP協議是無狀態協議。即每一個HTTP請求都是獨立的。全球資訊網伺服器不儲存過去的請求和過去的會話記錄。這就是說，同一個使用者再次訪問同一個伺服器時，只要伺服器沒有進行內容的更新，伺服器的響應就給出和以前被訪問時相同的響應。伺服器不記錄曾經訪問過的使用者，也不記錄某個使用者訪問過多少次。

回到頂部

5、HTTP請求

回到頂部

　　5.1、Request 訊息的結構

　　請求訊息的結構由三部分組成，請求行、請求頭、請求主體（即：請求行、訊息報頭、請求正文。）

【請 求 行】請求方法空格請求資源地址(URI、無域名)空格HTTP版本空格 CRLF(換行符)

【請 求 頭】標識:內容 CRLF(換行符)

【空 一 行】（表示請求頭結束）

【請求主體】（即請求正文，使用者的主要資料。POST方式時使用，GET無請求主體）

　　在HTTP/1.1協議中，所有的請求頭，除Host外，都是可選的。　　

　　例：

GET /phpstudy2015-6/ HTTP/1.1
Host: www.cnblogs.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
If-Modified-Since: Sat, 06 May 2017 12:05:41 GMT

回到頂部

　　5.2、請求方法

　　HTTP/1.1協議中共定義了八種方法（有時也叫“動作”）來表明Request-URI指定的資源的不同操作方式，最基本的有4種，分別是GET,POST,PUT,DELETE。一個URL地址用於描述一個網路上的資源，而HTTP中的GET, POST, PUT, DELETE就對應著對這個資源的查，改，增，刪4個操作。 我們最常見的就是GET和POST了。GET一般用於獲取/查詢資源資訊，而POST一般用於更新資源資訊。

　　【我們在瀏覽器位址列直接輸入地址的時候，採用的就是GET方法】

各方法如下：

　　1、GET：向特定的資源發出請求

　　2、POST：向指定資源提交資料進行處理請求（例如提交表單或者上傳檔案）。資料被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。

　　3、PUT：向指定資源位置上傳其最新內容。

　　4、DELETE：請求伺服器刪除Request-URI所標識的資源。

　　5、HEAD：向伺服器索要與GET請求相一致的響應，只不過響應體將不會被返回。這一方法可以在不必傳輸整個響應內容的情況下，就可以獲取包含在響應訊息頭中的元資訊。該方法常用於測試超連結的有效性，是否可以訪問，以及最近是否更新。

　　6、TRACE：請求伺服器會送收到的請求資訊，主要用於測試或診斷。

　　7、OPTIONS：請求查詢伺服器的效能，或者查詢與資源相關的選項和需求

　　8、CONNECT：HTTP/1.1協議中預留給能夠將連線改為管道方式的代理伺服器。（即留為將來使用）

　　【注意：請求方法區分大小寫；所示請求方法應為大寫】

GET與POST的區別：

　　1、GET提交的資料會放在URL之後，以?分割URL和傳輸資料，引數之間以&相連，如EditPosts.aspx?postid=6810130&update=1；POST方法是把提交的資料放在HTTP包的Body中。

　　2、GET提交的資料大小有限制（因為瀏覽器對URL的長度有限制），而POST方法提交的資料沒有限制。

　　3、GET方式需要使用Request.QueryString來取得變數的值，而POST方式通過Request.Form來獲取變數的值。

　　4、GET方式提交資料，會帶來安全問題，比如一個登入頁面，通過GET方式提交資料時，使用者名稱和密碼將出現在URL上，如果頁面可以被快取或者其他人可以訪問這臺機器，就可以從歷史記錄獲得該使用者的賬號和密碼。

回到頂部

　　5.3、http的無狀態以及建立連線方式

　　無狀態：

　　http協議為了保證伺服器的記憶體，不會維持客戶端發過來的請求，即同一個客戶端的這次請求和上次請求是沒有對應關係，對http伺服器來說，它並不知道這兩個請求來自同一個客戶端。例如：一個瀏覽器在短短几秒之內兩次訪問同一物件時，伺服器程序不會因為已經給它發過應答報文而不接受第二期服務請求。

　　為了解決這個問題， Web程式引入了Cookie機制來維護狀態。

　　建立連線方式：

　　HTTP中支援兩種連線方式：非持久連線和持久連線(HTTP1.1預設的連線方式為持久連線)。

　　1、非持久連線方式（採用訪問例子來說明）

　　讓我們檢視一下非持久連線情況下從伺服器到客戶傳送一個Web頁面的步驟。假設該貝面由1個基本HTML檔案和10個JPEG影象構成，而且所有這些物件都存放在同一臺伺服器主機中。再假設該基本HTML檔案的URL為：cnblogs.com/phpstudy2015-6/index.html。

　　下面是具體步騾：

　　1. HTTP客戶初始化一個與伺服器主機cnblogs.com中的HTTP伺服器的TCP連線。HTTP伺服器使用預設埠號80監聽來自HTTP客戶的連線建立請求。

　　2. HTTP客戶經由與TCP連線相關聯的本地套接字發出—個HTTP請求訊息。這個訊息中包含路徑名/somepath/index.html。

　　3. HTTP伺服器經由與TCP連線相關聯的本地套接字接收這個請求訊息，再從伺服器主機的記憶體或硬碟中取出物件/somepath/index.html，經由同一個套接字發出包含該物件的響應訊息。

　　4. HTTP伺服器告知TCP關閉這個TCP連線(不過TCP要到客戶收到剛才這個響應訊息之後才會真正終止這個連線)。

　　5. HTTP客戶經由同一個套接字接收這個響應訊息。TCP連線隨後終止。該訊息標明所封裝的物件是一個HTML檔案。客戶從中取出這個檔案，加以分析後發現其中有10個JPEG物件的引用。

　　6.給每一個引用到的JPEG物件重複步騾1-4。

　　上述步驟之所以稱為使用非持久連線，原因是每次伺服器發出一個物件後，相應的TCP連線就被關閉，也就是說每個連線都沒有持續到可用於傳送其他物件。每個TCP連線只用於傳輸一個請求訊息和一個響應訊息。就上述例子而言，使用者每請求一次那個web頁面，就產生11個TCP連線。

　　2、持久連線

　　非持久連線有一個很大的缺點就是，每一個http請求都需要建立一個TCP連線，就上面的例子而言，get一個html頁面就要建立十一次TCP連線，這是嚴重浪費資源行為！

　　首先，客戶得為每個待請求的物件建立並維護一個新的連線。對於每個這樣的連線，TCP得在客戶端和伺服器端分配TCP緩衝區，並維持TCP變數。對於有可能同時為來自數百個不同客戶的請求提供服務的web伺服器來說，這會嚴重增加其負擔。其次，如前所述，每個物件都有2個RTT的響應延長——一個RTT用於建立TCP連線，另—個RTT用於請求和接收物件。最後，每個物件都遭受TCP緩啟動，因為每個TCP連線都起始於緩啟動階段。不過並行TCP連線的使用能夠部分減輕RTT延遲和緩啟動延遲的影響。

【RTT(Round-Trip Time): 往返時延。在計算機網路中它是一個重要的效能指標，表示從傳送端傳送資料開始，到傳送端收到來自接收端的確認（接收端收到資料後便立即傳送確認），總共經歷的時延。】

　　持久連線就能夠很好解決這一缺點，在持久連線情況下，伺服器在發出響應後讓TCP連線繼續開啟著。同一對客戶/伺服器之間的後續請求和響應可以通過這個連線傳送。整個Web頁面(上例中為包含一個基本HTMLL檔案和10個影象的頁面)自不用說可以通過單個持久TCP連線傳送:甚至存放在同一個伺服器中的多個web頁面也可以通過單個持久TCP連線傳送。

　　通常，HTTP伺服器在某個連線閒置一段特定時間後關閉它，而這段時間通常是可以配置的。

　　持久連線分為不帶流水線(without pipelining)和帶流水線(with pipelining)兩個版本。

　　不帶流水線的版本：

　　客戶只在收到前一個請求的響應後才發出新的請求。這種情況下，web頁面所引用的每個物件(上例中的10個影象)都經歷1個RTT的延遲，用於請求和接收該物件。與非持久連線2個RTT的延遲相比，不帶流水線的持久連線已有所改善，不過帶流水線的持久連線還能進一步降低響應延遲。不帶流水線版本的另一個缺點是，伺服器送出一個物件後開始等待下一個請求，而這個新請求卻不能馬上到達。這段時間伺服器資源便閒置了。

　　帶流水線的持久連線：

　　HTTP/1.1的預設模式使用帶流水線的持久連線。這種情況下，HTTP客戶每碰到一個引用就立即發出一個請求，因而HTTP客戶可以一個接一個緊挨著發出各個引用物件的請求。伺服器收到這些請求後，也可以一個接一個緊挨著發出各個物件。如果所有的請求和響應都是緊挨著傳送的，那麼所有引用到的物件一共只經歷1個RTT的延遲(而不是像不帶流水線的版本那樣，每個引用到的物件都各有1個RTT的延遲)。另外，帶流水線的持久連線中伺服器空等請求的時間比較少。與非持久連線相比，持久連線(不論是否帶流水線)除降低了1個RTT的響應延遲外，緩啟動延遲也比較小。其原因在於既然各個物件使用同一個TCP連線，伺服器發出第一個物件後就不必再以一開始的緩慢速率傳送後續物件。相反，伺服器可以按照第一個物件傳送完畢時的速率開始傳送下一個物件。

回到頂部

　　5.4、請求行

　　正如上面所講的，請求行以一個方法符號開頭，空格之後，一個請求URI，再空格，然後一個HTTP版本，最後一個回車換行。

　　它的作用是用來說明當前請求的最基本資訊。

回到頂部

　　5.5、請求頭

　　（注：在HTTP/1.1 協議中，所有的請求頭，除Host外，都是可選的）

　　#請求頭的書寫形式為：Host:coblogs.com \r\n【識別符號:內容 換行】

　　常見的請求頭：

　　1、Host：（傳送請求時，該頭域是必需的）主要用於指定被請求資源的Internet主機和埠號，它通常從HTTP URL中提取出來的。HTTP/1.1請求必須包含主機頭域，否則系統會以400狀態碼返回。
　　例如: 我們在瀏覽器中輸入：http://www.guet.edu.cn/index.html，瀏覽器傳送的請求訊息中，就會包含Host請求頭域：Host：http://www.guet.edu.cn，此處使用預設埠號80，若指定了埠號，則變成：Host：指定埠號。

　　2、User-Agent：告訴HTTP伺服器，客戶端使用的作業系統和瀏覽器的名稱和版本。
　　例如： User-Agent:Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0

　　3、Content-Type：例如：Content-Type: application/x-www-form-urlencoded

　　4、Accept-Language：瀏覽器申明自己接收的語言。語言跟字符集的區別：中文是語言，中文有多種字符集，比如big5，gb2312，gbk等等；例如：Accept-Language: en-us。如果請求訊息中沒有設定這個報頭域，伺服器假定客戶端對各種語言都可以接受。

　　5、Accept：text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

　　6、Accept-Encoding：瀏覽器申明自己可接收的編碼方法，通常指定壓縮方法，是否支援壓縮，支援什麼壓縮方法（gzip，deflate）;Servlet能夠向支援gzip的瀏覽器返回經gzip編碼的HTML頁面。許多情形下這可以減少5到10倍的下載時間。

　　例如： Accept-Encoding: gzip, deflate。如果請求訊息中沒有設定這個域，伺服器假定客戶端對各種內容編碼都可以接受。

　　7、Cookie：最重要的請求頭之一, 將cookie的值傳送給HTTP伺服器。

　　8、Connection：HTTP 1.1預設進行持久連線keep-alive。
　　例如：Connection: keep-alive 當一個網頁開啟完成後，客戶端和伺服器之間用於傳輸HTTP資料的TCP連線不會關閉，如果客戶端再次訪問這個伺服器上的網頁，會繼續使用這一條已經建立的連線。

　　利用持久連線的優點，當頁面包含多個元素時（例如Applet，圖片），顯著地減少下載所需要的時間。要實現這一點，Servlet需要在應答中傳送一個Content-Length頭，最簡單的實現方法是：先把內容寫入ByteArrayOutputStream，然後在正式寫出內容之前計算它的大小。
　　Connection: close 代表一個Request完成後，客戶端和伺服器之間用於傳輸HTTP資料的TCP連線會關閉，當客戶端再次傳送Request，需要重新建立TCP連線。

　　9、Keep-Alive：30保持持久連線30s

　　10、If-Modified-Since：把瀏覽器端快取頁面的最後修改時間傳送到伺服器去，伺服器會把這個時間與伺服器上實際檔案的最後修改時間進行對比。如果時間一致，那麼返回304，客戶端就直接使用本地快取檔案。如果時間不一致，就會返回200和新的檔案內容。客戶端接到之後，會丟棄舊檔案，把新檔案快取起來，並顯示在瀏覽器中。

　　例如：If-Modified-Since:Sat, 06 May 2017 12:05:41 GMT

　　11、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"。

　　12、Pragma：指定“no-cache”值表示伺服器必須返回一個重新整理後的文件，即使它是代理伺服器而且已經有了頁面的本地拷貝；在HTTP/1.1版本中，它和Cache-Control:no-cache作用一模一樣。Pargma只有一個用法， 例如： Pragma: no-cache

　　13、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。

　　注意: 在HTTP/1.0版本中，只實現了Pragema:no-cache, 沒有實現Cache-Control

　　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訊息的值，那麼客戶機可以接收超出超時期指定值之內的響應訊息。

　　14、Accept-Charset：瀏覽器可接受的字符集。如果在請求訊息中沒有設定這個域，預設表示任何字符集都可以接受。

　　15、Referer：包含一個URL，使用者從該URL代表的頁面出發訪問當前請求的頁面。提供了Request的上下文資訊的伺服器，告訴伺服器我是從哪個連結過來的，比如從我主頁上鍊接到一個朋友那裡，他的伺服器就能夠從HTTP Referer中統計出每天有多少使用者點選我主頁上的連結訪問他的網站。

　　例如: Referer:http://translate.google.cn/?hl=zh-cn&tab=wT

　　16、Content-Length：表示請求訊息正文的長度。例如：Content-Length: 38。

　　17、From：請求傳送者的email地址，由一些特殊的Web客戶程式使用，瀏覽器不會用到它。

　　18、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）。

回到頂部

　　5.6、請求主體

　　請求的主要使用者資料，就是POST資料。

　　如果方式為POST，則需要請求主體部分；GET則沒有請求主體

　　資料形式：類似name=XXX&pwd=XXXX的內容

回到頂部

6、HTTP響應

回到頂部

　　6.1、Response 訊息的結構

　　響應訊息的結構由三部分組成，響應行、相應頭、相應主體（即：狀態行、訊息報頭、響應正文。）

【響 應 行】HTTP版本空格狀態碼空格狀態碼的文字描述空格 CRLF(換行符)

【響 應 頭】:內容 CRLF(換行符)

【空 一 行】（表示響應頭結束）

【響應主體】所謂響應主體，就是伺服器返回的資源的內容。即整個HTML檔案。

回到頂部

　　6.2、響應行

　　響應資料的第一行，響應結果的概述。

　　狀態碼：

　　狀態程式碼有3位數字組成，狀態描述給出了狀態程式碼簡短的描述。狀態碼第一個數字定義了響應的類別，有五種可能取值：
　　1xx　　：　　指示資訊--表示請求已接收，繼續處理
　　2xx　　：　　成功--表示請求已被成功接收、理解、接受
　　3xx　　：　　重定向--要完成請求必須進行更進一步的操作
　　4xx　　：　　客戶端錯誤--請求有語法錯誤或請求無法實現
　　5xx　　：　　伺服器端錯誤--伺服器未能實現合法的請求

　　所有狀態碼如下（已摺疊）：

View Code 回到頂部

　　6.3、響應頭

　　同理，請求頭！

　　HTTP常見的響應頭：

　　1、Date：表示訊息傳送的時間，時間的描述格式由rfc822定義。例如，Date:Sat, 06 May 2017 12:16:56 GMT。Date描述的時間表示世界標準時，換算成本地時間，需要知道使用者所在的時區。你可以用setDateHeader來設定這個頭以避免轉換時間格式的麻煩　　

　　2、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.)

　　3、Expires：指明應該在什麼時候認為文件已經過期，從而不再快取它，重新從伺服器獲取，會更新快取。過期之前使用本地快取。HTTP1.1的客戶端和快取會將非法的日期格式（包括0）看作已經過期。

　　eg：為了讓瀏覽器不要快取頁面，我們也可以將Expires實體報頭域，設定為0。
　　例如: Expires: Tue, 08 Feb 2022 11:35:14 GMT

　　4、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

　　5、Set-Cookie：非常重要的header, 用於把cookie傳送到客戶端瀏覽器，每一個寫入cookie都會生成一個Set-Cookie。
　　例如: Set-Cookie: sc=4c31523a; path=/; domain=.acookie.taobao.com

　　6、ETag：和If-None-Match 配合使用。

　　7、Last-Modified：用於指示資源的最後修改日期和時間。Last-Modified也可用setDateHeader方法來設定。

　　8、Content-Range：用於指定整個實體中的一部分的插入位置，他也指示了整個實體的長度。在伺服器向客戶返回一個部分響應，它必須描述響應覆蓋的範圍和整個實體長度。一般格式：Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-length。
　　例如，傳送頭500個位元組次欄位的形式：Content-Range:bytes0-499/1234如果一個http訊息包含此節（例如，對範圍請求的響 應或對一系列範圍的重疊請求），Content-Range表示傳送的範圍。

　　9、Content-Length：指明實體正文的長度，以位元組方式儲存的十進位制數字來表示。在資料下行的過程中，Content-Length的方式要預先在伺服器中快取所有資料，然後所有資料再一股腦兒地發給客戶端。只有當瀏覽器使用持久HTTP連線時才需要這個資料。如果你想要利用持久連線的優勢，可以把輸出文件寫入ByteArrayOutputStram，完成後檢視其大小，然後把該值放入Content-Length頭，最後通過byteArrayStream.writeTo(response.getOutputStream()傳送內容。

　　例如: Content-Length: 19847

　　10、Content-Encoding：WEB伺服器表明自己使用了什麼壓縮方法（gzip，deflate）壓縮響應中的物件。只有在解碼之後才可以得到Content-Type頭指定的內容型別。利用gzip壓縮文件能夠顯著地減少HTML文件的下載時間。Java的GZIPOutputStream可以很方便地進行gzip壓縮，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支援它。因此，Servlet應該通過檢視Accept-Encoding頭（即request.getHeader("Accept-Encoding")）檢查瀏覽器是否支援gzip，為支援gzip的瀏覽器返回經gzip壓縮的HTML頁面，為其他瀏覽器返回普通頁面。
　　例如：Content-Encoding：gzip

　　11、Content-Language：WEB伺服器告訴瀏覽器自己響應的物件所用的自然語言。

　　例如： Content-Language:da。沒有設定該域則認為實體內容將提供給所有的語言閱讀。

　　12、Server：指明HTTP伺服器用來處理請求的軟體資訊。例如：Server: Microsoft-IIS/7.5、Server：Apache-Coyote/1.1。此域能包含多個產品標識和註釋，產品標識一般按照重要性排序

　　13、X-AspNet-Version：如果網站是用ASP.NET開發的，這個header用來表示ASP.NET的版本。
　　例如: X-AspNet-Version: 4.0.30319

　　14、X-Powered-By：表示網站是用什麼技術開發的。
　　例如： X-Powered-By: ASP.NET

　　15、Connection：keep-alive /close
　　16、Location：用於重定向一個新的位置，包含新的URL地址。表示客戶應當到哪裡去提取文件。Location通常不是直接設定的，而是通過HttpServletResponse的sendRedirect方法，該方法同時設定狀態程式碼為302。Location響應報頭域常用在更換域名的時候。

　　17、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都支援它。

回到頂部

　　6.4、響應主體

　　就是伺服器返回的資源的內容。即整個HTML檔案

回到頂部

7、HTTP請求詳細過程

　　從前面講解中我們大概對HTTP有了一個基本的認識，那麼接下來我們就詳細研究瞭解HTTP請求的具體過程。

　　引用鹹魚老弟的部落格文章

回到頂部

　　7.1、輸入地址

　　當我們開始在瀏覽器中輸入網址的時候，瀏覽器其實就已經在智慧的匹配可能得 url 了，他會從歷史記錄，書籤等地方，找到已經輸入的字串可能對應的 url，然後給出智慧提示，讓你可以補全url地址。對於google的chrome 的瀏覽器，他甚至會直接從快取中把網頁展示出來，就是說，你還沒有按下 enter，頁面就出來了。

回到頂部

　　7.2、瀏覽器查詢域名的IP

　　1、請求一旦發起，瀏覽器首先要做的事情就是解析這個域名，一般來說，瀏覽器會首先檢視本地硬碟的 hosts 檔案，看看其中有沒有和這個域名對應的規則，如果有的話就直接使用 hosts 檔案裡面的 ip 地址。

2、如果在本地的 hosts 檔案沒有能夠找到對應的 ip 地址，瀏覽器會發出一個 DNS請求到本地DNS伺服器 。本地DNS伺服器一般都是你的網路接入伺服器商提供，比如中國電信，中國移動。

　 3、查詢你輸入的網址的DNS請求到達本地DNS伺服器之後，本地DNS伺服器會首先查詢它的快取記錄，如果快取中有此條記錄，就可以直接返回結果，此過程是遞迴的方式進行查詢。如果沒有，本地DNS伺服器還要向DNS根伺服器進行查詢。

　　4、根DNS伺服器沒有記錄具體的域名和IP地址的對應關係，而是告訴本地DNS伺服器，你可以到域伺服器上去繼續查詢，並給出域伺服器的地址。這種過程是迭代的過程。

　　5、本地DNS伺服器繼續向域伺服器發出請求，在這個例子中，請求的物件是.com域伺服器。.com域伺服器收到請求之後，也不會直接返回域名和IP地址的對應關係，而是告訴本地DNS伺服器，你的域名的解析伺服器的地址。

　　6、最後，本地DNS伺服器向域名的解析伺服器發出請求，這時就能收到一個域名和IP地址對應關係，本地DNS伺服器不僅要把IP地址返回給使用者電腦，還要把這個對應關係儲存在快取中，以備下次別的使用者查詢時，可以直接返回結果，加快網路訪問。

下面這張圖很完美的解釋了這一過程：

知識擴充套件：

1)什麼是DNS？

　　DNS（Domain Name System，域名系統），因特網上作為域名和IP地址相互對映的一個分散式資料庫，能夠使使用者更方便的訪問網際網路，而不用去記住能夠被機器直接讀取的IP數串。通過主機名，最終得到該主機名對應的IP地址的過程叫做域名解析（或主機名解析）。

　　通俗的講，我們更習慣於記住一個網站的名字，比如www.baidu.com,而不是記住它的ip地址，比如：167.23.10.2。而計算機更擅長記住網站的ip地址，而不是像www.baidu.com等連結。因為，DNS就相當於一個電話本，比如你要找www.baidu.com這個域名，那我翻一翻我的電話本，我就知道，哦，它的電話（ip）是167.23.10.2。

2)DNS查詢的兩種方式：遞迴查詢和迭代查詢

1、遞迴解析

當局部DNS伺服器自己不能回答客戶機的DNS查詢時，它就需要向其他DNS伺服器進行查詢。此時有兩種方式，如圖所示的是遞迴方式。區域性DNS伺服器自己負責向其他DNS伺服器進行查詢，一般是先向該域名的根域伺服器查詢，再由根域名伺服器一級級向下查詢。最後得到的查詢結果返回給區域性DNS伺服器，再由區域性DNS伺服器返回給客戶端。

　　簡單來講，就是參與此次尋找IP的所有伺服器，最後都能夠得到該域名對應的IP資訊（將資訊進行往返傳送！）

2、迭代解析

　　當局部DNS伺服器自己不能回答客戶機的DNS查詢時，也可以通過迭代查詢的方式進行解析，如圖所示。區域性DNS伺服器不是自己向其他DNS伺服器進行查詢，而是把能解析該域名的其他DNS伺服器的IP地址返回給客戶端DNS程式，客戶端DNS程式再繼續向這些DNS伺服器進行查詢，直到得到查詢結果為止。也就是說，迭代解析只是幫你找到相關的伺服器而已，而不會幫你去查。比如說：baidu.com的伺服器ip地址在192.168.4.5這裡，你自己去查吧，本人比較忙，只能幫你到這裡了。

　　簡單的來講，就是隻有最後一臺伺服器與最初的伺服器進行該域名/IP資訊的傳送！

3)DNS域名稱空間的組織方式

　　我們在前面有說到根DNS伺服器，域DNS伺服器，這些都是DNS域名稱空間的組織方式。按其功能名稱空間中用來描述 DNS 域名稱的五個類別的介紹詳見下表中，以及與每個名稱型別的示例

4)DNS負載均衡

　　當一個網站有足夠多的使用者的時候，假如每次請求的資源都位於同一臺機器上面，那麼這臺機器隨時可能會蹦掉。處理辦法就是用DNS負載均衡技術，它的原理是在DNS伺服器中為同一個主機名配置多個IP地址,在應答DNS查詢時,DNS伺服器對每個查詢將以DNS檔案中主機記錄的IP地址按順序返回不同的解析結果,將客戶端的訪問引導到不同的機器上去,使得不同的客戶端訪問不同的伺服器,從而達到負載均衡的目的｡例如可以根據每臺機器的負載量，該機器離使用者地理位置的距離等等。

回到頂部

　　7.3、瀏覽器攜帶IP地址向Web伺服器發起HTTP請求

　　拿到域名對應的IP地址之後，瀏覽器會以一個隨機埠（1024<埠<65535）向伺服器的WEB程式（常用的有httpd,nginx等）80埠發起TCP的連線請求。這個連線請求到達伺服器端後（這中間通過各種路由裝置，區域網內除外），進入到網絡卡，然後是進入到核心的TCP/IP協議棧（用於識別該連線請求，解封包，一層一層的剝開），還有可能要經過Netfilter防火牆（屬於核心的模組）的過濾，最終到達WEB程式，最終建立了TCP/IP的連線。

TCP連線參考上面

　　建立了TCP連線之後，發起一個http請求。一個典型的 http request header 一般需要包括請求的方法，例如 GET 或者 POST 等，不常用的還有 PUT 和 DELETE 、HEAD、OPTION以及 TRACE 方法，一般的瀏覽器只能發起 GET 或者 POST 請求。

回到頂部

　　7.4、伺服器的永久重定向響應　

　　伺服器給瀏覽器響應一個301永久重定向響應，這樣瀏覽器就會訪問“http://www.google.com/” 而非“http://google.com/”。

　　為什麼伺服器一定要重定向而不是直接傳送使用者想看的網頁內容呢？其中一個原因跟搜尋引擎排名有關。如果一個頁面有兩個地址，就像http://www.yy.com/和http://yy.com/，搜尋引擎會認為它們是兩個網站，結果造成每個搜尋連結都減少從而降低排名。而搜尋引擎知道301永久重定向是什麼意思，這樣就會把訪問帶www的和不帶www的地址歸到同一個網站排名下。還有就是用不同的地址會造成快取友好性變差，當一個頁面有好幾個名字時，它可能會在快取裡出現好幾次。

擴充套件知識

1）301和302的區別。

　　301和302狀態碼都表示重定向，就是說瀏覽器在拿到伺服器返回的這個狀態碼後會自動跳轉到一個新的URL地址，這個地址可以從響應的Location首部中獲取（使用者看到的效果就是他輸入的地址A瞬間變成了另一個地址B）——這是它們的共同點。

　　他們的不同在於。301表示舊地址A的資源已經被永久地移除了（這個資源不可訪問了），搜尋引擎在抓取新內容的同時也將舊的網址交換為重定向之後的網址；

　　302表示舊地址A的資源還在（仍然可以訪問），這個重定向只是臨時地從舊地址A跳轉到地址B，搜尋引擎會抓取新的內容而儲存舊的網址。SEO302好於301

2）重定向原因：

（1）網站調整（如改變網頁目錄結構）； （2）網頁被移到一個新地址； （3）網頁副檔名改變(如應用需要把.php改成.Html或.shtml)。 這種情況下，如果不做重定向，則使用者收藏夾或搜尋引擎資料庫中舊地址只能讓訪問客戶得到一個404頁面錯誤資訊，訪問流量白白喪失；再者某些註冊了多個域名的網站，也需要通過重定向讓訪問這些域名的使用者自動跳轉到主站點等。

3）什麼時候進行301或者302跳轉呢？

當一個網站或者網頁24—48小時內臨時移動到一個新的位置，這時候就要進行302跳轉，而使用301跳轉的場景就是之前的網站因為某種原因需要移除掉，然後要到新的地址訪問，是永久性的。 清晰明確而言：使用301跳轉的大概場景如下： 1、域名到期不想續費（或者發現了更適合網站的域名），想換個域名。 2、在搜尋引擎的搜尋結果中出現了不帶www的域名，而帶www的域名卻沒有收錄，這個時候可以用301重定向來告訴搜尋引擎我們目標的域名是哪一個。 3、空間伺服器不穩定，換空間的時候。 回到頂部

　　7.5、發出新的請求（重定向）

　　現在瀏覽器知道了 "http://www.google.com/"才是要訪問的正確地址，所以它會發送另一個http請求。重複上面的http請求步驟

回到頂部

　　7.6、伺服器主機處理

　　經過前面的重重步驟，我們終於將我們的http請求傳送到了伺服器這裡，其實前面的重定向已經是到達伺服器了，那麼，伺服器是如何處理我們的請求的呢？

　　後端從在固定的埠接收到TCP報文開始，它會對TCP連線進行處理，對HTTP協議進行解析，並按照報文格式進一步封裝成HTTP Request物件，供上層使用。

　　【一些大一點的網站會將你的請求到反向代理伺服器中，因為當網站訪問量非常大，網站越來越慢，一臺伺服器已經不夠用了。於是將同一個應用部署在多臺伺服器上，將大量使用者的請求分配給多臺機器處理。此時，客戶端不是直接通過HTTP協議訪問某網站應用伺服器，而是先請求到Nginx，Nginx再請求應用伺服器，然後將結果返回給客戶端，這裡Nginx的作用是反向代理伺服器。同時也帶來了一個好處，其中一臺伺服器萬一掛了，只要還有其他伺服器正常執行，就不會影響使用者使用。】

回到頂部

　　7.7、Web應用伺服器處理http請求

　　【假設伺服器端使用nginx+php(fastcgi)架構提供服務】

　　假設我此時輸入的URL為http://www.mecnblogs.com/

　　① nginx讀取配置檔案，並尋找檔案

　　當伺服器主機將瀏覽器傳送過來的所有資料通過各個網路層的相應協議的規定進行了解密以及封裝，最後將資料包送達應用層使用。（可參考TCP/IP網路模型）

　　當Nginx在收到瀏覽器 GET / 請求時，會讀取http請求裡面的頭部資訊，根據Host來匹配 自己的所有的虛擬主機的配置檔案的server_name,看看有沒有匹配的，有匹配那麼就讀取該虛擬主機的配置，發現如下配置：

root /web/echo

　　通過這個就知道所有網頁檔案的就在這個目錄下 這個目錄就是/ 當我們http://www.mecnblogs.com/時就是訪問這個目錄下面的檔案，例如訪問http://www.mecnblogs.com/index.html,那麼代表/web/echo下面有個檔案叫index.html

index index.html index.htm index.php

　　通過這個就能得知網站的首頁檔案是那個檔案，也就是我們在入http://www.mecnblogs.com/ ，nginx就會自動幫我們把index.html（假設首頁是index.php 當然是會嘗試的去找到該檔案，如果沒有找到該檔案就依次往下找，如果這3個檔案都沒有找到，那麼就丟擲一個404錯誤）加到後面，那麼新增之後的URL是/index.php，然後根據後面的配置進行處理

location ~ .*\.php(\/.*)*$ {
   root /web/echo;
   fastcgi_pass   127.0.0.1:9000;
   fastcgi_index  index.php;
   astcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
   include        fastcgi_params;
}

　　這一段配置指明凡是請求的URL中匹配（這裡是啟用了正則表示式進行匹配） *.php字尾的（後面跟的引數）都交給後端的fastcgi程序進行處理。

　　② 把php檔案交給fastcgi程序去處理

　　於是nginx把/index.php這個URL交給了後端的fastcgi程序處理，等待fastcgi處理完成後（結合資料庫查詢出資料，填充模板生成html檔案）返回給nginx一個index.html文件，Nginx再把這個index.html返回給瀏覽器（通過HTTP協議返回，即HTTP響應【響應訊息結構可以參考上面】），於是乎瀏覽器就拿到了首頁的html程式碼，同時nginx寫一條訪問日誌到日誌檔案中去。

【擴充套件：】

nginx是怎麼找index.php檔案的？

　　當nginx發現需要/web/echo/index.php檔案時，就會向核心發起IO系統呼叫(因為要跟硬體打交道，這裡的硬體是指硬碟，通常需要靠核心來操作，而核心提供的這些功能是通過系統呼叫來實現的)，告訴核心，我需要這個檔案,核心從/開始找到web目錄，再在web目錄下找到echo目錄，最後在echo目錄下找到index.php檔案，於是把這個index.php從硬碟上讀取到核心自身的記憶體空間，然後再把這個檔案複製到nginx程序所在的記憶體空間，於是乎nginx就得到了自己想要的檔案了。

尋找檔案在檔案系統層面是怎麼操作的？

　　比如nginx需要得到/web/echo/index.php這個檔案

　　每個分割槽（像ext3 ext3等檔案系統，block塊是檔案儲存的最小單元 預設是4096位元組）都是包含元資料區和資料區，每一個檔案在元資料區都有元資料條目（一般是128位元組大小），每一個條目都有一個編號，我們稱之為inode（index node 索引節點），這個inode裡面包含 檔案型別、許可權、連線次數、屬主和陣列的ID、時間戳、這個檔案佔據了那些磁碟塊也就是塊的編號（block，每個檔案可以佔用多個block,並且block不一定是連續的，每個block是有編號的），如下圖所示：

　　還有一個要點：目錄其實也普通是檔案，也需要佔用磁碟塊，目錄不是一個容器。你看預設建立的目錄就是4096位元組，也就說只需要佔用一個磁碟塊，但這是不確定的。所以要找到目錄也是需要到元資料區裡面找到對應的條目，只有找到對應的inode就可找到目錄所佔用的磁碟塊。

那到底目錄裡面存放著什麼，難道不是檔案或者其他目錄嗎？

　　其實目錄存著這麼一張表（姑且這麼理解），裡面放著 目錄或者檔案的名稱和對應的inode號（暫時稱之為對映表）,如下圖：

假設

/ 在資料區佔據 1、2號block ，/其實也是一個目錄 裡面有3個目錄 web 111

web 佔據 5號block 是目錄 裡面有2個目錄 echo data

echo 佔據 11號 block 是目錄 裡面有1個檔案 index.php

index.php 佔據 15 16號 block 是檔案

其在檔案系統中分佈如下圖所示：

那麼核心究竟是怎麼找到index.php這個檔案的呢？

　　核心拿到nginx的IO系統呼叫要獲取/web/echo/index.php這個檔案請求之後

　　① 核心讀取元資料區 / 的inode，從inode裡面讀取/所對應的資料塊的編號，然後在資料區找到其對應的塊（1 2號塊），讀取1號塊上的對映表找到web這個名稱在元資料區對應的inode號

　　② 核心讀取web對應的inode（3號），從中得知web在資料區對應的塊是5號塊，於是到資料區找到5號塊，從中讀取對映表，知道echo對應的inode是5號，於是到元資料區找到5號inode

　　③ 核心讀取5號inode，得到echo在資料區對應的是11號塊，於是到資料區讀取11號塊得到對映表，得到index.php對應的inode是9號

　　④ 核心到元資料區讀取9號inode，得到index.php對應的是15和16號資料塊，於是就到資料區域找到15 16號塊，讀取其中的內容，得到index.php的完整內容

回到頂部

　　7.8、瀏覽器處理並顯示html檔案

　　在瀏覽器沒有完整接受全部HTML文件時，它就已經開始顯示這個頁面了，瀏覽器是如何把頁面呈現在螢幕上的呢？不同瀏覽器可能解析的過程不太一樣，這裡我們只介紹webkit的渲染過程，下圖對應的就是WebKit渲染的過程，這個過程包括：

　　解析html以構建dom樹 -> 構建render樹 -> 佈局render樹 -> 繪製render樹

　　在瀏覽器顯示的時候，當遇到要獲取外圖片，CSS，JS檔案等等時，瀏覽器將會發起不斷髮起非同步的http請求來獲取這些資源。

回到頂部

8、總結

　　站在巨人的肩膀上來學習確實能夠讓自己的眼界更加開闊，同時深入學習與鞏固HTTP這方面的知識，能夠讓自己深入瞭解Web的B/S結構、Web通訊的具體過程，有助於自己日後的Web開發。同時也為接下來的面試做準備。在此當然是要感謝各位前輩大牛啦。

回到頂部

9、參考文獻

1. 《圖解TCP-IP協議》

2. 《一次完整的HTTP事務是怎樣一個過程？》

3. 《【原】老生常談-從輸入url到頁面展示到底發生了什麼》

4. 《淺析HTTP協議》

5. 《HTTP協議詳解》

（以上是自己的一些見解，若有不足或者錯誤的地方請各位指出）

作者：那一葉隨風 http://www.cnblogs.com/phpstudy2015-6/

原文地址：http://www.cnblogs.com/phpstudy2015-6/p/6810130.html

宣告：只代表本人在工作學習中某一時間內總結的觀點或結論。轉載時請在文章頁面明顯位置給出原文連結

1|0　　http狀態碼基本上可以分為5類：

1|1　　1xx為訊息類，該類狀態碼用於表示伺服器臨時迴應。

　　　　100 continue 表示出的請求已經被伺服器接收，遊覽器應當繼續傳送請求的其餘部分（HTTP1.1）

　　　　101 switching pototcols 伺服器將遵從客戶的請求轉換到另外一種協議（HTTP1.1）。

1|2　　2xx 表示瀏覽器端請求被處理成功

　　　　200 ok 一切正常

　　　　201 created 伺服器已經建立了文件，location 頭給出了他的URL。

　　　　202 accepted 已經接收請求，但是尚未處理完成。

　　　　203 non-authoritative information 文件已經正常的返回，但一些應答頭可能不正確，因為使用的是的文件的拷貝(HTTP 1.1新)。

　　　　204 no content 沒有新文件，遊覽器應該繼續顯示原來的文件，這個跟下面的304非常相似。

　　　　205 Reset content 沒有新的內容，到那時遊覽器應該重置它所顯示的內容，用來強制清楚表單輸入內容（HTTP1.1 新）

　　　　206 partial content 客戶傳送了一個帶有range頭的GET請求，伺服器完成了它（HTTP1.1 新）。注意 通過Range 可以實現斷點續傳。

1|3　　3xx 重定向。

　　　　300 Multiple choices 客戶請求的文件可以在多個位置找到，這些位置已經在返回的文件內列出，如果伺服器要提出優先選擇，則應該在location 應答頭指明。

　　　　301 Mulitiple permanently 客戶請求的文件在其他地方，新的url在location 頭中給出，瀏覽器應該自動的訪問新的URL。

　　　　302 Found 類似301，但新的URL應該被視為臨時性的替代，而不是永久性的，注意，在HTTP1.0中對應的狀態資訊moved Temporatily。出現該狀態碼，瀏覽器能夠給自動訪問新的URL，因此他是一個很有用的狀態程式碼。

　　　　注意這個狀態程式碼有時候可以和301替換使用，例如，如果瀏覽器錯誤的請求http：// host/~user（缺少了後面的斜槓，有的伺服器返回301，有的返回302）。嚴格的說，我們只能假定原來的請求是GET時瀏覽器才會自動重定向。

　　　　303 see other 類似於301/302，不同之處在於，如果原來的請求是post，location頭指定的重定向目標文件應該通過get提取（http 1.1 新）。

　　　　304 not modified 客戶端有緩衝的文件併發出了一個條件性的請求（一般是提供if -modified -since 頭表示客戶端執行比指定日期更新的文件）。伺服器告訴客戶，原來緩衝的文件還可以繼續使用。

　　　　305 use proxy 客戶請求的文件應該通過location 頭所指明的代理伺服器提取（HTTP 1.1新）。

　　　　307 temporary redirect 和302（found）相同，許多瀏覽器會錯誤的相應302應該進行重定向，即使原來的請求是post，即使它實際上只在post請求的應答是303時，才能重定向。由於這個原因，HTTP1.1新增了307，以便更加清楚的區分幾個狀態程式碼，當出現303應答時，瀏覽器可以跟隨重定向的get和post請求，如是307應答，則瀏覽器只能跟隨對get的請求的重定向。

1|4　　400 錯誤

　　　　400 Bad Request 請求出現語法錯誤。

　　　　401 unauthorized 客戶試圖未經授權訪問受密碼保護的頁面。應答中會包含-WWW-Authenticate頭，瀏覽器據此顯示使用者名稱字和密碼對話方塊，然後再填寫合適的authorization頭後再次傳送請求。

　　　　403 Forbidden 資源不可用。伺服器理解客戶的需求，但是拒絕處理他通常由於伺服器上檔案或目錄的許可權設定問題。

　　　　404 NO Found 無法找到指定位置的資源，也是一個常用的應答。

　　　　405 Method not allowed 請求方法（GET、POST、HEAD、Delete、put、trace等）對指定的資源不適用。（HTTP 1.1新）

　　　　406 not acceptable 指定的資源已經找到，但是mime型別和客戶在accpet頭中所指定的不相容（HTTP 1.1新）

　　　　407 proxy authentication reqired 類似於401 ，表示客戶必須先經過代理伺服器的授權。（HTTP 1.1新）

　　　　408 request timeout 在伺服器許可的等待時間內，客戶一直沒有發出任何請求。客戶可以在以後重複同一請求。（HTTP 1.1新）

　　　　409 conflict 通常和put 請求有關，由於請求和資源的當前狀態相沖突，因此請求不能成功（HTTP 1.1新）

　　　　410 Gone 所請求的文件已經不在可用，而且伺服器不知道應該重新到哪一個地址，他和404的不同在於，返回407表示文件永久的離開了指定的位置，而404表示由於位置的原因文件不可用。（HTTP 1.1新）

　　　　411 length required 伺服器不能處理請求，除非客戶傳送一個contene-length頭（HTTP 1.1新）

　　　　412 preconfition Failed請求頭中指定的一些前提條件失敗（HTTP 1.1新）

　　　　413 request entity too large 目標文件的大小超過伺服器當前原意處理的大小。如果伺服器認為自己能夠稍後再處理請求，則應該提供一個retry-After頭（HTTP 1.1新）

　　　　414 Request URL Too loog URL太長（ HTTP 1.1新）

　　　　416 required range not satisfiable 伺服器不能滿足客戶在請求中的指定range 頭（HTTP 1.1新）

1|5　　5xx伺服器錯誤

　　　　500 internal Server Error 伺服器遇到了意料不到的情況，不能完成客戶的請求

　　　　501 Not lmplemented 伺服器不支援請求所需要的功能。例如，客戶發出來了一個伺服器不支援的put請求。

　　　　502Bad Gateway 伺服器作為閘道器或者代理時，為了完成請求訪問下一個伺服器，但該伺服器返回了非法的應答。

　　　　503 service unavilable 伺服器由於維護或者負載過重未能應答。例如，servlet 可能在資料庫連線池已滿的情況下返回503.伺服器返回503時可以提供一個retry-after頭。

　　　　504 gateway timeout 作為代理或閘道器伺服器使用，表示不能及時的從遠端伺服器獲得應答（HTTP 1.1新）

　　　　505 HTTPversion not supported 伺服器不支援請求中所指明的HTTP版本。（HTTP 1.1新）