Sieci dostarczania tre�ci

Sieci dostarczania tre�ci, znane jako CDN, to du�e rozproszone sieci serwer�w, kt�re przyspieszaj� dostarczanie platformy do klient�w, zapewniaj� bezpiecze�stwo, przydzielaj� klient�w do centrum danych, je�li dzia�asz wi�cej ni� jeden, zapewniaj� d�awienie i wiele innych warto�ci dodaje. Ich rola w nowoczesnym handlu elektronicznym na du�� skal� jest wszechobecna i cz�sto konieczna. Najwi�kszy CDN na �wiecie ma 137 000 serwer�w w 87 krajach. Serwery nale��ce do CDN s� cz�sto kolokowane bezpo�rednio w centrach danych dostawc�w us�ug internetowych / szkieletowych i pod��czane bezpo�rednio do ich szybkich sieci. Mo�liwe, �e CDN ma serwery w ci�gu kilku milisekund od miejsca zamieszkania. Ze wzgl�du na blisko�� klient�w CDN-y s� cz�sto nazywane obliczaniem kraw�dzi. Cz�sto CDN s� ca�kowicie przejrzyste dla Twoich klient�w. Przyk�adem warto�ci oferty CDN jest przyspieszenie stron internetowych opartych na HTML. Rysunek pokazuje rozk�ad czasu potrzebnego do za�adowania strony g��wnej popularnej witryny e-commerce z siedzib� w USA dla anonimowego klienta. Oczekiwanie na odpowied� po stronie serwera stanowi zaledwie 2,4% ca�kowitego czasu wy�wietlania strony. Jest to bardzo reprezentatywne dla wi�kszo�ci stron internetowych e-commerce. Sieci CDN s� odpowiedzialne za dostarczenie pozosta�ych 97,6% w tym przyk�adzie. Sieci CDN mog� r�wnie� przyspieszy� dostarczanie odpowiedzi po stronie serwera, co om�wimy w dalszej cz�ci rozdzia�u. Sieci CDN odgrywaj� coraz wi�ksz� rol� podczas przechodzenia do chmury. Chocia� sieci CDN od dawna s� kojarzone z dostarczaniem stron internetowych (HTML, obrazy, CSS, JavaScript), ich rola znacznie si� rozwin�a do tego stopnia, �e s� teraz kluczowe dla dostarczania ca�ych platform. Przyjrzyjmy si� ich r�norodnym rolom i tym, jak mog� poprawi� wra�enia klient�w.

Co to jest CDN?

Sieci CDN po raz pierwszy zacz�to wykorzystywa� pod koniec lat 90. XX wieku do dostarczania tre�ci statycznych na du�� skal�. W tym czasie wi�kszo�� stron internetowych eCommerce pochodzi�a z wewn�trznych korporacyjnych centr�w danych nale��cych do dostawc�w eCommerce. Podawanie du�ej ilo�ci tre�ci statycznych wymaga ogromnej przepustowo�ci Internetu i specjalistycznej infrastruktury sieciowej, kt�ra by�a wyj�tkowo droga i skomplikowana. Efektem ubocznym dostarczania ca�ej tej zawarto�ci by�a poprawa wydajno�ci. Poprawiona wydajno�� prowadzi do wi�kszej satysfakcji klient�w, wy�szych wsp�czynnik�w konwersji i wi�kszej lojalno�ci wobec marki. Poniewa� wydajno�� sta�a si� wa�niejsza dla klient�w CDN, a zw�aszcza klient�w eCommerce, dostawcy CDN skupili si� na poprawie wydajno�ci. Przez pewien czas CDN by�y w zasadzie serwerami internetowymi obs�uguj�cymi tre�ci statyczne. Ich propozycj� warto�ci by�o zapewnienie dost�pno�ci i skalowania poprzez roz�adowanie zawarto�ci statycznej i dostarczenie jej z maszyn w pobli�u u�ytkownika ko�cowego. Z czasem dostawcy CDN rozwin�li swoj� ofert� w celu:

• Proxy HTTP ��da zwrotu z powrotem do twoich centr�w danych (zwanych pocz�tkiem), skutecznie usuwaj�c twoj� platform� z Internetu, najpierw zmuszaj�c wszystkie ��dania HTTP przez CDN.
• Zoptymalizowania dostarczania tre�ci dzi�ki zaawansowanym funkcjom, takim jak wst�pne pobieranie tre�ci, optymalizacja sieci, kompresja, zmiana rozmiaru obrazu, geolokalizacja i modyfikacja HTML stron w celu poprawy renderowania i wydajno�ci przegl�darki.
• Buforowania ca�e odpowiedzi (w tym strony HTML) na kraw�dzi, takie jak strona g��wna dla anonimowych klient�w.
• Wywo�ania API pami�ci podr�cznej na brzegu. Odpowiedzi to zazwyczaj XML lub JSON.
• Warto�� oferty stanowi dodatkow� zapor� sieciow�, ochron� przed rozproszonymi atakami typu "odmowa us�ugi" oraz pe�ne rozwi�zanie Global Server Load Balance.
• Zmniejszenia zu�ycia procesora, multipleksuj�c po��czenia HTTP i utrzymuj�c po��czenia przy �yciu przez d�u�szy czas.

Pochodzenie jest terminem u�ywanym przez dostawc�w Content Delivery Network odnosz� si� do centr�w danych, kt�re faktycznie generuj� tre�ci, kt�re sie� dostarczania tre�ci s�u�y. Zazwyczaj oznacza to centra danych, w kt�rych masz serwery aplikacji.

Czy CDN s� chmurami?

CDN s� chmurami, aczkolwiek mniejsz� form� chmur. Aby uzna� si� za cz�� chmury, ofert� nale�y opisa� za pomoc� nast�puj�cych trzech przymiotnik�w:

• Elastyczna
• Na ��danie

Sieci CDN zawsze spe�niaj� pierwszy i drugi wym�g, ale nie zawsze trzeci. Niekt�rzy dostawcy zezwalaj� na korzystanie z ich us�ug tylko na podstawie um�w na rok lub d�u�ej. Sta�e umowy d�ugoterminowe s� powszechnymi sposobami p�acenia dostawcom CDN i dlatego technicznie nie mog� by� uwa�ane za przetwarzanie w chmurze. Pragmatyzm powinien rz�dzi� podejmowaniem decyzji. Wybierz najlepszego dostawc�, niezale�nie od tego, jak Ci� rozliczaj�. Poniewa� ich podstawowa dzia�alno�� jest obecnie do�� dojrza�a, sieci CDN przenosz� si� w przestrze� tradycyjnie nale��c� do dostawc�w chmury. Dostawcy us�ug w chmurze r�wnie� przenosz� si� do przestrzeni CDN, staraj�c si� oferowa� swoim klientom w pe�ni zintegrowane rozwi�zania pionowo i zwi�kszy� sw�j udzia� w wydatkach na technologie klient�w. Wszyscy dostawcy technologii staraj� si� zapewni� swoim klientom kompleksowe, zintegrowane pionowo rozwi�zania, w przeciwie�stwie do produkt�w / us�ug punktowych. Rzeczywista r�nica mi�dzy sieciami CDN a dostawcami infrastruktury jako us�ugi polega na tym, �e sieci CDN wci�� nie pochodz� z tre�ci, kt�re obs�uguj�. Po prostu przyspieszaj� dostarczanie tre�ci pochodz�cych z innych �r�de�. Dostawcy infrastruktury jako us�ugi pochodz� z tre�ci i mog� w pewnym stopniu przyspieszy� ich dostarczanie. Chocia� nak�adaj� si� na siebie, oba nadal robi� zasadniczo r�ne rzeczy.

Udost�pnianie tre�ci statycznych

Pierwsza i pierwotna propozycja warto�ci CDN polega na tym, �e prawie ca�kowicie eliminuj� one op�nienia. Kiedy podci�gasz swoj� ulubion� witryn� e-commerce, wysy�asz pojedyncze ��danie HTTP na http://www.walgreens.com. W odpowiedzi na Twoj� pro�b� otrzymasz plik HTML o rozmiarze prawdopodobnie poni�ej 100 kilobajt�w. Gdyby tak by�o, nie potrzebowa�by� CDN. �rednie op�nienie mi�dzy Tokio a Londynem wynosi zaledwie 242 milisekundy. Op�nienie to mo�e by� tolerowane dla jednego ��dania HTTP. Przegl�darki internetowe musz� wysy�a� setki ��da� HTTP. Gdy Twoja przegl�darka internetowa odzyska kod HTML z pochodzenia, przeanalizuje go, aby dowiedzie� si�, jak� inn� zawarto�� musi pobra�, aby strona by�a renderowana:

< script type = "text / javascript" src = '/ gomez-tag.js' > < /script >
< script type = "text / javascript" src = 'http: //img.website.com/scripts/mbox.js' >
< /script >
< link rel = "ikona skr�tu" type = "image / x-icon" href = "/ favicon.ico" / >
< script type = "text / javascript" src = "http://www.website.com/scripts/common.js" >
< /script >
< script type = "text / javascript" src = "http://img.website.com/scripts/menu.js" >
< /script >

Ka�da z tych opcji wymaga ��dania HTTP, przynajmniej do momentu lokalnego buforowania obiektu w przegl�darce internetowej klienta. Liczba ��da� HTTP mo�e wynosi� od kilkudziesi�ciu do kilkuset.

Udost�pnianie tre�ci statycznych

Pierwsza i pierwotna propozycja warto�ci CDN polega na tym, �e prawie ca�kowicie eliminuj� one op�nienia. Kiedy podci�gasz swoj� ulubion� witryn� e-commerce, wysy�asz pojedyncze ��danie HTTP na http://www.walgreens.com. W odpowiedzi na Twoj� pro�b� otrzymasz plik HTML o rozmiarze prawdopodobnie poni�ej 100 kilobajt�w. Gdyby tak by�o, nie potrzebowa�by� CDN. �rednie op�nienie mi�dzy Tokio a Londynem wynosi zaledwie 242 milisekundy. Op�nienie to mo�e by� tolerowane dla jednego ��dania HTTP. Przegl�darki internetowe musz� wysy�a� setki ��da� HTTP. Gdy Twoja przegl�darka internetowa odzyska kod HTML z pochodzenia, przeanalizuje go, aby dowiedzie� si�, jak� inn� zawarto�� musi pobra�, aby strona by�a renderowana:

< script type = "text / javascript" src = '/ gomez-tag.js'> < /script >
< script type = "text / javascript" src = 'http: //img.website.com/scripts/mbox.js' >
< /script >
< link rel = "ikona skr�tu" type = "image / x-icon" href = "/ favicon.ico" / >
< script type = "text / javascript" src = "http://www.website.com/scripts/common.js" >
< /script >
< script type = "text / javascript" src = "http://img.website.com/scripts/menu.js" >
< /script >

Ka�da z tych opcji wymaga ��dania HTTP, przynajmniej do momentu lokalnego buforowania obiektu w przegl�darce internetowej klienta. Liczba ��da� HTTP mo�e wynosi� od kilkudziesi�ciu do kilkuset. Problem z �adowaniem wszystkich tych obiekt�w w ci�gu kilku sekund polega na tym, �e przegl�darki internetowe �aduj� obiekty w seriach oko�o 10 ��da� HTTP. Sytuacja staje si� jeszcze gorsza w przypadku witryn, kt�re s� udost�pniane odbiorcom w sieciach o du�ych op�nieniach, takich jak te, kt�re nie znajduj� si� fizycznie blisko �r�d�a, sieci kom�rkowe itp. Nie obejmuje to czasu potrzebnego na wygenerowanie odpowiedzi przez �r�d�o. Wygenerowanie odpowiedzi HTTP dla strony dynamicznej mo�e potrwa� sekund� lub d�u�ej. a zasada pozwala na obs�ug� stron internetowych z jednego centrum danych do globalnej publiczno�ci. Zak�adaj�c, �e tych samych 15 podr�y w obie strony z powrotem do centrum danych pochodzenia w celu renderowania strony, strona internetowa obs�ugiwana z Londynu do Tokio z 260 milisekundami op�nienia spowodowa�aby narzut 3,9 sekundy z powodu op�nienia. Po uwzgl�dnieniu czasu potrzebnego do renderowania HTML, podania tre�ci statycznej i tak dalej, nale�y oczekiwa� czasu reakcji ponad 6 sekund. Opr�cz znacznego zmniejszenia op�nie� zawarto�� statyczna jest pobierana szybciej, poniewa� pakiety musz� przeby� kr�tsz� odleg�o�� przez mniejsz� liczb� przeskok�w sieciowych. Przy przeci�tnych stronach g��wnych zbli�aj�cych si� do 2 MB klienci bardzo musz� pobiera� du�o danych szybko. Korzy�ci biznesowe tego s� oczywiste: wi�ksze, bardziej interaktywne strony mog� by� dostarczane z mniejszym op�nieniem, ni� gdyby� nie korzysta� z CDN.

Udost�pnianie tre�ci dynamicznych

Technologia s�u��ca do dostarczania tre�ci statycznych jest do�� prosta. Sieci CDN buduj� dziesi�tki, a nawet setki centr�w danych i podaj� statyczne tre�ci z serwer�w internetowych w swoich centrach danych we w�asnej domenie (np. Http://www.website.com/images) lub twojej subdomeny (np. Http: //images.website.com). Kiedy� obrazy musia�y by� podawane ze strony http://customer.cdn-vendor.com. Tre�ci s� przyspieszane przede wszystkim dlatego, �e s� tak blisko klient�w. Aby wyj�� poza statyczne dostarczanie tre�ci, CDN mo�e dzia�a� jako serwer proxy przed ca�� witryn�. To podej�cie wymaga, aby rekord DNS wskazywa� na dostawc� CDN i aby ca�y ruch przechodzi� przez CDN. Przy takim podej�ciu rekord DNS faktycznie wskazuje na dostawc� CDN. ��dania dotycz�ce http://www.website.com przechodz� przez CDN. Korzy�ci z tego s� ogromne dla wydajno�ci i bezpiecze�stwa. Przyjrzyjmy si� r�nym funkcjom w��czonym w poni�szych sekcjach.

Buforowanie ca�ych stron

Zdecydowana wi�kszo�� da� HTTP dotyczy tre�ci statycznych. Spo�r�d przeci�tnych 151 ��da� HTTP zwi�zanych z renderowaniem strony po raz pierwszy, pierwsze ��danie HTTP dotyczy kodu HTML strony. Dop�ki przegl�darka internetowa nie za�aduje i nie przeanalizuje kodu HTML, �adne z pozosta�ych 150 kolejnych ��da� HTTP nie zostanie wykonane. Innymi s�owy, znajduje si� na �cie�ce krytycznej. ��dania HTML nie zawsze musz� by� przekazywane z powrotem do �r�d�a, poniewa� przez wi�kszo�� czasu HTML jest zawsze taki sam dla danego zestawu parametr�w wej�ciowych. Na przyk�ad ��dania HTTP wysy�ane przez anonimowych klient�w dla strony g��wnej (np. Http://www.website.com) prawdopodobnie zwr�c� ten sam kod HTML, chyba �e zastosujesz zaawansowane kierowanie na podstawie po�o�enia geograficznego u�ytkownika. Zdecydowana wi�kszo�� ruchu na platformie e-commerce jest buforowana ze wzgl�du na tak zwany lejek ruchu e-commerce. Nie obejmuje to nawet ruchu z nieludzkich bot�w, kt�re stanowi� obecnie 61% ��da� HTTP. Wszystkie odpowiedzi na boty mog� by� obs�ugiwane bezpo�rednio z CDN. Pozosta�e ��dania HTTP przedstawione na tej �cie�ce pochodz� od anonimowych klient�w strony g��wnej, stron kategorii, stron produkt�w i tak dalej. Ponownie wi�kszo�� tych stron mo�e by� obs�ugiwana r�wnie� z CDN. Tylko stosunkowo niewielka cz�� ca�kowitego ruchu pochodzi od rzeczywistych klient�w, kt�rzy s� faktycznie zalogowani. Jeszcze mniejszy odsetek klient�w faktycznie kupuje cokolwiek. Wielu klient�w odwiedza witryny z trwa�ymi plikami cookie do logowania. Strony internetowe witaj� klient�w, m�wi�c: "Witaj ponownie, [Imi�]!" Lub co� podobnego. Je�li personalizacja nie jest zbyt znacz�ca, mo�esz po prostu zapisa� w pami�ci podr�cznej ca�� stron� HTML w sieci CDN, ale wywo�a� wywo�anie zwrotne AJAX do miejsca pochodzenia, aby zape�ni� j� dynamiczn� tre�ci�, na przyk�ad nazw� klienta. Pod wzgl�dem kodu wygl�da�oby to mniej wi�cej tak:

< head >
< script src = "/ app / jquery / jquery.min.js" > < /script >
< script >
$ .ajax ({url: "/ app / RetrieveWelcomeMessage", sukces: funkcja (wynik) {
// odzyskuje "Welcome Back, Kelly!"
$ ("# WelcomeMessage"). Html (wynik);
}});
< /script >
< /head >
< body >
< h2 > < div id = "WelcomeMessage" > Zaloguj si� < /div >
... reszta strony internetowej
< /body >

Mo�esz to powt�rzy� dla innych dynamicznych obszar�w na swojej stronie internetowej, takich jak sekcja "Mo�esz polubi�" lub g��wny obraz na stronie g��wnej. Mo�esz tak�e wykona� tylko jedno wywo�anie zwrotne do swojego �r�d�a, z pojedyncz� odpowiedzi� JSON lub XML zawieraj�c� wszystkie dane wymagane do prawid�owej personalizacji strony. Zalet� tego podej�cia jest to, �e usuwa �adowanie pierwszej strony HTML ze �cie�ki krytycznej (poniewa� ��dania AJAX s� asynchroniczne), ale nadal mo�na stosowa� ograniczon� personalizacj�. Klienci uzyskuj� wysok� wydajno��, a twoje pochodzenie jest ledwo dotkni�te. To �wietne podej�cie, kt�re zosta�o om�wione dalej w cz�ci 11. Niewielk� r�nic� jest buforowanie r�nych wersji ka�dej strony w CDN. Sieci CDN s� w stanie g��biej przyjrze� si� ��daniu HTTP w polach, takich jak �r�d�owy adres IP, agent u�ytkownika, parametry adresu URL i pliki cookie. Informacje te mog� by� nast�pnie wykorzystane przez CDN do odkrycia takich fakt�w:

• Czy klient jest zalogowany
• Przegl�darka internetowa / agent u�ytkownika
• Fizyczna lokalizacja (czasami dok�adna do zip + 4 w USA lub kod pocztowy poza USA)
• Szybko�� po��czenia internetowego
• Ustawienia regionalne
• System operacyjny
• Wymiary ekranu
• Obs�uga Flash
• Mo�liwo�ci obs�ugiwane przez ka�de urz�dzenie

Je�li masz odmiany stron oparte na tych atrybutach, mo�esz po prostu zapisa� ka�d� odmian� w sieci CDN i poprosi� o pobranie odpowiedniej wersji strony dla ka�dego klienta. Na przyk�ad sprzedawca prowadz�cy sprzeda� mi�dzynarodow� online mo�e mie� wersje ka�dej strony g��wnej dla danego kraju, przy czym ka�da lokalizacja ma swoj� w�asn� kopi�. Pozwoli�oby to zaoszcz�dzi� dziesi�tki, je�li nie setki milisekund w kr�tkim czasie, jednocze�nie pozwalaj�c, aby strony by�y ci�sze i bardziej dynamiczne. Mo�na teraz buforowa� nawet wiele stron wynik�w wyszukiwania. W przypadku du�ych platform eCommerce 20% wyszukiwanych hase� stanowi 80% ruchu. Tak d�ugo, jak mo�esz wyci�gn�� parametry wyszukiwania i umie�ci� je w adresie URL, mo�esz buforowa� strony. Strony wynik�w wyszukiwania wymagaj� adres�w URL takich jak search.jsp? Query = shirt & size = xl & onsale = true. Ta sztuczka mo�e spowodowa�, �e jeszcze wi�cej Twojej platformy b�dzie obs�ugiwanych bezpo�rednio z CDN.

Wcze�niejsze pobieranie zawarto�ci statycznej

Niekt�rych stron nie mo�na buforowa� statycznie. Na przyk�ad strony realizacji transakcji s� z natury dynamiczne i nie mo�na ich �atwo buforowa�. W przypadku u�ycia jako odwrotnego serwera proxy sieci CDN mog� przyspieszy� dostarczanie zawarto�ci statycznej dla wszystkich stron. Oko�o 150 ze �rednio 151 ��da� HTTP dotycz�cych pocz�tkowego za�adowania strony dotyczy zawarto�ci statycznej. Poniewa� odpowied� HTTP przechodzi z powrotem przez CDN po powrocie do klient�w, CDN mo�e analizowa� HTML i proaktywnie wysy�a� wsp�bie�ne ��dania HTTP do �r�d�a dla tre�ci statycznej, kt�rej jeszcze nie ma. Sieci CDN maj� dziesi�tki, a nawet setki centr�w danych, a ka�de centrum danych og�lnie utrzymuje w�asn� autonomiczn� pami�� podr�czn�. CDN mo�e wysy�a� wszystkie ��dania HTTP jednocze�nie w b�yskawicznie szybkiej sieci, podczas gdy twoja przegl�darka musi wysy�a� ��dania HTTP w partiach po 10 w wolnej sieci "ostatniej mili", zanim dotrze nawet do zoptymalizowanej sieci CDN. Pobieranie wst�pne jest rozs�dne w u�yciu i mo�e przynie�� znaczne korzy�ci.

Bezpiecze�stwo

Sieci CDN s� w stanie zapewni� wyj�tkowe bezpiecze�stwo, po prostu usuwaj�c swoje pierwotne centra danych z Internetu. Aby dotrze� do swojego pochodzenia, wszyscy musz� najpierw przej�� przez CDN. Ju� samo to zapewnia ogromn� warto�� poprzez zmniejszenie profilu ataku. G��boka obrona lub zwi�kszenie bezpiecze�stwa warstw jest doskona�� obron� przed atakami. Sieci CDN maj� kilka sztuczek, kt�re mog� zastosowa�, aby zapewni� Ci bezpiecze�stwo. Rozproszone ataki typu "odmowa us�ugi", w ramach kt�rych osoby atakuj�ce zalewaj� twoje pochodzenie ruchem pr�buj�c wyeliminowa� ci� z po��czenia z sieci�, stanowi� du�y problem. Opr�cz specjalnych technik zapobiegania rozproszonym atakom typu "odmowa us�ugi" i zatrzymywania ich, sieci CDN maj� wiele tysi�cy fizycznych serwer�w w dziesi�tkach, a nawet setkach centr�w danych, kt�re mog� wch�on�� ruch z ataku. Na przyk�ad mo�e to by� pomocne dla ameryka�skich dostawc�w eCommerce, poniewa� wiele atak�w pochodzi z Azji. Serwery CDN w Azji poch�aniaj� ruch po ataku, pozostawiaj�c serwery i pochodzenie z USA, aby nadal obs�ugiwa� ruch do Stan�w Zjednoczonych i innych klient�w na ca�ym �wiecie w normalny spos�b. Ponadto ataki maj� tendencj� do atakowania jednej strony internetowej na raz, pozostawiaj�c nadwy�k� pojemno�ci w sieci CDN dost�pnej, aby poradzi� sobie z ruchem z ataku. CloudFlare s�ynie z szybko�ci przesy�ania 118 gigabajt�w danych na sekund�, 4 pomimo tego, �e jest do�� ma�ym CDN w stosunku do swoich konkurent�w. Wi�kszo�� platform e-commerce ma jak�� form� rozproszonego ograniczenia atak�w typu "odmowa us�ugi", czy to od dedykowanego dostawcy oprogramowania jako us�ugi, czy CDN. W dzisiejszych czasach wyj�tkowo rzadko osoby atakuj�ce mog� uzyska� dost�p do systemu operacyjnego jako root. Korzystanie z sieci CDN i innych po�rednik�w, w po��czeniu z silnymi zaporami ogniowymi, w du�ej mierze zapobieg�o tym atakom. Ataki takie jak wstrzykni�cie SQL (zmuszanie bazy danych do wykonania w�asnego arbitralnego SQL), wykonywanie skrypt�w mi�dzy witrynami (co pozwala na kradzie� sesji i zwi�zanych z nimi uprawnie�) oraz wstrzykiwanie kodu (wykonywanie w�asnego dowolnego kodu) s� znacznie bardziej prawdopodobne. Na przyk�ad wstrzykiwanie SQL jest cz�st� luk�:

< %
String userId = request.getParameter("userId");
String query = "SELECT * FROM user where userId=" + userId + "'";
Statement st = conn.createStatement();
ResultSet res = st.executeQuery(query);
% >

Ustawienie userId na 12345 lub 1 = 1 przez wykonanie adresu URL i productId = 12345 '% 20 lub% 20'1% 3D1 spowoduje, �e aplikacja wydrukuje szczeg�y ka�dego u�ytkownika w bazie danych bez jawnego nara�enia jakiegokolwiek systemu. Wiele sieci CDN ma pe�ne zapory ogniowe aplikacji internetowych do sprawdzania kodu HTML i oceny dla s�abych punkt�w. Na przyk�ad jakikolwiek parametr o warto�ci select% 20 *% 20 z% 20credit_card (wybierz * z karty kredytowej) nigdy nie powinien by� dopuszczony do powrotu do aplikacji. Gdy prowadzisz wielkoskalow� platform� e-commerce, przekonasz si�, �e niekt�re boty mog� sia� spustoszenie, ��daj�c zbyt wielu stron zbyt szybko. Poniewa� wi�kszo�� bot�w nie rozumie sesji HTTP, ostatecznie utworz� now� sesj� HTTP dla ka�dego wy�wietlenia strony. Wi�kszo�� sieci CDN pozwala na umieszczenie na czarnej li�cie wed�ug adresu IP, agenta u�ytkownika, podsieci itp. Wiele sieci CDN oferuje r�wnie� pe�n� zgodno�� z powszechnymi ramami bezpiecze�stwa, takimi jak FedRAMP, 5 PCI DSS, 6 HIPAA, 7 i ISO.8. Zgodno�� z tymi ramami pomaga wykaza�, �e tym dostawcom mo�na zaufa� w przypadku najbardziej wra�liwych danych.

Dodatkowe oferty CDN

Opr�cz wydajno�ci i bezpiecze�stwa sieci CDN oferuj� wiele us�ug pomocniczych, takich jak DNS i pami�� masowa. Sieci CDN s� strategicznie rozmieszczone dzi�ki du�ej powierzchni serwer�w na ca�ym �wiecie pod��czonych bezpo�rednio do sieci szkieletowych. Z tego punktu widokowego �atwo jest zepchn�� inne dodatki na kraw�d�, korzystaj�c ze znacznej infrastruktury mie� na miejscu

Optymalizacja interfejsu u�ytkownika

Kod frontendowy wi�kszo�ci witryn e-commerce jest bardzo �le napisany. Poszczeg�lni programi�ci pracuj� nad w�asnymi ma�ymi fragmentami strony, cz�sto nikt nie patrzy na du�y obraz. Kiedy kto� dba o wydajno��, zwykle jest ju� za p�no, aby wr�ci� i naprawi� problemy. Wiele sieci CDN oferuje teraz przepisywanie HTML, dzi�ki czemu b�d� dynamicznie przepisywa� HTML na brzegu dla ka�dego konkretnego klienta na podstawie czynnik�w takich jak typ urz�dzenia, rozdzielczo��, przegl�darka internetowa i szybko�� po��czenia. Optymalizacje mog� obejmowa�:

• Zmniejszenie liczby ��da� HTTP poprzez po��czenie CSS i JavaScript oraz wstawianie
• Przekazywanie cz�sto odwo�ywanych element�w statycznych do przegl�darki internetowej, zanim ��danie HTTP zostanie wys�ane do CDN
• Dokonywanie optymalizacji specyficznych dla przegl�darki
• Odroczenie wczytywania zewn�trznych sygna��w JavaScript (np. Analityki i reklam) do momentu pe�nego wyrenderowania strony
• Korzystanie z �adowania obraz�w na ��danie lub na ��danie, kt�re �aduje obrazy podczas przewijania klienta
• Pobieranie obraz�w z wielu poddomen, aby umo�liwi� przegl�darce r�wnoleg�e pobieranie wi�kszej liczby plik�w
• Wst�pne pobieranie DNS
• Zmniejszenie bia�ych znak�w
• Zmiana rozmiaru zdj��
• Korzystanie z kompresji
• Przepisywanie kodu HTML w celu wykorzystania funkcji specyficznych dla przegl�darki

Je�li nie mo�esz samodzielnie przeprowadzi� tych optymalizacji, zdecydowanie zalecamy skorzystanie z tych us�ug.

DNS / GSLB

DNS to obszar, w kt�ry CDN zainwestowa�y znaczne kwoty, zar�wno w standardowy hosting DNS, jak i bardziej zaawansowany Global Server Load Balancing (GSLB). Om�wimy DNS i GSLB obszernie w rozdziale 10. DNS jest czym�, czego �aden sprzedawca e-commerce nie powinien sam hostowa�. Wady hostingu obejmuj�:

• Koszt prawid�owej budowy i utrzymania DNS
• Wyzwanie zwi�zane z wdra�aniem systemu DNS w wielu centrach danych lub wielu sieciach
• Obawy dotycz�ce bezpiecze�stwa

-DNS jest cz�sto celem exploit�w.
-NDNS mo�na ograniczy� za pomoc� rozproszonych atak�w typu "odmowa us�ugi".
-SDNS mo�na oszuka�, aby zala� ofiar� rozproszonego ataku typu "odmowa us�ugi".

• Wyst�puje op�nienie, a klienci kwerenduj� serwery DNS

W�a�ciwie hostowane rozwi�zania DNS, czy to w sieci CDN, czy nie, s� w stanie pokona� te wyzwania przede wszystkim dzi�ki swojej zdolno�ci do koncentracji. Dostawcy, kt�rzy sprzedaj� t� us�ug�, mog� zatrudni� najlepszych ekspert�w na �wiecie, korzysta� z najlepszych technologii i stosowa� najlepsze techniki bezpiecze�stwa. Koszt kra�cowy nowego konsumenta jego us�ugi jest bardzo niski, co pozwala mu zarabia�, oszcz�dzaj�c pieni�dze. Sieci CDN oferuj� mo�liwo�� odpowiadania na zapytania DNS od brzegu, prawdopodobnie zaledwie kilka milisekund od ka�dego klienta.

W przypadku tradycyjnego systemu DNS mo�e by� konieczne wybranie si� do innego kraju lub nawet do kraju, aby uzyska� adres IP. DNS jest o wiele bardziej skomplikowany, ale jak wida�, obs�uga DNS od brzegu ma zalety. Opr�cz mapowania nazw domen z powrotem na adresy IP, DNS mo�e by� r�wnie� u�ywany do przypisywania klient�w do centr�w danych. Ka�de centrum danych, z kt�rego prowadzisz platform� e-commerce, og�lnie przedstawia �wiatu jeden adres IP. Je�li brakuje Ci wielu centr�w danych, potrzebujesz sposobu na okre�lenie, do kt�rego centrum danych powinien zosta� przypisany ka�dy klient. Nazywa si� to globalnym r�wnowa�eniem obci��enia serwera (GSLB) i skutecznie usprawnia DNS. GSLB dzia�a poprzez ci�g�e przekierowywanie klient�w do w�a�ciwego centrum danych przez kombinacj� czynnik�w, w tym dost�pno��, pojemno�� / wykorzystanie centrum danych, arbitralne wagi i wydajno�� w czasie rzeczywistym. Sieci CDN maj� do�� wyj�tkow� przewag� nad tradycyjnymi dostawcami hostingu DNS, poniewa� s� w stanie dok�adnie odwzorowa� wydajno�� Internetu w czasie rzeczywistym i poniewa� maj� tak wiele serwer�w pod��czonych do tak wielu r�nych sieci na ca�ym �wiecie. To jest cz�sto przypadek, w kt�rym najszybsza trasa mi�dzy dowolnymi dwoma punktami nie jest najkr�tsza. Wydajno�� sieci, szybko��, przeci��enie, przeskoki i ingerencja ze strony rz�d�w odgrywaj� rol� w zmniejszaniu przepustowo�ci sieci i op�nie�. Kolejn� zalet� sieci CDN jest to, �e mog� monitorowa� faktyczny czas, w kt�rym ka�de centrum danych odpowiada na ��dania HTTP, poniewa� cz�sto s�u�� one jako serwery proxy.

D�awienie

Przed chmur� ka�da platforma mia�a sta�� pojemno��, kt�r� mog�a obs�u�y� bez zerwania. Na przyk�ad, je�li wdro�y�e� 500 serwer�w, a ka�dy serwer ma 10 000 jednoczesnych klient�w, wiesz, �e nie mo�esz obs�u�y� wi�cej ni� 5 000 000 jednoczesnych klient�w. Nie by�o sensu pozwala� nikomu na dost�p do Twojego pochodzenia, je�li wiesz, �e to nie zadzia�a. Sieci CDN oferuj� mo�liwo�� d�awienia, dzi�ki czemu 5000 000 klient�w zostanie skierowanych do wirtualnej poczekalni. Te poczekalnie oferuj� przynajmniej pomocne wiadomo�ci o sytuacji, w tym szacunkowe dane, kiedy strona b�dzie ponownie dost�pna. Poczekalnie mog� r�wnie� zawiera� gry lub nawet pe�ne katalogi, aby klienci mogli zacz�� zakupy, a nast�pnie zako�czy� po ponownym uruchomieniu witryny. Zastosowanie ograniczania przepustowo�ci chroni twoje pochodzenie przed nadmiernym wykorzystaniem, jednocze�nie utrzymuj�c zadowolenie klient�w, ni� gdyby po prostu otrzymali komunikat o b��dzie. Tradycyjne urz�dzenia r�wnowa��ce obci��enie r�wnie� oferuj� d�awienie, ale istniej� dwie wady.
Pierwsz� jest to, �e same modu�y r�wnowa�enia obci��enia mog� zosta� przyt�oczone. Jak ka�dy uk�ad fizyczny, maj� swoje granice. Jest r�wnie� pod��czony do sieci i innej infrastruktury fizycznej, kt�ra sama mo�e zosta� przyt�oczona. Drug� wad� jest to, �e tradycyjne modu�y r�wnowa��ce obci��enie musz� kierowa� ruch przepe�nienia do strony poczekalni. Je�li ta strona znajduje si� w tym samym centrum danych, kt�re jest przyt�oczone, istnieje du�a szansa, �e sama poczekalnia nie b�dzie dzia�a�. Same sieci CDN mog� wy�wietla� tre�ci bezpo�rednio z brzegu, niezale�nie od tego, co dzieje si� w centrum danych. Mo�e istnie� oprogramowanie, kt�re nie mo�e skalowa� si� do okre�lonego punktu lub oprogramowanie, kt�rego nie mo�na wdro�y� w chmurze, a zatem ma za sob� sta�� pojemno�� sprz�tu. �adna platforma nie skaluje si� w niesko�czono��. Z tych powod�w, nawet przy elastyczno�ci, jak� przynosi chmura, zaleca si� d�awienie.

e-Commerce w ChmurzeHandel

Sieci dostarczania tre�ci