search

cloudflare / quiche

🥧 Savoury implementation of the QUIC transport protocol and HTTP/3
https://docs.quic.tech/quiche/
BSD 2-Clause "Simplified" License
9.46k stars 720 forks source link

quiche need 3 rtt to create a connection #811

Closed lilongyan-huawei closed 3 years ago

lilongyan-huawei commented 3 years ago

Hi,there I found a question, the quiche need 3 rtt to create a new connection. but only 1-rtt when create a new connetion in ietf draft .

3-rtt

junhochoi commented 3 years ago

Packet 1 and 2 is version negotation which takes addtional 1 rtt. You may try to send an exact version the server supports to remove this roundtrip. e.g. quiche-client --wire-version ff00001d

lilongyan-huawei commented 3 years ago

Packet 1 and 2 is version negotation which takes addtional 1 rtt. You may try to send an exact version the server supports to remove this roundtrip. e.g. quiche-client --wire-version ff00001d

OK, but beyond that, there are still problems. except packet 1 and 2, there are still have 2-rtt during new connection. How could we implement 1-rtt ?

junhochoi commented 3 years ago

In the screenshot I see 2 quic connections are created. Can you try to capture again without version negotiation? Also it'd be help to know how to reproduce it. Also if you use quiche-server, try to add --no-retry as well.

lilongyan-huawei commented 3 years ago

In the screenshot I see 2 quic connections are created. Can you try to capture again without version negotiation? Also it'd be help to know how to reproduce it. Also if you use quiche-server, try to add --no-retry as well.

I capture it without version negotiation. x.x.213.186 is client, x.x.50.51 is server. rtt is 35ms-40ms 2rtt

lilongyan-huawei commented 3 years ago

In the screenshot I see 2 quic connections are created. Can you try to capture again without version negotiation? Also it'd be help to know how to reproduce it. Also if you use quiche-server, try to add --no-retry as well.

how to use '--no-retry' in my server ? my server is nginx-quiche.

junhochoi commented 3 years ago

If you are nginx + quiche, there is no retry by default.

lilongyan-huawei commented 3 years ago

In the screenshot I see 2 quic connections are created. Can you try to capture again without version negotiation? Also it'd be help to know how to reproduce it. Also if you use quiche-server, try to add --no-retry as well.

I capture it without version negotiation. x.x.213.186 is client, x.x.50.51 is server. rtt is 35ms-40ms 2rtt

my client is http3-client of quiche's example, my server is nginx+quiche, but new connection costs 2-rtt . pls check~

junhochoi commented 3 years ago

@lilongyan-huawei it seems to be correct - packet 23,26,27,28,29,52 is making a quic connection established (1 rtt). from packet 54 it's http3 request, taking another rtt. let me know why you think it's 2 rtt.

lilongyan-huawei commented 3 years ago

@lilongyan-huawei it seems to be correct - packet 23,26,27,28,29,52 is making a quic connection established (1 rtt). from packet 54 it's http3 request, taking another rtt. let me know why you think it's 2 rtt.

packet 23, 26, 27, 28, 29 , this is the first rtt. packet 35,37,49,52,this is the second rtt. one rtt costs 35ms,but this quic connection costs 75ms,

x.x.213.186 is the client, x.x.50.51 is the server. the network is pure, there is no other quic requests.

junhochoi commented 3 years ago

Oh I see. I think 2nd rtt (37, 49) is because the server hits the amplification limit (https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-8.1), which limits for sender not to send more than 3x of what it received. Looks like the handshake from the server is bigger than 3 x 1200 which is Initial from the client (size of 27 + 28 + 29), so 29 looks truncated and 4th one (49) is delivered after servers gets ack (37). If this is the case, you may try to have a smaller SSL cert on your server.

lilongyan-huawei commented 3 years ago

Oh I see. I think 2nd rtt (37, 49) is because the server hits the amplification limit (https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-8.1), which limits for sender not to send more than 3x of what it received. Looks like the handshake from the server is bigger than 3 x 1200 which is Initial from the client (size of 27 + 28 + 29), so 29 looks truncated and 4th one (49) is delivered after servers gets ack (37). If this is the case, you may try to have a smaller SSL cert on your server.

I got it. my SSL is too big. many thanks. this issue can be closed now.