24 ans de libcurl

Posté par  (site web personnel) . Édité par Ysabeau 🧶, palm123 et bobble bubble. Modéré par Ysabeau 🧶. Licence CC By‑SA.
Étiquettes :
57
7
août
2024
Internet

Curl est un outil en ligne de commande destiné à récupérer le contenu d’une ressource accessible par un réseau informatique et gérant de nombreux protocoles.

Curl est un outil essentiel pour de nombreux usages, pris en charge par une gamme très large de systèmes d’exploitation, d’architectures matérielles, de l’objet connecté à l’embarqué spatial en passant par l’informatique classique ou les consoles de jeux. Il évolue rapidement et fréquemment, voir par exemple l’arrivée prochaine de HTTP3 pour curl dans Debian unstable (avec le backend gnutls). Son domaine d’utilisation pourrait encore s’étendre avec l’apparition de wcurl dans Debian et bientôt dans le monde entier ?

Il y a 24 ans, une division du code entre une interface ligne de commande et une bibliothèque a été faite.

(Cette dépêche est principalement basée sur l’annonce anglophone par Daniel Stenberg, auteur principal de curl et libcurl ; dépêche rédigée sur un téléphone embarquant curl 7.80, pas vraiment la dernière version…).

La première version de libcurl, baptisée 7.1, date du 7 août 2000. La version de curl précédente, la 6.5.2, pas encore séparée entre une interface ligne de commande et une bibliothèque. Il s’agit de l’écart le plus long entre deux versions de curl. La création de la bibliothèque a été très largement réalisée par Daniel Stenberg seul.

Il décrit son choix de division ainsi : c'était juste une intuition et une conjecture. Je ne savais pas. Je n’avais pas fait de recherches sur cela ou autre chose. Je me suis juste lancé en me disant qu’on verrait plus tard si j’avais raison ou tort.

Le nom de la bibliothèque a été choisi faute d’une meilleure idée. L’API a été définie comme étant bas niveau (on peut toujours ajouter une API de plus haut niveau par-dessus), en observant ioctl(), fcntl() et les fonctions du genre. Le code est en C, langage de prédilection de l’auteur principal.

L’API a bien vieilli : 17 fonctions encore présentes proviennent de la 7.1 ; elle est passée de 17 000 lignes à 171 000 ; elle a survécu aux révolutions HTTP/2 (transferts multiples multiplexés) et HTTP/3 (passer de TCP à UDP).

L’usage a aussi bien progressé depuis l’entrée dans PHP 4.0.2 comme premier binding (ici rendre utilisable en langage PHP), moins d’un mois après la publication de la bibliothèque.

En 2002 a été ajoutée une API multi pour gérer des transferts parallèles concurrents de façon illimitée dans un même thread.

Puis en 2006 vient en surplus le multi_action avec des mécanismes orientés événements, avec une boucle événementielle (comme epoll).

Les premiers changements douloureux sur l’interface binaire (ABI) ont entraîné une volonté de stabilité, de ne jamais casser volontairement cette interface, et ce depuis 2006.

libcurl possède des bindings vers au moins 65 langages de programmation, fonctionne sur au moins 103 systèmes d’exploitation et 28 architectures de processeur, est présent dans les bibliothèques standard de langages de programmation (Python, Java, Rust ou .Net). Son ancien concurrent principal libwww n’est plus développé. Bref 18 ans de stabilité d’API et d’ABI.

L’utilisation de libcurl continue de croître (de plus en plus d’objets connectés notamment). Et curl de manière générale supporte rapidement les nouveaux protocoles et leurs évolutions. À noter que l’auteur principal ne mentionne pas dans ses projections ce qui me semble le plus gros risque pour Curl/libcurl, la difficulté d’avoir une personne prête à lui succéder si quand cela s’avérera nécessaire.

Aller plus loin

  • # Non, HTTP/3 n'est pas vraiment sur UDP

    Posté par  (site web personnel, Mastodon) . Évalué à 8.

    HTTP/3 (passer de TCP à UDP)

    Ce n'est pas la bonne description. HTTP/3 utilise QUIC et non pas UDP comme protocole de transport. QUIC ne peut pas tourner directement sur IP en raison de toutes les boxes àlakon qui bloquent les protocoles de transport inconnus, donc il utilise UDP mais ce n'est qu'un hack, fondamentalement, le protocole de transport de HTTP/3 est QUIC, pas UDP.

    • [^] # Re: Non, HTTP/3 n'est pas vraiment sur UDP

      Posté par  (site web personnel) . Évalué à 8. Dernière modification le 08 août 2024 à 21:25.

      and HTTP/3, which switches from TCP to UDP

      Certes mais c'est la description mentionnée dans le texte original sur les évolutions de libcurl.

      Curl sinon prend en charge HTTP/3 et QUIC, cf https://curl.se/docs/http3.html

    • [^] # Re: Non, HTTP/3 n'est pas vraiment sur UDP

      Posté par  . Évalué à 3.

      Et pourtant, Wikipedia, HTTP/3, premier paragraphe:

      HTTP/3 uses QUIC, a multiplexed transport protocol built on UDP.[3]

      Et dans l'article sur QUIC:

      The second change is to use UDP rather than TCP as its basis

    • [^] # Re: Non, HTTP/3 n'est pas vraiment sur UDP

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      Cet été, j'ai trouvé ce message très intéressant dans un fil de discussion lancé par Julia Evans sur les utilisations (in)connues d'UDP.

      En gros l'auteur du message dit que l'on peut voir UDP comme la couche IPv4 avec l'ajout d'un numéro de port et d'un checksum. Ça permettait de créer différents services sur IP sans avoir besoin de réserver un numéro de protocole à chaque service nécessaire (les paquets IPv4 ont un espace dans l'en-tête IP qui permet de définir 256 protocoles différents, IPv6 n'a apparemment plus cette information).

      Du coup, de ce point de vue ça semble logique que QUIC utilise UDP pour se déployer: ça ajoute très peu de complexité (le numéro de port et un calcul de checksum) et ça utilise une fonctionnalité prévue d'UDP (déployer des nouveaux protocoles sans faire d'enregistrement formel pour réserver un numéro de protocole dans IPv4).

      • [^] # Re: Non, HTTP/3 n'est pas vraiment sur UDP

        Posté par  (site web personnel) . Évalué à 3.

        C'est surtout que c'est impossible de modifier la configuration des routeurs aujourd'hui… Déjà IPv6 a du mal à être déployé. Les DSI ferment quasi tout sauf http/https ! Donc on se retrouve avec du https pour tout et n'importe quoi. Bilan, on fait du https sur udp pour pouvoir ensuite faire tout ce que l'on veut pour franchir les routeurs… Et comme les DSI ne seront pas contentes : boites noires et EDR partout.

        Cela me semble irréversible, mais n'est pas vraiment très respectueux d'un internet sobre.

      • [^] # Re: Non, HTTP/3 n'est pas vraiment sur UDP

        Posté par  . Évalué à 3. Dernière modification le 04 septembre 2024 à 00:16.

        (les paquets IPv4 ont un espace dans l'en-tête IP qui permet de définir 256 protocoles différents, IPv6 n'a apparemment plus cette information).

        Cette information existe toujours, elle n'est juste plus au même endroit (ni nommée pareille) : c'est désormais le champ «Next Header» qui permet de préciser le protocole encapsulé par le paquet IPv6, soit le champ «Next Header» de l'entête fixe (celui qui donne, entre autres, les adresses source et destination), soit celui du dernier entête d'extension, celui qui précède la charge utile du paquet.
        La liste des protocoles est la même que pour IPv4, avec quelques «protocoles» spécifiques à IPv6 (par exemple le 59, IPv6-NoNxt, qui indique qu'il n'y a pas d'autre entête après celui-ci, et donc que ce paquet n'encapsule pas de charge d'un protocole de niveau supérieur à IPv6).

  • # wcurl à la conquête du monde

    Posté par  (site web personnel) . Évalué à 3. Dernière modification le 04 septembre 2024 à 06:44.

    En tant qu'homme engagé..
    …je viens d'installer wcurl sur toutes mes distributions.
    Un petit coup pour l'homme, un grand coup pour le progrès social !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.