Networking - Pytania Rekrutacyjne dla DevOps i Backend Developera [2026]

Znajomość sieci odróżnia dobrego DevOps engineera od świetnego. Gdy produkcja pada o 3 w nocy, musisz wiedzieć czy problem to DNS, reguła firewall, czy padający load balancer - i musisz to wiedzieć szybko.

Ten przewodnik zawiera 50+ pytań rekrutacyjnych z odpowiedziami - od podstaw TCP/IP, przez DNS i HTTP, po load balancing i troubleshooting. To nie teoria z certyfikacji, ale praktyczna wiedza do debugowania prawdziwych systemów.

Spis treści

• Podstawy sieci
• DNS - głębokie zanurzenie
• HTTP i HTTPS
• Load balancing
• Firewalle i bezpieczeństwo
• Narzędzia do troubleshootingu
• Zobacz też

Chcesz więcej pytań rekrutacyjnych?

Fiszki Online to ponad 800 pytań z 13 technologii - JavaScript, React, TypeScript, Node.js, SQL i więcej. Natychmiastowy dostęp na 30 dni, nauka na każdym urządzeniu.

Sprawdź za 49,99 zł →

Podstawy sieci

Model OSI - praktyczne podejście

Odpowiedź w 30 sekund:

Nie musisz znać wszystkich 7 warstw. Skup się na tych ważnych dla troubleshootingu: Layer 7 (Application - HTTP, DNS), Layer 4 (Transport - TCP, UDP), Layer 3 (Network - IP, routing), Layer 2 (Data Link - MAC, switche).

Odpowiedź w 2 minuty:

Model OSI jest frameworkiem do zrozumienia gdzie w stacku sieciowym występuje problem:

Layer 7 - Application    HTTP, DNS, SSH (co mówi twoja aplikacja)
Layer 4 - Transport      TCP, UDP (jak dane są dostarczane)
Layer 3 - Network        IP, routing (gdzie dane idą)
Layer 2 - Data Link      Adresy MAC, switche (lokalna sieć)
Layer 1 - Physical       Kable, sygnały (hardware)

Dlaczego to ważne: Przy debugowaniu pracujesz w górę stacku:

• Nie możesz pingować? Problem Layer 3.
• Ping działa ale nie możesz połączyć się z portem? Layer 4.
• Połączenie działa ale aplikacja failuje? Layer 7.

Czym różni się TCP od UDP?

Odpowiedź w 30 sekund:

TCP jest połączeniowy z gwarantowaną dostawą i kolejnością pakietów - używany dla HTTP, SSH, baz danych. UDP jest bezpołączeniowy bez gwarancji - niższa latencja, używany dla DNS, video streaming, gaming. TCP ma three-way handshake, UDP po prostu wysyła pakiety.

Odpowiedź w 2 minuty:

To najczęstsze pytanie o protokoły na rozmowach:

TCP (Transmission Control Protocol):

• Połączeniowy (three-way handshake)
• Gwarantowana dostawa z acknowledgements
• Pakiety w kolejności
• Flow control i congestion control
• Używany dla: HTTP, HTTPS, SSH, FTP, SMTP, bazy danych

UDP (User Datagram Protocol):

• Bezpołączeniowy (fire and forget)
• Brak gwarancji dostawy
• Brak gwarancji kolejności
• Niższa latencja, mniejszy overhead
• Używany dla: DNS queries, video streaming, gaming, VoIP

TCP Three-Way Handshake:

Client              Server
   |---- SYN ---->|     "Chcę się połączyć"
   |<-- SYN-ACK --|     "OK, potwierdzam"
   |---- ACK ---->|     "Świetnie, gadamy"
   |              |
   |-- DATA <---> |     Połączenie ustanowione

Pytanie rekrutacyjne: "Kiedy wybrałbyś UDP zamiast TCP?"

Gdy latencja jest ważniejsza niż niezawodność. Video streaming może pominąć klatki - retransmitowany pakiet przychodzący z opóźnieniem jest bezużyteczny. DNS queries są małe i mogą po prostu retry. Gaming potrzebuje real-time updates gdzie stare dane są bezwartościowe.

Jak działa adresowanie IP i subnetting?

Odpowiedź w 30 sekund:

IPv4 to cztery oktety (0-255 każdy), np. 192.168.1.100. Private IP ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. CIDR notation jak /24 oznacza 256 adresów. Subnetting dzieli sieci na mniejsze segmenty dla bezpieczeństwa i organizacji.

Odpowiedź w 2 minuty:

Zrozumienie adresacji IP jest fundamentalne dla każdego DevOps engineera:

Private IP ranges (RFC 1918):

• 10.0.0.0/8 - 16 milionów adresów (duże sieci)
• 172.16.0.0/12 - 1 milion adresów (średnie sieci)
• 192.168.0.0/16 - 65,536 adresów (home/małe sieci)

CIDR notation:

10.0.0.0/8    = 10.0.0.0 - 10.255.255.255   (16,777,216 IPs)
10.0.0.0/16   = 10.0.0.0 - 10.0.255.255     (65,536 IPs)
10.0.0.0/24   = 10.0.0.0 - 10.0.0.255       (256 IPs)
10.0.0.0/32   = 10.0.0.0                     (1 IP - pojedynczy host)

Subnet math shortcut:

• /24 = 256 adresów (2^8)
• /25 = 128 adresów (2^7)
• /26 = 64 adresy (2^6)
• Odejmij 2 dla network i broadcast address

Pytanie rekrutacyjne: "Zaprojektuj adresację IP dla VPC z trzema subnetami."

VPC: 10.0.0.0/16 (65,536 adresów łącznie)

Subnety:
- Public:  10.0.1.0/24  (web servers, load balancers)
- Private: 10.0.2.0/24  (application servers)
- Data:    10.0.3.0/24  (databases)

Każdy subnet ma 254 używalne IP, dużo miejsca na wzrost.

Jakie porty musisz znać?

Odpowiedź w 30 sekund:

22 SSH, 80 HTTP, 443 HTTPS, 53 DNS, 3306 MySQL, 5432 PostgreSQL, 6379 Redis, 27017 MongoDB, 8080 alt HTTP. Te porty pojawią się na każdej rozmowie DevOps.

Odpowiedź w 2 minuty:

Tabela portów które musisz znać na pamięć:

Quick reference:
22   SSH         443  HTTPS       6379  Redis
80   HTTP        3306 MySQL       27017 MongoDB
53   DNS         5432 PostgreSQL  9200  Elasticsearch

DNS - głębokie zanurzenie

DNS tłumaczy nazwy czytelne dla ludzi na adresy IP. Jest zaangażowany w prawie każdy problem sieciowy.

Jak działa DNS resolution?

Odpowiedź w 30 sekund:

DNS resolution przechodzi przez: browser cache → OS cache → resolver (ISP lub 8.8.8.8) → root servers → TLD servers → authoritative nameserver. Wynik jest cachowany na czas TTL. Recursive resolver robi całą robotę, iterative wymaga odpytywania każdego serwera osobno.

Odpowiedź w 2 minuty:

Pełny flow DNS resolution wygląda następująco:

Recursive vs Iterative:

• Recursive: Resolver robi całą robotę, zwraca finalną odpowiedź
• Iterative: Każdy serwer mówi "nie wiem, zapytaj ich"

Jakie są typy rekordów DNS?

Odpowiedź w 30 sekund:

A mapuje na IPv4, AAAA na IPv6. CNAME to alias do innej domeny (nie można na apex). MX dla serwerów pocztowych z priorytetem. TXT dla SPF, DKIM, weryfikacji. NS dla delegacji nameservers. PTR dla reverse lookup.

Odpowiedź w 2 minuty:

Tabela rekordów DNS które musisz znać:

Ograniczenia CNAME:

• Nie można użyć na zone apex (root domain)
• www.example.com → CNAME OK
• example.com → CNAME NIE OK (użyj ALIAS lub A record)

Co to jest TTL i jak go używać?

Odpowiedź w 30 sekund:

TTL (Time To Live) określa jak długo rekordy DNS są cachowane. Niski TTL (60-300s) = szybka propagacja zmian ale więcej zapytań. Wysoki TTL (3600-86400s) = lepsza wydajność ale wolna propagacja. Ustaw niski TTL przed planowanymi zmianami, podnieś po.

Odpowiedź w 2 minuty:

TTL ma bezpośredni wpływ na dostępność i wydajność:

Niski TTL (60-300 sekund):
+ Szybka propagacja zmian
+ Łatwiejszy failover
- Więcej zapytań DNS
- Wyższa latencja

Wysoki TTL (3600-86400 sekund):
+ Mniej zapytań DNS
+ Lepsza wydajność
- Wolna propagacja
- Trudniej szybko zmienić

Best practice: Użyj niskiego TTL przed planowanymi zmianami (np. migracja), podnieś go po stabilizacji.

Jak debugować problemy DNS?

Odpowiedź w 30 sekund:

Użyj dig example.com dla podstawowego lookup. dig @8.8.8.8 do query konkretnego nameserver. dig +trace do śledzenia pełnej ścieżki resolution. Sprawdź TTL w output. Typowe błędy: NXDOMAIN (domena nie istnieje), SERVFAIL (błąd nameserver), timeout (problem sieciowy).

Odpowiedź w 2 minuty:

Komendy do troubleshootingu DNS:

# Podstawowy lookup
dig example.com
nslookup example.com

# Query konkretnego typu rekordu
dig example.com MX
dig example.com TXT

# Query konkretnego nameserver
dig @8.8.8.8 example.com

# Trace pełnej ścieżki resolution
dig +trace example.com

# Sprawdź pozostały TTL
dig example.com | grep -E "^example"
# example.com.    234    IN    A    93.184.216.34
#                 ^^^-- sekund do wygaśnięcia cache

# Reverse lookup
dig -x 93.184.216.34

Typowe błędy DNS:

• NXDOMAIN: Domena nie istnieje
• SERVFAIL: Błąd nameserver
• Timeout: Problem sieciowy lub serwer down
• Zły IP: Stary cache lub błędna konfiguracja

HTTP i HTTPS

Jakie są metody HTTP i czym się różnią?

Odpowiedź w 30 sekund:

GET pobiera zasób (idempotent, safe). POST tworzy zasób (nie idempotent). PUT zastępuje zasób (idempotent). PATCH częściowa aktualizacja. DELETE usuwa (idempotent). Idempotent = wielokrotne identyczne requesty mają ten sam efekt co jeden.

Odpowiedź w 2 minuty:

Tabela metod HTTP z ich właściwościami:

Idempotent: Wielokrotne identyczne requesty mają ten sam efekt co jeden. Safe: Nie modyfikuje stanu serwera.

Jakie kody statusu HTTP musisz znać?

Odpowiedź w 30 sekund:

1xx informacyjne, 2xx sukces (200 OK, 201 Created), 3xx przekierowania (301 permanent, 302 temporary), 4xx błędy klienta (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found), 5xx błędy serwera (500 Internal Error, 502 Bad Gateway, 503 Service Unavailable).

Odpowiedź w 2 minuty:

Najważniejsze kody statusu HTTP:

1xx - Informacyjne (100 Continue, 101 Switching Protocols)
2xx - Sukces (200 OK, 201 Created, 204 No Content)
3xx - Przekierowanie (301 Permanent, 302 Found, 304 Not Modified)
4xx - Błąd klienta (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found)
5xx - Błąd serwera (500 Internal Error, 502 Bad Gateway, 503 Service Unavailable)

Ważne rozróżnienia:

• 401 vs 403: 401 = nie uwierzytelniony, 403 = uwierzytelniony ale nie autoryzowany
• 502 vs 503 vs 504: 502 = zła odpowiedź od upstream, 503 = serwer przeciążony, 504 = upstream timeout

Jak działa TLS/SSL handshake?

Odpowiedź w 30 sekund:

Client Hello (wspierane ciphers, wersja TLS) → Server Hello (wybrany cipher, certyfikat) → weryfikacja łańcucha certyfikatów → wymiana kluczy → ustanowienie szyfrowanego kanału. Typowe problemy: certyfikat wygasł, name mismatch, brakujący intermediate cert.

Odpowiedź w 2 minuty:

TLS handshake ustanawia bezpieczne połączenie:

Client                          Server
   |                               |
   |------ Client Hello --------->|  Wspierane cipher suites, wersja TLS
   |<----- Server Hello ----------|  Wybrany cipher, certyfikat
   |                               |
   |  [Weryfikacja łańcucha cert]  |
   |                               |
   |------ Key Exchange --------->|  Generowanie session keys
   |<----- Key Exchange ----------|
   |                               |
   |====== Szyfrowany ruch =======|  Wszystkie dane teraz szyfrowane

Łańcuch certyfikatów:

1. Server certificate (twoja domena)
2. Intermediate certificate(s)
3. Root certificate (zaufany przez przeglądarki)

Typowe problemy TLS:

• Certyfikat wygasł: Sprawdź datę notAfter
• Name mismatch: Certyfikat nie pasuje do domeny
• Niekompletny łańcuch: Brakujący intermediate certificate
• Self-signed: Nie zaufany domyślnie

# Sprawdź certyfikat
openssl s_client -connect example.com:443 -servername example.com

# Sprawdź datę wygaśnięcia
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

Czym różni się HTTP/2 od HTTP/1.1?

Odpowiedź w 30 sekund:

HTTP/1.1: jeden request per connection (head-of-line blocking), text-based headers. HTTP/2: multiplexing (wiele requestów przez jedno połączenie), header compression (HPACK), binary protocol, server push. HTTP/3 używa QUIC (UDP-based) dla jeszcze lepszej wydajności.

Odpowiedź w 2 minuty:

Ewolucja protokołu HTTP rozwiązuje problemy wydajności:

HTTP/1.1 ograniczenia:

• Jeden request per connection (head-of-line blocking)
• Nagłówki tekstowe (nieefektywne)
• Brak server push

HTTP/2 ulepszenia:

• Multiplexing (wiele requestów przez jedno połączenie)
• Kompresja nagłówków (HPACK)
• Server push
• Binary protocol

HTTP/3 ulepszenia:

• Protokół QUIC (UDP-based)
• Brak head-of-line blocking na warstwie transportu
• Szybsze ustanawianie połączeń
• Lepsza wydajność mobilna (connection migration)

Load balancing

Czym różni się Layer 4 od Layer 7 load balancing?

Odpowiedź w 30 sekund:

Layer 4 (transport) routuje na podstawie IP i portu - szybki, bez inspekcji treści. Layer 7 (application) sprawdza HTTP headers, URLs, cookies - może routować po path, SSL termination. L4 dla TCP/UDP passthrough, L7 dla routing HTTP i manipulacji requestów.

Odpowiedź w 2 minuty:

Wybór między L4 a L7 load balancerem zależy od wymagań:

Layer 4 (Transport):

• Routuje na podstawie IP address i port
• Brak inspekcji treści
• Szybszy, mniej CPU intensive
• Użycie: TCP/UDP passthrough, protokoły non-HTTP

Layer 7 (Application):

• Sprawdza HTTP headers, URLs, cookies
• Może routować na podstawie treści
• SSL termination
• Użycie: HTTP routing, path-based routing, A/B testing

Layer 4 Load Balancer:
Client → [L4 LB] → Server
         (routuje po IP:port)

Layer 7 Load Balancer:
Client → [L7 LB] → Server
         (routuje /api/* → api-servers)
         (routuje /static/* → cdn)

Jakie są algorytmy load balancingu?

Odpowiedź w 30 sekund:

Round Robin - rotacja po serwerach. Weighted Round Robin - rotacja z wagami. Least Connections - wysyłaj do serwera z najmniejszą liczbą połączeń. IP Hash - hash IP klienta dla session affinity. Least Response Time - wysyłaj do najszybszego.

Odpowiedź w 2 minuty:

Tabela algorytmów load balancingu:

Pytanie rekrutacyjne: "Użytkownicy zgłaszają wolne odpowiedzi. Jak algorytm LB może to powodować?"

Jeśli używasz round robin z serwerami o różnej wydajności, wolniejsze serwery dostają taki sam ruch i stają się bottleneckiem. Zmień na least connections lub weighted round robin. Jeśli requesty mają różny czas trwania, least connections zapobiega queue buildup na wolnych serwerach.

Jak działają health checks?

Odpowiedź w 30 sekund:

Health checks sprawdzają czy backend jest zdrowy. TCP Check - czy można połączyć z portem. HTTP Check - czy GET /health zwraca 200. Custom Check - czy /health zwraca {"status":"ok"}. Parametry: interval (jak często), timeout, threshold (ile failures przed unhealthy).

Odpowiedź w 2 minuty:

Load balancery potrzebują wiedzieć które backendy są zdrowe:

Typy Health Check:

TCP Check:
- Czy możemy połączyć z portem 80?
- Szybki, podstawowy

HTTP Check:
- Czy GET /health zwraca 200?
- Świadomy aplikacji

Custom Check:
- Czy /health zwraca {"status": "ok", "db": "connected"}?
- Głęboka weryfikacja zdrowia

Parametry health check:

• Interval: Jak często sprawdzać (np. 10 sekund)
• Timeout: Jak długo czekać na odpowiedź (np. 5 sekund)
• Threshold: Ile failures przed oznaczeniem unhealthy (np. 3)
• Recovery: Ile sukcesów przed oznaczeniem healthy (np. 2)

Co to są sticky sessions i kiedy ich używać?

Odpowiedź w 30 sekund:

Sticky sessions utrzymują użytkownika połączonego z tym samym serwerem. Metody: cookie-based (LB ustawia cookie z server ID), IP-based (hash IP klienta). Trade-off: prostszy kod aplikacji ale nierówne rozłożenie obciążenia i utrata sesji przy awarii serwera. Lepsza alternatywa: externalize session do Redis.

Odpowiedź w 2 minuty:

Sticky sessions mają zalety i wady:

Zalety:
+ Stan sesji zostaje na jednym serwerze
+ Prostszy kod aplikacji
+ Lepsze hit rates cache

Wady:
- Nierówne rozłożenie obciążenia
- Awaria serwera = utrata sesji
- Trudniej skalować w dół

Metody:

• Cookie-based: Load balancer ustawia cookie z server ID
• IP-based: Hash IP klienta (problemy z NAT)
• Application-based: Aplikacja ustawia session cookie, LB czyta

Lepsza alternatywa: Externalize stan sesji do Redis lub bazy danych. Wtedy każdy serwer może obsłużyć każdy request.

Chcesz więcej pytań rekrutacyjnych?

Fiszki Online to ponad 800 pytań z 13 technologii - JavaScript, React, TypeScript, Node.js, SQL i więcej. Natychmiastowy dostęp na 30 dni, nauka na każdym urządzeniu.

Sprawdź za 49,99 zł →

Firewalle i bezpieczeństwo

Jak działają reguły firewall?

Odpowiedź w 30 sekund:

Firewall filtruje ruch na podstawie reguł ewaluowanych w kolejności. Reguła: [Priority] [Action] [Protocol] [Source] [Destination] [Port]. Stateful firewall śledzi połączenia i automatycznie przepuszcza ruch powrotny. Stateless wymaga explicit reguł dla obu kierunków.

Odpowiedź w 2 minuty:

Struktura reguł firewall:

[Priority] [Action] [Protocol] [Source] [Destination] [Port]

Przykładowe reguły:
1. ALLOW  TCP  10.0.0.0/8    any         22     # SSH z internal
2. ALLOW  TCP  any           any         443    # HTTPS zewsząd
3. ALLOW  TCP  any           any         80     # HTTP zewsząd
4. DENY   any  any           any         any    # Default deny

Stateful vs Stateless:

Jak projektować segmentację sieci?

Odpowiedź w 30 sekund:

Dziel sieci na strefy bezpieczeństwa: DMZ (public-facing), Private (aplikacje), Data (bazy danych). Każda strefa ma własne firewall rules. Traffic może płynąć do bardziej restrykcyjnych stref przez firewall. Zasada least privilege - domyślnie deny, allow tylko to co potrzebne.

Odpowiedź w 2 minuty:

Typowa architektura segmentacji sieci:

┌─────────────────────────────────────────────┐
│                  Internet                    │
└──────────────────────┬──────────────────────┘
                       │
              ┌────────▼────────┐
              │  Load Balancer  │
              │   (Public)      │
              └────────┬────────┘
                       │
┌──────────────────────┼──────────────────────┐
│ DMZ                  │                       │
│              ┌───────▼───────┐              │
│              │  Web Servers  │              │
│              └───────┬───────┘              │
└──────────────────────┼──────────────────────┘
                       │ (Firewall)
┌──────────────────────┼──────────────────────┐
│ Private              │                       │
│              ┌───────▼───────┐              │
│              │  App Servers  │              │
│              └───────┬───────┘              │
└──────────────────────┼──────────────────────┘
                       │ (Firewall)
┌──────────────────────┼──────────────────────┐
│ Data                 │                       │
│              ┌───────▼───────┐              │
│              │   Databases   │              │
│              └───────────────┘              │
└─────────────────────────────────────────────┘

Jak działa NAT?

Odpowiedź w 30 sekund:

NAT (Network Address Translation) tłumaczy prywatne IP na publiczne. SNAT (Source NAT) zmienia source IP dla ruchu wychodzącego. DNAT (Destination NAT) zmienia destination IP dla ruchu przychodzącego. PAT (Port Address Translation) pozwala wielu prywatnym IP współdzielić jeden publiczny.

Odpowiedź w 2 minuty:

NAT jest fundamentem dla prywatnych sieci łączących się z internetem:

Typy NAT:

• SNAT (Source NAT): Zmiana source IP (ruch wychodzący)
• DNAT (Destination NAT): Zmiana destination IP (ruch przychodzący)
• PAT (Port Address Translation): Wiele prywatnych IP współdzieli jeden publiczny

Przykład NAT (outbound):

Private                NAT Gateway              Internet
10.0.1.50 ──────────> 203.0.113.5:12345 ──────────> example.com
         source IP     przetłumaczony na
         zmieniony     publiczny IP + port

NAT Gateway/Instance: Pozwala prywatnym subnetom na dostęp do internetu bez bycia bezpośrednio dostępnymi z zewnątrz.

Narzędzia do troubleshootingu

Jak testować łączność?

Odpowiedź w 30 sekund:

ping dla podstawowej łączności. traceroute/mtr do identyfikacji gdzie pakiety się zatrzymują. telnet/nc do testowania czy port jest otwarty. dig/nslookup dla DNS. curl -v dla HTTP z pełnym output. Systematyczne podejście: DNS → ping → port → TLS → HTTP.

Odpowiedź w 2 minuty:

Narzędzia do testowania łączności:

# Podstawowa łączność
ping example.com
ping -c 4 example.com          # Stop po 4 pingach

# Trace route do destination
traceroute example.com         # Linux/Mac
tracert example.com            # Windows
mtr example.com                # Lepszy traceroute (continuous)

# Test konkretnego portu
telnet example.com 80
nc -zv example.com 80          # Netcat
nc -zv example.com 20-25       # Range portów

Jak sprawdzać statystyki sieciowe?

Odpowiedź w 30 sekund:

netstat -tulpn lub ss -tulpn pokazuje listening ports. lsof -i :80 pokazuje co używa portu 80. tcpdump do przechwytywania pakietów. wireshark dla GUI analizy.

Odpowiedź w 2 minuty:

Komendy do statystyk sieciowych:

# Pokaż listening ports
netstat -tulpn                 # Linux
netstat -an | grep LISTEN      # Mac

# Nowoczesna alternatywa dla netstat
ss -tulpn                      # Pokaż listening ports
ss -s                          # Socket statistics

# Co używa portu?
lsof -i :80                    # Jaki proces ma port 80
fuser 80/tcp                   # Alternatywa

Jak analizować pakiety?

Odpowiedź w 30 sekund:

tcpdump -i eth0 przechwytuje cały ruch na interfejsie. Filtry: port 80, host 10.0.1.50. -w capture.pcap zapisuje do pliku. Wireshark do GUI analizy. Szukaj SYN bez SYN-ACK (connection refused), retransmisji (packet loss), RST (connection reset).

Odpowiedź w 2 minuty:

Analiza pakietów z tcpdump:

# Przechwytywanie pakietów
tcpdump -i eth0                        # Cały ruch na interfejsie
tcpdump -i eth0 port 80                # Tylko port 80
tcpdump -i eth0 host 10.0.1.50         # Tylko konkretny host
tcpdump -i eth0 -w capture.pcap        # Zapisz do pliku

# Odczyt pliku capture
tcpdump -r capture.pcap
wireshark capture.pcap                  # GUI analiza

# Przydatne filtry
tcpdump 'tcp[tcpflags] & (tcp-syn) != 0'  # Tylko SYN pakiety
tcpdump -A port 80                         # Pokaż ASCII content

Jak debugować HTTP z curl?

Odpowiedź w 30 sekund:

curl -v dla verbose output (widać handshake). curl -I dla HEAD request (tylko headers). curl -L follow redirects. curl -H custom headers. curl -w do mierzenia czasu (DNS, connect, TLS, total).

Odpowiedź w 2 minuty:

curl jest najważniejszym narzędziem do debugowania HTTP:

# Podstawowy request
curl https://example.com

# Pokaż headers
curl -I https://example.com             # HEAD request (tylko headers)
curl -i https://example.com             # Include headers w output

# Verbose output (widać handshake)
curl -v https://example.com

# Follow redirects
curl -L https://example.com

# Custom headers
curl -H "Authorization: Bearer token" https://api.example.com

# POST z danymi
curl -X POST -d '{"key":"value"}' -H "Content-Type: application/json" https://api.example.com

# Mierzenie czasu
curl -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTotal: %{time_total}s\n" -o /dev/null -s https://example.com

Klasyczne pytanie: "Co się dzieje gdy wpisujesz google.com w przeglądarce?"

To pytanie testuje end-to-end understanding sieci:

1. URL Parsing: Przeglądarka wyodrębnia protokół (https), hostname (google.com), path (/)

2. DNS Resolution:

   • Sprawdź cache przeglądarki
   • Sprawdź cache OS
   • Query DNS resolver
   • Recursive lookup przez root → TLD → authoritative
   • Cache wynik na podstawie TTL

3. TCP Connection:

   • Three-way handshake (SYN, SYN-ACK, ACK)
   • Połączenie z IP na porcie 443

4. TLS Handshake:

   • Client Hello (wspierane ciphers)
   • Server Hello (wybrany cipher, certyfikat)
   • Weryfikacja certyfikatu
   • Wymiana kluczy
   • Szyfrowany kanał ustanowiony

5. HTTP Request:

   • GET / HTTP/2
   • Headers (Host, User-Agent, Accept, etc.)

6. Server Processing:

   • Load balancer routuje request
   • Web server przetwarza
   • Backend calls jeśli potrzebne
   • Response generowany

7. Response:

   • Status code (200 OK)
   • Headers (Content-Type, Cache-Control)
   • Body (HTML)

8. Rendering:

   • Parse HTML
   • Fetch CSS, JS, images (parallel requests)
   • Build DOM i CSSOM
   • Execute JavaScript
   • Paint to screen

Systematyczne debugowanie połączeń

# 1. Czy możemy rozwiązać hostname?
dig api.example.com
# Jeśli NXDOMAIN → problem DNS

# 2. Czy możemy dotrzeć do IP?
ping 93.184.216.34
# Jeśli timeout → problem routing/firewall

# 3. Czy możemy dotrzeć do portu?
nc -zv 93.184.216.34 443
# Jeśli refused → usługa nie działa lub firewall

# 4. Czy TLS działa?
openssl s_client -connect api.example.com:443
# Jeśli handshake fails → problem z certyfikatem

# 5. Czy HTTP działa?
curl -v https://api.example.com/health
# Jeśli error → problem aplikacji

Na co rekruterzy naprawdę zwracają uwagę

Systematyczne debugowanie - pracuj przez warstwy metodycznie. Pokaż że potrafisz izolować problem.

Znajomość narzędzi - dig, curl, tcpdump, netstat. Rekruterzy chcą widzieć że używasz tych narzędzi w praktyce.

Zrozumienie protokołów - TCP vs UDP, HTTP status codes, DNS records. To fundamenty.

Świadomość bezpieczeństwa - Firewalle, szyfrowanie, segmentacja. Każdy DevOps musi rozumieć security.

Zadania praktyczne

1. Debuguj problem DNS - zasymuluj NXDOMAIN i SERVFAIL, zidentyfikuj przyczynę.
2. Skonfiguruj load balancer z health checks i sticky sessions.
3. Przeanalizuj ruch tcpdump - znajdź retransmisje, connection resets.
4. Zaprojektuj VPC z trzema subnetami i odpowiednimi firewall rules.
5. Zmierz latencję curl - DNS, connect, TLS, total dla różnych endpoints.

Quick Reference

Essential Commands

Troubleshooting Checklist

□ DNS resolving correctly?
□ IP reachable (ping)?
□ Port open (nc/telnet)?
□ Firewall rules allow traffic?
□ Service running on target?
□ TLS certificate valid?
□ Application responding?
□ Correct response code?

Zobacz też

• Linux - Pytania Rekrutacyjne - komendy i narzędzia systemowe
• Docker - Pytania Rekrutacyjne - networking kontenerów
• Kubernetes - Pytania Rekrutacyjne - Services, Ingress, NetworkPolicy
• AWS - Pytania Rekrutacyjne - VPC, Security Groups, ELB
• Kompletny Przewodnik - Rozmowa DevOps Engineer - pełna mapa przygotowania

Ten artykuł jest częścią serii przygotowującej do rozmów rekrutacyjnych na stanowiska DevOps i Backend Developer. Sprawdź nasze fiszki z pytaniami i odpowiedziami do nauki: Fiszki Online.