Gemini è un protocollo di comunicazione leggero e orientato ai testi, progettato per consentire il trasferimento di documenti tramite Internet in modo semplice e sicuro. È stato sviluppato con l’obiettivo di offrire un’alternativa più leggera e versatile rispetto ad HTTP, utilizzato per il trasferimento delle pagine Web. Il protocollo HTTP (Hypertext Transfer Protocol) è stato inventato da Tim Berners-Lee nel 1991, l’informatico britannico universalmente considerato il padre del World Wide Web: in un altro articolo abbiamo parlato dei primi 30 anni del Web.
Nel 1990, Tim Berners-Lee ha introdotto le prime versioni di HTTP come parte di un progetto per creare un sistema di informazione distribuito basato su ipertesti; la prima versione ufficiale di HTTP, chiamata HTTP/1.0, è stata rilasciata nel 1996. Successivamente, sono state introdotte diverse versioni successive, come HTTP/1.1 nel 1997 e HTTP/2 nel 2015, per migliorare le prestazioni, l’efficienza e la sicurezza della comunicazione tra client e server.
L’evoluzione continua del protocollo HTTP ha portato allo sviluppo di nuove specifiche, come HTTP/3, a loro volta basate sul lavoro svolto da Google con il protocollo QUIC che unisce i vantaggi di TCP, inventato dai leggendari Vint Cerf e Bob Kahn nel 1973, con quelli di UDP (User Datagram Protocol, nato nel 1980) per assicurare non solo migliori velocità trasmissive ma anche un recupero più veloce in caso di guasti e disconnessioni.
C’è davvero bisogno di un’alternativa ad HTTP come Gemini?
Nel 2019, uno sviluppatore di software indipendente battezzatosi con lo pseudonimo di Solderpunk, ha presentato il protocollo Geminicon l’idea di tornare a un approccio più semplice e meno orientato agli elementi multimediali rispetto al Web moderno. Il protocollo è basato su un modello client-server: il client richiede e riceve documenti da un server Gemini. I documenti sono principalmente testuali, ma possono anche contenere link a risorse esterne, immagini o file.
Una caratteristica distintiva del protocollo Gemini è la sua enfasi sulla privacy e sulla sicurezza. I collegamenti alle risorse esterne, ad esempio, sono limitati, e non sono supportate le funzionalità avanzate come l’esecuzione di script o l’inclusione di contenuti dinamici. Così, Gemini ha guadagnato popolarità nella comunità dei tecnici che guardando a un’alternativa più semplice e meno invasiva rispetto agli approcci abitualmente utilizzati al giorno d’oggi.
Gemini non ha cookie, nessuna negoziazione, nessuna autenticazione, nessuna compressione e praticamente nessuna intestazione addizionale rispetto all’insieme minimo definito in seno al protocollo: il tutto per evitare attività di sorveglianza e il tracciamento. Viene invece promosso l’utilizzo di certificati client TLS per mantenere lo stato delle richieste.
I sostenitori di Gemini affermano che il protocollo non vuole “scimmiottare” il Web ma si propone come qualcosa di nuovo: in effetti, nell’ambito del suo sviluppo, non sono state coinvolte IETF (Internet Engineering Task Force) e altre organizzazioni competenti. E si vede.
A questo proposito è sicuramente molto interessante la posizione di Daniel Stenberg, inventore del comando curl, utilizzato ormai in centinaia di milioni di dispositivi. Stenberg, di recente, ha presentato trurl, utilità che permette di gestire e modificare gli URL.
Esaminando le specifiche di Gemini, Stenberg conferma che si tratta di una breve paginetta contenente le indicazioni di base sulla struttura degli URL e il formato di documento text/gemini che, per stessa ammissione degli autori, trae spunto dalle gophermap e dal linguaggio di markup Markdown.
Gemini: apparentemente un tentativo di reintrodurre il vecchio protocollo Gopher
Le gophermap sono file di testo utilizzati nel protocollo Gopher per strutturare e presentare le informazioni. Sviluppato negli anni ’90, il protocollo Gopher era stato progettato come uno strumento per organizzare e visualizzare contenuti su Internet in modo semplice e immediato. Le gophermap sono uno dei componenti fondamentali di un server Gopher e determinano la struttura e il layout delle risorse disponibili.
Stenberg rileva infatti il tentativo di promuovere Gemini, come una sorta di “rinascita di Gopher”. Il protocollo Gemini impone la chiusura della connessione dopo ogni risposta, rendendo forzatamente impossibile il riutilizzo della connessione. Come sottolinea l’inventore di curl, si tratta di un approccio pessimo dal punto di vista delle performance quando vi è la necessità di recuperare più di una risorsa dallo stesso server. Nel complesso, anche per altre scelte tecniche, Gemini si preannuncia un protocollo piuttosto lento.
Il motivo principale per cui è stato scelto questo design sembra essere quello di evitare di avere un modo per segnalare la dimensione dei payload o eseguire una trasferimenti “a blocchi”. “Un approccio più facile da documentare e da implementare ma certamente più lento e dispendioso“, osserva Stenberg.
Servire una pagina HTML “tipica” utilizzando un buon numero di risorse/immagini collegate sarà quindi significativamente più lento con Gemini rispetto a HTTP/1.1 o versioni successive, soprattutto con server remoti. “La mia ipotesi è che Gemini non sia davvero pensato come un’alternativa per la distribuzione di pagine HTML“, continua ancora Stenberg.
Poiché Stenberg ha ricevuto diverse richieste di integrare il supporto per Gemini all’interno del comando curl, lo sviluppatore ha analizzato in profondità il funzionamento del nuovo protocollo emettendo un suo giudizio complessivo.
Innanzi tutto, no, Gemini non sostituirà il Web e, anzi, non sembra neppure un protocollo per l’utilizzo “in massa” da parte degli utenti. “Non sono un grande fan di questo protocollo, ma credo che possa funzionare e servire la sua comunità di utenti. Se qualcuno me lo chiedesse, ecco alcune cose che prenderei in considerazione“, scrive Stenberg dando alcuni consigli agli ideatori di Gemini: dividere le specifiche in quelle relativa al protocollo in sé, alla sintassi dell’URL, al tipo di supporto; legare l’utilizzo del certificato client all’origine e non al nome dell’host; prendere in considerazione un modo per riutilizzare le connessioni, anche se ciò significa introdurre alcune parti essenziali di HTTP.