Piles De Protocoles

PILES DE PROTOCOLES

COUCHES PROTOCOLES Application Gopher, Telnet, SSH, FTP, HTTP, HTTPS, NNTP, DNS, SNMP, SMTP, POP3, IMAP, IRC, VoIP, WebDAV, SIMPLE, …

Présentation Videotex, Unicode, MIME, HTTP/HTML, XML, TDI, ASN.1, XDR, UUCP, NCP, AFP, SSP, SSL, TLS, …

Session RTSP, H.323, SIP, NFS, Netbios, CIFS, AppleTalk, … Transport TCP, UDP, SCTP, RTP, SPX, TCAP, DCCP, …

Réseau NetBEUI, IPv4, IPv6, ARP, IPX, BGP, ICMP, OSPF, RIP, IGMP, IS-IS, CLNP, WDS, … Liaison Ethernet, Anneau à jeton, LocalTalk, FDDI, X.21, X.25, Frame Relay, BitNet, CAN, ATM, Wi-Fi, …

Physique CSMA/CD, CSMA/CA, Codage NRZ, Codage Manchester, Codage Miller, RS-232, RS- 449, V.21-V.23, V.42-V.90, Câble coaxial, 10Base2, 10BASE5, Paire torsadée, 10BASE- T, 100BASE-TX, ISDN, PDH, SDH, T-carrier, EIA-422, EIA-485, SONET, ADSL, SDSL, VDSL, DSSS, FHSS, IrDA, USB, IEEE 1394, Wireless USB, …

Le modèle OSI (Open Systems Interconnection, « modèle de référence d'interconnexion de systèmes ouverts ») a été créé à la fin des années 1970 par l'ISO (Organisation internationale de normalisation) norme ISO 7498 dans le but d'offrir une base commune à la description du processus de fonctionnement de tout réseau informatique et pour que les matériels et applications provenant de différents constructeurs et éditeurs puissent être compatibles entre eux.

Dans ce modèle, l'ensemble des protocoles d'un réseau est décomposé en 7 parties appelées couches OSI, numérotées de 1 à 7. Les couches OSI respectent les principes suivants :

. Chaque couche décrit un protocole indépendamment des autres couches ; . Chaque couche procure des services à la couche immédiatement supérieure ; . Chaque couche requiert les services de la couche immédiatement inférieure ; . La couche 1 utilise le médium (le support de communication) ; . La couche 7 procure des services à l'utilisateur ou à un programme informatique.

Lors d'une communication, l'utilisateur d'un réseau utilise les services de la couche 5 (IRC par exemple) via un programme. Cette couche met en forme et enrichit l'information qu'elle reçoit du programme en respectant son protocole, puis elle l'envoie à la couche inférieure lors d'une demande de service. À chaque couche, l'information subit des mises en formes et des ajouts en fonction des protocoles utilisés. Enfin, elle est envoyée sur le médium et reçue par un autre nœud du réseau. Elle parcourt toutes les couches de ce nœud dans l'autre sens pour finir dans le programme IRC du correspondant, dépouillée des différents ajouts liés aux protocoles.

Les 7 couches du modèle OSI se décomposent en deux groupes : . applicatif : les 3 couches supérieures définissent la façon dont les applications vont communiquer entre elles et avec les utilisateurs finaux.

. transport : les 4 couches inférieures définissent la façon dont les données sont transmises d'un point à un autre.

Le modèle à 7 couches proposé par l'OSI a fait l'objet d'implémentations chez divers constructeurs, mais sans succès commercial, le marché s'étant largement orienté vers le modèle à 4 couches de TCP/IP, plus facile à comprendre et pour lequel existaient déjà des implémentations portables. Le modèle garde toutefois un intérêt théorique, bien que les frontières des 4 couches TCP/IP ne correspondent pas à d'exacts équivalents en OSI. Analyse d'un échec

On peut parler dans le cas de l'OSI d'un échec historique, le modèle n'étant aujourd'hui que partiellement utilisé, en comparaison du modèle TCP/IP.

Des éléments d'analyse ont été proposés. Le modèle s'est développé à partir des couches basses, vers le haut. Il a été complété de façon apparemment satisfaisante jusqu'à la couche 4 comprise, dont la complexité était déjà importante. Les couches supérieures, session, présentation et surtout application, n'ont en fait jamais été complétées. La couche application n'était en fait pas une vraie couche, composée d'éléments de service s'utilisant les uns les autres suivant les besoins des configurations.

Deux domaines d'applications ont révélé certaines des inadaptations du modèle : la sécurité et la gestion. Ni l'une ni l'autre ne pouvaient se limiter aux couches existantes. De plus, le modèle rendait mal compte de pratiques telles que le tunneling, dans laquelle l'ordre des couches était remis en question.

Cet échec rejaillit sur le modèle ancestral de la décomposition ordonnée (par couches), qui touche là à ses limites en termes de gestion de la complexité. COUCHE TRANSPORT Transmission Control Protocol

TCP, acronyme de Transmission Control Protocol, est un protocole de transport fiable, en mode connecté, documenté dans la RFC 793 de l'IETF.

Dans le modèle TCP/IP, TCP est situé entre la couche de réseau (généralement le protocole IP), et la couche application. Les applications transmettent des flux d'octets sur le réseau. TCP découpe le flux d'octets en segments, dont la taille dépend de la MTU du réseau sous-jacent (couche liaison de données).

Sommaire

. 1 Fonctionnement . 1.1 Structure d'un segment TCP . 1.2 Établissement d'une connexion . 1.3 Transferts de données . 1.4 Terminaison d'une connexion . 2 Ports TCP . 3 Développement de TCP . 4 Alternatives à TCP . 5 Voir aussi . 5.1 Liens internes

. 5.2 Liens externes Fonctionnement

Une session TCP fonctionne en trois phases :

. l'établissement de la connexion ; . les transferts de données ; . la fin de la connexion.

L'établissement de la connexion se fait par une poignée de main en trois temps. La rupture de connexion, elle, utilise une poignée de main en quatre temps. Pendant la phase d'établissement de la connexion, des paramètres comme le numéro de séquence sont initialisés afin d'assurer la transmission fiable (sans perte et dans l'ordre) des données.

Structure d'un segment TCP

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Port Source Port destination Numéro de séquence Numéro d'acquittement Taille de l'en-tête réservé URG ACK PSH RST SYN FIN Fenêtre Checksum Pointeur de données urgentes Options Remplissage Données

Signification des champs :

. Port source : Numéro du port source . Port destination : Numéro du port destination . Numéro de séquence : Numéro de séquence du premier octet de ce segment . Numéro d'acquittement : Numéro de séquence du prochain octet attendu . Taille de l'en-tête : Longueur de l'en-tête en mots de 32 bits (les options font partie de l'en-tête) . Réservé : Réservé pour un usage futur . Drapeaux . URG : Signale la présence de données URGentes . ACK : Signale que le paquet est un accusé de réception (ACKnowledgement) . PSH : Données à envoyer tout de suite (PuSH) . RST : Rupture anormale de la connexion (ReSeT) . SYN : Demande de SYNchronisation ou établissement de connexion . FIN : Demande la fin de la connexion . Fenêtre : Taille de fenêtre demandée, c'est-à-dire le nombre d'octets que le récepteur souhaite recevoir sans accusé de réception . Checksum : Somme de contrôle (CRC, Cyclic Redundancy Check) calculé sur l'ensemble de l'en-tête TCP et des données, mais aussi sur un pseudo en-tête (extrait de l'en-tête IP) . Pointeur de données urgentes : Position relative des dernières données urgentes . Options : Facultatives . Remplissage : Zéros ajoutés pour aligner les champs suivants du paquet sur 32 bits, si nécessaire . Données : Séquences d'octets transmis par l'application (par exemple: +OK POP3 server ready, ...)

Établissement d'une connexion

Même s'il est possible, pour deux systèmes, d'établir une connexion entre eux simultanément, dans le cas général, un système ouvre un 'socket' (point d'accès à une connexion TCP) et se met en attente passive de demandes de connexion d'un autre système. Ce fonctionnement est communément appelé ouverture passive, et est utilisé par le côté serveur de la connexion. Le côté client de la connexion effectue une ouverture active en envoyant un segment SYN au serveur, ce qui constitue la première étape de la poignée de mains en trois temps. Le serveur doit répondre à un segment SYN valide par un segment SYN/ACK. Enfin, le client répond au serveur avec un segment ACK, complétant la poignée de main en trois temps, et donc la phase d'établissement de la connexion.

Transferts de données

Pendant la phase de transferts de données, certains mécanismes clefs permettent d'assurer la robustesse et la fiabilité de TCP. En particulier, les numéros de séquence sont utilisés afin d'ordonner les segments TCP reçus et de détecter les données perdues, les checksums permettent la détection d'erreurs, et les acquittements ainsi que les temporisations permettent la détection des segments perdus ou retardés.

Pendant la phase d'établissement de la connexion, les numéros de séquence initiaux sont échangés par les deux interlocuteurs. Ces numéros de séquence sont utilisés pour décompter les données dans le flux d'octets. On trouve toujours deux de ces nombres dans chaque segment TCP, qui sont le numéro de séquence et le numéro d'acquittement. Le numéro de séquence représente le propre numéro de séquence de l'émetteur TCP, tandis que le numéro d'acquittement représente le numéro de séquence du destinataire. Afin d'assurer la fiabilité de TCP, le destinataire doit acquitter les segments reçus en indiquant qu'il a reçu toutes les données du flux d'octets jusqu'à un certain numéro de séquence. Une amélioration de TCP, nommée acquittement sélectif (selective acknowlegement ou SACK), autorise le destinataire TCP à acquitter des blocs de données reçus dans le désordre.

Grâce aux numéros de séquence et d'acquittement, les systèmes terminaux peuvent remettre les données reçues dans l'ordre à l'application destinataire. Les numéros de séquence sont des nombres entiers non signés sur 32 bits, qui reviennent à zéro après avoir atteint 2^32-1. Le choix du numéro de séquence initial est une des clefs de la robustesse et de la sécurité des connexions TCP.

Une somme de contrôle sur 16 bits, constituée par le complément à un de la somme des compléments à un de tous les éléments d'un segment TCP (en-tête et données), est calculée par l'émetteur, et incluse dans le segment émis. Le destinataire recalcule la somme de contrôle du segment reçu, et si elle correspond à la somme de contrôle reçue, on considère que le segment a été reçu intact et sans erreur.

La somme de contrôle en complément à un utilisée par TCP est relativement peu fiable selon les standards modernes. Ceci restreint l'utilisation de TCP à des réseaux offrant des taux d'erreurs faibles. Si TCP était redéfini aujourd'hui, on utiliserait probablement un CRC sur 32 bits au lieu du mécanisme actuel. Ce manque de fiabilité de la somme de contrôle est partiellement compensé par l'utilisation fréquente d'un CRC ou d'un meilleur contrôle d'intégrité au niveau 2 (couche liaison de données), au-dessous de TCP et IP, comme par exemple dans les trames PPP ou Ethernet. Toutefois, cela ne signifie pas que la somme de contrôle TCP est redondante: des études sur le trafic Internet ont montré qu'on rencontre couramment des erreurs matérielles et logicielles qui introduisent des erreurs dans les paquets entre les nœuds protégés par des CRC, et que le principe de somme de contrôle de bout en bout de TCP détecte la plupart de ces erreurs.

Les acquittements des données émises, ou l'absence d'acquittements, sont utilisés par les émetteurs pour interpréter de façon implicite l'état du réseau entre les systèmes finaux. À l'aide de temporisations, les émetteurs et destinataires TCP peuvent modifier le comportement du flux de données. C'est ce qu'on appelle généralement le contrôle de flux.

TCP utilise un certain nombre de mécanismes afin d'obtenir une bonne robustesse et des performances élevées. Ces mécanismes comprennent l'utilisation d'une fenêtre glissante, l'algorithme de démarrage lent (slow start), l'algorithme d'évitement de congestion (congestion avoidance), les algorithmes de retransmission rapide (fast retransmit) et de récupération rapide (fast recovery), etc. Des recherches sont menées actuellement afin d'améliorer TCP pour traiter efficacement les pertes, minimiser les erreurs, gérer la congestion et être rapide dans des environnements très haut débit.

Terminaison d'une connexion

La phase de terminaison d'une connexion utilise une poignée de main en quatre temps, chaque extrémité de la connexion effectuant sa terminaison de manière indépendante. Ainsi, la fin d'une connexion nécessite une paire de segments FIN et ACK pour chaque extrémité. Ports TCP

TCP utilise la notion de numéro de port pour identifier les applications. À chaque extrémité de la connexion TCP est associé un numéro de port sur 16 bits assigné à l'application émettrice ou réceptrice. Les ports peuvent faire partie de trois catégories de base: les ports bien connus, les ports enregistrés et les ports dynamiques/privés. Les ports bien connus sont assignés par l'IANA (Internet Assigned Numbers Authority) et sont souvent utilisés par des processus système ou ayant des droits privilégiés. Les applications bien connues qui fonctionnent en tant que serveur et sont en attente de connexions utilisent généralement ces types de ports. Exemples: FTP (21), Telnet (23), SMTP (25) et HTTP (80). Les ports enregistrés sont généralement utilisés par des applications utilisateur comme ports sources éphémères pour se connecter à un serveur, mais ils peuvent aussi identifier des services non enregistrés par l'IANA. Les ports dynamiques/privés peuvent aussi être utilisés par des applications utilisateur, mais plus rarement. Ils n'ont pas de sens en dehors d'une connexion TCP particulière. Développement de TCP

TCP est un protocole assez complexe, et en évolution. Même si des améliorations significatives ont été apportées au cours des années, son fonctionnement de base a peu changé depuis le RFC 793, publié en 1981. Le RFC 1122 (Host Requirements for Internet Hosts), a clarifié un certain nombre de pré-requis pour l'implémentation du protocole TCP. Le RFC 2581 (TCP Congestion Control), l'un des plus importants de ces dernières années, décrit de nouveaux algorithmes utilisés par TCP pour éviter les congestions. En 2001, le RFC 3168 a été écrit afin de présenter un mécanisme de signalisation des congestions (explicit congestion notification ou ECN), et s'ajoute à la liste des RFCs importants qui complètent la spécification originale. Au début du XXIe siècle, TCP est utilisé approximativement pour 95% de tout le trafic Internet. Les applications les plus courantes qui utilisent TCP sont HTTP/HTTPS (world wide web), SMTP/POP3/IMAP (messagerie) et FTP (transfert de fichiers). Son utilisation très répandue est la preuve de la qualité de la conception réalisée par ses créateurs originaux.. Alternatives à TCP

Toutefois, TCP n'est pas approprié pour de nombreuses applications, et de nouveaux protocoles de transport sont créés et déployés afin de combler certaines de ses lacunes. Par exemple, de nombreuses applications temps-réel n'ont pas besoin, et peuvent même souffrir, des mécanismes de transport fiable de TCP. Dans ce type d'applications, il est souvent préférable de gérer les pertes, erreurs ou congestions, plutôt que d'essayer de les éviter. Les applications de diffusion multimédia (audio et vidéo, etc), ou certains jeux multi-joueurs en temps-réel, par exemple, n'utilisent pas TCP. Toute application qui ne nécessite pas la fiabilité de TCP, ou a un besoin limité en fonctionnalité, peut choisir de ne pas l'utiliser. Dans de nombreux cas, UDP (User datagram protocol) peut être utilisé à la place de TCP lorsque seuls les services de multiplexage applicatifs sont requis.

User Datagram Protocol

Un article de Wikipédia, l'encyclopédie libre.

UDP, abréviation de User Datagram Protocol, est un des principaux protocoles de télécommunication utilisé par Internet. Il fait partie de la couche transport de la pile de protocole TCP/IP: dans l'adaptation approximative de cette dernière au modèle OSI, il appartiendrait la couche 4, comme TCP. Il est détaillé dans la RFC 1662.

Le rôle de ce protocole est de permettre la transmission de paquets (aussi appelés datagrammes) de manière très simple entre deux entités, chacune étant définie par une adresse IP et un numéro de port (pour différentier différents utilisateurs sur la même machine). Contrairement au protocole TCP, il travaille en mode non-connecté: il n'y a pas de moyen de vérifier si tous les paquets envoyés sont bien arrivés à destination et ni dans quel ordre. C'est pour cela qu'il est souvent décrit comme étant un protocole non-fiable. Par contre, pour un datagramme UDP donné, l'exactitude du contenu des données est assuré grâce à une somme de contrôle (Checksum). Structure d'un datagramme UDP

Le paquet UDP est encapsulé dans un paquet IP. Il comporte un en-tête suivi des données proprement dites à transporter.

En-tête IP En-tête UDP Données

L'en-tête (header en anglais) d'un datagramme UDP est bien plus simple que celui de TCP :

Port Source (16 bits) Port Destination (16 bits) Longueur (16 bits) Somme de contrôle (16 bits) Données (longueur variable)

Il contient les 4 champs suivants:

Port Source il indique depuis quel port le paquet a été envoyé. Port de Destination il indique à quel port le paquet doit être envoyé Longueur il indique la longueur totale du datagramme UDP (en-tête et données). La longueur minimal est donc de 8 octets (taille de l'en-tête) Somme de contrôle celle-ci (CRC, Cyclic Redundancy Check) permet de s'assurer de l'intégrité du paquet reçu. Elle est calculée sur l'ensemble de l'en-tête UDP et des données, mais aussi sur un pseudo en-tête (extrait de l'en-tête IP) Note: la présence de ce pseudo en-tête, interaction entre les deux couches IP et UDP, est une des raisons qui font que le modèle TCP/IP ne s'applique pas parfaitement au modèle OSI. Utilisation

Il est utilisé quand il est nécessaire soit de transmettre des données très rapidement, et où la perte d'une partie de ces données n'a pas grande importance, soit de transmettre des petites quantités de données, là où la connexion « 3- WAY » TCP serait trop lourde. Par exemple, dans le cas de la transmission de la voix sur IP, ce n'est pas grave si l'un ou l'autre paquet se perd (il existe des mécanismes de substitution des données manquante), par contre la rapidité de transmission est un critère primordial pour la qualité d'écoute.

Exemples d'utilisation :

. le programme traceroute, . les protocoles DNS, TFTP, . les jeux en réseau (exemple : jeux de tir subjectifs) . le streaming: il est indispensable pour des applications multimédias de par sa faible latence.

Sequenced Packet eXchange (SPX) est un protocole de communication qui est utilisé conjointement avec IPX dans les réseaux locaux NetWare de Novell.

Récupérée de « http://fr.wikipedia.org/wiki/Sequenced_packet_exchange »

Le Datagram Congestion Control Protocol (DCCP) est un protocole de communication de couche de transport orienté message. Il est en cours de développement à l'IETF et n'a donc pas de RFC définies pour le moment. TCAP (Transaction Capabilities Application Part) est un protocole binaire du réseau SS7 encapsulé par le protocole SCCP.

Il permet la transmission d'informations applicatives non-orientées appel entre différents Point Code du réseau de signalisation, notamment pour les réseaux intelligents (IN). TCAP propose un service de communication connecté (ou non pour les messages TC_UNI) pour les protocoles de niveau superieur. Cela implique une gestion de la connexion et des états de transaction (permanence du dialogue). Dans un réseau IN, TCAP encapsule principalement des requêtes MAP, INAP ou OMAP destinées à la localisation, la mobilité, le pré-paiement et les SMS.

Le protocole TCAP se divise en deux couches distinctes encapsulées l'une dans l'autre:

 La partie transactionnelle qui gère les états du dialogue et de la connexion entre les deux point code communicants.  La partie composants, encapsulée par la partie transactionnelle, qui gère le type d'information échangée.

[modifier]

Standards

 Normes ITU (1988 - blue book - et 1992 - white book -)  Normes ANSI (1990 - 1996 - 2000) Stream Control Transmission Protocol

Aller à : navigation, Rechercher

SCTP, ou Stream Control Transmission Protocol est un protocole défini en 2000 par l'IETF. Le protocole est défini dans la RFC 2960, et un texte d'introduction est fourni dans la RFC 3286.

En tant que protocole de transport, SCTP est équivalent dans un certain sens au TCP ou à l'UDP. En effet, il fournit des services similaires à TCP, assurant la fiabilité, la remise en ordre des séquences, et le contrôle de congestion. Alors que TCP est byte-oriented (orienté octets), SCTP gère des « frames » (courtes séquences).

Une avancée majeure de SCTP est la possibilité de communications multi-cibles, où une des extrémités (ou les) de la connexion est constituée de plusieurs adresses IP.

À l'origine, SCTP était destiné au transport de protocoles téléphoniques sur le réseau IP (VoIP).

[modifier]

Liens Externes

 RFC 2960 Stream Control Transmission Protocol  RFC 3286 An Introduction to the Stream Control Transmission Protocol  RFC 3257 Stream Control Transmission Protocol Applicability Statement  RFC 3309 Stream Control Transmission Protocol (SCTP) Checksum Change

 http://www.sigtran.org  http://www.sctp.org  http://www.openss7.org  http://www.sctp.de  The Linux Kernel Stream Control Transmission Protocol (lksctp) project

APPLICATION

POP3, ou Post Office Protocol Version 3 (littéralement le protocole du bureau de poste, version 3), est un protocole qui permet de récupérer les courriers électroniques situés sur un serveur.

Cette opération nécessite une connexion à un réseau TCP/IP. Le port utilisé est le 110. Ce protocole a été défini dans la RFC 1939.

POP3S (POP3 over SSL) utilise SSL pour sécuriser la communication avec le serveur, tel que décrit dans la RFC 2595. POP3S utilise le port 995. Sommaire

[masquer]

 1 Commandes o 1.1 Commandes principales o 1.2 Autres commandes POP3  2 Voir aussi

 3 Liens externes [modifier] Commandes

Pour récupérer les courriels, on peut :

 soit utiliser un logiciel, souvent appelé client mail, qui le fait automatiquement et qui nous cache les commandes, tel que Mozilla Thunderbird,  soit directement utiliser les commandes POP3 de manière interactive.

Tout d'abord, il faut se connecter au serveur :

 telnet nom_du_serveur 110  Exemple : telnet mail.altern.org 110

Ensuite, il faut s'identifier et s'authentifier :

 USER nom_de_votre_compte (ce qui se trouve avant le « @ » de l'adresse électronique)  PASS mot_de_passe (le mot de passe pour accéder à la boîte de courrier)

Puis, vous pouvez utiliser l'une des commandes POP3 suivantes

[modifier]

Commandes principales

 DELE numéro_du_message : efface le message spécifié  LIST : donne une liste des messages ainsi que la taille de chaque message : un numéro suivi de la taille en octets.  RETR numéro_du_message : récupère le message indiqué  STAT : indique le nombre de messages et la taille occupée par l'ensemble des messages  TOP numéro_du_message nombre_de_lignes : affiche les premières lignes du message.

[modifier]

Autres commandes POP3

 APOP : permet une authentification sécurisée (le mot de passe ne transite pas en clair)  NOOP : ne rien faire, juste pour garder la porteuse  QUIT : quitter la session en cours  RSET : réinitialise complètement la session  UIDL : affiche (pour un seul ou pour tous les messages) un identifiant unique qui ne varie pas entre chaque session

[modifier] Voir aussi

 Internet  Courrier électronique  Client email  IMAP  SMTP  SSL

[modifier] Liens externes

 RFC 1939 (en) - spécifications du protocole POP version 3  RFC 2595 (en) - utilisation de TLS (SSL) avec les protocoles POP3 et IMAP4

Le Simple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier »), généralement abrégé SMTP, est un protocole de communication utilisé pour transférer le courrier électronique vers les boîtes de messagerie d'Internet.

SMTP est un protocole assez simple (comme son nom l'indique). On commence par spécifier le ou les destinataires d'un message puis, l'expéditeur du message, puis, en général après avoir vérifié leur existence, le corps du message est transféré. Il est assez facile de tester un serveur SMTP en utilisant telnet sur le port 25.

Le SMTP a commencé à être largement utilisé au début des années 1980. Il était alors un complément à l'UUCP, celui-ci étant plus adapté pour le transfert d'e-mails entre des machines dont l'interconnexion est intermittente. Le SMTP, de son côté, fonctionne mieux lorsque les machines qui envoient et reçoivent les messages sont interconnectées en permanence.

Le logiciel Sendmail fut l'un des premiers, sinon le premier, Mail Transfer Agent (MTA), logiciel de transfert de courrier, à utiliser SMTP. Depuis, la plupart des logiciels de courriel clients peuvent utiliser SMTP pour envoyer les messages. Certains nouveaux serveurs sont apparus, comme Postfix, Qmail de Daniel J. Bernstein, Exim et Exchange de Microsoft (qui accomplit également d'autres fonctions).

Comme le protocole utilisait du texte en ASCII (7 bits), il ne fonctionnait pas pour l'envoi de n'importe quels octets dans des fichiers binaires. Pour pallier ce problème, des standards comme MIME ont été développés pour permettre le codage des fichiers binaires au travers de SMTP. Aujourd'hui, la plupart des serveurs SMTP acceptent le MIME sur 8 bits, ce qui permet de transférer des fichiers binaires presque aussi facilement que du texte simple.

SMTP ne permet pas de récupérer à distance des courriels arrivés dans une boîte aux lettres sur un serveur. Les standards POP et IMAP ont été créés dans ce but.

Une des limitations de SMTP était qu'il n'y avait pas de moyen d'identifier l'expéditeur. Pour ceci, l'extension SMTP-AUTH a été définie.

[modifier] Voir aussi

[modifier] Liens internes

courrier électronique ~ exim ~ postfix ~ qmail ~ sendmail ~ POP ~ IMAP

[modifier]

Liens externes

 RFC 821 - Le RFC « historique » sur SMTP (août 1982)  RFC 1869 - Définit la possibilité de créer des extensions (Extended SMTP, ou ESMTP) ;  RFC 3461 - Le Service Extension Delivery Status Notifications (DSNs) de SMTP qui a rendu obsolète le RFC 1891.  RFC 2821 - The Simple Mail Transfer Protocol qui a rendu obsolète les RFCs 821 et 1869;  Présentation de SMTP sur un site de vulgarisation  Liste des RFCs

Récupérée de « http://fr.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol »

Internet Relay Chat

IRC, acronyme de Internet Relay Chat (en français, discussion relayée par internet), est un protocole de communication sur Internet. Il sert à la communication instantanée, antécédent de la messagerie instantanée. Sommaire

[masquer]

 1 Aspects techniques  2 Voir aussi o 2.1 Liens internes

o 2.2 Liens externes [modifier] Aspects techniques

Conçu fin août 1988, il a été décrit initialement dans la RFC 1459 par Jarkko Oikarinen (surnommé "WiZ") et D. Reed, puis révisé dans les RFC 2810 à 2813. IRC fut créé pour remplacer un programme appellé MUT (MultiUser talk) sur un BBS finlandais (OuluBox). Oikarinen s'est inspiré du Bitnet Relay Chat du réseau Bitnet.

Le protocole de communication décrit un réseau informatique formé de plusieurs serveurs connectés dans lequel les clients communiquent généralement par le biais du serveur (qui relayera éventuellement le message au reste du réseau). Il est également possible de connecter deux clients directement pour une conversation privée ou un transfert de fichier, on parle alors de DCC (Direct Client-to-Client). Ce protocole étant public, des clients existent pour de nombreux systèmes d'exploitations, de même que les serveurs IRC, aussi désignés par le terme IRCD qui signifie Internet Relay Chat Daemon.

Il existe différents réseaux, dont les plus connus sont IRCnet, EFnet, DalNET, Undernet, Freenode. Ils sont le plus souvent libres d'utilisation et gratuits. QuakeNet est le plus grand réseau avec 200.000 clients.

Avec l'arrivée des gros fournisseurs de contenu un peu avant 2000, le succès d'IRC a été quelque peu diminué par l'arrivée des messageries instantanées. Ces réseaux restent néanmoins très utilisés par ceux qui veulent discuter sans passer par un programme client propriétaire ou n'offrant pas l'interactivité sous forme de canaux, permettant ainsi de rejoindre des milliers d'usagers. L'anglicisme chat est souvent utilisé pour décrire les discussions se déroulant sur l'IRC. En français, certains utilisent bavardage, tchatche ou clavardage (principalement au Quebec).

Un IRC est normalement géré par un IrcOp, contraction d'origine anglophone de IRC Operator ou opérateur d'IRC.

Le sigle SNMP signifie Simple Network Management Protocol (protocole simple de gestion de réseau en Français). Il s'agit d'un protocole de communication qui permet aux administrateurs réseau de gérer les équipements du réseau et de diagnostiquer les problèmes de réseau. Sommaire

[masquer]

 1 Principe de fonctionnement du protocole SNMP  2 SNMP en pratique  3 Autres utilisations  4 Voir aussi

o 4.1 Liens externes [modifier] Principe de fonctionnement du protocole SNMP

Le système de gestion de réseau est basé sur trois éléments principaux: un superviseur, des nœuds (ou nodes) et des agents. Dans la terminologie SNMP, le synonyme manager est plus souvent employé que superviseur. Le superviseur est la console qui permet à l'administrateur réseau d'exécuter des requêtes de management. Les agents sont des entités qui se trouvent au niveau de chaque interface, connectant l'équipement managé (nœud) au réseau et permettant de récupérer des informations sur différents objets.

Switchs, hubs, routeurs et serveurs sont des exemples d'équipements contenant des objets manageables. Ces objets manageables peuvent être des informations matérielles, des paramètres de configuration, des statistiques de performance et autres objets qui sont directement liés au comportement en cours de l'équipement en question. Ces objets sont classés dans une sorte de base de donnée appelée MIB (« Management Information Base »). SNMP permet le dialogue entre le superviseur et les agents afin de recueillir les objets souhaités dans la MIB.

L'architecture de gestion du réseau proposée par le protocole SNMP est donc fondé sur trois principaux éléments :

 Les équipements managés (managed devices) sont des éléments du réseau (ponts, hubs, routeurs ou serveurs), contenant des « objets de gestion » (managed objects) pouvant être des informations sur le matériel, des éléments de configuration ou des informations statistiques ;  Les agents, c'est-à-dire une application de gestion de réseau résidant dans un périphérique et chargé de transmettre les données locales de gestion du périphérique au format SNMP ;  Les systèmes de management de réseau (network management systems notés NMS), c'est-à-dire une console à travers laquelle les administrateurs peuvent réaliser des tâches d'administration.

[modifier] SNMP en pratique

Concrètement, dans le cadre d'un réseau, SNMP est utilisé:

 pour administrer les équipements  pour surveiller le comportement des équipements.

Une requête SNMP est un paquet UDP usuellement à destination du port 161. Les schémas de sécurité dépendent des versions de SNMP (v1,v2 ou v3). Dans la version 1 et 2, une requête SNMP contient un nom appelé communauté, utilisé comme un mot de passe. Il y a un nom de communauté différent pour obtenir les droits en lecture et pour obtenir les droits en écriture. Dans bien des cas, les colossales lacunes de sécurité que comportent les versions 1 et 2 de SNMP limitent l'utilisation de SNMP à la lecture des informations. Un grand nombre de logiciels libres et payants utilisent SNMP pour interroger régulièrement les équipements et produire des graphes rendant compte de l'évolution des réseaux ou des systèmes informatiques (MRTG, cacti, Nagios,...).

Le protocole SNMP définit aussi un concept de trap. Une fois défini, si un certain évènement se produit, comme par exemple le dépassement d'un seuil, l'agent envoie un paquet UDP à un serveur. Ce processus d'alerte est utilisé dans les cas où il est possible de définir simplement un seuil d'alerte. Dans nombre de cas, hélas, une alerte réseau ne devrait être déclenchée qu'en corrélant plusieurs événements.

[modifier] Autres utilisations

Le protocole SNMP peut aussi être utilisé dans le domaine industriel. Dans ce cas, SNMP sert à transporter des informations ne concernant pas le réseau informatique. SNMP transporte alors des informations applicatives industrielles.

Dans ce cas, SNMP ressemble à une sorte de base de données arborescente.

Domain Name System (DNS) est un système permettant d'établir une correspondance entre une adresse IP et un nom de domaine et, plus généralement, de trouver une information à partir d'un nom de domaine. Sommaire

[masquer]

 1 Associer une adresse IP et un nom de domaine  2 Un système réparti o 2.1 Principaux enregistrements DNS . 2.1.1 MX record . 2.1.2 NAPTR record o 2.2 Sécurité du DNS . 2.2.1 DNSSEC o 2.3 Voir aussi

o 2.4 Liens externes [modifier] Associer une adresse IP et un nom de domaine

Les ordinateurs connectés à un réseau IP, par exemple Internet, possèdent tous une adresse IP. Ces adresses sont numériques afin d'être plus facilement traitées par une machine . Selon IPv4, elles prennent la forme xxx.yyy.zzz.aaa, où xxx, yyy, zzz et aaa sont quatre nombres variant entre 0 et 255 (en système décimal).

Il n'est évidemment pas simple pour un humain de retenir ce numéro lorsque l'on désire accéder à un ordinateur d'Internet. C'est pourquoi le Domain Name System (ou DNS, système de noms de domaine) fut inventé en 1983 par Paul Mockapetris. Il permet d'associer à une adresse IP, un nom intelligible, humainement plus simple à retenir, appelé nom de domaine. fr.wikipedia.org, par exemple, est composé du domaine générique org, du domaine déposé wikipedia et du nom d'hôte fr.

Quand un utilisateur souhaite accéder à un site, comme par exemple www.free.fr, son ordinateur émet une requête spéciale à un serveur DNS, demandant 'Quelle est l'adresse de www.free.fr ?'. Le serveur répond en retournant l'adresse IP du serveur, qui est dans ce cas-ci, 213.228.0.42.

Il est également possible de poser la question inverse, à savoir 'Quel est le nom de domaine de telle adresse IP ?'. On parle alors de résolution inverse.

Plusieurs noms de domaine peuvent pointer vers une même adresse IP. Mais une adresse IP ne peut pointer que sur un unique nom de domaine.

Lorsqu'un service génère un trafic important, celui-ci peut faire appel à la technique du DNS Round-Robin, qui consiste à associer plusieurs adresses IP à un nom de domaine. Les différentes versions de Wikipedia, comme fr.wikipedia.org par exemple, sont associées à plusieurs adresses IP : 207.142.131.247, 207.142.131.248, 207.142.131.235, 207.142.131.236, 207.142.131.245 et 207.142.131.246. Une rotation circulaire entre ces différentes adresses permet ainsi de répartir la charge générée par ce trafic important, entre les différentes machines, ayant ces adresses IP. [modifier] Un système réparti

Il existe en fait des centaines de milliers de serveurs DNS dans le monde entier. Chaque serveur DNS n'a en réalité à sa disposition qu'un ensemble d'informations restreint.

Quand notre serveur DNS (par exemple, celui de notre fournisseur d'accès à Internet) doit trouver l'adresse IP de fr.wikipedia.org, une certaine communication s'instaure alors avec d'autres serveurs DNS. Tout d'abord, notre serveur demande à des serveurs DNS peu nombreux appelés root-servers quels serveurs peuvent lui répondre pour la zone org. Parmi ceux-ci, notre serveur va en choisir un pour savoir quel serveur est capable de lui répondre pour la zone wikipedia.org. C'est ce dernier qui pourra lui donner l'adresse IP de fr.wikipedia.org.

Cependant, ce processus de résolution de nom est long. C'est pourquoi, la plupart des serveurs DNS (et notamment ceux des Fournisseurs d'accès à Internet) font aussi office de DNS cache : ils gardent en mémoire la réponse d'une résolution de nom afin de ne pas effectuer ce long processus à nouveau ultérieurement.

Un nom de domaine peut utiliser plusieurs serveurs DNS. Généralement, les noms de domaines en utilisent deux : un primaire et un secondaire. Seuls ces derniers peuvent fournir une réponse valable à tout instant. On parle de réponse faisant autorité (authoritative answer en anglais). Les serveurs des Fournisseurs d'accès à Internet quant à eux fournissent des réponses qui ne sont pas nécessairement à jour, à cause du cache mis en place. On parle alors de réponse ne faisant pas autorité (non authoritative answer en anglais).

Pour trouver le nom de domaine d'une IP, on utilise le même principe. Dans un nom de domaine, la partie la plus générale est à droite: org dans fr.wikipedia.org. Dans une adresse ip, c'est le contraire: 213 est la partie la plus générale de 213.228.0.42. Pour conserver une logique cohérente, on inverse l'ordre des quatre termes de l'adresse et on la concatène au pseudo domaine in-addr.arpa.. Ainsi, par exemple, pour trouver le nom de domaine de l'adresse IP 213.228.0.42, on résout 42.0.228.213.in-addr.arpa, qui est un pointeur vers www1.free.fr.

Cette architecture garantit au réseau Internet une certaine sécurité. Quand un serveur DNS tombe, le bon fonctionnement de la résolution de nom n'est pas remise en cause. De plus, elle permet de mettre à jour l'adresse IP associée à un nom de domaine dans le monde entier facilement et assez rapidement (un délai de 48 heures est généralement suffisant).

[modifier] Principaux enregistrements DNS

Les principaux enregistrements définis par un DNS sont :

 A record ou address record qui fait correspondre un nom d'hôte à une adresse IPv4 de 32 bits.  AAAA record ou IPv6 address record qui fait correspondre un nom d'hôte à une adresse IPv6 de 128 bits.  CNAME record ou canonical name record qui permet de faire d'un domaine un alias vers un autre. Cet alias hérite de tous les sous-domaines de l'original.  MX record ou mail exchange record qui définit les serveurs de mail pour ce domaine.  PTR record ou pointer record qui définit un nom domaine pour une adresse IP.  NS record ou name server record qui définit les serveurs DNS de ce domaine.  SOA record ou start of authority record qui définit le serveur DNS fournissant l'information faisant autorité sur un domaine Internet.  SRV record qui généralise la notion de MX record, standardisé dans la RFC 2782.  NAPTR record qui donne accès à des règles de réécriture de l'information, permettant des correspondances assez lâches entre un nom de domaine et une ressource. Il est spécifié dans la RFC 3403.  TXT record permet à un administrateur d'insérer un texte quelconque dans un enregistrement DNS. Par exemple, cet enregistrement était utilisé pour implémenter la spécification Sender Policy Framework.

D'autres types d'enregistrements servent simplement à donner des informations (par exemple, un LOC record - rarissime - indique l'emplacement physique d'un hôte).

[modifier]

MX record

Une entrée DNS MX indique les serveurs SMTP à contacter pour envoyer un e-mail à un utilisateur d'un domaine donné. Sous Unix on peut récupérer les entrées MX correspondant à un domaine à l'aide du programme host(1) (entre autres). Par exemple:

$ host -v -t MX wikimedia.org [...] ;; QUESTION SECTION: ;wikimedia.org. IN MX

;; ANSWER SECTION: wikimedia.org. 3600 IN MX 50 mormo.org. wikimedia.org. 3600 IN MX 10 mail.wikimedia.org.

On voit que les e-mails envoyé à une adresse en @wikimedia.org sont en fait envoyés au serveur mormo.org ou mail.wikimedia.org. Le nombre précédent le serveur représente la priorité. Normalement on est censé utiliser le serveur avec la priorité numérique la plus petite.

Les entrées MX sont rendues obsolètes par les entrées SRV qui permettent de faire la même chose mais pour tous les services, pas juste SMTP (l'e-mail). L'avantage des entrées SRV par rapport aux entrées MX est aussi qu'elles permettent de choisir un port arbitraire pour chaque service ainsi que de faire de la répartition de charge plus efficacement. L'inconvénient c'est qu'il existe encore peu de programmes clients qui gèrent les entrées SRV.

[modifier]

NAPTR record

Peu répandus à l'heure actuelle (ils sont surtout utilisés par ENUM). Ils décrivent une réécriture d'une clé (un nom de domaine) en URI. Par exemple, dans ENUM, des enregistrements NAPTR peuvent être utilisés pour trouver l'adresse de courrier électronique d'une personne, connaissant son numéro de téléphone (qui sert de clé à ENUM).

[modifier] Sécurité du DNS

Comme beaucoup de protocoles Internet, le DNS a été conçu sans se préoccuper de la sécurité. Il ne faut donc pas se fier au DNS pour arriver sur le bon serveur et c'est pour cela que des protocoles comme SSH font leur propre vérification (via la cryptographie). Les principales failles du DNS (décrites dans le RFC 3833) sont :

 Interception du paquet (requête ou réponse) et émission d'un autre paquet à sa place,  Fabrication d'une réponse (les serveurs DNS acceptent trop facilement des réponses puisque seul un numéro de requête, très petit, sert d'authentification),  Trahison par un serveur (le secondaire hors-site d'un domaine peut par exemple passer sous le contrôle de personnes malintentionnées),  et le traditionnel déni de service.

[modifier]

DNSSEC

Gopher

Gopher, du nom de l'écureuil américain aussi appelé « spermophile », est un protocole de l'Internet. Mis au point par l'université du Minnesota pour la consultation d'informations organisées sous la forme d'une arborescence de menus hiérarchiques, il fonctionnait en mode caractère. Il a disparu parce que le protocole qu'il utilisait était la « propriété » de l'université du Minnesota, qui a menacé au printemps 1993 de réclamer des royalties. Son abandon a favorisé le développement de HTTP, le protocole à la base du Web qui, lui, est libre.

Récupérée de « http://fr.wikipedia.org/wiki/Gopher »

Telnet Un article de Wikipédia, l'encyclopédie libre.

Telnet est un protocole réseau utilisé sur tout réseau supportant le protocole TCP/IP. Il appartient à la couche session du modèle OSI et à la couche application du modèle ARPA. Il est normalisé par l'IETF (RFC 854 et RFC 855). Selon, l'IETF, le but du protocole Telnet est de fournir un moyen de communication très généraliste, bi- directionnel et orienté octet.

telnet est aussi une commande permettant de créer une session Telnet sur une machine distante. Cette commande était disponible d'abord sur les sytèmes Unix puis elle apparu sur la plupart des systèmes d'exploitation. Sommaire

[masquer]

 1 Détails du protocole  2 Utilisation  3 Défaut de sécurité  4 Voir aussi

 5 Liens externes [modifier] Détails du protocole

Telnet est un protocole de type client-serveur basé sur TCP. Les clients se connectent généralement sur le port 23 du serveur.

[modifier] Utilisation

Une des utilisations majeures de la commande telnet était de se connecter à des serveurs telnet, qui demandaient un identifiant, puis un mot de passe, et donnaient une ligne de commmande sur la machine distante en échange. Pour cela elle nécessitait le lancement d'un démon sur la machine hôte, souvent appelé telnetd.

La commande telnet reste malgré tout une commande très pratique pour tester des serveurs. Vu la flexibilité du programme, il est possible d'utiliser la commande telnet pour établir une connexion TCP interactive avec d'autres services tel que SMTP ou HTTP.

[modifier] Défaut de sécurité

Le côté basique de telnet fait que toute communication est transmise en clair sur le réseau, mots de passe compris. Des sniffer comme tcpdump ou ethereal permettent d'intercepter les communications de la commande telnet.

Il est préférable d'utiliser des protocoles cryptés (comme SSH) pour obtenir des accès en ligne de commande sur des machines distantes, à la place de Telnet

Internet Message Access Protocol

Aller à : navigation, Rechercher Pile de protocoles

Couche Protocoles

Gopher, Telnet, SSH, FTP, HTTP, HTTPS, NNTP, DNS, Application SNMP, SMTP, POP3, IMAP, IRC, VoIP, WebDAV, SIMPLE, …

Videotex, Unicode, MIME, HTTP/HTML, XML, TDI, Présentation ASN.1, XDR, UUCP, NCP, AFP, SSP, SSL, TLS, …

RTSP, H.323, SIP, NFS, Session Netbios, CIFS, AppleTalk, …

TCP, UDP, SCTP, RTP, SPX, Transport TCAP, DCCP, …

NetBEUI, IPv4, IPv6, ARP, Réseau IPX, BGP, ICMP, OSPF, RIP, IGMP, IS-IS, CLNP, WDS, …

Ethernet, Anneau à jeton, LocalTalk, FDDI, X.21, X.25, Liaison Frame Relay, BitNet, CAN, ATM, Wi-Fi, …

CSMA/CD, CSMA/CA, Codage NRZ, Codage Manchester, Codage Miller, RS-232, RS-449, V.21-V.23, V.42-V.90, Câble coaxial, 10Base2, 10BASE5, Paire Physique torsadée, 10BASE-T, 100BASE-TX, ISDN, PDH, SDH, T-carrier, EIA-422, EIA- 485, SONET, ADSL, SDSL, VDSL, DSSS, FHSS, IrDA, USB, IEEE 1394, Wireless USB, …

Modèle OSI

Internet Message Access Protocol (IMAP) est un protocole de messagerie électronique, fonctionnant pour la réception. Ce protocole permet de laisser ses e-mails sur le serveur dans le but de pouvoir les consulter de différents clients e-mails ou webmail. Il comporte des fonctionnalités avancées, comme les boîtes aux lettres multiples, la possibilité de créer des dossiers pour trier ses e-mails...

IMAP utilise le port TCP 143.

Le fait que les messages soient archivés sur le serveur fait que l'utilisateur peut accéder à tous ses messages depuis n'importe où sur le réseau et que l'administrateur peut facilement faire des copies de sauvegarde.

Il est particulièrement bien adapté à l'accès à travers des connexions lentes.

IMAPS (IMAP over SSL) permet l'accès sécurisé au serveur en utilisant SSL. Il utilise le port TCP 993. L'utilisation du protocole IMAP au dessus de SSL est décrit dans la RFC 2595.

[modifier] Le client e-mail La plupart des clients e-mail implémentent le protocole IMAP puisque celui-ci est largement utilisé par les différents fournisseurs.

Libres :

 Mozilla Thunderbird  KMail  Novell Evolution  Mutt  Sylpheed

Propriétaires :

 Opera  Lotus Notes  Microsoft Outlook  Outlook Express  Apple Mail

 RFC 3501 (en) - spécifications du protocole IMAP, version 4, révision 1  RFC 2595 (en) - utilisation de TLS (SSL) avec les protocoles POP3 et IMAP4  The IMAP connection (en)

[modifier] Voir aussi Reverse address resolution protocol

RARP (pour Reverse ARP) permet à partir d'une adresse matérielle (adresse MAC) de déterminer l'adresse IP d'une machine. En résumé, RARP fait l'inverse de ARP.

Récupérée de « http://fr.wikipedia.org/wiki/Reverse_address_resolution_protocol » Voix sur réseau IP

(Redirigé depuis VoIP) Aller à : navigation, Rechercher

La voix sur réseau IP, parfois appelée téléphonie IP ou téléphonie sur Internet, et souvent abrégée en « VoIP » (abrégé de l'anglais Voice over IP), est une technique qui permet de communiquer par voix à distance via le réseau Internet, ou tout autre réseau acceptant le protocole TCP/IP.

Au contraire des téléphones analogiques filaires (RTC) dépendant de centraux téléphoniques dédiés, la voix sur IP permet le transport de conversations téléphoniques sur tout réseau numérique ou analogique acceptant le protocole TCP/IP (Ethernet, RNIS, PPP, etc.) Sommaire [masquer]

 1 Description de fonctionnement  2 Les principaux protocoles  3 Les différents modes de diffusion  4 Aspect logiciel  5 Quelques logiciels de voix sur IP  6 Matériels

 7 Liens externes [modifier] Description de fonctionnement

Schématiquement, le transport de la voix se fait ainsi. Le codec audio de l'émetteur numérise et compresse la voix, ces données numériques sont acheminées jusqu'au destinataire dans des paquets IP. Le codec du destinataire effectue les opérations inverses (décompression, puis restitution du son).

Pour assurer une certaine qualité à la voix, il y a plusieurs facteurs à considérer. Par convention, l'information voyage dans des datagrammes UDP (on ne parle en effet de paquet qu'après encapsulation IP), un protocole qui ne garantit pas la livraison, en échange de moins de traitement tout au long de son voyage sur le réseau. Selon les conditions du réseau, engorgement surtout, certains datagrammes UDP sont détruits. Pour cette raison, des datagrammes peuvent être retransmis à plusieurs reprises.

La numérisation est un processus discret, c'est-à-dire que plusieurs fréquences contenues dans la voix ne sont pas numérisées ni restituées, ce qui amène une perte d'information. Il est possible d'augmenter la qualité de la voix, mais au prix de demander plus de bande passante. Pour la voix, sans compression, la bande passante est de 64 kbps (codec G711), il existe de nombreux autres codecs dont le G729 moins consommateur et dernièrement des normalisations autour de codecs larges bandes comme G729- EV, permettant d'améliorer sensiblement la qualité vocale des communications.

Pour des raisons techniques, le phénomène d'écho est, à degré variable, omniprésent dans ce type de communication. Les logiciels qui compensent cet effet sont souvent propriétaires. Supposons que l'appareil A utilise le logiciel A et que l'appareil B utilise le logiciel B. Les deux logiciels risquent de traiter l'écho de façon légèrement différente, ce qui amène des effets de bord non contrôlés. Par exemple, des sifflements se font entendre pendant la communication. Finalement, la latence variable du réseau Internet fait que les données voyagent plus ou moins vite. Alors que cette variabilité est acceptable pour des données, elle ne l'est pas pour la voix, phénomène physique qui demande une certaine continuité pour que les gens puissent se comprendre.

La transmission des fax et les services d'urgence (18, 17,911...) sont aussi des défis importants à résoudre pour la téléphonie IP dite grand public. En effet l'utilisation d'adresse IP est relativement indépendante de la localisation de l'utilisateur (contrairement à l'utilisation d'une ligne de cuivre traditionnelle qui identifie formellement la localisation de l'usager), ce qui complexifie le routage des appels vers le service d'urgence le plus proche.

En dehors de la ToIP sur Internet, la ToIP se retrouve aussi dans le milieu opérateur en cœur de réseau pour remplacer les infrastructures TDM traditionnelles. On trouve principalement 2 usages résidentiels opérateurs :

 l'utilisation de call server IP et de passerelle VoIP résidentielles (Livebox,Freebox,...) pour utiliser l'ADSL pour transporter la voix plutôt que la bande basse de la ligne analogique  l'utilisation de call server IP et passerelles voix dans les DSLAM qui permettent de faire de la voix sur IP à partir d'un téléphone traditionnel et de manière transparente pour l'utilisateur.

Ces évolutions d'usages amènent les grands opérateurs à revoir leurs infrastructures cœur pour le traitement d'appel. Les normalisation européennes ETSI normalisent pour ces usages TISPAN qui instancie et fédère les normalisation 3GPP IMS pour un usage convergent fixe mobile sur IP.

[modifier] Les principaux protocoles

Les principaux protocoles utilisés pour l'établissement de connexions en voix sur IP sont :

 H.323 ;  SIP ;  MGCP ;  SCCP (propriétaire Cisco Systems) ;  Jingle, basé sur le protocole de messagerie instantanée standard ouvert Jabber Les principaux protocoles utilisés pour le transport de la voix elle-même sont :

 RTP ;  RTCP.

[modifier] Les différents modes de diffusion

Le terme « VoIP » est en général utilisé pour décrire des communications « point à point ». Pour la diffusion de son sur IP en multipoints, on parlera plutôt de streaming, comme les radios Web par exemple.

La voix ou le son sur IP peut se faire en mode Unicast, Broadcast ou Multicast sur les réseaux, c'est-à-dire en mode « point à point », en mode « une émission et plusieurs réceptions » (comme un émetteur TV, par ex.) et en mode « une émission pour plusieurs réceptions » (mais le signal n'est routé que s'il y a des récepteurs). Le protocole H.323 ne fonctionne qu'en mode Unicast.

Note : Le transport de communication sur IP est très dépendant du délai de latence d'un réseau. Ce délai influe beaucoup sur la qualité psycho-acoustique d'une conversation. Avec l'avènement des réseaux 100 Mégabits/s et ADSL, les temps de latence deviennent acceptables pour une utilisation quotidienne de la voix sur IP. À l'inverse, les connexions par liaison satellite souffrent d'un temps de latence souvent trop important pour prendre en charge les applications de voix sur IP. En moyenne, le temps de latence sur ce type de liaison est estimé entre 400 et 800 millisecondes. Une connexion filaire (fibre optique ou cuivre) bénéficie d'un temps de latence de 60 à 200 millisecondes.

[modifier] Aspect logiciel

Avec la démocratisation des réseaux haut débit le nombre d’applications possibles a considérablement augmenté. Les applications de VoIP (Voice over IP) sont une des nouvelles possibilités offertes. En effet, l’augmentation des débits et les connexions permanentes offrent des possibilités de développement de la voix sur IP (Internet Protocol).

Le développement de la VoIP a entraîné les concepteurs de plates-formes de programmation à développer des API (Application Programming Interface) spécifiques à la voix sur IP. L’intégration de nouveaux besoins dans une plate-forme de développement permet d’attirer les concepteurs de logiciels qui doivent intégrer des fonctions de voix sur IP dans leurs applications. Elles implémentent le protocole SIP.

Les API de VoIP peuvent être utilisées dans de nombreuses applications, la plus simple étant les téléphones logiciels (soft phones). D’autres applications peuvent intégrer de la VoIP comme besoin secondaire. Citons par exemple les applications de messagerie instantanée qui intègrent de plus en plus souvent la possibilité de parler directement avec ses contacts ou bien toutes les applications nécessitant une interaction textuelle entre les différentes applications clientes comme les jeux vidéos.

[modifier] Quelques logiciels de voix sur IP

 GnomeMeeting renommé en Ekiga (licence GNU GPL)  KPhone  Linphone (licence GNU GPL)  Annasoft Lite - version free  Annasoft Pro - version payante  Microsoft NetMeeting  TeamSpeak  RAT  Skype (propriétaire et non standard)  Gizmo (propriétaire mais basé sur le standard SIP)  WengoPhone (logiciel libre basé sur des standards)  LiveCom  (en) GoogleTalk  Windows Live Messenger (MSN v.8)  Visioconference HotConference  Streamwide, suites logicielle

[modifier] Matériels

On trouve de plus en plus de matériels directements compatibles avec des logiciels de VoIP, comme des téléphones Wifi; malheureusement, la plupart sont liés, dans leurs fonctionnement, aux solutions propriétaires comme les téléphones compatibles Skype par exemple. Pour ne pas se retrouver avec des matériels incompatibles avec les futures standards, qui ne tarderons pas à se dégager, il est prudent de ne pas investire trop tôt pour une technologie plutôt qu'une autre.

 (fr) Portail VoIP francophone  (en) voip-info.org : wiki anglophone dédié à la voix sur IP  (en) Cours d'instruction de VoIP : Une description complète de transmission de voix en utilisant VoIP. Inclut l'information sur la technologie, conditions, installant VoIP, en utilisant des lignes de PSTN et des issues de largeur de bande  (en) VoIP Telephony News  (en) FCC - Voice-Over-Internet Protocol  (en) Comparatif de fournisseurs de service VoIP  (fr) Sécurité de la voix sur IP

Récupérée de « http://fr.wikipedia.org/wiki/Voix_sur_r%C3%A9seau_IP »

Catégories: Téléphonie | Internet IPsec

Cet article est une ébauche à compléter concernant la cryptologie, vous pouvez partager vos connaissances en le modifiant.

IPsec est un protocole (couche 3 modèle OSI) permettant le transport de données chiffrées sur un réseau IP pour établir un réseau privé virtuel.

Un réseau privé virtuel IPsec consiste à établir deux canaux de communication entre les machines :

 un canal d'échange de clés, sur une connexion UDP depuis et vers le port 500 (ISAKMP pour Internet Security Association and Key Management Protocol), défini dans la RFC 2408

 un ou plusieurs canaux de données par lesquels le trafic du réseau privé est véhiculé, deux protocoles sont possibles : o le protocole IP n°50 ESP (Encapsulating Security Payload), défini dans la RFC 2406 qui fournit l'intégrité et la confidentialité o AH (Authentication Header) qui ne fournit que l'intégrité, il est spécifié dans la RFC 2402.

La mise en place d'une architecture sécurisée à base d'IPsec est détaillée dans la RFC 2401.

[modifier] Description des paquets

[modifier]

Authentication Header (AH) Un paquet AH se présente comme suit :

0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 Entête suivante Taille Réservé Index du paramètre de sécurité (SPI) Numéro de séquence

Données d'authentification (variable)

Significations :

Entête suivante identifie le protocole utilisé pour le transfert Taille taille du paquet AH Réservé champ à zéro (pour une utilisation future) Index du paramètre de sécurité (SPI) identifie les paramètres de sécurité en fonction de l'adresse IP Numéro de séquence un compteur qui évite les attaques par répétition Données d'authentification contient les informations nécessaires pour authentifier le paquet [modifier]

Encapsulated Security Payload (ESP)

Un paquet ESP se présente comme suit :

0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 Index du paramètre de sécurité (SPI) Numéro de séquence

Données attachées * (variable)

Remplissage (0-255 octets) Longueur du remplissage Entête suivante

Données d'authentification (variable)

Significations :

Index du paramètre de sécurité (SPI) identifie les paramètres de sécurité en fonction de l'adresse IP Numéro de séquence un compteur qui évite les attaques par répétition Données attachées les données à transférer Remplissage permet d'obtenir une taille de bloc compatible avec le chiffrement Longueur du remplissage exprimée en bits Entête suivante identifie le protocole utilisé pour le transfert Données d'authentification contient les informations nécessaires pour authentifier le paquet Portail de la cryptologie – Accédez aux articles de Wikipédia concernant la cryptologie. Récupérée de « http://fr.wikipedia.org/wiki/IPsec »

Catégories: Protocole réseau | Protocole de communication chiffrée | Wikipédia:ébauche cryptologie