如果你是一個網絡從業者,一定學習過 OSI 7 層模型,長期以來,這一直作為我們理解和解決網絡問題的基石存在。
然而,2023年9月,Robert Graham 在Google文檔發表了一篇名為“OSI Deprogrammer,重新構想網絡空間”的文章,并主張“OSI模型必須淘汰!”
Robert Graham曾在20世紀90年代末擔任Network General的首席架構師,為OSI和TCP/IP編寫代碼。本文的大部分內容來自他從不同角度看待網絡的經驗,而不僅僅是OSI或TCP/IP的角度。其后也在數據中心工作了多年,解決了很多互聯網的核心問題,除了實踐經驗外,他還綜合了很多學術論文的觀點。
Graham在摘要中表示,OSI模型是一個徹頭徹尾的謊言,沒有任何幫助。除了作為20世紀70年代大型機的歷史注腳外,它應該被徹底移除。
我們普遍理解的OSI 7層模型每層都有其獨特的功能:
物理層:處理硬件,如電纜和網卡。
數據鏈路層:確保連接設備之間有牢固的鏈接,并處理錯誤。它定義了“幀”——物理鏈接可使用的最大單元,并標識了鏈接上的內容。
網絡層:使用鏈路層的幀和鏈路層標識在不同網絡之間發送數據。
傳輸層:管理設備之間的數據流并修復錯誤。
會話層:使用一個或多個底層傳輸設置并維護應用程序之間的連接。
表示層:確保數據可讀且安全。
應用層:軟件應用與網絡進行交互的地方。
Graham認為,OSI模型存在多個方面的問題:
它基于過時的、大型機時代的概念,強調跨過程調用棧的嚴格功能分離,而這些概念已不再適用。
它缺乏靈活性,實際上網絡中的功能可以在不同上下文之間交叉。調用可以進入傳輸層(TCP、UDP),影響網絡和鏈路層(IPv4或IPv6,以及以太網或光網絡)在會話方面的行為。
它對網絡交換的哪些部分發生在本地,哪些發生端到端以及在此過程中客戶端和服務器的各自角色方面施加了限制。
本文重點選取了“誤解”一章的部分內容,這一章中Graham揭露了諸如“分層”之類的普遍“錯誤”觀念。
01OSI 不是通用理論
OSI 被視為理論的主要原因是很多人并不知道它的含義。該模型包含很多只適用于大型機網絡的術語。大家不了解大型機,所以當遇到一個本應特定于大型機的術語時,他們反過來強行將其重新解釋,讓它來做到包含所有網絡通用的含義。
這一點在“會話層(session)”尤為明顯。在 OSI 命名這一層時,它與一般會話無關,而是與將終端連接到大型機的非常具體的問題有關。他們甚至可以用許多同義詞來稱呼它:連接層、通道層、討論層、對話層、交互層、關聯層等等。
我們所認為的會話 (如在HTTP中)實際上在 OSI 中稱為關聯(associations),并分配給應用層。
而OSI 的會話從來就不是指我們現在所認為的抽象的、理論性的概念。它從不包含HTTP會話cookie、SSL會話握手和NetBIOS會話服務等內容。
人們往往會被自己的無知所迷惑。他們不知道OSI最初的session是什么意思,所以相信它可以是任何意思。這就導致了每個人的解釋都不一樣的問題。這同樣適用于幾乎所有其他OSI術語。它們都有特定的含義——對大型機而言。我們不清楚這些詞在其他語境中到底是什么意思,所以每個人都在對它們的意思做出自己的解釋。
02OSI不是一個框架
OSI 模型中的“層”有兩個用途。第一個是協議的具體設計。第二個是某種分類法、層次結構、分類系統、類別、框架、時間線、位置或本體論。即使沒有協議屬于這層,也會將概念分配給層。
例如,沒有表示層協議,但盡管如此,人們還是將功能分配給該層,例如加密或壓縮。
我們現在將功能分配給層的方式實際上很大程度上都是用的TCP/IP 模型。今天的傳輸層幾乎從未像 OSI 那樣定義,而取決于 TCP 如何定義自身。
實際上,網絡的大多數功能都可以發生在任何層。
例如,我們分配給傳輸層的大多數功能,連接、分段、流量控制和重傳實際上可以在任何層發生。
我們所看到的分配給層的功能來自于重新解釋。將以太網和TCP/IP協議的功能分配給最近的OSI層,然后根據以太網和TCP/IP的功能定義OSI層。由于TCP 支持這些功能(連接、分段、流量控制、重傳),并且我們將 TCP 指定為Transport傳輸,因此我們聲稱這些是傳輸層的功能。
層中定義的真正功能實際上很小。例如,OSI 對傳輸層的真正定義是它是端到端的,其中端點被定義為在兩臺計算機上運行的進程。就這樣,沒有更多了。
所有層都是如此。OSI 幾乎沒有為任何特定層分配任何內容,現在分配給特定層的大多數功能都是由多個 OSI 層處理的。
03OSI前 3 層是虛構的,下4層也不準確
OSI 模型有 7 層。然而,在當今的互聯網上,只有最后 4 個以任何合理的形式存在。這給很多人帶來了難題,他們往往選擇以下兩種策略之一:
1)忽略上面 3 層,重點關注下面 4 層。
2)制作一些東西來填充上面 3 層。
OSI 模型的上面 3 層是虛構的,下面 4 層大致映射到以太網 MAC+PHY 和互聯網 TCP/IP。
這里的一個問題是,以太網和互聯網實際上并不符合這 4 層的原始定義,即 20 世紀 70 年代創建的定義。為了讓它變得合適,他們對 OSI 的說法以及以太網和互聯網的工作原理“撒了謊”。
最大的謊言是假裝以太網不是網絡。
以太網是一個成熟的網絡,它根據目標地址逐跳轉發數據包。這就是以太網交換機內部發生的情況。然而,為了能夠合理解釋這一切,他們創造了一些新詞,例如, 當以太網執行中繼時,將中繼稱為“橋接”,而當互聯網執行中繼時,將中繼稱為“路由”。事實上,它的功能相同,只有細微的差別。
同樣,TCP/IP 互聯網是一個互聯網絡 ,而不是 OSI網絡層設想的網絡,必須對它們最初的含義“撒謊”,才能夠自圓其說。
同樣的情況也發生在互聯網上,互聯網確實在以太網上運行,但在一個模型中一起展示細節是錯誤的抽象層。正確的抽象層是在本地網絡(如以太網)上定義互聯網。然后我們可以展開子層,顯示每個子層如何執行相同的功能。這樣,上2層就不會與下2層糾纏在一起。
04OSI 的“層”概念并不存在
除了列舉具體的層之外,OSI 還將分層(layering)作為一個抽象概念。
例如以下抽象,其中每一層都是根據它如何與這一端的相鄰層交互來定義的,同時與遠程端的對等層進行通信。
但實際上沒有任何層純粹以這種方式工作。
網絡堆棧最重要的原則是事物是分層的。但這并不意味著存在固有的層次,即某些東西屬于 某個特定的層次。
我們喜歡分層的是整個網絡。互聯網是一個完整的網絡。在ISP中,它可能位于MPLS之上,MPLS 也是整個網絡。MPLS本身可以在本地鏈路上分層,包括以太網,這是一個完整的網絡。
分層的另一種類型是協議。它們是在彼此之上運行的,但這并不意味著它們屬于堆棧中的某個位置。
例如,MS-RPC一種重要的 Microsoft 協議,下圖是它的原理圖。它基于各種協議,而這些協議又相互疊加。
這里沒有一致的框架。“事物”只是分層在其他“事物”之上。
有些人可能會聲稱 IPv4 和 IPv6 是同一“層”的替代“協議”,但事實并非如此。它們實際上是同一協議的兩個版本。它們與互聯網堆棧的其余部分(例如TCP、UDP、ICMP、DHCP、DNS等)集成度太高。唯一可以實際聲明層的地方是整個網絡的抽象層,例如Internet 層或以太網層。
層的一個重要概念是它們彼此獨立。而 OSI 并沒有能夠體現這一點。互聯網沒有固定的層數。當數據包通過互聯網傳輸時,它們下面的層數會發生巨大變化。同樣,頂部的層數也根據應用而變化。然后還有諸如 VPN 之類的東西,它們將互聯網置于自身之上。
05數據包標頭
OSI 強調數據包沿層傳遞,每層添加一個標頭。有時在數據包嗅探器中看起來是這樣,但這不是正確的抽象。相反,協議在其有效負載中封裝了其他內容。
下面是Wireshark的圖片,它是一個數據包嗅探器,可以從本地網絡捕獲數據包。該顯示共有三個窗格。
頂部窗格顯示已捕獲的數據包列表。
底部窗格顯示數據包的原始十六進制轉儲。
中間窗格“解碼”十六進制轉儲,顯示原始字節的含義,例如對應于IP 標頭的字節。
以下是與上面相同的數據包的十六進制轉儲,并對每個標頭進行了著色:以太網、IPv4、TCP,然后是 SSL (TLS) 記錄標頭。
OSI 通過數據包在一端沿網絡堆棧下行來描述這一點,每一層都添加自己的標頭。該過程在接收時相反,每一層在傳遞到上面的下一層之前剝離自己的標頭。
這種概念化的方式并不適用于所有情況,在實踐中只有偶爾才能發生。
特別是TCP 的有效負載是字節流,而不是數據包。當 TCP 有效負載較小且適合單個段時,它看起來符合上圖。但在其他情況下,單個 TCP 分段可能攜帶多個有效負載,或者有效負載可能跨越多個 TCP 分段。
下面的Wireshark 捕獲中可以看到這兩種情況都發生了。SSL (TLS) 將數據作為一系列記錄進行傳輸。我們看到單個 TCP 段可以包含多個 SSL 記錄,并且一個 SSL 記錄可以跨越多個 TCP 段。
在下面的數據包中,我們在單個 TCP/IP 數據包中看到五個 SSL 記錄。其中四個記錄完全包含在數據包中,而第五個記錄跨越該數據包的末尾和下一個數據包的開頭。
用上面的圖來畫這個,就會變成下面這樣:
這類錯誤在現實世界中具有重要意義。以Snort IDS為例。它嘗試通過搜索數據包中的簽名 (特定攻擊特有的字節模式)來檢測黑客活動。它將每個TCP 段視為僅包含一個SSL 記錄,并且無法檢測到不符合此條件的攻擊。
關鍵字“depth”是從數據包有效負載的開頭而不是流的開頭開始測量的。例如,以下是著名的 OpenSSL Heartbleed攻擊的簽名,與|18 03 03 00 40| 的 SSL 記錄標頭匹配。在數據包的前五個字節中。
但是,正如我們在上面看到的,SSL 記錄標頭可以出現在 TCP 有效負載中的任何位置,而不僅僅是數據包邊界。TCP 確實有數據包邊界的概念,這是只有我們人類才能看到的東西。以下是利用Heartbleed 的數據包 ,它不會觸發上述簽名,因為它在前面插入了 7 字節的 TLS 記錄,將包含攻擊的第二條記錄推入數據包的更深處,超出了 depth:5 的 限制。
在當今的網絡堆棧中,這種向數據包添加標頭的模型實際上只出現在兩個地方。一個是內核添加組合的 TCP/IP 標頭,另一個是添加以太網標頭:
這與替代的兩層模型一致,即互聯網在以太網等本地網絡上運行。
盡管我們在數據包中看到一系列的標頭,但實際的層邊界并不完全落在我們看到的線上。它們是一個偶然的產物,而不是被設計成這樣工作的。
06僅本地可見性
OSI 模型假設所有層作為單個網絡一起工作,所有內容都遵循相同的模型。
事實是,我們只能了解本地網絡或互聯網上發生的情況。我們的數據包到底發生了什么細節對我們來說是不透明的。下圖重新繪制了上面的模型,其中左側符合我們的網絡,但網絡的其余部分如何未知,有時層數較少,有時層數較多。我們無法了解網絡的其余部分是如何構建的。
07控制協議
大家根據數據傳輸方式來學習分層,但對于控制信息如何傳輸存在很多困惑。
我們需要DHCP 來配置IP地址。
我們需要ICMP 來控制消息。
我們需要 ARP 和NDP 來查找以太網上的MAC 地址 。
我們需要DNS 將名稱轉換為地址。
我們需要以太網中的一個子層來自動協商鏈路速度。
我們需要TCP中的SYN和FIN數據包來創建和銷毀連接。
我們需要完全脫離網絡堆棧的SSL證書管理。
WiFi 需要與接入點關聯。
在所有層,有時我們還需要身份驗證以確保安全。
所有層上都有大量的網絡管理正在進行,跟蹤計費和監控等使用情況。
數據如何傳輸是容易的,但控制是困難的。
當試圖將 OSI 模型應用于TCP/IP時,它被徹底歪曲了。盡管像DHCP這樣功能運行在UDP 之上,但它們并不是“應用層”的一部分。DHCP的功能是IP 協議功能的重要組成部分。這同樣適用于BGP,盡管它運行在路由器之間的 TCP 連接上,但它確實是 IP“層”的一部分。
08OSI 從不是真正的標準
Graham 一直在反復強調,當前我們所學的或者是別人教授給我們的,并不是原始的 OSI 標準,而是他們自己的非標準解釋。
OSI 從來就不是一種理論或正確的框架。人們如此重視它的部分原因是因為它被認定為“標準”。換句話說,如果大家都采用了這個標準,那么它就成為了理論和框架。
但 OSI 失敗了。1980 年左右的學術論文和早期教科書是錯誤的,因為沒有人真正采用該框架,OSI 最初的計劃從未完成,已被互聯網淘汰。盡管官方標準文件存在,但它是一個已失效的標準。這是謊言,不是真理。無論有多少標準組織堅稱這是事實,它仍然是一個謊言。
OSI 是由不懂網絡的人編寫的。他們專注于終端與大型機的對話,因為這是他們自己的大部分個人經驗。OSI 就是這樣設計的。
1981 年,當 Tanenbaum 創建第一本計算機網絡大學教科書時,TCP/IP 尚未發布。這在某種程度上是正確的,因為當時大多數學術論文都以某種方式引用了 OSI 模型。但后期的 OSI只是通過強行解釋,讓它來適配當今互聯網的發展模式。
互聯網并不是因為它而發展的。
09爭 議
研究科學家George Michaelson表示對Graham的觀點并不完全贊同。Michaelson介紹,自己自1982年以來就一直在這個領域工作,曾在英國的VAX VMS系統上使用PL/1編寫OSI傳輸類1、2和3的早期實現,并在1985/6年在倫敦的UCL-CS參與了由Marshall Rose監督的項目,后來成為ISODE系統。其現在在應用領域工作,涉及到X.400和X.500系統(電子郵件和目錄服務)。
Michaelson稱QUIC協議在UDP上保持連接狀態的做法很好地符合會話層的定義。它保存的狀態使應用程序在底層網絡發生變化時保持靈活。這正是OSI模型中會話層所執行的一些功能。同樣,TLS模塊模擬了會話層行為。
Michaelson還認為物理-鏈接-網絡的抽象不可被摒棄,因為這些概念與我們的理解密切相關。Michaelson強調,模型不僅是一本規則書,更是相互理解和進一步討論的基礎。
總的來說,Graham的文章推理嚴密,感興趣的朋友可以點擊閱讀原文查看完整內容,也歡迎大家在評論區發表自己的觀點!
審核編輯:湯梓紅
-
網絡
+關注
關注
14文章
7514瀏覽量
88626 -
物理層
+關注
關注
1文章
148瀏覽量
34286 -
OSI
+關注
關注
0文章
81瀏覽量
15403 -
模型
+關注
關注
1文章
3171瀏覽量
48711
原文標題:是時候放棄 OSI 七層模型了嗎?
文章出處:【微信號:SDNLAB,微信公眾號:SDNLAB】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論