Pourquoi les services utilisant TCP populaires ont-ils des entrées UDP et TCP dans / etc / services?

Je lis un livre sur la programmation réseau avec Go. Un des chapitres traite du fichier / etc / services. Quelque chose que j'ai remarqué en explorant ce fichier est que certaines entrées populaires comme HTTP et SSH, qui utilisent toutes deux TCP au niveau de la couche de transport, ont une deuxième entrée pour UDP. Par exemple sur Ubuntu 14.04:

ubuntu@vm1:~$ grep ssh /etc/services  
ssh             22/tcp         # SSH Remote Login Protocol 
ssh             22/udp

ubuntu@vm1:~$ grep http /etc/services  
http            80/tcp          www             # WorldWideWeb HTTP            
http            80/udp                          # HyperText Transfer Protocol

Quelqu'un sait pourquoi ceux-ci ont deux entrées? Je ne crois pas que SSH ou HTTP utilisent jamais UDP (confirmé par cette question pour SSH).

— sixty4bit
source

22/udpa été supprimé dans Debian en 2016. L' IANA répertorie toujours 22 / udp et répertorie à la fois udp et tcp pour la plupart des protocoles qui ne sont généralement implémentés que sur l'un d'entre eux. Cela pourrait-il simplement signifier que 22 est réservé à ssh au cas où quelqu'un voudrait implémenter ssh sur udp un jour?

— Stéphane Chazelas

Voir aussi la section 7.1 de rfc6335

— Stéphane Chazelas

Fondamentalement, c'est parce que c'était la tradition depuis le moment où les numéros de port ont commencé à être attribués jusqu'à environ 2011. Voir, par exemple, le § 7.1 «Principes passés» de la RFC 6335 :

Les ports TCP et UDP ont été attribués simultanément lorsque l'un ou l'autre a été demandé

Il est possible qu'ils ne soient pas alloués un jour, bien sûr, car les ports 1023 et inférieurs sont les "ports système", traités spécialement par la plupart des systèmes d'exploitation, et la plupart de cette plage est actuellement attribuée.

Et, au fait, HTTP / 3 fonctionne sur UDP. Bien qu'il puisse utiliser n'importe quel port UDP, pas seulement 80/443. Donc, vraiment, ils ne sont toujours pas utilisés.

En ce qui concerne Debian, elle /etc/servicesavait déjà 22 / udp en 1.0 (buzz 1996) .

Il a cependant été supprimé dans ce commit en 2016, d'abord publié dans la version 5.4 du netbasepackage.

Au moment de l'écriture, la dernière version stable de Debian (buster) a 5.6 . Et le dernier paquet Ubuntu LTS (18.04, bionique) netbase est basé sur Debian netbase 5.4 et vous pouvez voir que son changelog mentionne également la suppression d'udp / 22 .

— derobert
source

@SergiyKolodyazhnyy Je ne pense pas, car cette pratique est antérieure aux pare-feu.

— derobert

@TobySpeight Ce n'est pas seulement Linux, cela fait partie des normes pertinentes. Voir, par exemple, le §6 de cette RFC. Bien que l'IANA enregistre également des ports plus élevés, leur classification est différente (et cela compte dans la pratique en raison de la façon dont les systèmes d'exploitation, pas seulement Linux, les traitent). Je vais clarifier cela un peu. De plus, 0 n'est pas un port valide. Il est utilisé par l'API sockets en tant que caractère générique (pour indiquer au noyau de choisir un port pour vous).

— derobert

"0 n'est pas un port valide" est discutable. Ce n'est certainement pas un port utilisable sur notre système d'exploitation (c'est pourquoi je l'ai appelé spécifiquement, et pourquoi il est actuellement réservé et peu susceptible d'être attribué à quoi que ce soit), mais ce n'est pas spécial au niveau du protocole.

— Toby Speight

@derobert: Votre argument est que le port 0 est inutilisable sur les machines Unix car le port 0 signifie "choisissez un port libre". Je dis que l'argument est faux. La conclusion ne découle pas logiquement de la prémisse.

— MSalters le

Bien qu'il puisse utiliser n'importe quel port UDP, pas seulement 80/443 C'est essentiellement vrai pour tout protocole TCP / UDP, ce ne sont que les ports par défaut associés à chacun. La plupart des applications qui utilisent TCP et UDP ne fournissent pas un moyen de spécifier des ports autres que ceux par défaut, mais HTTP permet de les spécifier dans des URL, il est donc plus possible de faire varier le port.

— Barmar