免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: platinum
打印 上一主题 下一主题

应如何正确计算 TCP 序号? [复制链接]

论坛徽章:
0
21 [报告]
发表于 2008-10-30 17:00 |只看该作者
原帖由 platinum 于 2008-10-30 16:35 发表

可是我不知道应该怎么处理异常数据包
比如这个过来的数据包本身序号是错的,我如果正常计算并维护,有可能整个都错了
也就是说,我需要分析出来哪些包是错误的,从而不再计算
因为在 session 中途可能还要 ...


下午一直忙,Au_Hank的回复就是我说的意思,必须如此,否则报文总会被一方丢掉

你在通信过程中还可能继续修改,差值还要变,这没关系,完成了一次交互,这个值就可以变更了,把新的差值叠加上去,比如原来-2,这次+5,叠加之后就是+3

我说的proxy不是这个意思,之前和诸位讨论的都是关于seq,ack的计算,这也存在proxy,就如同syn_proxy,我上面的描述基本上就是syn_proxy的方法

而我原本所说的proxy不是这个意思,我的意思是完全有你的设备去与目的主机建立连接,然后把内容在发回源主机,但是这样的话,在桥下比较困难,相当于透明proxy

但是这样就避免了随便修改报文带来的途中出错的问题。

主要思路就是你的设备将真实的一对TCP连接(from Host A to Host B)替换为两对连接(from A to your BOX, from your BOX to B)。

也挺麻烦的。。。

论坛徽章:
0
22 [报告]
发表于 2008-10-30 17:25 |只看该作者
大体明白了!
如果 seq 变了,那么 win 是不是也要跟着变呢?这个计算起来岂不是更复杂?

论坛徽章:
0
23 [报告]
发表于 2008-10-30 17:27 |只看该作者
原帖由 platinum 于 2008-10-30 17:25 发表
大体明白了!
如果 seq 变了,那么 win 是不是也要跟着变呢?这个计算起来岂不是更复杂?


我目前没仔细想,给你引用一段吧

The TCP Window field advertises how many bytes of data the remote peer is
allowed to send before a new advertisement is made. Theoretically, the
maximum transfer rate that can be achieved by TCP is limited to:
Maximum Transfer Rate = Window / RTT
This means that, under ideal network conditions (e.g., no packet loss), the
Window in use should be at least:
Window = 2 * Bandwidth * Delay
Using a larger Window than that resulting from the previous equation will not
provide any improvements in terms of performance.
In practice, selection of the most convenient Window size may also depend on
number of other parameters, such as: packet loss rate, loss recovery mechanisms in
use, etc.
An aspect of the TCP Window that is usually overlooked is the security
implications of its size. Increasing the TCP window increases the sequence
number space of the sequence numbers that will be considered “valid”. Thus, use
of unnecessarily large TCP Window sizes increases TCP’s vulnerability to
spoofing attacks unnecessarily.
In those scenarios in which the network conditions are known and/or can be easily
predicted, it is recommended that the TCP Window is never set to a value larger
than that resulting from the equations above. Additionally, the nature of the
application running over TCP should be considered when tuning the TCP
window. As an example, an H.245 signaling application certainly does not have
high requirements on throughput, and thus a window size of around 4 KBytes will
usually fulfill its needs, while keeping TCP’s resistance to off-path spoofing
attacks at a decent level. Some rough measurements seem to indicate that a TCP
window of 4Kbytes is common practice for the TCP connections of routers
servicing applications such as BGP.
In principle, a possible approach to avoid having administrators manually set the
TCP window would be to implement an automatic buffer tuning mechanism, such
as that described in [Heffner, 2002]. However, as discussed in Section 8.2.2 of
this document these mechanisms can be exploited to perform other types of
attacks.


理论上说,window不需要改

不过还有更严格的环境,不允许window滑动,必须精确吻合的,那就麻烦了

建议你先别顾虑这么多,试试之前讨论的吧。

论坛徽章:
0
24 [报告]
发表于 2008-10-30 17:32 |只看该作者
多谢 Jobs!
另外还有一个实在不知道怎么处理
如果遇到了重传包,而重传的恰好是需要修改 payload 内容的(长度会变),那么这时我怎么知道这个包该不该处理,seqdiff 该不该累加呢?

论坛徽章:
0
25 [报告]
发表于 2008-10-30 17:40 |只看该作者
原帖由 platinum 于 2008-10-30 17:32 发表
多谢 Jobs!
另外还有一个实在不知道怎么处理
如果遇到了重传包,而重传的恰好是需要修改 payload 内容的(长度会变),那么这时我怎么知道这个包该不该处理,seqdiff 该不该累加呢?


重传意味着跟上一个包内容完全一样,对吧?

所以你就应该保持你的所有参数

举例说:
packet 1 : seq=1000, ack=2000, len=500, next seq=1500, 修改后seq=1001, ack=2000, diff_len=+1, len=501
re-pak 1 : seq=1000, ack=2000, len=500, next seq=1500, 修改后seq=1001, ack=2000, diff_len=+1, len=501

如果是重传,seq肯定不变啊,你系统里至少要保留next seq,pre seq

论坛徽章:
0
26 [报告]
发表于 2008-10-30 18:14 |只看该作者
原帖由 Jobs.AE@ 于 2008-10-30 17:40 发表


重传意味着跟上一个包内容完全一样,对吧?

所以你就应该保持你的所有参数

举例说:
packet 1 : seq=1000, ack=2000, len=500, next seq=1500, 修改后seq=1001, ack=2000, diff_len=+1, len=501
re ...

经过实际抓包测试,发现不一定必须是 “上一个”
比如我收到的数据包是 1、2、3、4、5、6、7,其中第 5 个没有收到
那么,A -> B 的时候,B 有可能在收到 7 以后仍然收到 5 的重传,此时 B 要放弃 6、7 继续从 5 接收,这个时候规律就全打乱了

论坛徽章:
0
27 [报告]
发表于 2008-10-30 18:23 |只看该作者
原帖由 platinum 于 2008-10-30 18:14 发表

经过实际抓包测试,发现不一定必须是 “上一个”
比如我收到的数据包是 1、2、3、4、5、6、7,其中第 5 个没有收到
那么,A -> B 的时候,B 有可能在收到 7 以后仍然收到 5 的重传,此时 B 要放弃 6、7 继续 ...


嗯,我忽略了乱序,确实是个问题
如果乱序了,这个路径基本就废掉了

要不兄弟你先试试seq的问题?
如果确实是因为这个造成的丢包,咱们再想怎么改吧!

论坛徽章:
0
28 [报告]
发表于 2008-10-30 18:26 |只看该作者
原帖由 Jobs.AE@ 于 2008-10-30 18:23 发表


嗯,我忽略了乱序,确实是个问题
如果乱序了,这个路径基本就废掉了

要不兄弟你先试试seq的问题?
如果确实是因为这个造成的丢包,咱们再想怎么改吧!

还是谢谢兆博了!我再仔细确定一下问题的原因,再考虑对策不迟!
另外,你拍的很不错,洗了很多张

论坛徽章:
0
29 [报告]
发表于 2008-10-30 18:54 |只看该作者
原帖由 platinum 于 2008-10-30 18:26 发表

还是谢谢兆博了!我再仔细确定一下问题的原因,再考虑对策不迟!
另外,你拍的很不错,洗了很多张


客气了!

论坛徽章:
0
30 [报告]
发表于 2008-10-30 19:01 |只看该作者
窗口是发送包方指示对方所我还可以接受多少数据,你插入或者删除数据对发送方没有影响,所以不用修改窗口。

麻烦的是,如果你插入太多数据,超过接收方的窗口怎么办?

还有包丢失和乱序的还真麻烦,下面有一个方法不知道是否可行:
每次做数据变动,都记住此时原始的ORI_SEQ,对应数据变动的字节数N

如果下次收到的SEQ<ORI_SEQ,则是代表重传或者乱序的包,而且是发生在数据变动之前的重传或者乱序的包,所以让他们直接通过,不需要修改。

如果下次收到的SEQ>=ORI_SEQ,则是发生在数据变动之后的包,需要修改SEQ,修改方法参照我上面说的那样。

你可能有多次的数据修改,这样一来你需要记住多个的 (ORI_SEQ,N)偶对。如何消除旧的(ORI_SEQ,N)偶对是个问题。我觉得原则是已经被ACK过的ORI_SEQ可以被删除,但是如何知道ACK被另外一端收到了是个问题(因为ACK可能被你的设备收到了,但是RELAY给接收方的时候丢失了)。

还有一个难办的是selective ack,要崩溃了。我觉得还不如在用户空间socket转接算了,简单多了,但是性能差了。

[ 本帖最后由 Au_Hank 于 2008-10-30 19:08 编辑 ]
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP