Hosting dla aplikacji strumieniowych: Optymalizacja przepustowości i opóźnień

Hosting strumieniowy decyduje o tym, czy strumienie działają bez zacinania się: Planuję przepustowość na strumień i zmniejszam opóźnienia za pomocą odpowiednich protokołów, bliskości krawędzi i czystego peeringu. Z wyprzedzeniem obliczam szczyty obciążenia, wybieram wydajne kodeki i minimalizuję ścieżki pakietów, aby widzowie widzieli stabilną jakość w czasie rzeczywistym.

Punkty centralne

Podsumowuję najważniejsze dźwignie dla Szerokość pasma oraz Opóźnienie dzięki czemu można niezawodnie planować obciążenia związane z transmisją strumieniową. Zaczynam od określonych przepływności dla rozdzielczości, ekstrapoluję obciążenie widzów i ustalam marginesy bezpieczeństwa. Następnie omawiam sposoby zmniejszenia opóźnień, od protokołów po ścieżki sieciowe. Pokazuję warianty hostingu o wysokiej wydajności netto i wyjaśniam, w jaki sposób sieci brzegowe i CDN niwelują opóźnienia. Na koniec przedstawiam praktyczne kroki, które można podjąć w celu sprawdzenia wydajności, zaplanowania kosztów i zapewnienia jakości w perspektywie długoterminowej.

• Szerokość pasma Prawidłowe obliczenia
• Opóźnienie konsekwentnie zmniejszać
• Protokoły wybrać odpowiedni
• Edge/CDN Wykorzystaj strategicznie
• Monitoring Ciągłe wdrażanie

Przepustowość i opóźnienia: co tak naprawdę się liczy?

Dokonuję wyraźnego rozróżnienia między Szerokość pasma oraz Opóźnienie, ponieważ obie zmienne tworzą różne wąskie gardła. Przepustowość określa, ile i jak wysokiej jakości strumieni działa jednocześnie. Opóźnienie kontroluje czas dotarcia treści i płynność interakcji. W przypadku treści na żądanie przepustowość jest najważniejszym czynnikiem; w przypadku treści na żywo i interaktywnych decydujące znaczenie ma opóźnienie. Od około 60 ms zauważysz opóźnienia w reakcjach, w przypadku gier i czatu na żywo dążę do mniej niż 50 ms.

Zapotrzebowanie na przepustowość na rozdzielczość i liczbę widzów

Obliczam przepływność na jakość i biorę pod uwagę kodek oraz Nad głową. H.264 jest standardem, HEVC często pozwala zaoszczędzić nawet połowę. Ustawiam rezerwę 20 % na bufory, aby krótkie szczyty obciążenia nie spadały natychmiast. Jeśli jest wielu równoległych widzów, dodaję wybrany bitrate na strumień i mnożę go przez liczbę jednoczesnych widzów. W przypadku ABR planuję obciążenie oddzielnie dla każdego poziomu jakości i ważę je zgodnie z rzeczywistymi udziałami użytkowania.

Rozdzielczość	H.264 (Mbit/s)	H.265/HEVC (Mbit/s)	Zalecane (Mbit/s)
720p (HD)	3-5	2-3	5
1080p (Full HD)	5-10	3-5	10
4K (Ultra HD)	25-35	15-25	50
8K	>100	50–60	100

Przykład uczyni to namacalnym: 500 jednoczesnych widzów przy 1080p z 5 Mbit/s daje 2,5 Gbit/s, z 20 buforami % kończę z około 3 Gbit/s. Dla wydarzenia 4K z 1000 widzów i 25 Mbit/s, obliczam 30 Gbit/s z uwzględnieniem bufora. W przypadku ABR podzieliłem dystrybucję, około 40 % 720p i 60 % 1080p, aby przewidzieć realistyczne obciążenie. Po stronie gospodarstwa domowego wystarczy 3-5 Mbit/s dla SD/HD, 10 Mbit/s dla Full HD i 25 Mbit/s dla 4K na strumień. Przy łączu w dół o przepustowości 1 Gbit/s, mogę obsłużyć ponad 60 strumieni w 4K równolegle, o ile domowa sieć LAN nie jest ograniczona.

Planowanie wydajności z formułą i przykładami

Używam prostego wzoru: Całkowita przepustowość = (bitrate na strumień × jednoczesni widzowie) × 1,2. Współczynnik 1,2 obejmuje bufory dla krótkoterminowych szczytów. W przypadku ABR obliczam każdy poziom osobno i sumuję wyniki, aby żaden poziom jakości nie stał się pułapką. Ważne: Zaplanuj dodatkowe rezerwy na miniatury, wywołania API, czat i metryki, które mogą kosztować dodatkowe 5-10 %. Od około 5 Gbit/s zalecam porty 10 Gbit, aby mieć zapas na skoki i retransmisje.

Wcześnie też zwymiarowałem upstream, ponieważ upload dla Na żywo pozostaje kluczowa. W przypadku platform UGC obliczam liczbę twórców po stronie pozyskiwania i dodaję wystarczającą pojemność transkodowania do jednoczesnego kodowania. W przypadku wydarzeń krajowych rozkładam kilka punktów PoP, aby skrócić odległości. W przypadku wydarzeń międzynarodowych łączę lokalizacje brzegowe na głównych rynkach. Dzięki temu obciążenie jest kontrolowane, a opóźnienia niskie.

Strategie zmniejszania opóźnień

Zmniejszam opóźnienie poprzez Ścieżki zwięzłość i Bufor smart. Krótszy RTT ze względu na bliskie lokalizacje działa szybciej niż jakiekolwiek ulepszenia procesora. Minimalizuję przeskoki poprzez dobry peering i redukuję kolejki w wąskich gardłach. W odtwarzaczu ustawiam małe segmenty dla HLS/DASH o niskim opóźnieniu i optymalizuję bufory startowe. W przypadku interakcji w czasie rzeczywistym nadaję priorytet WebRTC i unikam powolnych serwerów proxy.

Zwracam uwagę na czyste wartości MTU, aktywuję BBR lub CUBIC, aby dopasować ścieżkę i uniknąć bufferbloat po stronie klienta. Przyspieszam uściski dłoni TLS za pomocą metody 1-RTT i wznawiania sesji. Pamięci podręczne na brzegu sieci dostarczają segmenty szybciej, podczas gdy tylko pozyskiwanie i pochodzenie pozostają scentralizowane. Oznaczenia QoS pomagają we własnych sieciach, ścieżki publiczne korzystają z dobrego routingu. Oznacza to, że każdy pakiet szybciej dociera do odbiorcy.

Protokoły i ich przydatność

Wybieram protokół zgodnie z Przypadek użycia oraz Tolerancja dla opóźnień. WebRTC jest odpowiedni dla opóźnień i interakcji poniżej sekundy, podczas gdy LL-HLS i LL-DASH są odpowiednie dla dużych wydarzeń na żywo o zasięgu milionów. Standardowy HLS pozostaje silny dla VoD i konserwatywnych przepływów pracy. Dzielę według potrzeb: Interakcja przez WebRTC, masowa transmisja przez LL-HLS. Wydarzenia z czatem korzystają z 2-4 sekund end-to-end, ponieważ moderacja i synchronizacja działają wtedy dobrze.

Protokół	Opóźnienie (sekundy)	Zakres zastosowania
WebRTC	< 1	Transmisja strumieniowa w czasie rzeczywistym
HLS o niskich opóźnieniach	2-3	Transmisja na żywo
DASH o niskim opóźnieniu	2-4	Adaptacyjna transmisja strumieniowa
Standardowy HLS	6-30	VoD, klasyczna transmisja strumieniowa

W przypadku widzów ze zmiennymi połączeniami łączę protokół i ABR, aby skrócić czas uruchamiania i przyspieszyć przełączanie. Krótkie segmenty, HTTP/2 lub HTTP/3 i agresywne buforowanie opłacają się tutaj. Po stronie produkcyjnej utrzymuję transkodery blisko punktów pozyskiwania. Geostereowanie DNS automatycznie kieruje użytkowników do najlepszej krawędzi. Zapewnia to spójne wrażenia nawet w przypadku zmiany trasy.

Opcje hostingu: VPS, Dedykowany, Edge

Decyduję zgodnie z profil obciążenia oraz Możliwość planowania między zasobami VPS, dedykowanymi i brzegowymi. Instancje VPS zapewniają szybkie uruchamianie i elastyczne skalowanie; należy zwrócić uwagę na gwarantowane porty i dobre strefy peeringowe. Serwery dedykowane o przepustowości 10 Gbit/s lub większej są odpowiednie dla stałych, wysokich obciążeń, takich jak IPTV lub duże wydarzenia na żywo. Węzły brzegowe znacznie skracają czas dotarcia do widzów i odciążają Origin. W przypadku projektów międzynarodowych łączę centralny Origin, kilka brzegowych POP i CDN.

Wybierz taryfy z wystarczającą liczbą wyjść, bez twardego dławienia pod obciążeniem produkcyjnym. Nieopomiarowane porty są pomocne, o ile wydajność netto naprawdę istnieje. Sprawdzaj przepustowość netto zamiast tylko nominalnej prędkości portu i dokonuj pomiarów kilka razy dziennie. Poproś o testy tras na głównych rynkach. Tylko wtedy platforma będzie niezawodnie spełniać oczekiwania.

Lokalizacja, peering i CDN

Wybieram lokalizację w pobliżu Grupy docelowe i postawić na Podgląd z dużymi operatorami, aby skrócić odległości. Dobre połączenie IXP oszczędza przeskoki i zmniejsza straty pakietów. CDN przenosi segmenty na krawędź i chroni źródło przed szczytami. W przypadku wydarzeń regionalnych, brzegowy PoP zapewnia najlepszy stosunek ceny do wydajności na rynku docelowym. Więcej szczegółowych informacji na temat anycast, PoP i równoważenia obciążenia można znaleźć na stronie Technologie brzegowe.

Aktywuję geosteering i kontrole kondycji, aby ruch automatycznie kierował się do najlepszej instancji. Buforuję zasoby statyczne daleko z przodu, podczas gdy segmenty na żywo pozostają krótkotrwałe. Używam ciepłych pamięci podręcznych przed zdarzeniami dla szczytów połączeń. Wybieram umiarkowany DNS TTL, aby móc szybko dostosować routing. W ten sposób każde żądanie trafia tam, gdzie przepustowość i bliskość są odpowiednie.

Adaptacyjna szybkość transmisji, kodeki i bufory

Ustawiłem ABR dzięki czemu odtwarzacz elastycznie reaguje na wahania sieci. Wielokrotne renderowanie z wyraźnymi poziomami przepływności zapobiega przerwom w odtwarzaniu i zapewnia stabilność odtwarzania. HEVC lub AV1 znacznie zmniejszają wymaganą przepustowość na poziom, pod warunkiem, że urządzenia obsługują ten format. Testuję profile drabinkowe w terenie i skracam poziomy, które użytkownicy rzadko wybierają. Jeśli chcesz zagłębić się w temat, możesz znaleźć przegląd Adaptacyjna szybkość transmisji.

Utrzymuję mały bufor początkowy, aby wideo było odtwarzane szybko, ale zwiększam go nieznacznie w przypadku długich sesji. Ustawiam odstępy między klatkami kluczowymi, aby przełączanie odbywało się szybko. Zarządzam długością segmentu w zależności od protokołu; jeśli zmienia się opóźnienie, dostosowuję je. W przypadku sieci mobilnych wybieram niższe poziomy przy ścisłej kompresji. Pozwala to zachować równowagę między czasem uruchomienia, stabilnością i jakością.

Dostrajanie sprzętu i stos systemu operacyjnego

Wybieram profile CPU z silnymi Pojedynczy rdzeń oraz AVX-wsparcie dla kodowania. Więcej rdzeni pomaga przy transkodowaniu wielu renderingów, podczas gdy wysokie częstotliwości taktowania liczą się w przypadku potoków na żywo. Planuję duże rozmiary pamięci RAM dla buforów i pamięci podręcznych. Pamięć masowa NVMe zmniejsza opóźnienia dla segmentów I/O. W systemie operacyjnym dostosowuję balans IRQ, zwiększam bufory gniazd i starannie konfiguruję odciążanie TCP.

Mierzę wydajność PPS kart sieciowych i aktywuję RSS, aby obciążenie było rozłożone na rdzenie. Używam stosu obserwowalności opartego na eBPF do rozpoznawania spadków na wczesnym etapie. Organizuję kontenery tak, aby transkodery działały blisko pozyskiwania. Dla węzłów brzegowych definiuję małe, szybkie obrazy z wyraźnymi kontrolami stanu. Dzięki temu stos jest zwinny i skalowalny.

Zarządzanie przepustowością i planowanie kosztów

I link Koszty oraz Ruch uliczny, dzięki czemu budżet pozostaje przewidywalny. Opłaty za wysyłkę często dominują w rachunku, dlatego korzystam z buforowania i dostawy regionalnej. Symuluję dni szczytu i negocjuję zniżki od jasnych wartości progowych. Aby zapewnić bezpieczeństwo cenowe, używam pakietów z wystarczającą ilością ruchu. Wprowadzenie do kwot, rezerw i równoważenia obciążenia można znaleźć w artykule na stronie Zarządzanie przepustowością.

Porównuję nominalną szybkość portu z trwałą przepustowością pod obciążeniem. Tymczasowo rezerwuję dodatkowe porty lub opcje burst na potrzeby wydarzeń. Minimalizuję ruch źródłowy za pomocą stopniowanych czasów TTL i regionalnych ponownych źródeł. W przypadku umów partnerskich sprawdzam opłaty wyjściowe i kredyty SLA. Dzięki temu obliczenia są realistyczne, nawet jeśli popyt rośnie szybciej niż oczekiwano.

Monitorowanie i testowanie

Mierzę QoE oraz QoS oddzielone w celu wyraźnego przypisania przyczyn. Metryki graczy, takie jak czas uruchamiania, współczynnik odbicia i przełączniki ABR, pokazują, co odczuwają użytkownicy. Wskaźniki sieciowe, takie jak RTT, straty i jitter, wyjaśniają, dlaczego tak się dzieje. Przed wydarzeniami przeprowadzam syntetyczne testy obciążenia z kilku regionów. Po wydarzeniu koreluję dzienniki, aby trwale wyeliminować wąskie gardła.

Używam pulpitów nawigacyjnych z mapami cieplnymi według regionu, dostawcy usług internetowych i urządzenia. Uruchamiam alerty przy limitach SLO, takich jak współczynniki rebuffer powyżej 1 %. Przygotowuję trasy awaryjne i regularnie je testuję. Planuję okna wydań poza godzinami szczytu. Dzięki temu operacje są przewidywalne, a zakłócenia ograniczone do minimum.

Wysoka dostępność i redundancja w czasie rzeczywistym

Planuję po stronie spożycia N+1 dwa kodery na źródło (aktywny/aktywny lub aktywny/pasywny) i podwójne punkty końcowe pozyskiwania w oddzielnych strefach. Używam Origins w parze z Gorący tryb gotowości plus Origin‑Shield przed nim, aby CDN nie szturmował bezpośrednio głównego źródła. Kontrole stanu, krótkie czasy przełączania awaryjnego i czysta replikacja stanu (sesje/manifesty) utrzymują przełączenia poniżej jednej sekundy. W przypadku krytycznych zdarzeń symuluję awarie za pomocą testów chaosu, aby podręczniki były na miejscu, a ludzie i systemy reagowały niezawodnie.

Na poziomie sieci używam Podwójny upstream (dwóch operatorów, oddzielne trasy) i różne IXP. Przełączanie awaryjne DNS jest moją ostatnią linią; wcześniej krawędzie anycast działają z kierowaniem BGP. Zapewniam redundantne klastry TURN dla WebRTC, ponieważ NAT traversal nie jest gwarantowany bez TURN. Reguła: Każdy pojedynczy komponent może zawieść bez zauważenia przez widzów.

Bezpieczeństwo, DRM i ochrona dostępu

Chronię strumienie za pomocą TLS (PFS), krótkie czasy uruchamiania certyfikatów i HSTS. Zabezpieczam dostęp poprzez podpisane adresy URL/tokeny z powiązaniem IP i krótką ważnością. Filtry geograficzne i ASN blokują nadużycia, a ochrona przed hotlinkami zapobiega osadzaniu poza autoryzowanymi domenami. W przypadku treści premium używam DRM (Widevine/FairPlay/PlayReady) na urządzenie docelowe. Kryminalistyczne znaki wodne identyfikuje wycieki bez uszczerbku dla QoE. A WAF filtruje ataki warstwy 7, podczas gdy ataki objętościowe są odrzucane przez centra oczyszczania DDoS. Automatycznie obracam klucze i przechowuję sekrety poza obrazami.

Minimalizuję powierzchnię ataku w Origin: otwarte tylko niezbędne porty, limity szybkości dla punktów końcowych API, oddzielne konta usług z najmniejszymi uprawnieniami. Pseudonimizuję dzienniki, aby chronić prywatność danych i utrzymywać krótkie okresy przechowywania.

WebRTC w szczegółach: skalowanie i jakość

W kwestii interakcji polegam na Topologie SFU, ponieważ łączą przepustowość z serwerem i selektywnie odtwarzają ją widzom. Simulcast/SVC zapewnia kilka poziomów jakości bez ponownego kodowania. ICE Używam STUN/TURN, aby zapewnić, że klienci pracują za NAT-ami klasy operatorskiej. Kontrola przepustowości jest obsługiwana przez Kontrola przeciążenia (GCC/SCReaM) w połączeniu z parametrami kodeka (maxBitrate, maxFramerate). Ruch TURN budżetuję osobno, ponieważ szybko dominuje pod względem kosztów, jeśli peer-to-peer nie działa.

Utrzymuję opóźnienie od końca do końca na poziomie poniżej sekundy, utrzymując małe bufory jittera, nadając priorytet audio i tymczasowo kompresując wideo. W przypadku dużych formatów Q&A dzielę interakcję (WebRTC) i transmisję (LL-HLS) zarówno pod względem technicznym, jak i ekonomicznym.

Napisy, wielojęzyczność i dźwięk

Dostarczam Wielokanałowy dźwięk i kilka języków oddzielnie za pomocą wersji audio. Ustawiłem napisy jako WebVTT lub TTML, w tym CEA-608/708, aby zapewnić kompatybilność urządzeń. Zwracam uwagę na Lipsync między audio, wideo i napisami (ustaw PTS/DTS czysto) i zachowaj Głośność spójne (np. wartości docelowe EBU R128), aby przełączanie nie było irytujące. Aby ułatwić dostęp, zapewniam audiodeskrypcję i wysoki kontrast w odtwarzaczu.

W przypadku wydarzeń międzynarodowych rozdzielam ścieżki tłumaczenia: Ingest w oryginalnym języku, a następnie transkodowanie i MUX dla każdego języka docelowego osobno. Pozwala to zachować błędy na poziomie lokalnym i przyspiesza odzyskiwanie.

Reklama i monetyzacja

Integruję reklamy za pośrednictwem SCTE-35-marker i ustaw na SSAI, gdy liczy się spójność urządzenia. W przypadku spersonalizowanych reklam łączę decyzje dotyczące krawędzi z wydajnością pamięci podręcznej (klucze pamięci podręcznej z klasami urządzeń zamiast pełnej personalizacji). CSAI gdzie kontrola i pomiar aplikacji muszą być bardziej szczegółowe. Mierzę QoE reklam oddzielnie (start reklamy, błąd, głośność, czas trwania) i chronię doświadczenie użytkownika za pomocą limitów czasu i kreacji awaryjnych.

Przejrzyste budżety reklamowe i limity zapobiegają eksplozji kosztów podczas szczytów. Ściśle synchronizuję bloki reklamowe, aby zapping i ponowne dołączenia przebiegały płynnie.

Przesunięcie czasowe, DVR i nagrywanie

Aktywuję DVR z buforami w kształcie pierścienia (np. 30-120 minut) i zapis równoległy w Przechowywanie obiektów dla powtórek. Oddzielnie Ciepły- oraz Przechowywanie w chłodniCiepłe przez pierwsze kilka dni z wysokim ciśnieniem pobierania, zimne dla archiwów z korzystniejszymi klasami. Indeksy (manifesty, etykiety skoków) są małe i przyjazne dla CDN. Aby zapewnić zgodność, zapewniam procedury usuwania i szyfrowanie w spoczynku.

W przypadku nadrabiania zaległości telewizyjnych planuję wyjście oddzielnie, ponieważ połączenia opóźnione w czasie nadal tworzą wzorce szczytowe. Wstępne podgrzanie dla najlepszych klipów znacznie zmniejsza opóźnienie startu.

Optymalizacja odtwarzacza na urządzeniach końcowych

Optymalizuję Ścieżka uruchamianiaRozdzielczość DNS, TLS, paralelizacja pierwszych segmentów i użycie prefetch. HTTP/3 pomaga w sieciach stratnych dzięki odzyskiwaniu QUIC. W telewizorach Smart TV biorę pod uwagę powolne procesory i wyższe opóźnienia dekodera; wybieram dłuższe interwały klatek kluczowych umiarkowanie, aby nie spowalniać przełączania. Na urządzeniach mobilnych biorę pod uwagę ograniczenia bateryjne i termiczne, zmniejszam rozdzielczość w przypadku przegrzania i wstrzymuję pobieranie wstępne w tle.

W ABR umieszczam Podłoga bezpieczeństwa najniższy poziom (np. 240p/360p), dzięki czemu odtwarzanie pozostaje stabilne nawet w słabych sieciach. W szczególności testuję na przeglądarkach brzegowych i producentach OEM telewizorów, gdzie implementacje historycznie się różnią.

Prognozy, SLO i testy

Prognozuję możliwości z P95/P99-CCU (współbieżnych użytkowników) zamiast wartości średnich oraz uwzględniam sezonowość i działania marketingowe. W przypadku wydarzeń tworzę plany ramp-up (np. +10 % CCU na minutę) i definiuję twarde wartości graniczne, kiedy obniżam jakość zamiast tracić strumienie. SLO Definiuję blisko użytkownika: np. start < 2 s (P95), rebuffer < 0,5 %, opóźnienie end-to-end 2-4 s.

Łączę testy syntetyczne (kontrolowane, powtarzalne) z rzeczywistymi pomiarami użytkowników. Manifesty kanaryjskie służą jako system wczesnego ostrzegania: mała kohorta otrzymuje nowe ustawienia, zanim wprowadzę je globalnie. Zapisuję dni gry i ćwiczenia regeneracyjne w runbookach, w tym ścieżki komunikacji.

Realistyczne modele obliczania kosztów

Biorę pod uwagę 95. percentyl-Korzystam również z rozliczeń egress z przewoźnikami i decyduję się na użycie zobowiązane lub płatne w zależności od możliwości zaplanowania wydarzenia. Zmniejszam koszty połączeń wychodzących poprzez Prywatne połączenia międzysieciowe do dużych dostawców usług internetowych lub poprzez peering w sieci. Porównuję transkodowanie na miejscu (ASIC/GPU) z chmurą (OpEx) z TCO obejmującym koszty energii i krzywą wykorzystania. Śledzę koszt na godzinę i koszt na GB na renderowanie, aby decyzje były oparte na danych.

Ustawiłem Automatyczne skalowanie z Guardrails: skaluj wcześnie przed szczytami, skaluj powoli, aby uniknąć trzepotania. Prewarpuję cache specjalnie dla topowych tytułów; oszczędza to na wychodzeniu w punkcie początkowym i poprawia QoE.

Zrównoważony rozwój i wydajność

Wybieram wydajność Kodeki i koderów sprzętowych, aby zmniejszyć zużycie watów na godzinę strumieniowania. AV1 oszczędza przepustowość, ale wymaga dużej mocy obliczeniowej procesora podczas kodowania; dlatego używam potoków sprzętowych (ASIC/GPU) na żywo, kodowanie programowe na żądanie może mieć sens. Obciążenia umieszczam w centrach danych o wysokim PUE i energii odnawialnej bez poświęcania opóźnień. Krótsze odległości to nie tylko oszczędność czasu, ale i energii.

Minimalizuję niepotrzebne ponowne kodowanie, deduplikuję zasoby i utrzymuję realistyczne czasy przechowywania. W ten sposób zmniejszam koszty i emisję dwutlenku węgla.

Krótkie podsumowanie

Zapewniam płynny streaming poprzez Pojemność czysty plan i Opóźnienie systematycznie. Definiuję wyraźne przepływności na strumień, dodaję jednoczesnych widzów i trzymam 20 % w rezerwie. W przypadku interakcji polegam na WebRTC, w przypadku masowego zasięgu na LL-HLS/DASH, VoD pozostaje silny dzięki HLS. Bliskość krawędzi, dobry peering i odpowiedni CDN skracają odległości i odciążają Origin. Dzięki drabinkom ABR, wydajnym kodekom, spójnemu monitorowaniu i odpornym portom, hosting streamingu pozostaje przewidywalny - nawet przy dużych szczytach.