Quels délais d'inactivité les passerelles NAT et répartiteurs de charge courants appliquent-ils réellement, et quel intervalle de keep-alive leur survit ?

Question ouverte

Les connexions longue durée (pools de bases de données, abonnements à des files de messages, sessions WebSocket, tunnels VPN) traversent des dispositifs NAT et des répartiteurs de charge qui expirent les correspondances inactives. La RFC 4787 fixe un plancher de deux minutes pour les correspondances UDP et la RFC 5382 un plancher de 2 heures 4 minutes pour les connexions TCP établies, mais ce sont des minimums pour des NAT conformes, pas des promesses sur les dispositifs réellement déployés ; les passerelles NAT cloud, les répartiteurs de charge gérés, les routeurs domestiques et les opérateurs mobiles font couramment l'objet de rapports indiquant qu'ils expirent les correspondances bien plus tôt, et la valeur par défaut de keep-alive de Linux, deux heures (tcp_keepalive_time), est plus longue que chacune d'elles. Lorsqu'une correspondance expire, aucune des deux extrémités ne l'apprend : la prochaine écriture est retransmise dans le vide jusqu'à ce que le minuteur de retransmission abandonne, ou un RST provenant du dispositif intermédiaire met fin brutalement à la connexion, selon l'appareil.

La question est donc double. Quels délais d'inactivité sont appliqués aujourd'hui par les passerelles NAT cloud, les répartiteurs de charge gérés, les routeurs domestiques et les opérateurs mobiles largement utilisés, pour TCP et pour UDP séparément ? Et quels intervalles de keep-alive (réglages TCP_KEEPIDLE par socket, pings au niveau applicatif, pings QUIC ou WebSocket) se sont avérés maintenir les sessions actives à travers ces dispositifs sans générer un trafic qui constitue lui-même un coût, par exemple sur des liaisons mobiles facturées au volume ?

Ce qu'une réponse utile contient

• Le dispositif ou le service, sa configuration le cas échéant, et la date d'observation, car les délais changent d'une génération de produit à l'autre.
• Le protocole et l'état observé : TCP établi, TCP transitoire (semi-ouvert ou en fermeture) et UDP ont chacun leur propre minuteur dans les RFC 4787 et 5382.
• Le délai documenté, avec la page du fournisseur citée et son URL, et le délai mesuré si les deux diffèrent.
• Si le dispositif répond à un paquet sur une correspondance expirée par un RST, une erreur ICMP ou le silence ; le silence est le cas qui laisse les pools de connexions en suspens.
• L'intervalle de keep-alive qui a fonctionné et le plus court qui n'a pas fonctionné, et comment la mesure a été effectuée, par exemple des connexions inactives de durée croissante suivies d'une écriture, répétées suffisamment de fois pour écarter d'autres causes.
• Les anecdotes signalées comme telles et distinguées des résultats mesurés.