#git #networking
Вопрос:
Справочная информация:
- Наша компания имеет коммерческую связь на 100 Мб между офисом в Китае и США в качестве интрасети, а задержка составляет 150 мс при stdev 0,2 мс. потеря 0%.
- Сервер git расположен в США, а разработчики находятся как в Китае, так и в США.
- Когда разработчики в США клонируют репо выше 100 Мбит/с, поэтому производительность сервера git не должна быть проблемой.
Разработчики в Китае, которые используют ту же команду, могут достигать только 0,5~2 Мбит/с, когда ссылка занята, и 3~6 Мбит/с в выходные или нерабочие часы.
Случайно мы обнаружили, что если клон использует https вместо ssh, скорость составит 11 Мбит/с. И если настроить HTTP-прокси в США на любом сервере или рабочей станции и добавить следующее в файл .ssh/config разработчиков CN, скорость клонирования ssh также будет постоянной 11 МБ/с.
Host *
User git
ProxyCommand nc -x proxy.intranet.com 8080 -Xconnect %h %p
Конфигурация кальмара очень проста,
acl GOOD dstdomain git.intranet.com
http_access allow GOOD
http_access deny all
http_port 8080
dns_nameservers 10.10.10.10
Я также попытался включить Linux BBR на тестовом сервере Git в США, но ничего не изменилось, я настроил сервер squid в Китае и позволил клону git пройти через этот сервер squid, но ничего не улучшилось. Это должен быть сервер squid, расположенный в интрасети США, независимо от того, в IDC или просто обычный ноутбук.
Я очень смущен причиной и задаюсь вопросом, есть ли способ правильно решить эту проблему вместо использования кальмара в качестве обходного пути.
*Я не могу добавить скриншот напрямую из-за низкой репутации, пожалуйста, проверьте изображение здесь примерная топология
Комментарии:
1. Вы могли бы получить лучшие ответы на serverfault.com/help/on-topic
2. Я нацелил близкую рекомендацию на суперпользователя, но serverfault, вероятно, лучше. Если бы я пытался это отладить, я бы хотел наблюдать за пакетами и метками времени, когда они входят и выходят с серверов в Китае, а также входят и выходят с серверов в США. Очевидное предположение состоит в том, что Китай замедляет трафик ssh (порт 22) по каким-либо причинам, связанным с национальными интересами, которые у них могут быть. (Например, они могут записывать все данные на диск.)
3. (Это было бы легко проверить: настройте дополнительный ssh-сервер на другом порту и попробуйте это. Если скорость движения подскочит, у вас будет что-то настолько близкое, насколько вы сможете подобраться к дымящемуся пистолету. Хотя они могли переключаться на что-то другое, кроме порта.)
4. просто попытался добавить порты 222 и 12345 в sshd_config, и scp из этих новых портов не увеличивает скорость. если есть дроссель, он, вероятно, не основан на портах, может быть основан на протоколе, но не уверен, есть ли способ его опробовать.
5. Хорошо, очень интересно, я использовал инструмент под названием «obfs4proxy» и «proxychains» для запуска ssh под запутанными SOCKS5, скорость значительно улучшилась, как и при использовании Squid. Я думаю, что ваша догадка верна, я свяжусь с нашими ИТ-специалистами и посмотрю, есть ли что-нибудь в нашей сети.