我们有一个运行Jenkins（1.477、1.480.3和1.508）的VM（在VMWare群集中），以为向我们的SVN存储库（Collabnet SVN 1.7.5-3150.92）的提交进行构建。通过SSL连接访问存储库。出于安全原因，计算机（构建服务器或SVN服务器）均无法访问Internet。当Jenkins生成开始SVN更新时，控制台将在更新“ https://vcfs01.redacted-address.com/svn/MTCM/Trunk”时暂停30-90秒。更新开始后，速度相当快。
为了排除詹金斯的罪魁祸首，我使用TortoiseSVN从构建服务器中签出，重现了同样的问题。乌龟也会出现相同的延迟，一旦文件开始传输，传输速率范围为50-70 KB / s（这很好）。
我们使用卡巴斯基，并已将其排除为问题，因为在装有卡巴斯基的程序员PC上不会发生此问题。我们还尝试排除两个服务器，只是为了确保％100。
一段时间以来，我确信这是证书吊销检查的问题，因为我发现WireShark尝试从http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab?dca976bb02bdc2e3进行HTTP GET。使用this KB article中的步骤，我在Jenkins服务器和SVN服务器上都禁用了证书吊销检查（尽管我怀疑后者是否重要）。进行此更改后，我不再尝试连接到Windowsupdate服务器，而是从http://crl.globalsign.com/gs/gsorganizationvalg2.crl看到了HTTP GET。我偶然发现了this article on disabling CRL checking。我在这两个服务器上都遵循了那里的步骤，并且不再看到到外部（互联网）地址的HTTP GET。
[Jenkins服务器可以访问Internet时，在Tortoise中握手大约需要5秒（而防火墙阻止访问时大约需要90秒）。尽管与Tortoise进行了快速握手，但Jenkins的速度与防火墙就位时的速度相同！
我对Jenkins进行了一些研究（我还将Jenkins从1.477版本更新到1.508），并发现了an article about SVNKit having problems with symbolic links。据我所知，没有使用符号链接。
我在WireShark中看到的是Jenkins服务器和SVN服务器之间存在一些初始活动（创建加密连接）。在初始活动之后约30秒过去了，然后还有更多活动（已发送应用程序数据）。在应用程序数据之后，还有大约30秒的延迟，然后发送了更多的应用程序数据，重置了加密的连接，并开始了更新。
我与网络小组讨论了@Chris和@Barmar写的内容，网络小组说：
我们的DNS服务器已经有一个反向168.192查找区域，并在其中填充了 相当多的服务器。我很少需要对这些区域进行任何操作 搜索内部服务器的旧恶意条目除外。
我认为这不是查找问题，但是我在这里头不住了。这是Jenkins机器（172.25.2.106）和SVN服务器（172.25.2.106）之间的过滤捕获，显示了数据包传输之间的暂停：
<< img src =“ https://image.soinside.com/eyJ1cmwiOiAiaHR0cHM6Ly9pLnN0YWNrLmltZ3VyLmNvbS9IZGtMai5qcGcifQ==” alt =“ WireShark Trace”>
这两个都是Win2K8 R2数据中心VMware机器。根据我们的网络小组的信息，这些服务器的DNS条目/查找已配置并正常工作。
问题：在受防火墙保护的服务器上的命令行上调用SVN之后，在15秒钟内什么都看不见，然后程序退出，并出现以下错误：
svn：E170013：无法连接到URL'SVN.REPOSITORY.REDACTED'的存储库”
svn：E730054：运行上下文错误：远程主机强行关闭了现有连接。
调查：互联网对上述错误的研究没有发现任何相关信息。
进程跟踪（procmon）显示在与SVN服务器进行SSL / TLS握手后尝试与Akamai（云服务）服务器建立连接。服务器的主机名未在“进程跟踪”中显示。反向DNS查找显示a184-51-112-88.deploy.static.akamaitechnologies.com或a184-51-112-80.deploy.static.akamaitechnologies.com作为主机名，其IP为184.51.112.88或184.51。 112.80（DNS缓存中有2个条目）。
在与SVN服务器的SSL / TLS握手之后，数据包捕获工具（MMA）显示了与主机名ctldl.windowsupdate.com的连接尝试。
Windows Crypto API试图连接到Windows Update以检索证书吊销信息（CRL –证书吊销列表）。 CRL检索的默认超时为15秒。服务器上的认证超时时间为10秒；因为15大于10，这将失败。
解决方案：互联网研究发现了以下内容：（另请参见底部图片）
解决方案1：减少CRL超时组策略->计算机配置-> Windows设置->安全设置->公钥策略->证书路径验证设置->网络检索-参见下图。
https://subversion.open.collab.net/ds/viewMessage.do?dsForumId=4&dsMessageId=470698
support.microsoft.com/en-us/kb/2625048
blogs.technet.com/b/exchange/archive/2010/05/14/3409948.aspx
解决方案2：为CRL通信打开防火墙
support.microsoft.com/en-us/kb/2677070
解决方案3：SVN命令行标志（未调试）
serverfault.com/questions/716845/tortoise-svn-initial-connect-timeout-备用svn命令行标志解决方案。
其他信息：调试此问题特别困难。 SVN 1.8禁用了对Neon HTTP RA（存储库访问）库的支持，而转而使用了Serf库，后者删除了客户端调试日志记录。 [1]此外，返回的SVN错误代码与svn_error_codes.h中给出的字符串不匹配。[2]此外，SVN错误代码无法轻松地映射回其ENUM标签，在这种情况下，SVN错误代码E170013映射到SVN_ERR_RA_CAN_T_CREATE_SESSION。 >
建议的SVN更改：
像所有操作一样在命令上启用详细程度
将错误的ENUM名称添加到stderr
添加用于Serf库调试日志记录的配置标志。
它看起来仍然是DNS解析问题，证书吊销列表问题或（！）IPv6问题。我无法为您提供分步解决方案，但是以下是要检查的事项列表：
网络组注意到这些机器是VM，尚未安装VMTools。他们现在已经安装了VMTools。刚开始时性能似乎是相同的，但是现在更新需要30秒左右（仍然比Tortoise差，但比最初要好）。