Editer un article - Informaticien.be

Editer un article

Titre
Mots Clés
Texte	[size=18] [b]Nom[/b] [/size] tcp - Protocole TCP. [size=18] [b]Résumé[/b] [/size] [b]#include <sys/socket.h>[/b] [b][/b] [b]#include <netinet/in.h>[/b] [b][/b] [b]tcp_socket = socket(PF_INET, SOCK_STREAM, 0); [/b] [size=18] [b]Description[/b] [/size] 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 [b]ip (7).[/b] 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 [b]connect (2)[/b] pour établir la connexion sur une autre socket TCP. Pour recevoir les connexions entrantes, attachez d'abord la socket avec [b]bind (2) [/b] à une adresse locale et un port, puis appelez [b]listen (2)[/b] pour mettre la socket dans un état d'attente. Après cela, une nouvelle socket peut être obtenue pour chaque connexion entrante en utilisant [b]accept (2).[/b] Une socket sur laquelle on a appelé [b]accept[/b] ou [b]connect[/b] 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 [b]net.ipv4.tcp_wmem[/b] et [b]net.ipv4.tcp_rmem[/b] ou individuellement sur les sockets avec les options [b]SO_SNDBUF [/b] et [b]SO_RCVBUF[/b] de l'appel-système [b]setsockopt (2).[/b] Les tailles maximales pour les buffers déclarés via [b]SO_SNDBUF[/b] et [b]SO_RCVBUF[/b] sont limitées par les sysctls généraux [b]net.core.rmem_max[/b] et [b]net.core.wmem_max[/b] Notez que TCP alloue en fait deux fois plus de place que la taille demandée avec l'appel [b]setsockopt (2),[/b] et qu'un appel [b]getsockopt (2)[/b] réussi ne renverra pas la même taille de buffer que celle réclamée dans le [b]setsockopt (2).[/b] TCP les utilise à des fins administratives et pour des structures internes du noyau, et les variables sysctls renvoient des tailles supérieures à celle des véritables fenêtres TCP. Pour les connexions individuelles, la taille du buffer doit être fixée avant les appels [b]listen ()[/b] ou [b]connect ()[/b] pour qu'elle soit prise en compte. Voir [b]socket (7)[/b] pour plus de détails. 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 [b]MSG_OOB[/b] de [b]send (2).[/b] Quand des données urgentes sont reçues, le noyau envoie un signal [b]SIGURG[/b] au processus lecture ou au groupe de processus qui a été indiqué pour la socket avec les ioctls [b]FIOCSPGRP[/b] ou [b]FIOCSETOWN .[/b] Quand l'option de socket [b]SO_OOBINLINE[/b] 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 [b]SIOCATMARK ),[/b] sinon, on ne peut les recevoir que lorsque l'attribut [b]MSG_OOB[/b] et positionné pour [b]sendmsg (2). [/b] Linux 2.4 a introduit un certain nombre de changements pour améliorer le débit et l'extensibilité, ainsi que des fonctionnalités améliorées. Certaines de ces fonctions incluent le support pour l'émission sans copie avec [b]sendfil (2),[/b] la notification de congestion explicitie, la nouvelle gestion des sockets TIME_WAIT, les options "keep-alive" et le support des extensions SACK dupliqués. [size=18] [b]Formats dadresse[/b] [/size] TCP est construit au-dessus de IP (voir [b]ip (7)).[/b] Les formats d'adresse définis pour [b]ip (7)[/b] s'appliquent pour TCP. TCP ne supporte que les communications point-à-point. Le broadcast et le multicast ne sont pas supportés. [size=18] [b]Sysctls[/b] [/size] Ces variables sont accessibles avec les fichiers [b]/proc/sys/net/ipv4/* [/b] ou avec l'interface [b]sysctl (2).[/b] De plus, la plupart des sysctls d'IP s'appliquent à TCP. Voir [b]ip (7). [/b] [b]tcp_abort_on_overflow[/b] [table][row][col]    [/col][col]Valide la réinitialisation des connexions si le service en écoute est trop lent et incapable de les traiter et les accepter. Ceci n'est pas validé par défaut. Ce qui signifie que si un déborderment se produit à cause d'une surcharge temporaire, la connexion va se rattraper. N'activez cette option que si vous êtes SÛRS que le démon en écoute ne peut pas être configuré pour accepter les connexions plus vite. Cette option peut désorienter les clients de votre serveur.[/col][/row][/table] [b]tcp_adv_win_scale[/b] [table][row][col]    [/col][col]Calculer le surplus du buffer comme 1/2^tcp_adv_win_scale (si tcp_adv_win_scale > 0) ou 1 - 1/2^(-tcp_adv_win_scale) (si tcp_adv_win_scal <= 0). La valeur par défaut est 2. L'espace du buffer de réception de la socket est partagé entre l'application et le noyau. TCP conserve une portion du buffer en tant que fenêtre TCP, c'est la taille de la fenêtre de réception indiquée au correspondant. Le reste de cet espace est utilisé comme buffer d'"application", pour isoler le réseau des latences de l'ordonnanceur et de l'application. La valeur par défaut de [b]tcp_adv_win_scale[/b] (2) indique que l'espace utilisé pour le buffer d'application est un quart de l'espace total.[/col][/row][/table] [b]tcp_app_win [/b] [table][row][col]    [/col][col]Cette variable définit combien d'octets de la fenêtre TCP sont réservés pour le surplus de buffer. Un maximum de (fenetre/2^tcp_app_win, mss) octets de la fenêtre est réservé pour le buffer d'application. Une valeur nulle indique qu'aucune portion n'est réservée. La valeur par défaut est 31.[/col][/row][/table] [b]tcp_dsack[/b] [table][row][col]    [/col][col]Valide le support TCP SACK dupliqué, de la RFC2883. Validé par défaut.[/col][/row][/table] [b]tcp_ecn[/b] [table][row][col]    [/col][col]Valide la notification explicite de congestion de la RFC2884. Elles n'est pas activée par défaut. Lorsqu'elle est en service, la connectivité avec certaines destinations peut être affectée à cause de vieux routeurs mal configurés le long du trajet, et les connexions peuvent être rompues.[/col][/row][/table] [b]tcp_fack[/b] [table][row][col]    [/col][col]Valide le support TCP Forward Acknoledgement. Validé par défaut.[/col][/row][/table] [b]tcp_fin_timeout[/b] [table][row][col]    [/col][col]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. La valeur par défaut dans les noyaux 2.4 est 60, elle était 180 dans les 2.2.[/col][/row][/table] [b]tcp_keepalive_intvl[/b] [table][row][col]    [/col][col]L'intervalle en secondes entre deux messages TCP keep-alive. La valeur par défaut est 75 secondes.[/col][/row][/table] [b]tcp_keepalive_probes[/b] [table][row][col]    [/col][col]Nombre maximal de tentatives TCP keep-alive à envoyer avant d'abandonner et de tuer la connexion si aucune réponse n'est obtenue de l'autre partie. La valeur par défaut est 9.[/col][/row][/table] [b]tcp_keepalive_time[/b] [table][row][col]    [/col][col]Nombre de secondes durant lesquelles aucune donnée n'est transmise sur la connexion avant d'envoyer un message keep-alive. Ces messages ne sont envoyés que si l'option [b]SO_KEEPALIVE [/b] de la socket est validée. La valeur par défaut est 7200 secondes (2 heures). Une connexion inactive est coupée environ 11 minutes plus tard (9 tentatives à 75 secondes d'écart). Notez que les délais de la couche de transport sous-jacente, ou de l'application peuvent être bien plus courts.[/col][/row][/table] [b]tcp_max_orphans[/b] [table][row][col]    [/col][col]Le nombre maximal de sockets TCP orphelines (attachées à aucun descripteur utilisateur) sur le système. Quand ce nombre est dépassé, la connexion orpheline est réinitialisée et un message d'avertissement est affiché. Cette limite n'existe que pour éviter les attaques par déni de service ; la diminuer n'est pas recommandé. Certaines situations peuvent réclamer d'augmenter cette limite, mais notez que chaque connexion orpheline peut consommer jusqu'à 64 ko de mémoire non-swappable. La valeur par défaut est égale au paramètre NR_FILE du noyau. Elle est ajustée en fonction de la mémoire disponible sur le système.[/col][/row][/table] [b]tcp_max_syn_backlog[/b] [table][row][col]    [/col][col]Le nombre maximal de requêtes de connexions en attente, qui n'ont pas encore reçu d'acquittement de la part du client se connectant. Si ce nombre est atteint, le noyau commencera à abandonner des requêtes. La valeur par défaut, 256, est augmentée jusqu'à 1024 si la mémoire présente est suffisante (>= 128 Mo) et peut être diminuée à 128 sur les systèmes avec très peu de mémoire (<= 32 Mo). Il est recommandé, s'il faut augmenter cette valeur au dessus de 1024, de modifier TCP_SYNQ_HSIZE dans include/net/tcp.h pour conserver TCP_SYNQ_HSIZE * 16 <= tcp_max_syn_backlog et de recompiler le noyau.[/col][/row][/table] [b]tcp_max_tw_buckets[/b] [table][row][col]    [/col][col]Le nombre maximal de sockets dans l'état TIME_WAIT autorisées sur le système. Cette limite n'existe que pour éviter les attaques par déni de service. La valeur par défaut est NR_FILE2, ajustée en fonction de la mémoire disponible. Si ce nombre est atteint, la socket est fermée et un avertissement est affiché.[/col][/row][/table] [b]tcp_mem[/b] [table][row][col]    [/col][col]Il s'agit d'un vecteur de trois entiers : [bas, charge, haut]. Ces limites sont utilisées par TCP pour surveiller sa consommation mémoire. Les valeurs par défaut sont calculées au moment du boot à partir de la mémoire disponible. [i]bas[/i] - TCP ne cherche pas à réguler ses allocations mémoire quand le nombre de pages qu'il a alloué est en-dessous de ce nombre [i]charge[/i] - lorsque la taille mémoire allouée par TCP dépasse ce nombre de pages, TCP modère sa consommation mémoire. L'état de mémoire chargée se termine lorsque le nombre de pages allouées descend en dessous de la marque [b]bas .[/b] [i]haut[/i] - le nombre global maximal de pages que TCP allouera. Cette valeur surcharge tout autre limite imposée par le noyau.[/col][/row][/table] [b]tcp_orphan_retries[/b] [table][row][col]    [/col][col]Le nombre maximal de tentatives pour accéder à l'autre extrémité d'une connexion dont notre côté a été fermé. La valeur par défaut est 8.[/col][/row][/table] [b]tcp_reordering[/b] [table][row][col]    [/col][col]Le nombre de réorganisations dans un flux TCP avant de supposer qu'un paquet est perdu et reprendre au début. La valeur par défaut est 3. Il n'est pas conseillé de modifier cette valeur. C'est une métrique sur la détection des réordonnancements de paquets conçue pour minimiser les retransmissions inutiles provoquées par la réorganisation des paquets dans une connexion.[/col][/row][/table] [b]tcp_retrans_collapse[/b] [table][row][col]    [/col][col]Essayer d'envoyer des paquets de tailles complètes durant les réémissions. C'est validé par défaut.[/col][/row][/table] [b]tcp_retries1[/b] [table][row][col]    [/col][col]Le nombre de fois que TCP essayera de retransmettre un paquet sur une connexion établie normalement, sans demander de contribution supplémentaire de la couche réseau concernée. Une fois ce nombre atteint, on demande au niveau réseau de remettre à jour son routage, si possible avant chaque nouvelle transmission. La valeur par défaut, 3, est le minimum indiqué dans la RFC.[/col][/row][/table] [b]tcp_retries2[/b] [table][row][col]    [/col][col]Le nombre de fois qu'un paquet TCP est restransmis sur une connexion établie avant d'abandonner. La valeur par défaut est 15, ce qui correspond à une durée entre 13 et 3 minutes suivant le délai maximal de retransmission. La limite minimal de 100 secondes spécifiée par la RFC 1122 est typiquement considérée comme trop courte. .T [b]tcp_rfc1337[/b] Activer le comportement TCP conformément à la RFC 1337. Ceci n'est pas actif par défaut. Lorsqu'il n'est pas activé, si un RST est reçu en état TIME_WAIT, on ferme la socket immédiatement sans attendre la fin de la période TIME_WAIT.[/col][/row][/table] [b]tcp_rmem[/b] [table][row][col]    [/col][col]Il s'agit d'un vecteur de trois entiers : [min, défaut, max]. Ces paramètres sont utilisés par TCP pour régler la taille du buffer de réception. TCP ajuste dynamiquement la taille à partir de la valeur par défaut, dans l'intervalle de ces variables sysctls, en fonction de la mémoire disponible sur le système. [i]min[/i] - taille minimale du buffer de réception utilisée par chaque socket TCP. La valeur par défaut 4 Ko et descend à PAGE_SIZE octets sur les systèmes avec peu de mémoire. Cette valeur assure qu'en mode de mémoire chargée, les allocations en-dessous de cette taille réussiront. Elle n'est pas utilisée pour limiter la taille du buffer de réception, déclarée en utilisant l'option [b]SO_RCVBUF[/b] sur la socket. [i]défaut[/i] - la taille par défaut du buffer de réceptiion pour une socket TCP. Cette valeur écrase la taille par défaut dans la valeur globale [b]net.core.rmem_defautl[/b] définie pour tous les protocoles. La valeur par défaut est 87380 octets, et descend à 43689 sur les systèmes avec peu de mémoire. Si une taille plus grande est désirée, il faut augmenter cette valeur (pour affecter toutes les sockets). Pour utiliser une grande fenêtre TCP, l'option [b]net.ipv4.tcp_window_scaling[/b] doit être activé (par défaut). [i]max[/i] - la taille maximale du buffer de réception utilisé par chaque socket TCP. Cette valeur ne surcharge pas la valeur globale [b]net.core.rmem_max .[/b] Elle ne permet pas de limiter la taille du buffer de réception déclarée avec l'option [b]SO_RCVBUF[/b] sur la socket. La valeur par défaut est 873802 octets et peut descendre à 87380 sur les systèmes avec peu de mémoire.[/col][/row][/table] [b]tcp_sack[/b] [table][row][col]    [/col][col]Activer l'acquittement TCP sélectif (RFC 2018). Actif par défaut.[/col][/row][/table] [b]tcp_stdurg[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]tcp_synack_retries[/b] [table][row][col]    [/col][col]Le nombre maximal de fois où un segment SYN/ACK sera retransmis sur une connection TCP passive. Ce nombre ne doit pas dépasser 255. La valeur par défaut est 5.[/col][/row][/table] [b]tcp_syncookies[/b] [table][row][col]    [/col][col]Valider les syncookies TCP. Le noyau doit être compilé avec l'option [b]CONFIG_SYN_COOKIES .[/b] Envoie des syncookies lorsque la file d'attente des connexions sur une socket déborde. Ceci est utilisé pour se protéger d'une attaque de type "SYN flood". On ne doit l'utiliser qu'en dernier ressort. C'est une violation du protocole TCP, et entre en conflit avec d'autres fonctions comme les extensions TCP. Cela peut poser des problèmes avec les clients ou les relais. Ce mécanisme n'est pas considéré comme un moyen de réglage sur un serveur très chargé ou mal configuré. Pour des alternatives acceptables, voyez [b]tcp_max_syn_backlog ,[/b] [b]tcp_synack_retries ,[/b] [b]tcp_abort_on_overflow .[/b][/col][/row][/table] [b]tcp_syn_retries[/b] [table][row][col]    [/col][col]Le nombre maximal de fois où un paquet SYN initial sera retransmis pour une tentative de connexion TCP active. Cette valeur ne doit pas dépasser 255. La valeur par défaut est 5, ce qui correspond approximativement à 180 secondes. [/col][/row][/table] [b]tcp_timestamps[/b] [table][row][col]    [/col][col]Activer les horodatages TCP (RFC 1323). Ceci est actif par défaut.[/col][/row][/table] [b]tcp_tw_recycle[/b] [table][row][col]    [/col][col]Activer le recyclage rapide des sockets TIME-WAIT. Ceci n'est pas actif par défaut. Cette option n'est pas recommandée car elle peut poser des problèmes avec les redirections NAT (Network Address Translation).[/col][/row][/table] [b]tcp_window_scaling[/b] [table][row][col]    [/col][col]Activer le dimensionnement de la fenêtre TCP (RFC 1323). Ceci est actif par défaut. Cette fonctionnalité permet d'utiliser une grande fenêtre (> 64 Ko) sur une connexion TCP si le correspondant le supporte. Normalement, les 16 bits du champ de longueur de fenêtre dans l'en-tête TCP limitent la taille à 64 Ko. Si on désire une fenêtre plus grande, l'application peut augmenter la taille du buffer le la socket et activer l'option tcp_window_scaling. Si [b]tcp_window_scaling[/b] est inhibée, TCP ne négotiera pas l'utilisation du dimensionnement des fenêtres avec le correspondant lors de l'initialisation de la connexion.[/col][/row][/table] [b]tcp_wmem[/b] [table][row][col]    [/col][col]Il s'agit d'un vecteur de trois entiers : [min, défaut, max]. Ces paramètres servent à TCP pour réguler la taille du buffer d'émission. La taille est ajustée dynamiquement à partir de la valeur par défaut, dans l'intervalle des variables sysctl, en fonction de la mémoire disponible. [i]min[/i] - taille minimale du buffer d'émission utilisé par chaque socket TCP. La valeur par défaut est 4 Ko. Cette valeur assure qu'en mode de mémoire chargée, les allocations en-dessous de cette taille réussiront. Elle n'est pas utilisée pour limiter la taille du buffer de réception, déclarée en utilisant l'option [b]SO_SNDBUF[/b] sur la socket. [i]défaut[/i] - la taille par défaut du buffer d'émission pour une socket TCP. Cette valeur écrase la taille par défaut dans la valeur globale [b]net.core.wmem_defautl[/b] définie pour tous les protocoles. La valeur par défaut est 16 Ko. Si une taille plus grande est désirée, il faut augmenter cette valeur (pour affecter toutes les sockets). Pour utiliser une grande fenêtre TCP, la variable [b]net.ipv4.tcp_window_scaling[/b] doit être activé (par défaut). [i]max[/i] - la taille maximale du buffer d'émission utilisé par chaque socket TCP. Cette valeur ne surcharge pas la valeur globale [b]net.core.rmem_max .[/b] Elle ne permet pas de limiter la taille du buffer de réception déclarée avec l'option [b]SO_SNDBUF[/b] sur la socket. La valeur par défaut est 128 Ko et peut descendre à 64 Ko sur les systèmes avec peu de mémoire.[/col][/row][/table] [size=18] [b]Options[/b] [/size] Pour lire ou écrire une option de socket TCP, appeler [b]getsockopt (2)[/b] pour la lecture ou [b]setsockopt (2)[/b] pour l'écriture, avec l'argument famille de socket valant [b]SOL_TCP .[/b] De plus, la plupart des options de socket [b]SOL_IP [/b] sont valides sur les sockets TCP. Pour plus de détails, voir [b]ip (7).[/b] [b]TCP_CORK[/b] [table][row][col]    [/col][col]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 en-têtes avant d'appeler [b]sendfile (2),[/b] ou pour optimiser le débit. Cette option ne peut pas être combinée avec [b]TCP_NODELAY .[/b] Cette option ne doit pas être utilisée dans du code conçu pour être portable.[/col][/row][/table] [b]TCP_DEFER_ACCEPT[/b] [table][row][col]    [/col][col]Permettre à un processus en écoute de n'être réveillé que si des données arrivent sur la socket. Prend une valeur entière (en secondes), correspondant au nombre maximal de tentatives que TCP fera pour terminer la connexion. Cette option ne doit pas être utilisée dans du code conçu pour être portable.[/col][/row][/table] [b]TCP_INFO[/b] [table][row][col]    [/col][col]Fournit des informations sur la socket. Le noyau renvoie une structure tcp_info comme définie dans le fichier /usr/include/linux/tcp.h. Cette option ne doit pas être utilisée dans du code conçu pour être portable.[/col][/row][/table] [b]TCP_KEEPCNT[/b] [table][row][col]    [/col][col]Le nombre maximal de messages keepalive envoyés par TCP avant d'abandonner une connexion. Cette option ne doit pas être utilisée dans du code conçu pour être portable.[/col][/row][/table] [table][row][col]    [/col][col].N TCP_KEEPIDLE La durée (en secondes) d'inactivité sur une connexion avant que TCP commence à envoyer les messages keepalive, si l'option SO_KEEPALIVE a été activée sur la socket. Cette option ne doit pas être employée dans du code conçu pour être portable.[/col][/row][/table] [b]TCP_KEEPINTVL[/b] [table][row][col]    [/col][col]Délai (en seconde) entre deux messages keepalive. Cette option ne doit pas être utilisée dans du code conçu pour être portable.[/col][/row][/table] [b]TCP_LINGER2[/b] [table][row][col]    [/col][col]La durée des sockets orphelines dans l'état FIN_WAIT2. Cette option peut servir à surcharger la valeur de la variable sysctl (globale pour le système) [b]tcp_fin_timeout[/b] spécialement pour la socket. À ne pas confondre avec l'option [b]SO_LINGER[/b] du niveau [b]socket (7).[/b] Cette option ne doit pas être utilisée dans du code conçu pour être portable.[/col][/row][/table] [b]TCP_MAXSEG [/b] [table][row][col]    [/col][col]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 imposera ses limites minimales et maximales plutôt que les valeurs fournies.[/col][/row][/table] [b]TCP_NODELAY[/b] [table][row][col]    [/col][col]Désactiver l'algorithme Nagle. Ceci signifie que les paquets seront envoyés dès que possible, même s'il n'y a que très peu de données. Sinon, les données sont conservées jusqu'à ce qu'il y en ait un nombre suffisant, pour éviter d'envoyer de fréquents petits paquets, au détriment du réseau. Cette option ne peut pas être utilisée en même temps que l'option [b]TCP_CORK .[/b][/col][/row][/table] [b]TCP_QUICKACK[/b] [table][row][col]    [/col][col]Valider le mode quickack, ou l'inhiber si l'option est nulle. En mode quickack, les acquitements sont envoyés immédiatement plutôt que retardés si besoin par rapport au fonctionnement normal de TCP. Cet attribut n'est pas permanent, il s'agit seulement d'un basculement vers ou depuis le mode quickack. Les opérations ultérieures du protocole TCP feront à nouveau entrer/quitter le mode quickack en fonction des traitements internes du protocole et de facteurs tels que les délais d'acquittements retardés, ou les tranferts de données. Cette option ne doit pas être utilisée dans du code conçu pour être portable.[/col][/row][/table] [b]TCP_SYNCNT[/b] [table][row][col]    [/col][col]Indique le nombre de retransmissions de SYN que TCP doit envoyer avant d'annuler la tentative de connexion. Ne doit pas dépasser 255. Cette option ne doit pas être utilisée dans du code conçu pour être portable.[/col][/row][/table] [b]TCP_WINDOW_CLAMP[/b] [table][row][col]    [/col][col]Limite la taille de la fenêtre. Le noyau impose une taille minimale de SOCK_MIN_RCVBUF/2. Cette option ne doit pas être employée dans du code conçu pour être portable.[/col][/row][/table] [size=18] [b]Ioctls[/b] [/size] Ces ioctls sont accessibles à travers l'appel-système [b]ioctl (2).[/b] La syntaxe correcte est : [table][row][col]    [/col][col] .nf [b][i]int value;[/i][/b] [b][i]error = ioctl( tcp_socket , ioctl_type , & value );[/i][/b] .fi[/col][/row][/table] [b]SIOCINQ[/b] [table][row][col]    [/col][col]Renvoie la quantité de données non lues en attente dans le buffer de réception. L'argument est un pointeur sur un entier. La socket ne doit pas être dans l'état LISTEN, sinon l'erreur EINVAL est renvoyée.[/col][/row][/table] [b]SIOCATMARK[/b] [table][row][col]    [/col][col]Renvoie vrai si toutes les données urgentes ont déjà été reçues par le programme utilisateur. On l'utilise conjointement à [b]SO_OOBINLINE .[/b] L'argument est un pointeur sur un entier contenant le résultat.[/col][/row][/table] [b]SIOCOUTQ[/b] [table][row][col]    [/col][col]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. La socket ne doit pas être dans l'état LISTEN, sinon l'erreur EINVAL est renvoyée.[/col][/row][/table] [size=18] [b]Gestion derreur[/b] [/size] 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 [b]ETIMEDOUT [/b] 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 [b]IP_RECVERR [/b] de niveau [b]SOL_IP .[/b] Quand cette option est active, toutes les erreurs arrivant sont immédiatement passées au programme utilisateur. Employez cette option avec précaution, elle rend TCP moins tolérant envers les modifications de routage et autres conditions réseau normales. [size=18] [b]Notes[/b] [/size] Lorsqu'une erreur se produit due à une écriture durant l'établissement de la connexion, le signal [b]SIGPIPE[/b] n'est envoyé que lorsque l'option [b]SO_KEEPALIVE[/b] 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 [b]SO_OOBINLINE[/b] 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 [b]tcp_stdurg .[/b] [size=18] [b]Erreurs[/b] [/size] [b]EPIPE[/b] [table][row][col]    [/col][col]L'autre extrémité a fermé inopinément la socket, ou une lecture est tenté sur une socket terminée.[/col][/row][/table] [b]ETIMEDOUT[/b] [table][row][col]    [/col][col]L'autre côte n'a pas acquitté les données retransmises après un certain délai.[/col][/row][/table] [b]EAFNOTSUPPORT[/b] [table][row][col]    [/col][col]Le type d'adresse de la socket passée dans [i]sin_family [/i] n'était pas [b]AF_INET .[/b][/col][/row][/table] Toutes les erreurs définies dans [b]ip (7)[/b] ou au niveau générique des sockets peuvent aussi se produire avec TCP. [size=18] [b]Bugs[/b] [/size] Toutes les erreurs ne sont pas documentées. [b][/b] IPv6 n'est pas décrit. [size=18] [b]Versions[/b] [/size] Le support pour la notification explicite de congestion, l'émission de fichiers dsans copie, le réordonnancement et certaines extensions SACK (DSACK) ont été introduits dans Linux 2.4. Le support du Forward Acknowledgement (FACK), le recyclage de TIME_WAIT les options des messages keepalive et les variables sysctls ont été introduits dans Linux 2.3. Les valeurs par défaut et les descriptions des variables sysctls décrites ci-dessus sont applicables pour les noyaux 2.4. [size=18] [b]Auteurs[/b] [/size] Cette page de manuel a été écrite à l'origine par Andi Kleen. Elle a été mise à jour pour le 2.4 par Nivedita Singhvi en se basant sur le fichier Documentation/networking/ip-sysctls.txt d'Alexey Kuznetsov. [size=18] [b]Voir aussi[/b] [/size] [b]socket (7),[/b] [b]socket (2),[/b] [b]ip (7),[/b] [b]bind (2),[/b] [b]listen (2),[/b] [b]accept (2),[/b] [b]connect (2),[/b] [b]sendmsg (2),[/b] [b]recvmsg (2),[/b] [b]sendfile (2),[/b] [b]sysctl (2),[/b] [b]getsockopt (2).[/b] RFC 793 pour les spécifications TCP. [b][/b] RFC 1122 pour les nécessités TCP et une description de l'algorithme Nagle. [b][/b] RFC1323 pour les options d'horodatage et la fenêtre TCP. [b][/b] RFC1644 pour une description des dangers de TIME_WAIT. [b][/b] RFC2481 pour une description de la notification explicite de congestion. [b][/b] RFC 2581 pour des algorithmes de contrôle de congestion TCP. [b][/b] RFC2018 et RFC2883 pour SACK et ses extensions. [size=18] [b]Traduction[/b] [/size] Christophe Blaess, 2001-2003.
Fichier