Relay: Speicherlos heißt nicht arbeitslos
Warum das Relay (Serverweg) keine Datei behält und trotzdem Speicher und CPU braucht, und wie Rückstau es begrenzt hält.
Beim Relay (Serverweg) müssen beide Endpunkte gleichzeitig erreichbar sein. Der Dienst authentisiert und autorisiert sie, bindet sie an denselben Versuch und leitet begrenzte Binärnachrichten weiter. Dateibytes berühren weder Objektspeicher noch den Nachrichtenbus. Endpunktzuordnung, Budgets, laufende Rechteprüfung und Abbruch bleiben erforderlich.
Speicherlos heißt: Es wird nie eine Datei geschrieben, nicht „ohne Arbeitsspeicher“. Socketpuffer, Framepuffer und begrenzte Verarbeitung brauchen Arbeitsspeicher. Backpressure, also Rückstau vom langsamen Empfänger, sorgt dafür, dass die Kette den Sender bremst, statt die ganze Datei in einer unbeschränkten Warteschlange zu sammeln.
- Verschlüsselte FramesDateidaten
- Begrenzte WeiterleitungDateidaten
- Verschlüsselte FramesDateidaten
- Kann gerade weniger aufnehmenAlternativer Weg
- Begrenzter RückstauAlternativer Weg
- Der Sender wird gebremstAlternativer Weg
Warum kann dabei trotzdem CPU-Last entstehen?
CPU-Last auf einem Relay ist Paketverarbeitung und TLS, keine Dateientschlüsselung. Der Host bearbeitet Netzwerkpakete, TLS am HTTPS-Endpunkt, WebSocket-Frames, Kopien zwischen Puffern, Systemaufrufe und Prozessaufweckungen. Bei kleinen Frames oder zusätzlichen Proxyhops kann dieser Verwaltungsaufwand relevant sein, obwohl keine AES-Dateientschlüsselung auf dem Server stattfindet.
Das Relay verwendet Puffer wieder und bündelt kleine Socketwrites. Größere begrenzte Schreibpuffer sind keine neue Dateiablage und kein Anlass, Rechteprüfungen, Zeitgrenzen oder Backpressure abzuschalten. Mehr Serverkerne helfen mehreren gleichzeitigen Verbindungen; sie versprechen nicht, dass ein einzelner serieller Datenpfad schneller wird.
Ein Prozessausfall kann den Kanal beenden. Das Relay ist ein Livekanal, kein Postfach: Fällt eine Seite weg, wird mit einem neuen Versuch nach demselben Auftrag fortgesetzt.
Verwandte Anleitungen
Streaming und Sendefenster: Durchsatz ohne unendlichen Puffer
Vier Größen, die man nicht verwechseln darf, wie ein Fenster eine lange Leitung ausgelastet hält und warum ein größeres Fenster allein nichts beschleunigt.
Verbindungsaufbau: Nahbereich, WebRTC, TLS, Routing und ICMP
Wie Geräte sich im Nahbereich und über Netze hinweg finden, warum ein geroutetes Netz kein Sonderformat braucht und was der ICMP-Weg für abgeschottete Linux-Hosts leistet.
Direkt, Serverweg und geroutete Netze: Welcher Weg funktioniert?
Was „direkt“ wirklich bedeutet, wann pipeit über seine Server leitet und was du prüfen kannst.