Mardi 1er juin 2021 Nouvelles techniques quic, TCP, cornac, nocodb, Python 3.10.0 beta 2

Quic

Le protocole de transport QUIC vient d’être normalisé, sous la forme de plusieurs RFC. QUIC, déjà largement déployé, peut changer pas mal de choses sur le fonctionnement de l’Internet, en remplaçant, au moins partiellement, TCP.

Quels sont les concepts de base de QUIC ? QUIC gère des connexions entre machines, comme TCP. Par contre, contrairement à TCP, ces connexions portent ensuite des ruisseaux (streams) séparés, ayant leur propre contrôle de congestion, en plus du contrôle global à la connexion.

Les ruisseaux peuvent être facilement et rapidement créés. Ce n’est pas par hasard que le concept ressemble à celui des ruisseaux de HTTP/2 (RFC 7540), dans les deux cas, le but était de s’adapter au désir des navigateurs Web de charger toutes les ressources d’une page en parallèle, sans pour autant « payer » l’établissement d’une connexion pour chaque ressource.

Avec QUIC, le chiffrement est obligatoire. Il n’y a pas de version de QUIC en clair. Non seulement les données applicatives sont chiffrées, comme avec TLS ou SSH mais une bonne partie de la couche transport l’est également. Pourquoi ?

  • En raison de la prévalence de la surveillance massive sur l’Internet (RFC 7258) ; moins on expose de données, moins il y a de risques.

  • Afin d’éviter que les middleboxes ne se croient capables d’analyser le fonctionnement de la couche transport, et ne se croient autorisées à y intervenir, ce qui mène à une ossification de l’Internet. Si tout est chiffré, on pourra faire évoluer le protocole sans craindre l’intervention de ces fichus intermédiaires.

  • Certains FAI ont déjà exploité le caractère visible de TCP (RFC 8546) pour des attaques, par exemple en envoyant des paquets RST (ReSeT) pour couper le trafic BitTorrent. TLS et SSH ne protègent pas contre ce genre d’attaques. (Mais QUIC ne protège pas complètement ; le problème est difficile car il faut bien permettre aux machines terminales de réclamer une coupure de la connexion.)

  • L’observation de la couche transport peut permettre d’identifier les services utilisés et d’en dé-prioritiser certains. Le chiffrement du transport peut donc aider à préserver la neutralité du réseau.

On peut prévoir que les habituels adversaires du chiffrement protesteront d’ailleurs contre QUIC, en l’accusant de gêner la visibilité (ce qui est bien le but).

Voir par exemple le RFC 8404. On voit ainsi un fabricant de produits de sécurité qui conseille carrément de bloquer QUIC.

Qu’est-ce que vont dire ces adversaires du chiffrement lorsqu’on aura des VPN sur QUIC, comme ce sur quoi travaille le bien nommé groupe MASQUE !

Pour résumer les différences entre QUIC et TCP (rappelez-vous qu’ils assurent à peu près les mêmes fonctions) :

  • QUIC est systématiquement chiffré,

  • QUIC permet un vrai multiplexage ; la requête lente ne bloque pas la rapide, et la perte d’un paquet ne ralentit pas tous les ruisseaux multiplexés,

  • QUIC fusionne transport et chiffrement, ce qui permet notamment de diminuer la latence à l’établissement de la connexion,

  • QUIC permet la migration d’une connexion en cas de changement d’adresse IP (je n’en ai pas parlé ici, voir RFC 9000).

Les RFC normalisant QUIC sont :

  • RFC 9000 est la norme principale, décrivant le socle de base de QUIC,

  • RFC 9001 normalise l’utilisation de TLS avec QUIC,

  • RFC 9002 spécifie les mécanismes de récupération de QUIC, quand des paquets sont perdus et qu’il faut ré-émettre, sans pour autant écrouler le réseau,

  • RFC 8999 est consacré aux invariants de QUIC, aux points qui ne changeront pas dans les nouvelles versions de QUIC.

J’ai dit que QUIC, comme TCP, est un protocole de transport généraliste, et qu’on peut faire tourner plusieurs applications différentes dessus.

En pratique, QUIC a été conçu essentiellement en pensant à HTTP mais dans le futur, d’autres protocoles pourront profiter de QUIC, notamment s’ils ont des problèmes qui ressemblent à ceux du Web (désir de faible latence, et de multiplexage).

Pour HTTP, la version de HTTP qui tourne sur QUIC se nomme HTTP/3 et sera normalisée plus tard.

Comme HTTP/2 (RFC 7540), HTTP/3 a un encodage binaire mais il ne fait plus de multiplexage, celui-ci étant désormais assuré par QUIC.

Pour d’autres protocoles, les curieux pourront s’intéresser à SMB (déjà géré par Wireshark), au DNS (draft-ietf-dprive-dnsoquic) ou SSH (draft-bider-ssh-quic).

Quelques lectures sur QUIC :

  • La référence est bien sûr le livre libre et gratuit de Daniel Stenberg (l’auteur de curl), HTTP/3 explained. En dépit de son nom, il couvre également QUIC. Il a une traduction en français.

  • Mon exposé à Capitole du Libre en 2019 couvrait QUIC, avec un beau résumé en image, fait par Kevin Ottens.

  • Il n’y a pas à l’heure actuelle de page QUIC sur le Wikipédia francophone.

  • Si vous aimez les détails techniques, outre les RFC cités plus haut, j’ai fait un article détaillant une session QUIC

Django pages

Basic usage

The magic happens in the get_elided_page_range method on the Paginator. The basic usage looks like this: 

page = request.GET.get('page', 1)
paginator = Paginator(articles, 40)
page_range = paginator.get_elided_page_range(number=page)

This attempt to get the page parameter from the URL query string, creates Paginator and finally gets the elided range. Basically « incomplete » page range.

nocodb (Turns any MySQL, PostgreSQL, SQL Server, SQLite & MariaDB into a smart-spreadsheet)

Intégrer PostgreSQL dans un cloud privé avec cornac

Liens utiles

Le cloud est à un seuil similaire au web des années 2000.

À l’époque, la technologie LAMP (Linux, Apache, PHP, MySQL) a ouvert une brèche dans un monde dominé par Java.

Depuis, le web carbure au logiciel libre.

Dans le même temps, la guerre des navigateurs a poussé l’émergence de standards du web, pour le plus grand soulagement des utilisateurs et des développeurs.

Aujourd’hui, le cloud profite lui aussi du logiciel libre. En revanche, la jungle des API rappelle la guerre des navigateurs. De même, les monopoles des grands opérateurs rappelle le verrouillage des grands éditeurs logiciels.

Les entreprises veulent bien du cloud, mais pas d’une prison technologique avec une facturation arbitraire à la clef. C’est là l’enjeu du cloud privé : la technologie cloud est-elle assez mature pour être opérée en interne, avec un niveau de fonctionnalité suffisant pour concurrencer le confort du cloud public ?

Tu as présenté cet automne le projet cornac, explique-nous.

Étienne : C’est dans cet esprit de développer le cloud privé que Dalibo, fort de son expertise en industrialisation de PostgreSQL, a initié le projet cornac. Il s’agit d’une implémentation de l’API AWS RDS (Relationnal Database Service) et une console web administrant un parc de machines virtuelles exécutant PostgreSQL.

Plutôt que de s’isoler dans une niche technologique, nous avons parié sur la compatibilité. Considérons l’API RDS comme le standard de la consommation d’un service DBaaS (DataBase as a Service) et produisons une implémentation libre !

C’est déjà le cas pour S3 (Simple Storage Service, le stockage objet d’AWS) et EC2 (Elastic Compute, le service de machine virtuelle d’AWS). Pourquoi pas RDS ?

Le fait d’être rigoureusement compatible RDS nous ouvre l’accès à un écosystème mature pour l’intégration dans les catalogues de services, les solutions Infrastructure as Code et les outils DevOps en général.

Actuellement, cornac gère le provisionnement, les sauvegardes PITR, la supervision et la haute disponibilité. Le service cornac consomme l’API vSphere vCenter pour provisionner les VM et nous envisageons d’exploiter également OpenStack et pourquoi pas harvester, un orchestrateur de VM dans kubernetes.

Nous avons fait le choix de la VM plutôt que du conteneur pour travailler sur une technologie éprouvée, facile à diagnostiquer en cas de problème. D’ailleurs, AWS RDS fonctionne avec des VM. Ce qui est stratégique pour le projet n’est pas tant le choix VM ou conteneur, mais la compatibilité avec l’API RDS et l’interface.

Le principe du cloud est justement d’ignorer le détails d’implémentation derrière un guichet API ou web.

Quelles tendances envisages-tu autour des clouds dans un futur proche ?

Étienne : Kubernetes est bouillonnant et cherche encore son chemin. Les prochaines années devraient le voir émerger comme un outil générique d’orchestration de nombreuses ressources. On voit les prémices d’usages de Kubernetes découplés des conteneurs. Cela ouvre de grandes possibilités.

Ainsi, Kubernetes pourrait être le nouveau moteur des infrastructures privées comme vSphere l’est actuellement. À la différence près que Kubernetes a beaucoup plus d’intelligence pour gérer le cycle de vie des ressources.

Néanmoins, deux problèmes persistent : la complexité du déploiement - notamment la sécurisation des ressources - et la disponibilité d’API mature.

Il reste encore du chemin au projet Kubernetes pour être stable et accessible sans investir énormément dans la formation d’une technologie très changeante.

Docker a connu cette étape autour de 2015. Nous aurons toujours besoin d’implémentation d’API standards au-dessus de cette nouvelle infrastructure.

Postgis

bash-aliases 

Last one:

alias run-django='docker-compose -f local.yml run django python http://manage.py'

Lets you immediately run any django management commands without a bunch of typing.

Usage example: run-django collectstatic