Measure if there are performance benefits on TOR onion services using http/2 vs http/1.1 request/response

[citkane]

Discussion on slack is at #p2p-network

Websockets are long living network data stream connections. (RFC 6455)

It has been established that it is technically possible to connect a websocket connection to a TOR onion service. (bisq-front).

Initial response from the TOR onion community is that this is an accepted methodology that has been approved into the TOR spec.

The questions are:

• Is there any real performance benefit in using websockets?
• Can this be used to improve the Bisq network?

It is proposed that a simple test be written in isolation, the logic of which will be:

• Create a simple onion service that accepts traditional htttp and websocket connection
• Create a client that can emit to the websocket and also send http request/responses
• Create a load testing routine that sends/receives a timestamp over both websocket and req/res
• Measure the time differences for the two scenarios

I am not going to get to this any time soon, so I am putting it out here in the hope that someone can pick up on it before me.

The onion service config (torrc file) will look something like this:

HiddenServiceDir /home/michaeladmin/.tor/bob
HiddenServicePort 80 127.0.0.1:3110
HiddenServicePort 3111 127.0.0.1:3111

where HiddenServicePort 80 is the http server and HiddenServicePort 3111 is the websocket http server

[citkane]

The test has been built and live results are here:

TOR: http://flhqvb2425keopts.onion Web: http://oniontests.openpoint.ie

There are 3 scenarios:

• WebSockets vs Req-Res
• gRPC vs Req-Res
• WebSockets vs gRPC

Code for the test is here: https://github.com/citkane/onion-tests

Early results indicate an approximate 68% network performance benefit for the http/2 methods compared to http/1.1 req-res.

@mrosseel @ManfredKarrer @cbeams What may be of interest is that, since TOR stable v. 0.3.2.10 - 2018-03-03, gRPC can hop onto the TOR network via a TOR native http connect tunneled HTTP proxy. This renders thoughts of WebSockets redundant, as gRPC offers all the same benefits and more (Unary + [client,server,bidirectional] Streaming + Compression over http/2).

The above-mentioned gRPC tests are using the TOR native HTTP proxy on localhost to get onto the TOR network.

[mrosseel]

hi, nice site and results! Is this for API usage or for the P2P network?

For P2P it might be worthwhile to add the Socket approach which is currently used.

For API it depends a bit how the architecture is made but it seems that websockets/gRPC are the way to go if you want to access over tor.

[citkane]

Thanks Mike,

This test is more of a "useful general knowledge" thing which is relevant to wherever two machines communicate with each other over TOR network.

Would you give me the spec for :

the Socket approach which is currently used.

(not the Java Socket from client to proxy, but the proxied request outwards to TOR). If this is not http/1.1 I would like to reproduce it in the test.

Here is an interesting article on the anatomy of a gRPC request: https://nghttp2.org/blog/2015/03/24/proxying-grpc-with-nghttpx/

[cbeams]

Closing as inactive (per guidance in #11), but also as probably just too low-level and not really a proposal, but more of an investigation / discussion. With that said, I really appreciate your looking into the gRPC over Tor stuff, and would love to discuss it more after I present my ideas around a gRPC API for Bisq (which I plan to do as soon as possible).

[citkane]

Thanks @cbeams. I look forward to the advancement of the gRPC API and discussions to follow.