Auteur Sujet: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info  (Lu 30666 fois)

0 Membres et 2 Invités sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 47 076
    • Twitter LaFibre.info
Je regarde les connexions TCP/IP sur lafibre.info.

C'est vraiment énorme le nombre de connexions en TIME_WAIT (274 !)

$ netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c
      1 CLOSE_WAIT
     24 ESTABLISHED
      3 FIN_WAIT1
     36 FIN_WAIT2
      2 LAST_ACK
      9 LISTEN
    274 TIME_WAIT


ESTABLISHED:La socket a une connexion établie.
SYN_SENT: La socket attend activement d'établir une connexion.
SYN_RECV: Une requête de connexion a été reçue du réseau.
FIN_WAIT1: La socket est fermée, et la connexion est en cours de terminaison.
FIN_WAIT2: La connexion est fermée, et la socket attend une terminaison du distant.
TIME_WAIT: La socket attend le traitement de tous les paquets encore sur le réseau avant d'entreprendre la fermeture.
CLOSED: La socket n'est pas utilisée.
CLOSE_WAIT: Le distant a arrêté, attendant la fermeture de la socket.
LAST_ACK: Le distant termine, et la socket est fermée. Attente d'acquittement.
LISTEN: La socket est à l'écoute de connexions entrantes. Ces sockets ne sont affichées que si le paramètre -a,--listening est fourni.
CLOSING: Les deux socket sont arrêtées mais toutes les données locales n'ont pas encore été envoyées.
UNKNOWN: L'état du socket est inconnu.

Snickerss

  • Expert Free + Client Bbox fibre FTTH
  • Modérateur
  • *
  • Messages: 4 823
  • Mes paroles n'engagent que moi :)
    • BlueSky
Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
« Réponse #1 le: 22 mars 2016 à 00:05:34 »
C'est anormalement haut par rapport à un comportement standard ou c'est le mécanisme qui veut ca ?

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 674
  • La Madeleine (59)
Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
« Réponse #2 le: 22 mars 2016 à 00:15:17 »
C'est normal, et pas vraiment problématique

Une bonne explication sur ça:

L’état TIME-WAIT a deux buts : Le premier est d’empêcher les segments en retard d’être acceptés dans une connexion utilisant le même quadruplet (adresse source, port source, adresse cible, port cible). La RFC 1337 explique en détail ce qui peut arriver si l’état TIME-WAIT ne joue pas son rôle.

Le second but est d’assurer que l’hôte distant a bien fermé la connexion. Lorsque que le dernier ACK est perdu, l’hôte distant reste dans l’état LAST-ACK3. Si l’état TIME-WAIT n’existait pas, une connexion vers cet hôte pourrait être tentée. Le segment SYN peut alors être accueilli avec un RST.

La RFC 793 demande à ce que l’état TIME-WAIT dure au moins deux fois le MSL. Sur Linux, cette durée n’est pas configurable. Elle est définie dans include/net/tcp.h et vaut une minute


Source : http://vincent.bernat.im/fr/blog/2014-tcp-time-wait-state-linux.html (y'a des jolis dessins, je crois)

corrector

  • Invité
Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
« Réponse #3 le: 22 mars 2016 à 00:50:40 »
Je regarde les connexions TCP/IP sur lafibre.info.

C'est vraiment énorme le nombre de connexions en TIME_WAIT (274 !)

$ netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c
      1 CLOSE_WAIT
     24 ESTABLISHED
      3 FIN_WAIT1
     36 FIN_WAIT2
      2 LAST_ACK
      9 LISTEN
    274 TIME_WAIT

Et ça t'étonne parce que... ?

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
« Réponse #4 le: 22 mars 2016 à 01:37:20 »
cf ce qu'a poster jack et je rajouterais: passe a HTTP/2 -> moins de connexion par utilisateur -> moins de time_wait

minidou

  • Abonné Orange Fibre
  • *
  • Messages: 403
  • FTTH 1 Gb/s sur Nantes (44)
Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
« Réponse #5 le: 22 mars 2016 à 19:50:58 »
cf ce qu'a poster jack et je rajouterais: passe a HTTP/2 -> moins de connexion par utilisateur -> moins de time_wait
lafibre.info va finir par devenir la vitrine incontournable des technologies du web ;D

corrector

  • Invité
Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
« Réponse #6 le: 22 mars 2016 à 20:57:37 »
C'est pour mettre la honte aux sites "corporate" et étatiques!

Snickerss

  • Expert Free + Client Bbox fibre FTTH
  • Modérateur
  • *
  • Messages: 4 823
  • Mes paroles n'engagent que moi :)
    • BlueSky
Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
« Réponse #7 le: 22 mars 2016 à 21:10:17 »
C'est normal, et pas vraiment problématique

Une bonne explication sur ça: http://vincent.bernat.im/fr/blog/2014-tcp-time-wait-state-linux.html (y'a des jolis dessins, je crois)

Magnifique article.

vivien

  • Administrateur
  • *
  • Messages: 47 076
    • Twitter LaFibre.info
Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
« Réponse #8 le: 22 mars 2016 à 21:42:36 »
Superbe article effectivement.
Pas mal de choses sur son blog : http://vincent.bernat.im/fr/blog/

Et le diagramme de Ivan Griffin sur les etats TCP est top (disponible sous la licence LaTeX Project Public License 1.3).



Ou celui là sur une poignée de mains SSL complète :

corrector

  • Invité
Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
« Réponse #9 le: 26 mars 2016 à 02:25:29 »
le Protocole Internet Version 6-Spécification (traduction de RFC 2460 par Nicolas Jourdan)

Citer
8.2. Durée de vie maximale d’un paquet

Contrairement à IPv4, les nœuds IPv6 ne sont pas obligés d’imposer un temps de vie maximum des paquets. C’est la raison pour laquelle le champ IPv4 " Temps à Vivre " (" Time to Live ") a été renommé " Nombre de Sauts Maximum " (" Hop Limit ") dans IPv6. En pratique, très peu, s’il y en a, d’implèmentations d’IPv4 sont conformes aux exigences de limitation de la durée de vie des paquets, aussi ceci n’est pas un changement en pratique. Tout protocole de couche supérieure qui compte sur la couche inter-réseaux (que se soit IPv4 ou IPv6) pour limiter la durée de vie des paquets devrait être mis à jour pour fournir ses propres mécanismes pour détecter et éliminer des paquets périmés.

Donc la couche inférieure ne garantit pas à TCP une durée de vie < TTL (time to live) et TCP doit prendre une durée importante pour éviter le risque d'accepter un segment TCP perdu et retrouvé par la Poste des années après.

corrector

  • Invité
Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
« Réponse #10 le: 26 mars 2016 à 04:40:45 »
Ou celui là sur une poignée de mains SSL complète :

Dans le cas simple. Le serveur peut aussi réclamer un certificat au client, ce qui ajoute des messages (mais pas des aller-retour).

Citer
If the server has requested client authentication (an optional step in the handshake), the client also signs another piece of data that is unique to this handshake and known by both the client and server. In this case the client sends both the signed data and the client's own digital certificate to the server along with the encrypted premaster secret.
http://www.pierobon.org/ssl/ch2/detail.htm

corrector

  • Invité
Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
« Réponse #11 le: 26 mars 2016 à 05:58:19 »
Et le diagramme de Ivan Griffin sur les etats TCP est top (disponible sous la licence LaTeX Project Public License 1.3).


Je me demande bien qui a déjà vu la queue de cette action "send" sur une socket LISTEN!