Jak działa sieć w architekturze klient-serwer?

Sieć w architekturze klient-serwer działa na zasadzie bezpośredniej wymiany komunikatów, w której urządzenie użytkownika (klient) wysyła żądanie o dane, a centralna maszyna (serwer) przetwarza to zapytanie i odsyła gotowy wynik. Cały ten proces opiera się na ściśle określonych protokołach komunikacyjnych, takich jak TCP/IP oraz HTTP, zapewniających bezbłędny transport pakietów informacji po kablach i łączach bezprzewodowych. Działa to bardzo prosto. Żądasz zasobu, a serwer go wydaje.

Zbudowanie stabilnej komunikacji w firmie wymaga zrozumienia, że architektura klient-serwer to nie jest układ równorzędny. Mamy tutaj wyraźnego zarządcę zasobów i wielu petentów. Kiedy analizujemy ruch sieciowy w takich środowiskach, od razu widać asymetrię. Serwer nasłuchuje na określonym porcie. Klient inicjuje połączenie. Uważam, że to podejście całkowicie zdominowało tworzenie oprogramowania internetowego, ponieważ pozwala zamknąć logikę biznesową w jednym, bezpiecznym miejscu. Nie musimy ufać urządzeniom końcowym. Ufamy wyłącznie naszej infrastrukturze.

Na czym dokładnie polega architektura klient-serwer i jak obsługuje żądania?

Architektura klient-serwer definiuje fizyczny i logiczny podział ról w sieci komputerowej. Z jednej strony mamy aplikację kliencką. To może być przeglądarka internetowa na twoim telefonie, aplikacja bankowa albo terminal kasowy w supermarkecie. Z drugiej strony stoi serwer, czyli wydajna maszyna podpięta do grubego łącza, która przechowuje bazy danych i wykonuje ciężkie obliczenia. Model ten rozdziela interfejs użytkownika od warstwy przechowywania danych. To daje gigantyczną przewagę przy aktualizacjach oprogramowania.

Pamiętam wdrożenie systemu magazynowego dla lokalnej hurtowni na obrzeżach Radomia. Mieliśmy tam cztery stare terminale wózkowe i jeden serwer schowany w zakurzonej szafie rackowej. Zrobiliśmy na wdrożeniu aktualizację bazy danych, potem zawiesiło się oprogramowanie na jednym z czytników, więc wprowadzono poprawkę na serwerze przed poniedziałkiem. Magazynierzy niczego nie musieli instalować na swoich urządzeniach. Zmiana logiki po stronie serwera automatycznie zmieniła to, co widzieli klienci. To jest twardy dowód na wyższość centralizacji nad rozproszonymi systemami w małym biznesie.

Komunikacja między tymi dwoma bytami opiera się na modelu żądanie-odpowiedź (request-response). Klient formułuje zapytanie. Pakuje je w odpowiedni format, najczęściej JSON lub XML, i wysyła w świat. Serwer odbiera te dane, waliduje je, odpytuje bazę danych, a następnie generuje odpowiedź. Odsyła ją do klienta wraz z kodem statusu. Zwykłe 200 OK oznacza sukces. Błąd 500 oznacza, że coś po stronie serwera uległo awarii. Nie ma tu miejsca na domysły. Protokół wymusza konkretne zachowania.

Jakie są realne obowiązki klienta w sieci?

Klient w modelu klient-serwer jest z natury leniwy. Jego zadania są mocno ograniczone. Przede wszystkim ma poprawnie wyrenderować interfejs graficzny. Ma pozwolić użytkownikowi kliknąć przycisk. Następnie jego zadaniem jest zebranie wprowadzonych danych, sformatowanie ich i wysłanie pod wskazany adres IP lub domenę. Po otrzymaniu odpowiedzi klient musi ją po prostu wyświetlić w czytelnej formie. Zrzucenie ciężaru obliczeniowego na serwer sprawia, że telefony i tanie laptopy w ogóle są w stanie obsługiwać zaawansowane aplikacje webowe.

Za co odpowiada serwer w środowisku produkcyjnym?

Serwer to koń roboczy całej operacji. Przetwarza żądania od tysięcy klientów jednocześnie. Musi autoryzować użytkownika. Sprawdza, czy Jan Kowalski ma prawo dostępu do konkretnego pliku. Następnie serwer komunikuje się z bazą danych. Wykonuje operacje zapisu, odczytu lub modyfikacji. Na koniec formuje pakiet zwrotny. Wymaga to ogromnej mocy obliczeniowej, dużej ilości pamięci RAM oraz szybkich dysków NVMe. Jeśli serwer nie wyrabia, cała sieć w architekturze klient-serwer staje się bezużyteczna, a aplikacja po prostu wisi.

Jak fizycznie podróżują pakiety w sieci klient-serwer?

Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze, gdy sprawdzamy opóźnienia? Sam się z tym borykałem dzisiaj u siebie we wtorek, analizując logi z routerów brzegowych. Prawda jest zresztą absolutnie taka, że dane nie teleportują się w próżni. Wymiana informacji w sieci klient-serwer to brutalna, fizyczna przeprawa impulsów elektrycznych i światła przez dziesiątki urządzeń pośredniczących.

Kiedy klient klika „Zaloguj”, system operacyjny tnie jego żądanie na małe kawałki zwane pakietami. Każdy pakiet otrzymuje nagłówek. W nagłówku znajduje się adres IP nadawcy oraz adres IP serwera docelowego. Przypomina to naklejanie adresu na kopertę. Następnie pakiety trafiają do lokalnego routera. Router sprawdza swoją tablicę routingu i decyduje, gdzie popchnąć pakiet dalej. Dane przelatują przez węzły operatorów telekomunikacyjnych. Czasami lecą światłowodem na dnie oceanu. Ostatecznie trafiają do centrum danych, w którym fizycznie stoi serwer.

Serwer docelowy odbiera te pakiety. Często przychodzą w złej kolejności. Mechanizmy sieciowe układają je z powrotem w logiczną całość. Dopiero wtedy oprogramowanie serwera widzi pełne żądanie HTTP. Odpowiedź wraca dokładnie tą samą drogą, choć pakiety mogą wybrać inną, szybszą trasę powrotną. Cały ten proces trwa zazwyczaj kilkadziesiąt milisekund. To czysta fizyka i matematyka realizowana przez sprzęt sieciowy.

Co dokładnie dzieje się pod maską od kliknięcia do wyświetlenia strony?

• Rozwiązywanie nazwy domeny (DNS): Przeglądarka nie rozumie nazw takich jak wp.pl. Musi zapytać serwer DNS o adres IP przypisany do tej domeny. Serwer DNS przeszukuje swoje rekordy i zwraca ciąg liczb, na przykład 212.77.98.9. To absolutna podstawa, bez której cała reszta komunikacji w ogóle by nie ruszyła, bo urządzenia sieciowe gadają tylko na liczbach.
• Nawiązanie połączenia (Handshake TCP): Klient wysyła pakiet SYN. Serwer odpowiada SYN-ACK. Klient potwierdza wysyłając ACK. Mamy otwarty kanał.
• Właściwy transfer danych: Klient pcha żądanie GET po protokole HTTP. Serwer odbiera dane, miele je w swoim procesorze i wypluwa odpowiedź z kodem HTML.
• Zamknięcie sesji: Połączenie zostaje przerwane by zwolnić porty.

Jakie protokoły sterują architekturą klient-serwer?

Bez protokołów sieć w architekturze klient-serwer byłaby stertą bezużytecznego złomu. Protokoły to twarde zasady określające, jak formatować i przesyłać dane. Na samym dole mamy warstwę internetową z protokołem IP (Internet Protocol). Odpowiada on za adresację maszyn. Wyżej działa warstwa transportowa. Tutaj rządzą dwa główne rozwiązania: TCP oraz UDP. Na samej górze mamy warstwę aplikacji. Zwykły użytkownik najczęściej styka się z HTTP lub HTTPS, które służą do pobierania stron WWW.

Zastosowaliśmy u siebie na robocie twarde rozróżnienie tych warstw. Zmieniliśmy te zasady na robocie, żeby analitycy nie mylili logiki biznesowej z problemami sieciowymi. Jeśli aplikacja nie może połączyć się z bazą danych, sprawdzamy warstwę transportową. Jeśli dostajemy dziwne błędy w przeglądarce, winny jest zazwyczaj źle sformatowany nagłówek HTTP.

Dlaczego TCP wygrywa z UDP w systemach biznesowych?

Protokół TCP to fundament systemów transakcyjnych. Kiedy klient wysyła przelew bankowy, nie możemy pozwolić na utratę choćby jednego bita informacji. TCP weryfikuje, czy serwer odebrał każdą paczkę danych. Jeśli coś zginie po drodze, TCP automatycznie retransmituje zgubiony fragment. UDP działa zupełnie inaczej. Po prostu wypluwa pakiety w sieć i nie interesuje go, czy dotarły do celu. Dlatego UDP stosujemy tam, gdzie liczy się prędkość, a zgubienie pojedynczej klatki obrazu nie zepsuje relacji z klientem. Uważam, że UDP nadaje się wyłącznie do streamingu i gier. Cały biznes e-commerce i B2B stoi na TCP.

Z czym wiąże się skalowanie i obciążenie na serwerach?

Skalowanie sieci w modelu klient-serwer to brutalne zderzenie teorii z rzeczywistością. Kiedy aplikację używa dziesięciu klientów, wszystko działa błyskawicznie. Problem pojawia się, gdy w piątek wieczorem ruch skacze do dziesięciu tysięcy jednoczesnych połączeń. Pojedynczy serwer ma fizyczne limity procesora i pamięci. Szybko zapycha się kolejka żądań. Wtedy musimy wprowadzić load balancing, czyli równoważenie obciążenia. Zamiast jednej maszyny stawiamy pięć, a przed nimi montujemy specjalny węzeł, który rozdziela ruch od klientów na poszczególne serwery aplikacyjne.

Widzieliśmy to wielokrotnie podczas kampanii sprzedażowych w e-commerce. Bez mała prawie pięćdziesiąt procent na plusie uderzając do przodu u wyników sprzedaży w ciągu godziny. Architektura klient-serwer pozwala na skalowanie poziome. Dokładamy kolejne tanie maszyny do klastra. Load balancer sprawdza, który serwer aktualnie ma najwięcej wolnych zasobów, i właśnie tam kieruje nowe żądanie HTTP. Klient nie ma zielonego pojęcia, z którą konkretnie fizyczną maszyną w centrum danych rozmawia. Otrzymuje tylko swój wynik na ekranie. Skalowalność to główna zaleta oddzielenia frontendu od backendu.

Szczerze mówiąc, dokumentację do tych wdrożeń piszemy zazwyczaj o trzeciej nad ranem po zderzeniu z awarią na produkcji u nas w oddziale na Żoliborzu we wtorek, by upewnić się, że nikt z zarządu nie będzie pytał o braki w logach. Wtedy człowiek zastanawia się nad sensem tego całego rygoru. Wciskasz ENTER i modlisz się, żeby router podniósł się po restarcie, a zaimplementowane reguły zapory sieciowej nie odcięły nam dostępu SSH. Czasami to wszystko to po prostu KATASTROFA oparta na trytytkach i starych skryptach w Bashu, o czym nikt głośno nie mówi na konferencjach IT. Ale działa. Musi działać, bo rano przychodzą zamówienia.

Co najczęściej niszczy wydajność komunikacji klient-serwer?

W zdecydowanej większości przypadków problemem wcale nie jest przepustowość samej sieci, ale to, co dzieje się pod maską u aplikacji. Deweloperzy często piszą fatalne zapytania SQL. Klient wysyła proste żądanie, ale serwer musi przeszukać miliony wierszy w bazie danych, żeby wypluć odpowiedź. Zanim baza odda wynik, serwer trzyma otwarte połączenie z klientem. Porty się wyczerpują. Pamięć RAM zostaje zjedzona w całości.

Innym powodem są tak zwane wąskie gardła na łączach wychodzących (uplink). Serwer może wygenerować odpowiedź w ułamek sekundy, ale karta sieciowa o przepustowości 1 Gbps po prostu nie przepchnie fizycznie większej liczby pakietów do dostawcy internetu. Dochodzi do zjawiska gubienia pakietów (packet loss), co zmusza protokół TCP do ponownego wysyłania tych samych danych. To tworzy błędne koło obciążenia.

W jaki sposób bazy danych wpinają się w tę architekturę?

Architektura klient-serwer bardzo często ewoluuje w architekturę trójwarstwową (three-tier). Klient nie rozmawia bezpośrednio z bazą danych. To jest absolutnie najgorsza opcja z wszystkich z punktu widzenia bezpieczeństwa. Wpuszczenie obcego urządzenia bezpośrednio do struktury SQL to proszenie się o kłopoty. Zamiast tego klient uderza do serwera aplikacyjnego. Serwer aplikacyjny weryfikuje token użytkownika. Dopiero potem, już w bezpiecznej sieci wewnętrznej, serwer aplikacyjny łączy się z serwerem bazy danych.

To działa jak śluza sanitarna. Aplikacja backendowa ma zaszyte uprawnienia do bazy. Baza ufa wyłącznie serwerowi aplikacji, blokując wszelki ruch z zewnątrz. Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj u jednego z naszych klientów, więc wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał przed spowolnieniem rynku, że firmy zaczną masowo upraszczać te struktury z powodu kosztów utrzymania oddzielnych klastrów bazodanowych. Mimo to, podział na warstwy to standard branżowy poprawiający odporność na ataki typu SQL Injection.

Bezpieczeństwo i autoryzacja żądań sieciowych

Sieć w architekturze klient-serwer to otwarta przestrzeń. Każdy może wysłać pakiet na twój publiczny adres IP. Dlatego warstwa autoryzacji jest fundamentalna. Kiedyś używano stanowych sesji. Serwer zapisywał w pamięci, że użytkownik X jest zalogowany. Dziś używamy bezstanowych tokenów JWT (JSON Web Tokens). Klient loguje się raz, otrzymuje kryptograficznie podpisany ciąg znaków i dołącza go do każdego kolejnego żądania HTTP.

Dzięki tokenom serwer nie musi pytać bazy danych przy każdym kliknięciu. Po prostu sprawdza podpis cyfrowy tokena w ułamku sekundy. Odciąża to infrastrukturę i przyspiesza działanie aplikacji. Jeśli token straci ważność, serwer po prostu odrzuca żądanie z kodem błędu 401 Unauthorized. Klient musi wtedy poprosić o nowy token. To mechanika pozbawiona jakiejkolwiek empatii dla błędów w kodzie. Albo masz ważny bilet, albo wylatujesz za drzwi.

Dobrym pomysłem jest wdrożenie szyfrowania TLS na całym ruchu z zewnątrz. Dzięki temu, nawet jeśli ktoś podsłuchuje pakiety w kawiarni z darmowym Wi-Fi, zobaczy tylko losowy szum. Certyfikaty SSL wymuszają na serwerze i kliencie ustalenie wspólnego klucza szyfrującego zanim prześlą choćby jeden bajt właściwych danych. To standard, który całkowicie zmienił podejście do budowania sieci publicznych.

Czy architektura klient-serwer ma w ogóle sensowne alternatywy?

Rynek zna inne modele komunikacji. Najpopularniejszym z nich jest model Peer-to-Peer (P2P). W sieci P2P nie ma centralnego zarządcy. Każdy węzeł jest jednocześnie klientem i serwerem. Użytkownicy wymieniają się plikami bezpośrednio między sobą. P2P jest niezwykle tanie w utrzymaniu, bo koszty infrastruktury ponoszą sami użytkownicy użyczając swojego łącza. Torrenty działają dokładnie na tej zasadzie.

Dlaczego więc firmy nie stawiają swoich systemów księgowych na P2P? Bo nie masz absolutnie żadnej kontroli nad danymi. Węzeł może w każdej chwili zniknąć z sieci. Model klient-serwer daje pełną kontrolę i gwarancję dostępności. My decydujemy, kiedy serwer ma przerwę techniczną. My odpowiadamy za kopie zapasowe. Architektura centralna pozostanie z nami na dekady właśnie z powodu bezpieczeństwa i odpowiedzialności prawnej za przechowywane informacje. P2P to wolna amerykanka. Klient-serwer to twardy reżim korporacyjny.

Sprawdź swoje logi systemowe na firewallu już dzisiaj rano. Zobacz, ile nieautoryzowanych żądań odbija się codziennie od twoich publicznych adresów IP. Zrozumiesz wtedy natychmiast, dlaczego centralizacja zasobów i zamykanie ich za grubym murem serwera proxy to jedyna rozsądna metoda budowy infrastruktury informatycznej w firmie. Reszta to tylko teoria z podręczników.

Często zadawane pytania (FAQ)

• Co to jest architektura klient-serwer w sieci?
  Architektura klient-serwer to model komunikacji w sieci, w którym zadania są podzielone na dostawców zasobów lub usług (serwery) oraz osoby żądające tych zasobów (klienci). Klient wysyła zapytanie, a serwer je przetwarza i zwraca wynik.
• Jak działa sieć w architekturze klient-serwer w praktyce?
  W praktyce aplikacja kliencka łączy się z adresem IP serwera przez określony port (np. 80 lub 443 dla HTTP/HTTPS). Wysyła sformatowane żądanie. Serwer odbiera pakiety, przetwarza logikę biznesową, ewentualnie łączy się z bazą danych, a na koniec odsyła klientowi sformatowaną odpowiedź, którą ten wyświetla na ekranie.
• Jakie są główne zalety modelu klient-serwer?
  Główną zaletą jest centralizacja danych, co ułatwia zarządzanie bezpieczeństwem, robienie kopii zapasowych oraz aktualizację oprogramowania. Klienci nie muszą posiadać dużej mocy obliczeniowej, ponieważ większość ciężkich operacji wykonuje serwer.
• Jaki protokół jest najczęściej używany do komunikacji w tym modelu?
  Fundamentem dla większości aplikacji jest protokół TCP/IP w warstwie transportowej, który gwarantuje dostarczenie pakietów, oraz protokół HTTP lub HTTPS w warstwie aplikacji do przesyłania konkretnych komend i zasobów webowych.
• Czym architektura klient-serwer różni się od Peer-to-Peer (P2P)?
  W modelu P2P każdy uczestnik sieci jest równorzędny – pełni funkcję zarówno klienta, jak i serwera, bezpośrednio wymieniając się danymi z innymi. W architekturze klient-serwer istnieje wyraźny podział ról, a centralny serwer posiada wyłączną władzę nad zasobami.
• Co to jest load balancing w architekturze klient-serwer?
  Load balancing to mechanizm równoważenia obciążenia. Kiedy ruch z urządzeń klienckich jest zbyt duży dla jednej maszyny, load balancer rozdziela przychodzące pakiety i żądania na kilka mniejszych serwerów w klastrze, zapobiegając awarii i spowolnieniom sieci.

Bibliografia

1. Naukowa i Akademicka Sieć Komputerowa – https://www.nask.pl
2. Wydawnictwo Naukowe PWN – https://pwn.pl
3. Ministerstwo Cyfryzacji – https://www.gov.pl/web/cyfryzacja
4. Urząd Komunikacji Elektronicznej – https://uke.gov.pl
5. Główny Urząd Statystyczny – https://stat.gov.pl