成熟丰满熟妇av无码区,亚洲日本va午夜中文字幕,日本精品久久久久影院日本,国产AV巨作饥渴难耐的男雇主

　　網絡帶寬已經跨過了10M/100M/1000M，當前的10G、N*10G的高速帶寬正成為網絡建設的基本規(guī)格。隨著>8*10G性能的需求日趨強烈，超高速網絡(40/100G平臺)技術已經開始在當前的數據中心部署使用。

　　云計算網絡的性能要求超過常規(guī)應用數據中心，這樣的要求使得網絡平臺構建上性能的考慮區(qū)別于傳統(tǒng)的認識，深入認識云的底層特質。網絡的交換容量和網絡浪涌的吸收容量即是云計算(或大型數據中心)網絡的性能關注點要同時關注的兩方面。

　　超高速交換網絡之前的幾個概念

　　線速

　　指的是線路數據傳送的實際速率能夠達到名義值，比如千兆端口能夠實際吞吐量到千兆，這在交換機是比較輕松的事，但是早期的高端路由器端口如果能夠達到千兆實際轉發(fā)速率，那是非常了不起的(不過現在已經稀疏平常了)。

　　超線速

　　如千兆端口能夠吞吐的流量超過一千兆(一般也就超出一點點)，這種交換機與標準線速設備對接后容易產生丟包甚至將標準交換機“堵死”。在數據中心環(huán)境下極少數情況也允許滿足超線速的組網，只是對交換機有特殊要求。

　　全線速

　　交換機的所有端口能夠同時達到線速轉發(fā)。這個能力也體現了交換機的性能，對于某些性能較低的設備，稱為達到全線速轉發(fā)，是指達到了設備的最高性能而已，有可能離該交換機的端口容量總和還遠著呢。

　　“無阻塞”全線速

　　有時候在全線速前面再定義一個“無阻塞”，其實是強化交換機的全線速能力，指的是對交換的任意大小字節(jié)的報文均能夠達到全線速的能力，所有端口都以線速接收幀，并能無延遲地處理被稱為“無阻塞（Nonblocking）”，之所以這樣叫是因為設備內部沒有等待處理的報文（沒有阻塞）。但是無阻塞有時也會遇到挑戰(zhàn)，在很小的概率下(即實際測試中極不容易出現)，確實能夠構造特定測試例使得交換機產生阻塞，這是因為傳統(tǒng)交換架構下理論上也能分析出阻塞的可能性。

　　一、超高速交換網絡

　　傳統(tǒng)交換架構，非真正意義的“無阻塞”

　　在“數據中心級交換機”概念出現以前(這個概念也是隨著云計算發(fā)展而產生的，此前只有核心交換機、高端交換機的概念)，盒式交換機一般是單芯片，機架式交換機則主要是“交換網+IO芯片”結構，比較先進的交換網一般采用crossbar，架構如圖1所示。

　　傳統(tǒng)高端設備以交換線卡連接crossbar高性能交換網，數據在Crossbar內部選路基于實現配置好的規(guī)則，同一數據流在內部的運轉路徑是確定的(HASH算法)，因此存在特殊情況下在交換不同級層上會發(fā)生阻塞的現象，如圖1的數據流1和2在第一級、數據流3和4在第二級的阻塞(情景有點類似于等價路由或鏈路捆綁的流量不完全均衡性)。這種架構的交換網容量并不大，一般以支持10GE為主。這種非真正意義的“無阻塞”在一般性數據中心并不會遇到挑戰(zhàn)，但在大型互聯(lián)網數據中心，隨著近年來ISP業(yè)務不斷豐富、業(yè)務規(guī)模不斷擴大和實際帶寬消耗迅猛增長，已經出現了傳統(tǒng)交換架構在互聯(lián)網數據中心難以滿足性能需求的現狀。

圖1傳統(tǒng)Crossbar交換架構的阻塞分析模型

　　無阻塞交換，云計算核心交換平臺的關鍵且基本的要求

　　到了新一代交換平臺產生的時代，數據中心級核心交換平臺的能力已經確定在10Tbps的級別，交換系統(tǒng)的架構產生了本質的變化，這種變化是為了應對云計算超高速100G、以及實現今后10T環(huán)境下的完全無阻塞所帶來的挑戰(zhàn)而變革產生的架構，也就是CLOS架構。

　　那么，完全無阻塞的意義就是對一個交換架構無論是理論分析還是實測，都能夠達到真正的無阻塞交換(如果不能全線速，完全無阻塞也用處不大了)。完全無阻塞的概念，也是在云計算環(huán)境下開始逐步強調的，因為云計算中心應用密度比之傳統(tǒng)數據中心高得多，流量情況更為復雜，數據性能要求更為嚴格，如果在交換平臺核心不能滿足完全無阻塞的交換條件，瞬時引起的阻塞必然會導致網絡流量異常，即使是理論上小概率的瞬時阻塞，也可能在云計算網絡中反復出現。這對大型網絡來說，是存在隱患的，因為不斷增長的業(yè)務和流量可能因為核心平臺的隱患而有所限制(莫名其妙的情況下發(fā)現網絡偶然不暢)，這種潛在問題有時是無法分析清楚的，特別是已經在運行的網絡。因此，完全意義上的無阻塞交換，是云計算核心交換平臺的關鍵而基本的要求。

　　新一代交換架構三級CLOS&CELL交換可支持完全無阻塞交換，是完全遵循復雜業(yè)務流要求的，能夠將大規(guī)模密集流量在交換系統(tǒng)內部均勻交換，避免了阻塞帶來的性能惡化與嚴重下降。其實現基本原理如圖2所示，在系統(tǒng)內部采用動態(tài)選路方式(線卡、交換網保存內部數據轉發(fā)路徑信息，如果出現路徑不可用或網板、線卡故障，選路信息動態(tài)改變，這一切操作由硬件系統(tǒng)內完成)，業(yè)務線卡接收到的數據包文，進行等長切片處理形成定長信元，每個信元加載動態(tài)選路的標記頭(長度不夠的信元會進行內部填充)。

圖2H3C新一代CLOS架構&Cell交換實現模型

　　如何構造無阻塞交換網絡

　　云計算需要超大的計算能力和網絡交換能力，通過網絡來組織數千臺至上萬臺服務器的協(xié)同計算，因此云計算的支撐網絡也提出了無阻塞的方向。

　　首先看如何構造大規(guī)模的線速網絡，如圖3所示，從兩個方向來擴展，在層次上，每一層的交換設備上行所有鏈路帶寬與下行的所有鏈路帶寬相等，在同一層次，按照下一層設備的上行端口數擴展，如此直到最高層(目前主流構造兩層到三層網絡結構)。

圖3大規(guī)模網絡擴展方式

　　構造線速交換網絡比較簡單，但是要達到無阻塞，當前的技術實現還不夠徹底，因為在網絡級別只能使用鏈路負載均衡技術實現對帶寬的充分利用。如圖4所示，實現方式主要有兩種。

圖4鏈路負載均衡

　　Roundrobin方式：將數據流依次向可用鏈路均勻轉發(fā)(可以基于統(tǒng)計速率、也可以基于逐包方式)，一般來說，當服務器之間全部使用定長報文(如1500字節(jié))交互數據，基本就構成了一個“完全無阻塞交換網絡”(是定長數據交換條件下)，但是存在的問題是，同一數據流的不同報文可能經過不同網絡路徑到達目的地，經過網絡大規(guī)模流量浪涌后會存在嚴重的亂序問題。

　　HASH方式：使用網絡設備的硬件負載均衡算法，基于數據流的二三層地址信息和四層端口號信息得到不同鏈路的選路信息，能夠保證同一數據流經過相同路徑到達目的地，避免亂序，但是不同數據流因為流量大小有差異，使得網絡不同鏈路難以完全均衡，不過在當前技術條件下，不均衡度已經極小，十分接近完全無阻塞交換網絡了。

　　二、浪涌，云計算環(huán)境下的一個網絡現象

　　在云計算環(huán)境下，性能無疑成為最為關注的核心要素，但是，有了超高速的交換性能，不一定表示網絡能夠達到理想的效果,還需要關注網絡浪涌的吸收容量，我們從分析端口流量情況和網絡實際流量情況入手。

　　端口流量

　　圖5是我們進行毫秒級網絡流量研究時得到的流量圖，不妨稱之為微觀流量視圖(事實上早在2000年左右，運營商的研究機構已經在622M骨干網發(fā)現了這個現象)。在秒級、分鐘級以上的宏觀時間尺度下，流量A和B的采樣曲線十分平滑，這是因為流量觀測的累積平均效果造成的，當采樣尺度縮小到毫秒級，我們發(fā)現，從端口得到的流量曲線發(fā)生了變化，最高的流量值可能達到平均流量的2-3倍

圖5微觀的流量視圖

　　這個問題的本質來源于交換機的線速轉發(fā)特性(實際上核心、高端交換機內部還有更大的加速比，即內部交換通道速率一般遠高于對外的端口速率，但我們不必過于復雜化)。線速轉發(fā)的機制，使得交換機在接收或者發(fā)送任意一個報文的時候，都不同于我們觀察到的結果(我們看到的都是一段時間內的平均速率)，任一個報文都是以千兆或萬兆速率在轉發(fā)，而且持續(xù)達到線速后，報文之間的轉發(fā)時間間隔(或稱幀間隙)達到了最小值。我們以圖6為例作一個不太嚴格的分析，在千兆端口下，假定轉發(fā)的報文大小為端口MTU級，即報文為1500字節(jié)，計算出的串行化時延約為12微秒，由于報文之間還有幀間隙，為簡單起見，假設為8微秒(實際幀間隙非常之小)，那么一個報文的轉發(fā)到鏈路時間為20微秒。也就是說，要體現交換機線速轉發(fā)，端口上每20微秒就發(fā)送一個1500字節(jié)報文。隱含的事實是，任何一個1500字節(jié)的報文都以20微秒的標準在交換端口轉發(fā)出來，所用帶寬均為1Gbps。

圖6微觀采樣的理想化分析

　　那么如果網絡中我們觀測到一個端口流量是500Mbps，該如何來理解這個信息呢？如圖7所示，最理想的情況當然是每40微秒轉發(fā)一個報文，這樣網絡流量最平穩(wěn)，最惡劣的情況是，在觀測周期內，前半段時間流量20微秒的密集(即持續(xù)千兆速率轉發(fā))，后半段時間無數據轉發(fā)。當然，正常情況下是界于二者之間非常隨機的。

圖7平均速率的理解模型

　　網絡的實際流量

　　網絡是由多個網絡設備組成的，網絡的流量難以有很合適的描述模型，不同的網絡業(yè)務模型、性能要求都不一樣，我們只分析網絡數據流的走向情況。

　　先看一個全線速、完全無阻塞交換機的數據流向,包含兩種情況（如圖8所示）。不論是A還是B，對單個網絡節(jié)點而言，即使是全線速無阻塞的性能，也面臨著在短時間的高帶寬向低帶寬的數據流向，相對而言情況A比較容易確定，情況B比較復雜。因此分析網絡的實際流量，其本質上網絡節(jié)點的流量并不是均衡的，也就是說，網絡實際流量并不是完全按照網絡設備的無阻塞架構來轉發(fā)的，總是會造成一個瞬時擁塞，即進入交換機的帶寬比出交換的帶寬要高，如數據中心內部多臺服務器向少數服務器傳送數據的情況，如圖9所示。左邊兩種情況都不會影響業(yè)務性能，但是最右邊引起瞬時擁塞，如果產生丟包，必然對上層應用產生影響，特別是云計算環(huán)境下，數據流量超大，擁塞的數據被丟掉后必然使得整個云平臺的性能和可用性大為降低。這種惡劣的影響并非網絡設備交換性能不夠產生的，實質上是網絡流量的不可控可變帶寬比產生瞬時收斂造成的(如多個萬兆到少數萬兆、萬兆到千兆等)。

圖8定向與不定向的網絡流量

圖9網絡中的可變動態(tài)帶寬比

　　基于以上兩方面的分析，我們確定云計算環(huán)境下的一個網絡現象---浪涌(在一般網絡條件下稱為流量突發(fā)，burst)，密集的高速流量，瞬時的收斂性數據傳輸與同步特點。比之一般網絡的突發(fā)更為嚴峻的是云計算網絡一旦發(fā)生擁塞丟包，所需要處理的數據量比常規(guī)條件下大得多。如圖10所示，網絡端口的平均流量并不高，但是從兩個端口向一個端口的流量由于疏密不均，造成了突發(fā)。在入端口方向，由于交換線速轉發(fā)的特點，宏觀平緩數據流在不同毫秒級范圍內度量結果也不一樣(340pps～800pps的成倍關系)，當這兩個端口流量要向同一端口輸出時，是不是會造成更為惡劣的流量突發(fā)---浪涌情況？

圖10突發(fā)的基本形態(tài)

　　突發(fā)畢竟是瞬時的，一般情況下認為是毫秒級的或亞秒級的(所以叫瞬時擁塞)，而平均流量并沒有達到所用的帶寬，如果是持續(xù)的擁塞，則應該是帶寬需要擴容了。

　　對網絡節(jié)點的突發(fā)分析也適用于整個云計算網絡，即使是無阻塞的網絡架構，其上承載的浪涌突發(fā)數據流也是不定向的，整個網絡的浪涌吸收能力決定了云計算的密集數據吞吐、交互、處理能力。

　　三、云計算核心交換網絡的緩存結構

　　對于交換機而言，緩存方式也有不同的機制：出端口和入端口緩存。傳統(tǒng)技術實現多以出端口緩存為主，這種機制使得所有數據流的突發(fā)在出端口處被緩存，緩存的大小即是網絡最大可能的突發(fā)值。

　　新一代云網絡的核心交換平臺一般采用入端口緩存（如圖11所示），一般結合虛擬輸出隊列(VoQ)技術，在每個入端口方向配置大容量緩存，在出端口配置較小緩存，使用專用流量管理器件TM(trafficmanager)進行內部流量管理，并采用credit來控制每個端口入方向的數據向出端口的突發(fā)，每個出端口向其它入端口分配credit數量，當出端口在線速向外轉發(fā)數據時，如果入方向過來的數據速度較快，在達到或超過出端口設定的突發(fā)門限時，出端口不再為入端口分配credit，從而使得入端口的數據緩存在本地的大容量buffer中，當出端口(保持線速對外轉發(fā))的排隊下降到門限以下，繼續(xù)向入端口分配credit，使得緩存的數據得以繼續(xù)轉發(fā)。

圖11入端口緩存

　　因此入端口緩存機制下，各端口的數據在出端口擁塞時都能在本地緩存，因而緩存容量是與入端口數成正比的線性關系。這種線性比例的緩存能力，能夠自適應于云計算的不定向浪涌流量，交換緩存架構能夠自動調節(jié)不同方向的瞬時流量擁塞壓力，是當前云計算網絡的主要應用技術。

　　而對于時延與緩存，很多人一談到大緩存設備，立即聯(lián)想到大的交換時延，而低時延必然是小緩存，其實，兩者之間并沒有必然的聯(lián)系，一切取決于網絡的應用情況。對于交換而言，一般的存儲轉發(fā)時延是幾個微秒，與緩存大小并無絕對關系，如圖12所示，對于無擁塞的輕載網絡A，數據進入交換機緩存后立即進行查表轉發(fā)，大緩存和小緩存的效果是一樣的，當出現瞬時擁塞后如B，大緩存能夠避免丟包(重傳引起的時延比緩存的時延大多了)，而小緩存在大規(guī)模突發(fā)流量下如C，必然對突發(fā)的緩存量少，會丟棄報文。

圖12時延與轉發(fā)

　　但并不是所有應用都需要大緩存(畢竟成本不一樣)，因此考慮到時延的網絡平臺需要根據應用的具體情況構建，一般情況下建議實測來選擇建網方案。

　　四、浪涌緩存模型分析---多大緩存合適

　　有不少研究曾經著重于網絡到底需要多大的緩存，最著名莫過于圖13這個公式了，該公式更多地被應用到路由器作為廣域鏈路連接時的緩存大小確定，其目的是為了充分利用昂貴的廣域網帶寬。

圖13常見的緩存公式

　　其中：Buffer指緩存大小，單位Byte；BW數據傳送帶寬；RTT(Round-TripTime)往返時延，在網絡中它是一個重要的性能指標，它表示從發(fā)送端發(fā)送數據開始，到發(fā)送端收到來自接收端的確認(接收端收到數據后便立即發(fā)送確認)，總共經歷的時延。

　　數據中心的緩存如何來建模呢？數據中心與廣域網有顯著區(qū)別，內部帶寬可以是足夠的(高速交換)，但是突發(fā)浪涌很嚴重，那么緩存主要不是用來充分利用帶寬的，而是用來吸收浪涌的。這里的模型并不具有嚴格的學術意義，但是，用戶如果能夠在日常注意收集數據中心的相關業(yè)務數據，對于自身的緩存需求建模和網絡性能分析是很有參考意義的，下文描述的模型有助于分析某些應用中的問題。

　　動態(tài)收斂比：N

　　如圖14所示，在云計算網絡中，由于整個網絡都可能是無阻塞的，從表面上是看不

圖14動態(tài)收斂比定義

　　簡單起見，假設端口的帶寬BW是固定的(千兆或萬兆)，流量的入端口數為Mi，出端口數為Me，要求Mi大于Me，那么：

　　-----------------------------公式1

　　突發(fā)數據量和網絡傳送時間：D和T

　　我們再來定義兩個指標，如圖15所示，對于構建云計算網絡的用戶來說，Tm是由業(yè)務層面提供的參考數據，D也應由業(yè)務層面給出，但一般難有具體值，需要經過分析來獲取，后文將給出兩個分析案例。

圖15突發(fā)數據量和網絡傳送時間

　　實際的數據傳送時間為t，t必須小于等于Tm才能滿足業(yè)務要求，那么：

　　----------------------------------公式2

　　臨界緩存值：buffer0

　　我們再定義一個臨界緩存值buffer0，是指能夠剛好滿足突發(fā)要求的最小緩存值，即在數據D的突發(fā)量下，buffer0剛好能夠容納這些數據(因為在緩存容納數據的同時，出端口還在往外轉發(fā)數據)，如圖16所示。

　　我們借用水池漏水的題目，如圖16所示，蓄水池的大小是buffer0，粗水管以BH的速率往水池里灌水，細水管以BL的速率往外流水，問題：

　　1.當水池裝滿后，粗水管一共灌了多少水？

　　--------------求突發(fā)量D與buffer0、入出帶寬BH和BL的關系

　　2.如果當水池滿后就停止灌水，那么從最開始灌水，到水池的水流干，一共要多長時間？

　　--------------求突發(fā)量D下，數據傳送時間t與buffer0和帶寬關系(是否滿足應用的需求)

圖16臨界緩存buffer0

　　通過對以上問題的求解（由于篇幅有限，這里求解過程略去），我們得出當網絡的出帶寬等于入帶寬時，是不需要buffer的。同樣，根據公式分析，在發(fā)生瞬時擁塞的條件下，增加出口帶寬(入帶寬不變)可以減少對buffer的要求。

　　臨界緩存與收斂比的關系如圖17所示，出帶寬增加，不僅收斂比減小，buffer0的要求降低，同時根據t=D/BL得知相同突發(fā)數據量的傳送時間大幅降低。反過來也根據模型得出，收斂比減小出方向帶寬增加時可突發(fā)的數據量比原有收斂比要大。

圖17臨界緩存與收斂比的關系

　　如果網絡的收斂比不變、緩存也不變，但是隨著業(yè)務量的突發(fā)嚴重，要求更大的突發(fā)量，該如何調整？根據模型公式分析，需要應用層進行調整，即對數據突發(fā)進行平緩處理(避免突發(fā)過于集中超過buffer0導致大量丟包)，同時增加Tm的值，即允許網絡傳輸時間更長。

　　上述公式比較離散，分析問題時需要根據條件不斷轉化，雖然云計算環(huán)境非常復雜，但是只要在網絡規(guī)劃、運行過程中不斷收集參數，對浪涌的分析與優(yōu)化是可行的

　　兩個傳統(tǒng)數據中心實例說明如何利用模型進行分析

　　實例分析一：網絡搜索

　　應用的基本描述

　　查詢服務器向200臺響應服務器發(fā)起請求

　　每臺響應服務器發(fā)出60KB的數據，折合1.5KB報文約40個，響應服務器在最短時間向網卡發(fā)送數據，時間非常短(1-2毫秒)，可認為所有服務器發(fā)生了瞬時突發(fā)

　　查詢服務器將所有請求收到的時間規(guī)定在40-60毫秒內，我們設為50毫秒

　　當時使用的這個設備緩存大，但是緩存分配的個數只有4K個單元，且均分到不同端口，因此隨著應用的負載增加，逐步出現檢索丟包的現象。

圖18搜索模型的簡單分析

　　從上面的一些數據，可以得到

　　突發(fā)數據量D=200*60KB=12MB

　　業(yè)務響應要求時間Tm=50毫秒

　　網絡收斂比是200千兆端口數據發(fā)向1個千兆端口，但是最嚴重的地方在于查詢服務器所在的交換機兩個萬兆流量打入A所在的千兆端口，不妨設定收斂比為N=20G:1G=20

　　那么平均要求的傳輸帶寬是12MB/50毫秒=1.9G，說明現有的帶寬1G根本不能滿足業(yè)務需求。

　　現在應用進行調整，將60KB數據降低到30KB，此時D=200*30KB=6MB,1G帶寬是可以滿足要求的，現在來看緩存的要求，根據模型公式，buffer0=(1-1/20)*6MB=5.7MB，按照1.5KB一個報文，buffer0至少需要緩存報文個數為5.7MB/1.5KB=3.8K個，因此一個設備的緩存不僅要求大小為5.7MB，可緩存的報文個數還要在4千個左右。

　　為了優(yōu)化性能，可以選擇兩種方式來改進。

　　第一種是將緩存的所有單元全部分配給查詢服務器單端口，這樣能夠滿足突發(fā)所需的緩存需求。但是對于負載增加，入信息增加到60KB、服務器群增加的擴展性有很大限制。

　　第二種，將查詢服務器改為萬兆，此時收斂比N=2，如果在現有緩存能力(4K個報文32MB容量)下，可以突發(fā)的數據量D=buffer0×N/(N-1)=4K*1.5KB*2=12MB，比原來突發(fā)量升了一倍。

　　而業(yè)務響應時間t=D/BL=12MB/10G=9.6毫秒，遠小于50毫秒的上限，而同步可傳輸的數據量是原來的10倍(帶寬增加了10倍)。如果應用層進行調整，平緩突發(fā)如分組或分時(以9.6毫秒為參考)，那么在50毫秒的響應時間條件下可獲取更大的突發(fā)能力。

　　實例分析二：校園網數據中心應用

　　20000學生規(guī)模，300臺左右服務器

　　兩臺接入設備使用VRRP方式運行在三層主備模式。

　　上行各為一個千兆，兩臺設備之間為兩個千兆互聯(lián)

　　右邊設備為Master，使用了一塊4:1收斂的交換線卡上行，緩存<500KB，其它線卡緩存

　　問題是每學期學生集中選課時網絡異常，但是平均流量很小，不足200Mbps

　　當人為進行A和B鏈路切換(數據流從B上)，VRRP主備不倒換時，故障消失，平均流量依然為200Mbps左右。

圖19校園網數據中心案例

　　經過現場診斷和深入分析，解決方法為將右側Master上行線卡更換為全線速、大緩存的線卡，運行至今未見問題出現。

　　問題分析：

　　選課一般時間比較集中，2萬個學生選課假定10%的同時在線率，說明服務器要對外處理8000個會話，假定每個報文為512B(報文大小不一，只能假設一個)，則突發(fā)數據量可假定為D=2000*512B=1MB，即D=1MB。

　　收斂比，按照數據流從A鏈路上行，N=20:1=20(假定只有同時20臺服務器對外工作，其它服務器可能還提供別的服務，也對網絡突發(fā)是有貢獻的)。

　　因此buffer0=(1-1/20)*1MB=0.95MB，說明緩存要求顯然高于現有網絡運行產品的要求。

　　那么，為什么數據流繞行B鏈路上行能夠緩解突發(fā)呢？

　　首先是Master向Slave發(fā)送端口的

　　根據模型公式，原來帶寬是1G，在緩存滿時已經傳輸的數據量是buffer0*1/19

　　帶寬到2G后，緩存滿時已經傳輸的數據量是buffer0*1/9

    1/19，說明原有緩存滿后，已經傳輸的數據量超過了原來的兩倍，這樣就極大降低了突發(fā)。從slave的角度，收斂比只有2:1，也能夠緩解緩存的要求，同時數據流經過了Master和slave設備，經過了兩級網絡緩存，進一步改善了突發(fā)。

　　五、結束語

　　云計算是前所未有的性能密集型IT業(yè)務模式已經是不爭的事實，云計算的發(fā)展將直接依托于超高速網絡，并依賴于超高速交換技術實現服務交付。然而超高速交換本身還不足以解決所有問題，圍繞超高速網絡環(huán)境下的多種關鍵技術還有待于無縫集成。