Cours II Présentation générale des réseaux 28 7 – Couche transport

Download Report

Transcript Cours II Présentation générale des réseaux 28 7 – Couche transport

Cours II
Présentation générale des réseaux
7 – Couche transport (couche 4)
7.1 – Introduction
Dans la plupart des cas, les couches 5 (session) et 6 (présentation) du modèle OSI n’existent pas.
La couche transport segmente les données des applications (couche 7) à l’émission et se charge du réassemblage de
ces blocs de données à la réception.
Pour ce faire, elle doit :
•
•
•
•
identifier les différentes applications exécutées sur un hôte. Pour cela, un identificateur unique est affecté
à chaque application. Les protocoles du modèle TCP/IP appellent cet identificateur un numéro de port.
Chaque processus qui accède au réseau se voit affecter un numéro de port unique sur son hôte.
segmenter les données et gérer le transport de chaque segment de donnée par le réseau;
effectuer un suivi des communications individuelles entre une application exécutée sur l’hôte source et une
autre exécutée sur l’hôte destination ;
réassembler les segments en flux de données d’application à la réception;
Les protocoles de la couche transport offrent des services aux programmes de la couche application Ces fonctions
sont accessibles par des primitives appelées dans les programmes qui veulent transmettre ou recevoir des données
par le réseau.
28
Cours II
Présentation générale des réseaux
Selon les besoins des applications, les communications peuvent se faire de deux façons :
•
sans connexion : la communication est simple et rapide, mais elle n’est pas fiable.
o les données sont envoyées directement sur le réseau
o « au mieux »
Dans le modèle Internet, le protocole de couche transport sans connexion est UDP (User Datagram Protocol)
•
avec connexion : la communication est fiable. Elle se fait en 3 phases
o établissement de la connexion
o transfert des données
o libération de la connexion
Dans le modèle Internet, le protocole de couche transport avec connexion est TCP (Transmission Control
Protocol)
7.2 - Critères de choix d’un protocole de transport avec ou sans connexion pour une application
Certaines applications, comme les bases de données, les pages Web et les courriels, ont besoin que toutes les
données envoyées arrivent à destination dans leur état d’origine. Toute donnée manquante risque de corrompre la
communication en la rendant incomplète ou illisible. Ces applications utilisent un protocole de couche transport qui
implémente la fiabilité (avec connexion). On considère que la surcharge supplémentaire pour le réseau est
indispensable pour ces applications.
D’autres applications tolèrent mieux la perte de petites quantités de données. Si, par exemple, un ou deux segments
d’une lecture vidéo n’arrivent pas, cela ne fera que créer une interruption momentanée du flux. Ceci pourra se traduire
par une distorsion de l’image que l’utilisateur ne remarquera peut-être même pas.
Imposer une surcharge pour garantir la fiabilité risquerait de réduire l’utilité de l’application.
7.3 – Identification des applications
Pour différencier les segments (TCP) et les datagrammes (UDP) de chaque application, les protocoles TCP et UDP
utilisent des champs (de l’en-tête) identifiant chaque application de façon unique.
Ces identificateurs uniques sont les numéros de port.
L’en-tête de chaque segment ou datagramme contient un port source et un port de destination.
Le numéro de port source est le numéro associé à l’application d’origine sur l’hôte local (émetteur du segment) pour
une communication. Le numéro de port de destination est le numéro associé à l’application de destination sur l’hôte
distant (le récepteur) pour cette communication.
Les processus « serveur » se voient attribuer des numéros de ports statiques.
Les clients choisissent généralement dynamiquement un numéro de port pour chaque conversation.
Lorsqu’une application cliente envoie une requête à une application serveur, le port de destination inclus dans l’en-tête
est le numéro de port affecté à l’application serveur exécutée sur l’hôte distant. Le logiciel client doit savoir quel
numéro de port est associé au processus serveur sur l’hôte distant.
Par exemple, quand une application de navigateur Web envoie une requête à un serveur Web, le navigateur utilise le
protocole TCP et le port numéro 80, sauf indication contraire. Ceci est dû au fait que le port 80 du protocole TCP est le
port affecté par défaut aux applications de service Web (http). De nombreuses applications (serveur) courantes
ont des ports qui leur sont affectés par défaut (ports « bien connus »).
Le port source d’un en-tête de segment ou de datagramme d’une requête client est en général généré de façon
aléatoire (valeur >1024 et unique sur le client). Le numéro de port source de la requête (envoyée par le client) sert de
numéro de port de destination dans la réponse renvoyée par le serveur.
L’ensemble formé par le numéro de port de la couche transport et l’adresse IP de la couche réseau affectée à
l’hôte, identifie de façon unique un processus s’exécutant sur l’inter-réseau.
Cet ensemble est appelé une « interface de connexion » ou « extrémité de connexion ».
Une interface de connexion est notée adresse_ip:numero_port.
Une paire d’extrémités de connexion, composée des adresses IP et des numéros de port source et de
destination, est également unique et identifie une conversation entre deux hôtes.
Par exemple, une requête de page Web HTTP envoyée à un serveur Web (port 80) s’exécutant sur un hôte d’adresse
IP 192.168.1.20 sera destinée à l’interface de connexion 192.168.1.20:80. Si le navigateur Web demandant la
29
Cours II
Présentation générale des réseaux
page Web s’exécute sur l’hôte 192.168.100.48 et que le numéro de port dynamique affecté au navigateur Web est
49152, l’interface de connexion sur le client est 192.168.100.48:49152.
7.4 - Liste des ports TCP/UDP « bien connus »
Afin de permettre aux clients de contacter des serveurs, leurs numéros de ports logiciels sont « bien connus ». Ces
valeurs sont disponibles par le lien suivant : http://www.iana.org/assignments/port-numbers.
Ces informations sont en général reprises par chaque système dans un fichier.
Par exemple :
• sur linux : /etc/services
• sur Windows : %SystemRoot%\system32\drivers\etc\services
Extrait du fichier “services” d’un système Windows
#
#
#
#
Copyright (c) 1993-2004 Microsoft Corp.
This file contains port numbers for well-known services defined by IANA
Format:
<service name> <port number>/<protocol> [aliases...]
[#<comment>]
echo
echo
discard
discard
systat
systat
daytime
daytime
qotd
qotd
chargen
chargen
ftp-data
ftp
ssh
telnet
smtp
time
time
rlp
nameserver
nameserver
nicname
domain
domain
bootps
bootpc
tftp
gopher
finger
http
hosts2-ns
hosts2-ns
kerberos
kerberos
7/tcp
7/udp
9/tcp
9/udp
11/tcp
11/udp
13/tcp
13/udp
17/tcp
17/udp
19/tcp
19/udp
20/tcp
21/tcp
22/tcp
23/tcp
25/tcp
37/tcp
37/udp
39/udp
42/tcp
42/udp
43/tcp
53/tcp
53/udp
67/udp
68/udp
69/udp
70/tcp
79/tcp
80/tcp
81/tcp
81/udp
88/tcp
88/udp
sink null
sink null
users
users
#Active users
#Active users
quote
quote
ttytst source
ttytst source
#Quote of the day
#Quote of the day
#Character generator
#Character generator
#FTP, data
#FTP. control
#SSH Remote Login Protocol
mail
timserver
timserver
resource
name
name
whois
#Simple Mail Transfer Protocol
dhcps
dhcpc
www www-http
krb5 kerberos-sec
krb5 kerberos-sec
#Resource Location Protocol
#Host Name Server
#Host Name Server
#Domain Name Server
#Domain Name Server
#Bootstrap Protocol Server
#Bootstrap Protocol Client
#Trivial File Transfer
#World Wide Web
#HOSTS2 Name Server
#HOSTS2 Name Server
#Kerberos
#Kerberos
7.5 - UDP (User Datagram Protocol)
Dans l’en-tête du paquet IP, ce protocole de couche transport est identifié par le numéro 17 (0x11).
Le protocole UDP est un protocole simple, sans connexion, décrit par le document RFC 768.
Il présente l’avantage d’imposer peu de surcharge pour l’acheminement des données. Les blocs de communications
utilisés dans le protocole UDP sont appelés des datagrammes. Ces datagrammes sont envoyés « au mieux » par ce
protocole de couche transport.
Le protocole UDP est par exemple utilisé par des applications de :
• Système de noms de domaine (DNS)
• Lecture vidéo en continu
• Voix sur IP (VoIP)
• Routage dynamique (RIP)
30
Cours II
Présentation générale des réseaux
Datagramme UDP (32 bits soit 4 octets par ligne)
1
31
port source
long. Message UDP
port destination
Somme de contrôle
Données (application)
7.5 – TCP (Transmission Control Protocol)
7.5.1 – Dans l’en-tête du paquet IP, ce protocole de couche transport est identifié par le numéro 6.
Le protocole TCP impose une surcharge sur le réseau. Il permet :
• la livraison dans l’ordre
• l’acheminement fiable (accusés de réception)
• le contrôle du flux.
Les blocs de communications utilisés dans le protocole TCP sont appelés des segments. Ils utilisent 20 octets dans
l’en-tête pour encapsuler les données de la couche application.
Le protocole TCP est utilisé par exemple par :
• les navigateurs Web
• le courriel (mail)
• le transfert de fichiers
• et plus généralement tous les services qui nécessitent un transport fiable de données
Segment TCP (32 bits soit 4 octets par ligne)
1
31
port source
port destination
numéro de séquence
numéro d’acquittement
Longueur de
l’en-tête TCP (4)
Réservé (6)
indicateurs
U A P R S F
Somme de contrôle
Taille de la fenêtre
En-tête
TCP
pointeur de données urgentes (si U=1)
Options (longueur variable)
Données (application)
La transmission de données entre les applications se fait dans les deux sens.
Un segment peut servir à la fois à envoyer des données de l’application de l’hôte local vers l’hôte distant et à
acquitter les données reçues en provenance de l’hôte distant.
Description des champs de l’en-tête :
Numéro de séquence (4 octets): les octets transmis sont numérotés. Ce numéro est celui du premier octet transmis
dans les données (d’application) dans ce segment (lorsqu’il y en a).
Numéro d’acquittement (4 octets): il s’agit du numéro du numéro du prochain octet (d’application) attendu dans le
prochain segment reçu. Ce numéro acquitte les octets précédents, si l’indicateur ACK est marqué.
Taille de la fenêtre (2 octets) : ce champ permet de contrôler de flux. Le récepteur dispose d’un tampon de dans
lequel les données reçues sont stockées en attendant d’être traitées. La taille de la fenêtre indique combien d’octets,
le récepteur est capable de recevoir (nombre de cases libres dans le tampon) pour les prochains segments reçus.
31
Cours II
Présentation générale des réseaux
Pointeur de données urgentes (2 octets) : si l’indicateur U (urgent) est marqué, cette valeur indique le décalage des
données urgentes par rapport au numéro de séquence.
Indicateurs (6 bits):
•
•
•
•
•
•
URG : Signale la présence de données URGentes
ACK : Signale que le segment sert d’accusé de réception (ACKnowledgement).
Le champ n° d’acquittement indique que les octets précédents ce n° sont acquittés.
PSH : les données doivent être transmises le plus tôt possible à l’application (PuSH)
RST : Rupture anormale de la connexion (ReSeT)
SYN : Demande de SYNchronisation du numéro de séquence ou d’établissement de connexion
FIN : Indique la FIN du transfert des données
Options (longueur variable) : des options sont fréquemment utilisées lors de l’établissement de la connexion, par
exemple pour choisir la taille maximale d’un segment (MSS = Maximum Segment Size).
7.5.2 – Etablissement d’une connexion TCP
Elle se fait en 3 étapes (et 3 segments):
•
Etape 1 : segment 1 : client -> serveur
Le client TCP initie la connexion en envoyant un segment dont l’indicateur SYN est marqué. Cet indicateur
indique une valeur initiale dans le champ de numéro de séquence de l’en-tête. Cette valeur initiale, appelée
ISN (Initial Sequence Number), est choisie de façon aléatoire et sert à commencer le suivi du flot de données
entre le client et le serveur pour cette session.
•
Étape 2 : segment 2 : serveur -> client
Le serveur répond par un segment
• dont l’indicateur ACK est marqué pour valider la demande de synchronisation du client (le n°
d’acquittement est égal à ISN + 1)
• dont l’indicateur SYN est marqué pour indiquer son propre ISN (suivi du flux du serveur vers le client)
•
Etape 3 : segment 3 : client -> serveur
Le client envoie à son tour un segment dont l’indicateur ACK est marqué pour valider la demande de
synchronisation du serveur (le n° d’acquittement est égal à ISNserveur + 1).
7.5.3 – Libération d’une connexion TCP
Elle se fait en 4 étapes :
•
Etape 1 :
L’extrémité (1) qui a fini d’envoyer ses données envoie un segment dont l’indicateur FIN est marqué.
•
Etape 2 :
L’extrémité (2) qui reçoit le segment FIN acquitte ce segment pour libérer la connexion (dans le sens 1->2).
•
Etape 3 :
L’extrémité (2) envoie un segment dont l’indicateur FIN est marqué.
•
Etape 4 :
L’extrémité (1) qui reçoit le segment FIN acquitte ce segment pour libérer la connexion (dans le sens 2->1).
Remarques :
• A la réception d’un segment FIN, TCP notifie à l’application que le flot de données est terminé.
• L’extrémité qui émet le segment FIN effectue une libération « active ». L’autre effectue une libération passive.
• Bien que très rarement utilisé, TCP permet une libération unilatérale de la connexion (dans un seul sens).
Dans ce cas des données peuvent être transmises dans le seul sens restant ouvert entre les étapes 2 et 3.
7.5.4 – Exemple
Une application cliente sur 194.167.228.1 utilise le port TCP 50549 pour se connecter à l’application serveur de port
18 sur l’hôte80.125.123.172. Elle envoie 100 octets puis libère la connexion.
32
Cours II
Présentation générale des réseaux
194.167.228.1:50549
80.125.123.172 :18
SYN, seq=1000(len=0)
SYN,ACK, seq=5000(len=0), ack=1001
Etablissement
de la
connexion
ACK, seq=1001(len=0), ack=5001
seq=1001(len=100)
ACK, seq=5001(len=0), ack=1101
Transmission
de 100 octets
FIN, seq=1101(len=0)
ACK, seq=5001(len=0), ack=1101
FIN, seq=5001(len=0)
libération de
la connexion
ACK, seq=1101(len=0), ack=5001
8 – Couche application
8.1 - Introduction
La couche application du modèle Internet regroupe les couches 5, 6 et 7 du modèle OSI.
Les processus exécutant cette couche sont nombreux et de natures diverses.
•
•
•
•
Certaines applications donnent un accès au réseau à l’utilisateur final. Pour cela, elles utilisent les services
des couches inférieures de la pile de protocoles. Les clients de messagerie et les navigateurs Web sont des
exemples de ces types d’applications.
Ces applications échangent souvent des données avec des processus exécutés sur des hôtes connectés au
réseau appelés serveurs.
Elles peuvent aussi nécessiter l’assistance d’autres services de la couche application. Par exemple le service
DNS qui permet de trouver l’adresse IP d’un hôte à partir d’un nom de domaine est systématiquement utilisé
par les navigateurs web.
Certaine applications permettent de faciliter la gestion du réseau. Les applications de routage dynamique qui
permettent de mettre à jour automatiquement les tables de routage, l’attribution automatique des paramètres
de configuration réseau (DHCP) sont d’autres exemples de protocoles de la couche application.
8.2 – Le modèle client/serveur
Dans le modèle client/serveur, l’hôte qui demande les informations est nommé client et celui qui répond à la demande
est nommé serveur.
Les processus client et serveur font partie de la couche application.
33
Cours II
Présentation générale des réseaux
Les protocoles de couche application décrivent le format des requêtes et des réponses entre clients et serveurs. Outre
le transfert de données effectif, cet échange peut également nécessiter des informations de contrôle, telles que
l’authentification de l’utilisateur ou
l’identification d’un fichier de données à
transférer.
L’échange de données est toujours
bidirectionnel.
Le transfert de données d’un client vers un
serveur est désigné par le terme
téléchargement montant. Le transfert de
données d’un serveur vers un client est
désigné par le terme téléchargement
descendant.
Le serveur exécute un service de la couche
application nommé démon de serveur. Les
démons s’exécutent généralement en tâche de
fond et ne sont pas sous le contrôle direct de
l’utilisateur final. Ils sont décrits comme « étant
à l’écoute » d’une requête de la part d’un
client. Lorsqu’un démon reçoit une requête
d’un client, il échange les messages
appropriés avec le client, selon les règles
requises par son protocole.
8.3 – Le modèle « Peer to Peer »
Réseaux « Peer to Peer » (homologue à homologue)
Dans un réseau Peer to Peer, deux ordinateurs ou plus sont connectés via un réseau et peuvent partager des
ressources (par exemple, des imprimantes et des fichiers) sans disposer de serveur dédié. Chaque hôte connecté
(nommé homologue) peut opérer en tant que serveur ou en tant que client. Un ordinateur peut remplir le rôle de
serveur pour une transaction tout en servant simultanément de client pour un autre ordinateur. Les rôles de client et
de serveur sont définis en fonction de chaque requête.
Applications « Peer to Peer »
Une application Peer to Peer (P2P), permet à un périphérique d’opérer à la fois comme client et comme serveur au
sein d’une même communication. Dans ce modèle, chaque client est un serveur et chaque serveur un client. Les deux
peuvent lancer une communication et sont considérés comme égaux dans le processus de communication. Les
applications Peer to Peer nécessitent que chaque hôte fournisse une interface utilisateur et exécute un service en
tâche de fond.
34
Cours II
Présentation générale des réseaux
8.4 – Le système de noms de domaine : DNS
Les utilisateurs mémorisent difficilement les adresses numériques. Pour cette raison, des noms de domaine ont été
créés pour convertir les adresses numériques en noms simples et explicites appelés noms de domaines (par exemple,
www.iut-marseille.fr).
Avantages :
• Ils sont beaucoup plus faciles à mémoriser que leurs équivalents numériques (par exemple, 82.165.85.108)
• si l’organisme décide de changer d’adresse IP, ce changement est transparent pour l’utilisateur car le nom de
domaine ne change pas. La nouvelle adresse est simplement liée au nom de domaine existant.
Fichier hosts
Lorsque les réseaux sont de petite taille, il est simple de maintenir localement, dans un fichier (souvent nommé
hosts), le mappage entre les noms de domaine et les adresses qu’ils représentent.
DNS
Le protocole DNS (Domain Name System) a été créé afin de permettre la résolution de nom pour les grands réseaux
et en particulier Internet. Il utilise un ensemble distribué de serveurs qui permettent de convertir les noms en adresses
IP. Le protocole DNS utilise des datagrammes UDP (un serveur dns utilise le port 53).
C’est un service client/serveur dont la particularité est que le client DNS s’exécute lui aussi en tant que service.
Le client DNS, parfois nommé résolveur DNS, prend en charge la résolution de noms pour les autres applications
réseau.
Lors de la configuration d’un périphérique réseau, au minimum une adresse de serveur DNS est requise. Le
client DNS l’utilise pour la résolution de noms. Le fournisseur de services Internet fournit généralement les adresses
de serveurs à utiliser.
Principe :
Lorsque l’application (par exemple un navigateur) d’un utilisateur demande à se connecter à un hôte distant à l’aide
d’un nom, le client DNS vérifie si l’entrée existe localement dans un cache (en mémoire) puis dans le fichier hosts.
S’il ne trouve pas localement la correspondance nom/adresse IP, il interroge le serveur de noms (dont il connaît
l’adresse IP par configuration).
Lorsqu’un client effectue une demande, le serveur examine d’abord ses propres enregistrements (dans une table)
pour voir s’il peut résoudre le nom. S’il le peut, il répond, sinon il contacte d’autres serveurs. Lorsqu’une
correspondance est trouvée et retournée au serveur demandeur d’origine, ce dernier stocke temporairement dans sa
table (cache) l’adresse IP correspondant au nom.
Remarques :
•
•
La commande ipconfig /displaydns affiche toutes les entrées DNS mises en cache sur un système
Windows.
Le système d’exploitation des ordinateurs comprend également un utilitaire nommé nslookup ou host qui
permet d’envoyer une requête manuellement à un serveur de nom. Il dispose de nombreuses options
permettant de tester et de vérifier le processus DNS de manière approfondie.
Pour des informations complémentaires, consultez : http://www.ietf.org/rfc/rfc1034.txt et
http://www.ietf.org/rfc/rfc1035.txt.
8.5 – Le service DHCP (Dynamic Host Configuration Protocol)
Il permet aux hôtes d’un réseau d’obtenir automatiquement d’un serveur DHCP les paramètres de configuration IP.
Cette configuration est qualifiée de dynamique par opposition à l’adressage manuel qualifié de statique.
Lorsqu’il est contacté, le serveur DHCP choisit une adresse IP dans une plage d’adresses nommée pool et en affecte
une au client pour une durée définie (un bail).
Divers types de périphériques peuvent servir de serveurs DHCP. Il suffit qu’ils exécutent un logiciel de serveur DHCP.
Dans la plupart des réseaux, il est exécuté sur un PC ou sur un routeur.
Le protocole DHCP utilise des datagrammes UDP (ports 67=serveur et 68=client).
35
Cours II
Présentation générale des réseaux
Principe :
•
•
•
•
•
Lorsqu’un hôte configuré pour le protocole DHCP est mis sous tension ou se connecte au réseau, le client
diffuse un paquet DHCP DISCOVER pour identifier les serveurs DHCP disponibles du réseau.
Le serveur DHCP répond avec un paquet DHCP OFFER, à savoir un message d’offre de bail qui indique une
adresse IP attribuée, un masque de sous-réseau, un serveur DNS, une passerelle par défaut, ainsi que la
durée du bail.
Si le réseau local comporte plusieurs serveurs DHCP, le client peut recevoir plusieurs paquets DHCP OFFER.
Il doit donc effectuer un choix et diffuser un paquet DHCP REQUEST qui identifie explicitement le serveur et
l’offre de bail qu’il accepte. Un client peut choisir de demander une adresse que le serveur lui a déjà attribuée
précédemment.
Si l’adresse IP demandée par le client est encore valide, le serveur retourne un message DHCP ACK
confirmant que le bail est effectué. Si l’offre n’est plus valide (à cause par exemple d’un délai d’attente
dépassé), le serveur répond par un message DHCP NAK (Negative Acknowledgement). Le processus de
sélection doit recommencer avec un nouveau message DHCP DISCOVER.
Une fois que le client obtient le bail, celui-ci doit être renouvelé avant son expiration via un autre message
DHCP REQUEST.
Remarques :
•
•
•
•
Le serveur DHCP s’assure que toutes les adresses IP sont uniques.
Les fournisseurs Internet utilisent en général un protocole DHCP pour attribuer une adresse IP, un masque de
sous-réseau, une adresse de passerelle par défaut et une adresse de serveur DNS à leurs clients.
Le protocole DHCP peut représenter un risque pour la sécurité car n’importe quel périphérique connecté au
réseau peut recevoir une adresse. Ce risque est un facteur important lors du choix entre un adressage
dynamique et un adressage manuel.
L’adressage dynamique et l’adressage statique ont chacun leur place dans la conception des réseaux. En
général, on utilise à la fois le protocole DHCP et l’adressage statique. Le protocole DHCP est utilisé pour les
hôtes à utilisation générale et les adresses fixes pour les périphériques dont l’adresse doit être connue
comme les routeurs (passerelles), les serveurs et les imprimantes.
36