URL訪問網站的網絡傳輸全過程

打開瀏覽器，在地址欄輸入URL，回車，出現網站內容。這是咱們幾乎天天都在作的事，那這個過程當中究竟是什麼原理呢？HTTP、TCP、DNS、IP這些耳熟能詳的名詞都在何時起着什麼做用呢？在這裏總體梳理一遍。

整個過程基本分作下面幾個部分：

一、域名解析成IP地址；
二、與目的主機進行TCP鏈接（三次握手）；
三、發送與收取數據；
四、與目的主機斷開TCP鏈接（四次揮手）；
下面分別進行詳細說明。

域名解析成IP地址
首先說什麼是域名解析？

咱們在瀏覽器地址欄中輸入的都是相似「www.baidu.com」、「www.qq.com」等等容易記憶的英文域名，但這些字母你直接交給整個網絡線路去尋找目的主機找獲得嗎？找不到，由於每一個主機在網絡中的位置都是以IP標識的，IP纔是主機在網絡中的位置，域名只是爲了方便用戶記憶而已，這就要求瀏覽器可以識別域名而且將其轉化爲對應的IP地址。

因此瀏覽器會有一個DNS緩存，其中記錄了一些域名與IP的對應關係，供瀏覽器快速查找須要的IP。可是這個DNS緩存不可能存下全部的域名-IP地址，況且IP地址有時候還會變化，所以當在DNS緩存中沒有找到的時候，就要先向DNS服務器請求域名解析，咱們常聽到的DNS服務器很大的做用就是進行域名解析。

值得一提的是，DNS域名解析時用的是UDP協議。

整個域名解析的過程以下：

一、瀏覽器向本機DNS模塊發出DNS請求，DNS模塊生成相關的DNS報文；
二、DNS模塊將生成的DNS報文傳遞給傳輸層的UDP協議單元；
三、UDP協議單元將該數據封裝成UDP數據報，傳遞給網絡層的IP協議單元；
四、IP協議單元將該數據封裝成IP數據包，其目的IP地址爲DNS服務器的IP地址；
五、封裝好的IP數據包將傳遞給數據鏈路層的協議單元進行發送；
六、發送時在ARP緩存中查詢相關數據，若是沒有，就發送ARP廣播（包含待查詢的IP地址，收到廣播的主機檢查本身的IP，符合條件的主機將含有本身MAC地址的ARP包發送給ARP廣播的主機）請求，等待ARP迴應；
七、獲得ARP迴應後，將IP地址與路由的下一跳MAC地址對應的信息寫入ARP緩存表；
八、寫入緩存後，以路由下一跳的地址填充目的MAC地址，以數據幀形式轉發；
九、轉發可能進行屢次；
十、DNS請求到達DNS服務器的數據鏈路層協議單元；
十一、DNS服務器的數據鏈路層協議單元解析數據幀，將內部的IP數據包傳遞給網絡層IP協議單元；
十二、DNS服務器的IP協議單元解析IP數據包，將內部的UDP數據報傳遞給傳輸層UDP協議單元；
1三、DNS服務器的UDP協議單元解析收到的UDP數據報，將內部的DNS報文傳遞給DNS服務單元；
1四、DNS服務單元將域名解析成對應IP地址，產生DNS迴應報文；
1五、DNS迴應報文->UDP->IP->MAC->個人主機；
1六、個人主機收到數據幀，將數據幀->IP->UDP->瀏覽器；
1七、將域名解析結果以域名和IP地址對應的形式寫入DNS緩存表。
其中提到了一個ARP的概念，相似於DNS將域名翻譯成IP，ARP則是將IP翻譯成MAC地址，咱們知道了IP後，須要經過主機的MAC地址來更具體的找到主機。一樣的也有一個ARP緩存，其中存儲了一些IP與MAC地址的對應關係，若是緩存中找不到，就會進行廣播來查找MAC地址，收到廣播的主機會檢查本身的IP是不是待查找的IP，是的話就返回本身的MAC地址。

若是作開發，每每還會接觸到端口這個概念，那端口是什麼呢？這裏是指TCP/IP協議中的端口，端口號的範圍從0到65535，好比用於瀏覽網頁服務的80端口，用於FTP服務的21端口等等，都有一些固定的端口號，被佔用後就不能被別的服務拿來傳輸數據了。

與目的主機進行TCP鏈接（三次握手）
獲得域名對應的IP地址後，也就表示能夠將數據送達目的主機了，這時候纔開始咱們常說的三次握手創建鏈接。

HTTP的請求時使用TCP進行傳輸的，能夠保證可靠傳輸，而且有序，而TCP是有鏈接的傳輸，也就是在傳輸數據以前，會創建個人主機與目的主機之間的鏈接，而後才能傳輸數據，傳輸完成後，還有斷開鏈接。這也就是TCP的三次握手和四次揮手，大體過程以下圖所示：

具體的三次握手創建鏈接的過程以下表述，其中數據包的傳輸過程相似上文請求DNS服務器時的過程，就簡單的表示一下：

一、向目的主機發送TCP鏈接請求報文；
二、該TCP報文中SYN標誌位設爲1，表示鏈接請求；
三、該TCP報文經過IP（DNS）->MAC（ARP）->網關->目的主機；
四、目的主機收到數據幀，經過IP->TCP，TCP協議單元迴應請求應答報文；
五、該報文中SYN和ACK標誌設爲1，表示鏈接請求應答；
六、該TCP報文經過IP（DNS）->MAC（ARP）->網關->個人主機；
七、個人主機收到數據幀，經過IP->TCP，TCP協議單元迴應請求確認報文；
八、該TCP報文經過IP（DNS）->MAC（ARP）->網關->目的主機；
九、目的主機收到數據幀，經過IP->TCP，鏈接創建完成。
三次握手的過程就是一去一回一去，互相確認一下，就創建鏈接啦。這個過程當中任何一個報文出錯或者超時，都要進行重傳。

發送與收取數據
如上所說，只有創建鏈接後才能開始傳輸數據，數據其實有多種傳輸方式，好比分段啊分組啊分時啊等等。而一個數據包的傳輸過程以下所示，以HTTP的GET方法請求爲例：

一、瀏覽器向域名發出GET方法報文；
二、該GET方法報文經過TCP->IP（DNS）->MAC（ARP）->網關->目的主機；
三、目的主機收到數據幀，經過IP->TCP->HTTP，HTTP協議單元會迴應HTTP協議格式封裝好的HTML形式數據；
四、該HTML數據經過TCP->IP（DNS）->MAC（ARP）->網關->個人主機；
五、個人主機收到數據幀，經過IP->TCP->HTTP->瀏覽器，瀏覽器以網頁形式顯示HTML內容。
其餘的HTTP方法在傳輸數據時方法都相似，只是所攜帶的內容不一樣。

與目的主機斷開TCP鏈接（四次揮手）
數據傳輸完成後須要斷開鏈接，與創建時不一樣，斷開鏈接須要多一次，有四次揮手，至於爲何，看完過程咱們再講。

這裏再把圖拿過來幫助理解：

過程以下：

一、瀏覽器向目的主機發出TCP鏈接結束請求報文，此時進入FIN WAIT狀態；
二、該報文FIN標誌位設爲1，表示結束請求；
三、TCP結束請求報文經過IP（DNS）->MAC（ARP）->網關->目的主機；
四、目的主機收到數據幀，經過IP->TCP，TCP協議單元迴應結束應答報文；
五、當前只是進行迴應，由於目的主機可能還有數據要傳，並不急着斷開鏈接；
六、該報文中ACK標誌位設爲1，表示收到結束請求；
七、目的數據發送完全部數據後，向個人主機發出TCP鏈接結束請求報文；
八、該報文FIN標誌位設爲1，表示結束請求；
九、TCP結束請求報文經過IP（DNS）->MAC（ARP）->網關->個人主機；
十、個人主機收到數據幀，經過IP->TCP，TCP協議單元迴應結束應答報文，此時進入TIME WAIT狀態，由於不相信網絡是可靠的，若是目的主機沒收到還能夠重發；
十一、該報文中的FIN標誌位均設爲1，表示結束應答；
十二、該TCP迴應報文經過IP（DNS）->MAC（ARP）->網關->目的主機；
1三、目的主機關閉鏈接；
1四、TIME WAIT等待結束後，沒有收到回覆，說明目的正常關閉了，個人主機也關閉鏈接。
這裏的過程是以個人主機主動發起結束請求開始的，實際上也能夠由目的主機主動發起，那麼過程就會跟上面相反，但細節差很少。

FIN_WAIT狀態是主動發起請求時等待確認信息，而TIME_WAIT狀態是收到結束請求後發送確認信息後等待看是否須要重發。

如今來講說爲何斷開鏈接時須要四次揮手呢？由於創建鏈接時目的主機能夠直接發送SYN（同步）+ACK（應答）報文。而當斷開時，目的主機收到FIN後可能還有數據要發，並不必定直接斷開，因此先發送一次應答，告知個人主機收到了請求，等確認全部數據都發完了，再發送FIN，同時等待個人主機應答，這裏的FIN和ACK就不能一塊兒發送，因此須要四次。

結
以上就是URL訪問網站時的網絡傳輸全過程，概括起來就是：

首先要經過域名找到IP，若是緩存裏沒有就要請求DNS服務器；獲得IP後開始於目的主機進行三次握手來創建TCP鏈接；鏈接創建後進行HTTP訪問，傳輸並獲取網頁內容；傳輸完後與目的主機四次揮手來斷開TCP鏈接。 ---------------------