#Niezbędnik Juniora: Jak działa internet

By 18 kwietnia 2016Niezbędnik Juniora

Z internetu korzysta każdy z nas na codzień, ale czy wiesz, jak on działa? W tym wpisie zerkniemy na najważniejsze protokoły i mechanizmy, dzięki którym to wszystko działa!

Słowniczek

Zanim zaczniemy – kilka słów wyjaśnienia co jest czym:

  • protokół – zbiór zasad dotyczących tego, jak ma wyglądać komunikacja pomiędzy dwoma systemami (lub np. pomiędzy systemem i użytkownikiem), określający nie tylko w jaki sposób transmitować dane, ale też jak je interpretować, co oznaczają i jakie są ograniczenia / wymagania związane z wymianą danych
  • URL / adres URL – adres URL składa się z 3 części (w przypadku HTTP):
    • protokół – jest to przedrostek, który określa protokół, z którego korzystamy; przeglądając internet będzie to najczęściej http:// lub https:// (ta część adresu URL zawsze kończy się dwukropkiem i dwoma ukośnikami, dalsza część adresu jest uzależniona od protokołu)
    • serwer – w przypadku protokołu HTTP kolejną częścią jest lokalizacja serwera, czyli adres serwera (jako nazwa domeny lub adres IP) oraz port, np: kobietydokodu.pl:80 – jeśli nie podamy numeru portu (dwukropek i numer z zakresu 1-65535 (jest to zakres 16-bitowej liczby), używany jest domyślny port (80 dla HTTP i 443 dla HTTPS)
    • URI – nastepna część to URI, czyli część zapytania która jest istotna tylko i wyłacznie dla serwera (protokół i adres serwera uzależniają działanie i kroki podejmowane przez przeglądarkę, adres URI jest po prostu przekazywany do serwera), jest to cała reszta ścieżki zaczynająca się od / zaraz po adresie serwera

Co się dzieje po wpisaniu w przeglądarce ‚www.kobietydokodu.pl’ ?

Najpierw przeglądarka musi zamienić domenę na konkretną lokalizację serwera – adres IP. Służy do tego protokół DNS, z którego przeglądarka korzysta jeśli nie zna jeszcze danej domeny, lub pamięć podręczna przeglądarki/systemu operacyjnego, jeśli niedawno była ona używana.

Następnie na uzyskany adres IP wysyła zapytania HTTP – czyli informacje co ma zostać zwrócone, jakie dane są wysyłane (o ile jakiekolwiek są) oraz dodatkowe informacje (np. o ciasteczkach czy o zalogowanym użytkowniku).

Po stronie serwera oprogramowanie odbiera to zapytanie i przygotowuje odpowiedź na podstawie tego, co ono zawierało. Najczęściej będzie to zawartość HTML lub jakiś plik, który przeglądarka w Twoim oknie albo wyświetli w postaci graficznej, albo zapisze na dysku.

Każdy z tych mechanizmów jest omówiony dokładniej poniżej.

DNS

DNS to akronim od Domain Name Server – w uproszczeniu jest to katalog, który dla każdej nazwy domeny (np. kobietydokodu.pl) ma przypisany adres IP serwera WWW (lub kilka adresów), lokalizację serwera poczty (stąd wysyłając maila na blog@kobietydokodu.pl serwer poczty wie, dokąd go przesłać) oraz inne informacje (np. informacje pozwalające poprawnie klasyfikować spam podszywający się pod daną domenę).

Każda z tych informacji nazywa się rekordem, dla każdej domeny może być zapisane (teoretycznie) nieskończenie wiele rekordów. Każdy rekord to ‚klucz’, ‚typ’ oraz ‚wartość’. Kluczem jest np. subdomena, którą chcemy opisać. Typ to rodzaj informacji, a wartość to parametr, który ustawiamy. Najważniejsze typy rekordów DNS to:

  • A – adres IP dla konkretnej domeny lub subdomeny
  • AAAA – adres IP (IPv6) dla konkretnej domeny lub subdomeny
  • CNAME – deleguje konfigurację DNS na inną nazwę domeny
  • MX – nazwa serwera email obsługującego daną domenę
  • NS – adres serwera zarządzającego rekordami DNS dla danej domeny i  jej subdomen
  • Więcej typów rekordów na wikipedii

Skąd jednak przeglądarka wie, gdzie szukać takiego rekordu? Odbywa się to dzięki hierarchicznej strukturze katalogu DNS. Aby ‚odtworzyć’ to, co robi przeglądarka musimy podzielić naszą domenę na elementy – kropki traktowane są jako separatory. W naszym przypadku będzie to ‚kobietydokodu’ oraz ‚pl’. Następnie odwracamy kolejność otrzymując listę ‚pl’, ‚kobietydokodu’ . Istnieje główny rejestr, zarządzany przez organizację ICAAN, który posiada rekordy DNS dla wszystkich domen narodowych (i nie tylko) – są to tak zwane domeny TLD (Top Level Domain). Każda taka domena posiada organizację zarządzającą – dla domen .pl jest to NASK. Przeglądarka najpierw pyta więc o domenę ‚pl’, po czym dostaje odpowiedź pod jakim adresem w sieci jest ona zarządzana. Następnie tam wysyła zapytanie o ‚kobietydokodu’, skąd dostaje lokalizację, pod którą jest zarządzana domena kobietydokodu.pl. Tam znajduje się już konkretny adres serwera w naszym przypadku – ten serwer może być zarządzany przez Ciebie, najczęściej jednak wykupując hosting, serwer ten jest zarządzany przez usługodawcę.

Taka struktura pozwala na dużą niezawodność ale też wolność internetu od wpływów politycznych i od ataków hakerów – każdy kraj posiada własną organizację, która zarządza jego domeną narodową i przechowuje wszystkie dane.

W rzeczywistości nie każde zapytanie skutkuje pytaniami do serwera DNS – rekordy posiadają dodatkowy parametr ‚TTL’, który określa, jak długo konkretna wartość jest ‚ważna’ – tzn po jakim czasie należy ją odświeżyć. Zarówno system operacyjny, jak i przeglądarka mogą przechowywać te informacje przez jakiś czas aby przyspieszyć działanie w przyszłości.

Protokół HTTP

Kiedy już przeglądarka ‚przetłumaczy’ nazwę domeny na adres IP konkretnego serwera, do gry wchodzi protokół HTTP – przeglądarka wysyła zapytanie do serwera, który odpowiada odpowiednią treścią.

W kwestii protokołu HTTP należy pamiętać (uwaga: te fakty dotyczą protokołu w wersji podstawowej, bez rozszerzeń – wiele standardów rozszerza protokół HTTP czyniąc go efektywniejszym, ale ta wiedza wykracza poza to, co będzie Ci potrzebne na początku; poniższe zasady i fakty są nadal ważne i obowiązujące):

  • jest to protokół typu zapytanie-odpowiedź (request-response) – połączenie jest nawiązywane tylko na czas transmisji danych i nie jest utrzymywane dłużej – każde kolejne zapytanie do tego samego serwera powoduje nawiązanie nowego połączenia
  • jest bezstanowy – sam protokół nie ‚przechowuje’ stanu – na podstawie wymiany informacji nie można nic powiedzieć na temat wcześniejszej komunikacji czy wymiany danych pomiędzy klientem a serwerem (co nie znaczy, że nie istnieją mechanizmy które to umożliwiają – najprostszym jest mechanizm ciasteczek, który jest częścią HTTP i pozwala na przechowywanie i przenoszenie informacji pomiędzy kolejnymi zapytaniami)
  • jest tekstowy – transmisja odbywa się w formie tekstowej, tzn. przechwytując przesyłane informacje, są one czytelne dla człowieka

Sama interakcja pomiędzy serwerem a klientem jest zawsze inicjowana przez klienta, który wysyła zapytanie, i otrzymuje od serwera odpowiedź. Zarówno zapytanie, jak i odpowiedź mają podobną budowę i składają się z kilku elementów:

  • zapytanie/odpowiedź – jest to główna różnica pomiędzy zapytaniem a odpowiedzią
    • zapytanie zawiera metodę HTTP, adres URI oraz wersję protokołu
    • odpowiedź zawiera wersję protokołu HTTP oraz kod statusu
  • listę nagłówków HTTP w formacie Nazwa: Wartość, oddzielonych znakiem nowej linii
  • jedną pustą linię
  • zawartość (tzw. payload) – np. dane formularza, kod HTML zwracanej strony lub zawartość pliku

Jeśli chodzi o metody HTTP, odpowiadają one różnym operacją które możemy wykonać na potencjalnym pliku lub zasobie zdalnym, kilka najważniejszych to:

  • GET – pobieranie zasobu
  • POST – przesłanie danych do lokalizacji zdalnej
  • DELETE – żądanie usunięcia zasobu
  • dokładniejszy opis oraz listę pozostałych znajdziesz np. na wikipedii

Statusy HTTP to liczba, która określa jaki był wynik zapytania. Są one pogrupowane na kilka sekcji:

  • 1xx – informacyjne
  • 2xx – operacja zakończona powodzeniem
    • do tej grupy zalicza się kod 200 oznaczający OK, i zwracany zawsze, kiedy zapytanie się powiedzie
  • 3xx – przekierowanie
  • 4xx – błędy spowodowane przez klienta (w tym także brak dostępu, nieistniejący zasób itp)
  • 5xx – błędy po stronie serwera

Jako ciekawostkę zachęcamy do sprawdzenia znaczenia i pochodzenia kodu 418 – jest on faktycznie uwzględniony w wielu implementacjach ;)

Kompletną listę kodów HTTP wraz z ich znaczeniem znajdziesz np. na wikipedii.

Po stronie serwera

Póki co omówiliśmy co się dzieje niezależnie od serwera – czyli jak działa przeglądarka WWW i co robi po kolei, oraz jak to działa ‚online’. Po stronie serwera jest trochę większa dowolność – dopóki aplikacja jest zgodna z protokołem HTTP, może być zaimplementowana w dowolny sposób (i prawda jest taka, że wiele ‚dużych’ aplikacji z tego czy innego powodu działa niestandardowo). Poniżej omówimy najbardziej standardową aplikację, najczęściej rzeczywiste systemy są rozwinięciem i modyfikacją tego schematu.

Load balancer

W większości przypadków aplikacje działają z użyciem tzw. Load Balancera. Jego zadaniem jest kierowanie ruchu do różnych serwerów, na których działa dokładnie taka sama aplikacja. Głównym celem takiego działania jest skalowanie oraz zabezpieczenie przed awarią jednego z serwerów. Load Balancer przyjmuje zapytania od klientów, a następnie przekierowuje je do jednego z działających serwerów. To druga funkcja, która jest często implementowana – sprawdzanie, czy serwery są ‚zdrowe’ i mogą obsługiwać ruch klientów. Dzięki zastosowaniu load-balancera aplikacja może obsługiwać dużo większy ruch niż pojedyncze serwery, a prawdopodobieństwo awarii jest też odpowiednio niższe.

Istnieją zarówno rozwiązania sprzętowe, jak i programowe (np. nginx czy Amazon ELB).

Jeśli chodzi o samo działanie load-balancera jest kilka parametrów, z których najważniejsze są dwa:

  • algorytm rotujący – wg jakiego algorytmu zapytanie jest przydzielane do konkretnego serwera, najprostszy to ’round-robin’, czyli przydzielanie zapytań po kolei do kolejnych serwerów; algorytmy te mogą uwzględniać heurystyki dotyczące zapytań (np. fakt, że zapytanie typu POST wymaga x razy więcej zasobów niż zapytanie typu GET) lub faktyczne mierzalne wartości (jak np. wykorzystanie procesora czy pamięci RAM)
  • session stickyness – jeśli parametr ten jest uwzględniony, wszystkie zapytania od jednego użytkownika (powiązane z jedną sesją) będą kierowane do tego samego serwera – jest to rozwiązanie bardzo pomocne szczególnie w sytuacji, kiedy aplikacja nie jest przystosowana do działania na wielu serwerach jednocześnie (choć oczywiście może to nie być wystarczające rozwiązanie mimo wszystko)

Load Balancery to jedna z podstawowych metod pozwalających na skalowanie aplikacji.

Serwer HTTP

Serwer HTTP to nic innego jak aplikacja, która implementuje protokół HTTP. Działa ona na każdym z serwerów ‚za’ load balancerem (lub czasem bezpośrednio na serwerze podpiętym do domeny bez load balancera). Serwer na podstawie zapytania HTTP, które otrzymuje, podejmuje okresloną akcję a następnie zwraca wynik. Współcześnie większość rzeczy dostępnych w internecie to aplikacje webowe – czyli aplikacje, które posiadają logikę opierającą się o zapytania HTTP.

Serwery HTTP są dostępne w prawie każdym języku programowania, na większość platform. Zaczynając od Apache Server (znany także jako httpd), poprzez nginx (oba napisane w C++), Tomcat i Jetty (Java), IIS (C#), kończąc na bibliotekach i modułach jak np. SimpleHTTPServer w Pythonie. Każdy z nich działa minimalnie inaczej, ale ich cechą wspólną jest to, że komunikują się ze światem z użyciem protokołu HTTP.

CDN (Content Delivery Network)

CDN to jedna z metod na obniżenie kosztów działania globalnej aplikacji web oraz przyspieszenie jej wyświetlania w przeglądarce.

Głównym celem sieci CDN jest dostarczanie treści statycznych. Ponieważ standardowe serwery HTTP są wielofunkcyjne, a przez to najprostsza operacja – zwrócenie statycznego obrazka czy tekstu – jest stosunkowo ‚kosztowna’ jeśli chodzi o zasoby (a więc także koszty pieniężne). Aby zoptymalizować wykorzystanie serwerów, obsługa treści statycznych jest delegowana do serwerów przeznaczonych tylko do tego celu, a więc także zoptymalizowanych pod tym kątem. Dzięki temu ogólny koszt wyświetlenia witryny dla jednego użytkownika jest niższy.

CDNy mają jeszcze jedną bardzo istotną funkcję – bardzo często są one umieszczane w wielu lokalizacjach geograficznych (tzw. edge locations), podczas wykonywania zapytania używana jest ta, która jest najbliżej ‚pytającego’ – czyli klienta wykonującego zapytanie. Pozwala to zaoszczędzić sporo czasu przy wyświetlaniu strony (np. minimalny czas pobrania czegoś z serwera w USA będąc w Europie to ok. 200ms – CDN zlokalizowany np. w Irlandii czy Niemczech zwróci ten sam zasób w kilkanaście/kilkadziesiąt milisekund). Biorąc pod uwagę ilość elementów graficznych na współczesnych stronach (często jest to nawet kilkaset na pojedynczej witrynie), ma to zauważalny dla człowieka efekt.

Systemy CDN są najczęściej rozwiązaniami głównie softwareowymi, oferowanymi zarówno w ramach innych usług (np. usługa CloudFront w ramach Amazon AWS) jak też jako jeden z głównych produktów firmy (np. firma CloudFlare specjalizuje się w rozwiązaniach opartych o zasadę działania CDN). Niektóre firmy budują także rozwiązania dedykowane, sprzętowe, ale jest to bardzo bardzo sporadyczne (ostatnio Dropbox podjął się tego rodzaju inicjatywy).

O ile CDNy nie są absolutną koniecznością, o ile nie obsługujesz milionów użytkowników z całego świata, warto je rozważyć jak tylko ruch w Twojej aplikacji zacznie rosnąć – są efektywnym sposobem redukcji kosztów i polepszania wrażenia użytkowników końcowych.

Podsumowanie

Jak sama widzisz, Internet to w gruncie rzeczy prosty koncept, który działa na ogromną skalę. Choć mechanizmy, które pozwalają mu działać są skomplikowane i zaawansowane, jeśliby wchodzić w szczegóły, to stoją za nimi proste idee. Zasadę działania warto jednak znać – po pierwsze dlatego, że często możesz być o to zapytana na rozmowie kwalifikacyjnej, ale także znając dostępne narzędzia i możliwości, łatwiej jest rozwiązywać problemy z którymi się zetkniesz w pracy :)

  •  
  •  
  •  
  •  
  •  
  • Zawsze jak czytam takie wpisy zastanawiam się jak są one odbierane przez osoby, które jeszcze tej wiedzy nie mają. Nawet dla „technicznych” osób, czasami ilość wiedzy przekazana w takim artykule może być ogromna ;)

    Jeśli dobrze kojarzę to nie jest do końca tak, że URI jest częścią URL a raczej nadzbiorem URLi.
    URL = ://(:)()

    • Co do URI niekoniecznie masz racje – URI faktycznie jest ‚nadzbiorem’ URL, ale jednocześnie jest to bardzo elastyczna definicja. W efekcie mimo, że ‚ścieżka’ jest częścią URLa, który jest URI, to ona sama także jest URI. Zerknij np na https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#Examples_of_URI_references na przykłady (lub do RFC, jeśli masz wystarczająco cierpliwości i wolnego czasu :) ). Sama specyfikacja HTTP także definiuje ‚ścieżkę’ jako URI (dokładniej rzecz ujmując wszędzie odnoszą się do tej części jako ‚request URI’) – sekcja 5.1 dokumentu https://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html .
      Także jednocześnie masz racje, że URL to URI, nie mając jej w twierdzeniu, że ścieżka to nie URI ;)
      Ale dzięki wielkie za zwrócenie uwagi i spostrzegawczość!

      • Lolek

        Poprawcie to, bo w waszym artykule URI jest zdefiniowane jako część URL co być może jest prawdą, ale przede wszystkim URL jest URI.

        • Obawiam się, że informacja ta nie wniesie za wiele do artykułu – fakt, że URI jest częścią URL, który jest jednocześnie URI może być nieco zawiły dla czytelników. Jednocześnie nie zmienia to żadnego faktu przedstawionego w artykule. URI/URL w artykule są używane głównie jako nazwy, jego celem nie jest dogłębne zapoznanie czytelnika z kompletną definicją każdego z tych pojęć. Dobrze, że dyskusja ta pojawiła się pod artykułem, dla zainteresowanych, ale dla samego meritum nie ma znaczenia.

  • piotrek7035

    Zauważyłem, że w spisie „”niezbędnik juniora” nie ma tego tematu, trafiłem na niego całkiem przypadkowo z podpowiedzi :) Proponuję podpiąć, bo naprawdę fajny i pomocny artykuł

    • Faktycznie, czasem zapominamy dodawać na bieżąco :( zaraz zaktualizuje, dzięki za przypomnienie!