En fait la traduction dans la dépêche est assez mauvaise et confuse. Cette limite du nombre de paquets ICMP existait déjà, notamment pour éviter de mettre à plat le réseau. Ça change rien là-dessus.
Pour être plus clair, le cas d'usage est le suivant : normalement ton serveur écoute sur une socket en UDP et absorbe des Mb/s de trafic (par exemple un serveur de logs). Tu redémarres/coupes le service. Plus rien n'écoute sur ton port, alors le kernel génère des paquets ICMP d'erreurs pour dire « y'a personne ici ! ». Il y a depuis longtemps des mécanismes pour limiter le nombre d'erreur générées (par exemple voir les paramètres icmp_ratelimit et icmp_ratemask des sysctl).
Même avec du ratelimiting, on arrivait dans le noyau à une situation absurde : le noyau était plus efficace à traiter des paquets quand une socket était ouverte que si aucun service n'écoutait ! (notamment grâce à des optimisations récentes sur le cas « normal » d'un serveur absorbant le paquet). Le noyau 4.11 permet de remettre de l'ordre (ce serait logique d'aller plus vite quand on ne fait rien ou presque du paquet), notamment avec un changement assez malin. Avant, on générait le paquet, et on se demandait ensuite si on l'envoyait vraiment. Maintenant, on regarde si au final on l'enverra, et on ne le génère que si la réponse est positive (ça coûte donc beaucoup moins cher en ressource, allocations de mémoire, etc. On gagne environ un facteur deux).
[^] # Re: lapin
Posté par Florent Fourcot . En réponse à la dépêche Sortie du noyau Linux 4.11. Évalué à 5.
En fait la traduction dans la dépêche est assez mauvaise et confuse. Cette limite du nombre de paquets ICMP existait déjà, notamment pour éviter de mettre à plat le réseau. Ça change rien là-dessus.
Pour être plus clair, le cas d'usage est le suivant : normalement ton serveur écoute sur une socket en UDP et absorbe des Mb/s de trafic (par exemple un serveur de logs). Tu redémarres/coupes le service. Plus rien n'écoute sur ton port, alors le kernel génère des paquets ICMP d'erreurs pour dire « y'a personne ici ! ». Il y a depuis longtemps des mécanismes pour limiter le nombre d'erreur générées (par exemple voir les paramètres
icmp_ratelimiteticmp_ratemaskdes sysctl).Même avec du ratelimiting, on arrivait dans le noyau à une situation absurde : le noyau était plus efficace à traiter des paquets quand une socket était ouverte que si aucun service n'écoutait ! (notamment grâce à des optimisations récentes sur le cas « normal » d'un serveur absorbant le paquet). Le noyau 4.11 permet de remettre de l'ordre (ce serait logique d'aller plus vite quand on ne fait rien ou presque du paquet), notamment avec un changement assez malin. Avant, on générait le paquet, et on se demandait ensuite si on l'envoyait vraiment. Maintenant, on regarde si au final on l'enverra, et on ne le génère que si la réponse est positive (ça coûte donc beaucoup moins cher en ressource, allocations de mémoire, etc. On gagne environ un facteur deux).