2026 · matrice d’entrée globale « type Halo »
SCP/SFTP inter-régions (p95), fenêtres TCP & checklist JP / Corée / HK / SG / US Ouest

Cette note prolonge le cadrage DNS et SSH de GeoDNS, latence SSH et matrice de nœuds (2026) ainsi que le volet TTL / split-horizon de Split-horizon vs GeoDNS et p95 des artefacts, mais cible explicitement les transferts volumineux sur SSH et l’agrandissement des fenêtres TCP lorsque des runners au Japon, en Corée, à Hong Kong, à Singapour et sur la côte ouest des États-Unis échangent des artefacts avec un registre parfois séparé par un océan. Pour le HTTPS piloté en périphérie et une grille d’acceptation SSH US Ouest contre HK ou Singapour, gardez ouvert dans un autre onglet Worker Cloudflare et SSH p95 afin que les noms marketing ne divergent pas silencieusement de ce que la CI utilise réellement.

Matrice d’entrée Halo (plan de contrôle vs plan d’artefacts)

Utilisez la matrice en revue de conception avant de standardiser un seul nom « mondial » pour humains et automatisation. Les lignes décrivent ce que vous optimisez ; les colonnes indiquent si l’indirection façon Halo aide ou masque la douleur.

Choix de routage (quel PoP porte les octets)

Le choix de routage désigne ici toute la chaîne : réponse du résolveur client, chemin TCP vers le Mac distant ou bastion, puis chemin vers le stockage d’objets — pas seul le drapeau pays du marketing. Pour SCP/SFTP, retenez le PoP où (a) tourne votre builder, (b) vit le registre faisant foi ou répliqué, et (c) votre politique de sortie autorise déjà les flux volumineux. Si une jambe diffère, documentez un « saut relais » avec son propre budget de latence au lieu de prétendre que le GeoDNS a aboli la physique.

Partage pratique : les humains peuvent atterrir sur un hôte Halo ; la CI doit appeler des points de terminaison du type artifacts.jp.example qui se résolvent dans le même métro que le runner. Lorsque des équipes Corée et Japon partagent un registre à Singapour par politique, traitez Singapour comme hub de retour conçu et dimensionnez le p95 contre ce hub — pas contre un raccourci Tokyo–Séoul imaginaire sur Internet public.

Connexions concurrentes (éviter l’auto-surcharge)

SCP et SFTP via OpenSSH gèrent mal de nombreux petits fichiers lorsque vous ouvrez des dizaines de sessions parallèles depuis le même hôte CI : chaque session paie des poignées de main et rivalise pour les tampons noyau. Plafonnez les transferts concurrents par runner (souvent 2–4 gros flux, ou un flux plus métadonnées) et augmentez les limites seulement après validation du MaxSessions, du CPU et du disque côté serveur. Sur builders macOS, surveillez syslog pour la pression disque ; sur relais Linux, les retransmissions dans ss.

Si vous comptez sur ControlMaster pour de nombreux petits fichiers, rappelez-vous qu’il optimise l’établissement de session — pas la bande passante transocéanique. Associez-le à une archive (tar avant copie) ou à des deltas façon rsync lorsque la politique le permet, afin que le réglage de concurrence corresponde à de vrais octets sur le fil.

Sommes de contrôle (faire confiance, mais vérifier à l’échelle p95)

À l’échelle multi‑gigaoctet, « copie terminée » sans contrôle cryptographique tient du ticket de loterie. Standardisez un algorithme par pipeline (sha256sum des deux côtés, ou manifestes émis par votre registre) et consignez condensat, taille et durée écoulée sur la même ligne de journal que le nom d’hôte et l’identifiant de région. Pour SFTP automatisé, préférez des manifestes signés par votre chaîne de build aux pipelines shell ad hoc difficiles à rejouer en incident.

Lorsque les sommes divergent, traitez d’abord un incident transport ou stockage, pas une « erreur utilisateur » : capturez les retransmissions TCP sur le relais, comparez les chemins MTU, puis relancez le transfert avec une fenêtre de concurrence plus étroite.

Nouvelles tentatives après échec (backoff exponentiel vs rayon d’explosion)

Les nouvelles tentatives doivent être bornées : backoff exponentiel avec jitter, nombre maximal de passes, disjoncteur lorsque le p95 dépasse le budget pendant quinze minutes. Évitez les boucles serrées de reconnexion vers un bastion partagé — cela ressemble à une attaque et épuise les descripteurs de fichiers pour tout le monde. Pour fichiers partiels, préférez les primitives de reprise déjà exposées par votre chaîne (serveurs SFTP compatibles append, téléchargements HTTP segmentés, API multipart objet) plutôt que supprimer et relancer aveuglément des copies multi-heures.

Journalisez des codes de motif (timeout, reset, digest_mismatch, quota) pour que les post-mortems distinguent oscillations DNS et pertes par congestion sans relancer le transfert.

Fenêtres TCP, sysctl et réglages OpenSSH (avec limites)

Les chemins à fort produit bande-passante × délai nécessitent des fenêtres d’envoi et de réception assez grandes pour que le scaling des fenêtres TCP serve réellement ; sinon le débit reste plat bien en dessous de la capacité de liaison alors que le ping semble acceptable. Le réglage concerne surtout les relais Linux ou registres que vous maîtrisez — pas chaque portable — et toujours sous contrôle de changement.

# ── Relais Linux / bastion que vous administrez (PAS des clients macOS arbitraires) ──
# Limite : hôtes de transfert dédiés uniquement ; mesurer avant/après ;
# revenir en arrière si middleboxes ou pare-feu hérités mal digèrent les grandes fenêtres.
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"

# Client OpenSSH pour gros volumes (par job ou stanza ~/.ssh/config)
# Limite : Compression=yes peut dégrader des artefacts déjà compressés.
scp -o Compression=no -c aes128-gcm@openssh.com -o IPQoS=throughput …

# Extrait serveur OpenSSH (sshd_config) — limite : calibrer MaxStartups après banc de charge
# MaxStartups 10:30:100
# ClientAliveInterval 30

Résumé — achat et provisionnement : choisissez le PoP vpshalo qui aligne à la fois votre plan de contrôle SSH et votre couloir d’artefacts avant d’engager un trimestre de builds sur la mauvaise côte. Validez le p95 sur un objet de référence, figez la politique de sommes de contrôle, câblez les budgets de nouvelles tentatives, puis achetez ou étendez la capacité Mac dans cette même région afin que finance, DNS et octets sur le fil racontent la même histoire. Rejouez la matrice après chaque mouvement majeur de DNS ou de registre.