tcp − Protocole TCP.

#include <sys/socket.h>
#include <netinet/in.h>
tcp_socket = socket(PF_INET, SOCK_STREAM, 0);

Il s’agit d’une implémentation du protocole TCP défini dans les RFC 793, RFC 1122 et RFC 2001 avec les extensions SACK et NewReno. Cela fournit un connexion full-duplex fiable orientée flux entre deux sockets au-dessus de ip(7). TCP garantit que les données arrivent dans l’ordre et assure la retransmission des paquets perdus. Il calcule et vérifie une somme de contrôle par paquet pour détecter les erreurs de transmission. TCP ne préserve pas les limites des enregistrements.

Une socket TCP neuve n’a pas d’adresse locale ou distante et n’est pas complètement définie. Pour créer une connexion TCP sortante, utilisez connect(2) pour établir la connexion sur une autre socket TCP. Pour recevoir les connexions entrantes, attachez d’abord la socket avec bind(2) à une adresse locale et un port, puis appelez listen(2) pour mettre la socket dans un état d’attente. Après cela, une nouvelle socket peut être obtenue pour chaque connexion entrante en utilisant accept(2). Une socket sur laquelle on a appelé accept ou connect avec succès est complètement définie et peut transmettre des données. Les données ne peuvent pas circuler sur les socket en attente ou non connectées.

Linux 2.2 supporte les extensions TCP à hautes performances RFC 1323. Cela inclue les fenêtres TCP larges pour supporter les liaisons avec une latence ou une bande passante élevées. Pour les utiliser, les tailles des buffers d’émission et de réception doivent être augmentées. On peut les fixer globalement avec les sysctls net.core.wmem_default et net.core.rmem_default ou individuellement sur les sockets avec les options SO_SNDBUF et SO_RCVBUF. Les tailles maximales pour les buffers sont limitées par les sysctls net.core.rmem_max et net.core.wmem_max Voir socket(7) pour plus d’informations.

TCP supporte les données urgentes. Elles signalent au récepteur qu’un message important est dans le flux de données et qu’il doit être traité le plus tôt possible. Pour envoyer des données urgentes, indiquez l’option MSG_OOB de send(2). Quand des données urgentes sont reçues, le noyau envoie un signal SIGURG au processus lecture ou au groupe de processus qui a été indiqué pour la socket avec les ioctls FIOCSPGRP ou FIOCSETOWN. Quand l’option de socket SO_OOBINLINE est validée, les données urgentes sont mises dans le flux de données normal (et peuvent être détectées avec l’ioctl SIOCATMARK), sinon, on ne peut les recevoir que lorsque l’attribut MSG_OOB et positionné pour sendmsg(2).

TCP est construit au-dessus de IP (voir ip(7)). Les formats d’adresse définis pour ip(7) s’appliquent pour TCP. TCP ne supporte que les communications point-à -point. Le broadcast et le multicast ne sont pas supportés.

Ces sysctls sont accessibles avec les fichiers /proc/sys/net/ipv4/* ou avec l’interface sysctl(2). De plus, la plupart des sysctls d’IP s’appliquent à TCP. Voir ip(7).

tcp_window_scaling

Activer le dimensionnement de la fenêtre TCP (RFC 1323).

tcp_sack

Activer l’acquittement TCP sélectif (RFC 2018).

tcp_timestamps

Activer les horodatages TCP (RFC 1323).

tcp_fin_timeout

Nombre de secondes à attendre un paquet final FIN avant que la socket soit fermée de force. Strictement parlant, ceci est une violation des spécifications TCP, mais est nécessaire pour empêcher les attaques par déni de service.

tcp_keepalive_probes

Nombre maximal de tentatives TCP keep-alive à envoyer avant d’abandonner. Les messages keep-alive ne sont envoyés que si l’option SO_KEEPALIVE de la socket est validée.

tcp_keepalive_time

Nombre de secondes durant lesquelles aucune donnée n’est transmise sur la connexion avant d’envoyer un message keep-alive. La valeur par défaut est 10800 secondes (3 heures).

tcp_max_ka_probes

Nombre de messages keep-alive envoyés par "slow timer run" [NDT: ?] Pour éviter les congestions du réseau, cette valeur ne doit pas être trop haute.

tcp_stdurg

Activation de l’interprétation RFC 793 stricte du champ TCP Urgent-Pointer. Par défaut on utilise une interprétation compatible BSD de ce champ, qui pointe vers le premier octet des données urgentes. L’interprétation RFC 793 le fait pointer vers le dernier octet des données urgentes. Valider cette option peut poser des problèmes d’interactions entre systèmes.

tcp_syncookies

Valider les syncookies TCP. Le noyau doit être compilé avec l’option CONFIG_SYN_COOKIES. Les syncookies protègent la socket des surcharges lorsque trop de tentatives de connexions arrivent. Les machines clientes peuvent ne plus être capables de détecter une machine surchargée avec un faible délai lorsque les syncookies sont activés.

tcp_max_syn_backlog

Longueur de la file d’attente par socket des connexions. Dans Linux 2.2, la valeur indiquée dans listen(2) ne correspond qu’à la longueur de la file des sockets déjà établies. La file maximale des sockets pas encore établies (dans l’état SYN_RECV) par socket en attente est fixée par ce syctl. Lorsque des demandes de connexion supplémentaires arrivent, Linux commence à rejeter les paquets. Lorsque les syncookies sont activés, il répond quand même aux paquets, et cette valeur est de fait ignorée.

tcp_retries1

Définit combien de fois une réponse à une requête TCP est retransmise avant d’abandonner.

tcp_retries2

Définit combien de fois un paquet TCP est retransmis dans l’état établi avant d’abandonner.

tcp_syn_retries

Définit combien de fois un paquet SYN initial est envoyé à un hôte distant avant d’abandonner et de renvoyer une erreur. Doit être inférieur à 255. Il ne s’agit que d’un maximum pour les connexions sortantes. Pour les connexions entrantes, le nombre de retransmission est défini par tcp_retries1.

tcp_retrans_collapse

Essayer d’envoyer des paquets de taille complète durant les retransmissions. Ceci permettait de contourner des bogues dans certaines piles TCP.

Pour lire ou écrire une option de socket TCP, appeler getsockopt(2) pour la lecture ou setsockopt(2) pour l’écriture, avec l’argument famille de socket valant SOL_TCP. De plus, la plupart des options de socket SOL_IP sont valides sur les sockets TCP. Pour plus de détails, voir ip(7).

TCP_NODELAY

Désactiver l’algorithme Nagle. Cela signifie que les paquets sont toujours envoyés dès que possible et aucun délai supplémentaire n’est introduit, au prix d’un nombre plus important de paquets sur le réseau. Il s’agit d’un attribut entier booléen.

TCP_MAXSEG

Lit ou écrit la taille maximale de segment pour les paquets TCP sortants. Si cette options est fixée avant d’établir la connexion, elle change également la valeur MSS annoncée à l’autre extrémité, dans le paquet initial. Les valeurs supérieures au MTU de l’interface sont ignorées et n’ont pas d’effet.

TCP_CORK

Ne pas envoyer de trames partielles. Toutes les trames partielles en attente sont envoyées lorsque cette option est effacée à nouveau. Ceci permet de préparer les entête avant d’appeler sendfile(2), ou pour optimiser le débit. Cette option ne peut pas être combinée avec TCP_NODELAY.

Ces ioctls sont accessibles à travers l’appel-système ioctl(2). La syntaxe correcte est :

int value;
error = ioctl(tcp_socket, ioctl_type, &value);

FIONREAD ou TIOCINQ

Renvoie la quantité de données non lues en attente dans le buffer de réception. L’argument est un pointeur sur un entier.

SIOCATMARK

Renvoie vrai si toutes les données urgentes ont déjà été reçues par le programme utilisateur. On l’utilise conjointement à SO_OOBINLINE. L’argument est un pointeur sur un entier contenant le résultat.

TIOCOUTQ

Renvoie la quantité de données non lues en attente dans le buffer d’émission. La valeur est écrite dans l’entier sur lequel on passe un pointeur. Malheureusement, l’implémentation de cet ioctl est boguée dans toutes les versions connues de Linux et renvoie à la place l’espace libre (taille du buffer moins les octets utilisés y compris les données de contrôle) dans la file d’émission. Ceci sera corrigé dans les versions de Linux à venir. Si vous utilisez TIOCOUTQ, incluez un test à l’exécution pour déterminer quel est le comportement de cet ioctl, et assurer un fonctionnement correct dans le futur et sur d’autres Unix.

Quand une erreur réseau se produit, TCP tente de renvoyer le paquet. S’il ne réussit pas après un certain temps, soit ETIMEDOUT soit la dernière erreur reçue sur la connexion est renvoyée.

Certaines application demande une notification d’erreur plus rapide. Ceci peut être validé avec l’option de socket IP_RECVERR de niveau SOL_IP. Quand cette option est active, toutes les erreurs arrivant sont immédiatement passées au programme utilisateur. Employez cette option avec soin, elle rend TCP moins tolérant envers les modifications de routage et autres conditions réseau normales.

Lorsqu’une erreur se produit due à une écriture durant l’établissement de la connexion, le signal SIGPIPE n’est envoyé que lorsque l’option SO_KEEPALIVE de la socket est active.

TCP n’a pas de véritables données hors-bande ; il a des données urgentes. Sous Linux cela signifie que si l’autre côté envoie de nouvelles données hors-bande, les données urgentes plus anciennes sont insérées comme des données normales dans le flux (même quand SO_OOBINLINE n’est pas actif). Cela diffère des piles basées sur BSD.

Linux utilise par défaut une interprétation compatible BSD du champ Urgent-Pointer. Ceci viole la RFC 1122, mais est indispensable pour l’interopérabilité avec les autres piles. On peut modifier ce comportement avec le sysctl tcp_stdurg.

EPIPE

L’autre extrémité a fermé inopinément la socket, ou une lecture est tenté sur une socket terminée.

ETIMEDOUT

L’autre côte n’a pas acquitté les données retransmises après un certain délai.

EAFNOTSUPPORT

Le type d’adresse de la socket passée dans sin_family n’était pas AF_INET.

Toutes les erreurs définies dans ip(7) ou au niveau générique des sockets peuvent aussi se produire avec TCP.

Toutes les erreurs ne sont pas documentées.

IPv6 n’est pas décrit.

Les options des proxy transparents ne sont pas décrites.

Les sysctls sont nouveaux dans Linux 2.2. IP_RECVERR est une nouvelle fonctionnalité dans Linux 2.2. TCP_CORK est nouveau dans Linux 2.2.

socket(7), socket(2), ip(7), sendmsg(2), recvmsg(2)
RFC 793 pour les spécifications TCP.
RFC 1122 pour les nécessités TCP et une description de l’algorithme Nagle.
RFC 2581 pour quelques algorithmes TCP.

Christophe Blaess, 2001.