Eclipse-Unix http://umlfact.berlios.de/~s_xsun/
posted on 2008-08-07 09:20 Xiaobo Sun 閱讀(9700) 評論(4) 編輯 收藏 所屬分類: TCP/IP UDP
握手階段: 序號 方向 seq ack 1 A->B 10000 0 2 B->A 20000 10000+1=10001 3 A->B 10001 20000+1=20001 解釋: 1:A向B發起連接請求,以一個隨機數初始化A的seq,這里假設為10000,此時ACK=0 2:B收到A的連接請求后,也以一個隨機數初始化B的seq,這里假設為20000,意思是:你的請求我已收到,我這方的數據流就從這個數開始。B的ACK是A的seq加1,即10000+1=10001 3:A收到B的回復后,它的seq是它的上個請求的seq加1,即10000+1=10001,意思也是:你的回復我收到了,我這方的數據流就從這個數開始。A此時的ACK是B的seq加1,即20000+1=20001 數據傳輸階段: 序號 方向 seq ack size 23 A->B 40000 70000 1514 24 B->A 70000 40000+1514-54=41460 54 25 A->B 41460 70000+54-54=70000 1514 26 B->A 70000 41460+1514-54=42920 54 解釋: 23:B接收到A發來的seq=40000,ack=70000,size=1514的數據包 24:于是B向A也發一個數據包,告訴B,你的上個包我收到了。B的seq就以它收到的數據包的ACK填充,ACK是它收到的數據包的SEQ加上數據包的大小(不包括以太網協議頭,IP頭,TCP頭),以證實B發過來的數據全收到了。 25:A在收到B發過來的ack為41460的數據包時,一看到41460,正好是它的上個數據包的seq加上包的大小,就明白,上次發送的數據包已安全到達。于是它再發一個數據包給B。這個正在發送的數據包的seq也以它收到的數據包的ACK填充,ACK就以它收到的數據包的seq(70000)加上包的size(54)填充,即ack=70000+54-54(全是頭長,沒數據項)。 26:一樣的啊 回復 更多評論
其實在握手和結束時確認號應該是對方序列號加1,傳輸數據時則是對方序列號加上對方攜帶應用層數據的長度.如果從以太網包返回來計算所加的長度,就嫌走彎路了. 另外,如果對方沒有數據過來,則自己的確認號不變,序列號為上次的序列號加上本次應用層數據發送長度. 回復 更多評論
請教一下:socket 遠程通信,為什么同一個socket 會有 多個TIME_WAIT 的狀態?如下tcp 0 0 58.248.1*1.*:80 124.65.82.194:2922 TIME_WAIT - tcp 0 0 58.248.1*1.*:80 124.65.82.194:2922 TIME_WAIT - tcp 0 0 58.248.1*1.*:80 124.65.82.194:2922 TIME_WAIT - tcp 0 0 58.248.1*1.*:80 124.65.82.194:2922 TIME_WAIT - tcp 0 0 58.248.1*1.*:80 124.65.82.194:2922 TIME_WAIT - tcp 0 0 58.248.181.4:80 124.65.82.194:2922 TIME_WAIT - tcp 0 0 58.248.181.4:80 124.65.82.194:2922 TIME_WAIT - 回復 更多評論
Hi想請教一個問題,一般產生RST報文的時候win位是否為0?或者,win=0直接就引起server端發送RST報文?我聯系方式 403921798謝謝,望給與指導 回復 更多評論
Powered by: BlogJava Copyright © Xiaobo Sun