WEBVTT

00:00.090 --> 00:01.020
Jason : Dans cette

00:01.020 --> 00:03.480
leçon, nous allons discuter des types de

00:03.480 --> 00:05.637
protocoles IP, y compris TCP, UDP, et

00:05.637 --> 00:07.650
des concepts de méthodes sans connexion

00:07.650 --> 00:10.020
et orientées connexion.

00:10.020 --> 00:12.300
Qu'est-ce que le TCP ?

00:12.300 --> 00:15.270
TCP est un protocole de contrôle de transmission.

00:15.270 --> 00:17.340
Il s'agit d'un protocole orienté connexion,

00:17.340 --> 00:18.990
ce qui signifie qu'il s'agit d'un moyen

00:18.990 --> 00:22.080
fiable de transporter des segments à travers notre réseau.

00:22.080 --> 00:23.580
Désormais, si un segment est abandonné,

00:23.580 --> 00:25.770
le protocole demandera un accusé de réception à chaque

00:25.770 --> 00:26.603
fois.

00:26.603 --> 00:28.890
Et s'il ne reçoit pas cet accusé de réception,

00:28.890 --> 00:31.530
il va renvoyer l'information.

00:31.530 --> 00:34.410
C'est la raison pour laquelle nous appelons ce protocole un protocole à connexion

00:34.410 --> 00:36.960
complète, car il s'agit d'un type d'information bidirectionnelle

00:36.960 --> 00:38.280
: je vous envoie des informations et

00:38.280 --> 00:40.200
je vérifie que vous les avez bien reçues en écoutant

00:40.200 --> 00:43.170
que vous les avez reçues et que vous me donnez une réponse.

00:43.170 --> 00:44.640
Examinons maintenant ce petit diagramme

00:44.640 --> 00:46.230
à l'écran pendant une seconde.

00:46.230 --> 00:48.210
Vous allez voir que j'ai un client à gauche

00:48.210 --> 00:49.800
et un serveur à droite.

00:49.800 --> 00:52.860
Le client va envoyer ce que l'on appelle un paquet

00:52.860 --> 00:54.510
syn, ou paquet de synchronisation,

00:54.510 --> 00:55.950
au serveur.

00:55.950 --> 00:57.240
Lorsque le serveur reçoit

00:57.240 --> 00:58.170
ce message, il renvoie

00:58.170 --> 01:00.720
au client un accusé de réception de synchronisation,

01:00.720 --> 01:02.580
appelé syn ack.

01:02.580 --> 01:04.740
Lorsque le client reçoit cet accusé de réception,

01:04.740 --> 01:07.380
il renvoie son propre accusé de réception au serveur.

01:07.380 --> 01:09.060
C'est ce qu'on appelle l'ack.

01:09.060 --> 01:11.940
Lorsque nous faisons ce syn, syn ack, ack, c'est ce

01:11.940 --> 01:15.030
que nous appelons une poignée de main à trois voies.

01:15.030 --> 01:16.807
En gros, c'est le client qui dit : "Hé,

01:16.807 --> 01:19.440
serveur, es-tu prêt à recevoir des informations ? Le serveur répond alors : "Bien

01:19.440 --> 01:21.367
sûr".

01:21.367 --> 01:21.367
Pourquoi pas ?

01:21.367 --> 01:22.920
"Envoyez-moi des informations. Et le client dit

01:22.920 --> 01:25.440
: "Voilà, c'est parti. Ensuite, la transmission va commencer parce

01:25.440 --> 01:27.630
que nous avons établi cette poignée de

01:27.630 --> 01:29.940
main à trois et que nous savons que les deux

01:29.940 --> 01:32.737
parties sont prêtes à communiquer.

01:32.737 --> 01:33.937
"Maintenant, vous êtes prêts ? "Oui, je le

01:33.937 --> 01:36.810
suis. "Le voici.

01:36.810 --> 01:36.810
Chaque

01:36.810 --> 01:39.150
fois que ces données, que nous appelons un segment,

01:39.150 --> 01:40.710
sont envoyées sur le réseau, un accusé

01:40.710 --> 01:43.080
de réception est reçu et nous indique que la communication

01:43.080 --> 01:45.030
bidirectionnelle s'est déroulée avec

01:45.030 --> 01:46.980
succès.

01:46.980 --> 01:48.600
Si ce serveur s'attend à recevoir

01:48.600 --> 01:50.370
100 informations, mais qu'il n'en

01:50.370 --> 01:52.500
a reçu que 98, il dira au client : "Vous

01:52.500 --> 01:53.587
m'aviez dit que vous

01:53.587 --> 01:56.347
alliez m'envoyer 100 choses, mais vous ne m'en avez

01:56.347 --> 01:58.177
envoyé que 98.

01:58.177 --> 02:00.450
"Envoyez-moi les deux choses qui me manquent. Ensuite, une retransmission

02:00.450 --> 02:02.730
a lieu.

02:02.730 --> 02:03.563
De cette façon, la communication

02:03.563 --> 02:05.310
peut se dérouler pour nous et nous pouvons toujours

02:05.310 --> 02:06.240
nous assurer que nous recevons

02:06.240 --> 02:07.470
ce que nous sommes censés recevoir

02:07.470 --> 02:09.450
parce que nous avons ce renvoi des paquets à travers le

02:09.450 --> 02:10.920
réseau.

02:10.920 --> 02:13.170
Il est utilisé pour toutes les données du réseau

02:13.170 --> 02:16.830
qui doivent être assurées d'arriver à leur destination finale.

02:16.830 --> 02:19.470
J'aime à penser que c'est comme un courrier certifié.

02:19.470 --> 02:22.440
Si je veux envoyer un message au fisc, par exemple, je veux m'assurer

02:22.440 --> 02:23.970
qu'il le recevra et qu'il ne se perdra

02:23.970 --> 02:25.620
pas dans le courrier.

02:25.620 --> 02:27.630
Je peux donc payer un peu plus cher pour obtenir un

02:27.630 --> 02:29.160
reçu certifié qui, une fois arrivé à destination,

02:29.160 --> 02:31.080
doit être signé par la personne concernée et m'être

02:31.080 --> 02:32.820
renvoyé par la poste.

02:32.820 --> 02:33.653
Ainsi, lorsque

02:33.653 --> 02:34.740
je recevrai le reçu,

02:34.740 --> 02:37.500
je saurai que le fisc a bien reçu mon courrier.

02:37.500 --> 02:39.960
C'est ainsi que fonctionne le TCP.

02:39.960 --> 02:41.220
D'autre part, nous avons

02:41.220 --> 02:44.250
un autre protocole connu sous le nom d'UDP.

02:44.250 --> 02:47.250
UDP est ce que l'on appelle un protocole sans connexion, ce qui signifie

02:47.250 --> 02:49.770
qu'il n'a pas besoin d'attendre les connexions.

02:49.770 --> 02:52.830
UDP signifie User Datagram Protocol (protocole de datagramme utilisateur).

02:52.830 --> 02:54.270
La raison pour laquelle nous l'appelons

02:54.270 --> 02:56.160
datagramme est que si vous utilisez UDP, vous

02:56.160 --> 02:57.750
utilisez ce type de données.

02:57.750 --> 02:59.220
Il s'agit d'un datagramme.

02:59.220 --> 03:01.317
L'UDP n'est pas fiable et

03:01.317 --> 03:03.060
transmet des segments

03:03.060 --> 03:05.490
appelés datagrammes.

03:05.490 --> 03:06.510
Et s'ils sont abandonnés,

03:06.510 --> 03:09.000
l'expéditeur n'en saura jamais rien.

03:09.000 --> 03:10.830
Pourquoi voudrais-je envoyer des choses dont l'expéditeur

03:10.830 --> 03:12.300
n'est pas au courant et pour lesquelles

03:12.300 --> 03:14.220
je ne reçois aucun accusé de réception ?

03:14.220 --> 03:17.850
L'UDP est très utile pour le streaming audio et visuel, car il permet d'envoyer

03:17.850 --> 03:19.920
un grand nombre de données et il y a beaucoup moins

03:19.920 --> 03:22.620
de frais généraux lorsque l'on utilise l'UDP, parce qu'il

03:22.620 --> 03:24.810
n'y a pas cette constante poignée de main à trois

03:24.810 --> 03:25.950
pour l'établir et qu'il n'y

03:25.950 --> 03:27.840
a pas toutes les vérifications et tous les

03:27.840 --> 03:30.840
équilibres associés à l'utilisation du TCP.

03:30.840 --> 03:32.520
L'utilisation d'UDP permet

03:32.520 --> 03:35.190
donc d'augmenter les performances de votre réseau,

03:35.190 --> 03:37.800
car il n'y a aucune retransmission.

03:37.800 --> 03:39.870
Vous finirez par laisser tomber des informations.

03:39.870 --> 03:41.490
N'est-ce pas une mauvaise chose ?

03:41.490 --> 03:43.530
Pourquoi voudrions-nous laisser tomber des informations ?

03:43.530 --> 03:45.300
Pour certaines applications, cela n'a

03:45.300 --> 03:46.740
pas vraiment d'importance.

03:46.740 --> 03:49.440
Par exemple, vous êtes en train de visionner cette vidéo.

03:49.440 --> 03:52.110
Et si j'abandonnais pendant 1/100 de seconde,

03:52.110 --> 03:53.520
le remarqueriez-vous ?

03:53.520 --> 03:54.960
C'est pourquoi l'UDP est

03:54.960 --> 03:56.820
si efficace, car nous pouvons laisser

03:56.820 --> 03:59.520
tomber 1/100 du temps et vous ne le remarquerez

03:59.520 --> 04:03.120
même pas, et il n'y aura pas de retransmission.

04:03.120 --> 04:04.740
Mais avec le TCP, la mise en mémoire tampon

04:04.740 --> 04:06.300
sera beaucoup plus importante, car

04:06.300 --> 04:07.440
il faudra attendre, puis

04:07.440 --> 04:08.670
se faire renvoyer l'information,

04:08.670 --> 04:09.810
la placer au bon endroit et

04:09.810 --> 04:11.250
la restituer.

04:11.250 --> 04:13.770
Ainsi, en raison de cet accusé de réception et de

04:13.770 --> 04:15.870
ce surdébit, chaque seconde de cette vidéo

04:15.870 --> 04:17.880
finira par l'agrandir et utiliser beaucoup

04:17.880 --> 04:19.830
plus de bande passante.

04:19.830 --> 04:21.150
C'est l'une des principales

04:21.150 --> 04:24.660
raisons pour lesquelles nous utilisons UDP pour les flux vidéo et audio.

04:24.660 --> 04:28.740
Faisons un petit résumé du TCP par rapport à l'UDP.

04:28.740 --> 04:31.410
Car il s'agit d'un concept très, très important.

04:31.410 --> 04:33.600
En fait, si vous avez vos notes à portée de main,

04:33.600 --> 04:35.160
j'écrirais ce tableau que je vais

04:35.160 --> 04:36.420
vous présenter maintenant,

04:36.420 --> 04:38.520
alors que nous parlons de TCP et d'UDP.

04:38.520 --> 04:40.770
Parce que c'est vraiment important.

04:40.770 --> 04:43.380
Tout d'abord, le TCP est fiable, il dispose d'une

04:43.380 --> 04:44.820
poignée de main à trois voies,

04:44.820 --> 04:47.040
alors que l'UDP n'est pas très fiable.

04:47.040 --> 04:48.540
C'est un protocole peu fiable

04:48.540 --> 04:51.180
car il n'y a pas de poignée de main à trois.

04:51.180 --> 04:53.490
Le TCP est ce que nous appelons un protocole orienté connexion

04:53.490 --> 04:55.560
ou un protocole à connexion complète parce que nous

04:55.560 --> 04:56.880
avons cette poignée de main à trois

04:56.880 --> 04:57.960
voies dans les accusés de réception,

04:57.960 --> 05:00.660
alors que l'UDP est sans connexion.

05:00.660 --> 05:02.550
C'est la méthode du feu et de l'oubli.

05:02.550 --> 05:04.200
Je commence à envoyer des informations

05:04.200 --> 05:06.660
et j'espère que vous les recevrez.

05:06.660 --> 05:10.170
TCP utilise la retransmission de segments et le contrôle de flux

05:10.170 --> 05:12.030
qui est géré par le fenêtrage.

05:12.030 --> 05:13.230
En revanche, UDP ne

05:13.230 --> 05:16.230
prévoit ni retransmission ni fenêtrage.

05:16.230 --> 05:17.160
Avec le TCP, nous avons

05:17.160 --> 05:19.140
une segmentation de notre séquençage de tous

05:19.140 --> 05:20.820
nos différents segments.

05:20.820 --> 05:23.370
Avec UDP, il n'y a pas de séquençage.

05:23.370 --> 05:25.530
Cela signifie que lorsque j'enverrai tous les

05:25.530 --> 05:27.570
documents, je les enverrai dans l'ordre approprié,

05:27.570 --> 05:28.710
de 1 à 100.

05:28.710 --> 05:31.260
Je le ferai pour TCP et UDP.

05:31.260 --> 05:32.910
Maintenant, si vous manquez certains de

05:32.910 --> 05:34.350
ces éléments, ou s'ils arrivent dans

05:34.350 --> 05:36.480
un ordre différent parce qu'ils empruntent un chemin

05:36.480 --> 05:37.500
différent sur le réseau,

05:37.500 --> 05:38.520
avec TCP, ils sont séquencés,

05:38.520 --> 05:40.137
de sorte qu'il sait que vous en avez un à 1000

05:40.137 --> 05:42.420
et qu'il les remet dans le bon ordre.

05:42.420 --> 05:43.440
Avec UDP, quel que soit

05:43.440 --> 05:44.850
le nom sous lequel ils arrivent,

05:44.850 --> 05:46.650
c'est ainsi qu'ils seront diffusés.

05:46.650 --> 05:48.030
Ainsi, il peut arriver

05:48.030 --> 05:49.230
un, 50, deux, 500,

05:49.230 --> 05:50.910
trois, quatre, cinq,

05:50.910 --> 05:55.230
six, 20, dans n'importe quel ordre aléatoire.

05:55.230 --> 05:56.580
Et c'est ainsi que vous l'entendrez.

05:56.580 --> 05:59.010
Ainsi, dans le cas d'une vidéo, vous pouvez entendre des

05:59.010 --> 06:00.780
sauts ou des grincements aigus, ou quelque

06:00.780 --> 06:01.740
chose de ce genre, parce

06:01.740 --> 06:04.320
que l'une de ces images peut avoir été désordonnée.

06:04.320 --> 06:05.550
Maintenant, lorsque nous revenons

06:05.550 --> 06:08.010
au TCP, il va reconnaître chacun de ces segments.

06:08.010 --> 06:09.780
Il s'agit donc d'une reconnaissance.

06:09.780 --> 06:10.680
Si je ne la reçois pas,

06:10.680 --> 06:11.513
je sais que je ne l'ai

06:11.513 --> 06:13.650
pas reçue et je peux la faire retransmettre, puis

06:13.650 --> 06:15.000
la recevoir à nouveau.

06:15.000 --> 06:17.190
Avec UDP, il n'y a pas d'accusé de réception.

06:17.190 --> 06:20.220
Encore une fois, l'UDP a beaucoup moins de frais généraux parce

06:20.220 --> 06:21.540
qu'il n'y a pas de connexion,

06:21.540 --> 06:23.790
pas de fenêtrage, pas de retransmission, pas

06:23.790 --> 06:26.610
de séquençage et pas d'accusé de réception.

06:26.610 --> 06:28.620
Maintenant, si vous devez envoyer quelque

06:28.620 --> 06:30.870
chose et que vous voulez être sûr que la personne

06:30.870 --> 06:34.590
l'a reçu, vous devez vraiment utiliser TCP comme protocole de choix.

06:34.590 --> 06:36.930
C'est pourquoi nous allons vraiment utiliser TCP pour des

06:36.930 --> 06:39.510
activités telles que les services bancaires, les sites web et le

06:39.510 --> 06:40.770
commerce électronique, etc.

06:40.770 --> 06:42.900
Mais si nous avons quelque chose qui contient beaucoup

06:42.900 --> 06:44.550
de données, comme un flux audio ou vidéo,

06:44.550 --> 06:46.560
l'UDP est vraiment bien adapté, car nous n'avons

06:46.560 --> 06:47.490
pas besoin d'obtenir

06:47.490 --> 06:49.320
chaque morceau du fichier.

06:49.320 --> 06:50.880
Nous pouvons sauter un peu ici

06:50.880 --> 06:52.510
et là, et ce n'est pas grave.

06:52.510 --> 06:54.570
- : [Un autre instructeur] En ce qui concerne TCP

06:54.570 --> 06:56.820
et UDP, nous avons parlé du fait qu'il s'agit de protocoles

06:56.820 --> 06:58.560
à connexion complète ou orientés connexion,

06:58.560 --> 07:00.510
et de protocoles sans connexion.

07:00.510 --> 07:02.190
Permettez-moi donc de vous donner quelques

07:02.190 --> 07:05.340
exemples de protocoles qui utilisent soit TCP, soit UDP, afin que vous puissiez

07:05.340 --> 07:07.680
comprendre pourquoi nous utilisons l'un ou l'autre.

07:07.680 --> 07:08.513
Tout d'abord, examinons

07:08.513 --> 07:09.420
le protocole TCP et

07:09.420 --> 07:12.750
nos protocoles orientés connexion ou à connexion complète.

07:12.750 --> 07:17.520
Cela comprend des éléments tels que SSH, HTTP ou HTTPS.

07:17.520 --> 07:20.940
Pourquoi aurions-nous besoin d'une orientation vers les connexions dans ces cas-là ?

07:20.940 --> 07:23.490
Dans le cas de l'utilisation de quelque chose comme SSH,

07:23.490 --> 07:25.710
je fais de la communication bidirectionnelle

07:25.710 --> 07:28.320
et du contrôle de serveurs ou de postes de travail distants,

07:28.320 --> 07:30.390
et je peux le faire sur le port 22.

07:30.390 --> 07:31.830
Je veux m'assurer que je le fais

07:31.830 --> 07:34.920
d'une manière orientée vers la connexion ou pleine de connexion.

07:34.920 --> 07:37.110
Ainsi, lorsque j'envoie une commande et que je dis

07:37.110 --> 07:38.190
"redémarrer le serveur",

07:38.190 --> 07:40.080
je sais que cette commande est bien arrivée

07:40.080 --> 07:42.060
et que le redémarrage du serveur aura lieu.

07:42.060 --> 07:44.820
De même, lorsque nous utilisons HTTPS, nous devons nous assurer

07:44.820 --> 07:46.680
que nous disposons d'un protocole à connexion

07:46.680 --> 07:50.040
complète ou orientée vers la connexion utilisant TCP.

07:50.040 --> 07:51.120
La raison en est, encore une

07:51.120 --> 07:52.440
fois, que nous voulons nous assurer

07:52.440 --> 07:54.690
que ce que nous envoyons est bien reçu sur place.

07:54.690 --> 07:56.790
Il peut s'agir d'éléments tels que l'authentification

07:56.790 --> 07:58.500
lorsque nous essayons de nous connecter à un site

07:58.500 --> 08:00.090
web en utilisant notre nom d'utilisateur et

08:00.090 --> 08:01.500
notre mot de passe, ou encore les informations

08:01.500 --> 08:03.030
que nous recevons en retour de ce site web,

08:03.030 --> 08:06.180
telles que le solde de nos comptes et nos informations bancaires.

08:06.180 --> 08:07.013
En revanche, si

08:07.013 --> 08:08.970
nous utilisons le protocole UDP,

08:08.970 --> 08:11.400
nous travaillons sans connexion.

08:11.400 --> 08:12.390
J'ai déjà mentionné le fait que

08:12.390 --> 08:13.470
nous l'utilisons tout le temps

08:13.470 --> 08:15.600
pour des choses telles que le streaming audio et vidéo.

08:15.600 --> 08:16.680
Mais en plus de cela, nous

08:16.680 --> 08:19.230
l'utilisons aussi pour des choses comme le DHCP et le

08:19.230 --> 08:23.130
protocole de transfert de fichiers triviaux, connu sous le nom de TFTP.

08:23.130 --> 08:24.030
Si vous vous souvenez

08:24.030 --> 08:27.480
bien, le DHCP est utilisé comme protocole de contrôle dynamique

08:27.480 --> 08:30.660
de l'hôte et fonctionne sur les ports 67 et 68.

08:30.660 --> 08:32.310
Lorsque vous rejoignez un réseau,

08:32.310 --> 08:33.690
votre appareil, s'il est configuré

08:33.690 --> 08:35.850
pour une attribution dynamique de son adresse

08:35.850 --> 08:38.520
IP, envoie un message de diffusion sur ce réseau à la recherche

08:38.520 --> 08:40.650
d'un serveur DHCP.

08:40.650 --> 08:43.860
C'est pourquoi nous l'utilisons comme un protocole sans connexion.

08:43.860 --> 08:47.220
En effet, si ces informations sont envoyées et que personne ne répond,

08:47.220 --> 08:49.530
votre client les enverra à nouveau en espérant

08:49.530 --> 08:51.510
que quelqu'un d'autre sera présent.

08:51.510 --> 08:53.070
C'est ainsi que fonctionne le DHCP.

08:53.070 --> 08:55.080
Il va permettre l'envoi d'un message de

08:55.080 --> 08:57.090
diffusion, puis attendre une réponse.

08:57.090 --> 08:58.170
S'il ne reçoit pas de

08:58.170 --> 08:59.340
réponse dans un certain

08:59.340 --> 09:01.560
délai, il rediffuse simplement son message

09:01.560 --> 09:04.590
et recherche à nouveau un nouveau serveur DHCP.

09:04.590 --> 09:06.960
De même, le TFTP (Trivial File Transfer

09:06.960 --> 09:09.060
Protocol), qui opère sur le port

09:09.060 --> 09:11.250
69, fonctionne sans connexion en

09:11.250 --> 09:13.380
utilisant le protocole UDP comme

09:13.380 --> 09:15.690
moyen de transport.

09:15.690 --> 09:16.680
La raison en est que

09:16.680 --> 09:20.250
TFTP est le Trivial File Transfer Protocol, et que nous n'avons donc

09:20.250 --> 09:22.740
pas besoin d'avoir l'assurance que chaque paquet

09:22.740 --> 09:24.960
a été envoyé et reçu avec ces accusés de réception,

09:24.960 --> 09:26.250
ce qui crée beaucoup plus

09:26.250 --> 09:29.190
de surcharge si nous utilisons TCP.

09:29.190 --> 09:30.600
L'utilisation d'UDP permet donc

09:30.600 --> 09:32.430
un transfert de fichiers plus rapide lorsque

09:32.430 --> 09:34.500
l'on utilise quelque chose comme TFTP, au lieu

09:34.500 --> 09:38.163
d'utiliser un protocole qui nécessite plus de connexions, comme FTP.