You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
//mbedtls_ssl_context is extended to include a corking_count integer
mbedtls_ssl_corking (mbedtls_ssl_context *ssl);//Increment corking_count
mbedtls_ssl_push (mbedtls_ssl_context *ssl);//Decrement corking_count, flush buffer iff corking_count == 0
Once mbedtls_ssl_corking() is called, calls to mbedtls_ssl_write() that fit in the TLS write-buffer will be appended to the TLS write-buffer. Once the write-buffer becomes full, or full enough that the next write won't fit, the write-buffer will be encrypted and sent to the next layer for transport.
When mbedtls_ssl_push() is called the same number of times as mbedtls_ssl_corking(), and remaining bytes in the MbedTLS write buffer are encrypted and sent to the next layer for transport.
Justification
Mbed TLS needs this because sequences of small writes over TLS becomes sequences of small TCP packets with a lot of TLS overhead per mbedtls_ssl_write() call.
One example of this is a WebSocket client - each time application wants to write a payload string over a WebSocket, the WebSocket layer needs to mbedtls_ssl_write(WebSocketHeader), then mbedtls_ssl_write(WebSocketPayloadString). Currently, these become two TLS blocks, and depending on TCP send buffer state and Nagling, often the header will be sent first, wait for the TCP ACK, then send the payload.
Another example of this is HTTP1.1 request pipelining - each time the application submits a request through mbed_ssl_write(HTTP request), it's broken into its own TLS block, and its own TCP segment .
Maintaining a corking_count instead of a corking bit/mode is useful for applications like WebSockets where an application may know that it is about to send several small WebSocket frames back to back. Example pseudocode:
Suggested enhancement
TCP_CORK equivalent for MbedTLS.
Once
mbedtls_ssl_corking()
is called, calls tombedtls_ssl_write()
that fit in the TLS write-buffer will be appended to the TLS write-buffer. Once the write-buffer becomes full, or full enough that the next write won't fit, the write-buffer will be encrypted and sent to the next layer for transport.When
mbedtls_ssl_push()
is called the same number of times asmbedtls_ssl_corking()
, and remaining bytes in the MbedTLS write buffer are encrypted and sent to the next layer for transport.Justification
Mbed TLS needs this because sequences of small writes over TLS becomes sequences of small TCP packets with a lot of TLS overhead per mbedtls_ssl_write() call.
One example of this is a WebSocket client - each time application wants to write a payload string over a WebSocket, the WebSocket layer needs to mbedtls_ssl_write(WebSocketHeader), then mbedtls_ssl_write(WebSocketPayloadString). Currently, these become two TLS blocks, and depending on TCP send buffer state and Nagling, often the header will be sent first, wait for the TCP ACK, then send the payload.
Another example of this is HTTP1.1 request pipelining - each time the application submits a request through mbed_ssl_write(HTTP request), it's broken into its own TLS block, and its own TCP segment .
Maintaining a corking_count instead of a corking bit/mode is useful for applications like WebSockets where an application may know that it is about to send several small WebSocket frames back to back. Example pseudocode:
My apologies if there is already a way to achieve this behaviour.
The text was updated successfully, but these errors were encountered: