diff --git a/documentation/Home.md b/documentation/Home.md index 9b91630..c1196dd 100644 --- a/documentation/Home.md +++ b/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 diff --git a/documentation/README.md b/documentation/README.md index f4a4511..4168e63 100644 --- a/documentation/README.md +++ b/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`, …) diff --git a/documentation/ideen/architektur.md b/documentation/ideen/architektur.md index 272c5aa..dcd4935 100644 --- a/documentation/ideen/architektur.md +++ b/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 gepinnt (kein Splitting). +Exit, große Transfers über alle. + +- **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`) diff --git a/documentation/ideen/splitting.md b/documentation/ideen/splitting.md new file mode 100644 index 0000000..34933f7 --- /dev/null +++ b/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).