Vert.x HttpClient调用后端服务时使用Idle Timeout和KeepAlive Timeout的行
实在网上有大量讨论HTTP长连接的文章，而且Idle Timeout和KeepAlive Timeout都是HTTP协议上的事情，跟Vert.x本身没有太大关系，只不过最近在项目上遇到了一些问题，用到了Vert.x的HttpClient，就干脆总结一下，留给自己以后做参考。在使用Vert.x的HttpClient的时候，可以使用HttpClientOptions配置KeepAlive Timeout以及Idle Timeout的行为，本文将讨论在Vert.x HttpClient中Idle Timeout的设置、如何启用和禁用KeepAlive，以及假如启用KeepAlive，其超时设置（Timeout）对HTTP连接保活的影响。
需要注意的是，这是客户端的设置，服务端由于实现技能多样，这里不深入讨论，本文默认服务端已经开启了KeepAlive（事实上也是大多数HTTP服务器的默认行为）。
本文讨论的场景仅适用HTTP/1.1的环境，HTTP/1.0处理KeepAlive方式略有不同，HTTP/1.1默认支持KeepAlive，HTTP/1.0需要显式在header里参加Connection: keep-alive。
场景演练
这里我们设定多个场景来测试不同环境下，整个体系的行为表现是什么。
场景一：HttpClient禁用 KeepAlive
HttpClientOptions里使用setKeepAlive(false)来禁用KeepAlive：
final HttpClientOptions options = new HttpClientOptions()
.setKeepAlive(false);此时，Vert.x Http Client会在请求头中参加connection: close，表现在完成一次HTTP request/response的流程后，服务端需要主动发起关闭连接请求：
https://img2024.cnblogs.com/blog/119825/202409/119825-20240912133108166-1802187689.png
Wireshark抓包分析：
https://img2024.cnblogs.com/blog/119825/202409/119825-20240912133255668-491358607.png
[*]Vert.x HttpClient使用60489端口与服务端建立连接（SYN），服务端以（SYN, ACK）数据包回应，同意建立连接
[*]Vert.x HttpClient向服务端发送HTTP请求，服务端处理请求并返回
[*]由于Vert.x HttpClient在发出HTTP请求时，使用了connection: close，所以服务端主动发起（FIN, ACK）数据包，表现服务端已关闭连接，客户端得到数据包后，返回ACK表现确认，然后也向服务端发出（FIN, ACK），表现客户端也关闭了连接，末了服务端返回ACK，表现确认
场景二：HttpClient启用KeepAlive
HttpClientOptions里使用setKeepAlive(false)来禁用KeepAlive：
final HttpClientOptions options = new HttpClientOptions()
.setKeepAliveTimeout(15)
.setKeepAlive(true); 此时，Vert.x Http Client并不会发送connection: close头，因为HTTP/1.1默认使用长连接，所以无需额外指定任何请求头。在KeepAlive超时后，会由客户端主动关闭HTTP连接。
Wireshark抓包分析：
https://img2024.cnblogs.com/blog/119825/202409/119825-20240912135315857-726600788.png
[*]Vert.x HttpClient使用60937端口与服务端建立连接（SYN），服务端以（SYN, ACK）数据包回应，同意建立连接
[*]Vert.x HttpClient向服务端发送HTTP请求，服务端处理请求并返回
[*]Vert.x HttpClient在等待了约莫15秒以后（上面代码中setKeepAliveTimeout设置的15秒），由于没有新的HTTP请求需要占用连接，于是就向服务端发起（FIN, ACK）数据包，表现客户端已关闭连接，服务端得到数据包后，返回ACK表现确认，然后也向客户端发出（FIN, ACK），表现服务端也关闭了连接，末了客户端返回ACK，表现确认
假如服务端的KeepAlive Timeout大于HttpClient的KeepAlive Timeout，那么当一段时间内没有任何HTTP请求发出，在HttpClient KeepAlive首先超时前，HTTP连接可以一直被重用，直到HttpClient KeepAlive超时，由客户端发起关闭连接请求：
https://img2024.cnblogs.com/blog/119825/202409/119825-20240912143717847-1346925506.png
[*]可以看到，客户端端口63094的连接在多次HTTP请求中一直被重用
[*]15秒内，没有新的HTTP请求，客户端主动发起断开连接数据包
假如服务端的KeepAlive Timeout小于HttpClient的KeepAlive Timeout（比如服务端KeepAlive Timeout为10s），那么当一段时间内没有任何HTTP请求发出，服务端会首先发起关闭连接请求：
https://img2024.cnblogs.com/blog/119825/202409/119825-20240912150304970-2122716959.png
[*]Vert.x HttpClient使用64282端口与服务端建立连接（SYN），服务端以（SYN, ACK）数据包回应，同意建立连接
[*]在多次HTTP请求过程中，HTTP连接被重用
[*]10秒过后，服务端首先发起关闭连接请求
[*]之后客户端再次发出HTTP请求，会重新新建一个HTTP连接
场景三：HttpClient同时使用Idle Timeout和KeepAlive Timeout
为了模仿这样的场景，在创建Vert.x HttpClient时，使用如下HttpClientOptions：
final HttpClientOptions options = new HttpClientOptions()
.setIdleTimeout(5)
.setIdleTimeoutUnit(TimeUnit.SECONDS)
.setKeepAliveTimeout(20)
.setKeepAlive(true);然后让服务端在返回HTTP Response的时候，先等待7秒钟：
public async Task<IEnumerable<WeatherForecast>> Get()
{
await Task.Delay(7000);
return Enumerable.Range(1, 5).Select(index => new WeatherForecast
{
Date = DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
TemperatureC = Random.Shared.Next(-20, 55),
Summary = Summaries
})
.ToArray();
}Wireshark抓包分析：
https://img2024.cnblogs.com/blog/119825/202409/119825-20240912151718878-790092059.png
[*]建立连接
[*]发送请求，服务器开始处理请求，需要7秒才能处理完
[*]5秒后，客户端Idle Timeout了，等不起，就向服务端发起关闭连接，服务端相应关闭连接
[*]下一次请求，需建立新的连接
因此，可以这样理解这两个设置：
[*]短的 Idle Timeout 和长的 KeepAlive Timeout: 假如 IdleTimeout 设置得比较短，而 KeepAliveTimeout 设置得比较长，连接会因为空闲超时（Idle Timeout）而关闭。因此，当新的 HTTP 请求到来时，需要建立新的连接。
[*]长的 Idle Timeout 和短的 KeepAlive Timeout: 假如 IdleTimeout 设置得比较长，而 KeepAliveTimeout 设置得比较短，在 Keep-Alive 有效时间内，纵然当前连接上有请求在等待相应，该连接仍然可以接收新的 HTTP 请求，直到 Keep-Alive 超时触发。
[*]假如某个HTTP请求在某个HTTP连接上等待服务端返回，那么这个HTTP连接仍然处于生动状态，此时并不会触发KeepAlive的倒计时
在vert.x中，RequestOptions也有类似的setIdleTimeout的方法来设置Idle Timeout，但它的作用域仅限于当前的HTTP请求，而HttpClientOptions.setIdleTimeout作用域为整个应用程序全局。
场景四：在服务端KeepAlive即将到期的时候发送HTTP请求
仍然使用上面【场景二】的环境设定，只是让客户端每隔KeepAlive Timeout相同时间发送一次请求，会发现，多数环境下，请求可以成功，但偶然候会发生错误。比如，假如服务端KeepAlive Timeout为10秒，客户端也是每隔10秒发送请求：
https://img2024.cnblogs.com/blog/119825/202409/119825-20240912153548882-1474178113.png
[*]建立连接，并发送HTTP请求，服务端正常相应
[*]10秒后，客户端再次发出请求，服务端ACK了请求，但与此同时，服务端KeepAlive超时，于是就向客户端发送（RST, ACK）数据包用于复位连接（异常关闭连接），此时客户端就会报错：io.vertx.core.net.impl.ConnectionBase SEVERE: Connection reset
总结
[*]一个HTTP连接是否可以或许重用，同时取决于客户端和服务端的KeepAlive行为
[*]服务端通常是默认开启KeepAlive的，它也有一个默认值（不同服务端实现不一样）
[*]客户端可以选择是否启用HTTP连接重用（启用大概禁用KeepAlive）
[*]在HTTP/1.0中，启用时需要在Request Header中参加Connection: keep-alive，默认禁用
[*]在HTTP/1.1中，禁用时，需要在Request Header中参加Connection: close，默认启用
[*]假如客户端禁用，则HTTP连接不会重用，每次请求都会创建新的HTTP连接
[*]假如客户端启用，并且客户端KeepAlive Timeout（ckt）小于服务端KeepAlive Timeout（skt），那么在min(ckt, skt)时间段内假如没有新的HTTP请求，并且HTTP连接处于空闲状态，客户端会发起HTTP连接关闭
[*]假如客户端启用，并且客户端KeepAlive Timeout（ckt）大于服务端KeepAlive Timeout（skt），那么在min(ckt, skt)时间段内假如没有新的HTTP请求，并且HTTP连接处于空闲状态，服务端会发起HTTP连接关闭
[*]当一个HTTP请求发送到服务端后，服务端需要一定时间处理，Vert.x HTTP Client设置Idle Timeout，可以使恰当服务端在一定时间内没有相应时，客户端可以主动关闭HTTP连接。在客户端由于Idle Timeout而关闭连接之前，该HTTP请求仍在等待服务端的返回，此时承载该HTTP请求的HTTP连接仍可继续接受其它的HTTP请求
[*]当服务端需要一定时间处理HTTP请求时，假如这个处理时间恰好与服务端KeepAlive Timeout相当，是有可能出现HTTP连接被异常关闭导致客户端报错的环境的。常见办理办法：
[*]尽量避免在服务端KeepAlive超时时发出请求（根据现实环境调整KeepAlive参数大概定制HTTP请求发起策略）
[*]重试机制
[*]确保客户端和服务端超时设置合理，根据现实环境进行调整
KeepAlive Timeout和Idle Timeout的关系
两者是独立的设置，但在某些环境下可能会产生交互。比方，假如 IdleTimeout 设置的时间比 KeepAliveTimeout 短，那么连接可能会因为空闲超时而关闭，纵然 Keep-Alive 允许更长时间的连接复用。
最佳实践（参考自ChatGPT）
[*]根据应用需求调整:
[*]假如应用程序需要频仍复用连接，可以设置较长的 KeepAliveTimeout。
[*]假如需要防止连接长时间空闲占用资源，可以设置较短的 IdleTimeout。
[*]平衡性能和资源:
[*]设置 IdleTimeout 时，确保它足够长以完成请求处理，但不要过长以免浪费资源。
[*]设置 KeepAliveTimeout 时，确保它可以或许有效地复用连接以提高性能。
[*]测试和监控:
[*]在现实应用中，监控连接的使用环境，并根据性能和资源使用环境调整这些超时设置。
通过合理设置这两个超时值，可以优化连接的使用效率，同时避免不必要的资源占用。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]