Linux 高效能伺服器程式設計-TCP/IP 協議族

Dragonbuf發表於2018-10-09

1.1 TCP/IP 協議族體系結構以及主要協議

file

1.1.1 資料鏈路層

資料鏈路層實現了網路卡介面的網路驅動程式,以處理資料在物理媒介上的傳輸。

資料鏈路層兩個常用的協議:

  • 地址解析協議:ARP (Address Resolve Protocol )
  • 逆地址解析協議: RARP (Reverse Address Resolve Protocol)

他們實現了 IP 地址和機器實體地址(通常是 MAC 地址,乙太網、令牌環和802.11無限網路都使用 MAC地址)之間的相互轉換。

網路層使用 IP 地址定址一臺機器,而資料鏈路層使用實體地址定址一臺機器。

ARP 協議用途:
網路層必須先將目標機器的 IP 地址轉化成期實體地址,才能使用資料鏈路層提供的服務,這就是 APR 協議的用途。
RARP 協議用途:
RARP 協議僅用於網路上的某些無盤工作站,因為缺乏儲存裝置,無盤工作站無法記住自己的 IP 地址,但他們可以利用網路卡上的實體地址來向網路管理者(伺服器或網路管理軟體)查詢自身 IP 地址,執行 RARP 服務的網路管理者通常存有該網路上所有機器的實體地址到 IP 地址的對映。

1.1.2 網路層

網路層實現資料包的選路和轉發
  • 廣域網 :WAN (Wide Area Network)通常使用眾多分級的路由器來連線分散的主機或 LAN
  • 區域網:LAN(Local Area Netword)

    通訊的兩臺主機一般不是之間相連的,而是通過多箇中間節點(路由器)連線的,網路層的任務就是選擇這些中間節點,以確定兩臺主機之間的通訊路徑。同時,網路層對上層協議隱藏了網路拓撲連線的細節,是的在傳輸層和網路應用程式看來,通訊的雙方是直接相連的。
    核心協議:因特網協議 IP(Internet Protocol):

    IP 協議根據資料包的目的 IP 地址來決定如何投遞它,如果資料包不能直接傳送給目標主機,那麼IP 協議就為它尋找一個合適的(next hop)路由器,並將資料包交付給該路由器來轉發。最終到達目標主機或因傳送失敗而被丟棄。可見 hop by hop 的方式確定通訊協議。

    因特網控制報文協議 ICMP(Internet Control Message Protocol)

    它是 IP協議的重要補充,主要用於檢測網路連線,報文格式如下:

    file

    8位型別欄位主要用於區分報文型別。它將 ICMP報文分為兩大類:

    • 一類是差錯報文,這類報文主要用來回應網路錯誤,比如目標不可到達(型別為3)和重定向(型別為5)
    • 另一類是查詢報文,這類報文主要用來查詢網路資訊。比如 ping 程式就是使用 ICMP報文檢視目標是否可達(型別為8)。有的 ICMP報文還是用8位程式碼欄位來進一步細分不同的條件。比如重定向報文使用程式碼值0表示對網路重定向,程式碼值1表示對主機重定向。

    ICMP報文使用 16 位校驗和欄位對整個報文(包括頭部和內容部分)進行迴圈冗餘校驗(Cyclic Redundancy Check, CRC),以檢驗報文在傳輸過程中是否損壞。ICMP 協議並非嚴格意義上的網路層協議,因為它使用處於同一層的 IP 協議提供的服務(上層協議使用下層協議提供的服務)

    1.1.3 傳輸層

    傳輸層為兩臺主機上的應用程式提供端到端(end to end)的通訊。

傳輸層只關心通訊的起始端和目的端,而不在乎資料包的中轉過程。
file
資料鏈路層(驅動程式)封裝了物理網路的細節。網路層封裝了網路連線的細節。傳輸層則為應用層封裝了一條端到端的邏輯通訊鏈路,它負責資料的收發、鏈路的超時重連等。

傳輸層協議:
  • 傳輸控制協議:TCP協議 (Transmission Control Protoclo)
    為應用層提供可靠的、面向連線的和基於流的服務。TCP 協議使用超時重傳、資料確認等方式來確保資料包被正確地傳送至目的端,因此 TCP 服務是可靠的。使用 TCP 協議通訊的雙方必須先建立 TCP 連線,並在核心中為該連線維持一些必要的資料結構,比如連線的狀態、讀寫緩衝區,以及諸多定時器等。當通訊結束時,雙方必須關閉連線,釋放核心資料。TCP 資料基於流,沒有長度限制。
  • 使用者資料包協議 UDP協議(User Datagram Protocol)
    它為應用層提供不可靠、無連線和基於資料包的服務,無法保證資料從正確的傳送到目的端。且舞連線,通訊雙方不能保持一個長久的連線,且 UDP資料包都有一個長度。接收端必須以該長度為最小單位一次性讀出,否則資料會被截斷。
  • 流控制傳輸協議 SCTP協議 (Stream Control Trasmission Protocol)
    為因特網上傳輸電話訊號而設計

    1.1.4 應用層

    應用層負責處理應用程式的邏輯。

資料鏈路層、網路層、和傳輸層負責網路通訊細節,所以在核心空間實現,應用層多在使用者空間實現。

應用層協議:
  • ping 是應用程式,利用 ICMP報文檢測網路連線。
  • telnet 是遠端登入協議
  • 開放最短路徑優先: OSPF(Open Shortest Path First): 動態路由更新協議,用於路由器之間的通訊,以告知對方各自的路由資訊
  • DNS(Domain Name Service 域名服務)協議提供機器域名到 IP地址的轉

    應用層協議可能跳過傳輸層,之間呼叫網路層的服務,比如 ping 和 OSPF 協議。 可通過檢視 /etc/services 檢視所有知名的應用層協議。

1.2 封裝

上層協議通過封裝(encapsulation)使用下層協議提供的服務。

file

應用程式在傳送到物理網路上之前,沿著協議棧從上向下傳遞,每層協議都在上層協議的基礎上加上自己的頭部資訊(有時包括尾部資訊)

經過TCP 封裝後的資料稱為 TCP報文段 (TCP message segment),或簡稱 TCP 段。 TCP頭部資訊 和 TCP核心緩衝區(傳送緩衝區或接受緩衝區)一起構成了TCP報文段。
file

當傳送端應用程式使用 send (或 write)向一個 TCP 連線寫入資料時,核心中的 TCP模組首先把這些資料複製到與該 TCP連線對應的 TCP 核心傳送緩衝區中,然後TCP 模組呼叫 IP 模組提供的服務,傳遞的引數包括 TCP 頭部資訊和 TCP 傳送緩衝區中的資料。
經過 UDP封裝後的資料稱為 UDP資料包(UDP datagram)。UDP無需為應用層資料儲存副本,因為其本身是不可靠的,當一個 UDP 資料包 被髮送以後, UDP 核心緩衝區中的該 資料包就被廢棄了,如果重發,則應用程式需從使用者空間將該資料包拷貝到 UDP 核心傳送緩衝區中。
經過 IP 封裝後的資料稱為 IP 資料包,IP 資料包包括頭部資訊和資料部分(TCP報文段、UDP資料包或 ICMP報文)。
經過資料鏈路層封裝的資料稱為幀(frame)。傳輸媒介不同,幀的種類也不同,如乙太網傳輸以太幀,令牌環網路上傳輸令牌環幀。
乙太網幀使用6最的目的實體地址,6位元組的源實體地址來表示通訊雙方,CRC對幀的其他部分提供迴圈冗餘校驗。
file
幀的最大傳輸單元(Max Transmit Unit,MTU),即幀最多能攜帶多上上層協議資料(如IP資料包),通常受到網路型別限制。 如圖 乙太網幀的 MTU 為 1500 位元組。所以過長的 IP 資料包可能需要被分片(fragment)傳輸。

幀才是最終在物理網路上傳送的位元組序列。

1.3 分用

當幀到達目的主機時,將沿著協議棧自底向上以此傳遞。
各層協議依次處理幀中本層負責的頭部資料,以獲取所需的資訊,並將處理後的幀交給目標應用程式。
(dumultiplexing)

file
因為 IP 協議、ARP 協議、RARP 協議都使用幀傳輸資料,幀頭部提供欄位區分(具體取決於幀型別)。以太幀使用2位元組的型別欄位來標識上層協議。

1.4 測試網路

為了分析 ARP協議 IP 協議 ICMP 協議 TCP 協議 DNS 協議,來準備測試網路,包括 A B 主機。

file
對於路由器,不涉及 ISP (Internet Service Provider 因特網服務提供商),因為用不到。

1.5 ARP協議工作原理

ARP協議能實現任意網路層地址到任意實體地址的轉換。

主機向自己所在的網路廣播一個 ARP 請求,該請求包含目標機器的網路地址,此網路上其他機器都收到此請求,但只有被請求的目標機器會回應一個 ARP 應答,其中包括自己的實體地址。。

1.5.1 乙太網 ARP請求 / 應答報文詳解

file

  • 硬體型別:定義實體地址的型別, 1 表示 MAC 地址
  • 協議型別: 要對映的協議地址型別,如 0x800 表示 IP 地址
  • 硬體地址長度 + 協議地址長度 :單位 位元組, MAC 為 6, IP (v4)為 4
  • 操作: ARP 請求為 1 ,ARP 應答為 2 ,RARP 請求 為 3 ,RARP 應答為 4
  • 最後 4 個指定通訊雙方的乙太網地址和IP地址。傳送端填充除 目的端乙太網地址 外其他3欄位,構建ARP請求併傳送,接收端 把自己乙太網地址填進去,然後交換目的端地址和傳送端地址,然後構建ARP 應答。

1.5.2 ARP 快取記憶體的檢視和修改

ARP 維護一個快取記憶體,包括經常訪問(如閘道器地址)或最近訪問的機器的 IP地址到實體地址的對映。
避免重複請求,提高傳送資料包速度。

可使用 arp 命令來檢視和修改 ARP 快取記憶體,如使用 arp-a (ARP 快取記憶體是動態變化)

  • 刪除 ARP 快取: arp -d 192.168.1.109
  • 新增 ARR 快取: arp -s 192.168.1.109 08:00:27:53:10:67

1.5.3 使用 tcpdump 觀察ARP通訊過程

1.6 DNS 工作原理

1.6.1 DNS查詢和應答報文詳解

DNS  是一套分散式的域名服務系統。

每個DNS 伺服器上都存放大量的機器名和IP 地址的對映,並且是動態更新的,眾多網路客戶端都使用DNS 協議來向 DNS 伺服器查詢目標主機的 IP 。
DNS 查詢、應答報文:
file
16 位標識欄位用於標記一對DNS查詢和應答,以此區分一個DNS應答是哪個DNS查詢的回應。
16 位標誌欄位用於協商具體的通訊方式和返回通訊狀態。
file

  • QR : 查詢/應答標誌 。0 查詢 1 應答
  • opcode:定義查詢和應答型別;0 標準查詢 1 反向查詢(由IP地址獲得主機域名) 2 請求伺服器狀態
  • AA 授權應答標誌,僅應答報文使用, 1 表示域名伺服器是授權伺服器
  • TC 截斷標誌,僅當 DNS報文使用 UDP 服務時使用,因為 UDP服務由長度限制,1 表示 DNS 報文超過 512 位元組,被截斷
  • RD 遞迴查詢標誌。1 執行遞迴查詢(如果目標DNS伺服器無法解析,它將向其他伺服器繼續查詢,至遞迴到結果,並把結果返回客戶端) 0 執行迭代查詢 (DNS 伺服器無法解析,它將自己知道的其他DNS 伺服器的IP 地址返回給客戶端參考)
  • RA 允許遞迴標誌。 僅由應答報文使用 1 表示 DNS 伺服器支援遞迴查詢
  • zero 未使用,設定為 0
  • rcode 返回碼,表示應答狀態, 0 無錯誤 3 域名不存在

接下來 4 個欄位分別指出 DNS 報文的最後 4 個欄位的資源記錄數目。對於查詢報文 它包含一個查詢問題。 對於 應答資源記錄數、授權資源記錄數、額外資源記錄數 為 0. 應答報文的 應答資源記錄數至少為 1,而授權資源記錄數和額外資源記錄數可為0 或 非 0
查詢問題的格式如圖:
file
查詢名以一定的格式封裝了要查詢的主機域名。16 位查詢型別表示如何執行查詢操作,常見型別如下:

  • 型別A 值為 1 獲取目標主機的 IP 地址
  • 型別 CNAME 值是 5 表示獲得目標主機的別名
  • 型別 PTR 值 12 表示反向查詢
    16 位查詢型別通常為 1 ,表示獲取 IP 地址。

應答欄位、授權欄位、額外資訊欄位都使用資源記錄(Resource Record,RR)格式:
file

  • 32 位域名 是該記錄中與資源對應的名字,其格和查詢問題中的查詢名欄位相同。
  • 16位型別和16位類 欄位的含義也與 DNS 查詢問題的對應欄位相同
  • 32位生存時間表示 該查詢記錄結果可被本地客戶端快取多少秒
  • 16位資源資料長度和資源資料的長度取決於型別欄位。對於型別 A 資源資料是 32 位 IPv4 地址,而資源長度則為 4 個位元組

1.6.2 訪問 DNS 服務

/etc/resolv.conf 存放 DNS 伺服器的 IP 地址
向首選 DNS伺服器 查詢 IP 地址
host -t A www.baidu.com

1.6.3 使用 tcpdump 觀察 DNS 通訊過程

sudo tcpdumpt -i eth0 -nt -s 500 port domain
host -t A www.baidu.com

1.7 socket 和 TCP/IP 協議族的關係

作業系統需要實現一組系統呼叫,使得應用程式能夠訪問 資料鏈路層、網路層、傳輸層提供的服務。

實現這組系統呼叫的 API主要有兩套:socket 和 XTI(基本不使用)。
socket 定義的API 提供兩點功能:

  • 將應用程式資料從使用者緩衝區中複製到 TCP/UDP 核心傳送緩衝區,以交付核心來傳送資料(如 send 函式)或者是從核心 TCP/UDP 接受緩衝區中複製資料到使用者緩衝區,以讀取資料。
  • 應用程式可以通過它們來修改核心中各層協議的某些頭部資訊或其他資料結構,從而精細地控制底層通訊的行為。比如可以通過 setsockopt 函式 來設定IP資料包在網路上的存活時間。

    socket 是一套通用網路程式設計介面,不但可以訪問核心中的 TCP/IP 協議棧,而且可以訪問其他網路協議棧(如X.25協議棧、UNIX本地域協議棧等)

本作品採用《CC 協議》,轉載必須註明作者和本文連結

相關文章