路由器需要多大内存？
作者 黄 岩 | 2008-12-16 15:34 | 类型 中国系统软件, 弯曲推荐, 通讯产品 | 11条用户评论 »
|
计算机需要多大内存？当然是越大越好了，这是用户的想法。但是计算机的设计者则必须在成本、实现难度、和取悦客户等几个因素之间进行折中，选取一个最佳平衡点。对计算机来说，其主要依据是产品的市场定位，高端商务PC至少配2G内存，低端学生机配256M就够了。如果用256M RAM的学生机来作复杂的大规模FPGA仿真，可能会发现硬盘的灯一直是亮的，这说明内存已经不够用了，操作系统正在不停的在内存和硬盘之间兑换数据，用大容量的低速硬盘来弥补内存太小的不足，但是代价是计算时间延长了很多倍。路由器是不是也向PC一样，主要依据售价来决定内存配置的大小呢？会不会也是内存越大越好呢？路由器的设计者依据哪些因素来决定内存配置的大小？一般来说，路由器的内存主要用于一下这些方面： （1）用于存储路由器软件指令和静态数据，路由器跟PC不同，PC是只把当前运行的程序装到RAM中，但多数路由器都是一开机就把全部程序都装到RAM中，一般来说，路由器的程序也不大（几兆到几十兆）；（注：此处主要指控制平面的程序，也就是Cisco和Juniper的路由引擎） （2）用于存储动态数据，例如：路由表、OSPF的链路状态数据库等。假如某路由器需要支持最多10万条路由，按照每条路由256字节计算，那么大约需要200M左右内存。 （3）用于缓冲数据报文，路由器的工作原理是存储转发。极端情况下，路由器的每个接口，至少需要缓冲一个报文，否则路由器根本不能工作。下面重点讨论这个问题。 一般来说，路由器配置的报文缓冲区都不止一个报文。因为这样也就意味着当有新报文到达的时候，如果前面一个报文正在发送，这个报文缓冲区尚未处于空闲状态，那么新的报文势必将会被丢掉。等前面一个报文发送完了，链路处于空闲状态，但是由于刚才报文已经被丢掉了，也无法利用链路空闲状态。如果被丢掉的报文是TCP报文，那么主机势必将重传这个报文（在该路由器前面的一段线路上传输两次同样的报文），并缩小自己的发送窗口，降低了TCP连接的速率。 也就是说，如果接口的报文缓冲区太小，将导致丢包率高，数据链路利用率低，TCP传输效率低。那么是不是报文缓冲区越大越好呢？也不是，因为报文缓冲区大到一定程度，就不能继续提高数据链路利用率和降低丢包率了。如果这台路由器处于拥塞状态，接收报文的速率远远大于接口的发送带宽，无论多大的报文缓冲区都会被填满，而报文缓冲区大了，那么也就意味着拥塞状态的时候，报文的转发延迟时间会很长。延迟时间太长的报文，对于接收方来说，已经没有意义了。以TCP连接为例，当报文大于发送方的重传时间的时候，发送方就会重传该报文，也就是说，大于TCP的重传时间的到达的报文，是没有意义的。对VoIP等应用来说，对网络延时更加敏感。 一般来说，路由器的接口缓冲区的大小有一个经验法则（rule-of-thumb）：B = C * RTT，C是链路速率，RTT是平均报文往返之间。至于这个经验法则源自哪里，我没有认真考证。但这个经验法则的主要依据是最大化TCP效率，最大化网络接口带宽利用率。如果依据这个法则来设计路由器，对中低端路由器来说，问题不大。但是对于高端路由器，是有挑战的。一般中高端Internet骨干路由器上会假设RTT为250ms，那么对于个10GE接口，需要的内存是(10G bit/s * 0.25 s) / 8 约为300MB。也许大家会说，300M不大么，但是可以预见，最近两年核心路由器的容量必将发展到单槽位80 - 160G，也就是说单大约需要2.5G - 5G内存。虽然不是完全不可实现，但还是有一定难度。从Juniper的一个白皮书（Characteristics of Switches and Routers）可以看出，Juniper也是按照这个经验法则设计的。 但是最近的一些研究认为（sizing router buffers, Guido Appenzler, Isaac Keslassy, Nick McKeown），其实路由器不需要那么大的内存，每个端口只需要缓冲几十个报文就足够了，这样用NP或ASIC内嵌的RAM就够了，不用配置外部RAM。他主要依据是以前的经验法则是根据单TCP流来推算的，作者认为这个模型不对，实际的骨干路由器上是有很多TCP流的，因此应该按照B = C * RTT / sqrt(N)来计算，N是TCP流数量。但是另外一些研究则认为这个结论不对，路由器上不能只考虑TCP，还有很多急于UDP的语音和视频应用。反正在教授们之间，这个问题至今仍然没有一致的意见。工程师已经不再争论这个问题了，就按照B = C * RTT来设计，成本可以接受，而且也比较安全:） | |
  (9个打分， 平均：4.89 / 5) |
雁过留声
“路由器需要多大内存？”有11个回复
那个经验法则应该是根据 queueing theory里的little’s law. 理想状态下的排队系统容量就是那个公式所表达的意思.
大哥， 倒底多少条路由啊。
10万路由， 256byte的， 应该是20MB的内存啊
应该是100万条，10万条中低端路由器还差不多。
另外，如果用DRAM做，容量应该不是问题，DRAM足够大足够便宜，主要问题应该是内存访问速度,访问速度上不来，谈多大内存容量意义已经不大。如果为了提高内存访问速度，采用SRAM/RLDRAM等高速存储，这个时候容量才成为问题，因为他们做不大，并且还特贵。
简直受不了。一个西陲边疆的一个非大公司的一个做技术文档的工程师就这样功力厉害，。。。。。。真是山外有山，人外有人呀。。。。。。
多谢黄岩的好文章。已加入“弯曲推荐”。
BNN难得夸奖人。
国内民间的人才很多的，缺乏有效组织。
目前国内缺乏合格的工程师，更缺乏合格的管理者。导致人才使用不充分。
对现代路由器来讲，应该更多的考虑性价比的问题。针对国内的状况，可以考虑做一款对p2p”友好的路由器产品。
目前，利用linux或BSD构建出来的路由器。最大的问题是网络部分没有线程化。多核的解决方案难度很大（其实就是芯片厂商提供的programming guide很难有创新的空间，导致同质化的产品）。
这个问题 望有识之士 讨论下 是否能针对kernel改进，小弟曾经考虑过这个问题
小弟近期也打算回家乡“西陲边疆”之地（不是成都）
Nick McKeown他们在斯坦福搞clean slate的网络研究，新的TCP是其方向之一。这个根据TCP流数来修正buffer量也是与其大方向匹配的。当然，如果更宽裕的buffer数值在工程上不成问题，教授们的研究结果（除以根号N）就没那么石破天惊了。
感觉上不太对，说手我看法哈：
——————————–
一般报文转发的时候，查的路由表是放在查表硬件里的，而对于转发时候，包缓存一般都是用的NP下挂的QDR或者SDRAM（由于这个处理时间很快，所以完全用不到250ms的时间），使用到内存的时候，只有更新路由表的时候，内存作为将路由表项写到硬件中的缓存，而这个缓存大小，实际上是与表项下发的时间和写入到硬件的时间有关系。报文转发的过程链路上，每个器件都有一个处理时间，真正的报文缓存大小应该是和这个链路上处理速度最慢的期间对报文的占用“时间”有关。有于内存本身访问的时候存在很大的延迟，所以一般都不拿内存来做包缓存。
把这篇文章顶上来。很重要的一篇。我感觉要重新整理版面。我把我的那个“中国系统软件”拿下，换成“通信系统”或者什么的。从而读者可以方便的reach到所有通信系统相关的文章。
ingress和egress应该是分开考虑的，就packet buffer来说，是不是也要考虑一下包的大小，比如jumbo frame之类的。一般来说每个packet buffer size应该是固定的，至于要用多少buffer，上面说的公式就起作用了。
的确好文章，不过这个命题有些宽泛了，我觉得容易产生一些歧义和错误的争论，虽然说争论总是有益的。
比如限定一类的路由器，或者一类的板卡可能更好一些。