💾 Archived View for rawtext.club › ~sloum › geminilist › 001985.gmi captured on 2020-09-24 at 01:30:42. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Meff meff at meff.me
Sat Jun 27 21:25:21 BST 2020
- - - - - - - - - - - - - - - - - - -
I, personally, feel that TLS is an incontrovertible part of the appeal of Gemini to me(I've been using Gopher for my own personal things that I want to serve _without_ TLS),but I think there should be guidance on selecting TLS parameters. I've run some load testsand generated some pretty graphs for different generated keys and using them with bothJetforce and Molly Brown, and there is certainly low hanging fruit to work on. If folksare interested, I can collect some of my tests, data, and Python analysis and I canput them up in a digestible post.
- meff
On 6/26/20 3:37 PM, solderpunk wrote:
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 been
pointing out comparatively quick and easy things we could do without
changing the spec at all to address it, because I'd much rather do that
than increase complexity or reduce security. But my personal experience
using 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