來源 | java小杰要加油（ID：xhJaver）
今天來分享一個關于計算機網(wǎng)絡的知識點——網(wǎng)絡到底是怎么連接的？
瀏覽器生成消息且發(fā)送
生成HTTP請求消息
舉個栗子，當我們在瀏覽器輸入https://www.jdl.cn/img/service.843585b7.png網(wǎng)絡地址的時候
- https：表示訪問數(shù)據(jù)源的機制，也就是協(xié)議
- service.843585b7.png：表示文件名 然后就要生成HTTP消息了，它大概長這樣
DNS域名解析為IP地址
瀏覽器生成了這個HTTP消息后，它要往哪里發(fā)送呢？當然是服務器啦，所以就要解析這個域名對應的是哪臺服務器，IP地址是什么，因為IP地址不好記，所以才有了對應的域名，便于我們人類記憶。
- 操作系統(tǒng)會檢查緩存（就是我們平常說的hosts文件）
- 操作系統(tǒng)會發(fā)送給本地區(qū)的DNS服務器，讓它幫忙解析下 DNS服務器接受來自客戶端的查詢，包括以下三個內容
- Class：在最早設計DNS時，DNS在互聯(lián)網(wǎng)以外的其他網(wǎng)絡中的應用也被考慮到了，而Class就是用來識別網(wǎng)絡信息的，不過如今除了互聯(lián)網(wǎng)就沒有其他網(wǎng)絡了，因此Class的值永遠代表互聯(lián)網(wǎng)的IN
- MX時，表示域名對應的是郵件服務器 對于不同的記錄類型，響應數(shù)據(jù)也不一樣
域名的層次結構
- 越靠右層次越高，從右向左一級一級的劃分 : 例如 www.jdl.cn 就是cn->jdl->www
- 具有這種層次結構的域名信息都會注冊到DNS服務器中，而每個域都是作為一個整體來處理的 客戶端和DNS服務器交互流程大概如下
- 上級DNS服務器中要注冊其下級域的DNS服務器IP地址，然后上級DNS服務器IP地址要注冊到更上一級的DNS服務器中，此次類推
- 根域的DNS服務器信息保存到互聯(lián)網(wǎng)中所有的DNS服務器中，這樣的話，所有的DNS服務器都會找到根域，然后一級一級的往下找，直到找到自己想要的那個域名
- 分配給根域的IP地址僅有13個，就是頂級域名（com,cn等）對應的ip地址具體交互就是下面這樣
但是一臺服務器存不下這么多，所以一般都是DNS服務器大接力來尋找這個ip地址，圖如下
客戶端找到最近的DNS服務器，查找www.jdl.cn的信息，可是最近的DNS服務器沒有這個信息，就轉發(fā)到了根域服務器下，經(jīng)過判斷發(fā)現(xiàn)是cn的頂級域名的，于是根域DNS服務器會返回它所管理的cn域中的DNS服務器的ip地址，接下來，最近的這個DNS服務器又回去訪問com域名的服務器，以此類推，最終會找到 www.jdl.cn這個服務器的IP地址
委托協(xié)議棧發(fā)送消息
知道了IP地址后，就可以委托操作系統(tǒng)內部的協(xié)議棧向這個目標IP地址發(fā)送消息了
- 瀏覽器、郵件等一般應用程序收發(fā)數(shù)據(jù)時用TCP
- DNS查詢等收發(fā)較短的控制數(shù)據(jù)用UDP
網(wǎng)絡分層
開放式系統(tǒng)互聯(lián)通信參考模型（英語：Open System Interconnection Reference Model，縮寫為 OSI），簡稱為OSI模型（OSI model），一種概念模型，由國際標準化組織提出，一個試圖使各種計算機在世界范圍內互連為網(wǎng)絡的標準框架。定義于ISO/IEC 7498-1。
TCP/IP（Transmission Control Protocol/Internet Protocol，傳輸控制協(xié)議/網(wǎng)際協(xié)議）TCP/IP協(xié)議不僅僅指的是TCP 和IP兩個協(xié)議，而是指一個由FTP、SMTP、TCP、UDP、IP等協(xié)議構成的協(xié)議簇， 只是因為在TCP/IP協(xié)議中TCP協(xié)議和IP協(xié)議最具代表性，所以被稱為TCP/IP協(xié)議
客戶端服務器傳遞數(shù)據(jù)流程
- 一個數(shù)據(jù)包從客戶端到服務端中間經(jīng)過每一層都需要加工處理
- 客戶端這邊需要不斷的給數(shù)據(jù)包添加頭部
- 服務端這邊需要不斷的拆分這個數(shù)據(jù)包
三次握手
當兩臺計算機要傳遞數(shù)據(jù)的時候，一定要先連接，得經(jīng)過TCP三次握手吧（僅僅指指走TCP協(xié)議需要連接的），我們平常都說TCP連接要經(jīng)過三次握手，我們就來看一下到底什么是TCP三次握手，如圖所示
- 客戶端要發(fā)送的時候，主動從closed狀態(tài)打開，服務器啟動后就一直處于監(jiān)聽LISTEN狀態(tài)
- 客戶端發(fā)送 SYN = 1,seq = x 給服務端，客戶端處于SYN_SEND狀態(tài)。
- 服務端收到后給客戶端發(fā)送 SYN = 1,ACK =1, seq = y,ack = x+1。此時服務端處于SYN_RCVD狀態(tài)
- 客戶端收到后發(fā)送ACK =1, seq = x+1,ack = y+1給服務器，此時客戶端狀態(tài)是ESTAB-LISHED
- 服務端收到后狀態(tài)變?yōu)?strong>ESTAB-LISHED
- 三次握手通過后，就代表客戶端和服務端可以傳遞數(shù)據(jù)包進行交互啦
- 我們說到SYN，ACK,seq,ack這些又是什么呢？這些其實是TCP數(shù)據(jù)包里的屬性，我們接著往下看(在傳輸層中有解釋)
應用層
HTTP數(shù)據(jù)包拆分
- 一般HTTP請求消息不會太長，一個網(wǎng)絡包就能裝的下
- 發(fā)送緩沖區(qū)中的數(shù)據(jù)如果超過MSS的長度，就會被以MSS長度進行拆分放進單獨的網(wǎng)絡包中
- MTU（Maximum Transmission Unit）:一個網(wǎng)絡包的最大長度，以太網(wǎng)中一般是1500字節(jié)
- MSS（Maximum Segment Size）:除去頭部之后，一個網(wǎng)絡包所容納的TCP數(shù)據(jù)的最大長度
傳輸層
- 然后上面應用層的這個網(wǎng)絡包再加上TCP頭部
TCP報文格式
- 源端口號（16位）：發(fā)送網(wǎng)絡包的端口號
- 目的端口號（16位）：網(wǎng)絡包的接受方的端口號
- 序號（發(fā)送數(shù)據(jù)的順序編號）（32位）：發(fā)送方告知接收方已經(jīng)收到了所有數(shù)據(jù)的第幾個字節(jié)
- 確認序號（接收數(shù)據(jù)的順序編號）（32位）：接收方告知發(fā)送方接收方已經(jīng)收到了所有數(shù)據(jù)的第幾個字節(jié)
- 頭部長度（4位）：表示數(shù)據(jù)的起始部分，數(shù)據(jù)偏移量
- 保留（6位）：該字段為保留，現(xiàn)在未使用
- 控制位（6位）：該字段中的每個比特位分別表示以下通信控制的含義
- ACK：表示接收數(shù)據(jù)序號字段有效，一般表示數(shù)據(jù)已被接收方收到
- PSH:表示通過flush操作發(fā)送的數(shù)據(jù)
- SYN:發(fā)送方和接收方相互確認序號，表示連接操作
- 窗口大小（16位）：接收方告知發(fā)送方窗口大?。礋o需等待確認可一起發(fā)送的數(shù)據(jù)）
- 校驗和（16位）：用來檢查是否出現(xiàn)錯誤
- 緊急指針（16位）：表示應急處理的數(shù)據(jù)位置
- 可選字段（可變長度）：除了上面的固定頭部字段外，還可以添加可選字段，但除了連接操作外，很少使用可選字段
還記得三次握手提到過的各種序號嗎，就是這個報文里的屬性
網(wǎng)絡層
IP報文格式
- 版本號（4比特）：IP協(xié)議版本號，目前是版本4
- 頭部長度（4比特）：IP頭部的長度，可選字段可導致頭部長度的變化，因此這里需要指定頭部的長度
- 服務類型（TOS）(8比特)：表示包傳輸優(yōu)先級。最初的協(xié)議規(guī)格里對這個參數(shù)的定義很模糊，最近DIFFServ規(guī)則重新定義了這個字段的用法
- ID號（16比特）：用于識別包的編號，一般為的序列號。如果一個包被IP分片，則所有分片都擁有相同的ID
- 標志（Flag）(3比特)：該字段有3個比特，其中2個比特有效，分別代表是否允許分片，以及當前分片是否為分片包
- 分片偏移量（13比特）：表示當前包的內容為整個IP消息的第幾個字節(jié)開始的內容
- 生存時間（TTL）（8比特）：表示包的生存時間，這是為了避免網(wǎng)絡出現(xiàn)回環(huán)時一個包永遠在網(wǎng)絡中打轉。每經(jīng)過一個路由器，這個值就會減一，減到0的是hi這個包就會被丟棄
- 協(xié)議號（8比特）：協(xié)議號表示協(xié)議的類型（以下均為16進制）
- 頭部校驗和（16比特）：用于檢查錯誤，現(xiàn)在已經(jīng)不在使用
- 發(fā)送方IP地址（32比特）：網(wǎng)絡包發(fā)送方的IP地址
- 接收方IP地址（32比特）：網(wǎng)絡包接收方的IP地址
- 可選字段（可變長度）：除了上面的固定頭部字段外，還可以添加可選字段，但除了連接操作外，很少使用可選字段
MAC數(shù)據(jù)包
- 接收方MAC地址(48比特)：網(wǎng)絡包接收方的MAC地址，在局域網(wǎng)中使用這一地址來傳輸網(wǎng)絡包
- 發(fā)送方MAC地址(48比特)：網(wǎng)絡包發(fā)送方的MAC地址，接收方通過它來判斷是誰發(fā)送了這個網(wǎng)絡包
- 以太類型（16比特）：使用的協(xié)議類型。下面是一些常見的類型，一般在TCP/IP通信中只是用0800和0806這兩種。
MAC地址 VS IP地址
- 為什么需要MAC數(shù)據(jù)包呢？因為在以太網(wǎng)的世界中，TCP/IP這個思路是行不通的。
- 以太網(wǎng)在判斷網(wǎng)絡包目的地時和TCP/IP的方式不同，因此必須采用想匹配的方式才能在以太網(wǎng)中將包發(fā)往目的地，而MAC地址就是干這個的
- 發(fā)送方MAC地址：MAC地址是寫在網(wǎng)卡生產(chǎn)時寫入ROM里的，只需要將這個值讀取出來寫入MA頭部就好了
發(fā)送方的MAC地址還比較容易獲取到，但是接收方的MAC地址就不太容易獲取到了
ARP廣播
- ARP :Addresss Resolution Protocal 地址解析協(xié)議
- 根據(jù)IP地址查詢接收方MAC地址的時候會用到ARP廣播
- 在同一個子網(wǎng)中，利用廣播對所有設備提問 XXX這個ip地址是誰的，其他設備發(fā)現(xiàn)自己的ip地址是這個xxx的話，那么他就會把它的MAC地址告訴提問者，這樣就會檢測到接收方的MAC地址了，如果發(fā)現(xiàn)自己的ip地址不是這個XXX，那么則會丟棄這個消息并不去理會。
- 如果每次都去廣播的話，那么網(wǎng)絡中就會增加很多ARP包，所以為了提高效率，我們有ARP緩存在內存中。查詢之前先去查詢ARP緩存。
- 當目的地的IP地址對應的MAC地址變了的話，那么這個MAC緩存就會出問題，所以為了避免這種問題發(fā)生，這個緩存幾分鐘后會被刪除，非常簡單粗暴。
- 動態(tài)ARP：會過段時間自動失效（文中說的就是它）
- MAC頭部：以太網(wǎng)用的頭部，包含MAC地址
總體數(shù)據(jù)包
這個時候的數(shù)據(jù)包變成了這個樣子
MTU（Maximum Transmission Unit）:一個網(wǎng)絡包的最大長度，以太網(wǎng)中一般是1500字節(jié)
MSS（Maximum Segment Size）:除去頭部之后，一個網(wǎng)絡包所容納的TCP數(shù)據(jù)的最大長度
然后這數(shù)據(jù)包，沿著網(wǎng)卡出去，到集線器，路由器一頓傳輸（中間涉及到電信號轉換等等），到達服務端那邊，再一層一層的扒皮（前往中說過，一層一層的拆分數(shù)據(jù)包）
斷開連接
四次揮手
兩臺計算機最后連接結束后要斷開連接，進行四次揮手
其實三次握手，四次揮手還有好多好多知識點要說，像什么為什么握手需要三次，而揮手需要四次啦這些問題，以后小杰會單獨和大家聊這個，記得收看呀
本站僅提供存儲服務，所有內容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權內容，請
點擊舉報。
