Jak działa internet? DNS, serwery, requesty

Wpisujesz google.com w przeglądarkę i po chwili widzisz stronę. Ale co dzieje się po drodze? Jak komputer znajduje właściwy serwer, jak dogaduje się z nim co do szyfrowania i jak odpowiedź wraca z sieci na Twój ekran?

Jako frontend developer używasz internetu codziennie, ale łatwo traktować go jak czarną skrzynkę. Ten artykuł rozkłada ten proces na części bez zbędnego żargonu. To wiedza, która przyda się i przy debugowaniu, i na rozmowie technicznej.

Krótka odpowiedź: Od URL do strony: DNSDNS, czyli Domain Name System, tłumaczy nazwy domen na adresy IP potrzebne do połączenia z serwerem. resolwuje domenę na IP (cache lokalny → ISP → root servers) → TCP handshake (3-way) → TLS handshake (HTTPS) → HTTP request → serwer odpowiada HTML → przeglądarka parsuje i renderuje. Cały ten proces zwykle zajmuje od kilkudziesięciu do kilkuset milisekund, zależnie od cache, sieci i odległości od serwera.

Wielki obrazek — co się dzieje gdy wpisujesz URL

1. Wpisujesz: google.com
          ↓
2. DNS: "google.com to 142.250.186.206"
          ↓
3. TCP lub QUIC: Nawiązanie połączenia transportowego
          ↓
4. TLS/HTTPS: Ustalenie szyfrowania i wysłanie żądania
          ↓
5. Serwer: Przetworzenie i odpowiedź
          ↓
6. Przeglądarka: Rendering HTML/CSS/JS
          ↓
7. Widzisz stronę Google

Teraz rozbijmy każdy krok.

Adresy IP — prawdziwe adresy w internecie

Komputery nie rozumieją google.com. Rozumieją adresy IP — numeryczne identyfikatory:

IPv4: 142.250.186.206 (4 liczby 0-255)
IPv6: 2607:f8b0:4004:800::200e (dłuższy, więcej adresów)

Adres IP działa jak adres pocztowy dla ruchu sieciowego. W praktyce urządzenie często ma lokalny adres w sieci domowej, a na zewnątrz wychodzi przez publiczny adres routera lub infrastruktury operatora.

Twój komputer też ma IP:

# Sprawdź swoje lokalne IP
ipconfig  # Windows
ifconfig  # macOS
ip addr   # Linux
 
# Sprawdź publiczne IP
curl ifconfig.me

DNS — książka telefoniczna internetu

DNS (Domain Name System) tłumaczy nazwy domen na adresy IP:

google.com → 142.250.186.206
facebook.com → 157.240.1.35
twoja-strona.pl → 123.45.67.89

Jak działa zapytanie DNS?

1. Wpisujesz: google.com
          ↓
2. Przeglądarka: "Czy mam to w cache?" → Nie
          ↓
3. System operacyjny: "Czy mam to w cache?" → Nie
          ↓
4. Router: "Czy mam to w cache?" → Nie
          ↓
5. DNS Resolver (ISP): "Zapytam root server..."
          ↓
6. Root Server: "Zapytaj .com server"
          ↓
7. .com Server: "Zapytaj autorytatywny serwer domeny google.com"
          ↓
8. Serwer autorytatywny: "142.250.186.206"
          ↓
9. Odpowiedź wraca tą samą drogą (z cache)

Hierarchia DNS

                    Root (.)
                       │
         ┌─────────────┼─────────────┐
        .com          .org          .pl
         │             │             │
    ┌────┼────┐       ...      ┌────┼────┐
 google amazon              onet   wp
    │
   www

Rekordy DNS

A      → IPv4 adres (google.com → 142.250.186.206)
AAAA   → IPv6 adres
CNAME  → Alias (www.google.com → google.com)
MX     → Mail server
TXT    → Tekst (weryfikacja, SPF)
NS     → Name server

Sprawdź DNS sam

# Podstawowe zapytanie
nslookup google.com
 
# Szczegółowe
dig google.com
 
# Konkretny rekord
dig google.com MX

TCP/IP — jak dane podróżują

Model warstw

Internet działa w warstwach — każda ma swoją rolę:

┌─────────────────────────────────────┐
│  Aplikacja (HTTP, HTTPS, FTP)       │  ← Tu pracujesz jako dev
├─────────────────────────────────────┤
│  Transport (TCP, UDP)               │  ← Niezawodność, porty
├─────────────────────────────────────┤
│  Internet (IP)                      │  ← Adresowanie, routing
├─────────────────────────────────────┤
│  Sieć (Ethernet, WiFi)              │  ← Fizyczne połączenie
└─────────────────────────────────────┘

IP — adresowanie i routing

IP odpowiada za:

• Adresowanie — skąd i dokąd
• Routing — jaką drogą

Dane są dzielone na pakiety. Każdy pakiet ma nagłówek z adresami:

┌─────────────────────────────────────┐
│ Source IP: 192.168.1.100            │
│ Destination IP: 142.250.186.206     │
│ TTL: 64                             │
│ ... inne metadane ...               │
├─────────────────────────────────────┤
│ Dane (fragment wiadomości)          │
└─────────────────────────────────────┘

Pakiety mogą jechać różnymi drogami i dotrzeć w różnej kolejności!

TCP — niezawodność

TCP (Transmission Control Protocol) zapewnia:

• Pakiety dotrą
• W prawidłowej kolejności
• Bez błędów

Three-way handshake — nawiązanie połączenia:

Klient                     Serwer
   │                          │
   │──── SYN ────────────────▶│  "Chcę się połączyć"
   │                          │
   │◀──── SYN-ACK ────────────│  "OK, ja też"
   │                          │
   │──── ACK ────────────────▶│  "Super, zaczynamy"
   │                          │
   │◀════ Połączenie ════════▶│

Numery sekwencji:

Pakiet 1: SEQ=1, dane="Hel"
Pakiet 2: SEQ=4, dane="lo "
Pakiet 3: SEQ=7, dane="Wor"
Pakiet 4: SEQ=10, dane="ld!"

Odbiorca składa w całość: "Hello World!"

Potwierdzenia (ACK):

Klient: Wysyłam pakiet SEQ=1
Serwer: Otrzymałem, ACK=4 (czekam na kolejny od 4)
Klient: Wysyłam pakiet SEQ=4
Serwer: ACK=7
...

Jeśli ACK nie przyjdzie → retransmisja

UDP — szybkość bez gwarancji

UDP (User Datagram Protocol) to "fire and forget":

• Szybszy (brak handshake)
• Brak gwarancji dostarczenia
• Brak kolejności

Używany w:

• Streaming video/audio
• Gry online
• większość klasycznych zapytań DNS
• VoIP

Warto znać ważny wyjątek: nowoczesny HTTP/3 działa na QUIC, czyli nad UDP, a nie nad TCP.

Porty — rozróżnianie usług

Jeden serwer może obsługiwać wiele usług. Porty je rozróżniają:

IP: 142.250.186.206
Port 80: HTTP
Port 443: HTTPS
Port 22: SSH
Port 25: SMTP (email)

Pełny adres: 142.250.186.206:443

Znane porty:

• 80 — HTTP
• 443 — HTTPS
• 22 — SSH
• 21 — FTP
• 3000 — często dev server
• 5432 — PostgreSQL
• 27017 — MongoDB

Routing — jak pakiety znajdują drogę

Pakiet przeskakuje przez wiele routerów:

# Zobacz trasę pakietu
traceroute google.com  # Mac/Linux
tracert google.com     # Windows
 
# Przykładowy wynik:
1  192.168.1.1 (router domowy)     1ms
2  10.0.0.1 (ISP)                  5ms
3  72.14.215.85 (backbone)         15ms
4  142.250.186.206 (Google)        20ms

Każdy router decyduje: "Gdzie wysłać ten pakiet dalej?"

HTTP/HTTPS — protokół aplikacji

Na szczycie warstwy transportowej działa HTTP — protokół, którym rozmawiasz z serwerami web. W HTTP/1.1 i HTTP/2 najczęściej jedzie on po TCP, a w HTTP/3 po QUIC/UDP.

HTTP Request

GET /search?q=hello HTTP/1.1
Host: google.com
User-Agent: Mozilla/5.0...
Accept: text/html
Accept-Language: pl
Cookie: session=abc123

HTTP Response

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 12345
Cache-Control: max-age=3600
 
<!DOCTYPE html>
<html>...

HTTPS — szyfrowanie

HTTPS = HTTP + TLS (Transport Layer Security)

TLS Handshake:

1. Klient: "Cześć, obsługuję te algorytmy szyfrowania..."
2. Serwer: "OK, używamy AES-256. Oto mój certyfikat."
3. Klient: (weryfikuje certyfikat z CA)
4. Klient: "Oto zaszyfrowany klucz sesji"
5. Obie strony: Mają wspólny klucz, komunikacja zaszyfrowana

Certyfikat SSL/TLS zawiera:

• Nazwę domeny
• Klucz publiczny
• Wystawcę (CA)
• Datę ważności
• Podpis cyfrowy

Sprawdź certyfikat:

• Kliknij kłódkę w przeglądarce
• openssl s_client -connect google.com:443

CDN — treść bliżej użytkownika

CDNCDN, czyli Content Delivery Network, przyspiesza dostarczanie zasobów z serwerów bliższych użytkownikowi. (Content Delivery Network) to sieć serwerów na całym świecie:

Bez CDN:
Użytkownik (Polska) ────────────────▶ Serwer (USA)
                     ~150ms latency

Z CDN:
Użytkownik (Polska) ──▶ CDN Edge (Niemcy) ──▶ Origin (USA)
                  ~20ms           (cache)

Popularne CDN (używane też przez platformy serverless):

• Cloudflare
• AWS CloudFront
• Fastly
• Akamai

Co cachuje CDN:

• Statyczne pliki (JS, CSS, obrazy)
• Czasem całe strony HTML

Podsumowanie — pełna podróż requestu

1. Wpisujesz: https://google.com/search?q=hello

2. DNS Resolution:
   google.com → 142.250.186.206

3. TCP Handshake:
   SYN → SYN-ACK → ACK

4. TLS Handshake:
   Wymiana certyfikatów i kluczy

5. HTTP Request:
   GET /search?q=hello HTTP/1.1

6. Routing:
   Pakiety przez ~10-20 routerów

7. Serwer:
   Przetwarza request, generuje HTML

8. HTTP Response:
   200 OK + HTML

9. Przeglądarka:
   Parsuje HTML, pobiera CSS/JS, renderuje

10. Widzisz wyniki wyszukiwania!

Czas: od kilkudziesięciu milisekund do setek milisekund, zależnie od DNS, odległości od serwera, TLS, cache i liczby dodatkowych zasobów.

Narzędzia do eksploracji

# DNS
nslookup domain.com
dig domain.com
 
# Ping (czy host odpowiada)
ping google.com
 
# Traceroute (trasa pakietów)
traceroute google.com
 
# Curl (HTTP requests)
curl -v https://google.com
 
# Netstat (aktywne połączenia)
netstat -an
 
# DevTools → Network tab (w przeglądarce)

FAQ

Co dzieje się gdy wpisujesz adres URL w przeglądarkę?

Sekwencja kroków: (1) Sprawdzenie cache DNS w przeglądarce; (2) Jeśli brak — zapytanie do systemu operacyjnego i /etc/hosts; (3) Zapytanie do rekurencyjnego resolvera ISP; (4) Resolver pyta Root Server → TLD Server (.com) → Authoritative Server domeny → dostaje IP; (5) TCP three-way handshake (SYN → SYN-ACK → ACK); (6) TLS handshake (dla HTTPS) — wymiana certyfikatów i klucza; (7) HTTP request; (8) Serwer odpowiada HTML; (9) Przeglądarka parsuje HTML, pobiera zasoby (CSS, JS, obrazy), renderuje stronę.

Co to jest DNS i jak działa?

DNS (Domain Name System) to "książka telefoniczna internetu" — tłumaczy domeny (google.com) na adresy IP (142.250.186.206). Hierarchia: Root Servers (13 klastrów) → TLD Name Servers (.com, .pl) → Authoritative Name Servers (dla konkretnej domeny). DNS cache przyspiesza ten proces — przeglądarka, OS i ISP cachują wyniki przez czas TTL rekordu. Propagacja zmian DNS trwa 0-48 godzin ze względu na różne wartości TTL i cache w różnych punktach sieci.

Co to jest TCP i czym różni się od UDP?

TCP (Transmission Control Protocol): niezawodny, z potwierdzeniami (ACK), rejestruje utracone pakiety, gwarantuje kolejność. Wymaga three-way handshake przed transmisją. Używany przez HTTP/HTTPS, e-mail, SSH. UDP (User Datagram Protocol): bez potwierdzenia, bez retransmisji, szybszy. Używany przez DNS, streaming video, gry online, VoIP — gdzie prędkość ważniejsza od niezawodności. HTTP/3 (QUIC) działa na UDP ale dodaje własną warstwę niezawodności.

Czym jest TLS i jak zabezpiecza połączenie?

TLS (Transport Layer Security) to protokół szyfrowania działający między TCP a HTTP w HTTPS. Proces: (1) Client Hello — przeglądarka wysyła obsługiwane wersje TLS i algorytmy; (2) Server Hello — serwer wybiera algorytm, wysyła certyfikat SSL; (3) Przeglądarka weryfikuje certyfikat przez urząd certyfikacji (CA); (4) Wymiana kluczy i ustalenie klucza sesji; (5) Zaszyfrowana komunikacja. TLS szyfruje transmisję — chroni przed podsłuchiwaniem, ale nie naprawia problemów po stronie aplikacji.

Co to jest CDN i jak przyspiesza ładowanie stron?

CDN (Content Delivery Network) to sieć serwerów rozmieszczonych globalnie (edge nodes). Statyczne zasoby (obrazy, CSS, JS) są kopiowane na edge nodes blisko użytkowników. Gdy użytkownik z Polski odwiedza stronę hostowaną w USA, plik statyczny ładuje się z serwera CDN w Europie — nie z USA. Efekt: niższy latency, mniejsze TTFBTTFB, czyli Time to First Byte, mierzy czas od wysłania żądania do odebrania pierwszego bajtu odpowiedzi.. Cloudflare, AWS CloudFront, Fastly to popularne CDN. Vercel i Netlify mają wbudowany CDN dla statycznych assetów.

Co to jest IP, IPv4 i IPv6?

IP (Internet Protocol) to adres identyfikujący urządzenie w sieci. IPv4: 4 oktety (np. 192.168.1.1), ~4 miliardy adresów — skończyły się. IPv6: 128-bit (np. 2001:0db8::1), niemal nieograniczona przestrzeń adresowa. NAT (Network Address Translation) pozwala wielu urządzeniom za routerem dzielić jeden publiczny IP — to dlatego masz 192.168.x.x lokalnie, ale jeden publiczny IP. Większość serwerów wspiera dziś IPv4 i IPv6 jednocześnie (dual-stack).

Jak działają HTTP/2 i HTTP/3 w kontekście wydajności?

HTTP/1.1: jeden request per połączenie (lub pipelining, ale z problemami). Przeglądarka otwiera zwykle kilka połączeń per origin. HTTP/2: multiplexing — wiele requestów przez jedno połączenie TCP, bez head-of-line blocking na poziomie HTTP, header compression (HPACK). Znaczna poprawa przy wielu małych plikach. HTTP/3: używa QUIC (UDP-based), eliminuje head-of-line blocking na poziomie TCP, skraca koszt zestawienia połączenia i lepiej radzi sobie przy stratach pakietów, np. na mobile. Historyczny Server Push nie okazał się trwałą przewagą HTTP/2 i dziś nie jest głównym argumentem przy wyborze protokołu. Większość CDN i nowoczesnych serwerów wspiera HTTP/2 i HTTP/3.

Źródła i dokumentacja

• Cloudflare DNS docs — rekordy DNS i TTL
• Cloudflare Learning Center — DNS A record i podstawy rekordów
• MDN — Transport Layer Security (TLS)
• MDN — Evolution of HTTP

Podsumowanie

Zrozumienie tych podstaw pomoże Ci debugować problemy sieciowe, optymalizować wydajność i lepiej współpracować z backendowcami. Przydatne będą też podstawowe narzędzia sieciowe, takie jak curl, DevTools i logi serwera.

Chcesz dowiedzieć się więcej? Sprawdź HTTP od podstaw — szczegóły protokołu, którego używasz codziennie, lub przeczytaj kompletny przegląd backendu dla frontendowca.