Docs: add Splitting note (ranges vs flow distribution vs realtime) and link it

documentation/ideen/splitting.md

@@ -0,0 +1,97 @@
+# Splitting-Fähigkeit — was lässt sich über mehrere Exits verteilen?
+
+Die zentrale Frage: Welche Traffic-Arten können die gepoolte Bandbreite der
+Nachbarschaft nutzen, und was braucht die Quelle (Server) dafür?
+
+## Die drei Kategorien
+
+### 1. Range-basiert splittbar (echtes Splitting)
+
+Standard-HTTP, kein Spezialformat: Der Server muss nur **HTTP Range Requests**
+unterstützen ([RFC 9110](https://httpwg.org/specs/rfc9110.html) §14, früher
+RFC 7233) — Anfrage mit `Range: bytes=0-999999`-Header, Antwort `206 Partial
+Content`. Praktisch alle großen Datei-Server können das; man prüft es mit
+einer Kopf-Anfrage: `Accept-Ranges: bytes` in der Antwort.
+
+| Läuft gut | Begründung |
+|---|---|
+| ISO-Images, große Dateien (Linux-Distros, Archive) | klassischer Range-Fall, CDNs/S3/nginx/Apache unterstützen es |
+| Steam / Konsolen-Updates / OS-Updates | laden selbst mehrschichtig parallel, Ranges sind Teil des Designs |
+| Video-on-Demand (HLS/DASH-Streaming) | ohnehin in 2–10-s-Segmente zerlegt; Segmente sind einzelne HTTP-Objekte → Verteilung auf Exits gratis |
+| Torrents | sind inhärent multi-connection; Verteilung über Exits ist einfach Flow-Verteilung |
+
+**Wichtig bei HTTPS:** Range-Splitting funktioniert trotzdem — jeder Exit
+baut seine *eigene* TLS-Verbindung zum Server auf und sieht nur
+verschlüsselte Bytes. Der Server sieht dann N Verbindungen von N
+verschiedenen IPs (siehe Vorbehalte unten).
+
+### 2. Verbindungs-basiert verteilbar (Aggregation ohne Splitting)
+
+Hier wird **kein einzelner Strom** gesplittet — sondern viele
+selbstständige Verbindungen werden auf die Exits verteilt (Flow-Level-
+Balancing). Jede einzelne Verbindung läuft vollständig über einen Exit.
+
+| Läuft gut | Begründung |
+|---|---|
+| Normales Web-Browsing | der Browser baut ohnehin viele parallele Verbindungen zu vielen Hosts auf — die verteilen sich natürlich auf Exits |
+| Paketmanager (apt, pip, cargo, npm) | hunderte kleine Dateien = hunderte Verbindungen |
+| API-Traffic, RSS, DNS | viele kleine unabhängige Anfragen |
+
+Der Pooling-Gewinn entsteht **nur bei paralleler Last** (viele Verbindungen
+gleichzeitig). Ein einzelnes HTTP-Objekt ohne Range-Support bleibt auf
+Uplink-Geschwindigkeit.
+
+### 3. Nicht splittbar — sticky single Exit (bzw. Direct-Modus)
+
+Einzelne, latenzempfindliche Ströme, bei denen ein Mid-Stream-Exit-Wechsel
+die Verbindung kaputt machen würde (IP-Wechsel beendet die Session):
+
+| Kategorie | Warum nicht splittbar |
+|---|---|
+| **Video-Calls (WebRTC)** | einzelner DTLS/SRTP-UDP-Strom, echtzeitkritisch, IP-gebunden |
+| Online-Gaming | einzelner UDP-Flow, IP-Stickiness wichtig, Latenz >> Bandbreite |
+| SSH / Remote-Desktop | interaktive TCP-Session, IP-Stickiness |
+| Banking/Logins | Session an IP gekoppelt; aber: funktioniert technisch über jeden Exit, nur nicht *wechselnd mitten in der Session* |
+| VPNs (WireGuard etc.) | UDP-Flow mit State |
+
+**Policy-Vorschlag (Default):** realzeitkritischer Traffic geht in den
+**Direct-Modus** — ohne Umweg, normal über den eigenen Router/Uplink, als
+wäre SpiderNet nicht da. Optional "best single exit" (wenn die eigene
+Leitung gestört/überlastet ist, kann man den Call bewusst über einen
+Nachbarschafts-Exit pinnen — aber dann sticky für die Dauer der Session).
+
+## Was die Quelle mitbringen muss (Zusammenfassung)
+
+| Anforderung | Betrifft | Fehlt sie… |
+|---|---|---|
+| `Accept-Ranges: bytes` + `206 Partial Content` | Kategorie 1 | …fällt das Objekt auf Kategorie 2/3 zurück (Download über *einen* Exit komplett) |
+| viele unabhängige Verbindungen möglich | Kategorie 2 | nothing — das ist der Normalfall |
+| Session-Stabilität (IP-Stickiness) | Kategorie 3 | …darf der Exit nicht wechseln; Direct-Modus ist der sichere Default |
+
+## Vorbehalte bei Range-Splitting (ehrliche Liste)
+
+1. **Per-Connection-Limits:** manche Server/CDNs drosseln pro Verbindung
+   (z. B. 5 MB/s) — dann braucht man genug Segmente, um den Pool auszureizen.
+2. **Bot-Erkennung/IP-Diversity:** N Verbindungen von N verschiedenen IPs
+   für dasselbe Objekt kann Rate-Limits oder Captchas triggern. Gegenmaßnahme:
+   gleiche Exits pro Ziel-Host cachen (Affinität), Retry mit anderem Exit.
+3. **Signierte URLs:** meist unkritisch (Ranges innerhalb der Gültigkeit
+   erlaubt), aber Auth-Cookies müssen pro Exit-Verbindung mitgeliefert
+   werden — bei geteilten Logins vorsichtig.
+4. **`Accept-Ranges: none`:** Server kann Ranges explizit verweigern →
+   Fallback (ein Exit), nur bei großem Objekt schade.
+5. **MPTCP ist kein Plan A:** Multipath TCP könnte einen *einzigen* Stream
+   über mehrere Wege schicken, aber beide Endpunkte müssen es unterstützen —
+   im offenen Internet praktisch nicht gegeben. Deshalb: Segmentierung auf
+   Anwendungsebene, nicht Paketebene.
+
+## Konsequenz für die Software (`sn-fetch`)
+
+- Range-Fähigkeit pro URL/Host **automatisch erkennen** (Kopf-Anfrage auf
+  `Accept-Ranges`) und pro Host cachen.
+- Klassifizierung: Kategorie 1/2/3, je nach Art (auto: bekanntes Schema,
+  Konfig: Nutzer-Overrides, z. B. "WebRTC immer Direct").
+- Fallback-Kette: Ranges → Flow-Verteilung → single Exit (Direct-Modus).
+- Exit-Affinität pro Ziel-Host, um Bot-Erkennung zu vermeiden.
+
+Siehe auch: [[Architektur]] (Schicht 2), [[Idee]] (Realitätscheck).