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

Multiple HTTP tunnels for one TCP conneciton #6

Open
roointan opened this issue Feb 8, 2023 · 1 comment
Open

Multiple HTTP tunnels for one TCP conneciton #6

roointan opened this issue Feb 8, 2023 · 1 comment

Comments

@roointan
Copy link

roointan commented Feb 8, 2023

Hello! and thank you for your awesome project.

I have a question, is there an easy way to use multiple HTTP tunnels for one TCP connection?
The project works for me, but only about 2% of my bandwidth is allowed to pass through.
I thought using multiple HTTP tunnels could help improve it.
Can you think of an out of the box solution to like load balance it like that?
Or is it easy for you to add an option to support multiple Downstream/Upstream(s) instead of just one for each?
Maybe you could help me figure out how to do it myself, so I can contribute and add it?

Thanks again!

@Snawoot
Copy link
Owner

Snawoot commented Feb 8, 2023

Hi! Thank you!

I have a question, is there an easy way to use multiple HTTP tunnels for one TCP connection?

Possible, but not easy.

I thought using multiple HTTP tunnels could help improve it.

That's right, there are some solutions around like hydra protocol in HotSpotShield which try to leverage multiple connections like that. Patent: https://patents.google.com/patent/US10469410B2/en?assignee=anchorfree&oq=anchorfree That's actually a good read, because it reveals some details how it may be implemented.

Challenging part is to split stream between other streams in such way frames will arrive at the other end with minimal reordering. Otherwise transfer will be stalled until earliest frame arrived on the other side and aggregated speed will be actually lower than a single connection. It's hard to know in advance which underlying connection TCP connection should be used for next "frame" of payload. Implementation in patent I mentioned somehow controls state of sending buffers to achieve best result.

I think another approach to this problem could be something like fountain coding of frames, so it wouldn't matter in which order parts of some frame were received: we just need enough parts to recover frame on the other side and proceed to next portion of data. But as far as I know many successful implementations of erasure codes are also encumbered by patents.

And finally, another option would be to not have problem with TCP flow control in the first place: just use some UDP-based protocol for transport. Think about QUIC for example.

Can you think of an out of the box solution to like load balance it like that?
Or is it easy for you to add an option to support multiple Downstream/Upstream(s) instead of just one for each?

I tried it in other projects, but haven't achieved anything substantial:

Maybe you could help me figure out how to do it myself, so I can contribute and add it?

  1. I don't know which approach will work well.
  2. It seems subject in question is so big, much bigger than that simple connection wrapper I made. Likely it's worth to handle it as a separate project: existing code has no value to help solve that problem.

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