Snawoot/chunk-nordic

Multiple HTTP tunnels for one TCP conneciton

roointan opened this issue · 1 comments

roointan commented

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 commented

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.
  • 👍1