TCP重传时间间隔问题

zgx-07988

TCP重传时间间隔(RTO)计时器是在那条信令有的？是在TCP三握手还是？我想知道一次TCP连接中，TCP包第一次重传的时间间隔是多久

zgx-07988

我是指在TCP传输中，如何知道什么时候该重传长时间没收到确认的包，这个是能协商的吧？还是所有的连接都是一样的重传间隔？

爱卫生

zgx-07988 发表于 2013-10-22 17:57
我是指在TCP传输中，如何知道什么时候该重传长时间没收到确认的包，这个是能协商的吧？还是所有的连接都是一 ...

有个问题，RTO这个重传计时器为什么要在信令里边传呢？之所以要在信令里边传计时器的场景，基本都是需要在收发两边做状态的同步，例如ready
timer。但这里重传计时器控制的是重传，由发端来控制就好了，为什么收端也需要知道这个RTO并保持相同的值呢？其实应该是不需要的。

我查到的资料是RTO的值是根据RTT（round trip time）往返时间动态计算的。“确定超时重传的重要一步是测量RTT的值，根据RTT的值依据算法得到RTO的值，TCP在收到接受方回应时更新计算当时的RTT。当超时重传发生时，在重传数据的确认最后到达之前不能重新计算RTT。”

zgx-07988

爱卫生 发表于 2013-10-22 22:44
有个问题，RTO这个重传计时器为什么要在信令里边传呢？之所以要在信令里边传计时器的场景，基本都是需要在 ...

按你的说法应该是发送方决定什么时候重传的，可是我发现一个很异常的现象，发送方重传包的间隔(第一次重传)才50多毫秒，而且是一款终端访问大部分sp都会有这个情况。正常的重传(第一次)应该是1秒多才对，是吧

信令截图如下:

zgx-07988

信令采集的是IU-PS口的，用户侧对response的响应间隔是400多毫秒，属于正常情况吧？可是在这个间隔中sp方面已经重传了4次了！这个也太奇怪了吧

zgx-07988

我将我目前发现的都说下:
1.get的目的地址为10.0.0.172(cmwap)时，该终端的重传率属于较正常的水平，大约是1.4%
2.get的目的地址不为10.0.0.172时，该终端的重传率非常高，达到24.4%！
3.我们采集的数据是gb/iu-ps口的，目前看，该终端在2、3G网络都有上述的情况。
4.我挑了一些重传率比较高的用户去看，情况都是我上面描述的那种，极短时间内发起重传，很奇怪。

所以我想知道，究竟是不是真实的sp在这么短时间内发起了重传，sp是为什么要这么短时间内就重发，为什么会跟代理网关又会有关系(10.0.0.172)？

gzstu

lz有么有想过是采集的问题？重复采集了？我也遇到过类似的问题，不解。坐等爱总解惑。

碎娃

什么原因会造成服务提供商发起TCP连接重置呢？？如何解决

zgx-07988

gzstu 发表于 2013-10-29 10:49
lz有么有想过是采集的问题？重复采集了？我也遇到过类似的问题，不解。坐等爱总解惑。

不是采集的问题，在网上查到最新的技术可以做到最小间隔我50ms
摘取原文如下：
使用重新传输计时器来实现更低粒度的一种方式是，使用 TCP 的快速计时器（200 毫秒），可以将其缺省值设置为 50 毫秒，取代了原来的 200 毫秒。