免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 18106 | 回复: 8
打印 上一主题 下一主题

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

论坛徽章:
0
1 [报告]
发表于 2008-10-30 11:38 |显示全部楼层
你修改了payload以及所有相关len后,影响到的是下一个报文的sequence number,而不是当前的。

所以理论上讲,第一个报文你不需要修改seq,而后续的,由于host不知道你修改了payload,使用的seq可能就与正确的不符了,你需要进行差值计算。

如果方便你最好把通信的全过程抓包记录下来,报文发给我看看,修改前、修改后的。

滑动窗口的问题我想想再回答你。。。

论坛徽章:
0
2 [报告]
发表于 2008-10-30 11:40 |显示全部楼层
BTW:根据一些较严格的安全设备标准,seq和window这些参数都是需要审核的

可能你的局域网环境没有穿越类似设备,所以无法reproduce

论坛徽章:
0
3 [报告]
发表于 2008-10-30 11:58 |显示全部楼层
1、在系统中维护这个 TCP 连接的序号,重新计算,但应该怎么计算?
3、如果 TCP 连接正常,这个规律还相对简单,如果遇到丢包、重传、乱序、复制包怎么办?如何判断?
4、如果改变了 seq,那么 ack_seq 肯定也要改的,win 呢?是否也需要一起修改?
5、上面的解决思路是否正确?是否有什么好方法可以解决这个问题呢?


问题1:2楼解答了,再说一下方法,链接建立的第一个报文的seq相对为1,下一个报文(同方向)的seq等于1+len(第一个报文payload长度),以此类推
问题3:丢包就丢呗,跟你无关;重传,重新计算;乱序,与你无关;复制,所有字段保持一致;
问题4:同一个报文的seq与ack_seq是互为反方向的,按照2楼及问题1的解答处理;
问题5:如果不想处理复杂的协议校验修改,建议使用proxy模式。

粗粗一想,可能有不妥之处,你再斟酌啊,呵呵~~

论坛徽章:
0
4 [报告]
发表于 2008-10-30 12:02 |显示全部楼层
原帖由 Godbach 于 2008-10-30 11:55 发表


按照你的解释,如果LZ修改完数据包,但不修改序列号的好,应该是可以到达请求主机,而且请求主机的回应包也会发送的HOST上。

而不是LZ的那种情况,数据包在转发过程中就被丢弃了。


转发过程中,某些设备就回去校验你的seq对不对,不用等到host

我又想了一下,如果这样改了,host对收到的回应报文有可能丢弃,因为ack与他发送的seq不符了

似乎这个需求在不做proxy的情况下有点不可实现,违反了太多审查规定了。

论坛徽章:
0
5 [报告]
发表于 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
6 [报告]
发表于 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
7 [报告]
发表于 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
8 [报告]
发表于 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
9 [报告]
发表于 2008-10-30 18:54 |显示全部楼层
原帖由 platinum 于 2008-10-30 18:26 发表

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


客气了!
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

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

清除 Cookies - ChinaUnix - Archiver - WAP - TOP