UDP est un protocole simple et a une portée spécifique. Il s’agit tout d’abord des interactions client-serveur et du multimédia. Cependant, la plupart des applications Internet nécessitent une transmission fiable et cohérente. UDP ne répond pas à ces exigences, un protocole différent est donc requis. Ce protocole s'appelle TCP et il est bête de somme L'Internet.

Bases de TCP

Le protocole TCP (Transmission Control Protocol) a été spécialement conçu pour fournir un flux d'octets fiable de bout en bout sur un réseau Internet peu fiable. Un réseau interconnecté diffère d'un réseau autonome dans la mesure où ses différentes sections peuvent avoir des topologies, des bandes passantes, des valeurs de latence, des tailles de paquets et d'autres paramètres très différents. Le développement de TCP s'est concentré sur la capacité du protocole à s'adapter aux propriétés de l'inter-réseau et à être résilient face à divers problèmes.

Le protocole TCP est décrit dans la RFC 793. Au fil du temps, diverses erreurs et inexactitudes ont été découvertes et, à certains égards, les exigences ont été modifiées. Description détaillée Ces clarifications et corrections sont données dans la RFC 1122. Les extensions de protocole sont données dans la RFC 1323.

Chaque machine prenant en charge le protocole TCP possède une entité de transport TCP, qui est soit une procédure de bibliothèque, un processus utilisateur ou une partie du noyau système. Dans les deux cas, l'entité de transport gère les flux TCP et l'interface avec la couche IP. L'entité TCP reçoit les flux de données utilisateur des processus locaux, les divise en morceaux ne dépassant pas 64 Ko (en pratique, ce nombre est généralement de 460 octets de données, ce qui leur permet d'être placés dans une trame Ethernet avec des en-têtes IP et TCP), et les envoie sous forme de datagrammes IP distincts. Lorsque les datagrammes IP contenant des données TCP arrivent sur la machine, ils sont transférés à l'entité TCP, qui reconstruit le flux d'octets d'origine. Par souci de simplicité, nous utiliserons parfois « TCP » pour désigner l'entité de transport TCP (partie logiciel) ou le protocole TCP (ensemble de règles). D'après le contexte, ce que l'on entend par là apparaîtra clairement. Par exemple, dans l'expression « L'utilisateur transmet des données TCP », l'entité de transport TCP est naturellement sous-entendue.

La couche IP ne garantit pas la livraison correcte des datagrammes, TCP doit donc surveiller les délais d'attente expirés et retransmettre les paquets si nécessaire. Parfois, les datagrammes arrivent dans le mauvais ordre. TCP est également responsable de la récupération des messages de ces datagrammes. Ainsi, TCP est conçu pour fournir la fiabilité que de nombreux utilisateurs souhaitent et que IP ne fournit pas.

Modèle de service TCP

Le service TCP est basé sur ce que l'on appelle des sockets (sockets ou points de terminaison) créés à la fois par l'expéditeur et le destinataire. Ils ont été abordés dans la section Berkeley Sockets. Chaque socket possède un numéro (adresse) composé de l'adresse IP de l'hôte et d'un numéro de 16 bits local à l'hôte appelé port. Un port dans TCP est appelé adresse TSAP. Pour accéder au service TCP, une connexion doit être explicitement établie entre un socket sur la machine émettrice et un socket sur la machine destinataire.

Une prise peut être utilisée pour plusieurs connexions simultanément. En d’autres termes, deux ou plusieurs connexions peuvent aboutir sur la même prise. Les connexions se distinguent par les ID de socket aux deux extrémités - (socket1, socket2). Nombres canaux virtuels ou d'autres identifiants ne sont pas utilisés.

Les numéros de port inférieurs à 1 024, appelés ports populaires, sont réservés par les services standards. Par exemple, tout processus souhaitant se connecter à un hôte pour transférer un fichier via FTP peut contacter le port 21 de l'hôte de destination et ainsi contacter son démon FTP. Une liste des ports populaires est fournie sur le site Web www.iana.org.

Nous pourrions, bien sûr, lier le démon FTP au port 21 au moment du démarrage, puis lier le démon telnet au port 23, etc. Cependant, si nous faisions cela, nous ne ferions que gaspiller de la mémoire avec des informations sur les démons qui, en fait, , ils sont inactifs la plupart du temps. Au lieu de cela, il est courant d'utiliser un seul démon, appelé inetd sous UNIX, qui communique avec plusieurs ports et attend la première connexion entrante. Lorsque cela se produit, inetd crée un nouveau processus et appelle le démon approprié pour gérer la requête. Ainsi, seul inetd est constamment actif, les autres ne sont appelés que lorsqu'il y a du travail pour eux. Inetd dispose d'un fichier de configuration spécial à partir duquel il peut en savoir plus sur les attributions de ports. Cela signifie que Administrateur du système peut configurer le système de manière à ce que les démons persistants soient associés aux ports les plus occupés (par exemple, 80) et que inetd soit associé au reste.

Quelques ports réservés
	Protocole	Usage
21	FTP	Transférer des fichiers
23	Telnet	Connexion à distance
25	SMTP	E-mail
69	TFTP	Le protocole de transfert de fichiers le plus simple
79	Doigt	Recherche d'informations sur l'utilisateur
80	HTTP	World Wide Web
110	POP-3	Accès à la messagerie à distance
119	NNTP	Groupes de discussion

Toutes les connexions TCP sont en duplex intégral et point à point. Le full duplex signifie que le trafic peut circuler dans des directions opposées en même temps. Une connexion point à point signifie qu'elle comporte deux points de terminaison. La diffusion et la multidiffusion ne sont pas prises en charge par TCP.

Une connexion TCP est un flux d'octets et non un flux de messages. Les frontières entre les messages ne sont pas conservées. Par exemple, si un processus d'envoi écrit quatre morceaux de données de 512 octets dans un flux TCP, ces données peuvent être transmises au processus de réception sous forme de quatre morceaux de 512 octets, deux morceaux de 1 024 octets, un morceau de 2 048 octets ou quelque chose du genre. autre. Le destinataire n'a aucun moyen de déterminer comment les données ont été écrites.

Les fichiers sur un système UNIX possèdent également cette propriété. Le programme qui lit le rail ne peut pas déterminer comment ce fichier a été écrit : bloc par bloc, octet par octet ou entièrement en une seule fois. Comme pour les fichiers Systèmes UNIX Les programmes TCP n'ont aucune idée ou ne se soucient pas du but des octets. Un octet pour eux n'est qu'un octet.

Une fois que TCP reçoit des données d'une application, il peut les envoyer en une seule fois ou les mettre en mémoire tampon pour envoyer une plus grande quantité de données à la fois, à sa guise. Cependant, une application nécessite parfois que les données soient envoyées immédiatement. Disons, par exemple, qu'un utilisateur se connecte à une machine distante. Après avoir saisi une commande et appuyé sur la touche Entrée, il est important que la ligne qu'il saisit soit immédiatement transmise à la machine distante, plutôt que d'être mise en mémoire tampon jusqu'à ce que la ligne suivante soit saisie. Pour forcer le transfert des données sans délai, une application peut définir l'indicateur PUSH.

Certaines applications plus anciennes utilisaient l'indicateur PUSH comme délimiteur de message. Bien que cette astuce fonctionne parfois, toutes les implémentations TCP ne transmettent pas l'indicateur PUSH à l'application réceptrice. De plus, si l'entité TCP reçoit plusieurs autres paquets de ce type avant que le premier paquet PUSH ne soit envoyé sur la ligne (c'est-à-dire que la ligne de sortie est occupée), l'entité TCP aura le droit d'envoyer toutes ces données sous forme d'un seul datagramme, sans les diviser en portions séparées.

La dernière fonctionnalité à mentionner du service TCP concerne les données urgentes. Lorsqu'un utilisateur interagissant avec un programme appuie de manière interactive sur Supprimer la clé ou Ctrl-C pour terminer un processus distant qui a démarré, l'application émettrice place les informations de contrôle dans le flux de données de sortie et les transmet au service TCP avec l'indicateur URGENT (urgent). Cet indicateur amène l'entité TCP à cesser d'accumuler des données et à libérer immédiatement tout ce dont elle dispose pour la connexion au réseau.

Lorsque des données urgentes arrivent à destination, l'application réceptrice est interrompue (c'est-à-dire « signalée » dans la terminologie UNIX), après quoi elle peut lire les données du flux d'entrée et rechercher parmi elles des données urgentes. La fin des données urgentes est marquée afin que l'application puisse reconnaître où elles se terminent. Le début des données urgentes n'est pas marqué. L'application devrait le comprendre toute seule. Ce circuit fournit un mécanisme de signalisation rudimentaire, laissant tout le reste à l'application.

Protocole TCP

Cette section abordera le protocole TCP en termes généraux. Dans la section suivante, nous aborderons l'en-tête du protocole, champ par champ.

Une propriété clé de TCP qui définit l'ensemble de la structure du protocole est que dans une connexion TCP, chaque octet possède son propre numéro de séquence de 32 bits. Dans les premières années d’Internet, la vitesse de transfert de données de base entre les routeurs sur des lignes louées était de 56 Kbps. Pour un hôte qui pompe constamment des données à toute vitesse, il faudrait plus d’une semaine pour que les numéros de séquence bouclent la boucle. Aux vitesses actuelles, les numéros de séquence peuvent s'épuiser très rapidement, nous y reviendrons plus tard. Des numéros de séquence distincts de 32 bits sont utilisés pour les accusés de réception et pour le mécanisme de fenêtre coulissante, qui seront également abordés plus tard.

Les entités TCP émettrices et réceptrices échangent des données sous forme de segments. Un segment se compose d'un en-tête fixe de 20 octets (plus une partie facultative), qui peut être suivi d'octets de données. La taille des segments est déterminée par le logiciel TCP. Il peut combiner les données obtenues à la suite de plusieurs opérations d'écriture en un seul segment ou, à l'inverse, répartir le résultat d'une écriture sur plusieurs segments. La taille des segments est limitée par deux limites. Premièrement, chaque segment, y compris l'en-tête TCP, doit tenir dans le champ de charge utile de 65 515 octets du paquet IP. Deuxièmement, chaque réseau possède une unité de transfert maximale (MTU) et chaque segment doit s'insérer dans la MTU. En pratique, la taille de l'unité de transmission maximale est typiquement de 1500 octets (ce qui correspond à la taille du champ de charge utile Ethernet), et définit ainsi la limite supérieure de la taille du segment.

Le principal protocole utilisé par les entités TCP est le protocole à fenêtre glissante. Lors de la transmission d'un segment, l'expéditeur démarre une minuterie. Lorsque le segment arrive à destination, l'entité TCP réceptrice renvoie un segment (avec des données s'il y a quelque chose à envoyer, ou sans données) avec le numéro

accusé de réception égal au numéro de séquence du prochain segment attendu. Si le délai d'accusé de réception expire, l'expéditeur renvoie le segment.

Bien que ce protocole semble simple, plusieurs détails doivent être examinés plus en détail. Les segments peuvent arriver dans le mauvais ordre. Ainsi, par exemple, il est possible que les octets 3072 à 4095 soient déjà arrivés, mais qu'un accusé de réception ne puisse pas être envoyé car les octets 2048 à 3071 n'ont pas encore été reçus. De plus, les segments peuvent rester si longtemps sur le réseau que l'expéditeur expire et les transmet à nouveau. Le segment retransmis peut inclure différentes plages de fragments, une administration très minutieuse sera donc nécessaire pour déterminer les numéros d'octets qui ont déjà été reçus correctement. Cependant, puisque chaque octet du flux est identifié de manière unique par son décalage, cette tâche est réalisable.

TCP doit être capable de traiter ces problèmes et de les résoudre efficacement. De nombreux efforts ont été consacrés à l'optimisation des performances des flux TCP. Dans la section suivante, nous aborderons plusieurs algorithmes utilisés dans diverses implémentations du protocole TCP.

En-tête de segment TCP

Chaque segment commence par un en-tête au format fixe de 20 octets. Il peut être suivi de champs supplémentaires. Après les champs supplémentaires, il peut y avoir jusqu'à 65 535 - 20 - 20 = 65 495 octets de données, les 20 premiers octets étant l'en-tête IP et les seconds l'en-tête TCP. Les segments ne peuvent pas contenir de données. De tels segments sont souvent utilisés pour transmettre des accusés de réception et des messages de contrôle.

Examinons l'en-tête TCP champ par champ. Les champs Receiver Port et Source Port sont des identifiants des points de terminaison de connexion locale. Le numéro de port ainsi que l'adresse IP de l'hôte forment un identifiant de point de terminaison unique de 48 bits. Une paire de ces identifiants, liés à la source et à la destination, identifie de manière unique la connexion.

Les champs Numéro de séquence et Numéro de confirmation font leur travail fonction régulière. Notez que le champ Numéro d'accusé de réception fait référence à l'octet suivant attendu, et non au dernier octet reçu. Les deux sont en 32 bits car chaque octet de données dans un flux TCP est numéroté.

Le champ Longueur de l'en-tête TCP contient la taille de l'en-tête TCP, exprimée en mots de 32 bits. Ces informations sont nécessaires car le champ Champs facultatifs, et avec lui l'intégralité de l'en-tête, peut être de longueur variable. Essentiellement, ce champ spécifie le décalage entre le début du segment et le champ de données, mesuré en mots de 32 bits. C'est la même chose que la longueur du titre.

Vient ensuite un champ de 6 bits inutilisé. Le fait que ce domaine ait survécu pendant un quart de siècle témoigne de la qualité de la conception du TCP.

Ceci est suivi de six indicateurs de 1 bit. Le bit URG est défini sur 1 lors de l'utilisation du champ Pointeur de données urgentes, qui contient le décalage d'octet entre le numéro de séquence d'octets actuel et l'emplacement des données urgentes. C'est ainsi que TCP implémente les messages d'interruption. Comme déjà évoqué, le protocole TCP assure uniquement la délivrance du signal utilisateur au destinataire, sans s'intéresser à la cause de l'interruption.

Si le bit ACK est défini sur 1, le champ Numéro d'accusé de réception contient des données significatives. DANS sinon ce segment ne contient pas d'accusé de réception et le champ Numéro d'accusé de réception est simplement ignoré.

Le bit PSH est essentiellement un indicateur PUSH qui indique à l'expéditeur de transmettre les données à l'application dès qu'elle reçoit le paquet, plutôt que de les stocker dans un tampon jusqu'à ce qu'il soit plein. (Le destinataire peut mettre en mémoire tampon pour une plus grande efficacité.)

Le bit RST est utilisé pour réinitialiser l'état d'une connexion qui, en raison d'une panne de l'hôte ou pour une autre raison, est devenue bloquée. Il est également utilisé pour rejeter un segment invalide ou une tentative de création de connexion. Si vous recevez un segment avec le bit RST activé, il y a un problème.

Le bit SYN est utilisé pour établir une connexion. Une demande de connexion a le bit SYN = 1 et le bit ACK = 0, ce qui signifie que le champ d'accusé de réception n'est pas utilisé. La réponse à cette requête contient un accusé de réception, donc les valeurs de ces bits sont : SYN= 1, ACK- 1. Ainsi, le bit SYN est utilisé pour indiquer les segments CONNECTION REQUEST et CONNECTION ACCEPTED, et le bit ACK est utilisé pour les distinguer les uns des autres.

Le bit FIN est utilisé pour terminer la connexion. Cela indique que l'expéditeur n'a plus de données à transmettre. Cependant, même après la fermeture de la connexion, le processus peut continuer à recevoir des données indéfiniment. Les segments avec les bits FIN et SYN ont des numéros de séquence pour garantir qu'ils sont exécutés dans le bon ordre.

Le contrôle de flux dans le protocole TCP s'effectue à l'aide d'une fenêtre glissante de taille variable. Le champ Taille de la fenêtre indique combien d'octets peuvent être envoyés après l'octet d'accusé de réception. La valeur du champ Taille de la fenêtre peut être nulle, ce qui signifie que tous les octets jusqu'à l'accusé de réception numéro 1 ont été reçus, mais que le destinataire rencontre actuellement des problèmes et ne peut pas encore recevoir les octets restants. L'autorisation de transmission ultérieure peut être obtenue en envoyant un segment avec la même valeur de champ Numéro d'accusé de réception et une valeur de champ Taille de fenêtre non nulle.

Dans certains protocoles, les accusés de réception de trames sont associés à des autorisations pour poursuivre la transmission. Cette relation est une conséquence de la taille de la fenêtre glissante rigidement fixée dans ces protocoles. Dans TCP, les accusés de réception sont séparés des autorisations de transmettre des données. Essentiellement, le récepteur pourrait dire : « J'ai reçu des octets allant jusqu'à k-ro, mais je ne veux pas continuer à recevoir des données pour le moment. » Cette division (exprimée sous la forme d'une fenêtre glissante de taille variable) donne au protocole une flexibilité supplémentaire. Nous aborderons cet aspect plus en détail ci-dessous.

Le champ Checksum est utilisé pour augmenter la fiabilité. Il contient une somme de contrôle de l'en-tête, des données et du pseudo-en-tête. Lors de l'exécution de calculs, le champ Somme de contrôle est défini sur zéro et le champ de données est complété par un octet zéro si sa longueur est un nombre impair. L'algorithme de somme de contrôle ajoute simplement tous les mots de 16 bits en complément à deux, puis calcule le complément de la somme entière. Par conséquent, lorsque le destinataire vérifie l'intégralité du segment, y compris le champ Somme de contrôle, le résultat doit être 0.

Le pseudo-en-tête contient les adresses IP source et de destination de 32 bits, le numéro de protocole pour TCP (6) et le nombre d'octets pour le segment TCP (y compris l'en-tête). L'inclusion d'un pseudo-en-tête dans la somme de contrôle TCP permet de détecter les paquets mal livrés, bien que cela brise la hiérarchie du protocole car les adresses IP qu'il contient appartiennent à la couche IP et non à la couche TCP. UDP utilise le même pseudo-en-tête pour la somme de contrôle.

Le champ Champs facultatifs fournit caractéristiques supplémentaires, non couvert par l'en-tête standard. À l'aide de l'un de ces champs, chaque hôte peut spécifier la taille maximale du champ de charge utile qu'il peut accepter. Plus la taille des segments utilisés est grande, plus l'efficacité est grande car elle réduit la surcharge des en-têtes de 20 octets, mais tous les hôtes ne peuvent pas accepter de très gros segments. Les hôtes peuvent communiquer entre eux la taille maximale du champ de charge utile lors de l'établissement de la connexion. Par défaut, cette taille est de 536 octets. Tous les hôtes doivent accepter les segments TCP de taille 536 + 20 = 556 octets. Chaque direction peut avoir sa propre taille maximale de champ de charge utile.

Pour les lignes avec des taux de transfert élevés et/ou une latence élevée, une fenêtre de 64 Ko est trop petite. Ainsi, pour une ligne TZ (44,736 Mbit/s), une fenêtre complète peut être transmise à la ligne en seulement 12 ms. Si le temps aller-retour est de 50 ms (typique pour un câble optique transcontinental), 3/4 du temps que l'expéditeur passera à attendre un accusé de réception. Lors de la communication par satellite, la situation sera encore pire. Taille plus grande Windows pourrait améliorer l'efficacité, mais le champ Taille de fenêtre de 16 bits ne le permet pas. La RFC 1323 a proposé un nouveau paramètre Window Scale, sur la valeur duquel deux hôtes pouvaient s'entendre lors de l'établissement d'une connexion. Ce nombre permet au champ Taille de la fenêtre d'être décalé jusqu'à 14 bits vers la gauche, permettant ainsi à la taille de la fenêtre de s'étendre jusqu'à 230 octets (1 Go). Actuellement, la plupart des implémentations du protocole TCP prennent en charge cette fonctionnalité.

Une autre option, proposée dans la RFC 1106 et désormais largement utilisée, consiste à utiliser le protocole de nouvelle tentative sélective au lieu du retour en arrière. Si la destination reçoit un segment défectueux, puis un grand nombre de un bon TCP normal finira par expirer et retransmettra tous les segments non reconnus, y compris ceux qui ont été reçus correctement. La RFC 1106 proposait l'utilisation d'accusés de réception négatifs (NAK) pour permettre au destinataire de demander un ou plusieurs segments. Une fois reçu, le destinataire peut accuser réception de toutes les données stockées dans le tampon, réduisant ainsi la quantité de données retransmises.

UDP (User Datagram Protocol) est un protocole de transport pour le transfert de données sans connexion sur les réseaux IP. Il s'agit de l'un des protocoles de couche transport les plus simples du modèle OSI. Son identifiant IP est 0x11.

UDP est couramment utilisé dans des applications telles que le streaming vidéo et jeux d'ordinateur, où la perte de paquets est autorisée, et demande répétée difficile ou non justifié, ou dans les applications de requête-réponse (par exemple, requêtes DNS), où créer une connexion nécessite plus de ressources que la renvoyer. En fait, les fonctions UDP se résument à des opérations de multiplexage et de démultiplexage, ainsi qu'à une simple vérification des erreurs dans les données. Ainsi, lors de l'utilisation de U DP, l'application interagit presque directement avec le protocole couche réseau IP.

UDP reçoit des messages de niveau d'application, ajoute les champs de numéro de port source et de destination pour le démultiplexage par le côté réception, ainsi que deux autres champs spéciaux, et transmet le segment résultant à la couche réseau. La couche réseau enveloppe le segment dans un datagramme et le transmet « si possible » à l'hôte de destination. Si ce dernier reçoit le segment avec succès, UDP transmet les données du segment au processus souhaité en utilisant le champ du numéro de port de destination. Par conséquent, UDP est censé effectuer un transfert de données sans connexion.

DNS est un exemple de protocole de couche application utilisant les services de protocole UDP. Lorsqu'une application DNS génère une requête, elle crée un message DNS et le transmet au protocole UDP.

Comparaison des protocoles UDP et TCP.

Si une application requiert une confirmation de la remise du message, elle utilise le protocole TCP. TCP divise le message en fragments taille plus petite, appelés segments. Ces segments sont numérotés séquentiellement et transmis au protocole IP, qui assemble ensuite les paquets. TCP garde une trace du nombre de segments envoyés à un hôte particulier par une application particulière. Si l'expéditeur ne reçoit pas de confirmation dans le délai certaine période temps, TCP considère ces segments comme perdus et les renvoie. Seule la partie perdue du message est renvoyée, et non la totalité du message.

Le protocole TCP au niveau du nœud de réception est chargé de réassembler les segments de message et de les transmettre à l'application appropriée.

FTP et HTTP sont des exemples d'applications qui utilisent TCP pour transmettre des données.

Protocole UDP effectue une livraison de données non garantie et ne demande pas de confirmation au destinataire. Protocole UDP préférable pour le streaming audio, vidéo et communication vocale basé sur le protocole IP (VoIP). Confirmer la livraison ne fera que ralentir le processus de transfert de données et une nouvelle livraison n'est pas recommandée. Un exemple d'utilisation du protocole UDP est la radio Internet.

Protocole ARP. Application.

ARP(Anglais) Protocole de résolution d'adresse- protocole de détermination d'adresse) - utilisé dans réseaux informatiques Protocole de bas niveau conçu pour déterminer l'adresse de couche liaison à partir d'une adresse de couche réseau connue. Ce protocole est devenu plus répandu en raison de l'omniprésence des réseaux IP construits sur Ethernet, puisque dans près de 100 % des cas, ARP est utilisé avec cette combinaison. La description du protocole a été publiée en novembre 1982 dans la RFC 826. ARP a été conçu pour le cas de la transmission de paquets IP sur un segment Ethernet. Où principe général, proposé pour ARP, peut et a été utilisé pour d'autres types de réseaux.

Il existe les types de messages ARP suivants : requête ARP et réponse ARP. Le système d'envoi utilise une requête ARP pour demander l'adresse physique du système de réception. La réponse (l'adresse physique de l'hôte de destination) se présente sous la forme d'une réponse ARP.

Avant qu'un paquet de couche réseau ne soit envoyé sur un segment Ethernet, la pile réseau vérifie le cache ARP pour voir si les informations requises sur l'hôte de destination y sont déjà enregistrées. S'il n'existe aucune entrée de ce type dans le cache ARP, une demande de diffusion ARP est effectuée. Cette requête pour les appareils sur le réseau a la signification suivante : « Quelqu'un connaît-il l'adresse physique de l'appareil qui possède l'adresse IP suivante ? Lorsque le destinataire avec cette adresse IP recevra ce paquet, il devra répondre : « Oui, c'est mon adresse IP. Mon adresse physique est : … » L’expéditeur mettra alors à jour son cache ARP et pourra transmettre l’information au destinataire.

Les entrées du cache ARP peuvent être statiques ou dynamiques. L'exemple donné ci-dessus décrit une entrée de cache dynamique. Vous pouvez également créer des entrées statiques dans la table ARP.

ARP a été initialement développé non seulement pour le protocole IP, mais est désormais principalement utilisé pour mapper les adresses IP et MAC.

Principe d'opération

Un nœud qui doit mapper une adresse IP à une adresse locale génère une requête ARP, l'insère dans une trame de protocole de couche liaison, en y indiquant une adresse IP connue, et diffuse la requête.

Tous les hôtes du réseau local reçoivent une requête ARP et comparent l'adresse IP qui y est spécifiée avec la leur.

S'ils correspondent, le nœud génère une réponse ARP, dans laquelle il indique son adresse IP et son adresse locale et l'envoie déjà dirigé, puisque dans la requête ARP l'expéditeur indique son adresse locale.

Protocoles TCP et UDP

Protocole de contrôle de transmission TCP

La communication orientée connexion peut utiliser une communication fiable, dans laquelle le protocole de couche 4 envoie des accusés de réception lorsque les données ont été reçues et demande une retransmission si les données ne sont pas reçues ou sont corrompues. Le protocole TCP utilise précisément une communication aussi fiable. TCP est utilisé dans les protocoles d'application tels que HTTP, FTP, SMTP et Telnet.

Le protocole TCP nécessite qu'une connexion soit ouverte avant qu'un message puisse être envoyé. L'application serveur doit faire ce qu'on appelle passif ouvert pour créer une connexion vers un numéro de port connu, et au lieu d'envoyer l'appel au réseau, le serveur attend les requêtes entrantes. L'application client doit faire actif ouvert En envoyant application serveur numéro de séquence de synchronisation (SYN) identifiant la connexion. L'application client peut utiliser un numéro de port dynamique comme port local.

Le serveur doit envoyer un accusé de réception (ACK) au client ainsi qu'un numéro de séquence du serveur (SYN). À son tour, le client répond par ACK et la connexion est établie.

Après cela, le processus d’envoi et de réception de messages peut commencer. Lorsqu'un message est reçu, un message ACK est toujours envoyé en réponse. Si le délai d'attente expire avant que l'expéditeur ne reçoive l'ACK, le message est mis en file d'attente pour la retransmission.

Les champs d'en-tête TCP sont répertoriés dans le tableau suivant :

En-tête TCP

Champ	Longueur	Description
Port source	2 octets	Numéro de port source
Port de destination	2 octets	Numéro de port de destination
Numéro de série	4 octets	Le numéro de séquence est généré par la source et utilisé par la destination pour réorganiser les paquets afin de créer le message d'origine et d'envoyer un accusé de réception à la source.
Numéro de confirmation	4 octets	Si le bit ACK du champ Contrôle est activé, ce champ contient le prochain numéro de séquence attendu.
Décalage des données	4 bits	Informations sur le début d'un paquet de données.
Réserve	6 bits	Réservé pour une utilisation future.
Contrôle	6 bits	Les bits de contrôle contiennent des drapeaux indiquant si les champs d'accusé de réception (ACK), d'indicateur d'urgence (URG), si la connexion doit être réinitialisée (RST), si le numéro de série de synchronisation (SYN) a été envoyé, etc. sont valides.
La taille de la fenêtre	2 octets	Ce champ spécifie la taille du tampon de réception. À l'aide de messages de confirmation, le destinataire peut informer l'expéditeur de la quantité maximale de données qu'il peut envoyer.
Somme de contrôle	2 octets	Somme de contrôle de l’en-tête et des données ; il détermine si le paquet a été corrompu.
Indicateur d'urgence	2 octets	Dans ce champ, l'appareil cible reçoit des informations sur l'urgence des données.
Possibilités	variable	Valeurs facultatives qui sont précisées si nécessaire.
Ajout	variable	Suffisamment de zéros sont ajoutés au champ de remplissage pour que l'en-tête se termine sur une limite de 32 bits.

TCP est un protocole complexe et chronophage en raison de son mécanisme d'établissement de connexion, mais il garantit la livraison des paquets sans que nous ayons à inclure cette fonctionnalité dans le protocole d'application.

Le protocole TCP possède des capacités de livraison fiables intégrées. Si le message n'est pas envoyé correctement, nous recevrons un message d'erreur. Le protocole TCP est défini dans la RFC 793.

UDP - Protocole de datagramme utilisateur

Contrairement à TCP, UDP est un protocole très rapide car il définit le strict minimum requis pour le transfert de données. Bien sûr, cela présente certains inconvénients. Les messages arrivent dans n'importe quel ordre, et celui envoyé en premier peut être reçu en dernier. La livraison des messages UDP n'est pas du tout garantie, le message peut être perdu et deux copies du même message peuvent être reçues. Le dernier cas se produit si deux routes différentes sont utilisées pour envoyer des messages à une seule adresse.

UDP ne nécessite pas d'ouverture de connexion et les données peuvent être envoyées dès leur préparation. UDP n'envoie pas de messages d'accusé de réception, des données peuvent donc être reçues ou perdues. Si un transfert de données fiable est requis lors de l'utilisation d'UDP, il doit être implémenté dans un protocole de niveau supérieur.

Alors, quels sont les avantages d’UDP, pourquoi un protocole aussi peu fiable pourrait-il être nécessaire ? Pour comprendre la raison de l'utilisation d'UDP, vous devez faire la distinction entre la transmission unidirectionnelle, la transmission par diffusion et la transmission multidiffusion.

Message monodiffusion envoyé d’un nœud à un seul autre nœud. C'est ce qu'on appelle également la communication point à point. Le protocole TCP ne prend en charge que la communication unidirectionnelle. Si un serveur doit communiquer avec plusieurs clients via TCP, chaque client doit établir une connexion car les messages ne peuvent être envoyés qu'à des hôtes uniques.

Diffuser signifie que le message est envoyé à tous les nœuds du réseau. Distribution de groupe (multidiffusion) est un mécanisme intermédiaire : des messages sont envoyés à des groupes de nœuds sélectionnés.

UDP peut être utilisé pour une communication unidirectionnelle lorsqu'une transmission rapide est requise, par exemple pour transmettre des données multimédias, mais les principaux avantages d'UDP concernent la diffusion et la multidiffusion.

Protocole de datagramme utilisateur - UDP

Protocole UDP est l'un des deux protocoles de couche transport utilisés dans la pile de protocoles TCP/IP. UDP permet à un programme d'application de transmettre ses messages sur un réseau avec une surcharge minimale associée à la conversion des protocoles de couche application en IP. Cependant, le programme d'application lui-même doit se charger de confirmer que le message a été remis à sa destination. L'en-tête du datagramme (message) UDP ressemble à celui illustré dans la figure 2.10.

Riz. 2.10. Structure d'en-tête de message UDP

L'unité de données du protocole UDP est appelée paquet UDP ou datagramme utilisateur. Un paquet UDP se compose d'un en-tête et d'un champ de données contenant le paquet de couche application. L'en-tête a un format simple et se compose de quatre champs de deux octets :

Port source UDP - numéro de port du processus d'envoi,

Port de destination UDP - numéro de port du processus destinataire,

Longueur du message UDP - longueur du paquet UDP en octets,

Somme de contrôle UDP - somme de contrôle du paquet UDP

Tous les champs d'un paquet UDP ne doivent pas être remplis. Si le datagramme envoyé n'attend pas de réponse, des zéros peuvent être placés à la place de l'adresse de l'expéditeur. Vous pouvez également refuser de calculer la somme de contrôle, mais veuillez noter que le protocole IP calcule la somme de contrôle uniquement pour l'en-tête du paquet IP, en ignorant le champ de données.

Les ports de l'en-tête définissent le protocole UDP comme un multiplexeur qui permet de collecter et d'envoyer les messages des applications à la couche de protocole. Dans ce cas, l'application utilise un port spécifique. Les applications communiquant sur le réseau peuvent utiliser différents ports, ce qui se reflète dans l'en-tête du paquet. Au total, 216 ports différents peuvent être définis. Les 256 premiers ports sont attribués aux services dits « bien connus », qui comprennent par exemple le port UDP 53, qui est attribué au service DNS.

Champ Longueur détermine la longueur totale du message. Champ Somme de contrôle sert à contrôler l’intégrité des données. Une application qui utilise le protocole UDP doit veiller à l'intégrité des données en analysant les champs Somme de contrôle et Longueur. De plus, lors de l'échange de données via UDP, le programme d'application lui-même doit se charger du suivi de la livraison des données au destinataire. Ceci est généralement réalisé en échangeant des confirmations de livraison entre les programmes d'application.

Les services UDP les plus connus sont le service de noms de domaine BIND et le système de fichiers distribués NFS. Revenant à l'exemple traceroute, ce programme utilise également le transport UDP. En fait, c'est le message UDP qui est envoyé au réseau, mais il utilise un port qui n'a pas de service, c'est pourquoi un paquet ICMP est généré, qui détecte le manque de service sur la machine réceptrice lorsque le paquet atteint enfin le appareil de destination.

Protocole de contrôle de transfert - TCP

Si la surveillance de la qualité de la transmission des données sur le réseau est importante pour une application, alors dans ce cas, le protocole TCP est utilisé. Ce protocole est également appelé protocole fiable, orienté connexion et orienté flux. Avant d'aborder ces propriétés du protocole, considérons le format du datagramme transmis sur le réseau (Figure 2.11). Selon cette structure, TCP, comme UDP, possède des ports. Les 256 premiers ports sont attribués à WKS, les ports 256 à 1024 sont attribués aux services Unix et le reste peut être utilisé à votre discrétion. Sur le terrain Numéro de séquence le numéro de paquet est défini dans la séquence de paquets qui constitue l'intégralité du message, suivi d'un champ d'accusé de réception Numéro de connaissance et d'autres informations de contrôle.

Riz. 2.11. Structure des paquets TCP

Le port source (SOURS PORT) occupe 2 octets, identifie le processus d'envoi ;

Le port de destination (DESTINATION PORT) occupe 2 octets, identifie le processus destinataire ;

Le numéro de séquence (SEQUENCE NUMBER) occupe 4 octets, indique le numéro d'octet, qui détermine le décalage du segment par rapport au flux de données envoyé ;

Le numéro confirmé (ACKNOWLEDGEMENT NUMBER) occupe 4 octets, contient le nombre maximum d'octets dans le segment reçu, augmenté de un ; c'est cette valeur qui sert de reçu ;

La longueur de l'en-tête (HLEN) est longue de 4 bits et indique la longueur de l'en-tête du segment TCP, mesurée en mots de 32 bits. La longueur de l'en-tête n'est pas fixe et peut varier en fonction des valeurs définies dans le champ Options ;

La réserve (RESERVED) occupe 6 bits, le champ est réservé pour une utilisation ultérieure ;

Les bits de code (CODE BITS) occupent 6 bits et contiennent des informations de service sur le type d'un segment donné, spécifié en mettant les bits correspondants de ce champ à un :

URG - message urgent ;

ACK - reçu pour le segment reçu ;

PSH - demande d'envoi d'un message sans attendre que le tampon soit rempli ;

RST - demande de restauration de la connexion ;

SYN - message utilisé pour synchroniser les compteurs de données transmises lors de l'établissement d'une connexion ;

FIN est un signe que le côté émetteur a atteint le dernier octet du flux de données transmis.

Une fenêtre (WINDOW) occupe 2 octets, contient la valeur déclarée de la taille de la fenêtre en octets ;

La somme de contrôle (CHECKSUM) prend 2 octets et est calculée par segment ;

Le pointeur d'urgence (URGENT POINTER) occupe 2 octets, est utilisé en conjonction avec le bit de code URG, indique fin des données, qui doit être accepté de toute urgence malgré le débordement de tampon ;

OPTIONS - ce champ a une longueur variable et peut être totalement absent, la taille maximale du champ est de 3 octets ; utilisé pour résoudre des problèmes auxiliaires, par exemple lors du choix de la taille maximale du segment ;

PADDING, un remplissage de longueur variable, est un champ factice utilisé pour amener la taille de l'en-tête à un nombre entier de mots de 32 bits.

La fiabilité de TCP réside dans le fait que la source de données répète l'envoi à moins qu'elle ne reçoive la confirmation du destinataire dans un certain délai qu'elle a été reçue avec succès. Ce mécanisme est appelé Conscience positive avec retransmission (PAR). Comme nous l'avons défini précédemment, l'unité de transmission (paquet de données, message, etc.) en termes TCP est appelée un segment. Il y a un champ de somme de contrôle dans l'en-tête TCP. Si les données sont endommagées pendant la transmission, le module qui sépare les segments TCP des paquets IP peut le déterminer à l'aide de la somme de contrôle. Le paquet endommagé est détruit et rien n'est envoyé à la source. Si les données n'ont pas été corrompues, elles sont transmises à l'assemblage de messages de l'application et un accusé de réception est envoyé à la source.

L'orientation de la connexion est déterminée par le fait qu'avant d'envoyer un segment de données, les modules TCP source et destination échangent des informations de contrôle. Cet échange s'appelle poignée de main(littéralement « poignée de main »). TCP utilise une négociation en trois phases :

La source établit une connexion avec la destination en lui envoyant un paquet avec l'indicateur Synchronize Sequence Numbers (SYN). Le numéro dans la séquence identifie le numéro de paquet dans le message d'application. Il n'est pas nécessaire que ce soit 0 ou un. Mais tous les autres numéros l'utiliseront comme base, ce qui permettra de récupérer les paquets dans le bon ordre ;

Le destinataire répond avec un numéro dans le champ d'accusé de réception SYN qui correspond au numéro défini par la source. De plus, le champ « numéro en séquence » peut également indiquer le numéro demandé par la source ;

La source confirme qu'elle a accepté le segment de destination et envoie la première donnée.

Graphiquement, ce processus est présenté dans la figure 2.12.

Riz. 2.12. Établir une connexion TCP

Une fois la connexion établie, la source envoie des données au destinataire et attend la confirmation de sa part qu'elles ont été reçues, puis renvoie les données, etc., jusqu'à la fin du message. Le message se termine lorsque le bit FIN est défini dans le champ flags, ce qui signifie « plus de données ».

La nature du protocole en continu est déterminée par le fait que SYN détermine le nombre de départ pour compter les octets transmis, et non les paquets. Cela signifie que si SYN était réglé sur 0 et que 200 octets ont été transmis, alors le nombre défini dans le paquet suivant sera 201 et non 2.

Il est clair que la nature du protocole en continu et l’exigence de confirmer la réception des données posent le problème de la vitesse de transfert des données. Pour résoudre ce problème, utilisez une « fenêtre » – un champ – fenêtre. L'idée d'utiliser window est assez simple : transmettre des données sans attendre la confirmation de leur réception. Cela signifie que la source transmet une certaine quantité de données égale à la fenêtre sans attendre la confirmation de sa réception, puis arrête la transmission et attend la confirmation. S'il reçoit une confirmation pour seulement une partie des données transmises, il commencera à transmettre une nouvelle partie à partir du numéro suivant celui confirmé. Ceci est illustré graphiquement dans la figure 2.13.

Riz. 2.13. Mécanisme de transmission de données TCP

DANS dans cet exemple la fenêtre est définie sur 250 octets de large. Cela signifie que le segment actuel est un segment avec un décalage SYN de 250 octets. Cependant, après avoir transmis la totalité de la fenêtre, le module TCP source a reçu un accusé de réception pour ne recevoir que les 100 premiers octets. Le transfert débutera donc à partir de 101 octets, et non de 251.

Ainsi, nous avons examiné toutes les propriétés de base du protocole TCP. Il ne reste plus qu'à nommer les applications les plus connues utilisées par TCP pour l'échange de données. Il s'agit principalement de TELNET et FTP, ainsi que Protocole HTTP qui est le coeur Mondial La toile.

Interrompons un peu la conversation sur les protocoles et tournons notre attention vers un composant aussi important de l'ensemble du système TCP/IP que les adresses IP.

Dans les réseaux informatiques, un port est le point final de communication dans le système d'exploitation. Le terme est également utilisé pour désigner les périphériques matériels, mais dans les logiciels, il s'agit d'une construction logique qui identifie un processus ou un type de service spécifique.

Un port est toujours associé à une adresse IP et un type d'hôte et complète ainsi l'attribution de l'adresse de session. Il est identifié pour chaque adresse et protocole à l'aide d'un numéro de 16 bits, communément appelé numéro de port. Des numéros de port spécifiques sont souvent utilisés pour identifier des services spécifiques. Parmi les milliers répertoriés, 1 024 numéros de port bien connus sont protégés par convention pour identifier des types spécifiques de services sur l’hôte. Les protocoles qui utilisent principalement des ports sont utilisés pour contrôler les processus (tels que le protocole de contrôle de transmission (TCP) et le protocole de datagramme utilisateur (UDP) de la suite de protocoles Internet).

Signification

Les ports TCP ne sont pas nécessaires sur les liaisons point à point directes où les ordinateurs à chaque extrémité ne peuvent exécuter qu'un seul programme à la fois. Ils sont devenus nécessaires à mesure que les machines sont devenues capables d'exécuter plus d'un programme à la fois et ont été connectées aux réseaux modernes à commutation de paquets. Dans le modèle architecture client-serveur les applications, les ports et les clients du réseau se connectent pour lancer le service, fournissent des services de multiplexage une fois que la communication initiale est associée à un numéro de port connu, et elle est libérée en basculant chaque instance de service de demande vers une ligne dédiée. Une connexion est établie avec un numéro spécifique, et grâce à cela, des clients supplémentaires peuvent être servis sans attendre.

Détails

Les protocoles de transfert de données - Transmission Control Protocol (TCP) et User Datagram Protocol (UDP) - sont utilisés pour indiquer le numéro de port de destination et la source dans leurs en-têtes de segment. Le numéro de port est un entier non signé de 16 bits. Il peut donc être compris entre 0 et 65535.

Cependant, les ports TCP ne peuvent pas utiliser le numéro 0. Le port source pour UDP est facultatif et une valeur de zéro signifie qu'il n'est pas présent.

Un processus communique ses canaux d'entrée ou de sortie via une socket Internet (un type de descripteur de fichier) à l'aide d'un protocole de transport, d'un numéro de port et d'une adresse IP. Ce processus est connu sous le nom de liaison et permet aux données d'être envoyées et reçues sur un réseau.

Le système d'exploitation est responsable de la transmission des données sortantes de tous les ports d'application vers le réseau, ainsi que du transfert des paquets réseau entrants (en mappant l'adresse IP et le numéro). Un seul processus peut être lié à une combinaison d’adresse IP et de port spécifique en utilisant le même protocole de transport. Des pannes d'application courantes, parfois appelées conflits de ports, se produisent lorsque plusieurs programmes tentent de communiquer avec les mêmes numéros de port sur la même adresse IP en utilisant le même protocole.

Comment sont-ils utilisés ?

Les applications qui implémentent des services partagés utilisent souvent des services spécialement réservés et bien liste célèbre Ports TCP et UDP pour recevoir les demandes de service des clients. Ce processus est connu sous le nom d'écoute et implique la réception d'une requête provenant d'un port connu et l'établissement d'une conversation individuelle entre le serveur et le client en utilisant le même numéro de port local. D'autres clients peuvent continuer à se connecter - ceci est possible car la connexion TCP est identifiée comme une chaîne composée de connexions locales et adresses distantes et les ports. Standard Ports TCP et UDP sont déterminés par accord sous le contrôle de l'Internet Assigned Numbers Authority (IANA).

Les services du réseau central (principalement WorldWideWeb) ont tendance à utiliser de petits numéros de port, inférieurs à 1 024. Dans de nombreux systèmes d'exploitation des privilèges spéciaux sont requis pour que les applications puissent s'y lier, car ils sont souvent considérés comme essentiels au fonctionnement des réseaux IP. En revanche, le client final de la connexion en utilise généralement un grand nombre, alloués à une utilisation à court terme, c'est pourquoi il existe des ports dits éphémères.

Structure

Les ports TCP sont codés dans l'en-tête du paquet du protocole de transport et peuvent être facilement interprétés non seulement par les ordinateurs émetteurs et récepteurs, mais également par d'autres composants de l'infrastructure réseau. En particulier pare-feu, sont généralement configurés pour distinguer les paquets en fonction de leurs numéros de port source ou de destination. La redirection en est un exemple classique.

La pratique consistant à essayer de se connecter à une série de ports de manière séquentielle sur un seul ordinateur est connue sous le nom d'analyse des ports. Cela est généralement dû soit à des tentatives de perturbation malveillantes, soit à des administrateurs réseau recherchant d'éventuelles vulnérabilités pour empêcher de telles attaques.

Activités qui se concentrent sur la fréquence à laquelle les ordinateurs sont surveillés et enregistrés. Cette technique utilise un certain nombre de connexions de rechange pour garantir une connexion ininterrompue au serveur.

Exemples d'utilisation

L'exemple le plus important où les ports TCP/UDP sont activement utilisés est le système de messagerie Internet. Le serveur est utilisé pour travailler avec le courrier électronique (envoi et réception), et nécessite en général deux services. Le premier service est utilisé pour le transport via e-mail et autres serveurs. Ceci est réalisé en utilisant Généralement, l'application de service SMTP écoute sur le port TCP numéro 25 dans le but de traiter les demandes entrantes. Un autre service est POP (Post Office Protocol) ou IMAP (ou Internet Message Access Protocol) qui est requis pour que les applications client de messagerie sur les machines des utilisateurs reçoivent des messages du serveur. E-mail. Les services POP écoutent les numéros sur le port TCP 110. Les services ci-dessus peuvent tous deux s'exécuter sur le même ordinateur hôte. Lorsque cela se produit, le numéro de port distingue le service demandé appareil distant- Le PC de l'utilisateur ou tout autre serveur de messagerie.

Alors que le numéro de port d'écoute du serveur est correctement défini (l'IANA les appelle ports connus), ce paramètre le client est souvent sélectionné dans une plage dynamique. Dans certains cas, les clients et le serveur utilisent séparément des ports TCP spécifiques attribués dans l'IANA. Un bon exemple est DHCP, où le client utilise UDP 68 dans tous les cas et le serveur utilise UDP 67.

Utilisation dans les URL

Les numéros de port sont parfois clairement visibles sur Internet ou sur d'autres URL (Uniform Resource Locators). Par défaut, HTTP utilise et HTTPS utilise 443. Cependant, il existe d'autres variantes. Par exemple, l'URL http://www.example.com:8080/path/ indique que le navigateur Web se connecte au 8080 au lieu du serveur HTTP.

Liste des ports TCP et UDP

Comme indiqué, l'IANA (Internet Assigned Numbers Authority) est responsable de la coordination mondiale de la racine DNS, de l'adressage IP et d'autres ressources de protocole Internet. Cela inclut la journalisation des numéros de port fréquemment utilisés pour les services Internet bien connus.

Les numéros de port sont divisés en trois plages : connus, enregistrés et dynamiques ou privés. Les plus connus (également appelés système) sont ceux numérotés de 0 à 1023. Les exigences pour les nouveaux rendez-vous dans cette plage sont plus strictes que pour les autres inscriptions.

Exemples bien connus

Exemples trouvés dans cette liste, inclure:

• Port TCP 443 : HTTP sécurisé (HTTPS).
• 22 : Shell sécurisé (SSH).
• 25 : Protocole de transfert de courrier simple (SMTP).
• 53 : Système de noms de domaine (DNS).
• 80 : Protocole de transfert hypertexte (HTTP).
• 119 : Protocole de transfert de nouvelles sur le réseau (NNTP).
• 123 : Protocole de temps réseau (NTP).
• 143 : Protocole d'accès aux messages Internet (IMAP)
• 161 : Protocole de gestion de réseau simple (SNMP)1.
• 94 : Chat par relais Internet (IRC).

Les ports enregistrés vont de 1 024 à 49 151. L'IANA tient à jour une liste officielle des plages connues et enregistrées. Dynamique ou Privé - 49152 à 65535. Une utilisation de cette plage concerne les ports temporaires.

Histoire de la création

Le concept de numéro de port a été créé par les premiers développeurs d'ARPANET dans le cadre d'une collaboration informelle entre les auteurs de logiciels et les administrateurs système.

Le terme « numéro de port » n’était pas encore utilisé à cette époque. Ligne numérique pour hôte distantétait un nombre de 40 bits. Les 32 premiers bits étaient similaires à l'adresse IPv4 actuelle, mais les 8 premiers bits étaient les plus significatifs. La plus petite partie du nombre (bits 33 à 40) représentait un autre objet appelé AEN. C'est le prototype du numéro de port moderne.

Le 26 mars 1972, la création d'un répertoire de numéros de socket a été proposée pour la première fois dans la RFC 322, qui appelait à ce que chaque numéro persistant soit décrit en termes de ses fonctions et services réseau. Ce répertoire a ensuite été publié dans la RFC 433 en décembre 1972 et comprenait une liste d'hôtes, leurs numéros de port et la fonction correspondante utilisée sur chaque nœud du réseau. En mai 1972, les attributions officielles de numéros de port ont été documentées pour la première fois, services réseau, et a également proposé une fonction administrative spéciale pour la tenue de ce registre.

La première liste de ports TCP contenait 256 valeurs AEN, réparties dans les plages suivantes :

• De 0 à 63 : caractéristiques standards tout le réseau
• 64 à 127 : Fonctions spécifiques à l'hôte
• 128 à 239 : Réservé pour une utilisation future
• 240 à 255 : Toute fonctionnalité expérimentale.

Le service Telnet a reçu la première attribution officielle de la valeur 1. Au début d'ARPANET, le terme AEN faisait également référence au nom de la socket utilisée avec le protocole de connexion d'origine (MSP) et le programme de contrôle du réseau (NCP). ) composant. De plus, NCP était le prédécesseur des protocoles Internet modernes utilisant les ports TCP/IP.