Oui enfin bon ta condescendances sur "TCP est prévu pour ca, les mecs d'OpenSSH sont des cons moi je sais ce qu'il faut faire" est pire.
Je n'ai jamais dit ça. J'ai regretté qu'ils l'aient activé par défaut, mais je pense qu'ils l'ont fait pour accommoder beaucoup d'utilisateurs qui blâmaient ssh alors qu'ils avaient un réseau pourri.
Cette fonctionnalité de TCP c'est cool, le problème c'est que si tu n'émets pas de trafic, la connexion à une durée de vie illimitée et tu ne peux jamais libérer les ressources. Dans le monde réel ca pose comme un tout petit problème.
Le nombres de ressources que tu gaspilles à gérer la persistance plus haut… Et si ce timeout était de plusieurs jours/semaines par défaut, ça serait déjà moins problématique. Mais non, c'est fait pour killer les sessions très rapidement.
Donc OpenSSH prend une très bonne approche, utiliser une configuration par défaut qui convient à 99% des configs (que leur réseau soit bon ou mauvais, ils ne veulent pas que ca leak) et fournissent une option pour ceux qui préfère l'autre comportement.
C'est ce que j'ai expliqué dans mon journal : oui, ils ont voulu s'adapter aux réseaux pourris, et donc aujourd'hui, quand on a un réseau qui marche bien, ça fait plus chier qu'autre chose, du coup personne n'a l'envie d'avoir un réseau qui marche. Ça te fait plaisir d'avoir des sessions ssh qui tombent régulièrement ? Pas moi.
En plus ils fournissent un heartbeat applicatif au dessus de TCP, qui est aussi nécessaire par ce que beaucoup de gens n'ont pas envie de devoir taper une commande pour se rendre compte que la connexion est tombée ou pour éviter de tomber dans la lenteur des timeouts TCP.
Le hearbeat applicatif a exactement le même but que le keepalive tcp. Ça n'a pas de rapport avec s'il y a du trafic ou non. L'avantage, disent-ils, c'est qu'on ne peut pas spoofer le keepalive applicatif, contrairement au keepalive tcp (même si ça me paraît un cas un peu maigre pour mériter une telle option, mais pourquoi pas).
Bref les choix par défaut sont très raisonnables, et tu as toutes les options nécessaires pour faire ce que tu veux. Pourquoi venir pleurer pour qu'ils passent en mode "tire toi dans le pied" par défaut ?
Parce que les choix par défaut font que ça pourrit les utilisations « modernes » d'une pile TCP. Ça n'est pas se tirer dans le pied, c'est comme ça qu'a été imaginé TCP. On en réduit les fonctionnalités parce que une bonne partie des gens ont des réseaux pourris, mais on ne fait surtout rien pour inciter à corriger ça.
Tu vas me dire « c'est pas leur rôle », toussa, le genre d'argument classique pour ne surtout pas chercher à améliorer la situation actuelle. Je ne pourrai qu'acquiescer en regrettant.
[^] # Re: Je comprends pas
Posté par benoar . En réponse au journal Le TCP keepalive m'a tué. Évalué à -1.
Je n'ai jamais dit ça. J'ai regretté qu'ils l'aient activé par défaut, mais je pense qu'ils l'ont fait pour accommoder beaucoup d'utilisateurs qui blâmaient ssh alors qu'ils avaient un réseau pourri.
Le nombres de ressources que tu gaspilles à gérer la persistance plus haut… Et si ce timeout était de plusieurs jours/semaines par défaut, ça serait déjà moins problématique. Mais non, c'est fait pour killer les sessions très rapidement.
C'est ce que j'ai expliqué dans mon journal : oui, ils ont voulu s'adapter aux réseaux pourris, et donc aujourd'hui, quand on a un réseau qui marche bien, ça fait plus chier qu'autre chose, du coup personne n'a l'envie d'avoir un réseau qui marche. Ça te fait plaisir d'avoir des sessions ssh qui tombent régulièrement ? Pas moi.
Le hearbeat applicatif a exactement le même but que le keepalive tcp. Ça n'a pas de rapport avec s'il y a du trafic ou non. L'avantage, disent-ils, c'est qu'on ne peut pas spoofer le keepalive applicatif, contrairement au keepalive tcp (même si ça me paraît un cas un peu maigre pour mériter une telle option, mais pourquoi pas).
Parce que les choix par défaut font que ça pourrit les utilisations « modernes » d'une pile TCP. Ça n'est pas se tirer dans le pied, c'est comme ça qu'a été imaginé TCP. On en réduit les fonctionnalités parce que une bonne partie des gens ont des réseaux pourris, mais on ne fait surtout rien pour inciter à corriger ça.
Tu vas me dire « c'est pas leur rôle », toussa, le genre d'argument classique pour ne surtout pas chercher à améliorer la situation actuelle. Je ne pourrai qu'acquiescer en regrettant.