企业官网建设流程全解析

先说我第一次认真研究RSVP时的情况。当时项目里要保障一场视频会议的带宽质量，组里的前辈丢给我一句话：RSVP都没弄明白，凭什么谈网络优化。翻了一堆资料之后，概念都能背，可一旦被问到“PATH消息和RESV消息到底谁先到”“预留是谁发起的”“预留建好之后数据包凭什么被特殊照顾”这几个问题，还是会卡壳。后来把资源预留协议RSVP的工作原理从头到尾捋了一遍，才意识到这个协议本质上想做的事并不复杂：在默认尽力而为的IP网络上，给特定数据流提前占住一条端到端的有保障通道。这篇文章就把这个经典问题拆开揉碎地讲一遍，帮正在备考、准备面试，或者刚开始接触网络QoS的朋友少走弯路。

1. 先想清楚一个前置问题：无连接的IP网络，为什么要搞资源预留

1.1 “尽力而为”网络带来的三个典型痛点

传统IP网络是典型的无连接网络。每一个IP分组在传输时都是独立个体，沿途路由器只关心“这个包要去哪个目的地址”，至于它属于哪一次视频通话、哪一次远程手术，路由器完全不关心，也没法关心。所有分组进了同一个漏斗，谁先到谁先走，满了就丢，这就是所谓的尽力而为（Best-Effort）服务。

这会带来三个非常直观的问题。首先，带宽没有保证。大家挤在同一段链路上，音频流、视频流、文件下载全都混在一起，没人承诺某一个流能分到多少带宽。其次，延迟和抖动没有控制。网络拥塞时，分组在路由器队列里排队的时间会拉长，前后两个分组可能排队时长相差很大，对实时音视频来说就是画面卡顿和声音断续。最后，丢包没有优先级。拥塞发生时路由器一律“一刀切”丢队尾的数据，重要的控制信令和普通的视频流量被同等对待，这在关键业务场景下是不可接受的。

用生活里的场景来类比，传统IP网络就像只有普通陆运的快递系统。任何包裹不论多急，都只能走同一条不保证时效的线路，高峰期堵在转运站，谁先到达完全看运气。可现实里就是有一些业务需要“特急专送”：线上手术指导、实时行情推送、视频会议、在线课堂。RSVP要解决的，就是如何在这样一张没有天然保障的网络里，给特定业务画出几条“专用运输通道”。

1.2 RSVP在QoS体系中的定位：它只是信令，不是执行者

在网络的QoS技solutions体系中，业界大致形成了两条路线。一条是集成服务模型（IntServ），核心思路是“逐流预留”，也就是对每一条具体的应用数据流，在它所经过的每一台路由器上都预留出明确的带宽和缓冲资源，做到能精确预估的端到端质量。另一条是区分服务模型（DiffServ），核心思路是“逐类调度”，不针对单个流，而是把流量分成服务等级，路由器只按优先级调度，骨干压力小、便于大规模部署。

RSVP就是IntServ模型里的核心信令协议。它是1990年代由IETF设计的，相关标准见RFC 2205，主要职责是让发送方和接收方在整条路径上协调资源的申请和确认。这里有个初学者最容易犯的误解：RSVP建好预留之后，是不是它自己就能保证带宽？不是。RSVP只负责“谈条件、签协议”，真正干活的是三部分：准入控制（Admission Control）判断链路还有没有资源，数据包分类器（Classifier）识别哪个包属于这条预留流，以及队列调度器（Scheduler）在转发时按预留参数投放资源。打个比方，RSVP是订座电话，不是送餐员，它保证你到店之后有位置坐，但端盘子上菜的是另外的人。

理解了这一点，再看RSVP的所有信令交互都会更清晰：它的全部工作，本质上是沿着数据流要走的路径，逐跳去找每一台路由器确认“能不能给这个流留出资源”，并把确认结果带回给通信双方。

2. PATH与RESV：RSVP的两条核心信令消息

2.1 PATH消息：从发送方出发的“侦察兵”

RSVP里最基础的消息是PATH消息。当发送方准备发起一个需要质量保障的会话时，会周期性发送PATH消息，消息的目的地址就是接收方的地址（组播场景下是组播组地址），沿着当前路由器计算出的下一跳逐跳转发下去。注意，PATH消息本质上还是一个IP包，它走的路由和普通数据包会走的路径是同一套规则，所以它能真实反映数据转发路径，这一点很关键。

PATH消息不是空手出门的，它身上带了两样重要信息。第一样是发送方的流量描述，叫做Tspechr，里面用令牌桶参数描述了发送方打算以多大速率、多大突发量来发送数据，接收方看到它就能知道上游流量的大致轮廓。第二样是Adspec，这是沿途各路由器在转发PATH时不断追加填写的“广告信息”，用来通知接收方整条链路目前具备哪些QoS能力，比如是否支持某种服务类型、可用的带宽大致处于什么水平。接收方后续计算“我该申请多少资源”时，会重点参考这份广告。

沿途每一台路由器收到PATH消息后，都会做一件很重要的事：记录路径状态（Path State）。记录的内容包括这条PATH是从哪个接口来的、上一跳是谁、下一跳是谁、发送方声称的流量参数是什么。这些状态就是后续RESV消息“原路返回”的路标，相当于侦察兵在沿途留下了返程的路标。除此之外，路由器也会更新PATH消息里的Adspec字段，把自己的能力信息加进去，再继续向下游转发。

2.2 RESV消息：接收方带着需求清单反向返回

接收方收到PATH消息后，会根据Tspechr和Adspec，再结合自己业务的需要，生成RESV消息。RESV是让初学者最容易混头的一步，因为它与前一半交互方向完全相反：RESV不是继续往接收方方向走，而是沿着刚才PATH建立好的路径状态，从接收方出发，逐跳逆向返回发送方。

RESV消息携带的是整个预留请求的核心参数，叫FlowSpec。这个FlowSpec又可以拆成两部分：一部分是Rspec，即“资源预留规格”，也就是接收方请求的服务质量等级，比如请求保证型服务时需要多少预留带宽、允许多少缓存延迟；另一部分是Tspeck，也就是流量的规格，用来描述接收方期望这条数据流符合怎样的令牌桶参数。除了FlowSpec之外，RESV还要带一个FilterSpec，用来精确说明“哪些数据包是这次预留要覆盖的”，常见形式是源地址、目的地址、协议端口号的集合。

这里有必要解释一下，为什么预留请求必须由接收方发起，而不是发送方一路申请过去。原因有几个。第一，组播场景下接收方可能非常多，如果每个接收方都各自向发送方反馈自己的需求，发送方会不堪重负，而由接收方主动申请，可以做到按需扩展。第二，接收方最清楚自己的实际需要，有的接收方终端屏幕小，只需要标清就够了，有的需要4K带宽，统一预留会造成浪费。第三，这种设计让网络资源的需求由数据消费端发起，更符合应用层的实际意图。所以面试里如果被问到“RSVP的预留是接收方发起还是发送方发起”，答案是接收方，这一点经常有人答错。

2.3 PATH与RESV如何配合：一个侦察，一个回执

把两条消息放在一起看，交互模型非常清晰。发送方用PATH把路径踩清楚，沿途所有路由器记住了这条路径的“逆时针返程路标”；接收方拿到信息后，用RESV沿路标走回去，沿途每台路由器在收到RESV时都会认真检查自己的资源和状态，决定是否接受预留。如果接受，它会把这条预留记录在案，并继续向上游传递RESV；如果拒绝，它会向下游返回ResvErr错误消息。

这个“侦察+回执”的配合关系，握住了RSVP整个机制的核心。你可以想象一次团体用餐：PATH是预订员先跑去餐厅确认路线和菜单可行性，RESV是客人沿着预订员留下的指示牌，到每个节点确认座位并付定金。两者配合得越紧密，端到端预留才能越可靠。这也是为什么RSVP要求PATH定期重发、RESV也定期刷新——因为对网络状态而言，任何一次路径改变，都可能让上一次侦察结果失效，必须持续维护。

3. 完整走一遍：一次端到端资源预留到底是怎么建立的

3.1 第一步：发送方启动会话并发送PATH

假设现在有一个视频会议软件，在主机A上启动，它想向一组接收方（可能是组播组）发送高质量视频流。主机A首先构造PATH消息，目的地址是接收方的组播地址或单播地址，协议号是46。消息里填入Tspechr：比如令牌桶速率是2Mbps，突发量为64KB，最大包长1500字节。然后主机A把PATH发给第一个路由器R1。

PATH消息每经过一台路由器，路由器都会把它往外发，同时记录下一跳关系。这里要特别说明的是，PATH消息里记录的“下一跳”并不是普通数据包的下一跳转发方向吗？是的，这个方向就是当前路由表里通向接收方的方向，也就是数据流的下游方向。每个路由器记录的关键信息是“这条PATH是从哪个上游接口进来的”“下游下一跳是哪个接口”，这样后续RESV才能知道往哪个方向回传。

在组播情况下，PATH消息会在组播树的分叉点复制成多份，分别沿着每个下游分支继续传，确保每个可能的接收方都能收到。这相当于快递路线图在每一个路口都分出一条新的支路。

3.2 第二步：沿途路由器记录Path State并处理Adspec

沿途的R1、R2、R3路由器收到PATH消息后，都会建立一条Path State。每条状态的核心字段包括：会话ID、上游接口、下游接口列表、发送方协议栈信息（Tspechr）、以及拼接起来的Adspec。

我实际配置中看过这类状态表，印象很深的一点是，Path State并不是跟着数据包走的瞬时信息，它更像是一张静态的“路径备忘单”。比如R2收到来自R1的PATH，它的转发表中记录了“到接收方走R3”，于是Path State里就记下“上游是R1，下游是R3”。这些状态会一直存在，直到超时或者被PathTear消息删除。

路由器在创建Path State之后，还会把自身支持的服务类型、链路带宽等能力写进Adspec字段，然后继续往下游转发PATH。Adspec的作用是让接收方在发起预留前，就知道整条链路到底能不能支撑它期望的服务质量。比如某个中间接口带宽只有1Mbps，接收方却想申请2Mbps，它能预先判断这次申请大概率没有意义，可以直接降低预期或选择放弃。

3.3 第三步：接收方依据需求生成RESV

当最后一个接收方主机B收到PATH消息，它开始计算自己需要多少资源。如果它只想保证网络不超过一定负载，可以选择受控负载服务；如果它希望网络提供硬性的带宽和延迟保证，就选择保证服务。假设主机B要的是保证服务，预留带宽为2Mbps，那么它会把Rspec里的路由带宽参数设为2Mbps，把Tspeck与PATH中带过来的发送方Tspechr对齐，再配上FilterSpec指定流的五元组，最终生成RESV消息。

这个环节有个很容易忽略的技巧：RESV并不是简单地把PATH里的Tspechr原样复制回去，而是接收方根据自己的接收能力做了裁剪。比如发送方声称能发4Mbps，但接收方屏幕只支持720p，它完全可以只预留1.5Mbps，这样能够有效节省链路上的资源。很多人在实验室里调通RSVP时会发现相同源和目的、不同接收方的预留带宽不同，原因就在这里。

RESV消息沿着Path State的返程路径发出，也就是从主机B回到R3，再从R3回到R2，一路往发送方方向走。

3.4 第四步：逐跳准入控制、合并与最终确认

RESV每到达一台路由器，路由器都会执行一次准入控制。准入控制的本质非常简单：看看出接口（相对于数据流下游方向）当前剩余可用带宽够不够，缓冲资源够不够。如果够，路由器就创建Reservation State，记录下这个预留，并把RESV继续向上游转发；如果不够，路由器会直接拒绝，向接收方回送ResvErr。

这里最体现RSVP设计精妙的地方在组播场景下的预留合并。假设路由器R2的下游有两个分支，一个分支要求预留2Mbps，另一个分支要求预留1.5Mbps，那么R2向R1继续传递RESV时，并不是把两个请求都转发过去，而是根据预留风格不同做不同处理。如果是共享式预留，R2会取两条分支需求的最大值作为新的请求向上游传递，也就是2Mbps；如果是独立式预留，则可能把两个请求都向上传，让上游分别保留资源。这个合并策略直接决定了多个接收方共享带宽时资源被占用的总量。

当RESV最终到达发送方主机A的直连路由器时，整个端到端的资源预订就算初步建立完成。如果接收方在RESV里设置了请求确认标志，路由器还会生成ResvConf消息回给接收方，表示这条预留已被全网接受。至此，从A到B的数据路径上，每一台路由器的出接口都记录了一条预留条目：凡是符合FilterSpec的数据包，会被单独放入预留队列，按预留带宽调度转发。

3.5 数据包进入预留通道后，路由器如何处理

预留建好之后，真正的数据包开始从A流向B。每台路由器收到数据包，会先交给数据包分类器，分类器把包头信息与已建立的Reservation State里的FilterSpec进行匹配。如果匹配成功，说明这是预留流的数据包，它不进入普通的尽力而为队列，而是被放进与这条预留关联的队列里，由调度器在每轮调度中保证分配给它的配额。

这里要再强调一遍：RSVP本身不参与这些转发动作，它只在最初和周期刷新时发挥作用。一旦预留条目建立完成，数据路径上的转发逻辑完全由分类器和调度器接管。这也解释了一个常见疑惑：预留拆了，数据是不是就断了？答案是不一定。如果RSVP状态被删除，数据包仍然能作为普通IP包继续传输，只是失去QoS保障，优先队列不再对它特殊照顾。

4. 软状态机制：RSVP能自动清理陈旧路径的秘密

4.1 软状态与硬状态的根本区别

传统面向连接的协议，比如TCP，会在建立连接时创建状态，在连接生命周期内保持不变，断开时再显式清理，这叫硬状态。RSVP选择了一条不同的路：所有路由器上创建的Path State和Reservation State都不设永久的存活期，而是需要周期性刷新来“续命”。如果一段时间没有收到对应的PATH或RESV消息，路由器就会自动把状态删除。这种会“过期”的状态，就是软状态。

软状态的优点体现在两方面。一方面，它避免了复杂的状态清理机制。如果某条路径突然断了，或者某个应用异常退出，网络根本不需要专门的通知消息去逐个删除状态，只要它停止刷新，超时之后状态自然消失。另一方面，它对路由变化足够宽容。动态路由协议改路后，旧路径上的状态因为没有刷新会被清理，新路径上则由PATH和RESV重新协商，整个过程不需要人工介入。

我从实际排障中体会最深的一点是，软状态让RSVP的容错性远好于“一次建立，永久有效”的设计。试想一下，如果状态是硬状态，某台路由器重启后，它已经丢失了所有预留信息，但上下游的路由器还认为预留依然存在，数据路径上就会出现断档；而软状态下，重启后的路由器由于没有状态，PATH和RESV的刷新很快就会让整条链路重新协商，恢复预留。

4.2 周期性刷新与超时参数

RSVP规定，PATH和RESV消息都会以一定时间间隔重新发送。RFC 2205定义的默认刷新间隔大约是30秒。当一台路由器的Path State或者Reservation State在超时时间内没有收到刷新消息，它就会将该状态删除。默认超时时间通常是刷新周期的三倍，也就是约90秒。这里要注意的是，超时参数并不是写死在协议里的，实际实现中完全可以通过配置调整。如果你在测试环境里希望路径变化能更快收敛，可以把刷新间隔调短，代价是更多信令消息占用的带宽和CPU开销。

刷新机制的另一个作用是动态更新预留参数。设想某个视频会议开始时，接收方预留了2Mbps带宽，会议中途画面分辨率提升了，发送方的Tspechr发生变化，它会通过新的PATH消息重新通告；接收方如果希望同步提升预留，就会在周期刷新中重算RESV参数。这样周期刷新的机制，天然支持了服务质量的动态调整，不需要单独设计一套参数修改信令。

4.3 路由变化时预留如何重建与清理

当路由协议决定改变转发路径时，RSVP会经历一个短暂的状态转换期。假设原来路径是R1-R2-R3，现在路由协议把到接收方的路径改成R1-R4-R3。在变化后的第一轮刷新周期里，PATH会沿着新路径穿过R4，R4还没有这条路径的Path State，它会新建Path State并记录下一跳。而旧路径R2仍然保留着旧的Path State和Reservation State，直到超时后被静默删除。

与此同时，接收方沿新路径的Path State发送RESV，新路径上的路由器会逐步建立预留状态。结果是，在几个刷新周期之后，新的端到端预留会在R1-R4-R3上建立起来，而旧路径R1-R2-R3上如果不再有任何流经过，它的状态会在超时后自动清理。这个过程中可能出现短暂的QoS保障缺失，因为R4在第一次收到RESV之前并没有对应的调度资源；但对于大多数容忍抖动不大的应用来说，几十秒内收敛是可以接受的。

5. 三种预留风格：一个协议如何适配不同业务场景

5.1 通配符预留：多个发送方共享同一个预留

RSVP把“如何表示预留对象”这件事做成了参数化的预留风格。第一种是通配符预留，也叫Wildcard Filter，用WF表示。WF风格下，会话对应的预留不区分具体发送方，所有发送方共享同一个资源池。路由器在合并多个下游分支的WF请求时，只需要在这些分支里取最大的带宽需求，再向上一跳传递。

WF风格的典型场景是多对多的组播会议，比如在线课堂里，有多个教师都可能发言，但同一时刻只有一个人在讲话。如果给每个人都单独预留一路高清带宽，会浪费大量网络资源；采用WF风格，所有发言教师的数据流共享预设的带宽额度，谁说话了谁就用，整体成本显著降低。WF风格的合并规则也非常省钱：多个下游分支的带宽请求取最大值，而不是累加，这种设计贴合了“共享”的本质。

5.2 固定过滤预留：一个发送方一条专属通道

第二种风格是固定过滤预留，也叫Fixed Filter，用FF表示。FF风格中，接收方会在RESV消息里明确指定它针对哪个发送方做预留，不同发送方之间互不共享，每个发送方的高效预留独立存在。路由器在合并FF请求时，对不同发送方的需求要取总和，因为两个发送方可能同时全速发送数据，不能指望它们错峰。

FF适合单播点播类业务，比如视频点播系统里，每个用户都在看自己选择的不同影片，每个视频流都是独立且满载的，不存在发一个送方之间的资源复用。如果这时候还用WF风格，某个用户看到的高清流可能会抢占另一个用户预留的带宽，画面就没办法保障。FF风格虽然费资源，但胜在隔离性强，保证质量最可靠。

5.3 共享显式预留：在共享和隔离之间取得平衡

第三种风格是共享显式预留，也叫Shared Explicit，用SE表示。SE的特点是接收方在请求时明确列出一个发送方的集合，并声明这些发送方共享一个预留。与WF不同，SE的共享范围是显式的，网络不需要默认“所有发送方都能共享”，而只对列出的发送方开放资源池。合并时，SE对同一个共享集合内的发送方取最大需求，集合之间再根据情况累加。

SE风格在多路视频会议中很实用。比如一个会议有四个分会场，任意时刻最多两个会场同时发言，接收方就可以把这两个可能发言的会场指定为一个SE共享集合，预留一份能承载一路高清流的带宽，这样既避免了全流量独立预留的浪费，又比WF风格更可控，不会让不在列表中的意外流量挤占预留资源。

5.4 实际选型时怎么决定用哪种风格

选预留风格时，核心问题只有一个：这个业务场景里的多个发送方，是否会同时抢带宽？如果会，选FF，隔离最关键；如果不会，选WF或SE，共享效率更高。再考虑接收方更多还是发送方更多：组播课堂倾向于WF，点播系统选FF，多点控制会议选SE。在配置RSVP的路由器上，如果同时收到不同风格的预留请求，RSVP规定必须保持风格一致才能合并，不一致时会产生冲突，路由器只能保留其中一种并报告错误，所以实际网络中同一会话最好从设计阶段就统一下来。

6. RSVP的软肋与它的现代归宿

6.1 可扩展性瓶颈：为什么运营商没有把它铺满全网

RSVP协议设计上有很多优点，但落地推广最大的障碍是可扩展性。它为每一条应用流维护状态，意味着网络中每条需要保障的流，在每一跳路由器上都需要占用一份状态表项。在骨干路由器上，同时经过的业务流数以十万甚至百万计，每一流都要保存Path State和Reservation State，还要周期性处理PATH和RESV消息，内存和CPU开销会高到不可承受。因此，运营商骨干网和大型数据中心内部基本没有全量部署RSVP，而更多是把资源预留理念做成了MPLS流量工程的拓展，也就是RSVP-TE。

RSVP的另一个部署难题是依赖整条路径上的所有设备都支持RSVP。只要路径中有一台路由器不支持或不启用RSVP，预留请求就在那里中断，接收方无法获得端到端保证。这导致在实际组网中，RSVP往往只在可控的园区网、接入网、企业专线内部署，跨运营商或跨管理域的端到端预留非常难实现。可以说，RSVP是“越核心越不敢用，越边缘越能用”。

6.2 从RSVP到RSVP-TE与QoS方案的交融

虽然传统RSVP在骨干网里很少直接使用，但它并没有被淘汰。RSVP-TE就是RSVP家族一个重要的延伸方向，它利用RSVP的信令框架，在MPLS网络中逐跳创建标签交换路径（LSP），并携带带宽、亲和属性等约束条件，实现流量工程。很多企业分支互访专线、运营商骨干隧道，实际跑的就是RSVP-TE协商出来的标签路径。把RSVP原生理解透了，再看RSVP-TE会轻松很多，因为它们共享PATH/RESV、软状态、逐跳建立这些底子。

除此之外，服务器和终端侧也演化出了不少替代思路，比如应用层感知的带宽管理、数据中心里的显式拥塞通知（ECN）、基于优先级的调度等。这些方案不要求逐流信令，而是在队列机制上下功夫，部署成本更低、扩展性更好，适合现代大规模网络。但RSVP作为理解“端到端资源预约为什么难、怎么实现”的经典模型，依然不可替代，这也是它在计算机网络经典考题里频繁出现的原因。

7. 备考与实战中容易踩的坑和高频追问

7.1 高频追问一：预留的发起方向到底是谁向谁

面试和考试特别爱问一个问题：PATH消息和RESV消息谁先发，从哪里到哪里。最容易答错的就是把“发送方先发PATH”理解成“发送方发起资源预留”。实际流程是，发送方只是用PATH通知网络“有一条流要来了”，真正的资源预留决定权在接收方。接收方评估自身需求后，用RESV向上游申请资源。所以学习时可以把网络留的动作主语记成“接收方”，而不是“发送方”。

另一个高频追问是：PATH沿数据流方向往下游走还是逆着走。记住一条铁律：PATH和普通数据包同方向，都从发送方到接收方；RESV是反向的，从接收方回到发送方。很多人刚开始学，总是把RESV和PATH的方向搞反，导致整个流程理解全都错位。这个问题我建议画图，把发送方放左边，接收方放右边，PATH从左往右画实线箭头，RESV从右往左画虚线箭头，一眼就能记住。

7.2 高频追问二：上游、下游到底怎么定义

“上游”和“下游”这两个词在RSVP语境里也容易让人发晕。它们的基准是数据流动方向。数据从发送方流向接收方，所以站在某台路由器上看，发送方那一侧是上游，接收方那一侧是下游。PATH消息从上游往下游方向转发，RESV消息从下游往上游方向转发。很多资料描述“路由器收到RESV后向上游转发”，如果忘了这个基准，就会看成是“往发送方方向转发”，其实想表达的是同一个意思，只是表述角度不同。

在实际排查中，我会在设备上通过命令查看Path State和Reservation State，重点关注它们的入接口和出接口。只要确认接口方向与数据流向一致，就能快速定位哪一跳预留没有成功建立，问题出在路由还是准入控制。

7.3 常见误区速查表

7.4 实验验证时的小建议

如果条件允许，建议在模拟器里搭一个三台路由器的链状拓扑，把RSVP打开，再用流量工具发一路测试流。抓包看PATH和RESV的周期刷新频率，再看看路由器上预留状态表的变化。我在测试中习惯先开抓包，再手动断开一条链路触发路由切换，观察旧路径状态是否在90秒左右超时消失，新路径是否重新建立——这套验证方法能帮助你直观理解软状态机制，比单纯背概念效率高很多。抓包的时候重点看协议号，RESV消息里FlowSpec的Rspec字段变化，能让你理解接收方请求不同带宽时，上游预留如何随之更新。

最后分享一点我自己在学习RSVP时获得的经验：不要死记信令名称和字段，抓住“两个方向”和“一个过期原则”就够了。两个方向是指PATH沿数据方向走、RESV逆向回传；一个过期原则是指网络上的所有预留状态都需要周期性刷新才能存活。把这三条主线刻进脑子里，RSVP的工作原理就不再是一堆碎片化的知识点，而是一条完整、自洽的逻辑链。我后来跟同事讲QoS方案，都是先画组播树，再标Path State和ResvState，十分钟就能让对方理解端到端资源预留的来龙去脉。RSVP的门道不止这些，往深了可以继续挖RSVP-TE和流量工程，但先把这套底子吃透，后面的路会顺很多。