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
- libcurl is 24 years old (6 août 2024) (72 clics)
- curl 8.9.1 (31 juillet 2024) (31 clics)
- Curl (55 clics)
- les 28 protocoles gérés par curl (98 clics)
# Non, HTTP/3 n'est pas vraiment sur UDP
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 8 (+8/-2).
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 Benoît Sibaud (site web personnel) . Évalué à 8 (+5/-0). Dernière modification le 08 août 2024 à 21:25.
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 steph1978 . Évalué à 3 (+2/-1).
Et pourtant, Wikipedia, HTTP/3, premier paragraphe:
Et dans l'article sur QUIC:
[^] # Re: Non, HTTP/3 n'est pas vraiment sur UDP
Posté par jmiven . Évalué à 3 (+2/-0).
Je pense qu'il faut que tu relises le message de Stéphane, parce que tes citations ne contredisent pas vraiment son propos.
[^] # Re: Non, HTTP/3 n'est pas vraiment sur UDP
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 5 (+3/-0).
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 Sytoka Modon (site web personnel) . Évalué à 3 (+1/-0).
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 Pol' uX (site web personnel) . Évalué à 5 (+3/-0).
Mais si les DSI ferment tout sauf https, ne serait il pas plus approprié de faire UDP sur https pour ensuite permettre http/3 sur Quic sur UDP ?
Adhérer à l'April, ça vous tente ?
[^] # Re: Non, HTTP/3 n'est pas vraiment sur UDP
Posté par Joris Dedieu (site web personnel) . Évalué à 3 (+1/-0).
Je ne suis pas certain de la comparaison avec IPv6.
Depuis 15 ans Ipv6 est supporté par tous les logiciels et matériels. S'il n'est pas utilisé c'est peut-être tout simplement qu'outre sa complexité opérationnelle, il répond à des problèmes que quasiment personne ne se pose …
```
[^] # Re: Non, HTTP/3 n'est pas vraiment sur UDP
Posté par Tangi Colin . Évalué à 2 (+1/-0).
Assez d'accord, ipv6 a modifier trop en profondeur la topo réseaux avec le RA et le support dhcpv6 qui n'a été spécifié que plus tard. Ça a été trop ambitieux au début pour moi.
[^] # Re: Non, HTTP/3 n'est pas vraiment sur UDP
Posté par Pol' uX (site web personnel) . Évalué à 3 (+1/-0).
En plus il pose des problèmes auxquels quasiment personne ne répond …
Adhérer à l'April, ça vous tente ?
[^] # Re: Non, HTTP/3 n'est pas vraiment sur UDP
Posté par Frédéric Blanc . Évalué à 3 (+2/-0). Dernière modification le 04 septembre 2024 à 00:16.
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).
[^] # Re: Non, HTTP/3 n'est pas vraiment sur UDP
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Merci, je ne l'avais pas vu.
En regardant à nouveau Wikipedia, j'ai trouvé la liste des numéros de protocoles réservés: la liste est beaucoup plus grande que ce que j'imaginais et elle est déjà bien remplie !
Étonnamment, QUIC n'y apparaît pas. Elle n'y est pas non plus sur la liste de l'IANA.
Il serait donc impossible de déployer directement QUIC sans passer par UDP ?
UDP serait donc effectivement utile pour déployer de nouveaux protocoles sur IP :)
# wcurl à la conquête du monde
Posté par Tarnyko (site web personnel) . Évalué à 3 (+1/-0). 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 !
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.