schauen, wer von euch noch wach ist,
während ihr versucht, das Notebook zum Laufen zu bringen.
Aber wir schauen vorsichtshalber trotzdem mal nach. Ich sehe schon so
einen verkehrten Blick. Gut. Fangen wir mit was Einfachem an,
um die Leuten zu überfordern, kurz vor der Pause.
Wer von euch benutzt Facebook? Noch darf man sich trauen,
in die Hand zu heben, ja.
Es ist im Mainstream angekommen, aber es ist noch nicht
peinlich, gut. Wer von euch benutzt,
entweder ein Apple-Betriebssystem, irgendeiner Art und Weise oder ein Microsoft-Betriebssystem
Na, gut. Gut, gut, gut.
Wer hat nicht die Hand gehoben? Bei welcher Frage?
Bei beiden. Okay, das heißt,
wir haben entweder sehr alternative Leute da oder Leute,
die sich verlaufen haben und nichts mit Web zu tun haben.
Sie sind sich sicher, richtiger Raum?
Gut. So. Meine Präsentation ist leicht anders als die davor
. Sie hat zwar eine Security-Komponente am Ende,
aber ich erzähle erst mal etwas über Cilienz und
ein bisschen über
Ist immer trendy. Präsentation ohne IPV 6 sind einfach nicht
state of the art. Und versuche keinen Company-Namen zu sagen.
Ist ja auch genügend Logos drauf. Aber ich werde auch versuchen,
generell über CDNs zu reden und ein bisschen die Unterschiede zu zeigen,
welches CD ändern was macht.
Ah ja, genau. Ich bin der Christian und apparently
arbeite ich für allgemein. Soweit dazu. Gut. Da
wir... Das waren nur die Vorwärtstaste. Nee,
nee, das heißt... Wenn das kommt,
einfach mal hier so hübsch draufklicken und dann
Deshalb bringe ich nie meinen eigenen Computer mit. Gut,
er synchronisiert sich. Ihr kennt das ja schon alle.
So, technische Präsentation ohne AfC ist natürlich keine technische Präsentation.
Tatsache ist, CDNs sind sogar definiert. Ihr könnt das
mal durchlesen, wenn ihr es danach verstanden habt,
könnt ihr schon zu Hause gehen, was trinken.
Falls es alles sehr fluffig und schwammig ist und noch keinen Sinn macht,
würde ich vorschlagen, noch etwas zu bleiben.
Gut, generell, CDNs, Content Delivery Networks oder Content
Distribution Networks
Sind Networks, die dafür da sind, Content auszuliefern.
Welche Überraschung? Speziell den Content, von dem wir
vorhin gesprochen haben. Also wir reden hier von Facebook-Bildern,
wir reden von jeglicher Art von Videos. Wir reden von Downloads
. Deshalb soll die Microsoft-Geschichten. Wir reden von Webseiten,
bevorzugt alles mal, was Richtung HTTP 80 geht.
Aber auch SSL und sonstige andere Dinge. Die Idee ist einfach,
ihr seid jemand, der diesen Content hat, eine Firma,
wie zum Beispiel die genannten, und möchte das jetzt weltweit verteilen.
Dann sucht ihr euch einen CDN in eurer Wahl.
Dafür gibt es verschiedene Auswahlkriterien und die helfen euch,
das dann auszuführen
Senden zu den jeweiligen Usern, sprich wir alle im Raum,
bis auf die drei Herren, die sich gemeldet haben,
sodass dieser Content möglichst schnell, sicher,
dazu kommen wir nachher, bei uns ankommt.
Content oder Silienz sind normalerweise Overlay-Netzwerke. Das heißt, wir
haben so das normale Eyeball-ISP-Konzept. Wir haben schon DSL,
ein Kabel-Provider auf der einen Seite, wo wir alle daheim angeschlossen sind.
Wir haben dann so ein bisschen Backbone und Transit-Netzwerke,
sofern ihr irgendwas damit zu tun habt, normale Hosting-Firmen,
die dann in irgendwelchen Datacenter sitzen.
Und irgendwie da dazwischen verteilen wir dann,
das sehen wir dann gleich genauer,
Service für das Silien
Die Cilience, die Server unterscheiden sich so ein bisschen.
Normalerweise ist das so mehr oder weniger normale PC-Hardware in irgendeiner
Art und Weise. Davon ganz viele, so was hier
vielleicht auch von der Google oder so schon gesehen habe.
Und die sind dann unter Umständen so ein bisschen optimiert.
Es kommt so ein bisschen auf den CDN-Provider an,
Betriebssystem mag variieren oder ob er eigengeschriebene Demens hat.
Sprich, ob es dann HTTP-Demen an eigener ist und sein Name-Server.
Und wie weiter das eben optimieren möchte,
entweder für kleine falsch oder für große Video-Files.
Ich wäre besser
Ich weiß schon, wo ich drücken muss. Gut,
bekannte CDNs sind, muss ich nicht unbedingt vorlesen,
die ersten drei, die sind dafür bekannt,
dass sie ein eigenes Netz haben.
Sprich, von außen sehen die aus wie ein Transit-Provider oder ein normaler Holzsake-Provider.
Speziell der erste davon ist natürlich einer. Und davon gibt,
wir haben praktisch ein AS und dann kann man von denen entweder
einen Transit kaufen oder mit denen dann Internet Exchanges peeren.
Und so kriegt man dann diesen Content.
Dann gibt es eine zweite Art, wozu die zwei Letzteren
gehören in den zweiten Klammer
Die haben ein bisschen andere Vorgehensweise. Die gehen zwar unter Umständen
auch an den Internet Exchange oder Pieren mit den verschiedenen Netzen,
aber sie setzen auch Server in ein Ibor-Netzwerk.
Sprich, ihr habt einen größeren Provider, was auch immer.
Was gibt es denn? So Hansene zum Beispiel in Hamburg
. Und dann ist da eine gewisse Chance da,
dass in deren Netz Server von den jeweiligen CDNs schon drin sind.
Das heißt, anstelle über deren Background zu gehen,
deren Peering oder deren Transit-Provider kommt der Content dann verteilt aus dem jeweiligen Netz selbst,
was das Ganze einmal schneller macht von der Latency-Perspektive
Klar, ist viel näher. Der Server steht schon in
Hamburg, nicht in Frankfurt oder noch schlimmer in Amerika.
Und der zweite Vorteil ist, was auch immer ihr so
über Bottlenecks gehört habt, im Internet.
Die Server sind hoffentlich so nahe an euch dran,
dass die Bottlenecks von Impeering und den Transits,
wo dann die verschiedenen Provider versuchen zu sparen,
davor sind und nicht dahinter.
Gut. So, wie funktioniert es uns ideen?
Es gibt im Endeffekt zwei Varianten. Die Erstgenannten,
sprich die, die ein Netzwerk haben und ein
eigenes AS,
die machen normalerweise
einen Anycast
Sprich, die geben mehr oder weniger bounder Parklaster in die Welt.
Frankfurt, New York, was auch immer, San Francisco,
geben denen dieselbe IP-Adresse. Und je nachdem, wo ihr dann seid,
geht ihr zu dem jeweiligen, nee, nächstgelegensten Cluster.
Sprich, Hamburg würde eine Verbindung nach Frankfurt aufbauen und nicht nach New York.
Hoffentlich, wenn das Routing passt. Wenn nicht, ist es halt
eine Spur langsamer, Mai. Die andere Variante ist,
und das ist, was den Non-CDNs oder Non-Network-CDNs machen ist,
sie benutzen eine Technologie, das nennt sich Mapping.
Und sie versuchen, mit verschiedenen Kriterien herauszufinden,
bis zum Punkt zu wissen, wo ihr euch befindet.
Dazu gibt es dann... Jetzt habe ich eine Idee.
Dazu gibt es dann Pinks, BGP, Traceroots und verschiedene andere Sachen.
Und was dann passiert ist, ihr bekommt eine Antwort,
die mehr oder weniger auf euch maßgeschneidert ist.
Sprich, eine IP-Adresse, die hoffentlich möglichst nah an euch dran ist.
Ja, das wäre die nächste Idee gewesen.
Ist ein Herz. Christine, wie kann ich
das abschalten
Digga. Bis gleich. Dieses Zuweisen,
nennen wir eben Mapping und wenn das Mapping besser ist,
sprich wir haben eine bessere Idee, wo ihr seid.
Können wir euch zu einem Cluster schicken, der näher dran ist.
Das sieht in etwas so aus. Nein,
das ist einer der Kunden, wenn man einen Host oder
ein NS-Lookup macht, dann kriegt man ja bekanntlicherweise IP-Adressen.
In dem Fall kriegt man erst mal einen Scening.
Der Seename zeigt dann auf den jeweiligen CDN-Provider. Das heißt,
das ist der Moment, wo der Kunde praktisch übergibt und sagt,
du bist mein CDN, das ist die URL,
die ich praktisch Ja, wir nennen es Ackermeisen.
Ich glaube, da fällt mir jetzt kein generischer Name ein.
Die Werke meisten möchten. Und was wir dann machen,
ist, wir geben ihm dann so eine mehr oder weniger kryptische Name.
Und der zeigt, man sieht es,
oben ist New York und ist Boston eine verschiedene IP.
Und zwar jeweils eine IP von einem Cluster in der jeweiligen Stadt.
Sprich, macht ihr das an verschiedenen Orten mit verschiedenen Providern
auf dieselbe URL, bekommt ihr immer eine unterschiedliche IP.
Und zwar die, die möglichst nah an euch
dran ist
Aber latency oder Nähe ist nur eines der Kriterien. Es bringt nämlich gar nichts,
wenn wir euch zu einem Cluster schicken,
der möglichst nahe dran ist, der aber leider zu wenig Server hat,
voll ist oder den Content gar nicht hat.
So, nochmal. WLAN abschalten jetzt. Und so finde
ich irgendwann den roten Faden. Ja, ich verstehe es
ja auch nicht. Genau, sondern wir müssen auch sicherstellen,
dass der Cluster genügend Bankbreite hat, genügend Server,
vielleicht auch schon den Content drin hat,
sodass wir ihn dann ausliefern können.
Und all diese Kriterien und vielleicht noch etwa 20 andere Verbieten?
Ah. Da war schon ein Verbieten Erlauben-Dings. Ja,
aber das sollte eigentlich gar nicht mehr kommen, verdammte Axt.
Es wird lange Präsentation. Es tut mir leid für eure Pause.
Es tut mir auch sehr leid. Aber Pausen sind auch
überbewertet. Wir waren noch gar nicht bei den Slides,
die sich bewegen. Wir kamen noch gar nicht zum interessanten
Teil. So, genau. Wie gesagt,
idealerweise schicken wir euch zu einem Cluster,
der nicht nur niedrige Latenz hat,
sondern auch genügend Bandbreite
Kein Pack and Loss und all die verschiedenen Sachen. Geografie ist natürlich wichtig,
da Geschwindigkeit des Lichtes nun mal mehr oder weniger dieselbe ist,
geht es nicht schneller als derselbige und dementsprechend ist näher besser,
sofern er genügend Kapazität hat.
Gut, jetzt haben wir euch praktisch zu einem Server geschickt,
der nahe ist, haben euch eine IP gegeben und
ihr fängt mal an, Content herunterzuladen.
So, lasst uns mal sehen, was genau passiert,
beziehungsweise wie das denn so ausschauen kann.
Ganz wichtig, das sind die animierten Slides vom amerikanischen PR-Department,
also aufpassen, die waren teuer.
So, ihr gebt eine Adresse ein. Das wäre so
die... Ist super, oder? Wartet, bis die
Totenköpfe kommen. In dem Fall wird eine Verbindung zum Origin-Server,
das wäre so praktisch dann der Kunde des CDANs aufgebaut,
holt sich die Index HTML in der Index HTML,
sind natürlich Objekte,
Bilder,
Videos,
wer weiß was alles
Drin und die bekommt ihr dann von einem City Encash,
der dann, wie gesagt, wesentlich näher steht,
höhere Bandbreite hat und dementsprechend die Sachen schnell zur Verfügung stellt.
Das wäre so die klassische Julien-Variante,
die es eigentlich relativ langweilig ist und kaum noch gibt.
Das Ganze funktioniert auch für ganze Seiten. Wir können natürlich
auch die Index HTML selber auf den Cash packen und dann
die Bilder, wie vorher von dort liefern.
Ein altgebrachtes Vorurteil ist, dass das Ganze nur mit statischen Seiten funktioniert.
Das ist nicht ganz richtig. Wenn ihr Shops habt,
Datenbankanbindungen und was auch immer, Dann gibt es auch die Variante,
dass der jeweilige Cluster oder Cash, praktisch die Seite,
die Datenbank Connection selbst aufbaut, die Seite unter Umspenden selbst passt,
euch dann die Index HTML gibt,
mit der Shopping Card und dann die ganzen Bilder von,
was auch immer ihr gerade bestellt habt,
dann zu euch liefert.
Das heißt, je nachdem, wie kompliziert das Ganze ist,
funktionieren durchaus auch dynamische Inhalte.
So, gut
Soweit sind wir immer davon ausgegangen, dass der Inhalt,
den wir haben wollen, nämlich die bunten Bilder,
die auf der rechten Seite so ganz schnell hin und her zocken,
nehme ich schon in diesem Cluster drin sind.
Das ist aber genau genommen nur richtig, falls euer Nachbar
zu eurer linken oder Rechten die Webseite vorher schon mal angeschaut hat.
Hat er das nämlich nicht getan,
ist nämlich der Inhalt überhaupt nicht im Cash drin.
Der Inhalt der jeweiligen Kunden ist bei Fahr viel größer als
was die Cluster so an Hartes haben. Das heißt,
wir können nicht alles vorhalten und schon mal alles reinpacken in der Hoffnung,
dass es irgendwann irgendjemand anschaut,
sondern wir holen uns die Sachen im Endeffekt dann,
wenn jemand Interesse hat
Sprich, die erste Person holt sie sich. Und dann wird sie
an die anderen Personen, die danach kommen, schneller ausgeliefert.
Gut, damit könnte man natürlich jetzt sagen, ja,
das ist gut für Sachen, die oft angeschaut werden.
Aber was passiert denn eigentlich mit Sachen? Die relativ selten
sind. Facebook-Bilder. So ein Beispiel, Ebay-Pictures in 1,
wenn nicht jemand auch zufällig Regenschirme sammelt und sich dieselben Regenschirme anschaut in Hamburg.
Na gut, vielleicht in Hamburg schon.
Dann ist die Wahrscheinlichkeit nicht so groß,
dass die Sachen auch überhaupt im Cluster sind.
Dafür gibt es Prefetching
Same, same. Wir bauen eine Verbindung zum Kunstnächstgelegensten Cluster auf.
Fragen für Inhalte, die denn noch gar nicht im Cluster sind.
Die Index HTML-Komfortat, wir geben sie dem End-User.
Und jetzt passiert was Schönes. Wir können nämlich in die Zukunft schauen.
Wenn wir die Index HTML auf dem Cluster vorher parsen und mal reinschauen,
was denn die Index HTML so hat, dann hat die Index HTML all diese Embedded Objects. Das heißt,
bevor wir sie oder zur selben Zeit,
wo wir sie dem End-User geben,
können wir selbst reinschauen und dann all diese Objekte,
von denen wir wissen, dass sie da in User gleich anfragen wird,
Weil das ist genau, was sein Browser macht,
schon mal holen, über eine Persistent-HATDCP-Connection,
die schon aufgedreht ist und dementsprechend auch eine hohe MTU hat und laden die Sachen schon mal runter und dann das Blitz-Second später,
wenn er sie dann selbst haben möchte, tada,
sind sie schon im Cluster.
Das heißt, auch Cold Objects, wie wir es nennen,
können mit Prefetching im Endeffekt beschleunigt werden. Gut,
jetzt haben wir so eine grobe Idee,
was die CDNs machen,
zumindest mal so das Brot- und Buttergeschäft für das ganz normale CDN-Dasein,
dann lasset uns doch mal schnell schauen
Wie das Ganze mit V6 ausschaut. Wer von euch hat V6
schon irgendwie implementiert? Wow. Das sind ja wesentlich weniger,
als ich dachte. Das sind ja gerade mal 10 Prozent.
Gute Nachrichten an Teil der Lösung ist hier.
Gut aufgepasst. Also. Als die Leute V6 entwickelt haben,
kam sie doch auf die geniale Idee,
zwar die Adressen länger zu machen und mit ein paar Feature zu versehen,
aber vorsichtshalber mal nicht rückwärts kompatibel zu machen.
Sodass wir auch immer es benutzen möchte mit dem üblichen Henne-Ei-Problem,
dann erstmal von einem großen Problem steht
Im Endeffekt sind es zwei getrennte Internets,
das mit V4 und V6, die wir zwar versuchen,
irgendwie so alle miteinander zusammenzukleben, in der Hoffnung, dass es funktioniert.
Und die übliche Version davon ist Duals Deck.
Das heißt, ich gebe meinem jeweiligen Rechner einfach beide IP-Stacks.
Idealerweise eine V4 und eine V6-Adresse. Das heißt,
je nachdem, wo er dann hin will,
nimmt er dann die eine oder andere und damit funktioniert es eigentlich schon mal ganz gut.
Für all diejenigen, die das nicht haben, sprich,
weil der Cable-Provider, DSA-Provider keine V4-Adressen mehr hat und sie
dann nur noch V6 in der Zukunft kriegen.
Oder den anderen Weg herum, WNV6-Adresse aufrufen möchte,
die es nicht in V4 gibt.
Ich suche immer noch eine, falls jemand eine Idee hat,
was für eine Adresse das sein könnte, E-Mail schicken.
Dann brauchen wir irgendwas, was die zwei Wolken in der Mitte zusammenklebt.
Und das ist dann normalerweise irgendeine Art von Nut. Carrier Great Night,
Net 6 to 4 und 10 andere relativ eklige Technologien,
die das Ganze miteinander versuchen zu verbinden.
Mehr oder weniger erfolgreich. Dazu kommt,
dass IPV4 und V6 speziell, wenn es um DNS geht,
so ein paar Überraschungen vorhält
Wenn ich so vertraut damit ist, IPV 4,
wenn man es auflöst, man bekommt einen A-Record.
IPV 6, einen sogenannten Quad-A-Record. Und ein Name,
jetzt kommt die Überraschung, kann beides haben. Sprich,
die URL eurer Wahl muss nicht V4 oder V6 sein,
sie kann beides sein, daher ja auch die Duals-Degady.
Und wenn man dann ein NS-Lokup oder ein Host auf die
Adresse macht, kriegt man auch zwei verschiedene IP-Adressen zurück.
Einmal vor vier,
einmal vor sechs
So, nun kommt die Frage, was passiert jetzt eigentlich?
Wenn ich jetzt schon beides bekommen habe, welches benutze ich,
war vier, vor sechs? Im Endeffekt,
die meisten Leute wissen es gar nicht so genau,
was darunter passiert, weil im Endeffekt,
man treibt nur eine URL ein und dann, Mike,
kommt die Webseite oder nicht.
Die meisten Betriebssysteme heutzutage bevorzugen IPV 6 vor IPV 4. Sprich,
wenn ihr V6 habt und ihr eurem,
in dem Falle Mac,
eine V6 Adresse dahin gebt,
dann versucht ihr
die auch zu benutzen
Falls die Connectivity, und das kann jetzt ganz verschiedene Gründe haben,
euer Nutgateway zu Hause, euer kleiner Wi-Fi-Router packt das nicht ganz,
oder mittendrin das Routing irgendwo im Internet, ist nicht so das Beste.
Oder der Web-Server ist, hat zwar V6 als IP-Adresse,
aber die Webseite ist nur unter V4 erreichbar und V6 ist eine Test-Website.
Sehr witzig zu sehen. Dann bekommt ihr entweder nichts oder
nicht das, was ihr wolltet. Gut. Dazu kommt,
dass die IPV6 und DNS so ein bisschen verwirrend ist.
Die Anfrage, für den DNS, und das war im Endeffekt,
ich sollte nicht so schnell klicken, sonst stürzt es wieder ab.
Der Teil, wenn ihr praktisch eine Auflösung macht,
hat nämlich nichts damit zu tun, welches Protokoll ihr benutzt. Sprich,
ihr habt V4 oder V6, was ihr mit eurem Resolver spricht,
ob ihr dann einen A oder einen Quad-Air-Record zurückbekommt oder was der Resolver,
der Name-Server eures Providers, bevor ihr dann irgendwelche Rootname-Server oder andere fragt,
und was ihr als Antwort bekommt,
hat auch gar nichts mit V4 und eine V6 zu tun.
Das heißt, der erste könnte V4 sein,
der Ressolver fragt für V6, über das Protokoll V6 nach,
hat eine TCP-Verbindung, kriegt Abonnionen, CordA-Rekord zurück.
Das Ganze funktioniert auch in die andere Richtung.
Ihr fragt nach einem A oder einem QuadA,
die ganze Verbindung ist IPV4. Ihr kriegt aber einen QuadA zurück,
der wird vom Betriebssystem bevorzugt und ihr versucht an einen IPV6-Webserver zu erreichen.
Sprich, die Anfrage und was ihr selbst als Protokoll
habt oder was mittendrin der Ressolver mit dem Authority-DNS bespricht,
am Nix miteinander zu tun
Gut, Main. Als CDN,
um mal sicher zu gehen, dass das Ganze funktioniert.
Das Einfachste ist, wir machen mal alle Server-Dools weg.
Sprich, Sie kriegen eine V4 und eine V6-Adresse.
Dann ist im Endeffekt egal, mit was der klein kommt und was er fragt.
Wir haben dann für beide Flavors was im Angebot.
Und bauen wir das mal ganz auf hier.
So. Jetzt kommt es drauf an
Was man denn so machen möchte. Dummerweise ist es nämlich so,
dass die Sexkonnektivität noch nicht so schnell ist wie die V4.
Es gibt nur ganz, ganz wenige Anwendungsfälle, wo sie tatsächlich schneller ist.
Ansonsten ist sie entweder langsamer, weil der Routing-Pfad länger ist oder
weil mittendrin irgendwelche Tunnels sind. Tunnel sind so ganz beliebt,
um über V4 Wolken, wo kein V6 dazwischen ist,
erstmal so drüber zu springen, um das dann zu tunneln.
Und um all diese Sachen abzuhandeln, gibt es dann verschiedene Möglichkeiten.
So will ich, und das kommt zurück zu der Frage,
was machen denn Siliens, Siliens versuchen an Content so schnell wie möglich auszuliefern.
Wenn ich jetzt aber einen Kunden habe, der V6,
anfragt. Und ich glaube schon zu wissen,
dass eine Connectivity schlechter ist als in V4. Ich aber auch weiß,
nur weil er danach anfragt, heißt nicht zwangsläufig,
dass er genau das will. Kann ich ihm, ja,
vielleicht was anderes geben und gebe ihm einfach einen Quad,
Entschuldigung, einen A-Record anstelle eines Squad-Ace zurück.
Das ist, was Google gemacht hat. Google hat
relativ früh damit angefangen und die haben gesagt, ja,
wir wissen aber, dass so ein Teil der Netze nicht
so besonders schnell und performant ist und haben da eine Liste gepflegt von Hand.
Später auch, wo man sich selbst eintragen konnte,
wo man dann,
wenn der eigene Provider nicht schnell genug war oder ein Problem hatte,
den praktisch Black and White Listing gemacht hat
Und dann konnte man zwar versuchen, V6 aufzurufen,
aber Google hat dann gesagt, nee,
ich weiß es besser, deine Verbindung ist schlecht,
ich gebe dir jetzt halt einen A-Rekord zurück.
Gut, so eine Liste ist, wie das Internet selbst,
relativ groß, skaliert relativ gar nicht.
Und dementsprechend kam dann Google und auch wir auf die Idee,
das doch viel besser zu machen und einfach die Performance zu messen,
im jeweiligen IPV6-Variante.
Und danach dynamisch eine Entscheidung zu treffen,
welche IP wir zurückgeben
Sprich, wissen wir, dass V6 oder V4 der Performance-Unterschied
zu groß ist. Dann geben wir einfach nur eine davon
zurück und nicht beide und lassen den Client nicht entscheiden.
Um sicherzugehen, was wir denn genau machen,
lassen wir das im Endeffekt unseren Kunden entscheiden. Das heißt,
wie aggressiv wir V4 oder V6 bevorzugen, liegt an ihm.
Aber im Endeffekt ist es Performance bezogen und wird die Performance besser.
Sprich, jemand räumt sein V6-Netz auf und bekommt bessere Connectivity.
Dann müssen wir nicht irgendeine Liste nachpflegen, sechs Monate später,
sondern ein paar Stunden später funktioniert das dann alles.
Und der bekommt einfach
eine andere Antwort
Ähm, das Ganze nochmal versinnt bildlicht. Das heißt,
ein Quad A, sprich ein V6-Rekord,
gibt es nur zurück, wenn die Performance auch dementsprechend ist.
Sprich, selbst wenn der IPV 4 und V6 Connectivity hat,
weil er daheim Duals-Deck ist und sein Wi-Fi-Router daheim das auch kann,
heißt das noch nicht zwangsläufig, dass er das auch wirklich will.
Wenn er V6 gar nicht hat, meint,
dann ist es nicht so schwer, gell?
Dann geht man ihm V4 zurück, das machen wir seit
20 Jahren, nichts Spezielles daran.
Hops, die Totenköpfe gleich
So. Und wenn die Verbindung eben wesentlich langsamer ist,
er aber eine hat, dann geben wir eben nur V4 zurück.
Und dazu eben ein Kommentar, wer denn noch kein V6 hat,
aber seine Webseite gern in V6 haben möchte.
Der hat mit einem CDN praktisch einen Migrationspfad. Der Punkt ist nämlich,
V6 einzuführen in einem Backbone ist jetzt nicht so schwer,
so ein paar Route zu konfigurieren und DNS ist relativ einfach.
Wenn man aber Web-Applikationen hat,
wenn man vielleicht sogar eine Firewall hatte davor, ist,
die noch kein VSX kann und die erst in zwei Jahren abgeschrieben ist.
Oder wenn man feststellt, Jafar 6 ist zwar schön,
aber ich muss meine ganzen Skripts anpassen und mein Logging und
außerdem habe ich meine Leute noch nicht trainiert.
Ich hätte es aber gern. Dann besteht eine Variante darin,
das an den Cylien auszusourcen. Das heißt,
ich habe nach wie vor IPVV4, ganz normal,
schalte bei meinem CDN meines Vertrauens V6 an.
Und der liefert dann beides aus, fragt aber mich als Origin,
das war immer die Denkeseite.
In unserem kleinen Beispiel dann einfach über V4 und der Cluster
liefert es über V6 aus
Und damit habe ich dann den Vorteil,
V6 zu haben, als Webapplikation oder als Hosting,
ohne dass ich es direkt anschalten muss und habe dann ein bisschen länger Zeit,
mir zu überlegen, wie ich das Ganze mache.
Gut. Die versprechenden Totenköpfe. Viele? Rot? Offensichtlich sehr gefährlich.
Gut. Ein schöner Nebeneffekt oder zumindest mal für den Anfang
ein schöner Nebeneffekt an vielen verteilten Clustern in der ganzen Welt.
Und wir reden hier von jenseits der 100.000 Server,
2.000 Locations, also ganz viele Städte.
Wir reden hier nicht nur so für fünf oder so
Zumindest mal bei den großen CDNs. Einer der Vorteile ist,
dass sich die Last sehr gut verteilt. Weil was passiert denn
? Irgendeiner in der ersten Reihe mag seinen Nachbarn nicht.
Hat ein ähnliches Business-Modell oder er mag ihn generell nicht.
Ihr dürft euch einen aussuchen links oder rechts.
Dann geht ihr zu dem Botnetz eures Vertrauens.
Hat vermutliche russische Webseite. Und bestellt da mal 10.000 oder 20.000
Bots. Irgendwelche übernommenen meist Windows-PCs würde ich mal annehmen.
Und fängt dann an, euren freundlichen Nachbarn zu attackieren
Hat er nur ein paar Server in einem Hosting-Center?
Dann passiert genau das, was ihr davor gesehen habt.
Der Gute wird dann erstmal geflattet und die Leitung ist zu.
Er hat dann noch die Möglichkeit, mit seinem Provider
zu reden, kauft sich vielleicht auch eine fancy Box.
Die gibt es ja auch in verschiedenen Farben, stellt sie sich davor.
Und das ist eine Möglichkeit, damit umzugehen. Die andere Möglichkeit ist,
und das ist eben ein komplett anderer Ansatz, ist,
die Sachen zu verteilen.
Denn was passiert denn? Die 2000 Lokationen, GVT,
von denen ich gesprochen habe, wo die ganzen Server stehen,
kriegen ja immer einen Teil der Last.
Das heißt, ihr stellt euch mal vor,
jeder von euch hat jetzt so einen übernommenen Botnet-Rechner daheim.
Ihr geht ja zu ganz verschiedenen Website. Selbst wenn ihr
zur selben Website geht und die versucht zu überladen,
ihr geht ja zu ganz verschiedenen Clustern.
Also allein in Hamburg sind es vermutlich so zehn oder so.
Wenn jetzt noch welche außerhalb von Hamburg sind,
dann landet ihr an ganz verschiedenen IPs. Das heißt,
so einen Angriff zu bündeln mit den 10,
20.000 Botnets rechnen, ist gar nicht so einfach,
weil die mit dem Distributed-Ansatz hier sowieso schon mal in völlig verschiedene Richtungen gehen.
Das heißt, jeder von den Servern kriegt nämlich gar nicht
so viel von der Last ab
Und das Ganze geht im Endeffekt im Grundrauschen unter.
Das ist zumindest mal richtig für die ganzen Geschichten, wo es um DDoS-Attacken geht.
Einfach mal mit viel Bandbreite auf ein kleines Ziel geschossen wird.
Genau. Ich habe gesagt, die bewegen sich. Das heißt,
wir haben auf der linken Seite dann so den Traffic,
der sich nicht viel verändert, weil die Cashes oder die Cluster,
die mit dem Origin reden,
im Endeffekt mehr oder weniger dasselbe tun.
Und sie filtern dann, das ist praktisch der rechte Grafen,
Entweder verteilen sie die Attacken, das ist mal der erste Ansatz.
Das heißt, der Origin-Server oder euer Datacenter kriegt gar nicht
die volle Last ab. Und der zweite Punkt ist,
da kann man dann beliebig Web Application Firewards draufsetzen.
Das ist dann so ein bisschen unterschiedlich von CDN zu CDN,
falls sie es überhaupt haben.
Aber die, die es haben, gibt es dann so
ein bisschen verschiedene Ansätze. Und das führt dann eben dazu,
dass auf dem Distributed Edge dann auch noch gefiltert wird.
Und falls doch wirklich mal einer von den Clustern abgeschossen wird,
dann passiert auch nichts anderes als im Normalfall passiert,
falls so ein Cluster in Maintenance geht und nicht mehr
da ist
Diejenigen, die denen angegriffen haben,
werden dann einfach umgerutscht auf den nächsten Cluster.
Ups. Rechts unten. Und attackieren dann den.
Und damit geht das Ganze im Endeffekt im Grundrauschen unter.
Das wäre dann so eine Variante, wie man mit dem
Ganzen umgehen kann. Gut. 29 Minuten mit 5 Mal
Rebooten, nicht so schlecht.
Fragen? Kommentare
Ich habe eine Frage. Und zwar, war das?
Ich komme. Hallöchen. Also, und zwar,
ihr schaltet euch ja mal ganz brutal runtergebrochen als Cash zwischen den Server und den Usern.
Wenn ich auf meinem Server jetzt meine Seite hoste und Tracking-Tool X,
sag ich mal, da laufen habe, welche Anfrage kriege ich denn da,
wenn zum Beispiel die gecashten Content-Anfragen eigentlich von den CDN-Servern kommen?
Gute Frage. Dummerweise hast du dir jetzt gerade
den Infrastrukturtypen ausgesucht für Tracking-Fragen
Ja. Gut. Ja. Wir haben einen zweiten,
Christian. Die heißen alle Christian bei uns. Das macht's einfacher
. Ich komme. Wir haben auch nur eine Nummer.
Danke dir, René. Ja, ich hab den anderen Christian
den Vortrag halten lassen. Das war bequemer von der ersten
Reihe auszusehen. Die Frage ist relativ einfach zu beantworten.
Dein Tracking-Tool wird in der Regel auf JavaScript laufen.
Du guckst dir nicht mehr deine Logfiles an.
Also zumindest 99,5 Prozent der Kunden, die ich kenne,
machen das so. Das heißt, du mäscherst in deinem
Browser was passiert und da ist es ihm vollkommen egal,
wo das JavaScript herkommt oder die Dateien herkommen,
weil du den View dann in deinem Browser bist.
Beantwortet es
deine Frage
Gott, du bist falsch. Ansonsten, ja,
wenn du tatsächlich in Cash-Offload gehst,
also wenn es aus dem Cash kommt,
wirst du es nicht als Log-Eintrag in deiner Origin sehen,
also in deiner eigenen Web-Infrastruktur.
Gib mehrere Möglichkeiten. CDNs können Logfiles schreiben,
dann kannst du es da analysieren und echte Client-IP-Adressen schicken wir
auch mit und machen Mitbewerber auch.
Also das kann man dann bilasteral gucken,
aber ich habe keinen Kunden erlebt, der damit einen Stress hat,
dass sein Tracking irgendwie nicht läuft.
Soll ich nochmal rumlaufen? Alles klar. Noch jemand mit
einer Frage. Nein, okay. Gut, dann danke
. Vielen Dank nochmal