路由、流量控制和防火牆/流量控制
 |
此頁面或部分內容是未完成的草稿或大綱。 您可以幫助 完成這項工作，或者您可以在 專案室 中尋求幫助。 |
Switch>> traffic}>- switch
切換}<block_link_from_fore_poin_/\link
\/heck
Blocked
流量
Block traffic network link from the hacker system google
基於 IP 的分組交換網路本質上是無狀態的。這意味著流經網路的每個新資料片段理論上都與之前的所有資料片段完全獨立處理。這使得從許多獨立部分構建大型網路變得非常容易，但在分配有限資源方面存在缺點。如果一個網路使用者正在傳送網路所能支援的最大數量的資料包，那麼其他使用者理論上可能最終無法傳輸任何資料。來自郵件、Usenet 或 DNS 更新的大量低優先順序流量可能會淹沒像 VoIP 這樣的高優先順序流量。如果 DNS 重新整理或電子郵件延遲 30 秒，沒有人會受到影響，但如果 VoIP 資料包發生同樣的情況，呼叫可能會被結束通話。
流量控制是試圖透過對資料進行分類，並根據網路管理員設定的規則來阻止、重定向或限制資料來解決網路這一普遍弱點的一般術語。
佇列是保留的記憶體塊，可以容納一定數量的等待順序處理的物件。佇列使用的典型模型是物件從一端推入，從另一端拉出以進行處理。這意味著物件按其進入的順序完全相同地處理：First In First Out 或 FIFO。在流量控制的上下文中，佇列中的物件是網路資料包。
FIFO 佇列本身不執行任何流量控制。實際上，網路堆疊的預設行為（沒有配置流量控制）是使用單個 FIFO 佇列，因為這提供了一種中立的方式來處理網路資料包，不會偏袒任何源。實際上，網路堆疊的實現至少需要一個 FIFO 佇列，因為資料包的到達速度可能比網路堆疊處理的速度快得多。在繁忙時，必須有一個緩衝區來儲存資料包，否則許多資料包將被丟棄。由於佇列是有限的，如果資料包的到達速度過快，持續時間過長，則始終有可能丟失資料包，但如果佇列的大小合理，這將成為罕見事件。
為什麼網路必須基於 FIFO 佇列？FIFO 的相反是 LIFO，或 Last In First Out，通常稱為堆疊。考慮一下如果我們將 LIFO 儲存用於我們的緩衝區會發生什麼。資料包 A、B、C 和 D 緊隨其後地到達（資料包 D 在網路堆疊有機會開始處理它們之前到達）。由於我們從最後一個數據包開始，網路堆疊自然會先處理資料包 D，然後處理資料包 C。在鏈路的另一端，資料包會以不同的順序到達。雖然更高級別的協議被設計為從亂序到達的資料包中恢復過來，但這會導致資料包丟失並重新發送，因此會浪費資源，並且在有簡單方法避免這種情況時，不應該依賴它。
但是，使用堆疊有一個更深層次的問題：如果資料包的到達速度恰好與處理器處理的速度相同，那麼我們每次都會處理最新到達的資料包。資料包 A 和 B 將停留在堆疊中，永遠不會被處理。最終，兩端的客戶端將假設資料包已丟失，並（如果使用像 TCP 這樣的協議來保證傳輸）重新發送資料包。這意味著浪費了資源兩次傳送 A 和 B，並且緩衝區被遺忘的資料包堵塞。
佇列傾向於確保每個資料包花費在等待處理上的時間儘可能相似（即最壞情況不會比最好情況差太多，儘管如果流量水平不一致，它仍然會有很大差異）。另一方面，堆疊傾向於導致最壞情況和最好情況相差懸殊，這在網路中從來不是我們想要的。
資料包和幀這兩個術語都指的是跨網路傳輸的資訊塊；這兩個術語之間的區別僅僅是它們在網路堆疊的不同層使用。在第 2 層（例如乙太網）中，被傳輸的塊稱為幀，而在堆疊的上一層網路層（例如 IP）中，它們被稱為資料包。
在物理鏈路傳輸的任何時候，說這兩種型別都被傳輸是同樣正確的，一種包含在另一種中（例如，包含在乙太網幀中的 IP 資料包），但是為了簡化實現模型，通常一次只考慮一種模型。乙太網幀包含一些有效負載（實際上可能是 IP 資料包），但是乙太網協議實現者可以忽略它所承載資料的實現細節。同樣，IP 資料包必須透過某種物理方式傳輸（實際上可能是透過乙太網幀），但是 IP 協議實現者可以忽略這個細節。
您可能會想忽略資料包和幀之間的區別，因為實際上幾乎沒有歧義。事實上，許多非正式文件和營銷材料往往模糊了這種區別。但是，本書將嘗試一致地使用這些術語，並鼓勵您也這樣做。