你知道嗎？當(dāng)你部署IaaS云計算平臺時，就已經(jīng)在應(yīng)用SDN了。你知道嗎？云計算平臺可以在vSwitch和physical Switch之間無縫切換。你知道嗎？當(dāng)前的云計算平臺的網(wǎng)絡(luò)部分有很大的優(yōu)化空間。本文就帶你了解這一切。

　　一、沒有SDN，就沒有云計算網(wǎng)絡(luò)

　　SDN起源于校園網(wǎng)絡(luò)，發(fā)揚(yáng)光大于數(shù)據(jù)中心。但現(xiàn)在看來很多人對后一句話并沒有真正理解，如果你不服氣，你能回答我這個問題嗎：為什么說SDN很適合數(shù)據(jù)中心？我相信很多人對此都不甚了解。我這么說有一個依據(jù)，因為工作的關(guān)系，我跟國內(nèi)不少做云平臺的技術(shù)和管理人員聊過，包括提供公有云、私有云服務(wù)的公司以及企業(yè)內(nèi)部私有云網(wǎng)絡(luò)的研發(fā)和運(yùn)維部門 的員工，有很多人跟我說過這樣一句話：我們目前還沒有開始使用SDN，但正在研究，也許以后會考慮吧。這句話暴露了當(dāng)前很多從事云計算網(wǎng)絡(luò)研發(fā)和運(yùn)維的技術(shù)人員，對SDN在云計算網(wǎng)絡(luò)中的應(yīng)用并不清楚。

　　實際上，當(dāng)你的數(shù)據(jù)中心在部署云計算平臺（如OpenStack）時，就已在應(yīng)用SDN了。先來看看OpenStack的網(wǎng)絡(luò)組件Neutron的整體架構(gòu)（如圖1所示）。

　　這個架構(gòu)，邏輯上可以分為三個部分。最上面的一部分是OpenStack的控制平臺，它通過用戶操作直接或者間接向網(wǎng)絡(luò)組件Neutron發(fā)送標(biāo)準(zhǔn)的命令。 第二層是Neutron組件，它通常是位于一個獨(dú)立的控制節(jié)點上（一臺服務(wù)器），它有一套標(biāo)準(zhǔn)的API對應(yīng)上層應(yīng)用發(fā)給它的每個命令，這些API包括 create_network、create_port、create_subnet等創(chuàng)建多租戶網(wǎng)絡(luò)以及創(chuàng)建Firewall、Load Balancer等各種業(yè)務(wù)的API。這套API從SDN的架構(gòu)來看屬于北向接口。在Neutron組件內(nèi)部有很多個不同的插件（plugin），這些插 件大多數(shù)都是vSwitch插件，例如OVS、Linux Bridge和OpenFlow Controller等，也有部分硬件交換機(jī)插件，目前已經(jīng)存在的包括Cisco、Arista和Mellanox，相信后面還會有公司會提交。用戶可以 選擇自己的網(wǎng)絡(luò)使用哪種方式，然后選擇相應(yīng)的插件，這些插件會處理Neutron API調(diào)用，將它們轉(zhuǎn)換為每種插件對應(yīng)的switch所提供的API調(diào)用，然后通過各自定義的方式，發(fā)消息去調(diào)用虛擬交換機(jī)或者物理交換機(jī)提供的API， 這套API從SDN的架構(gòu)來看屬于南向接口。

　　我們再回過頭來看看SDN的定義。SDN有很多屬性，每個人理解都不同，正是因為如此，所以很 多人對于某一項技術(shù)是否是SDN看法不同。實際上，有很多屬性是偽屬性，它們并不影響對某項技術(shù)是否是SDN的判斷，比如是否用了OpenFlow，是否 有標(biāo)準(zhǔn)化的編程接口，是否使用了物理交換機(jī)，都跟是否是SDN無關(guān)。在我看來，SDN有三個核心屬性可以用來判斷一個技術(shù)是否是SDN，這三個屬性包括控 制與轉(zhuǎn)發(fā)分離、開放的編程接口、集中化的網(wǎng)絡(luò)控制（關(guān)于這點會有歧義，這里集中化網(wǎng)絡(luò)控制，并不意味著Controller必須是集中式架構(gòu)，也可以是分 布式的，只是說，所有參與控制的Controller，在被控制的交換機(jī)看來，邏輯上只有一個）。

　　然后我們再來看一下 OpenStack（別的云平臺也一樣）是否符合這三個要求。

　　第一，OpenStack架構(gòu)中，控制面都是在OpenStack邏輯中（圖1中的第一層和 第二層），而轉(zhuǎn)發(fā)面則在虛擬交換機(jī)或者物理交換機(jī)中，絕對的控制與轉(zhuǎn)發(fā)分離。

　　第二，無論是南向還是北向，都有開放的編程接口。

　　第三，集中化的 OpenStack控制平臺控制著網(wǎng)絡(luò)中多臺服務(wù)器和交換機(jī)。所以無論從哪個方面看，OpenStack都是標(biāo)準(zhǔn)的SDN架構(gòu)，OpenStack就是一 個超級Controller。

　　可以說如果沒有SDN的理念，就沒有OpenStack，你能想象交換機(jī)（物理或者虛擬）如果不提供編程接口 出來，OpenStack怎樣靈活控制網(wǎng)絡(luò)嗎？特別是網(wǎng)絡(luò)虛擬化的引入更是離不開SDN的協(xié)助（但網(wǎng)絡(luò)虛擬化不等于SDN，不要搞混了）。而SDN確實為 包括OpenStack在內(nèi)的云平臺提供了無可替代的便利，讓云平臺的自動化操作成為可能。所以現(xiàn)在可以回答最開始的問題了：為什么說SDN非常適合用在 數(shù)據(jù)中心？其實更準(zhǔn)確地說，是適合部署了云計算網(wǎng)絡(luò)的數(shù)據(jù)中心，因為云計算網(wǎng)絡(luò)要協(xié)調(diào)的資源非常多，引入一個業(yè)務(wù)要執(zhí)行的操作非常復(fù)雜，靠手工去操作，一 方面容易出錯，另一方面耗時太長，所以需要借助工具進(jìn)行自動化部署，而使用了SDN的云管理平臺使得這一切成為了可能。以后如果再有人問你SDN到底有什 么用，有什么是SDN能做而傳統(tǒng)網(wǎng)絡(luò)設(shè)備做不了的，給他講講這個例子。

　　但為什么還是有很多做云計算平臺的人不認(rèn)為自己使用了SDN呢？我歸 納了一下，大致有三種原因。

　　第一種，這些人不了解OpenStack Neutron的架構(gòu)和工作原理，自然就不清楚。就像我在沒有深入研究Neutron之前，也不清楚這一點。

　　第二種，很多人潛意識里面覺得沒有用到 OpenFlow，就不能算用了SDN。前面提到，用不用OpenFlow并非是否是SDN的判斷依據(jù)，因為OpenFlow只是SDN的其中一種實現(xiàn)方 式。

　　第三種，有人潛意識里面覺得我都用的是OVS，沒有涉及到物理交換機(jī)，就覺得不能算是SDN，或者是覺得沒有全網(wǎng)都用SDN，只是在網(wǎng)絡(luò)邊緣用到了， 不能算是部署SDN了。這一切都是誤解，歸根結(jié)底還是屬于對SDN的本質(zhì)或者OpenStack架構(gòu)看得不透徹。

　　對于云計算網(wǎng)絡(luò)的用戶來 說，他們看不到SDN，但這并不代表他們沒有享受到SDN帶給他們的好處?，F(xiàn)在大多數(shù)公有云平臺的用戶都是自助服務(wù)的，他們自己創(chuàng)建虛機(jī)，自己創(chuàng)建虛擬網(wǎng) 絡(luò)，自己創(chuàng)建虛擬路由器，自己創(chuàng)建防火墻等，誰在底層支撐著這些動作的順利執(zhí)行呢？是SDN架構(gòu)！沒有SDN，就沒有這一切！SDN的最高境界就是用戶在 享受著SDN帶來的便利卻并沒有意識到自己使用了SDN。

　　二、用物理交換機(jī)取代虛擬交換機(jī)？

　　云計算網(wǎng)絡(luò)目前還處于發(fā)展的初級階段，為了支持多租戶網(wǎng)絡(luò)和支持VM的可移動性，網(wǎng)絡(luò)虛擬化被廣泛使用，包括基于VLan的、基于VxLan和基于GRE的。

　　目 前絕大多數(shù)網(wǎng)絡(luò)都使用虛擬交換機(jī)（vSwitch）作為網(wǎng)絡(luò)的邊緣，最著名的就是Nicira公司發(fā)起的開源虛擬交換機(jī)項目OVS。之所以vSwitch 被大量用作網(wǎng)絡(luò)虛擬化的邊緣，跟VMware等軟件公司的大力推動密不可分，這涉及到他們的利益，也涉及到網(wǎng)絡(luò)的控制權(quán)之爭：究竟是數(shù)據(jù)中心的系統(tǒng)運(yùn)維團(tuán) 隊控制虛擬網(wǎng)絡(luò)還是網(wǎng)絡(luò)運(yùn)維團(tuán)隊控制虛擬網(wǎng)絡(luò)？以Cisco為代表的傳統(tǒng)硬件廠商極力反對VMware的這種做法，理由包括網(wǎng)絡(luò)可視化（Network Visibility）以及性能都是大問題，特別是性能問題。

　　但反對歸反對，很多云計算網(wǎng)絡(luò)的管理員有了先入為主的思維模式，如果有人讓他 們切換到使用物理交換機(jī)，他們會普遍提出一堆問題，包括以下幾個很典型的：會不會被鎖定到特定的廠商身上？物理交換機(jī)能有虛擬交換機(jī)那么靈活滿足各種需求 嗎？我能像控制虛擬交換機(jī)那樣方便地控制物理交換機(jī)嗎？會不會增加網(wǎng)絡(luò)成本？

　　盡管如此，很多人確實也都同意，使用虛擬交換機(jī)，例如OVS，確實有很多性能問題，這是使用物理交換機(jī)的方案最吸引人的地方，順帶著還有可擴(kuò)展性（云管理平臺要控制的虛擬網(wǎng)絡(luò)節(jié)點太多）。所以現(xiàn)在問題就變成了：我知道使用物理交換機(jī)有這樣的好處，但你怎樣解決上述顧慮？

　　其實OpenStack的Neutron plugin機(jī)制特別是最新版（Havana）引入的ML2 plugin已經(jīng)給出了答案。前面講過，Neutron向上提供了一套標(biāo)準(zhǔn)的編程接口，這套接口獨(dú)立于任何虛擬或者物理的交換機(jī)。對管理員來說，根本不需 要關(guān)心底下用的是誰的交換機(jī)，虛擬的還是物理的。對于數(shù)據(jù)中心系統(tǒng)研發(fā)部門的工程師來說，他們可以通過plugin機(jī)制引入多種交換機(jī)，虛擬的或者物理 的，前提是這些交換機(jī)必須能支持Neutron向上提供出那些API來，如果無法支持，自然就不會出現(xiàn)在我的采購列表里面，而支持了之后，如果以后因為某 些原因想換掉了，也很簡單，只要換用另外一個交換機(jī)的plugin就可以了。這樣第一個廠商鎖定問題就沒有了。特別是Havana版本引入的ML2 plugin機(jī)制，允許一個OpenStack域內(nèi)同時支持多種交換機(jī)的plugin。這樣只要管理員愿意，甚至都可以有的節(jié)點使用虛擬交換機(jī)，有的節(jié)點 使用物理交換機(jī)，而且可以是不同廠家的，唯一的前提就是這些交換機(jī)必須支持通用的Neutron API，這是北向接口標(biāo)準(zhǔn)化的好處。

　　第二個問題，物理交換機(jī)能有虛擬交換機(jī)那么靈活滿足各種需求嗎？其實對于特定的場景，這是個很隱蔽的偽命題。一提到靈活性，誰都想要，而且最好是無限靈活。但 如果有人問管理員，我可以滿足你的場景中所有的實際需求，但無法提供任意不受約束的靈活性，你要任意靈活的話，需要付出代價，你要不要？我相信絕大多數(shù)理 性的管理員都不會要求任意靈活，因為超過需求之外的靈活，是無意義的，而你要為這些無意義的事情付出代價。另外，在有了SDN的機(jī)制，交換機(jī)可以向上提供 編程接口而不是命令行之后，特別是有了OpenFlow之后，一些交換機(jī)特別是為SDN優(yōu)化過的交換機(jī)已可以滿足絕大多數(shù)甚至全部云計算網(wǎng)絡(luò)的需求了。退 一步說，不能滿足需求的交換機(jī)，根據(jù)上面第一點，不會進(jìn)入采購列表。

　　第三個問題，我能像控制虛擬交換機(jī)那樣方便地控制物理交換機(jī)嗎？在 SDN控制與轉(zhuǎn)發(fā)分離的架構(gòu)下，管理員通過云平臺控制的永遠(yuǎn)都是直接的北向接口，那是與設(shè)備無關(guān)的。設(shè)備的差異性都被底層的實現(xiàn)給屏蔽掉了，如前所述，只 要底層設(shè)備能夠提供足夠的南向接口，通過換不同的plugin，OpenStack就可以控制不同的交換機(jī)，包括物理交換機(jī)。

　　第四個問題， 會不會增加我的網(wǎng)絡(luò)成本？無論哪種方案，TOR交換機(jī)總是需要的?，F(xiàn)在并不需要增加新的交換機(jī)設(shè)備，而只是要讓原來的TOR交換機(jī)支持SDN方式或者換用 能支持SDN的交換機(jī)充當(dāng)TOR。當(dāng)然，客戶都有保護(hù)已有投資的需要，往往不想把現(xiàn)有設(shè)備替換掉，這也沒關(guān)系，前面講過，OpenStack Neutron ML2的架構(gòu)允許網(wǎng)絡(luò)中有的網(wǎng)絡(luò)節(jié)點是虛擬交換機(jī)，有的是物理交換機(jī)，所以想保護(hù)已有投資就變得很簡單了，只需要在新增節(jié)點上用云平臺來控制SDN物理交 換機(jī)就行了，原有的節(jié)點仍然是控制虛擬交換機(jī)，這樣就可以讓整個網(wǎng)絡(luò)平滑引入物理交換機(jī)作為云平臺控制的網(wǎng)絡(luò)節(jié)點。

　　三、虛擬交換機(jī)的性能需要優(yōu)化嗎？

　　前面講這么多，其實主要是想要說明，如果云計算網(wǎng)絡(luò)管理員想要從虛擬交換機(jī)切換到物理交換機(jī)的話，是很容易做到的，不會有什么損失。但接下來網(wǎng)絡(luò)管理員馬上就會問：為什么要切換？有什么好處？答案有多個，主要的兩點是網(wǎng)絡(luò)可視化和網(wǎng)絡(luò)性能。

　　網(wǎng)絡(luò)可視化的問題相對好分析，容易理解。因為如果在Hypervisor上做了Tunnel封裝，報文送到TOR交換機(jī)上時，交換機(jī)已經(jīng)看不到用戶原始報文了，物理網(wǎng)絡(luò)就很難對原始報文做統(tǒng)計和應(yīng)用各種策略。而如果Tunnel封裝在TOR上面做，則沒有這個問題。

　　而對于性能問題大家的看法可能各異，大體可分為三類：

　　第一類是覺得沒有什么性能問題；

　　第二類是覺得有，但還可以忍受；

　　第三類是覺得已到了影響業(yè)務(wù)、無法忍受 的地步了。

　　我相信他們講的都是他們所看到的事實，為什么結(jié)果迥異？我分析過，基本上前面兩類，要么是仍然處于試驗階段，還沒有大業(yè)務(wù)的壓力，要么是已正式 部署，但網(wǎng)絡(luò)規(guī)模不大或者網(wǎng)絡(luò)內(nèi)的業(yè)務(wù)流量壓力不大，當(dāng)然我也不排除有的人技術(shù)能力特別牛，把性能優(yōu)化到了極致。而第三類，則是已經(jīng)有很大業(yè)務(wù)量部署在生 產(chǎn)網(wǎng)絡(luò)中了，或者是用充分的測試手段模擬過實際的業(yè)務(wù)。第三類的典型例子就是國內(nèi)的云服務(wù)提供商UCloud，他們有大量實際用戶（很多是游戲客戶）租用 了他們的公有云網(wǎng)絡(luò)，業(yè)務(wù)量很大。和AWS等云計算平臺一樣，網(wǎng)絡(luò)處理會占用計算資源，帶寬損耗也很大。

　　另外一個云服務(wù)提供商 99Cloud也曾經(jīng)做過這樣的實驗：先是用iPerf進(jìn)行大流量測試，使用vSwitch帶寬大概能到800多MB，后來在iPerf發(fā)包的同時，用迅 雷下載模擬實際網(wǎng)絡(luò)流量，帶寬馬上降到了500多MB，有高達(dá)300MB的帶寬被損耗掉了。所以結(jié)論就是，虛擬交換機(jī)肯定有性能問題，需要優(yōu)化。就算是對 于那種技術(shù)特別牛，能將軟件優(yōu)化做到極致的人，他也無法否認(rèn)，你再怎么優(yōu)化，網(wǎng)絡(luò)處理也要占用計算資源，而按道理網(wǎng)絡(luò)只是工具，計算才是核心價值。

　　前面是定量測試，下面我們來進(jìn)行一些理論分析?，F(xiàn)在服務(wù)器的性能這么強(qiáng)勁，還有網(wǎng)卡加速，為什么虛擬交換機(jī)還有性能問題？我分析主要有以下幾個原因。

　　vSwitch做Tunnel加封裝和解封裝時，報文在內(nèi)存中的移動和拷貝會影響性能。

　　網(wǎng)卡中的TSO是可以對TCP報文進(jìn)行分片加速的，但一旦vSwitch給報文加了VxLan或者GRE Tunnel，網(wǎng)卡一看不是TCP報文，就不會進(jìn)行分片加速了。這對性能損耗也比較大。

　　軟件中的流表查找消耗比較大，特別是在流表數(shù)量比較大，TCP短連接比較多的時候。

　　圖2是使用虛擬交換機(jī)OVS的OpenStack網(wǎng)絡(luò)架構(gòu)。

　　四、云計算網(wǎng)絡(luò)性能優(yōu)化方案

　　針對上述產(chǎn)生性能問題的原因，可以從以下幾個方面來對云計算網(wǎng)絡(luò)進(jìn)行優(yōu)化。將Tunnel加封裝、解封裝的功能Offload到支持SDN的TOR交換機(jī)上，這樣一方面去掉了服務(wù)器上加解封裝的開銷，另外更重要的是網(wǎng)卡仍然可以通過TSO做TCP報文分片加速。

　　所有的流表都是預(yù)先加而非動態(tài)報文學(xué)習(xí)，減少Flow學(xué)習(xí)帶來的沖擊。同時通過合理地設(shè)置默認(rèn)流表項（Default Entry）來有效減少流表項數(shù)量。有人對流表為什么可以預(yù)先加不理解，其實很簡單，云計算平臺掌握了所有的信息，包括一個租戶有多少個VM，每個VM都 掛在哪個交換機(jī)的哪個端口下面，每個VM的MAC和IP各是多少，默認(rèn)網(wǎng)關(guān)是什么，同一個租戶之間VM的通信使用哪個Tunnel，需要對某個VM應(yīng)用何 種策略等等。有了這些信息，就足以構(gòu)建起轉(zhuǎn)發(fā)面所需要的流表，既然能預(yù)先配置，為什么需要動態(tài)學(xué)習(xí)？為什么需要Flood呢？

　　將流表項查找也Offload到TOR SDN交換機(jī)，使用Linux Bridge做內(nèi)部VM交換或者為了安全可控，讓報文無論如何先送到TOR交換機(jī)，交換機(jī)處理后再送回去。這樣延時會稍微大一點點兒。這一步根據(jù)用戶情況 可選，也可以只做前面兩步，流表查找仍然使用服務(wù)器內(nèi)部的OVS。

　　更進(jìn)一步，將基本的無狀態(tài)Firewall、基于L2-L4的Load Balancer等（當(dāng)然，如果是有狀態(tài)的Firewall或者四層之上的Firewall/Load Balancer，交換機(jī)就搞不定了）也都在TOR交換機(jī)上面實現(xiàn)，把OpenStack中獨(dú)立的網(wǎng)絡(luò)節(jié)點服務(wù)器完全省掉了。當(dāng)然這一步對交換機(jī)的要求比 較高，不是都能做到。如果做不到?jīng)]關(guān)系，仍然放到服務(wù)器內(nèi)部做。但這一步如果做了，對性能提升也會很明顯。

　　L3 Gateway是所有云計算平臺所共同面臨的瓶頸，比如OpenStack，有專門的網(wǎng)絡(luò)節(jié)點（Server）來充當(dāng)L3 Gateway，用于支持租戶的虛擬Router，由于所有需要路由的報文都要經(jīng)過這些虛擬Router來轉(zhuǎn)發(fā)，充當(dāng)L3 Gateway的Server就成了瓶頸。有的硬件SDN交換機(jī)可以支持這種情況下的L3 Gateway，而且可以做成全分布式的，這樣就不再存在性能瓶頸。

　　通過在TOR上啟用ARP代理，幫助答復(fù)ARP請求，這樣就可以避免ARP廣播。

　　當(dāng)然這只是理論分析，還需要實踐檢驗，目前這方面的實踐很少。盛科網(wǎng)絡(luò)在這方面做了嘗試，用自己的SDN交換機(jī)V350為多家云服務(wù)提供商（如 UCloud、99Cloud等）提供了基于硬件交換機(jī)的云計算網(wǎng)絡(luò)解決方案，實現(xiàn)了上述優(yōu)化措施，并將提交自己的plugin到OpenStack。 UCloud與盛科共同推出了云計算網(wǎng)絡(luò)解決方案（如圖3所示）。

　　當(dāng)然并非所有云平臺都是基于OpenStack的，那是否別的云平臺也可以使用硬件交換機(jī)代替vSwitch呢？答案是肯定的，其實UCloud的云平臺就 并非OpenStack。另外，對于網(wǎng)絡(luò)虛擬化，有人是用VLan做的，有人用Tunnel overlay技術(shù)，這并不影響使用vSwitch還是物理交換機(jī)。

　　當(dāng)然，即便是這樣，仍然會有人說，雖然虛擬交換機(jī)確實會導(dǎo)致CPU利用 率有點高，但高點就高點，也沒什么；雖然虛擬交換機(jī)會導(dǎo)致更多的帶寬損耗，但損耗點也沒關(guān)系，反正我的網(wǎng)絡(luò)也不需要那么高帶寬，所以我真沒必要使用硬件 SDN方案。這話聽起來也有道理，但換個角度想想，公有云的基礎(chǔ)架構(gòu)成本非常高昂，公有云服務(wù)商要想賺錢，必須要在保證用戶體驗的前提下降低成本。怎么降 低？如果能夠在一個Server內(nèi)放更多的虛機(jī)，自然就可以降低成本，所以如果能把網(wǎng)絡(luò)處理的消耗轉(zhuǎn)移到物理交換機(jī)，讓網(wǎng)絡(luò)設(shè)備去處理網(wǎng)絡(luò)功 能，Server專注于計算，那就可以省出更多資源來放置更多虛擬機(jī)。而所有這一切并不需要引入額外的設(shè)備，用得不爽了可以隨時切換回原有方案，讓SDN TOR交換機(jī)只執(zhí)行普通TOR功能，可以說基本沒有什么負(fù)面影響，何樂而不為呢？說到底，還是因為大家都被虛擬機(jī)廠商影響太深，有了先入為主的成見，特別 是在很多人對網(wǎng)絡(luò)不是很了解的前提下。

　　五、結(jié)語

　　當(dāng)前，很多從事 云計算的技術(shù)人員都是從企業(yè)內(nèi)部的運(yùn)維和系統(tǒng)研發(fā)人員直接轉(zhuǎn)過來的。在傳統(tǒng)網(wǎng)絡(luò)時代，網(wǎng)絡(luò)對他們來說只是個工具，會操作就行。但到了云計算時代，對云計算平臺的開發(fā)人員來說，就不僅僅是會用這么簡單了，而是提出了更高的要求，需要相關(guān)從業(yè)人員精通網(wǎng)絡(luò)原理，這樣才能讓云計算網(wǎng)絡(luò)的性能、可擴(kuò)展性、對業(yè)務(wù)的 支持都做到最優(yōu)，現(xiàn)在流行的DevOps概念就體現(xiàn)了這種要求。

　　因此，對這些人來說，深入了解網(wǎng)絡(luò)技術(shù)就變得必不可少。但無論如何，云計算讓網(wǎng)絡(luò)應(yīng)用變得精彩，讓應(yīng)用創(chuàng)新變得更容易；網(wǎng)絡(luò)是云計算的基石，沒有網(wǎng)絡(luò)就沒有云計算，那么，付出一點學(xué)習(xí)的代價又算得了什么呢？