[功能请求] hop_interval增加随机性

[Smallthing]

功能描述

hop_interval目前的设定，如10秒/120秒经过抓包为固定，idle心跳包也是，设定为20时为标准的8s 此特征是否过于明显和可被中间设备观测。应该有所波动，如hop_interval设定为120秒，则可能在115-130之间随机波动，心跳包同上。 具体实施待定

这个功能的必要性

虽然实现了端口平移，但此发包时间过于规律，此特征是否过于明显和可被中间设备观测

当前可用的替代方案

No response

补充

No response

[liuxyon]

是的,应该不能有规律性.

[f4nff]

{
  "server": "45.63.93.94:123", 
  "protocol": "udp",
  "up_mbps": 30,
  "down_mbps": 50,
  "retry": -1, 
  "retry_interval": 1,
  "handshake_timeout": 30, // 握手超时，单位为秒
  "idle_timeout": 60, // 空闲超时，单位为秒。客户端会以这个值的 2/5 作为发送心跳包的间隔
  "hop_interval": 15, // 端口跳跃间隔，单位为秒。见 端口跳跃 页面

  "tun": {
    "name": "tun0",
    "timeout": 60,
    "mtu": 1500, 
    "tcp_sndbuf": "4m", 
    "tcp_rcvbuf": "4m", 
    "tcp_autotuning": true, 
    "persist": false,
  },
    "server_name": "1-courier.push.apple.com", 
    "insecure": true, 
    "recv_window_conn": 671088640, 
    "recv_window": 671088640, 
    "disable_mtu_discovery": false

}

iperf3.exe -c 45.63.93.14 -R -t 3600

tun模式下，使用iperf3测速，60s准时断开。。。

[f4nff]

经过测试，

  "tun": {
    "name": "tun0",
    "timeout": 60,
    "mtu": 1500, 
    "tcp_sndbuf": "4m", 
    "tcp_rcvbuf": "4m", 
    "tcp_autotuning": true, 
    "persist": false,
  },

60s 准时断开。。。

[f4nff]

https://github.com/apernet/hysteria/commit/7481a859b624c01bc1d4324475acfa39491b2dab

编译了这个版本， 然后执行 iperf3.exe -c 45.63.93.14 -R -t 3600 依然60s断开。。。

[haruue]

7481a85

编译了这个版本， 然后执行 iperf3.exe -c 45.63.93.14 -R -t 3600 依然60s断开。。。

提及变更和你遇到的这个问题无关。

[haruue]

@f4nff 当你遇到 60s 断开时， 客户端和服务端有相关的日志吗？ 我不认为这是 tun 的问题。

[f4nff]

我测试就是tun超时导致的， 因为iperf3测速的时候，会导致单边带宽占满，可能导致心跳超时， 心跳包应该优先。

server：

{
    "listen": ":123",
    "cert": "./my.crt",
    "key": "./my.key",
    "up_mbps": 300,
    "down_mbps": 300,
    "recv_window_conn": 671088640, 
    "recv_window_client": 671088640, 
    "max_conn_client": 65535
}

client：

{

  "server": "45.63.93.191:30000-60000", 
  "protocol": "udp",
  "up_mbps": 30,
  "down_mbps": 300,
  "retry": -1, 
  "retry_interval": 1,
  "handshake_timeout": 30, // 握手超时，单位为秒
  "idle_timeout": 60, // 空闲超时，单位为秒。客户端会以这个值的 2/5 作为发送心跳包的间隔
  "hop_interval": 15, // 端口跳跃间隔，单位为秒。见 端口跳跃 页面
"http": {
    "listen": "0.0.0.0:8080", 
    "timeout": 60 

  },
  "tun": {
    "name": "tun0",
    "timeout": 60,
    "mtu": 1500, 
    "tcp_sndbuf": "4m", 
    "tcp_rcvbuf": "4m", 
    "tcp_autotuning": true, 
    "persist": false,
  },
  "relay_tcps": [
    {
      "listen": "0.0.0.0:531", 
      "remote": "[2001:4860:4860::8888]:53", 
      "timeout": 60 
    }
  ],
   "relay_udps": [
    {
      "listen": "0.0.0.0:531", 
      "remote": "[2001:4860:4860::8888]:53",
      "timeout": 60 
    }
  ],

    "server_name": "1-courier.push.apple.com", 
    "insecure": true, 
    "recv_window_conn": 671088640, 
    "recv_window": 671088640, 
    "disable_mtu_discovery": false

}

iperf3.exe -c 45.63.93.14 -R -t 3600

iperf3 准时60s异常断开。

[f4nff]

我尝试把tun的超时改成120s，那么iperf3就是120s断开。

[haruue]

iperf3.exe -c 45.63.93.14 -R -t 3600

tun模式下，使用iperf3测速，60s准时断开。。。

@f4nff 我这边研究了下， 只有 iperf3 会超时， 正常的有数据传输的 TCP 长连接不会超时， 原因和 iperf3 的工作流程有关。

iperf3 在进行 TCP 测速时， 会先与服务器建立一个 TCP 连接用于传输测试参数， 也就是所谓的「控制连接」， 而实际上用于测试的数据则是通过另外建立的 TCP 连接来发送的。 iperf3(1) 对这个流程有详细的介绍。

在 iperf3 进行 TCP 测速的过程中， 上述的「控制连接」是没有任何数据传输的。 因此， 这个「控制连接」会因为没有活跃的通信而超时， 从而被 hysteria 断开， 导致 iperf3 终止测速流程。

[f4nff]

所以hysteria判断没有活跃的通信的逻辑是不对的， 不能以没有数据返回就判断为 非活跃通信 单边通信也是 活跃通信。

[f4nff]

iperf3 是单边发包，另一方是没数据包返回的， tcp本身是被允许的。

[f4nff]

而且不止iperf3我碰到这类情形， 我在跑http单线程下载的时候，也遇到异常断开。

[haruue]

iperf3 是单边发包，另一方是没数据包返回的， tcp本身是被允许的。

@f4nff

你认真看我的回复， 被关闭的那条 TCP 连接是「没有任何数据发送」而超时的， 不是单边， 而是两边都没有任何数据发送。

只要任何一个方向有一点数据传输的 TCP 连接， 就不会被超时关闭。

[f4nff]

iperf3.exe -c 45.63.93.14 -R -t 3600

返回一直是有数据包的，只不过数据包的所有数据都是00字节， 你自己抓包看看。

[haruue]

iperf3.exe -c 45.63.93.14 -R -t 3600

返回一直是有数据包的，只不过数据包的所有数据都是00字节， 你自己抓包看看。

@f4nff

我说了 iperf3 开了两条 TCP 连接， 一条在测速的过程中是没有数据发送的， 另一条是有数据发送的， 被关闭的是那条没数据传输的 TCP 连接。 你可以看看你抓的包， 这两条连接连本地端口号都不一样。

[f4nff]

但是这种逻辑也不对呀， 影响了正常的iperf3的业务。

[f4nff]

正常的隧道不应该会导致iperf3的业务中断的。

[haruue]

正常的隧道不应该会导致iperf3的业务中断的。

@f4nff

如果你路由器的 NAT 对 TCP 连接的超时也只有 60s ， 那也一样会影响 iperf3 这种开着 TCP 连接不传任何数据的业务的。

[f4nff]

行吧，那我吧tun超时改成7200了。

[f4nff]

# cat /proc/sys/net/ipv4/tcp_keepalive_time   7200    
# cat /proc/sys/net/ipv4/tcp_keepalive_intvl   75    
# cat /proc/sys/net/ipv4/tcp_keepalive_probes   9

设置为60确实不合理。

[showgood163]

请问这个问题有进展吗？