亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標(biāo)題: 如何讓 linux 包轉(zhuǎn)發(fā)達(dá)到 40萬pps,嘗試中！ [打印本頁]
作者: bingosek    時間: 2005-11-06 02:09
1000Kpps,好像有點(diǎn)難度哦,cisco 2600我記得就那么幾十Kpps
作者: platinum    時間: 2005-11-06 09:10
1000MBps 線速才 148.8Wpps，你這個 100Wpps 快達(dá)到千兆線速了，X86 構(gòu)架是沒戲的，只能考慮 NP 構(gòu)架了
作者: caibird3rd    時間: 2005-11-06 12:12
原帖由 platinum 于 2005-11-6 09:10 發(fā)表
1000MBps 線速才 148.8Wpps，你這個 100Wpps 快達(dá)到千兆線速了，X86 構(gòu)架是沒戲的，只能考慮 NP 構(gòu)架了

148.8Wpps是怎么來的？X86的限制在哪里呢？
作者: platinum    時間: 2005-11-06 13:29
包轉(zhuǎn)發(fā)線速的衡量標(biāo)準(zhǔn)是以單位時間內(nèi)發(fā)送64byte的數(shù)據(jù)包（最小包）的個數(shù)作為計(jì)算基準(zhǔn)的。對于千兆以太網(wǎng)來說，計(jì)算方法如下：1,000,000,000bps/8bit/（64 + 8 + 12）byte=1,488,095pps 說明：當(dāng)以太網(wǎng)幀為64byte時，需考慮8byte的幀頭和12byte的幀間隙的固定開銷。故一個線速的千兆以太網(wǎng)端口在轉(zhuǎn)發(fā)64byte包時的包轉(zhuǎn)發(fā)率為1.488Mpps�？焖僖蕴W(wǎng)的線速端口包轉(zhuǎn)發(fā)率正好為千兆以太網(wǎng)的十分之一，為148.8kpps。
*對于萬兆以太網(wǎng)，一個線速端口的包轉(zhuǎn)發(fā)率為14.88Mpps。
*對于千兆以太網(wǎng)，一個線速端口的包轉(zhuǎn)發(fā)率為1.488Mpps。
*對于快速以太網(wǎng)，一個線速端口的包轉(zhuǎn)發(fā)率為0.1488Mpps。

但是我不清楚 X86 的瓶頸在哪里
作者: guotie    時間: 2005-11-07 10:18
100Wpps是可能的。
作者: guotie    時間: 2005-11-07 10:54
你可以使用bridge，轉(zhuǎn)發(fā)效率更高。
作者: cx6445    時間: 2005-11-07 17:05
x86構(gòu)架不差的，我現(xiàn)在用的網(wǎng)絡(luò)設(shè)備x86的工控機(jī)，修改過的freebsd4.X，專用軟件。每秒http請求近1萬，并發(fā)連接10多萬，流量進(jìn)600兆出700兆，還是做nat+負(fù)載均衡的。比很多所謂的專用構(gòu)架專用芯片的網(wǎng)絡(luò)設(shè)備強(qiáng)得不止一個檔止。

[ 本帖最后由 cx6445 于 2005-11-7 17:29 編輯 ]
作者: platinum    時間: 2005-11-07 17:44
原帖由 cx6445 于 2005-11-7 17:05 發(fā)表
x86構(gòu)架不差的，我現(xiàn)在用的網(wǎng)絡(luò)設(shè)備x86的工控機(jī)，修改過的freebsd4.X，專用軟件。每秒http請求近1萬，并發(fā)連接10多萬，流量進(jìn)600兆出700兆，還是做nat+負(fù)載均衡的。比很多所謂的專用構(gòu)架專用芯片的網(wǎng)絡(luò)設(shè)備強(qiáng)得不 ...

這個是用來做什么的？服務(wù)器還是 NAT 設(shè)備還是什么？
是否統(tǒng)計(jì)過 pps 有多少？我想知道 ^_^
作者: skylove    時間: 2005-11-07 20:19
原帖由 cx6445 于 2005-11-7 17:05 發(fā)表
x86構(gòu)架不差的，我現(xiàn)在用的網(wǎng)絡(luò)設(shè)備x86的工控機(jī)，修改過的freebsd4.X，專用軟件。每秒http請求近1萬，并發(fā)連接10多萬，流量進(jìn)600兆出700兆，還是做nat+負(fù)載均衡的。比很多所謂的專用構(gòu)架專用芯片的網(wǎng)絡(luò)設(shè)備強(qiáng)得不 ...


你用的什么web server ? 能單機(jī)支持這么多連接請求...
作者: cx6445    時間: 2005-11-07 23:15
暈倒，說了是網(wǎng)絡(luò)設(shè)備呀，做負(fù)載均衡加image cache和tcp offload。
作者: platinum    時間: 2005-11-07 23:26
pps 到了多少？硬件配置又是什么樣子的？
作者: cx6445    時間: 2005-11-07 23:34
http://tech.sina.com.cn/t/2004-11-02/2337452622.shtml
就是這種產(chǎn)品，是我用過最爽的網(wǎng)絡(luò)設(shè)備，web界面和性能都非常出色的。不象有些知名網(wǎng)絡(luò)設(shè)備,官方標(biāo)稱和實(shí)際使用根本兩回事。
目前我看到過最高的時候pps好象是20萬

http://www.netscaler.ca/downloads/Datasheet-Switch.pdf

好象有做廣告嫌疑，呵呵！不過新浪用得很爽的。

[ 本帖最后由 cx6445 于 2005-11-8 00:08 編輯 ]
作者: platinum    時間: 2005-11-08 00:04
這個東西成本也低不了吧
作者: cx6445    時間: 2005-11-08 00:14
當(dāng)然不便宜了，我原意只是想說x86構(gòu)架不差的，也不是說其它的構(gòu)架不好。
作者: causky    時間: 2005-11-08 22:04
發(fā)連接10多萬??太假了
作者: guotie    時間: 2005-11-09 10:22
x86架構(gòu)服務(wù)器，上兩個cpu，linux 應(yīng)該可以輕松達(dá)到50Wpps以上的純粹轉(zhuǎn)發(fā)效率
作者: platinum    時間: 2005-11-09 10:41
“純粹轉(zhuǎn)發(fā)效率”指什么？
作者: guotie    時間: 2005-11-09 11:10
指僅僅轉(zhuǎn)發(fā)數(shù)據(jù)包。
作者: platinum    時間: 2005-11-09 11:31
X86 構(gòu)架很難做千兆的網(wǎng)絡(luò)設(shè)備，PCI 總線不夠大，不知道 PCI-E 的 133 出來以后，再配上 64 位處理器能否實(shí)現(xiàn)
作者: cx6445    時間: 2005-11-09 13:12
X86 構(gòu)架是指處理器的構(gòu)架吧，又沒說一定要使用pci的。

[ 本帖最后由 cx6445 于 2005-11-9 13:15 編輯 ]
作者: platinum    時間: 2005-11-09 13:44
原帖由 cx6445 于 2005-11-9 13:12 發(fā)表
X86 構(gòu)架是指處理器的構(gòu)架吧，又沒說一定要使用pci的。

愿聽詳解 ^_^
作者: cx6445    時間: 2005-11-09 21:25


沒有什么詳細(xì)的，一般廠商都不會自己開發(fā)總線系統(tǒng)的，成本高難度大。好象PCI－X構(gòu)架用著就不錯了。
事實(shí)就是：
FreeBSD 4.4-RELEASE
CPU: Pentium 4 (3065.00-MHz 686-class CPU)
real memory  = 3893362688 (3802112K bytes)
pci2: <CI bus> on pcib2
bx1: <3Com 3C996SX Gigabit Fiber-SX Server NIC>
bx1: PCIX target workaraund

[ 本帖最后由 cx6445 于 2005-11-9 21:26 編輯 ]
作者: caibird3rd    時間: 2005-11-10 08:51
據(jù)我所知，它的性能主要來自：
網(wǎng)絡(luò)硬件采用交換架構(gòu)，即使用交換機(jī)板，并且使用了專用硬件加速芯片（這個占了一大半成本）
現(xiàn)在要做這類高性能設(shè)備，沒有硬件支持是不行的了

能更詳細(xì)的介紹一下你們用的這款產(chǎn)品的硬件配置嗎？把你在FreeBSD下看到的輸出都列一下羅
我們現(xiàn)在用一款純軟件實(shí)現(xiàn)的產(chǎn)品，進(jìn)出各能達(dá)到近500兆，好像到瓶頸了。不過你說的進(jìn)出600/700兆，
好像吞吐量也不是很大嘛，不知最大能到多少？
原帖由 cx6445 于 2005-11-7 23:34 發(fā)表
http://tech.sina.com.cn/t/2004-11-02/2337452622.shtml
就是這種產(chǎn)品，是我用過最爽的網(wǎng)絡(luò)設(shè)備，web界面和性能都非常出色的。不象有些知名網(wǎng)絡(luò)設(shè)備,官方標(biāo)稱和實(shí)際使用根本兩回事。
目前我看到過最 ...

[ 本帖最后由 caibird3rd 于 2005-11-10 09:14 編輯 ]
作者: cubzsdb    時間: 2005-11-14 16:23
標(biāo)題: 不是有PCI 64 BIT嗎?
不是有PCI 64 BIT嗎?
作者: ahuoo    時間: 2005-11-15 00:08
兄弟是否在做防火墻之類的產(chǎn)品？
作者: mirnshi    時間: 2005-11-15 16:03
x86架構(gòu)是指cpu的指令集是i386的，pci和cpu沒有關(guān)系，好多arm指令集的嵌入式板子也采用pci總線。pci是以Intel為首的弄的，
目前工控板服務(wù)器板都是x86+pci總線的，由于包處理都是需要網(wǎng)卡經(jīng)總線由cpu處理。目前CPU的速度是足夠快了，但是pci總線卻無法滿足速度要求。
想開發(fā)一套自己的總線是沒有問題，關(guān)鍵在于周邊的設(shè)備，諸如網(wǎng)卡芯片都是PCI之類的，當(dāng)然有錢還可以接著開發(fā)自己的網(wǎng)絡(luò)處理芯片，于是變成了NP。
作千兆還是不要用FreeBSD4.x的好，內(nèi)核不支持多線程�？梢杂�6.0或者換成Linux
作者: wxxszzz    時間: 2005-11-16 22:02
主要還是現(xiàn)在的主板都是PCI總線結(jié)構(gòu)的，
只有133速率，即每秒 133M/s
跑個百兆網(wǎng)絡(luò)轉(zhuǎn)發(fā)還差不多，

即使是跑百兆網(wǎng)絡(luò)，在內(nèi)網(wǎng)機(jī)器多的情況下，內(nèi)網(wǎng)的網(wǎng)卡最好還是用千兆或者是雙百兆網(wǎng)卡，及一塊外網(wǎng)百兆網(wǎng)卡。否則內(nèi)網(wǎng)網(wǎng)卡錯誤的IP包就會很多的�？赏ㄟ^ifconfig查看到。

因?yàn)閮?nèi)網(wǎng)有很多包并不需要到外網(wǎng)去，所以內(nèi)網(wǎng)網(wǎng)卡的工作量比外網(wǎng)網(wǎng)卡多的多。

一般現(xiàn)在的815芯片到865芯片架構(gòu)的主板做內(nèi)外構(gòu)通的話，合理，經(jīng)濟(jì)的方式就是

就是兩塊百兆內(nèi)網(wǎng)網(wǎng)卡做bond綁定負(fù)載輪流接內(nèi)網(wǎng)交換機(jī)，不需要交換機(jī)支持綁定的，用個現(xiàn)在通用的
DLINK1024R+即可。。
一塊外網(wǎng)百兆網(wǎng)卡接ISP商。

基本可以跑到百兆速度極限。如果ISP沒做流量控制的話。

換算成字節(jié)的話就是每秒 11.5m/s 左右。

你可以用FTP軟件傳一個大文件試試就行了。

如果是bit的話就是 11.5*8 m/s 左右。
作者: caibird3rd    時間: 2005-11-17 10:17
原帖由 wxxszzz 于 2005-11-16 22:02 發(fā)表
主要還是現(xiàn)在的主板都是PCI總線結(jié)構(gòu)的，
只有133速率，即每秒 133M/s
跑個百兆網(wǎng)絡(luò)轉(zhuǎn)發(fā)還差不多，
...

每秒133M/s是什么東東？
作者: colddawn    時間: 2005-11-17 16:42
樓上說的正解，cpu指令集和總線架構(gòu)是2回事，pci確實(shí)不行了，32bit，133Mhz，算算帶寬百兆多點(diǎn)，稍微高點(diǎn)的應(yīng)用就不行了，所以民用領(lǐng)域推出agp，服務(wù)器領(lǐng)域推出pci-X，但目前的趨勢是統(tǒng)一回pci-E。
去intel的網(wǎng)站看看intel的網(wǎng)卡型號吧，824XX，825XX，總共幾十個型號，都是有區(qū)別的，有pci的，有pci-X 66MHz的，有pci-X133Mhz的，還有pci-E的，甚至有dual port ，quard port的，說明一旦用上pci-X以上級別的總線，網(wǎng)卡絕對是能跑那么大帶寬的，所以不必覺得X86不行了。
作者: caibird3rd    時間: 2005-11-17 21:37
32bit,133Mhz，我怎么算出來是500多兆字節(jié)呀？4個G bit/s啊
感覺處理大流量的瓶頸還是在CPU上，光是系統(tǒng)中斷的處理就是不小的一塊了
原帖由 colddawn 于 2005-11-17 16:42 發(fā)表
樓上說的正解，cpu指令集和總線架構(gòu)是2回事，pci確實(shí)不行了，32bit，133Mhz，算算帶寬百兆多點(diǎn)，稍微高點(diǎn)的應(yīng)用就不行了，所以民用領(lǐng)域推出agp，服務(wù)器領(lǐng)域推出pci-X，但目前的趨勢是統(tǒng)一回pci-E。
去intel的網(wǎng)站 ...
作者: q1208c    時間: 2005-11-17 22:19
原帖由 platinum 于 2005-11-9 11:31 發(fā)表
X86 構(gòu)架很難做千兆的網(wǎng)絡(luò)設(shè)備，PCI 總線不夠大，不知道 PCI-E 的 133 出來以后，再配上 64 位處理器能否實(shí)現(xiàn)


PCI-X 是 64bit 133MHz的. 應(yīng)該能夠用的. 但好象一臺機(jī)器也就支持一個133Mhz的然后就只能是兩個 100Mhz的. 再下來就是66Mhz的了.

X86應(yīng)該是沒什么大問題的. CheckPoint還不是多數(shù)放在x86上跑了. 只不過要優(yōu)化一下, 咱那PC可能差一點(diǎn).
作者: 阿輝    時間: 2005-11-18 09:55
我想這個可能是 LINUX性能的問題，不知樓主用的是什么網(wǎng)卡，驅(qū)動是哪的？有時候換個驅(qū)動會快很多�，F(xiàn)在有一個技術(shù)叫零拷貝。還有如果你是按到交換機(jī)上。也要看看交換機(jī)是否能達(dá)到那么高。有些交換機(jī)比較慢。建議用3com的。
作者: colddawn    時間: 2005-11-18 10:08
sorry ，前面提供資料有誤，現(xiàn)在更正一下，
最初PCI總線是32bit，33Mhz，這樣帶寬為133Mbps。
接著因?yàn)樵诜⻊?wù)器領(lǐng)域傳輸要求Intel把總線位數(shù)提高到64，這樣又出現(xiàn)了2種PCI總線，分別為64bit/33Mhz和64bit/66Mhz，當(dāng)然帶寬分別翻倍了，為266Mbps和533Mbps，這個比較通常的名稱應(yīng)該是pci-64，但這好像是intel自己做的，沒有行業(yè)標(biāo)準(zhǔn)。
稍后一段時間，在民用領(lǐng)域，單獨(dú)開發(fā)出了AGP，32bit，66Mhz，這樣帶寬為266Mbps，再加上后來AGP2.0的2X和4X標(biāo)準(zhǔn)，最高4X的帶寬高達(dá)1Gbps，但是這個只是為顯卡設(shè)計(jì)的。
同時服務(wù)器領(lǐng)域也沒閑著，幾家廠商聯(lián)合制定了PCI-X，這個就是真正PCI下一代的工業(yè)標(biāo)準(zhǔn)了，其實(shí)也沒什么新意，就是64bit，133Mhz版本的PCI，那這樣帶寬就為1Gbps，后來PCI-X 2.0,3.0又分別提升頻率，經(jīng)歷過266Mhz，533Mhz，甚至1GMhz，各位自己算帶寬吧，我乘法學(xué)的不好，這個帶寬可以說是非常足夠的了，不過這個時候PCI也面臨一些問題：一方面是頻率提高造成的并行信號串?dāng)_，另一方面是共享式總線造成的資源爭用，總之也就是說雖然規(guī)格上去了，但實(shí)際效果可能跑不了這些指標(biāo)。
然后就是我們目前的明星pci-E了，這個標(biāo)準(zhǔn)應(yīng)該是和pci-X同時出現(xiàn)的，但是由于當(dāng)時用不到這么高帶寬，并且不像pci-X一樣兼容老pci板卡，所以一直沒什么發(fā)展，直到最近民用領(lǐng)域顯卡帶寬又不夠了，服務(wù)器領(lǐng)域?qū)ci-X也覺得不爽了，pci-E才真正顯出優(yōu)勢來，目前這個標(biāo)準(zhǔn)應(yīng)該會替代agp和pci-X，成為民用和服務(wù)器兩大領(lǐng)域的統(tǒng)一標(biāo)準(zhǔn)。
PCI-E標(biāo)準(zhǔn)的最大特點(diǎn)就是串行總線，和普通pci的區(qū)別類似于ide和sata的區(qū)別，具體說起來就比較麻煩了，簡單來看指標(biāo)的話，頻率為2.5Ghz（這個恐怖，串行的好處，同樣因?yàn)榇�，位寬就沒意義了，但是據(jù)說是什么8bit/10bit的傳輸），帶寬 pci-E 1X單向傳輸250MBps，雙向也就500了，同時pci-e的倍速最高可達(dá)16X，多少就自己乘吧，要注意的是pci-e不存在共享問題，也就是說掛在總線上的任何一個設(shè)備都會達(dá)到這個速度而不是所有設(shè)備帶寬的總合。下面引用一篇文章的一段，感興趣的自己看一下：

  在工作原理上，PCI Express與并行體系的PCI沒有任何相似之處，它采用串行方式傳輸數(shù)據(jù)，而依靠高頻率來獲得高性能，因此PCI Express也一度被人稱為“串行PCI”。由于串行傳輸不存在信號干擾，總線頻率提升不受阻礙，PCI Express很順利就達(dá)到2.5GHz的超高工作頻率。其次，PCI Express采用全雙工運(yùn)作模式，最基本的PCI Express擁有4根傳輸線路，其中2線用于數(shù)據(jù)發(fā)送，2線用于數(shù)據(jù)接收，也就是發(fā)送數(shù)據(jù)和接收數(shù)據(jù)可以同時進(jìn)行。相比之下，PCI總線和PCI-X總線在一個時鐘周期內(nèi)只能作單向數(shù)據(jù)傳輸，效率只有PCI Express的一半；加之PCI Express使用8b/10b編碼的內(nèi)嵌時鐘技術(shù)，時鐘信息被直接寫入數(shù)據(jù)流中，這比PCI總線能更有效節(jié)省傳輸通道，提高傳輸效率。第三，PCI Express沒有沿用傳統(tǒng)的共享式結(jié)構(gòu)，它采用點(diǎn)對點(diǎn)工作模式（Peer to Peer，也被簡稱為P2P），每個PCI Express設(shè)備都有自己的專用連接，這樣就無需向整條總線申請帶寬，避免多個設(shè)備爭搶帶寬的糟糕情形發(fā)生，而此種情況在共享架構(gòu)的PCI系統(tǒng)中司空見慣。

    由于工作頻率高達(dá)2.5GHz，最基本的PCI Express總線可提供的單向帶寬便達(dá)到250MBps（2.5Gbps×1 B/8bit×8b/10b=250MBps），再考慮全雙工運(yùn)作，該總線的總帶寬達(dá)到500MBps—這僅僅是最基本的PCI Express ×1模式。如果使用兩個通道捆綁的×2模式，PCI Express便可提供1GBps的有效數(shù)據(jù)帶寬。依此類推，PCI Express ×4、×8和×16模式的有效數(shù)據(jù)傳輸速率分別達(dá)到2GBps、4GBps和8GBps。這與PCI總線可憐的共享式133MBps速率形成極其鮮明的對比，更何況這些都還是每個PCI Express可獨(dú)自占用的帶寬。


總之寫這么多廢話，目的就是說明就系統(tǒng)總線來說，承受高帶寬，高pps是沒問題的。
再上面有人說即使總線沒限制，cpu也會成為瓶頸，這話有一定道理，其實(shí)關(guān)鍵在于高pps帶來的恐怖中斷flood，其實(shí)對于這么高的中斷，i386的apic（高級中斷控制）是完全處理的來，瓶頸是在操作系統(tǒng)的中斷處理程序上了，這方面問題就由操作系統(tǒng)來解決了，所以不是什么不可能完成的任務(wù)，實(shí)際上目前也都有很成熟的方案了，比如BSD系統(tǒng)的網(wǎng)卡Polling，Linux也有，具體叫什么我忘記了。
還是那句話，別對i386沒信心，也別對目前的PC架構(gòu)計(jì)算機(jī)的能力有任何懷疑，事實(shí)證明，這樣的搭配至少能滿足90%的應(yīng)用需要。
作者: caibird3rd    時間: 2005-11-18 15:51
目前，linux作為一種通用的操作系統(tǒng)，
的確跟不上超高速網(wǎng)絡(luò)流量處理的需求了
不知在這方面有什么linux的改進(jìn)項(xiàng)目沒有？
聽說通過精簡優(yōu)化其TCP/IP堆�？梢垣@得近20%的性能提升，不知有沒有這回事？
覺得關(guān)鍵還在系統(tǒng)中斷方面，真是成也蕭何，敗也蕭何！
原帖由 colddawn 于 2005-11-18 10:08 發(fā)表
sorry ，前面提供資料有誤，現(xiàn)在更正一下，
最初PCI總線是32bit，33Mhz，這樣帶寬為133Mbps。
接著因?yàn)樵诜⻊?wù)器領(lǐng)域傳輸要求Intel把總線位數(shù)提高到64，這樣又出現(xiàn)了2種PCI總線，分別為64bit/33Mhz和64bit/66Mhz ...
作者: colddawn    時間: 2005-11-21 09:15
原帖由 caibird3rd 于 2005-11-18 15:51 發(fā)表
目前，linux作為一種通用的操作系統(tǒng)，
的確跟不上超高速網(wǎng)絡(luò)流量處理的需求了
不知在這方面有什么linux的改進(jìn)項(xiàng)目沒有？
聽說通過精簡優(yōu)化其TCP/IP堆�？梢垣@得近20%的性能提升，不知有沒有這回事？
覺得關(guān)鍵 ...



優(yōu)化協(xié)議棧的工作確實(shí)有人在搞，性能提升20%的說法只是聽說，沒見有實(shí)際證據(jù)，至于linux不能應(yīng)付搞網(wǎng)絡(luò)流量處理的問題，請問您是從哪里得來的？有沒有實(shí)際數(shù)據(jù)？所謂高速網(wǎng)絡(luò)高到什么程度？高流量還是高pps？
作者: wheel    時間: 2005-11-21 10:28
pci-e現(xiàn)在可以比pci-X達(dá)到跟快的速度了，現(xiàn)在ic設(shè)計(jì)里，并行的發(fā)展已經(jīng)達(dá)到一個瓶頸，因?yàn)轭l率的提高，分布和泛生也隨之更復(fù)雜，所以設(shè)計(jì)同樣性能的一個PCB,使用PCI-E比X會容易的多，并且現(xiàn)在Synopsys和Cadence對于PCI-e的IPcore的公布，新的主板使用E代替X的會越來越多，X的線真的太多了，串?dāng)_太難搞了，最少要6層板才搞的定，E就好搞到多，幾個蛇部就過去了。其實(shí)從時序分析上看不出X比E的優(yōu)點(diǎn)在那，可能還是在產(chǎn)品鏈上把。
作者: 獨(dú)孤九賤    時間: 2005-11-21 16:04
原帖由 colddawn 于 2005-11-21 09:15 發(fā)表



優(yōu)化協(xié)議棧的工作確實(shí)有人在搞，性能提升20%的說法只是聽說，沒見有實(shí)際證據(jù)，至于linux不能應(yīng)付搞網(wǎng)絡(luò)流量處理的問題，請問您是從哪里得來的？有沒有實(shí)際數(shù)據(jù)？所謂高速網(wǎng)絡(luò)高到什么程度？高流量還是高pps？


偶見過許過權(quán)威的測試報告，測試過國內(nèi)很多用linux作的防火墻、安全網(wǎng)關(guān)……等一大堆東東，用smartbit來測：
pIII 1G 的CPU，可以達(dá)到35%/64bytes左右。freebsd的話，稍好一點(diǎn)，不過也僅是“稍”；離線速差得太遠(yuǎn)了。
————————————————————
這個還只是100M，如果1000M的話，更是慘……即使是雙至強(qiáng)的CPU。

偶某高校的朋友用四至強(qiáng)的服務(wù)器，達(dá)到了1000M線速……不過成本也太……

——————————
性能不佳，有硬件的原因，也有軟件的原因。不過就目前Linux的這種定位、目前這種網(wǎng)絡(luò)堆棧架構(gòu)來看，短時間要提高，是不太現(xiàn)實(shí)的。
所以，只能希望通過硬件來提升，只是通用X86架構(gòu)，同樣，定位也不是專門針對此的，所以……
關(guān)于X86的這點(diǎn)，偶同志從CPU的角度，有一篇精典論述：
http://www.skynet.org.cn/viewthread.php?tid=11&fpage=1

聽說，ixp1200以上，powerNP高頻的CPU可以達(dá)到線速。也看過一些硬件廠商產(chǎn)品發(fā)布會現(xiàn)場演示，的確如此，不過本人沒有親自試過，不敢肯定……
作者: colddawn    時間: 2005-11-22 09:16
原帖由 獨(dú)孤九賤 于 2005-11-21 16:04 發(fā)表


偶見過許過權(quán)威的測試報告，測試過國內(nèi)很多用linux作的防火墻、安全網(wǎng)關(guān)……等一大堆東東，用smartbit來測：
pIII 1G 的CPU，可以達(dá)到35%/64bytes左右。freebsd的話，稍好一點(diǎn)，不過也僅是“稍”；離線速差得 ...



請給出所謂權(quán)威報告的鏈接？謝謝！
國內(nèi)很多防火墻是用了linux+iptables再套個外殼實(shí)現(xiàn)的，要知道光netfilter架構(gòu)處理占用的cpu時間就高達(dá)30%，如果再加上那個性能風(fēng)傳非常差的conntrack的話，這個結(jié)果不出奇，這并不能說明是總線瓶頸或者是cpu瓶頸，另一方面，即使是你說的35%的帶寬利用率，你有統(tǒng)計(jì)過那時中斷/s的數(shù)量嗎？有證據(jù)證明是cpu中斷處理不過來了嗎？
linux的我倒真是沒測試過，但是同樣是p3 1G，板載pro 100，我裝過freebsd，僅僅使用ipfw+bridge做透明防火墻，連內(nèi)核都沒有優(yōu)化過，輕松達(dá)到80M，無延遲，無丟包，100%線速說不上，但90M的時候的丟包率也是基本可以忽略不計(jì)。
如果一個1000M包轉(zhuǎn)發(fā)的設(shè)備都要用4路Xeon，那24口千兆三層交換或者路由器豈不是要大型機(jī)？
作者: 獨(dú)孤九賤    時間: 2005-11-22 09:37
原帖由 colddawn 于 2005-11-22 09:16 發(fā)表



請給出所謂權(quán)威報告的鏈接？謝謝！
國內(nèi)很多防火墻是用了linux+iptables再套個外殼實(shí)現(xiàn)的，要知道光netfilter架構(gòu)處理占用的cpu時間就高達(dá)30%，如果再加上那個性能風(fēng)傳非常差的conntrack的話，這個結(jié)果不出 ...


不太同意你的話：

1、我的報告是國家信息安全測評中心測試的，只是關(guān)系很多商家的利益，不敢亂貼，sorry！
2、請貼出你的freebsd能到80M講給出測試環(huán)境，以及測試的包的大小，我不太相信p3 1G的CPU，64bytes下能到80M，我現(xiàn)在有好幾臺freebsd的機(jī)器，p4的和至強(qiáng)的，兩邊用光陣列機(jī)來跑，512bytes下才能到100M，64bytes下離你說的數(shù)據(jù)差得太遠(yuǎn)，因?yàn)闆]有條件，沒有辦法拿Smartbit來做測試，不過我想誤差應(yīng)該不會太離譜。
3、目前intel架構(gòu)的CPU網(wǎng)絡(luò)數(shù)據(jù)處理與交換機(jī)的CPU等處理有質(zhì)的差別，不能同一而論……否則大家做什么ASIC，做什么NP，拿一塊p3不就完了……
4、至于性能不到，如果跑開軟件不談，光是談硬件的話，我個人從經(jīng)驗(yàn)來看，100M環(huán)境瓶頸主要在CPU，1000M則是一個綜合的因素，目前PC架構(gòu)在很多方面都無法滿足1000M的大流量的處理。而如果要談軟件呢，linux和unix性能之別主要還是“其實(shí)是MBuf和skbuf的優(yōu)劣，這是個老話題。……”

至于為什么我認(rèn)為100M下邊，硬件方面CPU是主要的瓶頸，這是因?yàn)?br /> 1、實(shí)踐中，換個CPU，性能可以得到質(zhì)的提升；
2、在目前的一些貼子中，我始終還是認(rèn)為我同事說得有道理，把他的原話貼出來：
——————————————————————————————————————————————
目前，很多X86的防火墻廠商都宣稱，64bytes小包線速轉(zhuǎn)發(fā)，94%……，呵呵，讓我們來看看kola關(guān)于這個的經(jīng)典論述<部份地方稍有修改>：

一. 線速
線速轉(zhuǎn)發(fā)是對一個網(wǎng)絡(luò)中轉(zhuǎn)設(shè)備的理想要求。但平時大多數(shù)人都關(guān)注著設(shè)備的bps（bits per second，每秒數(shù)據(jù)的位數(shù)），很少人會想到fps（frame per second，每秒數(shù)據(jù)的幀數(shù)）實(shí)際上更考驗(yàn)設(shè)備的轉(zhuǎn)發(fā)能力。
簡單的說，bps是指每秒鐘有多少字節(jié)的數(shù)據(jù)經(jīng)過，fps是每秒鐘有多少個數(shù)據(jù)包經(jīng)過。
以10Mb的網(wǎng)絡(luò)來說，線速時bps為10M，fps最大值為14880。
那么這個14880是怎么計(jì)算出來的呢？
首先我們要知道幾個規(guī)定：
1. 以太網(wǎng)內(nèi)最小的數(shù)據(jù)包的大小為64字節(jié)，它包括4字節(jié)的CRC，2字節(jié)的以太網(wǎng)類型（或長度），6字節(jié)的源Mac地址，6字節(jié)的目的Mac地址以及46字節(jié)的負(fù)荷。
2. 以太網(wǎng)幀與幀之間至少要有96位（12字節(jié)）的幀間隙（IFP，inter frame gap）以確保區(qū)分兩個數(shù)據(jù)包。
3. 每個數(shù)據(jù)幀開始之間必須要有8字節(jié)的Mac地址前導(dǎo)位（MAC preamble）以確保發(fā)送方接收方同步數(shù)據(jù)位。
因此，以太網(wǎng)內(nèi)最小的數(shù)據(jù)包實(shí)際上是64+12+8=84字節(jié)=672位。
于是，10M網(wǎng)絡(luò)環(huán)境下fps的最大值就是
10M位每秒 / 672 位每幀 = 14480 幀每秒。
同理，我們可以算出10M網(wǎng)絡(luò)環(huán)境下fps的最大值為
10M位每秒 / ( ( 1518+12+8 ) * 8 ) 位每幀 = 812 幀每秒
而100M網(wǎng)絡(luò)環(huán)境下這兩個值分別為148809和8127。

二. 處理能力
我們已經(jīng)知道了線速情況下最大的fps值，現(xiàn)在我們看看要達(dá)到線速所需要的處理能力。
假設(shè)市面上某防火墻的是X86架構(gòu)的CII 900Mhz 的CPU，即每秒鐘可以分成900M個時鐘周期。
于是，在100M的網(wǎng)絡(luò)環(huán)境下，處理一個數(shù)據(jù)幀所允許的最大時鐘周期為：
900M 時鐘周期每秒 / 148809 幀每秒 = 6048 時鐘周期每幀
也就是說，要達(dá)到線速轉(zhuǎn)發(fā)，900Mhz的CPU平均要在6048個時鐘周期內(nèi)完成對一個數(shù)據(jù)包的處理。
這只是理想情況，基于x86架構(gòu)的系統(tǒng)里CPU還要負(fù)責(zé)各類中斷（如系統(tǒng)時鐘）的處理，每次中斷時都要保存當(dāng)前的運(yùn)行狀態(tài)，切換到中斷處理程序，等中斷處理完后，再恢復(fù)當(dāng)前狀態(tài)，切換回原來的處理流程。光是這個切換過程至少都要費(fèi)上500個時鐘周期，還不包括中斷處理程序所用的時鐘周期。好在這類中斷還”不算“頻繁，扣除系統(tǒng)這部分開銷后，真正分?jǐn)偟矫總�數(shù)據(jù)包的處理時間平均大約還有5500個時鐘周期。
雖然Intel P3以上級的CPU如CII在設(shè)計(jì)指令集時已經(jīng)將大量常用的指令（如兩個寄存器相加/減）優(yōu)化到可以在一個時鐘周期內(nèi)完成，但做為防火墻，更常用的是讀/寫內(nèi)存數(shù)據(jù)（比如要比較源地址，計(jì)算IP的校驗(yàn)和等）這類多時鐘周期的指令，所以5500個時鐘周期內(nèi)大約只能執(zhí)行2000條指令。
對一個數(shù)據(jù)包的處理，從為這個數(shù)據(jù)包分配內(nèi)存起，依次要檢查以太網(wǎng)絡(luò)協(xié)議（如果是RFC1042格式的數(shù)據(jù)包還要跳過LLC頭找真正的以太網(wǎng)絡(luò)協(xié)議），檢查IP頭、校驗(yàn)和（如果是TCP/UDP協(xié)議還要計(jì)算對應(yīng)的校驗(yàn)和），DoS防御，狀態(tài)檢測，NAT規(guī)則，安全/統(tǒng)計(jì)規(guī)則，更新ARP/路由表，選擇轉(zhuǎn)發(fā)網(wǎng)卡，直到最終把這個數(shù)據(jù)包添加到發(fā)送隊(duì)列中才算完成。
你認(rèn)為2000條x86的指令能完成這一切嗎？

三. 現(xiàn)實(shí)數(shù)據(jù)
2000條指令看起來很多，實(shí)際上并不多，舉個例子，要完成最簡單的 A = A + B 這個算式最優(yōu)化的指令也要用上兩條：
mov eax, [val_B]
add [val_A], eax
未優(yōu)化的會用上四條：
mov eax, [val_A]
mov ebx, [val_B]
add eax, ebx
mov [val_A], eax
目前的防火墻的開發(fā)大多是在Unix/Linux上完成的，以GCC編譯器為例，它的優(yōu)化效果比商業(yè)的編譯器如VC/BC差了大概20%，也就是說同一段C代碼，用商業(yè)編譯器能編譯成100條指令的話，GCC最好的情況下只能編譯成120條指令。
實(shí)際上，在沒有任何包過濾規(guī)則或其它配置的情況下，完整的處理一個數(shù)據(jù)包需要大約14000條指令。
所以,根據(jù)上面的計(jì)算，目前許多X86架構(gòu)防火墻（PIII 800）在100M網(wǎng)絡(luò)環(huán)境下的結(jié)果是64byte的情況下達(dá)到42%的線速轉(zhuǎn)發(fā)能力，即62000fps的處理能力。至于100%，95%，90%以上……
作者: colddawn    時間: 2005-11-22 11:13
1、我的報告是國家信息安全測評中心測試的，只是關(guān)系很多商家的利益，不敢亂貼，sorry！

理解！不過這也證明目前市面上的很多國產(chǎn)設(shè)備的現(xiàn)狀以及國內(nèi)這個領(lǐng)域的研發(fā)狀況，不做評價

2、請貼出你的freebsd能到80M講給出測試環(huán)境，以及測試的包的大小，我不太相信p3 1G的CPU，64bytes下能到80M，我現(xiàn)在有好幾臺freebsd的機(jī)器，p4的和至強(qiáng)的，兩邊用光陣列機(jī)來跑，512bytes下才能到100M，64bytes下離你說的數(shù)據(jù)差得太遠(yuǎn)，因?yàn)闆]有條件，沒有辦法拿Smartbit來做測試，不過我想誤差應(yīng)該不會太離譜。

ok，我承認(rèn)，我用的是P3 1G Xeon MP，PCI-X架構(gòu)的pro 100網(wǎng)卡，以太網(wǎng)口。
同時我做的是透明網(wǎng)橋，包在2層就bridge走了，因此效率確實(shí)是比較好的，同時ipfw這個也是簡單高效的代表，因此我相信我這套搭配應(yīng)改在效率方面有較大的優(yōu)勢。
我測試的方法是發(fā)起100Mbps的synflood，這個應(yīng)該是64bytes吧，如果全速情況下，我的設(shè)備能透過84M左右到達(dá)對端，也就是能保證80M不丟包。
我認(rèn)為你測試達(dá)不到的原因可能在于你的光陣列，據(jù)我所知，光電轉(zhuǎn)換后frame結(jié)構(gòu)會改變的，跟以太網(wǎng)貞又很大區(qū)別，而光傳輸?shù)膬?yōu)勢在于高帶寬高時延，但pps就不是很好，如果你用這這種設(shè)備，2次轉(zhuǎn)換后應(yīng)該會有折損的，具體細(xì)節(jié)我不是很了解，這只是推測。另外一個原因是你的設(shè)備的網(wǎng)絡(luò)其他部分占用了較多cpu，例如ip層轉(zhuǎn)發(fā)。我的設(shè)備在最高流量下cpu占用80%左右，打開網(wǎng)卡polling后降至40%，負(fù)載不會超過1，屬于可以承受范圍

3、目前intel架構(gòu)的CPU網(wǎng)絡(luò)數(shù)據(jù)處理與交換機(jī)的CPU等處理有質(zhì)的差別，不能同一而論……否則大家做什么ASIC，做什么NP，拿一塊p3不就完了……

這里我同意，ASIC的架構(gòu)確實(shí)更適合一些，我的意思是目前CPU的指令處理速度應(yīng)該不止于如此不堪。

4、至于性能不到，如果跑開軟件不談，光是談硬件的話，我個人從經(jīng)驗(yàn)來看，100M環(huán)境瓶頸主要在CPU，1000M則是一個綜合的因素，目前PC架構(gòu)在很多方面都無法滿足1000M的大流量的處理。而如果要談軟件呢，linux和unix性能之別主要還是“其實(shí)是MBuf和skbuf的優(yōu)劣，這是個老話題�！�


CPU確實(shí)有很大影響，但是我感覺在做好一定優(yōu)化的基礎(chǔ)上，i386絕對能勝任的。MBuf的問題就不討論了，討論那就是班門弄斧了。
作者: caibird3rd    時間: 2005-11-23 09:50
現(xiàn)在100Mb/s以下的流量已經(jīng)不是問題了
我們的目標(biāo)是千兆甚至更多
現(xiàn)在看來，通用的linux平臺的確不能滿足需要（這里不談硬件部分）

誰能告訴我，linux在這方面有什么改進(jìn)項(xiàng)目沒有？或者有什么公司可以做這個事情？

另外，沒看過MBuf的資料，它比skbuf好在哪里啊？哪位能點(diǎn)撥一二？

原帖由 colddawn 于 2005-11-22 09:16 發(fā)表



請給出所謂權(quán)威報告的鏈接？謝謝！
國內(nèi)很多防火墻是用了linux+iptables再套個外殼實(shí)現(xiàn)的，要知道光netfilter架構(gòu)處理占用的cpu時間就高達(dá)30%，如果再加上那個性能風(fēng)傳非常差的conntrack的話，這個結(jié)果不出奇，這并不能說明是總線瓶頸或者是cpu瓶頸，另一方面，即使是你說的35%的帶寬利用率，你有統(tǒng)計(jì)過那時中斷/s的數(shù)量嗎？有證據(jù)證明是cpu中斷處理不過來了嗎？
linux的我倒真是沒測試過，但是同樣是p3 1G，板載pro 100，我裝過freebsd，僅僅使用ipfw+bridge做透明防火墻，連內(nèi)核都沒有優(yōu)化過，輕松達(dá)到80M，無延遲，無丟包，100%線速說不上，但90M的時候的丟包率也是基本可以忽略不計(jì)。
如果一個1000M包轉(zhuǎn)發(fā)的設(shè)備都要用4路Xeon，那24口千兆三層交換或者路由器豈不是要大型機(jī)？  ...

[ 本帖最后由 caibird3rd 于 2005-11-23 09:55 編輯 ]
作者: mirnshi    時間: 2005-11-23 21:59
原帖由 獨(dú)孤九賤 于 2005-11-22 09:37 發(fā)表


不太同意你的話：

1、我的報告是國家信息安全測評中心測試的，只是關(guān)系很多商家的利益，不敢亂貼，sorry！
2、請貼出你的freebsd能到80M講給出測試環(huán)境，以及測試的包的大小，我不太相信p3 1G的CPU，64by ...


fps鮮有所聞，大家好像一般都是說pps。楨的概念似乎是通訊上的，包似乎是網(wǎng)絡(luò)處理上的。

先看看操作系統(tǒng)如何處理包：
一般對于高效處理，很少是一個包一個中斷的，都是通過輪詢方式，比如在freebsd下，高負(fù)載情況下，
可以設(shè)置5000次/s(intel百兆卡，一般夠用，至于怎么夠用，自己算吧)甚至更高，網(wǎng)卡會將收到的包
存放于隊(duì)列中，等待cpu的主動處理。這樣中斷數(shù)會極大降低。一般好的網(wǎng)卡比如常見的intel百兆卡，
(如果沒有記錯的話，隊(duì)列大小是32，而8139才4)，可以緩沖大量的包，這樣cpu的一次中斷可以處理多
個包。在純路由模式下，即使有少量的規(guī)則，包轉(zhuǎn)發(fā)的速度是非�？斓�，基本可以達(dá)到線速的，當(dāng)然
不是100M，所有的網(wǎng)絡(luò)節(jié)點(diǎn)設(shè)備都會有延時的，只是多少而已。在防火墻中，消耗cpu的是nat和復(fù)雜的
規(guī)則檢測，其他的基本功能消耗cpu比較少, 速度非�？�，拿過一個包，通過指針定位ip頭，根據(jù)ip頭
定位動態(tài)規(guī)則表（hash檢索），比較一下要么丟棄，要么直接送到下層。如果對協(xié)議棧了解的話，會
知道一個包從網(wǎng)絡(luò)進(jìn)入?yún)f(xié)議棧，大部分流程都是條件判斷。
arp表，路由表之類的處理也非�？斓�，記得是3跳命中。再說了還有高速緩沖的，在freebsd中還可以
打開fastforward。mbuf使用起來也不像應(yīng)用層的內(nèi)存申請使用，不用擔(dān)心那么耗費(fèi)指令。對于包效驗(yàn)
和，匯編指令編寫的，一般需要幾十條指令，不會超過百條。

再看看CPU:
談?wù)摰紺PU，不能僅僅考慮頻率。CPU的性能不能僅看頻率，不同CPU的IPC也是不同的，眾所周知的PIV
剛出來的時候還不如PIII，就是因?yàn)镻IV的IPC不如PIII。而且現(xiàn)在CPU的IPC大都大于1，流水線技術(shù)不是
個擺設(shè)。還有就是PIII不等同于i686，i686只是一個指令集，支持i686的cpu很多，但是同代CPU中，PIII
是最強(qiáng)的。至于Cyrix的，是走低功耗市場的，性能嘛，不說了。

做程序，講性能，不是簡簡單單的加減乘除，理論不等于實(shí)際。42%，莫非增加N多復(fù)雜規(guī)則檢測？
作者: mirnshi    時間: 2005-11-23 22:22
目前對于百兆, CPU的速度足夠，除非增加各種稀奇古怪的功能進(jìn)去--什么各種代理過濾之類的。
對于千兆，由于pps增加了，網(wǎng)卡的隊(duì)列也增加了，考慮到時延問題和中斷，以及PCI通道問題，CPU就顯得不夠用了。內(nèi)核支持SMP的，性能會提高很多。而且千兆很多都是橋模式的，最差也是路由模式，有哪個網(wǎng)管愿意在出口處，放個瓶頸？橋模式都是2層上作，省去了三層協(xié)議隊(duì)列，當(dāng)然處理時，需要自己構(gòu)建協(xié)議棧了，包轉(zhuǎn)到協(xié)議棧后，再由其他線程處理，分工合作。但無論怎樣，受到PCI/X限制，也只能是當(dāng)個假千兆用。
曾在Freebsd上作過測試，DDOS攻擊，如果直接收包丟棄，可以達(dá)到8、900M，機(jī)器是PIV2.4至強(qiáng)，bsd 4.11，但是發(fā)包受限，優(yōu)化得非常好了不過300多。
作者: zyzf    時間: 2005-11-30 11:17
X86的瓶頸就在網(wǎng)卡驅(qū)動上面。
個人覺得。
作者: test_tmp    時間: 2005-12-05 08:43
標(biāo)題: 請問樓主,如何達(dá)到5萬PPS?
我也在做NAT,但還是新手,請樓主指點(diǎn)一下,如何達(dá)到5萬PPS?還有如何測一臺機(jī)器的PPS數(shù)
非常感謝
作者: test_tmp    時間: 2005-12-06 16:56
怎么沒人理我
作者: depthblue_xsc    時間: 2005-12-15 17:17
我正在測試千兆防火墻的性能，64B雙向達(dá)到線速的15%（30秒的測試時間）
如何能夠再提高，系統(tǒng)如何再優(yōu)化呢？netfilter的效率不高，linux的網(wǎng)絡(luò)i/o分布不平衡
系統(tǒng)還有什么地方可以優(yōu)化呢？
作者: Solaris12    時間: 2005-12-15 17:32
原帖由 mirnshi 于 2005-11-23 22:22 發(fā)表
目前對于百兆, CPU的速度足夠，除非增加各種稀奇古怪的功能進(jìn)去--什么各種代理過濾之類的。
對于千兆，由于pps增加了，網(wǎng)卡的隊(duì)列也增加了，考慮到時延問題和中斷，以及PCI通道問題，CPU就顯得不夠用了。內(nèi)核支持 ...


100M/1000M現(xiàn)在OS一般都handle的了。

上1000個連接達(dá)到線速也是沒問題的，不需要很強(qiáng)勁的機(jī)器。

但是10000M網(wǎng)卡就不一樣了，這個需要特別的處理。

感興趣的話，可以在solaris上測測萬兆網(wǎng)卡。


因?yàn)楸救瞬皇歉惴阑饓Φ�，所以不了解這方面的問題。

在100M/1000M上，CPU真的不是大問題。
而且先進(jìn)的網(wǎng)卡都支持HW offload，很多工作不需要CPU來做。

當(dāng)然這取決與你driver和OS是否充分利用了網(wǎng)卡的先進(jìn)特性。


在intel e1000和broadcom的網(wǎng)卡上，都有類似的特性。

所以你的dirver和你的OS版本很重要，一定要用支持HW offload的版本

[ 本帖最后由 Solaris12 于 2005-12-15 17:39 編輯 ]
作者: caibird3rd    時間: 2005-12-15 20:54
現(xiàn)在的問題既不是網(wǎng)卡，也不是CPU
而是網(wǎng)絡(luò)協(xié)議及其依賴的OS中斷處理機(jī)制，而且網(wǎng)卡僅僅支持csum等簡單的offload作用不大
原帖由 Solaris12 于 2005-12-15 17:32 發(fā)表


100M/1000M現(xiàn)在OS一般都handle的了。

上1000個連接達(dá)到線速也是沒問題的，不需要很強(qiáng)勁的機(jī)器。

但是10000M網(wǎng)卡就不一樣了，這個需要特別的處理。

感興趣的話，可以在solaris上測測萬兆網(wǎng)卡。


...

[ 本帖最后由 caibird3rd 于 2005-12-15 20:56 編輯 ]
作者: Solaris12    時間: 2005-12-16 11:22
原帖由 caibird3rd 于 2005-12-15 20:54 發(fā)表
現(xiàn)在的問題既不是網(wǎng)卡，也不是CPU
而是網(wǎng)絡(luò)協(xié)議及其依賴的OS中斷處理機(jī)制，而且網(wǎng)卡僅僅支持csum等簡單的offload作用不大



這個問題，既是網(wǎng)卡，CPU，總線，還是OS，更是driver的問題，需要幾部分協(xié)作：

網(wǎng)卡：提供HW offload機(jī)制，目的是減輕CPU的壓力，比如check sum offload，LSO，MSI，interruput blanking，甚至是整個協(xié)議棧的offload

CPU：NP/SUN的CMT

總線：PCI-X對付1000M綽綽有余

OS: interruput blanking/MSI

dirver: 充分利用OS和網(wǎng)卡提供的這些特性。

目前，Solaris已經(jīng)支持了interruput blanking，很多dirver也使用了HW  offload機(jī)制.

相信linux也差不多。所以我說100M/1000M的問題已經(jīng)解決，目前主要10000M的問題。

關(guān)于操作系統(tǒng)的網(wǎng)絡(luò)方面，我們曾經(jīng)請SUN的著名工程師eric，也是IEEE的委員，做過一次演講，請參考下面的網(wǎng)址：

http://blog.csdn.net/yayong/archive/2005/10/22/513676.aspx

http://www.opensolaris.org/os/co ... g-erik_nordmark.pdf

[ 本帖最后由 Solaris12 于 2005-12-16 11:32 編輯 ]
作者: hvtony    時間: 2005-12-16 11:49
標(biāo)題: linux---firewall
不清楚各位在linux下測試相關(guān)性能的時候用的是怎樣的linux？是一般的標(biāo)準(zhǔn)發(fā)行版本redhat,suse什么的（猜的，不大可能吧），還是定制的呢？
我在linux下測試的brouter，帶防火墻和流量控制，100M網(wǎng)絡(luò)環(huán)境，目前是帶了15臺服務(wù)器，流量跑到11Mbyte/s是輕而易舉的，而且看到的負(fù)載主要集中于硬件的IRQ上。
對于iptables和conntrack的優(yōu)化，目前有很多的方法啊，比如ipset和nf-hipac就是不錯的選擇，就算是iptables在使用的過程中也不會太占用CPU的，我的防火墻規(guī)則大概150條左右。
CPU用的是Celern 2.0G的，網(wǎng)卡用的是Intel 1000M，主要是看中了他的NAPI和tso。
對于100M網(wǎng)絡(luò)，32位的66MHZ的卡肯定是可以的，32*66已經(jīng)大于100了。
作者: lenn    時間: 2006-01-09 10:50
P4 2.8*2 Xeon CPU下是可以達(dá)到這個轉(zhuǎn)發(fā)性能的.
我把E1000網(wǎng)卡修改成零拷貝,直接收包,可以達(dá)到950Mbps以上,包數(shù)可以達(dá)到120W,雖然64bit的小包線速達(dá)不到,
但是流量是可觀的,單個CPU使用70%,
發(fā)包的我沒有硬件做測試,假如雙網(wǎng)卡,使用核心線程作零拷貝發(fā)包,也就是包不通過協(xié)議棧,假設(shè)性能折扣為3/4,那應(yīng)該也可
以達(dá)到600到700Mbps的.如果你有興趣,我們可以討論下.
MSN:liangvy@bigfoot.com
作者: sbyond    時間: 2006-01-10 15:20
2006.1.10再來一點(diǎn)補(bǔ)充
上次說錯了100萬應(yīng)該是1，000，000,即1000kpps
2.6.14 自編譯內(nèi)核 轉(zhuǎn)發(fā)峰值155Kpps  ,基本能穩(wěn)定在130kpps
離我希望的400kpps 還有一定差距，繼續(xù)努力中
作者: guotie    時間: 2006-02-22 13:41
呵呵，不知道樓主的情況如何了。

我剛剛在linux-net的郵件列表上看到的討論，關(guān)于linux net轉(zhuǎn)發(fā)率的測試數(shù)據(jù)：

Yes PCI-X boards is sending around ~800 kpps. With some ugly patches about
300 kpps more.

Intel w. e1000 82546GB @ 133 MHz

60  748406
124  693133
252  452951
508  234982
1020  119742
1496  82242

The BCM PCI-X  *inside* the serverworks H2000 is faster.

BCM w. tg3

60  1421959
124  844572
252  452918
508  234970
1020  119735
1496  82239

Fastest and most intresing sofar is the Intel 82571 Server PCI-E dual
server adapter.

60  1488305
124  844635
252  452835
508  234973
1020  119737
1496  82240

IO latency is worse with PCI-E but the Intel 82571 can handle four
concurrent RX/TX transactions. Also PCI-E is FX this seems to well
handle the PCI-E extra latency.

Stephen I've heard some good things about the Syskonnect PCI-E adapters
any chance you could run a test similar to the tests above?
作者: wheel    時間: 2006-02-22 17:34
8bits的基帶數(shù)據(jù)映射成10bits的數(shù)據(jù),保證10bit數(shù)據(jù)中“0”/“1”信號的數(shù)量相等,的確是PCI-E的加速特性，這樣不用時鐘，PCI-Ex總線在8B/10B編碼層之前采用擾頻，和K28.0字符時鐘補(bǔ)償 。使得高頻特性跟好了。
作者: caibird3rd    時間: 2006-02-24 09:01
對于PCI、PCI-X、PCI-E等總線，是否可以認(rèn)為如下結(jié)論成立：
雙向同時傳輸數(shù)據(jù)時單個方向上的速率是否為完全單向傳輸速率的一半？
作者: skipjack    時間: 2006-03-01 15:11
標(biāo)題: 回復(fù) 1樓 sbyond 的帖子
40萬?要求也太低了吧,100M冰盾軟件都能轉(zhuǎn)發(fā)25萬pps,1000M下至少也是160萬啊?(網(wǎng)上你搜一下)
還有什么方正黑殺,dosnipe,神洲盾.....都是一個小黑箱就號稱可防數(shù)百萬pps啊,你要做一個40萬的,估計(jì)要用到486CPU,這可不好找啊.
作者: lenn    時間: 2006-03-01 15:53
原帖由 skipjack 于 2006-3-1 15:11 發(fā)表
40萬?要求也太低了吧,100M冰盾軟件都能轉(zhuǎn)發(fā)25萬pps,1000M下至少也是160萬啊?(網(wǎng)上你搜一下)
還有什么方正黑殺,dosnipe,神洲盾.....都是一個小黑箱就號稱可防數(shù)百萬pps啊,你要做一個40萬的,估計(jì)要用到486CPU,這可 ...


軟件轉(zhuǎn)發(fā),有這么牛么??
作者: skipjack    時間: 2006-03-01 16:01
原帖由 lenn 于 2006-3-1 15:53 發(fā)表


軟件轉(zhuǎn)發(fā),有這么牛么??


做syn包判斷比轉(zhuǎn)發(fā)更耗時吧,再說判斷的結(jié)果可能就是轉(zhuǎn)發(fā)啊,號稱是每秒13萬個包時不丟包,呵呵
作者: coco520    時間: 2006-04-07 16:17
有種技術(shù)叫napi的，從中斷入手解決轉(zhuǎn)發(fā)效率，效果還可以。lz可以試試。
作者: obrire    時間: 2006-04-07 20:29
標(biāo)題: 是可以實(shí)現(xiàn)的
原帖由 sbyond 于 2005-11-6 01:09 發(fā)表
以前作NAT 5萬PPS 沒有問題（AS4）CPU只到5%左右

現(xiàn)在不需要NAT，只做靜態(tài)路由轉(zhuǎn)發(fā)（）
(route)
echo 1 >/proc/sys/net/ipv4/ip_forward
eth0 1.1.1.1
eth1 2.2.2.1

測試拓?fù)洌?client1_----------- ...


此前公司的IP_FORWARD就達(dá)到了8,000,000
不過你內(nèi)核最好修改一下.

至于說到CISCO/華為的產(chǎn)品, 早在沖擊波時, 就趴下一大堆(一所學(xué)校, 有2K Workstation)
不過Linux還是挺起的.

首先要修改MAX CONNECTION
還有并發(fā)的SESSION.
細(xì)節(jié)參閱/proc/sys/net/ipxx下面的相關(guān)記錄.

最好是SMP構(gòu)架, 修改Ether卡的驅(qū)動, 大規(guī)模啟用DMA.
近乎于SUN的IP BOND.也可多臺, 實(shí)現(xiàn)應(yīng)用層交換.
1000萬的PPS都沒問題.看看Google的流量. 一天多少?用IPVS機(jī)群, 都可以實(shí)現(xiàn)
包括Real Networks流媒體服務(wù)器系統(tǒng).
作者: obrire    時間: 2006-04-07 20:48
標(biāo)題: 純軟件是達(dá)不到QOS要求的
原帖由 skipjack 于 2006-3-1 15:11 發(fā)表
40萬?要求也太低了吧,100M冰盾軟件都能轉(zhuǎn)發(fā)25萬pps,1000M下至少也是160萬啊?(網(wǎng)上你搜一下)
還有什么方正黑殺,dosnipe,神洲盾.....都是一個小黑箱就號稱可防數(shù)百萬pps啊,你要做一個40萬的,估計(jì)要用到486CPU,這可 ...


純軟件始終要采用OS提供的IP協(xié)議棧,  如果僅在Windows下或未經(jīng)優(yōu)化的內(nèi)核, 即便是達(dá)到了,
也不合格. 你可以用專業(yè)儀器測試一下.

要優(yōu)化性能, 首先要從物理層開始, 充分利用物理特性(如DShow/DDraw).
如果所用晶片有限, 軟件是做不出來的.

至于有人翻譯的ZERO COPY, 其實(shí)最大限度就是DMA傳送.

在OS的MM管理中,你看看當(dāng)前我們的內(nèi)存帶寬有多大, 然后將各種時延算進(jìn)去,
最終封包, 發(fā)出去, 才知道我們的性能怎么樣.

其始在NP/MP之外, CISCO也用Intel的P系列CPU.
只是OS Kernel不一樣, 其它也與你的PC一樣.

至于傳輸Channel,以前公司生產(chǎn)光交換, 但也要通過光電轉(zhuǎn)換.
如果光電轉(zhuǎn)換及Cable Drive能力很差, 性能也是跟不上的.

順便說一下, 目前的電纜也可以傳10Gbps.我有朋友就是CISCO全球三大核心晶片(10G平臺)供應(yīng)商之一.
加拿大的,還有一家叫Broadcom的公司也能做, Siemens下的半導(dǎo)體公司也很牛的.

用10Gbps減去各種限制時延和內(nèi)存封包能力, 就可以從理論上算出我們所要的pps了.
作者: obrire    時間: 2006-04-07 21:04
標(biāo)題: 有點(diǎn)好笑(GCC)
原帖由 獨(dú)孤九賤 于 2005-11-22 09:37 發(fā)表


不太同意你的話：

1、我的報告是國家信息安全測評中心測試的，只是關(guān)系很多商家的利益，不敢亂貼，sorry！
2、請貼出你的freebsd能到80M講給出測試環(huán)境，以及測試的包的大小，我不太相信p3 1G的CPU，64by ...


知道VxWorks的C編譯器嗎?
其實(shí)Intel 的C編譯器與GCC也有很多合作,PowerPC一般都采用的GCC, Apple就是(OS是GCC編譯的,
Default Compile也是GCC),我看過公司的服務(wù)器Apple Server/Power G5 2.0 2 CPU, 性能高得很,
比2 枚AMD 64/2 枚Intel至強(qiáng)同等高很多.

你看過IPP的源碼嗎? 懂什么叫優(yōu)化嗎? 做過WiMMX優(yōu)化嗎?

如果說VC能優(yōu)化, GCC不能優(yōu)化, 可能你根本就沒從事過這方面的工作.
NY 的交通系統(tǒng),就是VxWorks在GCC下編譯的.

其實(shí)VxWorks提供的ARM平臺源碼中, 幾乎就是GCC定制的一個子集.

知道CELL用什么編譯嗎?IBM用的是GCC,而SONY美國也在招GNU工作師.

天知道, 怎么會發(fā)這樣的 B I A 言.

如果說他們是白癡, 總還有一些從比他們更白癡!
作者: skipjack    時間: 2006-04-07 22:13
>>純軟件始終要采用OS提供的IP協(xié)議棧,  如果僅在Windows下或未經(jīng)優(yōu)化的內(nèi)核, 即便是達(dá)到了,
>>也不合格. 你可以用專業(yè)儀器測試一下.
你指的不合格是什么?專業(yè)儀器測SMB和IXIA應(yīng)該說的過去吧

>>要優(yōu)化性能, 首先要從物理層開始, 充分利用物理特性(如DShow/DDraw).
>>如果所用晶片有限, 軟件是做不出來的.
物理層從網(wǎng)線算還是從網(wǎng)卡模塊算起?給個結(jié)論IA體系的轉(zhuǎn)發(fā)極值是多少?

>>至于有人翻譯的ZERO COPY, 其實(shí)最大限度就是DMA傳送.
這個了解,但真正意義上的包轉(zhuǎn)發(fā)線速和DMA沒必然的聯(lián)系,DMA主要還是為了用于解決收包時的瓶勁,但NP/MP還是靠微引擎的并行度

>>OS的MM管理中,你看看當(dāng)前我們的內(nèi)存帶寬有多大, 然后將各種時延算進(jìn)去,
>>最終封包, 發(fā)出去, 才知道我們的性能怎么樣.
很迷惑了,看不出其間的聯(lián)系,軟硬中斷都不考慮在內(nèi)是嗎?

>>其始在NP/MP之外, CISCO也用Intel的P系列CPU.
>>只是OS Kernel不一樣, 其它也與你的PC一樣.
那是因?yàn)镮A構(gòu)架在某種應(yīng)用時優(yōu)于NP/MP

>>至于傳輸Channel,以前公司生產(chǎn)光交換, 但也要通過光電轉(zhuǎn)換.
>>如果光電轉(zhuǎn)換及Cable Drive能力很差, 性能也是跟不上的.
就這句知道是什么意思

>>順便說一下, 目前的電纜也可以傳10Gbps.我有朋友就是CISCO全球三大核心晶片(10G平臺)
>>供應(yīng)商之一.加拿大的,還有一家叫Broadcom的公司也能做, Siemens下的半導(dǎo)體公司也很牛的.
>>用10Gbps減去各種限制時延和內(nèi)存封包能力, 就可以從理論上算出我們所要的pps了.
為什么是10G而不是100G,好像10G是個極限似的?如果是,怎么算出來的?
作者: skipjack    時間: 2006-04-07 22:26
>>知道VxWorks的C編譯器嗎?
知道

>>其實(shí)Intel 的C編譯器與GCC也有很多合作,PowerPC一般都采用的GCC, Apple就是(OS是GCC編譯的,
>>Default Compile也是GCC),我看過公司的服務(wù)器Apple Server/Power G5 2.0 2 CPU, 性能高得很,
>>比2 枚AMD 64/2 枚Intel至強(qiáng)同等高很多.
你是說這個性能提升都是編譯器的功勞?

>>你看過IPP的源碼嗎? 懂什么叫優(yōu)化嗎? 做過WiMMX優(yōu)化嗎?
沒                    懂             沒做過

>>如果說VC能優(yōu)化, GCC不能優(yōu)化, 可能你根本就沒從事過這方面的工作.
>>NY 的交通系統(tǒng),就是VxWorks在GCC下編譯的.
倒~勇氣號也是VxWorks,NY的交通系統(tǒng)能說明GCC什么?您到底想說明什么問題?

>>其實(shí)VxWorks提供的ARM平臺源碼中, 幾乎就是GCC定制的一個子集.
您這么一解釋,我都快不知道VxWorks和xscale,那個是OS那個是CPU了

>>知道CELL用什么編譯嗎?IBM用的是GCC,而SONY美國也在招GNU工作師.
>>天知道, 怎么會發(fā)這樣的 B I A 言.
>>如果說他們是白癡, 總還有一些從比他們更白癡!
知道CELL是IBM的多核,但這能說明GCC什么呀?看了您的貼子,我怎么感覺頭有點(diǎn)暈啊.
作者: skipjack    時間: 2006-04-07 22:34
>>此前公司的IP_FORWARD就達(dá)到了8,000,000,不過你內(nèi)核最好修改一下.
幾網(wǎng)口,上面這個數(shù)字的單位是什么?只修改內(nèi)核就可以了?不會是軟件控制硬件的bypass功能吧?

>>至于說到CISCO/華為的產(chǎn)品, 早在沖擊波時, 就趴下一大堆(一所學(xué)校, 有2K Workstation)
>>不過Linux還是挺起的.
呵呵....告訴我拓樸和環(huán)境,就像你說Google流量大,但我的機(jī)器卻安然無樣一樣.

>>首先要修改MAX CONNECTION
>>還有并發(fā)的SESSION.
>>細(xì)節(jié)參閱/proc/sys/net/ipxx下面的相關(guān)記錄.
開始胡說八道了

>>最好是SMP構(gòu)架, 修改Ether卡的驅(qū)動, 大規(guī)模啟用DMA.
>>近乎于SUN的IP BOND.也可多臺, 實(shí)現(xiàn)應(yīng)用層交換.
>>1000萬的PPS都沒問題.看看Google的流量. 一天多少?用IPVS機(jī)群, 都可以實(shí)現(xiàn)
>>包括Real Networks流媒體服務(wù)器系統(tǒng).
春風(fēng)吹~戰(zhàn)鼓擂了
作者: obrire    時間: 2006-04-08 11:58
原帖由 skipjack 于 2006-4-7 22:13 發(fā)表
>>純軟件始終要采用OS提供的IP協(xié)議棧,  如果僅在Windows下或未經(jīng)優(yōu)化的內(nèi)核, 即便是達(dá)到了,
>>也不合格. 你可以用專業(yè)儀器測試一下.
你指的不合格是什么?專業(yè)儀器測SMB和IXIA應(yīng)該說的過去吧

> ...


至于專業(yè)的NP/MP，也就是專業(yè)的ASIC，將路由算法內(nèi)置于其中．就像有些DSP一樣，將算法內(nèi)置．
這不新鮮．AXIS就將一個ARM 920核和4M Memory和4M Flash內(nèi)置，還有一些算法．PMC以前有
些Chip,在PMC自己做的VoIP上，在泰爾測試時，時延都比較大，你不迷信ASIC.這只能HU外行．ASIC
設(shè)計(jì)也有水平高低，也有算法邏輯的優(yōu)劣，不同公司出品的，以及新的技術(shù)的加入，這都會影響最終
對數(shù)據(jù)包的處理能力的．如果你的NP運(yùn)算能力有限，我就用兩枚P IV加優(yōu)化了的軟件算法，也是可以
達(dá)到的，有時還可以超出，以前有朋友幫Intel做一個NP的驅(qū)動，NP好貴．現(xiàn)在有一種便宜的做法是
用VS機(jī)群來取代這種方式．他最終受限于總線．就你DVR系統(tǒng)一樣，如果IDE接口受限，你可以使用
Fiber Channel/IEEE 1394B等．NP最終還是要和其它電路接口的，各種接口也是一種限制．就像在
通信中，F(xiàn)REEDM的能力一樣，HDLC鏈路成幀就是專門的ASIC，但要工作，還得接入我的計(jì)算機(jī)系統(tǒng)
才行呀．你寫的Driver就直接影響性能吧．當(dāng)時我看了IBM和DELL的兩臺服務(wù)器，同樣的配置，但I(xiàn)BM
的整體性能就要好一點(diǎn)，只是相差不很大而已.(TPCC測試)

但在通信領(lǐng)域，目前在10G平臺，做得最好的就是Juniper．其實(shí)我就懷疑港灣就是OEM他們的，
或者是給Juniper提供核心的公司的．CISCO還要慢一步．

至于有人談到10/100G，光鍵是在MSTP上，SDH一般以10G單波為基礎(chǔ)．至于DWDM，只是多波
復(fù)用（密集波分），所以一般以10G為一技術(shù)基準(zhǔn)．如果全光交換及交叉，是沒問題的，但我們的其它
接入系統(tǒng)是電接口，因此必須有光電轉(zhuǎn)換．因此單通道以10G為基準(zhǔn)．談1T沒實(shí)際意義，這只是在傳
輸干線才使用，肯定是國家級干線，或國際干線，都是DWDM．光纖在理論是帶寬是無限寬的．

其實(shí)就是你家的有線電視線，或電氣特性有些差異，在短距離是可以傳10Gbps的數(shù)字信號的．也就
是說，在電接口方面，好的網(wǎng)線也可以達(dá)到10G數(shù)字帶寬，這是很難的．3.5G->5G->10這是其技術(shù)
發(fā)展路線．我不肯定，這會用到OFDM調(diào)制．在電力線上要達(dá)到100Mbps，必使用OFDM.

我們公司原來的路由器是Intel的，但他的性能是穩(wěn)定的，如果是高性能，就談不上了．如果P2P并發(fā)太
多，肯定會死的．在CISCO 3000/4000中，你用目前的通用CPU，選好的PHY接口CHIP，不是RTL的，
最好是Broadcom的，你看看是你的快，還是CISCO的路由器好吧．只能說Linux下，IP性能上稍差于BSD
Unix，如果優(yōu)化一下，或使用VxWorks提供的，那就不一樣了．而華為/CISCO等，還不是基于VxWorks
做的．其實(shí)將IP Stack放入ASIC或置于計(jì)算機(jī)中，差異不是很大，要可配置，必然內(nèi)存等級與你用的差不
多，訪問時間也差不多．有時在通信CPU中，MIPS值可能很高的．一般可以達(dá)到5000-8000，就是DSP
也不行呀．DSP目前最快的也就1GHz．如果我的CPU也做專項(xiàng)運(yùn)行，上Embedd OS，性能還要優(yōu)于這些
專用的ASIC．如果專門來做路由及應(yīng)用交換，用VS是首選，我的內(nèi)存可以很大呀，專用的ASIC不可能集成
很多內(nèi)存的，擴(kuò)展不就與我的一樣了嗎？關(guān)鍵是ASIC各X86計(jì)算機(jī)，在MII層要好的芯片，不然性能差異較大．

好多人說100Mbps，看看你的各種網(wǎng)卡，測出來都什么樣吧．有些高于，有些還達(dá)不到．

只能說，專門的如Juniper的T640這種設(shè)備，各個環(huán)節(jié)都是相適應(yīng)的．

但這些由專業(yè)廠商做的東東，沒有幾M　RMB是拿不下來的．他是直接上干線，下行至你的Workstation．

所以人家才牛嘛．

[ 本帖最后由 obrire 于 2006-4-8 12:18 編輯 ]
作者: obrire    時間: 2006-04-08 12:06
標(biāo)題: 當(dāng)時我們公司也有80臺交換機(jī)
原帖由 skipjack 于 2006-4-7 22:34 發(fā)表
>>此前公司的IP_FORWARD就達(dá)到了8,000,000,不過你內(nèi)核最好修改一下.
幾網(wǎng)口,上面這個數(shù)字的單位是什么?只修改內(nèi)核就可以了?不會是軟件控制硬件的bypass功能吧?

>>至于說到CISCO/華為的產(chǎn)品, 早在 ...


這是2003年的夏天．
不僅如此，就是聯(lián)通和電信的機(jī)房，也比較忙的．因?yàn)楫?dāng)時的軟件中沒有對連接會話進(jìn)行限制．

如果NAT，他限也限不了呀．我內(nèi)網(wǎng)中IP時時變．

后來，我們設(shè)計(jì)了程序，一旦發(fā)現(xiàn)過多的報文來自同一MAC，就封了．并對各種狀態(tài)進(jìn)行過濾．
當(dāng)然這會讓性能下降．不過計(jì)算性能較高，P IV對小網(wǎng)足夠了．

如果2W 用戶，每人100連接，不修改，你看Linux不Crash才怪．好像IP默認(rèn)最大連接不超
過10萬（我在Windows下，記不起了）

內(nèi)網(wǎng)100Mbps／外網(wǎng)100Mbps.如果交換機(jī)沒有流控，你看看倒不倒.
作者: obrire    時間: 2006-04-08 12:16
標(biāo)題: 上海電信 Web Cache
原帖由 skipjack 于 2006-4-7 22:34 發(fā)表
>>此前公司的IP_FORWARD就達(dá)到了8,000,000,不過你內(nèi)核最好修改一下.
幾網(wǎng)口,上面這個數(shù)字的單位是什么?只修改內(nèi)核就可以了?不會是軟件控制硬件的bypass功能吧?

>>至于說到CISCO/華為的產(chǎn)品, 早在 ...

這是基于Linux做的，國內(nèi)還有朗新用FreeBSD做的．

如果這不能說明問題，我就無話可說了．這是IPVS發(fā)起人的弟弟布置的．在2003年可以是挺得很直喲．
當(dāng)時好多CISCO倒下了．

有些人說話要有證據(jù)才行呀． 英國Tunsys超級計(jì)算機(jī)公司的設(shè)計(jì)也是基于二層交換，VS做的．這在
FBI用了很多喲．

IPVS目前已經(jīng)并入Linux 2.6的內(nèi)核中．是章文嵩博士發(fā)起的．有什么問題，你可以向他提問．

先看看在IBM上他的算法吧．不過有人以后用這些前沿技術(shù)，記得向開發(fā)者致敬呀，別像TurboLinux，
很沒道德．IBM贊助了章在世界各地講學(xué)呀，IBM在網(wǎng)格計(jì)算中，應(yīng)當(dāng)會有這些技術(shù)的身影．

中國人呀，首先要有道德，不能亂整，沒修養(yǎng)．
作者: skipjack    時間: 2006-04-08 15:25
原帖由 obrire 于 2006-4-8 12:16 發(fā)表

這是基于Linux做的，國內(nèi)還有朗新用FreeBSD做的．

如果這不能說明問題，我就無話可說了．這是IPVS發(fā)起人的弟弟布置的．在2003年可以是挺得很直喲．
當(dāng)時好多CISCO倒下了．

有些人說話要有證據(jù)才行呀． 英 ...


謝謝,雖然你說的我現(xiàn)在不能全部理解,但至少有了個全面的了解.哈哈......你說的這些環(huán)境,我還都沒有機(jī)會見到過.Juniper的性能很高,就像你說的轉(zhuǎn)發(fā)時把路由算法內(nèi)置了.但像內(nèi)容過濾這類的應(yīng)用.現(xiàn)在他可以內(nèi)置了嗎?因?yàn)閚etscreen在連接率上受限于ASIC芯片,也不是什么強(qiáng)項(xiàng).只聽說過Tcom之類的芯片,但應(yīng)用中還沒有觸及過.類似的還有正則表達(dá)式匹配芯片等等,它們的瓶勁在那里?
作者: obrire    時間: 2006-04-08 17:03
標(biāo)題: 回復(fù) 71樓 skipjack 的帖子
內(nèi)容過濾在第四層及以上層面
也就是有人所說的七層交換, 這里已經(jīng)沒有傳統(tǒng)路由的概念了.
新技術(shù)的發(fā)展,  以前的定義和說法是需要局部限定的.
以前說LAN是局部的, 如果采用IP->E1映射, LAN也可以從上海到北京.



歡迎光臨 Chinaunix (http://www.72891.cn/) Powered by Discuz! X3.2