凌晨3点钟，半夜睡眼朦胧，忽然听到左右两耳嗡嗡，身下的榻榻米垫沙沙作响，以为在梦境，然而睁眼清醒过来，发现并没有看见什么，依然在黑夜， 于是确认这不是在在梦。于是开灯，发现一只蟑螂趴在垫子上，两只蚊子却早已不知所踪。旁边睡着小小，我怒抓起蟑螂跑到卫生间好一顿蹂躏，然后本想继续梦里 那些个没有完成的各种约，可是却再也睡不着了。
一想到一会儿就要坐528路公交车穿过可恶的沪太路，心里就很是不爽。每天这条路本就很堵，红绿灯又多，公交车停站点又多，我所谓的拥塞预测与避堵原则完 全失效，这条路上真的是走哪堵哪。不知道为什么放弃了坐地铁，可能是因为拥挤吧，自行车，电瓶车，轿车这种自路由的工具不在考虑范围，因为驾驶它们会占掉 我本来就不多的时间。不管怎么说是睡不着了，那就扯点关于高速网络卸载的东西吧。
早在几年前，就有一个想法，为什么一列火车要停站？为了上下客吗？那么不下车的乘客为何要为下车的乘客付出时间成本呢？当然，铁路运输方不会考虑这个，因 为它们认为这是一个固有延迟，就好像一个IP包进入路由器查询转发表的固有延迟一样。然而对于货运，人们可能会有一些不同的想法，一列货运火车开过一个货 站，货舱门打开，工作人员在车辆未停的状态下把要在该站卸载的货物一个一个往下扔，怕货物摔坏吗？垫一个弹簧垫子即可。同样的例子，你可以考虑空投和空 降，或者轰炸机投弹，你见过飞机先停下再扔东西或者扔人吗？不都是在速度保持的情况下卸载载荷的吗？
在货运和普通客运这种低速环境下，停站带来的固有延迟成本并不是很高，然而在高速甚至超高速情况下就完全不同了。对于客运来讲，人们当然不能说像扔货物一 样在列车不停的前提下把要下车的人往下扔，下面有个弹簧垫子.....但是我觉得这个是个技术问题，是完全可以解决的。首先，直接的想法就是下车的人自己 在车站前面一点往下跳，结果摔死了，然后为了不摔死，下面垫一些东西，结果还是残废了，最后，考虑到把下面全部都做成完全柔软的东西，结果安然无恙，但是 还是受到了惊吓....这不就是靠技术一点点解决的吗？人还是那些下车的人，动作依然是往下跳，不同的是结果。
难道就不能把“要下车的人自己跳向站前柔软气垫”的过程做的更好吗？
可以设想一个密闭的容器空间，将要下车的人提前进入这个容器，然后列车在到站前将该容器卸载，列车本身并不减速。至于说这个容器怎么停下来或者说停到哪里 去，这完全是它自己的事，难道你没有发现这是一个完全解耦合的典型例子吗？一般在电影里我们总是看到在列车上打斗的场景，一般都是火车的前半段有个炸弹， 主角最后打死反派，或者把反派困在放炸弹的车厢，然后转动一个把手，将列车的后半段与前半段脱离，前半段继续以不变的速度前行，后半段由于摩擦力自己停下 来了，然后就是轰的一声，电影基本就结束了。这不是一个典型的高速卸载例子吗？当然最后轰的一声那个除外。
可以将每车厢一个的这些下车容器挂在高速列车的旁边，车站附近会有专门的下客轨道和上客轨道，然后列车到站前X米的时候，将容器脱离到下客轨道上，此时由 于惯性该下客容器的速度依然与列车一致，但是之后，它可以采取制动措施，使得这个“小车厢”完全在车站停止。对于乘客而言，不会有任何不适的感觉。
对于上客，原则一样，也是这些容器，在车站的上客轨道上自行加速到一个和高速列车一样的速度，然后勾挂在列车上，乘客之后进入列车的车厢。这真是无级变速 啊！当然，前面提到的X米是多少，上客容器何时启动，，这些都是要经过周密计算的。我只是给出一点原理而已。
不下车的乘客再也不用受到下车乘客的干扰了。我觉得这才称得上是高铁啊！真正的高铁！如果我从上海要到深圳，我花费的时间几乎就是上海到深圳的高铁轨道长 度除以高铁的速度，这种不停站的设计可以让高铁以尽可能的完全匀速行驶，不再受到车站的影响。它将仅受制于天气，以及流量管制等不可抗因素。
轨道交通固然可以如此，IP网络则如何呢？目前的技术而言，很难！
但是光网络卸载技术确实是有的，举一个最简单的例子就会明白。光网络的复用是波分复用的，也就是波长复用，因此卸载的就是波长，从一个叠加波里面分离出一个特定的波长完全是一个物理过程，而这根本不需要花费延迟！光分离器，光交换机等就用了这样的原理。
然而，对于IP网络，这种电子数字网络，却很难如此。即便是Cisco的CEF这样的技术，也不能在将本地流量和转发流量区分的过程中不影响转发流量，路 由器或者交换机需要对数据包做逐一检测，以匹配到一个流或者一个别的什么策略上。高端的路由器所能做的，只是让这个检测过程尽可能的快。
发这种牢骚干什么？！IP网络之所以这样难道不是因为它就应该这样吗！像我前面说的，高速环境中分离出一支来，在物理层是最容易做的，何必要在IP层 做，IP层带来了复杂性的同时也带来了可控。在核心传输网，光纤上跑的就不是IP报文，它更像是IP报文经过调制后的物理层的流。各种xDM本质上都是用 到了这种分离叠加技术，在芯片内部，在主板上，在接入网，在传输网，你都会发现很多复用器，解复用器，分离器之类的东西，这些东西做的事情就跟轨道交通的 不停站卸载差不多。
一想到一会儿就要坐528路公交车穿过可恶的沪太路，心里就很是不爽。每天这条路本就很堵，红绿灯又多，公交车停站点又多，我所谓的拥塞预测与避堵原则完 全失效，这条路上真的是走哪堵哪。不知道为什么放弃了坐地铁，可能是因为拥挤吧，自行车，电瓶车，轿车这种自路由的工具不在考虑范围，因为驾驶它们会占掉 我本来就不多的时间。不管怎么说是睡不着了，那就扯点关于高速网络卸载的东西吧。
早在几年前，就有一个想法，为什么一列火车要停站？为了上下客吗？那么不下车的乘客为何要为下车的乘客付出时间成本呢？当然，铁路运输方不会考虑这个，因 为它们认为这是一个固有延迟，就好像一个IP包进入路由器查询转发表的固有延迟一样。然而对于货运，人们可能会有一些不同的想法，一列货运火车开过一个货 站，货舱门打开，工作人员在车辆未停的状态下把要在该站卸载的货物一个一个往下扔，怕货物摔坏吗？垫一个弹簧垫子即可。同样的例子，你可以考虑空投和空 降，或者轰炸机投弹，你见过飞机先停下再扔东西或者扔人吗？不都是在速度保持的情况下卸载载荷的吗？
在货运和普通客运这种低速环境下，停站带来的固有延迟成本并不是很高，然而在高速甚至超高速情况下就完全不同了。对于客运来讲，人们当然不能说像扔货物一 样在列车不停的前提下把要下车的人往下扔，下面有个弹簧垫子.....但是我觉得这个是个技术问题，是完全可以解决的。首先，直接的想法就是下车的人自己 在车站前面一点往下跳，结果摔死了，然后为了不摔死，下面垫一些东西，结果还是残废了，最后，考虑到把下面全部都做成完全柔软的东西，结果安然无恙，但是 还是受到了惊吓....这不就是靠技术一点点解决的吗？人还是那些下车的人，动作依然是往下跳，不同的是结果。
难道就不能把“要下车的人自己跳向站前柔软气垫”的过程做的更好吗？
可以设想一个密闭的容器空间，将要下车的人提前进入这个容器，然后列车在到站前将该容器卸载，列车本身并不减速。至于说这个容器怎么停下来或者说停到哪里 去，这完全是它自己的事，难道你没有发现这是一个完全解耦合的典型例子吗？一般在电影里我们总是看到在列车上打斗的场景，一般都是火车的前半段有个炸弹， 主角最后打死反派，或者把反派困在放炸弹的车厢，然后转动一个把手，将列车的后半段与前半段脱离，前半段继续以不变的速度前行，后半段由于摩擦力自己停下 来了，然后就是轰的一声，电影基本就结束了。这不是一个典型的高速卸载例子吗？当然最后轰的一声那个除外。
可以将每车厢一个的这些下车容器挂在高速列车的旁边，车站附近会有专门的下客轨道和上客轨道，然后列车到站前X米的时候，将容器脱离到下客轨道上，此时由 于惯性该下客容器的速度依然与列车一致，但是之后，它可以采取制动措施，使得这个“小车厢”完全在车站停止。对于乘客而言，不会有任何不适的感觉。
对于上客，原则一样，也是这些容器，在车站的上客轨道上自行加速到一个和高速列车一样的速度，然后勾挂在列车上，乘客之后进入列车的车厢。这真是无级变速 啊！当然，前面提到的X米是多少，上客容器何时启动，，这些都是要经过周密计算的。我只是给出一点原理而已。
不下车的乘客再也不用受到下车乘客的干扰了。我觉得这才称得上是高铁啊！真正的高铁！如果我从上海要到深圳，我花费的时间几乎就是上海到深圳的高铁轨道长 度除以高铁的速度，这种不停站的设计可以让高铁以尽可能的完全匀速行驶，不再受到车站的影响。它将仅受制于天气，以及流量管制等不可抗因素。
轨道交通固然可以如此，IP网络则如何呢？目前的技术而言，很难！
但是光网络卸载技术确实是有的，举一个最简单的例子就会明白。光网络的复用是波分复用的，也就是波长复用，因此卸载的就是波长，从一个叠加波里面分离出一个特定的波长完全是一个物理过程，而这根本不需要花费延迟！光分离器，光交换机等就用了这样的原理。
然而，对于IP网络，这种电子数字网络，却很难如此。即便是Cisco的CEF这样的技术，也不能在将本地流量和转发流量区分的过程中不影响转发流量，路 由器或者交换机需要对数据包做逐一检测，以匹配到一个流或者一个别的什么策略上。高端的路由器所能做的，只是让这个检测过程尽可能的快。
发这种牢骚干什么？！IP网络之所以这样难道不是因为它就应该这样吗！像我前面说的，高速环境中分离出一支来，在物理层是最容易做的，何必要在IP层 做，IP层带来了复杂性的同时也带来了可控。在核心传输网，光纤上跑的就不是IP报文，它更像是IP报文经过调制后的物理层的流。各种xDM本质上都是用 到了这种分离叠加技术，在芯片内部，在主板上，在接入网，在传输网，你都会发现很多复用器，解复用器，分离器之类的东西，这些东西做的事情就跟轨道交通的 不停站卸载差不多。
5点40分，这个时间点，多少人在做着美梦....
本文转自 dog250 51CTO博客，原文链接:http://blog.51cto.com/dog250/1677787
