Linux必會原理之輸入網址到看到頁面内容原理

使用者從浏覽器輸入網址到頁面顯示，細分了一下基本上由八大快原理組成，他們是：

dns解析原理、TCP三次連接配接、http請求資料包、資料包的封裝、資料包的解封裝、叢集内部的一個請求、伺服器的響應封包、四次斷開

> dns解析原理：

當使用者在用戶端輸入網址後，用戶端會先通路本地的hosts檔案和dns緩存，我們hosts一般都是做測試使用來配置的。是以裝置第一通路這個網址，在本地的hosts和local是沒有這個解析的，這個時候會向LDNS（也交本地dns尋求解析），如果lDNS這裡有記錄，就會回報給用戶端，如果LDNS沒有這個記錄，LDNS就會向全球13台的根伺服器去解析。這13台伺服器是“層級式”域名解析體系，最上面的伺服器叫做根伺服器，在我們網址的後面都會影藏一個. 這個點就代表的是根伺服器，根伺服器下面的13台伺服器叫做一級域也叫頂級域，再下面的是二級域，當根伺服器收到請求後，根伺服器隻有下面的13台頂級域的解析，他會告訴LDNS去通路對應的一級域名，一級域名伺服器收到請求後，檢視自己的A記錄，告知LDNS去找etiantian這個伺服器，LDNS再次找到etiantian伺服器，etiantian伺服器檢視自己的A記錄，把資訊告知LDNS。lDNS把資訊告知用戶端。LDNS和本地的dns都會把這條記錄緩存下來也叫做A記錄還有一些的記錄例如郵件的MX記錄，prt反向解析記錄，cname記錄。A記錄不是一對一的，他可以一對多。這裡有個ttl （time to live）是控制dns的緩存周期的，ttl是什麼那？就是dns多長時間重新整理一下，對于網站修改量小的可以把ttl改的時間長一點。例如3600秒，這樣dns緩存的時間長，使用者通路資料可直接從本地讀取，加快了流量，如果一個網址修改量大，我們就要把ttl時間改小點，如果太大，伺服器那邊已經修改了，本地緩存的還是舊的。如果太小也不好，假如1秒，dns就重新整理的太快，全球dns重新整理一次要12個小時多，是以使用者一直是同通過遞歸和疊代的方式去解析給後端dns解析伺服器帶來了很大的壓力。到處dns解析就介紹了。用戶端得到了網址對應的ip了；下面使用者将要去通路這個ip的伺服器了

> tcp的三次握手

用戶端向伺服器端發送一個syn的請求，狀态從closed變成了syn_sent，伺服器在收到用戶端的syn請求後，把syn發回給用戶端，同時也會回發送一個ack，伺服器從狀态變成syn_rcvd狀态，用戶端收到伺服器傳回的syn和用戶端後，傳回一個ack給服務端，用戶端的狀态變成establish，伺服器收到用戶端發回的ack後狀态變成established，到此tcp的連接配接建立成功

>http請求封包

為什麼要先連接配接後進行http的協定？

http協定是在tcp協定之上，是以隻有tcp連接配接建立了以後應用層的http協定才可以通信~~~~~~~~~~~~~~~~~~~~~~~

http的請求封包一般有請求行，請求頭，請求主體三部分組成，在請求行裡面包含了請求方法，URL和http的協定版本還有一個空行，他們之間都是用空格分隔的，現在使用的請求方法有GET.PUT,POST,HEAD,DELETE,MOVE.GET方法是把用戶端請求指定的内容，從伺服器端獲得該内容；PUT方法是把用戶端的資源上傳到伺服器來代替指定的内容；POST方法将客戶的資源送出到伺服器，例如系統資料庫單，delete和move不經常用，這裡就不介紹。下面看請求頭都有哪些東西？在請求頭裡面包含了：媒體類型，語言類型，壓縮方法，用戶端資訊，主機頭，連接配接狀态等一些資訊，這裡與這個請求頭相關的最常用的請求頭就是Content-Type媒體和Content-Length請求長度這兩種。在請求頭的下面是一個“空行”，這裡通過發送回車或者換行符來告訴空行以下不會有請求頭的内容了。在空行的下面是請求主體，如果是get方法這裡是沒有請求主體的。到此http的請求封包包含這些東西，然後經過OSI的七層模型開始給這個請求頭進行資料封裝

> 資料包封裝

請求封包在應用層封裝資料，在傳輸層會封裝上tcp頭轉換成資料段，在網絡層封裝上ip資料段轉換成資料包，在資料鍊路層封裝進去mac和llc頭，把資料包轉換成幀，下面會在實體層把幀轉換成bit流來傳送，現在用戶端這的所有工作都結束了，下面bit流會到達遠端的Lb負載伺服器，負載伺服器通過解封裝把資料提取出來，解封裝的過程正好是封裝資料包的反向，從實體層開始，一直到應用層。在應用層分析出請求封包的資訊後，負載會向後面的内容叢集查找指定的内容，我們常用的軟體負載有‘nginx LVS HAproxy’優缺點自己了解，當然還有硬體的負載A10和′F5等。如果請求的資訊是靜态資訊，複制會請求後方的靜态伺服器，公司如果有CDN的情況，會把這些靜态檔案放在CDN前面，這樣客戶通路速度快，也能給内部叢集減少壓力；如果請求包含css，jss等一些是動态資料，由于這些結構的化的動态資料都存放在背景的資料庫，或者nfs，是以會去請求資料庫或者nfs伺服器，當然在資料庫和nfs前面有緩存伺服器類似mamcache ，會直接通路緩存，這樣都是對内部的一個優化。把使用者想要的資料經過内部叢集的一個調用，最後要傳回到用戶端，在這裡就出現了http的響應封包

http的響應封包包含有：起始行（也叫狀态行），響應頭部，空行和響應主體。起始行内包含了協定及版本，狀态碼以及狀态資訊。http協定有0.9 1.0.1和1.1現在0.9已經淘汰找不到了。1.0和1.1相比，1.0版本伺服器和用戶端隻能保持短連接配接，請求完畢會關閉這個連接配接，而1.1增加了keep-alive持久連接配接，可擴充性，緩存處理等特點，持久連接配接也是在請求頭裡面展現，當收到用戶端的請求頭包含close資訊時，請求斷開。協定版本後面是數字的一個狀态碼，這個狀态碼是回報給用戶端的資訊，告知是否連接配接成功，以及故障大體的方向，狀态碼範圍100-199，指定用戶端應響應的動作，200-299請求成功，還有300-399 400-499用戶端的錯誤導緻 500-599，伺服器的錯誤導緻，我們工作中經常能見到幾個代碼，需要注意下，例如：200 表示請求成功，301 永久跳轉，但是請求是成功的，403 forbidden 禁止通路，這裡一般是伺服器一端的權限配置問題，404 not found 這個也是伺服器端的，造成這個原因有很多，有可能是叢集内部資料的傳回逾時，或者請求的内容在伺服器上已經不存在，500這是一個内容伺服器的籠統報錯，造成這個的原因很多，502 bad gateway一般是代理伺服器請求後端，後端沒有放回或者請求逾時，一般為方向代理的下面的節點問題；503 services unavailable  伺服器不可用，可能是伺服器超載或者當機，或者反向代理後面沒有提供服務的節點 504 Gateway timeout 代理向後請求，後端在一定時間内沒有給回報，造成的逾時。下面看看響應頭部，這裡主要包含了，媒體類型MIME，時間，伺服器服務版本，連接配接狀态，字元集類型，MIME是一種文本标記，中間由一條斜杠來分割的；在響應頭部下面是一個空行，告訴響應頭部内容結束，下面是響應主體，這裡裝載了給用戶端的資料，這些資料都是文本，也可以是二進制的（圖檔，視訊）

用戶端收到響應封包後，向伺服器發送一個fin的信号，用戶端從established狀态變成了FIN_wait1，伺服器收到用戶端的FIN後傳回一個ACK，同時伺服器狀态變為close_wait，用戶端收到伺服器傳回的ack，狀态變成了fin_wait2，這個時候用戶端會等伺服器，如果伺服器還沒有發送完資料，就繼續發送，如果發送完畢 會給用戶端發送一個FIN，此時伺服器變為LAST_ACK狀态，用戶端收到伺服器的fin後，馬上傳回一個ack給伺服器告知收到，狀态進入到time-wait,此時用戶端在等2msl時間後進入到closed狀态，伺服器收到用戶端ack後進入到closed狀态。到此四次斷開結束，還有一種情況就是closing狀态，這是由于用戶端發送了fin給伺服器，而沒有收到伺服器的ack 卻收到了伺服器的fin，發生ack丢包的情況，這有可能是網絡原因。。。上面就是使用者從浏覽器輸入網址到看到頁面内容的一個過程

本文轉自 kesungang 51CTO部落格，原文連結：http://blog.51cto.com/sgk2011/1794644，如需轉載請自行聯系原作者