查看: 2192|回复: 2

学习杂谈

[复制链接]
发表于 2008-1-21 12:22:38 | 显示全部楼层 |阅读模式
1、为何握手时确认号要加1
参考资料1说到:“当SYN出现,序列码实际上是初始序列码(ISN),而第一个数据字节是ISN+1”。我认为这个解释比“因为一个SYN 将占用一个序号,所以要加 1”要好。从图1可以看到,824-826是握手过程,而827是客户端的第一个有数据的包,其序列号是ISN+1。

2、序列号和确认号都是序列号
一端确认的是对端的序列号,即要接收的下一个包的序列号,而一端序列号是随发送的应用层数据量增长的。图1中828是服务器对GET请求的确认,序列号尾数是49328,包829、830分别发送了167、1350字节的数据,所以下一个包的序列号将是49328+167+1350=50845,即包831的确认号。

3、FIN,序列号也要加1,这个就不知如何解释为好了

4、观察一个TCP会话,有时收到两个包ACK一次,有时收到一个包就ACK,不知规律何在。参考资料2说道“检查对于收到的这个数据,要不要回一个ACK。如果需要,则发送一个ACK”,但是没有说明检查什么。

5、有网友请资料2的主人推荐资料,他说“我从不保存别人的资料,我只看原代码”。由衷钦佩。如能看懂他的文章,则不但知其然,也知其所以然。

参考资料:
1、http://www.opxv.com/n55285c24.shtml
2、http://hi.baidu.com/linux%5Fkernel/blog/item/87fd95ee8e522f292df53492.html

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?CSNA会员注册

×

评分

1

查看全部评分

回复

使用道具 举报

发表于 2008-1-26 03:26:42 | 显示全部楼层
3、FIN,序列号也要加1,这个就不知如何解释为好了

为了retransmission,因为FIN也可能丢失

4、观察一个TCP会话,有时收到两个包ACK一次,有时收到一个包就ACK,不知规律何在。参考资料2说道“检查对于收到的这个数据,要不要回一个ACK。如果需要,则发送一个ACK”,但是没有说明检查什么。

涉及到nagle算法之类的,没法给你说出一般性的规律。检查所接受到的seq number是否是其想要接受的next seq number。如果不是,发送一个ack,指出seq number that receiver expects,但是不一定要立即发送。

这些东西bible,RFC上我记得都说过,你似乎都没有看过??

[ 本帖最后由 iLRainyday 于 2008-1-26 03:36 编辑 ]
回复

使用道具 举报

 楼主| 发表于 2008-1-26 22:21:54 | 显示全部楼层
初学者,学习网络分析才两个月,继续努力。请iLRainyday给个bible的下载链接。

[ 本帖最后由 oldjiang 于 2008-1-26 22:48 编辑 ]
回复

使用道具 举报

您需要登录后才可以回帖 登录 | CSNA会员注册

本版积分规则

快速回复 返回顶部 返回列表