Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



23.09.2021

5 edycja konferencji Test...

21 października startuje kolejna, piąta już edycja największej w Polsce konferencji...
23.09.2021

Zero Trust Firewall

FortiGate 3500F
23.09.2021

Ochrona IoT

Kaspersky SHS
23.09.2021

Wydatki lobbingowe

Cyfrowy monopol
23.09.2021

Współdziałanie klastrów

SUSE Rancher 2.6
23.09.2021

Panasonic TOUGHBOOK 55

Najnowsza wersja wszechstronnego Panasonic TOUGHBOOK 55 to wytrzymały notebook typu...
23.09.2021

Elastyczna dystrybucja...

Liebert RXA i MBX
23.09.2021

Zdalny podgląd w 360°

D-Link DCS-8635LH
23.09.2021

Sejf na dane

Szyfrowany pendrive

Komunikacja z Matrix

Data publikacji: 23-09-2021 Autor: Maciej Olanicki
Rozproszona wymiana czterech...

Ledwie opadły emocje po premierze zwiastuna czwartej części serii „Matrix”, a my wracamy do tematu. Rzecz jasna nie do filmu, lecz do protokołu komunikacji i oprogramowania Matrix – niezależnego, opensource’owego systemu wymiany informacji, którego potencjał, możliwości i przewagę nad liczną komercyjną konkurencją przedstawimy wraz z praktycznymi poradami odnośnie do konfiguracji serwera i integracji z różnymi klientami i komunikatorami.

 

W przypadku systemu Matrix trudno o jednoznaczną definicję. Jest to bowiem zbiorcza nazwa sporego i wciąż rozrastającego się grona rozwiązań – protokołu, serwerów, oprogramowania desktopowego i mobilnego – który ma jednak jedno zasadnicze, ale jakże ambitne zastosowanie. Jest nim umożliwienie komunikacji wielu użytkownikom, niezależnie od ich liczby, w sposób bezpieczny, niezawodny, dalece zdecentralizowany i zaszyfrowany end-to-end z użyciem najnowocześniejszych standardów. W 2019 roku projekt wyszedł z fazy testowej, dziś można go już bez obaw stosować w środowiskach produkcyjnych, do czego przekonało się jak dotąd ponad 25 mln użytkowników.

Matrix powinien zainteresować szczególnie tych, którzy chcą uniezależnić komunikację w organizacji od firm trzecich, których usługi – jak już niejednokrotnie się przekonaliśmy – mogą przestać być dostępne lub ulec dyskwalifikującym je zmianom z dnia na dzień. Ponadto w odróżnieniu od usług firm trzecich Matrix jest odporny na awarie, których nie ustrzegają się przecież nawet najbardziej zaawansowane usługi chmurowe. Rozwiązanie nie bazuje bowiem na jakimkolwiek centralnym węźle, którego niedostępność mogłaby zaburzyć komunikację. Całość kodu jest wolna (zatwierdzona przez FSF Apache License 2.0, kompatybilna z GNU General Public License 3), a sam projekt rozwijany przez fundację non-profit i skupioną wokół Matriksa społeczność.

O rozmachu całego przedsięwzięcia niech świadczy jego funkcjonalność – nie jest to jakiś duchowy następca IRC-a, lecz pełnoprawny komunikacyjny kombajn obsługujący czaty, pokoje, rozmowy głosowe VoIP, wideokonferencje za pośrednictwem WebRTC, konwersacje grupowe, boty czy zaawansowane systemy powiadomień. Słowem: funkcjonalność nie odbiega, a w niektórych przypadkach może przewyższać produkty takie jak Slack czy Microsoft Teams. Rzecz w tym, że z pełni możliwości Matriksa bez jakichkolwiek ograniczeń co do liczby użytkowników czy wielkości archiwizowanych danych każdy może korzystać za darmo.

 

> MATRIX JAKO „PROTOKÓŁ”

Rozkwit ekosystemu usług i narzędzi komunikacyjnych towarzyszących Matriksowi nie byłby możliwy, gdyby nie solidny fundament w postaci protokołu, choć sami twórcy wolą go raczej określać jako „zdecentralizowany magazyn konwersacji”. U podstaw leży założenie, że wymianie informacji uczestniczy tyle serwerów, ilu uczestników konwersacji – każdy dysponuje swoją własną instancją występującą tutaj pod nazwą homeserver. Niezależnie od liczby użytkowników czatu nigdy nie dojdzie do sytuacji, kiedy dane są przechowywane w jednym centralnym miejscu. Niemożliwe jest również, aby stan poszczególnych serwerów się różnił.

Może to przywodzić na myśl blokowe łańcuchy danych lub commity w systemie Git. Po nadaniu wiadomości przez jednego z użytkowników ta jest replikowana na wszystkich homeserverach uczestników konwersacji. Mogą to być również wydzielone przez nadawcę serwery, przez co uzyskuje się system pokoi wewnątrz ogólnego czatu. Skoro zatem zapis poszczególnych rozmów przechowywany jest na wszystkich homeserverach, to mimo awarii (łącznie z całkowitym wyłączeniem) jednego z węzłów nigdy nie zostanie on utracony i nie zakłóci on działania pozostałych instancji, czego nie można powiedzieć o systemach komunikacji działających w strukturach scentralizowanych. Ponadto, w sytuacji przywrócenia awaryjnego homeservera do sprawności, automatycznie synchronizuje on swój stan z innymi, a zatem pobiera tę część konwersacji, które go „ominęły”. Warto odnotować, że nie mamy tu do czynienia z jakąś wariacją modelu P2P, w której dotarcie wiadomości z serwera A do serwera C wymagałoby pośrednictwa serwera B – jak już podkreślaliśmy, komunikacja przebiega w sposób całkowicie zdecentralizowany, a poszczególne instancje są od siebie niezależne.

Rzeczone stwierdzenia twórców Matriksa, że de facto nie jest on protokołem, są zresztą uzasadnione. Od strony technicznej nie otrzymaliśmy bowiem żadnego standardu i omówiona metoda wymiany i przechowywana informacji w swoim najprostszym wariancie realizowana jest z użyciem technologii znanych od lat i relatywnie nieskomplikowanych. Warunkiem niezbędnym do wymiany komunikatów pomiędzy klientem i serwerem jest obsługa protokołu HTTPS (możliwe jest również użycie HTTP, co jednak z oczywistych powodów nie jest zalecane), za pośrednictwem którego wymieniane są komunikaty w postaci obiektów JSON. Uwierzytelnianie odbywa się za pomocą handshake’u pomiędzy serwerami użytkowników a ich klientami w postaci tokenów, które potwierdzają tożsamość uczestników konwersacji. Wszystko to odbywa się z wykorzystaniem otwartych standardów Olm i Megolm, których skuteczność potwierdził audyt grupy NCC. Ich połączenie stanowi algorytm podwójnej zapadki kryptograficznej, która wykorzystywana jest między innymi także w coraz popularniejszym komunikatorze Signal.

Wykorzystanie HTTPS i wiadomości zapisanych w strukturze JSON to oczywiście podstawowy scenariusz wymiany informacji. W bardziej zaawansowanych wdrożeniach wykorzystywane jest API bazujące na protokole WebSocket, które zastępuje HTTPS. Takie rozwiązanie sprawdzi się szczególnie wtedy, gdy przewidujemy budowę rozległej infrastruktury, w przypadku której ewentualne opóźnienia wynikające z tego, jak działa protokół HTTPS i REST API, będą odczuwalne. WebSocket jest bowiem protokołem, w którym ruch może się odbywać w tym samym czasie w obu kierunkach i w którym nie zachodzi potrzeba negocjacji SSL czy wymiany nagłówków HTTP.

 

[...]

 

Dziennikarz, redaktor, bloger. Entuzjasta i popularyzator wolnego oprogramowania. Redaktor prowadzący „IT Professional”.

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"