2013-08-01 56 views
1

層關係,我有一個關於網絡層的問題,那就是:有關網絡

大家都知道,在層架構,N + 2層應該只依賴於N + 1層上,而對此一無所知N層。例如,在典型應用中,網絡層應該只依賴於商業邏輯層上,而不是數據訪問層

,當涉及到計算機網絡,事情似乎有所不同。在應用層,程序必須知道不僅傳歷程層(TCP端口),也是網絡層(IP地址)

這讓我困惑,你怎麼看?

感謝您的幫助。

+0

不幸的是生活並不是真的那樣。例如,TCP/IP以多種方式違反了該原則。 OSI堆棧試圖不去,但今天它在哪裏? – EJP

回答

2

通常你是對的。不幸的是,網絡中的圖層之間的邊界有點模糊,這不僅僅是因爲我們有一個未使用的標準(OSI)和事實上的標準,它不強制您提到的想法,而且還因爲協議通常不會嚴格地綁定到一個圖層但可以對其中的一個做更多的事情。在OSI模型之前和標準化之前已經開發出了大量的協議,然後對一些根本性的改變已經太晚了。所以有些協議被認爲是在兩層之間(或者在兩層之間),比如MPLS,ARP等。而且基於另一個協議的協議也是在同一層,就像OSPF一樣在IP之上運行,即使它們被認爲是在L3上。

你所提到的是另一個例子。原因在於尋址不是在最上層(應用層)上完成的,而是在網絡層(對於主機/網絡適配器)和傳輸層(對於進程/應用程序)中完成的。因此,您需要知道IP地址和端口號(實際上是協議)才能夠解決遠程應用程序的問題。這就是網絡套接字作爲應用程序和網絡之間的網關(或API)進入的地方。所以,即使你在技術上對抗分層模型的原理是正確的,但你並沒有對L3或L4做任何事情(但你可以))。您不需要對數據包進行分段,處理重新傳輸或擔心錯誤更正等,您只需在創建套接字時傳遞所需的尋址信息即可。

TCP/IP是對實施的可行性,其中OSI更關心的標準則該標準的實施更加註重。這是糟糕和好的一面。自由實施協議的能力可以是一個優勢,如果你使用這種能力很好,並且由於你沒有嚴格地約束某些規範,你可以更高效地做一些事情......或者是故事失敗。混合「責任」的缺點是顯而易見的,例如H.323等協議將IP地址嵌入到用戶的有效負載中,所以如果您想要執行NAT,您需要檢查有效負載,更改IP地址,重新計算校驗和以及像這樣的東西,而不是僅僅處理網絡層上的翻譯。

爲什麼東西還是這樣嗎?可能是因爲沒有簡單的方法來改變任何這種情況,因爲需要更新的設備和協議,應用程序等數量龐大,這需要花費很多時間。只要看看採用IPv6的速度已經超過15年了。

+0

非常感謝。你解釋得很清楚,不僅回答我的問題,而且還解決一些基本的想法。 – michael