f4nff
f4nff
目前负载均衡不怎么好用， 如果主线路，备用线路分别有多个， 就没法设置，相对来说，还是nginx负载均衡的格式好用一些。 ``` upstream tomcats { server 192.168.0.100:8080 weight=2 max_fails=3 fail_timeout=15; server 192.168.0.101:8080 weight=3; server 192.168.0.102:8080 backup; } ```
udp 不通
``` gost -L=relay+wss://:8811 gost -L=:1080 -F=relay+wss://127.0.0.1:8811 ``` 通过socks5连接1080 ， udp测试不通。
### 功能描述 `iperf3 -c de2sk.72mb.xyz -R -u -b 300M` 测速单线程跑300M没啥问题， 为什么tcp单线程下载最高也就是100MBps 起码也得250Mbps左右吧？ ### 这个功能的必要性 按道理说，iperf3 测速udp单线程300MBps， hysteria 开销那么大，性能吃掉小二百兆的开销？ ### 当前可用的替代方案 _No response_ ### 补充 _No response_
`./resize-image.sh openwrt-21.02.2-x86-64-generic-ext4-combined-efi.img.gz 8G` After testing, it has been invalid.
添加特殊反向中转代理，
使用场景， ``` 服务器A 10.10.10.1（内网） 服务器B 2.2.2.2（外网） 客户端C 10.10.2.1（内网） ``` **客户端C** 通过 **服务器B**连接**服务器A**， 使用客户端A作为代理服务器，服务器B作为中转， 服务器A不可以监听本地端口，没有监听本地端口的权限，只能发起连接。 那么就不能使用反向端口转发， ``` gostA -F=mws://2.2.2.2:80?key=jddsf332 gostB -L=mws://:80 gostC -L=socks5://:1080 -F=mws://2.2.2.2:80?key=jddsf332 ``` 这样c就可以通过B连接A，通过A访问请求。 唯一不同的是gostA **不能监听本地端口**，但是可以发起请求，添加key辨别。
`tcp6 0 85400 51.255.119.117:80 15.5.28.48:47232 CLOSE_WAIT` ``` root@26029 ~/caddy # ./caddy -v v2.7.5 h1:HoysvZkLcN2xJExEepaFHK92Qgs7xAiCFydN5x5Hs6Q= ``` ``` http://dl.own.dev { log default { output discard format json } encode gzip # gzip压缩...
### 功能描述  ### 这个功能的必要性 之前没有发现，现在很多错误。 golang 1.20编译的。 ### 当前可用的替代方案 _No response_ ### 补充 _No response_
### 功能描述 现在就只支持监听一个端口, 如果使用iptables转发会多一次转发,性能会降低. ### 这个功能的必要性 多端口监听之后, 使用端口跳跃,降低被封,被qos的概率. ### 当前可用的替代方案 _No response_ ### 补充 _No response_
### 功能描述 使用"protocol": "faketcp", 服务端会出现很多close-wait ### 这个功能的必要性 应该是关闭不对，导致内存泄漏。 ### 当前可用的替代方案 _No response_ ### 补充 _No response_
``` selector: strategy: fifo maxFails: 2 failTimeout: 30s ``` 这是目前的负载均衡,根据发起请求是否死亡作为链路的评定标准,但是如果一个链路出现丢包的时候, 体验会急剧下降,这时候需要转移节点.  目前的负载均衡是无法对这种链路进行判断的. 以grpc协议为例,应该加一个最大延时的判断基准,以grpc ping的延时作为基准, ``` selector: strategy: fifo maxFails: 2 failTimeout: 30s pingtime: 250ms ``` 当ping的延时大于预设的250ms标记为节点死亡. 这样可以最大程度的反馈出当前链路的质量,并且快速的转移到优质备用节点.