Co to jest protokół Gossip w sieciach P2P?

Kupuj kryptowaluty BLIKiem ⚡

Błyskawiczne wpłaty bez opłat i prowizji na giełdzie OKX.

Kup krypto z 0% prowizji

Siemka! Fajnie, że zgłębiasz temat, bo protokół Gossip w sieciach P2P to faktycznie totalny fundament, jeśli chcesz kumać współczesne systemy rozproszone. Twoja metafora z biurową plotą trafia w punkt, to najlepiej obrazuje, jak działa protokół plotkowania. Ale żeby to banglało na produkcji i nie zabiło sieci, devsi musieli pod maską zaimplementować kilka sprytnych trików.

Pytasz, jak to wygląda w praktyce z tym zapychaniem łącza i czy węzły nie mielą w kółko tych samych paczek. Otóż nie, bo algorytmy Gossip wcale nie są takie głupie na jakie brzmią. Zazwyczaj węzły nie wysyłają od razu całych, grubych danych (tzw. payloadu). Działa to na zasadzie wymiany metadanych albo krótkich haszy. Wyobraź sobie, że jeden node puka do drugiego i mówi: "Ej, mam stany sieci w wersji 15, a ty?". Jak ten drugi ma wersję 12, to wtedy dopiero dociąga braki. Mamy tu do czynienia z mechanikami typu push-pull. Dzięki temu wymiana danych w sieci rozproszonej po prostu nie zarzyna bandwidthu.

Do tego wjeżdża mocno temat wersjonowania i wektorów zegara (vector clocks). Każdy wpis czy grubszy update w takiej sieci peer-to-peer ma swój znacznik czasu albo konkretny numer generacji. Jeśli maszyna dostaje info, które jest starsze niż to, co już ma wycache'owane u siebie, to po prostu ten pakiet dropuje. Nie ma opcji, żeby stara plota krążyła po klastrze w nieskończoność. Często devopsi ustawiają też hardcorowo parametr TTL (Time To Live), czyli po ilu skokach (hopach) dany pakiet ma po prostu wygasnąć i przestać być dalej rozsyłany. To załatwia problem nieskończonego echa.

Z perspektywy utrzymaniowej – bo pytasz, kto w tym dłubał – mogę ci podrzucić, jak to wygląda na produkcji. Wspomniałeś o Apache Cassandra i to jest sztandarowy przykład. Tam gossip protocol odpowiada głównie za wykrywanie awarii (tzw. failure detection). Nody cały czas wysyłają do siebie w tle takie malutkie pakiety heartbeat. Jak nagle jakiś serwer przestaje odpowiadać na plotki sąsiadów, reszta automatycznie uznaje go za trupa i przepina ruch gdzie indziej. Podobnie ogarnia to Consul od HashiCorpa (korzystają z biblioteki Serf) do zarządzania topologią klastra. To robi niesamowitą robotę, bo decentralizacja w takich środowiskach faktycznie gwarantuje wysoką dostępność, nawet jak chmura dostanie czkawki.

Ale żeby nie było tak kolorowo, pytałeś o realne minusy całej tej zabawy. Największy ból głowy przy projektowaniu apek to tzw. eventual consistency (spójność ostateczna). Ponieważ przesyłanie informacji i komunikacja w sieciach P2P zajmuje ułamki sekund (zanim plota dotrze do każdego zakątka klastra na tysiące maszyn), przez ten krótki czas różne węzły moga mieć różny stan wiedzy. Nie masz tu od razu natychmiastowej spójności jak w starych, dobrych, relacyjnych bazach SQL. Jak odpytasz noda, do którego plotka jeszcze fizycznie nie dotarła, dostaniesz nieaktualne dane. Z tym trzeba po prostu umieć żyć i odpowiednio pisać logikę na froncie, żeby user nie zwariował widząc skaczące stany konta.

Tak czy inaczej, jak chcesz dogłębnie zrozumieć co to jest protokół Gossip w sieciach P2P od strony technicznej, postaw sobie lokalnie w Dockerze ze 3-4 nody Cassandry, zrzuć logi na konsolę i popatrz na żywo, jak one ze sobą gadają. Mega satysfakcjonująca rozkmina, a szybko złapiesz, jak to rozproszone plotkowanie śmiga pod dużym obciążeniem. Powodzenia w dalszym kodzeniu!

Kupuj kryptowaluty BLIKiem ⚡

Błyskawiczne wpłaty bez opłat i prowizji na giełdzie OKX.

Kup krypto z 0% prowizji

Cześć! Poprzednik ładnie wyjaśnił technikalia i to, jak wymiana danych w sieci rozproszonej radzi sobie z optymalizacją łącza, ale ja dorzucę tu swoje trzy grosze z zupełnie innej beczki. Skoro na celowniku masz głównie krypto, to musimy pogadać o bezpieczeństwie, bo algorytmy Gossip mają w otwartym internecie jeden spory słaby punkt.

Wracając do twojej metafory biura – a co się stanie, jeśli któryś pracownik jest zwykłym trollem i celowo puszcza fejkowe ploty, żeby narobić dymu? W zamkniętym klastrze w jakiejś firmie ufamy wszystkim maszynom, ale w publicznej sieci peer-to-peer każdy może podpiąć swój serwer. Złośliwy node może zacząć spamować fałszywymi stanami transakcji albo modyfikować pakiety w locie. Dlatego sam protokół plotkowania to w blockchainie za mało. Dokleja się do niego solidną kryptografię, np. każdy pakiet musi mieć prawidłowy podpis cyfrowy. Jeśli sąsiedzi widzą, że dany węzeł rozsyła śmieci, dają mu bana, ucinają połączenie i ignorują typa. Reputacja w takich sieciach to podstawa.

Z perspektywy devopsowej, o którą pytałeś, jest jeszcze jeden hardcore z którym borykamy się na utrzymaniu. Wyobraź sobie fizyczną awarię u dostawcy chmury. Główny switch pada i nagle twój ogromny klaster dzieli się na dwie połowy, które nie mają ze sobą łączności. Masz wtedy tzw. split-brain. Obie grupy plotkują tylko między sobą, żyjąc w przekonaniu, że reszta węzłów umarła. Kiedy po paru godzinach sieć wstaje i obie grupy znów zaczynają wymieniać dane, nagle okazuje się, że mają kompletnie inną historię zdarzeń. Mergowanie konfliktów po takiej akcji to jest poprostu rzeźnia i bez dobrych mechanizmów rozwiązywania konfliktów (jak CRDTs) masz gwarantowany rozsyp danych.

Poprzednik radził stawianie Dockera, co jest super pomysłem, ale jak chcesz najpierw na sucho poczuć, jak działa komunikacja w sieciach P2P przy masowych awariach, wygooglaj sobie interaktywne symulatory (np. "gossip protocol interactive visualization"). Zobaczysz na własne oczy w przeglądarce, jak kolorowe kropki wymieniają pakiety i jak wirusowo rozchodzi się info, nawet gdy zaczniesz złośliwie klikać i ubijać połowę infrastruktury na ekranie. Mega to ryje banie i świetnie wizualizuje chaos. Powodzenia w dłubaniu!