solderpunk solderpunk at SDF.ORG
Fri Jun 26 23:37:43 BST 2020
- - - - - - - - - - - - - - - - - - -
On Fri, Jun 26, 2020 at 06:18:11PM -0400, Sean Conner wrote:
It was thus said that the Great solderpunk once stated:
There are several contributing factors to TLS overhead.
I think some of the overhead concern is overblown.
Oh, I completely agree. It seems to bother a lot of people so I've beenpointing out comparatively quick and easy things we could do withoutchanging the spec at all to address it, because I'd much rather do thatthan increase complexity or reduce security. But my personal experienceusing AV-98 is that browsing Geminispace feels plenty snappy enough as is.Especially relative to how long the content takes to consume.
How are they stored? If they look like this:
-----BEGIN CERTIFICATE-----
MIIGHDCCBASgAwIBAgICEBIwDQYJKoZIhvcNAQELBQAwgZMxCzAJBgNVBAYTAlVT
MQswCQYDVQQIDAJGTDEcMBoGA1UECgwTQ29ubWFuIExhYm9yYXRvcmllczEaMBgG
A1UECwwRU2VjdXJpdHkgRGl2aXNpb24xHzAdBgNVBAMMFkNvbm1hbiBMYWJvcmF0
...
then your figures are a bit high
They're DER encoded binary files, so no worries about that.
size direction
1 60 -
SYN packet to server (no data)
2 60 <- SYN + ACK from server (still no data)> 3 52 -
ACK from client (still no data)
4 203 -
initial client TLS request
5 52 <- ACK from server (no data)> 6 1492 <- server certificate> 7 52 -
ACK from client (no data)
8 611 <- TLS? unsure from this point on> 9 52 -
ACK from client (no data)
10 144 -
data
11 52 <- ACK from server (no data)> 12 95 <- data> 13 102 -
data
14 1492 <- data (I'm assuming by now this is the file)> 15 1282 <- data (probably more file)> 16 52 -
ACK from client (no data)
17 75 <- getting ready to close?> 18 75 -
getting ready to cloes?
19 52 -
FIN + ACK from client (no data)
20 46 <- FIN from server (no data)
Thanks for this, very enlightening!
Cheers,Solderpunk