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 §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 — und zwar als echter Pass-Through: SpiderNet gibt diese Verbindungen unverändert weiter, sie nehmen den normalen Weg durch den eigenen Router und den eigenen Uplink, als wäre SpiderNet nicht da (kein Tunnel, kein MITM). 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)

Per-Connection-Limits: manche Server/CDNs drosseln pro Verbindung (z. B. 5 MB/s) — dann braucht man genug Segmente, um den Pool auszureizen.
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.
Signierte URLs: meist unkritisch (Ranges innerhalb der Gültigkeit erlaubt), aber Auth-Cookies müssen pro Exit-Verbindung mitgeliefert werden — bei geteilten Logins vorsichtig.
Accept-Ranges: none: Server kann Ranges explizit verweigern → Fallback (ein Exit), nur bei großem Objekt schade.
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).

5.3 KiB Raw Blame History Unescape Escape