網路通訊協定棧的一些問題–附帶設計問題

1.網路位址轉譯是對ip架構的一種諷刺還是一種補充，要知道nat的實質，就是臭名昭著的中間人攻擊。
2.上層修改下層地址，路由器修改以太頭，tcp和udp也能通過不變連接埠的nat，而應用程式層的路由器則是Proxy 伺服器，最典型的例子可能還是要屬於郵件傳輸代理程式了。
3.tcp/ip以及支撐其運作的物理網卡其實並沒有完整的實現分層模型，這一點從tcp校正碼的偽頭以及物理網卡的tso就可以看出來，不管是偽頭還是tso，都違背了分層的原則。
4.幾年前，曾經想通過gmail發送一個patch到一個maillist，可是該maillist規定所有的郵件必須以純文字的形式發送，並且對郵件用戶端有很多要求，最重要的恐怕就是“不允許郵件用戶端對郵件進行任何更改，哪怕刪除該用戶端認為多餘的空格都不行”。開始的時候，覺得gmail這麼厲害的傢伙，應該可以通過配置做到這點的，後來發現gmail著重於商務和交流，並不為如此底層的特性提供更多的配置，於是就放棄了gmail，註冊了另一個郵箱X，一直在linux下用命令列工作，感覺很好，直到有一天我必須在gui下工作的時候，哪怕只工作了一天，我就徹底對gui失去了信心。
     該工作的要求和maillist的要求一樣，必須使用純文字，使用UNIX的分行符號...並且郵件用戶端不能更改內容，好了，這些都能做到(windows和kde/gnome下都有X相應的用戶端，也很好)，那麼問題出在哪裡呢？出在gui的剪貼簿上，gui的剪貼簿在粘貼後有的時候並無法真實還原未經處理資料，特別是空格，換行，斷行符號，tab之類的，因此除非使用額外的工具，否則很難完成工作，要是換在linux命令列下，通過'|'很容易構建一條輸出和輸入首尾相接的透明管道，這在gui下是不可能的。
關於設計：
如果讀核心代碼時看不懂了咋辦，這種事經常發生，畢竟核心不是一個人寫的，甚至讀apache或者別的開源作品比如OpenSSL，OpenVPN，fetchmail等的時候也會遇到這種問題。其實很多人都是硬著頭皮去領會一段詭異代碼的含義，實際上沒有必要，以協議棧為例，如果你十分理解tcp/ip協議的原理，那你完全可以根據自己的想法先設計一個實現架構，然後拿來和既有的比如linux核心作比對，這樣我估計你能學到很多東西，如果僅僅迷失於既有的代碼，那麼肯定會事倍功半。
     linux核心關於related串連的實現是基於串連跟蹤的，如果按照自己的想法先想一番，肯定會在探測了ftp的資料連線請求後，會儲存連接埠和ip等資訊，然後在這些串連確實到達的時候將之設定為related串連，就這麼簡單，接下來再看代碼，就會覺得沒有那麼複雜了。總之，記住，一定從全域著眼，不要迷失於細節，當總體把握後，再關注一個一個的細節問題。