与 KMS 服务器的 ssl 握手需要一些请求事件的时间（50 秒），尽管根据日志，套接字连接超时为 2000

Question

我们使用 AwsCrypto aws java sdk 进行加密和解密。我们遵循此 aws 文档中提到的模式，在启用数据密钥缓存的情况下使用相同的模式。

对于一些请求，我看到间歇性地与 kms 服务器进行 TLS 握手需要时间（根据日志重试建立连接之前最多需要 50 秒），但还有其他类似的请求，其中 TLS 握手正在

ms

内发生。

根据日志，套接字连接超时设置为

2000 ms

，但由于某种原因，连接超时没有发生，并且线程卡在等待握手响应超过 30 秒，最长可达 50 秒。

这是一个更大的问题，因为线程无缘无故被阻塞，并且随着我们的服务规模的扩大，它可能成为瓶颈，我们希望修复这些由于 kms 导致的延迟峰值。

相关日志

*.*.awssdk.http.apache.internal.conn.SdkTlsSocketFactory: Connecting socket to kms.us-east-1.amazonaws.com/52.119.199.83:443 with timeout 2000

2023-12-09T14:26:04.993Z *.*.awssdk.http.apache.*.conn.SdkTlsSocketFactory: Starting handshake

2023-12-09T14:26:35.029Z *.*.awssdk.request: Retryable error detected. Will retry in 43ms. Request attempt number 2

可以看出，握手启动后，连接在重试之前 30 秒内没有中断。但是连接到套接字的超时是

2sec

，从第一个日志可以看出

是否存在某些错误配置导致此问题或其他问题？

我们的服务是基于 ECS 的服务，使用 aws sdk 1.x

PS： 对于那些投票结束的人，请评论为什么应该结束这个问题。如果有可以接受的理由，我很乐意亲自这样做。

Answer 1

基于 POC，我尝试了 diff。与 KMS 客户端相关的超时类型，了解以下内容：

• 在AWS客户端中，连接超时是与服务器主机的初始连接相关的超时。可以理解为客户端向端点发送请求以及与服务器建立连接所花费的时间。可以启动握手过程。但这个超时不包括握手。

• 一旦建立连接，现在套接字超时就会出现，握手时间也受同样的控制。

在我们的例子中，我们没有设置任何值，而是使用默认值 50 秒。一旦我们设置了套接字超时的自定义值，我们就能够摆脱较长的握手时间。

虽然不知道为什么握手需要这么长时间，但根据我的研究，可能存在短暂的网络问题导致握手，最好有自定义套接字超时，以便客户端可以重试并快速失败。