Files

Stanislav Hubacek c6fa0bff6a commit

2026-06-11 15:27:28 +02:00

17 KiB

Raw Blame History

🌐 Síťová architektura

Referenční model (TCP/IP)

Vrstva	Protokoly	Zařízení
Aplikační	HTTP/HTTPS, DNS, SMTP, SSH	—
Transportní	TCP, UDP	—
Síťová	IP, ICMP, BGP	Routery
Linková	Ethernet, ARP, VLAN	Switche

TCP detail

3-way handshake

Client                          Server
  |                               |
  |  SYN (seq=x)                  |
  |──────────────────────────────>|
  |                               |
  |  SYN+ACK (seq=y, ack=x+1)    |
  |<──────────────────────────────|
  |                               |
  |  ACK (seq=x+1, ack=y+1)      |
  |──────────────────────────────>|
  |                               |
  |  << established >>            |

SYN — client odešle segment s příznakem SYN (Synchronize Sequence Number)
SYN-ACK — server odpoví vlastním SYN + potvrzením clientova seq čísla
ACK — client potvrdí, spojení je navázáno
TCP Fast Open (TFO) — data v SYN paketu pro 0-RTT u opakovaných spojení

Flow control (sliding window)

Receiver Window (rwnd) — kolik dat je receiver ochoten přijmout
Sliding window — sender udržuje okno nepotvrzených paketů
Window scaling (RFC 1323) — umožňuje okno až 1 GB (místo 64 KB)
Zero Window — receiver oznámí 0, sender zastaví, persist timer periodicky testuje

Congestion control

Algoritmus	Popis	Use case
Cubic	Výchozí v Linuxu (od kernel 2.6.19), kubická growth funkce	Obecné sítě, výchozí pro Internet
BBR (Bottleneck Bandwidth and RTT)	Model-based, měří bandwidth a RTT, ne packet loss	Vysokorychlostní sítě, YouTube, Google
Reno	Classic AIMD (Additive Increase Multiplicative Decrease)	Legacy, reference
CDG (CAIA Delay Gradient)	Delay-based, detekce congeste podle RTT gradientu	Videostreaming, real-time

BBRv2 (2024+) — zahrnuje ECN signalizaci, koexistenci s Cubic, lepší handling při loss.

DNS (Domain Name System)

Record typy: A, AAAA, CNAME, MX, TXT, NS, SRV, PTR, CAA, DS, DNSKEY, RRSIG, NSEC
DNS resolver: rekurzivní dotaz přes hierarchii (root → TLD → authoritative)
Anycast DNS — stejná IP z více lokací, směrování k nejbližší
DNS caching — TTL řízení, cache poisoning ochrana (DNSSEC)
Cloud DNS — Route53, Azure DNS, Cloud DNS

DNS lookup flow (krok za krokem)

1. Uživatel zadá "api.example.com" do prohlížeče
2. OS stub resolver zkontroluje lokální cache (/etc/hosts, systemd-resolved)
3. Pokud není v cache → dotaz na rekurzivní resolver (ISP / 8.8.8.8 / 1.1.1.1)
4. Resolver zkontroluje svou cache
5. Nenalezeno → resolver začne rekurzivní lookup:
   a. Dotaz na root nameserver (.) → vrátí NS pro .com
   b. Dotaz na .com TLD nameserver → vrátí NS pro example.com
   c. Dotaz na autoritativní NS pro example.com → vrátí A záznam (IP)
6. Resolver uloží do cache (TTL), vrátí IP clientu
7. Client naváže TCP spojení na získanou IP

Celý proces typicky trvá 10–200 ms (s cache < 1 ms).

DNSSEC detail

RRSIG — digitální podpis pro každý RRset (Resource Record Set)
DNSKEY — veřejný klíč zóny (ZSK = Zone Signing Key, KSK = Key Signing Key)
DS (Delegation Signer) — hash DNSKEY předávaný do parent zóny (řetěz důvěry)
NSEC / NSEC3 — authenticated denial of existence (důkaz, že záznam neexistuje)
Chain of trust: root → .com → example.com (cesta od trust anchor přes DS recordy)

Root DS → .com DNSKEY → .com DS → example.com DNSKEY → example.com RRSIG(A)

Validace: resolver zkontroluje podpisy přes celý řetěz až k trust anchor

DNS-based service discovery

Mechanismus	Popis	Příklad
SRV record	Service location (priority, weight, port, target)	`_http._tcp.example.com`
Consul DNS	Service discovery přes DNS rozhraní	`web.service.consul`
CoreDNS	Kubernetes DNS, plugin-based	`my-svc.my-namespace.svc.cluster.local`
Kubernetes DNS	Service discovery uvnitř clusteru (kube-dns / CoreDNS)	`svc.cluster.local`
mDNS (Multicast DNS)	Zero-config, lokální síť (Bonjour/Avahi)	`myprinter.local`

Load Balancing

Typ	Vrstva (OSI)	Popis
L4 (NLB)	4	TCP/UDP, rychlý, nižší latence
L7 (ALB)	7	HTTP/HTTPS, path-based routing, sticky sessions
Global	DNS	Geo-routing, latency-based, weighted

Algoritmy

Round Robin / Weighted RR
Least Connections
IP Hash (session persistence)
Random

Health check typy

Typ	Popis	Vhodné pro
TCP health check	TCP handshake na cílový port	L4 NLB, základní check
HTTP health check	HTTP GET na URL, očekává 200 OK	L7 ALB, webové služby
HTTPS health check	HTTP + TLS handshake	Služby s TLS terminací
gRPC health check	gRPC Health/Check RPC (gRPC specific)	Microservices, gRPC služby
ICMP ping	Ping na cílovou IP	Základní konektivita

Connection draining

Connection draining (AWS) / Deregistration delay — při odebrání targetu z ASG/LB se počká, až existující spojení skončí (configurable: 1-3600 s)
Slow start — nový target dostává postupně více requestů (zabrání přetížení cold cache)

Cross-zone load balancing

Enabled: LB rovnoměrně rozděluje traffic napříč všemi AZ (i nerovnoměrný počet instancí)
Disabled: traffic rozdělen rovnoměrně mezi AZ, pak v rámci AZ mezi instance
AWS ALB/NLB: enabled by default (2022+), bez dalších poplatků

Firewally a bezpečnost

Stateful firewall — sleduje stav spojení (AWS Security Groups, Azure NSG)
Stateless firewall — ACL (Network ACLs)
NGFW — aplikační vrstva, IPS/IDS (Palo Alto, Fortinet)
WAF — ochrana web aplikací (Cloudflare, AWS WAF, Azure WAF)

Network segmentation — Security Groups vs Network ACLs

Vlastnost	Security Group (SG)	Network ACL (NACL)
State	Stateful (automaticky povoluje return traffic)	Stateless (nutné explicitní pravidlo pro oba směry)
Úroveň	Instance / ENI	Subnet
Pravidla	Povolující (allow only)	Povolující i zakazující (allow + deny)
Vyhodnocení	Všechna pravidla se vyhodnotí (OR)	Pravidla od nejnižšího čísla (first match)
Default	All traffic denied (inbound), all traffic allowed (outbound)	All traffic denied (inbound i outbound)
Podpora	AWS, GCP (firewall rules), Azure (NSG)	AWS (NACL), GCP (firewall rules na subnet), Azure (NSG)

Mikrosegmentace

Zero Trust networking — každý workload má vlastní security group / NGFW policy
Service mesh — Istio, Linkerd, Consul Connect pro L7 mikrosegmentaci (mTLS, authorization policies)
Network policies — Kubernetes NetworkPolicy pro segmentaci pod-to-pod trafficu
Tanzu / NSX — micro-segmentation na hypervisor úrovni

VPN

Site-to-Site — IPSec, trvalé spojení mezi lokalitami
Client-to-Site — OpenVPN, WireGuard, AnyConnect
Cloud VPN — AWS VPN, Azure VPN Gateway, GCP Cloud VPN

CDN (Content Delivery Network)

Edge lokace pro cachování statického obsahu
DDoS ochrana
SSL/TLS termination na edge
Poskytovatelé: CloudFront, Cloudflare, Akamai, Fastly

BGP a routing

BGP — protokol pro výměnu rout mezi AS (autonomními systémy)
ASN — unikátní identifikátor sítě
iBGP — interní BGP (uvnitř AS)
eBGP — externí BGP (mezi AS)

BGP path selection algoritmus

BGP router vybírá jedinou nejlepší cestu podle následujících kriterií (v pořadí priority):

WEIGHT (Cisco-specific) — nejvyšší weight (local to router)
LOCAL_PREF — nejvyšší local preference (v rámci AS)
Originate — preferuje route originovanou lokálním routerem
AS_PATH — nejkratší AS_PATH length
ORIGIN — IGP < EGP < INCOMPLETE
MED (Multi-Exit Discriminator) — nejnižší MED (při stejném AS souseda)
eBGP > iBGP — preferuje externí BGP před interním
Next-hop reachable — cesta k next-hop musí být dosažitelná
Neighbor IP — preferuje cestu od routeru s nejnižší IP
Router ID — preferuje cestu s nejnižším Router ID

iBGP full mesh vs Route Reflectors

Aspekt	Full mesh	Route reflectors
Počet session	n(n-1)/2	n (každý peer k RR)
Při 100 routerech	4 950 session	100 (při 1 RR)
Škálování	Špatné (kvadratické)	Lineární
Redundance	Přirozená	Nutné multi-RR + cluster
Konfigurace	Jednoduchá logika	RR pravidel (non-transitive)

BGP nutné znát pro: Cloud interconnects, MPLS L3VPN, SD-WAN, Data center fabrics (VXLAN + BGP EVPN)

Architektura VPC / Virtual Network

Internet ──┬── Internet Gateway (IGW)
           │
    ┌──────▼──────┐
    │  Public Subnet │
    │  ┌──────────┐  │
    │  │  ALB/NAT │  │
    │  └────┬─────┘  │
    └───────┼────────┘
            │
    ┌───────▼────────┐
    │  Private Subnet │
    │  ┌──────────┐   │
    │  │  App      │   │
    │  └────┬─────┘   │
    └───────┼─────────┘
            │
    ┌───────▼─────────┐
    │  Data Subnet     │
    │  ┌────────────┐  │
    │  │  Database   │  │
    │  └────────────┘  │
    └──────────────────┘

VPC design patterns

Three-tier architecture

Web tier (public subnets) → ALB
App tier (private subnets) → auto-scaling
Data tier (private subnets) → RDS / self-managed DB
NAT Gateway / Instance v public subnet pro outbound traffic z app/data tier

VPC Peering

Přímé spojení mezi dvěma VPC (same nebo cross-account)
Transitive peering není podporován (A→B, B→C neznamená A→C)
Případy: sharing resources (LDAP, monitoring), service endpoints

Transit Gateway

Hub-and-spoke topologie, transitive routing
Podporuje: VPC, VPN, Direct Connect, peering mezi TGW
Route tables per attachment — izolace environmentů
AWS TGW: 50 Gbps per attachment, až 5000 attachments

PrivateLink / VPC Endpoint

Privátní přístup k službám bez IGW, NAT, VPC peering
Interface Endpoint (ENI v subnet) — pro AWS services, SaaS
Gateway Endpoint (S3, DynamoDB) — route table entry, zdarma
AWS PrivateLink — Service Consumer ↔ NLB/ENI ↔ Service Provider

MTU, jumbo frames, PMTUD

Síť	Standardní MTU	Jumbo frames
Ethernet	1500 B	9001 B (AWS: 9001, Azure: 1400→9000)
GRE tunel	1476 B	—
PPPoE	1492 B	—
VLAN (802.1Q)	1496 B	—
VXLAN	N/A (inner 1500 + 50)	8950 B

PMTUD (Path MTU Discovery)

Nastaví DF (Don't Fragment) bit v IP hlavičce
Pokud cesta vyžaduje fragmentaci → ICMP "Fragmentation Needed" (Type 3, Code 4)
Snižuje MTU, dokud paket neprojde
Častý problém: ICMP blokovaný firewallem → black hole (TCP connection hangs)
Workaround: MSS clamping (TCP MSS = MTU - 40)

Jumbo frames use cases

NFS / SMB (NAS)
iSCSI / NVMe-oF (SAN)
HPC / MPI workloads
Data replication (DB, DRBD)
Amazon EFS, AWS Managed Streaming pro Kafka

Anycast vs Unicast vs Multicast

Typ	Popis	Příklad
Unicast	1:1 — jeden source, jeden destination	Běžný TCP/IP provoz
Multicast	1:N — jeden source, skupina receiverů	IPTV, mDNS, VXLAN BUM traffic
Anycast	1:1 z nejbližšího — stejná IP z více lokací	DNS (8.8.8.8, 1.1.1.1), Cloudflare
Broadcast	1:VŠICHNI — všechna zařízení v síti	ARP, DHCP (omezeno na L2 broadcast doménu)

Anycast detail:

Stejná IP prefix je anunciována z více lokací (BGP)
Traffic jde k topologicky nejbližšímu uzlu (BGP path selection)
Výhody: jednoduchá redundance, DDoS absorpce, nižší latence
Výzvy: connection persistence (TCP), stateful anycast, routing convergence
Cloud: Route53, CloudFront, Cloudflare, Google DNS

Cloud networking resilience (2026)

Viz také: CLOUD.md — cloud architektura, multi-AZ, hybrid cloud konektivita.

Cell-based architektury

Izolace fault domain do "cell" (skupina AZ + services)
Každá cell samostatně deploysovatelná, vlastní DB, vlastní LB
Limit blast radius: selhání jedné cell neovlivní ostatní
Implementace: AWS Cell-based architecture, Azure STAG (Scale Tier Availability Group)

DNS resilience

Anycast DNS — stejná IP z více regionů, směrování k nejbližšímu
DNS failover — health checky automaticky odstraňují nedostupné endpointy
Multi-DNS provider — Route53 + Cloudflare + UltraDNS pro eliminaci SPOF

Traffic engineering

BGP optimization — AS path prepend, MED, local pref pro řízení vstupního/výstupního trafficu
Global Load Balancing — GSLB na DNS úrovni (latency-based, geo-proximity, weighted)
AIOps — ML-based predikce traffic patternů a automatické škálování

Nové trendy

Path Aware Networking — aplikace si vybírá cestu sítí podle aktuálních podmínek
Segment Routing (SR-MPLS / SRv6) — zjednodušení MPLS, programovatelné cesty
Zero Trust Networking — mikrosegmentace, identity-based access, never trust / always verify

Best practices

Segmentace sítě — oddělení environmentů (dev/staging/prod), vrstev (web/app/db)
Least privilege access — security groups povolují jen nutný provoz
Monitoring — VPC Flow Logs, netflow, sFlow
Redundance — multi-AZ, multi-region pro kritické služby
Encryption in transit — TLS všude, mTLS pro service-to-service
DDoS protection — AWS Shield, Azure DDoS Protection, Cloudflare

Zdroje

Odkazy, knihy a standardy: sources/networking/sources.md

MTU alignment — konzistentní MTU napříč celou cestou, kontrola ICMP blokování pro PMTUD
IP planning — RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), vyhnout se překryvům pro peering

TLS detail

TLS 1.3 handshake (1-RTT)

Client                                     Server
  |                                          |
  |  ClientHello (key_share, sig_algs)      |
  |─────────────────────────────────────────>|
  |                                          |
  |  ServerHello + EncryptedExtensions       |
  |  + Certificate + CertificateVerify      |
  |  + Finished                              |
  |<─────────────────────────────────────────|
  |                                          |
  |  Finished                                |
  |─────────────────────────────────────────>|
  |                                          |
  |  << Application Data >>                  |

0-RTT (early data) — client posílá data ihned s první zprávou (při opakovaném spojení s PSK)
Riziko 0-RTT: replay attacks (HTTP GET je bezpečný, POST vyžaduje ochranu)
Oproti TLS 1.2: odstraněny zastaralé ciphery, AEAD required, faster handshake (2 RTT → 1 RTT)

Cipher suites

Suite	Key exchange	Auth	Encryption	MAC	Status
`TLS_AES_128_GCM_SHA256`	(EC)DHE	(EC)DHE	AES-128-GCM	AEAD	TLS 1.3 default
`TLS_AES_256_GCM_SHA384`	(EC)DHE	(EC)DHE	AES-256-GCM	AEAD	Vyšší bezpečnost
`TLS_CHACHA20_POLY1305_SHA256`	(EC)DHE	(EC)DHE	ChaCha20-Poly1305	AEAD	Mobilní / bez AES-NI
`ECDHE-ECDSA-AES128-GCM-SHA256`	ECDHE	ECDSA	AES-128-GCM	AEAD	TLS 1.2 (PFS)
`ECDHE-RSA-AES128-GCM-SHA256`	ECDHE	RSA	AES-128-GCM	AEAD	TLS 1.2 (PFS)

PFS (Perfect Forward Secrecy) — při kompromitaci privátního klíče nelze dešifrovat dříve zachycený provoz (ECDHE + ephemeral klíče).

Certificate chain validation

1. Client obdrží certificate chain od serveru
2. Validace:
   a. Datum: certifikát není expirovaný a je platný (notBefore, notAfter)
   b. CRL / OCSP: certifikát není revokován (OCSP stapling pro snížení latence)
   c. Signature chain: podpis každého certu v řetězu je ověřen veřejným klíčem vydavatele
   d. Root CA: poslední cert v řetězu je důvěryhodný (v trust store klienta)
3. CN / SAN: doménové jméno v certifikátu musí odpovídat cílové doméně

Typický řetěz: Leaf Cert → Intermediate CA → Root CA (self-signed, v trust store).

17 KiB Raw Blame History Unescape Escape