@LuckyLauncher #17 纯用爱发电！但也是爱用就用，无所谓。

@0o0O0o0O0o #13 都是权衡，一边是与时俱进，一边是近 1 / 5 的 Windows 用户。

@kokutou #12 我会用 Win7 测试过的，在 Cygwin 、MSYS2 或 Git Bash 内，是可以用的，遇到的问题也做了兼容。

@skuuhui #10 我不用 Win7 ，只是有部分用户用，详见 issue：

https://github.com/trzsz/trzsz-ssh/issues/13

https://github.com/trzsz/trzsz-ssh/issues/22

@BeautifulSoap #8 你要这么说，我也不反驳。我也就看看大家是如何做的，决定一个放弃 Win7 的时间。

@afxcn #3 新版本往往会带来新特性，有些代码写起来会优雅很多。KCP 协议是用了 go1.21 的 clear 方法，避免了原来要 copy 内存的写法。QUIC 协议是只支持 go 最新的两个版本，当前也就是 go1.21 和 go1.22 ，用 go1.20 是编译不过的了，具体我没细看。

过滤，关键词提醒

Windows Terminal + https://github.com/trzsz/trzsz-ssh

@xxxccc #36 我没有仔细去研究 sshd 的机制，实际端口转发很容易实现的。首先，本地的 tssh 与远程的 tsshd 已经建立了一个通道，只要支持多道复用（或者建立多个通道），只要将服务器的连接与本地的连接串起来，就是端口转发了。具体可以看看源码里 forward.go 的实现，服务端 https://github.com/trzsz/tsshd/blob/main/tsshd/forward.go ，客户端 https://github.com/trzsz/trzsz-ssh/blob/main/tssh/forward.go

来研究一下 ssh 吧：

https://github.com/trzsz/trzsz-ssh

https://github.com/trzsz/tsshd

@JohnSmith #24 vscode 的 ssh remote 是它自己实现的，它是调用 ssh 创建一个隧道，然后就自己在这个隧道中玩。可以让 vscode 使用 tssh --udp 来创建隧道，这个隧道本身就是走 UDP 协议的，vscode 会在这个隧道上再创建一个一个的终端的。

@chinni #22 应该是没有滚动问题的，你可以试一下。

#15 --tssh-path 写错了，应该是 --tsshd-path

@yushi17 #14 应该可以自动重连的，不过我没有测过，你可以帮忙测一测，然后告诉我结果。

有一个配置项 UdpAliveTimeout ，默认是 100 （ 秒 ），超时的话会 tsshd 会自动退出。看你需要在多久之内能重连，要改一下这个配置。

在命令行中，可以这样指定 tssh --udp --tssh-path '~/go/bin/tsshd' -oUdpAliveTimeout=2000 xxx ，这样就是 2000 秒内，可以自动重连。如果 -oUdpAliveTimeout=0 则无论多久都可以重连（理论上），但是 tsshd 会常驻在服务器上，不会自己退出。

也可以在 ~/.ssh/config 中配置，如：

Host xxx
#!! UdpMode yes
#!! TsshdPath ~/go/bin/tsshd
#!! UdpAliveTimeout 2000

@rrfeng #11 如果只是想第一跳是 UDP ，后面的是 TCP ，那现在是支持的，如：

tssh -oProxyCommand='tssh --udp -W x.x.x.x:22 A' B

这样，到 A 是用 UDP ，再到 B 是用 TCP 。

@rrfeng #11 如果 UDP 无法直通，现在还不支持哈。如果要支持，得在中间那里运行一个进程来转发，相当的复杂，但不是完全不可能。

@mightybruce tsshd 的本质是实现了 sshd 类似的功能，但是 tsshd 并没有替换 sshd ，他们是同时存在，互不影响的。

@tool2dx 再结合 udp2raw 确实会更好，但好像要求 root 启动，或者要加权限 sudo setcap cap_net_raw+ep ...

如果有需求的人多，等有空时，再看看怎么与 udp2raw 结合在一起使用。

@cheneven 主要是对标 mosh： https://github.com/mobile-shell/mosh

在网络质量不是很好的场景（ 例如，跨境的网络 ），TCP 的延迟可能会比较大（ 例如，按下键盘比较久后，屏幕上才显示输入的字母，卡顿感比较明显 ），甚至可能 TCP 中断卡死了。

使用 UDP （ 这里用了 KCP 的实现，站在巨人的肩膀上 ），可以优化 TCP 延迟大的问题，改善 ssh 后的输入体验。

有人在 tssh 的 issue 提出 https://github.com/trzsz/trzsz-ssh/issues/117 ，而碰巧我知道怎么实现，于是就造了这个轮子，顺便支持（ mosh 目前还不支持的 ）端口转发。