P2P-serwis wideo na WebRTC: rozwój od zera w 9 miesięcy

# Serwis P2P wideo od zera: 9 miesięcy rozwoju na VPS z 1 rdzeniem

Za dziewięć miesięcy wolnego czasu elektryk z prowincji stworzył w pełni działający serwis P2P wideo «Wizawi» bez rejestracji i instalowania aplikacji. Projekt, opracowany od zera na skromnym VPS (1 rdzeń, 512 MB RAM), wykorzystuje WebRTC do bezpośredniego łączenia użytkowników i rozwiązuje problem omijania blokad. Efekt — przeglądarkowe rozwiązanie z rosyjską domeną, zdolne do pracy nawet przy lokalnych ograniczeniach sieciowych.

Od pomysłu do realizacji: jak powstał «Wizawi»

Twórca projektu napotkał blokadę standardowych serwisów wideo, co zmusiło go do poszukiwania alternatywy. W trakcie eksperymentów z siecią neuronową pojawiło się pytanie: «Czy możesz zrobić wideorozmowę?». Zaczynając od podstawowych pojęć WebRTC, serwerów STUN/TURN i kandydatów ICE, autor zagłębił się w szczegóły techniczne. Pierwsze udane testowe połączenia stały się katalizatorem dalszego rozwoju. Kluczową cechą stało się zrezygnowanie z rejestracji i aplikacji — połączenie nawiązuje się przez przeglądarkę za pomocą krótkiego cyfrowego identyfikatora pokoju.

Architektura opiera się na zasadzie «budynku z pokojami»: użytkownicy wpisują numer pokoju na stronie https://vi-for-vi.rf/, po czym system automatycznie ich łączy, gdy jest dwóch uczestników. Przekazanie numeru pokoju zależy od użytkowników — przez komunikatory, głosem przez telefon lub przy osobistym spotkaniu. Taki sposób minimalizuje bariery wejścia: po przejściu po linku wystarczy tylko zgoda na dostęp do kamery i mikrofonu.

stos technologiczny: minimalizm jako filozofia

Serwis jest wdrożony na wynajętym VPS w moskiewskim centrum danych o minimalnych parametrach:

• 1 rdzeń procesora
• 512 MB pamięci RAM
• 10 GB dysku SSD (zajęte 3,3 GB)
• OS Debian 11

Infrastruktura obejmuje:

• Coturn — własny serwer STUN/TURN do omijania NAT
• Node.js (serwer sygnalizacyjny) zarządzany przez PM2
• Nginx jako reverse proxy
• SSL od Let’s Encrypt z automatycznym odnawianiem
• UFW i Fail2Ban do podstawowej ochrony
• Logika klienta i serwera w czystym JavaScript
• Express do serwowania statyki i REST API
• Socket.io do wymiany sygnałów WebRTC w czasie rzeczywistym

Przechowywanie danych jest zorganizowane za pomocą plików JSON zamiast tradycyjnych SGBD. To rozwiązanie wynika z ograniczonych zasobów serwera i ułatwia wdrożenie. Panel administracyjny, stworzony od zera, dostarcza dane o bieżących połączeniach i pomaga monitorować aktywność w czasie rzeczywistym.

Typy pokojów: od prostych po VIP

System obsługuje trzy typy pokojów:

• Zwykłe pokoje — podstawowy tryb dla dwóch uczestników. Po wpisaniu tego samego numeru użytkownicy łączą się automatycznie. Brak nagrywania rozmów, logowania IP i przechowywania wiadomości.

• Pokoje VIP — dodają hierarchię: właściciel zyskuje kontrolę nad czatem, nagrywaniem spotkań, prawem wyrzucania gości. Goście mogą udostępniać ekran i przesyłać pliki. Zaimplementowana jest kolejka dla jednoczesnych połączeń oraz funkcja zostawiania wiadomości przy wejściu.

• Pokoje do obserwacji (w opracowaniu) — koncepcja «baby monitora»: jedno urządzenie działa jako kamera, drugie jako monitor. Planowane jest wykorzystanie starych smartfonów jako źródeł wideo.

Krytyczną cechą jest brak kroków pośrednich przed połączeniem. W przeciwieństwie do konkurentów wymagających rejestracji lub podania imienia, «Wizawi» łączy użytkowników natychmiast po wpisaniu numeru pokoju.

Bezpieczeństwo i prywatność: obecny stan

Szyfrowanie end-to-end jest zapewnione na poziomie WebRTC, co gwarantuje ochronę transmitowanego strumienia audio i wideo. Jednak kilka aspektów wymaga dopracowania:

• Historia czatu jest przechowywana w localStorage przeglądarki w formie jawnej
• Wiadomości przy wejściu do pokojów VIP są zapisywane w plikach JSON bez szyfrowania
• Brak uwierzytelniania dostępu do pokojów

Autor podkreśla, że system nie jest przeznaczony do przekazywania poufnych danych, ale uznaje konieczność wzmocnienia ochrony. W warunkach ograniczonych zasobów VPS (512 MB RAM) wdrożenie pełnego szyfrowania wymaga równowagi między bezpieczeństwem a wydajnością.

Co ważne: kluczowe wnioski dla programistów

• Minimalizm architektury — używanie JSON zamiast SGBD i rezygnacja z nadmiarowych zależności jest kluczowa dla pracy na słabych VPS.
• Elastyczność serwera sygnalizacyjnego — Socket.io efektywnie radzi sobie z sygnałami WebRTC nawet przy dużej liczbie botów i skanerów.
• Doświadczenie użytkownika — eliminacja kroków pośrednich (rejestracja, podawanie imienia) bezpośrednio wpływa na zaangażowanie.
• Bezpieczeństwo jako proces — podstawowa ochrona (UFW, Fail2Ban) jest obowiązkowa nawet w małych projektach, ale wymaga ciągłego audytu.

System zmaga się z ciągłymi zapytaniami od skanerów i botów, co zmusza do wdrożenia filtrowania: dla nieprzeglądarkowych klientów serwowana jest uproszczona strona HTML bez JavaScript. To rozwiązanie zmniejsza obciążenie serwera i poprawia indeksację SEO.

Projekt pokazuje, że zaawansowane technologie jak WebRTC są dostępne nawet dla początkujących programistów. Kluczowe czynniki sukcesu to etapowa realizacja, skupienie na funkcjach rdzennych i korzystanie z gotowych rozwiązań (Coturn, Let’s Encrypt). Aby kontynuować rozwój, autor planuje dodać szyfrowanie wiadomości i zoptymalizować obsługę dużej liczby jednoczesnych połączeń.

— Editorial Team