首屏摘要：三類「假慢」與你要先量的數
跨洲推 iOS 歸檔或素材到遠程 Mac時常見「千兆出口卻只有個位數 MB/s」：單連接受 RTT 與窗口限制；SSH/SFTP佔 CPU；rsync 掃描可能觸發中間盒空閒掐斷。
本文給Runbook 判別順序：單流 SFTP 與 iperf3 對齊期望，再選並行、rsync 策略或路徑優化。吞吐優化不犧牲發佈語義：字節進releases 暫存，校驗後切current（《原子發佈》）；SHA256 閘門見《傳輸完整性》。
交互式拖拽與 CI 無人值守要共享會話預算：MaxSessions 與客戶端並行度須對齊，見《併發 SFTP》；多後端鏡像與 rclone 邊界見《rclone 決策矩陣》。
痛點拆解：為什麼「單流 SFTP」和「rsync 首階段」最容易背鍋
痛點 1：把「標稱帶寬」當成「單連接應得帶寬」。在跨太平洋或跨洲鏈路上，RTT 常常落在 150ms 到 250ms 區間，甚至更高。此時即便物理層能跑數百 Mbps，單條 TCP 連接也可能因為擁塞控制與窗口演化而在長時間尺度上呈現「穩定的中等吞吐」。這不是供應商「縮水」，而是時延帶寬積的基本算術。工程上要麼接受多路並行（注意與服務器會話上限對齊），要麼在可控範圍內優化路徑（更近區域、更乾淨跳板、減少層層 NAT）。
痛點 2：rsync 掃描階段掉線。極大單文件或海量小文件會先耗在元數據/校驗；中間盒可能掐「長時間少 payload」的 SSH。拆目錄、評估 whole-file、調保活，並把階段耗時打進 CI 日誌。
痛點 3：壓縮/加密。已壓縮產物再開壓縮常被 CPU 綁死；文本日誌類可 A/B。按內容熵固化團隊配方。
痛點 4：破壞發佈語義。禁止 in-place 覆蓋對外目錄；並行只打不同 build_id 前綴。短期密鑰生命週期與並行 job 對齊（《CI/CD 憑據》）。
決策矩陣：何時加並行、何時改 rsync 策略、何時回到架構
評審時把結論記在工單：單流基線 Mbps、RTT、計劃並行度、賬號會話預算、目標目錄是否為 releases 暫存區、是否與 SHA256 清單閘門綁定。
| 觀測現象 | 優先假設 | 推薦動作 | 與站內文檔銜接 |
|---|---|---|---|
| 單流 SFTP 與 iperf3 單流 TCP 接近 | 窗口/RTT 限制 | 多路並行或更近區域；檢查 CPU 是否打滿 | 併發 SFTP、rclone 多連接 |
| 僅 rsync 在首階段掉線 | 空閒會話被掐 | 調保活；拆目錄；評估 whole-file；降校驗強度（在風險可控前提下） | 傳輸完整性、原子發佈 |
| 局域網極快、跨 WAN 極慢 | 路徑與隊列 | 檢查跳板、運營商 QoS、是否誤走代理 | ProxyJump 單入口文 |
| 並行一加就斷 | sshd 會話或速率限制 | 下調並行度；拆分賬號；排隊 | 併發 SFTP |
| 傳完但業務不敢發版 | 完整性未閘門 | 獨立校驗文件；禁止以退出碼替代位級一致 | 傳輸完整性 |
矩陣核心：快與對分門禁；目錄與帳號邊界先畫清
實操步驟：從基線測量到與發佈閘門銜接（How-to）
在測試前綴目錄演練；生產寫入僅指向 releases/<build_id>/；不要把探測腳本指向 current。
# 步驟 1：記錄 RTT 與單流基線（示例：替換為你的主機）
ping -c 20 your-remote-mac.example
# 步驟 2：OpenSSH 客戶端保活（~/.ssh/config 片段）
Host remote-mac-prod
HostName your-remote-mac.example
User ci_upload
ServerAliveInterval 60
ServerAliveCountMax 3
# 步驟 3：sshd 側（需權限）與組織策略對齊示例
# ClientAliveInterval 60
# ClientAliveCountMax 3
# 步驟 4：rsync 長傳示例（按內容調整校驗策略）
rsync -av --partial --inplace ./build/ remote-mac-prod:uploads/staging/build-123/
# 步驟 5：若單流明顯低於 iperf3 單流，嘗試拆分大文件為多個並行任務（不同目標前綴）
# 步驟 6：校驗通過後再執行原子切換（見《原子發佈》腳本與 runbook）
# 步驟 7：日誌字段：握手耗時、首字節、平均吞吐、重試、退出碼 —— 寫入 CI 摘要
上述命令是教學骨架，生產環境必須把密鑰來源、sudo 邊界與日誌脫敏寫成清單，並與《CI/CD 憑據》一致。
可引用數據與參數基線（便於寫進評審表）
經驗抓手（非 SLA）：RTT >150ms 且單流長期低於標稱 30% 時先查窗口/並行而非磁盤；並行從 2~4 檔試起並記錄 sshd CPU；ServerAliveInterval=60 常作長傳起點；已壓縮產物關壓縮層常見 1.3~2.1× 表觀提升；發佈仍靠獨立 SHA256 清單，勿以工具校驗替代業務閘門。
基線寫入 Runbook 可減少「只換客戶端」的無效嘗試；多入口維護成本高時，託管遠程 Mac收斂會話與隔離更省總成本。rclone 鏡像須與發佈目錄分賬號，見《rclone 決策矩陣》。
FAQ、站內互鏈與為何考慮託管遠程 Mac
單流慢是否一定要換 UDP 類方案？
不一定。多數構建產物鏈路仍終止在 SSH/SFTP 生態內；UDP 類加速往往引入新的合規與防火牆問題。優先把單流基線、並行與會話預算算清楚，再評估是否值得引入新協議面。
並行上傳會打亂文件順序嗎？
字節層面各任務獨立；業務層面只要你堅持「只向 build_id 暫存區寫入，校驗後切換」，就不會出現用戶讀到半套目錄的問題。避免多任務寫同一前綴。
Mac 客戶端需要特別調 sysctl 嗎？
極端案例可調 TCP delayed ack，須走變更流程；優先並行與工具策略。
總結：遠程 Mac 大文件上傳的「跑不滿」多數是單流語義、RTT 與工具階段成本的綜合結果；用基線測量與決策矩陣拆分問題，再用並行與保活落地，同時堅持暫存—校驗—切換的發佈語義。
侷限：自建多入口與多租戶調優會持續消耗高級工程師時間；SFTPMAC 提供的託管遠程 Mac把隔離、入口與會話策略打包成可消費的服務，讓你把精力放在產物質量與發佈節奏，而不是深夜排查「為什麼又卡在 rsync 第一階段」。
若希望用統一遠程 Mac 入口承載 CI 上傳、團隊交付與穩定會話策略，可瞭解 SFTPMAC 套餐與區域節點說明。