序列程式設計/序列連線上的 IP

序列程式設計
序列連線上的 IP

序列程式設計: 介紹和 OSI 網路模型 -- RS-232 佈線和連線 -- 典型的 RS232 硬體配置 -- 8250 UART -- DOS -- MAX232 驅動器/接收器系列 -- Windows 中的 TAPI 通訊 -- Linux 和 Unix -- Java -- Hayes 相容調變解調器和 AT 命令 -- 通用序列匯流排 (USB) -- 形成資料包 -- 錯誤校正方法 -- 雙向通訊 -- 資料包恢復方法 -- 序列資料網路 -- 實際應用開發 -- 序列連線上的 IP

概述

先決條件

本頁假設讀者熟悉 TCP/IP 協議族和一般的 IP 通訊。

關於術語的說明

本模組使用正常的 TCP/IP 術語，其中術語表示以下內容

TCP: TCP 協議本身，在傳輸層。
IP: IP 協議本身，在網際網路層。
TCP/IP: 完整的網際網路協議族，包括比 TCP 或 IP 更多的協議。

此外，本模組使用 TCP/IP 的協議層符號，而不是 OSI 模型，除非另有說明。

+--------------------+
| Application Layer  |  e.g. SMTP
+--------------------+
| Transport Layer    |  e.g. TCP
+--------------------+
| Internetwork Layer |  e.g. IP
+--------------------+
| Link Layer         |  e.g. SLIP or PPP
+--------------------+

問題

概述

透過序列 (RS-232) 線傳輸 IP 資料會遇到一些問題，其中包括：

缺少幀
缺少流量控制
缺少會話管理

其中缺少幀是最嚴重的問題。所有提到的問題都將解釋如下。

缺少幀

不同的層在 TCP/IP 協議棧中承擔不同的任務。上層協議期望下層協議提供特定的服務。IP 協議期望鏈路層提供的服務之一是 IP 資料包的幀和去幀。這意味著，鏈路層負責在資料包透過通訊鏈路時正確分離每個資料包並識別 IP 資料包的開始和結束。鏈路層應該這樣做，以便在將資料包放置在某個資料流中時，可以正確地從資料流中提取它們。

在使用“裸”序列連線作為鏈路層的情況下，會產生一個問題，因為簡單的序列連線不提供任何幀功能。相反，資料只是一個流。接收方將無法明確識別資料包的開始和結束。

在 100% 可靠的序列連線中，這可以容忍，因為 IP 資料包中的長度資訊可以用來將資料包從序列資料流中分離出來。但是，連線通常不是 100% 可靠的，特別是如果它是透過調變解調器在公共電話線上進行的。如果資料包被損壞、部分丟失等，接收方將失去同步，傳輸將完全混亂。如果可以可靠地識別損壞的 IP 資料包，TCP 等上層協議可以處理問題並啟動重新傳輸。因此，正確識別，以及 IP 資料包的幀/去幀是必不可少的。

缺少流量控制

由於序列連線的性質，需要對序列連線躍點進行流量控制。但是，IP 沒有提供任何在鏈路層控制流量的機制，TCP 等協議使用完全不同的方式進行端到端流量控制，並且根本不處理單個躍點。

缺少會話管理

在序列線上執行 IP 時，通常需要做一些額外的“管理工作”，特別是當該序列線由調變解調器連線支援時。這包括建立這樣的調變解調器連線（撥號到某個遠端站點）並在該遠端站點進行身份驗證。IP 本身不支援這些任務。

解決方案

概述

解決上述問題的辦法是在鏈路層引入一個額外的協議。該協議實際上代表了上層協議的鏈路層，並在內部使用序列連線。

目前常用的協議有兩種。一種非常簡單的協議叫 SLIP，另一種更復雜但更強大的協議叫 PPP。新服務通常使用 PPP，而 SLIP 仍然可以在一些舊服務中找到。

+-------------+
| TCP         |
+-------------+
| IP          |
+-------------+---------------+
| Link Layer  | Modem Control |
+-------------+---------------+
| Serial Line                 |
+-----------------------------+
| Modem                       |
+-----------------------------+
| Phone Line                  |
+-----------------------------+

SLIP

SLIP 解決了將 IP 資料報傳送到序列線上的一個最嚴重的問題：缺乏幀定界。流量控制由調變解調器傳輸協議和更高級別的 TCP/IP 協議處理。會話管理應該在 SLIP 之外處理，例如調變解調器連線的設定（“撥號”）不是由 SLIP 完成的。SLIP 假設序列連線已經建立。

SLIP 在 RFC 1055 中進行了標準化，標題為 *透過序列線路傳輸 IP 資料報的非標準方法：SLIP*。標題中的 *非標準* 一詞源於歷史原因。SLIP 很久以來都沒有被描述，直到它最終在 RFC 1055 中被描述，這個描述僅僅是作為對當時實踐情況的非正式總結。直到後來才決定將該 RFC 賦予 IETF 官方標準的地位，但由於 SLIP 的侷限性，它不應該成為首選。

SLIP 非常簡單，幾乎令人尷尬。它需要 8 位資料位、無奇偶校驗和硬體流控制或 CLOCAL 模式（3 線空閒模式）的序列埠配置。它只定義了四個特殊的 8 位序列（字元）和很少的功能，超過了標準的序列線路協議。

十六進位制值	八進位制值	縮寫	描述
0xC0	0300	END	幀結束
0xDB	0333	ESC	轉義
0xDC	0334	ESC_END	轉置的幀結束符，在轉義序列中使用
0xDD	0335	ESC_ESC	轉置的轉義符，在轉義序列中使用

當 SLIP 驅動程式從互操作層接收 IP 資料報時，它簡單地逐位元組複製（除了一個小的例外，見下文）並附加一個值為 0xC0（十六進位制）的額外位元組。這個額外的位元組標記 IP 資料報的結束，因此稱為 *END* 字元。

為了避免隨機線路噪聲被解釋為資料報的開頭，習慣上在 IP 資料報之前新增 *END* 字元，如果資料報不是連續且以全速傳送到線路上的，並且傳輸恢復。這樣，可能的隨機噪聲本身就被封裝成一個數據報，而更高層（特別是 IP 層）將丟棄這些“資料報”，因為它們將被識別為非法的（錯誤的校驗和、錯誤的大小、低於最小大小）。

連續傳送時的幀

+-----------------+-----------------+-----------------+
| IP datagram |END| IP datagram |END| IP datagram |END| ...
+-----------------+-----------------+-----------------+

延遲傳送資料包時的幀，在資料包之前新增額外的 END 字元以排除線路噪聲

+-----------------+            +----+-----------------+            +----+-----------------+
| IP datagram |END| line noise |END | IP datagram |END| line noise |END | IP datagram |END| ...
+-----------------+            +----+-----------------+            +----+-----------------+

上圖中用紅色標記的 END 字元是在它們後面的 IP 資料報之前新增的 END 字元。但它們實際上充當前面線路噪聲的結束標記，將潛在的隨機線路噪聲與真實資料分開。

用 0xC0 *END* 字元進行幀定界會產生一個問題。如果該字元本身出現在 IP 資料報中，SLIP 會錯誤地將它解釋為資料報的結束。這個問題透過引入另一個特殊字元 *ESC* 字元（值為 0xDB（十六進位制））來解決。它用於構建兩個轉義序列

0xDB 0xDC: 替換 IP 資料報內的 0xC0 值
這確保了傳輸資料報中永遠不會出現 *END* 字元
0xDB 0xDD: 替換 IP 資料報內的 0xDB 值
這是“轉義轉義”字元。

SLIP 將這些轉義序列插入它從互操作層接收的 IP 資料報中進行傳輸，並在轉發接收到的資料報到互操作層時用原始值替換轉義序列。

這就是 SLIP 所做的全部。沒有錯誤檢測、壓縮或裝置（調變解調器）控制。也沒有對主機配置、安全性、會話管理和其他控制功能的支援。因此，SLIP 本身在容易出錯的撥號連線上並不令人滿意，儘管它在 MNP4（或更高版本）錯誤糾正調變解調器鏈路上可靠地執行。

PPP

PPP（點對點協議）提供了一種標準方法，用於在點對點鏈路上傳輸資料報，包括標準序列線。PPP 的規範定義了以下三個主要組成部分

一種在 PPP 幀中封裝資料報的方法。它支援 IP 資料報以及其他網路協議的資料報。
鏈路控制協議 (LCP)。該協議定義了建立、配置和測試資料鏈路連線的過程。
一個網路控制協議 (NCP) 家族，用於建立和配置不同的網路層協議。

PPP 是一個相當複雜的協議，由強制性和可選部分以及擴充套件組成。下面列出了一個可能不完整的 PPP 相關 RFC 標準列表

RFC 1661 - 點對點協議 (PPP)
RFC 1332 - PPP 網際網路協議控制協議 (IPCP)
RFC 1334 - PPP 認證協議
RFC 1377 - PPP OSI 網路層控制協議 (OSINLCP)
RFC 1378 - PPP AppleTalk 控制協議 (ATCP)
RFC 1552 - PPP 互操作分組交換控制協議 (IPXCP)
RFC 1570 - PPP LCP 擴充套件
RFC 1618 - PPP over ISDN
RFC 1662 - PPP 在類似 HDLC 的幀定界中
RFC 1962 - PPP 壓縮控制協議 (CCP)
RFC 1968 - PPP 加密控制協議 (ECP)
RFC 1973 - PPP 在幀中繼中
RFC 1989 - PPP 鏈路質量監控
RFC 1990 - PPP 多鏈路協議 (ML)
RFC 1994 - PPP 質詢握手身份驗證協議 (CHAP)
RFC 2043 - PPP SNA 控制協議 (SNACP)
RFC 2097 - PPP NetBIOS 幀控制協議 (NBFCP)
RFC 2125 - PPP 頻寬分配協議 (BAP) / PPP 頻寬分配控制協議 (BACP)
RFC 2290 - PPP IPCP 的移動 IPv4 配置選項
RFC 2364 - PPP over AAL5
RFC 2472 - PPP 上的 IPv6 版本
RFC 2516 - 透過乙太網傳輸 PPP 的方法 (PPPoE)
RFC 2615 - PPP over SONET / SDH

待辦事項
以某種方式標記與序列線路通訊相關的 RFC。可能根本不提及其他 RFC。

簡而言之，實現 PPP 並非易事。這是一項嚴肅的任務，需要紮實的程式設計、協議和電信知識，即使只考慮與序列線路通訊相關的部分。希望實現 PPP 的程式設計師應該提前預留數週時間來學習相關標準。定義需要實現哪些可選 PPP 部分的明確需求也是一個好主意。還應該考慮獲得相容性測試套件以驗證自身實現的標準符合性。對現有協議消費者實現進行簡單的試錯通常不切實際。這隻能在一定程度上“保證”PPP 實現與特定配置下的特定其他實現相容。它不能保證該實現與各種現有的 PPP 實現相容。

如果購買特定平臺的 PPP 實現是一個可行的選擇，而不是進行自己的實現，那麼應該認真考慮這個選擇。

HDLC

HDLC（高階資料鏈路控制）是另一個第二層協議，可用於在序列（和其他）連線上承載 IP 流量。HDLC 早於 PPP 並且是一個通用的第二層協議。它可以在工業應用中找到，並且在 IP 路由器之間的序列點對點鏈路中也很流行。它在終端使用者應用程式（如撥號連線到 ISP）中並不常見。關於 HDLC 的維基百科文章提供了關於 HDLC 的良好概述，並提供了對相關標準的引用。

HDLC 主要關注幀定界，並提供了一些額外的控制訊息（*過程*）。它在序列線上相對容易實現。

序列程式設計: 介紹和 OSI 網路模型 -- RS-232 佈線和連線 -- 典型的 RS232 硬體配置 -- 8250 UART -- DOS -- MAX232 驅動器/接收器系列 -- Windows 中的 TAPI 通訊 -- Linux 和 Unix -- Java -- Hayes 相容調變解調器和 AT 命令 -- 通用序列匯流排 (USB) -- 形成資料包 -- 錯誤校正方法 -- 雙向通訊 -- 資料包恢復方法 -- 序列資料網路 -- 實際應用開發 -- 序列連線上的 IP