La Fibre

Télécom => Réseau => TCP/IP / Fonctionnement des réseaux => Discussion démarrée par: vivien le 21 mars 2016 à 23:04:33

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: vivien le 21 mars 2016 à 23:04:33

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.

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: Snickerss 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 ?

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: jack 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)

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: corrector le 22 mars 2016 à 00:50:40

Citation de: vivien le 21 mars 2016 à 23:04:33

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... ?

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: kgersen 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

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: minidou le 22 mars 2016 à 19:50:58

Citation de: kgersen 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

lafibre.info va finir par devenir la vitrine incontournable des technologies du web ;D

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: corrector le 22 mars 2016 à 20:57:37

C'est pour mettre la honte aux sites "corporate" et étatiques!

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: Snickerss le 22 mars 2016 à 21:10:17

Citation de: jack le 22 mars 2016 à 00:15: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.

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: vivien 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).

(https://lafibre.info/images/tuto/200912_diagramme_etats_tcp.png)

Ou celui là sur une poignée de mains SSL complète :
(https://lafibre.info/images/tuto/201101_poingee_de_main_ssl.png)

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: corrector le 26 mars 2016 à 02:25:29

le Protocole Internet Version 6-Spécification (https://lafibre.info/tcpip/time_wait/msg319833/#msg319833) (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.

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: corrector le 26 mars 2016 à 04:40:45

Citation de: vivien le 22 mars 2016 à 21:42:36

Ou celui là sur une poignée de mains SSL complète :
(https://lafibre.info/images/tuto/201101_poingee_de_main_ssl.png)

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

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: corrector le 26 mars 2016 à 05:58:19

Citation de: vivien le 22 mars 2016 à 21:42:36

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

(https://lafibre.info/images/tuto/200912_diagramme_etats_tcp.png)

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

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: corrector le 26 mars 2016 à 09:29:52

D'après certains, cela correspondrait à un connect après un bind!!!

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: corrector le 28 mars 2016 à 01:51:43

Est-ce que quelqu'un connait une bonne explication de TCP?

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: corrector le 28 mars 2016 à 15:26:37

Citation de: vivien le 22 mars 2016 à 21:42:36

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

(https://lafibre.info/images/tuto/200912_diagramme_etats_tcp.png)

AMHA ton schéma n'est pas un bon support pour expliquer TCP.

Ce schéma n'est-il est pas mieux?

active open  ---> +---------------+  ---> active close   
                  |  ESTABLISHED  |
passive open ---> +---------------+  ---> passive close

Dans le monde réel, la transition provoquée par Send de LISTEN à SYN_SENT n'existe pour ainsi dire jamais. (Je ne sais même pas à quel appel système ça correspond d'ailleurs.)

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: vivien le 28 mars 2016 à 16:19:04

C'est plus simple, mais ce que j'apprécie sur le schéma, c'est de voir les messages envoyés sur le réseau.

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: corrector le 28 mars 2016 à 16:44:03

Citation de: vivien le 28 mars 2016 à 16:19:04

C'est plus simple, mais ce que j'apprécie sur le schéma, c'est de voir les messages envoyés sur le réseau.

Oui mais je le trouve assez illisible.

Je vais essayer de l'améliorer.

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: kgersen le 28 mars 2016 à 17:13:40

y'en a plein sur le Net. https://www.google.com/images?q=TCP+state+transition

celui la est pas mal:

(https://lafibre.info/images/tuto/201001_diagramme_etats_tcp.png)

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: corrector le 28 mars 2016 à 17:24:41

Enfin les machines à états, bof... moi j'aime pas.

L'important avec TCP est de comprendre que de chaque coté on a la progression :

SYN > suite d'octets > FIN

et que toute information reçue sur la progression entraîne un ACK

Le SYN transmet un numéro initial, qui correspond au 0 de la transmission de l'information. Le ACK correspondant est un 1 (donc le numéro initial + 1).

Le numéros tournent comme l'aiguille d'une montre. Il n'y pas de fin à ce manège, en regardant une seule aiguille de ta montre au moins deux fois par tour tu ne perds jamais l'heure et la date.

En fait TCP est un système qui cherche à synchroniser les informations sur 2 machines. On peut dire que c'est un double système de réplication de l'information (comme un système de sauvegarde distante).

Les informations sont réémises jusqu'à un ACK (donc la perte d'un segment ou d'un ACK correspond est géré de la même façon). La confirmation d'un ACK vient du fait que le segment n'est pas réémis et qu'un segment ayant progressé est reçu (c'est donc un système de confirmation positif puis négatif).

On voit facilement que la destruction de l'association entre les machines est nécessairement un cas particulier, puisque dans une discussion il faut une personne qui parle en dernier, et elle ne peut pas savoir si l'autre a reçu le message puisqu'il n'y a pas de réponse par définition : le ACK du dernier FIN est le seul ACK qui ne sera pas confirmé négativement, parce que rien ne vient après par définition.

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: corrector le 28 mars 2016 à 17:26:13

Citation de: kgersen le 28 mars 2016 à 17:13:40

y'en a plein sur le Net. https://www.google.com/images?q=TCP+state+transition

celui la est pas mal:

(https://lafibre.info/images/tuto/201001_diagramme_etats_tcp.png)

Voilà, c'est bien ce que je disais : il n'y a plus d'opération "send"!

SYN-SENT -> SYN-RECEIVED : c'est possible dans le monde réel où c'est un cas virtuel qui n'arrive que dans des conditions artificielles?

Ton graphe met bien la transition SYN-SENT -> SYN-RECEIVED qui ne doit pas arriver souvent est écrit, mais pas FIN-WAIT-1 -> TIME-WAIT qui est facile à imaginer.

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: corrector le 28 mars 2016 à 21:49:49

Citation de: vivien le 21 mars 2016 à 23:04:33

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 prises sont arrêtées mais toutes les données locales n'ont pas encore été envoyées.
UNKNOWN: L'état de la prise est inconnu.

AMTHA c'est très moyen : d'une tu traduis "socket" par "socket" ou par "prise", mais pas par l'un ou l'autre selon l'humeur, de deux les descriptions sont incompréhensibles.

Quand un signal est envoyé et reçu, je les distingue : SYN vs. SYN'

CLOSED = peut signifier une absence de socket ou une socket qui n'est sur le réseau du tout (ne reçoit rien, n'èmet rien)

phase d'ouverture :

CLOSED = socket crée (fonction socket) et éventuellement liée à un port (fonction bind)
LISTEN (ou LISTENING) = ouverture de socket passive (fonction listen) , a réservé un port local, peut recevoir des demande d'ouverture active : attente SYN
SYN_SENT = tentative d'ouverture active (fonction connect) : SYN envoyé, attente ACK(SYN)
SYN_RECV = reçu demande d'ouverture active, essai d'établir la connexion bidirectionnelle : SYN reçu, SYN'+ACK(SYN) envoyé, attente ACK(SYN')

ESTABLISHED = ACK(SYN') reçu, connexion bidirectionnelle fonctionnelle, échange de données en cours : envoi de ACK pour les segments de données reçus

états suite à fermeture initiée localement :

FIN_WAIT1 = annonce l'arrêt de l'envoi de données : FIN envoyé, attente ACK(FIN), réception de données seulement (envoi de ACK pour les segments de données reçus)
FIN_WAIT2 = confirmation de l'arrêt de l'envoi de données : ACK(FIN) reçu, réception de données seulement (envoi de ACK pour les segments de données reçus)
CLOSING = le partenaire a annoncé l'arrêt de l'envoi de données sans avoir vu l'arrêt d'envoi de données de l'hôte local, plus aucun segment de données ne sera plus échangé : FIN' reçu, ACK(FIN') envoyé, attente ACK(FIN)
TIME_WAIT = le partenaire sait que aucun segment de données ne sera plus échangé (mais ne sait pas forcèment que l'hôte local le sait) : FIN' et ACK(FIN) reçus (séparèment ou en même temps), ACK(FIN') envoyé

états suite à fermeture initiée par le partenaire :

CLOSE_WAIT = le partenaire a annoncé l'arrêt de l'envoi de données, connexion en émission seulement : FIN reçu, ACK(FIN) envoyé
LAST_ACK = confirmation de l'arrêt de l'envoi de données, plus aucun segment de données ne sera échangé : ACK(FIN) reçu, FIN' envoyé, attente ACK(FIN')
CLOSED après LAST_ACK : ACK(FIN') reçu

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: vivien le 28 mars 2016 à 22:27:24

Et tu penses que de ces schémas pour montrer ce que fait gagner http/2 et OCSP Stapling ?

C'est simplifié car un navigateur va ouvrir plusieurs connexions TCP en // mais j'ai essayé d'être le plus fidèle sans trop compliquer la chose.

https via http/1.1 (sans OCSP Stapling)

(https://lafibre.info/images/tuto/201603_https_1.png)


https via http/2 (avec OCSP Stapling)

(https://lafibre.info/images/tuto/201603_https_2.png)

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: corrector le 29 mars 2016 à 08:36:40

C'est quoi "srv certificats SSL"?

On le devine mais ce n'est pas clair au premier abord!

Plutôt que [SYN,ACK] je préfère [SYN(ACK),ACK] ou bien [SYN of ACK,ACK].

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: vivien le 29 mars 2016 à 09:25:56

srv certificats SSL, c'est le serveur qui pour vérifier si le certificat est révoqué.

Pour la notation [SYN,ACK], j'ai repris celle de Wireshark...

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: corrector le 29 mars 2016 à 09:53:28

Wireshark s'adresse à des gens qui ont déjà des bases. Pour expliquer aux débutants, je préfère ACK(quelquechose). En TCP, tous les messages d'un échange sauf le premier indiquent le ACK du dernier message reçu. Dans les schémas précédant le ACK n'est indiqué que quand il y a progrès.

Ce n'est pas forcèment évident pour quelqu'un qui découvre la mécanique de TCP.

AMHA la plupart des explications sur TCP sont tout simplement horribles!!!

Pour moi le plus important c'est le principe du progrès de la réplication. Conceptuellement c'est très simple, contrairement aux diagrammes incompréhensibles.

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: corrector le 30 mars 2016 à 15:40:23

Citation de: vivien le 28 mars 2016 à 22:27:24

Et tu penses que de ces schémas poru montrer ce que fait gagner http/2 et OCSP Stapling ?

Je pense qu'ils sont valables uniquement pour une connexion initiale. Les connexions suivantes sont accélérées.

N'oublie pas de le préciser dans la légende!

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: corrector le 30 mars 2016 à 16:09:03

Citation de: vivien le 22 mars 2016 à 21:42:36

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

(https://lafibre.info/images/tuto/200912_diagramme_etats_tcp.png)

Citation de: kgersen le 28 mars 2016 à 17:13:40

y'en a plein sur le Net. https://www.google.com/images?q=TCP+state+transition

celui la est pas mal:

(https://lafibre.info/images/tuto/201001_diagramme_etats_tcp.png)

Il y a plein de schémas en effet qui se décomposent en deux groupes :

Avec LISTEN -> SYN_SENT

(http://www.vorlesungen.uni-osnabrueck.de/informatik/networking-programming/notes/22Nov96/tcpStateDia.gif)

http://www.vorlesungen.uni-osnabrueck.de/informatik/networking-programming/notes/22Nov96/4.html

(http://ttcplinux.sourceforge.net/documents/one/tcpstate/tcpstate.jpg)

http://ttcplinux.sourceforge.net/documents/one/tcpstate/tcpstate.html

Aucune explication ici n'est donnée sur ce que signifie cette transition et la façon de la provoquer, à part un mystérieux "SEND".

Sans LISTEN -> SYN_SENT

(https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.halu101/dwgl0004.gif)

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.halu101/constatus.htm

EDIT : ibm.com a changé ses URL internes.

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: corrector le 31 mars 2016 à 01:11:05

Dites, je suis le seul à trouver qu'il y a un souci, ou quoi?

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: corrector le 31 mars 2016 à 01:58:15

1. Simultaneous Open

It's possible for two applications to send a SYN to each other to start a TCP connection, although the possibility is small, because both sides have to know which port on the other side to send to. This process is called "Simultaneous Open", or "simultaneous active open on both sides".

For example: An application at host A uses 7777 as the local port and connects to port 8888 on host B. At the same time, an application at host B uses 8888 as the local port and connects to port 7777 on host A. This is "Simultaneous Open".

Here is another example: The Telnet client at host A connects to the Telnet server at host B. At the same time, the Telnet client at host B connects to the Telnet server at host A.

Be careful. This time, it's not "Simultaneous Open" because the two Telnet servers on both sides do "passive open" instead of "active open". There are actually two TCP connections, instead of one in "Simultaneous Open".

TCP is specially designed to deal with "Simultaneous Open", during which only one TCP connection is established, not two. The state transitions are shown in the following figure:

(http://ttcplinux.sourceforge.net/documents/one/tcpstate/simopen.jpg)

During "Simultaneous Open", 4 packets are exchanged, 1 packet more than in normal situations.

http://ttcplinux.sourceforge.net/documents/one/tcpstate/tcpstate.html

QUESTION

Quelqu'un a déjà vu ça utilisé dans la vie réelle?

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: corrector le 04 avril 2016 à 03:51:19

Comprendre l'idée d'état TCP n'est pas évident. Il correspond à plusieurs fonctions :
- certains états correspondent à une socket telle que manipulée par un processus;
- certains états correspondent à la possibilité de recevoir des paquets démultiplexés de la couche IP;
- certains états monopolisent un port.

Le fait de représenter plusieurs fonctions sur un même schéma tend à embrouiller les choses. Je propose de virer l'état CLOSED du graphique : c'est un parasitage intellectuel. On pourra le mettre sur un autre graphique si on veut.

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: corrector le 04 avril 2016 à 19:01:28

Citation de: vivien le 22 mars 2016 à 21:42:36

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

(https://lafibre.info/images/tuto/200912_diagramme_etats_tcp.png)

J'aimerai savoir si ce schéma a réellement permis à quelqu'un de comprendre TCP.

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: corrector le 01 septembre 2016 à 18:12:01

Et vous, comment avez-vous compris le fonctionnement du protocole TCP?

Quelle est la meilleure explication?

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: corrector le 22 octobre 2016 à 17:38:21

Est-ce que le subtilités de TCP intéressent qui que ce soit?

Titre: Majorités des connexions en "TIME_WAIT" sur le serveur LaFibre.info
Posté par: corrector le 30 avril 2017 à 22:24:08

On devrait déplacer la discussion sur les subtilités du protocole TCP dans un topic en propre, non?