Livre blanc Services Akamai pour l'accélération des applications : comment transformer Internet en une plate-forme de diffusion d'applications parée pour le commerce électronique
Table des matières APERÇU... 1 DÉFIS LIÉS À LA DIFFUSION D'APPLICATIONS WEB... 2 Applications dynamiques Services web 2 2 LE RÉSEAU ET SES PROTOCOLES INEFFICACES SONT RESPONSABLES DE LA LENTEUR DES DIFFUSIONS D'APPLICATIONS... 2 Les goulots d'étranglement du kilomètre intermédiaire au premier plan. Le RTT (temps d'aller-retour) est une cause de lenteur de la diffusion d'applications Tenir compte également de l'effet multiplicateur du RTT 2 2 3 APPROCHES COURANTES POUR AMÉLIORER LA DIFFUSION D'APPLICATIONS... 3 Expansion des centres de données. Appareils de diffusion d'applications Réseaux de diffusion de contenu (CDN) traditionnels Services de réseau de diffusion d'applications (ADN) 3 4 5 L'EDGEPLATFORM D'AKAMAI - UN RÉSEAU DE DIFFUSION D'APPLICATIONS... 5 Plate-forme de serveur hautement distribué Architecture binodale 5 6 SUREROUTE D'AKAMAI - RÉDUIT LE RTT... 6 SureRoute élimine les défauts d'efficacité du BGP 6 PROTOCOLE AKAMAI - RÉDUIT L'EFFET MULTIPLICATEUR DU RTT... 6 Plate-forme de serveur hautement distribué Le protocole Akamai élimine les défauts d'efficacité liés au HTTP 7 7 DÉLESTAGE DE L'INFRASTRUCTURE D'ORIGINE... 8 MONTÉE EN CHARGE ET PERFORMANCES D'APPLICATION PROUVÉES... 8 SÉCURITÉ DANS LE NUAGE... 9 IMPACT COMMERCIAL... 9 RÉSUMÉ..... 10 À PROPOS D'AKAMAI... 10
1 Aperçu Les applications d'entreprises se «webifient» pour tirer profit de la portée et de la rentabilité d'internet et étendre leur processus métier à l'échelle mondiale. L'entreprise a rapidement déployé des applications en ligne de collaboration et de productivité personnelle telles que Microsoft Outlook et SharePoint, des processus métier de l'entreprise gérés par SAP et Oracle, des systèmes de gestion de contenu et des portails extranet ainsi que des services web pour tirer profit des interactions machine-machine, pour n'en nommer que quelques-uns. Les entreprises sont confrontées à des exigences conflictuelles lorsqu'elles déplacent sur Internet des processus et applications essentiels à leur activité : minimiser les coûts et la complexité de gestion associés au déploiement de centres de données tout en assurant la meilleure sécurité et les meilleures performances d'applications possibles. De plus, les considérations de conformité réglementaire telles que la loi Sarbanes-Oxley essaient de regrouper les serveurs d'applications dans le moins d'emplacements possibles. À la surprise de tous ceux qui ont développé eux-mêmes des applications d'entreprise en ligne ou en ont acheté des toutes faites, les performances et la disponibilité de leur application ne répond souvent pas aux besoins de l'entreprise du point de vue de l'utilisateur. Dans la plupart des cas, l'application fonctionne correctement, offrant des temps de réponse inférieurs à une seconde aux utilisateurs proches de l'emplacement du serveur d'applications. Cependant, à mesure que les utilisateurs s'éloignent du serveur, les performances se détériorent rapidement. En fait, les temps de réponse d'applications en ligne pour les utilisateurs éloignés du serveur peuvent souvent dépasser de 10 fois ceux des utilisateurs proches, ce qui rend l'expérience d'utilisation de l'application très mauvaise, voire complètement inutilisable pour une base d'utilisateurs répartie mondialement. La cause sous-jacente à cette dégradation des performances est que les protocoles de routage d'internet, BGP, le protocole de transport, TCP et le protocole de communication du web, HTTP, ne sont tout simplement pas conçus pour offrir une montée en charge et des performances optimales, ce qui devient de plus en plus évident à mesure que la distance augmente. On les appelle souvent les goulots d'étranglement du «kilomètre intermédiaire». Les temps de réponse des utilisateurs éloignés du serveur peuvent bien souvent dépasser de 10 fois ceux des utilisateurs proches. Le TCP et le protocole de communication du web, le HTTP, ne sont tout simplement pas conçus pour offrir une montée en charge et des performances optimales. Temps de réponse d'application (sec.) Denver San Francisco Chicago Londres Seattle Madrid Francfort Copenhague Prague Helsinki Tokyo Istanbul Río de Janeiro Séoul Bombay Melbourne Emplacement de l'utilisateur Le Cap Perth Shanghai Le besoin d'applications en ligne hautement performantes et disponibles a entraîné la création de nombreuses solutions que les propriétaires d'applications et responsables informatiques peuvent évaluer. Dans ce livre blanc, nous examinons les causes à l'origine de la lenteur et de l'imprévisibilité des temps de réponse d'applications sur Internet et les raisons pour lesquelles l'edgeplatform mondialement distribuée d'akamai, l'infrastructure de ses managed services en accélération d'ip et de web dynamique, transcende à la fois les CDN traditionnels mais aussi les solutions d'équipement matériel d'accélération d'application pour amplifier les atouts de l'internet tout en surmontant ses faiblesses en matière de performances et de fiabilité.
2 Défis liés à la diffusion d'applications web Une entreprise présente en ligne peut offrir aux entreprises, de manière rentable, une flexibilité et une portée phénoménales pour les applications essentielles à leur activité. Cependant, la nature des applications en ligne a considérablement changé au fil du temps, à mesure que celles-ci sont devenues plus dynamiques et interactives. Les entreprises doivent améliorer les performances et l'évolutivité des deux principales catégories d'applications en ligne : les applications dynamiques et les services web. Les organisations informatiques sont confrontées à des défis de mise en œuvre pour ces deux classes d'applications en ligne dynamiques, notamment : De mauvaises performances d'applications qui se traduisent par des taux d'adoption faibles et des processus métier inefficaces Une disponibilité d'application irrégulière qui se traduit par un taux d'abandon élevé et une satisfaction médiocre de l'utilisateur Des planifications de capacité imprévisibles à cause des pics de trafic, ce qui se traduit souvent par des infrastructures d'applications submergées ou surdimensionnées. Applications dynamiques On estime que jusqu'à 75 % de la totalité des applications en ligne sont générées dynamiquement, de par le besoin d'offrir un contenu personnalisé aux processus métier essentiels. Le contenu dynamique ne se prête pas à la mise en cache, technique utilisée pour améliorer le temps de réponse associé à du contenu statique ou fréquemment utilisé. Services web L'utilisation de services web, également connus sous le nom d'interaction machine-machine, devient une plate-forme de plus en plus courante pour les applications stratégiques de B2B. Les données d'une application de service web géographiquement éloignée deviennent un ingrédient indispensable à la présentation ou au traitement d'une autre application. Le réseau et ses protocoles inefficaces sont responsables de la lenteur des diffusions d'applications Les goulots d'étranglement du kilomètre intermédiaire au premier plan La conception inhérente à Internet, «réseau de réseaux» de meilleur effort, est la cause même des problèmes de diffusion d'applications d'une base d'utilisateurs mondiale. Les entreprises en ligne n'ont pas été prises en compte lors de la conception d'internet. Nous examinons la source des problèmes de performances de services web et d'applications web dynamiques rencontrés par des utilisateurs mondiaux, c'est-à-dire le «kilomètre intermédiaire», goulots d'étranglement de réseau étendu causés par le réseau lui-même et protocoles inefficaces utilisés pour la communication. Le RTT (temps d'aller-retour) est une cause de lenteur de la diffusion d'applications Les informations envoyées via un réseau entraînent toujours une certaine latence, le temps de son voyage de la source à la cible, que l'on mesure en «IP (Internet Protocol) Round-Trip Time» ou RTT IP. Cela correspond au nombre de millisecondes nécessaire à un paquet IP pour aller d'un endroit à un autre et pour qu'un paquet de réponse soit reçu par le même chemin. Par exemple, envoyer un paquet pour un aller-retour Los Angeles-New York ne prendra jamais moins de ~30 ms, puisque c'est le temps que met la lumière à traverser les États-Unis en ligne droite. Même si une fraction du RTT sera toujours due à la limite de la vitesse de la lumière, les goulots d'étranglement réseau associés à la conception d'internet, tels que les points d'appairage des fournisseurs de services, l'encombrement et les pannes partielles et totales ajoutent de la latence inutile et une perte de paquets, empêchant les RTT de rimer avec parfait. Par exemple, au sein d'une même région géographique telle que les États-Unis ou l'europe, la latence peut dépasser 100 ms avec 10 % de perte de paquets. De la même manière, entre la région Asie-Pacifique et les États-Unis, un RTT peut souvent dépasser 500 ms avec 20 % de perte de paquets. Les entreprises en ligne n'ont pas été prises en compte lors de la conception d'internet. Les goulots d'étranglement réseau associés à la conception d'internet, tels que les points d'appairage des fournisseurs de services, l'encombrement et les pannes partielles et totales ajoutent de la latence inutile et une perte de paquets.
3 Tenir compte également de l'effet multiplicateur du RTT Le téléchargement complet d'une page web ne demande pas un, mais plusieurs dizaines de RTT entre un client et un serveur avant que la page entière ne soit chargée. Ce «multiplicateur de RTT» augmente pour les utilisateurs d'applications qui sont plus éloignés du serveur d'application d'origine. Ainsi, les goulots d'étranglement du «kilomètre intermédiaire» ne sont pas introduits uniquement par les RTT, pour un aller-retour fait sur Internet, mais également par le multiplicateur de RTT associé au nombre de fois qu'un RTT doit être effectué pour l'affichage d'une seule page web. L'effet multiplicateur du RTT est dû au protocole de transport d'internet (TCP), au protocole au cœur de l'application web (HTTP) et à la manière dont ces deux protocoles interagissent. De par sa conception, le TCP nécessite des RTT pour établir chaque nouvelle connexion, la «poignée de main en trois temps», puis des RTT supplémentaires pour «réchauffer» chaque nouvelle connexion. La fonction de TCP, nommée comme de juste «démarrage lent», est conçue pour négocier une vitesse de communication entre le navigateur et le serveur. Il faut en général trois échanges de protocole TCP pour établir une connexion TCP de communication et quatre échanges pour l'interrompre. Une page web classique, avec un corps en HTML et de nombreux objets et images intégrés, nécessite plusieurs connexions TCP séparées. Il en résulte un multiplicateur de RTT important, même quand il n'y a aucune défaillance réseau. La valeur exacte du multiplicateur dépend de plusieurs facteurs distincts, tels que la taille de la page, le nombre d'objets sur la page, leur taille et les technologies du serveur et du navigateur. Dans les applications en ligne, un nombre élevé de RTT, entre 30 et 50, est monnaie courante. Dans les applications en ligne, un nombre élevé de RTT, entre 30 et 50, est monnaie courante. Un autre point à prendre en compte est l'extrême sensibilité des temps de réponse d'une application à la congestion et aux pannes d'internet, qui se manifeste sous la forme de perte de paquets. Les points de connexion entre différents réseaux, ou points d'appairage, peuvent être une source de perte de paquets. Les réseaux se pairent par nécessité mais ils sont souvent en compétition directe avec leurs pairs, ce qui peut se traduire en raison d'alliances et de conflits par une limitation de la bande passante arrivant d'un autre réseau, entraînant alors encombrement et perte de paquets. Un mauvais choix d'itinéraire Internet peut aussi être à l'origine d'un encombrement et d'une perte de paquets. Tout paquet perdu ou hors-service peut entraîner des dépassements de délai TCP et des retransmissions, augmentant davantage le multiplicateur RTT. Les goulots d'étranglement du «premier kilomètre», capacité de l'infrastructure du serveur d'origine à monter en charge pour répondre aux attentes des utilisateurs, comme les terminaisons de connexions TCP/IP, l'équilibrage de charge de serveur, la compression de contenu et le cryptage/décryptage SSL, peuvent être résolus grâce à des techniques de délestage du serveur d'origine. Les goulots d'étranglement du «dernier kilomètre», capacité de bande passante d'une connexion Internet, disparaissent progressivement à mesure que les utilisateurs adoptent des connexions à très haut débit. Ceci amène les goulots d'étranglement de performances du «kilomètre intermédiaire» sur le devant de la scène, à savoir l'optimisation du RTT et du multiplicateur de RTT, les deux principaux coupables qui empêchent les temps de réponse d'applications d'être acceptables pour une base d'utilisateurs mondiale. Approches courantes pour améliorer la diffusion d'applications Alors que de plus en plus de processus métier sont mis en ligne par les entreprises via des services et applications web, un certain nombre de solutions et de technologies ont tenté de surmonter les défis liés à la diffusion d'applications. Les solutions potentielles doivent s'adapter à tous les contenus (dynamiques ou statiques), être bidirectionnelles (débit montant ou descendant) et ne pas gérer uniquement des interactions navigateur-serveur, mais aussi des services web pour des interactions serveur-serveur. De plus, les solutions orientées vers l'amélioration de la diffusion d'applications doivent s'attaquer au cœur des inefficacités ayant un impact sur le RTT et l'effet multiplicateur de RTT. Ceci demande un ensemble de techniques capables d'optimiser au niveau de trois couches distinctes ((1) le routage, (2) le transport et (3) l'application) qui travaillent toutes ensemble pour offrir des temps de réponse d'application optimaux. Le RTT et le multiplicateur de RTT sont les deux principaux coupables qui empêchent les temps de réponse d'application d'être acceptables pour une base d'utilisateurs mondiale. La diffusion d'applications nécessite l'optimisation de trois couches (1) le routage, (2) le transport et (3) l'application.
4 Les approches visant à l'amélioration de la diffusion d'applications appartiennent à l'une des catégories suivantes : Expansion des centres de données Appareils de diffusion d'applications Services réseaux de diffusion de contenu (CDN) traditionnels Services réseau de diffusion d'application (ADN) Expansion des centres de données L'approche «briques et mortier» pour résoudre les mauvaises performances d'applications web consiste à construire des centres de données plus nombreux et plus vastes, ce qui ajoute des serveurs et de la bande passante nécessaires à la gestion de la demande, tout en rapprochant les applications et le contenu des utilisateurs géographiquement dispersés. Par exemple, les entreprises peuvent déployer un centre de données sur chaque côte américaine, un dans la zone EMEA et l'autre dans la région Asie-Pacifique. Plusieurs problèmes se posent avec cette approche en force. Tout d'abord, l'expansion d'une infrastructure pour gérer les pics de trafic est coûteuse et se traduira parfois par une sous-exploitation des ressources de capital. En outre, bien que l'ajout de centres de données atténue les goulots d'étranglement du kilomètre intermédiaire pour les utilisateurs proches d'un centre de données, il amène également la nécessité de synchroniser et de dupliquer les données, ce qui inclut des risques en matière de conformité, de coûts et de complexité. Cette approche contraste vivement avec la tendance actuelle qui consiste à consolider les serveurs. De plus, l'expansion des centres de données n'est pas essentielle à la stratégie d'entreprise. Appareils de diffusion d'applications Des appareils spécialisés sont apparus pour pallier les inefficacités de l'expansion des centres de données, améliorer la montée en charge et optimiser la diffusion d'applications. Les appareils de diffusion d'applications sont répartis en deux catégories principales : les contrôleurs de diffusion d'application (ADC) et les contrôleurs d'optimisation de WAN (WOC). L'expansion d'une infrastructure pour gérer les pics de trafic est coûteuse et se traduira parfois par une sous-exploitation des ressources de capital. Le déploiement d'un appareil partout où un utilisateur peut accéder à un navigateur web n'est pas plausible. Les ADC ont été conçus pour offrir un basculement entre les couches 4 à 7 ; ils offrent aujourd'hui tout un panel de fonctions comprenant l'équilibrage de charge locale, la compression et le délestage SSL. Ces dispositifs se concentrent sur l'optimisation du centre de données de l'entreprise devant les serveurs web. Ils offrent une certaine amélioration des performances mais ne sont qu'une partie de l'équation. Bien qu'ils traitent les informations à leur sortie du centre de données, ils ne s'attaquent pas aux goulots d'étranglement du nuage, entre les ADC et les utilisateurs. Les applications bidirectionnelles sont mieux desservies par des méthodes de diffusion binodales mais le déploiement d'un appareil partout où un utilisateur peut accéder à un navigateur web n'est pas plausible. Puisque l'empreinte d'un contrôleur de diffusion d'application est limitée au centre de données, celui-ci ne peut offrir d'optimisation binodale en rapprochant des utilisateurs les services ou informations de traitement. Ceci limite leur capacité à optimiser correctement les goulots d'étranglement du «kilomètre intermédiaire», ce qui empêche les RTT et multiplicateurs de RTT d'être optimaux. Les WOC sont des solutions binodales où les appareils ou clients logiciels résident des deux côtés d'une liaison WAN pour offrir optimisation de protocole, compression et adaptation afin d'améliorer les temps de réponse d'applications. Cela participe également à l'amélioration des performances des succursales qui luttent avec certaines applications submergeant les liaisons WAN. C'est une solution convaincante pour les Intranets avec un petit nombre d'emplacements. Cependant, elle ne convient pas à un grand nombre d'emplacements car le service informatique doit déployer et gérer les solutions WOC à chaque emplacement d'utilisateur. Ils ne seront également d'aucune aide pour les applications extranet ni pour les requêtes de service web sur Internet, où la communauté d'utilisateurs réside à l'extérieur de l'environnement WAN d'entreprise, comme un client ou un partenaire commercial. Réseaux de diffusion de contenu (CDN) traditionnels Les CDN traditionnels mettent le contenu statique en cache au plus près des utilisateurs, généralement avec une architecture centralisée contenant un petit nombre d'emplacements de serveurs. Les CDN traditionnels ne s'attaquent pas aux goulots d'étranglement du kilomètre intermédiaire associés aux applications d'entreprise dynamiques en ligne et n'aident donc pas les applications telles que celles offertes par SAP, Oracle et Outlook Web Access, qui ont très peu, ou pas, de contenu statique à mettre en cache.
5 Services de réseau de diffusion d'applications (ADN) Des services réseau de diffusion d'applications sont apparus sous la forme d'une vaste plate-forme en ligne destinée à améliorer les performances d'applications web. Les ADN ont remplacé les CDN traditionnels et les appareils de diffusion d'applications en s'attaquant à la fois aux goulots d'étranglements du premier kilomètre et du kilomètre intermédiaire et en optimisant la diffusion des applications dynamiques, du contenu statique et des services web. Grâce à la mise en œuvre d'un réseau dédié sur Internet, les fournisseurs de services ADN utilisent l'intelligence d'internet tout en combinant les techniques employées par les appareils de diffusion d'application et les CDN pour transformer Internet en une plate-forme de diffusion hautement performante pour les applications IP et web. Les ADN peuvent offrir aux utilisateurs mondiaux des temps de réponse locaux, une disponibilité élevée, une montée en charge à la demande et une sécurité d'entreprise sans qu'aucun changement ne soit apporté aux applications ou à l'infrastructure du centre de données. Des contrats de niveau de service sont généralement offerts pour garantir la disponibilité et la performance des applications. En même temps, le TCO est plus faible qu'avec des approches utilisant des appareils. Les coûts sont plus prévisibles : il n'y a que le coût mensuel du service. L'EdgePlatform d'akamai - un réseau de diffusion d'applications L'EdgePlatform d'akamai est un réseau de diffusion d'applications spécifique qui accélère la diffusion d'applications et de contenu via Internet, ce qui peut entraîner des augmentations en termes d'utilisation, d'adoption et de productivité. Avec son réseau mondial de serveurs spécialisés reliés via des protocoles optimisés, la plate-forme couvre Internet en toute transparence et optimise la diffusion de contenu et d'applications à la demande. En s'attaquant aux points faibles au cœur des protocoles Internet, Akamai a créé un système de diffusion à travers la périphérie du réseau conçu pour améliorer les performances, la disponibilité et la montée en charge d'applications dynamiques IP, de services web et de contenu statique. Les ADN peuvent offrir aux utilisateurs mondiaux des temps de réponse locaux, une disponibilité élevée, une montée en charge à la demande et une sécurité d' entreprise sans qu'aucun changement ne soit apporté aux applications ou à l'infrastructure du centre de données. Akamai a créé un système de diffusion conçu pour améliorer les performances, la disponibilité et la montée en charge d'applications dynamiques IP, de services web et de contenu statique. Si l'on s'intéresse de plus près à l'architecture et aux technologies de l'edgeplatform d'akamai, on comprend pourquoi il s'agit de la méthode de diffusion d'applications idéale pour offrir des temps de réponse locaux aux utilisateurs mondiaux. Pour mieux comprendre les technologies qui se cachent derrière l'edgeplatform, il est important de passer en revue les composants clés de son architecture et la manière dont les applications sont diffusées. Plate-forme de serveur hautement distribué La plate-forme se compose d'un réseau dédié binodal composé de serveurs spécialisés baptisés «serveurs périphériques» d'akamai. Ces serveurs périphériques sont distribués dans des emplacements très proches des utilisateurs comme de l'infrastructure d'origine. Il s'agit d'une plate-forme de serveurs distribués mondialement avec plus de 28 000 serveurs répartis dans environ 1 000 réseaux et environ 70 pays. Avec cette plate-forme, 90 % des utilisateurs mondiaux d'internet sont à moins d'un «bond» de réseau d'un serveur périphérique d'akamai. 90 % des utilisateurs mondiaux d'internet sont à moins d'un «bond» de réseau d'un serveur périphérique d'akamai. La nature largement distribuée des serveurs périphériques implique que pour chaque internaute et chaque application centralisée correspondante, quels que soient leurs emplacements, il existe non loin une région de serveur périphérique. Akamai utilise un système de mapping dynamique intelligent pour diriger chaque utilisateur et emplacement d'origine vers le serveur périphérique optimal, qui servira de rampes d'arrivée et de départ jusqu'au réseau Akamai. Les serveurs périphériques d'akamai forment ainsi un réseau direct binodal entre les applications centralisées et les utilisateurs à la périphérie d'internet. En disposant de serveurs au plus près des utilisateurs, la latence et les pertes de paquets sont minimisées. Cela est essentiel à l'optimisation des goulots d'étranglement du kilomètre intermédiaire, à savoir le RTT et le multiplicateur RTT, dans la mesure où le routage et le débit TCP sont majoritairement régis par ces deux paramètres.
6 Architecture binodale Quand un utilisateur accède à une application web optimisée par Akamai, la requête du navigateur est traitée par son système de mapping dynamique qui dirige la requête vers un serveur périphérique proche, aussi appelé «ES-User». De par ses dizaines de milliers de serveurs distribués mondialement, l'implantation d'akamai rend possible une proximité des utilisateurs et offre une architecture permettant d'atteindre une performance optimale, car il est essentiel de se trouver au plus près des utilisateurs, sans avoir à être effectivement sur le client lui-même. De la même manière, un serveur périphérique d'origine optimal, «ES-Origin», est assigné au plus proche du serveur d'application du client. La requête d'application va d'es-user à ES-Origin, qui agit comme proxy du serveur d'application. ES-Origin confirme la session du navigateur puis le serveur transmet la requête au serveur d'application, en obtient la réponse qu'il transmet alors jusqu'en bout de chaîne. À ce stade, deux serveurs périphériques binodaux d'akamai, ES-User et ES-Origin, se sont interposés de manière transparente dans l'itinéraire entre le client et le serveur d'application, sans aucun changement au processus de transfert ou à l'infrastructure d'application. Au sein de cette architecture binodale, plusieurs technologies clés sont appliquées pour accélérer la diffusion, augmenter la disponibilité et améliorer la montée en charge des applications. SureRoute d'akamai - réduit le RTT SureRoute élimine les défauts d'efficacité du BGP SureRoute d'akamai est conçu pour résoudre les faiblesses du BGP en tirant profit d'algorithmes exclusifs et du réseau de serveurs périphériques d'akamai pour offrir une carte météo en temps réel de l'internet afin de faire des choix de routage axés sur les performances. À tout moment donné, pour chaque utilisateur indépendant, SureRoute détermine le chemin le plus disponible et le plus performant pour communiquer entre deux serveurs périphériques d'akamai. SureRoute est bénéfique sur deux aspects : SureRoute d'akamai offre une carte météo en temps réel de l'internet afin de faire des choix de routage axés sur les performances. Il optimise le RTT au lieu des décisions de routage du prochain bond prises par le BGP, le protocole au cœur du routage d'internet. Cela devient de plus en plus important pour les applications où le multiplicateur RTT est bas, comme c'est le cas dans les appels de service web, les applications AJAX et les applications en temps réel telles que la VoIP. Il optimise la disponibilité d'internet pour l'application en s'assurant que les requêtes d'utilisateurs atteignent le serveur d'application, et ce malgré les goulots d'étranglement d'internet tels que les pannes partielles et totales du fournisseur de service, le désappairage, les pannes réseau, les tremblements de terre, etc. Les décisions de routage optimisées sont mise à jour en temps réel avec SureRoute car l'état d'internet évolue constamment. Toutes les communications entre un réseau binodal de deux serveurs périphériques d'akamai se font via un chemin optimisé par SureRoute pour garantir un RTT optimal à chaque tour complet effectué sur Internet. Protocole Akamai - réduit l'effet multiplicateur du RTT Le protocole Akamai résout les faiblesses du TCP et du HTTP en tirant profit du réseau de serveurs périphériques d'akamai. Le protocole Akamai s'attaque aux goulots d'étranglement du kilomètre intermédiaire ayant un effet sur le multiplicateur de RTT, en éliminant les conversations au cœur des protocoles Internet et en les remplaçant par le protocole Akamai le plus efficace comme moyen de communication entre les serveurs périphériques d'origine et d'utilisateur. SureRoute s'assure que les requêtes d'utilisateurs atteignent le serveur d'application malgré les goulots d'étranglement d'internet. Le protocole Akamai élimine les faiblesses du TCP et du HTTP en tirant profit du réseau de serveurs périphériques d'akamai. Les requêtes arrivent à ES-User en trafic HTTP(S)/TCP normal et sont ensuite converties au protocole Akamai pour un long voyage via Internet jusqu'à ES-Origin. Toutes les communications de protocole Akamai entre les deux serveurs périphériques se font par un chemin SureRoute optimisé. Le trafic est converti de nouveau en HTTP(S)/TCP normal à son arrivée à ES-Origin.
7 Le protocole Akamai profite également du RTT réduit grâce à SureRoute dans la mesure où la latence et la perte de paquets régissent les débits de données maximaux associés au protocole. En résumé, ils offrent plus en travaillant ensemble que séparément. Le protocole Akamai élimine les faiblesses du TCP Pas de «poignée de main en trois temps» pour l'établissement et la destruction d'une connexion - ES-Origin établit une série de connexions de communication persistantes longue durée entre lui-même et les serveurs périphériques d'akamai. Ces connexions sont disponibles à la demande pour la gestion de plusieurs requêtes de navigateurs ou de machines. Pas de démarrage lent : les serveurs périphériques gardent un journal détaillé des conditions réseau telles que la bande passante et la latence. Grâce à cette vigilance, ils peuvent communiquer immédiatement avec une taille de fenêtre optimale, en évitant le mécanisme à démarrage lent du TCP, et changer dynamiquement selon les conditions réseau. Pipelining garanti : en tirant profit des connexions persistantes et des renseignements entre les serveurs périphériques et le centre de données du serveur d'origine, Akamai utilise le pipelining qui permet d'envoyer simultanément plusieurs requêtes HTTP en cascade via une seule connexion sans avoir à attendre de réponse. Retransmission intelligente : les serveurs périphériques conservent une quantité considérable d'informations telles que la latence entre les machines, la taille des fenêtres de transmission et les informations de mise en séquence des paquets, et offrent ainsi une méthodologie de retransmission plus intelligente que le paramètre d'expiration de délai du TCP. Le protocole Akamai élimine les défauts d'efficacité liés au HTTP Le HTTP, protocole au cœur de la navigation, amplifie les faiblesses du TCP en exigeant la création et la destruction de plusieurs connexions TCP pour l'affichage d'une page. Préchargement intelligent : la compression, la mise en cache et le préchargement intelligents aident à se débarrasser des faiblesses du HTTP. Quand ES-User envoie la requête de page modèle au navigateur, il analyse en même temps la page HTML de base de manière récursive, il prévoit les requêtes des objets intégrés ultérieurs et il délivre immédiatement les requêtes correspondantes au serveur d'origine. Tout le contenu est alors re-transféré en une unique transaction vers ES-User grâce au protocole exclusif Akamai. Quand le navigateur reçoit la page modèle et demande les éléments restants de la page, ils sont déjà chez ES-User prêts à être livrés, comme si le serveur d'origine ne se trouvait qu'à quelques millisecondes de distance. Compression : les données sont compressées en chemin, ce qui réduit l'utilisation de la bande passante. Mise en cache : tout contenu pouvant être mis en cache sera stocké chez ES-User, à proximité des utilisateurs, avant d'être offert à partir de ce cache. Le protocole Akamai élimine les «poignées de main en trois temps» et le démarrage lent. La compression, la mise en cache et le préchargement intelligents aident à se débarrasser des faiblesses du HTTP. Kilomètre intermédiaire sans Akamai Exemple de diffusion d'applications web - HTTP sur TCP/IP Le kilomètre intermédiaire avec Akamai Exemple de diffusion d'applications web - HTTP sur TCP/IP Centre de données (Atlanta) Utilisateurs répartis dans le monde entier (Sydney) Centre de données (Atlanta) Utilisateurs répartis dans le monde entier (Sydney) Internet ES-Origin Serveurs périphériques d'akamai ES-User 1 2 3 Premier kilomètre Durée de traitement de l'application et génération de contenu Kilomètre intermédiaire Round Trip Time (RTT) x nb d'allers-retours Dernier kilomètre Durée de transfert relative à la bande passante 0,25 secondes 7,75 secondes 0,20 secondes (31 x 250 ms) D'Atlanta à Sydney, il faut environ 31 allers-retours pour rendre une page web standard de 70 ko contenant 25 objets. Délai total de réponse = 8,20 sec.- 95 % du délai total de réponse est dû au kilomètre intermédiaire 1 2 3 Premier kilomètre Durée de traitement de l'application et génération de contenu Kilomètre intermédiaire Round Trip Time (RTT) x nb d'allers-retours Afficher la même page web ne demande plus que 5 allers-retours, en plus d'une réduction du RTT Délai total de réponse = 1,45 sec.- Akamai réduit les allers-retours au nombre de 5 Dernier kilomètre Durée de transfert relative à la bande passante 0,25 segundos 1,00 secondes 0,20 secondes (5 x 200 ms)
8 Délestage de l'infrastructure d'origine Les serveurs périphériques d'akamai offrent plusieurs techniques d'optimisation des performances du premier kilomètre pour délester les tâches du serveur d'application gourmandes en ressources et mieux assurer les performances d'application et la montée en charge : Gestion des connexions TCP : en délestant les connexions TCP/IP du client sur ES-Origin, les ressources de traitement du serveur d'origine peuvent être dédiées à l'offre de contenu. Les performances du serveur d'origine peuvent également être améliorées en créant de multiples connexions TCP/IP persistantes entre ES-Origin et le serveur d'application d'origine. Compression : les serveurs périphériques compressent et décompressent de manière dynamique des données qui profiteront de la compression tout en diminuant la charge requise pour les transférer via Internet. Les objets textuels tels que le HTML et le JavaScript sont hautement compressibles : ils permettent souvent un taux de compression de 90 %. Mise en cache : les serveurs périphériques peuvent être configurés pour mettre automatiquement en cache le contenu statique, comme les petits objets de page (ex. : les petits.gif,.doc et.jpg), les documents ou les ressources numériques telles que des fichiers multimédias ou logiciels. Ceci permet à la plate-forme Akamai de délester l'infrastructure d'origine et de réduire le délai de réponse de page en offrant le contenu pouvant être mis en cache au plus près de l'utilisateur. Akamai respecte les normes du secteur en termes d'heuristique et de contrôles de durée d'existence du cache. Montée en charge et performances d'application prouvées L'EdgePlatform distribuée d'akamai, la prévision d'itinéraire SureRoute en temps réel et le protocole Akamai de communication hautement performant travaillent ensemble comme un système pour améliorer les performances et la montée en charge d'applications dynamiques et de services web. En s'attaquant aux problèmes d'origine des protocoles d'internet, d'énormes gains de performances peuvent être atteints, quel que soit le type ou la classe d'application. Akamai améliore considérablement la montée en charge du serveur au sein du centre de données en s'attaquant aux goulots d'étranglement à l'extérieur du centre de données. Le contenu statique peut être délesté hors du centre de données par une mise en cache et par des installations de stockage en nuage dupliquées et persistantes. De plus, le délestage de contenu et le stockage en nuage réduit la bande passante nécessaire au support d'applications. En association avec le protocole Akamai, on obtient une réduction spectaculaire des hits du serveur, libérant ainsi de précieuses ressources du serveur tout en optimisant la puissance et l'espace d'hébergement au sein du centre de données. Les serveurs périphériques d'akamai délestent les tâches du serveur d'application gourmandes en ressources pour mieux assurer les performances d'application et la montée en charge. Akamai réduit de manière spectaculaire les hits du serveur, libérant ainsi de précieuses ressources du serveur tout en optimisant la puissance et l'espace d'hébergement au sein du centre de données. Secondes = Avec Akamai = Sans Akamai 1 : Amsterdam 2 : Atlanta 3 : Boston 4 : Chicago 5 : Genève 6 : Hong Kong 7 : Kansas City 8 : Londres 9 : Los Angeles 10 : Madrid 11 : Miami 12 : Milan 13 : Montréal 14 : Munich 15 : New York 16 : Paris 17 : Philadelphie 18 : San José 19 : Seattle 20 : Séoul 21 : Singapour 22 : Sydney 23 : Tokyo 24 : Vancouver 25 : Washington PERFORMANCES MONDIALES AVEC ET SANS AKAMAI
9 Sécurité dans le nuage Les menaces se faisant de plus en plus pressantes, Akamai vous permet d'éliminer les points d'entrée publics de votre infrastructure d'entreprise, les serveurs périphériques d'akamai recevant le premier hit à l'extérieur du centre de données. Akamai offre une protection à la périphérie, aux niveaux 3 à 7, en verrouillant un périmètre de sécurité et en gardant les attaques malveillantes à l'extérieur du centre de données. Pour y parvenir, Akamai utilise plusieurs technologies telles que la sécurité DNS, la protection DDoS de la couche IP, le contrôle d'accès à la couche IP par IP ou emplacement géographique et la dissimulation de l'origine. Alors que les pirates se sophistiquent, Akamai améliore sa protection de la périphérie au niveau de la couche d'application en proposant les fonctionnalités du Web Application Firewall où les serveurs périphériques d'akamai peuvent être configurés pour vérifier la requête au niveau de la couche 7 et s'assurer que seules les requêtes valides sont transférées jusqu'à l'origine. Impact commercial L'EdgePlatform d'akamai est une extension puissante pour toute infrastructure web d'entreprise, quelle qu'elle soit. Grâce à leur capacité d'optimisation de la diffusion d'applications dynamiques et de services web, les entreprises peuvent centraliser leurs infrastructures sans compromette les performances et la disponibilité de leur application, que leurs exigences de diffusion soient nationales ou mondiales. L'absence de modification des applications web, des serveurs ou des clients se traduit par un risque faible et une rentabilisation rapide. Akamai vous permet d'éliminer les points d'entrée publics de votre infrastructure d'entreprise en s'assurant que seules les requêtes valides sont transférées jusqu'à l'origine. L'EdgePlatform d'akamai permet aux entreprises de centraliser leur infrastructure sans compromettre les performances et la disponibilité de leur application. La plate-forme Akamai se montre à la hauteur de cinq exigences critiques en une unique plate-forme complète pour toutes les classes d'applications web : Des performances dignes d'un réseau local pour des utilisateurs mondiaux : les serveurs périphériques distribués dans le monde entier, SureRoute et le protocole Akamai travaillent ensemble pour offrir des délais de réponse dignes d'un réseau local à des utilisateurs mondiaux pour des applications dynamiques et des services web. Haute disponibilité : le contenu dynamique qui doit être récupéré depuis l'origine est protégé par la capacité de SureRoute à éviter en temps réel les goulots d'étranglement d'internet. Capacité prévisible : répond à la demande d'applications dynamiques et de services web qui peuvent résister, à n'importe quel moment, à des niveaux de pics de trafic des milliers de fois plus élevés que la normale. Sécurité d'entreprise : offre une diffusion accélérée et sécurisée d'applications SSL en s'intégrant de façon homogène aux systèmes et processus d'authentification existants tels que la prise en charge des certificats de client X.509 et la conformité PCI pour l'e-commerce. Coût total de propriété (TCO) minime : pas de frais cachés car le TCO équivaut au coût de l'abonnement mensuel. Aucune modification de l'application ni de l'infrastructure n'est requise, ce qui se traduit par une rentabilisation rapide et un risque faible. Dans un livre blanc récemment publié par IDC, «Détermination du retour sur investissement des Managed Services pour l'accélération des applications web», le bénéfice annuel moyen réalisé par une entreprise utilisant l'edgeplatform d'akamai pour une diffusion d'application d'entreprise en ligne était de 42 830 $ pour 100 utilisateurs de l'application. En se basant uniquement sur les avantages de réduction des coûts, la période de remboursement à compter du déploiement du service était de 1,8 mois en moyenne pour les entreprises interrogées, soit un retour sur investissement moyen de 582 %.
10 Résumé L'EdgePlatform d'akamai s'attaque à la source des goulots d'étranglement des performances et de la montée en charge d'internet en se plaçant intelligemment entre l'utilisateur et le centre de données d'origine comme un réseau dédié d'internet, le transformant ainsi en une plate-forme de diffusion d'applications fiable et hautement performante. Tout en offrant des techniques d'accélération de protocole uniques telles que SureRoute et le protocole Akamai pour s'attaquer aux goulots d'étranglement des performances du kilomètre intermédiaire, le réseau de diffusion d'applications d'akamai offre une plate-forme unique qui combine avec élégance de multiples technologies pour fournir, à des applications dynamiques et des services web, performance et montée en charge à la demande. Bien qu'un nombre croissant d'applications d'entreprises deviennent des applications en ligne, il existe d'autres applications, telles que les applications classiques client/serveur, les applications virtualisées et les applications sensibles en temps réel, qui ne conviennent pas à une interface web. De telles applications sont vulnérables, de la même manière, aux goulots d'étranglement du kilomètre intermédiaire. Les services d'accélération des applications IP d'akamai profitent de l'edgeplatform distribuée, des fonctionnalités de SureRoute et du protocole Akamai pour améliorer n'importe quelle application IP en exploitant des facteurs économiques, de montée en charge et d'accessibilité associés à l'utilisation d'internet comme plate-forme de diffusion d'applications. La différence Akamai Akamai propose des managed services à la pointe du marché dédiés à la diffusion de contenus de média riche, de transactions dynamiques et d'applications d'entreprise sur Internet. Ayant ouvert la voie du marché de la diffusion de contenu dix ans auparavant, les services Akamai ont été adoptés par les marques les plus célèbres du globe dans divers secteurs. Alternative à une infrastructure web centralisée, le réseau mondial d'akamai composé de dizaines de milliers de serveurs distribués offre la montée en charge, la fiabilité, les performances et la visibilité nécessaires à la réussite des commerces en ligne. Akamai conforte l Internet dans son rôle d information, de divertissement, d échange et de communication. Pour découvrir la différence Akamai, allez sur www.akamai.fr Akamai Technologies, Inc. Sede central en EE.UU. 8 Cambridge Center Cambridge, MA 02142 Tél. :617.444.3000 Fax : 617.444.3001 Numéro vert (USA) : 877.4AKAMAI (877.425.2624) www.akamai.fr Bureaux dans le monde Unterfoehring, Allemagne Paris, France Milan, Italie Londres, Angleterre Madrid, Espagne Stockholm, Suède Bangalore, Inde Sydney, Australie Pékin, Chine Tokyo, Japon Séoul, Corée Singapour 2009 Akamai Technologies Inc. Tous droits réservés. Toute reproduction complète ou partielle sous quelque forme ou support que ce soit sans autorisation écrite expresse est strictement interdite. Akamai et le logo en forme de vagues d Akamai sont des marques déposées. Les autres marques commerciales citées appartiennent à leurs propriétaires respectifs. À la connaissance d'akamai, les informations utilisées dans la présente publication sont exactes à la date de leur parution. Ces informations sont sujettes à modification sans préavis.