Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding tcp-brutal Support to Xray, for [VLESS-gRPC-uTLS-REALITY + tcp-brutal] #2735

Closed
KoriIku opened this issue Nov 18, 2023 · 4 comments
Closed

Comments

@KoriIku
Copy link

KoriIku commented Nov 18, 2023

I am endeavoring to add server-side support for tcp-brutal to xray-core, but I've encountered an issue that eludes resolution.

Let me provide some context and detail my objectives:

tcp-brutal is the congestion control algorithm from hysteria2, affording any protocol some of hysteria2's advantages. Its usage necessitates three conditions: the installation of a Linux kernel module, utilization exclusively on a protocol with multiplexing employing a single connection, and active algorithm specification with rate configuration by the application.

Key Point: Since downstream traffic dominates in most scenarios, enabling brutal on the server side yields immediate and impactful performance gains, without the need for client adaptation.

Naturally, my first inclination was toward "VLESS-gRPC-uTLS-REALITY + tcp-brutal" Consider the exquisite synergy: reality for obfuscation, grpc for multiplexing and low latency, vless for lightweight simplicity, and tcp-brutal (hysteria) for bandwidth enhancement.

I promptly experimented with the "VLESS-gRPC-uTLS-REALITY + brutal" combination, and it proved not only feasible but remarkably effective. Consequently, I crafted this code(#2734), aspiring to bring this exciting solution to the community. (For a quick validation, I directly edited the tcp-brutal source code to set the desired rate for personal use. In practical scenarios, using setsockopt as instructed in the tcp-brutal repository is essential, and this is where I encountered the issue.)

Herein lies the challenge: encountering an error when invoking the syscall.Setsockopt interface. Despite adding prints in the brutal kernel module, I cannot observe any output, suggesting that this system call doesn't enter the brutal code.

Lacking familiarity with setsockopt and Go, I seek the community's assistance in diagnosing this issue.

Testing Approach:
Follow the tcp-brutal instructions to install the brutal module. Then, create a simple configuration, adding the following to the inbound

streamSettings:{
  "sockopt": {
    "tcpcongestion": "bbr",
    "rate": 100000000,
    "cwnd_gain": 20
  }
}

(Please note that I've only provided configurations related to sockopt here. In actual usage, configurations for gRPC are also necessary. However, if it's solely for reproducing my issue, adding these is sufficient.)

This should result in an error: "failed to set brutal config, protocol not supported."

Summarizing my issue: Why did the setsockopt operation fail?

My current progress: I compared the Python sample program for tcp-brutal (https:/apernet/tcp-brutal/blob/bbd040546d697bddddb0a0760df76a781edef1b4/example/server.py#L20), and the structure of the configuration should be consistent. As mentioned earlier, I attempted to add prints in the brutal module, but no prints were observed when setsockopt was called.

For the configuration details of tcp-brutal, you can refer to this link: https:/apernet/tcp-brutal#for-developers

The above content was translated using a translator, so I'm not entirely sure if there are any errors. Please clarify if you have any questions.

@xqdoo00o
Copy link

You need SetsockoptString after server accept tcp conn, means you need setsockopt on each transport type.
I write the simliar code as you commited 1 week ago, also the same error.

@KoriIku
Copy link
Author

KoriIku commented Nov 18, 2023

You need SetsockoptString after server accept tcp conn, means you need setsockopt on each transport type. I write the simliar code as you commited 1 week ago, also the same error.

Thank you for pointing out the crucial issue. I made a very basic mistake, and I need to rewrite all the code to achieve the goal. Sadly, I'm not familiar with the architecture of xray at all. Do you have any insights? 😢

@xqdoo00o
Copy link

You need SetsockoptString after server accept tcp conn, means you need setsockopt on each transport type. I write the simliar code as you commited 1 week ago, also the same error.

Thank you for pointing out the crucial issue. I made a very basic mistake, and I need to rewrite all the code to achieve the goal. Sadly, I'm not familiar with the architecture of xray at all. Do you have any insights? 😢

I give up writing code in each transport hub.go, but set brutal module param in sockopt_linux.go, check the closed brutal pr, and xray commit, the only problem is required root permission.

If you want get the worked code of transport/grpc hub.go, just check hysteria telegram group the tech discussion 1 weeks ago.

@KoriIku
Copy link
Author

KoriIku commented Nov 19, 2023

You need SetsockoptString after server accept tcp conn, means you need setsockopt on each transport type. I write the simliar code as you commited 1 week ago, also the same error.

Thank you for pointing out the crucial issue. I made a very basic mistake, and I need to rewrite all the code to achieve the goal. Sadly, I'm not familiar with the architecture of xray at all. Do you have any insights? 😢

I give up writing code in each transport hub.go, but set brutal module param in sockopt_linux.go, check the closed brutal pr, and xray commit, the only problem is required root permission.

If you want get the worked code of transport/grpc hub.go, just check hysteria telegram group the tech discussion 1 weeks ago.

Thank you very much! I believe our use cases align, and I will proceed with your proposed solution.

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

No branches or pull requests

2 participants