Closed Jinnrry closed 1 year ago
ss是无状态TCP协议,所以不具备心跳机制。
ss是无状态TCP协议,所以不具备心跳机制。
这样的话是不是意味着ss不适用于反向代理呢,在这个场景下,内网于公网断联了不会自动恢复呀。
在普通代理场景下无状态确实没问题,单次连接断了客户端会重试,但是反向代理中不就出问题了
ss是无状态TCP协议,所以不具备心跳机制。
细想了一下,ss协议确实是无状态的,但是tcp是长连接,tcp连接应该有心跳呀。tcp连接如果断了,那就应该尝试重连吧。
ss是无状态TCP协议,所以不具备心跳机制。
细想了一下,ss协议确实是无状态的,但是tcp是长连接,tcp连接应该有心跳呀。tcp连接如果断了,那就应该尝试重连吧。
TCP/UDP是工作在简化的OSI模型(互联网协议套件,Internet Protocol Suite)四层中的第三层——传输层,只负责传输,不负责应用功能。TCP是可靠传输,UDP是非可靠传输。 TCP中的握手状态可是非常明显的特征,但这个状态和心跳包是2个回事。 心跳包(HTTP/HTTPS/SSH等)一般是工作在第四层——应用层,是该层的功能实现,和传输无关。 HTTP/HTTPS等就是TCP协议在应用层的最佳实现。 GFW可以在握手的第2步(ACK标识)就能嗅探并掐断连接(发送RST标识),正因为SS使用了无状态TCP,难以发现,才会被GFW强力针对干扰和探测。 先去学习一下网络的基础吧。 https://zh.wikipedia.org/wiki/%E4%BC%A0%E8%BE%93%E6%8E%A7%E5%88%B6%E5%8D%8F%E8%AE%AE
ss是无状态TCP协议,所以不具备心跳机制。
细想了一下,ss协议确实是无状态的,但是tcp是长连接,tcp连接应该有心跳呀。tcp连接如果断了,那就应该尝试重连吧。
TCP/UDP是工作在简化的OSI模型(互联网协议套件,Internet Protocol Suite)四层中的第三层——传输层,只负责传输,不负责应用功能。TCP是可靠传输,UDP是非可靠传输。 TCP中的握手状态可是非常明显的特征,但这个状态和心跳包是2个回事。 心跳包(HTTP/HTTPS/SSH等)一般是工作在第四层——应用层,是该层的功能实现,和传输无关。 HTTP/HTTPS等就是TCP协议在应用层的最佳实现。 GFW可以在握手的第2步(ACK标识)就能嗅探并掐断连接(发送RST标识),正因为SS使用了无状态TCP,难以发现,才会被GFW强力针对干扰和探测。 先去学习一下网络的基础吧。 https://zh.wikipedia.org/wiki/%E4%BC%A0%E8%BE%93%E6%8E%A7%E5%88%B6%E5%8D%8F%E8%AE%AE
我并不想和你讨论TCP心跳包的问题。我想表达的是使用ss协议做反向代理的情况下,内网公网服务器断连并不会自动恢复。我说的心跳是业务层面的,我没说TCP里面的心跳包。
公网与内网服务器断连,服务不可用,此时不进行重连,是这个问题
ss是无状态TCP协议,所以不具备心跳机制。
细想了一下,ss协议确实是无状态的,但是tcp是长连接,tcp连接应该有心跳呀。tcp连接如果断了,那就应该尝试重连吧。
TCP/UDP是工作在简化的OSI模型(互联网协议套件,Internet Protocol Suite)四层中的第三层——传输层,只负责传输,不负责应用功能。TCP是可靠传输,UDP是非可靠传输。 TCP中的握手状态可是非常明显的特征,但这个状态和心跳包是2个回事。 心跳包(HTTP/HTTPS/SSH等)一般是工作在第四层——应用层,是该层的功能实现,和传输无关。 HTTP/HTTPS等就是TCP协议在应用层的最佳实现。 GFW可以在握手的第2步(ACK标识)就能嗅探并掐断连接(发送RST标识),正因为SS使用了无状态TCP,难以发现,才会被GFW强力针对干扰和探测。 先去学习一下网络的基础吧。 https://zh.wikipedia.org/wiki/%E4%BC%A0%E8%BE%93%E6%8E%A7%E5%88%B6%E5%8D%8F%E8%AE%AE
我并不想和你讨论TCP心跳包的问题。我想表达的是使用ss协议做反向代理的情况下,内网公网服务器断连并不会自动恢复。我说的心跳是业务层面的,我没说TCP里面的心跳包。
公网与内网服务器断连,服务不可用,此时不进行重连,是这个问题
请先理解TCP的握手过程! 请先理解TCP的握手过程! 请先理解TCP的握手过程! 关键字:TCP三次握手 既然是无状态TCP,意味着没有完成一次完整的TCP握手。未能完全握手,就不能实现状态监听。没有监听就不能发现丢包,从而没有发起重连。 心跳包是应用层实现的,TCP可没有心跳包这个概念。TCP只有状态,而这个状态和握手有关。 简单点说一下SS协议的实现: SS协议在TCP握手的第二步,客户端就开始发送往服务端正式数据包,服务端也是知道第二步发过来的TCP包是正式数据包,从而执行转发并请求目标服务器,收到目标服务器返回的数据后就直接发TCP包会客户端,而客户端也是知道这个数据包是正式数据包,从而开始解释数据包。 从一开始就没有完整握手的TCP连接,根本不可能实现丢包重传或发保持连接的数据包。 只要是基于SS协议的,你用来普通翻墙当然没有问题,但用来反向代理,一旦TCP连接没有接收到保持连接的数据包而超时后,就会丢弃连接。 打算普及一下基础理论,却遇上钻牛角尖的小白。连基础理论都没有理解,就在硬拗。
就如V2EX上某些土豪小白,买了BWH的年付CN2-GIA用onekey script部署,谁不知BWH等热门商家和其IP段已经被GFW特殊关注。被封之后换了几次IP之后,就在骂GFW杀疯。GFW当然该骂,但应该反省一下,正因为翻墙被搞得低门槛之后,GFW才会大杀特杀。
不再回复此issues,浪费时间。
我真是无语,我需要你给我在这扯这些么。我反馈的是“反向代理场景下,内网公网断连后无法恢复”。我仅仅是想反馈这个问题,至于是协议漏洞,还是程序bug,作为用户来说,我不在乎,我仅仅是反馈,断连后服务就不可用了。你跟我扯这么多TCP干嘛啊。另外,我寻思你也不是这个项目的Contributor啊,你说一堆什么玩意呀
我真是无语,我需要你给我在这扯这些么。我反馈的是“反向代理场景下,内网公网断连后无法恢复”。我仅仅是想反馈这个问题,至于是协议漏洞,还是程序bug,作为用户来说,我不在乎,我仅仅是反馈,断连后服务就不可用了。你跟我扯这么多TCP干嘛啊。另外,我寻思你也不是这个项目的Contributor啊,你说一堆什么玩意呀
协议实现天然不支持丢包恢复,本来就是无效反馈,你看不懂还怪人家扯 TCP,你才是莫名其妙吧……
版本:xray 1.6.1
使用ss2022协议做反向代理的时候,一旦内网服务器与公网服务器断连,就无法恢复连接。
复现方法:
1、日志级别设置为debug 2、开启公网服务器 3、开启内网服务器,此时在公网和内网服务器日志中能够看到均正常连接 4、关闭公网服务器。此时无论等多久,都不能看到内网服务器发起重连的日志
造成问题:
反向代理使用过程中,一旦由于网络抖动,公网server与内网server连接断开,内网就一直不会尝试重连,从而导致反向代理永久不可用。想要恢复就只能手动重启内网服务器