IT Share you

어떤 프로토콜?

shareyou 2020. 12. 8. 20:23
반응형

어떤 프로토콜? svn : // 또는 http (s) : //?


SVN의 네트워크 액세스를위한 4 가지 공통 프로토콜이 있습니다.

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

Wikipedia 페이지는 네 가지 프로토콜의 차이점에 대해 많이 설명하지 않습니다. svn://설정하기가 가장 쉬우므로 항상 선호 했지만 차이점은 무엇이며 어떤 것이 "더 나은"것입니까?


http://심각한 수천 개의 작은 파일을 처리 특히, 오버 헤드를. 나는 약 50,000 개의 아이콘이있는 웹 사이트에 svn을 사용했는데, 모두 SVN에 저장되었습니다. HTTP를 사용하면 결제하는 데 약 20 분이 걸렸습니다. 로 전환 svn://한 후 1 분도 채 걸리지 않았습니다. HTTP에서는 파일 당 하나의 새 HTTP 요청이기 때문입니다.

http://그러나 다음과 같은 큰 이점이 있습니다. 일반적으로 방화벽을 통과합니다. 예를 들어, 이제 svn://방화벽으로 인해 대학에서 더 이상 내 저장소에 액세스 할 수 없음으로 전환했습니다 .

SSL / TLS 사용 여부의 차이점은 분명합니다. 데이터는 암호화됩니다. 그러나 설정하기가 더 어렵습니다.


svn+sshsvnSSH 터널 내에서 실행 되는 프로토콜입니다. 클라이언트는 SSH를 사용하여 원격 서버에 로그온하고 해당 터널에서 svn 명령을 원격으로 실행합니다. 내 생각에는 svn+ssh이미 SSH 서버가 실행 중이라고 가정하고 해당 시스템에서 시작할 서버가 없기 때문에 먼 시스템에서 Subversion 저장소를 사용하는 가장 쉬운 방법입니다.

또한 svn+sshSSH의 암호화 보호의 이점도 있습니다. svn신뢰할 수없는 네트워크 에서는 원시 프로토콜을 사용하지 마십시오 .

의 주요 문제 svn+ssh는 원격 컴퓨터에서 셸 액세스가 필요하다는 것입니다. 다른 사람에게 전체 쉘 계정에 대한 액세스 권한을주지 않고 저장소에 대한 액세스 권한을 제공하는 것은 어렵습니다. 이를 위해 HTTP 기반 방법 중 하나를 원합니다. 즉, http또는 https(가급적 https이면 암호화 및 인증 계층 때문에). 이러한 방법은 구성하기가 더 복잡하지만 (예 : Apache와 같은 HTTP / HTTPS 서버가 필요함) 저장소 관리자가 저장소 액세스 권한을 신중하고 정확하게 제어 할 수 있도록합니다.


https://svn+ssh://암호화 등 같은 당신의 SVN 암호로 보안 데이터를 (전송 더 안전합니다.

힘내 같은 그것의 아무것도, 경우 svn+ssh://보다 빠른 것 https://svn://보다 빠른 것입니다 http://.


또한 http : // (Apache + SVN)를 사용하는 경우 mod_auth_sspi 모듈을 추가하여 Windows 인증을 사용하여 사용자가 로그인하도록 할 수 있습니다.

여기를 참조하십시오 : http://blog.pengoworks.com/index.cfm/2007/11/1/Configuring-Windows-Authentication-with-Apache-22x-and-Subversion

따라서 (Windows) 개발자는 한 명의 사용자 / 암호 만 기억하면됩니다.


Subversion 리포지토리에 액세스 할 때 일반 HTTP 또는 보안 HTTPS보다 훨씬 더 나은 성능과 속도를 제공 한다고 말 svn://하거나 svn+ssh://제공 할 수 있지만 오늘날에는 그렇지 않습니다. 동안 svn://이나 svn+ssh://빠른 HTTP (S)보다가 SVN 1.6 또는 이전 버전되면서 그 차이는 크지 않다.

HTTP (S) 및 최신 Subversion 1.7+ 클라이언트 및 서버 에는 주요 성능 문제 없습니다 .

Subversion 1.7을 사용한 HTTP (S) 액세스는 HTTPv2 덕분에 특히 대기 시간이 긴 네트워크 연결에서 훨씬 더 성능이 향상되었습니다 (HTTP / 2와 혼동하지 마십시오!) . 서브 버전 1.8로 전환 libneon하는 libserfHTTP (S) 액세스를 위해 그리고 libserf보다 더 나은 성능을 제공합니다 libneon.

HTTP (S) 또는 HTTP (S)를 통해 작동하는 Subversion의 성능과 관련이 있다고 생각하는 문제가있는 경우 네트워크에 HTTP (S)를 느리게 만드는 서비스가 있는지 조사해야합니다. 근본 원인은 바이러스 백신, 활성 방화벽 또는 프록시 일 수 있습니다. 잘못 구성된 네트워크 설정은 말할 것도 없습니다. 그리고 최신 Subversion 클라이언트와 서버를 사용하는 것을 잊지 마십시오!

네트워크 구성 오류의 예를 생각하면 Windows Update 사이트 ( http://ctldl.windowsupdate.com/ )에 액세스 할 수없는 연결이 끊긴 네트워크에서 작동하는 클라이언트 컴퓨터에 영향을주는 매우 일반적인 문제가있는 것 같습니다 . 이는 광범위한 시스템 서비스에 영향을 미치는 중요한 문제이지만 최종 사용자는 HTTPS를 통해 Subversion 클라이언트를 사용할 때이를인지하고보고합니다. 문제는 성능과 관련된 것처럼 보이지만 그렇지 않습니다. 자세한 내용은이 StackOverflow 스레드를 읽으십시오 : https://stackoverflow.com/a/38499619/761095 .


http그리고 https당신이 당신의 저장소에 대한 액세스를 제한에 (htaccess로를 통해 구성) HTTP 기반 인증을 사용할 수 있도록), 서브 버전 지원을위한 웹 서버 모듈에 의해 처리됩니다.

참고 URL : https://stackoverflow.com/questions/2140954/which-protocol-svn-or-https

반응형