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

  免費注冊 查看新帖 |

Chinaunix

  平臺 論壇 博客 文庫
最近訪問板塊 發(fā)新帖
樓主: lenn
打印 上一主題 下一主題

Intel-E100網(wǎng)卡驅動實例分析 [復制鏈接]

論壇徽章:
0
11 [報告]
發(fā)表于 2006-01-18 16:38 |只看該作者
請問 lenn,用“旁路 TCP 攔截”技術,PC 能達到千兆線速嗎?

(筆誤,之前少寫了一個 n,呵呵

[ 本帖最后由 platinum 于 2006-1-19 01:09 編輯 ]

論壇徽章:
0
12 [報告]
發(fā)表于 2006-01-18 22:37 |只看該作者
線速達不到,我們實際電信生產(chǎn)大概一臺機器2個網(wǎng)卡能處理1.8G的流量,1個網(wǎng)卡處理950M流量。
實際上“線速”這個概念只存在于實驗室,電信的亂包大概是100多字節(jié)長度比較多,而且很多都是
大包。旁路攔截其實發(fā)出來的攔截包很少的,普通網(wǎng)卡用sock_raw發(fā)包就足夠了,主要是能收下所有
的包及時處理,“及時”的概念是在下一輪收報不給覆蓋,就可以了,延遲點問題不大,因為你處于被控制
的地方最近,通常是出口附近。而訪問的地方通常是比較遠,跨越路由器的。

我叫l(wèi)enn,不是len,呵呵...

論壇徽章:
0
13 [報告]
發(fā)表于 2006-01-19 01:12 |只看該作者
原帖由 lenn 于 2006-1-18 22:37 發(fā)表
線速達不到,我們實際電信生產(chǎn)大概一臺機器2個網(wǎng)卡能處理1.8G的流量,1個網(wǎng)卡處理950M流量。
實際上“線速”這個概念只存在于實驗室,電信的亂包大概是100多字節(jié)長度比較多,而且很多都是
大包。旁路攔截其實發(fā) ...

繼續(xù)請教 lenn
“及時”的概念是在下一輪收報不給覆蓋,就可以了

倘若被覆蓋了,又會怎樣呢?

還有,“延時大點無所謂”,這個延時是人為用程序產(chǎn)生的嗎?這個怎么理解?

另外,我沒有明白上面說的“大概一臺機器2個網(wǎng)卡能處理1.8G的流量,1個網(wǎng)卡處理950M流量”,可能我還沒能理解“旁路”的工作原理

論壇徽章:
0
14 [報告]
發(fā)表于 2006-01-19 14:25 |只看該作者
延時大點無所謂,我的意思是說,給網(wǎng)卡開的緩沖區(qū)是一定的,即使用內(nèi)部協(xié)議棧,包在系統(tǒng)內(nèi)的生存時間總有一個固定值,
假如說一個網(wǎng)卡1000K包數(shù)/秒,開辟一個100M大小的緩沖區(qū),因為一個eth frame是1500,為了計算方便,給每個包使用
2k字節(jié), 則1M放512個包, 100M可以放共100*512= 50K個包; 如果不做任何處理,則包的生存時間是1/20秒= 0.05秒
也就是如果應用程序能夠50毫秒內(nèi)處理完這個包,則系統(tǒng)相當不丟包,在這個條件下,一個應用程序如果有鎖的碰撞,很容易丟包.

旁路攔截是在智能交換機(路由器)中,使用portmap或者端口分光技術,把出口的流量進行復制后送給處理機器,這樣處理機器
就能處理那么多的流量了. 通;貜桶乃俣纫h遠快于正常請求包速度,這樣就能先到達請求機器,從而達到控制的目的.
這種情況下,只能對tcp進行攔截,對udp無能為力,如果要對udp應用攔截,只能是模擬應用發(fā)送udp請求包.

這個系統(tǒng)缺點是要使用交換機等設備,但是能做交換機作不到的很多工作,比如應用攔截,統(tǒng)計,監(jiān)控等.
如果采用直接攔截,我認為目前的PC SERVER是達不到這樣的能力的,一個普通的防火墻應用,最多也只能處理300M左右
的流量吧(不確定).所以要用PC作這樣的高性能防火墻,估計性能還是不怎么夠.

如有錯誤,請多指教,呵呵.

論壇徽章:
0
15 [報告]
發(fā)表于 2006-01-19 15:03 |只看該作者
lenn兄弟的帖子我得頂,哈哈

論壇徽章:
0
16 [報告]
發(fā)表于 2006-01-19 15:04 |只看該作者
不錯,高人

論壇徽章:
0
17 [報告]
發(fā)表于 2006-01-19 15:37 |只看該作者

回復 14樓 lenn 的帖子

你說2個網(wǎng)卡能搞1.8G,是不是這個東西的瓶頸就完全在網(wǎng)卡抓包這一塊?如果你抓到了1.8G的流量。處理起來cpu和內(nèi)存是不是增長的不是很大呢?

論壇徽章:
0
18 [報告]
發(fā)表于 2006-01-19 16:02 |只看該作者
技術瓶頸是在抓包這一塊,如果走協(xié)議棧,CPU都消耗在system上了,達不到要求;
如果CPU> 2.4G的主頻,那性能瓶頸是應用處理, 為了分析各種包, 必須要把所有的原數(shù)據(jù),比如用戶信息,過濾關鍵信息等
都放在大內(nèi)存中作cache,這么大的流量,頻繁的鎖肯定是不能用的,其實都沒有什么技術含量了,只有一些經(jīng)驗的做法,知道
怎么處理更快,怎么處理更節(jié)約時間,呵呵.

論壇徽章:
0
19 [報告]
發(fā)表于 2006-01-19 16:30 |只看該作者

回復 18樓 lenn 的帖子

如果過濾關鍵信息的時候也是在cache里處理而不copy出來的話,那應該是需要處理得很快了。但是這個cache怎么組織呢?如果就是一片內(nèi)存的話,那數(shù)據(jù)包的長度都不一樣,放進去倒是方便,取出來的時候怎么知道哪兒是一個數(shù)據(jù)包的頭,哪兒是尾呢?是不是你還得自己給接受到的數(shù)據(jù)包也加一個自己定義的頭然后在放到cache里?
  
  總之一句話,如果不能頻繁加鎖。那怎么控制緩存的同步問題?

論壇徽章:
0
20 [報告]
發(fā)表于 2006-01-21 00:11 |只看該作者
好東西啊
您需要登錄后才可以回帖 登錄 | 注冊

本版積分規(guī)則 發(fā)表回復

  

北京盛拓優(yōu)訊信息技術有限公司. 版權所有 京ICP備16024965號-6 北京市公安局海淀分局網(wǎng)監(jiān)中心備案編號:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年舉報專區(qū)
中國互聯(lián)網(wǎng)協(xié)會會員  聯(lián)系我們:huangweiwei@itpub.net
感謝所有關心和支持過ChinaUnix的朋友們 轉載本站內(nèi)容請注明原作者名及出處

清除 Cookies - ChinaUnix - Archiver - WAP - TOP