search

quictls / openssl

TLS/SSL and crypto library with QUIC APIs
https://quictls.github.io/openssl
Apache License 2.0
366 stars 50 forks source link

Improve QUIC defragmentation of TLS packets. #158

Open bwelling opened 4 months ago

bwelling commented 4 months ago

This avoids excessive persistent memory usage associated with every QUIC connection, by avoiding a large (21k) preallocation of a buffer used for defragmentation of TLS packets.

Instead of preallocating space for all TLS data, this only stores TLS fragments that cannot be fully assembled on the connection.

bwelling commented 4 months ago

This addresses the issue in #157.

As far as I can tell, there isn't any real testing of calling SSL_provide_quic_data with differently framed TLS fragments, and I don't know how to write all of these tests from scratch.

tmshort commented 3 weeks ago

When 3.1.6 is ready, this should be rebased... but we can always pull the commit over.

wbl commented 4 days ago

I've added nibanks as a reviewer. Let's figure out how to release this on 3.1.7 after we finish making it (bump a version somehow with a suffix?) or agree it's good for 3.1.8/whatever happens next. Still need input from nibanks on if VLA will work for him: suspect answer is yes. (And I think that means a code change if yes)

nibanks commented 4 days ago

I don't have a lot of feedback except to add that MsQuic explicitly looks at the TLS framing layer to ensure it never gives a fragment down to the lower layer, so it can completely handle the complexity itself the same across all TLS libraries. So we don't need any large preallocated buffer. But that's just MsQuic...

wbl commented 4 days ago

What about the use of VLA? I think that would make the patch nicer, as I'm not 100% sure of the current code being right. It would however mean updating our C level to C99, and we want to be sure you're onboard with that.