CN107204926B - 预处理cache的路由快速查找方法 - Google Patents

Abstract

本发明公开了预处理cache的路由快速查找方法，其将路由信息直接写入cache，创建cache。本方案将创建cache的时机由转发时提前到了添加路由时，这样就不会占用转发时的时间，转发时只需做哈希查询操作即可，大大提升了转发性能。

Description

预处理cache的路由快速查找方法

技术领域

本发明涉及网络数据，具体涉及路由技术。

背景技术

为了提高路由查找效率以及实现按流负载均衡，设计了路由cache机制，把已经查过路由的目的ip地址及其查到的路由结果用哈希表的形式缓存起来。这样下次针对同样的目的地址，可以直接从上述哈希表(即cache)中找到路由结果，而无需再查路由表，毕竟路由表一般以二叉树的形式组织，查询比较慢。

然而，这种做法针对同一个目的地址，只有第二次及以后的查询会快，第一次查询仍然需要查路由表，路由的查询速度还是比较慢的。

由此可见，路由的查找速度往往成为设备的性能瓶颈，虽然cache的加入大大缓解了这个问题，但仅限于流量稳定之后(如针对同一个目的地址，第二次及以后的查询)；因此如何提高流量首次进入时(第一次查询)的路由查找速度，是本领域亟需解决的问题。

发明内容

名词解释：

cache－缓存；

CIDR－无类域间路由。

针对现有路由查找技术所存在的问题，需要一种能够高效的路由快速查找方案。

为此，本发明所要解决的技术问题是提供一种预处理cache的路由快速查找方法。

为了解决上述技术问题，本发明提供的预处理cache的路由快速查找方法，其将路由信息直接写入cache，创建cache。

在本方案中，在添加路由时就直接把路由信息预同步到cache里。

在本方案中，在创建cache时，将掩码长度也引入cache，每增加一条路由，直接同步创建一条带有掩码长度的cache。

在本方案中，被同一子网覆盖的所有目的地址共享同一个cache条目。

在本方案中，在cache表里用有序数组代替链表。

在本方案中，所述数组每一项是个结构体，至少要保存目的地址、掩码长度和指向cache结构的指针这三项，按掩码长度由长到短排序。

在本方案中，配置一辅助表来预测最终匹配到的掩码长度，辅助表在更新路由时同步更新，统计具有相同掩码长度的路由的个数。

在本方案中，所述辅助表有256个表项，以目的地址的前8位为索引，保存掩码长度与路由相对应的信息。

在本方案中，在查cache之前，先用目的地址的前8位为索引查辅助表，得到可能的最长掩码，再与目的地址相与后再计算哈希值查cache。

在本方案中，所述辅助表的每一项还有一个指针指向二叉树形式的路由表的相应节点，该节点通常为辅助表这一项所对应的子树的头结点。

使用本方案可以做到只查cache就能得到路由结果，避免了较慢的路由表查找，最大限度的优化了查找效率，提升了转发报文的性能。

附图说明

以下结合附图和具体实施方式来进一步说明本发明。

图1为本发明实例中预处理cache加快路由查找的原理图。

具体实施方式

为了使本发明实现的技术手段、创作特征、达成目的与功效易于明白了解，下面结合具体图示，进一步阐述本发明。

本实例方案通过路由信息直接写入cache，实现在添加路由时创建cache，即将创建cache的时机由转发时提前到了添加路由时，这样就不会占用转发时的时间，转发时只需做哈希查询操作即可，大大提升了转发性能。

具体的，本实例方案在现有的路由cache基础上进行扩展，在添加路由时就直接将路由信息预同步到cache里，无需等到转发报文时。这样实现在第一次查路由时，也可以直接从cache中获得结果，不必查路由表，有效提高第一次查路由的查询速度，解决了第一次查询慢的问题。

进一步的，本实例方案相对于传统的cache机制需要对每个不同的目的地址创建一个独立的cache条目，本方案让被同一子网覆盖的所有目的地址共享同一个cache条目，由此来大大节约内存。

再者，本方案还进一步用数组代替链表来解决哈希冲突，这样能够减少仿存次数，提高查找效率。

以下说明一下本实例方案的具体实现过程：

传统的cache机制中，刚开始打流时是不存在cache的，需要做“查cache失败->查路由表->创建cache->cache与路由关联”这一系列动作，这一过程比较慢。对此，本实例方案从此处着手，在打流之前预先建好cache，实现绝大多数查找都在cache里进行，最大限度减少查路由的动作。

由于传统的cache都是以32位目的地址为索引的，在实际打流之前完全无法预计哪些目的地址的报文会冲过来。据此，为了能够预先创建好cache，本实例方案将掩码长度也引入cache，每增加一条路由，直接同步创建一条带有掩码长度的cache，即这一种特殊的cache，是与路由相对应的，而非与流相对应。

由于cache的哈希算法，只能进行精确匹配，无法进行最长掩码匹配。在此基础上，为能够有效实现查找，本实例方案进一步增加一个辅助表来帮助“预测”最终匹配到的掩码长度。辅助表有256个表项，以目的地址的前8位为索引，保存了掩码长度与路由相对应的信息(即“在哪些掩码长度上有路由”的信息)。查cache之前，要先用目的地址的前8位为索引查辅助表，得到可能的最长掩码，与目的地址相与后再计算哈希值查cache。

由于一个正常的路由表，往往只有少数几种掩码长度，在此情况下，可以通过少数几次查cache表的操作找到最佳匹配的cache条目。如果所有可能的前缀长度都被试过也找不到，则说明不存在匹配的路由，也无需再查路由表了，因为所有路由表信息都已经被完整地保存到cache表中。这就大大缓解了那些查不到路由的背景流量对CPU的冲击。

本实例方案中，根据路由创建cache与根据流创建cache，二者可以同时存在。比如对于直连路由(非点到点)和等价路由，就需要根据流创建cache，对于以太网直连路由，cache可以减少arp查找的开销；对于等价路由，cache可以实现按流负载均衡。

在本实例方案的基础上，对于多个掩码长度同时存在的情况，此时也需要根据流创建cache，以加速下一次查找。对于其它情况，查到cache就可以直接转发了，不用再创建32位掩码的cache了，节约了时间和内存。

由于同一设备端口个数有限，所有路由的下一跳存在大量重复，由此使得与下一跳有关联的cache内容将会存在重复。对此，本实例方案将被同一子网覆盖的所有目的地址共享同一个cache条目，使得相同的cache内容只保存一份，通过指针共享，不但能大大节省内存，还将因更可能驻留在cpu缓存里而提高性能。

对于cache表里的哈希冲突，本实例方案用有序数组代替链表，这样一次访存可以比较更多冲突项，以减少访存次数。

该数组每一项是个结构体，至少要保存目的地址、掩码长度和指向cache结构的指针这三项，按掩码长度由长到短排序。

针对上述的具体实现方案通过一具体应用实例来说明。

参见图1，其所示为基于预处理cache来加快路由查找的实现原理图。

由图可知，本方案在添加路由时就直接将路由信息预同步到cache里，同时将掩码长度也引入cache，每增加一条路由，直接同步创建一条带有掩码长度的cache，并且增加一个辅助表来帮助“预测”最终匹配到的掩码长度。

该辅助表以目的地址的前8位为索引，共256个表项，这样可以进一步细分路由表，尽可能减少每个表项对应的掩码长度个数，尤其是对于没有应用CIDR的传统路由分布，效果更好。

每个表项中的压缩掩码是一个32位无符号整数(对应ipv4地址的32位)，每一位表示该位对应的掩码长度上有无路由，对于掩码长度小于8的路由需要特殊处理；而压缩掩码实质就是掩码长度统计表的压缩存储形式，统计表中更详细的记录了每种掩码长度的个数，个数非0时对应的压缩掩码位为1，否则为0，查cache时读入压缩掩码即可，无需再查掩码长度统计表，以减少访存次数。每次路由更新时，除了cache需要同步之外，辅助表里的统计值和压缩掩码也需要同步更新。

据此，每次查cache时需要先以目的地址的前8位为索引查辅助表，得到压缩掩码，然后结合压缩掩码的末位1的位置得出用于查cache表的目的地址(将原目的地址截取到该位为止，后面的位全部清0)，再查cache表，若查不到，则结合压缩掩码的倒数第二个1的位置得到新的查cache表的目的地址······以此类推，直到所有可能的掩码长度都被试过。

例如，需要查路由的目的地址为192.168.3.3，查辅助表得到索引192对应的压缩掩码为0x00010100，则表明第一字节为192的所有路由有16和24两种掩码长度，先用24位掩码与初始目的地址相与，得到192.168.3.0，再用192.168.3.0作为目的地址计算哈希值去查cache，如果查到了cache则继续走转发流程，否则再用16位掩码重复上述步骤，若还查不到，则说明没有相应的路由，丢包即可。

另外，针对辅助表，其中的每一项还有一个指针指向二叉树形式的路由表的某个节点，该节点通常为辅助表这一项所对应的子树的头结点，可用于添加删除路由时尽快定位相关节点。

由上实例可知，通过本实例方案即可实现只查cache就能得到路由结果，避免了较慢的路由表查找，最大限度的优化了查找效率，提升了转发报文的性能。

以上显示和描述了本发明的基本原理、主要特征和本发明的优点。本行业的技术人员应该了解，本发明不受上述实施例的限制，上述实施例和说明书中描述的只是说明本发明的原理，在不脱离本发明精神和范围的前提下，本发明还会有各种变化和改进，这些变化和改进都落入要求保护的本发明范围内。本发明要求保护范围由所附的权利要求书及其等效物界定。

Claims (8)

1.预处理cache的路由快速查找方法，其特征在于，在打流之前预先建好cache，在添加路由时就直接将路由信息预同步到cache里，同时将掩码长度也引入cache，每增加一条路由，直接同步创建一条带有掩码长度的cache，并且增加一个辅助表来预测最终匹配到的掩码长度，所述辅助表以目的地址的前8位为索引，共256个表项，每个表项中的压缩掩码是一个32位无符号整数，每一位表示该位对应的掩码长度上有无路由，每次路由更新时，除了cache需要同步之外，辅助表里的统计表和压缩掩码也需要同步更新；每次查cache时需要先以目的地址的前8位为索引查辅助表，得到压缩掩码，然后结合压缩掩码的末位1的位置得出用于查cache表的目的地址，将原目的地址截取到该位为止，后面的位全部清0，再查cache表，若查不到，则结合压缩掩码的倒数第二个1的位置得到新的查cache表的目的地址，以此类推，直到所有可能的掩码长度都被试过。

2.根据权利要求1所述的路由快速查找方法，其特征在于，被同一子网覆盖的所有目的地址共享同一个cache条目。

3.根据权利要求1所述的路由快速查找方法，其特征在于，在cache表里用有序数组代替链表。

4.根据权利要求3所述的路由快速查找方法，其特征在于，所述数组每一项是个结构体，至少要保存目的地址、掩码长度和指向cache结构的指针这三项，按掩码长度由长到短排序。

5.根据权利要求1所述的路由快速查找方法，其特征在于，配置一辅助表来辅助最终匹配到的掩码长度，辅助表在更新路由时同步更新，统计具有相同掩码长度的路由的个数。

6.根据权利要求5所述的路由快速查找方法，其特征在于，所述辅助表有256个表项，以目的地址的前8位为索引，保存掩码长度与路由相对应的信息。

7.根据权利要求6所述的路由快速查找方法，其特征在于，在查cache之前，先用目的地址的前8位为索引查辅助表，得到可能的最长掩码，再与目的地址相与后再计算哈希值查cache。

8.根据权利要求6所述的路由快速查找方法，其特征在于，所述辅助表的每一项还有一个指针指向二叉树形式的路由表的相应节点，该节点通常为辅助表这一项所对应的子树的头结点。

Images