Google CDN liefert zufällig keinen gzip-Inhalt

Ich brauche fortgeschrittene Leute, die mir einen Rat geben, ist dies ein Google CDN Bug oder ich vermisse etwas. Ich entdecke diesen Bug wie vor 4 Monaten, habe versucht, ihre Unterstützung zu kontaktieren, aber sie waren so unhöflich, dass ich hier nicht einmal darüber sprechen möchte. Sie haben akzeptiert, zumindest haben sie mir gesagt, dass sie das Problem an das Backend-Team schicken werden, aber danach haben sie den Issue Tracker gelöscht und sie reagieren nicht mehr auf meine E-Mails. Das ist der Hauptgrund, warum ich hier frage.

Problem

Google CDN liefert dem Endnutzer zufällig keine gzip-Inhalte. Also statt ~ 70KB laden sie 500KB Dateien herunter. Ich kann dieses Problem nicht direkt zu meinem Ursprung herstellen, aber ich kann dieses Problem sehr einfach auf Google CDN erzeugen.

Hier ist eine Beispielanforderung an CDN:

Anfrage:

Antwort:

Wie Sie sehen können, habe meine Anfrage accept-encoding: gzip header, aber ich erhalte keinen gzip-Inhalt. Anstelle von 70KB erhalte ich 500KB. Beachten Sie auch Alter Header, dieses Element ist für 58422 Sekunden auf CDN im Cache / vorhanden!

Hier ist die gleiche Anfrage von einer anderen Maschine (US)

Anfrage:

Antwort:

Wie Sie sehen können, habe ich einen gzip-Inhalt von meinem anderen Server bekommen.

Ich habe eine Menge HAR-Dateien und auch Videos, die diesen Bug beweisen, aber wir wollen es einfach halten. Google CDN-Protokolle sind im GCP-Dashboard verfügbar, überprüfen Sie, wie sie aussehen.

Wenn alle meine Besucher gzip nicht unterstützen, was ist mit GoogleBot?

Ich analysierte auch meine Serverprotokolle und fand Statistiken wie 99% Antwortgröße für diese Datei als gzip, nur wenige Anfragen sind nicht gzip. Sehr logisch, da einige Besucher oder ich lieber sagen, dass Roboter diese Datei ohne gzip-Header angefordert haben.

Vorübergehende Lösung des Problems

Wenn ich den CDN-Cache lösche, existiert dieses Problem nicht in den nächsten Minuten / Stunden. Nach einiger Zeit passiert es immer noch. Auch dieses Problem passiert nicht immer, sondern zufällig. Ich habe ein System, das CDN-Logs parsiert und mir Graphen zeigt, das ist eigentlich, wie ich diesen Bug entdecke.

Wenn ich sehe, dass die Kartenbandbreite steigt (doppelt so normal), wenn ich mich im Google Dashboard anmelde und Protokolle prüfe, finde ich diese 500KB-Protokolle wie 50% dieser Dateianforderungen, und es ist einfach, den Fehler im Browser zu erzeugen Melden Sie sich bei meinen Servern an, fordern Sie die Datei an und erhalten Sie zufällige Ergebnisse.

Ich werde so glücklich sein, wenn das Problem in meinem Ursprung seit krank in 1 Minute lösen, aber ich denke, es ist Google CDN Bug. Ich freue mich, wenn jemand mehr auf CDN-Technologie zurückgreifen kann, um mir oder einer anderen Person aus Google Cloud zu helfen.

BEARBEITEN:

Wie gesagt, dieser Fehler passiert im zufälligen Zeitrahmen, hier ist ein Video, das ich jetzt aufgenommen habe und das uns einen 'NO BUG TIME FRAME' zeigt. Wie Sie sehen können, ist jede Antwort komprimiert.

KEIN FEHLERZEITRAHMEN CDN VIDEO

EDIT2:

Hier ist ein Diagramm, das die Anzahl der Gzip- und nicht der Gzip-Antworten für einen einzelnen .css-URL-Test zeigt.

EDIT3:

Auf dem ersten Graphenbild sind die Linien stapelbar, hier ist der gleiche Graph ohne zu stapeln. Wie Sie sehen können, haben einige Stunden fast 100% keine gzip Antworten.

EDIT4:

Hier sind meine Herkunft geparste Protokolle für die gleiche CSS-Datei.

1060 Anfragen wurden mit einer Antwortgröße unter 100 KB beantwortet. 200,304,206 Antwortcodes. 32 Anfragen wurden mit einer Antwortgröße über 100 KB beantwortet. 200 und 206 Antwortcodes.

EDIT5:

Analysieren 1-7 April Protokolle hier sind einige zusätzliche Statistiken für einzelne. CSS-URL:

19803 CDN-Anfragen wurden mit & gt; 100KB (nicht gzip)

41004 CDN-Anfragen wurden mit & lt; 100 KB (gzip)

29 Cache Füllung vom Ursprung mit & gt; 100KB (nicht gzip)

924 Cache Füllung vom Ursprung mit & lt; 100 KB (gzip)

423 Cache-To-Cache füllen mit & gt; 100KB (nicht gzip)

2295 Cache-zu-Cache füllen mit & lt; 100 KB (gzip)

Ich bin überrascht, wie Cache-To-Cache füllt, ist sehr effektiv, erstaunlich.

LÖSUNG

Es gibt keinen Bug im Ursprung, nicht einmal in Google CDN. Problem ist, wenn Google CDN eine cache-fähige Entität ohne 'Vary: Accept-Encoding' erhält, wenn die Anfrage 'Accept-Encoding: gzip' nicht gesendet hat. Google CDN speichert diese unkomprimierte Antwort und überschreibt dann alle gespeicherten komprimierten Caches Entitäten .Wenn das nächste Mal versucht wird, eine Datei wie .css zu erhalten, wird Google CDN wie folgt antworten:

1. Ich habe diese Datei vom Ursprung erhalten und sie unterscheidet sich durch nichts.
2. Unkomprimierte Antwort senden.

Beachten Sie, dass Webserver nicht für das Senden von "Vary: Accept-Encoding" -Köpfen bei Anfragen konfiguriert sind, die keine "Accept-Encoding: gzip" -Kopfzeilen haben. Ich habe dies auf Litespeed, Apache, Nginx und Cloudflare Nginx getestet.

Ich empfehle Google-Team dringend, die Dokumentation zu diesem Thema zu aktualisieren. Es gibt eine Aussage über 'Vary-Header', aber niemand wird den Punkt bezüglich dieses Problems bekommen, da nicht ich, nicht Google First Level Support (ich hatte auch 20 Tage Kommunikation auf Google Problem Tracker mit zwei Google-Support-Personen), Stack-Overflow oder andere Person beantworten das Problem.

Zusätzlich steht in der Dokumentation:

Aber nichts, wenn die Anfrage keinen 'Vary'-Header hat.

So repariere ich es: