关于关于--关于网络，关于还是关于

1.关于IPSec的实现和虚拟网卡的实现
freeswan作为IPSec的解决方案相对于OpenVPN来讲有很多相似之处，freeswan也是先将数据包路由到上层，然后经过IPSec的策略处理后重新发往下层继续路由，IPSec的方案省略了虚拟网卡的过程，将一上一下的过程完全在协议栈中特殊处理，因此需要修改协议栈，而是用虚拟网卡的方式却不需要修改协议栈，完全按照现在的协议栈架构来实现--网卡入数据必然从网卡来，出数据必然由网卡出(而非IPSec那样，网卡入数据可以由上层来，而链路层出数据可以经再封装)。
2.关于ASIC转发
三层交换机使用ASIC硬件芯片进行数据快速转发，三层交换机实现了路由器的功能，这个结论的本质在于缓存的使用，缓存绕过了路由查找的过程，直接将目的ip和出口设备进行对应，同时该结论还解释了为什么不淘汰路由器而全部使用三层交换机的原因。路由器中存储的路由表项，路由表项不可缺的是目的地址以及通往该目的地址的下一跳地址或者接口，路由器路由数据包的依据来自数据包的IP头，因为IP头中有目的地址，路由器的路由模块根据数据包IP头的目的地址查找到出口设备，然后将数据包IP层以及IP层往上的部分原封不到的从该出口转发出去(不考虑NAT以及链接跟踪的作用)，因此路由结果中最重要的东西就是这个出口设备，所谓的ip地址只不过是一个查找键，因此很直观的优化方式就是缓存“目的地址-出口设备”对，可是目的地址和出口设备的映射并不是一个简单的对应关系，比如一一对应关系，而是一个多对一的关系，因此这个缓存不易实现，需要大量的存储空间存储不同的目的ip地址，然后将它们统一映射到同一个出口设备，这种方式在公网大量不同目的的数据包情况下对于硬件实现来说尤其消耗资源，硬件倒是比较容易维护诸如少量固定的ip地址和出口设备之间的映射，这就是我们局域网的情况，但是局域网有路由的必要吗？没有！局域网是链路层寻址的，不需要ip路由，使用路由器有些大材小用了，真的是这样的情况，但是对于vlan来说就不同了，vlan虽然同在一个“实”lan，但是vlan之间的主机通信却需要路由，这时基于asci硬件缓存的三层交换机就有用武之地了，vlan中的三层交换机利用了“实”lan中ip地址(不同vlan)固定的特征，同时利用了硬件缓存的高效机制，一实一虚，一软一硬，真的很好。在公网上，由于目的ip地址不具备少量且固定的特征，因此不宜使用三层交换机。
3.关于MTU
MTU会限制接收数据的长度吗？不会的！MTU的本质是什么？在乎线路，在乎环境，还是在乎终端？如果MTU不会限制接收数据，那么为何ping一个超过MTU的超大包会导致持续丢包？那是因为IP分段增加了丢包率(一个片断丢失整个包将丢失，icmp不重发)，另外，以太网环境下，特别是使用hub和烂网线的情况下，丢包会很有规律的，甚至有时候超过1500的分段大小你是永远都收不到的，即使低于1500的分段在快速流量压制下也会有规律的持续丢包，导致ping百分之百失败，这真的不关你的机器或者网卡的事，而是以太网和双绞线自身的问题。两台机器，一台设置mtu为300，另一台设为1000，然后互相ping一个1300大小的包，没有问题的，但是ping包一旦超过1500(以太网的最大传输帧长度)就会随机出现问题或者没有问题，这不是mtu的问题，实际上mtu那么小根本就没有什么问题，而还是网线和以太网本身的问题，如果将mtu设置的大于1500，那么恶劣环境下，数据帧是无法被送达的。
     MTU描述的是线路环境的性质，可能会涉及一些网卡的性质，但是它终究是物理层的参数。比如以太网规定帧的最小长度以及最大长度，完全是以太网本身造成的，而不是硬性的规定，以太网的双绞线的电气特性，CSMA/CD协议的行为最终可以推出为何最小长度是46而最大长度是1500，这里说一下推倒过程，先考虑最小长度，为了让CSMA/CD任何情况起作用，首先必须在冲突冲突信号到来之前持续发送，如果不是这样，冲突信号到了数据也发送完了，这就会使网卡认为数据发送成功了，然而这是不对的，因此极端情况下设信号到达最大长度(由双绞线以及hub的电气特征决定)的时间为t，此时发生冲突，冲突信号到达发送端的时间显然也是t，因此发送端必须持续发送2t时间的数据，在10Mbps以太网上经计算最小的长度为46，100M的更长...。因此最小帧长度是CSMA/CD推导出来的，那么最大长度呢？那就要考虑另一个极端，假设一个网卡发送了数据的第一个位而没有冲突，它一直发送数据，到什么情况为止呢？到损害公平性时为止，如果不规定一个最大长度，该网卡实际上可以永远发送下去的，因此每当其它网卡要发送数据时，都将听到载波信号导致等待，因此以太网上的最大帧长是由于公平性而规定的。最终人们就可以将1500定位为以太网的MTU，注意，大于1500的帧能否通过就看以太网设备比如hub或者交换机会不会丢弃它们了(Giant帧)，有的会丢弃，而有的却不会。
转载一段：
发送和接受端如何感知冲突？
      假设：A、B两地间通过一个传送带链起来，传送带的滚动速度是C(C代表光速)，也就是20.3cm/ns(每纳秒20.3厘米)，A点有个人叫A1，他要把一车苹果分成一小堆一小堆的发送给B点的那个人B1，现则A1需要抉择的是：我在传送苹果给B1的时，如果B1同时也有苹果传给我，这个时候就会产生冲突，而冲突会把传送中的苹果撞碎，破碎的苹果渣会通过传送带反送给我，我很想知道是哪一小堆苹果被撞碎了，如何实现？一个办法就是：在我收到苹果碎片的时候，我仍旧在传着这堆苹果！比如有很多堆苹果，第1堆，第2堆等，当我发送第3堆苹果的过程中，收了苹果碎片，那肯定是第3堆里先发出的苹果出现了碰撞，而不是第2堆或第1堆中的苹果发生碰撞。
为了实现这一点，假如A到B点的距离是2500米(250000厘米)，传送带上的苹果每纳秒 20.3厘米，那么一堆苹果中的第一个苹果到达B点的用时就是250000除以20.3=12500纳秒，在加上碎片返回的时间是12500纳秒，等于 25000纳秒，这个时间就是一堆苹果必须持续的时间。
体力稍好的人，往传送带上放苹果的时候快，体力不好的就慢。体力稍好的人每秒可以往传送带上放100Mbit个苹果，换算一下，也就是说放一个苹果用10纳秒。体力不好的人每秒钟只能往传送带上放10Mbit个，也就是说放一个苹果用100纳秒。
因为一堆苹果必须持续的时间25000纳秒，那么对于体力不好的人，25000除以100=250个苹果，这个结果就是一堆苹果的数量。所以，理论上一个10Mbit/s的以太网，最小帧长应该是250bit。但为了确保碰撞切实的被检测到，最小帧长被定义为512bit(64字节)。
因为一堆苹果必须持续的时间25000纳秒，对于体力好的人，25000除以10=2500个苹果，这个结果就是一堆苹果的数量。所以，理论上一个 100Mbit/s的以太网，最小帧长应该是2500bit。但一个2500bit的帧又太大了，上层来的数据包不可能这么大。所以我们只能缩短A点到B 点的距离为250米，一个苹果在传送带上往返的时间也变成了2500纳秒。这时用2500除以10=250个苹果，这个结果就是一堆苹果的数量。所以，理论上一个100Mbit/s的以太网，最小帧长应该是250bit，网络最大有效距离是250米。但为了确保碰撞切实的被检测到，最小帧长被定义为 512bit(64字节)。
由此可见，MAC层发送的速度越快，以太网的最大有效距离就越短。
4.关于虚拟终端和虚拟网卡
虚拟网卡完美的实现了vpn，其完美之处在于数据进入虚拟网卡后从字符设备流出到用户空间，然后任由其它进程读取该字符设备然后任意处理。有一个更完美的类似机制，那就是虚拟终端，它甚至只用了一套成对的字符设备，例如/dev/ptmx和/dev/pty/X，写入/dev/pty/X的数据全部从/dev/ptmx流出到用户空间，它和虚拟网卡不同之处完全不在于实现方式，而在于应用场合，写入虚拟网卡的都是网络数据包，依靠路由将数据写入，由于数据包可以来自本机，也可以是forwarding的数据，因此虚拟网卡的数据来源有两处，对于虚拟终端，写入/dev/pty/X的都是使用终端的进程，比如shell和任何没有重定向标准输出的进程，因此/dev/pty/X的数据来源就只有一个，那就是用户态进程，不管怎样，/dev/pty/X对于使用终端的进程和/dev/ptmx都扮演了硬件的角色，进程认为数据写入了设备，而实际上却写入了用户空间，进程读终端认为数据来自底层，而实际上数据却来自用户空间，这点和虚拟网卡是一样的，路由过后，协议栈认为数据写入了网络线路，而实际上却写入了用户空间...虚拟网卡和虚拟终端的不同在于其应用的层次不同，虚拟网卡的应用者工作在网络层，而虚拟终端的应用者工作在应用层，它们也有相同的地方，用户态进程都扮演了硬件的角色。
5.关于OpenVPN中的MTU一致性
由于OpenVPN用户态进程扮演了硬件接收器的角色(类似光纤的光电转换器或者以太网卡的电磁感应器等)，那么按照道理来将应该是来多少数据收多少数据的，MTU对接收并没有什么影响，然而如果OpenVPN两端配置的MTU不一致，发送大MTU那么大的包时在小MTU一端就会按照小MTU值截断，这岂不违背了MTU的原理，本质上MTU是限制线路的，而不是限制终端的啊。是的，是违背了一些原则，可是要知道，OpenVPN是用recv或者recvfrom来接收数据的，这两个函数均需要一个接收长度参数，另外数据是经过SSL记录协议的，完全按照块传输加密解密的，并且为了安全和健壮，数据也不是来了就直接送往虚拟网卡的而要经过若干的判断，针对上述原因，如果想完全模拟硬件接收器，那么就必须有一个组包的逻辑，比如mtu值大的那一端发来了数据，长度超过了接收端的接收长度参数，数据显然没有完，OpenVPN必须缓存这个不完整的数据片断，然后还要想办法告诉发送端从而让发送端把截断之后的数据再发一遍，这显然增加了复杂性，这个复杂性太大以至于没有实现的必要。剩下一种比较好的方式就是mtu协商了，按照mtu较大的值接收数据，这是一个解决问题的办法，但是需要密切关注加密解密的问题。OpenVPN目前的实现是基于自己的MTU值来确定recv或者recvfrom中的接收长度的。总的来说，OpenVPN的mtu不但限制能发多大，并且限制能接收多大，不像真实的物理线路接收一点是一点逐渐累计，OpenVPN将数据截断后会导致解密出错，即使有重发机制，整个一段必须重发，重发的包又会被截断...因此OpenVPN中，起码在2.1.1以及之前的版本使用过程中，两端的MTU要配置成一致。
6.生育是生物问题，而优生则是社会问题。