劉景林

（泉州經(jīng)貿(mào)職業(yè)技術(shù)學(xué)院信息技術(shù)系，福建 泉州 362000）

近年來，在網(wǎng)絡(luò)直播、網(wǎng)上貿(mào)易、云計(jì)算等應(yīng)用需求的推動(dòng)下，許多全球數(shù)據(jù)中心網(wǎng)絡(luò)相繼建立。與廣域網(wǎng)相比， 數(shù)據(jù)中心網(wǎng)具有部署靈活、 帶寬高、時(shí)延低等優(yōu)點(diǎn)。 數(shù)據(jù)中心網(wǎng)絡(luò)是由各種計(jì)算設(shè)備、 網(wǎng)絡(luò)互聯(lián)設(shè)備等相關(guān)設(shè)施組成的基礎(chǔ)服務(wù)集群。 在數(shù)據(jù)中心內(nèi)通過高速鏈路和交換機(jī)連接大量服務(wù)器的網(wǎng)絡(luò)，采用分層結(jié)構(gòu)實(shí)現(xiàn)，每個(gè)應(yīng)用程序運(yùn)行在特定的服務(wù)器或虛擬服務(wù)器集上。 數(shù)據(jù)中心網(wǎng)絡(luò)具有控制域單一、 網(wǎng)絡(luò)體系結(jié)構(gòu)同質(zhì)等不同于Internet 的特點(diǎn)，給設(shè)計(jì)帶來了機(jī)遇和挑戰(zhàn)[1]。由于TCP 協(xié)議在數(shù)據(jù)中心網(wǎng)絡(luò)應(yīng)用中存在傳輸性能方面的局限性， 所以在數(shù)據(jù)中心網(wǎng)絡(luò)中引入了Google 開發(fā)的新的傳輸協(xié)議QUIC(Quick UDP Internet Connection)， 該協(xié)議是基于 UDP 的傳輸協(xié)議，目的是保證傳輸可靠性的同時(shí)降低網(wǎng)絡(luò)延遲。QUIC 不僅減少了握手時(shí)延，而且在擁塞控制中引入了嚴(yán)格的遞增序列號(hào)機(jī)制， 實(shí)現(xiàn)了無隊(duì)列頭阻塞的復(fù)用，理論上，在傳輸性能方面明顯優(yōu)于TCP協(xié)議[2]。

目前，超大型數(shù)據(jù)中心網(wǎng)絡(luò)的應(yīng)用非常廣泛，隨著通信運(yùn)營商網(wǎng)絡(luò)業(yè)務(wù)的不斷增加， 重點(diǎn)研究超大型數(shù)據(jù)中心數(shù)據(jù)傳輸?shù)木C合性能， 以實(shí)現(xiàn)支持更多的業(yè)務(wù)系統(tǒng)。 所以，關(guān)于如何提高超大型數(shù)據(jù)中心網(wǎng)絡(luò)的綜合性能方面， 亟待進(jìn)一步深入的研究。

1 fat-tree 數(shù)據(jù)中心網(wǎng)絡(luò)

為了增加吞吐量、 降低時(shí)延以及緩解流量擁塞，數(shù)據(jù)中心網(wǎng)絡(luò)需要設(shè)計(jì)不同的拓?fù)浣Y(jié)構(gòu)[3]，如以fat-tree[4]和VL2[5]為代表的新型樹狀拓?fù)浣Y(jié)構(gòu)，以Dcell[6]和BCube[7]為代表的分層遞歸拓?fù)浣Y(jié)構(gòu)，以 SWDC（Small World Data Center）和 Jellfish[8]為代表的隨機(jī)小世界拓?fù)浣Y(jié)構(gòu)。 在數(shù)據(jù)中心網(wǎng)絡(luò)中，Leiserson 提出了fat-tree 的分層網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，它具有帶寬平分的特點(diǎn)，應(yīng)用極為廣泛。 以下是基于fat-tree 為背景研究QUIC 協(xié)議的網(wǎng)絡(luò)傳輸。

fat-tree 數(shù)據(jù)中心網(wǎng)絡(luò)采用多交換機(jī)級(jí)聯(lián)的三層拓?fù)浣Y(jié)構(gòu)，分為核心層、匯聚層和接入層（見圖1）。 然而，其與傳統(tǒng)的樹狀結(jié)構(gòu)不同，接入交換機(jī)和匯聚交換機(jī)被劃分為不同的集群。 在集群中，每個(gè)接入交換機(jī)與每個(gè)匯聚交換機(jī)相連， 形成一個(gè)完整的二部圖。 每個(gè)匯聚交換機(jī)連接一部分核心交換機(jī)，使每個(gè)集群連接到核心層交換機(jī)[9]。在fattree 結(jié)構(gòu)中， 提供了足夠的核心交換機(jī)來保證1∶1的網(wǎng)絡(luò)覆蓋率，并提供服務(wù)器間的無阻塞通信。

圖1 fat-tree 數(shù)據(jù)中心網(wǎng)絡(luò)

構(gòu)建fat-tree 網(wǎng)絡(luò)拓?fù)涞囊?guī)則是：fat-tree 拓?fù)渲械?pod point of Delivery)個(gè)數(shù)為k，每個(gè)pod 連接的服務(wù)器個(gè)數(shù)為(k/2)2，每個(gè)pod 中的接入交換機(jī)和匯聚交換機(jī)個(gè)數(shù)為k/2， 核心交換機(jī)個(gè)數(shù)為(k/2)2，網(wǎng)絡(luò)中每個(gè)交換機(jī)的端口個(gè)數(shù)為k，網(wǎng)絡(luò)支持的服務(wù)器總數(shù)為k3/4。

fat-tree 結(jié)構(gòu)可以通過核心層中的多個(gè)鏈路及時(shí)處理負(fù)載，避免網(wǎng)絡(luò)中的熱點(diǎn)，通過pod 中的合理分流避免過載。 fat-tree 的另一個(gè)優(yōu)點(diǎn)是它使用的所有交換機(jī)都是相同的， 這使得我們可以在整個(gè)數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)中使用普通的交換機(jī)[10]。

隨著網(wǎng)絡(luò)規(guī)模的擴(kuò)大，fat-tree 的匯聚帶寬增加， 可以為數(shù)據(jù)中心提供高吞吐量的傳輸服務(wù)[11]。對(duì)于不同pod 之間服務(wù)器間的通信，源節(jié)點(diǎn)和目的節(jié)點(diǎn)之間存在多條并行路徑， 因此網(wǎng)絡(luò)的容錯(cuò)性能良好，一般不存在單點(diǎn)故障。 采用商用設(shè)備取代高性能交換設(shè)備，大大降低了網(wǎng)絡(luò)設(shè)備開銷。 網(wǎng)絡(luò)直徑小，可以保證網(wǎng)絡(luò)上視頻、在線會(huì)議等業(yè)務(wù)的實(shí)時(shí)性要求。 規(guī)則對(duì)稱的拓?fù)浣Y(jié)構(gòu)，有利于網(wǎng)絡(luò)布線、網(wǎng)絡(luò)的自動(dòng)配置及優(yōu)化升級(jí)。

目前， 數(shù)據(jù)中心網(wǎng)絡(luò)中的數(shù)據(jù)流在很多情況下是分布不均衡的[12]，例如，在基于Web 應(yīng)用的數(shù)據(jù)中心中，當(dāng)傳輸多個(gè)小數(shù)據(jù)流時(shí)，占用的帶寬較多，因此對(duì)擁塞控制突發(fā)提出了更高的要求。 而當(dāng)前的QUIC 傳輸協(xié)議在TCP 擁塞算法的基礎(chǔ)上，它不使用TCP 根據(jù)字節(jié)序列號(hào)和ACK 來確認(rèn)消息的有序到達(dá)，而是使用新建的序列號(hào)，每個(gè)序列號(hào)均嚴(yán)格遞增，因此如果包n 丟失，則重傳包n 的序列號(hào)不是n，而是大于n 的值，這樣就很容易解決TCP 重傳的歧義性問題， 并且這種機(jī)制可以顯著提高吞吐量[13]。

2 QUIC 協(xié)議及其應(yīng)用

QUIC 是基于UDP 協(xié)議的低時(shí)延互聯(lián)網(wǎng)傳輸層協(xié)議，可以通過多路傳輸解決隊(duì)頭阻塞問題，通過0-RTT 握手降低傳輸層握手延時(shí)， 通過連接遷移更好地對(duì)移動(dòng)性提供支持， 能夠較好地解決當(dāng)今傳輸層和應(yīng)用層面臨的各種需求， 包括處理更多的連接，減少連接延遲，保障數(shù)據(jù)傳輸?shù)目煽啃缘葐栴}。QUIC 已在SDN 網(wǎng)絡(luò)和空間網(wǎng)絡(luò)中進(jìn)行了評(píng)估，其總體上優(yōu)于傳統(tǒng)TCP 協(xié)議，因此將其應(yīng)用于數(shù)據(jù)中心網(wǎng)絡(luò)具有很大的優(yōu)勢。

TCP 最重要的特性之一是擁塞控制機(jī)制，它通過調(diào)整傳輸速率來避免擁塞崩潰（見圖2）。 QUIC在 UDP 上實(shí)現(xiàn)類似于 TCP+TLS+HTTP/2。 由于TCP 是在操作系統(tǒng)內(nèi)核和中間件固件中實(shí)現(xiàn)的，因此幾乎不可能對(duì)TCP 進(jìn)行重大更改 （TCP 協(xié)議棧通常由操作系統(tǒng)實(shí)現(xiàn)，如Linux、Windows 內(nèi)核或其他移動(dòng)設(shè)備操作系統(tǒng)）， 修改TCP 協(xié)議非常復(fù)雜，因?yàn)槊總€(gè)設(shè)備和系統(tǒng)的實(shí)現(xiàn)都需要更新。 但是，由于QUIC 是基于UDP 的， 因此沒有這樣的限制。QUIC 可以實(shí)現(xiàn)可靠的傳輸，與TCP 相比，它的流量控制功能是在用戶空間而不是在內(nèi)核空間，可以根據(jù)應(yīng)用場景自由選擇，甚至自由調(diào)整和優(yōu)化，具有更大的發(fā)展優(yōu)勢。

圖2 QUIC 與 TCP 協(xié)議比較

2.1 0-RTT 往返時(shí)延

RTT（Round-Trip Time）是客戶端與服務(wù)器連接成功以及連接速度的重要參數(shù)。

客戶端發(fā)送數(shù)據(jù)之前，QUIC 協(xié)議下僅需0-RTT 即可與服務(wù)器建立安全會(huì)話， 而TCP/IP 協(xié)議下的TCP+TLS 則需要1-3 RTT (s) 才能夠建立連接，其主要的改進(jìn)是在QUIC 協(xié)議下，客戶端獲取到會(huì)話server config 以后，便能計(jì)算出密鑰，且不再重新建立新會(huì)話，直接發(fā)送應(yīng)用數(shù)據(jù)，此機(jī)制稱為0-RTT。

QUIC 協(xié)議通過合并Transport Layer Security減少了建立安全連接所需的往返次數(shù)。 當(dāng)客戶端第一次訪問服務(wù)器時(shí)， 它需要1 個(gè)RTT 來交換加密信息。 如果當(dāng)前客戶機(jī)已訪問服務(wù)器，則不再需要RTT。 在QUIC 協(xié)議中，客戶機(jī)和服務(wù)器之間的連接時(shí)間最多是1 個(gè)RTT，是安全的，而TCP 協(xié)議需要 2 個(gè) RTT 和另外 1 個(gè) RTT 通過 TLS 加密數(shù)據(jù)。

QUIC 的連接采用加密和傳輸握手相結(jié)合的方式來減少確認(rèn)次數(shù)，適用于數(shù)據(jù)中心網(wǎng)絡(luò)，有利于降低時(shí)延。

2.2 靈活的擁塞控制機(jī)制

QUIC 的擁塞控制是在傳統(tǒng)TCP NewReno 基礎(chǔ)上發(fā)展而來的，即基于擁塞窗口的擁塞控制，其核心原理基本一樣，但QUIC 可以靈活地使用擁塞控制多種算法， 一次選擇一個(gè)或幾個(gè)擁塞控制算法同時(shí)工作，但QUIC 在應(yīng)用程序不需要停機(jī)和升級(jí)，TCP 需要在服務(wù)端進(jìn)行修改， 而QUIC 現(xiàn)在只需要簡單的重新加載就能實(shí)現(xiàn)不同擁塞控制切換。

2.3 前向糾錯(cuò)

QUIC 傳輸過程中應(yīng)用了與TCP 差別很大的糾錯(cuò)機(jī)制， 其隨時(shí)用 Forward Error Correction packet 來代替某些新的packet，由于Forward Error Correction packet 中有奇偶核驗(yàn)機(jī)制， 能及時(shí)判斷出是否丟失， 并恢復(fù)packet 內(nèi)容段， 整個(gè)效率極高，且可根據(jù)傳輸請(qǐng)求的某一階段進(jìn)一步優(yōu)化，以實(shí)現(xiàn)前向糾錯(cuò)目的。

在QUIC 協(xié)議中， 用于確認(rèn)數(shù)據(jù)的ACK 包增強(qiáng)了新的功能， 支持從接收包到返回ACK 的延遲值， 增加值的目的是更加精確地計(jì)算基于分?jǐn)?shù)的RTT。 所以說在處理數(shù)據(jù)上， 較先前的TCP/IP 協(xié)議，可以綜合RTT 與CWND 來調(diào)節(jié)適合實(shí)時(shí)的擁塞算法，更加的靈活。 在數(shù)據(jù)中心網(wǎng)絡(luò)中，當(dāng)流量過大時(shí)，傳統(tǒng)的匯聚交換機(jī)對(duì)負(fù)載均衡能力較弱，且實(shí)時(shí)性較差， 再者TCP/IP 協(xié)議不能較好地適時(shí)調(diào)節(jié)整個(gè)網(wǎng)絡(luò)的擁塞情況，而QUIC 的靈活處理機(jī)制具有較好的應(yīng)用前景。

3 基于QUIC-UDP 傳輸?shù)膄at-tree超大型數(shù)據(jù)中心網(wǎng)絡(luò)性能測試

數(shù)據(jù)中心是大型網(wǎng)絡(luò)系統(tǒng)的核心， 既是眾多服務(wù)器的集中地，又是信息數(shù)據(jù)的總匯。 按文獻(xiàn)[14]設(shè)計(jì)了基于fat-tree 的超大型數(shù)據(jù)中心網(wǎng)絡(luò)。 本文的超大型數(shù)據(jù)中心網(wǎng)絡(luò)是指Pod 個(gè)數(shù)k＞30 的fattree 數(shù)據(jù)中心網(wǎng)絡(luò)。 網(wǎng)絡(luò)拓?fù)渑c圖 1 類似，f1 作為服務(wù)器，應(yīng)用TCP 協(xié)議與QUIC-UDP 協(xié)議，而其他主機(jī)fn 作為應(yīng)用服務(wù)器，主要研究其傳輸性能。

網(wǎng)絡(luò)中的所有鏈路均設(shè)為全雙工鏈路， 設(shè)置鏈路帶寬等， 并使用iperf 工具產(chǎn)生模擬的數(shù)據(jù)中心流量。傳輸吞吐量的計(jì)算流程為：首先主機(jī)f1 作為服務(wù)器，客戶端主機(jī)數(shù)據(jù)傳輸前，記錄開始時(shí)間t1；然后客戶端主機(jī)fn 向服務(wù)器主機(jī)f1 發(fā)request請(qǐng)求， 服務(wù)器主機(jī)f1 收到請(qǐng)求時(shí)做出response 回應(yīng)，并傳輸網(wǎng)頁；客戶端主機(jī)fn 收到網(wǎng)頁后，判斷是否完整，若完整無誤，記錄結(jié)束時(shí)間t2；最后計(jì)算本次傳輸吞吐量，其值為傳輸網(wǎng)頁大小/(t2-t1)。

網(wǎng)絡(luò)傳輸中最常見的應(yīng)用是Web 網(wǎng)頁的瀏覽，即在兩主機(jī)中通過瀏覽器渲染包括html、各種腳本、控制樣式等文件。 為了進(jìn)一步研究QUIC 和TCP 兩種協(xié)議的傳輸特點(diǎn)，實(shí)現(xiàn)在數(shù)據(jù)中心網(wǎng)絡(luò)中的不同網(wǎng)絡(luò)條件下加載相同網(wǎng)頁進(jìn)行性能測試，分別設(shè)計(jì)了3 種基于fat-tree 拓?fù)浣Y(jié)構(gòu)的數(shù)據(jù)中心網(wǎng)絡(luò)，如表1 所示。

表1 3 種不同類型的fat-tree 數(shù)據(jù)中心網(wǎng)絡(luò)

網(wǎng)絡(luò)傳輸性能測試所使用的服務(wù)器和客戶端均采用64 位Linux 內(nèi)核， 操作系統(tǒng)為xfce 4.10。QUIC 協(xié)議的QUIC-go 的較新版本是0.15.4。HTTP服務(wù)器是Nginx 1.14。 TCP 初始窗口大小默認(rèn)設(shè)置為1024。測試網(wǎng)頁是HTML 語言編寫的，包括大量文本、5 幅圖像和 JavaScript 腳本， 總大小為15.6MB。網(wǎng)絡(luò)拓?fù)涔ぞ呤褂胢ininet，該軟件是一個(gè)通過虛擬終端節(jié)點(diǎn)、 交換機(jī)和路由器連接起來的網(wǎng)絡(luò)模擬器，可以方便地創(chuàng)建一個(gè)數(shù)據(jù)中心網(wǎng)絡(luò)，其采用虛擬化技術(shù)，使系統(tǒng)與實(shí)際網(wǎng)絡(luò)基本一致。TCP 服務(wù)器使用Nginx 服務(wù)器， 是一種高性能的Web 服務(wù)器，具有低功耗、穩(wěn)定性好、并發(fā)性強(qiáng)以及易于配置等優(yōu)點(diǎn)。

本次測試使用TC 和 Netem、mahimahi 工具模擬不同的網(wǎng)絡(luò)環(huán)境， 該工具支持TCP 和QUIC 協(xié)議， 可以記錄整個(gè)Web 傳輸過程， 包括記錄Web內(nèi)容的 recordshell、 回放存儲(chǔ) Web 內(nèi)容的 replayshell、模擬延遲帶寬鏈路的delayshell，用于模擬指定數(shù)據(jù)傳輸?shù)乃俣葞掓溌返膌inkshell，以及用于模擬指定丟包率鏈路的lossshell。

LinkShell 的原理是使用數(shù)據(jù)包傳遞跟蹤文件來模擬鏈接。uplink 鏈路跟蹤文件模擬從LinkShell容器到Internet 的鏈接，downlink 鏈路跟蹤文件模擬從 Internet 到LinkShell 容器的鏈接。 LinkShell可以模擬時(shí)變鏈路（如蜂窩鏈路）和具有固定鏈路速度的鏈路。 當(dāng)數(shù)據(jù)包到達(dá)鏈路時(shí)（從Internet 或LinkShell）， 它將根據(jù)其預(yù)期的方向直接放入兩個(gè)數(shù)據(jù)包隊(duì)列中的一個(gè)：uplink 隊(duì)列或downlink 隊(duì)列。 LinkShell 根據(jù)相應(yīng)的輸入數(shù)據(jù)包傳遞跟蹤從每個(gè)隊(duì)列釋放數(shù)據(jù)包。 跟蹤文件中的每一行表示一個(gè)數(shù)據(jù)包傳遞機(jī)會(huì)：在仿真中可以傳遞MTU 大小的數(shù)據(jù)包的時(shí)間。 整個(gè)記錄過程是在字節(jié)級(jí)別完成的。因此，跟蹤wget 請(qǐng)求中的一行可以傳遞幾個(gè)較小的數(shù)據(jù)包，這些數(shù)據(jù)包的大小總和為1 500字節(jié)。 如果在傳輸過程中出現(xiàn)的瞬間字節(jié)不可用，則會(huì)再次傳輸一次。 LinkShell 可以嵌套在DelayShell 中， 以靈活地創(chuàng)建具有用戶提供的單向延遲和用戶提供的鏈接速率的鏈接。

整個(gè)測試實(shí)驗(yàn)中網(wǎng)絡(luò)傳輸和網(wǎng)絡(luò)信息的具體設(shè)置見表2。

表2 數(shù)據(jù)中心網(wǎng)絡(luò)參數(shù)設(shè)置

實(shí)驗(yàn)中，將QUIC 部署在基于fat-tree 的超大型數(shù)據(jù)中心網(wǎng)絡(luò)中，TCP 和QUIC 服務(wù)器部署在主機(jī)f1 中，fn 是客戶端。 利用 wget 傳輸工具，得到 TCP和QUIC 的網(wǎng)頁傳輸時(shí)間， 并計(jì)算出對(duì)應(yīng)的PLT（Page Loading Time）。 為了評(píng)價(jià) TCP 與 QUIC 兩種不同協(xié)議的傳輸性能， 選擇相同單位時(shí)間內(nèi)網(wǎng)頁加載時(shí)間作為評(píng)價(jià)標(biāo)準(zhǔn)。 為了消除不穩(wěn)定因素，每次試驗(yàn)重復(fù)60 次。

基于 fat-tree 的 k=2 數(shù)據(jù)中心網(wǎng) h1 和 h8 在不同核心交換機(jī)和相同聚合交換機(jī)下的網(wǎng)絡(luò)性能分析，如圖3 所示。

圖3 基于fat-tree 數(shù)據(jù)中心網(wǎng)絡(luò)的TCP/QUIC 傳輸性能測試比較

為了進(jìn)一步研究移動(dòng)網(wǎng)絡(luò)環(huán)境下兩種協(xié)議的傳輸性能方面的差異， 實(shí)驗(yàn)?zāi)M不同upLink 與downLink 下帶寬為20Mbps 的網(wǎng)絡(luò)環(huán)境。模擬移動(dòng)網(wǎng)絡(luò)命令如下：mm-delay 20 mm-link--meter-all

/usr/share/mahimahi/traces/Verizon-LTE-short.up

/usr/share/mahimahi/traces/Verizon-LTE-short.down

其傳輸結(jié)果見圖4。

圖4 基于fat-tree 數(shù)據(jù)中心網(wǎng)絡(luò)的TCP/QUIC 移動(dòng)傳輸性能測試比較

從圖3 可以看出， 隨著帶寬和丟包率的增加，TCP 和QUIC 的傳輸性能均有所下降，但TCP 的傳輸性能下降幅度會(huì)更大些。 在5Mbps 帶寬下，TCP的吞吐量剛開始很高，但隨著丟包率增加到1%左右，QUIC 的吞吐量超過了 TCP。 在 20Mbps 帶寬下，隨著丟包率的增加，QUIC 除了時(shí)延5ms 外，其吞吐量始終超過 TCP。 首先，QUIC 在 100Mbps 帶寬下的吞吐量較高， 而在100Mbps 帶寬下延時(shí)2ms 時(shí)，QUIC 的吞吐量基本相同， 在 5ms 及 10ms延時(shí)時(shí)，其輸出吞吐量接近于0。

從圖4 可知， 在移動(dòng)網(wǎng)絡(luò)環(huán)境中低丟包率情形下，QUIC 傳輸性能明顯優(yōu)于TCP。 隨著丟包率增加，QUIC 由于其前向糾錯(cuò)等功能， 所以一直優(yōu)于TCP。

4 結(jié)論

通過構(gòu)建基于超大型數(shù)據(jù)中心網(wǎng)絡(luò)中的fattree 拓?fù)洵h(huán)境，對(duì)TCP 和QUIC 的網(wǎng)絡(luò)傳輸性能進(jìn)行研究，并在不同的網(wǎng)絡(luò)環(huán)境中進(jìn)行測試，比較基于TCP 和QUIC 的數(shù)據(jù)中心網(wǎng)絡(luò)傳輸性能的差異，發(fā)現(xiàn)隨著丟包率的增加，兩種協(xié)議的傳輸性能（指吞吐量）均有所下降，但TCP 的下降幅度要大得多，QUIC 在高丟包率網(wǎng)絡(luò)環(huán)境下傳輸性能要明顯優(yōu)于TCP。 在移動(dòng)網(wǎng)絡(luò)環(huán)境下，QUIC 傳輸性能一直優(yōu)于傳統(tǒng)的TCP 協(xié)議， 隨著數(shù)據(jù)中心網(wǎng)絡(luò)規(guī)模的增大，TCP 和QUIC 的網(wǎng)絡(luò)傳輸能力趨于穩(wěn)定。 在今后的研究中，將進(jìn)一步擴(kuò)大數(shù)據(jù)中心網(wǎng)絡(luò)規(guī)模，比較高負(fù)載、高丟包率等網(wǎng)絡(luò)環(huán)境中二者的性能差異。