单端端口聚合与环路
端口聚和旨在以太网链路上做负载或者提供冗余备份，它和另一种方案有着根本的冲突，因为它不但可以做冗余，还可以做负载，然而传统以太网上根本就不可以做多路径负载均衡！以上说的另一种方案就是物理环路+STP的方案。因此在以太网部署端口聚合一定要注意，它最好是封闭的，也就是说，如果你在一台设备上启用了端口聚合，那么对端设备也要同样的聚合，确保不发生环路，检测手段有mac flapping报警信息等

传输网络与IP网络
学校里或者工作中，我们遇到的几乎都是IP网络，从socket到网卡驱动调优。也许参加过Cisco，华为培训的同学们可能听说过帧中继，ATM，X.25等，但是大体也只是听说而已，并没有亲见。实际上，IP网络只是一套寻址网络，真正传输数据的是IP网络层以下的技术，也就是上面说到的那些广域网技术，大体上，核心网络的拓扑并不像我们的公司那样，基本上都是一些带有自愈功能的大环结构，具体的封装可以采用各种技术，但是几乎没有直接用IP封装的，因为IP交换并不是真正的交换，而是需要额外的一些计算在里面，这些额外的计算就是路由查找和地址解析，核心网上的交换基本都是真正的交换，就是说通过简单的映射匹配就能知道该往哪个端口传输数据，而这正是ATM，MPLS等技术的强项，因此我们习惯于把这些技术称作封装IP数据报的链路层技术，而实际上它们真的就是链路层技术吗？如果上层承载的是IP网络，那么它们确实是，如果上面承载的是传输层，那么它们其实也可以被看作是网络层技术，事实也如此！这些广域网技术还不是真正的传输技术，它只是一种封装，传输技术就和介质相关了，比如光纤上的SDH，SONET，铜线上的SDH等等。然而我们可以看到，SDH是可以直接传输IP报文的，因为它自己有帧封装机制，凌乱了吧？
        要想真正理解网络的分层，我觉得可以通过Open×××的tun/tap模型来类比，把Open×××当成是一个物理层，那么tap就是链路层，如果说tun只能承载IP数据报，那么Open×××就是带有帧封装功能的物理层。

计算和传输之间的暧昧和较量
是什么原因降低了用户使用网络的体验，是网速，因为核心网传输资源在云环境下非常珍贵，所有的用户都要分享这珍贵的资源，并且，用户的流量类型五花八门...网络基础设施的扩容建设必须提上日程，这是一个不争的事实。另一方面，终端的类型越来越多，处理能力越来越强，这又衍生出了越来越多，越来越丰富的流量，底层网络传输能力的不足这件事越来越明显！
        能不能让处理器和网络之间配合一下，削平波峰和波谷呢？答案是肯定的！很多的网络加速方案的思想都和Linux的rsync思想差不多，就是尽可能通过执行设计精妙的算法，尽可能少的传输数据，减少带宽使用，取而代之的是传输少量的控制信息，其思想和压缩算法也有些一致。这种加速方案的核心即，将复杂且占带宽的数据编码映射成简单的索引，首先在传输数据前先传输索引，然后再使用动态的算法传输数据或者索引，下面举一例子：
数据：汪迪有时去拉面馆就是说不是每天都去更不是每天中午都去，但是这同样也不意味着他有时去的那一次当中每次去拉面馆都能吃完一碗拉面，并且也并不肯定每次去吃的都是拉面！
索引：拉面馆-1；每次-2...（数字编码比汉字编码简单得多！！）
如果可能，传输的数据将会是1，2，而不是拉面馆，汪迪，中午等编码。最终网络的压力卸载给了CPU的计算，搜索，插入...这里的例子并没有说明匹配规则以及不命中时的处理。

SSL与软件UI外观
都说SSL×××不需要安装客户端，实际上也还是需要客户端的，那就是浏览器，正是因为大多数的浏览器实现都将内置SSL作为 了一种标准来实现，所以看起来就是不需要客户端了。我并不是在批评SSL，相反，正是浏览器越来越多的取代了其他的客户端，SSL×××才风靡。这说明大 多数的数据都可以在浏览器中来操作，大多数（如果不是所有的话）的应用都可以基于WEB来实现。
        人们越来越关注的是数据本身而不是操作数据的手段和界面，曾经，几乎每一个软件客户端都有换肤功能，我也为用java 1.4.2不调用Native method写一个不规则窗口而几个晚上不睡觉，可是现在这些不再被人们所关注了，所有的操作基本都能靠四四方方规规矩矩的浏览器来完成，人们不再对软件的UI形状有过高的要求，而是把这种要求直接付诸硬件，现在不是有物联网了嘛，一个很炫的手表，不规则形状的播放器，它们要比在显示器上显示一个模拟的很炫的钟表，不规则的播放器要有吸引力的多！

以太网的路由
以太网就不是一个交换网络，在从源到目标的过程中，它的帧头就是可以利用的最底层了，你无法利用物理层的丰富的“首部”字段吧，以太网帧头本身也没有什么太丰富的字段，因此它是简单的。实际上完全可以实现一个基于MAC地址的类似IP路由那样的路由机制，然而它最终将比IP路由更加难以管理，因为你知道，IP路由的掩码/前缀的作用多么的巨大，可是MAC地址却是完全没有规律的，不能进行路由汇聚和子网划分，路由条目将完全是明细路由，在以太网这样的地址空间支持比较好的主动路由寻址，将是多么的困难，困难之处并不是人们认识到的那样：增加以太网的复杂性，而是以太网的地址空间本来就不是用来路由寻址的，每一个MAC地址都是基于全球唯一性来指定的，而不是在一张设计的网络拓扑中被指定的。
        路由式以太网是一定要设计出来的，以太网上急需多路径负载均衡转发，动态最短路径转发，这一切单凭被动的STP是做不到的，相反由于STP的存在，一些本应该可以转发流量的备份路径却被当做环路的元凶被kill掉，STP难道就不能智能一些，识别一下流量的细节？

负载均衡/虚拟化与IP地址
如果说上一个小节得出了MAC地址不适合被路由因此必须设计新的地址空间以及新的封装头这个结论是MAC不如IP的另一个说法的话，那么可以说IP还真是五十步笑百步。为什么这么说呢？诸多的路由协议不是在已有的IP网络上工作得很好吗？事实是，在没有引入负载均衡虚拟机，备份技术时是工作的很好，因为IP地址本身就被设计用来寻址，寻找世界上处在任何地点的全球唯一的IP节点，然而负载均衡和虚拟化打破了这个全球唯一标识的定义，对于负载均衡而言，逻辑上对外呈现的是一个IP节点，可是物理上参与寻址的却是多个IP节点，你要考虑最终将数据送到哪一个IP节点，这就分出了层次，而IP协议并不支持这种分层，在技术上，内网NAT技术以及Linux的IPVS等等诸如此类的技术修补性地解决了这个问题。虚拟机技术从另一个角度说明了IP寻址的不合理性，我们经常在局域网内拷贝虚拟机，可是在拷贝完了之后很多时候都要修改其IP地址，否则就会IP地址冲突，事实上，虚拟机还是那样虚拟机，之所以要有多个虚拟机是因为我要么想提供一个负载均衡功能，要么想提供一个备份功能，对外仅仅呈现一个IP地址，也就是说把IP节点的角色和位置分开，这种需求其实可以用×××+NAT来满足，举个最简单的例子，北京和上海两大备份中心均可以使用192.168.1.13这个表示角色的地址（如果不使用私有地址，那也就不用NAT了），到底数据被路由到哪里由×××封装策略决定，事实上封装可以解决一切寻址问题，但是却并不漂亮。以上的需求呼唤出来的是另一种协议，那就是LISP，它提供了双IP寻址结构，仔细看看它的面孔就会发现它和IPSec多么的相似，只是内层数据不加密而已，内部的IP头指示角色，外部的IP头负责寻址，它之所以不被称作×××是因为它更标准些罢了。

MPLS比IP快在哪里
MPLS部署在运营商级别的网络上，被称为一种交换网络，或者一种2.5 Layer网络，它比纯IP快是因为纯IP网络的路由查找过程中的计算过程比较耗时，而查找并交换标签却是很快的，MPLS利用动态路由协议生成的路由以及标签分发协议生成一个标签交换表，并不是被动得在数据实际到来的时候在生成映射，而是主动的在数据到来前就生成，这样在路由数据的时候，就可以直接用了，并且基于标签的交换式传输，本身效率就很高。实际上，MPLS并不是新的东西，标准IP网络路由的最长掩码匹配规则只是一种最原始的回退手段，很多的实现都要比这个高效，比如Cisco的CEF技术，即使Linux也可以使用Netfilter提供的接口来实现类似CEF的技术，MPLS与这些技术的不同之处在于，它是一种标准化的协议，而不仅仅是一种优化手段，标准和优化的区别在于，虽然可能标准化的MPLS协议对交换式网络的优化可能还没有CEF这类优化手段高，但是标准可以衍生出很多其它的优化手段，标准可以获得最多数设备的直接支持。

封装，还是封装
封装会将OSI模型搞得七零八落吗？很多人多说是的，但是并不绝对！标准的封装是下层封装上层，可是出现上层封装下层并不是说打破了OSI模型，要记住这种封装并不是处于一个逻辑层次上的，举例说明，×××的封装可以是IP封装以太帧，然而IP是寻址层面上，而以太帧则是×××的P层面上的。总之，封装这个设计实在是太好了，它几乎可以解决网络上的任何问题，基于这种思想，越来越多的协议被设计出来，起初是GRE，×××，后来有了MPLS，LISP等，它们要么解决安全问题，要么解决兼容问题，要么解决性能问题以及可扩展问题，相反那些不是基于封装而被设计的协议，比如STP等，可扩展性就没那么强了，不过这并不绝对，路由协议也不是基于封装的，然而它却工作的很好，特别是和协议无关的路由协议，比如ISIS。

Cache思想和LISP
CPU在读数据的时候，会尝试去Cache读取，如果没有Line命中，才会将请求发到总线上去。这种思想在互联网上也是有的，特别是物联网铺开以后，快速转发数据就成了最根本的原则，而快速转发的最大瓶颈就是路由查找和策略路由计算，如果节点数量增加，核心设备的路由条目势必增大，计算就更慢了。LISP做的比较好，LISP设备内部保存一些映射条目，用于直接转发数据的路由依据，在所有的LISP设备之上，又有一个BGP网络，负责在没有条目命中的时候查询路由。之所以设计这么一个层次是因为LISP将节点角色和位置分开了，因此即使两个角色处于同一个网段，它们实际上的位置也可能相距×××，LISP路由条目是一个角色/位置下一跳的映射，不再支持汇聚，没有汇聚，路由条目就会大大增加，因此LISP设备的路由条目索性就干脆退化成Cache吧，仅仅保留很少的条目做到快速转发，而将所有没有命中的数据包统一发送到它的一个BGP邻居那里去，由它来完成慢速路由，然后回送一个Cache更新。
        LISP的精妙之处在于解耦合了很多因素，比如角色/位置的解耦合，明细路由条目匹配/路由查找计算的解耦合，一台LISP设备仅仅需要负责查找条目，将不命中的包发给自己的BGP邻居，接收路由条目这些操作即可，路由计算之类的慢速操作由专门的设备来完成。那么它和×××封装有区别吗？数据层面上没什么太大的区别，但是在设计思想上区别就大了。

×××的控制粒度
IPSec控制的粒度很粗，因为IP协议本身只提供逐跳传送服务，并不针对任何上层协议进行任何的假设。因此，如果想用IP层的×××来实现应用层的控制，你就不得不求救于外部的类似扩展access-list的东西，即使这样，acl也不一定能帮你太多，毕竟它只能控制到五元组的粒度，Linux的iptables string match也许可以帮到你，但是那样的深度解析难度太大，iptables近期推出的L7 match效果也不如想象的那么好，因此基本上外援是无效的，所以用IP层的×××来控制应用层服务，效果不好。最好的还是要用应用层本身的访问控制来实现×××网络准入，记住，这是以下技术PK的年代：a.网络层的FW策略可以控制ssh登录；b.sshd的配置文件也可以控制ssh的登录！

网络管理员和系统管理员的交叉
程序员在互联网上创造价值，系统管理员企图传播这种价值，而网络人员使得这种价值得以传播，三者缺一不可。进入虚拟化时代以后，网络管理员和系统管理员就有了交叉，比如网管不单单是完成布线，配置端口策略等等就完事了，因为虚拟化时代的端口也许也是虚拟的，网管不得不“侵入”到系统管理员的领地，去配置一些虚拟化管理层面上的东西，因此网管不可一世的年代也随之而去。