{"id":549,"date":"2017-04-29T16:54:24","date_gmt":"2017-04-29T14:54:24","guid":{"rendered":"http:\/\/www.gatoux.com\/?page_id=549"},"modified":"2017-05-02T20:38:23","modified_gmt":"2017-05-02T18:38:23","slug":"pourquoi-partager","status":"publish","type":"page","link":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/pourquoi-partager\/","title":{"rendered":"Pourquoi partager ?"},"content":{"rendered":"

En fait sur un plan technique<\/strong> c’est plut\u00f4t simple : On cherche \u00e0 remplir le tuyau<\/strong> !<\/p>\n

Et sur un plan \u00e9conomique<\/strong> ce n’est pas plus compliqu\u00e9 : On cherche \u00e0 payer le moins cher possible<\/strong> … en remplissant le mieux possible les tuyaux !<\/p>\n

La solution est donc tr\u00e8s simple : On partage, on divise, le d\u00e9bit et le co\u00fbt entre plusieurs partenaires !<\/p>\n

L’aspect \u00e9conomique des choses …<\/h2>\n

C’est naturel ! Moins c’est cher plus on est heureux ! En mati\u00e8re de r\u00e9seau, comme en toutes choses d’ailleurs, toutes les entreprises cherchent \u00e0 obtenir le meilleur service au moindre co\u00fbt. Pour comprendre l’int\u00e9r\u00eat \u00e9conomique de la mutualisation il suffit de conna\u00eetre les mod\u00e8les de tarification<\/strong> existant actuellement en mati\u00e8re de supports de transmission.<\/p>\n

La liaison lou\u00e9e<\/strong> permet de r\u00e9aliser une interconnexion point \u00e0 point. Son prix grandit avec la distance \u00e0 parcourir<\/strong> (\u00e0 vol d’oiseau entre deux sites) et son d\u00e9bit<\/strong> binaire. Donc plus la liaison est courte et plus son d\u00e9bit est faible, mieux c’est ! L’utilisation de points de concentration interm\u00e9diaires permet de diminuer globalement les distances (2 liaisons de 10Km concentr\u00e9es sur une liaison de 5Km \u00e9gal 25 Km, contre deux liaisons de 15 Km \u00e9gal \u00e0 30 Km !). Cependant cette topologie peut obliger \u00e0 appliquer une augmentation de d\u00e9bit sur le lien de concentration (2 liaisons de 10 Km \u00e0 64 Kbps sur une liaison de 5 Km \u00e0 128 Kbps, contre deux liaisons de 15 Km \u00e0 64 Kbps). Dans ce cas, il s’agit de savoir si le fait de passer \u00e0 128 Kbps sur 5 km ne serait pas plus cher que de rester \u00e0 64 Kbps sur deux fois 5 Km !! Tout d\u00e9pendra de la longueur de la liaison de concentration … Il faut faire le calcul !<\/p>\n

Les raccordements \u00e0 un backbone op\u00e9rateur<\/strong> (X25, Frame Relay, Internet, IP, etc.). Ici, g\u00e9n\u00e9ralement, seul reste le crit\u00e8re de d\u00e9bit<\/strong>. L’op\u00e9rateur pratique g\u00e9n\u00e9ralement une \u00ab\u00a0p\u00e9r\u00e9quation<\/strong>\u00a0\u00bb de ses tarifs de raccordement. En fait le r\u00e9seau op\u00e9rateur dispose de plus ou moins de points d’acc\u00e8s nationaux et internationaux. Il estime donc qu’en moyenne quelle que soit la localisation du site client la longueur de la liaison de raccordement sera de X Km. Pour des sites sur Paris, par exemple, la longueur sera tr\u00e8s inf\u00e9rieure \u00e0 X mais un site sur le plateau du Larzac\u00a0 sera \u00e0 une distance bien sup\u00e9rieure \u00e0 X. Mais l’op\u00e9rateur calcule ses prix de raccordement sur la valeur X, en priant pour ne pas avoir des clients que sur le plateau du Larzac (entre-nous, il y a peu de chance ! Ils ne sont pas fous les op\u00e9rateurs !<\/em>). Bien s\u00fbr le prix du raccordement \u00e0 un d\u00e9bit donn\u00e9 et souvent un peu plus cher qu’une liaison point \u00e0 point de m\u00eame longueur et de m\u00eame d\u00e9bit car l’op\u00e9rateur ajoute les co\u00fbts d’architecture, d’exploitation et de maintenance du backbone ! (Sans oublier sa petite marge quand m\u00eame !<\/em>).
\nAttention<\/strong> : Cette p\u00e9r\u00e9quation est souvent appliqu\u00e9e pour les raccordements nationaux ! Pour les raccordements internationaux cela d\u00e9pendra des accords pass\u00e9s entre l’op\u00e9rateur fournissant le service de backbone et les op\u00e9rateurs locaux fournissant les liaisons de raccordement.<\/p>\n

Le prix des raccordements \u00e0 un r\u00e9seau de type RNIS ou RTC augmente en fonction de la dur\u00e9e de communication et en fonction de sa distance<\/strong> (appels locaux, nationaux ou internationaux). Ce type de r\u00e9seau devient tr\u00e8s on\u00e9reux si les communications sont fr\u00e9quentes, voir constantes ! L’avantage est qu’ils sont tr\u00e8s ouverts, depuis un m\u00eame point on peut contacter successivement de nombreux autres sites quel que soit leur localisation dans le monde. L’inconv\u00e9nient est qu’il y a souvent un sens unique \u00e0 l’appel (souvent site distant vers site central) afin d’\u00e9viter les croisements d’appels. Pour limiter les co\u00fbts de communication, la majorit\u00e9 des op\u00e9rateurs proposent des acc\u00e8s RNIS et RTC \u00e0 leur r\u00e9seau backbone. Le site appel un serveur d’acc\u00e8s au r\u00e9seau (NAS<\/strong> : N<\/strong>etwork A<\/strong>ccess S<\/strong>erver) qui achemine le trafic vers un site central connect\u00e9 au r\u00e9seau par une liaison permanente. Les NAS \u00e9tant diss\u00e9min\u00e9s dans le r\u00e9seau les communications RNIS ou RTC sont souvent locales.<\/p>\n

Le cas atypique du r\u00e9seau X25<\/strong>, une innovation essentiellement fran\u00e7aise, est la facturation au volume<\/strong> ! Ce principe est d’ailleurs repris dans les r\u00e9seaux GPRS ! Il s’agit cette fois de facturer le volume de donn\u00e9es transmis (en plus du prix du raccordement). Dans cette logique il vaut mieux avoir des protocoles peu bavard sur le r\u00e9seau ! Nous reviendrons sur X25 dans un cours sp\u00e9cifique.<\/p>\n

Donc globalement il appara\u00eet clairement que quel que soit le mode de raccordement, le d\u00e9bit d’interconnexion est un facteur \u00e9conomique<\/strong>, il y en a d’autres mais ce n’est pas le sujet de ce cours.<\/p>\n

Donc cherchons \u00e0 diminuer les d\u00e9bits en les partageant ! Seulement sur un plan technique est-ce si simple ? Pourquoi pourrait-on partager un support ?<\/p>\n

C’est tout d’abord une question d’application …<\/h2>\n

En gros, toute transmission informatique ressemble \u00e0 du gruy\u00e8re ! C’est bourr\u00e9 de trous, de silences de transmission …On peut diviser les applications en quatre grandes familles :<\/p>\n

    \n
  • les applications clients-serveurs<\/strong> : ce sont g\u00e9n\u00e9ralement des applications qui pr\u00e9sentent des masques \u00e0 remplir aux utilisateurs et g\u00e9n\u00e8rent des requ\u00eates vers des bases de donn\u00e9es et serveurs d’application centraux. Ici on peut subdiviser cette famille en deux :\n
      \n
    • le client-serveur non connect\u00e9<\/u> : ce sont typiquement les applications en mode HTTP<\/strong> (Web), mais \u00e9galement d’autres d\u00e9veloppement \u00e0 base de Java ou autres. L’utilisateur rempli un masque, et transmets son masque en validant un bouton. Pendant que l’utilisateur saisi son \u00e9cran, il n’y a pas de transmission en ligne ! Premier trou dans le gruy\u00e8re ! Lorsque les donn\u00e9es arrivent au serveur, il les traite puis \u00e9mets une r\u00e9ponse. Pendant le traitement, il n’y a pas de transmission en ligne ! Deuxi\u00e8me trou dans le gruy\u00e8re (dans l’autre sens de transmission, je vous l’accorde<\/em>) ! D’autre part pour ce type d’application, le volume de donn\u00e9es \u00e9mis par l’utilisateur est relativement faible<\/strong>. Un \u00e9cran d\u00e9passera rarement les 2 Ko (soit environ 2000 caract\u00e8res), par contre une r\u00e9ponse serveur pourrait \u00eatre importante (un gros SELECT sur une base de donn\u00e9es).<\/li>\n
    • le client-serveur connect\u00e9<\/u> (SNA d’IBM, SAP\/IPX ou les watchdogs) : ce sont des applications du m\u00eame type que pr\u00e9c\u00e9demment si ce n’est qu’il existe un dialogue constant entre le client et le serveur pour v\u00e9rifier la pr\u00e9sence du client. Des requ\u00eates de maintien de sessions permettent au serveur de savoir si le client est toujours pr\u00e9sent ou s’il peut lib\u00e9rer la session (et les ressources associ\u00e9es comme une zone m\u00e9moire, un pool de variables de contexte, etc.). Dans ce mode le volume reste malgr\u00e9 tout toujours assez faible car les requ\u00eates sont fr\u00e9quentes mais peu volumineuses<\/strong>. Le probl\u00e8me ici est plut\u00f4t le d\u00e9lai de transit, mais c’est un autre sujet … Ici occupons nous du niveau d’utilisation de la bande passante.<\/li>\n<\/ul>\n<\/li>\n
    • les applications de transfert de fichiers<\/strong> : vous connaissez bien notre star \u00e0 nous : FTP<\/strong> ! Il en existe des tonnes d’autres comme CFT, TFTP ou encore FTAM. Tout d\u00e9pend des environnements informatiques. Par contre elles pr\u00e9sentent toutes la m\u00eame caract\u00e9ristique : elles utilisent toute la bande passante disponible<\/strong> pendant leur transfert. Mais g\u00e9n\u00e9ralement ces transferts sont tr\u00e8s \u00e9pisodiques<\/strong> et il y a de longs moments d’ennuis … Sauf bien s\u00fbr si vous \u00eates un serveur h\u00e9bergeant des tonnes de MP3 ou de DivX sur Internet ! En g\u00e9n\u00e9ral ce type d’application n\u00e9cessite tout de m\u00eame des architectures \u00e0 fortes bandes passantes<\/strong> en g\u00e9n\u00e9ral, ou mieux, des supports pr\u00e9sentant une bande passante variable comme le Frame Relay ou l’ATM, voir asym\u00e9trique, comme l’ADSL ! A noter qu’on classera sous cette cat\u00e9gorie les \u00e9changes SMTP<\/strong> (messagerie) qui pr\u00e9sentent souvent des messages volumineux en raison des pi\u00e8ces jointes !<\/li>\n
    • les applications d’\u00e9mulation d’\u00e9crans<\/strong> : il s’agit d’offrir \u00e0 un terminal peu intelligent, ou incompatible avec un type de serveur, la possibilit\u00e9 d\u2019acc\u00e9der \u00e0 un environnement informatique distant. On divise \u00e9galement cette famille en deux :\n
        \n
      • les \u00e9mulations de terminal en mode caract\u00e8res<\/u> (TELNET, VT) : le client \u00e9met des caract\u00e8res vers le serveur, celui-ci les interpr\u00e8tent et lui retourne ce qu’il a compris (on appelle \u00e7a l’\u00e9cho distant). Plut\u00f4t que d’afficher sur l’\u00e9cran ce que le serveur a compris certain terminaux permettent d’afficher ce qui vient d’\u00eatre tap\u00e9 sur le clavier (on appelle \u00e7a l’\u00e9cho local). Quoiqu’il en soit les caract\u00e8res sont \u00e9mis un \u00e0 un sur la ligne, si vous avec une super secr\u00e9taire vous pouvez esp\u00e9rer avoir un meilleur taux d’utilisation de la ligne que si c’est un policier qui frappe avec ses deux doigts (s’il a encore ses deux bras !<\/em>). Mais dans tous les cas on reste tr\u00e8s faible.
        \nExemple<\/strong> :
        \nune secr\u00e9taire chevronn\u00e9e tapant au rythme effr\u00e9n\u00e9 de 90 mots minutes (Diantre ! M\u00eame ma m\u00e8re tape pas aussi vite !<\/em>). Sur une moyenne de 10 caract\u00e8res par mots on obtient 900 caract\u00e8res\/min soit 15 caract\u00e8res\/sec soit royalement 120 bits\/s (8 eb par caract\u00e8res)… Et pendant la pause caf\u00e9, il est \u00e0 combien le d\u00e9bit <\/em>?<\/li>\n
      • les \u00e9mulations de terminal en mode graphique<\/u> : ces applications permettent de repr\u00e9senter graphiquement un environnement informatique distant. Imaginez que votre poste client soit sous un vieil OS comme OS\/2 et que vous souhaitiez lui offrir un environnement bureautique \u00ab\u00a0high-tech\u00a0\u00bb comme Office 2000 (Bilou va m’embrasser ! Office 2000 high-tech !<\/em> ). Vous \u00eates dans la mouise ! Il vous faut changer vos postes clients ! Et \u00e7a peut \u00eatre tr\u00e8s, tr\u00e8s, tr\u00e8s co\u00fbteux ! Avec des environnements comme Citrix, Terminal Server ou encore X11 vous allez pouvoir vous en sortir en installant un minimum de soft sur le poste client.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n

        Ce soft va permettre d’\u00e9tablir une connexion avec un serveur d’\u00e9mulation. Ce serveur va allouer une zone m\u00e9moire pour simuler votre \u00e9cran Windows (pour notre exemple) et y faire tourner ce que vous voulez … \u00e0 distance ! Le protocole entre le client et le serveur va informer l’un et l’autre des modifications au niveau du clavier, de la souris ou de l’\u00e9cran. C’est un peu comme si vous regardiez un Windows tourner sur une autre machine par une petite fen\u00eatre (votre \u00e9cran !) et que vous le t\u00e9l\u00e9commandiez avec votre clavier et votre souris ! Cool non ?
        \nCe type d’application n’est pas forc\u00e9ment gourmand en bande passante, mais g\u00e9n\u00e9ralement les transmissions sont assez constantes. Citrix annonce une bande passante moyenne par session de 15 Kbps environ. Cependant \u00e9tant donn\u00e9 que le principe est de transmettre des informations sur les zones d’\u00e9crans \u00e0 rafra\u00eechir, il est certain que si vous visualisez une vid\u00e9o \u00e0 distance ou un GIF anim\u00e9 … Vous allez p\u00e9ter le compteur ! Donc un dimensionnement de r\u00e9seau avec ce type d’application c’est un peu du \u00ab\u00a0petit bonheur la chance\u00a0\u00bb ! Finalement on fait confiance \u00e0 Citrix et on prend 15 Kbps par session utilisateur (pour X11 il semblerait que ce soit similaire, pour Terminal Server j’ai aucune id\u00e9e !).<\/p><\/blockquote>\n

          \n
        • les applications multim\u00e9dia<\/strong> : il s’agit ici des applications de type voix (sur IP ou sur Frame Relay ou autres), plus g\u00e9n\u00e9ralement on parle d’int\u00e9gration voix-donn\u00e9es. Mais il s’agit \u00e9galement des applications de visioconf\u00e9rence, de streaming bref, tout ce qui touche \u00e0 la vid\u00e9o. Ici les contraintes sont diff\u00e9rentes, les applications de voix ont besoin d’une bande passante constante (entre 16 et 25 kbps par session selon la compression et le nombre de voix simultan\u00e9es). Les applications vid\u00e9o ont \u00e9galement besoin de beaucoup de bande passante (256 Kbps minimum pour une session de visioconf\u00e9rence correcte) mais g\u00e9n\u00e8re des bursts, la transmission est beaucoup moins lin\u00e9aire que pour de la voix. Ce sont sans doute les applications qui g\u00e9n\u00e8rent le moins de \u00ab\u00a0trous\u00a0\u00bb de transmission. Mais bien s\u00fbr, entre deux communications … la bande passante est libre !<\/li>\n<\/ul>\n

          Donc, en r\u00e9sum\u00e9, quelque soit l’application utilis\u00e9e, il est extr\u00eamement rare que le support soit utilis\u00e9 \u00e0 100% ! Dans le sch\u00e9ma suivant le lien est partag\u00e9 par les utilisateurs U1 et U2. Les paquets correspondant sont s\u00e9par\u00e9s et des espaces libres de transmission subsistent.<\/p>\n

          \"\"<\/p>\n

          C’est aussi une question d’utilisation …<\/h2>\n

          Le sch\u00e9ma pr\u00e9c\u00e9dent montre l’espace existant entre deux paquets U1 ou deux paquets U2 qui symbolise le fonctionnement asynchrone des applications<\/strong> tel que nous venons de l’expliquer. Mais il montre \u00e9galement qu’il existe des espaces libres entre un paquet U1 et un paquet U2. Cette espace ne rel\u00e8ve pas du mode de fonctionnement des applications, mais de l’asynchronisme d’utilisation des applications par les utilisateurs<\/strong> ! Chacun d’eux ne transmets pas forc\u00e9ment en m\u00eame temps !<\/p>\n

          Ce param\u00e8tre dit de \u00ab\u00a0sessions simultan\u00e9es<\/strong>\u00a0\u00bb est tr\u00e8s important ! Combien d’utilisateurs utiliseront une application en m\u00eame temps ? C’est toute la probl\u00e9matique dans un dimensionnement de r\u00e9seaux :<\/p>\n

            \n
          • il faut conna\u00eetre la bande passante n\u00e9cessaire<\/strong> par session pour une application donn\u00e9e<\/li>\n
          • puis il faut savoir combien de sessions simultan\u00e9es<\/strong> peuvent \u00eatre \u00e9tablies en moyenne pour une application !<\/li>\n
          • enfin il faut identifier chaque application <\/strong>susceptibles d’\u00eatre utilis\u00e9e par les clients d’un site donn\u00e9. Pour chaque application, les param\u00e8tres de bande passante par session et de simultan\u00e9it\u00e9 de sessions doivent bien s\u00fbr \u00eatre connus !<\/li>\n<\/ul>\n

            Avec ces trois param\u00e8tres vous pouvez d\u00e9finir quel est le d\u00e9bit n\u00e9cessaire pour un site donn\u00e9 ! Le probl\u00e8me est qu’il est bien souvent difficile d’avoir une vue pr\u00e9cise du deuxi\u00e8me facteur (d\u00e9j\u00e0 avoir des informations sur le premier est un vrai bonheur !<\/em>). En effet le deuxi\u00e8me facteur, m\u00eame pour une m\u00eame application, va consid\u00e9rablement varier :<\/p>\n