网络协议栈的一些问题--附带设计问题

1.网络地址转换是对ip架构的一种讽刺还是一种补充，要知道nat的实质，就是臭名昭著的中间人攻击。
2.上层修改下层地址，路由器修改以太头，tcp和udp也能通过不变端口的nat，而应用层的路由器则是代理服务器，最典型的例子可能还是要属于邮件传输代理了。
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连接，就这么简单，接下来再看代码，就会觉得没有那么复杂了。总之，记住，一定从全局着眼，不要迷失于细节，当总体把握后，再关注一个一个的细节问题。