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

documentation/Home.md

@@ -22,6 +22,7 @@ Nachbarschaft betreibt ihre eigene Instanz nach eigenen Regeln.
 | [[Idee]] | Kernidee + ehrlicher Realitätscheck |
 | [[Architektur]] | Schichten: Physik → Routing → Pooling → Freenet-Inhalte |
 | [[Recht]] | Deutsche Rechtslage + Pflichtregeln für die Software |
+| [[Splitting]] | Was sich splitten lässt: Ranges, Flow-Verteilung, Realtime |
 | [[Lizenz]] | Lizenz-Optionen (Code & Doku) |
 | [[Roadmap]] | Phasen: Pilot → MVP → Rollout → Freenet → Backbone |
 | [[Server-README|Server-Konzept]] | Software-Komponenten, Code-Standards |
@@ -38,7 +39,8 @@ Nachbarschaft betreibt ihre eigene Instanz nach eigenen Regeln.
 
 - [[Ethos]] §2 (Fairness/Leechen) ↔ [[Architektur]] (Leech-Modus, `sn-fair`)
 - [[Recht]] §5 (Pflichtregeln) ↔ [[Server-README]] (Haftungsausschluss)
-- [[Idee]] (Realitätscheck) ↔ [[Architektur]] (10G-Faser, `sn-fetch`)
+- [[Idee]] (Realitätscheck) ↔ [[Architektur]] (link-agnostische Physik, `sn-fetch`)
+- [[Splitting]] ↔ [[Architektur]] (Schicht 2) — was der Exit-Pool tatsächlich nutzen kann
 - [[Lizenz]] ↔ [[Ethos]] §6 (Transparenz) und `freenet-core` (AGPL)
 
 ## Außerhalb der Doku

documentation/README.md

@@ -14,6 +14,7 @@ unabhängige SpiderNet-Instanzen geben; wir providen nur die Werkzeuge.
 - [[Idee]] — Die Kernidee und ein ehrlicher Realitätscheck
 - [[Architektur]] — Technische Architektur (Physik → Routing → Pooling → Inhalt)
 - [[Recht]] — Rechtslage in Deutschland (Störerhaftung, Abmahnrisiko, Verkabelung)
+- [[Splitting]] — Was sich über mehrere Exits splitten/verteilen lässt (und was nicht)
 - [[Lizenz]] — Lizenz-Optionen und Empfehlung
 - [[Roadmap]] — Phasenplan vom Pilot bis zum Nachbarschafts-Backbone
 - [[Server-README|Server-Konzept]] — geplante Software (`sn-node`, `sn-fetch`, …)

documentation/ideen/architektur.md

@@ -116,8 +116,15 @@ sequenceDiagram
 
 VPN-artiges Overlay: pro Gerät ein verschlüsselter Tunnel zu *einem*
 gewählten Exit, Exit-Wahl rotiert; Browsing/Video-Calls laufen über einen
-Exit, große Transfers über alle. Video-Calls werden explizit auf einen
+Exit, große Transfers über alle.
-Exit gepinnt (kein Splitting).
+
+- **Realzeitkritischer Traffic (Video-Calls, Gaming, SSH): Direct-Modus
+  als Default** — ohne Umweg, normal über den eigenen Router/Uplink, als
+  wäre SpiderNet nicht da. Optional "best single exit" mit Session-Sticky
+  (kein Mid-Call-Wechsel, siehe [[Splitting]]).
+
+Was sich splitten lässt und was die Quelle dafür mitbringen muss:
+siehe [[Splitting]].
 
 ### Fairness-Scheduler (`sn-fair`)
 

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