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

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.2 KiB Raw Blame History Unescape Escape