knowledge-base/NETWORKING.md

🌐 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 kritérií (v pořadí priority):

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

Rozšířená témata podle knih

TCP/IP Illustrated (Stevens, ISBN 978-0321336316)

Klíčové architektonické principy dle knihy:

• End-to-End Argument — korektnost a kompletnost komunikace může být zajištěna pouze na úrovni aplikace, nikoliv nižších vrstev. Síť má být "hloupá", koncové stanice "chytré".
• Fate Sharing — veškerý stav nutný k udržení aktivní komunikace musí být uložen na koncových bodech (endpoints), nikoliv v síti.
• Layering — hierarchické vrstvení protokolů dle OSI modelu; každá vrstva zapouzdřuje PDU z vyšší vrstvy a přidává vlastní hlavičku.
• Multiplexing/Demultiplexing — protokoly na stejné vrstvě koexistují díky identifikátorům (IP proto, TCP/UDP port).
• Sliding window — efektivní využití linky při vysoké latenci (window size = bandwidth × RTT).

Kniha pokrývá celý TCP/IP stack od linkové vrstvy (Ethernet, ARP, PPP) přes IP, ICMP, DHCP, NAT, DNS, UDP, TCP (connection management, timeout, retransmission, congestion control, keepalive) až po aplikace (SNMP, Telnet, FTP, SMTP, NFS, HTTP).

AI Data Center Network Design (Subramaniam, ISBN 978-0-13-543628-8)

Komplexní, vendor-agnostický průvodce návrhem síťové infrastruktury pro AI clustery.

Klíčové koncepty:

• Rail-Optimized Design (ROD) — propojení GPU napříč racky po "kolejích" (rail), každá kolej tvoří nezávislou síť pro all-reduce komunikaci. Minimalizuje latenci pro synchronní training.
• Rail-Unified Design (RUD) — sdílená network fabric pro všechny GPU, flexibilnější, ale vyšší nároky na load balancing.
• RoCEv2 (RDMA over Converged Ethernet) — primární transport pro AI clustery: vyžaduje lossless fabric (ECN, PFC, DCQCN, SFC, CSIG).
• Load balancing pro AI — ECMP nestačí, nutné dynamic/global load balancing (DLB/GLB), flowlet-based rebalancing, per-packet spraying.
• Topologie — Clos (3-stage/5-stage), Dragonfly, Torus pro škálování na desítky tisíc GPU.
• Ultra Ethernet Consortium (UEC) — nový standard pro Ethernet v AI clastrech (2025+), řeší omezení RoCEv2.
• Storage pro AI — NVMe-oF, GPUDirect Storage, parallel file systems pro checkpointing a dataset loading.
• KPIs — Job Completion Time (JCT), tail latency, fabric utilization, PFC storm detection.

Cloud Networking and Resilience (Critelli, ISBN 979-8868824357)

Praktický průvodce budováním resilientních cloudových sítí (Apress, 2026). Autor je EMEA Lead pro Networking & Resilience v AWS.

Vrstvový přístup k resilienci (podle OSI modelu):

Vrstva	Opatření
L1 (Fyzická)	Redundantní přípojky, diverse fibre paths, DWDM
L2 (Linková)	MLAG, LACP, spanning-tree rychlá konvergence
L3 (Síťová)	BGP multi-homing, AS path prepend, Anycast
L4 (Transportní)	Connection draining, slow start, health checky
L7 (Aplikační)	DNS failover, global load balancing, cell-based architektury

Regulatorní rámce: DORA (Digital Operational Resilience Act), NIS2 — vyžadují pravidelné testování resiliency, chaos engineering, business continuity plány.

AIOps v resilienci: ML-based predikce traffic patternů, automatické škálování, proaktivní fault detection (přechod od reaktivního monitoringu k prediktivní prevenci).

Zero Trust in Resilient Cloud and Network Architectures (Halley et al., ISBN 978-0-13-820460-0)

Cisco Press — praktická příručka pro nasazení Zero Trust architektur v hybridních a cloudových prostředích.

Implementační rámec:

• User and Device Trust — ověření identity uživatele i zařízení před udělením přístupu (SSE — Security Service Edge).
• Application Access Policies — granulární pravidla na úrovni aplikace, nikoliv IP adresy.
• Greenfield vs Brownfield — nové sítě stavěné jako Zero Trust od základu vs. migrace existující infrastruktury.
• Automation — Terraform, Ansible pro provisioning; Meraki, EVPN, Pub/Sub telemetrie.
• Industrial Zero Trust — rozšíření konceptu do OT/ICS prostředí.
• Quantum security — příprava na post-quantum kryptografii v síťových architekturách.

The Segmentation Blueprint (Kulkarni, ISBN 978-0-13-546236-2)

Cisco Press (2026) — pragmatický průvodce segmentací sítě od VLAN po nanosegmentaci.

Evoluce segmentace:

Generace	Technologie	Rozsah
Tradiční	VLAN, ACL, firewall	Podsíť / subnet
Mikrosegmentace	Security Groups, Network Policies	Workload / instance
Nanosegmentace	Service mesh (Istio, Linkerd), mTLS	Aplikace / API / proces

Maturity model segmentace:

1. Initial — flat network, žádná segmentace
2. Basic — VLANy, firewall mezi environmenty
3. Defined — Security Groups, service access policies
4. Managed — Mikrosegmentace, Network Policies, EVPN
5. Optimized — Nanosegmentace, service mesh, Zero Trust, AI-driven policy management

Klíčová metrika: Blast radius — kolik workloadů je ohroženo při kompromitaci jednoho uzlu. Cílem je redukce na minimum.

Segment Routing for SP and Enterprise Networks (Deragisch, ISBN 978-0-13-823101-9)

Cisco Press (2024) — ucelený průvodce Segment Routingem pro MPLS i IPv6 data plane.

SR-MPLS vs SRv6:

Vlastnost	SR-MPLS	SRv6
SID délka	20 bit (MPLS label)	128 bit (IPv6 address)
Data plane	MPLS	IPv6 + SRH (Segment Routing Header)
Signalizace	IGP (IS-IS/OSPF) extensions	IGP + BGP extensions
Zrání	Mature, široce nasazeno	Emerging, standardizace dokončena
Use case	SP sítě, MPLS migration	Cloud, DC, 5G, end-to-end programovatelnost

Výhody SR oproti klasickému MPLS:

• Eliminace LDP/RSVP-TE (signaling je součástí IGP)
• Traffic engineering state přesunutý z uzlů do packet headerů (source routing)
• Fast reroute (FRR) bez dodatečných protokolů
• Egress Peer Engineering (EPE) — výběr exit pointu AS
• Mikro-loop avoidance při konvergenci

Migrační strategie: Greenfield (nová síť), Brownfield (postupná migrace z MPLS), "SR in a box" — kombinace SR a LDP.

Understanding and Designing Azure Networking (Stuart, Moreno, 2025)

Praktický průvodce návrhem Azure sítí od dvou Microsoft Solution Engineers (bývalí CCIE).

Klíčová témata:

Oblast	Klíčové služby a koncepty
Topologie	Hub-and-spoke, Virtual WAN, multi-hub designs, Azure Route Server
Hybridní konektivita	ExpressRoute, VPN Gateway, SD-WAN integrace
Multi-cloud	Azure ↔ AWS/GCP, cross-cloud fabrics
Bezpečnost	NSG, Azure Firewall, DDoS Protection, WAF, AVNM, ZTNA
DNS & PaaS	Private Link, Private DNS Zones, Private Resolver, hybrid DNS forwarding
Application delivery	Azure Load Balancer, App Gateway, Front Door, Traffic Manager
Monitoring	Network Watcher, Traffic Analytics, Azure Monitor, Policy-as-code

Design decision framework: Sbírej požadavky → analyzuj constraints → vyber topologii → implementuj → monitoruj.

Mastering Next-Gen Juniper Data Centers (Chatterjee, ISBN 978-0-13-533636-6)

Addison-Wesley (2026) — hands-on průvodce EVPN VXLAN fabrikami na Juniper zařízeních.

Klíčové architektury:

• EVPN VXLAN fabric — multi-tenant overlay sítě s BGP EVPN control plane a VXLAN data plane.
• Multivendor interoperability — detailní postupy pro EVPN napříč Juniper, Cisco NX-OS, Arista EOS.
• Multicast v EVPN VXLAN — intra-subnet i inter-subnet multicast design (IGMP/MLD proxying, PIM, EVPN Type-6/7 routes).
• Day-2 operations — Juniper Apstra pro automatizaci (Terraform provider), telemetrie (gNMI, OpenConfig).
• Service chaining — propojení NGFW, load balancerů v rámci fabric.
• DCI s EVPN — Over-the-Top (OTT) i Integrated Interconnect (VXLAN stitching, MPLS transit).

Evoluce od předchozí knihy (Deploying Juniper Data Centers with EVPN VXLAN, 2024): Rozšíření o pokročilá témata — multicast, interoperability, Apstra Day-2, observability stack.

Intelligent Cloud Networking: AI-Driven Resource Management (Yadav, ISBN 9364220110)

Průnik AI/ML a cloudového network managementu (Addition Publishing, 2026).

Aplikace AI v síťovém managementu:

Oblast	Technika	Přínos
Flow prediction	LSTM, Transformer	Predikce traffic patternů, proaktivní škálování
Flow classification	CNN, RL	Identifikace typů provozu pro QoS
Load balancing	DRL (Deep RL)	Dynamická distribuce zátěže, redukce congestion
Resource management	Q-learning, DQN	Optimalizace alokace CPU/memory/network
Routing optimization	DRL, GNN	Adaptivní routing podle aktuálních podmínek
Congestion control	ML-based CC	Prediktivní řízení congeste (místo reakce na loss)
Anomaly detection	Autoencoders, Isolation Forest	Detekce útoků a anomálií v reálném čase
Blockchain security	Smart contracts	Decentralizované řízení přístupu, audit trail

Technologické směry:

• Ultra Ethernet Consortium (UEC) — nová generace Ethernetu pro AI, lossless fabric, telemetrie, adaptive routing.
• Path Aware Networking — aplikace si vybírá cestu podle aktuálních podmínek (latence, loss, cena).
• Self-optimizing networks — uzavřená smyčka: telemetrie → AI analýza → automatická akce → zpětná vazba.

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).

Poslední revize: 2026-06-03