Performance: after TCP connection timeout on nodejs response gets delayed by 1000 ms #120

New Issue

fergalmoran · 2025-08-09T17:15:05Z

fergalmoran commented

2025-08-09 17:15:05 +00:00

Originally created by @CoolerIV on 3/22/2018

Setup

Node V6.12.3
.NET Core MVC (.NET Core 2.0; JavaScriptServices 2.0.1)
React w/ MobX
Win10

While testing our software, we started observing that after 120 seconds of inactivity since last request, next response time increases by 1000ms. Upgraded node version to latest LTS which is 8.x, and it became even worse: it was reproducible each 5 seconds of inactivity.
This delay is not affected by SPA framework used - tested it with angular 5.x, and it is exactly the same.
Also as a matter of fact delay entirely depends of which client is being used (in this case it's http client of net core - 1000ms; postman adds - 500ms etc).

Findings

Problem arises when .net core process tries to do a http post on http://localhost:port to a http server running on nodejs listening on IPv4 address resolved out of localhost. As long as localhost loopback address in nodejs is resolved to IPv4 format (127.0.0.1) and network configuration preferes IPv6 (::1), each time .net core process has to resolve localhost to do a http post to nodejs, it results in IPv6. It fails to reach nodejs listening on IPv4 and after 1000ms of timeout it falls back to IPv4 version, succeeds and we have extra 1000ms added to this response time.

Summary:

nodejs httpserver listens on 127.0.0.1:port
http client (.net core process) tries to do a http post on IPv6 loopback address (::1)
after 1000ms connection timeouts using ::1, then it falls back on 127.0.0.1 and succeeds
result -> additional 1000ms on that request

Solution would be quite simple: once starting nodejs process .net core side should listen not only to port printed to stdout stream, but also to a resolved address when starting server on localhost. Then .netcore side should do a http post not to a localhost:port but to resolved ip:port.

Tested this configuration, works quite fine. I can do a PR for this, if it looks feasible for you guys.

*Originally created by @CoolerIV on 3/22/2018* **Setup** * Node V6.12.3 * .NET Core MVC (.NET Core 2.0; JavaScriptServices 2.0.1) * React w/ MobX * Win10 While testing our software, we started observing that after 120 seconds of inactivity since last request, next response time increases by 1000ms. Upgraded node version to latest LTS which is 8.x, and it became even worse: it was reproducible each 5 seconds of inactivity. This delay is not affected by SPA framework used - tested it with angular 5.x, and it is exactly the same. Also as a matter of fact delay entirely depends of which client is being used (in this case it's http client of net core - 1000ms; postman adds - 500ms etc). **Findings** Problem arises when .net core process tries to do a http post on `http://localhost:port` to a http server running on nodejs listening on IPv4 address resolved out of `localhost`. As long as localhost loopback address in nodejs is resolved to IPv4 format (127.0.0.1) and network configuration preferes IPv6 (::1), each time .net core process has to resolve `localhost` to do a http post to nodejs, it results in IPv6. It fails to reach nodejs listening on IPv4 and after 1000ms of timeout it falls back to IPv4 version, succeeds and we have extra 1000ms added to this response time. **Summary:** * nodejs httpserver listens on 127.0.0.1:port * http client (.net core process) tries to do a http post on IPv6 loopback address (::1) * after 1000ms connection timeouts using ::1, then it falls back on 127.0.0.1 and succeeds * result -> additional 1000ms on that request Solution would be quite simple: once starting nodejs process .net core side should listen not only to port printed to stdout stream, but also to a resolved address when starting server on `localhost`. Then .netcore side should do a http post not to a `localhost:port` but to resolved `ip:port`. Tested this configuration, works quite fine. I can do a PR for this, if it looks feasible for you guys.

fergalmoran closed this issue

2025-08-09 17:15:05 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/JavaScriptServices#120