You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/load-balancer/load-balancer-tcp-reset.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,27 +1,27 @@
1
1
---
2
2
title: Load Balancer TCP Reset and idle timeout in Azure
3
3
titleSuffix: Azure Load Balancer
4
-
description: With this article, learn about Azure Load Balancer with bidirectional TCP RST packets on idle timeout.
4
+
description: With this article, learn about Azure Load Balancer with bidirectional TCP Resetpackets on idle timeout.
5
5
services: load-balancer
6
6
author: mbender-ms
7
7
ms.service: load-balancer
8
8
ms.topic: conceptual
9
-
ms.date: 01/19/2024
9
+
ms.date: 07/31/2024
10
10
ms.author: mbender
11
11
ms.custom: template-concept, engagement-fy23
12
12
---
13
13
14
14
# Load Balancer TCP Reset and Idle Timeout
15
15
16
-
You can use [Standard Load Balancer](./load-balancer-overview.md) to create a more predictable application behavior for your scenarios by enabling TCP Reset on Idle for a given rule. Load Balancer's default behavior is to silently drop flows when the idle timeout of a flow is reached. Enabling TCP reset causes Load Balancer to send bidirectional TCP Resets (TCP RST packets) on idle timeout to inform your application endpoints that the connection timed out and is no longer usable. Endpoints can immediately establish a new connection if needed.
16
+
You can use [Standard Load Balancer](./load-balancer-overview.md) to create a more predictable application behavior for your scenarios by enabling TCP Reset on Idle for a given rule. Load Balancer's default behavior is to silently drop flows when the idle timeout of a flow is reached. Enabling TCP reset causes Load Balancer to send bidirectional TCP Resets (TCP reset packets) on idle timeout to inform your application endpoints that the connection timed out and is no longer usable. Endpoints can immediately establish a new connection if needed.
You change this default behavior and enable sending TCP Resets on idle timeout on inbound NAT rules, load balancing rules, and [outbound rules](./load-balancer-outbound-connections.md#outboundrules). When enabled per rule, Load Balancer sends bidirectional TCP Resets (TCP RST packets) to both client and server endpoints at the time of idle timeout for all matching flows.
23
23
24
-
Endpoints receiving TCP RST packets close the corresponding socket immediately. This provides an immediate notification to the endpoint's connection release and any future communication on the same TCP connection will fail. Applications can purge connections when the socket closes and reestablish connections as needed without waiting for the TCP connection to eventually time-out.
24
+
Endpoints receiving TCP rest packets close the corresponding socket immediately. This provides an immediate notification to the endpoint's connection release and any future communication on the same TCP connection will fail. Applications can purge connections when the socket closes and reestablish connections as needed without waiting for the TCP connection to eventually time-out.
25
25
26
26
For many scenarios, TCP reset can reduce the need to send TCP (or application layer) keepalives to refresh the idle timeout of a flow.
27
27
@@ -35,7 +35,7 @@ Azure Load Balancer has a 4 minutes to 100-minutes timeout range for Load Balanc
35
35
36
36
When the connection is closed, your client application can receive the following error message: "The underlying connection was closed: A connection that was expected to be kept alive was closed by the server."
37
37
38
-
If TCP RSTs are enabled, and it's missed for any reason, RSTs will be sent for any subsequent packets. If the TCP RST option isn't enabled, then packets will be silently dropped.
38
+
If TCP resets are enabled, and it is missed for any reason, resets for any subsequent packets. If the TCP reset option is not enabled, then packets will be silently dropped.
39
39
40
40
A common practice is to use a TCP keep-alive. This practice keeps the connection active for a longer period. For more information, see these [.NET examples](/dotnet/api/system.net.servicepoint.settcpkeepalive). With keep-alive enabled, packets are sent during periods of inactivity on the connection. Keep-alive packets ensure the idle timeout value isn't reached and the connection is maintained for a long period.
41
41
@@ -61,7 +61,7 @@ It's important to take into account how the idle timeout values set for differen
61
61
62
62
- TCP reset only sent during TCP connection in ESTABLISHED state.
- TCP reset isn't supported for ILB HA ports when a network virtual appliance is in the path. A workaround could be to use outbound rule with TCP reset from NVA.
64
+
- TCP reset isn't supported for Internal Load Balancer HA ports when a network virtual appliance is in the path. A workaround could be to use outbound rule with TCP reset from Network Virtual Appliance.
0 commit comments