Aller au contenu principal

3. Background (Contexte)

3. Background (Contexte)

Le protocole de contrôle de transmission (Transmission Control Protocol, TCP) [RFC0793] et le protocole de datagramme utilisateur (User Datagram Protocol, UDP) [RFC0768] ont connu un succès remarquable au fil des décennies en tant que les deux protocoles de transport les plus largement utilisés sur Internet. Ils se sont appuyés sur le concept de "ports" en tant qu'entités logiques pour la communication Internet. Les ports ont deux objectifs: premièrement, ils fournissent un identifiant de démultiplexage pour différencier les sessions de transport entre la même paire de points de terminaison, et deuxièmement, ils peuvent également identifier le protocole d'application et le service associé auquel les processus se connectent. Les protocoles de transport plus récents, tels que le protocole de transmission à contrôle de flux (Stream Control Transmission Protocol, SCTP) [RFC4960] et le protocole de contrôle de congestion de datagrammes (Datagram Congestion Control Protocol, DCCP) [RFC4342], ont également adopté le concept de ports pour leurs sessions de communication et utilisent des numéros de port 16 bits de la même manière que TCP et UDP (et UDP-Lite [RFC3828], une variante de UDP).

Les numéros de port sont le moyen original et le plus largement utilisé pour l'identification des applications et des services sur Internet. Les ports sont des nombres de 16 bits, et la combinaison des numéros de port source et de destination avec les adresses IP des systèmes terminaux communicants identifie de manière unique une session d'un protocole de transport donné. Les numéros de port sont également connus par leurs noms de service associés tels que "telnet" pour le numéro de port 23 et "http" (ainsi que "www" et "www-http") pour le numéro de port 80.

Toutes les parties impliquées —— les hôtes exécutant des services, les hôtes accédant aux services sur d'autres hôtes et les dispositifs intermédiaires (tels que les pare-feu et les NAT) qui restreignent les services —— doivent s'entendre sur le service correspondant à un port de destination particulier. Bien qu'il s'agisse en fin de compte d'une décision locale n'ayant de sens qu'entre les points de terminaison d'une connexion, il est courant que de nombreux services aient un port par défaut sur lequel ces serveurs écoutent généralement, lorsque cela est possible, et ces ports sont enregistrés par l'Internet Assigned Numbers Authority (IANA) via le registre des noms de service et des numéros de port [PORTREG].

Au fil du temps, l'hypothèse qu'un numéro de port particulier implique nécessairement un service particulier peut devenir moins vraie. Par exemple, plusieurs instances du même service sur le même hôte ne peuvent généralement pas écouter sur le même port, et plusieurs hôtes derrière la même passerelle NAT ne peuvent pas tous avoir un mappage pour le même port sur le côté externe de la passerelle NAT, que ce soit en utilisant des mappages de port statiques configurés manuellement par l'utilisateur ou des mappages de port dynamiques configurés automatiquement à l'aide d'un protocole de mappage de port comme le protocole de mappage de port NAT [NAT-PMP] ou le dispositif de passerelle Internet [IGD].

Les applications peuvent utiliser directement les numéros de port, rechercher des numéros de port basés sur des noms de service via des appels système tels que getservbyname() sur UNIX, rechercher des numéros de port en effectuant des requêtes pour des enregistrements DNS SRV [RFC2782] [DNS-SD], ou déterminer les numéros de port de diverses autres manières comme le multiplexeur de service de port TCP (TCP Port Service Multiplexer, TCPMUX) [RFC1078].

Les concepteurs d'applications et de protocoles au niveau applicatif peuvent demander à l'IANA un nom de service et un numéro de port attribués pour une application spécifique, et peuvent —— après attribution —— supposer qu'aucune autre application n'utilisera ce nom de service ou ce numéro de port pour ses sessions de communication. Les concepteurs d'applications ont également la possibilité de demander uniquement un nom de service attribué sans numéro de port fixe correspondant si leur application n'en nécessite pas, comme les applications qui utilisent des enregistrements DNS SRV pour rechercher dynamiquement les numéros de port au moment de l'exécution. Étant donné que l'espace de numéros de port est fini (et donc la conservation est un objectif important), l'alternative d'utiliser des noms de service au lieu de numéros de port est RECOMMANDÉE dans la mesure du possible.