- 新しい順
- 投票が多い順
- コメントが多い順
I can't find any documentation on the behaviour of NLB for KeepAlive, except for a mention here https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html#connection-idle-timeout
The difference between TCP and TLS, it's that in TLS the communication is encrypted from your client to the NLB, and then a new connection with encryption happens between NLB and the server (there is SSL termination at LoadBalancer), whilst in the case of TCP the SSL is not terminated at load balancer but the request is sent as received directly to the server, and then it will be the server to decrypt the request and the SSL handshake is done directly between the client and the server.
I think that is the reason why the behaviour is different, as for TLS, you need an SSL handshake between client and NLB, and the keepAlive from NBL for that reason.
Please check our updated at document https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html#connection-idle-timeout
When a TLS listener receives a TCP keepalive packet from either a client or a target, the load balancer generates TCP keepalive packets and sends them to both the front-end and back-end connections every 20 seconds. You can't modify this behavior.
It explained your question and difference behavior between TCP and TLS listener in your IoT device .
関連するコンテンツ
- AWS公式更新しました 1年前
- AWS公式更新しました 1年前
- AWS公式更新しました 1年前
Thanks, Miki, for the answer. Yes, it is not documented. Besides, as you already noted, this happens on TLS. However, my question is why the TLS connection in NLB should send a Keepalive time to the Client while the Client already sends a Keepalive to keep the connection. I am just wondering am i experiencing this behaviour due to some bug in NLB ?