主要观点：

• 最初在使用git-lfs上传 500MB 二进制资产时，发现通过 wifi 上传速度仅 50KB/s，而连接以太网后瞬间提升至 2.5MB/s，经调查发现 wifi 2Ghz 频段干扰严重，5Ghz 频段也有少许干扰，且路由器配置有误导致 5Ghz 客户端连接问题，修复后内网速度达 600MB/s 且外网吞吐量与有线相当。
• 深入研究发现git-lfs即使在 5Ghz 网络下也很慢，通过 Wireshark 观察到约 30 - 50%的流量出现乱序/重复 ACK 导致重传，推测是网络中随机 50 - 100ms 延迟所致，且git-lfs发送的数据包为约 50 字节有效载荷（约 100 字节总大小，MTU 为 1500），这与 Nagle 算法预期不符，推测是TCP_NODELAY未设置导致。
• 介绍了 Nagle 算法的由来及作用，以及 Go 语言中默认关闭TCP_NODELAY的情况，认为这是个“讨厌的技巧”，可能会导致网络负载增加、重传增多等问题，希望了解其默认设置的原因。
• 此默认设置在 Go 生态系统中影响广泛，如 Caddy 性能不佳，Kubernetes 情况未知，git-lfs也受其影响，作者希望git-lfs能修复此问题并已开 issue。
• 总结在大多数情况下不应启用TCP_NODELAY，除非明确知道网络情况并管理自己的缓冲区，否则应关闭TCP_NODELAY让 Nagle 算法处理。

关键信息：

• git-lfs上传速度在不同网络环境下差异大。
• wifi 网络存在干扰问题。
• git-lfs传输中出现大量重传。
• Go 语言中TCP_NODELAY默认关闭。
• 此默认设置对 Go 生态系统有广泛影响。

重要细节：

• 速度测试结果显示 wifi 上传速度 40MB/s，有线 60MB/s。
• 发现网络中存在随机 50 - 100ms 延迟。
• Go 中net.Dial默认关闭TCP_NODELAY及相关原因。
• 此默认设置对 Caddy 和git-lfs的具体影响及作者的行动。