最近在思考一個問題，圖書館里書越來越多，書店的書也越來越多，人類的問題非但沒有減少，反而越來越多？

我從事計算機網絡行業，談談我的觀點。

計算機網絡技術發展特別快，有些技術從誕生到消失可能只有幾年的時間，所以還沒有來得及出書，技術就消失得無影無蹤。

還有一些技術，比如NAT技術，盡管很常用也有技術標準，但是各個廠家的實現方式并不統一。技術標準是先有產品后來才有的技術標準，所以這種技術標準并沒有多大的用處，因為產品已經成型了。

但是，NAT技術并不需要不同廠家平臺的交互，所以不會有什么問題。不像路由協議需要交互信息，如果沒有嚴格遵照標準，可能就無法通信了。

所以像這些技術很難去出書，不像路由協議那么有廣泛性、代表性。廠家更愿意出一些配置文檔、白皮書供用戶參閱。

這些內容會告訴用戶如何配置、以及簡單的工作原理，但是很難找到這個問題的答案，這就是為何知乎等問答平臺可以誕生的原因。

問題來了，答主辛辛苦苦寫的文字，一分錢沒有，這種依賴雷鋒式奉獻精神的模式到底能走多遠？所以，我很不看好這個平臺，除非讓優質內容的輸出者得到自己應得的那一份。

聽聞Oracle關閉中國研發中心，波及1000多人，對于有扎實技術的骨干人員，重新找一份類似工作不難，但是沒有核心技術的人員，短期內可能會備受煎熬。

學好一門技術，可以拯救自己于危難時刻！

CPU進程轉發

IP報文到達入接口，轉交給軟件轉發進程，查詢路由表，找到對應出口及下一跳IP，查詢下一跳MAC，完成二層封裝，從出口發送出去。

硬件快速轉發

IP 報文到達入接口，硬件芯片查詢硬件轉發表，獲得對應出口及二層封裝，從出口發送出去。

硬件轉發要遠遠快于CPU進程轉發，相差至少一個數量級。有同學會疑惑地問，既然硬件轉發那么快，為何還用進程轉發呢？

硬件轉發芯片長于轉發流量，但是卻處理不了復雜的邏輯。

硬件轉發表是天上掉下來的餡餅嗎？不是的！

是天生就存在于硬件芯片里的嗎？ 不是的！

是硬件芯片自己學習到的嗎？不是的！

既然都不是，那是從哪里來的呢？

路由進程告訴的！

路由進程，是不是就是路由協議RIP 、OSPF、BGP之流？

對的。

路由進程跑在CPU上，路由進程和鄰居、整個網絡同步完路由表，將路由表(以二層轉發表的形式)下發到硬件芯片里，然后硬件芯片就可以愉快地工作了。

當路由器配置了NAT，路由器并不能將二層轉發表提前下發到硬件芯片，為什么呢？

每一個TCP/UDP會話的四元組(源IP，源端口，目的IP，目的端口)是動態的，這些動態的信息沒有辦法提前知曉。所以，TCP/UDP會話第一個報文到達路由器入口時，硬件芯片的轉發表(NAT表)是空的，必須交由CPU進程處理。

CPU最強大的地方，就是可以處理任何復雜的邏輯！NAT進程立馬介入，生成一個動態的NAT表條目，將IP報文的私有源IP+端口，替換成公網的IP + 端口，然后轉發出去。

完了嗎？

沒有！

NAT進程還需要將NAT轉發表下發到硬件，硬件芯片有了NAT表就變得強大了起來。如同加滿油的老司機，地板油走起，一路絕塵。。。

有乘客會問，TCP的第二個報文是CPU轉發還是硬件轉發？

老司機冷笑一聲，我都有了NAT表，可以獨自開車，為什么要勞煩CPU大神！

話音未落，老司機一個地板油，風馳電掣開始飆車，乘客發出鬼哭狼嚎的尖叫聲。。。

歸納一下

配置NAT之后，會對CPU有影響。至于影響多少，取決于有多少個全新的TCP/UDP會話數目。

相信這篇回答不會在任何教科書，或者廠家的配置文檔、白皮書里找到。如果喜歡這篇文章，請點贊支持，謝謝！

總結

以上是生活随笔為你收集整理的硬件nat关闭还是开启_路由器开启NAT和防火墙功能，性能会下降吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。