-- Leo's gemini proxy
-- Connecting to warmedal.se:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; lang=en
This might be a somewhat misleading title...
Anyways! I've been thinking about writing this for some time; and today is December 2nd. As good a time as any! I spent some time yesterday doing some measurements in order to write this post. There was *a lot* of difficulty involved in that, so there will be some handwaved assumptions at play here. Bear with me.
The point of this whole exercise is to have some info ready when we discuss differences between the web and geminispace in terms of bandwidth usage, overhead, and environmental impact.
Making a fair comparison of a webpage and a gemini capsule is really hard. What is reasonable to compare? There's no such thing as an "average" webpage, and I guess that's to some extent true of capsules too. I decided to not dwell on this too much. You're reading a simple gemlog right now, published by a single individual. I figure a fair comparison is a simple blog, published by a single individual and with roughly the same human-parseable information mass -- i.e. actual text. I entered "wordpress.com" into duckduckgo and picked a result that looked like a simple blog post. For comparison I used my second post about POSTing in gemini, as that looked like it had roughly the same amount of text.
Wow... this was complicated, especially since I wanted to capture TLS and TCP overhead, and have an average and... yeah, suffice to say that I fiddled a lot with netstat and wget only to find that html and http are hopelessly weird. And the overhead would differ a whole lot depending on which version of http was used, too. I ended up just entering the blog post URL into https://tools.pingdom.com and checking the weight of the page and the number of requests made there.
For the gemlog post I actually did do "netstat -s; <fetched the site ten times>; netstat -s" and compared the number of in/out octets before and after. I'm thinking I must have missed something somehow, because I ran it with and without client certificate in the transmission and it looked the same on both... I believe that summarizing the size of the server cert with the size of the post might get me far enough for the purposes of this post, so that's what I'm gonna go with. There's so much margin of error in the measurements.
The test at pingdom reveals that it takes a total of 48 requests and takes up 1.4MB of data to render the post. This includes a couple of pictures (about 1.0MB, according to the summary), which my gemlog post does not. How much extra bandwidth is involved in TLS transmissions? Not much, but too much.
HTTPS reuses TLS connections, so there's only one handshake and certificate exchange per domain and page load, but the 48 requests made are not all made to the same domain! Typically a web page will fetch images and scripts from CDNs on other domains.
In essence:
48 requests.
At least 3 TLS handshakes (I can't suss out exactly which of all the different link elements are actually requested, so this is a conservative estimate).
1.4MB of data, of which 1.0MB is images and about 2.2KB are the actual text content of the post. The other ~0.4MB are probably stylesheets and scripts, and a whole lot of invisible html elements.
Not much to say here:
1 request.
4.2KB of content. Almost all of it actual text, because gemtext markup is very spartan.
The certificate at tilde.team is about 1.4KB, and without looking at it in too much detail I'm going to assume that this is roughly true for most certificates; server and client alike. This is an unfair assumption, because:
There's a big difference in size between RSA and Elliptic Curve certificates (the former and bigger is most used, because not all TLS libraries support the ciphers of the latter).
A self-signed cert is generally smaller compared to one that includes a long certificate chain.
These differences are not too interesting here, however. We end up in pretty much the same ballpark either way. In the case of HTTP/HTML/JS/CSS the size of the certificate and TLS handshake is too small to be significant. In the case of gemini the numbers are tiny in an absolute sense -- especially compared to the blog post example -- but "pretty big" in a relative sense.
HTTP/HTML/CSS/JS is bloated. No news there. Of course we have to make HTTP more efficient and consider reducing all sorts of overhead, because we need to fit all that crap in! I guarantee that the rebound effect of a faster connection will be that all the more crap is sent, bogging down our CPUs and RAM and making the pages load slower.
An average (for some value of "average") gemini request is about one third certificate and two thirds content. Probably about half of each if a client certificate is used too. But it's also just the one request to load an entire post.
On the web a certificate sent is just a fart in space compared to everything else.
The size difference is relatively huge! The blog post sans images still weighs in at 400KB, compared to the 4.2KB of the gemlog post. That's one hundred times the size. Even if we add (and overestimate) server and client certificates to the gemini request it's still only one 50th the size of the blog post.
If you want to be really, really efficient with your bandwidth usage, consider this:
A redirect adds a relatively large amount of bandwidth usage, as a large portion of bandwidth in gemini is certs being exchanged. In absolute numbers we're still a lot cheaper than the web, ofcourse, but it's worth thinking about. If you're writing a gemtext and linking to directories, make sure to add a trailing slash (/). Otherwise a server must serve a redirect for relative links on that URI to work. If you're writing an app for geminispace, consider how to avoid redirects.
Every request is costly. Not prohibitively so, as we've seen, in comparison to the web. But as an author of content or programmer of apps it's worth considering what your readers or users want and making that available with as few requests as possible.
Remember, however, that content in geminispace is a lot lot lot cheaper in terms of CPU, RAM, and bandwidth than corresponding content is likely to be on the web. Write, my friends, and make apps, unfethered by these tiny numbers. Create and enjoy the fruits of your labour :)
PS. Tomorrow's post will probably be a lot less wordy...
-- CC0 ew0k, 2020-12-02
-- Response ended
-- Page fetched on Sat May 4 19:12:59 2024