🥇Les bases de la transmission de données fiable

À ceux qui vise s'intéressent aux réseaux et aux protocoles.

En résumé

Cet article aborde les bases de la transmission fiable des données, avec des exemples sur Go, y compris UDP et TCP. Inspiré par un, deux, trois et le livre "Réseaux informatiques. Approche descendante", car tout le monde parle seulement de Tanenbaum et d'Olifer.

Le protocole de transport

assure une connexion logique entre les processus applicatifs s'exécutant sur différents hôtes. La connexion logique du point de vue des applications apparaît comme un canal reliant directement les processus.

Les protocoles de transport sont pris en charge par les systèmes finaux, mais pas par les routeurs de réseau (sauf pour — DPI). Du côté de l'émetteur, le niveau de transport convertit les données du niveau applicatif, reçues du processus applicatif émetteur, en paquets de transport, appelés segments.

Cela se fait en fragmentant (si nécessaire) les messages du niveau applicatif en morceaux et en ajoutant un en-tête de niveau de transport à chacun d'eux.

Ensuite, le niveau de transport transmet le segment au niveau réseau de l'émetteur, où le segment est encapsulé dans un paquet de niveau réseau (datagramme) et envoyé. Du côté récepteur, le niveau réseau extrait le segment de niveau transport du datagramme et le transmet au niveau de transport. Ensuite, le niveau de transport traite le segment reçu de manière à rendre ses données accessibles à l'application réceptrice.

Principes de transmission fiable des données

Transmission fiable des données sur un canal parfaitement fiable

C'est le cas le plus simple. La partie émettrice reçoit simplement les données du niveau supérieur, crée un paquet contenant ces données et l'envoie dans le canal.

Serveur

package main

import (
    "log"
    "net"
)

func main() {
    // Adresse IP du serveur et port
    serverAddr, err := net.ResolveUDPAddr("udp", "127.0.0.1:12000")
    if err != nil {
        log.Fatal(err)
    }

    // créer un socket avec le port
    serverConn, err := net.ListenUDP("udp", serverAddr)
    if err != nil {
        log.Fatal(err)
    }
    // fermeture différée de la connexion
    defer serverConn.Close()

    // créer un buffer pour les données
    buf := make([]byte, 1024)

    // attendre la connexion
    for {
        // lire la demande
        n, addr, err := serverConn.ReadFromUDP(buf)
        // transmettre les données au NIVEAU SUPÉRIEUR : dans notre cas stdout
        println(string(buf[0:n]), " form ", addr.IP.String())
        if err != nil {
            log.Fatal(err)
        }
        // pas de réponse, car c'est UDP + canal fiable
    }
}

Client

package main

import (
    "fmt"
    "log"
    "net"
    "time"
)

func main() {
    // Adresse IP du serveur et port
    serverAddr, err := net.ResolveUDPAddr("udp", "127.0.0.1:12000")
    if err != nil {
        log.Fatal(err)
    }
    // Adresse IP locale et port
    localAddr, err := net.ResolveUDPAddr("udp", "127.0.0.1:0")
    if err != nil {
        log.Fatal(err)
    }
    // Établissement de la connexion
    conn, err := net.DialUDP("udp", localAddr, serverAddr)
    if err != nil {
        log.Fatal(err)
    }
    // Fermeture décalée de la connexion
    defer conn.Close()

    for {
        // Réception de données de la COUCHE SUPÉRIEURE
        fmt.Print("Entrez une phrase en clair > ")
        var msg string
        _, err := fmt.Scanf("%s", &msg)
        if err != nil {
            log.Fatal(err)
        }
        // Un flux de bytes est transmis, pas une chaîne
        buf := []byte(msg)
        // Écriture (transmission) dans la connexion
        _, err = conn.Write(buf)
        if err != nil {
            log.Fatal(err)
        }
        // Une seconde
        time.Sleep(time.Second * 1)
    }
}

Transmission fiable des données via un canal avec d'éventuelles erreurs

L'étape suivante consiste à supposer que tous les paquets transmis sont reçus dans l'ordre dans lequel ils ont été envoyés, mais que des bits peuvent être endommagés, car le canal transmet parfois des données de manière altérée.

Dans ce cas, des mécanismes sont appliqués :

détection des erreurs ;
retour d'information ;
retransmission.

Les protocoles de transmission fiable des données qui possèdent de tels mécanismes de retransmission sont appelés protocoles à demande de retransmission automatique (Automatic Repeat reQuest, ARQ).
De plus, il convient de prévoir la possibilité d'erreurs dans les accusés de réception, lorsque la partie réceptrice ne reçoit aucune information sur les résultats de la transmission du dernier paquet.
La solution à ce problème, utilisée notamment dans TCP, consiste à ajouter un nouveau champ contenant le numéro de séquence du paquet dans le paquet de données.

Transmission fiable des données sur un canal non fiable, permettant la distorsion et la perte de paquets

Malheureusement, en plus de ces distorsions, la perte de paquets est également présente sur le réseau.
Et pour résoudre ce problème, des mécanismes sont nécessaires :

détection de la perte de paquets ;
retransmission des paquets perdus à la partie réceptrice.

En plus de la perte de paquets, il est nécessaire de prévoir la possibilité de la perte d'accusés de réception ou, si rien n'est perdu, de leur livraison avec un retard significatif. Dans tous les cas, la même action est effectuée : la retransmission du paquet. Un minuteur est utilisé pour contrôler le temps dans ce mécanisme, permettant de déterminer la fin de l'intervalle d'attente. Ainsi, dans le paquet net le paramètre TCPKeepAlive est défini sur 15 secondes par défaut :

// defaultTCPKeepAlive is a default constant value for TCPKeepAlive times
// See golang.org/issue/31510
const (
    defaultTCPKeepAlive = 15 * time.Second
)

Le côté émetteur doit démarrer le minuteur chaque fois qu'il transmet un paquet (que ce soit lors de la première transmission ou de la retransmission), gérer les interruptions du minuteur et l'arrêter.

Ainsi, nous avons examiné les concepts clés des protocoles de transmission de données fiables :

les sommes de contrôle ;
les numéros de séquence des paquets ;
les minuteurs ;
les accusés de réception positifs et négatifs.

Mais ce n'est pas tout !

Le protocole de transmission de données fiables avec mise en pipeline

Dans la version que nous avons déjà examinée, le protocole de livraison fiable est très inefficace. Il commence à « freiner » la transmission assurée par le canal de communication lorsque le RTT augmente. Pour améliorer son efficacité et mieux utiliser la bande passante du canal de communication, la mise en pipeline est appliquée.

L'application de la mise en pipeline conduit à :

une augmentation de la plage des numéros de séquence, car tous les paquets envoyés (à l'exception des retransmissions) doivent être identifiables de manière unique ;
un besoin accru de buffers du côté de l'émetteur et du récepteur.

La plage des numéros de séquence et les exigences concernant la taille des buffers dépendent des actions entreprises par le protocole en réponse à la distorsion, à la perte et au retard des paquets. Dans le cas de la mise en pipeline, il existe deux méthodes de correction des erreurs :

retourner à N paquets en arrière ;
répétition sélective.

Retourner à N paquets en arrière — le protocole à fenêtre glissante

L'expéditeur doit prendre en charge trois types d'événements :

appel via un protocole de niveau supérieur. Lorsque la fonction d'envoi de données est appelée « d'en haut », la partie émettrice vérifie d'abord le degré de remplissage de la fenêtre (c'est-à-dire la présence de N messages envoyés en attente d'accusés de réception). Si la fenêtre n'est pas remplie, un nouveau paquet est formé et transmis, et les valeurs des variables sont mises à jour. Dans le cas contraire, la partie émettrice renvoie les données au niveau supérieur, ce qui implique de manière implicite que la fenêtre est remplie. En général, le niveau supérieur tentera de retransmettre les données après un certain temps. Dans une application réelle, l'expéditeur aurait probablement soit mis en mémoire tampon les données (au lieu de les envoyer immédiatement), soit disposé d'un mécanisme de synchronisation (comme un sémaphore ou un drapeau) permettant au niveau supérieur d'appeler la fonction d'envoi de données uniquement lorsque la fenêtre n'est pas remplie.
accusé de réception. Dans le protocole pour un paquet avec le numéro de séquence N, un accusé général est émis, indiquant que tous les paquets avec des numéros de séquence précédant N ont été acceptés avec succès.
expiration du délai d'attente. Pour déterminer les pertes et les retards de paquets et d'accusés de réception, le protocole utilise un minuteur. Si le délai d'attente expire, la partie émettrice renvoie tous les paquets non confirmés.

répétition sélective

Lorsque la taille de la fenêtre et le produit de la bande passante par le délai de propagation sont élevés, un grand nombre de paquets peuvent être en transit. Dans ce cas, une erreur d'un paquet particulier peut entraîner la retransmission d'un grand nombre de paquets, dont la plupart n'étaient pas nécessaires.

Exemple

Meilleures théoriques pratiques rassemblées dans une mise en œuvre pratique TCP. Et si quelqu'un sait comment faire mieux — bienvenue.

Serveur

package main

import (
    "bufio"
    "fmt"
    "log"
    "net"
    "strings"
)

func main() {
    // créer un socket sur le port 
    ln, err := net.Listen("tcp", ":8081")
    if err != nil {
        log.Fatalln(err)
    }
    // attente d'un appel
    conn, _ := ln.Accept()

    for {
        // lecture des données
        msg, err := bufio.NewReader(conn).ReadString('n')
        if err != nil {
            log.Fatalln(err)
        }
        // affichage du message dans stdout
        fmt.Print("Message reçu:", string(msg))
        // conversion de la chaîne en majuscules
        newMsg := strings.ToUpper(msg)
        // envoi des données
        conn.Write([]byte(newMsg + "n"))
    }
}

Client

package main

import (
    "bufio"
    "fmt"
    "log"
    "net"
    "os"
)

func main() {
    // établissant la connexion
    conn, err := net.Dial("tcp", "127.0.0.1:8081")
    if err != nil {
        log.Fatalln(err)
    }

    for {
        // lecture des données depuis stdin
        reader := bufio.NewReader(os.Stdin)
        fmt.Print("Texte à envoyer : ")
        // ligne par ligne
        text, err := reader.ReadString('n')
        if err != nil {
            log.Fatalln(err)
        }
        // envoi
        fmt.Fprintf(conn, text+"n")
        // réception
        msg, err := bufio.NewReader(conn).ReadString('n')
        if err != nil {
            log.Fatalln(err)
        }
        // affichage de la réponse reçue
        fmt.Print("Msg du serveur : " + msg)
    }
}

Sortie

Mécanismes garantissant une transmission fiable des données et leur utilisation

Le mécanisme
Application, commentaire

Somme de contrôle
Utilisée pour détecter les erreurs de bits dans le paquet transmis

Chronomètre
Délai d'attente et indication de son expiration. Cela signifie qu'il est très probable que le paquet ou son accusé de réception ont été perdus lors de la transmission. Dans le cas où le paquet est livré avec retard mais n'est pas perdu (expiration prématurée du délai d'attente), ou s'il y a une perte de l'accusé de réception, une retransmission entraîne un doublon du paquet du côté du récepteur

Numéro de séquence
Utilisé pour la numérotation séquentielle des paquets de données transmis de l'expéditeur au destinataire. Les écarts dans les numéros de séquence des paquets reçus permettent au destinataire de détecter la perte de paquet. Des numéros de séquence identiques signifient que les paquets se dupliquent

Accusé de réception
Généré par le récepteur et indique à l'expéditeur que le paquet ou le groupe de paquets correspondant a été reçu avec succès. En général, l'accusé de réception contient les numéros de séquence des paquets reçus avec succès. Selon le protocole, on distingue les accusés de réception individuels et groupés

Accusé de réception négatif
Utilisé par le récepteur pour informer l'expéditeur que le paquet a été reçu de manière incorrecte. L'accusé de réception négatif inclut généralement le numéro de séquence du paquet qui n'a pas été correctement reçu

Fenêtre, pipeline
Ils limitent la plage des numéros de séquence qui peuvent être utilisés pour la transmission de paquets. La diffusion groupée et la poignée de main permettent d'augmenter considérablement la capacité des protocoles par rapport au mode d'attente des accusés de réception. Comme nous le verrons, la taille de la fenêtre peut être calculée en fonction des capacités de réception et de mise en tampon du côté récepteur, ainsi que du niveau de congestion du réseau.

D'autres exemples d'utilisation de Go pour le travail en réseau.

Dans dépôts.

Source : habr.com

Les bases du transfert de données fiable