Instytut Telekomunikacji PW Wybrane zagadnienia przyszłego Internetu Sieci dostarczania treści stan i kierunki rozwoju Materiały wykładowe do użytku wewnętrznego CDN 1
Współczesna rola Internetu (czyli zamiast agendy) Rozpowszechnianie i obrabianie informacji jaki obecnie jest charakter ruchu (popularność różnych informacji) jak jest to wykorzystywane jakie są możliwe drogi rozwoju Global FIXED traffic (ExaByte/month) Global MOBILE traffic (ExaByte/month) 100 2.5 80 Residential Unicast TV 2.0 Handheld data traffic 60 Residential Internet 1.5 Laptop Data Traffic 40 20 Voice Traffic Business Internet 1.0 0.5 Voice Traffic 0 2007 2008 2009 2010 2011 2012 2013 2014 2015 Fixed broadband traffic is 40x mobile in 2015 0.0 2007 2008 2009 2010 2011 2012 2013 2014 2015 Mobile data traffic grows 300 fold źródło: MEVICO / Nokia CDN 2
Charakter ruchu Obiekty diametralnie różnią się częstością wywołań, np. 1% najpopularniejszych obiektów odpowiada 20%-35% żądań 10% najpopularniejszych obiektów odpowiada 45%-55% żądań Rozkład Zipf a jako model opisu rozkładu popularności treści f(k, s) ~ 1 / k s częstość wystąpienia żądania k miejsce obiektu w rankingu (1, 2, 3, ) s stała rozkładu (przyjmuje wartości w okolicach 1) (rodzina rozkładów potęgowych, np. Zipf, Pareto) skala log-log populacja miast popularność kontentu idealny Zipf CDN 3
Zakres Schowkowanie treści (caching) Od prostego do kooperatywnego Sieci CDN (Content Delivery Network) Terminologia, ekosystem Architektura funkcjonalna Przykładowe scenariusze działania Przyszłość dystrybucji treści - sieci informacyjne (ICN) Zasady Główne podejścia CDN 4
Schowkowanie treści - wprowadzenie
Schowkowanie treści - wprowadzenie Idea: pobranie treści ze źródła bliższego niż serwer dostawcy oszczędność zasobów sieciowych (zwykle zauważalne) krótsze czasy dostępu do treści (nie zawsze kluczowe) Schowkowanie w przeglądarce przeglądarka cache żądanie odpowiedź Serwer WWW możliwa współpraca między klientem i serwerem (modele push, pull) Schowkowanie w proxy Kooperatywne schowkowanie Sieci CDN CDN 6
Schowkowanie w proxy Schowkowanie w proxy (często ang. transparent caching) przeglądarka żąd. odp. Web proxy cache żąd. odp. Serwer WWW przeglądarka proxy zwykle instalowany na brzegu sieci przez ISP przechwytuje zapytania (kończy sesje TCP) może serwować obiekt ze schowka, może zapamiętać nowy możliwa współpraca proxy z serwerem Push-based: serwer inicjuje odświeżanie (HTTP Update, Invalidate) (w tym przypadku mniej transparent ) strategia odświeżania: update dla popularnych, invalidate dla reszty zalety: aktualne dane, bezstanowe proxy wady: stan w sewerze (lista proxy) wrażliwość na awarie serwera z uwagi na wady w praktyce właściwie nie stosowane CDN 7
Schowkowanie Pull-based w proxy cd. proxy GET response Web server proxy całkowicie odpowiada za spójność danych proxy okresowo odpytuje serwer w celu sprawdzenia zmiany obiektu GET <IRI> If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT OK lub 304 w odpowiedzi. kiedy należy odpytywać? Serwer informuje proxy o czasach ważności kontentu (nagłówki Cache control lub Expires) nie ma gwarancji co do konieczności odpytania po upłynięciu czasu alternatywa: można adaptacyjnie wyznaczać ten czas samemu (a la TCP) zalety bezstanowy serwer, odporność na awarie serwera i proxy wady słabsza spójność danych, spory narzut sygnalizacyjny (wymiana wiadomości)
Schowkowanie kooperatywne Optymalne schowkowanie uzasadnienie dla kooperacji x p serv(p) =1 c O(c) origin server for c y io(c)c =1 K(v,c) z kc x vc =1 c y kvc =1 v d v l kvc =2 w y kwc =0 k domain l io(c)c =3 i d v - storage capacity of node v x vc = 1 iff item c cached in v y kvc = 1 iff c served for k from v l kvc path length (in hops) from k to v on the route towards c z kc - retrieval rate of k for c K(v,c) set of clients that can receive c from v relaksacja
cd. uzasadnienie dla kooperacji Funkcja Lagrange a relaksująca ograniczenie (1c) ma postać: subgradient Wychodząc z (2), problem (1) można zapisać następująco:
cd. uzasadnienie dla kooperacji => sygnalizacja) Iteracja subgradientowa w każdym węźle v wymaga wiedzy o k Iteracja plecakowa w każdym węźle v (lokalny problem plecakowy) waga obiektu O(c) Iteracja na ścieżce od klienta k do serwera O(c) (wybór v) v k wybór najmniejszej wartości na ścieżce, wymaga sygnalizacji
Schowkowanie kooperatywne Infrastruktura schowków obejmuje wiele serwerów proxy wiele sposobów organizowania serwerów proxy, np. hierarchicznie zasadniczo nadal jest to transparent caching proxy mogą ze sobą współpracować odpowiadać na żądania klientów rozsyłać powiadomienia serwerowe (wzajemnie klient/serwer) często stosuje się kombinację HTTP i ICP (Internet Caching Protocol) lub HTCP (Hypertext Caching Protocol), czy też Cache Digest ICP służy do szybkiego odpytywania sąsiadów o dostępność u nich kontentu HTCP zastąpił ICP; rozbudowany protokół zarządzania schowkami, z możliwością np. wykrywanie schowków i kontentu, informowania o zmianie/usunięciu kontentu Cache Digest informowania o zawartości schowków HTTP służy do przesyłania kontentu najpopularniejszy opensource: Squid (wykorzystuje podzbiór HCTP, lecz jednocześnie wprowadza algorytmy zarządzania) Kolejny stopień zaawansowania: sieci CDN (Content Delivery Network)
Sieci CDN (Content Delivery Network)
Sieci CDN (Content Delivery Network) Wady transparentnego schowkowania (model proxy) charakter: robione za plecami dostawców treści ograniczone zaufanie dostawców treści do poprawności implementacji proxy brak kontroli nad treścią przez dostawców ograniczona aktualność kontentu statystyki wykorzystania i rozliczanie (np. reklamy) personalizacja treści zarządzanie prawami (Digital Rights Management, DRM) w efekcie: utrudnienia ze strony dostawców treści (np. tokeny jednorazowe URI) w celu obniżenia sprawności schowkowania ale to kosztuje Rozwiązanie: instytucjonalne zorganizowanie schowkowania sieci CDN uwaga: technologie typu P2P też mogą służyć do realizacji usług typu CDN
Sieci CDN - idea Model biznesowy dostawca treści (content provider), np. www.bbc.com, płaci dostawcy usług CDN (np. Akamai) za dostarczanie treści do użytkowników z dobrą jakością sam dostawca treści oszczędza na zasobach, optymalizacja dostarczania po stronie CDN wiele problemów wytkniętych dla modelu proxy jest rozwiązanych przez CDN na bazie kontraktu i zaufania (ze wsparciem w formie środków technicznych, np. logi zbierane przez CDN) Główne środki techniczne stosowane w sieciach CDN replikowanie treści (powielania w wielu serwerach) wybór optymalnego serwera dla każdego wywołania rejestrowanie zdarzeń na potrzeby rozliczeń (i optymalizacji rozłożenia treści)
Podstawowa terminologia Treść (content): dowolna kombinacja informacji tekstowych, obrazów, apletów, ramek, MP3, wideo, etc. Dostawca treści (content provider): osoba fizyczna lub organizacja, która życzy sobie udostępniania jej treści innym użytkownikom. Serwer źródłowy (origin server): serwer dostawcy treści gdzie treść jest pierwotnie udostępniana. Dystrybutor treści (content distributor): strona odpowiedzialna za optymalne dostarczanie treści do użytkowników. Serwer CDN (surrogate server, także edge server): serwer dystrybutora treści (w sieci CDN), w którym dostępne są repliki obiektów.
Ekosystem - środowisko biznesowe OTT Główne strony Reklamodawca Yahoo, BBC, Microsoft, FIAT, Hitachi, Dostawca treści PC World, Red Hat, dostarcza treści Dystrybutor treści Użytkownik Akamai, Edge Cast, Limelight, AT&T, HP, Cisco, ALU, Dostawca HW/SW Dostawca hostingu Orange
Dostarczanie treści w CDN ogólny obraz Operator sieci CDN rozmieszcza serwery CDN w centrach hostingowych różne modele: Akamai tysiące małych, EdgeCast kilkadziesiąt dużych CDN replikuje treści klientów w serwerach CDN. W przypadku zmiany treści przez dostawcę treści CDN rozsyła nową treść do serwerów. CDN ma mechanizmy zapewniające skierowanie wywołania użytkownika na serwer CDN najlepszy z punktu widzenia czasu pobrania różne szczegółowe kryteria bliskość (np. wg adresu IP), dostępność dobrej drogi transmisyjnej do użytkownika (wymaga to monitorowania sieci).
Główne bloki funkcjonalne sieci CDN Funkcja dystrybucji kontentu (ulokowanie w serwerach CDN) Funkcja udostępnienia kontentu, w tym przekierowania (Redirection - skierowanie żądania na właściwy serwer CDN) Funkcja rozliczeniowa (accounting & billing)
Funkcja dystrybucji kontentu Dostawca treści (także CP) decyduje które z jego treści mają być dostarczane przez sieć CDN. Dostawca treści naznacza te treści i przekazuje je do sieci CDN; ta następnie replikuje treści w serwerach CDN wg własnych algorytmów. Podstawowe modele dla tego kroku: Pull (przekazanie przy pierwszym żądaniu od użytkownika technicznie prosty model, ale z fazą rozruchową ) Push (aktywne przekazanie treści do sieci CDN technicznie trudniejszy model, wymagający dodatkowego interfejsu między CP an CDN) Pull Serwer źródłowy GET/OK Push Serwer źródłowy PUT( content) CDN CDN Serwer dystrybucyjny CDN Serwer dystrybucyjny CDN push content push content GET/ OK Serwer CDN w CCC push content Serwer CDN w CCC Serwer CDN w AAA Serwer CDN w BBB Serwer CDN w AAA Serwer CDN w BBB GET/OK
cd. Pytanie: w jaki sposób przeglądarka określa skąd należy pobrać dany obiekt z serwera źródłowego czy z serwera CDN? Jeśli z CDN, to z którego serwera? Przykładowo, załóżmy: nazwę FQDN serwera źródłowego jako www.bbc.com nazwę FQDN operatora CDN jako www.akamai.com Ustalenie właściwego serwera CDN dla danego żądania następuje w wyniku rozwiązania nazwy URI obiektu w ramach procedury przekierowania znanej jako Redirection lub Request routing.
Przekierowanie zapytań (request routing) w CDN Użytkownik (przeglądarka) pobiera dokument html ze strony www.bbc.com; może to być index.html W index.html stosuje się zmieniony URI dla obiektów obsługiwanych przez CDN. np. pierwotną nazwę pliku <img src= http://bbc.com/dl/y.gif > można zmienić na <img src= http://b22.akamaitech.net/6/24/bbc.com/dl/y.gif > prefix b22.akamaitech.net/6/24/ jest uzgadniany z operatorem CDN; wymagana jest więc ingerencja w dokumenty html Przeglądarka będzie teraz rozwiązywać nazwę hosta b22.akamaitech.net. zamiast bbc.com.
cd. przekierowanie System DNS jest konfigurowany tak, aby zapytania o akamaitech.net były przekazywane do serwera autorytatywnego dla akamaitech.net (server DNS Akamai) Serwer DNS Akamai, po otrzymaniu zapytania DNS, ustala lokalizację użytkownika na podstawie adresu IP nadawcy w tym zapytaniu (typowo jest to adres lokalnego serwera DNS). Na podstawie adresu IP oraz utrzymywanej przez Akamai mapy Internetu, a także z uwzględnieniem polityk, ustalany jest i zwracany w odpowiedzi adres właściwego serwera CDN (surrogate server). przy okazji, adres serwera DNS Akamai ląduje w schowku lokalnego DNS i kolejne żądania mogą być szybciej obsługiwane TTL dla adresu IP serwera DNS Akamai ma stosunkowo małą wartość.
Przekierowanie - ogólny schemat index.html... <img src="http://www.cdn.com/bbc/ images/i1.gif >... bbc.com index.html GET www.bbc.com/index.html DNS query: cdn.com? Autorytatywny serwer DNS dla cdn.com 44.555.22.33 Użytkownik 44.555.22.33 lokalny serwer DNS
Przypadek pudła (cache miss) Gdy we wskazanym serwerze CDN nie ma obiektu? serwer CDN może odpytać inne serwery z sąsiedztwa o dostępność obiektu (pamiętamy używając np. protokołu ICP lub HTCP, lub jeszcze inaczej) w ostateczności zapytanie można skierować do serwera źródłowego (u dostawcy treści) są rozwiązania, gdzie ten tryb jest podstawowy *) 4 Origi n serve r 1 CD N DN S 2 5 3 HTTP GET/OK schowek schowek HTTP GET/OK *) np.. Veriview, obecnie Akamai
Przekierowanie - optymalizacje Schemat pracy z przeplotem poziomu DNS i HTTAP jest dość typowy (choć detale bywają różne) Sztuka polega jednak na wyznaczaniu dobrego serwera CDN główne wymagania: równoważenie obciążeń i awarie/włączanie nowych serwerów duża liczba serwerów duży strumień wywołań dynamiczne warunki zarówno na poziomie serwerów CDN, ja ki sieciowym Akamai: każdy serwer CDN prowadzi pomiary i raportuje wyniki do Net. Oper. Comm. Center (NOCC). liczba aktywnych sesji TCP, strumień żądań HTTP, dostępne pasmo itp. informacje te służą do parametryzacji algorytmów w autorytatywnym serwerze DNS Akamai
Przykładowe zastosowanie CDN Netflix OTT VoD źródło: http://www.payott.tv/2012/04/17/build-netflix-like-multiscreen-ott-service/
W podsumowaniu: ewolucja technik CDN Zautomatyzowane, o prostej obsłudze na poziomie technicznym (plugand-play) Źródło: M.Pathan, R.Buyya, A.Vakali, Content Delivery Networks: State of the Art, Insights, and Imperatives, w R. Buyya et al. (eds.), Content Delivery Networks, Springer-Verlag Berlin Heidelberg 2008
Koncepcja ICN (Information-Centric Network) - zarys
Koncepcja sieci ICN (Information-Centric Network) Rozpowszechnianie i obrabianie nazwanej informacji podstawowe zastosowanie Internetu centralna rola adresu IP nie odpowiada istocie wykorzystania sieci host-centric Global FIXED traffic (ExaByte/month) Global MOBILE traffic (ExaByte/month) 100 2.5 80 Residential Unicast TV 2.0 Handheld data traffic 60 Residential Internet 1.5 Laptop Data Traffic 40 20 Voice Traffic Business Internet 1.0 0.5 Voice Traffic 0 2007 2008 2009 2010 2011 2012 2013 2014 2015 Fixed broadband traffic is 40x mobile in 2015 źródło: MEVICO / Nokia 0.0 2007 2008 2009 2010 2011 2012 2013 2014 2015 Mobile data traffic grows 300 fold CDN 30
Podejścia i problemy Wzrost ruchu, np. video i cloud computing => stosowanie rozmaitych technik i rozproszonych usług bazujących na: schowkowaniu, replikacji danych i dostarczaniu treści Obecnie dominuje podejście typu silos wzajemnie rozłączne sieci CDN i aplikacje P2P Przykładowo nie zapewniają jednoznacznej i bezpiecznej identyfikacji nazwanej treści w sposób niezależny od kanału dystrybucji realizowane na bazie firmowych rozwiązań implementowane nakładkowo => niepotrzebna utrata efektywności podejścia typu ALTO dla P2P na razie bardziej teoria (Application Layer Traffic Optimisation, IETF) CDN 31
Dokładniej: wybrane problemy (1) Trwałość nazwy obiektu (name persistence) nazwa raz nadana przez twórcę powinna być trwała, niezależnie od lokalizacji obiektu i jego aktualnego właściciela(i) oraz dostawcy(ów) np. struktura WEB URL: format gdzie/co. URL dostosowany do adresowej struktury sieciowej wymaga zmiany przy zmianie dostawcy ( gdzie także w przypadku CDN) sieć typu ICN => możliwość wyszukiwania by-name (atrybut gdzie jest zbędny z punktu widzenia aplikacji) Dystrybucja treści poprawianie jakości dystrybucji i wykorzystania zasobów przez schowkowanie i replikację na bazie rozwiązań firmowych (Akamai CDN, P2P, WEB proxy) nie współpracują ze sobą, rozwiązania poważne są płatne sieć typu ICN => możliwość wbudowania replikacji i schowkowania jako prymitywów sieciowych dostępnych dla każdego CDN 32
Dokładniej: wybrane problemy (2) Opóźnienie wyszukiwania obecnie każde zapytanie zaczyna się od interakcji z DNS (pobranie adresu IP) opóźnienie DNS staje się czynnikiem znaczącym (w stopniu zależnym od przypadku) systemy CDN typowo mają wewnętrzny DNS, co dodatkowo spowalnia proces wyszukiwania (request routing) sieć typu ICN => możliwość wyeliminowania mediacji DNS Mobilność adres IP zwykle określa lokalizację oraz identyfikuje zakończnie obecnie źródło wielu problemów sieć typu ICN => nazwa określa zarazem zakończenie a ruting nie odnosi się wprost do lokalizacji CDN 33
Dokładniej: wybrane problemy (3) Bezpieczeństwo użytkownika interesuje zaufana treść dzisiaj osiąga się to pośrednio: przez zaufanie do strony, która udostępnia treść (a nie do samej treści) obecnie wiele ryzyk wiele stron w łańcuchu, np. wiara, że faktycznie negocjuję z Amazon (bo klikam www.amazon.com po wyszukaniu na stronie Google) pośrednio wiara w DNS, który tłumaczy URL na adres IP następnie wierzę serwerowi z repliką po przekierowaniu przez CDN itd. sieć typu ICN => informacje zapewniające bezpieczeństwo (uwierzytelnienie, zaufanie) bezpośrednio związane z treścią; treść może pochodzić z niezaufanego serwera, być przenoszona przez niezaufaną sieć pozwala to na replikację treści w dowolnym miejscu prawa autorskie i aktualność treści to odrębna kwestia CDN 34
Co dalej? Information-Centric Networking (ICN) Dzisiejszy Internet Centrum uwagi: węzły, hosty Przyszła sieć ICN Centrum uwagi: obiekty informacyjne (również jako reprezentacje obiektów fizycznych IoT) Dominująca forma wykorzystania sieci: dostęp do informacji CDN 35
Wymagania i główne podejścia Wymagania i oczekiwane korzyści unikatowe nazwy obiektów informacyjnych podstawa przyszłego Internetu dane niezależne od lokalizacji, właściciela i dostawcy i formy transportu wsparcie dla cachingu i replikacji w sieci korzyści: poprawa wydajności i ekonomiki sieci większa skalowalność sieci w odniesieniu do liczby obiektów i pasma ułatwienie dostawy treści w wymagających scenariuszach sieciowych (mobilność, sieci DTN, sieci czujników, etc.) Główne podejścia: CCN (Content Centric Networking, aka Network Named Data, NDN) http://conferences.sigcomm.org/co-next/2009/papers/jacobson.pdf http://www.parc.com/content/attachments/securing-network-content-tr.pdf NetInf (Network of Information) http://www.netinf.org/home/home/ http://www.netinf.org/home/publications/ PSIRP/PURSUIT (Publish/Subscribe Internet Routing Paradigm) http://www.cs.ucla.edu/classes/cs217/2011_illustrate_pubsub.pdf CDN 36
Wybrane podejścia - porównanie: CDN/NetInf - CCN CDN CCN DNS prox y CDN DNS Origi n serve r Req. 2/3 4/5 Loka lny DNS Resp. Req. Resp. CDN Streamer selector dość podobne 4/5 schowek 3/6 schowek Req. 1/6 nazwa 7/8 HTTP GET/302 9 / 10 lub 12 HTTP GET/OK schowek gdy brak w schowku 10 / 11 HTTP GET/OK Origi n serve r schowek 1/7 Req. nazwa Resp. schowek CDN 37 2
Dwa główne podejścia Ewolucyjne (por. NetInf) cel: poprawienie obecnego Internetu zasada: opracowanie nakładki content centric w istocie to forma ewolucji CDN wprowadzenie metadanych jako kanonu dozwolone różne formy transportu (nie tylko TCP/IP) domenowość, ale na bazie wspólnego schematu nazwy (z grubsza: niuri ::= ni://[część hierarchiczna>/]<hash kryptograficzny> ) Radykalne (clean-slate) (por. NDN / CCN) nazwa obiektu hierarchiczna warstwa sieciowa content-centric operuje bezpośrednio na łączu danych transparent caching wbudowany w warstę sieciową uwierzytelnienie treści (podpis konkatenacji nazwa+pole_danych ) wymaga nowego podejścia do wielu zagadnień ruting i mobilność (skalowalność compact routing?) QoS i sterowanie przeciążeniem po stronie odbiornika (przeciwnie do TCP) nowy model współpracy z warstwą aplikacyjną CDN 38
ICN wdrożenie na razie odległe Wymagana ciągłość pracy bez godziny W itp. dla prowadzenia eksperymentów na szeroką skalę Kluczowe dla wykazania zasadności danej koncepcji Trudny problem, na razie mało zbadany (próby realizacji przykładowych, wyizolowanych aplikacji) Tymczasem celem bliższym jest ewolucja CDN przejęcie ruchu wolumenowego przez ISP z powodu spadku dochodów dostawców CDN OTT w tym obszarze (wolumen ma być za darmo ) w znacznej mierze zastosowanie dla celów inżynierii ruchu niełatwe z uwagi na lokalny charakter większości ISP implementacja w formie aplikacji w chmurze (aby tanio) współpraca sieci CDN? (CDN Interworking - IETF) CDN 39
Literatura R. Buyya et al. (eds.), Content Delivery Networks, Springer- Verlag Berlin Heidelberg 2008. dostępne w wersji elektronicznej prze serwer Biblioteki Głównej PW (http://eczyt.bg.pw.edu.pl/han/springerlink/link.springer.com/bo ok/10.1007/978-3-540-77887-5/page/1)