Detaillierte Erläuterung des CDN-Anforderungsprozesses

Einführung in CDN

CDN ist jedem bekannt, hier eine kurze Einführung.

Mit CDN können Benutzer hauptsächlich Ressourcen von CDN-Knoten abrufen, die den Benutzern beim Zugriff auf Ressourcen sehr nahe stehen, anstatt zu dem Computer zu wechseln, der tatsächlich Dienste bereitstellt. So kann CDN

1. Lassen Sie Benutzer den Inhalt, den sie benötigen, schneller erhalten
2. Reduzieren Sie den Backbone-Netzwerkverkehr
3. Reduzieren Sie den Serverdruck

CDN hat drei Phasen durchlaufen

Die erste Phase 1995 gründete Tim, der Erfinder des Internets, das erste CDN-Dienstleistungsunternehmen Akamai

In der zweiten Phase 1999 ~ 2001, dem Höhepunkt der Internetentwicklung, entwickelte sich CDN rasant

In der dritten Phase brach das Internet im Jahr 2001 zusammen, CDN-Unternehmen gingen bankrott und Tims Unternehmen ging ebenfalls bankrott. Ab 2002 haben Breitband-Upgrades, Spiele- und Videoentwicklung zur Entwicklung von CDN geführt

Obwohl CDN mehr als 20 Jahre Entwicklungszeit hinter sich hat, hat es noch keine Standardspezifikation gebildet, und die spezifische Implementierung jedes Unternehmens ist unterschiedlich. In diesem Artikel wird nur ein Typ erläutert, und wir möchten Ihnen ein tieferes Verständnis von CDN vermitteln.

CDN-Anforderungsprozess

Der CDN-Anforderungsprozess entspricht in etwa der folgenden Abbildung, und ich werde ihn im Folgenden kurz vorstellen. Das durchgezogene Feld links ist die DNS-Suchphase, und das gepunktete Feld rechts ist der Bereich des CDN. https://www.processon.com/view/link/5ed5175e0791291d5dba30ea

DNS-Suchphase

Der Benutzer fordert einen Link im Browser an, z. B. event.mi.com. Der Browser muss die IP-Adresse finden, die dem Domainnamen entspricht

1. Überprüfen Sie zunächst, ob auf dem DNS-Client Ihres Computers ein Eintrag vorhanden ist, falls kein Eintrag vorhanden ist

2. Wenden Sie sich an den lokalen DNS-Server, wenn der lokale DNS-Server keinen Eintrag hat

3. Suchen Sie vom Root-Domain-Name-Server (13 Root-Domain-Name-Server weltweit). Der Root-Domain-Name gibt die Adresse des com-Domain-Name-Servers zurück

4. Der lokale DNS-Server sucht vom com-Domänennamenserver und der com-Domänennamenserver gibt die autorisierende Domänennamenserveradresse von event.mi.com zurück

• Autorisierender Domainname DNS-Server: Enthält alle Informationen zum Domainnamen

5. Nachdem Sie den autorisierenden Domain Name Server gefunden haben, werden Sie feststellen, dass der Domain Name einen CNAME hat. Dieser CNAME verweist im Allgemeinen auf das globale Lastausgleichssystem des CDN

• DNS Ein Eintrag

  • Das Format des A-Eintrags lautet "Domain Name-IP", und der Datensatz ist die Server-IP-Adresse, die dem Domain-Namen entspricht

• DNS-CNAME

  CNAME ist der Alias ​​des Domainnamens und hat im Allgemeinen zwei Funktionen

  1) Mehrere Domänennamen verweisen auf dieselbe Dienst-IP. Wenn sich die Dienst-IP ändert, muss nur ein A-Datensatz geändert werden. Beispielsweise lautet der A-Eintrag des Domainnamens www.abc.com 1.1.1.1, und der Alias ​​des Domainnamens mail.abc.com und study.abc.com kann auf www.abc.com gesetzt werden, sodass nur dann, wenn der Dienst die IP-Adresse ändert Der A-Eintrag von www.abc.com muss geändert werden. Es müssen keine anderen Domain-Namen geändert werden, wodurch die Wartungskosten gesenkt werden

  2) Die Rolle von CNAME auf CDN ist ebenfalls sehr wichtig. Um einen Domänennamen an das CDN zu hängen, müssen Sie den CNAME des Domänennamens auf den vom CDN-Anbieter bereitgestellten Domänennamen festlegen, damit der CDN-Anbieter Datenverkehr über DNS an das CDN übertragen kann. Nachdem der CNAME des Domänennamens auf den Domänennamen des CDN festgelegt wurde, kann der A-Eintrag des Domänennamens nicht vorhanden sein. Im Allgemeinen können Sie die DNS-Auflösung über die Befehle nslookup und dig anzeigen. Wie in der folgenden Abbildung dargestellt, können Sie sehen, dass der CNAME des Domainnamens event.mi.com ein Domainname von Baishan Cloud ist. Außerdem können Sie sehen, dass der Domainname von Baishan Cloud auch einen entsprechenden CNAME hat. Dies dient hauptsächlich dem Lastausgleich, der später erläutert wird.
  

  3) Die in diesem Modul beschriebene DNS-Auflösung verwendet die iterative Suche. DNS bietet auch eine rekursive Suchmethode. Wenn Sie interessiert sind, können Sie den Unterschied zwischen den beiden untersuchen

CDN-Stufe

Durch den oben beschriebenen DNS-Auflösungsprozess hat der CDN-Betreiber die Anforderung erfolgreich an sie übertragen

1. Es gibt viele Möglichkeiten, das globale Lastausgleichssystem von CDN zu implementieren. Hier ist eine häufigere Lösung, das DNS-basierte globale Lastausgleichssystem.

• Erstens ist das System DNS, das Domänennamen auflösen kann

• Zweitens hat das System eine Lastausgleichsfunktion. Im Allgemeinen gibt es zwei Arten von Lastausgleichsstrategien für CDN: den statischen Lastausgleich (wählen Sie verschiedene Server basierend auf dem geografischen Standort des Benutzers, den Netzwerkbetreibern usw.) und den dynamischen Lastausgleich (wählen Sie Server basierend auf dynamischen Daten wie Serververkehr, Leistung und Last aus). Da der dynamische Lastausgleich mehr Ressourcen verbraucht, verwenden globale Lastausgleichssysteme im Allgemeinen statische Lastausgleichsstrategien, und regionale Lastausgleichssysteme verwenden im Allgemeinen dynamische Lastausgleichsstrategien.

• Schließlich wählt das globale Lastausgleichssystem basierend auf der statischen Lastausgleichsstrategie die entsprechende IP des regionalen Lastausgleichssystems für den Anforderer aus.

• PS: Im Allgemeinen verfügt das globale Lastausgleichssystem über ein Sicherungssystem, und die Konfiguration des Sicherungssystems entspricht genau der des aktuellen Systems. Wenn festgestellt wird, dass das CDN von DDos angegriffen wird, wird das Sicherungssystem aktiviert, die IP des Sicherungssystems wird dem DNS hinzugefügt und die Cache-Zeit der IP-Einstellung wird länger. Diese Lösung kann DDos-Angriffe reduzieren.

• PS: Der Lastausgleich hat vier Ebenen des Lastausgleichs und sieben Ebenen des Lastausgleichs. Die sogenannten vier und sieben Ebenen entsprechen den sieben Schichten von OSI. Die vierte Schicht kann nur einen Lastausgleich basierend auf IP usw. durchführen, und die siebte Schicht kann die angeforderten Informationen erhalten, wie z Cookies usw. führen einen Lastausgleich durch. Unser häufig verwendetes Nginx kann einen vierstufigen Lastausgleich und einen siebenstufigen Lastausgleich durchführen.

2. Der Client fordert das regionale CDN-Lastausgleichssystem an, das den CDN-Cache-Server ermittelt, der den Dienst bereitstellt. Regionale Lastausgleichssysteme verwenden im Allgemeinen dynamische Strategien. Aus diesem Grund wird ein separater Server benötigt, um verschiedene Informationen zu CDN-Cache-Servern in der Region zu erfassen (z. B. Sitzungskapazität, Roundtrip-Zeit, Datenverkehr, Cache-Speicherort usw.).

• Hier finden Sie eine kurze Einführung in die Auswahl eines CDN-Cache-Servers basierend auf dem Speicherort des Caches. Das Implementierungsprinzip dieser Methode ist sehr einfach: Die angeforderte URL wird über einen bestimmten Algorithmus mit einem CDN-Cache-Server abgeglichen. Wenn die URL in Zukunft erneut angefordert wird, trifft sie weiterhin auf den Cache-Server. Der Vorteil dieser Methode besteht darin, dass Platz gespart wird. Eine Anforderung wird nur auf einem Server gespeichert, und es gibt keine Redundanz. Der Nachteil ist, dass bei einer heißen URL der Serverdruck zu hoch ist und bei einem Problem mit dem Server möglicherweise alle Anforderungen an die Quelle zurückgegeben werden.

3. Wenn der vom regionalen Lastausgleichssystem bereitgestellte CDN-Cache-Server nicht zwischengespeichert wird oder der Cache ungültig ist, wird eine Anforderung an den übergeordneten CDN-Cache-Server gesendet. Die häufig verwendeten Protokolle sind ICP / HTCP / CARP usw. Natürlich werden die Grundkenntnisse des Webs verwendet, um die Ungültigmachung des Caches zu beurteilen, z. B. Pragma, Expires, Cache-Control, Last-Modified, Etag usw.

4. Wenn der obere CDN-Cache-Server immer noch nicht zwischengespeichert oder abgelaufen ist, fordert er die Datei auf dem Back-to-Origin-Computer an und zwischenspeichert sie, nachdem die Anforderung erfolgreich war

Einige Probleme bei der Verwendung von CDN

CDN ist sehr nützlich gegen hohe Parallelität. Weitere Informationen finden Sie in diesem Artikel "Allgemeine Caching-Techniken".

Bei der Verwendung von CDN können jedoch auch einige Probleme auftreten. Hier werde ich Ihnen einige Probleme erläutern, auf die ich gestoßen bin.

Das Abrufen von Dateien dauert zu lange

Ich bin kürzlich auf ein Problem gestoßen. Es dauerte 120 Sekunden, um ein 50-KB-Bild über CDN zu erhalten.

Der Grund dafür ist, dass es ein Problem mit der Lastausgleichskonfiguration des CDN-Herstellers gibt. Unter der falschen Konfiguration muss die Hälfte der Erde zurückgelegt werden, um das Bild zu erhalten. Später, nachdem der CDN-Hersteller die Konfiguration geändert hat, dauert es nur 0,2 Sekunden.

Falsche Datei abrufen

Das Produkt muss über eine Produktwebsite verfügen, und die Produktwebsite verweist auf die js-Datei. Jedes Mal, wenn sich die Produktwebsite ändert, ändert sich der js-Name nicht, aber das js-Tag ändert sich, z. B. base.js? V01 in base.js? V02. Die js-Datei läuft so ab, dass sie niemals abläuft. Wenn sich die Versionsnummer ändert, wird sie an die Quelle zurückgegeben, die die Voraussetzung ist.

Wenn die Produktwebsite nicht mit der js-Version übereinstimmt, führt die Produktwebsite zu Fehlern, z. B. dass die Seite nicht geöffnet oder einige Funktionen nicht verwendet werden können. Es gibt zwei Situationen, in denen die Produktwebsite und js nicht übereinstimmen

1. Die Produktseite ist die neue Version, js ist die alte Version

Diese Situation ist im Allgemeinen auf die Tatsache zurückzuführen, dass js nicht zum ersten Mal auf dem Back-to-Source-Computer freigegeben wurde, als es freigegeben wurde, sondern dass zuerst eine neue Produktwebsite freigegeben wurde. Wenn die neue Produktwebsite neue js anfordert, fordert sie den Back-to-Source-Computer an und kehrt zurück Der Quellcomputer ist immer noch die alte Version, daher wird der alte js als neuer js-Cache behandelt. Danach wird in der Regel eine neue js-Version generiert und der Release-Vorgang erneut ausgeführt.

2. Die Produktseite ist die alte Version, js ist die neue Version

Es gibt viele Gründe für diese Situation, und es ist oft schwierig, damit umzugehen. Voraussetzung dafür ist, dass das neue js auf dem Quellcomputer freigegeben wurde und die alte Produktwebsite noch nicht freigegeben wurde

• Wenn es nur einen CDN-Dienstanbieter gibt und die Benutzer zu diesem Zeitpunkt alle im Ausland sind und die Produktwebsite in China besuchen, ist diese Anforderung gemäß der globalen Lastausgleichsstrategie die erste Anforderung im Land, und es gibt keinen Cache auf dem CDN Es ist ein neues js, aber die Wahrscheinlichkeit dieses Auftretens ist relativ gering und die Auswirkung ist nicht groß
• Wenn es mehrere CDN-Dienstanbieter gibt, ist die Wahrscheinlichkeit, dass dies geschieht, extrem hoch. Da verschiedene Dienstanbieter unterschiedliche Dienstbereiche haben und der Betrieb und die Wartung möglicherweise auch den Datenverkehr verschiedener Dienstanbieter bereitstellen, ist es wahrscheinlich, dass sich die js-Anforderung überhaupt nicht auf dem CDN befindet, was zu einer Back-to-Origin-Situation führt. In diesem Fall wird der CDN-Cache im Allgemeinen gelöscht, um eine Versionsvereinbarung zu erzwingen. Dies kann jedoch weiterhin Auswirkungen auf Benutzer haben
• Eine andere Situation besteht darin, dass, wenn Dateien nur auf einem CDN-Cache-Server zwischengespeichert werden und der Server ausfällt, auch ein Back-to-Origin auftritt. Diese Situation ist jedoch selten, da die Wahrscheinlichkeit eines Serverschadens nicht hoch ist und sich auf der oberen Schicht des CDN-Servers ein Cache-Server befindet, sodass die Wahrscheinlichkeit gering ist.

Fordern Sie eine große Anzahl von Back-to-Origin an

Danach ist der Server häufig überlastet. Der Grund dafür ist, dass die meisten CDN-Dienstanbieter den CDN-Treffer anhand der gesamten URL beurteilen. Wenn die URL über Google-Anzeigen beworben wird, wird später ein anderes Suffix hinzugefügt, das nicht getroffen wird. Um dies zu verhindern, können Sie den Betrieb und die Wartung bei der Durchführung einer speziellen Konfiguration unterstützen lassen, und nur die angegebenen Änderungen der Abfrageparameter werden an die Quelle zurückgegeben (der Betrieb und die Wartung möchten diesen Vorgang möglicherweise nicht ausführen, da dies für eine spätere Wartung nicht förderlich ist) oder die Leistung Ihres eigenen Dienstes verbessern.

Wenn Sie

Zu guter Letzt

Wenn Ihnen mein Artikel gefällt, können Sie meinem öffentlichen Konto folgen (Programmiererin Mala Tang).

Detaillierte Erläuterung des CDN-Anforderungsprozesses

Gedanken zur Karriereentwicklung von Programmierern

Die Geschichte des Blog-Dienstes wird zerstört

Gängige Caching-Techniken

So verbinden Sie sich effizient mit Zahlungen von Drittanbietern

Gin Framework prägnante Version

Denken Sie über die Codeüberprüfung nach

Daten

1. https://cloud.tencent.com/developer/article/1349559
2. https://www.cnblogs.com/liyuanhong/articles/7353974.html
3. https://www.jianshu.com/p/4d8df62d55e3
4. https://blog.csdn.net/jiajiren11/article/details/80071312?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2. 2. kein Fall
5. Einführung in die DNS-Funktion und Verwendung in CDN
6. https://mp.weixin.qq.com/s?__biz=Mzg3MjA4MTExMw==&mid=2247486200&idx=1&sn=197c0905028104e1ae32dc6bed7941f5&chksm=cef5f94ef982705874cf1a852e2f3e4879e59cb0705d1aed5a12cd91f845fba1869b58cb8863&scene=21#wechat_redirect