OpenFlow會(huì)不會(huì)城頭變幻大王旗？

作者簡(jiǎn)介：儲(chǔ)子叡，互聯(lián)港灣軟件架構(gòu)師，資深網(wǎng)絡(luò)愛(ài)好者 曾供職于Juniper/Brocade/VMware，對(duì)網(wǎng)絡(luò)安全/操作系統(tǒng)內(nèi)核/包轉(zhuǎn)發(fā)/ASIC均有涉獵

“在革命的每個(gè)階段都有人退出，這一點(diǎn)也不奇怪，正如大多數(shù)創(chuàng)業(yè)公司都會(huì)死掉，因此任何時(shí)間退出從概率上來(lái)看往往都是正確的。”

我們的問(wèn)題在于，OpenFlow還行不行，如果不行了，是不是該選擇退出？是徹底退出，還是給OpenFlow找個(gè)接班人？這個(gè)問(wèn)題相信已經(jīng)在SDN界（如果真的有SDN界的話）持續(xù)了一段時(shí)間了。

讓人不禁有些氣餒的是，我們不得不進(jìn)行如下的思考，OpenFlow從當(dāng)紅炸子雞變成今天的過(guò)氣網(wǎng)紅，這期間到底發(fā)生了什么？先天不足還是后天發(fā)育不良？是時(shí)機(jī)未到還是參與者各自心懷鬼胎？

這些問(wèn)題里最幽默的是，很多振振有詞的質(zhì)疑者，他們其實(shí)根本連OpenFlow/OpenFlow-Controller 架構(gòu)是什么也搞不清楚，更別說(shuō)讀懂一條流表，抑或是看懂一行OVS的代碼。我雖然不是OpenFlow的鐵粉，也覺(jué)得有必要來(lái)個(gè)正本清源，談?wù)凮penFlow是什么，談?wù)勅绾巫叩竭@一步，再談?wù)剬?lái)的事情不遲。

首先，要談?wù)揙penFlow，先要說(shuō)控轉(zhuǎn)分離即控制平面（Control-plane）和轉(zhuǎn)發(fā)平面的（Forwarding-plane）的分離。轉(zhuǎn)發(fā)平面有時(shí)候也被叫做數(shù)據(jù)平面（Data-plane),其原因就是交換機(jī)/路由器/防火墻這些所謂的數(shù)通設(shè)備，其本質(zhì)特征就是轉(zhuǎn)發(fā),數(shù)據(jù)包從一個(gè)接口進(jìn)來(lái)，從另一個(gè)接口（可能是同一個(gè)接口）或者多個(gè)接口出去，如此而已。關(guān)鍵在于，進(jìn)來(lái)的數(shù)據(jù)包從哪個(gè)（或者哪些）端口出去，由誰(shuí)來(lái)決定？毫無(wú)疑問(wèn)是由控制平面決定?？刂破矫娓鶕?jù)從管理平面(Management-plane）來(lái)的命令/配置，加上通過(guò)路由/廣播等方法學(xué)來(lái)的網(wǎng)絡(luò)拓?fù)洌瑧?yīng)用到特定的數(shù)據(jù)包身上，從而得出相應(yīng)的轉(zhuǎn)發(fā)動(dòng)作，通常而言，是把數(shù)據(jù)包復(fù)制一份，修改相應(yīng)的報(bào)文字段，再?gòu)牧硗庖粋€(gè)接口送出去。

傳統(tǒng)設(shè)備上控制平面和轉(zhuǎn)發(fā)平面從來(lái)都是分離的。所謂控轉(zhuǎn)分離，是指把原先存在于每個(gè)設(shè)備的控制平面抽出來(lái)，集中放在一臺(tái)或者幾臺(tái)核心設(shè)備上，由這些設(shè)備計(jì)算出網(wǎng)絡(luò)拓?fù)浜兔總€(gè)具體流量需要經(jīng)過(guò)的轉(zhuǎn)發(fā)路徑，計(jì)算的依據(jù)，依然是來(lái)自控制平面的命令/配置，以及可以學(xué)習(xí)的拓?fù)?。?jì)算結(jié)果流表通過(guò)OpenFlow協(xié)議下發(fā)到每臺(tái)設(shè)備上，設(shè)備僅需要匹配這些下發(fā)的流表完成轉(zhuǎn)發(fā)動(dòng)作即可。因此，要理解OpenFlow，必須理解流表。

首先要搞懂流表，流表就是一張表！和一張普通的數(shù)據(jù)庫(kù)表并沒(méi)有什么不一樣，都是由一些字段（Field）定義的，可以把它們稱為列。而流表的具體內(nèi)容，可以稱為行。列是需要預(yù)先定義（Pre-defined）的，而行則是可以隨時(shí)（Run-time）被增刪改查（CRUD）的。

我們先忽略O(shè)penFlow復(fù)雜的版本關(guān)系，看看這張表抽象以后是個(gè)什么樣子。

首先，Header Fields是數(shù)據(jù)包的包頭。我們知道幾乎所有的數(shù)據(jù)包都是由包頭（header）和負(fù)載（payload）組成的。一個(gè)數(shù)據(jù)包可能有很多個(gè)包頭組成的，這實(shí)際上就是網(wǎng)絡(luò)分層（layer）的本質(zhì)，每一層都有自己的能夠提供的服務(wù)（service），而服務(wù)其實(shí)就是定義在包頭里的。下個(gè)層次的包頭對(duì)于上一個(gè)層次來(lái)說(shuō)，是負(fù)載的一部分。打個(gè)比方來(lái)說(shuō)TCP的包頭就是緊接在IP包頭的后面的，對(duì)于IP這個(gè)層次來(lái)說(shuō)，TCP的包頭就是負(fù)載。所以，從數(shù)據(jù)流的視角來(lái)看，數(shù)據(jù)包是由一系列的包頭依次組成的，不同的轉(zhuǎn)發(fā)層面的動(dòng)作，例如我們常說(shuō)的二層交換，三層路由，四層防火墻，其實(shí)就是對(duì)于數(shù)據(jù)包這個(gè)連續(xù)的數(shù)據(jù)流，你看多遠(yuǎn)（多少個(gè)包頭）而已。其實(shí)并沒(méi)有本質(zhì)區(qū)別。

因此，OpenFlow 的Header Fields是一系列需要匹配的包頭的組合。

OpenFlow的轉(zhuǎn)發(fā)動(dòng)作就是從以上連續(xù)的包頭的域（Field）里，找出需要匹配的那些，用來(lái)標(biāo)志出一個(gè)數(shù)據(jù)流（Flow），對(duì)于所有匹配這個(gè)流的數(shù)據(jù)包，均做相同的動(dòng)作（Action），并且更新計(jì)數(shù)器（Counter）。對(duì)于所有Flow都不能匹配的數(shù)據(jù)包，則需要用Packet-in的消息把這個(gè)數(shù)據(jù)包送到控制器去，由控制器來(lái)決定怎么辦，或者丟棄，或者為這個(gè)包創(chuàng)建一個(gè)新的數(shù)據(jù)流。

通過(guò)OpenFlow完成的轉(zhuǎn)發(fā)動(dòng)作，和原先傳統(tǒng)設(shè)備的轉(zhuǎn)發(fā)流程并沒(méi)有區(qū)別，換句話說(shuō)，如果傳統(tǒng)設(shè)備廠商愿意，完全可以在自己?jiǎn)闻_(tái)設(shè)備的控轉(zhuǎn)平面之間跑OpenFlow，因此，控轉(zhuǎn)分離的架構(gòu)不會(huì)給轉(zhuǎn)發(fā)設(shè)備帶來(lái)任何挑戰(zhàn)，那么OpenFlow帶來(lái)的真正挑戰(zhàn)是什么？

如下是一個(gè)具體的OpenFlow的表，看看其中有何奧妙。

我們知道數(shù)據(jù)庫(kù)的設(shè)計(jì)，查起來(lái)快不快，關(guān)鍵在于鍵（Key）和索引（Index），以上這個(gè)表的問(wèn)題是鍵在哪里？可能被用來(lái)做為匹配的字段高達(dá)十二個(gè)，而每一行都可能只有這十幾個(gè)字段中的幾個(gè)，沒(méi)有鍵和索引，沒(méi)辦法迅速查表！

為什么要查表？剛才只講了轉(zhuǎn)發(fā)動(dòng)作中控制平面和轉(zhuǎn)發(fā)平面的互動(dòng)，由控制平面來(lái)決定如何進(jìn)行轉(zhuǎn)發(fā)，但是顯然一個(gè)數(shù)據(jù)流可能包括成千上萬(wàn)個(gè)數(shù)據(jù)包，決定了第一個(gè)包怎么轉(zhuǎn)發(fā)，其實(shí)基本就確定了后面所有的包如何轉(zhuǎn)發(fā)，完全沒(méi)有必要請(qǐng)控制平面來(lái)參與所有包的處理，轉(zhuǎn)發(fā)平面需要做的僅僅是查表而已，這個(gè)包屬于曾經(jīng)被轉(zhuǎn)發(fā)過(guò)的流，簡(jiǎn)單的復(fù)制一下轉(zhuǎn)發(fā)動(dòng)作即可，這就是所謂的快速轉(zhuǎn)發(fā)（Fast-path）。一個(gè)數(shù)據(jù)包從入接口（Ingress）進(jìn)來(lái)，OpenFlow交換機(jī)需要確定他匹配哪個(gè)流，從而找到相應(yīng)的轉(zhuǎn)發(fā)動(dòng)作，迅速的把這個(gè)數(shù)據(jù)包從出接口（Egress）送出去，然后趕緊去處理下一個(gè)數(shù)據(jù)包，必須迅速查流表，而不是線性查流表。換句話說(shuō)，不能從第一行（Line）開(kāi)始一行一行匹配，看這個(gè)數(shù)據(jù)包的Header Field是不是跟這一行匹配。如果這個(gè)表有成千上萬(wàn)的行，逐行的查找是不可接受的，因?yàn)樾枰臅r(shí)間，根本不能匹配10Gbps或者更高的速率！

首先看傳統(tǒng)網(wǎng)絡(luò)設(shè)備是怎么干的，傳統(tǒng)設(shè)備里也有轉(zhuǎn)發(fā)表，例如一個(gè)傳統(tǒng)的防火墻，他的轉(zhuǎn)發(fā)表可能支持一百萬(wàn)個(gè)會(huì)話（session），標(biāo)志一個(gè)會(huì)話的特征是五元組（源目的地址/源目的端口/協(xié)議號(hào)），所以一個(gè)數(shù)據(jù)包進(jìn)來(lái)以后，防火墻需要做的就是把這個(gè)五元組提取出來(lái)，然后根據(jù)這個(gè)五元組算一個(gè)哈希值（Hash），根據(jù)這個(gè)哈希值，常數(shù)時(shí)間O（1）直接可以找到會(huì)話，然后或者匹配這個(gè)會(huì)話以后，就知道應(yīng)該把包送到哪個(gè)出接口，是不是需要對(duì)包頭進(jìn)行修改，進(jìn)行轉(zhuǎn)發(fā)即可。如果匹配不到任何會(huì)話（把這個(gè)數(shù)據(jù)包送給控制平面的CPU，看能不能建立一個(gè)新的會(huì)話）。傳統(tǒng)設(shè)備為什么可以這么干？因?yàn)樗麄兊墓δ苁窍薅ǖ?，他們需要處理的包頭的域是確定無(wú)疑的，那么提取這些域，然后做哈希查找/快速轉(zhuǎn)發(fā)，全部可以用硬件實(shí)現(xiàn)，從而達(dá)到非常高的轉(zhuǎn)發(fā)速率。

問(wèn)題是到了OpenFlow這個(gè)新世界里，有些假設(shè)不存在了，還是以上這張表，在看到具體的表內(nèi)容之前，交換機(jī)/路由器是不可能預(yù)先知道需要提取哪些字段的，也很難提前做硬件電路設(shè)計(jì)，硬件雖說(shuō)不是完全沒(méi)有辦法，但是局限很大，適應(yīng)所有字段全靈活匹配的騰挪空間嚴(yán)重不足，那還怎么快速查表，怎么轉(zhuǎn)發(fā)？

隨著OpenFlow版本的不斷升級(jí)，匹配（match）的字段由少變多，匹配本身也從定長(zhǎng)變成了類似TLV的結(jié)構(gòu)，如下圖

OpenFlow 1.0

OpenFlow 1.1

OpenFlow 1.3

雖然OpenFlow版本之間并不一致，但是“需要匹配的域是不固定的”這點(diǎn)并沒(méi)有變化，對(duì)于大多數(shù)習(xí)慣了“二層交換，三層路由，四層防火墻”的廠商來(lái)說(shuō)，二三四層靈活組合的匹配方式，的確是太復(fù)雜了。雖然各家都在努力支持更多流表的種類，支持更多流表的數(shù)目，但跟傳統(tǒng)動(dòng)輒七八十萬(wàn)條路由，百萬(wàn)級(jí)的策略/會(huì)話的大盒子（Device）來(lái)比，純OpenFlow設(shè)備能達(dá)到的性能和指標(biāo)的確是還差得很遠(yuǎn)。

因此，OpenFlow太過(guò)靈活，先天不足等等說(shuō)法也就不足為奇了。

還好有些人并不這么想，硬件搞不定，就說(shuō)軟件太靈活，這個(gè)鍋不能背！難道不能設(shè)計(jì)一個(gè)能搞定的硬件嗎？答案是可以的，不僅可以，還不止一種！我們需要的是重新定義一下轉(zhuǎn)發(fā)面的硬件，也就是所謂的PISA（Protocol Independent Switch Architecture），大家把這個(gè)事情統(tǒng)一一下認(rèn)識(shí)，至于具體各家各戶怎么實(shí)現(xiàn)，大可以自己回家閉門造車，各顯其能。

PISA的核心是轉(zhuǎn)發(fā)平面可以編程（Programmable），編程語(yǔ)言也就是比OpenFlow更紅的P4了。那P4到底是不是OpenFlow的終結(jié)者/繼承者/替換者呢？首先看這個(gè)圖。

首先，Parser把數(shù)據(jù)包解析成一系列的Header，然后依次進(jìn)入Ingress和Egress兩類流水線。在流水線里可以經(jīng)歷一系列的匹配（M）/動(dòng)作（A）的階段（Stage）。每一個(gè)Stage的核心是：一張表！匹配這張表，然后根據(jù)匹配結(jié)果做動(dòng)作，跟我們上面說(shuō)的一摸一樣對(duì)不對(duì)！那么這張表是OpenFlow的流表嗎？答案是，不一定。

準(zhǔn)確的說(shuō)，某一類的流表可以轉(zhuǎn)化成PISA里的一張表。看一下一張P4的表，跟OpenFlow的表比較一下。

可以發(fā)現(xiàn)

• P4的表是需要被P4程序明確定義的，依然是Match/Action這個(gè)思路。
• P4的表需要匹配的鍵（Key）是固定的，如上圖的VRF/IP-Prefix
• P4支持多級(jí)的表，數(shù)據(jù)包匹配完第一個(gè)表后可以匹配下一個(gè)表，因此，對(duì)于 不同包頭字段的匹配要求，可以用多個(gè)表來(lái)實(shí)現(xiàn)
• P4的匹配項(xiàng)目可以支持最長(zhǎng)前綴匹配LPM（longest prefix match），以及帶 掩碼的三元匹配（Ternary Match），這是需要硬件TCAM支持的，考慮到TCAM 的成本，這樣的匹配項(xiàng)目顯然也不能太多（但是好歹比支持OpenFlow任意匹 配簡(jiǎn)單多了）。

最關(guān)鍵的一條，PISA 架構(gòu)要求可編程性，因此用P4定義的表是可以重新編程的，重新編程P4表可以導(dǎo)致重新生成一個(gè)交換機(jī)的固件（Firmware），交換機(jī)下載以后，可以重新分配他的硬件（流水線，內(nèi)存，TCAM等）資源，針對(duì)新的匹配表實(shí)現(xiàn)硬件加速。在此之前，基于ASIC的傳統(tǒng)轉(zhuǎn)發(fā)設(shè)備對(duì)此是不可想象的。ASIC被認(rèn)為是固定（fixed）的，一旦硬件成型以后其匹配/轉(zhuǎn)發(fā)能力就是確定而不可擴(kuò)展的，軟件只能通過(guò)修改寄存器來(lái)進(jìn)行微調(diào)。而進(jìn)行一次重要的ASIC版本升級(jí)，其消耗的時(shí)間和金錢都是巨大的。

所以簡(jiǎn)單的來(lái)說(shuō)，P4的出現(xiàn)并不是為了替換掉OpenFlow，而是為交換機(jī)支持OpenFlow提供了可能性。OpenFlow的設(shè)計(jì)的確是靈活，但是并不是“太過(guò)靈活”，事實(shí)上，支持任何類型的OpenFlow流表并沒(méi)有意義，實(shí)際情況下一臺(tái)網(wǎng)絡(luò)設(shè)備將要面對(duì)的流量和流量是可以預(yù)測(cè)的，是有限的，根據(jù)可能的OpenFlow流表寫好P4的程序是可能的，通過(guò)可編程的交換芯片實(shí)現(xiàn)硬件加速是可能的，一旦發(fā)生未知的流量/應(yīng)用重新編寫P4程序并下發(fā)到P4交換機(jī)也是完全可以的。因此可以這么說(shuō)，P4一開(kāi)始的誕生也許是為了讓交換芯片適應(yīng)OpenFlow（OpenFlow Adapter），后來(lái)逐漸發(fā)展成了一種全新的可編程的交換機(jī)架構(gòu)PISA，不僅表的匹配是可編程的，Parser也是可以編程的，匹配以后的動(dòng)作Action也是可以編程的，PISA可以說(shuō)是轉(zhuǎn)發(fā)層面的一場(chǎng)革命。

OpenFlow的流表和P4的表本質(zhì)上是一樣的，都是從控制層面到轉(zhuǎn)發(fā)層面的消息，而P4則定義了整個(gè)轉(zhuǎn)發(fā)層面，和OpenFlow所處的位置不完全一致。P4和OpenFlow可以很好的協(xié)同工作，所以不存在有了P4就可以代替OpenFlow的說(shuō)法，至于P4是OpenFlow 2.0的說(shuō)法也是非常不嚴(yán)謹(jǐn)?shù)模˙TW，P4-runtime成為OpenFlow 2.0還倒是真的有點(diǎn)可能）。做為參考資料，可以看下https://github.com/p4lang/switch/blob/master/p4src/OpenFlow.p4，看OpenFlow和P4這對(duì)好基友是怎么一起工作的 ：）

談完了轉(zhuǎn)發(fā)平面，再來(lái)討論一下控制平面的事情，OpenFlow是控制器發(fā)給交換機(jī)的，交換機(jī)有了PISA，那Controller呢？從這個(gè)架構(gòu)誕生的第一天起，如何解決Controller的單點(diǎn)故障問(wèn)題就被一直被質(zhì)疑。解決單點(diǎn)故障的唯一辦法就是把單點(diǎn)變成多點(diǎn)，也就是用多個(gè)Controller來(lái)代替單一的Controller，那么多個(gè)Controller之間數(shù)據(jù)如何同步？這又是一個(gè)老生常談的分布式系統(tǒng)的問(wèn)題。

我們知道，分布式系統(tǒng)有CAP原理。

闡述了分布式系統(tǒng)中的一個(gè)事實(shí)：一致性(Consistency)、可用性(Availability)和分區(qū)容錯(cuò)性(Partition Tolerance)不能同時(shí)保證。三個(gè)只能選擇兩個(gè)。很不幸，這是所有分布式系統(tǒng)都具備的特性，并不是OpenFlow-Controller架構(gòu)獨(dú)有的“缺陷”！即使是最紅的分布式系統(tǒng)區(qū)塊鏈技術(shù)，也得服從CAP原理。換句話說(shuō)，沒(méi)有萬(wàn)能的金丹。那種希望CAP兼得的想法，只能說(shuō)是瘋狂或者幻想（Pure Madness）。

首先來(lái)解釋一下這個(gè)原理。假設(shè)有兩臺(tái)Controller A、B，兩者之間互相同步保持?jǐn)?shù)據(jù)的一致性。現(xiàn)在B由于網(wǎng)絡(luò)原因不能與A通信(Network Partition)，此時(shí)某個(gè)交換機(jī)向A發(fā)了Packet-in，A通過(guò)計(jì)算以后發(fā)現(xiàn)需要下發(fā)流表。他有兩種選擇：

• A拒絕下發(fā)流表，這樣能保證與B的一致性，但是犧牲了可用性，交換機(jī)不能在有限的時(shí)間內(nèi)得到確定的響應(yīng)。
• A正常向Client下發(fā)流表，但是這樣就不能保證與B的一致性了。

由于眾所周知的原因，我們面臨的網(wǎng)絡(luò)環(huán)境，Network Partition是必然的，網(wǎng)絡(luò)非?？赡艹霈F(xiàn)問(wèn)題（斷線、超時(shí)），因此CAP理論一般只能AP或CP，也就是在可用性和一致性里二選一。

• CP: 要實(shí)現(xiàn)一致性，則需要一定的一致性算法。
• AP: 要實(shí)現(xiàn)可用性，則要有一定的策略決議到底用哪個(gè)數(shù)據(jù)。

在以上的例子里，顯然應(yīng)該首先滿足可用性，A控制器應(yīng)該先下發(fā)流表，保證交換機(jī)可以正常工作，等到AB之間的網(wǎng)絡(luò)恢復(fù)以后，再設(shè)法將這個(gè)變化同步給B，使得AB之間達(dá)到最終一致性。（Eventually Consistency）。如果這個(gè)分布式系統(tǒng)不止AB這兩個(gè)節(jié)點(diǎn)，而是足夠復(fù)雜，最終一致性可能不是通過(guò)簡(jiǎn)單的同步（Sync）可以完成的，可能需要再多個(gè)節(jié)點(diǎn)之間通過(guò)投票來(lái)完成。也就是著名的共識(shí)算法（如Paxos和Raft）。區(qū)塊鏈技術(shù)也高度依賴共識(shí)算法，一個(gè)基本的認(rèn)識(shí)是，去中心化（Decentralization）需要參與投票的節(jié)點(diǎn)足夠多，才可以避免有人可以控制51%以上的算力。同理，如果有人抱怨控制器不可靠或者不同步，原因可能僅僅是控制器不夠多。如果僅僅有兩臺(tái)數(shù)據(jù)不一致的控制器，如何確定哪一臺(tái)的數(shù)據(jù)是完備的？如果有三臺(tái)或者更多，可能就會(huì)簡(jiǎn)單一點(diǎn)，讓他們?nèi)ネ镀本秃昧?，畢竟多臺(tái)控制器集體發(fā)瘋的可能性比較小。

因此，為了避免單點(diǎn)故障引入了分布式系統(tǒng)，CAP原理是分布式系統(tǒng)固有的特征，這不是并不是OpenFlow-Controller架構(gòu)的什么固有缺陷。通過(guò)共識(shí)算法，達(dá)到分布式系統(tǒng)的最終一致性，是完全可以實(shí)現(xiàn)的。事實(shí)上，主流的SDN-Controller早已實(shí)現(xiàn)?？梢詤⒖既缦碌恼撐膆ttps://www.telematica.polito.it/~giaccone/papers/icc16-onos.pdf

話又說(shuō)回來(lái)了，控制器也不是越多越好的，傳統(tǒng)的網(wǎng)絡(luò)里，每臺(tái)設(shè)備都有控制平面，其實(shí)就是個(gè)控制器無(wú)限多的分布式系統(tǒng)。這些控制器之間跑著各種各樣五花八門的控制協(xié)議，想讓他們達(dá)成某種共識(shí)，幾乎是不可能的。傳統(tǒng)網(wǎng)絡(luò)基本上是一個(gè)既沒(méi)有一致性C也沒(méi)有可用性A的不可控的分布式系統(tǒng)，這個(gè)系統(tǒng)的形成有其歷史原因，跟互聯(lián)網(wǎng)一步步從一個(gè)個(gè)試圖互聯(lián)的孤島變成無(wú)所不在的智能網(wǎng)絡(luò)的歷程有關(guān)，目前看，似乎工作的還可以，但是這不是我們固步自封拒絕變化的理由。我們需要更好的互聯(lián)網(wǎng)，需要更好的一致性和可用性，在傳統(tǒng)設(shè)備的世界里自?shī)首詷?lè)，不能帶來(lái)這一切。

綜合起來(lái)看，OpenFlow的紅旗，說(shuō)得更準(zhǔn)確一些，SDN的紅旗，恐怕還是要繼續(xù)打下去了。

生成海報(bào)

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來(lái)自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁(yè)或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書(shū)面權(quán)利通知或不實(shí)情況說(shuō)明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開(kāi)相關(guān)鏈接。