← 7. Systems thinking – A nagy kép

7.4 Hálózati alapismeretek fejlesztőknek

Áttekintő

Ha fejlesztőként dolgozol, naponta találkozol hálózati fogalmakkal – anélkül, hogy feltétlenül tudnád, mit jelentenek. A szervered nem indul el, mert „a port már foglalt". A frontended nem kap adatot a backendtől, mert CORS hiba jelenik meg. Az API-od elérhető staging-en, de production-ban nem megy. Ezek mind hálózati problémák.

Nem kell hálózati mérnöknek lenned. De néhány alapfogalmat muszáj értened, különben órákat töltesz olyan hibák keresésével, amiket 5 perc alatt megoldanál, ha tudnád, hol keresni.

Ez az alfejezet az a minimum, amit minden webfejlesztőnek ismernie kell – nem többet, nem kevesebbet.

---

Részletes leírás

IP-cím és port – a lakcím és az ajtószám

Képzeld el, hogy a szervered egy nagy irodaépület. Az IP-cím az épület lakcíme – megmondja, hol van. A port az ajtószám – megmondja, melyik ajtón kell kopogni.

Egy szerveren egyszerre sok program futhat. Mindegyikük más-más porton „hallgat". A webszerver tipikusan a 80-as (HTTP) vagy 443-as (HTTPS) porton, egy adatbázis a 5432-es (PostgreSQL) vagy 3306-os (MySQL) porton, a fejlesztői szervered pedig valószínűleg a 3000-es, 8000-es vagy 8080-as porton.

http://192.168.1.100:3000
              ↑          ↑
           IP-cím       port

Amikor böngészőből megnyitsz egy oldalt, a böngésző csatlakozik az IP-cím megfelelő portjára, és elküldi a kérést. Ha a port nincs nyitva (nincs program mögötte), kapcsolat megtagadva.

Jól ismerd meg:

• 80 – HTTP (titkosítatlan web)
• 443 – HTTPS (titkosított web)
• 22 – SSH
• 5432 – PostgreSQL
• 3306 – MySQL/MariaDB
• 6379 – Redis
• 27017 – MongoDB

Domain és DNS – a telefonkönyv

Az IP-cím (142.250.185.78) nem megjegyezhető embereknek. A domain (google.com) azt cseréli le. A DNS (Domain Name System) a telefonkönyv, ami a kettő között fordít.

Amikor beírod a böngészőbe, hogy api.pelda.hu:

1. A böngésző megkérdezi a DNS szervert: „Mi az IP-je ennek?"
2. A DNS visszaadja: 142.250.185.78
3. A böngésző csatlakozik az IP-re

Ez néhány milliszekundum alatt történik, de ettől függ, hogy eléri-e a felhasználó a szerveredet egyáltalán.

Fejlesztőként mikor találkozol DNS-sel?

• Új domain beállítása production-hoz
• Subdomain létrehozása (api.sajatoldalad.hu)
• Local development-ben hostnév feloldás (/etc/hosts szerkesztése)

localhost vs. 0.0.0.0 – ami mindenkit megzavar

Ez az a különbség, amin sok junior fejlesztő megakad.

localhost (127.0.0.1):

• A saját gépedre mutat visszafelé (loopback)
• Csak a te gépedről érhető el
• http://localhost:3000 – te látod, senki más

0.0.0.0:

• „Hallgass minden hálózati interfészen"
• Ha a fejlesztői szervered erre köt, a hálózatodban mások is elérhetik

Tipikus szituáció:

# Csak te látod:
python -m http.server 8000  # localhost-ra köt

# Docker-ben ha nem adod meg a 0.0.0.0-t:
# a container belsejéből sem érhető el kívülről

# Ha más gépről is el kell érni (pl. mobilon tesztelni):
python -m http.server 8000 --bind 0.0.0.0

Production szerveren az alkalmazásod általában a 0.0.0.0-n hallgat, és egy reverse proxy (nginx, Caddy) kezeli a kéréseket az internet felé.

HTTPS – miért számít és miért nem elég a „majd élesítéskor"

A HTTP titkosítatlan – bárki, aki az úton van (routerek, szolgáltatók, kávézói wifi), láthatja az adatcserét. A HTTPS SSL/TLS titkosítással védi a kommunikációt.

Miért számít fejlesztőként:

• Modern böngészők egyre több funkciót tiltanak HTTP-n (geolocation, camera, service worker)
• Ha HTTPS-en kell tesztelni, localhost kivétel van, de staging-en már nem
• Tanúsítvány lejárta production-on leállást okoz (láttál már ilyet élesben? Mindenki látott)
• Bejelentkezési form HTTP-n? A jelszó plaintext megy az interneten

Local fejlesztésben: a localhost általában kivétel, http is működik. De ha HTTPS-specifikus dolgot fejlesztesz (pl. service worker, secure cookie), már helyi tanúsítvány kell (pl. mkcert eszközzel).

Production-ban: ingyenes tanúsítvány a Let's Encrypt segítségével, ami az esetek 95%-ában elegendő.

CORS – a legnépszerűbb fejlesztői bosszúság

A CORS (Cross-Origin Resource Sharing) az a védelmi mechanizmus, ami megakadályozza, hogy bármely weboldal bármely más weboldal nevében kéréseket küldön a felhasználód böngészőjéből.

Miért létezik? Védelmi mechanizmus: ha nem lenne CORS, egy rosszindulatú oldal a háttérben elküldhetne kéréseket a bankod API-jára a te sütijeid felhasználásával.

Mikor kapod a CORS hibát?

Access to XMLHttpRequest at 'http://api.pelda.hu/users' 
from origin 'http://localhost:3000' has been blocked by 
CORS policy: No 'Access-Control-Allow-Origin' header is 
present on the requested resource.

Ez akkor jelenik meg, ha:

• A frontend és a backend különböző originen fut (más domain, más port, más protokoll)
• A backend nem küldi vissza a megfelelő CORS fejléceket

Origin = protokoll + domain + port. Ha bármelyik különbözik, más origin.

Hol kell javítani? A backenden – mindig.

A CORS hibát a backend oldja meg, megfelelő fejlécek visszaküldésével:

Access-Control-Allow-Origin: https://frontend.pelda.hu
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization

Legtöbb backendben van ehhez könyvtár:

# FastAPI / Python
from fastapi.middleware.cors import CORSMiddleware

app.add_middleware(
    CORSMiddleware,
    allow_origins=["https://frontend.pelda.hu"],
    allow_methods=["*"],
    allow_headers=["*"],
)

// Express / Node.js
const cors = require('cors');

app.use(cors({
    origin: 'https://frontend.pelda.hu'
}));

// Laravel
// config/cors.php -> allowed_origins-ban add meg a frontendet

⚠️ Amit NE csinálj production-ban:

Access-Control-Allow-Origin: *

Ez mindenki számára engedélyezi – fejlesztés közbeni gyorsjavításnak elmegy, de production-ban biztonsági kockázat, különösen ha az API autentikált kéréseket fogad.

CORS hibát kapod, de a backend-es kollégád azt mondja „nálam működik"? Valószínűleg Postman-ből vagy curl-ből tesztelt – ott nincs böngésző-szintű CORS ellenőrzés. A CORS kizárólag böngészőkben érvényes.

Tűzfal és load balancer – fogalmak, amiket hallani fogsz

Ezeket nem kell konfigurálnod juniorként, de értened kell, mire valók.

Tűzfal (Firewall):

• Szűri a bejövő/kimenő hálózati forgalmat
• Meghatározza, melyik portról fogad kéréseket a szerver
• Ha a backend szerveredhez nem tudsz csatlakozni, és semmi más nem magyarázza – lehet, hogy a tűzfal blokkolja
• Cloud szolgáltatóknál (AWS, GCP, Azure) „security group" vagy „firewall rule" formájában találkozol vele

Load balancer (Terheléselosztó):

• Több szerverpéldány elé áll, és elosztja a kéréseket köztük
• Ha api.pelda.hu valójában 5 szerveren fut, a load balancer dönti el, melyikhez megy az adott kérés
• Juniorként ritkán kell konfigurálnod, de ha session-kezelést vagy file upload-ot csinálsz, számít: a kérések nem mindig ugyanahhoz a szerverhez mennek

                      ┌─────────────┐
                      │ Load balancer│
                      └──────┬──────┘
               ┌─────────────┼──────────────┐
               ▼             ▼              ▼
          [Szerver 1]   [Szerver 2]   [Szerver 3]

Gyakorlati hatás: ha a sessionödet memóriában tárolod (nem adatbázisban/Redis-ben), a load balancer mögött a felhasználó minden második kérésnél „kijelentkezik" – mert más szerverhez kerül.

---

Életszerű példák

1. példa: „Az API-m nem indul el, mert a port foglalt"

$ python manage.py runserver
Error: That port is already in use.

Diagnosztika:

# Linux/Mac: melyik process foglalja a portot?
lsof -i :8000

# Windows:
netstat -ano | findstr :8000

Eredmény megmutatja a PID-et. Vagy leállítod azt a processt, vagy más portot használsz:

python manage.py runserver 8001

---

2. példa: CORS hiba mobile tesztelésnél

Fejleszted a frontendet, az API localhost:8000-en fut. Mobilon akarod tesztelni, ezért a laptop IP-jére (192.168.1.50:8000) csatlakozol. CORS hibát kapsz, mert a frontend a mobilon más originen fut, mint a backend.

Megoldás: dev módban engedélyezd a CORS-t tágabban:

# Csak development-ben!
if DEBUG:
    CORS_ALLOW_ALL_ORIGINS = True

---

3. példa: Staging-en HTTPS-re cost a cookie, local development-en nem megy

// Cookie beállítva backenden:
Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Strict

A Secure flag azt jelenti: csak HTTPS-en küldik vissza a sütit. Localhost-on HTTPS nélkül tesztelve a süti sosem kerül vissza a kérésben – mintha sosem lett volna beállítva.

Megoldás: vagy Secure flag-et nem adod meg dev-ben (környezeti változóval kapcsolgatva), vagy mkcert-tel helyi HTTPS-t állítasz be.

---

4. példa: DNS propagáció – türelmi feladat

Beállítottál egy új domaint a production szerveredhez. Nálad működik, a főnöknél nem. Mindenki más azt mondja, nem megy.

DNS változások terjedése (propagáció) 0 perctől 48 óráig tarthat, attól függően, melyik DNS szerver melyik cached értéket adja vissza. Ez normális. A dig vagy nslookup paranccsal ellenőrizheted, mit lát a világ:

dig api.pelda.hu +short
# Ha más IP-t ad, mint amit te látsz -> DNS még terjedőben

---

Tesztfeladatok

1. Melyik fogalom melyik definícióhoz illik?

Párosítsd:

---

2. Igaz vagy hamis?

a) A CORS hibát a frontenden kell javítani, mert ott jelenik meg a hibaüzenet.
b) A localhost és a 127.0.0.1 ugyanaz.
c) Ha a backend Postman-ből működik, de böngészőből nem, akkor biztosan CORS probléma van.
d) A 0.0.0.0-ra kötött szerver csak localhost-ról elérhető.
e) A HTTPS kötelező ahhoz, hogy bármilyen weboldal működjön.

---

3. Szituáció-diagnosztika

Junior fejlesztő leírja a problémát: „A frontendünk Vue.js-ben van, a backend Django. Helyi fejlesztéskor a frontend localhost:5173-on fut, a backend localhost:8000-en. Mindig kapok egy hibát az API hívásoknál, de Postman-ből tökéletesen működik."

a) Mi a hiba valószínű neve és oka?
b) Ki oldja meg: a frontend fejlesztő vagy a backend fejlesztő?
c) Hol és hogyan kell javítani? (leírj egy lehetséges megoldást)

---

4. Port azonosítás

Melyik service melyik porton fut alapértelmezetten?

Lehetséges portok: 22, 80, 443, 3306, 5432, 6379, 27017

---

5. Mi a különbség?

Fejlesztőd azt mondja: „A szervered localhost:8000-en fut, de a containerből nem érem el."

a) Mi az oka ennek a problémának?
b) Mit kell változtatni?

---

6. CORS konfiguráció értékelése

Melyik CORS konfiguráció helyes production-ban, és miért?

A verzió:

Access-Control-Allow-Origin: *

B verzió:

Access-Control-Allow-Origin: https://app.pelda.hu

C verzió:

Access-Control-Allow-Origin: https://app.pelda.hu, https://admin.pelda.hu

---

7. DNS propagáció szituáció

Beállítottad az új production domaint (app.cegem.hu → a szerver IP-jére), és te már eléred. Egy kolléga Londonból jelenti, hogy nála még nem megy. Mi a legvalószínűbb ok, és mit tegyél?

a) Valószínű ok:
b) Megoldás (mit mondasz a kollégának?):
c) Hogyan ellenőrzöd, hogy terjedt-e már a DNS?

---

Tesztfeladat-megoldások

1. A-3, B-1, C-4, D-2, E-5

2.
a) Hamis – CORS hibát a backenden kell javítani, ott kell a megfelelő fejléceket visszaküldeni
b) Igaz – localhost az 127.0.0.1 loopback cím alias-a
c) Igaz – a CORS egy böngésző-szintű védelmi mechanizmus, Postman nem alkalmazza
d) Hamis – 0.0.0.0 azt jelenti: hallgat minden hálózati interfészen, tehát hálózatról is elérhető
e) Hamis – működik HTTP-n is, de egyre több funkció és böngészőszabály HTTPS-t követel meg

3.
a) CORS hiba – a frontend és backend különböző porton fut, így más az originjük (localhost:5173 ≠ localhost:8000)
b) A backend fejlesztő – a CORS fejléceket a backend küldi vissza
c) Django esetén: django-cors-headers csomag telepítése, CORS_ALLOWED_ORIGINS = ["http://localhost:5173"] beállítása a settings.py-ban

4.

• PostgreSQL: 5432
• HTTPS: 443
• SSH: 22
• Redis: 6379
• MySQL: 3306

5.
a) A localhost a container saját loopback interfészére mutat, nem a host gépre. A host gépen futó service-t a container nem éri el localhost-on keresztül.
b) A szerverednek 0.0.0.0-ra kell kötni, vagy Docker-ben a host.docker.internal hostname-t kell használni (host gépen futó service-hez Docker containerből)

6.

• A verzió – fejlesztésre elfogadható, production-ban kerülendő (bárki küldhet kérést)
• B verzió – helyes, specifikus origin engedélyezve
• C verzió – helyes, ha több frontend is van; pontosan definiált, mi engedélyezett

Production-ban B vagy C a megfelelő, soha nem *.

7.
a) DNS propagáció – a DNS változások nem terjednek azonnal, különböző DNS szerverek még a régi IP-t adhatják vissza
b) Várjon 24-48 órát, ez normális. Kényszerített DNS flush sem segít feltétlenül (más szerveren is cache lehet)
c) dig app.cegem.hu +short – ha különböző helyszínekről különböző IP-t ad, még terjed. Online eszköz: dnschecker.org