Skip to content

Serving content over HTTPS is very slow (17x-80x slower than HTTP) #7657

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

Open
ide opened this issue Feb 28, 2023 · 4 comments
Open

Serving content over HTTPS is very slow (17x-80x slower than HTTP) #7657

ide opened this issue Feb 28, 2023 · 4 comments

Comments

@ide
Copy link

ide commented Feb 28, 2023

I am interested in using CircuitPython running on a Pico W to serve a small website over HTTPS. The main reason for HTTPS is to enable browser APIs like service workers (good for offline support) and push notifications (useful for IoT).

The good news is it's possible to serve content over HTTPS using a self-signed certificate, shown in this minimal reproducible example. It's about 15 lines of code that does real work. The not-so-good news is that it's extremely slow, taking 6 seconds to respond with a HTML file that's around 100 bytes and a 1024-bit RSA certificate (2048-bit certificates are 1.5x slower). Over plain HTTP, the same file takes about 75 to 350 milliseconds to serve. The HTTPS performance becomes a practical issue when trying to serve a website comprising multiple assets like an HTML file, favicon, web app manifest, and a service worker script since the web server is single-threaded (admittedly, I haven't explored whether HTTP pipelining helps).

This is a feature request to make HTTPS web servers viable. Realistically, HTTPS/1.1 will incur more round trips and more computation than HTTP/1.1 but if they were just 2x slower, for instance, that'd make them viable to run on a Pico W. It's also definitely possible my server is written poorly or the certificate is misconfigured.

@tannewt tannewt added performance network rp2040 Raspberry Pi RP2040 labels Feb 28, 2023
@tannewt tannewt added this to the Long term milestone Feb 28, 2023
@tannewt
Copy link
Member

tannewt commented Feb 28, 2023

Are there any other implementations (MicroPython or pico-sdk) based that are faster? The cortex m0 isn't known for its speed and imagine ssl is compute intensive.

@ams1
Copy link

ams1 commented Oct 16, 2023

Hi,

Apparently another way to improve performance of the TLS handshake is to cache it.
https://arduino-pico.readthedocs.io/en/latest/bearssl-server-secure-class.html#client-sessions-resuming-connections-fast

Is caching of the TLS handshake possible in circuitpython ssl? (mbedtls I think has this ability)

@ams1
Copy link

ams1 commented Oct 18, 2023

Hi again,

I checked and apparently mbedtls has the ability to cache the handshake (and possibly speedup), using the MBEDTLS_SSL_CACHE_C:
https://github.com/Mbed-TLS/mbedtls/blob/1bc2c9cb8b8fe4659bd94b8ebba5a4c02029b7fa/include/mbedtls/config.h#L2884-L2894

BUT, as i see MBEDTLS_SSL_CACHE_C was NOT defined in circuitpythons' mbedtls_config.h, therefore currently cache seems disabled:
https://github.com/adafruit/circuitpython/blob/main/ports/raspberrypi/mbedtls/mbedtls_config.h

Not sure why it wasn't enabled (given that it's slow), but i'll try to enable it (🐰) and see if indeed it improves performance on subsequent requests.

@tannewt
Copy link
Member

tannewt commented Oct 18, 2023

Not sure why it wasn't enabled (given that it's slow), but i'll try to enable it (🐰) and see if indeed it improves performance on subsequent requests.

Thanks for giving it a shot! We'd be happy to merge as long as it doesn't impact other stuff.

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

No branches or pull requests

3 participants