身在資訊時代，幾乎人人都需使用裝置訪問網路上的資源。在這個過程中，建立網路連線所實現的連通性，是計算機網路最基本功能。今天，我們就來分享一個關於計算機網路的知識點 —— 網路到底是怎麼連線的？

瀏覽器生成訊息且傳送

傳送一個訊息的總體流程如下

生成HTTP請求訊息

舉個例子，當我們在瀏覽器輸入網路地址的時候，瀏覽器首先會對URL進行解析：

https：表示訪問資料來源的機制，也就是協議
: web伺服器名稱
img ：表示目錄名
service.843585b7.png：表示檔名然後就要生成HTTP訊息了，它大概長這樣

這些欄位具體內容是什麼可以參考這篇文章：五千來字小作文，是的，我們是有個HTTP。

DNS域名解析為IP地址

瀏覽器生成了這個HTTP訊息後，它要往哪裡傳送呢？當然是伺服器啦，所以就要解析這個域名對應的是哪臺伺服器，IP地址是什麼，因為IP地址不好記，所以才有了對應的域名，便於我們人類記憶。

瀏覽器會檢查快取有沒有這個域名對應的ip地址
作業系統會檢查快取（就是我們平常說的hosts檔案）
作業系統會傳送給本地區的DNS伺服器，讓它幫忙解析下 DNS伺服器接受來自客戶端的查詢，包括以下三個內容：
域名：伺服器，郵件伺服器的名稱
Class：在最早設計DNS時，DNS在網際網路以外的其他網路中的應用也被考慮到了，而Class就是用來識別網路資訊的，不過如今除了網際網路就沒有其他網路了，因此Class的值永遠代表網際網路的IN
記錄型別：表示域名對應何種記錄型別
A記錄時，域名直接對應IP地址
CNAME時，此域名對應其他域名
MX時，表示域名對應的是郵件伺服器對於不同的記錄型別，響應資料也不一樣

域名的層次結構

越靠右層次越高，從右向左一級一級的劃分 : 例如就是cn->jdl->www；
具有這種層次結構的域名資訊都會註冊到DNS伺服器中，而每個域都是作為一個整體來處理的客戶端和DNS伺服器互動流程大概如下；
上級DNS伺服器中要註冊其下級域的DNS伺服器IP地址，然後上級DNS伺服器IP地址要註冊到更上一級的DNS伺服器中，此次類推；
根域的DNS伺服器資訊儲存到網際網路中所有的DNS伺服器中，這樣的話，所有的DNS伺服器都會找到根域，然後一級一級的往下找，直到找到自己想要的那個域名；
分配給根域的IP地址僅有13個，就是頂級域名（com,cn等）對應的ip地址。

具體互動就是下面這樣

但是一臺伺服器存不下這麼多，所以一般都是DNS伺服器大接力來尋找這個IP地址，圖如下：

客戶端找到最近的DNS伺服器，查詢的資訊，可是最近的DNS伺服器沒有這個資訊，就轉發到了根域伺服器下，經過判斷發現是cn的頂級域名的，於是根域DNS伺服器會返回它所管理的cn域中的DNS伺服器的IP地址，接下來，最近的這個DNS伺服器又回去訪問com域名的伺服器，以此類推，最終會找到這個伺服器的IP地址。

委託協議棧傳送訊息

知道了IP地址後，就可以委託作業系統內部的協議棧向這個目標IP地址傳送訊息了。

協議棧的內部結構；

瀏覽器、郵件等一般應用程式收發資料時用TCP；
DNS查詢等收發較短的控制資料用UDP。

網路分層

OSI七層模型

開放式系統互聯通訊參考模型（英語：Open System Interconnection Reference Model，縮寫為 OSI），簡稱為OSI模型（OSI model），一種概念模型，由國際標準化組織提出，一個試圖使各種計算機在世界範圍內互連為網路的標準框架。定義於ISO/IEC 7498-1。

TCP/IP四次模型
應用層： HTTP、DNS、FTP；
傳輸層： TCP、UDP；
網路層： IP；
網路介面層。

TCP/IP（Transmission Control Protocol/Internet Protocol，傳輸控制協議/網際協議）TCP/IP協議不僅僅指的是TCP 和IP兩個協議，而是指一個由FTP、SMTP、TCP、UDP、IP等協議構成的協議簇，只是因為在TCP/IP協議中TCP協議和IP協議最具代表性，所以被稱為TCP/IP協議。

客戶端伺服器傳遞資料流程

一個資料包從客戶端到服務端中間經過每一層都需要加工處理；
客戶端這邊需要不斷的給資料包新增頭部；
服務端這邊需要不斷的拆分這個資料包。

三次握手

當兩臺計算機要傳遞資料的時候，一定要先連線，得經過TCP三次握手吧（僅僅指指走TCP協議需要連線的），我們平常都說TCP連線要經過三次握手，我們就來看一下到底什麼是TCP三次握手，如圖所示

客戶端要傳送的時候，主動從 closed狀態開啟，伺服器啟動後就一直處於監聽 LISTEN狀態
客戶端傳送 SYN = 1,seq = x 給服務端，客戶端處於 SYN_SEND狀態。
服務端收到後給客戶端傳送 SYN = 1,ACK =1, seq = y,ack = x+1。此時服務端處於 SYN_RCVD狀態
客戶端收到後傳送ACK =1, seq = x+1,ack = y+1給伺服器，此時客戶端狀態是 ESTAB-LISHED
服務端收到後狀態變為 ESTAB-LISHED

三次握手透過後，就代表客戶端和服務端可以傳遞資料包進行互動啦

我們說到SYN，ACK,seq,ack這些又是什麼呢？這些其實是 TCP資料包裡的屬性，我們接著往下看（在傳輸層中有解釋）

應用層

HTTP資料包拆分

一般HTTP請求訊息不會太長，一個網路包就能裝的下
傳送緩衝區中的資料如果超過MSS的長度，就會被以MSS長度進行拆分放進單獨的網路包中

MTU（Maximum Transmission Unit）: 一個網路包的最大長度，乙太網中一般是1500位元組

MSS（Maximum Segment Size）: 除去頭部之後，一個網路包所容納的TCP資料的最大長度

傳輸層

上面應用層的這個網路包再加上TCP頭部。

TCP報文格式

源埠號（16位）：傳送網路包的埠號
目的埠號（16位）：網路包的接受方的埠號
序號（傳送資料的順序編號）（32位）：傳送方告知接收方已經收到了所有資料的第幾個位元組
確認序號（接收資料的順序編號）（32位）：接收方告知傳送方接收方已經收到了所有資料的第幾個位元組
頭部長度（4位）：表示資料的起始部分，資料偏移量
保留（6位）：該欄位為保留，現在未使用
控制位（6位）：該欄位中的每個位元位分別表示以下通訊控制的含義
URG：表示緊急指標欄位有效
ACK：表示接收資料序號欄位有效，一般表示資料已被接收方收到
PSH: 表示透過flush操作傳送的資料
RST: 強制斷開連線，用於異常中斷的情況
SYN: 傳送方和接收方相互確認序號，表示連線操作
FIN: 表示斷開操作
視窗大小（16位）：接收方告知傳送方視窗大小（即無需等待確認可一起傳送的資料）
校驗和（16位）：用來檢查是否出現錯誤
緊急指標（16位）：表示應急處理的資料位置
可選欄位（可變長度）：除了上面的固定頭部欄位外，還可以新增可選欄位，但除了連線操作外，很少使用可選欄位

還記得三次握手提到過的各種序號嗎，就是這個報文裡的屬性

網路層

然後上面這個網路包再加上IP頭部

IP報文格式

版本號（4位元）： IP協議版本號，目前是版本4
頭部長度（4位元）： IP頭部的長度，可選欄位可導致頭部長度的變化，因此這裡需要指定頭部的長度
服務型別（TOS）(8位元)：表示包傳輸優先順序。最初的協議規格里對這個引數的定義很模糊，最近 DIFFServ規則重新定義了這個欄位的用法
總長度（16位元）：表示IP訊息的總長度
ID號（16位元）：用於識別包的編號，一般為的序列號。如果一個包被IP分片，則所有分片都擁有相同的ID
標誌（Flag）(3位元)：該欄位有3個位元，其中2個位元有效，分別代表是否允許分片，以及當前分片是否為分片包
分片偏移量（13位元）：表示當前包的內容為整個IP訊息的第幾個位元組開始的內容
生存時間（TTL）（8位元）：表示包的生存時間，這是為了避免網路出現迴環時一個包永遠在網路中打轉。每經過一個路由器，這個值就會減一，減到0的是hi這個包就會被丟棄
協議號（8位元）：協議號表示協議的型別（以下均為16進位制）
TCP: 06
UDP: 17
ICMP: 01
頭部校驗和（16位元）：用於檢查錯誤，現在已經不在使用
傳送方IP地址（32位元）：網路包傳送方的IP地址
接收方IP地址（32位元）：網路包接收方的IP地址
可選欄位（可變長度）：除了上面的固定頭部欄位外，還可以新增可選欄位，但除了連線操作外，很少使用可選欄位

然後這個網路包再加上MAC頭部

MAC資料包

接收方MAC地址(48位元)：網路包接收方的MAC地址，在區域網中使用這一地址來傳輸網路包
傳送方MAC地址(48位元)：網路包傳送方的MAC地址，接收方透過它來判斷是誰傳送了這個網路包
以太型別（16位元）：使用的協議型別。下面是一些常見的型別，一般在TCP/IP通訊中只是用0800和0806這兩種。
0000-05DC： IEEE 802.3
0800 : IP協議
0806 : ARP協議
86DD : IPV6

MAC地址 VS IP地址

IP頭部前面還會加上MAC頭部
為什麼需要MAC資料包呢？因為在乙太網的世界中，TCP/IP這個思路是行不通的。
乙太網在判斷網路包目的地時和TCP/IP的方式不同，因此必須採用想匹配的方式才能在乙太網中將包發往目的地，而MAC地址就是幹這個的
傳送方MAC地址：MAC地址是寫在網路卡生產時寫入ROM裡的，只需要將這個值讀取出來寫入MA頭部就好了

傳送方的MAC地址還比較容易獲取到，但是接收方的MAC地址就不太容易獲取到了

ARP廣播

ARP :Addresss Resolution Protocal 地址解析協議

根據IP地址查詢接收方MAC地址的時候會用到ARP廣播
在同一個子網中，利用廣播對所有裝置提問 XXX這個ip地址是誰的，其他裝置發現自己的ip地址是這個xxx的話，那麼他就會把它的MAC地址告訴提問者，這樣就會檢測到接收方的MAC地址了，如果發現自己的ip地址不是這個XXX，那麼則會丟棄這個訊息並不去理會。

如果每次都去廣播的話，那麼網路中就會增加很多ARP包，所以為了提高效率，我們有ARP快取在記憶體中。查詢之前先去查詢ARP快取。
當目的地的IP地址對應的MAC地址變了的話，那麼這個MAC快取就會出問題，所以為了避免這種問題發生，這個快取幾分鐘後會被刪除，非常簡單粗暴。
靜態ARP：手工維護，不會自動失效
動態ARP：會過段時間自動失效（文中說的就是它）

IP 模組負責新增如下兩個頭部：

MAC頭部：乙太網用的頭部，包含MAC地址

IP頭部： IP用的頭部，包含IP地址

總體資料包

這個時候的資料包變成了這個樣子：

MTU（Maximum Transmission Unit）: 一個網路包的最大長度，乙太網中一般是1500位元組；
MSS（Maximum Segment Size）: 除去頭部之後，一個網路包所容納的TCP資料的最大長度；
然後這資料包，沿著網路卡出去，到集線器，路由器一頓傳輸（中間涉及到電訊號轉換等等），到達服務端那邊，再一層一層的扒皮（前往中說過，一層一層的拆分資料包）。

斷開連線

四次揮手

兩臺計算機最後連線結束後要斷開連線，進行四次揮手：

其實三次握手，四次揮手還有好多好多知識點要說，像什麼為什麼握手需要三次，而揮手需要四次啦這些問題，之後我們會單獨開一篇內容和大家再深入地講一講，記得掃描下方二維碼關注我們喲！

歡迎點選【京東科技】，瞭解開發者社群

更多精彩技術實踐與獨家乾貨解析

歡迎關注【京東科技開發者】公眾號

網路連線總超時？從四層模型上解析網路是怎麼連線的