work/notes/nextcloud/Notes/IT-Know-How/web und cloud gedöns/Layer 7 Logik.md

„Layer‑7‑Logik“ bezieht sich auf Entscheidungen/Routing auf Basis der Anwendungsebene (Layer 7 im OSI-Modell).

Kurz zum Kontext:

• Layer 3 (Netzwerk): IP-Adressen
• Layer 4 (Transport): TCP/UDP, Ports (z. B. Port 80, 443)
• Layer 7 (Anwendung): HTTP, HTTPS, gRPC, SMTP etc. – also „Inhalt“ der Anfrage

Layer‑4‑Routing:
Es wird nur nach IP + Port entschieden. Beispiel:

• Alles an 10.0.0.5:80 geht zu Service A.
  Der Proxy/Loadbalancer „sieht“ nicht, ob das /api oder /shop ist.

Layer‑7‑Logik:
Der Proxy versteht das Protokoll (z. B. HTTP) und kann anhand von Anwendungsdaten entscheiden:

• Hostname: api.example.com → Service A, shop.example.com → Service B
• Pfad: /api → Backend 1, /app → Backend 2
• HTTP-Header: bestimmter User-Agent, X-Feature-Flag → anderes Routing
• Cookies / Session: z. B. „User ist in A/B-Test-Gruppe → anderes Backend“
• Authentifizierung / JWT token prüfen, bevor weitergeleitet wird
• TLS-Termination: HTTPS entschlüsseln, weiter innen nur HTTP sprechen

Im Kubernetes-Ingress-Kontext heißt „Layer‑7‑Logik“ also:
Der Ingress-Controller trifft Routing- und Sicherheitsentscheidungen auf Basis von HTTP(S)-Details (Host, Pfad, Header, Cookies usw.), nicht nur auf Basis von IPs und Ports.