深入了解Linux QoS的实现机制 (linux qos 实现机制)
网络质量及网络性能一直是企业与个人所关心的重点，为此，许多网络管理员和系统管理员通过不断地研究和尝试，试图实现更好的网络质量服务（QoS）。在众多的QoS技术中，Linux QoS 被认为是一种简便易行的解决方案。本文将深入探讨Linux QoS的实现机制，帮助读者理解Linux QoS的优势和限制，帮助读者更好地应用Linux QoS技术。
一、Linux QoS的概述
QoS（Quality of Service）质量服务，是一种网络技术，通过对网络流量进行控制和调整，来提高网络的性能。Linux QoS是一种基于Linux内核实现的QoS技术，通过对Linux内核中的网络流量进行分类和控制，来实现各种QoS服务。
Linux QoS技术主要分类为三种：
（1）差异化服务（DiffServ），它是一种面向服务质量的网络架构，可提供QoS级别服务，以便在网络中向待分类流提供优先级。当网络拥塞时，这些流的优先级将确定其在网络资源分配中的优先级。该技术通常用于有限带宽情况下的网络。
（2）集成服务（IntServ），它利用公共网络的服务质量特征来提供服务质量。此技术用于高速网络和网络中存在连续保证带宽的应用。在几乎没有拥塞的情况下，该技术会分配足够的带宽给每一个QoS流。
（3） 策略性选择服务（PSS），它是一个以策略为基础的联盟，在一个联盟中的用户可以凭借自己的策略来访问自己所需要的服务。这种技术在企业内部网络中经常使用。
二、Linux QoS的实现方式
Linux QoS的实现方式主要包括三个方面：
（1）流量分类
Linux QoS的流量分类是通过将网络中的流量进行分类，并将其放入不同的队列中，这些队列可按照优先级从高到低的顺序进行排列。Linux下的流量分类机制主要有基于 iptables 的流量分类和基于 tc 命令的流量分类。
（2）队列调度
队列调度是Linux QoS中用来调整流量的重要机制之一，其主要目的是对网络流量进行排队、调度和按照一定的策略分配。队列调度可实现不同流量的优先级。
（3）流量控制
流量控制是Linux QoS的最后一个环节，主要用于根据不同应用程序的需求，对流量进行限制、控制。通过流量控制机制，可确保网络的正常运行。
三、Linux QoS的应用
（1）业务分级与限速
通过对网络中的数据流进行分类和限速，可以使得不同的业务拥有不同的优先级，从而降低只负荷造成的瓶颈，实现网络的负载均衡。
（2）视频流优先级
在观看视频时，如果网络带宽不足，会导致视频的像素下降、画面卡顿，用户体验大打折扣。使用Linux QoS技术，对视频流的优先级进行提高，能够使得视频流在带宽不足的情况下仍然能够得到保证。
（3）游戏流优先级
当网络有拥塞情况发生时，游戏可能会因为网络卡顿或丢包而影响游戏体验。通常来说，需要通过提高游戏的流量优先级，让重要数据包优先传输，来保证网络的高质量和行畅。
四、Linux QoS的局限
尽管Linux QoS 在网络带宽管理和流量控制领域有很多优秀的优点，但也存在一些局限性。主要体现在以下几个方面：
（1）Linux QoS技术对于新晋管理员使用门槛较高，需要对Linux的网络原理和Linux实现QoS的机制有着更深入的了解。
（2）流量分类对硬件层面有着更高的需求，需要更高速的网路交换机支持，来确保较高级别的服务质量。
结论：
Linux QoS 的实现机制及其应用场景是一个极为广泛的话题，随着网络技术的变化和网络性能的需求增加，Linux QoS 技术必然会有新的发展。潜在的研究和应用价值是无限的，我们需要在不断摸索和实践的过程中，不断发现和探讨。
相关问题拓展阅读：
面试 linux 文件系统怎样io到底层
前言：本文主要讲解LinuxIO调度层的三种模式：cfp、deadline和noop，并给出各自的优化和适用场景建议。IO调度发生在Linux内核的IO调度层。这个层次是针对Linux的整体IO层次体系来说的。从read()或者write()系统调用的角度来说，Linux整体IO体系可以分为七层，它们分别是：VFS层：虚拟文件系统层。由于内核要跟多种文件系统打交道，而每一种文件系统所实现的数据结构和相关方法都可能不尽相同，所以，内核抽象了这一层，专门用来适配各种文件系统，并对外提供统一操作接口。文件系统层：不同的文件系统实现自己的操作过程，提供自己特有的特征，具体不多说了，大家愿意的话自己去看代码即可。页缓存层：负责真对page的缓存。通用块层：由于绝大多数情况的io操作是跟块设备打交道，所以Linux在此提供了一个类似vfs层的块设备操作抽象层。下层对接各种不同属性的块设备，对上提供统一的BlockIO请求标准。IO调度层：因为绝大多数的块设备都是类似磁盘这样的设备，所以有必要根据这类设备的特点以及应用的不同特点来设置一些不同的调度算法和队列。以便在不同的应用环境下有针对性的提高磁盘的读写效率，这里就是大名鼎鼎的Linux电梯所起作用的地方。针对机械硬盘的各种调度方法就是在这实现的。块设备驱动层：驱动层对外提供相对比较高级的设备操作接口，往往是C语言的，而下层对接设备本身的操作方法和规范。块设备层：这层就是具体的物理设备了，定义了各种真对设备操作方法和规范。有一个已经整理好的，非常经典，一图胜千言：我们今天要研究的内容主要在IO调度这一层。它要解决的核心问题是，如何提高块设备IO的整体性能？这一层也主要是针对机械硬盘结构而设计的。众所周知，机械硬盘的存储介质是磁盘，磁头在盘片上移动进行磁道寻址，行为类似播放一张唱片。这种结构的特点是，顺序访问时吞吐量较高，但是如果一旦对盘片有随机访问，那么大量的时间都会浪费在磁头的移动上，这时候就会导致每次IO的响应时间变长，极大的降低IO的响应速度。磁头在盘片上寻道的操作，类似电梯调度，实际上在最开始的时期，Linux把这个算法命名为Linux电梯算法，即：如果在寻道的过程中，能把顺序路过的相关磁道的数据请求都“顺便”处理掉，那么就可以在比较小影响响应速度的前提下，提高整体IO的吞吐量。这就是我们为什么要设计IO调度算法的原因。目前在内核中默认开启了三种算法/模式：noop，cfq和deadline。严格算应该是两种：因为之一种叫做noop，就是空操作调度算法，也就是没有任何调度操作，并不对io请求进行排序，仅仅做适当的io合并的一个fifo队列。目前内核中默认的调度算法应该是cfq，叫做完全公平队列调度。这个调度算法人如其名，它试图给所有进程提供一个完全公平的IO操作环境。注：请大家一定记住这个词语，cfq，完全公平队列调度，不然下文就没法看了。cfq为每个进程创建一个同步IO调度队列，并默认以时间片和请求数限定的方式分配IO资源，以此保证每个进程的IO资源占用是公平的，cfq还实现了针对进程级别的优先级调度，这个我们后面会详细解释。查看和修改IO调度算法的方法是：cfq是通用服务器比较好的IO调度算法选择，对桌面用户也是比较好的选择。但是对于很多IO压力较大的场景就并不是很适应，尤其是IO压力集中在某些进程上的场景。因为这种场景我们需要的满足某个或者某几个进程的IO响应速度，而不是让所有的进程公平的使用IO，比如数据库应用。deadline调度（最终期限调度）就是更适合上述场景的解决方案。deadline实现了四个队列：其中两个分别处理正常read和write，按扇区号排序，进行正常io的合并处理以提高吞吐量。因为IO请求可能会集中在某些磁盘位置，这样会导致新来的请求一直被合并，可能会有其他磁盘位置的io请求被饿死。另外两个处理超时read和write的队列，按请求创建时间排序，如果有超时的请求出现，就放进这两个队列，调度算法保证超时（达到最终期限时间）的队列中的请求会优先被处理，防止请求被饿死。不久前，内核还是默认标配四种算法，还有一种叫做as的算法（Anticipatoryscheduler），预测调度算法。一个高大上的名字，搞得我一度认为Linux内核都会算命了。结果发现，无非是在基于deadline算法做io调度的之前等一小会时间，如果这段时间内有可以合并的io请求到来，就可以合并处理，提高deadline调度的在顺序读写情况下的数据吞吐量。其实这根本不是啥预测，我觉得不如叫撞大运调度算法，当然这种策略在某些特定场景差效果不错。但是在大多数场景下，这个调度不仅没有提高吞吐量，还降低了响应速度，所以内核干脆把它从默认配置里删除了。毕竟Linux的宗旨是实用，而我们也就不再这个调度算法上多费口舌了。1、cfq：完全公平队列调度cfq是内核默认选择的IO调度队列，它在桌面应用场景以及大多数常见应用场景下都是很好的选择。如何实现一个所谓的完全公平队列（CompletelyFairQueueing）？首先我们要理解所谓的公平是对谁的公平？从操作系统的角度来说，产生操作行为的主体都是进程，所以这里的公平是针对每个进程而言的，我们要试图让进程可以公平的占用IO资源。那么如何让进程公平的占用IO资源？我们需要先理解什么是IO资源。当我们衡量一个IO资源的时候，一般喜欢用的是两个单位，一个是数据读写的带宽，另一个是数据读写的IOPS。带宽就是以时间为单位的读写数据量，比如，100Mbyte/s。而IOPS是以时间为单位的读写次数。在不同的读写情境下，这两个单位的表现可能不一样，但是可以确定的是，两个单位的任何一个达到了性能上限，都会成为IO的瓶颈。从机械硬盘的结构考虑，如果读写是顺序读写，那么IO的表现是可以通过比较少的IOPS达到较大的带宽，因为可以合并很多IO，也可以通过预读等方式加速数据读取效率。当IO的表现是偏向于随机读写的时候，那么IOPS就会变得更大，IO的请求的合并可能性下降，当每次io请求数据越少的时候，带宽表现就会越低。从这里我们可以理解，针对进程的IO资源的主要表现形式有两个：进程在单位时间内提交的IO请求个数和进程占用IO的带宽。其实无论哪个，都是跟进程分配的IO处理时间长度紧密相关的。有时业务可以在较少IOPS的情况下占用较大带宽，另外一些则可能在较大IOPS的情况下占用较少带宽，所以对进程占用IO的时间进行调度才是相对最公平的。即，我不管你是IOPS高还是带宽占用高，到了时间咱就换下一个进程处理，你爱咋样咋样。所以，cfq就是试图给所有进程分配等同的块设备使用的时间片，进程在时间片内，可以将产生的IO请求提交给块设备进行处理，时间片结束，进程的请求将排进它自己的队列，等待下次调度的时候进行处理。这就是cfq的基本原理。当然，现实生活中不可能有真正的“公平”，常见的应用场景下，我们很肯能需要人为的对进程的IO占用进行人为指定优先级，这就像对进程的CPU占用设置优先级的概念一样。所以，除了针对时间片进行公平队列调度外，cfq还提供了优先级支持。每个进程都可以设置一个IO优先级，cfq会根据这个优先级的设置情况作为调度时的重要参考因素。优先级首先分成三大类：RT、BE、IDLE，它们分别是实时（RealTime）、更佳效果（BestTry）和闲置（Idle）三个类别，对每个类别的IO，cfq都使用不同的策略进行处理。另外，RT和BE类别中，分别又再划分了8个子优先级实现更细节的QOS需求，而IDLE只有一个子优先级。另外，我们都知道内核默认对存储的读写都是经过缓存（buffer/cache）的，在这种情况下，cfq是无法区分当前处理的请求是来自哪一个进程的。只有在进程使用同步方式（syncread或者syncwirte）或者直接IO（DirectIO）方式进行读写的时候，cfq才能区分出IO请求来自哪个进程。所以，除了针对每个进程实现的IO队列以外，还实现了一个公共的队列用来处理异步请求。当前内核已经实现了针对IO资源的cgroup资源隔离，所以在以上体系的基础上，cfq也实现了针对cgroup的调度支持。总的来说，cfq用了一系列的数据结构实现了以上所有复杂功能的支持，大家可以通过源代码看到其相关实现，文件在源代码目录下的block/cfq-iosched.c。1.1cfq设计原理在此，我们对整体数据结构做一个简要描述：首先，cfq通过一个叫做cfq_data的数据结构维护了整个调度器流程。在一个支持了cgroup功能的cfq中，全部进程被分成了若干个contralgroup进行管理。每个cgroup在cfq中都有一个cfq_group的结构进行描述，所有的cgroup都被作为一个调度对象放进一个红黑树中，并以vdisktime为key进行排序。vdisktime这个时间纪录的是当前cgroup所占用的io时间，每次对cgroup进行调度时，总是通过红黑树选择当前vdisktime时间最少的cgroup进行处理，以保证所有cgroups之间的IO资源占用“公平”。当然我们知道，cgroup是可以对blkio进行资源比例分配的，其作用原理就是，分配比例大的cgroup占用vdisktime时间增长较慢，分配比例小的vdisktime时间增长较快，快慢与分配比例成正比。这样就做到了不同的cgroup分配的IO比例不一样，并且在cfq的角度看来依然是“公平“的。选择好了需要处理的cgroup（cfq_group）之后，调度器需要决策选择下一步的service_tree。service_tree这个数据结构对应的都是一系列的红黑树，主要目的是用来实现请求优先级分类的，就是RT、BE、IDLE的分类。每一个cfq_group都维护了7个service_trees，其定义如下：其中service_tree_idle就是用来给IDLE类型的请求进行排队用的红黑树。而上面二维数组，首先之一个维度针对RT和BE分别各实现了一个数组，每一个数组中都维护了三个红黑树，分别对应三种不同子类型的请求，分别是：SYNC、SYNC_NOIDLE以及ASYNC。我们可以认为SYNC相当于SYNC_IDLE并与SYNC_NOIDLE对应。idling是cfq在设计上为了尽量合并连续的IO请求以达到提高吞吐量的目的而加入的机制，我们可以理解为是一种“空转”等待机制。空转是指，当一个队列处理一个请求结束后，会在发生调度之前空等一小会时间，如果下一个请求到来，则可以减少磁头寻址，继续处理顺序的IO请求。为了实现这个功能，cfq在service_tree这层数据结构这实现了SYNC队列，如果请求是同步顺序请求，就入队这个servicetree，如果请求是同步随机请求，则入队SYNC_NOIDLE队列，以判断下一个请求是否是顺序请求。所有的异步写操作请求将入队ASYNC的servicetree，并且针对这个队列没有空转等待机制。此外，cfq还对SSD这样的硬盘有特殊调整，当cfq发现存储设备是一个ssd硬盘这样的队列深度更大的设备时，所有针对单独队列的空转都将不生效，所有的IO请求都将入队SYNC_NOIDLE这个servicetree。每一个servicetree都对应了若干个cfq_queue队列，每个cfq_queue队列对应一个进程，这个我们后续再详细说明。cfq_group还维护了一个在cgroup内部所有进程公用的异步IO请求队列，其结构如下：异步请求也分成了RT、BE、IDLE这三类进行处理，每一类对应一个cfq_queue进行排队。BE和RT也实现了优先级的支持，每一个类型有IOPRIO_BE_NR这么多个优先级，这个值定义为8，数组下标为0-7。我们目前分析的内核代码版本为Linux4.4，可以看出，从cfq的角度来说，已经可以实现异步IO的cgroup支持了，我们需要定义一下这里所谓异步IO的含义，它仅仅表示从内存的buffer/cache中的数据同步到硬盘的IO请求，而不是aio(man7aio)或者linux的native异步io以及libaio机制，实际上这些所谓的“异步”IO机制，在内核中都是同步实现的（本质上冯诺伊曼计算机没有真正的“异步”机制）。我们在上面已经说明过，由于进程正常情况下都是将数据先写入buffer/cache，所以这种异步IO都是统一由cfq_group中的async请求队列处理的。那么为什么在上面的service_tree中还要实现和一个ASYNC的类型呢？这当然是为了支持区分进程的异步IO并使之可以“完全公平”做准备喽。实际上在最新的cgroupv2的blkio体系中，内核已经支持了针对bufferIO的cgroup限速支持，而以上这些可能容易混淆的一堆类型，都是在新的体系下需要用到的类型标记。新体系的复杂度更高了，功能也更加强大，但是大家先不要着急，正式的cgroupv2体系，在Linux4.5发布的时候会正式跟大家见面。我们继续选择service_tree的过程，三种优先级类型的service_tree的选择就是根据类型的优先级来做选择的，RT优先级更高，BE其次，IDLE更低。就是说，RT里有，就会一直处理RT，RT没了再处理BE。每个service_tree对应一个元素为cfq_queue排队的红黑树，而每个cfq_queue就是内核为进程（线程）创建的请求队列。每一个cfq_queue都会维护一个rb_key的变量，这个变量实际上就是这个队列的IO服务时间（servicetime）。这里还是通过红黑树找到servicetime时间最短的那个cfq_queue进行服务，以保证“完全公平”。选择好了cfq_queue之后，就要开始处理这个队列里的IO请求了。这里的调度方式基本跟deadline类似。cfq_queue会对进入队列的每一个请求进行两次入队，一个放进fifo中，另一个放进按访问扇区顺序作为key的红黑树中。默认从红黑树中取请求进行处理，当请求的延时时间达到deadline时，就从红黑树中取等待时间最长的进行处理，以保证请求不被饿死。这就是整个cfq的调度流程，当然其中还有很多细枝末节没有交代，比如合并处理以及顺序处理等等。1.2cfq的参数调整理解整个调度流程有助于我们决策如何调整cfq的相关参数。所有cfq的可调参数都可以在/sys/class/block/sda/queue/iosched/目录下找到，当然，在你的系统上，请将sda替换为相应的磁盘名称。我们来看一下都有什么：这些参数部分是跟机械硬盘磁头寻道方式有关的，如果其说明你看不懂，请先补充相关知识：back_seek_max:磁头可以向后寻址的更大范围，默认值为16M。back_seek_penalty:向后寻址的惩罚系数。这个值是跟向前寻址进行比较的。以上两个是为了防止磁头寻道发生抖动而导致寻址过慢而设置的。基本思路是这样，一个io请求到来的时候，cfq会根据其寻址位置预估一下其磁头寻道成本。设置一个更大值back_seek_max，对于请求所访问的扇区号在磁头后方的请求，只要寻址范围没有超过这个值，cfq会像向前寻址的请求一样处理它。再设置一个评估成本的系数back_seek_penalty，相对于磁头向前寻址，向后寻址的距离为1/2(1/back_seek_penalty)时，cfq认为这两个请求寻址的代价是相同。这两个参数实际上是cfq判断请求合并处理的条件限制，凡事复合这个条件的请求，都会尽量在本次请求处理的时候一起合并处理。fifo_expire_async:设置异步请求的超时时间。同步请求和异步请求是区分不同队列处理的，cfq在调度的时候一般情况都会优先处理同步请求，之后再处理异步请求，除非异步请求符合上述合并处理的条件限制范围内。当本进程的队列被调度时，cfq会优先检查是否有异步请求超时，就是超过fifo_expire_async参数的限制。如果有，则优先发送一个超时的请求，其余请求仍然按照优先级以及扇区编号大小来处理。fifo_expire_sync:这个参数跟上面的类似，区别是用来设置同步请求的超时时间。slice_idle:参数设置了一个等待时间。这让cfq在切换cfq_queue或servicetree的时候等待一段时间，目的是提高机械硬盘的吞吐量。一般情况下，来自同一个cfq_queue或者servicetree的IO请求的寻址局部性更好，所以这样可以减少磁盘的寻址次数。这个值在机械硬盘上默认为非零。当然在固态硬盘或者硬RAID设备上设置这个值为非零会降低存储的效率，因为固态硬盘没有磁头寻址这个概念，所以在这样的设备上应该设置为0，关闭此功能。group_idle:这个参数也跟上一个参数类似，区别是当cfq要切换cfq_group的时候会等待一段时间。在cgroup的场景下，如果我们沿用slice_idle的方式，那么空转等待可能会在cgroup组内每个进程的cfq_queue切换时发生。这样会如果这个进程一直有请求要处理的话，那么直到这个cgroup的配额被耗尽，同组中的其它进程也可能无法被调度到。这样会导致同组中的其它进程饿死而产生IO性能瓶颈。在这种情况下，我们可以将slice_idle＝0而group_idle＝8。这样空转等待就是以cgroup为单位进行的，而不是以cfq_queue的进程为单位进行，以防止上述问题产生。low_latency:这个是用来开启或关闭cfq的低延时（lowlatency）模式的开关。当这个开关打开时，cfq将会根据target_latency的参数设置来对每一个进程的分片时间（slicetime）进行重新计算。这将有利于对吞吐量的公平（默认是对时间片分配的公平）。关闭这个参数（设置为0）将忽略target_latency的值。这将使系统中的进程完全按照时间片方式进行IO资源分配。这个开关默认是打开的。我们已经知道cfq设计上有“空转”（idling）这个概念，目的是为了可以让连续的读写操作尽可能多的合并处理，减少磁头的寻址操作以便增大吞吐量。如果有进程总是很快的进行顺序读写，那么它将因为cfq的空转等待命中率很高而导致其它需要处理IO的进程响应速度下降，如果另一个需要调度的进程不会发出大量顺序IO行为的话，系统中不同进程IO吞吐量的表现就会很不均衡。就比如，系统内存的cache中有很多脏页要写回时，桌面又要打开一个浏览器进行操作，这时脏页写回的后台行为就很可能会大量命中空转时间，而导致浏览器的小量IO一直等待，让用户感觉浏览器运行响应速度变慢。这个low_latency主要是对这种情况进行优化的选项，当其打开时，系统会根据target_latency的配置对因为命中空转而大量占用IO吞吐量的进程进行限制，以达到不同进程IO占用的吞吐量的相对均衡。这个开关比较合适在类似桌面应用的场景下打开。target_latency:当low_latency的值为开启状态时，cfq将根据这个值重新计算每个进程分配的IO时间片长度。quantum:这个参数用来设置每次从cfq_queue中处理多少个IO请求。在一个队列处理事件周期中，超过这个数字的IO请求将不会被处理。这个参数只对同步的请求有效。slice_sync:当一个cfq_queue队列被调度处理时，它可以被分配的处理总时间是通过这个值来作为一个计算参数指定的。公式为：time_slice=slice_sync+(slice_sync/5*(4-prio))。这个参数对同步请求有效。slice_async:这个值跟上一个类似，区别是对异步请求有效。slice_async_rq:这个参数用来限制在一个slice的时间范围内，一个队列最多可以处理的异步请求个数。请求被处理的更大个数还跟相关进程被设置的io优先级有关。1.3cfq的IOPS模式我们已经知道，默认情况下cfq是以时间片方式支持的带优先级的调度来保证IO资源占用的公平。高优先级的进程将得到的时间片长度，而低优先级的进程时间片相对较小。当我们的存储是一个高速并且支持NCQ（原生指令队列）的设备的时候，我们更好可以让其可以从多个cfq队列中处理多路的请求，以便提升NCQ的利用率。此时使用时间片的分配方式分配资源就显得不合时宜了，因为基于时间片的分配，同一时刻最多能处理的请求队列只有一个。这时，我们需要切换cfq的模式为IOPS模式。切换方式很简单，就是将slice_idle=0即可。内核会自动检测你的存储设备是否支持NCQ，如果支持的话cfq会自动切换为IOPS模式。另外，在默认的基于优先级的时间片方式下，我们可以使用ionice命令来调整进程的IO优先级。进程默认分配的IO优先级是根据进程的nice值计算而来的，计算方法可以在manionice中看到，这里不再废话。2、deadline：最终期限调度deadline调度算法相对cfq要简单很多。其设计目标是：在保证请求按照设备扇区的顺序进行访问的同时，兼顾其它请求不被饿死，要在一个最终期限前被调度到。我们知道磁头对磁盘的寻道是可以进行顺序访问和随机访问的，因为寻道延时时间的关系，顺序访问时IO的吞吐量更大，随机访问的吞吐量小。如果我们想为一个机械硬盘进行吞吐量优化的话，那么就可以让调度器按照尽量复合顺序访问的IO请求进行排序，之后请求以这样的顺序发送给硬盘，就可以使IO的吞吐量更大。但是这样做也有另一个问题，就是如果此时出现了一个请求，它要访问的磁道离目前磁头所在磁道很远，应用的请求又大量集中在目前磁道附近。导致大量请求一直会被合并和插队处理，而那个要访问比较远磁道的请求将因为一直不能被调度而饿死。deadline就是这样一种调度器，能在保证IO更大吞吐量的情况下，尽量使远端请求在一个期限内被调度而不被饿死的调度器。
Linux下IPV4和IPV6的互操作性研究
作为向下一代互联网络协议过渡的重要步骤 国际的IPv 试验网 bone在 年成立扒胡滑了 现在 bone已经扩展到全球 多个国家和地区 成为IPv 研究者 开发者和实践者的主要平台 CERNET国家网络中心于 年 月加入 bone 同年 月成为其骨干网成员 电子科大作为教育网的西南主节点 在得到Nokia的IPv 路由器之后 积极参与IPv 技术研究 我们先查阅研究了大多数与IPv 有关的RFC文档和相关技术资料 并且在此基础上进行了很多网络实验 该文先简单阐述了IPV 的必要性和IPV 到IPV 升级转换的机制 然后详细阐明了在Linux操作系统下进行的IPv 网络实验及其结论 并附有相关参考文献书目 一 使用IPv 的必要性现在运行的因特网协议IPv 存在其固有的局限性 一是地址问题 IPv 的地址只有 位 这意味着总的地址数大约是 亿 并且还有许多地址是不可用的 按照目前网络的发春腊展趋势 到 和 年之间IPv 的地址就会耗尽 必须用另一种地址方案来替代它 二是IPv 提供的服务局限性 IPv 尽它的更大努力来传送信息包 但是它不会保证提供给上层的服务是可靠的 没有QoS（服务质量）的概念 这些问题都是IPv 的薄弱环节 致命弱点 另外因特网不断提出对移动性 安全性以及多媒体业务的支持等问题 IPv 都无法解决 这样就迫使我们必须引入下一带因特网协议 IPv 二 IPv 和IPv 的互操作要将现在的IPV 网络升级到IPV 网络 不可能所有的机器在同时启用IPV 协议栈 配置好IPV 地址 安装好IPV 应用程序 所以必须实现IPV 网络与IPV 网络之间的互操作及平滑升级机制 IPv 到IPv 的升级转换机制的首要条件是允许IPv 和IPv 主机互操作 其次是在相互依赖性很小的情况下使IPv 的主机和路由器能在因特网中快速发展 第三是转换对端用户 系统管理员和网络实施者来说易于理解和执行 IPv 转换机制是一套主机和路由器执行的协议机制 有一套定址和配置的操作指导方案 尽可能减少转换过程中造成的破坏 IPv 转换机制的主要目标如下 · 可增加的升级和扩展性:单个IPv 的主机和路由器可在不需要其它的主机和路由器同时升级的情况下单独升级成IPv 新的IPv 主机和路由器可以后再一台台的安装成IPv ·最小的升级依赖性 将主机升级成IPv 的唯一先决条件是域名服务器必须先升级以处理IPv 地址记录 ·方便的寻址 当IPv 的主机和路由器升级到IPv 后 他们必须继续用原来的地址 他们不需要指定新的地址 管理者不需制定新的地址分配方案 ·很低的启动开销 将IPv 系统升级成IPv 很少或几乎不需要准备工作 IPv 转换机制确保IPv 主机能和任何因特网上的IPv 通信 直到IPv 被淘汰 并在那时允许在小范围内互相通信 这个特征保护了用户已经在IPv 上的巨大投入并使得IPv 不会将IPv 孤立 基于以上原因 IPv 主机和路由器上与Ipv 主机和路由器现在广泛采用了如下两种互操作的机制 隧道技术和双IP协议栈技做衡术A．隧道技术隧道提供了一种利用IPv 路由基础上传输IPv 包的方法 隧道应用于下面几种应用中 路由器到路由器 主机到路由器 主机到主机和路由器到主机 路由器到路由器和主机到路由器隧道技术都是将IPv 包传到路由器 隧道的终点是中间路由器 必须将IPv 包解出 并且转发到它的目的地 隧道终点的地址必须由配置隧道节点的配置信息获得 这种类型的隧道称作人工配置隧道 当利用隧道到达IPv 的主干网时 如果一个在IPv 网络和IPv 网络边界的IPv /IPv 路由器的IPv 地址已知时 那么隧道的端点可以配置为这个路由器 这个隧道的配置可以被写进路由表中作为 缺省路由 这就是说所有IPv 目的地址符合此路由的都可以使用这条隧道 这种隧道就是默认配置的隧道 主机到主机和路由器到主机隧道技术都是将IPv 包传到主机的 可以用IPv 包的信息获得终点地址 隧道入口创建一个IPv 封装头并传送包 隧道出口解包 去掉IPv 头 更新IPv 头 处理IPv 包 隧道入口节点需要保存隧道信息如MTU等 如果用于目的节点的IPv 地址是与IPv 兼容的地址 隧道的IPv 地址可以自动从IPv 地址继承下来 因此也就不需要人工配置 这种隧道也就称为自动隧道 IPv 兼容的IPv 地址格式如下B．双IP协议栈方式双协议栈方式包括提供IPv 和IPv 协议栈的主机和路由器 双协议栈工作方式的简单描述如下 ·如果应用程序使用的目的地址是IPv 地址 那么将使用IPv 协议栈 ·如果应用程序使用的目的地址是兼容IPv 的IPv 地址 那么IPv 就封装到IPv 中 ·如果目的地址是另一种类型的IPv 地址 那么就使用IPv 地址 可能封装在默认配置的隧道中 双协议栈的缺省IP包发送算法为 a 如果IP包的目的地址是IPv 地址 如果目的站点在可达链路上 直接发送 如果目的站点不可达 要么送往在线路由器 要么不可达 b 如果IP包的目的地址是IPv 兼容的IPv 地址 如果目的站点在可达链路上 直接发送IPv 包 如果目的站点处于off link （ ）如果有可达IPv 路由器 则封装在IPv 包中发往IPv 路由器 （ ）如果有可达IPv 路由器 则不封装 直接发送 （ ）如果没有可达路由器 则不可达 c 如果IP包的目的地址是纯IPv 地址 如果目的站点在 可达链路上 直接发送IPv 包 如果目的站点处于off link （ ）如果有可达IPv 路由器 则直接发送到路由器 （ 如果目的地通过手动隧道可达 并且链路上有可达IPv 路由器 则封装成IPv 包 目的IP地址为隧道终点地址 链路地址为可达路由器的链路地址 （ ）否则为不可达 d 在线/离线的确定 IPv 使用子网掩码确定 IPv 使用邻居发现协议 两者共同使用的是 如果目的地址是IPv 地址 则使用 RFC 比较两者的掩码 如果目的地址是IPv 兼容的IPv 地址 则使用低 位目的地址的子网掩码比较 如果是 IPv 纯地址 则使用邻居发现协议 三 Linux下IPv 网络研究实验我们在研究了大量IPv 协议（主要的IPv RFC文档）之后 进行了一系列的IPv 研究实验 现详细叙述如下 ．Pv 研究实验平台的选择在国内有几所大学已经或正在进行IPv 实验研究 并且建立了CERNET IPv 实验床 我们在与CERNET IPv 实验床的老师和同学取得联系并进行了交流 实验床网络中心最初的组网是通过主机配置FreeBSD来完成的 年开始用的是FreeBSD 现在是FreeBSD 都有 此外有些科研人员也开始采用linux进行实验 路由器现在采用的是Nokia的IP 还有FreeBSD+Mrtd的主机 电子科大作为教育网西南地区的主节点 也得到了Nokia捐赠的IPv 路由器 在此基础之上 我们通过分析比较研究各种操作系统 最后选定用linux作为IPv 主机和路由器研究实验平台 具体原因如下 A． Linux作为开放的操作系统 其原代码完全公开 具有很强的灵活性 现在有很多自由软件联盟为Linux免费开发如件 故Linux具有很强的生命力和活力 而其他大部分由个别公司开发的操作系统 一方面原代码不公开 无法根据自己的要求修改内核 其公司的发展的兴衰 很大程度上影响该操作系统的发展 B． Linux操作系统很先进 一直跟踪关注网络的发展 用Linux组建Internet网络 建立网站 进行网络开发研究 都是很好的选择 并且其内核从 开始 就已经开始支持IPv 技术了 这等于就为我们提供了IPv 协议栈原代码 我们可以利用其共享代码做IPv 的研究开发 ．Linux主机IPv 协议支持技术研究在选定了实验平台之后 我们就着手进行一系列的IPv 实验 主要针对在已大量安装了IPv 的主机和路由器情况下 如何成功地兼容地升级到IPv 如何运用在IPv 主机和路由器上 与Ipv 主机和路由器成功互操作 以及如何建立配置IPv 主机和路由器 在进行IPv 实验之前 我们根据网上查询资料及对Linux内核分析 研究了如何建立IPv 主机 包括安装协议栈 网络工具及网络程序 现以Redhat Linux为例 详细说明其具体步骤如下 A．支持IPv 协议的新内核的编译要让操作系统支持IPv 就要安装IPv 协议栈 Redhat 的内核为 版本 可支持IPv 但是安装缺省不支持 由于协议栈在操作系统中是处于核心地位的 必须重新编译新的内核才能安装上新的协议栈 其具体步骤如下 )以root身份登陆 进入源码所在的目录 cd /usr/src/linux )运行 make clean 清除一些可能过期的中间代码 ) 然后配置内核选项 make menuconfig 或者 make xmenuconfig运行make menuconfig后 将下面的支持IPv 的选项选上 其他内核选项请根据系统的具体情况作出符合系统的选择 Code maturity level optionsPrompt for development and/or inplete code/drivers Yes Neorking optionsPacket socket yesUnix domain socketsyesTCP/IP neorkingyesThe IPv protocolyesIPv : enable EUI token format yesIPv : disable provider based address yes File systems/ procfilesy lishixinzhi/Article/program/Oracle/202311/17046
关于linux qos 实现机制的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。
