Désolé, mais quand un protocole calcule des choses sur des octets pas de sa couche (au hasard : l'en-tête IPv4)
Ca va être compliqué de valider la cohérence d'un paquet sans le lire. Il est obligatoire pour TCP de lire les octets sur la couche qu'il controle - Si le but de TCP était simplement de garantir que la capsule TCP elle même est valide ca serait plus simple (mais vachement moins interressant). Donc TCP doit lire les infos de la couche inférieure pour faire un CRC dessus, c'est la seule manière de la controller.
et c'est bien ça que j'appelle "TCPv4" dans le sens où TCP est dépendant de sa couche inférieure
Il n'est pas dépendant de la couche inférieure. Certes les octets sous jacents choisis pour le controle l'ont été avec IP en tête, mais rien n'empêche de faire passer d'autres flux en controle TCP (pour que ca serve à quelque chose il faut juste que les octets en question soient relativement significatifs de l'état du paquet. En IPv6 ca n'est pas le cas - et c'est une connerie dans la façon dont l'entête IPv6 a été créée).
On évitera de parler du protocole qui balance un autre protocole si il a envie, hein…
Tu peux m'expliquer ce que fout ICMP à signifier que la connexion est injoignable ? C'est une couche transport ICMP ? Ca te semble logique comme comportement que si le port existe TCP renvoit un ACK, mais que si il n'existe pas c'est ICMP qui renvoit un bricolage plus ou moins fiable en fonction du modèle du routeur, de l'OS du serveur et du sens du vent ? Je cherche à établir une connexion IP et au moment de la négo TCP c'est un message ICMP qui m'est renvoyé ? Le plus logique serait que je me prenne un TCP RST systématiquement et que si je veux vraiment savoir ce qui se passe, libre à moi de balancer des paquets ARP ou ICMP.
[^] # Re: commentaire bookmark
Posté par Kaane . En réponse au journal Mega reprend le flambeau.. Évalué à 5.
Désolé, mais quand un protocole calcule des choses sur des octets pas de sa couche (au hasard : l'en-tête IPv4)
Ca va être compliqué de valider la cohérence d'un paquet sans le lire. Il est obligatoire pour TCP de lire les octets sur la couche qu'il controle - Si le but de TCP était simplement de garantir que la capsule TCP elle même est valide ca serait plus simple (mais vachement moins interressant). Donc TCP doit lire les infos de la couche inférieure pour faire un CRC dessus, c'est la seule manière de la controller.
et c'est bien ça que j'appelle "TCPv4" dans le sens où TCP est dépendant de sa couche inférieure
Il n'est pas dépendant de la couche inférieure. Certes les octets sous jacents choisis pour le controle l'ont été avec IP en tête, mais rien n'empêche de faire passer d'autres flux en controle TCP (pour que ca serve à quelque chose il faut juste que les octets en question soient relativement significatifs de l'état du paquet. En IPv6 ca n'est pas le cas - et c'est une connerie dans la façon dont l'entête IPv6 a été créée).
On évitera de parler du protocole qui balance un autre protocole si il a envie, hein…
Tu peux m'expliquer ce que fout ICMP à signifier que la connexion est injoignable ? C'est une couche transport ICMP ? Ca te semble logique comme comportement que si le port existe TCP renvoit un ACK, mais que si il n'existe pas c'est ICMP qui renvoit un bricolage plus ou moins fiable en fonction du modèle du routeur, de l'OS du serveur et du sens du vent ? Je cherche à établir une connexion IP et au moment de la négo TCP c'est un message ICMP qui m'est renvoyé ? Le plus logique serait que je me prenne un TCP RST systématiquement et que si je veux vraiment savoir ce qui se passe, libre à moi de balancer des paquets ARP ou ICMP.