【Network telemetry】談談網絡遙感技術，從主動探測與被動探測再到Netflow與INT

【前言】

　　【本篇爲原創】網絡遙感，Network telemetry，爲何叫「telemetry」呢？我我的的理解是將網絡中的數據進行一種「採集」，也就是其實是一種網絡數據的採集手段。因爲工做須要，接觸了一些網絡遙感方面的技術，本篇文章就來談一談主流的網絡遙感技術。本篇文章會介紹傳統網絡中基於「流」的遙感技術，以思科的Netflow技術爲表明和IETF的IPFIX標準，再到最近比較流行的INT技術，INT技術會着重介紹思科的IOAM和華爲的PBT兩種。

【場景】

　　網絡遙感是一種網絡信息採集技術，目的是爲了採集網絡中的信息，網絡越大，出了問題越難排查，所以須要一些技術對網絡進行史實的流量分析監控或是能夠自動化排查網絡中的「斷路」，而且在DCN網絡中（Datacenter Network）更須要一套手段來實現對網絡的監控與探測，對網絡的實時監控須要一套技術來實現，那麼網絡遙感就是用來解決這個問題而誕生的一種技術。網絡遙感通常分爲兩種，分別是主動探測和被動探測。被動探測以思科的Netflow技術爲表明，而主動探測則大多數相似於微軟Everflow中的guided probe組件爲表明（還有vmware爲表明的虛擬網絡的Traceflow，以及華爲的FusionNetDoctor，固然華爲作的有點low...實話實說）。

【主動探測】

　　主動探測，顧名思義，就是「主動去探測網絡中的狀態」，爲表明的以微軟Everflow系統中的guided probe組件爲表明，微軟於2016年在SIGCOMM發了一篇名爲《Packet-Level Telemetry in Large Datacenter Networks》文章，這篇文章主要介紹了微軟的一套實現數據包級別的網絡遙感技術，感興趣的能夠去google一下，我我的以爲寫的很是好的一篇文章。其中提到了一個重要組件，叫作「guided probe」，那麼這個guided probe是用來作什麼的呢？

圖1.典型的虛擬網絡拓撲

　　圖1是一個典型的虛擬網絡拓撲，虛擬機A到虛擬機B須要通過三個虛擬交換機，兩個虛擬路由器，那麼假設某一時刻「正在發生」虛擬機A到虛擬機B發生了「斷路」致使虛擬機A到虛擬機B的業務流量不通，怎麼定位到具體發生故障的位置以及發生故障的緣由呢？

　　微軟的guided probe和vmware的traceflow就是作這個事情的。guided probe會在VM A注入一種「探測數據包」，而後在網元上設置一些「探測識別點」，這個數據包每通過一個網元都會上傳狀態信息，例如圖2.

圖2.主動探測的一種實現

　　以圖2爲例，我在每個網元的輸入和輸出設置一些「探測識別點」，「探測數據包」通過「探測識別點」會向控制器上傳狀態信息，那麼假設虛擬機A到虛擬機B中的虛擬交換機3的輸入出發生故障，那麼最終上傳的信息會缺乏「虛擬交換機3的OUT」，那麼控制器就能夠判斷出虛擬交換機3處存在「正在發生「的故障，那麼就能夠經過北向通道告知管理面，管理面再告知用戶，或直接發出告警。

　　固然還不止這樣，若是數據面是自家公司研發的話還有一種升級的玩法，若是能夠感知到「某條具體的背景流發生了斷路」，「流「能夠用5-tuple來標識（src ip、dst ip、src port、dst port、l4 protocol或者加上tos），那麼我便在注入探測數據包的時候，拿出現「斷流」的背景流量做爲模板，構造出與出現「斷路」的背景流量相同的數據包進行主動探測，而且若是數據面是自家公司研發的話，徹底能夠在數據面轉發中的丟包處設置「探測識別點」，那麼這樣不只知道出現斷流的背景流具體的斷流位置，還能夠知道斷流的緣由，這樣能夠直接告訴用戶「xxx條流量出現了斷流，在xxx的位置，斷流丟包的緣由是xxx」，例如圖3是VMWare的Traceflow的顯示結果。

圖3.VMWare的Traceflow使用效果圖

　　上述流程即是主動探測的大多數實現，微軟的Everflow、Vmware的Traceflow以及華爲的FusionNetDoctor都是這樣實現的（這裏我必定要吹一波Vmware，作的真的有點好，真尼瑪炫酷...）可是主動探測一樣存在一些致命缺點：

1. 只能探測正在發生的故障。若是故障是時斷時續的，那主動探測這種手段就無能爲力了。
2. 探測的力度有限，例如正在發生的故障是丟包，而且丟包是隻丟一部分，那麼發出的探測數據包頗有可能沒有被丟，呈現出與現實世界不通的結果。（可是這種方法能夠批量注入來觀察）
3. 沒法回溯。這點與第一點基本相同，若是斷流是某個過去的時間點發生的，例如半夜，那主動探測便沒法得知過去某個時間點出現斷路的緣由與位置了。
4. 須要在數據面設置探測識別點，探測識別點識別探測數據包不能影響正常的數據面轉發性能。

　　微軟的Everflow中提到，這種主動探測主要就是探測正在發生的斷路，由於正在發生的斷路的故障優先級最高，能實現這點已經足夠，沒辦法期望單純的一種技術來應付全部場景。

　　固然主動探測之後我會寫一篇專門的文章來說解其中存在的一些技術難點和實現方法。

【被動探測】

　　被動探測是與主動探測相對應的一種探測，被動探測的定義是在「不影響當前網絡流量的狀況下進行探測」，因爲主動探測「注入探測數據包」會對當前網絡中的流量作出一些影響（出現了一條新的流量）。被動探測以思科的Netflow做爲表明，可是近年來也有一些新的技術分別亮相，好比思科提出的INT技術以及其具體應用IOAM，以及華爲根據思科IOAM技術進行優化提出的PBT技術。因爲被動探測的技術內容比主動探測的內容複雜一些，所以接下來會分別介紹，先介紹Netflow技術。

【Netflow】

　　Netflow技術由思科與1996年提出（和我同一年生....），到如今已通過了24年，已是一種很是成熟的技術了，而且各家根據思科Netflow的思想還發展處了一些方言版本，例如jFlow，sFlow等等等等。Netflow的架構經常如圖4所示。

圖4.Netflow架構圖

　　只要是基於Netflow的採集技術（其實不光是Netflow，主要是流量採集技術基本都差很少...），不管作成什麼樣，作的多大，基本都離不開Netflow架構的這幾個組件。

• Netflow Exporter。Netflow導出器，用處是將流數據經過Netflow協議進行導出至Netflow Collector中。
• Netflow Collector。Netflow收集器，用處是將Netflow數據包收上來後進行解析，解析出流數據後存至Flow Storage中。
• Flow Storage。流數據庫，存解析後的Netflow數據，一般流數據庫用的基本以TSDB爲主（時序數據庫），由於須要經常回溯某個時間點，或過去一段時間內流量分佈的變化與狀態信息，所以TSDB更適合，比較流行的有influxDB、Prometheus。
• Analyzer/Monitor。分析器，用於對流數據庫中的數據進行分析與呈現。

　　固然還有一個最終要的組件即是Netflow設備的Flow cache。在Netflow設備中會存在一張表，這張表會存放流的信息，如圖

圖5.Netflow Main Cache原理圖

　　原理也很是簡單，即：

當某條流的數據包第一次進入當前Netflow設備後，Netflow設備會根據此數據包的5-tuple信息（這裏隨意定義）提取並在Netflow cache中添加一條Flow Entry，這條Flow Entry便表明此條流，那麼即可以統計這條流的信息，並定時（Netflow cache一般都有老化機制）導出封裝爲Netflow協議數據包送往Netflow Collector

　　Netflow技術的原理很是簡單，就是採集流信息，上傳，而後分析。固然Netflow也有缺點，即是：

1. 採集粒度爲「流」，沒法到達更細粒度的「數據包」，因此統計丟包、時延有必定難度。
2. 會給Netflow設備帶來性能損耗，性能的損耗每每會帶來「觀察者效應」。好比某一網絡現象，拿網絡擁塞或丟包爲例，本來網絡中不會有擁塞或丟包，可是因爲開啓了Netflow採集功能，採集功能消耗Netflow設備的性能，致使Netflwo設備處理網絡流量的性能降低，進而產生了擁塞或丟包，那麼即是「觀察者效應」，最終的結果並非已經存在的，而是因爲去「觀察」這一動做纔會發生，不觀察就不會發生，那麼這種狀況就比較蛋疼。而性能問題又會帶來以下幾種問題。
   • 性能降低致使在DCN網絡沒法對每個數據包都進行更新Flow cache，因此每每會存在採樣頻率一說，比較常見的是「每100個數據包採集第一個數據包」，用這種方法來下降性能消耗，可是這種方法又會產生額外的問題，好比在網絡中一般會存在一些「大象流」和「老鼠流」，大象流的表明如FTP數據流，這些流量的特色是量大，持續一段時間後就會消失；而「老鼠流」的一些表明是一些控制協議或者是協商協議，這些流量的特色是量少，可是會一直持續，可靠性要求較高。可是若是存在採樣頻率，極可能會出現採集不到「老鼠流」，最後看起來就是「大象流」覆蓋了「老鼠流」，只能看見有FTP協議流量，其餘一些TCP協議流量看不到。
3. Netflow協議上傳的信息有限，儘管Netflow v9已經支持模板的方式去採集數據，可是仍然是有限的，而且沒法採集一些企業的私有數據，而且Netflow v9的傳輸層協議爲UDP協議，UDP協議自己可靠性較差，一旦出現上傳信息丟失，還得額外處理。
4. Netflow協議存在太多的方言版本，例如sFlow、jFlow，兼容性會有必定的問題，而且Netflow協議屬於思科提出的一種流量導出協議，並非一種標準。

　　Netflow的缺點中，第一種其實並非Netflow技術的缺陷，而是基於「流」的網絡信息採樣的共性缺陷，第三種爲Netflow這種傳輸層協議在設計的時候出現的缺陷，而第二種更偏向於「哲學」問題，「想看的更多就得花費更多的代價」，不想付出代價還想對網絡進行細粒度的觀察，是不可能的，就比如「你不能要一把槍射程又長，精度又高，爲例又大，體積又小，射擊速度又高」，這是不現實的。

【IPFIX】

　　IPFIX協議，IETF提出的一種「標準流信息導出協議」，目的就是爲了替代Netflow v9協議和衆多的方言版本協議，能夠看作是將來的趨勢，大多數廠商都已經兼容IPFIX協議，例如思科、華3、華爲的交換機，VMware一樣將IPFIX導出協議做爲一種標準的流信息導出協議。

可是要注意的是IPFIX協議只是一種「信息導出協議」，目的是爲了替代Netflow架構中的Exporter到Collector中的信息導出協議，可是總體架構基本如Netflow架構。IPFIX協議由Netflow v9協議發展而來，Netflow協議中的協議頭的version爲9，意味Netflow v9，而IPFIX協議中的協議頭與Netflow v9基本一致，而且version爲a（10），也就是Netflow v10，如圖6.

 

圖6.IPFIX頭格式和Netflow v9頭格式對比

 

 

　　而IPFIX做爲IETF推出的標準流信息協議，在Netflow v9的基礎上作了以下的改進：

1. IPFIX的傳輸層協議較於Netflow v9支持更加多樣化，支持UDP、TCP、SCTP協議做爲傳輸層協議的選擇；（這點請見RFC 7011的10.1節）
2. IPFIX相較於Netflow v9協議新增了企業字段、變長內容等新特性，能夠支持一些企業內部私有的數據導出（這個是我認爲最方便的一點特性）；（rfc 7012有詳細解釋）
3. IPFIX協議的模板內容相較於Netflow v9增長了很是多，能夠導出更多的信息。（同見rfc 7012）

　　能夠看到，IPFIX相較於思科的Netflow更是一種協議標準，其中的企業字段能夠很好的兼容一些方言版本的流信息導出協議，解決了不少兼容的麻煩，而且從功能的角度講，IPFIX是兼容Netflow v9的（注意這裏的功能值指的是導出內容上IPFIX要更全於Netflow v9），可是單純從協議的角度講是無法兼容的（也就是仍然得增長IPFIX的開發量）。

【INT】

　　INT技術是最近幾年一種新型的網絡遙感技術，全稱是Inband Network Telemetry，意味「帶內網絡遙感技術」，是由思科提出的一個技術，INT是一種技術手段，一種思想，在思科產品中的應用叫作IOAM（inband OAM）那麼這裏就有一個新的概念，什麼是「inband」？inband的意思直譯是「帶內」，可是「帶內「又如何理解呢？

　　我我的的理解是：相似於Netflow或是IPFIX這類流監控技術，能夠稱之爲」outband「，也就是帶外。舉個生活中的例子，帶外就比如你是一個監控人，你在監控這條流的狀態，你仍然處於一個旁觀者的位置，既然是在一個旁觀者的位置，那麼觀測的方法和觀測的位置勢必會對觀測的結果有很大偏差；而怎麼最大化消除這種偏差呢？生後中的經驗告訴咱們叫作」設身處地「，也就是咱們把本身擺在當事人的視角去看待事情，那麼咱們能夠看到更多有關事情的真面目，而inband就是這樣，inband Network telemetry就是這麼實現的，將旁觀者監測流，改成將檢測信息植入到數據包內部，這樣就至關於監測點掛載到了流中的每個數據包，那麼這樣數據包所經歷的，必然是監測點所經歷的。

 

圖7.INT的實現方式

 

　　如圖7所示，INT的實現方式就是將監測檢查點插入到數據包的內部，也就是途中的OAM層，INT一般的作法就是將數據包的頭（header）和數據包內部數據（payload）之間插入一塊OAM層，那麼這個數據包就從一個普通的網絡數據包變成了一個被咱們打上」標記「的數據包。再舉個例子，相信看過動物世界節目的朋友都知道，海洋學家爲了監測一些動物的行爲軌跡，會在海洋動物身上裝上遙感器，好比海龜、海豚、企鵝之類的，那麼最後海洋學家就能夠回收海豚的探測器，並根據探測器中記錄的數據來分析這個海豚的行動軌跡，海豚的行爲特徵。那麼INT就是這個原理，間圖8.

 

圖8.INT技術監測網絡情況的原理示意

　　如圖8中的例子，一個數據包（就比如一隻海豚）進入」起點「網元設備（被科學家捕獲）後，被插上了OAM層（被裝上了探測器），然後數據包通過每個網元（每一片海洋），都會將探測信息插入到OAM層中（被探測器記錄），包括網元對數據包的行爲，是轉發仍是丟棄（海豚死亡），最後數據包到達終點後，數據包中的OAM層被剝離出來，經過信息導出協議上傳到遠程的分析服務器（探測器被科學家回收分析數據）。那麼這裏有一個問題，網元設備，也就是OAM域內的傳輸節點怎麼知道要收集哪些信息呢？

 

 

 圖8.IOAM數據包中的OAM層

　　實際上，OAM層是由兩部分組成的，一部分叫作instruction，也就是指令，另外一部分就是data，也就是數據，指令中會攜帶須要收集的信息，translation node只須要根據指令把相應的信息塞入data部分中便可完成數據的收集。

　　能夠看到INT技術自己的原理仍是很是簡單的，就是在數據包內部插入一個自定義的層，而後記錄通過每個網元的信息，最後再將探測信息上傳至遠程的分析服務器。那麼INT技術會帶來什麼樣的優點，或者換句話說，能夠怎麼應用這種技術呢？

1. 數據包粒度級別的丟包監測，因爲監測的粒度從流變成了更細粒度的包，那麼理想狀況下，INT技術是能夠得知網絡中丟包的狀況以及丟包的緣由還有丟包的位置。
2. 捕獲網絡中的jitter現象，網絡中常常會出現一些jitter，jitter的特徵每每是短暫難以捕獲的，而因爲INT技術是一種帶內技術，那麼理想狀況下仍然是能夠捕獲到網絡中的時延或是丟包的jitter。
3. 智能路由和選路，根據OAM數據信息，能夠得知網絡中的每一條鏈路的時延、帶寬以及丟包狀況，那麼就能夠根據這些數據進行智能選路，將一些重要的流量進行從新reroute。

　　可是INT技術一樣帶來一些顯而易見的缺點，以傳統的INT技術，也就是思科的IOAM爲例：

1. DCN網絡或者是運營商網絡中，數據包數量巨大，對每個數據包進行插入OAM層，並進行監測，會產生巨量的信息，這麼多巨量的信息該如何壓縮、去重分析？
2. 」起點設備「（在INT技術中被稱爲encapsulation node）要對每個數據包進行插入一個新的OAM層，這會產生巨大的性能消耗，若是是轉發設備的轉發過程是軟件實現的，那對轉發性能更是毀滅性的打擊（你須要不斷的申請新的空間，並將原有的數據包進行拷貝，而後再插入一個新的層，事實上思科也注意到了這一點，因此在encapsulation node插入新的OAM層時有兩種實現，這點之後在詳細分析INT時再說）。
3. 轉發設備須要不停的將探測數據插入到數據包內部，並對數據包的checksum須要從新計算，一樣是一個性能消耗點。
4. IOAM技術中，轉發節點會不斷的向hdr與payload間插入OAM層，那麼考慮到數據包會被分片，OAM層的長度必然有限制，也進一步等於OAM數據包所通過的轉發設備（在IOAM技術中，這些轉發設備所組成的域稱之爲OAM域，OAM domain）不能太多。

　　IOAM的軟件實現能夠去看VPP的源代碼，VPP 17.xx版本之後的版本中都帶有IPv6的IOAM實現。

【PBT】

　　PBT（Postcards-Based Telemetry）技術本質上也是INT技術，是由華爲提出的一種基於思科IOAM技術的」升級版「，能夠理解爲一種優化版，華爲主要是針對IOAM缺陷中的第2條、第3條以及第4條進行了優化，而且華爲推出了兩種優化版，一種是PBT-I，另一種是PBT-M，前者爲超級版，後者爲兼容版。那麼PBT是怎麼作的呢？其實PBT的優化有點相似與以前說的主動探測的包注入技術。既然PBT技術本質上和IOAM技術並沒有不一樣，一樣拿海豚的例子來舉例：

• IOAM：一條海豚被海洋學家捕獲，海洋學家向海豚身上裝了一個探測器，探測器不能聯網，可是有內置硬盤，海豚帶着這個探測器遊遍太平洋，每通過一片海域，探測器就會收集信息，而後一年後被海洋學家蹲點捕獲，拆掉探測器，海洋學家根據探測器的內置硬盤中的數據進行分析。
• PBT：一條海豚被海洋學家捕獲，海洋學家向海豚身上裝了一個探測器，探測器內部沒有硬盤，可是有通訊模塊，海豚帶着這個探測器遊遍太平洋，每通過一片海域，探測器就會收集信息並馬上傳給遠程的海洋學家的服務器，海洋學家根據服務器接收的數據就能夠分析，或者是能夠先將數據存儲到數據中心，等一年事後，海洋學家捕獲了海豚，考慮到保護海洋動物的責任感，拆除了探測器，並根據數據中心完整的數據進行分析。

　　能夠看到，PBT和IOAM技術最大的不一樣是PBT是沒有攜帶OAM探測數據的，而是沒通過一個轉發節點（嚴格來講是OAM域內的translate node）都會馬上上傳信息，具體如PBT-I技術的實現原理能夠如圖9所示。

 

 

 圖9.PBT-I技術的實現原理

　　那麼PBT-T的原理敘述以下，數據包通過OAM域（能夠理解爲INT的監測域），並進入「起始節點」（encapsulation node），起始節點對數據包進行標記，注意這裏是標記，並非插入OAM層，和主動探測中的包注入技術相同，那麼被標記的數據包，接下來能夠稱之爲PBT探測數據包，接下來PBT探測數據包通過OAM域中每個網絡設備（translation node），傳輸節點都會去檢查數據包中的標記位，觀察是否時PBT探測數據包，若是是PBT探測數據包，則馬上上傳監測數據。

　　可是這裏仍然有一個問題，既然從原始的IOAM數據包的「監測模板」 + 「監測數據」縮小到只有1個bit的標記位，那麼設備怎麼知道要收集並上傳那些信息呢？這個地方能夠經過相似於ipfix的模板來實現，也就是實現管裏面或者控制面向OAM域中的每個傳輸節點下配置通知收集哪些信息。這樣的話，管控面須要對OAM域中的全部節點下發數據收集的模板配置，而不像IOAM同樣，只須要給encapsulation node下發數據收集的模板配置就行了。

　　那麼根據上述的原理介紹，咱們至少能夠知道，PBT-I相較於IOAM作了以下幾種較爲明顯的改進：

1. 收集的數據多少再也不受限於數據包的長度，由於收集的數據再也不插入在數據包的內部。
2. 不用對每個數據包進行十分浪費性能的插入收集數據，從新計算checksum等操做，對於ipv4數據包，只須要看一下ipv4 header中的標記爲，例如TOS中的reserve bit，就能夠知道要上傳哪些信息。

　　光這兩點改進，其實就已是質變了，尤爲是第二條的改進，大大的增長了INT技術在軟件轉發平臺上的可行性（軟件實現的轉發平臺最怕的就是對數據包進行從新分配內存+內存拷貝+從新計算checksum，這些會帶來大量的性能消耗），可是世界上沒有一種完美的技術，PBT-I技術的改進一樣帶來了其餘的缺點：

1. 管控面須要對OAM域中全部的節點下發模板配置信息，告知OAM域中的節點遇見PBT探測數據包要上報哪些信息。
2. 因爲沒通過一個translate node都須要上傳信息，因此上傳的信息次數會進一步變多，這樣一樣帶來了某一個節點上傳的信息丟失的風險。
3. 須要時間同步和信息重組，即一個PBT探測數據包通過了n個網元，如何將這n個網元上傳的信息進行聯繫組裝。
4. 不靈活，沒辦法定製化，例如網絡中有A、B、C、D、E五條流，其中我須要對A、B兩條流收集的信息集合爲M，對C、D、E三條流收集的信息集合爲N。可是標記位只有一個，沒有辦法進行更細粒度的進行區分。

　　雖然帶來了這幾個缺點，可是PBT-I的改進確實讓人看到了軟件實現INT技術的可行性。說完了PBT-I，接着說說「折中版」PBT-M，華爲提出的draft中一樣認可了PBT-I技術作得太絕，致使了上述幾個問題的出現，那麼能不能稍微作的不那麼絕，來個折中點的方案呢？因此就來了PBT-M這種折中版本。

　　PBT-M相較於PBT-I技術，沒有徹底捨棄OAM層，而相比於IOAM技術，又放棄了在OAM層中插入探測數據，所以PBT-M就是至關於IOAM與PBT-I的折中，即：

　　數據包第一次通過encapsulation node，一樣會插入OAM層，可是，直插入instruction，不插入data，至關於只插入收集指令，用於告知當前PBT探測數據包通過的每個網元，要給這個數據包收集什麼樣的信息，而後再將這個信息導出至遠程的分析服務器。那麼根據這個特徵，咱們能夠知道，實際上PBT-M時對PBT-T的4條缺點中的一、4進行了優化，管控面只須要給encapsulation node下發配置便可，舉個例子，網絡中有A、B、C、D、E五條流，其中我須要對A、B兩條流收集的信息集合爲M，對C、D、E三條流收集的信息集合爲N。A、B兩條流的數據包通過encapsulation node時，encapsulation node根據管控面下發的配置，對A、B中插入OAM層，instruction爲M，對C、D、E插入OAM層，instruction爲N，假若A流的數據包通過translation node時，translation node根據內置的OAM層中的instruction M就知道該上傳instruction M所對應的數據，這樣靈活性大大增強。不過PBT-M這種折中版仍然會帶來IOAM技術中的缺點2，也就是encapsulation node須要對這個數據包插入OAM層，對軟件實現來講仍然不友好。

【總結-說一說我本身的一些見解】

1. 主動包注入技術只能排查當前正在發生的一些網絡故障，所以侷限性較大，可是性能消耗小且易用，可是診斷的粒度很細，能夠馬上獲得網絡中正在發生的故障、故障位置以及故障緣由
2. Netflow或是IPFIX這種傳統的基於流的被動網絡探測技術，相較於主動探測技術性能消耗要大，而且存在測不許有偏差的狀況，粒度也不盡人意，可是做爲一種監控出身的技術，仍然是主流且容易實現的一種技術。
3. INT技術對於網絡探測能夠說是吊打Netflow或是IPFIX這種基於流的被動監測技術，可是INT技術中的IOAM技術目前看來不適合軟件實現，固然barefoot推出了支持INT技術的轉發芯片，讓IOAM技術能夠得以應用，不過芯片的價格感人，聽說一片要8000刀（去搶吧...），目前barefoot已經被intel收購，後續什麼狀況還猶未可知，目前IOAM這種INT技術的具體實現更多的都是基於硬件實現，而後與P4編程打組合拳。
4. INT技術中的PBT技術，目前對軟件實現比較友好的是PBT-I，固然對於PBT-M技術而言，若是encapsulation node是支持INT的硬件轉發設備，那麼PBT-M的靈活性確實是要比PBT-I更勝一籌的。

唉，網絡遙感技術這塊領域，大佬打架，我等渣渣只能吃瓜了....

先站一個坑，之後再慢慢具體說一說這些技術的一些具體細節，以及該怎麼實現。