Skip to content
This repository has been archived by the owner on Mar 17, 2024. It is now read-only.

[Feature Request]增强流量统计功能/shadowTls的回落流量需要被计入 #207

Open
e1732a364fed opened this issue Dec 22, 2022 · 5 comments

Comments

@e1732a364fed
Copy link
Owner

突然发现,在shadowTls中,如果是回落的话,目前的代码根本没有把这个通向第三服务器的流量计算到流量统计中

这是我回想起来,目前的流量统计功能不够完善,只是在最后的转发过程进行统计,前方的tls握手、协议握手等流量都没有计入

如果我们真想统计精准,必须做点什么改变。

@e1732a364fed
Copy link
Owner Author

然而仔细一想,如果握手没有成功的话,实际上这个损耗的流量不能认为是客户端损耗的流量,只损耗了服务端的流量。而握手成功后,才算双端都损耗了。

有一些复杂。不过,shadowTls的回落流量统计是必须要做的。

目前shadowTls的回落是走的自己的goroutine,没有走vs的回落系统,因此没被计算流量

@e1732a364fed e1732a364fed changed the title [Feature Request]增强流量统计功能 [Feature Request]增强流量统计功能/shadowTls的回落流量需要被计入 Dec 22, 2022
@e1732a364fed
Copy link
Owner Author

e1732a364fed commented Dec 22, 2022

其实shadowTls的回落也确实较为特殊;正常的回落都是回落到我们自己的服务器中(因为tls被剥离了,回落的一般都是明文http),而 shadowTls的回落 却是回落到 第三服务器上,而且还是加密的tls

这似乎引入了新的概念,即tls回落。

以前我们的回落都是 http层的回落,而shadowTls的回落属于更低级别的回落

@e1732a364fed
Copy link
Owner Author

同时 grpc的回落也没计入流量统计。

似乎需要一种更底层的方法,能够支持统计一切读写

@e1732a364fed
Copy link
Owner Author

e1732a364fed commented Dec 30, 2022

而且目前的统计也不精确,计算的是传送的内部承载数据的流量,而不是实际使用的流量。一般外面套tls,或者vmess加密等,都是有额外overhead的。

其实我认为科学的统计方法是都统计,承载数据消耗总量,实际消耗总流量

@e1732a364fed
Copy link
Owner Author

我觉得,可以加入一个新的流量统计模块来解决

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant