一次完整的HTTP事務是怎樣一個過程？(轉)

標籤：

（轉自http://www.linux178.com/web/httprequest.html）
寫的太好了，轉一個。

關於HTTP協議可以參考以下：

HTTP協議漫談  http://kb.cnblogs.com/page/140611/HTTP協議概覽  http://www.cnblogs.com/vamei/archive/2013/05/11/3069788.html瞭解HTTP Headers的方方面面  http://kb.cnblogs.com/page/55442/

當我們在瀏覽器的地址欄輸入 www.linux178.com ，然後斷行符號，斷行符號這一瞬間到看到頁面到底發生了什麼呢？

網域名稱解析 --> 發起TCP的3次握手 --> 建立TCP串連後發起http請求 --> 伺服器響應http請求，瀏覽器得到html代碼 --> 瀏覽器解析html代碼，並請求html代碼中的資源（如js、css、圖片等） --> 瀏覽器對頁面進行渲染呈現給使用者

以下就是上面過程的一一分析，我們就以Chrome瀏覽器為例：

一.網域名稱解析

首先Chrome瀏覽器會解析 www.linux178.com 這個網域名稱（準確的叫法應該是主機名稱）對應的IP地址。怎麼解析到對應的IP地址？

1 Chrome瀏覽器 會首先搜尋瀏覽器自身的DNS緩衝（緩衝時間比較短，大概只有1分鐘，且只能容納1000條緩衝），看自身的緩衝中是否有www.linux178.com 對應的條目，而且沒有到期，如果有且沒有到期則解析到此結束。     註：我們怎麼查看Chrome自身的緩衝？可以使用 chrome://net-internals/#dns 來進行查看2 如果瀏覽器自身的緩衝裡面沒有找到對應的條目，那麼Chrome會搜尋作業系統自身的DNS緩衝,如果找到且沒有到期則停止搜尋解析到此結束.      註：怎麼查看作業系統自身的DNS緩衝，以Windows系統為例，可以在命令列下使用 ipconfig /displaydns 來進行查看  3 如果在Windows系統的DNS緩衝也沒有找到，那麼嘗試讀取hosts檔案（位於C:\Windows\System32\drivers\etc），看看這裡面有沒有該網域名稱對應的IP地址，如果有則解析成功。4 如果在hosts檔案中也沒有找到對應的條目，瀏覽器就會發起一個DNS的系統調用，就會向本地配置的首選DNS伺服器（一般是電信電訊廠商提供的，也可以使用像Google提供的DNS伺服器）發起網域名稱解析請求（通過的是UDP協議向DNS的53連接埠發起請求，這個請求是遞迴的請求，也就是電訊廠商的DNS伺服器必須得提供給我們該網域名稱的IP地址），電訊廠商的DNS伺服器首先尋找自身的緩衝，找到對應的條目，且沒有到期，則解析成功。如果沒有找到對應的條目，則有電訊廠商的DNS代我們的瀏覽器發起迭代DNS解析請求，它首先是會找根域的DNS的IP地址（這個DNS伺服器都內建13台根域的DNS的IP地址），找打根域的DNS地址，就會向其發起請求（請問www.linux178.com這個網域名稱的IP地址是多少啊？），根域發現這是一個頂級域com域的一個網域名稱，於是就告訴電訊廠商的DNS我不知道這個網域名稱的IP地址，但是我知道com域的IP地址，你去找它去，於是電訊廠商的DNS就得到了com域的IP地址，又向com域的IP地址發起了請求（請問www.linux178.com這個網域名稱的IP地址是多少?）,com域這台伺服器告訴電訊廠商的DNS我不知道www.linux178.com這個網域名稱的IP地址，但是我知道linux178.com這個域的DNS地址，你去找它去，於是電訊廠商的DNS又向linux178.com這個網域名稱的DNS地址（這個一般就是由網域名稱註冊商提供的，像萬網，新網等）發起請求（請問www.linux178.com這個網域名稱的IP地址是多少？），這個時候linux178.com域的DNS伺服器一查，誒，果真在我這裡，於是就把找到的結果發送給電訊廠商的DNS伺服器，這個時候電訊廠商的DNS伺服器就拿到了www.linux178.com這個網域名稱對應的IP地址，並返回給Windows系統核心，核心又把結果返回給瀏覽器，終於瀏覽器拿到了www.linux178.com對應的IP地址，該進行一步的動作了。註：一般情況下是不會進行以下步驟的如果經過以上的4個步驟，還沒有解析成功，那麼會進行如下步驟：5 作業系統就會尋找NetBIOS name Cache（NetBIOS名稱緩衝，就存在用戶端電腦中的），那這個緩衝有什麼東西呢？凡是最近一段時間內和我成功通訊的電腦的電腦名稱和Ip地址，就都會存在這個緩衝裡面。什麼情況下該步能解析成功呢？就是該名稱正好是幾分鐘前和我成功通訊過，那麼這一步就可以成功解析。6 如果第5步也沒有成功，那會查詢WINS 伺服器（是NETBIOS名稱和IP地址對應的伺服器）7 如果第6步也沒有查詢成功，那麼用戶端就要進行廣播尋找8 如果第7步也沒有成功，那麼用戶端就讀取LMHOSTS檔案（和HOSTS檔案同一個目錄下，寫法也一樣）如果第八步還沒有解析成功，那麼就宣告這次解析失敗，那就無法跟目標電腦進行通訊。只要這八步中有一步可以解析成功，那就可以成功和目標電腦進行通訊。

看抓包：
Linux虛擬機器測試，使用命令 wget www.linux178.com 來請求，發現直接使用chrome瀏覽器請求時，幹擾請求比較多，所以就使用wget命令來請求，不過使用wget命令只能把index.html請求回來，並不會對index.html中包含的靜態資源（js、css等檔案）進行請求。

抓包分析：

1 號包，這個是那台虛擬機器在廣播，要擷取192.168.100.254（也就是網關）的MAC地址，因為區域網路的通訊靠的是MAC地址，它為什麼需要跟網關進行通訊是因為我們的DNS伺服器IP是外圍IP，要出去必須要依靠網關幫我們出去才行。2 號包，這個是網關收到了虛擬機器的廣播之後，回應給虛擬機器的回應，告訴虛擬機器自己的MAC地址，於是用戶端找到了路由出口。3 號包，這個包是wget命令向系統配置的DNS伺服器提出網域名稱解析請求（準確的說應該是wget發起了一個DNS解析的系統調用），請求的網域名稱www.linux178.com,期望得到的是IP6的地址（AAAA代表的是IPv6地址）4 號包，這個DNS伺服器給系統的響應，很顯然目前使用IPv6的還是極少數，所以得不到AAAA記錄的5 號包，這個還是請求解析IPv6地址，但是www.linux178.com.leo.com這個主機名稱是不存在的，所以得到結果就是no such name6 號包，這個才是請求的網域名稱對應的IPv4地址（A記錄）7 號包，DNS伺服器不管是從緩衝裡面，還是進行迭代查詢最終得到了網域名稱的IP地址，響應給了系統，系統再給了wget命令，wget於是得到了www.linux178.com的IP地址，這裡也可以看出用戶端和本地的DNS伺服器是遞迴的查詢（也就是伺服器必須給用戶端一個結果）這就可以開始下一步了，進行TCP的三向交握。

二.發起TCP的3次握手

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

如：

1） Client首先發送一個串連試探，ACK=0 表示確認號無效，SYN = 1 表示這是一個串連請求或串連接受報文，同時表示這個資料報不能攜帶資料，seq = x 表示Client自己的初始序號（seq = 0 就代表這是第0號包），這時候Client進入syn_sent狀態，表示用戶端等待伺服器的回複2） Server監聽到串連請求報文後，如同意建立串連，則向Client發送確認。TCP報文首部中的SYN 和 ACK都置1 ，ack = x + 1表示期望收到對方下一個報文段的第一個資料位元組序號是x+1，同時表明x為止的所有資料都已正確收到（ack=1其實是ack=0+1,也就是期望用戶端的第1個包），seq = y 表示Server 自己的初始序號（seq=0就代表這是伺服器這邊發出的第0號包）。這時伺服器進入syn_rcvd，表示伺服器已經收到Client的串連請求，等待client的確認。3） Client收到確認後還需再次發送確認，同時攜帶要發送給Server的資料。ACK 置1 表示確認號ack= y + 1 有效（代表期望收到伺服器的第1個包），Client自己的序號seq= x + 1（表示這就是我的第1個包，相對於第0個包來說的），一旦收到Client的確認之後，這個TCP串連就進入Established狀態，就可以發起http請求了。

看抓包：

9 號包 這個就是對應上面的步驟 1）10 號包 這個對應的上面的步驟 2）11 號包 這個對應的上面的步驟 3）

TCP 為什麼需要3次握手？

舉個例子：

假設一個老外在故宮裡面迷路了，看到了小明，於是就有下面的對話：

老外： Excuse me，Can you Speak English?小明： yes 。老外： OK,I want ...

在問路之前，老外先問小明是否會說英語，小明回答是的，這時老外才開始問路

2個電腦通訊是靠協議（目前流行的TCP/IP協議）來實現,如果2個電腦使用的協議不一樣，那是不能進行通訊的，所以這個3次握手就相當於試探一下對方是否遵循TCP/IP協議，協商完成後就可以進行通訊了，當然這樣理解不是那麼準確。

為什麼HTTP協議要基於TCP來實現？

目前在Internet中所有的傳輸都是通過TCP/IP進行的，HTTP協議作為TCP/IP模型中應用程式層的協議也不例外，TCP是一個端到端的可靠的連線導向的協議，所以HTTP基於傳輸層TCP協議不用擔心資料的傳輸的各種問題。

三.建立TCP串連後發起http請求

進過TCP3次握手之後，瀏覽器發起了http的請求（看第?包），使用的http的方法 GET 方法，請求的URL是 / ,協議是HTTP/1.0

下面是第12號包的詳細內容：

以上的報文是HTTP請求報文。

那麼HTTP請求報文和響應報文會是什麼格式呢？

起始行：如 GET / HTTP/1.0 （請求的方法  請求的URL 請求所使用的協議）頭部資訊：User-Agent  Host等成對出現的值主體

不管是請求報文還是響應報文都會遵循以上的格式。

那麼起始行中的要求方法有哪些種呢？

GET: 完整請求一個資源 （常用）HEAD: 僅請求響應首部POST：提交表單  （常用）PUT: (webdav) 上傳 DELETE：(webdav) 刪除 OPTIONS：返回請求的資源所支援的方法的方法 TRACE: 追求一個資源請求中間所經過的代理 

那什麼是URL、URI、URN？

URI  Uniform Resource Identifier 統一資源識別項URL  Uniform Resource Locator 統一資源定位器 格式如下：  scheme://[username:[email protected]]HOST:port/path/to/source             http://www.magedu.com/downloads/nginx-1.5.tar.gzURN  Uniform Resource Name 統一資源名稱URL和URN 都屬於 URI為了方便就把URL和URI暫時都通指一個東西

請求的協議有哪些種？

有以下幾種：

http/0.9: statelesshttp/1.0: MIME, keep-alive (保持串連), 緩衝http/1.1: 更多的要求方法，更精細的緩衝控制，持久串連(persistent connection) 比較常用

下面是Chrome發起的http請求報文頭部資訊

其中

Accept  就是告訴伺服器端，我接受那些MIME類型Accept-Encoding  這個看起來是接受那些壓縮方式的檔案Accept-Lanague   告訴伺服器能夠發送哪些語言 Connection       告訴伺服器支援keep-alive特性Cookie           每次請求時都會攜帶上Cookie以方便伺服器端識別是否是同一個用戶端Host             用來標識請求伺服器上的那個虛擬機器主機，比如Nginx裡面可以定義很多個虛擬機器主機                 那這裡就是用來標識要訪問那個虛擬機器主機。User-Agent       使用者代理程式，一般情況是瀏覽器，也有其他類型，如：wget curl 搜尋引擎的蜘蛛等     條件請求首部：If-Modified-Since 是瀏覽器向伺服器端詢問某個資源檔如果自從什麼時間修改過，那麼重新發給我，這樣就保證伺服器端資源             檔案更新時，瀏覽器再次去請求，而不是使用緩衝中的檔案安全請求首部：Authorization: 用戶端提供給伺服器的認證資訊；

什麼是MIME？

MIME（Multipurpose Internet Mail Extesions 多用途互連網郵件擴充）是一個互連網標準，它擴充了電子郵件標準，使其能夠支援非ASCII字元、二進位格式附件等多種格式的郵件訊息，這個標準被定義在RFC 2045、RFC 2046、RFC 2047、RFC 2048、RFC 2049等RFC中。 由RFC 822轉變而來的RFC 2822，規定電子郵件標準並不允許在郵件訊息中使用7位ASCII字元集以外的字元。正因如此，一些非英語字元訊息和二進位檔案，映像，聲音等非文字訊息都不能在電子郵件中傳輸。MIME規定了用於表示各種各樣的資料類型的符號化方法。 此外，在全球資訊網中使用的HTTP協議中也使用了MIME的架構，標準被擴充為互連網媒體類型。

MIME 遵循以下格式：major/minor 主類型/次類型 例如：

image/jpgimage/giftext/htmlvideo/quicktimeappliation/x-httpd-php

四.伺服器端響應http請求，瀏覽器得到html代碼

看 第12號包是http請求包，第32包是http響應包

伺服器端WEB程式接收到http請求以後，就開始處理該請求，處理之後就返回給瀏覽器html檔案。

第32號包 是伺服器返回給用戶端http響應包（200 ok 響應的MIME類型是text/html），代表這一次用戶端發起的http請求已成功響應。200 代表是的 響應成功的狀態代碼，還有其他的狀態代碼如下：

1xx: 資訊性狀態代碼     100, 1012xx: 成功狀態代碼     200：OK3xx: 重新導向狀態代碼     301: 永久重新導向, Location響應首部的值仍為當前URL，因此為隱藏重新導向;     302: 臨時重新導向，顯式重新導向, Location響應首部的值為新的URL     304：Not Modified  未修改，比如本機快取的資源檔和伺服器上比較時，發現並沒有修改，伺服器返回一個304狀態代碼，                         告訴瀏覽器，你不用請求該資源，直接使用本地的資源即可。4xx: 用戶端錯誤狀態代碼     404: Not Found  請求的URL資源並不存在5xx: 伺服器端錯誤狀態代碼     500: Internal Server Error  伺服器內部錯誤     502: Bad Gateway  前面Proxy 伺服器聯絡不到後端的伺服器時出現     504：Gateway Timeout  這個是代理能聯絡到後端的伺服器，但是後端的伺服器在規定的時間內沒有給Proxy 伺服器響應

用Chrome瀏覽器看到的回應標頭資訊：

Connection            使用keep-alive特性Content-Encoding      使用gzip方式對資源壓縮Content-type          MIME類型為html類型，字元集是 UTF-8Date                  響應的日期Server                使用的WEB伺服器Transfer-Encoding:chunked   分塊傳輸編碼 是http中的一種資料轉送機制，允許HTTP由網頁伺服器發送給用戶端應用（通常是網頁瀏覽器）的資料可以分成多個部分，分塊傳輸編碼只在HTTP協議1.1版本（HTTP/1.1）中提供Vary  這個可以參考（http://blog.csdn.net/tenfyguo/article/details/5939000）X-Pingback  參考（http://blog.sina.com.cn/s/blog_bb80041c0101fmfz.html）

那到底伺服器端接收到http請求後是怎麼樣產生html檔案？

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

1 nginx讀取設定檔

我們在瀏覽器的地址欄裡面輸入的是 http://www.linux178.com （http://可以不用輸入，瀏覽器會自動幫我們添加），其實完整的應該是http://www.linux178.com./ 後面還有個點（這個點代表就是根域，一般情況下我們不用輸入，也不顯示）,後面的/也是不用添加，瀏覽器會自動幫我們添加（且看第3部那個圖裡面的URL），那麼實際請求的URL是http://www.linux178.com/，那麼好了Nginx在收到 瀏覽器 GET / 請求時，會讀取http請求裡面的頭部資訊，根據Host來匹配 自己的所有的虛擬機器主機的設定檔的server_name,看看有沒有匹配的，有匹配那麼就讀取該虛擬機器主機的配置，發現如下配置：

root /web/echo   

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

index index.html index.htm index.php  

通過這個就能得知網站的首頁檔案是那個檔案，也就是我們在入http://www.linux178.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中匹配（這裡是啟用了Regex進行匹配） *.php尾碼的（後面跟的參數）都交給後端的fastcgi進程進行處理。

2 把php檔案交給fastcgi進程去處理

於是nginx把/index.php這個URL交給了後端的fastcgi進程處理，等待fastcgi處理完成後（結合資料庫查詢出資料，填充模板產生html檔案）返回給nginx一個index.html文檔，Nginx再把這個index.html返回給瀏覽器，於是乎瀏覽器就拿到了首頁的html代碼，同時nginx寫一條訪問日誌到記錄檔中去。

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

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

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

比如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 111web         佔據 5號block  是目錄 裡面有2個目錄 echo dataecho        佔據 11號 block  是目錄  裡面有1個檔案 index.phpindex.php   佔據 15 16號 block  是檔案

其在檔案系統中分布如所示

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

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

1 核心讀取中繼資料區 / 的inode，從inode裡面讀取/所對應的資料區塊的編號，然後在資料區找到其對應的塊（1 2號塊），讀取1號塊上的映射表找到web這個名稱在中繼資料區對應的inode號2 核心讀取web對應的inode（3號），從中得知web在資料區對應的塊是5號塊，於是到資料區找到5號塊，從中讀取映射表，知道echo對應的inode是5號，於是到中繼資料區找到5號inode3 核心讀取5號inode，得到echo在資料區對應的是11號塊，於是到資料區讀取11號塊得到映射表，得到index.php對應的inode是9號4 核心到中繼資料區讀取9號inode，得到index.php對應的是15和16號資料區塊，於是就到資料區域找到15 16號塊，讀取其中的內容，得到index.php的完整內容

五. 瀏覽器解析html代碼，並請求html代碼中的資源

瀏覽器拿到index.html檔案後，就開始解析其中的html代碼，遇到js/css/image等靜態資源時，就向伺服器端去請求下載（會使用多線程下載，每個瀏覽器的線程數不一樣），這個時候就用上keep-alive特性了，建立一次HTTP串連，可以請求多個資源，下載資源的順序就是按照代碼裡的順序，但是由於每個資源大小不一樣，而瀏覽器又多線程請求請求資源，所以從看出，這裡顯示的順序並不一定是代碼裡面的順序。

瀏覽器在請求靜態資源時（在未到期的情況下），向伺服器端發起一個http請求（詢問自從上一次修改時間到現在有沒有對資源進行修改），如果伺服器端返回304狀態代碼（告訴瀏覽器伺服器端沒有修改），那麼瀏覽器會直接讀取本地的該資源的快取檔案。

詳細的瀏覽器工作原理請看：http://kb.cnblogs.com/page/129756/

六.瀏覽器對頁面進行渲染呈現給使用者

最後，瀏覽器利用自己內部的工作機制，把請求到的靜態資源和html代碼進行渲染，渲染之後呈現給使用者。

自此一次完整的HTTP事務宣告完成.

 

 

 

 

 

dd

一次完整的HTTP事務是怎樣一個過程？(轉)