performance - 什么会延迟 Jenkins 服务器和 SSL SVN 服务器(均无法访问互联网)之间的握手？

Question

我们有一个运行 Jenkins(1.477、1.480.3 和 1.508)的虚拟机(在 VMWare 集群中)来构建提交到我们的 SVN 存储库 (Collabnet SVN 1.7.5-3150.92)。通过 SSL 连接访问存储库。出于安全原因，两台计算机(构建服务器或 SVN 服务器)都无法访问互联网。当 Jenkins 构建开始并开始 SVN 更新时，该作业的控制台会在更新“https://vcfs01.redacted-address.com/svn/MTCM/Trunk”时暂停 30 - 90 秒。更新开始后速度相当快。

为了将 Jenkins 排除在罪魁祸首之外，我通过使用 TortoiseSVN 从构建服务器进行 checkout 重现了同样的问题。同样的延迟发生在 Tortoise 上，一旦文件开始传输，传输速率范围为 50 - 70 KB/s(非常好)。

我们使用 Kaspersky，并将其作为问题排除，因为该问题不会发生在装有 Kaspersky 的程序员 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 服务器可以访问互联网时，在 Tortoise 中握手大约需要 5 秒(与防火墙阻止访问时大约 90 秒相反)。尽管 Tortoise 的握手速度很快，但 Jenkins 的速度与安装防火墙时的速度相同!

我对 Jenkins 做了一些研究(我还将 Jenkins 从版本 1.477 更新到 1.508)并找到了 an article about SVNKit having problems with symbolic links .据我所知，没有使用任何符号链接(symbolic link)。

我在 WireShark 中看到的是 Jenkins 服务器和 SVN 服务器之间存在一些初始事件(创建加密连接)。在初始事件 ~30 秒过去后，会有更多事件(发送应用程序数据)。在应用程序数据之后还有大约 30 秒的延迟，然后发送更多应用程序数据，重置加密连接，并开始更新。

我和网络小组讨论了@Chris 和@Barmar 写的内容，网络小组说:

Our DNS servers already have a reverse 168.192 look up zone and it is populated with quite a few servers. I have rarely ever had to do anything with these zones with the exception of searching for old rogue entries of internal servers.

我认为这意味着这不是查找问题，但我无法理解。这是 Jenkins 机器 (172.25.2.106) 和 SVN 服务器 (172.25.2.106) 之间的过滤捕获，显示了数据包传输之间的暂停:

这两个都是 Win2K8 R2 Datacenter VMware 机器。根据我们的网络组，这些服务器的 DNS 条目/查找已配置并正常工作。

Answer 1

问题:在受防火墙保护的服务器上通过命令行调用 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 更新以检索证书吊销信息(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_CANNOT_CREATE_SESSION。

1. stackoverflow.com/questions/8416989/is-it-possible-to-get-svn-client-debug-output
2. people.apache.org/~brane/svndocs/capi/svn__error__codes_8h.html#ac8784565366c15a28d456c4997963660a044e5248bb3a652768e5eb3105d6f28f
3. code.google.com/archive/p/serf/issues/172

建议的 SVN 更改:

1. 像所有操作一样在命令上启用 Verbosity

2. 将错误 ENUM 名称添加到 stderr

3. 为 Serf 库调试日志记录添加配置标志。