Pourquoi pas? J'ai peut-être déjà vu TCP sur du code morse.
soandos
2
Un exemple serait un tunnel ICMP, qui utilise TCP sur ICMP. Mais il est vrai qu’il n’est pas habituel de construire TCP sur une base autre que IP. C’est généralement la couche d’accès réseau qui utilise une gamme plus étendue de protocoles et de canaux (tels que les tambours bongo).
Monsieur Smith le
1
@TomWijsman Essayé un échec? D'après ce que j'ai compris, ils ont eu du mal à résoudre les problèmes et à assurer l'interopérabilité plutôt que de faire fonctionner TCP.
tylerl
2
@harper Avec un code Morse normal, 200 caractères / minute ne sont certainement pas inconnus pour les opérateurs expérimentés, et 100 c / min (20 min / min) est certainement réalisable pour la plupart des gens suffisamment expérimentés. Bien entendu, à ces vitesses, vous n'entendez pas vraiment chaque caractère, mais plutôt le son des mots. (On dit que la caractéristique d'un opérateur expérimenté est qu'il se souvient de la conversation, mais pas des mots utilisés.) J'imagine cependant que 100 caractères par minute espacés à une vitesse globale de 50 à 60 c / min seraient réalisables avec taux d'erreur de caractère négligeables.
un CVn
2
@harper Cela dépend de votre niveau de précision requis. Pour les discussions en grande partie (bavardage, en parlant de radio amateur), se tromper ici ou là n'est pas vraiment un problème, car le contexte compte plus que les mots exacts utilisés. Pour le trafic de télégrammes, les communications d’urgence / de détresse, etc., en particulier si le texte est chiffré, chaque mot, voire chaque caractère, doit être (non seulement reçu, mais également) copié correctement (et lisiblement). Notez que j'ai dit que 200 c / min n'est "pas inouï"; pas banal. 100 c / min est cependant assez courant sur les bandes de radioamateurs.
un CVn
Réponses:
16
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:
L'en-tête TCP ne contient pas de champ de taille de segment (uniquement le décalage de données, qui indique la taille de l'en-tête TCP). Par conséquent, TCP ne fonctionnera qu'avec un protocole de couche inférieure comprenant suffisamment d'informations pour calculer la taille du segment TCP (c'est-à-dire la taille de la charge utile du protocole de couche inférieure). Cette hypothèse est vraie pour IPv4 ( RFC 791 ), IPv6 ( RFC 2460 ) et IPX ( RFC 1791 ). Mais ce n'est pas vrai en général, par exemple, pas pour les transporteurs aviaires ( RFC 1149 ) (voir note a).
TCP est uniquement conçu pour fonctionner sur un protocole réseau sans connexion. TCP ne fonctionne effectivement pas sur certains protocoles de réseau en mode connexion (par exemple, le service à débit constant de l’ATM), car les deux fonctions de contrôle du taux de combat conduisent à des performances très mauvaises ou imprévisibles. Un autre exemple dégénéré est TCP sur un tunnel TCP.
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.
Techniquement précis (pour autant que je sache), minutieux, étayé par des références, clair et léger. Je donnerais ceci à une poignée de votes positifs.
Scott
2
L'exemple aviaire est lucide et hilarant!
john
88
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.
La propriété intellectuelle elle-même a été mise en œuvre sur de nombreuses technologies de réseau, même les pigeons voyageurs . Les oiseaux ont en fait été utilisés pour démontrer la livraison des paquets Ping ICMP, avec une perte de paquets de 55% (apparemment due à une erreur de l'opérateur) et des latences allant de une à deux heures. Il serait possible d’exécuter TCP en plus de cela, mais la configuration de la connexion demanderait beaucoup d’oiseaux ....
RBerteig
21
À propos du commentaire de RBerteig; Considérons un pigeon voyageur portant une carte mini-SDHC. Il y a la différence entre la latence et le débit. :-)
un CVn
16
@ MichaelKjörling Cela ne fonctionnerait pas avec la RFC 1149: "Le datagramme IP est imprimé, sur un petit rouleau de papier".
kmkaplan
4
@kmkaplan Sauf si le datagramme a été imprimé sur l'étiquette de la carte SDHC. C'est comme le cliché de plusieurs films - "oh, c'est en fait sur le disque dur!"
Jon Hanna
40
Il faudrait que le pare-feu soit percé de trous très volumineux pour permettre le passage des transporteurs aviaires.
squillman
76
Suite de 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.
Couche d'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.
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 †
Couche interréseau
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)
Couche d'interface réseau
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.
Annexe 1 - Note sur les protocoles de la couche de transport
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.
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
@StuartBlackler: Point intéressant, merci. Existe-t-il des sociétés (autres que TCP et UDP) qui ne relèvent pas de ce que j’appelais la catégorie "utilisation extrêmement restreinte par un spécialiste" et qui sont utilisées sur IP? Si je mesurais le trafic IP à un point d'échange Internet , quelle proportion des protocoles de la couche de transport serait autre que TCP ou UDP?
RedGrittyBrick
Prenons DCCP, par exemple, il s’agit toujours d’un nouveau protocole, mais j’imagine qu’au cours des prochaines années, de plus en plus d’applications utiliseront ce protocole. Raison pour laquelle je ne pense pas que cela soit encore courant, c'est parce que je ne pense pas qu'il soit pris en charge par Windows. Pensez-y comme UDP avec contrôle de congestion. Peut être très pratique pour de nombreuses applications telles que Skype et les jeux :) Jetez-y un œil. Pour répondre à votre question, il s'agit probablement d'un très petit montant pour le moment
Stuart Blackler le
@Rudi euh, vous devriez réaliser que ce n'est pas le modèle de référence OSI, et si vous vous en rendez compte, n'induisez pas les gens en erreur en leur faisant croire que c'est le cas. C'est le modèle / l'architecture TCP / IP ... Parfois, l'architecture TCP / IP est décrite avec la terminologie de l'OSI, le modèle de référence OSI. Mais les 4 couches montrées et avec ces noms, sont très bien TCP / IP, pas OSI. Aucun problème avec le post de red mais votre commentaire est au mieux trompeur.
Barlop
34
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.
Correct - la première version de TCP incluait la fonctionnalité IP. Peut-être une autre raison pour laquelle les gens disent «TCP / IP» est que, dans la grande majorité des cas, lorsque vous envoyez des données sur IP, vous voulez garantir que tout cela sera livré et dans le bon ordre, afin que vous utilisiez TCP. Par exemple, tout le trafic HTTP et FTP utilise TCP. Les données en temps réel constituent une catégorie d'exceptions. Skype, par exemple, utilise UDP, car vous préféreriez obtenir le dernier paquet dans une conversation plutôt que de tout arrêter pour en obtenir un que vous avez manqué.
Nathan Long
21
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.
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?
C'est un peu trompeur de dire que la propriété intellectuelle permet de "relier" deux points. IP fournit un moyen d'envoyer des paquets individuels discrets d'une machine à une autre; chaque paquet est indépendant de tous les autres. TCP donne l'illusion d'une connexion continue , qui est en réalité une séquence de paquets envoyés via IP.
Wyzard
4
IP n'est pas lié au matériel ni à la signalisation physique. Cela est géré par les technologies de bas niveau, par exemple Ethernet.
Wyzard
9
Il y a beaucoup de problèmes avec cette réponse et la question manque complètement. Premièrement, Ethernet n’est qu’un protocole de couche de liaison utilisé pour transporter l’IP. Il y en a beaucoup d'autres, et IP ne les connaît pas et ne s'en préoccupe pas. IP n'a rien à voir avec le matériel; c'est la couche de routage entre les réseaux, au-dessus du matériel utilisé pour les connecter. La question était de savoir si vous pouvez utiliser TCP sur autre chose que l'IP, pas si vous pouvez utiliser autre chose que TCP qui utilise IP (voir UDP pour un exemple de cela).
Psusi
3
@ Synetech, la question n'était pas "peut-on utiliser autre chose sur IP". C'était "peut-on utiliser TCP sur autre chose", c'est-à-dire sans IP.
Wyzard
2
> 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.
Lie Ryan
5
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.
Qu'en est-il d'IPv6? C'est juste IP. L'interface d'envoi et de réception d'un paquet reste la même. Donc, TCP peut utiliser la même fonction. Le système d'exploitation peut simplement remplacer le pointeur de fonction d'IPv4 et IPv6 et cela fonctionnerait toujours. Je ne suis pas sûr de ce que vous dites ici?
SurenNihalani
3
IPv6 et IPv4 sont similaires , avec des interfaces similaires pour les couches supérieures, mais certainement pas le même protocole et non strictement fonctionnellement équivalents.
Curiousguy
Vous pourriez aussi bien prétendre qu'UDP est le même protocole qu'IP , car ils offrent des interfaces extrêmement similaires aux couches supérieures: définissez des adresses de point de terminaison local et distant, envoyez et recevez des paquets ...
curiousguy
3
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)
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.
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.
Je sais que la réponse est ancienne, mais si possible, veuillez préciser votre réponse et éviter de poster des liens sous forme de réponses / source claires. si les liens ont disparu, votre réponse l'est aussi.
Lorenzo Von Matterhorn
2
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.
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.
la source
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é.
la source
Suite de 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.
Couche d'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.
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 †Couche interréseau
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)
Couche d'interface réseau
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.
Annexe 1 - Note sur les protocoles de la couche de transport
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
(mon emphase)
la source
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.
la source
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.
la source
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.
la source
En fait, il s’agit de Transmission Control Protocol over Internet Protocol
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 .
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.
la source
> 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.
la source
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)
la source
Je pense qu'il est possible d'exécuter le transport TCP sur IPX, si vous voulez utiliser le mode rétro.
la source
Outre les protocoles classiques TCP / IPv4 et TCP / IPv6, quelques protocoles expérimentaux ont été conçus, par exemple:
Presque TCP sur UDP (atou)
Et iproxy: exécuter les services TCP sur UDP , ce qui est plus amusant:
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 source
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
la source
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.
la source
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.
la source