Google CDN zufällig nicht gzip Inhalt

Question

Ich brauche ein paar 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 reden 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 dient gzip Inhalt zufällig nicht vom Benutzer zu beenden. Also statt ~ 70KB laden sie 500KB Dateien herunter. Ich kann dieses Problem nicht direkt zu meinem Ursprung erzeugen, aber ich kann dieses Problem sehr einfach auf Google CDN erzeugen.

Es folgt ein Beispielanfrage an CDN:

Anfrage:

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 
Accept-Encoding:gzip, deflate, sdch, br 
Accept-Language:en-US,en;q=0.8,bg;q=0.6,hr;q=0.4,mk;q=0.2,sr;q=0.2 
Cache-Control:no-cache 
Connection:keep-alive 
Cookie: example 
Host: example.com 
Pragma:no-cache 
Upgrade-Insecure-Requests:1 
User-Agent:Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 

Antwort:

Accept-Ranges:bytes 
Age:58422 
Alt-Svc:clear 
Cache-Control:public, max-age=604800 
Content-Length:550158 
Content-Type:text/css 
Date:Tue, 04 Apr 2017 03:45:53 GMT 
Expires:Tue, 11 Apr 2017 03:45:53 GMT 
Last-Modified:Sun, 19 Mar 2017 01:50:22 GMT 
Server:LiteSpeed 
Via:1.1 google 

Wie Sie meinen Wunsch haben sehen können, accept-encoding: gzip-Header, aber ich erhalten Inhalt nicht gzip. Anstelle von 70KB erhalte ich 500KB. Beachten Sie auch Alter Header, das Objekt ist für 58422 Sekunden im Cache/existiert auf CDN! Hier

ist die gleiche Anforderung von einer anderen Maschine (US)

Anfrage:

:authority: xxx 
:method:GET 
:path:/wp-content/themes/365/style.css 
:scheme:https 
accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 
accept-encoding:gzip, deflate, sdch, br 
accept-language:en-US,en;q=0.8 
cache-control:no-cache 
cookie: xxx 
pragma:no-cache 
upgrade-insecure-requests:1 
user-agent:Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 

Antwort:

accept-ranges:bytes 
age:58106 
alt-svc:clear 
cache-control:public, max-age=604800 
content-encoding:gzip 
content-length:72146 
content-type:text/css 
date:Tue, 04 Apr 2017 03:49:28 GMT 
expires:Tue, 11 Apr 2017 03:49:28 GMT 
last-modified:Sun, 19 Mar 2017 01:50:22 GMT 
server:LiteSpeed 
status:200 
vary:Accept-Encoding 
via:1.1 google 

Wie Sie sehen, ich habe einen gzip Inhalt von meinen anderen Server.

Ich habe eine Tonne von HAR-Dateien und auch Videos, die ich diesen Bug beweisen, aber lassen Sie es einfach bleiben. Google CDN-Protokolle sind im GCP-Dashboard verfügbar. Überprüfen Sie, wie sie aussehen.

Wenn alle meine Besucher gzip nicht unterstützt, was GoogleBot?

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

Temporary lösen das Problem

Wenn ich den CDN-Cache löschen, dieses Problem existiert nicht in der 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 analysiert und mir Graphen zeigt, das ist eigentlich, wie ich diesen Bug entdecke.

Immer, wenn ich Diagramm Bandbreitenerhöhung (Doppel als normal) zu sehen, wenn ich in Google Dashboard anmelden und Protokolle überprüfen, finde ich diese 500KB Protokolle wie 50% der Dateianforderungen, und es `s einfach zu Erzeugen Sie den Fehler im Browser, ich logge mich einfach bei meinen Servern ein, fordere die Datei an und erhalte zufällige Ergebnisse.

Ich bin so glücklich, 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 in die CDN-Technologie einsteigen wird, um mir oder einer anderen Person aus Google Cloud zu helfen.

EDIT:

Wie gesagt, geschieht dieser Fehler in zufälligem Zeitrahmen, hier ist ein Video, das ich nun festgehalten, dass uns zeigen, ein 'NO BUG TIME FRAME'. Wie Sie sehen können, ist jede Antwort komprimiert.

NO BUG TIME FRAME CDN VIDEO

EDIT2:

Hier ist ein Graph, die Anzahl von gzip zeigt und nicht die Antworten für einen einzelnen CSS-URL-Test gzip.

EDIT3:

Auf dem ersten Graph Bild sind Linien-Stack-fähig, hier ist die gleiche grafische Darstellung ohne stapeln. Wie Sie sehen können, haben einige Stunden fast 100% keine gzip Antworten.

Edit4:

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

1060 Anforderungen 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:

Analyse 1-7 April Protokolle sind hier einige zusätzliche Statistiken für einzelne CSS-url:

19803 CDN-Anfragen mit> 100 KB serviert wurden (nicht gzip)

41004 CDN-Anforderungen wurden mit < 100KB (gzip)

29 Cache Fill von orig mit> 100 KB (nicht gzip)

924 Cache von Herkunft Füllen mit < 100KB (gzip)

423 Cache-To-Cache füllt mit> 100 KB (nicht gzip)

2295 Cache-To- Cache füllen mit < 100KB (gzip)

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

SOLUTION

Es gibt keine Fehler 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 alle gespeicherten komprimierten Cache-Entitäten . Also nächstes Mal, wenn Benutzer versuchen, einige Datei zum Beispiel. CSS zu bekommen, wird Google CDN antworten wie:

Ich habe diese Datei aus dem Ursprung und seine nicht durch nichts variieren.

Unkomprimierte Antwort senden.

Beachten Sie, dass Webserver nicht für das Senden von 'Vary: Accept-Encoding'-Headern bei Anforderungen konfiguriert sind, die keine' Accept-Encoding: gzip 'Header haben. Ich habe dies auf Litespeed, Apache, Nginx und Cloudflare Nginx getestet.

Ich empfehle Google-Team, die Dokumentation zu diesem 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 ist die Dokumentation sagt:

In addition to the request URI, Cloud CDN respects any Vary headers that instances include in responses. 

aber nichts, wenn Anfrage nicht 'Vary' Header hat. Diese

ist, wie ich es beheben:

<FilesMatch '.(js|css|xml|gz|html|txt|xml|xsd|xsl|svg|svgz)$'> 
    Header merge Vary Accept-Encoding 
    </FilesMatch> 

Answer 1

Google Cloud CDN weder komprimiert noch dekomprimiert Antworten von Ihrer Herkunft. Stattdessen wird der Antwortkopf des Vary: Accept-Encoding-Antwortservers des Ursprungsservers berücksichtigt und es werden separate Varianten basierend auf dem Accept-Encoding-Anforderungsheader des Clients zwischengespeichert. Clients, die die gzip-Komprimierung unterstützen, sollten eine Variante erhalten, während Clients, die keine gzip-Komprimierung erhalten, eine andere erhalten sollten.

Das Problem ist, dass das Beispiel nicht komprimierte Antwort Sie die Vary bereitgestellt fehlt: Accept-Encoding-Header:

Accept-Ranges:bytes 
Age:58422 
Alt-Svc:clear 
Cache-Control:public, max-age=604800 
Content-Length:550158 
Content-Type:text/css 
Date:Tue, 04 Apr 2017 03:45:53 GMT 
Expires:Tue, 11 Apr 2017 03:45:53 GMT 
Last-Modified:Sun, 19 Mar 2017 01:50:22 GMT 
Server:LiteSpeed 
Via:1.1 google 

Die obige Antwort weist Cloud-CDN die unkomprimierte Variante für alle Clients zu verwenden, unabhängig davon, ob sie Unterstützt die Gzip-Komprimierung. Sobald eine Antwort ohne Header Vary: Accept-Encoding im Cache abgeschlossen ist, verwendet Cloud CDN diese zwischengespeicherte Antwort für alle Clients. Das Problem besteht darin, dass der Ursprungsserver einen Vary: Accept-Encoding-Header in seinen Antworten enthält.

Können Sie die Details zur Aktivierung der GZIP-Komprimierung teilen? Es scheint, dass Ihr Ursprungsserver manchmal den Header Vary: Accept-Encoding in seinen Antworten nicht enthält. Vielleicht enthält es diesen Header nicht, wenn er denkt, dass der Client die gzip-Komprimierung nicht unterstützt?