多圖慎入,從四層模型看網絡是怎麼鏈接的

你們好, 我是公衆號:java小杰要加油
今天來分享一個關於計算機網絡的知識點—— 網絡究竟是怎麼鏈接的?
  • 話很少說,直接開車

瀏覽器生成消息且發送

  • 發送一個消息的整體流程以下

生成HTTP請求消息

舉個栗子,當咱們在瀏覽器輸入https://www.jdl.cn/img/servic...網絡地址的時候java

  • 瀏覽器首先會對URL進行解析web

    • https:表示訪問數據源的機制,也就是協議
    • www.jdl.cn: web服務器名稱
    • img :表示目錄名
    • service.843585b7.png:表示文件名

而後就要生成HTTP消息了,它大概長這樣瀏覽器


這些字段具體內容是什麼能夠參考這篇文章五千來字小做文,是的,咱們是有個HTTP。緩存

DNS域名解析爲IP地址

瀏覽器生成了這個HTTP消息後,它要往哪裏發送呢?固然是服務器啦,因此就要解析這個域名對應的是哪臺服務器,IP地址是什麼,由於IP地址很差記,因此纔有了對應的域名,便於咱們人類記憶。服務器

  1. 瀏覽器會檢查緩存有沒有這個域名對應的ip地址
  2. 操做系統會檢查緩存(就是咱們日常說的hosts文件)
  3. 操做系統會發送給本地區的DNS服務器,讓它幫忙解析下

DNS服務器接受來自客戶端的查詢,包括如下三個內容網絡

  • 域名: 服務器,郵件服務器的名稱
  • Class: 在最先設計DNS時,DNS在互聯網之外的其餘網絡中的應用也被考慮到了,而Class就是用來識別網絡信息的,不過現在除了互聯網就沒有其餘網絡了,所以Class的值永遠表明互聯網的IN
  • 記錄類型: 表示域名對應何種記錄類型框架

    • A記錄時,域名直接對應IP地址
    • CNAME時,此域名對應其餘域名
    • MX時,表示域名對應的是郵件服務器

    對於不一樣的記錄類型,響應數據也不同spa

域名的層次結構

  • 越靠右層次越高,從右向左一級一級的劃分 : 例如 www.jdl.cn 就是cn->jdl->www
  • 具備這種層次結構的域名信息都會註冊到DNS服務器中,而每一個域都是做爲一個總體來處理的

客戶端和DNS服務器交互流程大概以下操作系統

  • 上級DNS服務器中要註冊其下級域的DNS服務器IP地址,而後上級DNS服務器IP地址要註冊到更上一級的DNS服務器中,這次類推
  • 根域的DNS服務器信息保存到互聯網中全部的DNS服務器中,這樣的話,全部的DNS服務器都會找到根域,而後一級一級的往下找,直到找到本身想要的那個域名
  • 分配給根域的IP地址僅有13個,就是頂級域名(com,cn等)對應的ip地址


具體交互就是下面這樣計算機網絡


可是一臺服務器存不下這麼多,因此通常都是DNS服務器大接力來尋找這個ip地址,圖以下

客戶端找到最近的DNS服務器,查找www.jdl.cn的信息,但是最近的DNS服務器沒有這個信息,就轉發到了根域服務器下,通過判斷髮現是cn的頂級域名的,因而根域DNS服務器會返回它所管理的cn域中的DNS服務器的ip地址,接下來,最近的這個DNS服務器又回去訪問com域名的服務器,以此類推,最終會找到 www.jdl.cn這個服務器的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數據的最大長度
  • 而後這數據包,沿着網卡出去,到集線器,路由器一頓傳輸(中間涉及到電信號轉換等等),到達服務端那邊,再一層一層的扒皮(前往中說過,一層一層的拆分數據包)

斷開鏈接

四次揮手

兩臺計算機最後鏈接結束後要斷開鏈接,進行四次揮手

其實 三次握手四次揮手還有好多好多知識點要說,像什麼爲何握手須要三次,而揮手須要四次啦這些問題,之後我會單獨和你們聊這個,記得收看呀

image

相關文章
相關標籤/搜索