Cours d'introduction à TCP/IP

La création d'une socket se fait par l'appel système socket.

#include <sys/types.h> /* Pour toutes les primitives */
#include <sys/socket.h> /* de ce chapitre il faut */
#include <netinet/in.h> /* inclure ces fichiers. */
int socket(int PF, int TYPE, int PROTOCOL) ;

PF spécifie la famille de protocole (« Protocol Family») à utiliser avec la socket. On trouve (extrait) par exemple sur FreeBSD (169) 7.0 :

• PF INET : pour les sockets IPv4 ;
• PF INET6 pour les sockets IPv6 ;
• PF LOCAL : pour rester en mode local (pipe)... ;
• PF UNIX : idem AF LOCAL ;
• PF ROUTE : accès à la table de routage
• PF KEY : accès à une table de clefs (IPsec) ;
• PF LINK : accès à la couche « Link».

Mais il existe d'autres implémentations notamment avec les protocoles(170) :

• PF APPLETALK : pour les réseaux Apple ;
• PF NS : pour le protocole Xerox NS ;
• PF ISO : pour le protocole de l'OSI ;
• PF SNA : pour le protocole SNA d'IBM ;
• PF IPX : protocole Internet de Novell ;
• PF ATM : « Asynchronous Transfert Mode »;
• ...

Le préfixe PF est la contraction de « Protocol Family» On peut également utiliser le préfixe AF, pour « Address Family». Les deux nommages sont possibles ; l'équivalence est définie dans le fichier d'entêtes socket.h.

TYPE Cet argument spécifie le type de communication désiré. En fait avec la famille PF INET, le type permet de faire le choix entre un mode connecté, un mode non connecté ou une intervention directe dans la couche IP :

• • SOCK STREAM : mode connecté couche transport ;
  • SOCK DGRAM : mode non connecté Idem ;
  • SOCK RAW : dialogue direct avec la couche IP.

Faut-il repréciser que seules les sockets en mode connecté permettent les liaisons « full-duplex» ?

PROTOCOL : ce troisième argument permet de spécifier le protocole à utiliser.

Il est du type UDP ou TCP le plus couramment(171) ;

• IPPROTO TCP : TCP ;
• IPPROTO SCTP : SCTP ;
• IPPROTO UDP : UDP ;
• IPPROTO RAW, IPPROTO ICMP : uniquement avec SOCK RAW

PROTOCOL est typiquement mis à zéro, car l'association de la famille de protocole et du type de communication définit explicitement le protocole de transport :

• PF INET + SOCK STREAM ==> TCP = IPPROTO TCP ;
• PF INET + SOCK DGRAM ==> UDP = IPPROTO UDP.

C'est une constante définie dans le fichier d'entêtes /usr/include/netinet/in.h et qui reflète le contenu du fichier système /etc/protocols.

13-3-1-1. Valeur retournée par socket▲

close(descripteur de socket) ;

Il faut remarquer qu'une socket est créée sans l'adresse de l'émetteur - comprendre le couple (numéro de port, adresse IP) - ni celle du destinataire. Il y a deux couples à préciser, celui côté client et l'autre côté serveur. La primitive bind effectue cette opération pour la socket de l'hôte local.

13-3-2-1. Spécification d'un numéro de port▲

13-3-2-2. Spécification d'une adresse IP▲

13-3-2-3. La primitive bind▲

int bind(int sockfd, struct sockaddr *myaddr, socklen t addrlen) ;

13-3-2-4. Les structures d'adresses▲

Avec la présence de plus en plus effective d'IPv6, les implémentations les plus récentes tiennent compte des recommandations de la RFC 3493(173), ajoutent un champ sa len d'une longueur de 8 bits et font passer de 16 à 8 bits la taille du champ sa family pour ne pas augmenter la taille globale de la structure.

 

Sélectionnez

struct sockaddr { /* La structure */
uint8_t sa_len ; /* generique */
sa_family_t sa_family ;
char sa_data[14] ;
} ;

• sa len indique la taille de la structure en octets, il est présent au même emplacement dans toutes les variantes de cette structure et contient 16 (octets) pour une structure de type sockaddr in, ou 28 octets pour une structure de type sockaddr in6 (IPv6).

Pour la famille PF INET (IPv4) cette structure se nomme sockaddr in, et est définie de la manière suivante :

 

Sélectionnez

struct in_addr {
unsigned long s_addr ; /* 32 bits Internet */
} ;
struct sockaddr_in {
uint8_t sin_len ; /* Taille de la structure == 16 octets */
sa_family_t sin_family ; /* PF_INET (IPv4) */
in_port_t sin_port ; /* Numero de port sur 16 bits / NBO */
struct in_addr sin_addr ; /* Adresse IP sur 32 bits / NBO */
char sin_zero[8] ; /* Inutilises */
} ;

La primitive bind ne permet pas toutes les associations de numéros de port, par exemple si un numéro de port est déjà utilisé par un autre processus, ou encore si l'adresse internet est invalide.

Trois utilisations typiques de la primitive :

• En règle générale les serveurs fonctionnent avec des numéros de port bien connus (cf. /etc/services). Dans ce cas bind indique au système « c'est mon adresse, tout message reçu à cette adresse doit m'être renvoyé ». En mode connecté ou non, les serveurs ont besoin de préciser cette information avant de pouvoir accepter les requêtes des clients ;
• Un client peut préciser sa propre adresse, en mode connecté ou non ;
• Un client en mode non connecté a besoin que le système lui assigne une adresse particulière, ce qui autorise l'usage des primitives read et write traditionnellement dédiées au mode connecté.

13-3-2-5. Valeur retournée par bind▲

Prendre l'initiative de l'établissement d'une connexion est typique de la démarche d'un client réseau.

La primitive connect permet d'établir la connexion avec une socket distante, supposée à l'écoute sur un port connu à l'avance de la partie cliente.

Son usage principal est d'utiliser une socket en mode « connecté». L'usage d'une socket en mode datagramme est possible mais a un autre sens (voir plus loin) et est moins utilisé.

La primitive connect a le prototype suivant :

int connect(int sockfd,const struct sockaddr *servaddr,socklen t addrlen) ;

• sockfd : le descripteur de socket renvoyé par la primitive socket ;
• servaddr : la structure qui définit l'adresse du destinataire, du même type que pour bind ;
• addrlen : la longueur de l'adresse, en octets.

13-3-3-1. Mode connecté▲

13-3-3-2. Mode datagramme▲

13-3-3-3. Valeur retournée par connect :▲

Une fois qu'un programme d'application a créé une socket, il peut l'utiliser pour transmettre des données. Il y a cinq primitives possibles pour ce faire :

• send, write, writev, sendto, sendmsg.

13-3-4-1. Envoi en mode connecté▲

ssize t write(int descripteur, const void *buffer, size t longueur) ;

ssize t writev(int descriptor, const struct iovec *iovector, int vectorlen) ;

int send(int s, const void *msg, size t len, int flags) ;

13-3-4-2. Envoi en mode datagramme▲

ssize t sendto(int s,const void *msg,size t len,int flags, const struct sockaddr *to, socklen t tolen) ;

ssize t sendmsg(int sockfd, const struct msghdr *messagestruct,int flags) ;

Symétriquement aux cinq primitives d'envoi, il existe cinq primitives de réception : read, readv, recv, recvfrom, recvmsg.

13-3-5-1. Reception en mode connecté▲

ssize t read(int descripteur, void *buffer,size t longueur) ;

ssize t readv(int descripteur, const struct iovec *iov, int vectorlen) ;

ssize t recv(int s, void *buf, size t len, int flags) ;

13-3-5-2. Recevoir en mode datagramme▲

ssize t recvfrom(int s, void *buf,size t len, int flags,struct sockaddr *from, socklen t *fromlen) ;

ssize t recvmsg(int sockfd, struct msghdr *messagestruct,int flags) ;

Imaginons un serveur en train de répondre à un client, si une requête arrive d'un autre client, le serveur étant occupé, la requête n'est pas prise en compte, et le système refuse la connexion.

La primitive listen est là pour permettre la mise en file d'attente des demandes de connexions.

Elle est généralement utilisée après les appels de socket et de bind et immédiatement avant le accept.

int listen(int sockfd, int backlog) ;

• sockfd : l'entier qui décrit la socket ;
• backlog : le nombre de connexions possibles en attente (quelques dizaines). La valeur maximale est fonction du paramétrage du noyau. Sous FreeBSD la valeur maximale par défaut est de 128 (sans paramètrage spécifique du noyau), alors que sous Solaris 10, « There is currently no backlog limit ».

Le nombre de fois où le noyau refuse une connexion est comptabilisé et accessible au niveau de la ligne de commande via le résultat de l'exécution de la commande netstat -s -p tcp (chercher « listen queue overflow »). Ce paramètre est important à suivre dans le cas d'un serveur très sollicité.

Accepter une connexion est typique de la démarche d'un serveur sur le réseau.

nous l'avons examiné, un serveur utilise les primitives socket, bind et listen pour se préparer à recevoir les connexions. Il manque cependant à ce trio le moyen de dire au protocole « j'accepte désormais les connexions entrantes ». La primitive accept est le chaînon manquant !

Quand le serveur invoque cette primitive, le noyau est prévenu que le processus est en attente d'un événement réseau le concernant. Le retour dans le code de l'application ne fait que sous deux conditions, réception d'une demande de connexion ou réception d'un signal par le processus.

int accept(int sockfd, struct sockaddr *addr, socklen t *addrlen) ;

Qui s'utilise comme suit :

int newsock ;
newsock = accept(sockfd, addr, addrlen) ;

• sockfd : descripteur de la socket, renvoyé par la primitive du même nom ;
• addr : un pointeur sur une structure du type sockaddr ;
• addlen : un pointeur sur un entier.

Quand une connexion arrive, les couches sous-jacentes du protocole de transport remplissent la structure addr avec l'adresse du client qui fait la demande de connexion. Addrlen contient alors la longueur de cette adresse.

Cette valeur peut être modifiée par le noyau lorsque la primitive est utilisée avec des sockets d'autres types pour lesquelles la taille de la structure d'adresse est variable (sockaddr un pour les sockets locales par exemple), ce qui justifie un pointeur là où nous ne pourrions attendre qu'un simple passage d'argument par valeur.

Puis le système crée une nouvelle socket par clonage de celle transmise et pour laquelle il renvoie un descripteur, récupéré ici dans newsock. Par cet artifice, la socket originale reste disponible pour d'éventuelles autres connexions (elle est clonée avant que le quintuplet soit complet).

En conclusion, lorsqu'une demande de connexion arrive, l'appel à la primitive accept redonne la main au code utilisateur.

Dans le cas du mode connecté on termine une connexion avec la primitive close ou shutdown.

int close(descripteur) ;

La primitive bien connue sous Unix peut être aussi employée avec un descripteur de socket. Si cette dernière est en mode connecté, le système assure que tous les octets en attente de transmission seront effectivement transmis dans de bonnes conditions. Normalement cet appel retourne immédiatement, cependant le kernel peut attendre le temps de la transmission des derniers octets (transparent).

Le moyen le plus classique de terminer une connexion est de passer par la primitive close, mais la primitive shutdown permet un plus grand contrôle sur les connexions en « full-duplex ».

int shutdown(int sockfd, int how) ;

Sockfd est le descripteur à fermer, how permet de fermer partiellement le descripteur suivant les valeurs qu'il prend :

• 0 : aucune donnée ne peut plus être reçue par la socket ;
• 1 : aucune donnée ne peut plus être émise ;
• 2 : combinaison de 0 et de 1 (équivalent de close).

Enfin, pour une socket en mode connecté, si un processus est interrompu de manière inopinée (réception d'un signal de fin par exemple), un « reset» est envoyé à l'hôte distant ce qui provoque la fin brutale de la connexion. Les octets éventuellement en attente sont perdus.

Exemple d'usage :

$ ./DTCPcli 192.168.52.232
Date(192.168.52.232) = Wed Dec 10 20:59:46 2003

Une capture des trames réseau échangées lors de l'exécution de cette commande se trouve plus loin.

• ligne 29 : déclaration de la structure saddr du type sockaddr in, à utiliser avec IPv4. Attention, il s'agit bien d'une structure et non d'un pointeur de structure.
• ligne 35 : la variable sfd, reçoit la valeur du descripteur de socket. Celle-ci est dédiée au protocole TCP.
• ligne 39 : le champ sin family de la structure saddr indique que ce qui suit (dans la structure) concerne IPv4.
• ligne 40 : Le champ sin port est affecté à la valeur du numéro de port sur lequel écoute le serveur. Il faut remarquer l'usage de la fonction htons (en fait une macro du préprocesseur cpp) qui s'assure que ce numéro de port respecte bien le NBO (« Network Byte Order »), car cette valeur est directement recopiée dans le champ PORT DESTINATION du protocole de transport employé.

Nous en dirons plus sur htons au chapitre suivant.

Si le processeur courant est du type « little endian » (architecture Intel par exemple) les octets sont inversés (le NBO est du type « big endian »). Vous croyez écrire 13 alors qu'en réalité pour le réseau vous avez écrit 3328 (0x0D00) ce qui bien évidemment ne conduit pas au même résultat, sauf si un serveur de date écoute également sur le port 3328, non conventionnel donc très peu probable a priori.

En résumé, si le programmeur n'utilise pas la fonction htons, ce code n'est utilisable que sur les machines d'architecture « big endian ».

/* $Id: DTCPcli.c 92 2009-02-12 17:39:44Z fla $
 *
 * Client TCP pour se connecter au serveur de date (port 13 - RFC 867).
 * La syntaxe d'utilisation est : DTCPcli <adresse ip sous forme décimale>
 *
 */

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sysexits.h>

#include <sys/types.h>
#include <sys/socket.h>
#include <sys/param.h>
#include <netinet/in.h>
#include <arpa/inet.h>

#define USAGE "Usage:%s adresse IP du serveur\n"
#define MAXMSG 1024
#define NPORT 13

int
main(int argc, char *argv[])
{
int n, sfd ;
char buf[MAXMSG] ;
struct sockaddr_in saddr ;

if (argc != 2) {
(void)fprintf(stderr,USAGE,argv[0]) ;
exit(EX_USAGE) ;
}
if ((sfd = socket(PF_INET,SOCK_STREAM,IPPROTO_TCP)) < 0) {
perror("socket") ;
exit(EX_OSERR) ;
}
saddr.sin_family = AF_INET ;
saddr.sin_port = htons(NPORT) ; /* Attention au NBO ! */
if(inet_pton(AF_INET,argv[1],&saddr.sin_addr) != 1) {
(void)fprintf(stderr,"Address «%s» is not parseable !\n",argv[1] ) ;
exit(EX_DATAERR) ;
}
if (connect(sfd,(struct sockaddr *)&saddr,sizeof saddr) < 0) {
perror("connect") ;
exit(EX_OSERR) ;
}
if ((n = read(sfd, buf,MAXMSG-1)) < 0) {
perror("read") ;
exit(EX_OSERR) ;
}
buf[n] = '\0' ;
(void)printf("Date(%s) = %s\n",argv[1],buf) ;
exit(EX_OK) ; /* close(sfd) implicite */
}

• ligne 41 : le champ s addr de la structure sin addr se voit affecté de l'adresse IP. C'est donc l'écriture de quatre octets (IPv4), pouvant comporter un caractère ASCII 0, donc interprétable comme le caractère de fin de chaîne du langage C.

C'est pourquoi à cet endroit on ne peut pas employer les habituelles fonctions de la bibliothèque standard (celles qui commencent par str).

Ici le problème se complique un peu dans la mesure où l'on dispose au départ d'une adresse IP sous sa forme décimale pointée. La gestion d'erreur protège le code des erreurs de syntaxe à la saisie.

La fonction inetpton gère parfaitement ce cas de figure. Nous en dirons plus à son sujet au chapitre suivant.

• ligne 45 : appel à la primitive connect pour établir la connexion avec le serveur distant. Quand celle-ci retourne dans le code du programme, soit la connexion a échoué et il faut traiter l'erreur, soit la connexion est établie. L'échange préliminaire des trois paquets s'est effectué dans de bonnes conditions.

Du point de vue TCP, les cinq éléments du quintuplet qui caractérisent la connexion sont définis.

Sur la capture des paquets plus loin nous sommes arrivés à la ligne 6, c'est-à-dire l'envoi de l'acquittement par le client du paquet de synchronisation envoyé par le serveur (ligne 3 et 4).

Il faut noter que bien que nous ayons transmis la structure saddr par adresse (caractère &) et non par valeur, la primitive connect ne modifie pas son contenu pour autant.

Notons également l'usage du « cast » du C pour forcer le type du pointeur (le prototype de la primitive exige à cet endroit un pointeur de type sockaddr).

• ligne 49 : appel à la primitive read pour lire le résultat en provenance du serveur, à l'aide du descripteur sfd.

Sur la capture d'écran on voit ligne 8 (et 9) l'envoi de la date en provenance du serveur, d'une longueur de 26 caractères.

Ce nombre de caractères effectivement lus est affecté à la variable n.

Ce nombre ne peut excéder le résultat de l'évaluation de MAXMSG - 1, qui correspond à la taille du buffer buf moins 1 caractère prévu pour ajouter le caractère 0 de fin de chaîne.

En effet, celui-ci fait partie de la convention de représentation des chaînes de caractères du langage C. Rien ne dit que le serveur qui répond ajoute un tel caractère à la fin de sa réponse. Le contraire est même certain puisque la RFC 867 n'y fait pas mention.

Remarque : le buffer buf est largement surdimensionné compte tenu de la réponse attendue. La RFC 867 ne prévoit pas de taille maximum si ce n'est implicitement celle de l'expression de la date du système en anglais, une quarantaine d'octets au maximum.

• ligne 53 : ajout du caractère de fin de chaîne en utilisant le nombre de caractères renvoyés par read.
• ligne 55 : la sortie du programme induit une clôture de la socket côté client. côté serveur elle est déjà fermée (séquence write + close) comme on peut le voir ligne 8 (flag FP) ci-après dans la capture du trafic entre le client et le serveur.

Remarque : rien n'est explicitement prévu dans le code pour établir la socket côté client, à savoir l'association d'un numéro de port et d'une adresse IP. En fait c'est la primitive connect qui s'en charge. L'adresse IP est celle de la machine. Le numéro de port est choisi dans la zone d'attribution automatique comme nous l'avons examiné.

Il existe bien entendu une possibilité pour le programme d'avoir connaissance de cette information : la primitive getsockname.

23:03:29.465183 client.2769 > serveur.daytime: S 2381636173:2381636173(0)
win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 299093825 0> (DF)
23:03:29.465361 serveur.daytime > client.2769: S 3179731077:3179731077(0)
ack 2381636174 win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp
4133222 299093825> (DF)
23:03:29.465397 client.2769 > serveur.daytime: . ack 1 win 57920
<nop,nop,timestamp 299093826 4133222> (DF)
23:03:29.466853 serveur.daytime > client.2769: FP 1:27(26) ack 1 win 57920
<nop,nop,timestamp 4133223 299093826> (DF)
23:03:29.466871 client.2769 > serveur.daytime: . ack 28 win 57894
<nop,nop,timestamp 299093826 4133223> (DF)
23:03:29.467146 client.2769 > serveur.daytime: F 1:1(0) ack 28 win 57920
<nop,nop,timestamp 299093826 4133223> (DF)
23:03:29.467296 serveur.daytime > client.2769: . ack 2 win 57920
<nop,nop,timestamp 4133223 299093826> (DF)

Un autre exemple d'interrogation, mais avec un autre hôte du même LAN mais sur lequel le service daytime n'est pas en fonctionnement :

$ ./DTCPcli 192.168.52.232
connect: Connection refused
16:13:21.612274 IP client.57694 > serveur.daytime: S 2248945646:2248945646(0)
win 65535 <mss 1460,nop,nop,sackOK,nop,wscale 1,nop,nop,
timestamp 360942290 0>
16:13:21.612648 IP serveur.daytime > client.57694: R 0:0(0) ack 2248945647 win 0

L'envoi d'un reset (drapeau R) par le serveur en guise de réponse est bien visible ligne 4.

/* $Id: DUDPcli.c 92 2009-02-12 17:39:44Z fla $
*
* Client UDP pour se connecter au serveur de date (port 13 - RFC 867).
* La syntaxe d'utilisation est : DUDPcli <adresse ip sous forme décimale>
*
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sysexits.h>

#include <sys/types.h>
#include <sys/socket.h>
#include <sys/param.h>
#include <netinet/in.h>
#include <arpa/inet.h>

#define USAGE "Usage:%s adresse IP du serveur\n"
#define MAXMSG 1024
#define NPORT 13

int
main(int argc, char *argv[])
{
int n, sfd ;
char buf[MAXMSG] ;
struct sockaddr_in saddr ;

if (argc != 2) {
(void)fprintf(stderr,USAGE,argv[0]) ;
exit(EX_USAGE) ;
}
if ((sfd = socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP)) < 0) {
perror("socket") ;
exit(EX_OSERR) ;
}
saddr.sin_family = AF_INET ;
saddr.sin_port = htons(NPORT) ; /* Attention au NBO ! */
if (inet_pton(PF_INET,argv[1],&saddr.sin_addr) != 1) {
(void)fprintf(stderr,"Address «%s» is not parseable !\n",argv[1] ) ;
exit(EX_DATAERR) ;
}
buf[0] = '\0' ;
if (sendto(sfd,buf,1,0,(struct sockaddr *)&saddr, sizeof saddr) != 1) {
perror("sendto") ;
exit(EX_OSERR) ;
}
if ((n=recv(sfd,buf,MAXMSG-1,0)) < 0) {
perror("recv") ;
exit(EX_OSERR) ;
}
buf[n] = '\0' ;
(void)printf("Date(%s) = %s\n",argv[1],buf) ;
exit(EX_OK) ; /* close(sfd) implicite */
}

Exemple d'usage :

$ ./DUDPcli 192.168.52.232
Date(192.168.52.232) = Wed Dec 10 20:56:58 2003

• ligne 34 : ouvertude d'une socket UDP, donc en mode non connecté.
• ligne 45 : envoi d'un caractère (NULL) au serveur, sans quoi il n'a aucun moyen de connaître notre existence.
• ligne 38, 39 et 40 : le remplissage de la structure saddr est identique à celui de la version TCP.
• ligne 49 : réception de caractères en provenance du réseau. Il faut remarquer que rien n'assure que les octets lus sont bien en provenance du serveur de date interrogé.

Nous aurions pu utiliser la primitive recvfrom dont un des arguments est une structure d'adresse contenant justement l'adresse de la socket qui envoie le datagramme (ici la réponse du serveur).

Le raisonnement sur la taille du buffer est identique à celui de la version TCP.

La capture de trames suivante montre l'extrême simplicité de l'échange en comparaison avec celle de la version utilisant TCP !

23:23:17.668689 client.4222 > serveur.daytime: udp 1
23:23:17.670175 serveur.daytime > client.4222: udp 26

Un autre essai avec la machine 192.168.52.233 qui ne répond pas plus sur le port 13 en UDP :

16:29:42.090816 IP client.55822 > serveur.daytime: UDP, length: 1
16:29:42.091205 IP serveur > client: icmp 36: serveur udp port daytime
unreachable

Et le code client reste bloqué en lecture, malgré l'envoi d'un code ICMP qui n'est pas interprété par défaut par recv... Pour éviter une telle situation de blocage, il faudrait configurer la socket en lui ajoutant un délai au-delà duquel elle retourne dans le code du client avec un code spécifique d'erreur(176).