|
Si un ordinateur envoie un paquet au niveau de la couche transport (TCP ou UDP) à un autre ordinateur sur Internet et qu'aucun processus n'écoute sur l'adresse du port de destination, le résultat dépend du protocole de transport utilisé :
TCP (Protocole de contrôle de transmission) :
* Échec de l'établissement de la connexion : TCP utilise une négociation à trois pour établir une connexion avant le transfert de données. Si le port de destination n'écoute pas (aucun processus serveur n'est lié à ce port), le serveur ne répondra pas à la demande SYN (synchronisation) du client. Le client finira par expirer après plusieurs tentatives de retransmission, entraînant un échec de connexion. L'application client recevra généralement une erreur indiquant que la connexion n'a pas pu être établie.
* Aucune donnée reçue : Même si une connexion était momentanément établie (très improbable), les données envoyées par le client ne seraient pas reçues ou traitées car il n'y a aucun processus sur le serveur pour gérer les données. Les paquets seront supprimés.
UDP (Protocole de datagramme utilisateur) :
* Rejet des paquets : UDP est un protocole sans connexion. L'ordinateur expéditeur envoie simplement le paquet à l'adresse IP et au port de destination. Si aucun processus n'écoute sur ce port, le noyau du système d'exploitation sur l'ordinateur récepteur rejettera simplement le paquet. Aucun message d'erreur ni notification n'est renvoyé à l'expéditeur. L’expéditeur ne sait peut-être même pas que le paquet a été perdu. L’application utilisant UDP devra gérer elle-même la perte potentielle de paquets.
Dans les deux cas :
* Aucun message d'erreur (généralement) : L'ordinateur expéditeur ne recevra généralement pas directement de message d'erreur dans le cas d'UDP. Pour TCP, le client recevra généralement une erreur de la pile TCP, mais celle-ci est souvent gérée en interne par les bibliothèques réseau et n'est pas directement exposée à l'application de manière facilement compréhensible.
* Règles de pare-feu : Les pare-feu sur la machine de destination peuvent également bloquer les paquets avant même qu'ils n'atteignent le noyau du système d'exploitation.
* Congestion du réseau : Même s'il existe un processus d'écoute, la congestion du réseau peut entraîner une perte de paquets. Ceci est différent du scénario décrit mais souligne que la perte de paquets n'est pas uniquement causée par un processus absent.
En résumé :le résultat principal est une perte de paquets et une tentative de connexion échouée (dans le cas de TCP). L'application émettrice devra peut-être implémenter des mécanismes de nouvelle tentative ou une gestion des erreurs pour résoudre ce problème. L'absence de processus d'écoute entraîne l'élimination du paquet sans accusé de réception.
|
