Est-il vrai que TCP est l'abréviation de TCP / IP et signifie-t-il la même chose?
Est-il possible que TCP soit construit sur un autre protocole que IP ?
Est-il vrai que TCP est l'abréviation de TCP / IP et signifie-t-il la même chose?
Est-il possible que TCP soit construit sur un autre protocole que IP ?
Réponses:
TCP et IP (v4 et v6) sont définitivement séparables, et l'un n'implique pas l'autre, comme le prouve l'exemple de TCP sur IPX ( RFC 1791 ).
Cependant, TCP ne peut pas être construit sur n'importe quel protocole réseau. Deux raisons:
La spécification TCP, RFC 793 , n’est pas une bonne source pour décider cette question, car elle admet qu’elle laisse son interface avec la couche inférieure en grande partie non spécifiée.
Note a) Pour que TCP puisse réassembler des datagrammes imprimés sur de petites feuilles de papier (transportés par des pigeons ou par un réseau corvid plus intelligent), la taille de la charge utile devrait être écrite à un emplacement standard. Alternativement, une couche d'adaptation pourrait déterminer de manière heuristique la taille du segment. Le scanner optique utilisé dans la mise en œuvre de la pile hôte de la spécification des porteuses aviaires ( RFC 1149 ) comprenait une telle couche d’adaptation heuristique, mais elle n’a pas été documentée.
Je n'ai pas lu l'intégralité de la RFC, mais le libellé de la section 1.4 semble suggérer que tout protocole de "niveau inférieur" peut être utilisé.
L’interface entre le protocole TCP et le protocole de niveau inférieur est essentiellement non spécifiée, sauf qu’il est supposé qu’il existe un mécanisme permettant aux deux niveaux de se passer de manière asynchrone des informations. Généralement, on s'attend à ce que le protocole de niveau inférieur spécifie cette interface. TCP est conçu pour fonctionner dans un environnement très général de réseaux interconnectés. Le protocole de niveau inférieur utilisé dans ce document est le protocole Internet.
TCP n'est pas un raccourci pour TCP / IP.
TCP / IP est souvent utilisé comme un raccourci pour dire " La suite de protocoles Internet " et inclut généralement d’autres protocoles standard. Quand les gens disent TCP / IP, ils incluent généralement UDP sur IP (UDP est utilisé à la place de TCP) et de nombreux autres protocoles tels que ARP, ICMP, DNS, SNMP et autres protocoles de couche application.
Les applications utilisent des protocoles de couche application tels que SMTP (pour le courrier électronique). Ceux-ci reposent sur l'un des deux protocoles de couche de transport - TCP et UDP. Quelques protocoles de couche application utiliseront UDP et TCP, ou les deux, mais la plupart sont utilisés avec un seul protocole de couche de transport.
TCP et UDP sont deux protocoles de couche de transport utilisés dans Internet Protocol Suite. S'il y en a d'autres, je ne les connais pas et d'autres constitueraient une utilisation extrêmement réduite. D'autres protocoles de couche de transport ont été définis - leur utilisation ne représente probablement qu'une faible proportion du trafic IP mondial †
Bien qu'il soit théoriquement possible d'utiliser TCP sur autre chose que IP, en pratique, TCP est toujours utilisé sur IP - le protocole Internet. IP déplace les paquets entre les réseaux (pensez à IP comme connectant plusieurs réseaux locaux ensemble)
Ethernet n’est que la famille la plus répandue de protocoles de couche liaison de bas niveau sur lesquels TCP / IP est acheminé, mais TCP / IP est également largement utilisé sur les systèmes ATM et autres.
Les seuls protocoles de la couche de transport utilisés de manière significative sur les réseaux qui utilisent Internet Protocol Suite sont TCP et UDP.
† Juste pour le plaisir, j’ai mesuré le trafic sur mon (très) petit réseau local, qui comprend NetBIOS (sur TCP), SSH, Rsync, courrier électronique, mises à jour logicielles, DNS, bavardage général de la boîte Windows et quelques autres types de trafic.
Notez également cette déclaration dans la FAQ de Google pour leur protocole QUIC
Pourquoi n'avez-vous pas créé un tout nouveau protocole, plutôt que d'utiliser UDP? Les boîtiers centraux sur Internet aujourd'hui bloquent généralement le trafic sauf s'il s'agit d'un trafic TCP ou UDP
(mon emphase)
La raison pour laquelle TCP / IP est une abréviation si courante (par opposition à, UDP / IP ou SCTP / IP) est due au fait que les deux protocoles ont été conçus ensemble, et dans le document original de Vint Cerf et Bob Kahn, les deux concepts étaient: combinés ensemble dans un protocole unique. Peu de temps après, ils ont été divisés en IP pour fournir le routage et TCP pour le contrôle de flux, le multiplexage, la détection d'erreur, etc. Ce n'est que six ans plus tard qu'UDP a été introduit pour fournir une couche de multiplexage "légère" sans le reste de la overhead impliqué avec TCP.
Néanmoins, TCP et IP sont deux choses distinctes et totalement et intentionnellement indépendantes. Le fait que TCP ne nécessite pas IP est immédiatement apparent avec le fait que TCP peut s'exécuter sans modification sur IPv4 et IPv6, qui sont deux protocoles complètement différents.
Avec un peu de travail, vous pourriez créer un protocole IP concurrent qui aurait les mêmes objectifs, mais il devrait probablement contenir la plupart sinon toutes les mêmes fonctionnalités, et finirait probablement par ressembler beaucoup à IP. Vous pouvez faire valoir que les extensions IP (telles que IPSec) sont en réalité des protocoles de couche 3 alternatifs.
Vous pouvez remplacer IP par quelque chose d'autre. En fait, c'est exactement ce que vous faites lorsque vous utilisez TCP sur IPv6. TCP est toujours TCP, mais l'IP est v6 au lieu de v4.
Autant que je sache, personne n’a créé d’autres protocoles de couche 3 pour travailler avec TCP au-dessus d’eux, mais rien ne nous en empêche.
TCP et IP sont comme du beurre sur du pain.
Vous pouvez associer tout ce qui fonctionne avec l'un ou l'autre protocole, mais ces deux systèmes sont si complémentaires qu'il ne s'agit que d'un moyen fiable et délicieux de transférer des données et de remplir le ventre de données Internet. Il lubrifie le tube pour permettre à d’autres aliments secs et au transfert de données de prendre en charge cet appariement. Mais ce n'est en aucun cas exclusif.
Q Cependant, n'est-il pas possible que TCP soit construit sur un autre protocole que IP?
A oui c'est possible. J'aime le code Morse et les exemples Pigeon de TCP sans IP.
J'ai toujours entendu dire que TCP est un raccourci pour TCP / IP
En fait, il s’agit de Transmission Control Protocol over Internet Protocol
et ils veulent dire la même chose.
Ce n'est pas correct
Premièrement, Ethernet est le système matériel de bas niveau qui contrôle le fonctionnement des pièces matérielles réelles.
Ensuite, considérez l’ IP comme un système téléphonique ou des panneaux de signalisation. Il fournit le contrôle de base de la connexion du système deux points ensemble.
TCP, en revanche, ressemble plus à un agent de contrôle de la circulation ou du système de messagerie qui dirige les messages / voitures vers le bon point.
Pris dans leur ensemble, TCP / IP fournit un système de transfert fiable des données vers et depuis deux périphériques connectés.
Avec Internet, lorsque vous souhaitez envoyer ou recevoir des données, la partie IP du système est la partie qui contrôle l’établissement des connexions matérielles réelles avec les fils (ou les ondes sans fil). La partie TCP du système est le logiciel responsable de la collecte et de la fragmentation des données, de leur envoi, du réassemblage des données reçues, de la vérification des données et de leur renvoi si nécessaire.
Il existe d' innombrables explications avec des analogies et des détails techniques disponibles, en particulier sous forme vidéo . DifferenceBetween.net en a un particulièrement bon sur ce sujet précis .
Cependant, n'est-il pas possible que TCP soit construit sur un autre protocole que IP?
Oui, vous pouvez en effet créer un système alternatif à TCP utilisant IP. Jetez un coup d'œil à Internet Protocol Suite pour plus de détails.
> the fact that !TCP can go over IP does not necessarily mean TCP can go over !IP Huh?
psusi essaie d'être intelligent en utilisant "!" en tant que "non opérateur". Son commentaire doit être lu comme suit: "le fait qu'un élément non TCP puisse passer sur IP ne signifie pas nécessairement que TCP peut dépasser un élément non IP". Il est fait référence à la dernière phrase de votre réponse, qui montrait l'existence de "Systèmes alternatifs à TCP". Cependant, montrer qu'il existe des alternatives à TCP ne signifie pas nécessairement qu'il n'existe pas d'alternative à IP.
TCP est un protocole de couche 4. Il fournit une garantie de transport des données sous la forme d'un flux ordonné d'un processus sur un ordinateur à un autre processus sur le même ordinateur / un autre.
IP est un protocole de couche 3. Il assure le transport d'un hôte à un autre.
Dans la mesure où il existe un protocole permettant le transfert de données hôte à hôte, TCP fonctionnera.
Donc, TCP peut être implémenté sur n’importe quel protocole, mais, Nous n’avons fait que de l’IP. IP est simple et fait le travail.
Un autre protocole de couche 3 n'est pas nécessaire.
Lorsque vous concevez un réseau, vous devez choisir un ensemble de protocoles (qui sont essentiellement des ensembles de règles de communication entre machines), pour chacune des différentes "couches" (que vous pouvez imaginer sous différents niveaux d'abstraction, que les concepteurs de réseau aiment utiliser. garder à l'esprit lors de la création et de la combinaison de protocoles).
Version simplifiée: les protocoles sont comme des boîtes dans lesquelles nous mettons nos messages . Ces boîtes ont des tailles différentes et vous mettez votre message dans la plus petite, puis dans une boîte un peu plus grande, etc. Choisir un ensemble de protocoles revient à choisir le type de boîte que vous utiliserez, pour chaque " couche "qui entoure votre message.
TCP et IP sont des protocoles pour deux couches indépendantes, créées ensemble et utilisables ensemble. mais peut très bien être utilisé avec d'autres protocoles. Cela arrive assez souvent: vous pouvez utiliser IP avec un protocole non-TCP, ou TCP avec un protocole non-IP .
La raison pour laquelle TCP / IP est une abréviation si commune est que ces deux protocoles ont formé, ensemble, la base de l’Internet et ont été la clé de son succès .
(TCP et IP ont certaines fonctionnalités spécialement conçues pour fonctionner ensemble, ce dont se vantent souvent les puristes, mais ils ne vous empêchent pas vraiment de les interfacer avec d'autres protocoles)
Je pense qu'il est possible d'exécuter le transport TCP sur IPX, si vous voulez utiliser le mode rétro.
Cependant, n'est-il pas possible que TCP soit construit sur un autre protocole que IP?
Outre les protocoles classiques TCP / IPv4 et TCP / IPv6, quelques protocoles expérimentaux ont été conçus, par exemple:
Dans le cadre de nos efforts Net100 et Probe visant à améliorer les transferts de masse sur des réseaux à grande vitesse et à latence élevée, nous avons développé une version instrumentée et ajustable du protocole TCP s'exécutant sur UDP. Le transport de type TCP UDP sert de faisceau de test pour expérimenter des contrôles de type TCP au niveau de l’application, similaires à TReno.
Et iproxy: exécuter les services TCP sur UDP , ce qui est plus amusant:
iproxy comprend un proxy côté client et un proxy côté serveur qui permettent aux services TCP / IP arbitraires de s'exécuter sur un UDP de diffusion, de multidiffusion ou d'unicast. Il a été conçu à l’origine comme une méthode permettant de configurer des serveurs qui n’avaient pas reçu d’adresse IP sur le réseau local à l’aide d’une interface Web.
Vous voyez donc: TCP sur UDP unicast, et même TCP sur UDP broadcast ou multicast !
Autant que je sache, TCP / IPv4 et TCP / IPv6 bénéficient d'un déploiement important.
La réponse est non! Par exemple, il existe un ancien RFC décrivant TCP sur IPX: http://tools.ietf.org/html/rfc1791
Pour ceux dont la mémoire est courte, IPX était le protocole Novell Netware: http://en.wikipedia.org/wiki/Internetwork_Packet_Exchange
Des implémentations de TCP au-dessus de divers protocoles prenant en charge le transport d'un datagramme de base existent déjà. En fait, il n'est même pas nécessaire de spécifier les informations de routage (TCP n'a même pas besoin de l'adresse IP pour fonctionner, un simple lien serila avec un destinataire implicite suffirait).
Donc, vous avez TCP implémenté en haut de UDP (avantage: vous utilisez un seul port du côté "serveur", ou vous pouvez l’intégrer sur une connexion existante transportant divers canaux multiplexés). Seul le niveau IP fournit le routage, mais TCP n'en a pas besoin. Tout ce qui compte est que le concept de MTU soit fourni par la couche inférieure.
Cela permet au protocole de contourner les limitations de la traversée NAT sans avoir à enregistrer un port de traduction UPnP pour un hôte spécifique. Il permet un réglage indépendant du MTU et du MSS, optimisé pour chaque client plutôt que par chaque routeur partagé intermédiaire. D'autres protocoles de routage sont possibles (y compris pour la distribution via des réseaux de multidiffusion et de diffusion). Et vous avez le choix des mécanismes de sécurité.
Un exemple d'utilisation est Gogo6.net (qui implémente son canal de transport IPv6 sur une session TCP en utilisant une réimplémentation de TCP sur UDP v4 (il fonctionne sur la plupart des routeurs d'accès à domicile ne disposant toujours que d'une adresse IPv4 et ne prenant pas toujours en charge la méthode UPnP). ; sans qu'il soit nécessaire de le configurer par les utilisateurs utilisant un numéro de port constant spécifique à l'application, même lorsqu'il n'est pas en cours d'exécution)
D'autres exemples consistent à encapsuler TCP sur HTTP (ou HTTPS) version 1.1 avec son extension "streamed" native. La plupart des VPN autorisant les réseaux de pontage sur Internet feront de même. Le pont peut même encapsuler plusieurs protocoles: Ethernet, PPP, IPv4 et IPv6 (extension du segment LAN local ou Ethernet uniquement), NetBEUI / LanMan, découverte de routeur (au sein du réseau ponté), y compris en mode brut (autorisant DHCPv4 ou DHCPv6) dans le réseau ponté. HTTPS est utilisé car l'encapsulation via HTTPS permet également le cryptage et l'authentification pour établir et sécuriser le pont, mais n'exige pas d'authentification / cryptage de bout en bout pour les clients et les serveurs sur le réseau ponté, et parce que les routeurs sont hautement optimisés pour HTTP et HTTPS.
Il existe des exemples de systèmes de communication dans l'armée utilisant TCP mais pas IP puisque le chemin de communication est une connexion de type série qui n'est pas routée via des routeurs, etc. Si vous regardez un paquet TCP avant qu'il ne soit en-tête avec des champs IP, semble facilement possible de ne pas utiliser IP si votre protocole de "routage" est différent.