2026 Halo-Style globaler Einstieg
SCP/SFTP-Artefakt-p95, TCP-Fenster & regionale Knoten-Abnahme

Dieser Text setzt die DNS- und SSH-Rahmung aus Halo-Style: GeoDNS, SSH & Knoten-Matrix und die TTL-/Split-Horizon-Diskussion in Split-horizon vs. GeoDNS & Artefakt-p95 fort, zielt aber auf Massentransfer über SSH und TCP-Fensterskalierung, wenn Runner in Japan, Korea, Hongkong, Singapur und US-West Artefakte mit Registries austauschen, die einen Ozean entfernt stehen können. Für per Edge geroutetes HTTPS plus SSH-Abnahme US-West gegenüber Hongkong oder Singapur parallel Cloudflare Worker, SSH-p95 offen halten, damit Marketing-Hostnamen nicht still von dem abweichen, was CI wirklich nutzt.

Halo-Einstieg: Entscheidungsmatrix (Steuerung vs. Artefaktebene)

Nutzen Sie die Matrix in Design-Reviews, bevor Sie einen einzigen „globalen“ Hostnamen für Menschen und Automatisierung zementieren. Zeilen beschreiben, wofür Sie optimieren; Spalten zeigen, ob Halo-Indirektion hilft oder Schmerz verbirgt.

Routenwahl (welcher PoP „besitzt“ die Bytes)

Routenwahl meint hier die ganze Kette: Antwort des Client-Resolvers, TCP-Pfad zum Remote Mac oder Bastion und Weiterweg zum Objektspeicher—nicht nur, welche Landesflagge im Marketing steht. Für SCP/SFTP wählen Sie den PoP, in dem (a) Ihr Builder läuft, (b) die autoritative oder replizierte Registry liegt und (c) Ihre Enterprise-Egress-Policy Massenflüsse bereits erlaubt. Weicht ein Bein ab, dokumentieren Sie es als „Relay-Hop“ mit eigenem Latenzbudget statt so zu tun, als hätte GeoDNS die Physik gelöst.

Pragmatische Teilung: Menschen dürfen auf einem Halo-Hostnamen landen; CI sollte Endpunkte im Stil artifacts.jp.example ansprechen, die im selben Metro wie der Runner auflösen. Wenn Korea- und Japan-Teams eine Singapur-Registry teilen, behandeln Sie Singapur als den gewollten Backhaul-Hub und dimensionieren p95 gegen diesen Hub—nicht gegen eine Fantasie-Direktverbindung Tokyo–Seoul über das öffentliche Internet.

Parallelverbindungen (Selbst-DDoS vermeiden)

SCP und SFTP über OpenSSH skalieren viele kleine Dateien schlecht, wenn Sie vom selben CI-Host dutzende parallele Sessions öffnen: jede Session zahlt Handshakes und konkurriert um Kernel-Puffer. Begrenzen Sie parallele Transfers pro Runner (oft 2–4 große Streams oder ein Stream plus Metadaten) und erhöhen Sie Limits erst, wenn Server-MaxSessions, CPU und Disk den Burst verkraften. Auf macOS-Buildern syslog auf Plattenstress prüfen; auf Linux-Relays Retransmit-Zähler in ss.

Wenn Sie für viele kleine Dateien auf ControlMaster setzen: Das optimiert Verbindungsaufbau—nicht Bandbreite über den Ozean. Kombinieren Sie mit Archiven (tar vor dem Kopieren) oder rsync-ähnlichen Deltas, wo Policy es erlaubt, damit Parallelität auf echte Bytes auf der Leitung abbildet.

Prüfsummen (trust, aber verify—im p95-Maßstab)

Im Multi-Gigabyte-Maßstab ist „Kopie fertig“ ohne kryptografische Prüfung ein Lotterielos. Standardisieren Sie ein Algorithmus pro Pipeline (sha256sum auf beiden Seiten oder Registry-Manifeste) und protokollieren Sie Digest, Größe und Sekunden in derselben Logzeile wie Hostname und Regions-ID. Für SFTP in Automatisierung: signierte Manifeste aus dem Build-System statt Ad-hoc-Remote-Shell-Pipelines, die sich im Vorfall schwer nachspielen lassen.

Bei Prüfsummen-Konflikt zuerst Transport- oder Storage-Vorfall annehmen, nicht „User Error“: TCP-Retransmits am Relay erfassen, MTU-Pfade vergleichen, erst dann Transfer mit engerem Parallelitätsfenster wiederholen.

Fehler & Wiederholung (Backoff vs. Blast-Radius)

Retries müssen begrenzt sein: exponentielles Backoff mit Jitter, maximale Versuchszahl und Circuit Breaker, wenn p95 fünfzehn Minuten über Budget liegt. Keine engen Reconnect-Schleifen gegen einen gemeinsamen Bastion—das wirkt wie ein Angriff und verbrennt File-Descriptors für alle. Bei Teildateien Resume-Primitive nutzen (anfügbare SFTP-Server, segmentierter HTTP-Download, Multipart-APIs des Objektspeichers) statt stundenlange Kopien blind zu löschen und neu zu starten.

Retry-Gründe loggen (timeout, reset, digest_mismatch, quota), damit Postmortems DNS-Flaps von Congestion-Loss unterscheiden ohne den Transfer erneut fahren zu müssen.

TCP-Fensterskalierung, sysctl und OpenSSH (mit Grenzen)

Pfade mit hohem Bandbreiten-Verzögerungs-Produkt brauchen groß genug Sende- und Empfangsfenster, damit TCP Window Scaling wirkt; sonst bleibt der Durchsatz flach unter der Linkkapazität, obwohl Ping harmlos wirkt. Tuning gehört primär auf von Ihnen betriebene Linux-Relays oder Registries—nicht auf jedes Laptop—und immer mit Change Control.

# ── Linux-Relay / Bastion unter Ihrer Kontrolle (NICHT beliebige macOS-Clients) ──
# Grenze: nur auf dedizierten Transfer-Hosts; vor/nach messen;
# zurückrollen, wenn Middleboxes oder Legacy-Firewalls große Fenster schlecht vertragen.
sudo sysctl -w net.ipv4.tcp_window_scaling=1
sudo sysctl -w net.core.rmem_max=134217728 net.core.wmem_max=134217728
sudo sysctl -w net.ipv4.tcp_rmem="4096 87380 67108864" net.ipv4.tcp_wmem="4096 65536 67108864"

# OpenSSH-Client für Bulk (pro Job oder ~/.ssh/config-Block)
# Grenze: Compression=yes kann bei bereits komprimierten Artefakten schaden.
scp -o Compression=no -c aes128-gcm@openssh.com -o IPQoS=throughput …

# OpenSSH-Server (sshd_config) — Grenze: MaxStartups nur nach Lasttest
# MaxStartups 10:30:100
# ClientAliveInterval 30

Zusammenfassung—Kauf und Bereitstellung: Wählen Sie den vpshalo-PoP, der sowohl zur SSH-Steuerung als auch zur Artefakt-Spur passt, bevor Sie ein Quartal Builds an die falsche Küste hängen. p95 am Referenzobjekt bestätigen, Prüfsummen-Policy fixieren, Retry-Budgets verdrahten, dann Mac-Kapazität kaufen oder erweitern in derselben Region, damit Finance, DNS und Bytes auf der Leitung eine Geschichte erzählen. Matrix nach jedem großen DNS- oder Registry-Move erneut durchlaufen.