Progi kompresji HTTP: optymalne konfiguracje dla hostingu internetowego

Progi kompresji HTTP określają rozmiar, przy którym serwer kompresuje zawartość, a tym samym bezpośrednio kontrolują TTFB, obciążenie procesora i przepustowość. W tym przewodniku pokażę konkretne progi, poziomy i ustawienia nagłówków dla szybkiego dostarczania, a także wyraźny podział na kompresję dynamiczną i statyczną. Kompresja.

Punkty centralne

Najpierw podsumuję najważniejsze dostosowania, abyś mógł zacząć w ukierunkowany sposób i uniknąć marnowania niepotrzebnych cykli procesora. Polegam na jasnych progach, odpowiednich poziomach i czystych nagłówkach, aby przeglądarki, serwery proxy i sieci CDN działały poprawnie. Rozróżniam dynamiczne odpowiedzi od zasobów kompilacji i ściśle kontroluję kompresję na skok. Minimalizuję TTFB przy umiarkowanych poziomach kompresji runtime i uzyskuję maksymalną szybkość z plików wstępnie skompresowanych. Regularnie sprawdzam wskaźniki i dostosowuję limity do rzeczywistego obciążenia, miksu plików i opóźnień, dzięki czemu konfiguracja jest zauważalnie bardziej wydajna. szybciej wola.

• Próg 512-1024 B, standardowo 1024 B
• Pałeczka do chleba 3-4 dynamiczne, 9-11 statyczne
• Gzip 5-6 jako rozwiązanie awaryjne
• MIME Tylko zasoby tekstowe
• Różne i ETag na kodowanie

Czym są progi kompresji HTTP?

Próg określa rozmiar, powyżej którego odpowiedź jest kompresowana i zapobiega sztucznemu zawyżaniu niewielkich plików przez nagłówki. Próg rentowności-Rozważania. W przypadku bardzo małych odpowiedzi kodowanie treści może zwiększyć ładunek i jednocześnie kosztować procesor. Dlatego zwykle ustawiam dolny limit na 1024 bajty lub 512 bajtów dla interfejsów API o wysokiej częstotliwości z wieloma małymi odpowiedziami. Mniejsze progi zwiększają współczynnik kompresji, ale zwiększają TTFB i procesor, gdy zawartość dynamiczna jest bardzo zmienna. Większe progi oszczędzają czas obliczeniowy, ale ryzykują zmarnowanie potencjału w przypadku średniej wielkości plików HTML, CSS lub JSON, które są dobrej jakości. Redukcja Zysk.

Brotli vs. Gzip: wybór i poziomy

Brotli często osiąga o 15-21 procent lepsze wyniki niż Gzip dla zasobów tekstowych, ale kosztuje więcej procesora na żądanie, co biorę pod uwagę w przypadku dynamicznych odpowiedzi i używam umiarkowanych poziomów. poduszka. Do kompresji runtime używam Brotli poziom 3-4, dla wstępnie spakowanych zasobów poziom 9-11. Dla starszych klientów lub mocno zmieniającej się zawartości używam Gzip poziom 5-6. HTTP/2 i HTTP/3 korzystają z dobrej kompresji, o ile bufory serwera i punkty spłukiwania są ustawione poprawnie i nie dochodzi do przeciągnięć strumienia. Jeśli chcesz dokonać głębszego porównania, możesz znaleźć więcej informacji w moim artykule Porównanie Gzip vs. Brotli dodatkowe praktyczne wartości i względy, które decydują o wyborze w codziennym hostingu ułatwienie.

Ustawianie progów: Bariery ochronne i próg rentowności

Zaczynam od 1024 bajtów jako podstawowego progu, ponieważ narzut nagłówka jest wtedy wyraźnie rekompensowany, a użycie procesora pozostaje rozsądne, szczególnie w przypadku HTML i JSON, które znacznie się różnią. kondensować opuścić. Przy sieciach o bardzo małych opóźnieniach i wielu minimalnych odpowiedziach API, 512 bajtów może być użyteczne. Kompresja rzadko jest opłacalna poniżej 512 bajtów, ponieważ koszty administracyjne często przekraczają redukcję obciążenia. W przypadku intensywnie wykorzystywanych maszyn, tymczasowo zwiększam próg, aż zbiorniki procesora znów będą miały bufory. Ta stopniowa regulacja utrzymuje TTFB na niskim poziomie i zachowuje Stabilność całego systemu.

Kompresuj w szczególności typy MIME

Kompresuję tylko tekstowe pliki MIME, takie jak text/html, text/css, application/javascript, application/json i image/svg+xml, ponieważ mogą one być używane ze względu na nadmiarowość. Wygrane drag. Pozostawiam zawartość binarną, taką jak image/*, application/pdf lub font/woff2 nietkniętą, ponieważ efekt jest niewielki lub ujemny. W przypadku czcionek używam bezpośrednio WOFF2, ponieważ już koduje wydajnie i dalsza kompresja jest mało przydatna. Utrzymuję wyraźne listy dozwolonych plików i unikam symboli wieloznacznych, aby żadne pliki binarne przypadkowo nie trafiły do kodera. W ten sposób utrzymuję łańcuch kompresji w czystości i zapobiegam Korupcja z powodu błędnej klasyfikacji.

Statyczne vs. dynamiczne: czysta separacja

Pakuję zasoby statyczne w procesie kompilacji lub na krawędzi CDN z wyprzedzeniem jako .br i .gz i pozwalam serwerowi bezpośrednio korzystać z tych wariantów. dostarczać. W przypadku dynamicznych odpowiedzi ustawiam umiarkowane poziomy i utrzymuję bufory na tyle małe, że pierwszy blok bajtów przepływa szybko. Ważne jest, aby kompresować tylko jeden przeskok w łańcuchach proxy, aby uniknąć podwójnej kompresji. Mogę wyłączyć kompresję w Origin, jeśli CDN już to zrobił i poprawnie oddzielił ją za pomocą Vary. Taka separacja oszczędza procesor i zapewnia stały Czasy reakcji nawet pod obciążeniem.

Zarządzanie nagłówkami i buforowanie

Zawsze wysyłam Vary: Accept-Encoding, aby pamięci podręczne poprawnie rozróżniały warianty i nie było żadnych pominięć, które spowalniają użytkowników lub fałszują zasoby; ten nagłówek to decydujący. Dla plików statycznych ustawiam kodowanie zawartości (br/gzip) plus długość zawartości, podczas gdy strumienie dynamiczne często działają z kodowaniem transferu: chunked. ETagi muszą być specyficzne dla kodowania, w przeciwnym razie pamięć podręczna dostarczy nieprawidłowe wersje. Ustawiam również długie TTL pamięci podręcznej dla wstępnie skompresowanych zasobów i zabezpieczam je za pomocą kontroli pamięci podręcznej: publiczne, niezmienne, jeśli skróty plików znajdują się w nazwie. Podaję tutaj kompaktowy punkt wyjścia: Konfiguracja kompresji HTTP, najważniejsze elementy składowe w Sekwencja pokazy.

HTTP/2 i HTTP/3: spłukiwanie i buforowanie

W przypadku HTTP/2 i HTTP/3 zwracam uwagę na wczesne punkty spłukiwania, aby krytyczny HTML i CSS nie opóźniały rozpoczęcia renderowania. opóźnienie. Zbyt duże bufory mogą spowolnić multipleksowanie, ponieważ jeden strumień dominuje w harmonogramie, a inna zawartość czeka. Pierwsze bloki kompresji powinny być małe i wysyłane szybko, a następnie zwiększane w przypadku długich plików. Brotli pokazuje dobre prędkości z umiarkowanym narzutem, o ile poziom 3-4 jest używany do dynamicznych odpowiedzi. Pozwala to utrzymać wysoką interaktywność, a duże pakiety są wydajne. kurczyć się.

Praktyka: Apache, Nginx, Caddy

Zaczynam od umiarkowanych poziomów i progu 1024 bajtów, a następnie systematycznie sprawdzam TTFB i CPU zamiast ślepo ustawiać maksymalne prędkości. egzekwować. W Apache aktywuję mod_deflate lub mod_brotli i definiuję tylko pożądane typy MIME. W Nginx ustawiam gzip_min_length 1024 i Brotli na on, łącząc to z brotli_static dla wstępnie skompresowanych plików. Caddy oferuje proste przełączniki z kodowaniem gzip zstd br; osobno obsługuję ścieżki dynamiczne z niskimi poziomami. Z doświadczenia warto przyjrzeć się Obciążenie procesora i poziom kompresji, ponieważ połączenie proporcji odpowiedzi dynamicznych i liczby rdzeni często przekracza limit. zestawy.

Apacz Przykład (mod_deflate/mod_brotli):

AddOutputFilterByType DEFLATE text/html text/css application/javascript application/json image/svg+xml
 SetOutputFilter DEFLATE
 DeflateCompressionLevel 6
 DeflateBufferSize 64k



 AddOutputFilterByType BROTLI_COMPRESS text/html text/css application/javascript application/json image/svg+xml
 BrotliCompressionQuality 4
 BrotliWindowSize 22

Nginx Przykład:

gzip włączony;
gzip_min_length 1024;
gzip_types text/plain text/css application/json application/javascript image/svg+xml;
gzip_comp_level 5;

brotli on;
brotli_comp_level 4;
brotli_static on;
brotli_types text/plain text/css application/json application/javascript image/svg+xml;

Monitorowanie i rozwiązywanie problemów

Mierzę TTFB, wykorzystanie procesora na pracownika i rozmiar transferu na typ, dzięki czemu mogę zobaczyć, gdzie kompresja pomaga, a gdzie jest potrzebna. szkody. Jeśli TTFB wzrasta po aktywacji, obniżam poziom lub podnoszę próg. Jeśli występują jakieś dziwne efekty, najpierw sprawdzam podwójną kompresję, brakujące nagłówki Vary lub nieprawidłowo rozpoznane typy MIME. Przyglądam się również politykom CDN i WAF, ponieważ drugi przeskok z kompresją przesuwa obciążenie i często pogarsza czas do pierwszego bajtu. Narzędzia takie jak WebPageTest i Browser-DevTools są wystarczające do wstępnego sprawdzenia. Audyt całkowicie.

Punkty pomiarowe i zalecane wartości

Trzymam się kilku jasnych parametrów, dzięki czemu konfiguracja pozostaje łatwa w zarządzaniu i nadal osiąga wysoki poziom jakości. Efekt pokazuje. Poniższa tabela podsumowuje przydatne progi, poziomy i instrukcje buforowania. Obejmuje ona typowe stosy internetowe z HTML, CSS, JS, JSON, SVG i czcionkami. Dostosuj próg w zależności od obciążenia, rezerwuaru procesora i proporcji dynamicznych odpowiedzi. Zacznij konserwatywnie, zmierz i iteracyjnie przesuwaj suwaki w małych krokach. Kroki.

Zasoby	Próg (bajty)	Dynamiczny (poziom)	Statyczny (poziom)	Wskazówka dotycząca pamięci podręcznej
HTML	1024	Br 3–4 / Gz 5–6	Br. 9-11 (wstępnie skompresowane)	Długi TTL dla nazw hash
CSS/JS	1024	Rzadko dynamiczny	Br. 9-11 (wstępnie skompresowane)	niezmienny, warianty na hash
JSON (API)	512-1024	Br 3–4 / Gz 5–6	nie jest to powszechne	Zachowaj spójność nagłówków
SVG	1024	Rzadko dynamiczny	Br 9–11	Żądania zakresu testowego
Czcionki (WOFF2)	brak	brak	brak	Nie ściskać dalej
Obrazy (PNG/JPEG/WEBP)	brak	brak	brak	Oddzielna optymalizacja
PDF	brak	brak	brak	Unikaj kodowania

Zstd w kontekście: kiedy ma sens, a kiedy nie

Oceniam Zstd niezależnie, ponieważ ma doskonałe Przepustowość z dobrą kompresją. W środowisku przeglądarki obsługa jest jednak niejednorodna, dlatego zwykle nie wdrażam Zstd jako głównego kodowania dla użytkowników końcowych. Pomiędzy usługami wewnętrznymi lub na trasie szkieletowej CDN, Zstd może być bardzo przydatny do utrzymania wydajności ruchu Origin CDN. Na obrzeżach trzymam się Brotli (dla tekstu) i Gzip jako rozwiązania awaryjnego, dopóki szeroko obsługiwana baza klientów nie zapewni, że warianty są negocjowane poprawnie. W Caddy pozostawiam opcjonalnie aktywne Zstd, ale nadaję priorytet protokołowi Negocjacje Brotli przed Gzip, aby zrównoważyć kompatybilność i wydajność.

Żądania zasięgu, pobieranie i wstępnie skompresowane pliki

Duże pliki do pobrania (np. PDF, CSV) sprawdzam osobno. W przypadku danych binarnych zazwyczaj wyłączam kodowanie treści i dostarczam tożsamość (tożsamość), aby żądania zasięgu działały poprawnie, a wznowione pobieranie pozostało stabilne. W przypadku statycznych plików tekstowych z wariantami .br/.gz zapewniam, że serwer wybiera prawidłowy wariant w zależności od żądania klienta oraz że długość zawartości, kodowanie zawartości i ETag są spójne. W przypadku częściowych żądań dla skompresowanych wariantów, zakresy bajtów dla opcji skompresowany length - jeśli stos nie obsługuje tego solidnie, dostarczam nieskompresowaną wersję dla żądań zakresu. Łagodzi to przypadki brzegowe i zapobiega nieprawidłowym restartom.

Bezpieczeństwo: kompresja i wycieki danych

Biorę pod uwagę kanały boczne związane z kompresją, takie jak BREACH. Jeśli odpowiedzi odzwierciedlają zawartość zależną od sekretów (tokeny, identyfikatory sesji) w pobliżu danych wejściowych, które mogą być kontrolowane przez atakującego, selektywnie wyłączam kompresję lub odłączam sekrety (wypełnianie, rozdzielanie na osobne nieskompresowane pola). W przypadku ścieżek logowania i płatności sensowne jest wyłączenie kompresji za pomocą nagłówków lub reguł. Pliki cookie z ustawionymi nagłówkami plików cookie nie są krytyczne, ważne jest to, co jest w nich zawarte. Odpowiedź-payload. Dlatego mam gotowe filtry, które są ukierunkowane na ścieżkę, MIME lub określone szablony, aby łatwo wymusić heurystykę.

Łańcuchy CDN i proxy: jedna kompresja na przeskok

Wyraźnie definiuję skok, przy którym następuje kompresja: Albo w Krawędź (CDN) lub w Origin, nie w obu. Jeśli CDN kompresuje, pomijam kodowanie treści w Origin i wysyłam Vary: Accept-Encoding, aby Edge tworzył poprawne warianty. Jeśli Origin ma dostarczać wstępnie skompresowane zasoby (.br/.gz), konfiguruję Edge, aby wysyłał te pliki do CDN. Przezroczysty i nie przekształca go ponownie. Jeśli chcę ściśle zapobiegać przekształceniom przez pośrednie serwery proxy (np. w celu zapewnienia zgodności), ustawiam Cache-Control: no-transform - wtedy planuję kompresję specjalnie w źródle. Dla celów debugowania, odnotowuję, który hop the Kompresja i utrzymywać metryki oddzielnie dla każdego przeskoku.

Streaming, SSE, gRPC i WebSockets

W przypadku zdarzeń wysyłanych przez serwer (SSE) i podobnych strumieni unikam wysokich poziomów i duży bufor; w przeciwnym razie opóźnienie zauważalnie wzrośnie. Używam małych bloków, częstego płukania i bardziej wyłączonej kompresji, jeśli priorytetem jest interaktywność. gRPC używa własnej kompresji wiadomości i działa przez HTTP/2 - tutaj unikam dodatkowego kodowania treści HTTP, aby zapobiec duplikacji. To samo dotyczy WebSockets: per-message deflate może być przydatny, ale włączam go tylko dla naprawdę ciężkich tekstowo kanałów i monitoruję CPU-dokładnie.

Serwer aplikacji: Ustawienia warstwy aplikacji

Wolę kontrolować progi w edge/reverse proxy, ale gdy frameworki kompresują, ustawiam spójne wartości, aby nic nie działało przeciwko sobie.

• Node.js/ExpressUstawiłem próg 1024 bajtów i umiarkowane poziomy. Obsługa statyczna obsługuje bezpośrednio wstępnie skompresowane zasoby statyczne, kompresuję tylko trasy dynamiczne dla tekstowych MIME.
• Wejdź na stronęWybieram jasną listę dozwolonych MIME dla każdej obsługi i pomijam kompresję poniżej 1 KB. W przypadku długich strumieni, utrzymuję niskie wartości write flush, aby nie przeciążać pierwszego paint'a. opóźnienie.
• Java/TomcatUżywam compressionMinSize 1024 i jawnie utrzymuję listę MIME; typy binarne są pomijane.

Tomcat Przykład (server.xml Connector):

<Connector port="8080" protocol="HTTP/1.1"
    compression="on"
    compressionMinSize="1024"
    noCompressionUserAgents=""
    compressableMimeType="text/html,text/css,application/javascript,application/json,image/svg+xml"
    URIEncoding="UTF-8" />

Ważne: Jeśli serwer proxy (Nginx, Caddy) już kompresuje, dezaktywuję kompresję warstwy aplikacji w celu Powielanie pracy i niech tylko jedna warstwa ponosi odpowiedzialność.

Adaptacyjne progi i kontrola obciążenia

Myślę w kategoriach polityki zamiast sztywnych wartości. Przy dużym obciążeniu procesora podnoszę Próg tymczasowo (np. z 1024 do 2048 bajtów) lub obniżyć poziom Brotli (np. z 4 do 2) dla dynamicznych odpowiedzi. Jeśli obciążenie spadnie, ponownie zwiększam wartości. Można to kontrolować za pomocą flagi funkcji, zmiennych Env lub prostego przeładowania. Na węzłach z małą ilością CPU rezerwuję kompresję dla najważniejszych MIME (HTML/JSON), podczas gdy CSS/JS są prawie wyłącznie wstępnie skompresowane z pamięci masowej/CDN. To Ustalanie priorytetów utrzymuje TTFB na stabilnym poziomie, zamiast przechylać się w kierunku szczytów.

Podręcznik testowy: szybka weryfikacja

Sprawdzam efekt za pomocą kilku powtarzalnych kroków:

• Negocjacje: curl -I -H „Accept-Encoding: br“ https://example.com - sprawdź Content-Encoding, Vary i Content-Length.
• Fallback: curl -I -H „Accept-Encoding: gzip“ - oczekiwany gzip? ETag różni się od Brotli?
• Bez kompresjicurl -I -H „Accept-Encoding: identity“ - Porównaj różnicę wielkości i TTFB.
• Zasięg: curl -I -H „Range: bytes=0-1023“ - czy serwer poprawnie akceptuje podzakresy i czy Content-Range pasuje?
• DevToolsPorównanie rozmiaru „w sieci“ z „rozmiarem zasobu“ w celu określenia rzeczywistego Oszczędności zobaczyć.

Krótkie podsumowanie

Ustaw próg na 1024 bajty jako szybki punkt wyjścia, sprawdź TTFB i CPU i dostosuj ustawienia za pomocą małych wartości. Korekty po. Używaj Brotli 3-4 dla dynamicznej zawartości i 9-11 dla wstępnie skompresowanych zasobów, zachowaj Gzip 5-6 jako rozwiązanie awaryjne. Kompresuj tylko tekstowe MIME i dostarczaj wstępnie skompresowane pliki bezpośrednio, aby zachować lekkość i trwałość zasobów kompilacji. Zwróć uwagę na Vary: Accept-Encoding, Content-Encoding i ETags specyficzne dla kodowania, aby pamięci podręczne działały poprawnie. Dzięki odpowiednio ustawionym progom kompresji HTTP można znacznie przyspieszyć dostarczanie bez obciążania maszyny niepotrzebną pracą obliczeniową. blok.