[{"@context":"http:\/\/schema.org\/","@type":"BlogPosting","@id":"https:\/\/wiki.edu.vn\/all2fr\/wiki1\/protocole-de-controle-de-la-transmission-wikipedia\/#BlogPosting","mainEntityOfPage":"https:\/\/wiki.edu.vn\/all2fr\/wiki1\/protocole-de-controle-de-la-transmission-wikipedia\/","headline":"Protocole de contr\u00f4le de la transmission – Wikipedia","name":"Protocole de contr\u00f4le de la transmission – Wikipedia","description":"before-content-x4 Le Protocole de contr\u00f4le de la transmission ( TCP , Engl. Pour “Protocole de contr\u00f4le de transmission”) est un","datePublished":"2019-07-01","dateModified":"2019-07-01","author":{"@type":"Person","@id":"https:\/\/wiki.edu.vn\/all2fr\/wiki1\/author\/lordneo\/#Person","name":"lordneo","url":"https:\/\/wiki.edu.vn\/all2fr\/wiki1\/author\/lordneo\/","image":{"@type":"ImageObject","@id":"https:\/\/secure.gravatar.com\/avatar\/44a4cee54c4c053e967fe3e7d054edd4?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/44a4cee54c4c053e967fe3e7d054edd4?s=96&d=mm&r=g","height":96,"width":96}},"publisher":{"@type":"Organization","name":"Enzyklop\u00e4die","logo":{"@type":"ImageObject","@id":"https:\/\/wiki.edu.vn\/wiki4\/wp-content\/uploads\/2023\/08\/download.jpg","url":"https:\/\/wiki.edu.vn\/wiki4\/wp-content\/uploads\/2023\/08\/download.jpg","width":600,"height":60}},"image":{"@type":"ImageObject","@id":"https:\/\/upload.wikimedia.org\/wikipedia\/commons\/thumb\/b\/ba\/Tcp_verbindung.png\/220px-Tcp_verbindung.png","url":"https:\/\/upload.wikimedia.org\/wikipedia\/commons\/thumb\/b\/ba\/Tcp_verbindung.png\/220px-Tcp_verbindung.png","height":"149","width":"220"},"url":"https:\/\/wiki.edu.vn\/all2fr\/wiki1\/protocole-de-controle-de-la-transmission-wikipedia\/","wordCount":11837,"articleBody":"     (adsbygoogle = window.adsbygoogle || []).push({});before-content-x4Le Protocole de contr\u00f4le de la transmission ( TCP , Engl. Pour “Protocole de contr\u00f4le de transmission”) est un protocole de r\u00e9seau qui d\u00e9finit la fa\u00e7on dont les donn\u00e9es doivent \u00eatre \u00e9chang\u00e9es entre les composants du r\u00e9seau. Presque tous les syst\u00e8mes d’exploitation actuels des ordinateurs modernes ma\u00eetrisent TCP et les utilisent pour l’\u00e9change de donn\u00e9es avec d’autres ordinateurs. Le protocole est un diagramme fiable, orient\u00e9 vers la connexion, [d’abord] Protocole de transport dans les r\u00e9seaux informatiques. Il fait partie de la famille du protocole Internet, la base d’Internet.        (adsbygoogle = window.adsbygoogle || []).push({});after-content-x4TCP a \u00e9t\u00e9 d\u00e9velopp\u00e9 par Robert E. Kahn et Vinton G. Cerf. Son travail de recherche qui a commenc\u00e9 en 1973 a dur\u00e9 plusieurs ann\u00e9es. La premi\u00e8re normalisation du TCP n’a donc \u00e9t\u00e9 effectu\u00e9e qu’en 1981 RFC 793 . Apr\u00e8s cela, il y avait de nombreuses extensions qui sont encore sp\u00e9cifi\u00e9es dans les nouveaux RFC, un certain nombre de documents techniques et organisationnels sur Internet. RFC 9293 Bundles la version originale et toutes ses extensions en un seul document. Contrairement \u00e0 la charni\u00e8re UDP ( Anglais  Protocole de datagramme utilisateur ) \u00e9tablit TCP entre deux points d’extr\u00e9mit\u00e9 d’une connexion r\u00e9seau (sockets). Les donn\u00e9es peuvent \u00eatre transmises sur cette connexion dans les deux sens. Dans la plupart des cas, TCP s’appuie sur l’IP (Protocole Internet), c’est pourquoi il y a souvent (et souvent pas enti\u00e8rement correct) du “protocole TCP \/ IP”. Dans les piles de protocole telles que le mod\u00e8le OSI, TCP et IP ne sont pas situ\u00e9s sur la m\u00eame couche. TCP est une impl\u00e9mentation de la couche de transport. En raison de ses nombreuses propri\u00e9t\u00e9s positives (les pertes de donn\u00e9es sont reconnues et automatiquement corrig\u00e9es, la transmission des donn\u00e9es est possible dans les deux sens, la surcharge du r\u00e9seau est \u00e9vit\u00e9, etc.) Le TCP est un protocole tr\u00e8s r\u00e9pandu pour la transmission des donn\u00e9es. Par exemple, TCP a \u00e9t\u00e9 utilis\u00e9 depuis longtemps comme protocole de transport presque exclusif pour le www, le courrier \u00e9lectronique et de nombreux autres services de r\u00e9seau populaires. Dans le www, TCP obtient la concurrence de la Protocole de transport crypt\u00e9e, qui a \u00e9t\u00e9 standardis\u00e9e en 2021.        (adsbygoogle = window.adsbygoogle || []).push({});after-content-x4En principe, TCP est une connexion de bout en bout \u00e0 Vollduplex, qui permet la transmission des informations aux deux directions, analogues \u00e0 un appel t\u00e9l\u00e9phonique. Cette connexion peut \u00e9galement \u00eatre consid\u00e9r\u00e9e comme deux compos\u00e9s semi -duplex dans lesquels les informations peuvent s’\u00e9couler dans les deux directions (mais pas en m\u00eame temps). Les donn\u00e9es dans la direction oppos\u00e9e peuvent contenir des informations de contr\u00f4le suppl\u00e9mentaires. La gestion de cette connexion et la transmission de donn\u00e9es sont repris par le logiciel TCP. Le logiciel TCP est g\u00e9n\u00e9ralement situ\u00e9 dans la pile de protocole r\u00e9seau du syst\u00e8me d’exploitation. Les programmes d’application utilisent une interface, principalement des sockets qui (diff\u00e9rents du syst\u00e8me d’exploitation) sont utilis\u00e9s, par exemple, dans Microsoft Windows dans les biblioth\u00e8ques de programmes (“winsock.dll” ou “wsock32.dll”) \u00e0 faire. Linux et de nombreux autres syst\u00e8mes d’exploitation Unixoid contiennent une couche de base dans le noyau du syst\u00e8me d’exploitation. Les appels syst\u00e8me sont accessibles sur la couche de socket. Les applications que TCP utilisent souvent sont des navigateurs Web et des serveurs Web, par exemple. Chaque connexion TCP est clairement identifi\u00e9e par deux points d’extr\u00e9mit\u00e9. Un point final est un couple ordonn\u00e9 compos\u00e9 d’une adresse IP et d’un port. Un tel couple forme une interface logicielle bidirectionnelle et est \u00e9galement appel\u00e9 socket. Une connexion TCP est ainsi identifi\u00e9e par quatre valeurs (un quadruple): (Ordinateur local, port local, ordinateur distant, port distant) Cela d\u00e9pend de l’ensemble du quadruple. Par exemple, deux processus diff\u00e9rents sur le m\u00eame ordinateur peuvent utiliser le m\u00eame port local et m\u00eame communiquer avec le m\u00eame ordinateur du c\u00f4t\u00e9 oppos\u00e9, \u00e0 condition que les processus impliqu\u00e9s utilisent diff\u00e9rents ports \u00e0 l’autre. Dans un tel cas, ce serait deux connexions diff\u00e9rentes, dont le quadruble ne diff\u00e8re que par l’une des quatre valeurs: le port du c\u00f4t\u00e9 oppos\u00e9. Connexion 1: (ordinateur local, port x, ordinateur distant, port y)Connexion 2: (ordinateur local, port x, ordinateur distant, port z) Par exemple, un processus de serveur cr\u00e9e une base ( prise , lier ) au port 80, marquez-le pour les connexions entrantes ( \u00e9couter ) et appelle la prochaine connexion \u00e0 venir \u00e0 partir du syst\u00e8me d’exploitation ( accepter ). Cette exigence bloque initialement le processus du serveur car il n’y a toujours pas de connexion. Si la premi\u00e8re demande de connexion est ensuite re\u00e7ue par un client, elle est accept\u00e9e par le syst\u00e8me d’exploitation afin que la connexion soit \u00e9tablie. \u00c0 partir de maintenant, cette connexion est identifi\u00e9e par le quadruple d\u00e9crit ci-dessus.        (adsbygoogle = window.adsbygoogle || []).push({});after-content-x4Enfin, le processus du serveur est r\u00e9veill\u00e9 et une poign\u00e9e pour cette connexion est pr\u00e9sent\u00e9e. Habituellement, le processus du serveur d\u00e9marre alors un processus enfant auquel il d\u00e9l\u00e9gue le traitement de la connexion. Il \u00e9tablit ensuite son travail avec un autre Accepter -requette pour le syst\u00e8me d’exploitation.Cela permet \u00e0 un serveur Web d’accepter plusieurs connexions \u00e0 partir de diff\u00e9rents ordinateurs. Plusieurs \u00e9couter Il n’est pas possible sur le m\u00eame port. Habituellement, le programme c\u00f4t\u00e9 client ne d\u00e9termine pas le port lui-m\u00eame, mais peut le faire attribuer par le syst\u00e8me d’exploitation. Les ports sont des num\u00e9ros 16 bits (num\u00e9ros de port) et varient de 0 \u00e0 65535. Les ports de 0 \u00e0 1023 sont r\u00e9serv\u00e9s [2] et sont d\u00e9cern\u00e9s par l’IANA, par ex. B. Le port 80 est r\u00e9serv\u00e9 au HTTP utilis\u00e9 dans le www. L’utilisation des ports pr\u00e9d\u00e9finis n’est pas de liaison. Par exemple, chaque administrateur peut ex\u00e9cuter un serveur FTP (g\u00e9n\u00e9ralement le port 21) sur n’importe quel autre port.  Fig. 2: Gestion des connexions TCP en tant que machine finie Un serveur qui offre son service cr\u00e9e un point final (socket) avec le num\u00e9ro de port et son adresse IP. Ce sera passif ouvert [3] ou aussi comme \u00e9couter [4] d\u00e9sign\u00e9. Si un client veut \u00e9tablir une connexion, cela cr\u00e9e sa propre prise \u00e0 partir de son adresse informatique et du sien, toujours le num\u00e9ro de port libre. Une connexion peut ensuite \u00eatre \u00e9tablie \u00e0 l’aide d’un port et \u00e0 l’adresse du serveur connu. Une connexion TCP est clairement identifi\u00e9e par les 4 valeurs suivantes: Quell-IP-Adresse Casse-caisse Adresse Target-IP Port cible Pendant la phase de transfert de donn\u00e9es ( Open actif ) sont les r\u00f4les du client et du serveur (du point de vue du TCP) compl\u00e8tement sym\u00e9triques. En particulier, chacun des deux ordinateurs participants peut initier une r\u00e9duction de connexion. Table of ContentsConnexions demi-clos [ Modifier | Modifier le texte source ]] Connexions \u00e0 moiti\u00e9 ouvertes [ Modifier | Modifier le texte source ]] Connexion [ Modifier | Modifier le texte source ]] Connexion [ Modifier | Modifier le texte source ]] Bouffeur [ Modifier | Modifier le texte source ]] Manuel \u00e0 trois voies [ Modifier | Modifier le texte source ]] G\u00e9n\u00e9ral [ Modifier | Modifier le texte source ]] Explication [ Modifier | Modifier le texte source ]] Taille du segment TCP \/ IP [ Modifier | Modifier le texte source ]] Division des donn\u00e9es d’application aux segments TCP \/ IP [ Modifier | Modifier le texte source ]] Exemple de transfert de donn\u00e9es TCP \/ IP [ Modifier | Modifier le texte source ]] Minuterie de retransmission [ Modifier | Modifier le texte source ]] Connexion du contr\u00f4le de la rivi\u00e8re et du contr\u00f4le des embouteillages [ Modifier | Modifier le texte source ]] Contr\u00f4le de la rivi\u00e8re [ Modifier | Modifier le texte source ]] Contr\u00f4le de surcharge \/ contr\u00f4le des embouteillages (contr\u00f4le de la congestion) [ Modifier | Modifier le texte source ]] Algorithme pour le contr\u00f4le de la surcharge [ Modifier | Modifier le texte source ]] D\u00e9marrage lent et \u00e9vitement de la congestion [ Modifier | Modifier le texte source ]] Retransmit rapide et r\u00e9cup\u00e9ration rapide [ Modifier | Modifier le texte source ]] ACKS s\u00e9lectifs (sac) [ Modifier | Modifier le texte source ]] TCP-Tahoe und TCP-RENO [ Modifier | Modifier le texte source ]] Contr\u00f4le de surcharge comme domaine de recherche [ Modifier | Modifier le texte source ]] Connexions demi-clos [ Modifier | Modifier le texte source ]] La connexion peut \u00eatre r\u00e9duite en deux types: des deux c\u00f4t\u00e9s ou progressive. Dans cette derni\u00e8re variante, on parle d’une connexion \u00e0 demi-clos (\u00e0 ne pas confondre avec les connexions de demi-ouvre-open, voir ci-dessous). Il permet au c\u00f4t\u00e9 oppos\u00e9 de transmettre des donn\u00e9es apr\u00e8s la s\u00e9paration \u00e0 un seul facteur. Les connexions \u00e0 demi-clos sont un h\u00e9ritage du syst\u00e8me d’exploitation UNIX, dans la zone dont TCP a \u00e9t\u00e9 cr\u00e9\u00e9. Selon le principe Tout est un fichier (dt. \u201e Tout est un fichier \u00ab) UNIX prend en charge une interaction compl\u00e8tement analogique entre deux processus dans les connexions TCP: pour un programme, il devrait tout simplement \u00eatre non pertinent, qu’il se lise \u00e0 partir d’une connexion TCP ou d’un fichier. Un programme UNIX se lit g\u00e9n\u00e9ralement jusqu’\u00e0 la fin de l’entr\u00e9e par d\u00e9faut, puis \u00e9crit le r\u00e9sultat du traitement dans l’\u00e9dition standard. Les flux de donn\u00e9es standard sont connect\u00e9s aux fichiers avant d’ex\u00e9cuter le programme. Les canaux de va-et-vient d’une connexion TCP sont connect\u00e9s \u00e0 la valeur par d\u00e9faut et \u00e0 la sortie et sont donc logiquement repr\u00e9sent\u00e9s comme un fichier. Une connexion ferm\u00e9e est traduite par le processus de lecture en tant que fin de fichier atteint. Le sch\u00e9ma de traitement UNIX typique mentionn\u00e9 n\u00e9cessite que la connexion soit toujours disponible pour l’\u00e9criture apr\u00e8s la lecture de la fin du fichier, ce qui entra\u00eene la n\u00e9cessit\u00e9 de connexions demi-cl\u00f4tur\u00e9es. [5] Connexions \u00e0 moiti\u00e9 ouvertes [ Modifier | Modifier le texte source ]] Une connexion est \u00e0 moiti\u00e9 ouverte lorsqu’un c\u00f4t\u00e9 s’\u00e9crase sans que le c\u00f4t\u00e9 restant ne ressente cela. Cela a l’effet ind\u00e9sirable que les ressources du syst\u00e8me d’exploitation ne sont pas publi\u00e9es. Des connexions \u00e0 moiti\u00e9 ouvertes peuvent survenir car des connexions TCP existent du c\u00f4t\u00e9 du protocole jusqu’\u00e0 ce qu’elles soient d\u00e9compos\u00e9es. Les pr\u00e9cautions correspondantes sont souvent prises par le c\u00f4t\u00e9 de l’application. Connexion [ Modifier | Modifier le texte source ]]  Le client qui souhaite \u00e9tablir une connexion envoie le serveur Son -Package (de Anglais  synchroniser ) avec un num\u00e9ro de s\u00e9quence X . Les num\u00e9ros de s\u00e9quence sont importants pour assurer une transmission compl\u00e8te dans l’ordre correct et sans doublons. C’est donc un package dont Syn-bit est d\u00e9fini dans la t\u00eate du package (voir l’en-t\u00eate TCP). Le num\u00e9ro de s\u00e9quence de d\u00e9marrage (\u00e9galement appel\u00e9 num\u00e9ro de s\u00e9quence (ISN)) est n’importe quel nombre, dont la g\u00e9n\u00e9ration d\u00e9pend de l’impl\u00e9mentation TCP respective. Cependant, il devrait \u00eatre aussi al\u00e9atoire que possible d’\u00e9viter les risques de s\u00e9curit\u00e9. [6] Le serveur (voir Sketch) re\u00e7oit le package. Si le port est ferm\u00e9, il r\u00e9pond avec un TCP RST pour signaler qu’aucune connexion ne peut \u00eatre \u00e9tablie. Si le port est ouvert, il confirme la pr\u00e9servation du premier package SYN et accepte la connexion en renvoyant un package SYN \/ ACK (ACK depuis Engl. reconnaissance ,Confirmation’). L’indicateur ACK r\u00e9gl\u00e9 dans l’en-t\u00eate TCP marque ces packages que le num\u00e9ro de s\u00e9quence x + 1 du synth\u00e8se dans l’en-t\u00eate. De plus, il envoie son num\u00e9ro de s\u00e9quence de d\u00e9marrage en retour et , qui est \u00e9galement arbitraire et ind\u00e9pendant du num\u00e9ro de s\u00e9quence de d\u00e9marrage du client. Le client confirme r\u00e9cemment la pr\u00e9servation du package SYN \/ ACK en envoyant son propre package ACK avec le num\u00e9ro de s\u00e9quence x + 1 . Ce processus est \u00e9galement appel\u00e9 “Forward RemercedgeMe”. Pour des raisons de s\u00e9curit\u00e9, le client envoie la valeur et + 1 (Le num\u00e9ro de s\u00e9quence du serveur + 1) dans le segment ACK. La connexion est \u00e9tablie. Dans l’exemple suivant, le processus est montr\u00e9 abstrait: d’abord. SynSent \u2192 \u2192 Synchroni\u00e9 2 Syn \/ ACK \u2190 \u2190 SYN \/ ACK-SENT 3 et 3 Ack \u2192 \u2192 \u00c9TABLI Une fois configur\u00e9, la connexion pour les deux partenaires de communication est \u00e9gale, vous ne pouvez pas voir une connexion existante au niveau TCP qui est le serveur et qui est le client. Par cons\u00e9quent, une distinction entre ces deux r\u00f4les n’est plus importante dans la nouvelle consid\u00e9ration. Connexion [ Modifier | Modifier le texte source ]]  La connexion r\u00e9glement\u00e9e est similaire. Au lieu des synBits, le bit fin vient (d’Engl. finir \u00abEnde\u00bb, \u00abconclusion\u00bb) \u00e0 utiliser, ce qui montre qu’aucune donn\u00e9e ne proviendra plus de l’\u00e9metteur. La r\u00e9ception du colis est \u00e0 nouveau confirm\u00e9e par l’ACK. Le destinataire du package FIN lui envoie r\u00e9cemment un package FIN, qui lui est \u00e9galement confirm\u00e9. De plus, une proc\u00e9dure raccourcie est possible, dans laquelle Fin et ACK sont h\u00e9berg\u00e9s dans le m\u00eame paquet, tout comme lors de la cr\u00e9ation d’une connexion. Le dur\u00e9e de vie maximale du segment (MSL) est le temps maximum qu’un segment peut passer dans le r\u00e9seau avant qu’il ne soit rejet\u00e9. Apr\u00e8s avoir envoy\u00e9 le dernier champ, le client passe \u00e0 un \u00e9tat d’attente de deux MSL ( \u00c9tat d’attente ), dans lequel tous les segments tardifs sont jet\u00e9s. Cela garantit qu’aucun segment tardif ne peut \u00eatre mal interpr\u00e9t\u00e9 dans le cadre d’une nouvelle connexion qui utilise au hasard le m\u00eame port. De plus, une terminaison de connexion correcte est assur\u00e9e. Aller ak et + 1 Lost, la minuterie s’enfuit et le segment Last_ack est \u00e0 nouveau transf\u00e9r\u00e9. Bouffeur [ Modifier | Modifier le texte source ]] Deux tampons sont utilis\u00e9s lors de l’envoi de donn\u00e9es via le TCP. L’application transmet les donn\u00e9es \u00e0 transmettre au TCP du c\u00f4t\u00e9 \u00e9metteur et ce tampon les donn\u00e9es afin d’envoyer plusieurs petites transmissions plus efficacement sous la forme d’un seul grand. Une fois les donn\u00e9es ensuite transmises au destinataire, elles se retrouvent dans le tampon de la peau du receveur. Cela poursuit des objectifs similaires. Si plusieurs packages individuels ont \u00e9t\u00e9 re\u00e7us par le TCP, il est pr\u00e9f\u00e9rable de les transmettre \u00e0 l’application. Manuel \u00e0 trois voies [ Modifier | Modifier le texte source ]] \u00c0 la fois dans la structure de connexion et la r\u00e9duction de la connexion, les r\u00e9ponses au premier package SYN ou FIN sont g\u00e9n\u00e9ralement r\u00e9sum\u00e9es en un seul package (syn \/ ack ou fin \/ ack) – th\u00e9oriquement, l’envoi de deux packages s\u00e9par\u00e9s serait \u00e9galement imaginable. \u00c9tant donn\u00e9 que seuls trois paquets doivent \u00eatre envoy\u00e9s dans ce cas, on parle souvent du soi-disant bilan \u00e0 trois.Cependant, le r\u00e9sum\u00e9 du package FIN et du package ACK est probl\u00e9matique, car l’envoi d’un package FIN n’a le sens “aucune autre donn\u00e9es ne suit”. Cependant, l’\u00e9metteur du package FIN peut continuer \u00e0 recevoir des donn\u00e9es; On parle d’une connexion \u00e0 moiti\u00e9 clos (la direction de la r\u00e9ception est toujours ouverte pendant la fermeture de la direction de transmission). Ce serait z. B. concevable, le d\u00e9but d’une demande HTTP ( Http-request ) Soumettez directement dans le package SYN, des donn\u00e9es suppl\u00e9mentaires d\u00e8s que la connexion a \u00e9t\u00e9 \u00e9tablie et dans le dernier package de demande HTTP pour fermer la (direction de transmission de la) connexion avec FIN. En pratique, cependant, cette proc\u00e9dure n’est pas appliqu\u00e9e. Si le navigateur fermait la connexion imm\u00e9diatement de cette mani\u00e8re, le serveur peut \u00e9galement fermer la connexion au lieu de la demande de r\u00e9ponse compl\u00e8tement. G\u00e9n\u00e9ral [ Modifier | Modifier le texte source ]] Le segment TCP se compose toujours de deux parties: l’en-t\u00eate et la charge utile ( Anglais  charge utile ). La charge utile contient les donn\u00e9es \u00e0 transmettre, qui \u00e0 leur tour peuvent correspondre \u00e0 des informations de protocole sur la couche d’application, telles que HTTP ou FTP. L’en-t\u00eate contient des donn\u00e9es requises pour la communication et les informations de format de fichier. La structure sch\u00e9matique de l’en-t\u00eate TCP est visible sur la figure 5. \u00c9tant donn\u00e9 que le champ d’option n’est g\u00e9n\u00e9ralement pas utilis\u00e9, un en-t\u00eate typique a une taille de 20 octets. Les valeurs sont donn\u00e9es dans l’ordre des octets Big-endian. Explication [ Modifier | Modifier le texte source ]]  Fig. 5: Construction de l’en-t\u00eate TCP Port source (Quellport) (2 octets) Donner la Num\u00e9ro de port du c\u00f4t\u00e9 de l’\u00e9metteur. Le port de destination (Zielport) (2 octets) Donner la Num\u00e9ro de port du c\u00f4t\u00e9 r\u00e9cepteur. Num\u00e9ro de s\u00e9quence (4 octets) Num\u00e9ro de s\u00e9quence des premi\u00e8res donn\u00e9es oket ( Octet ) ce package TCP ou le Num\u00e9ro de s\u00e9quence d’initialisation Si le Syn-Flag est d\u00e9fini. Apr\u00e8s la transmission des donn\u00e9es, il sert \u00e0 trier les segments TCP, car ils peuvent arriver au destinataire dans un ordre diff\u00e9rent. Num\u00e9ro de reconnaissance (Num\u00e9ro de qualit\u00e9) (4 octets) Elle donne le Num\u00e9ro de s\u00e9quence Sur ce, l’exp\u00e9diteur de ce segment TCP attend ensuite. Il n’est valable que si l’indicateur ACK est d\u00e9fini. D\u00e9calage des donn\u00e9es (4 bits) En-t\u00eates Long des TCP dans des blocs 32 bits sans donn\u00e9es utilisateur ( Charge utile ). Cela montre l’adresse de d\u00e9part des donn\u00e9es utilisateur. R\u00e9serv\u00e9 (4 bits) Le R\u00e9serv\u00e9 -Feld est r\u00e9serv\u00e9 aux utilisations futures. Tous les bits doivent \u00eatre nuls. Flags de contr\u00f4le (8 bits) Sont des variables \u00e0 deux valeurs avec les conditions possibles ensemble et insatisfait Cela est n\u00e9cessaire pour identifier certaines conditions pour la communication et le traitement ult\u00e9rieur des donn\u00e9es. Les drapeaux de l’en-t\u00eate TCP et les actions \u00e0 effectuer sont d\u00e9crits ci-dessous. CWR et ECE sont deux drapeaux requis pour la notification de conesion explicite (ECN). Avec un ensemble ECE-BIT (ECN-Echo), le destinataire informe l’\u00e9metteur que le r\u00e9seau est surcharg\u00e9 et que le taux d’\u00e9metteur doit \u00eatre r\u00e9duit. Si le diffuseur l’a fait, il raconte au destinataire en d\u00e9finissant le bit CWR ( Fen\u00eatre de congestion r\u00e9duite ) avec. Urger Est le drapeau urgent (Urgent = urgent) Ensemble, les donn\u00e9es sont imm\u00e9diatement trait\u00e9es par l’application en fonction de l’en-t\u00eate. L’application interrompt le traitement des donn\u00e9es du segment TCP actuel et lit tous les octets apr\u00e8s l’en-t\u00eate de l’octet sur lequel le Pointeur urgent -Pede montre. Cette proc\u00e9dure est loin d’\u00eatre un logiciel Terrup. Cet drapeau peut \u00eatre utilis\u00e9, par exemple, pour annuler une application sur le destinataire. La proc\u00e9dure est utilis\u00e9e tr\u00e8s rarement, les exemples sont le traitement pr\u00e9f\u00e9r\u00e9 de Ctrl-C (d\u00e9molition) en cas de connexion terminale via Rlogin ou Telnet. En r\u00e8gle g\u00e9n\u00e9rale, ce drapeau n’est pas \u00e9valu\u00e9. Ack Le Reconnaissance -Flag a en relation avec le Reconnaissance Num\u00e9rotez la t\u00e2che de confirmer la r\u00e9ception des segments TCP lors du transfert de donn\u00e9es. Le Reconnaissance Le num\u00e9ro n’est valide que si l’indicateur est d\u00e9fini. Psh RFC 1122 et RFC 793 Sp\u00e9cifiez que Pousser -FLAG de telle mani\u00e8re que lorsque le drapeau est d\u00e9fini, le tampon sortant et le tampon entrant est ignor\u00e9. \u00c9tant donn\u00e9 que vous n’envoyez pas de flux de donn\u00e9es chez TCP, mais que vous avez un flux de donn\u00e9es, le PSH-FLAG aide \u00e0 traiter l’\u00e9lectricit\u00e9 plus efficacement, car l’application de r\u00e9ception peut \u00eatre r\u00e9veill\u00e9e plus sp\u00e9cifiquement et n’a pas encore \u00e0 d\u00e9couvrir avec chaque segment de donn\u00e9es qui n’a pas encore \u00e9t\u00e9 re\u00e7u. Ceci est utile si, par exemple, vous souhaitez envoyer une commande au destinataire lors d’une session Cloak. Si cette commande n’\u00e9tait pas stock\u00e9e temporairement dans le tampon, elle serait (fortement) trait\u00e9e. Selon l’impl\u00e9mentation TCP dans le comportement, l’indicateur PSH peut s’\u00e9carter de la d\u00e9claration ci-dessus. Premier Le R\u00e9initialiser -FLAG est utilis\u00e9 lorsqu’une connexion doit \u00eatre annul\u00e9e. Cela se produit, par exemple, en cas de probl\u00e8mes techniques ou pour le licenciement des compos\u00e9s ind\u00e9sirables (tels que les ports non ouverts, contrairement \u00e0 l’UDP, aucun package ICMP avec “port inaccessible” n’est envoy\u00e9 ici). Son Les packages avec Syn-Flag set initier une connexion. Le serveur r\u00e9pond g\u00e9n\u00e9ralement avec SYN + ACK lorsqu’il est pr\u00eat \u00e0 accepter la connexion, sinon avec RST. Sert la synchronisation de Num\u00e9ros de s\u00e9quence Dans la structure de connexion (d’o\u00f9 la d\u00e9signation SY). FIN Ce dernier drapeau ( finir ) sert \u00e0 lib\u00e9rer la connexion et indiquer qu’aucune donn\u00e9e ne vient plus de l’\u00e9metteur. L’interruption et les syn-flag ont des num\u00e9ros de s\u00e9quence afin qu’ils soient trait\u00e9s dans l’ordre correct. (Recevoir) fen\u00eatre (2 octets) Est le nombre d’osstrates de donn\u00e9es (apr\u00e8s multiplication avec le facteur d’\u00e9chelle de la fen\u00eatre ( Octets ), \u00e0 commencer par \u00e7a Remerciementsfeld Index\u00e9 Data-Ortet que l’\u00e9metteur de ce package TCP est dispos\u00e9 \u00e0 recevoir. V\u00e9rification (2 octets) Le Sommet sert \u00e0 d\u00e9tecter les erreurs de transmission et est calcul\u00e9e via l’en-t\u00eate TCP, les donn\u00e9es et un en-t\u00eate pseudo. Cet en-t\u00eate se compose de l’IP cible, de l’IP source, de la d\u00e9tection du protocole TCP (0x0006) et de la longueur de l’en-t\u00eate TCP, y compris les donn\u00e9es utilisateur (en octets). Pointeur urgent (2 octets) Avec le num\u00e9ro de s\u00e9quence, cette valeur donne la position des premiers octets apr\u00e8s les donn\u00e9es d’origine dans le flux de donn\u00e9es. Les donn\u00e9es d’origine commencent imm\u00e9diatement apr\u00e8s l’en-t\u00eate. La valeur n’est valide que si l’indicateur URG est d\u00e9fini. Options (0\u201340 octet) Le champ d’option est diff\u00e9rent en taille et contient des informations suppl\u00e9mentaires. Les options doivent \u00eatre un multiple de 32 bits de long. Si vous ne l’\u00eates pas, il doit \u00eatre rempli de bits z\u00e9ro ( Rembourrage ). Ce champ permet de n\u00e9gocier des donn\u00e9es de connexion qui ne sont pas incluses dans l’en-t\u00eate TCP, telles que la taille maximale du champ de donn\u00e9es utilisateur.  Fig. 6: Segmentation des donn\u00e9es utilisateur Taille du segment TCP \/ IP [ Modifier | Modifier le texte source ]] Un segment TCP a g\u00e9n\u00e9ralement une taille maximale de 1500 octets. Cependant, un segment TCP doit s’int\u00e9grer dans la couche de transmission sous-jacente, le protocole Internet (IP); Voir \u00e9galement l’unit\u00e9 de transmission maximale (MTU). Les packages IP sont th\u00e9oriquement sp\u00e9cifi\u00e9s jusqu’\u00e0 65 535 octets (64 kib), mais sont principalement transmis via Ethernet, et avec Ethernet la taille des donn\u00e9es utilisateur (couche 3) (si l’on provient de Cadres jumbo Abandonn\u00e9) \u00e0 64 (incluant \u00e9ventuellement un rembourrage) jusqu’\u00e0 1500 octets. Le protocole TCP et IP d\u00e9finit un en-t\u00eate de la taille de 20 octets. Dans un package TCP \/ IP, 1460 octets (= 1500 octets Ethernet- [Donn\u00e9es utilisateur] -20 octets Donn\u00e9es d’en-t\u00eate TCP-20 Donn\u00e9es d’en-t\u00eate IP) Restez dans un package TCP \/ IP. \u00c9tant donn\u00e9 que la plupart des connexions Internet utilisent DSL, le protocole point \u00e0 point (PPP) entre l’IP et Ethernet y est \u00e9galement utilis\u00e9, qui utilise 8 autres octets pour le cadre PPP. Les donn\u00e9es de l’utilisateur sont donc r\u00e9duites \u00e0 un total de 1500 – 20 – 8 = 1452 octets MSS (taille maximale du segment). Cela correspond \u00e0 un taux de donn\u00e9es d’utilit\u00e9 maximum de 96,8%. Division des donn\u00e9es d’application aux segments TCP \/ IP [ Modifier | Modifier le texte source ]] Le destinataire et l’\u00e9metteur s’accordent sur la taille du MSS avant l’\u00e9change de donn\u00e9es via le champ d’option. L’application qui souhaite envoyer des donn\u00e9es, comme un serveur Web, prend, par exemple, un bloc de donn\u00e9es de 7 kilobytes dans le tampon.Afin d’envoyer 7 kilobytes de donn\u00e9es avec un champ de donn\u00e9es d’utilisation de 1460 octets, le logiciel TCP divise les donn\u00e9es sur plusieurs packages, ajoute un en-t\u00eate TCP et envoie les segments TCP. Ce processus est appel\u00e9 segmentation. Le bloc de donn\u00e9es dans le tampon est divis\u00e9 en cinq segments (voir Fig. 6). Chaque segment re\u00e7oit un en-t\u00eate TCP du logiciel TCP. Les segments TCP sont envoy\u00e9s l’un apr\u00e8s l’autre. Ceux-ci n’arrivent pas n\u00e9cessairement au destinataire dans le m\u00eame ordre dans lequel ils ont \u00e9t\u00e9 envoy\u00e9s, car chaque segment TCP peut emprunter un chemin diff\u00e9rent sur Internet. Chaque segment est num\u00e9rot\u00e9 afin que le logiciel TCP puisse trier \u00e0 nouveau les segments chez le destinataire. Le num\u00e9ro de s\u00e9quence est utilis\u00e9 lors de l’attribution des segments du destinataire.  Fig. 7: Exemple d’un transfert de donn\u00e9es Le logiciel TCP du destinataire confirme les segments TCP qui sont parfaitement arriv\u00e9s (c’est-\u00e0-dire avec la joue correcte). Sinon, les packages seront demand\u00e9s. Exemple de transfert de donn\u00e9es TCP \/ IP [ Modifier | Modifier le texte source ]] L’\u00e9metteur envoie son premier segment TCP avec un num\u00e9ro de s\u00e9quence Seq = 1 (vari\u00e9) et une longueur de donn\u00e9es utilisateur de 1460 octets au destinataire. Le destinataire le confirme avec un en-t\u00eate TCP sans donn\u00e9es avec ACK = 1461 et appelle ainsi le deuxi\u00e8me segment TCP du num\u00e9ro 1461 octet. Cela l’envoie ensuite au destinataire avec un segment TCP et SEQ = 1461. Cela le confirme \u00e0 nouveau avec un champ = 2921 et ainsi de suite. Le destinataire n’a pas besoin de confirmer chaque segment TCP s’il est coh\u00e9rent. S’il re\u00e7oit les segments TCP 1 \u00e0 5, il n’a qu’\u00e0 confirmer le dernier segment TCP. Par exemple, le segment TCP 3 est manquant car il a \u00e9t\u00e9 perdu, il ne peut que confirmer les 1 et 2, 4 et 5, cependant, pas encore. \u00c9tant donn\u00e9 que le diffuseur ne re\u00e7oit aucune confirmation pour le 3, sa minuterie fonctionne et il envoie le 3. Si le 3 arrive chez le destinataire, il confirme les cinq segments TCP si les deux c\u00f4t\u00e9s prennent en charge le sac d’option TCP (ACK s\u00e9lectif). Le diffuseur lance un temporisateur de retransmission pour chaque segment TCP qu’il envoie lors du voyage. Minuterie de retransmission [ Modifier | Modifier le texte source ]] Pour d\u00e9terminer quand un package a \u00e9t\u00e9 perdu dans le r\u00e9seau, l’\u00e9metteur utilise un d\u00e9lai d’attente auquel le c\u00f4t\u00e9 oppos\u00e9 doit \u00eatre arriv\u00e9. Un d\u00e9lai trop bas fait r\u00e9p\u00e9ter correctement les parcelles qui ont \u00e9t\u00e9 correctement dispos\u00e9es; Un d\u00e9lai trop \u00e9lev\u00e9 signifie que le package \u00e0 r\u00e9p\u00e9ter est envoy\u00e9 inutilement en retard si les pertes sont r\u00e9p\u00e9t\u00e9es.En raison des diff\u00e9rents termes des packages IP sous-jacents, seule une dynamique \u00e0 la connexion des minuteries adapt\u00e9es est logique. Les d\u00e9tails sont dans RFC 6298 [7] d\u00e9termin\u00e9 comme suit: Le d\u00e9lai d’attente (RTO = d\u00e9lai d’expiration de retransmission) est calcul\u00e9 \u00e0 partir de deux variables d’\u00e9tat r\u00e9alis\u00e9es par l’\u00e9metteur: Initialement, on estime que RTO = 1S (afin de cr\u00e9er une compatibilit\u00e9 avec l’ancienne version du document est \u00e9galement possible. Apr\u00e8s avoir mesur\u00e9 le RTT du premier package, il est d\u00e9fini:SRTT: = RTT Rttvar: = 0,5 * RTT RTO: = RTT + 4 * RTTVAR (devrait \u00eatre 4 * Rtttvar plus petit que la pr\u00e9cision de mesure de la minuterie, il est ajout\u00e9 \u00e0 la place.) \u00c0 chaque mesure suppl\u00e9mentaire du RTT ‘, les valeurs sont mises \u00e0 jour (RTTVAR doit \u00eatre calcul\u00e9 avant SRTT):Rttvar: = (1-\u03b2) * rttvar + \u03b2 * | srtt-rtt ‘| (La variance est \u00e9galement liss\u00e9e avec un facteur de \u03b2; puisque la variance sp\u00e9cifie une d\u00e9viation moyenne (ce qui est toujours positif), la quantit\u00e9 d’\u00e9cart par rapport \u00e0 RTT estim\u00e9 et r\u00e9el est utilis\u00e9e ici, et non la diff\u00e9rence simple. Il est recommand\u00e9 de choisir \u03b2 = 1\/4.) Srtt: = (1-\u03b1) * srtt + \u03b1 * rtt ‘(ce n’est pas simplement le nouveau RTT’, mais il est liss\u00e9 avec un facteur \u03b1. Il est recommand\u00e9 de choisir \u03b1 = 1\/8.) RTO: = SRTT + 4 * RTTVAR (devrait \u00eatre 4 * RTTVAR plus petit que la pr\u00e9cision de mesure du temporisateur, il est ajout\u00e9 \u00e0 la place. Pour le RTO, une valeur minimale de 1 s s’applique – quel que soit le calcul; une valeur maximale peut \u00e9galement \u00eatre attribu\u00e9e si cela est au moins 60 s.) En choisissant 2 puissances (4 ou 1\/2, 1\/4 etc.) comme facteurs, les calculs de l’impl\u00e9mentation peuvent \u00eatre r\u00e9alis\u00e9s par de simples op\u00e9rations de d\u00e9calage. L’algorithme de Karn de Phil Karn doit \u00eatre utilis\u00e9 pour mesurer le RTT; d. Autrement dit, seuls les packages sont utilis\u00e9s pour la mesure, dont la confirmation arrive sans que le package soit renvoy\u00e9 entre les deux. La raison en est que si la transmission \u00e9tait \u00e0 nouveau, il ne serait pas clair lequel des packages r\u00e9p\u00e9t\u00e9s a \u00e9t\u00e9 r\u00e9ellement confirm\u00e9, de sorte qu’une d\u00e9claration concernant le RTT n’est pas possible. Si un package n’a pas \u00e9t\u00e9 confirm\u00e9 dans le temps mort, le RTO est doubl\u00e9 (sauf s’il a atteint la barri\u00e8re sup\u00e9rieure en option). Dans ce cas (\u00e9galement facultatif), les valeurs trouv\u00e9es pour SRTT et RTTVAR peuvent \u00eatre r\u00e9initialis\u00e9es \u00e0 leur valeur initiale, car ils pourraient \u00e9ventuellement perturber le recalcul du RTO. Connexion du contr\u00f4le de la rivi\u00e8re et du contr\u00f4le des embouteillages [ Modifier | Modifier le texte source ]] Dans les deux sections suivantes, les concepts TCP pour le contr\u00f4le de la rivi\u00e8re et le contr\u00f4le des embouteillages (ou le contr\u00f4le des surcharges) sont expliqu\u00e9s. Qui va Fen\u00eatre coulissante et le Fen\u00eatre de congestion introduit. L’\u00e9metteur s\u00e9lectionne le minimum dans les deux fen\u00eatres comme taille de fen\u00eatre de diffusion r\u00e9elle. Afin d’assurer une transmission fiable des donn\u00e9es par le biais de r\u00e9p\u00e9titions de transmission, ainsi Arq-protokolle (Demande de r\u00e9p\u00e9tition automatique anglaise, demande de r\u00e9p\u00e9tition automatique allemande) Utilis\u00e9. Contr\u00f4le de la rivi\u00e8re [ Modifier | Modifier le texte source ]]  \u00c9tant donn\u00e9 que l’application lit les donn\u00e9es du tampon, le niveau de remplissage du tampon change constamment. Il est donc n\u00e9cessaire de contr\u00f4ler le flux de donn\u00e9es en cons\u00e9quence. Cela arrive avec \u00e7a Fen\u00eatre coulissante Et sa taille.Comme le montre la figure 8, nous \u00e9largissons le tampon de l’\u00e9metteur \u00e0 10 segments. Sur la figure 8a, les segments 1 \u00e0 5 viennent d’\u00eatre transf\u00e9r\u00e9s. La transmission est comparable \u00e0 la figure 7. Bien que le tampon du destinataire de la figure 7 soit plein \u00e0 la fin, il appelle les donn\u00e9es suivantes du BYTE 7301 avec ACK = 7301. En cons\u00e9quence, le prochain segment TCP ne peut plus \u00eatre trait\u00e9 par le destinataire. Cependant, les exceptions sont des segments TCP avec un indicateur URG d\u00e9fini. Avec le champ de fen\u00eatre, il peut dire au diffuseur qu’il ne devrait plus envoyer de donn\u00e9es. Cela se produit en entrant la valeur z\u00e9ro dans le champ de fen\u00eatre (fen\u00eatre z\u00e9ro). La valeur de z\u00e9ro correspond \u00e0 l’espace libre dans le tampon. L’application du destinataire lit d\u00e9sormais les segments 1 \u00e0 5 \u00e0 partir du tampon, avec lequel un espace de stockage de 7 300 octets est gratuit. Il peut donc demander les segments restants 6 \u00e0 10 avec un en-t\u00eate TCP qui contient les valeurs SEQ = 1, ACK = 7301 et Window = 7300. L’\u00e9metteur sait maintenant qu’il peut envoyer un maximum de cinq segments TCP au destinataire et d\u00e9place la fen\u00eatre de cinq segments vers la droite (voir Fig. 8b). Les segments 6-10 sont maintenant tous ensemble comme \u00c9clatement envoy\u00e9. Si tous les segments TCP arrivent au destinataire, il les reconna\u00eet avec seq = 1 et ack = 14601 et demande les donn\u00e9es suivantes. Syndrome de fen\u00eatre idiote  Le destinataire envoie un Fen\u00eatre z\u00e9ro \u00e0 l’\u00e9metteur parce que son tampon est plein. Cependant, l’application du destinataire ne lit que deux octets du tampon. Le destinataire envoie un en-t\u00eate TCP avec Window = 2 (mise \u00e0 jour de la fen\u00eatre) vers l’\u00e9metteur et en m\u00eame temps appelle les deux octets. L’\u00e9metteur est conforme \u00e0 la demande et envoie les deux octets au destinataire dans un package de 42 octets (avec en-t\u00eate IP et en-t\u00eate TCP). Avec cela, le tampon du r\u00e9cepteur est \u00e0 nouveau plein et il en envoie un autre Fen\u00eatre z\u00e9ro \u00c0 l’\u00e9metteur. Par exemple, l’application lit maintenant une centaine d’octets du tampon. Le destinataire envoie un en-t\u00eate TCP \u00e0 l’\u00e9metteur avec une petite valeur de fen\u00eatre. Ce jeu continue et gaspille la bande passante car seuls de tr\u00e8s petits packages sont envoy\u00e9s. La solution de Clark est que le destinataire Fen\u00eatre z\u00e9ro envoie et pendant si longtemps avec \u00e7a Mise \u00e0 jour de la fen\u00eatre Devrait attendre que l’application ait lu au moins la taille maximale du segment (taille maximale du segment, dans nos exemples pr\u00e9c\u00e9dents 1460 octets) du tampon ou le tampon est \u00e0 moiti\u00e9 leader – selon ce qui se produit en premier (Dave Clark, 1982). L’\u00e9metteur peut \u00e9galement envoyer des packages trop petits et gaspiller ainsi la bande passante. Ceci est \u00e9limin\u00e9 avec l’algorithme Nagle. C’est pourquoi il se compl\u00e8te par la solution de Clark. Contr\u00f4le de surcharge \/ contr\u00f4le des embouteillages (contr\u00f4le de la congestion) [ Modifier | Modifier le texte source ]] Sur Internet, dans lequel de nombreux r\u00e9seaux sont connect\u00e9s \u00e0 diff\u00e9rentes propri\u00e9t\u00e9s, la perte de donn\u00e9es de packages individuels est tout \u00e0 fait normale. Si une connexion est fortement charg\u00e9e, de plus en plus de packages sont rejet\u00e9s, ce qui doit \u00eatre r\u00e9p\u00e9t\u00e9 en cons\u00e9quence. En raison de la r\u00e9p\u00e9tition, le fardeau augmente, sans mesures appropri\u00e9es, il existe une congestion des donn\u00e9es. Le taux de perte est constamment observ\u00e9 par un r\u00e9seau IP. Selon le taux de perte, le transmetteur est influenc\u00e9 par des algorithmes appropri\u00e9s: g\u00e9n\u00e9ralement une connexion TCP \/ IP est lentement d\u00e9marr\u00e9e (d\u00e9marrage lent) et le transmetteur augmente progressivement jusqu’\u00e0 ce que la perte de donn\u00e9es se produise. Une perte de donn\u00e9es r\u00e9duit le taux d’\u00e9metteur, sans perte, elle est augment\u00e9e. Dans l’ensemble, le d\u00e9bit de donn\u00e9es aborde d’abord le maximum respectif disponible et y reste ensuite approximativement. Une surcharge est \u00e9vit\u00e9e. Algorithme pour le contr\u00f4le de la surcharge [ Modifier | Modifier le texte source ]] Si les packages sont perdus dans une certaine taille de fen\u00eatre, cela peut \u00eatre d\u00e9termin\u00e9 si l’\u00e9metteur ne re\u00e7oit aucune confirmation (ACK) dans un certain d\u00e9lai (d\u00e9lai d’attente). Il faut supposer que le package a \u00e9t\u00e9 rejet\u00e9 par un routeur sur Internet en raison d’une charge r\u00e9seau trop \u00e9lev\u00e9e. Cela signifie que le tampon d’un routeur est plein; Il s’agit d’un embouteillage sur le net, pour ainsi dire. Afin de dissoudre les embouteillages, tous les \u00e9metteurs impliqu\u00e9s doivent r\u00e9duire leur charge de r\u00e9seau. Pour ce faire, dans le RFC 2581 Quatre algorithmes d\u00e9finis: d\u00e9marrage lent , \u00c9vitement de la congestion , RetRansmit rapide et r\u00e9cup\u00e9ration rapide , par lequel d\u00e9marrage lent et \u00c9vitement de la congestion peut \u00eatre utilis\u00e9 ensemble. Les deux algorithmes RetRansmit rapide et r\u00e9cup\u00e9ration rapide sont \u00e9galement utilis\u00e9s ensemble et sont une expansion des algorithmes d\u00e9marrage lent et \u00c9vitement de la congestion . D\u00e9marrage lent et \u00e9vitement de la congestion [ Modifier | Modifier le texte source ]]  Repr\u00e9sentation graphique de l’algorithme de d\u00e9marrage lent Au d\u00e9but d’une transmission de donn\u00e9es, l’algorithme de d\u00e9marrage lent sert \u00e0 d\u00e9terminer fen\u00eatre de congestion (Litt\u00e9ralement: fen\u00eatre de surcharge) pour \u00e9viter une \u00e9ventuelle situation de surcharge. Vous souhaitez \u00e9viter les embouteillages, et comme l’utilisation actuelle du r\u00e9seau n’est pas connue, de petites quantit\u00e9s de donn\u00e9es commencent. L’algorithme commence par une petite fen\u00eatre \u00e0 partir d’un MSS (taille maximale du segment), dans lequel les packages de donn\u00e9es sont transmis de l’\u00e9metteur au receveur. Le destinataire renvoie d\u00e9sormais une confirmation (ACK) \u00e0 l’\u00e9metteur. La taille du fen\u00eatre de congestion augment\u00e9 par un MSS. \u00c9tant donn\u00e9 qu’un ACK est envoy\u00e9 pour chaque colis envoy\u00e9 \u00e0 une transmission r\u00e9ussie, cela conduit \u00e0 un doublement de la congr\u00e9gation Windows dans un d\u00e9lai aller-retour. Dans cette phase, il y a une croissance exponentielle. Par exemple, si la fen\u00eatre permet d’envoyer deux packages, l’\u00e9metteur re\u00e7oit \u00e9galement deux acks et augmente donc la fen\u00eatre de 2 \u00e0 4. Cette croissance exponentielle se poursuivra jusqu’\u00e0 ce que le SO Seuil de d\u00e9marrage lent est accompli. seuil ,Seuil’). La phase de la croissance exponentielle est \u00e9galement Phase de d\u00e9marrage lent appel\u00e9. Apr\u00e8s cela, la congr\u00e9gation de fen\u00eatre n’est augment\u00e9e que par un segment si tous les packages ont \u00e9t\u00e9 transf\u00e9r\u00e9s avec succ\u00e8s de la fen\u00eatre. Donc, il ne cro\u00eet que par un segment par temps aller-retour, donc seulement lin\u00e9airement. Cette phase est comme Phase d’\u00e9vitement de la congestion d\u00e9sign\u00e9. La croissance se termine lorsque la fen\u00eatre de r\u00e9ception d\u00e9finie par le receveur a \u00e9t\u00e9 atteinte (voir le contr\u00f4le de la rivi\u00e8re). S’il y a un d\u00e9lai d’expiration, il va fen\u00eatre de congestion r\u00e9initialiser avec 1 et le seuil de d\u00e9marrage lent Est sur la moiti\u00e9 de la taille du vol (la taille du vol est le nombre de colis qui ont \u00e9t\u00e9 envoy\u00e9s, mais n’ont pas encore \u00e9t\u00e9 reconnus) [8] r\u00e9duit. La phase de croissance exponentielle est raccourcie, de sorte que la fen\u00eatre se d\u00e9veloppe lentement avec des pertes de paquets fr\u00e9quents. Retransmit rapide et r\u00e9cup\u00e9ration rapide [ Modifier | Modifier le texte source ]] Retransmit rapide et R\u00e9cup\u00e9ration rapide (“Fast Relaxation”) sont utilis\u00e9s pour r\u00e9agir plus rapidement \u00e0 la situation des embouteillages apr\u00e8s une perte de package. Un destinataire informe l’\u00e9metteur lorsque les packages arrivent hors ligne et donc il y a une perte de package entre les deux. \u00c0 cette fin, le destinataire confirme le dernier package correct l’un pour l’autre un package entrant hors de la ligne. On parle de Dup-\u00e0-arc ( Remerciements en double ), c’est-\u00e0-dire plusieurs messages cons\u00e9cutifs, qui sont le m\u00eame segment de donn\u00e9es. Le diffuseur remarque les confirmations dupliqu\u00e9es, et apr\u00e8s le troisi\u00e8me double, il envoie \u00e0 nouveau le package perdu avant l’expiration du minuteur. Parce qu’il n’a pas \u00e0 attendre l’expiration de la minuterie, le principe signifie RetRansmit rapide . Les Sacs DUP sont \u00e9galement prouv\u00e9s qu’une perte de colis a eu lieu, mais les paquets suivants sont arriv\u00e9s. Par cons\u00e9quent, la fen\u00eatre de transmission n’est divis\u00e9e par moiti\u00e9 qu’apr\u00e8s l’erreur et ne recommencez pas avec le d\u00e9marrage lent comme avec le d\u00e9lai d’attente. De plus, la fen\u00eatre de transmission peut \u00eatre augment\u00e9e par le nombre de sacs DUP, car chacun repr\u00e9sente un autre package qui a atteint le destinataire, bien que hors ligne. \u00c9tant donn\u00e9 que les performances de transmission compl\u00e8tes sont atteintes plus rapidement apr\u00e8s l’erreur, le principe est appel\u00e9 R\u00e9cup\u00e9ration rapide . ACKS s\u00e9lectifs (sac) [ Modifier | Modifier le texte source ]] ACKS s\u00e9lectifs sont utilis\u00e9s pour retourner encore plus d’informations de contr\u00f4le via le flux de donn\u00e9es du receveur vers l’\u00e9metteur. Apr\u00e8s une perte de colis, un en-t\u00eate suppl\u00e9mentaire est ins\u00e9r\u00e9 par le destinataire dans le champ Option TCP, \u00e0 partir de laquelle la station peut voir exactement quels packages sont d\u00e9j\u00e0 arriv\u00e9s et qui manque (contrairement aux ACK cumulative standard de TCP, voir ci-dessus). Les packages ne sont toujours consid\u00e9r\u00e9s que si le destinataire a transmis un ACK pour les packages \u00e0 l’exp\u00e9diteur. TCP-Tahoe und TCP-RENO [ Modifier | Modifier le texte source ]] Les variantes de contr\u00f4le TCP Tahoe et Reno nomm\u00e9es d’apr\u00e8s les emplacements au Nevada sont deux proc\u00e9dures diff\u00e9rentes, telles que TCP sur un \u00e9v\u00e9nement de surcharge sous la forme de D\u00e9lais d’expiration ou Dup-\u00e0-arc r\u00e9agi. Le TCP Taoe, qui n’est plus utilis\u00e9, r\u00e9duit d\u00e8s qu’il y a un d\u00e9lai d’expiration, la fen\u00eatre de la congr\u00e9gation pour la prochaine unit\u00e9 de transmission \u00e0 1. Ensuite, le processus de d\u00e9marrage TCP-SLOW (avec un seuil r\u00e9duit, voir ci-dessous), jusqu’\u00e0 ce qu’un nouvel temps mort ou du DuP-Sach ait lieu ou la valeur de seuil ( Seuil ) peut \u00eatre atteint pour la transition vers la phase de conoocation-option. Ce seuil a \u00e9t\u00e9 fix\u00e9 sur la moiti\u00e9 de la taille de la fen\u00eatre de congr\u00e9gation actuelle apr\u00e8s que l’\u00e9v\u00e9nement de surcharge s’est produit. D’une part, l’inconv\u00e9nient de cette proc\u00e9dure est qu’une perte de package n’est d\u00e9termin\u00e9e que par un d\u00e9lai d’expiration, donc parfois dure assez longtemps, et d’autre part, la forte r\u00e9duction des fen\u00eatres conge sur 1. Le d\u00e9veloppement ult\u00e9rieur de Tahoe est TCP-Reno. Une distinction est faite entre les \u00e9v\u00e9nements de temps mort et DuP-Sachs qui se produisent: alors que TCP-Reno fait tout autant que TCP TAOE se produit lorsqu’un d\u00e9lai d’expiration se produit, il utilise une variante diff\u00e9rente pour d\u00e9terminer les fen\u00eatres de congr\u00e9gation suivantes lors de trois doublons. L’id\u00e9e de base est que la perte d’un segment sur le chemin du destinataire peut non seulement \u00eatre reconnue par un d\u00e9lai d’expiration, mais aussi par le fait que le destinataire avant renvoy\u00e9 au segment perdu (chaque fois qu’il re\u00e7oit un autre segment apr\u00e8s “l’\u00e9cart”). Par cons\u00e9quent, la congesation de fen\u00eatre suivante est d\u00e9finie pour la moiti\u00e9 de la valeur de la congr\u00e9gation de Window au moment de l’\u00e9v\u00e9nement de surcharge; Ensuite, la phase d’\u00e9vitement est \u00e0 nouveau convertie. Comme mentionn\u00e9 ci-dessus dans l’article, ce comportement est R\u00e9cup\u00e9ration rapide d\u00e9crit. Contr\u00f4le de surcharge comme domaine de recherche [ Modifier | Modifier le texte source ]] La conception exacte du contr\u00f4le de la surcharge TCP \u00e9tait et est un domaine de recherche extr\u00eamement actif avec de nombreuses publications scientifiques. Aujourd’hui encore, de nombreux scientifiques du monde entier travaillent sur des am\u00e9liorations du contr\u00f4le des surcharges du TCP ou essaient de les adapter \u00e0 certaines circonstances externes. Dans ce contexte, les conditions sp\u00e9ciales des diff\u00e9rentes techniques de transmission sans fil doivent \u00eatre mentionn\u00e9es en particulier, ce qui entra\u00eene souvent des retards de terme \u00e9lev\u00e9s ou fortement fluctuants ou des pertes de package trop \u00e9lev\u00e9es. Par d\u00e9faut, TCP suppose que la route de transmission est occup\u00e9e en tout lieu (congestion des donn\u00e9es). C’est g\u00e9n\u00e9ralement le cas avec les r\u00e9seaux li\u00e9s \u00e0 un fil, car il y a rarement des packages l\u00e0-bas sur la ligne sont perdus, mais ont presque toujours \u00e9t\u00e9 rejet\u00e9s par un routeur surcharg\u00e9. La bonne r\u00e9action \u00e0 une telle \u00abcongestion des donn\u00e9es\u00bb est donc la r\u00e9duction du transmetteur. Dans le cas des r\u00e9seaux sans fil, cependant, cette hypoth\u00e8se ne s’applique plus. En raison du milieu de transmission beaucoup plus peu fiable, les pertes de paquets se produisent souvent sans que l’un des routeurs ne soit surcharg\u00e9. Dans ce sc\u00e9nario, cependant, la r\u00e9duction du transmetteur n’a pas de sens. Au contraire, une augmentation du transmetteur, par exemple par plusieurs exp\u00e9diteurs de packages, pourrait augmenter la fiabilit\u00e9 de la connexion. Ces changements ou extensions de contr\u00f4le des surcharges sont souvent bas\u00e9s sur des fondations math\u00e9matiques ou r\u00e9glementaires complexes. Le projet d’am\u00e9liorations correspondantes est tout sauf facile, car il est g\u00e9n\u00e9ralement n\u00e9cessaire que les connexions TCP avec des m\u00e9canismes de contr\u00f4le des surcharges plus anciens ne soient pas consid\u00e9rablement d\u00e9savantag\u00e9s par les nouvelles m\u00e9thodes si, par exemple, plusieurs connexions TCP avec la bande passante de la bande passante sur un support partag\u00e9. Pour toutes ces raisons, le contr\u00f4le de la surcharge TCP utilis\u00e9 dans la r\u00e9alit\u00e9 est \u00e9galement beaucoup plus compliqu\u00e9 que d\u00e9crit ci-dessus dans l’article. En raison des nombreuses recherches sur le contr\u00f4le de la surcharge TCP, divers m\u00e9canismes de contr\u00f4le des surcharges ont pr\u00e9valu au fil du temps comme quasi-stands. TCP Reno, TCP Tahoo et TCP Vegas valent particuli\u00e8rement la peine d’\u00eatre mentionn\u00e9s ici. Dans les syst\u00e8mes d’exploitation modernes, TCP Cubic est utilis\u00e9 comme algorithme de surplomb standard. Dans ce qui suit, certaines approches plus r\u00e9centes ou plus exp\u00e9rimentales doivent \u00eatre \u00e0 peu pr\u00e8s d\u00e9crites. Une approche est, par exemple, RCF (r\u00e9troaction de la con\u00e9sion du routeur). Le routeur le long du chemin est envoy\u00e9 des informations plus \u00e9tendues aux canaux ou destinataires TCP afin qu’ils puissent mieux coordonner leur contr\u00f4le de surcharge de bout en bout. En cons\u00e9quence, des augmentations de d\u00e9bit consid\u00e9rables sont prouv\u00e9es. Des exemples de cela peuvent \u00eatre trouv\u00e9s dans la litt\u00e9rature sous les mots cl\u00e9s XCP ( protocole de contr\u00f4le explicite ), Ewa ( Adaptation \u00e0 la fen\u00eatre explicite ), S’\u00e9largir \u00e0 ( Ewa flou ), Fxcp ( XCP flou ) et etc. ( TCP am\u00e9lior\u00e9 ) (Au milieu de -2004). De plus, c’est Notification de congestion explicite (ECN) Impl\u00e9mentation d’un RFC. Pour le dire simplement, ces proc\u00e9dures forment un contr\u00f4le de surcharge en fonction de l’ATM. D’autres approches poursuivent la s\u00e9paration logique de la boucle de contr\u00f4le d’une connexion TCP en deux boucles de contr\u00f4le ou plus aux endroits d\u00e9cisifs sur Internet (par exemple avec le soi-disant TCP divis\u00e9). Il existe \u00e9galement la m\u00e9thode de regroupement logique de plusieurs connexions TCP dans une station TCP afin que ces compos\u00e9s puissent remplacer leurs informations sur la condition actuelle du r\u00e9seau et r\u00e9agir plus rapidement. Voici la proc\u00e9dure EFCM en particulier ( Gestion de la congestion des flux d’ensemble ) appeler. Toutes ces proc\u00e9dures peuvent \u00eatre sous le terme Partage d’informations r\u00e9seau \u00eatre r\u00e9sum\u00e9. L’en-t\u00eate pseudo est une compilation des parties d’en-t\u00eate d’un segment TCP et des parties de l’en-t\u00eate du package IP d’encapssuling. Il s’agit d’un mod\u00e8le sur lequel le calcul de la somme du test TCP ( Anglais  somme de contr\u00f4le ) D\u00e9crivez clairement. Si IP est utilis\u00e9 avec TCP, il est souhaitable d’inclure l’en-t\u00eate du package IP dans la s\u00e9curisation de TCP. Cela garantit la fiabilit\u00e9 de sa transmission. C’est pourquoi vous formez l’en-t\u00eate pseudo IP. Il se compose d’adresse de l’exp\u00e9diteur IP et du r\u00e9cepteur, un octet z\u00e9ro-octet qui indique le protocole auquel les donn\u00e9es utilisateur du package IP incluent et la longueur du segment TCP avec l’en-t\u00eate TCP. \u00c9tant donn\u00e9 que dans le cas de l’en-t\u00eate pseudo, il s’agit toujours de packages IP qui transportent les segments TCP, cet octet est d\u00e9fini sur la valeur 6. L’en-t\u00eate pseudo est plac\u00e9 devant l’en-t\u00eate TCP pour calculer la somme de contr\u00f4le. Calculez ensuite la joue. La somme est stock\u00e9e dans le champ “Tamis” et le fragment est envoy\u00e9. Aucun en-t\u00eate pseudo n’est jamais envoy\u00e9. TCP-Pseudo-Header (IPv4) D\u00e9calage de bit Bits 0\u20133 4\u20137 8-15 16\u201331 0 Adresse du remplacement IP 32 Adresse du r\u00e9cepteur IP soixante-quatre 00000000 6 (= TCP) TCP 96 Quellport Zielport 128 Num\u00e9ro de s\u00e9quence 160 Num\u00e9ro ACK 192 Datenoffset R\u00e9serv\u00e9 Drapeaux Fen\u00eatre 224 Sommet Pointeur urgent 256 Options (en option) 256\/288 + Donn\u00e9es  Le calcul du montant du test pour IPv4 est en RFC 793 Sont d\u00e9finis: La somme d’essai est le compl\u00e9ment 16 bits du compl\u00e9ment total de tous les mots 16 bits dans l’en-t\u00eate et les donn\u00e9es utiles du protocole sous-jacent. Si un segment contient des octets de nombre impair, un octet de rembourrage est attach\u00e9. Le rembourrage n’est pas transf\u00e9r\u00e9. Pendant le calcul de la somme de contr\u00f4le, le champ de somme d’essai lui-m\u00eame est rempli de z\u00e9ros.  En \u00e9cart par rapport \u00e0 cela, IPv6 voit l’en-t\u00eate pseudo selon RFC 2460 comme suit: ” Tout transport ou autre protocole de couche sup\u00e9rieure qui inclut les adresses de l’en-t\u00eate IP dans son calcul de somme de contr\u00f4le doit \u00eatre modifi\u00e9e pour une utilisation sur IPv6, pour inclure les adresses IPv6 128 bits au lieu d’adresses IPv4 32 bits. ” Tcp pseudo-t\u00eate pour ipv6 D\u00e9calage de bit 0\u20137 8-15 16-23 24\u201331 0 Cette demande 32 soixante-quatre 96 128 Adresse cible 160 192 224 256 TCP 288 Z\u00e9ro En-t\u00eate suivant 320 Quellport Zielport 352 Num\u00e9ro de s\u00e9quence 384 Num\u00e9ro ACK 416 Datenoffset R\u00e9serv\u00e9 Drapeaux Fen\u00eatre 448 Sommet Pointeur urgent 480 Options (en option) 480\/512 + Donn\u00e9es  Le destinataire cr\u00e9e \u00e9galement l’en-t\u00eate pseudo, puis effectue le m\u00eame calcul sans d\u00e9finir le champ de somme de contr\u00f4le sur z\u00e9ro. Cela devrait rendre le r\u00e9sultat FFFF (hexad\u00e9cimal). Si ce n’est pas le cas, le segment TCP est rejet\u00e9 sans message. En cons\u00e9quence, le temporisateur RTT est \u00e0 court de l’exp\u00e9diteur et le segment TCP est \u00e0 nouveau envoy\u00e9. La raison de cette proc\u00e9dure compliqu\u00e9e est que les parties de l’en-t\u00eate IP changent dans le r\u00e9seau IP pendant le routage. Le champ TTL est d\u00e9cr\u00e9ment\u00e9 de celui avec chaque IP-HOP. Si le champ TTL \u00e9tait incorpor\u00e9 dans le calcul de la somme d’essai, IP d\u00e9truirait le transport du transport par TCP. Par cons\u00e9quent, seule une partie de l’en-t\u00eate IP est incluse dans le calcul de la somme d’essai. D’une part, la quantit\u00e9 de test est sensible \u00e0 des erreurs incroyables en raison de sa longueur de seulement 16 bits et en raison de la simple r\u00e9gulation de calcul. De meilleures proc\u00e9dures telles que CRC-32 \u00e9taient consid\u00e9r\u00e9es comme trop co\u00fbteuses au moment de la d\u00e9finition. Contrairement \u00e0 la connexion avec la connexion, TCP impl\u00e9mente un flux de donn\u00e9es bidirectionnel, orient\u00e9 octet et fiable entre deux points de terminaison. Le protocole sous-jacent (IP) est orient\u00e9 vers le package, par lequel les packages de donn\u00e9es peuvent \u00eatre perdus, peuvent arriver dans le mauvais ordre et peuvent m\u00eame \u00eatre re\u00e7us deux fois. TCP a \u00e9t\u00e9 d\u00e9velopp\u00e9 pour faire face \u00e0 l’incertitude des couches en dessous. Il v\u00e9rifie donc l’int\u00e9grit\u00e9 des donn\u00e9es au moyen de la somme d’essai dans la t\u00eate du package et assure l’ordre par num\u00e9ros de s\u00e9quence. L’\u00e9metteur r\u00e9p\u00e8te l’envoi de packages en cas de confirmation dans un certain d\u00e9lai (d\u00e9lai d’attente). Les donn\u00e9es des packages sont fusionn\u00e9es dans un flux de donn\u00e9es dans un tampon dans un tampon dans le bon ordre et les packages doubles sont rejet\u00e9s. Bien s\u00fbr, le transfert de donn\u00e9es peut \u00eatre perturb\u00e9, retard\u00e9 ou compl\u00e8tement interrompu \u00e0 tout moment apr\u00e8s “\u00e9tablir une connexion”. Le syst\u00e8me de transmission se heurte ensuite \u00e0 un d\u00e9lai d’attente. La \u00abstructure de connexion\u00bb r\u00e9alis\u00e9e \u00e0 l’avance ne fournit donc aucune garantie d’une transmission s\u00e9curis\u00e9e en permanence ult\u00e9rieure. La longueur respective du tampon, jusqu’\u00e0 laquelle il n’y a pas d’espace dans le flux de donn\u00e9es, est confirm\u00e9 ( vitre ). Cela permet de profiter de la largeur du ruban du r\u00e9seau, m\u00eame sur de grandes itin\u00e9raires. En cas de connexion \u00e0 l’\u00e9tranger ou par satellite, l’arriv\u00e9e du premier signal ACK prend parfois plusieurs 100 millisecondes pour des raisons techniques, pendant ce temps, plusieurs centaines de colis peuvent \u00eatre envoy\u00e9s. L’\u00e9metteur peut remplir le tampon receveur avant l’arriv\u00e9e de la premi\u00e8re confirmation. Tous les packages du tampon peuvent \u00eatre confirm\u00e9s ensemble. Les confirmations peuvent \u00eatre ins\u00e9r\u00e9es en plus des donn\u00e9es dans l’en-t\u00eate TCP du flux de donn\u00e9es oppos\u00e9 ( insouciant ) Si le destinataire dispose \u00e9galement de donn\u00e9es pour l’\u00e9metteur. Douglas Comer: Internetworking avec TCP \/ IP. Principes, protocoles et architectures. Prentice Hall, 2000, ISBN 0-13-018380-6. Craig Hunt: Administration du r\u00e9seau TCP \/ IP. O\u2019Reilly, Bejing 2003, ISBN 3-89721-179-3. Richard Stevens: TCP \/ IP illustr\u00e9. Volume 1. Les protocoles . Addison-Wesley, Boston 1994, 2004. ISBN 0-201-63346-9. Richard Stevens: TCP \/ IP illustr\u00e9. 2ieme volume. La mise en oeuvre . Addison-Wesley, Boston 1994, ISBN 0-201-63354-X. Andrew S. Tanenbaum: R\u00e9seaux informatiques. 4e \u00e9dition. Pearson Studium, Munich 2003, ISBN 978-3-8273-7046-4, p. 580 ff. James F. Kurose, Keith W. Ross: R\u00e9seaux informatiques. Une approche descendante en mettant l’accent sur Internet. Baf\u00f6g Edition. Pearson Studies, Munich 2004, ISBN 3-8273-7150-3. Michael Tischer, Bruno Jennrich: Internet en interne. Technologie et programmation. Data-Becker, D\u00fcsseldorf 1997, ISBN 3-8158-1160-0. RFC  RFC 793 (Protocole de contr\u00f4le de la transmission) RFC 1071 (Calculez la somme du test pour IP, UDP et TCP) RFC 1122 (Fixation d’erreurs \u00e0 TCP) RFC 1323 (Extensions \u00e0 TCP) RFC 2018 (Sack TCP – Options de reconnaissance s\u00e9lective) RFC 3168 (Notification de congestion explicite) RFC 5482 (Option TCP Timeout utilisateur) RFC 5681 (Contr\u00f4le de surcharge TCP de la con\u00e9sion TCP) RFC 7414 (Aper\u00e7u des RFC TCP) Autre  \u2191  Ne pas confondre avec emballer . La t\u00e2che de TCP n’est pas de transf\u00e9rer des packages, mais les octets d’un flux de donn\u00e9es. La m\u00e9diation du package est fournie par le protocole Internet (IP). Par cons\u00e9quent, IP est m\u00e9di\u00e9 par le package, mais le package TCP.  \u2191   Num\u00e9ros de port. Internet Assigned Numbers Authority (IANA), 18. Juni 2010, Consult\u00e9 le 7 ao\u00fbt 2014 (Anglais).   \u2191   RFC 793. Internet Engineering Task Force (IETF), 1981. \u00abUne demande ouverte passive signifie que le processus souhaite accepter les demandes de connexion entrantes plut\u00f4t que de tenter d’initier une connexion.\u00bb  \u2191   RFC 793. Internet Engineering Task Force (IETF), 1981. \u00abBri\u00e8vement les significations des \u00c9tats sont: \u00e9couter – repr\u00e9sente l’attente d’une demande de connexion \u00e0 tout TCP et port distant.\u00bb  \u2191  W. Richard Stevens: TCP \/ IP Illustrated, vol. 1: les protocoles. Addison-Wesley, Kapitel 18.  \u2191  Steven M. Bellovin: RFC 1948 – D\u00e9fendre contre les attaques du num\u00e9ro de s\u00e9quence . Internet Engineering Task Force (IETF), 1996  \u2191  RFC 6298 – Calcul de la minuterie de retransmission de TCP  \u2191  Stevens, W. Richard, Allman, Mark, Paxson, Vern: Contr\u00f4le de la congestion TCP. Consult\u00e9 le 9 f\u00e9vrier 2017 (Anglais).        (adsbygoogle = window.adsbygoogle || []).push({});after-content-x4"},{"@context":"http:\/\/schema.org\/","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"https:\/\/wiki.edu.vn\/all2fr\/wiki1\/#breadcrumbitem","name":"Enzyklop\u00e4die"}},{"@type":"ListItem","position":2,"item":{"@id":"https:\/\/wiki.edu.vn\/all2fr\/wiki1\/protocole-de-controle-de-la-transmission-wikipedia\/#breadcrumbitem","name":"Protocole de contr\u00f4le de la transmission – Wikipedia"}}]}]