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.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](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*