Какой протокол? svn: / / или http (s)://?



существует четыре общих протокола для доступа к сети SVN.



svn://repos
svn+ssh://repos
https://repos
http://repos


страница в Википедии, не говорит много о различиях четырех различных протоколов. Я всегда предпочитал svn://, потому что это простой в настройке, но в чем разница и какой из них "лучше"?

746   6  

6 ответов:

http:// есть серьезные накладные расходы, особенно при работе с тысячами небольших файлов. Я использовал svn для веб-сайта, который имел около 50 000 значков, все сохраненные в SVN. С HTTP, это заняло около 20 минут, чтобы проверить. Как только я переключился на svn://, это заняло меньше минуты. Это связано с тем, что с HTTP это один новый HTTP-запрос на файл.

http:// однако имеет следующее большое преимущество: он обычно проходит через брандмауэры. Например, теперь, когда я переключился на svn:// Я больше не могу получить доступ к моему репозиторию из моего университета из-за их брандмауэра.

что касается разницы между использованием SSL/TLS или нет, ну, это очевидно: данные зашифрованы; однако это сложнее настроить.

svn+ssh - Это svn протокол выполняется внутри туннеля SSH. Клиент использует SSH для входа на удаленный сервер и удаленно запускает команду svn в этом туннеле. На мой взгляд, svn+ssh Это самый простой способ использовать репозиторий subversion в удаленной системе, потому что у вас нет сервера для запуска в этой системе, предполагая, что у вас уже есть сервер SSH.

и svn+ssh преимущества криптографической защиты SSH. Не используйте raw svn протокол за ненадежные сети.

главная проблема svn+ssh Это то, что он требует доступа оболочки на удаленной машине. Трудно предложить кого-то доступ к репозиторию, не давая ему доступ ко всей учетной записи. Для этого вам нужен один из методов на основе HTTP, т. е. http или https (предпочтительно https из-за уровня шифрования и аутентификации). Эти методы более сложны в настройке (вам нужен сервер HTTP / HTTPS, например Apache), но позволяют администратор репозитория тщательно и точно контролирует права доступа к репозиторию.

https:// и svn+ssh:// зашифрованы и поэтому безопаснее для передачи защищенных данных (например, ваш пароль SVN.

если это что-то вроде Git, svn+ssh:// будет быстрее, чем https:// и svn:// будет быстрее, чем http://.

кроме того, если вы используете http:// (Apache + SVN), то вы можете заставить своих пользователей войти в систему с помощью проверки подлинности Windows с добавлением модуля mod_auth_sspi.

смотрите здесь: http://blog.pengoworks.com/index.cfm/2007/11/1/Configuring-Windows-Authentication-with-Apache-22x-and-Subversion

поэтому ваши (windows) разработчики должны помнить только одного пользователя / пароль

http и https обрабатываются модулем веб-сервера для поддержки Subversion, поэтому вы можете использовать аутентификацию на основе HTTP (настроенную через .htaccess) для ограничения доступа к вашему репозиторию).

можно сказать, что svn:// или svn+ssh:// обеспечивают гораздо лучшую производительность и скорость, чем простой HTTP или безопасный HTTPS при доступе к репозиториям Subversion, но это не так в настоящее время. В то время как svn:// или svn+ssh:// быстрее, чем HTTP(S), разница не так велика, как это было с SVN 1.6 или более старыми версиями.

здесь нет основные проблемы производительности с HTTP (S) и актуальными клиентами Subversion 1.7+ и сервера.

HTTP (S) доступ с Subversion 1.7 стал намного более производительным и особенно на сетевых подключениях с высокой задержкой благодаря HTTPv2(не путайте с HTTP / 2!). Subversion 1.8 переключено с libneon до libserf для доступа HTTP (S) и libserf обеспечивает лучшую производительность, чем libneon.

если есть какая-то проблема, которая, как вы думаете, связана с производительностью HTTP (S) или Subversion работает над HTTP (S), Вы должны исследовать, есть ли какие-либо службы в вашей сети, которые делают HTTP(S) медленным. Основной причиной может быть антивирус, межсетевой экран или прокси-сервер. Не говоря уже о неверно настроенных сетевых настройках. И не забывайте использовать современные клиенты и серверы Subversion!

думая о примере неправильной конфигурации сети, кажется, что существует довольно распространенная проблема, которая влияет на клиентские компьютеры, работающие в отключенных сетях, которые не имеют доступа к Центру обновления Windows сайт (http://ctldl.windowsupdate.com/). Это критическая проблема, которая затрагивает широкий спектр системных служб, но конечные пользователи замечают и сообщают об этом при использовании клиентов Subversion через HTTPS. Проблема, похоже, связана с производительностью, но это не так. Прочитайте этот поток StackOverflow для получения дополнительной информации:https://stackoverflow.com/a/38499619/761095.

Comments

    Ничего не найдено.