3 ms·

I'm not well versed with CURL design, but curious - is your first connection handling TLS while second relying on the previously established handshake?

by omk 1y ago

swiftcoder 1y ago
TLS handshakes (outside of embedded hardware) should be measured in milliseconds, not seconds Edit: you can kind of tell this from the connect timings listed above. TLS is faster the second time around, but not enough to make much difference to the overall speedup
- scottlamb 1y ago
  I think you're right that TLS doesn't explain the difference shown above, but for completeness: TLS 1.3 can reduce the round trips from 3 to 2 on session resumption. [1] Depending on your Internet connection, that could be a lot more than milliseconds. I don't think `curl` uses it by default though. [1] https://blog.cloudflare.com/introducing-0-rtt/ https://blog.cloudflare.com/introducing-0-rtt/
smacker 1y ago
I'm not very well versed with CURL design too but afaik it does reuse connections but only inside the same process (e.g. downloading 10 files with 1 command). In this case it shouldn't be re-using them as I ran 2 different commands. I should have included TLS handshake time in the output, though. You can see it here (overall time is lower because I hit preview env that is slightly different from staging/prod): First hit: ``` DNS Lookup: 0.026284s Connect (TCP): 0.036498s Time app connect (TLS): 0.059136s Start Transfer: 1.282819s Total: 1.282928s ``` Second hit: ``` DNS Lookup: 0.003575s Connect (TCP): 0.016697s Time app connect (TLS): 0.032679s Start Transfer: 0.242647s Total: 0.242733s ``` Metrics description: time_namelookup: The time, in seconds, it took from the start until the name resolving was completed. time_connect: The time, in seconds, it took from the start until the TCP connect to the remote host (or proxy) was completed. time_appconnect: The time, in seconds, it took from the start until the SSL/SSH/etc connect/handshake to the remote host was completed. time_starttransfer: The time, in seconds, it took from the start until the first byte was just about to be transferred. This includes time_pretransfer and also the time the server needed to calculate the result.

I'm not well versed with CURL design, but curious - is your first connection handling TLS while second relying on the previously established handshake?

by omk 1y ago

I'm not well versed with CURL design, but curious - is your first connection handling TLS while second relying on the previously established handshake?

swiftcoder 1y ago

TLS handshakes (outside of embedded hardware) should be measured in milliseconds, not seconds Edit: you can kind of tell this from the connect timings listed above. TLS is faster the second time around, but not enough to make much difference to the overall speedup

scottlamb 1y ago
I think you're right that TLS doesn't explain the difference shown above, but for completeness: TLS 1.3 can reduce the round trips from 3 to 2 on session resumption. [1] Depending on your Internet connection, that could be a lot more than milliseconds. I don't think `curl` uses it by default though. [1] https://blog.cloudflare.com/introducing-0-rtt/ https://blog.cloudflare.com/introducing-0-rtt/

smacker 1y ago

I'm not very well versed with CURL design too but afaik it does reuse connections but only inside the same process (e.g. downloading 10 files with 1 command). In this case it shouldn't be re-using them as I ran 2 different commands. I should have included TLS handshake time in the output, though. You can see it here (overall time is lower because I hit preview env that is slightly different from staging/prod): First hit: ``` DNS Lookup: 0.026284s Connect (TCP): 0.036498s Time app connect (TLS): 0.059136s Start Transfer: 1.282819s Total: 1.282928s ``` Second hit: ``` DNS Lookup: 0.003575s Connect (TCP): 0.016697s Time app connect (TLS): 0.032679s Start Transfer: 0.242647s Total: 0.242733s ``` Metrics description: time_namelookup: The time, in seconds, it took from the start until the name resolving was completed. time_connect: The time, in seconds, it took from the start until the TCP connect to the remote host (or proxy) was completed. time_appconnect: The time, in seconds, it took from the start until the SSL/SSH/etc connect/handshake to the remote host was completed. time_starttransfer: The time, in seconds, it took from the start until the first byte was just about to be transferred. This includes time_pretransfer and also the time the server needed to calculate the result.