Quelle quantité de mémoire est consommée par le kernel Linux par connexion réseau TCP / IP?

Pour une connexion TCP, la mémoire consommée dépend de

1. taille de sk_buff (structure de réseau interne utilisée par le kernel Linux)

2. le tampon de lecture et d’écriture pour une connexion

la taille des tampons peut être modifiée au besoin

root@x:~# sysctl -A | grep net | grep mem 

vérifier ces variables

ceux-ci spécifient l’utilisation maximale du tampon mémoire par défaut pour toutes les connexions réseau dans le kernel

 net.core.wmem_max = 131071 net.core.rmem_max = 131071 net.core.wmem_default = 126976 net.core.rmem_default = 126976 

ceux-ci spécifient l’utilisation de la mémoire tampon spécifique aux connexions TCP

 net.ipv4.tcp_mem = 378528 504704 757056 net.ipv4.tcp_wmem = 4096 16384 4194304 net.ipv4.tcp_rmem = 4096 87380 4194304 

les trois valeurs spécifiées sont “min default max” tailles de tampon. Donc, pour commencer avec Linux, vous utiliserez les valeurs par défaut du tampon de lecture et d’écriture pour chaque connexion. Au fur et à mesure que le nombre de connexions augmente, ces tampons seront réduits [au maximum jusqu’à la valeur minimum spécifiée].

Ces valeurs peuvent être définies à l’aide de cette commande sysctl -w KEY=KEY VALUE

par exemple. La commande ci-dessous garantit que les tampons de lecture et d’écriture pour chaque connexion sont 4096 chacun.

 sysctl -w net.ipv4.tcp_rmem='4096 4096 4096' sysctl -w net.ipv4.tcp_wmem='4096 4096 4096' 

Dépend également de quelle couche. Dans le cas d’un scénario de transition pur, il n’y a que le FDB de niveau pont. Lorsque le routage entre en jeu, il y a la table de routage et la firebase database FDB / voisine IP. Et enfin, une fois qu’un socket local est dans le jeu, vous avez bien sûr la taille de la fenêtre, les tampons de socket (à la fois envoi et réception et 128k la dernière fois que j’ai vérifié), fragmentez les listes (si la mémoire disparaît, mais une réponse claire est difficile à faire avec toutes les pièces utilisées. Vous pouvez utiliser ss -m pour obtenir quelques statistiques sur la mémoire des sockets de stream locaux.

Ça dépend. Sur beaucoup de choses.
Je pense qu’une connexion inactive prendra quelques centaines d’octets.
Mais s’il y a des données dans les données de transmission et / ou de réception, la consommation augmente. La taille de la fenêtre peut limiter sensiblement cette consommation.
La consommation supplémentaire de données ne concerne pas uniquement les octets de la queue de réception / transmission. Il y a des frais généraux, donc un segment avec un octet peut prendre quelque chose comme 2K. TCP essaie de réduire cela, par exemple en fusionnant des segments dans un seul sk_buff, mais cela ne réussit pas toujours.