Introduction aux applications Internet RES 101 dario.rossi Introduction aux applications Internet Dario Rossi http://www.enst.fr/~drossi RES101 v03/2016
RES203 Internet applications Foreword Dario Rossi dario.rossi@enst.fr ([RES101] in the subject !!) http://www.enst.fr/~drossi Short CV 2001, MSc @ Politecnico di Torino, Italy 2003, Researcher @ University of California Berkeley, CA 2005, PhD @ Politecnico di Torino, Italy 2006, Associate Professor @ ENST, France 2010, HDR @ UPMC, France 2011, Qualification @ CNU 2012, Professor @ Telecom ParisTech, France 2012, Professor @ X, France RES203 Internet applications 2
Internet protocols http://javvin.com/map.html
Internet applications 4
Plan Terminologie Architectures applicatives vs Architectures reseaux Application et Protocoles Architectures applicatives vs Architectures reseaux Applicatives: Client-server, Content distribution networks, Peer-to- peer Reseaux: IP Multicast, Content centric networking Couche applicative (overlay) et couches TCP/IP (underlay) Interactions Interface (socket) Type d’applications et mesure de performance Applications orientés donnés vs application multimedia (voix, video) Quality of Service (QoS) vs Quality of Experience (QoE) Choix du protocole de transport 5
Applications: une vue d’ensemble “Application” est un terme abusé ou imprecis L’application de messagerie est votre logiciel mail preferé ? Architecture Besoin de definir plusieurs aspects commun aux applications Architecture Procole Processus agents et daemons Communication inter-processus Sockets Hote Agent utilisateur Socket Protocole Socket Daemon Serveur
Protocoles humains … Bonjour Bonjour T’as du feu ? Les humains utilisent des protocoles sans arrêt… un example avec Alice et Bob Protocoles humains: Emission de messages spécifiques “Quelle heure est-il ?”, “S’il vous plait”, “Veuillez agréer” … Actions spécifiques accomplies après réception de messages ou d'événements particuliers Bonjour Bonjour T’as du feu ? … 7
Protocoles applicatifs Définissent : Le type des messages Requête, réponse… La syntaxe des types de messages : Format des champs du message La sémantique des champs, La signification des champs Les règles de communication Déterminent quand et comment un processus envoie des messages et y répond Protocoles applicatifs Domaine public Définis dans les IETF RFC (e.g., HTTP, SMTP, client-server) Definis dans autres fora (e.g., Gnutella, BitTorrent BEP, etc.) Propriétaires ex KaZaA, Skype, PPLive, etc. application transport network data link physical application transport network data link physical application transport network data link physical
Architectures applicatives Terminologie Communication logique L4/L7 Service consumer Service producer Infrastructure physique Internet Local/regional nets Servers
Architectures: Client-server Paradigme client-server Problemes de passage à l’echelle
Architectures: CDN Content distribution network (CDN) Infrastructure couteuse
Architectures: Multicast, CCN … IP Multicast, Content Centric Networking CCN Complexes (IP multicast utilisé pour TV over IP)
Architectures: Peer-to-peer Paradigme P2P Couche application (deployment facile) Use toutes les resources (scalable) Ressources en periferie (deplace couts)
Architecture: Peer-to-peer Interaction L7 overlay vs IP underlay Les applications Internet (L7 OSI) posent sur l’infrastructure TCP/IP sous-jacente Paradigme P2P P2P overlay IP underlay
Interaction L7 overlay vs IP underlay Les applications Internet (L7 OSI) posent sur l’infrastructure TCP/IP sous-jacente L7 overlay Interaction L7/L3: applications vs couches TCP/IP IP underlay
Interaction L7 overlay vs IP underlay Control du trafic emis (“network friendly” lorsque competition equitable par rapport à TCP) L7 overlay Problematique type L4, solutions autres que TCP Skype, BitTorrent’s uTP, Google’s QUIC, etc. IP underlay
Interaction L7 overlay vs IP underlay Routage applicatif du trafic (“network aware” quand le trafic est localisé autant que possiable au sein du ISP) $$ L7 overlay Problematique type L3, solutions autres que IP, RIP, OSPF et BGP IP underlay AS1 AS2
Processus: Agents & Daemons Agents utilisateur Implémente le coté client d’un ou plusieurs protocoles applicatif Gere l’interface homme machine (au délà du protocole) Effectue l’open active de la connession TCP (typiquement) Utilise (obligatoirement) un port éphémère Daemon Implémente le coté serveur d’un protocole applicatif Reste à l’écoute des requêtes en provenance des agents utilisateurs (open passive) Utilise (généralement) un port réservé drossi@enst.fr http://www.google.com TCP/IP TCP/IP Internet Agent utilisateur Daemon
Socket: Interface applicative TCP/IP Addresses Point de vue human: URL http://www.google.com Point de vue réseau L3: Addresses IP L4: Numero de port Sockets: Type de protocole de transport Addresse IP de la machine Addresse TCP du processus (numero de port) Traduction Service d’annuaire pour la translation d’addresses (DNS) Regles pour les numeros de port (/etc/services) Remarque Le quintuplet (IPs,Ps,IPd,Pd,proto) est unique dans le reseau drossi@enst.fr http://www.google.com TCP/IP TCP/IP Internet 137.192.164.1:37562 74.125.39.180:80
Socket: Quel protocol de transport ? TCP et UDP fournissent des service tres different Lequel choisir ? Étude des services fournis par chaque protocole Etude du type de contenu de l’application Sélection du protocole qui correspond le mieux aux besoins de l'application Beaucoup de protocoles de transport existent TCP: Transport Control Protocol UDP: User Datagram Protocol SCTP: Stream Control Transport Protocol DCCP: Datagram Congestion Control Protocol T/TCP: Transaction TCP RUDP: Reliable UDP LEDBAT: Low Extra Delay Background Transport etc. TCP: Transport Control Protocol application transport network data link physical NewReno (IETF) Cubic (Linux) Compound (Windows) Many high speed variants exist!
Qualité de Service et d’Experience Qualité de Service (QoS) (network-centric) Qualité d’Experience (QoE) (user-centric) Bande passante (Throughput) Bits ecoulés par unité de temps Probabilité de perte (Loss rate) Probabilité qu’un packet arrive avec des erreurs detectables mais pas corrigeables (wireless) Probabilité qu’un packet soit perdu à une file d’attente (wired) Delai (Delay) Temps avant que le pacquet arrive Gigue (Jitter) Variabilité du delai Orienté données Temps de completement (Completion time) “Time to the first byte” “Time to the first paint” Fiabilité … Multimedia Peak Signal to Noise Ratio (PSNR) Mean Opinion Score (MOS) Structural similiarity (SSIM) Percetpual Evaluation of Video Quality (PEVQ) Faciles à mesurer, objectifs, peu parlant vis à vis des applications Compliqués, couteuses, pas d’entente à niveau mondiale
Rappel: delai Les paquet subissent du delai à chaque saut Quatre sources de delai: Processement (<ms) - Transmission = P/C (ms – ms) File d’attente (ms – s) - Propagation = D/V (LAN < ms, WAN >10ms) Variable à chaque paquet Fixe pour chaque paquet d’un meme flux Processement Transmission P=taille de paquet C=capacité du lien D=distance V=vitesse du signal File d’attente Propagation
Dependence: delai, débit, pertes C: capacité B: taille buffer C Débit utile C Débit en emission Delai B Débit en emission Pertes Débit en emission Note: la dependence n’est linéaire que pour des fins d’illustration
Flux orientés données Examples Besoin primaire: fiabilité Web, telechargement, sessions interactives, e-mail Besoin primaire: fiabilité L’information doit etre transmise sans erreur, dans le meme ordre En cas d’erreur, il faut retransmettre Autres characteristiques: Pas de contrainte real-time Un delai <3 second pour le debut de l’affichage limite typique pour un service de type Web (Plus de details dans le TP) Telechargement d’un fichier peut etre long mais il devrait etre le plus court possible: utiliser toute la bande passante disponible (applications élastiques) Retransmissions => limit the size of the data units transmitted in concordance to the probability of loss
Flux de streaming Example Besoin primaire Source Deadline Contenu multimedia Audio (radio) or video (television) generé en real-time Besoin primaire coherence temporelle Ni accelerer ni decelerer! Maintenir la bande passante constante Autre characteristiques Ces flux sont limités en debit (celui de la source) Les usagers tollerent mal des changement de qualité Packet sequence number Source Deadline Receiver Frozen stream Delay Time Playout buffer
Flux de voix Type de flux Besoin primaire Autres characteristiques Paquets petits (100-300Bytes) et frequents (20-30ms) Faible bande passante importante PCM : 64 kbit/s ; iLBC (Skype) : 13,3 kbit/s ; GSM : 13,3 kbit/s Besoin primaire Limiter le delai de bout en bout Pas possible d’utilizer des techniques de “buffering” Maximum “mouth-to-ear” delai tolerable: 300 ms (45 ms si il n’y a pas de suppression d’echo) Autres characteristiques Robuste contre les pertes qualité plus que acceptable avec 15% de perte Moins robuste si on utilise de la compression (il n’y a plus de information redundante)
Socket: Quel protocol de transport ? Données Remise in ordre et fiable Debit limité par le reseaux En principe TCP (elastique, recupère les pertes) En pratique UDP de plus en plus utilisé pour implementer des alternatives à TCP BitTorrent LEDBAT, Google QUIC Voix, Video Debit determiné par l’encodeur Tolerance au panne En principe UDP (plus de flexibilité) En pratique TCP de plus en plus utilisé pour contourner limitations de securité (e.g., firewalls) Port 80 et 443 jamais filtrés
?? || // 28