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

Chinaunix

標(biāo)題: TCP/IP實(shí)現(xiàn)刨根究底大討論【活動結(jié)束】 [打印本頁]

作者: Godbach 時(shí)間: 2011-03-20 23:49
標(biāo)題: TCP/IP實(shí)現(xiàn)刨根究底大討論【活動結(jié)束】
獲獎(jiǎng)名單 ID

一等獎(jiǎng)：ynchnluiti，aaaaa5aa
二等獎(jiǎng)：goter，EasyIOCP，asweisun_shan，sytpb
三等獎(jiǎng)：xiongweixie

注：感謝網(wǎng)友 sytpb 對本次活動的回帖做了匯總（http://72891.cn/thread-2310521-1-1.html），這里將其評為二等獎(jiǎng)。

請以上所有獲獎(jiǎng)?wù)撸M快通過站內(nèi)短信與“風(fēng)鈴之音”聯(lián)系領(lǐng)獎(jiǎng)事宜。

TCP/IP是網(wǎng)絡(luò)中使用的基本的通信協(xié)議，是Internet國際互聯(lián)網(wǎng)絡(luò)的基礎(chǔ)。TCP/IP協(xié)議的一個(gè)開源實(shí)現(xiàn)就是在GNU/Linux中。GNU/Linux是互聯(lián)網(wǎng)中使用非常廣泛的用于服務(wù)器的操作系統(tǒng)，借助于研究Linux內(nèi)核中TCP/IP協(xié)議棧的源代碼，可以幫助我們深入理解和掌握TCP/IP協(xié)議的精髓。

近期由機(jī)械工業(yè)出版社出版的《Linux內(nèi)核源碼剖析 —TCP/IP實(shí)現(xiàn)》是一部系統(tǒng)的講解Linux下TCP/IP協(xié)議棧實(shí)現(xiàn)的書。該書由從事網(wǎng)絡(luò)方面工作多年、有著豐富開發(fā)經(jīng)驗(yàn)的樊東東和莫瀾共同完成的。

感謝CU論壇和機(jī)械工業(yè)出版社的大力支持，本次活動由內(nèi)核源碼版和《Linux內(nèi)核源碼剖析 —TCP/IP實(shí)現(xiàn)》的作者聯(lián)手舉辦，活動的主題就是：

【討論Linux下TCP/IP的實(shí)現(xiàn)】

活動時(shí)間：3月20日---4月20日

活動參與：

1. 發(fā)表網(wǎng)絡(luò)內(nèi)核方面（Netfilter，TCP 協(xié)議棧等）的經(jīng)驗(yàn)分享或問題出來大家一起討論
2. 結(jié)合 TCP/IP 協(xié)議棧的實(shí)現(xiàn)（如能結(jié)合原書更好），有疑問之處，可以隨便發(fā)問，難倒作者或者嘉賓
3. 指出書中或者樣章中的錯(cuò)誤，包括筆誤和技術(shù)錯(cuò)誤
4. 結(jié)合高版本的內(nèi)核代碼（高于本書分析的 2.6.20）改動較大的實(shí)現(xiàn)，向作者提出改進(jìn)或完善的建議

作者介紹：

樊東東： ChinaUnix論壇資深會員，從事網(wǎng)絡(luò)行業(yè)十年以上，精通 Linux內(nèi)核及網(wǎng)絡(luò)協(xié)議棧的實(shí)現(xiàn)，對網(wǎng)絡(luò)方面有深入的研究, 對終端網(wǎng)絡(luò)設(shè)備的開發(fā)以及軟件系統(tǒng)架構(gòu)比較有經(jīng)驗(yàn)。

莫瀾：女，2004年畢業(yè)于中國地質(zhì)大學(xué)，方向地理信息系統(tǒng)，精通 Linux 內(nèi)核及協(xié)議棧的相關(guān)實(shí)現(xiàn)。目前從事項(xiàng)目管理工作，興趣廣博且多有專攻。

本書目前在ChinaUnix提供獨(dú)家試讀活動：
http://book.chinaunix.net/showbook.php?id=100703

Linux內(nèi)核源碼剖析 —TCP/IP實(shí)現(xiàn)

作　　者       樊東東莫瀾
出版社       機(jī) 械工業(yè) 出版社

樣章試讀（打開鏈接即可閱讀該章節(jié)的全部內(nèi)容）：

第11章  IP：網(wǎng)際協(xié)議

第26章  TCP：傳輸控制協(xié)議

第29章  TCP擁塞控制的實(shí)現(xiàn)

邀請嘉賓：

為了加強(qiáng)討論，我們還邀請一些專家參與討論，其中包括：

platinum： ChinaUnix 資深版主。精通 Linux TCP/IP協(xié)議棧的相關(guān)實(shí)現(xiàn)，精通內(nèi)核及網(wǎng)絡(luò)開發(fā)，精通 iptables 的開發(fā)和使用。

hritian：劉泓昊，長期從事linux內(nèi)核網(wǎng)絡(luò)協(xié)議棧方面的研究，尤其擅長tcp協(xié)議優(yōu)化；曾就職于某知名的CDN公司，開拓并負(fù)責(zé)linux內(nèi)核方面的定制，自行提出并完成了多個(gè)大幅度提高服務(wù)質(zhì)量和單機(jī)性能的項(xiàng)目。

cjhacker：現(xiàn)就讀于首都師范大學(xué)信息工程學(xué)院，研二，方向?yàn)樾畔z索，同時(shí)在九九房實(shí)習(xí)。目前對于網(wǎng)絡(luò)安全，垂直搜索，手機(jī)開發(fā)等有濃厚興趣。cjhacker為該書的校對提出了很多有價(jià)值的問題和建議，成為本書公開面世前的首批讀者。

活動獎(jiǎng)品：

一等獎(jiǎng)：《Linux內(nèi)核源碼剖析 —TCP/IP實(shí)現(xiàn)》圖書一套，共兩名
二等獎(jiǎng)，CU襯衫，共三名
三等獎(jiǎng)，CU積分800分，共五名

CU十周年禮品襯衫效果圖

評選規(guī)則：

針對某一個(gè)會員，有價(jià)值的討論貼達(dá)到5貼以上，將按照帖子的數(shù)量評出獎(jiǎng)品。

感謝機(jī)械工業(yè)出版提供禮品支持！

歡迎大家積極參與，更歡迎大家自薦為討論嘉賓。如有任何問題請聯(lián)系我們！

作者: send_linux 時(shí)間: 2011-03-21 00:03

支持一下，感謝版主的工作，我們以后要多發(fā)起這樣的技術(shù)討論活動，促進(jìn)技術(shù)版面的交流，從線上到線下，全面開花

作者: chenyx 時(shí)間: 2011-03-21 07:54
感謝版主的工作

作者: wkq5325 時(shí)間: 2011-03-21 08:02
142￥？好貴呀

作者: 獨(dú)孤九賤 時(shí)間: 2011-03-21 09:33
好像要參與，得先有書，看了才行……

作者: Godbach 時(shí)間: 2011-03-21 09:54

好像要參與，得先有書，看了才行……
獨(dú)孤九賤發(fā)表于 2011-03-21 09:33

九賤兄說得對啊。但是條件有限，僅能提供三章的內(nèi)容可供閱讀，可以看一下活動介紹。

另外，作者最初發(fā)帖介紹本書的時(shí)候，也提供了一些樣章，都可以作為參考：
http://72891.cn/viewthr ... p%3Bfilter%3Ddigest

作者: Godbach 時(shí)間: 2011-03-21 09:56
回復(fù) 4# wkq5325
多多發(fā)帖，說不定這本書就是你的了。

作者: 賀蘭云天 時(shí)間: 2011-03-21 09:58
送書不？

作者: Godbach 時(shí)間: 2011-03-21 10:02
回復(fù) 8# 賀蘭云天
看一下活動介紹嘛

活動獎(jiǎng)品：

一等獎(jiǎng)：《Linux內(nèi)核源碼剖析 —TCP/IP實(shí)現(xiàn)》圖書一套，共兩名
二等獎(jiǎng)，CU襯衫，共三名
三等獎(jiǎng)，CU積分800分，共五名

作者: ecjtubaowp 時(shí)間: 2011-03-21 10:05
支持支持，看看

作者: amarant 時(shí)間: 2011-03-21 10:06
一直都想看看TCP/IP的，現(xiàn)在比較忙。。計(jì)劃一直擱淺，估計(jì)要到明年才有時(shí)間開始學(xué)習(xí)網(wǎng)絡(luò)了

作者: flw2 時(shí)間: 2011-03-21 10:19
支持

作者: ww2000e 時(shí)間: 2011-03-21 10:24
目前知道的書一本說1.2.13的，還有一本說2.6.18的，這本講解版比較本高，想看看

作者: luoyan_xy 時(shí)間: 2011-03-21 10:35
支持一下，雖然一直都打算好好學(xué)習(xí)網(wǎng)絡(luò)協(xié)議，但目前進(jìn)展依然不大。。。

希望自己能夠堅(jiān)持學(xué)習(xí)

作者: Godbach 時(shí)間: 2011-03-21 10:49
回復(fù) 13# ww2000e
歡迎啊。這次申請的樣章，也是 TCP/IP 實(shí)現(xiàn)中比較核心的幾個(gè)章節(jié)，可以這幾章的鏈接，看一下具體內(nèi)容。

作者: cugb_cat 時(shí)間: 2011-03-21 11:00
校友啊！

作者: Godbach 時(shí)間: 2011-03-21 11:22
回復(fù) 16# cugb_cat
是的。不過不知道是武漢的還是北京的。

作者: duanjigang 時(shí)間: 2011-03-21 11:27
支持，感覺《深入理解linux網(wǎng)絡(luò)內(nèi)幕》這本書從介紹和框架上已經(jīng)講的不錯(cuò)了。
如果能結(jié)合此書閱讀源碼，定能收獲不小。
記得幾年前CSDN有個(gè)日志，記錄TCP/IP實(shí)現(xiàn)的，是源碼分析，寫的特別好，可惜剛才沒找到URL
細(xì)心的同學(xué)應(yīng)該有收藏的。。

作者: Godbach 時(shí)間: 2011-03-21 11:31
回復(fù) 18# duanjigang

感謝 duan 兄分享

作者: tempname2 時(shí)間: 2011-03-21 11:40
最初的那個(gè)帖子里，作者都說了是自己出書，后面還一群人求電子版囧。。。。。

作者: lovebible 時(shí)間: 2011-03-21 12:25
很好的活動，強(qiáng)烈支持。

作者: goter 時(shí)間: 2011-03-21 12:30
書已經(jīng)買了，hritian大俠我等你講擁塞算法呢

作者: Godbach 時(shí)間: 2011-03-21 12:36

書已經(jīng)買了，hritian大俠我等你講擁塞算法呢
goter 發(fā)表于 2011-03-21 12:30

goter 兄也可以先講一下自己存在的一些問題，對該書的一些建議

作者: goter 時(shí)間: 2011-03-21 12:38
回復(fù) 23# Godbach

我的問題就是沒時(shí)間看書

作者: ecjtubaowp 時(shí)間: 2011-03-21 13:58
hritian 校友+曾經(jīng)的同事啊，tcp/ip牛人，贊�。�

作者: sjtlqy 時(shí)間: 2011-03-21 19:51
有些貴�。】匆娔切┐u頭一樣的書，有些內(nèi)容很枯燥，不知道怎么樣這個(gè)

作者: Anzyfly 時(shí)間: 2011-03-21 21:43
支持一下，頂一頂

作者: ubuntuer 時(shí)間: 2011-03-21 22:46
找時(shí)間看看,不過我對這個(gè)MM更加有興趣莫瀾...
搞內(nèi)核的MM，御姐~

作者: Godbach 時(shí)間: 2011-03-22 09:48
回復(fù) 28# ubuntuer

LS 的嚴(yán)肅點(diǎn)。這兒討論 TCP 呢

作者: hritian 時(shí)間: 2011-03-22 11:07
回復(fù) 26# sjtlqy

我也是買了，基本沒怎么看。
這本書貌似當(dāng)工具書會比較好，內(nèi)容比較新，特色就如作者說的那樣，tcp協(xié)議棧講的是我看到的書里面講的最詳細(xì)的。

作者: Godbach 時(shí)間: 2011-03-22 11:09
本帖最后由 Godbach 于 2011-03-22 11:38 編輯

回復(fù) 30# hritian
歡迎 hritian 兄分享一下研究 TCP/IP 協(xié)議棧的方法。

作者: SpringfieldKing 時(shí)間: 2011-03-22 15:38
確實(shí)很貴，上下冊140多。。

作者: aaaaa5aa 時(shí)間: 2011-03-22 18:27
其實(shí)一直以來都有個(gè)問題，不知道這算不算與本書相關(guān)

大家都知道TCP連接的建立是要通過三次握手，而TCP頭里面有個(gè)COUNT（32位）是用于標(biāo)識包的順序，

每次傳一個(gè)包之后count的值要加上1，我想問的是建立三次握手時(shí)，這個(gè)count序號是不是要增加，是增

加了多少的值？能不能詳細(xì)的講一下建立三次握手時(shí)TCP頭的數(shù)據(jù)相關(guān)變化情況

作者: lmarsin 時(shí)間: 2011-03-22 22:27
回復(fù) 33# aaaaa5aa

SYN和FIN都會占一個(gè)序號，因此在握手過程中，沒有負(fù)載的情況下，會遞增1

作者: Godbach 時(shí)間: 2011-03-22 22:30
回復(fù) 33# aaaaa5aa

大家都知道TCP連接的建立是要通過三次握手，而TCP頭里面有個(gè)COUNT（32位）是用于標(biāo)識包的順序，

每次傳一個(gè)包之后count的值要加上1，我想問的是建立三次握手時(shí)，這個(gè)count序號是不是要增加，是增

加了多少的值？

你說的這個(gè)是序列號 seq。
每發(fā)一次包不是增加 1，而是 seq + len，這個(gè) len 指的是 TCP 數(shù)據(jù)部分的長度

能不能詳細(xì)的講一下建立三次握手時(shí)TCP頭的數(shù)據(jù)相關(guān)變化情況

等待 lmarsin 兄和 hritian 兄的分析。

作者: hritian 時(shí)間: 2011-03-23 10:09
回復(fù) 35# Godbach

tcp包頭只有個(gè)seq和ack位，沒有所謂的count。
seq和ack的作用是為了實(shí)現(xiàn)可靠傳輸機(jī)制，seq是表示當(dāng)前數(shù)據(jù)包的序號，ack是表示已經(jīng)確認(rèn)的數(shù)據(jù)的序號。通過seq和ack，接收方就可以知道對方發(fā)送過來的數(shù)據(jù)是否是順序的，類似的發(fā)送發(fā)通過ack就能夠知道有多少數(shù)據(jù)包被確認(rèn)，同時(shí)在tcp協(xié)議的早期，沒有開啟sack選項(xiàng)以前，3個(gè)重復(fù)的ack包，還是發(fā)送方判斷丟包的標(biāo)志（事實(shí)上2年前淘寶（百度好像也是）還沒有啟用sack）。
seq，我要是沒有記錯(cuò)的話，新數(shù)據(jù)包的skb->seq = tp->snd_nxt，每次有新的數(shù)據(jù)包發(fā)送以后會刷新snd_nxt =skb->end_seq，
skb->end_seq = skb->seq + 數(shù)據(jù)包內(nèi)容長度 + flag |（FIN|SYN）

作者: sjtlqy 時(shí)間: 2011-03-23 10:26
我已經(jīng)訂了曹大哥的1.12的情景分析，我初學(xué)者，多多包涵

作者: sjtlqy 時(shí)間: 2011-03-23 10:26
回復(fù) 30# hritian

我已經(jīng)訂了曹大哥的1.12的情景分析，我初學(xué)者，多多包涵

作者: snow888 時(shí)間: 2011-03-23 11:15
回復(fù) 2# send_linux

俺都沒這書啊，如何指出書中的問題撒。

作者: send_linux 時(shí)間: 2011-03-23 11:22

回復(fù) send_linux

俺都沒這書啊，如何指出書中的問題撒。
snow888 發(fā)表于 2011-03-23 11:15

有樣章的啊，可以在線看看的

作者: Godbach 時(shí)間: 2011-03-23 11:23
回復(fù) 39# snow888
本次活動有三個(gè)章節(jié)的樣張可以閱讀。
并且，我在1 樓中，也提到了，原先 lmarsin 兄在內(nèi)核版發(fā)的帖子中，也給了一些樣章。這些都可以供你閱讀。

作者: ryangecko 時(shí)間: 2011-03-23 13:53
最近在學(xué)習(xí)TCP擁塞控制的實(shí)現(xiàn)，下午去弄本書看看，哈，如果能加上tcp包重組實(shí)例就更好，可以對內(nèi)容過濾了

作者: Godbach 時(shí)間: 2011-03-23 14:20
回復(fù) 42# ryangecko

擁塞控制方面，本次活動提供的有原書中的對應(yīng)章節(jié)，LS 也可以參考。

作者: xtlx2000 時(shí)間: 2011-03-23 15:59
標(biāo)題: 【討論Linux下TCP/IP的實(shí)現(xiàn)】關(guān)于TCP擁塞處理和流量控制部分的入門問題
最近在結(jié)合阿獅的書在分析TCP部分，三次握手和發(fā)送接收的邏輯相對比較容易理解，但TCP的擁塞處理和流量控制部分有N多種情況的判斷，擁塞處理和流量控制又是動態(tài)的，無法根據(jù)情景模擬來徹底理解，同時(shí)關(guān)于TCP實(shí)現(xiàn)原理的書最權(quán)威的就是《TCPIP詳解》了，但當(dāng)前版本(我的linux是2.6.27)的實(shí)現(xiàn)已經(jīng)不再與《詳解》相同。。。

請問該如何入門以及如何真正理解擁塞處理和流量控制部分的方法？

作者: Godbach 時(shí)間: 2011-03-23 16:07
建議 LZ 直接在咱們內(nèi)核版活動貼 TCP/IP實(shí)現(xiàn)刨根究底大討論中跟帖吧。

作者: phone1126 時(shí)間: 2011-03-23 17:32
仔細(xì)看了
《Linux內(nèi)核源碼剖析 —TCP/IP實(shí)現(xiàn)》的目錄。好像沒有怎么涉及原始套接字的內(nèi)容吧

另外
提議：想把網(wǎng)絡(luò)這塊編成一個(gè)庫，實(shí)現(xiàn)如tcp/ip udp等協(xié)議原始套接字（應(yīng)用原始套接字,可以編寫出由TCP和UDP套接字不能夠?qū)崿F(xiàn)的功能）等，給用戶一個(gè)良好的api。
此外，最好實(shí)現(xiàn)其與平臺（linux，wince等）無關(guān)性，怎么實(shí)現(xiàn)呢？

作者: hritian 時(shí)間: 2011-03-23 19:24
本帖最后由 hritian 于 2011-03-23 20:18 編輯

回復(fù) 44# xtlx2000

這部分其實(shí)是tcp協(xié)議棧里面比較容易理解的，擁塞控制模塊里面包含了很多現(xiàn)在流行的擁塞控制算法，代碼也相對簡單明了。流量控制其實(shí)更簡單，你記住一句話，擁塞窗口永遠(yuǎn)小于滑動窗口，滑動窗口=對方發(fā)過來的ack包的windows*2的n次方，2的n次方也就是tcp的wscale選項(xiàng)確定的,而且tp->snd_una（被確認(rèn)的序號）+windows（窗口大�。�>tp->snd_nxt
+packet_len或者說是skb->end_seq (tcp_snd_wnd_test(tp, skb, mss_now))

作者: goter 時(shí)間: 2011-03-23 20:30
這本書講了linux擁塞控制的實(shí)現(xiàn)方法和架構(gòu)。具體的擁塞算法介紹的不多。
我個(gè)人認(rèn)為擁塞算法需要考慮的就是在避免擁塞產(chǎn)生的情況下盡可能的發(fā)包。

而僅僅通過是否丟包是判斷不出網(wǎng)絡(luò)擁塞還是鏈路本身的丟包。這個(gè)就是優(yōu)化點(diǎn)了。
理解有錯(cuò)誤的地方希望hritian ，hritian和Godbach 指出

作者: lmarsin 時(shí)間: 2011-03-23 21:33

這本書講了linux擁塞控制的實(shí)現(xiàn)方法和架構(gòu)。具體的擁塞算法介紹的不多。
我個(gè)人認(rèn)為擁塞算法需要考慮的就是 ...
goter 發(fā)表于 2011-03-23 20:30

當(dāng)初是想介紹幾個(gè)常用的算法，但后來由于篇幅以及時(shí)間原因，在加上算法嵌套在擁塞實(shí)現(xiàn)的框架中，不妨礙我們對擁塞的理解，因此沒有詳細(xì)介紹某個(gè)或多個(gè)具體的算法。

作者: platinum 時(shí)間: 2011-03-23 21:55
個(gè)人感覺，各種不同的擁塞控制算法是 TCP 的精髓部分

作者: ecjtubaowp 時(shí)間: 2011-03-24 10:20

仔細(xì)看了
《Linux內(nèi)核源碼剖析 —TCP/IP實(shí)現(xiàn)》的目錄。好像沒有怎么涉及原始套接字的內(nèi)容吧

另外
...
phone1126 發(fā)表于 2011-03-23 17:32

這個(gè)有很多的現(xiàn)成的庫啊，不用自己實(shí)現(xiàn)了，比如libpcap等，當(dāng)然你自己實(shí)現(xiàn)也可以嘍。

作者: hritian 時(shí)間: 2011-03-24 11:07
個(gè)人認(rèn)為擁塞控制的目的，從本質(zhì)上來說，是高效并且合理的利用網(wǎng)絡(luò)帶寬。所以理論界常用的擁塞控制的評價(jià)標(biāo)準(zhǔn)就成了效率、公平性和收斂性。
不過現(xiàn)在來看這個(gè)常用的評價(jià)標(biāo)準(zhǔn)還是有一些不合理的地方，soso也就會有這么多人來討論tcp協(xié)議的優(yōu)化。

從傳統(tǒng)意義上來說，擁塞控制的本質(zhì)是擁塞窗口的調(diào)整，不過就我現(xiàn)在的經(jīng)歷而言，我覺得可以跳出窗口的概念，從“什么時(shí)候發(fā)送包，發(fā)送什么包”這樣一個(gè)思路來看，可能空間會更大一些。
（以上僅是個(gè)人觀點(diǎn)，歡迎指正。）

作者: ynchnluiti 時(shí)間: 2011-03-24 15:23
回復(fù) 52# hritian

“什么時(shí)候發(fā)送包，發(fā)送什么包”

難點(diǎn)就在這里

作者: xiongweixie 時(shí)間: 2011-03-24 16:41
請問源碼中關(guān)于TCP擁塞控制中實(shí)現(xiàn)的部分是在哪些文件中？

作者: ynchnluiti 時(shí)間: 2011-03-24 17:07
回復(fù) 54# xiongweixie

net/ipv4/ 下：
tcp_input.c
擁塞算法：
tcp_cong.c
tcp_cubic.c
tcp_highspeed.c
tcp_htcp.c
tcp_hybla.c
tcp_bic.c
tcp_scalable.c
tcp_vegas.c
tcp_veno.c
tcp_westwood.c

作者: Godbach 時(shí)間: 2011-03-24 17:23
回復(fù) 55# ynchnluiti

LS 對擁塞控制很有研究啊，歡迎分享一些經(jīng)驗(yàn)。

作者: xiongweixie 時(shí)間: 2011-03-24 17:39
回復(fù) 55# ynchnluiti

十分感謝！要是遇到什么問題。繼續(xù)來問您。哈哈

作者: platinum 時(shí)間: 2011-03-24 17:41
各位如果細(xì)心的話，有沒有發(fā)現(xiàn)部分擁塞算法雖然內(nèi)核提供了，但卻無法使用？

比如 HSTCP（High Speed TCP），其內(nèi)部實(shí)現(xiàn)了快啟動機(jī)制（Quick-Start），Riverbed 就使用了該技術(shù)來實(shí)現(xiàn) TCP 加速
但是即便內(nèi)核里選擇了 <*>，在“Default TCP congestion control”里會發(fā)現(xiàn)，這個(gè)選項(xiàng)不存在。

是何用意呢？不得而知……

作者: aaaaa5aa 時(shí)間: 2011-03-24 18:33

回復(fù) Godbach

tcp包頭只有個(gè)seq和ack位，沒有所謂的count。
seq和ack的作用是為了實(shí)現(xiàn)可靠傳輸機(jī)制， ...
hritian 發(fā)表于 2011-03-23 10:09

seq是表示當(dāng)前數(shù)據(jù)包的序號也就相當(dāng)于count，我的count不是指包數(shù)量，而是包的個(gè)數(shù)

作者: aaaaa5aa 時(shí)間: 2011-03-24 18:43
還想問一個(gè)問題：

首先在IP層，IP數(shù)據(jù)有16個(gè)位來表示IP數(shù)據(jù)報(bào)的總長度，書上提到因此IP數(shù)據(jù)報(bào)最長可達(dá)65535B。盡管可以傳送一個(gè)65535B長的IP數(shù)據(jù)報(bào)，但是大多數(shù)的鏈路層都會對它進(jìn)行分片，而且主機(jī)也要求不能接收超過576B的數(shù)據(jù)報(bào)。

在TCP層，書中提到通常情況下TCP允許窗口尺寸為65535B，但對于帶寬很高的網(wǎng)絡(luò)而言這個(gè)值可能還是太小，此時(shí)如果啟用了該選項(xiàng)，可使TCP滑動窗口大小增大數(shù)個(gè)數(shù)量級，從而提高數(shù)據(jù)傳輸?shù)哪芰Α?br />
TCP層最終還是要通過IP層來傳輸，是否在IP層，還要對TCP包進(jìn)行分包，分包后的數(shù)據(jù)都包括TCP層和IP層頭數(shù)據(jù)嗎？請問能不能詳細(xì)講下分包過程

作者: hritian 時(shí)間: 2011-03-24 19:01
回復(fù) 58# platinum

quick-start我是四五年前看的，不知道記得對不對，它是一個(gè)基于網(wǎng)絡(luò)系統(tǒng)的大協(xié)議，光靠一個(gè)端系統(tǒng)支持就不能解決問題的。soso。。。。。。。。。
quick-start本質(zhì)上好像是初始窗口大小的自適應(yīng)調(diào)整吧，實(shí)際上現(xiàn)在很多定制的tcp協(xié)議棧（包括國內(nèi)數(shù)個(gè)CDN運(yùn)營商）早就自己調(diào)整初始窗口了，初始窗口20的我都見過。

作者: ynchnluiti 時(shí)間: 2011-03-24 21:33
回復(fù) 60# aaaaa5aa

通俗一點(diǎn)說就是：接收窗口增大，能發(fā)送到網(wǎng)絡(luò)中（未確認(rèn)的）的 TCP 段就更多了，當(dāng)然發(fā)送端還受用塞窗口的限制。

TCP 會按照 MSS 分段�？梢韵瓤纯聪旅娴奶�
http://72891.cn/thread-1937395-1-1.html

作者: lmarsin 時(shí)間: 2011-03-24 21:49
本帖最后由 lmarsin 于 2011-03-24 21:51 編輯

回復(fù) 60# aaaaa5aa

通常TCP段是不會或很少分片的，TCP會得到路徑上的PMTU，因此段的長度會小于PMTU。即使分片，也是就是分片而已，不會對TCP段進(jìn)行修改，只有第一個(gè)分片有TCP首部。

作者: platinum 時(shí)間: 2011-03-24 22:14

回復(fù) platinum

quick-start我是四五年前看的，不知道記得對不對，它是一個(gè)基于網(wǎng)絡(luò)系統(tǒng)的大協(xié)議 ...
hritian 發(fā)表于 2011-03-24 19:01

wscale 初始是 20 的話確實(shí)有點(diǎn)“為了目的不則手段”的感覺……

的確 Q-S 需要端對端的支持，就好像 SACK 一樣，只有一端支持是沒有效果的，且僅對高延時(shí)網(wǎng)絡(luò)下需要大吞吐量傳輸?shù)膽?yīng)用效果特別好，對需要頻繁數(shù)據(jù)交互的應(yīng)用就沒戲了（比如沒有 nagle 算法的 telnet 或利用 FTP 傳輸多個(gè)小文件的應(yīng)用）

很多國內(nèi)的 CDN 都已經(jīng)開始深入到修改 TCP 棧的領(lǐng)域，比如 ChinaCache，新浪也修改過，有些是修改初始窗口，有些還修改了 AIMD 算法，可能還有更巧的解決思路，具體不是很清楚了：）

作者: Godbach 時(shí)間: 2011-03-24 22:34
回復(fù) 64# platinum

wscale 初始是 20 的話確實(shí)有點(diǎn)“為了目的不則手段”的感覺……

白金兄，我覺得他說的是接收或者發(fā)送窗口吧，我記得 linux 下wscale最大也只能為 14

作者: hritian 時(shí)間: 2011-03-24 22:42
回復(fù) 64# platinum

不是wscale，wscale就算是該到20也沒有任何意義。

是初始的擁塞窗口大小，以前默認(rèn)是2，據(jù)說現(xiàn)在的內(nèi)核是可以配置的。

初始擁塞窗口改到20就有藍(lán)汛的份，不過cc的tcp協(xié)議棧的優(yōu)化方面，跟網(wǎng)宿和同興萬點(diǎn)比，就是小兒科。

作者: goter 時(shí)間: 2011-03-24 23:39

回復(fù) platinum

不是wscale，wscale就算是該到20也沒有任何意義。

是初始的擁塞窗口大小，以前默 ...
hritian 發(fā)表于 2011-03-24 22:42

hritian兄，ssthresh這個(gè)門閥值是不是降低后就很難再漲上去了？

作者: platinum 時(shí)間: 2011-03-25 00:10

回復(fù) platinum

白金兄，我覺得他說的是接收或者發(fā)送窗口吧，我記得 linux 下wscale最大也只能 ...
Godbach 發(fā)表于 2011-03-24 22:34

看來我理解錯(cuò)了，實(shí)在不好意思，呵呵

作者: platinum 時(shí)間: 2011-03-25 09:39

hritian兄，ssthresh這個(gè)門閥值是不是降低后就很難再漲上去了？
goter 發(fā)表于 2011-03-24 23:39

我覺得這和 AIMD 具體實(shí)現(xiàn)有關(guān)
http://wendang.baidu.com/view/1a8db91ba8114431b90dd887.html

作者: ynchnluiti 時(shí)間: 2011-03-25 10:00
回復(fù) 67# goter

首先ssthresh 的初始值很大（0x7fffffff)。進(jìn)入擁塞處理時(shí)會記錄當(dāng)前的ssthresh(用tp->prior_ssthresh, 注意有些狀態(tài)不會記錄），然后計(jì)算新的ssthresh (一般為cwnd * n: 不同擁塞算法n取值不同，就是很多文檔中說的1/2），
擁塞恢復(fù)后 ssthresh = prior_ssthresh。但2.6.20中prior_ssthresh是u16，單從變量類型看，擁塞發(fā)生后，ssthresh就不可能恢復(fù)初始值了。

實(shí)際運(yùn)行中，由于擁塞狀態(tài)轉(zhuǎn)換比較復(fù)雜，通常ssthresh會變得越來越小。

作者: ynchnluiti 時(shí)間: 2011-03-25 10:16
回復(fù) 66# hritian

看2.6.20 的源碼，cwnd 初始值是2，之后會根據(jù) RFC 3390 計(jì)算。
好像有建議改成10（mss <= 1460)

可以配置，是類似sysctl那樣的變量嗎，有人知道具體在什么地方嗎？

作者: simohayha_cu 時(shí)間: 2011-03-25 10:31
回復(fù) 71# ynchnluiti

使用iproute進(jìn)行設(shè)置，新的38內(nèi)核默認(rèn)已經(jīng) 是10了。

作者: ynchnluiti 時(shí)間: 2011-03-25 11:03
回復(fù) 72# simohayha_cu

高人啊�？催^你分析 TCP 源碼的文章，受益匪淺。在此感謝一下

簡單看了一下 2.6.38.1 中的代碼，只找到到初始接收窗口改成10了。

802 /*
803 * Convert RFC 3390 larger initial window into an equivalent number of packets.
804 * This is based on the numbers specified in RFC 5681, 3.1.
805 */
806 static inline u32 rfc3390_bytes_to_packets(const u32 smss)
807 {
808 return smss <= 1095 ? 4 : (smss > 2190 ? 2 : 3);
809 }
815 __u32 tcp_init_cwnd(struct tcp_sock *tp, struct dst_entry *dst)
816 {
817 __u32 cwnd = (dst ? dst_metric(dst, RTAX_INITCWND) : 0);
818
819 if (!cwnd)
820 cwnd = rfc3390_bytes_to_packets(tp->mss_cache);
821 return min_t(__u32, cwnd, tp->snd_cwnd_clamp);
822 }

復(fù)制代碼

/* Offer an initial receive window of 10 mss. */
#define TCP_DEFAULT_INIT_RCVWND 10

復(fù)制代碼

作者: hritian 時(shí)間: 2011-03-25 11:13
回復(fù) 73# ynchnluiti

說實(shí)話，我不贊同配置成那么高的初始窗口，至少在中國的寬帶事業(yè)進(jìn)步以前，我覺得過高的初始窗口只能是提高那么一點(diǎn)丟包率。

作者: hritian 時(shí)間: 2011-03-25 11:22
回復(fù) 69# platinum

ssthresh這個(gè)閾值，看起來是慢啟動的閾值，小于這個(gè)值的時(shí)候，慢啟動就會啟動，窗口會成指數(shù)增長、
但是進(jìn)入擁塞避免階段以后，他是隨著窗口的變化而變化的，并且的確認(rèn)網(wǎng)絡(luò)擁塞的時(shí)候給他賦值，如果網(wǎng)絡(luò)情況很好，cwnd增長到很高的值，這個(gè)時(shí)候網(wǎng)絡(luò)擁塞，賦給ssthresh就是一個(gè)很大的值。
它的一個(gè)很重要的作用是在timeout以后，擁塞窗口從1開始增加，一直慢啟動到ssthresh這個(gè)值。

作者: hritian 時(shí)間: 2011-03-25 11:28
回復(fù) 76# platinum

恩，那種情況下初始擁塞窗口變大意義就很大了。話說現(xiàn)在幾個(gè)流行的算法bic/cubic htcp c-tcp 都是以high BDP 網(wǎng)絡(luò)為研究背景的所以其實(shí)他對于中國的網(wǎng)絡(luò)意義并不是特別大，尤其是對于國內(nèi)的網(wǎng)站應(yīng)用，從我以前測試的感受的說，不需要太糾結(jié)他們。
我比較贊同的是自適應(yīng)初始擁塞窗口，實(shí)際上我現(xiàn)在的算法就是這么做的。

作者: ynchnluiti 時(shí)間: 2011-03-25 11:47
回復(fù) 74# hritian

丟包產(chǎn)生的原因之一是網(wǎng)絡(luò)擁擠，但好像也有網(wǎng)絡(luò)并不擁擠也會丟包的情況，不知各位嘉賓和觀眾對鏈路丟包方面有什么經(jīng)驗(yàn)，能否分享一下。
主要是丟包的原因到底有哪些，哪些是可以通過鏈路解決的，哪些是可以通過控制發(fā)送端 TCP 流量解決的。
這個(gè)問題看起來跟討論的主題 “TCP/IP實(shí)現(xiàn)”無關(guān)，但 TCP/IP 要解決的問題之一就是丟包的判斷及確認(rèn)丟包后的處理。了解了丟包的情況
對理解 TCP 實(shí)現(xiàn)是有幫助的。

作者: simohayha_cu 時(shí)間: 2011-03-25 11:52
本帖最后由 simohayha_cu 于 2011-03-25 11:53 編輯

.............

作者: simohayha_cu 時(shí)間: 2011-03-25 11:53
初始化擁塞窗口大小還是需要根據(jù)自己的網(wǎng)絡(luò)進(jìn)行測試調(diào)整。我們這邊測試使用窗口為7效果最好。

作者: goter 時(shí)間: 2011-03-25 12:38
但是進(jìn)入擁塞避免階段以后，他是隨著窗口的變化而變化的，并且的確認(rèn)網(wǎng)絡(luò)擁塞的時(shí)候給他賦值，如果網(wǎng)絡(luò)情況很好，cwnd增長到很高的值，這個(gè)時(shí)候網(wǎng)絡(luò)擁塞，賦給ssthresh就是一個(gè)很大的值。

擁塞避免階段會增長ssthresh嗎？？？
我的實(shí)際測試結(jié)果是ssthresh降下來后就很難再漲上去了，尤其是在模擬丟包環(huán)境里

作者: goter 時(shí)間: 2011-03-25 12:40
回復(fù) 74# hritian

丟包產(chǎn)生的原因之一是網(wǎng)絡(luò)擁擠，但好像也有網(wǎng)絡(luò)并不擁擠也會丟包的情況，不知各位嘉賓和觀眾對鏈路丟包方面有什么經(jīng)驗(yàn)，能否分享一下。
主要是丟包的原因到底有哪些，哪些是可以通過鏈路解決的，哪些是可以通過控制發(fā)送端 TCP 流量解決的。
這個(gè)問題看起來跟討論的主題 “TCP/IP實(shí)現(xiàn)”無關(guān)，但 TCP/IP 要解決的問題之一就是丟包的判斷及確認(rèn)丟包后的處理。了解了丟包的情況
對理解 TCP 實(shí)現(xiàn)是有幫助的。

這個(gè)和我前邊說的一樣，就是區(qū)分不出是鏈路丟包還是真的擁塞了。如果是前一種情況，就完全沒有必要降低窗口和門閥值

作者: aaaaa5aa 時(shí)間: 2011-03-25 12:44
本帖最后由 aaaaa5aa 于 2011-03-25 12:45 編輯

TCP/IP是網(wǎng)絡(luò)中使用的基本的通信協(xié)議，是Internet國際互聯(lián)網(wǎng)絡(luò)的基礎(chǔ)。TCP/IP協(xié)議的一個(gè)開源實(shí)現(xiàn)就是在GNU/ ...
Godbach 發(fā)表于 2011-03-20 23:49

TCP發(fā)包有個(gè)輪片機(jī)制（具體名字我記不太清楚了），就是發(fā)包的時(shí)候不是以一個(gè)包一個(gè)包發(fā)，而是以多個(gè)為一組同時(shí)發(fā)出去，
當(dāng)然這是為了提高發(fā)包速度，當(dāng)其中哪個(gè)序號的包丟失，就重新傳輸這一組包。大蝦們能不能詳細(xì)講一下這個(gè)機(jī)制的實(shí)現(xiàn)方式

（《VC++網(wǎng)絡(luò)高級編程》里講訴，但講得不詳細(xì)）

作者: ynchnluiti 時(shí)間: 2011-03-25 13:30
回復(fù) 81# goter

如果網(wǎng)絡(luò)情況很好，cwnd增長到很高的值，這個(gè)時(shí)候網(wǎng)絡(luò)擁塞，賦給ssthresh就是一個(gè)很大的值。

這里的很大不是說擁塞時(shí)還會增加ssthresh.

作者: ynchnluiti 時(shí)間: 2011-03-25 13:34

...當(dāng)其中哪個(gè)序號的包丟失，就重新傳輸這一組包。。。
aaaaa5aa 發(fā)表于 2011-03-25 12:44

這樣會造成過多重傳吧

作者: JohnBull 時(shí)間: 2011-03-25 16:34
無非是哈希表、紅黑樹、trie樹而已，有啥好討論的捏...

對了，Linux的IPv4報(bào)式socket默認(rèn)能夠接受廣播分組，是不是BUG��？？

作者: nxvnvm 時(shí)間: 2011-03-25 16:54
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: quazar 時(shí)間: 2011-03-25 18:42
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: ynchnluiti 時(shí)間: 2011-03-25 19:02
回復(fù) 88# quazar

tcp_input.c:
2178 static void tcp_ack_packets_out(struct sock *sk, struct tcp_sock *tp)
2179 {
2180 if (!tp->packets_out) {
2181 inet_csk_clear_xmit_timer(sk, ICSK_TIME_RETRANS);
2182 } else {
2183 inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS, inet_csk(sk)->icsk_rto, TCP_RTO_MAX);
2184 }
2185 }
...
2252 static int tcp_clean_rtx_queue(struct sock *sk, __s32 *seq_rtt_p)
...
2334 if (acked&FLAG_ACKED) {
2335 tcp_ack_update_rtt(sk, acked, seq_rtt);
2336 tcp_ack_packets_out(sk, tp);
2337 if (rtt_sample && !(acked & FLAG_RETRANS_DATA_ACKED))
2338 (*rtt_sample)(sk, tcp_usrtt(&tv));
2339
2340 if (icsk->icsk_ca_ops->pkts_acked)
2341 icsk->icsk_ca_ops->pkts_acked(sk, pkts_acked);
2342 }
...
2490 /* This routine deals with incoming acks, but not outgoing ones. */
2491 static int tcp_ack(struct sock *sk, struct sk_buff *skb, int flag)
....
2559 /* See if we can take anything off of the retransmit queue. */
2560 flag |= tcp_clean_rtx_queue(sk, &seq_rtt);

復(fù)制代碼

tcp_ack() -> tcp_clean_rtx_queue() : 檢查是否收到非重傳數(shù)據(jù)的 ACK -> 是則更新 RTT，RTO，然后處理重傳定時(shí)器

作者: quazar 時(shí)間: 2011-03-25 19:26
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: ynchnluiti 時(shí)間: 2011-03-25 19:57

第26章 TCP：傳輸控制協(xié)議
26.1  系統(tǒng)參數(shù)

（33）tcp_rmem，3個(gè)整數(shù)，默認(rèn)值為：4096，87380，174760，分別對應(yīng)于min，default，max，見表26-4。

表26-4  tcp_rmem的取值
tcp_rmem  描述
min  接收隊(duì)列中報(bào)文數(shù)據(jù)總長度（sock結(jié)構(gòu)的sk_rmem_alloc）的上限

min 的描述對嗎？

作者: hritian 時(shí)間: 2011-03-25 21:11
回復(fù) 82# goter

在有線網(wǎng)絡(luò)情況下，丟包絕大多數(shù)和網(wǎng)絡(luò)擁塞有關(guān)系，無線網(wǎng)絡(luò)情況會復(fù)雜很多，據(jù)說是鏈路本身的丟包率就會偏高。

作者: hritian 時(shí)間: 2011-03-25 21:13
回復(fù) 91# ynchnluiti

應(yīng)該是對的，這里應(yīng)該指的是，在內(nèi)存不夠用的時(shí)候給每個(gè)連接分配的最小讀或?qū)懢彺娲笮　?hr noshade size="2" width="100%" color="#808080"> 作者: EasyIOCP 時(shí)間: 2011-03-25 21:51
回復(fù) 89# ynchnluiti

也就是說只有兩種情況會啟動重傳定時(shí)器：
1、在發(fā)送數(shù)據(jù)之前檢查當(dāng)前的prior_packets（還未確認(rèn)的包的個(gè)數(shù)），是0，說明先前的發(fā)包都被確認(rèn)，于是啟動重傳定時(shí)器；
2、當(dāng)RTO被更新時(shí)（要么通過ACK計(jì)算出新的RTO，要么RTO因?yàn)槌瑫r(shí)而指數(shù)退避），無論接下來有沒有數(shù)據(jù)要發(fā)送，重傳定時(shí)器都被重啟
請問我的理解是否正確

作者: 嘉謨之行 時(shí)間: 2011-03-25 23:34
表示在看謝希仁的書，看完了，再看linux實(shí)現(xiàn)吧。

作者: goter 時(shí)間: 2011-03-26 00:00

回復(fù) ynchnluiti

也就是說只有兩種情況會啟動重傳定時(shí)器：
1、在發(fā)送數(shù)據(jù)之前檢查當(dāng)前的pri ...
EasyIOCP 發(fā)表于 2011-03-25 21:51

重傳定時(shí)器被設(shè)置的地方很多。重傳超時(shí)函數(shù)也會再次設(shè)置定時(shí)器。發(fā)新包（tcp_event_new_data_sent）會設(shè)置重傳定時(shí)器，收到ack（tcp_ack_probe）會更新定時(shí)器

作者: EasyIOCP 時(shí)間: 2011-03-26 08:39
回復(fù) 96# goter

所謂的“收到ack（tcp_ack_probe）會更新定時(shí)器”里的“更新”是不是就是重啟重傳定時(shí)器？

作者: goter 時(shí)間: 2011-03-26 08:46
回復(fù) 97# EasyIOCP

是重新設(shè)置超時(shí)時(shí)間

作者: ynchnluiti 時(shí)間: 2011-03-26 10:24

回復(fù) ynchnluiti

應(yīng)該是對的，這里應(yīng)該指的是，在內(nèi)存不夠用的時(shí)候給每個(gè)連接分配的最小讀或?qū)懢?...
hritian 發(fā)表于 2011-03-25 21:13

那是描述的不夠詳細(xì)，光看字面容易產(chǎn)生誤解

作者: dy145xp 時(shí)間: 2011-03-26 17:26
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: yifangyou 時(shí)間: 2011-03-26 18:51
現(xiàn)在IPV4的地址都分配完了，作者應(yīng)該跟上潮流把IPV6的IP結(jié)構(gòu)寫一下，IPV6估計(jì)馬上就開始普及了，那么書中的IP的結(jié)構(gòu)就不對了。

歡迎光臨 Chinaunix (http://72891.cn/)