#Niezbędnik Juniora: Jak działa internet

Z inter­ne­tu korzys­ta każdy z nas na codzień, ale czy wiesz, jak on dzi­ała? W tym wpisie zerkniemy na najważniejsze pro­tokoły i mech­a­nizmy, dzię­ki którym to wszys­tko działa!

Słowniczek

Zan­im zaczniemy — kil­ka słów wyjaśnienia co jest czym:

• pro­tokół — zbiór zasad doty­czą­cych tego, jak ma wyglą­dać komu­nikac­ja pomiędzy dwoma sys­tema­mi (lub np. pomiędzy sys­te­mem i użytkown­ikiem), określa­ją­cy nie tylko w jaki sposób trans­mi­tować dane, ale też jak je inter­pre­tować, co oznacza­ją i jakie są ograniczenia / wyma­gania związane z wymi­aną danych
• URL / adres URL — adres URL skła­da się z 3 częś­ci (w przy­pad­ku HTTP): 
  • pro­tokół — jest to prze­drostek, który określa pro­tokół, z którego korzys­tamy; przeglą­da­jąc inter­net będzie to najczęś­ciej http:// lub https:// (ta część adresu URL zawsze kończy się dwukrop­kiem i dwoma ukośnika­mi, dal­sza część adresu jest uza­leżniona od protokołu)
  • ser­w­er — w przy­pad­ku pro­tokołu HTTP kole­jną częś­cią jest lokaliza­c­ja ser­w­era, czyli adres ser­w­era (jako nazwa dome­ny lub adres IP) oraz port, np: kobietydokodu.pl:80 — jeśli nie podamy numeru por­tu (dwukropek i numer z zakre­su 1–65535 (jest to zakres 16-bitowej licz­by), uży­wany jest domyśl­ny port (80 dla HTTP i 443 dla HTTPS)
  • URI — nastep­na część to URI, czyli część zapy­ta­nia która jest istot­na tylko i wyłacznie dla ser­w­era (pro­tokół i adres ser­w­era uza­leż­ni­a­ją dzi­ałanie i kro­ki pode­j­mowane przez przeglą­darkę, adres URI jest po pros­tu przekazy­wany do ser­w­era), jest to cała resz­ta ścież­ki zaczy­na­ją­ca się od / zaraz po adresie serwera

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

Najpierw przeglą­dar­ka musi zamienić domenę na konkret­ną lokaliza­cję ser­w­era — adres IP. Służy do tego pro­tokół DNS, z którego przeglą­dar­ka korzys­ta jeśli nie zna jeszcze danej dome­ny, lub pamięć podręcz­na przeglądarki/systemu oper­a­cyjnego, jeśli niedawno była ona używana.

Następ­nie na uzyskany adres IP wysyła zapy­ta­nia HTTP — czyli infor­ma­c­je co ma zostać zwró­cone, jakie dane są wysyłane (o ile jakiekol­wiek są) oraz dodatkowe infor­ma­c­je (np. o ciasteczkach czy o zal­o­gowanym użytkowniku).

Po stron­ie ser­w­era opro­gramowanie odbiera to zapy­tanie i przy­go­towu­je odpowiedź na pod­staw­ie tego, co ono zaw­ier­ało. Najczęś­ciej będzie to zawartość HTML lub jak­iś plik, który przeglą­dar­ka w Twoim oknie albo wyświ­etli w postaci graficznej, albo zapisze na dysku.

Każdy z tych mech­a­nizmów jest omówiony dokład­niej poniżej.

DNS

DNS to akro­n­im od Domain Name Serv­er — w uproszcze­niu jest to kat­a­log, który dla każdej nazwy dome­ny (np. kobietydokodu.pl) ma przyp­isany adres IP ser­w­era WWW (lub kil­ka adresów), lokaliza­cję ser­w­era pocz­ty (stąd wysyła­jąc maila na [email protected] ser­w­er pocz­ty wie, dokąd go przesłać) oraz inne infor­ma­c­je (np. infor­ma­c­je pozwala­jące poprawnie klasy­fikować spam pod­szy­wa­ją­cy się pod daną domenę).

Każ­da z tych infor­ma­cji nazy­wa się reko­r­dem, dla każdej dome­ny może być zapisane (teo­re­ty­cznie) nieskończe­nie wiele reko­rdów. Każdy reko­rd to ‘klucz’, ‘typ’ oraz ‘wartość’. Kluczem jest np. sub­dom­e­na, którą chce­my opisać. Typ to rodzaj infor­ma­cji, a wartość to para­metr, który ustaw­iamy. Najważniejsze typy reko­rdów DNS to:

• A — adres IP dla konkret­nej dome­ny lub subdomeny
• AAAA — adres IP (IPv6) dla konkret­nej dome­ny lub subdomeny
• CNAME — delegu­je kon­fig­u­rację DNS na inną nazwę domeny
• MX — nazwa ser­w­era email obsługu­jącego daną domenę
• NS — adres ser­w­era zarządza­jącego reko­r­da­mi DNS dla danej dome­ny i  jej subdomen
• Więcej typów reko­rdów na wikipedii

Skąd jed­nak przeglą­dar­ka wie, gdzie szukać takiego reko­r­du? Odby­wa się to dzię­ki hier­ar­chicznej struk­turze kat­a­logu DNS. Aby ‘odt­worzyć’ to, co robi przeglą­dar­ka musimy podzielić naszą domenę na ele­men­ty — krop­ki trak­towane są jako sep­a­ra­to­ry. W naszym przy­pad­ku będzie to ‘kobi­ety­doko­du’ oraz ‘pl’. Następ­nie odwracamy kole­jność otrzy­mu­jąc listę ‘pl’, ‘kobi­ety­doko­du’ . Ist­nieje główny rejestr, zarządzany przez orga­ni­za­cję ICAAN, który posi­a­da reko­rdy DNS dla wszys­t­kich domen nar­o­dowych (i nie tylko) — są to tak zwane dome­ny TLD (Top Lev­el Domain). Każ­da taka dom­e­na posi­a­da orga­ni­za­cję zarządza­jącą — dla domen .pl jest to NASK. Przeglą­dar­ka najpierw pyta więc o domenę ‘pl’, po czym dosta­je odpowiedź pod jakim adresem w sieci jest ona zarządzana. Następ­nie tam wysyła zapy­tanie o ‘kobi­ety­doko­du’, skąd dosta­je lokaliza­cję, pod którą jest zarządzana dom­e­na kobietydokodu.pl. Tam zna­j­du­je się już konkret­ny adres ser­w­era w naszym przy­pad­ku — ten ser­w­er może być zarządzany przez Ciebie, najczęś­ciej jed­nak wykupu­jąc host­ing, ser­w­er ten jest zarządzany przez usługodawcę.

Taka struk­tu­ra pozwala na dużą nieza­wod­ność ale też wol­ność inter­ne­tu od wpły­wów poli­ty­cznych i od ataków hak­erów — każdy kraj posi­a­da włas­ną orga­ni­za­cję, która zarządza jego domeną nar­o­dową i prze­chowu­je wszys­tkie dane.

W rzeczy­wis­toś­ci nie każde zapy­tanie skutku­je pyta­ni­a­mi do ser­w­era DNS — reko­rdy posi­ada­ją dodatkowy para­metr ‘TTL’, który określa, jak dłu­go konkret­na wartość jest ‘waż­na’ — tzn po jakim cza­sie należy ją odświeżyć. Zarówno sys­tem oper­a­cyjny, jak i przeglą­dar­ka mogą prze­chowywać te infor­ma­c­je przez jak­iś czas aby przyspieszyć dzi­ałanie w przyszłości.

Protokół HTTP

Kiedy już przeglą­dar­ka ‘przetłu­maczy’ nazwę dome­ny na adres IP konkret­nego ser­w­era, do gry wchodzi pro­tokół HTTP — przeglą­dar­ka wysyła zapy­tanie do ser­w­era, który odpowia­da odpowied­nią treścią.

W kwestii pro­tokołu HTTP należy pamię­tać (uwa­ga: te fak­ty doty­czą pro­tokołu w wer­sji pod­sta­wowej, bez rozsz­erzeń — wiele stan­dard­ów rozsz­erza pro­tokół HTTP czyniąc go efek­ty­wniejszym, ale ta wiedza wykracza poza to, co będzie Ci potrzeb­ne na początku; poniższe zasady i fak­ty są nadal ważne i obowiązujące):

• jest to pro­tokół typu zapy­tanie-odpowiedź (request-response) — połącze­nie jest naw­iązy­wane tylko na czas trans­misji danych i nie jest utrzymy­wane dłużej — każde kole­jne zapy­tanie do tego samego ser­w­era powodu­je naw­iązanie nowego połączenia
• jest bezs­tanowy — sam pro­tokół nie ‘prze­chowu­je’ stanu — na pod­staw­ie wymi­any infor­ma­cji nie moż­na nic powiedzieć na tem­at wcześniejszej komu­nikacji czy wymi­any danych pomiędzy klien­tem a ser­w­erem (co nie znaczy, że nie ist­nieją mech­a­nizmy które to umożli­wia­ją — najprost­szym jest mech­a­nizm ciasteczek, który jest częś­cią HTTP i pozwala na prze­chowywanie i przenosze­nie infor­ma­cji pomiędzy kole­jny­mi zapytaniami)
• jest tek­stowy — trans­mis­ja odby­wa się w formie tek­stowej, tzn. przech­wytu­jąc przesyłane infor­ma­c­je, są one czytelne dla człowieka

Sama inter­akc­ja pomiędzy ser­w­erem a klien­tem jest zawsze inicjowana przez klien­ta, który wysyła zapy­tanie, i otrzy­mu­je od ser­w­era odpowiedź. Zarówno zapy­tanie, jak i odpowiedź mają podob­ną budowę i składa­ją się z kilku elementów:

• zapytanie/odpowiedź — jest to głów­na różni­ca pomiędzy zapy­taniem a odpowiedzią 
  • zapy­tanie zaw­iera metodę HTTP, adres URI oraz wer­sję protokołu
  • odpowiedź zaw­iera wer­sję pro­tokołu HTTP oraz kod statusu
• listę nagłówków HTTP w for­ma­cie Nazwa: Wartość, odd­zielonych znakiem nowej linii
• jed­ną pustą linię
• zawartość (tzw. pay­load) — np. dane for­mu­la­rza, kod HTML zwracanej strony lub zawartość pliku

Jeśli chodzi o metody HTTP, odpowiada­ją one różnym oper­acjom, które może­my wykon­ać na potenc­jal­nym pliku lub zaso­bie zdal­nym, kil­ka najważniejszych to:

• GET — pobieranie zasobu
• POST — przesłanie danych do lokaliza­cji zdalnej
• DELETE — żądanie usunię­cia zasobu
• dokład­niejszy opis oraz listę pozostałych zna­jdziesz np. na wikipedii

Sta­tusy HTTP to licz­ba, która określa jaki był wynik zapy­ta­nia. Są one pogrupowane na kil­ka sekcji:

• 1xx — informacyjne
• 2xx — oper­ac­ja zakońc­zona powodzeniem 
  • do tej grupy zal­icza się kod 200 oznacza­ją­cy OK, i zwracany zawsze, kiedy zapy­tanie się powiedzie
• 3xx — przekierowanie
• 4xx — błędy spowodowane przez klien­ta (w tym także brak dostępu, nieist­nieją­cy zasób itp)
• 5xx — błędy po stron­ie serwera

Jako cieka­wostkę zachę­camy do sprawdzenia znaczenia i pochodzenia kodu 418 — jest on fak­ty­cznie uwzględ­niony w wielu implementacjach ;)

Kom­plet­ną listę kodów HTTP wraz z ich znacze­niem zna­jdziesz np. na wikipedii.

Po stronie serwera

Póki co omówiliśmy co się dzieje nieza­leżnie od ser­w­era — czyli jak dzi­ała przeglą­dar­ka WWW i co robi po kolei, oraz jak to dzi­ała ‘online’. Po stron­ie ser­w­era jest trochę więk­sza dowol­ność — dopó­ki aplikac­ja jest zgod­na z pro­tokołem HTTP, może być zaim­ple­men­towana w dowol­ny sposób (i praw­da jest taka, że wiele ‘dużych’ aplikacji z tego czy innego powodu dzi­ała nie­s­tandar­d­owo). Poniżej omówimy najbardziej stan­dar­d­ową aplikację, najczęś­ciej rzeczy­wiste sys­te­my są rozwinię­ciem i mody­fikacją tego schematu.

Load balancer

W więk­szoś­ci przy­pad­ków aplikac­je dzi­ała­ją z uży­ciem tzw. Load Bal­ancera. Jego zadaniem jest kierowanie ruchu do różnych ser­w­erów, na których dzi­ała dokład­nie taka sama aplikac­ja. Głównym celem takiego dzi­ała­nia jest skalowanie oraz zabez­piecze­nie przed awar­ią jed­nego z ser­w­erów. Load Bal­ancer przyj­mu­je zapy­ta­nia od klien­tów, a następ­nie przekierowu­je je do jed­nego z dzi­ała­ją­cych ser­w­erów. To dru­ga funkc­ja, która jest częs­to imple­men­towana — sprawdzanie, czy ser­w­ery są ‘zdrowe’ i mogą obsługi­wać ruch klien­tów. Dzię­ki zas­tosowa­niu load-bal­ancera aplikac­ja może obsługi­wać dużo więk­szy ruch niż poje­dyncze ser­w­ery, a praw­dopodobieńst­wo awarii jest też odpowied­nio niższe.

Ist­nieją zarówno rozwiąza­nia sprzę­towe, jak i pro­gramowe (np. nginx czy Ama­zon ELB).

Jeśli chodzi o samo dzi­ałanie load-bal­ancera jest kil­ka para­metrów, z których najważniejsze są dwa:

• algo­rytm rotu­ją­cy — wg jakiego algo­ryt­mu zapy­tanie jest przy­dzielane do konkret­nego ser­w­era, najprost­szy to ’round-robin’, czyli przy­dzielanie zapy­tań po kolei do kole­jnych ser­w­erów; algo­ryt­my te mogą uwzględ­ni­ać heurysty­ki doty­czące zapy­tań (np. fakt, że zapy­tanie typu POST wyma­ga x razy więcej zasobów niż zapy­tanie typu GET) lub fak­ty­czne mierzalne wartoś­ci (jak np. wyko­rzys­tanie pro­ce­so­ra czy pamię­ci RAM)
• ses­sion stick­y­ness — jeśli para­metr ten jest uwzględ­niony, wszys­tkie zapy­ta­nia od jed­nego użytkown­i­ka (pow­iązane z jed­ną sesją) będą kierowane do tego samego ser­w­era — jest to rozwiązanie bard­zo pomoc­ne szczegól­nie w sytu­acji, kiedy aplikac­ja nie jest przys­tosowana do dzi­ała­nia na wielu ser­w­er­ach jed­nocześnie (choć oczy­wiś­cie może to nie być wystar­cza­jące rozwiązanie mimo wszystko)

Load Bal­ancery to jed­na z pod­sta­wowych metod pozwala­ją­cych na skalowanie aplikacji.

Serwer HTTP

Ser­w­er HTTP to nic innego jak aplikac­ja, która imple­men­tu­je pro­tokół HTTP. Dzi­ała ona na każdym z ser­w­erów ‘za’ load bal­ancerem (lub cza­sem bezpośred­nio na ser­w­erze pod­pię­tym do dome­ny bez load bal­ancera). Ser­w­er na pod­staw­ie zapy­ta­nia HTTP, które otrzy­mu­je, pode­j­mu­je okres­loną akcję a następ­nie zwraca wynik. Współcześnie więk­szość rzeczy dostęp­nych w internecie to aplikac­je webowe — czyli aplikac­je, które posi­ada­ją logikę opier­a­jącą się o zapy­ta­nia HTTP.

Ser­w­ery HTTP są dostęp­ne w praw­ie każdym języku pro­gramowa­nia, na więk­szość plat­form. Zaczy­na­jąc od Apache Serv­er (znany także jako httpd), poprzez nginx (oba napisane w C++), Tom­cat i Jet­ty (Java), IIS (C#), kończąc na bib­liotekach i mod­ułach jak np. Sim­ple­HTTPServ­er w Pythonie. Każdy z nich dzi­ała min­i­mal­nie inaczej, ale ich cechą wspól­ną jest to, że komu­niku­ją się ze światem z uży­ciem pro­tokołu HTTP.

CDN (Content Delivery Network)

CDN to jed­na z metod na obniże­nie kosztów dzi­ała­nia glob­al­nej aplikacji web oraz przyspiesze­nie jej wyświ­et­la­nia w przeglądarce.

Głównym celem sieci CDN jest dostar­czanie treś­ci staty­cznych. Ponieważ stan­dar­d­owe ser­w­ery HTTP są wielo­funkcyjne, a przez to najprost­sza oper­ac­ja — zwróce­nie staty­cznego obraz­ka czy tek­stu — jest sto­sunkowo ‘kosz­tow­na’ jeśli chodzi o zaso­by (a więc także kosz­ty pieniężne). Aby zop­ty­mal­i­zować wyko­rzys­tanie ser­w­erów, obsłu­ga treś­ci staty­cznych jest dele­gowana do ser­w­erów przez­nac­zonych tylko do tego celu, a więc także zop­ty­mal­i­zowanych pod tym kątem. Dzię­ki temu ogól­ny koszt wyświ­etle­nia wit­ryny dla jed­nego użytkown­i­ka jest niższy.

CDNy mają jeszcze jed­ną bard­zo istot­ną funkcję — bard­zo częs­to są one umieszczane w wielu lokaliza­c­jach geograficznych (tzw. edge loca­tions), pod­czas wykony­wa­nia zapy­ta­nia uży­wana jest ta, która jest najbliżej ‘pyta­jącego’ — czyli klien­ta wykonu­jącego zapy­tanie. Pozwala to zaoszczędz­ić sporo cza­su przy wyświ­et­la­niu strony (np. min­i­mal­ny czas pobra­nia czegoś z ser­w­era w USA będąc w Europie to ok. 200ms — CDN zlokali­zowany np. w Irlandii czy Niem­czech zwró­ci ten sam zasób w kilkanaście/kilkadziesiąt milisekund). Biorąc pod uwagę ilość ele­men­tów graficznych na współczes­nych stronach (częs­to jest to nawet kilka­set na poje­dynczej wit­rynie), ma to zauważal­ny dla człowieka efekt.

Sys­te­my CDN są najczęś­ciej rozwiąza­ni­a­mi głównie soft­ware­owy­mi, ofer­owany­mi zarówno w ramach innych usług (np. usłu­ga Cloud­Front w ramach Ama­zon AWS) jak też jako jeden z głównych pro­duk­tów firmy (np. fir­ma Cloud­Flare spec­jal­izu­je się w rozwiąza­ni­ach opar­tych o zasadę dzi­ała­nia CDN). Niek­tóre firmy budu­ją także rozwiąza­nia dedykowane, sprzę­towe, ale jest to bard­zo bard­zo spo­rady­czne (ostat­nio Drop­box pod­jął się tego rodza­ju inicjatywy).

O ile CDNy nie są abso­lut­ną koniecznoś­cią, o ile nie obsługu­jesz mil­ionów użytkown­ików z całego świa­ta, warto je rozważyć jak tylko ruch w Two­jej aplikacji zacznie ros­nąć — są efek­ty­wnym sposobem redukcji kosztów i polep­sza­nia wraże­nia użytkown­ików końcowych.

Podsumowanie

Jak sama widzisz, Inter­net to w grun­cie rzeczy prosty kon­cept, który dzi­ała na ogrom­ną skalę. Choć mech­a­nizmy, które pozwala­ją mu dzi­ałać są skom­p­likowane i zaawan­sowane, jeśli­by wchodz­ić w szczegóły, to sto­ją za nimi proste idee. Zasadę dzi­ała­nia warto jed­nak znać — po pier­wsze dlat­ego, że częs­to możesz być o to zapy­tana na roz­mowie kwal­i­fika­cyjnej, ale także zna­jąc dostęp­ne narzędzia i możli­woś­ci, łatwiej jest rozwiązy­wać prob­le­my z który­mi się zetkniesz w pracy :)