> On 23 Feb 2023, at 15:49, Roman Arutyunyan <a...@nginx.com> wrote:
>
> # HG changeset patch
> # User Roman Arutyunyan <a...@nginx.com>
> # Date 1677152799 -14400
> # Thu Feb 23 15:46:39 2023 +0400
> # Branch quic
> # Node ID 6d471753917c083b4044f73557f9af8d91c20d36
> # Parent 3c33d39a51d334d99fcc7d2b45e8d8190c431492
> QUIC: optimized sending stream response.
>
> When a stream is created by client, it's often the case that nginx will send
> immediate response on that stream. An example is HTTP/3 request stream, which
> in most cases quickly replies with at least HTTP headers.
>
> QUIC stream init handlers are called from a posted event. Output QUIC
> frames are also sent to client from a posted event, called the push event.
> If the push event is posted before the stream init event, then output produced
> by stream may trigger sending an extra UDP datagram. To address this, push
> event is now re-posted when a new stream init event is posted.
>
> An example is handling 0-RTT packets. Client typically sends an init packet
> coalesced with a 0-RTT packet. Previously, nginx replied with a padded CRYPTO
> datagram, followed by a 1-RTT stream reply datagram. Now CRYPTO and STREAM
> packets are coalesced in one reply datagram, which saves bandwidth.
>
For the record, there are use-cases in connections without 0-RTT:
- response to the 1st 1-RTT request in a new connection could be sent
separately, because push event was already posted.
The first 1-RTT request is usually coalesced with Init(ACK)+HS(ACK,CRYPTO)
which are handled before 1-RTT and are the reason of posted push event.
- additionally, handling of ACK+STREAM packets resulted in corresponding
MAX_STREAMS and STREAM frames sent in separate packets/datagrams.
Although it doesn't result in noticeable bandwidth waste unlike with 0-RTT,
this is extra packets and cpu cycles spent on their serialization.
> diff --git a/src/event/quic/ngx_event_quic_streams.c
> b/src/event/quic/ngx_event_quic_streams.c
> --- a/src/event/quic/ngx_event_quic_streams.c
> +++ b/src/event/quic/ngx_event_quic_streams.c
> @@ -472,6 +472,17 @@ ngx_quic_get_stream(ngx_connection_t *c,
>
> if (qc->streams.initialized) {
> ngx_post_event(rev, &ngx_posted_events);
> +
> + if (qc->push.posted) {
> + /*
> + * It's highly likely the posted stream will produce output
> + * immediately. By postponing the push event, we coalesce
> + * the stream output with queued frames in one UDP datagram.
> + */
> +
> + ngx_delete_posted_event(&qc->push);
> + ngx_post_event(&qc->push, &ngx_posted_events);
> + }
> }
> }
Looks good.
--
Sergey Kandaurov
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel
