Ethernet

Frames/Ethernet packets : ce qui circule dans les câbles (trames en français) : 1518 octets (B/bytes)

• En cas de perte de paquet, il ne se passe rien
• S’il a été modifié, il est rejeté

CRC c’est une optimisation, pas une fonctionnalité, le CRC rejette les paquets évidemment faux, pas basé sur la validité de la donnée en tant que telle, car le CRC n’est pas parfait.

EtherType codera que la donnée est de l’IP si on utilise le TCP/IP.

Débit réseau filaire : $\approx$ 1Gb/s (débit disque SSD : $\approx$ 24Gb/s)

Switch fabric (tissu du réseau)

• Hub : répète un signal sans traitement, envoie le signal sur toutes ses connexions.
• Switch : un hub, mais avec du traitement, donc il redirige uniquement aux bons destinataires en associant les adresses et les ports grâce à son “cache” (sinon il fait une annonce globale pour trouver le destinataire).
• Routeur : Comme un switch, mais il permet aussi de faire de l’analyse TCP/IP (il voit les adresses IP et les réseaux virtuels).

On veut que le ToR (top of rack) soit le plus rapide possible. Le switch est au ToR.

TCP/IP

Technologie utilisée partout sauf dans le cas des calculs scientifique, mais on s’en fout.

Le protocole TCP/IP garantit la livraison des données (en best-effort, il y a un timeout et il ne peut pas faire grand-chose si le destinataire dort).

Idée de “paquet en cours de transfert” : on a envoyé un paquet et on a pas encore reçu le ACK (acknowledgement).

TCP est bidirectionnelle, il y a une notion de “connexion”.

Le protocole UDP est très proche de l’Ethernet, car il n’offre aucune garantit, c’est le minimum possible au-dessus d’Ethernet.

QUIC de Google : Construit sur UDP avec les “vérifications” de UDP qui est chiffré pour empêcher les navigateurs de trop regarder ce qu’il y a dedans et améliorer les performances

VLAN

Réseau virtuel

RPC

• Appel bloquant synchrone
• Appel asynchrone

Met $t_{2}< t_1$ ? Dépend de l’horloge…

$$\text{slope : } (t_{4}-t_{1}) - (t_{3} - t_{2}) - t_{\text{request}} - t_{\text{response}}$$

• $t_{request}$ : temps que la requête a pris
• $t_{response}$ : temps que la réponse a pris
• slope : temps de dépertition/perte, qui doit être le plus bas possible.

Serveur canary : on lance une requête avant de la distribuer pour ne pas faire crash tous les serveurs.