Les processus comme je l'ai déjà décrit, forment une grande famille.

La famille processus

Dans la famille processus je voudrais le père

Les processus se reproduisent par fork (Mitose en français). Ce qui veut dire qu'à la genèse il n'y avait qu'un processus que nous ne nommerons pas Adam mais init.

Tous les processus possèdent un identifiant (pid) ainsi qu'un identifiant de processus parent (ppid) permettant de les repérer dans un arbre généalogique (pstree).

Comment reconnait-on le père du fils lors du fork d'un processus ? Uniquement par le code de retour de la méthode fork qui vaut 0 pour le fils et donne le pid du fils au père. En dehors de cela les 2 processus sont rigoureusement identiques.

Dans la famille processus je voudrais la mère

Désolé, il n'y a pas de femme chez les processus, la reproduction est asexuée, mais c'est une idée à creuser ...

Dans la famille processus je voudrais le fils

Lorsqu'un processus forke, en général le père poursuit sa vie comme si de rien n'était, par contre le fils va muter. La mutation génétique chez les processus est bien plus violente que chez les êtres vivants. En effet, le code (l'ADN en français) est intégralement relu et remplacé depuis un nouveau fichier sur le disque. C'est ce qu'on appelle un exec.

Il existe quelques cas de processus qui ne fonctionnent pas comme ceci, mais qui laissent leur père mourir (ingrats !) et qui prennent leur place. C'est le cas des démons (un parricide est-il un démon ?) dont le but est de devenir indépendants (émancipés) et ne plus avoir de problèmes d'adolescence (le tty du père) ou de famille (le groupe de processus).

Dans la famille processus je voudrais le grand-père

Lorsqu'un processus meurt, sa dépouille est remise à son père. Elle est essentiellement constituée de son code de retour.

Lorsque le père est déjà mort, c'est le doyen qui a la charge de récupérer le code de retour, par exemple avec la méthode wait.

Dans la famille processus je voudrais le zombie

Si le père ne s'occupe pas des funérailles du fils bien aimé, celui-ci erre dans les méandres du noyau en attendant que quelqu'un veuille bien l'enterrer.

C'est ce qu'on appelle un zombie, caractérisé par la lettre Z ou par le mot defunct dans la liste des processus. Il est impossible de tuer un zombie (il est déjà mort). Seul son ascendant le plus proche le peut.

Heureusement l'ascendant universel, père de tous les processus, j'ai nommé init, prend soin de la dépouille de tous les enfants qui lui sont confiés. Donc si le père d'un zombie meurt, init s'occupera de le faire disparaître.

Les non processus

Chez les amis des processus voudrais le thread

Le thread n'est pas vraiment un processus, c'est un élément de processus, tout comme la main est un élément du corps. Avoir plusieurs threads permet à un processus de faire plusieurs choses en même temps tout en restant une seule entité. Cela permet par exemple de dédier une main au traitement et un pied à l'affichage (oui on s'y prend souvent comme des pieds pour faire des IHM, sauf certains qui y dédient la casquette).

Chez les amis des processus je voudrais le binaire

Le binaire (ou fichier exécutable) est le modèle du processus, l'ADN si vous préférez. Sans binaire, impossible de créer un processus. Celui-ci est inerte et manipulable aisément.

Chez les amis des processus je voudrais la bibliothèque

La bibliothèque c'est un bout de code qui peut être réutilisé par des processus, tout comme les plasmides , elles s'intègrent à n'importe quel autre processus pour leur apporter une fonctionnalité donnée.

Chez les amis des processus je voudrais le thread noyau

Le thread noyau est un cas particulier de thread, il tourne dans l'espace noyau et ne partage donc sa mémoire qu'avec le noyau mais ne rentre dans aucun processus. On devrait les appeler des anges puisque ce sont des être invisibles (ou presque) agissant au compte de dieu (le noyau).

Chez les amis des processus je voudrais le core

Le core, ou core dump est la version fossilisée d'un processus mort au combat. Lorsqu'un processus meurt il est effacé de la mémoire, mais s'il meurt dans des conditions exceptionnelle, par exemple s'il s'est pris un coup de signal (man kill) dans la tête et qu'un résineux est à proximité (ulimit -c) on le coule dans l'ambre pour une analyse ultérieure. gdb est un grand ami médecin qui est aussi légiste, il saura vous aider le temps venu.

Si vous n'êtes pas admin de la machine sur laquelle vous êtes (université ?), mais que vous voudriez partager votre connexion, par exemple pour une machine virtuelle ou pour des amis qui voudraient emprunter votre IP ... Il vous faut du NAT (a moins que vous vous contentiez d'un simple tunnel).

Problème : vous ne pouvez pas le mettre en place puisque vous n'êtes pas admin sur la machine qui partage la connexion.
Solution : slirp.

Hé oui c'est tout simple, slirp décapsule du PPP pour l'injecter dans de une socket normale et donc fait l'équivalent du NAT. Mais avec quelques limitations, on ne peut pas faire passer n'importe quel paquet (genre ping) depuis l'espace utilisateur, malgré tout c'est largement suffisant.

Le serveur de NAT (enfin le routeur quoi)

Bon c'est pas si simple mais presque.

Slirp est une commande qui utilise le l'entrée et sortie standard pour communiquer ce qui fait que si on veut l'utiliser à distance il faut le connecter à un "listener", ici nous allons utiliser socat, mais si vous voulez un tunnel chiffré, utilisez stunnel.

Donc vous avez besoin de socat et slirp sur la machine où vous êtes simple utilisateur. Si vous ne les avez pas recompilez les vous avez le droit. Si vous n'avez pas de compilateur copiez-lez depuis une autre machine, si cela ne fonctionne pas, recompilez les chez-vous en statique ... enfin vous êtes grands que diable, ne me posez pas cette question !

Il vous faut un fichier de configuration minimaliste pour slirp (à mettre dans ~/.sliprc) :

ppp
asyncmap 0

Puis lancez le service genre sur le port 2000 (fullbolt = pas de limitation de vitesse) :

$ socat -s tcp4-listen:2000,fork system:/usr/bin/slirp-fullbolt

Le client de NAT (enfin le terminux quoi)

Ici c'est légèrement plus compliqué. Tout d'abord il faut être root puisque nous allons faire un vpn, donc un réseau, donc une interface et du routage. Pour cela il nous faut l'autre bout du tunnel (toujours socat dans l'exemple, mais vous pouvez utiliser stunnel pour faire du ssl) et pppd qui est en quelque sorte le client naturel de slirp.

Petite configuration optimisée de pppd pour correspondre à celle de slirp (à mettre dans /etc/ppp/peers/slirp) :

notty 115200
noauth
lcp-echo-interval 0
asyncmap 0
nodefaultroute
nodetach

Et c'est parti on se connecte :

 
$ socat tcp-connect:host3.enstb.com:2000 system:"pppd call slirp"

Maintenant nous avons une connexion mais un peu spéciale car slirp a des exigences :

• IP : 10.0.2.15
• Réseau : 10.0.2.0/24 (ou autre, il s'en fout)
• Gateway(machine distante) : 10.0.2.2
• IP de commande de slirp : 10.0.2.0 (! une adresse en 0, beware of the netmask !)
• IP spéciale : 10.0.2.1
• + route directe vers l'ip du host

Et ppd configure le tout pas proprement donc il faut supprimer l'ip qu'il a ajouté. Malheureusement slirp non plus n'est pas très doué en configuration réseau et utilise l'adresse 10.0.2.0 ce qui fait que soit vous utilisez un /16 soit vous vous débrouillez pour que 10.0.2.0 soit correctement routée soit vous n'accédez jamais à l'interface de slirp à distance.

Choisissons le premier cas, donc pour activer le routage coté client configurez comme indiqué, en live cela donne :

$ ip addr del 10.0.2.15 dev ppp0
$ ip addr add 10.0.0.0/16 dev ppp0
$ ip route add default via 10.0.2.2 dev ppp0 # tout ce que vous voulez tout router par là

Et oualà !

Forwarding

Slirp est configurable dynamiquement, ce qui veut dire qu'un telnet 10.0.2.0 permet d'accéder à une interface d'admin de slirp.

Les commandes disponibles sont les mêmes que celle qu'on peut mettre dans le fichier de configuration. L'une de ces commandes est redir qui permet de faire des redirections qu'on appellerait port forwarding sur un routeur NAT.

redir [once|time] [udp|tcp] PORT [to] [ADDRESS:]LPORT

Exemple pour permettre l'accès au port ssh local depuis l'extérieur sur le port 2222 :

$ telnet 10.0.2.0
redir 2222 22
quit

Mais encore

Slirp a bien d'autres usages. Au départ slirp a été inventé pour faire du réseau sur un modem.

Mais il est aussi intégré à certains autre outils comme :

• uml : il est possible de définir une interface réseau uml comme étant une interface slirp ce qui vous permet d'avoir une machine virtuelle uml disponible directement sur le réseau local à travers un NAT
• vde : il est possible de définir un lien slirp pour vde ce qui permet tout comme pour uml de mettre en place une certaine forme de NAT derrière un switch virtuel (en général pour un ensemble de vm) sans avoir besoin d'être root
• colinux : colinux intègre aussi slirp pour la même raison

Vous voulez préparer un cours ou une présentation à base de ligne de commande, espionner quelqu'un ... ?

Ça vous ennuie de taper les commandes en direct ?

J'ai la solution : script.

Script

Script est une commande qui crée un faux terminal virtuel et duplique tout ce qui s'y passe dans un fichier typescript.

Exemple :

$ script
# on est ici dans un terminal
$ echo coucou
> coucou
$ exit
# on est sorti du terminal
$ cat typescript
> $ echo coucou
> coucou
> $ exit

Dit comme ça, ça ne semble pas très utiles mais 2 choses vont tout changer. La première c'est que script fait un vrai terminal virtuel et pas seulement une redirection, ce qui veut dire que contrairement aux pipe (|) et autres redirections (>), il est capable d'enregistrer ce qui va sur le terminal (Il est important de savoir faire la différence entre le terminal et stdout).

Exemple : la commande time. Cette commande écrit le temps d'exécution directement sur le terminal et pas dans la sortie standard, on ne peut donc pas la récupérer facilement, script le peut.

Scriptreplay

La 2e commande qui va tout changer : scriptreplay.

Maintenant faites le même test mais enregistrez vos commande avec le paramètre -t (la sortie de -t va dans stderr, ça pourrait être mieux, mais c'est comme ça) :

$ script -t 2> timer

Et cette fois utilisez scriptreplay pour lire ce qui a été généré :

$ scriptreplay timer typescript

Et là vous avez out ce qu'il faut pour faire une présentation qui dure exactement le même temps que celui qui vous a été nécessaire pour taper les commandes.

Si vous voulez adapter les timer vous pouvez, le script est éditable, mais bon à la main c'est un peu chiant. Par contre vous pouvez utiliser ctrl-s (pause) et ctrl-q (unpause) pour contrôler l'exécution du rendu.

PS : pour ceux qui suivent, il est possible de remplacer mon ssh -t de l'article sur le test de bootloader par une commande script, ce qui est un peu plus propre.

Petite fiche technique pour ne pas se perdre dans le monde de l'hébergement :

Housing

C'est le même terme en français, on dit aussi colocation, il désigne en général la fourniture de l'espace dans une armoire, du réseau et de l'électricité et c'est tout.

Pourtant c'est en général l'offre la plus chère car la plus lourde à gérer pour l'hébergeur. C'est plutôt destiné aux entreprises qui ont leur propre matériel et/ou dont l'activité sera de revendre l'accès à leur propre matériel.

Server hosting

Ou serveur dédié en français. Pratique pour une PME, ce concept permet à un sysadmin ou une petite boite d'avoir un ou des serveurs qu'elle gère entièrement, sans contraintes mais aussi sans avoir à gérer la redondance électrique ou la redondance du réseau.

On a en général une bien meilleure disponibilité et un bien meilleur débit qu'un serveur hébergé chez soi. Donc valable dès qu'on offre des services à l'extérieur. De plus on ne s'embête plus avec les matériel et ses pannes ou presque.

VPS

Ou serveur virtuel en français. C'est une machine virtuelle sur laquelle vous avez tout pouvoir (root) mais située sur une machine physique partagée avec d'autres clients.

Cela permet de faire des machines très peu chères en contrepartie d'une absence de garantie de performances.

A noter qu'OVH a sorti un produit intermédiaire entre le vps et le dédié nommé RPS. Il s'agit d'un dédié léger mais dont le disque est partagé sur le réseau.

Web hosting

Hébergement mutualisé en français. Ce genre d'offre en général est la moins cher et la plus facile à gérer. Disponible immédiatement ou presque, vous avez plus ou moins d'espace disque, une base de données plus ou moins grosse et un virtualhost php avec parfois un nom de domaine.

A choisir lorsqu'on fait un "simple" site web.

Cloud

Petit nouveau, le cloud désigne en fait un groupe de machines dont on vous vend la puissance de calcul. Il existe autant de formes de cloud que de vendeurs de cloud, tous ont cette particularité de vendre des quantités variables.. Il y a ceux qui vous vendent des vm en grande quantité, il y a ceux qui vous vendent des serveurs d'application, il y a ceux qui vous vendent de la base de données ou du simple dépôt de fichier.

A choisir lorsqu'on a des applications scalable et qu'on prévoit un grand nombre de clients potentiels.

Autres

Les hébergeur offrent aussi sous forme de pack des noms de domaine, des services dns, des services de boite mail, d'envoi en masse de mail, en général pour pas trop cher, cherchez, vous trouverez.

Il existe aussi d'autres offres plus rares d'hébergement d'application ruby, python, java mais il faudra chercher pour trouver quelque chose d'intéressant.

Dans le genre exotique vous verrez aussi des offres de type shell où vous avez un shell sur une machine partagée entre plusieurs utilisateurs. Ce genre d'activité nécessite en général une certaine confiance et a plutôt tendance à fonctionner à travers des réseaux sociaux.

Que se passe-t-il lorsqu'apache reçoit une requête ?

La question peut paraître anodine jusqu'à ce qu'on ait à écrire un fichier de configuration un peu complexe. Il faut alors avoir une idée de l'ordre dans lequel les opérations sont effectuées.

Commençons par un aperçu rapide :
-> récupération du virtualhost concerné
-> récupération de la partie requête
-> rewrite rules et redirect
-> alias et réécriture de la requête nom de fichier
-> traitement par <Directory>, <DirectoryMatch>, .htaccess, <Files>, <FilesMatch>, <Location> et <LocationMatch>
-> droits d'accès
-> traitement du fichier en fonction de son type.

Ouf c'est long ! Comme cet article, alors prenez votre temps ...

Traitement de l'URL

Pour chaque requête, apache relit sa configuration (en fait il récupère la version parsée en mémoire). Ensuite il parcourt les éléments dans l'ordre, les compile en une seule conf puis la utilise cette conf spécifiquement pour cette requête.

Virtualhost

Bon ca c'est facile, on se base sur les ServerName définis dans les <Virtualhost>. Si on n'en trouve pas, on cherche dans les ServerAlias, si on n'en trouve pas on cherche encore, mais cette fois avec les wildcard (*.mondomaine.com), si on ne trouve toujours pas, on prend le premier <Virtualhost> qui a été dacléré. Et enfin s'il n'y a pas de virtualhost, on prend le DocumentRoot défini à la racine du serveur apache lui-même.

Voilà on a trouvé le virtualhost, maintenant on prend la requête, qui est la partie située à droite de l'URL après l'hôte et le port.

Transformation de l'URL

Contrairement à ce qu'on pourrait penser, lorsqu'il y a modification de l'url, il n'y a pas de gestion de droits d'accès sur la requête originale, seulement sur l'url modifiée (par rewriterule en général).

On traite d'abord les RewriteRule, dans l'ordre de leur priorités.

Si aucune ne correspond, on traite ensuite les Redirect et les RedirectMatch dans l'ordre de leur écriture. Attention on prend aussi en compte ceux qui sont dans les <Location> qui correspondent, mais on fait comme s'ils avaient été écrits à la racine. C'est-à-dire qu'on n'enlève pas le préfixe du location pour les traiter.

On traite ensuite les Alias, AliasMatch, ScriptAlias et ScriptAliasMatch dans l'ordre de leur apparition. Ce traitement fournit le nom de fichier réel à utiliser pour une URL donnée.

Si on ne trouve pas d'alias on ajoute le DocumentRoot à la requête pour obtenir le chemin complet du fichier.

Configuration et droits d'accès

A partir de maintenant on repart de la configuration du virtualhost et pour chaque section on prend la configuration qui correspond à la requête en cours. Et à la fin on fusionne les configurations récupérées selon une règle de fusion dépendant de chaque module.

C'est complexe et chiant à retenir, donc pour simplifier retenez que les configurations spécifiques aux droits d'accès sont en mode remplacement, c'est-à-dire que la dernière configuration remplace toutes les autres.

Directory et DirectoryMatch

On sait maintenant quel chemin doit être lu, on parcourt l'arborescence pour savoir si c'est un fichier et si on peu le lire s'il a un vrai chemin sur le système ...

On part de / et au fur et a mesure qu'on descend dans le système de fichier on vérifie les <Directory>, puis les .htaccess, puis les <DirectoryMatch> dans l'ordre pour chacun des répertoires. On a donc séquentiellement pour par exemple /var/www :

• <Directory />
• /.htaccess
• <DirectoryMatch />
• <Directory /var>
• /var/.htaccess
• <DirectoryMatch /var>
• <Directory /var/www>
• /var/www/.htaccess
• <DirectoryMatch /var/www>

Toutes les sections qui correspondent sont accumulées dans la configuration en cours.

Attention ! Si l'option FollowSymLinks est activée, on fait la correspondance sur les liens symboliques avant de les déréférencer. Si l'option est désactivée, on la fait sur les liens après les avoir déréférencés. C'est assez contre intuitif !

Files et FilesMatch

Une fois arrivé au bout, on a un fichier, on lit alors les sections <Files> et <FilesMatch> dans l'ordre de leur apparition, y compris celles qu'on a trouvé dans les .htaccess ou les <Directory>.

Notez que ces sections ne prennent en compte que le nom de fichier, sans chemin.

Attention, même remarque que précédemment sur les liens symboliques : "Si l'option FollowSymLinks est activée, on matche sur les liens symboliques avant de les déréférencer. Si l'option est désactivée, on matche sur les liens après les avoir déréférencés."

Location et LocationMatch

Maintenant il nous reste à prendre en compte tous les <Location> et <LocationMatch> de la configuration qui correspondent à notre URL. Cette fois on les prend séquentiellement et uniquement en fonction de l'url.

Attention les étapes de réécriture de règle sont passées, on matche donc sur l'url réécrite.

Configuration des droits

Dans le cas des droits d'accès, les blocs de directives se remplacent. C'est-à-dire que si vous avez une série de "order / allow / deny" dans une section, elle remplace intégralement toute autre série de "order / allow / deny" que vous pourriez trouver dans une section précédente.

Attention ceci est valable pour chacun des modules séparément.

Un exemple pour être plus clair :

<Location />
    order allow,deny
</Location>
<Directory /html>
    deny from all
    AuthUserFile users.txt
</Directory>
<DirectoryMatch />
    AuthUserFile web.txt
</DirectoryMatch>
<Directory />
    order deny,allow
    allow from all
    AuthUserFile admins.txt
</Directory>

Le premier <Directory> est lu, puis il est remplacé par le 2e <Directory>, puis il est remplacé par le <DirectoryMatch> puis par le <Location> intégralement, mais séparément pour le module authz_host (order, allow, deny) et le module authnz_user (AuthUserFile). On a donc pour une requête qui matcherait les 3 sections la configuration suivante :

order allow,deny
AuthUserFile web.txt

Pas évident hein :-) Surtout que cette règle n'est pas la même pour d'autres modules comme mod_rewrite.

Traitement des droits

Le traitement des droits lui-même est particulier.

Si on est en satisfy all (par défaut) :

• On prend tous les modules de traitement des droits d'accès et si l'un d'entre eux interdit l'accès, on interdit l'accès.
  
• Puis on prend tous les modules d'authentification utilisateur et si l'un d'entre eux autorise l'accès ou s'il n'y en a pas, on autorise l'accès.

Si on est en satisfy any :

• On prend tous les modules de traitement des droits d'accès et si l'un d'entre eux interdit l'accès :
  • On demande son avis aux modules d'authentification, si l'un d'entre eux autorise l'accès ou s'il n'y en a pas, on autorise.

Rewrite (again)

Arrivé ici, on repasse dans les RewriteRules Mais cette fois on ne traite que le cas particulier des rewrite dans les sections <Location>, <Directory>, <Files> et .htaccess

Ces rewrite se cumulent cette fois (contrairement aux module d'accès, mais toujours selon le même parsing vu précédemment).

Ces rewrites sont cette fois relatifs, contrairement aux rewrite globaux. Ce qui veut dire qu'on les écrit par rapport à une racine qui est l'endroit où la règle est écrite.

Réponse

Cool maintenant on a notre requête nettoyée et on sait vers quelle fichier elle pointe.

Reste à la traiter.

Filter

On cherche tous les filtres (input et output) associés à cette url. Par exemple il y a mod_include, vous savez, pour les fichier .shtml qui contiennent des truc genre :

<!--#echo var="DATE_LOCAL" --> 

Il y a aussi les filtres pour compresser (oui pas besoin de zipper en php, apache peut le faire tout seul).

Tout ceci avec SetInputFilter et SetOutputFilter.

Handler

Ensuite on cherche le handler associé à ce type de fichier. Il y a bien sur le handler fichier (incroyable), mais aussi le handler php, le handler perl (sisi), le handler cgi, mais aussi le handler proxy, et tous ceux que vous pourriez définir avec SetHandler .

On et hop lance le tout : inputfilter -> handler -> outputfilter.

Conclusion

En résumé c'est le bordel ! Celui qui a écrit ça devait en avoir pris une sacrée dose et pas que de la farine. Probablement un pote de celui qui a fait X11 ...

Ne supposez jamais que ça marche comme vous le pensez, testez à chaque modification de votre conf.

Espérons que le prochain apache en développement tiendra ses promesses et nettoiera un peu la gestion de la configuration et surtout des droits d'accès. Sinon je prédis un avenir merveilleux pour toutes les alternatives soit disant "légères" comme lighthttpd ou nginx.

Si je me connecte au réseau local gigabit, que je fais un transfert de fichier ... je n'arrive pas à dépasser 200Mb/s ! Vous rendez-vous compte que c'est normal ?

Vous allez me dire que je ne suis pas doué, mais ce n'est pas moi, ce sont les lois de la physique.

Bon puisque nous somme dans un cas particulier je m'explique.

Temps de réponse

Le débit a beau toujours augmenter, il y a quelque chose qui s'améliore beaucoup moins vite : le temps de réponse. Pour une bonne raison, l'information a une vitesse limite, celle de la lumière. La limite est un peu inférieure sur une fibre optique et encore inférieure sur un câble cuivre.

De plus il faut une certaine électronique pour traiter tous ces paquets et ce débit. Du coup la traversée de switchs et de firewall en fout un coup à la latence. Et pourtant le débit ne change quasiment pas.

Tout ceci se voit avec la commande ping. Si vous lancez un ping sur la machine d'à coté, vous constatez un temps de réponse de l'ordre de la milliseconde.

Par exemple :

PING mamachine (10.0.0.0.1) 56(84) bytes of data.
64 bytes from mamachine (10.0.0.0.1): icmp_seq=1 ttl=61 time=1.16 ms

C'est le temps qu'il a fallu pour créer le paquet ping, l'envoyer à travers le switch, le réceptionner, répondre, repasser dans le switch, lire la réponse. Donc il faut la diviser par deux pour avoir un ordre de grandeur du temps de transfert du paquet.

Pour une machine sur un autre réseau c'est plus dans les 20ms voire 100ms.

Dans cette histoire les plus gros temps de latence dépendent de votre infrastructure, si vous êtes sur une fibre de 100km c'est elle qui contribuera à la latence, si vous êtes sur un réseau local c'est plus le temps de traitement par la carte réseau et le noyau, et s'il y a plusieurs switchs ou un routeurs c'est l'électronique des ces appareils.

Tout ça pour dire qu'il y a plusieurs limitations qui font que la latence ne s'améliore pas aussi vite que le débit.

TCP

Le TCP a été inventé à une époque où le débit d'une connexion était de l'ordre du Mb/s en local.

Une des limite du TCP est la taille des données pouvant être envoyés sans attendre de réponse (window size). Celle-ci est variable mais est limitée à 65535. Ce qui veut dire qu'une fois qu'on a envoyé 64ko de données il faut attendre une réponse, sinon on est coincé.

On voit donc bien une limite en débit apparaître à cause de la latence.

Cette limite est toute simple à calculer :
débit max = taille fenêtre / latence d'un paquet

Ce qui nous donne pour la connexion précédente :
débit max = 64ko*8 / 0.00116 = 450Mb/s

Dommage, je pensais avoir du gigabit !

Donc pensez-y la prochaine fois que vous faites un test de transfert réseau et que vous constatez que vous n'atteignez pas la limite théorique de votre réseau. Commencez par faire un ping et refaites le calcul ci dessus pour voir quelle était la limite.

PS : ce calcul n'est valable que pour une unique connexion. Si vous en avec 2 vous avez deux fois cette limite.

Erreurs

De plus, une chose qu'on ignore car elles sont devenues rares et corrigées, ce sont les erreurs.

Elles ont beau être rares lorsqu'on envoi des milliards d'octets par seconde il commence à y en avoir pas mal.

Chaque perte de paquet provoque un renvoi de touts les paquets non acquittés depuis, soit dans le pire des cas la taille de la fenêtre. La forte utilisation d'un réseau peut augmenter la perte de paquet et donc avoir un impact visible sur le débit total obtenu.

La formule est cette fois :
débit max = MSS / latence / sqrt(Proba perte de paquet)

Pour un réseau local, en général MSS=1460, prenons une perte de 0.1% on obtient :
débit max = 1460*8 / 0.00116 / sqrt(0.001) = 320Mb/s

Encore pire !

La suite

Mais non, TCP a beau être vieux, il a toujours des réserves. 2 évolutions ont donc été ajoutées à ce protocole il y a déjà un certain temps : window scaling et selective acknowledgement.

Window scaling est une extension TCP permettant d'augmenter la taille de la fenêtre jusqu'à 1Go, ça nous laisse un peu de marge.

Sous linux on vérifie l'utilisation de cette option et la taille de fenêtre associée avec :

$ cat /proc/sys/net/ipv4/tcp_window_scaling
$ cat /proc/sys/net/core/wmem_default
$ cat /proc/sys/net/core/wmem_max

Selective acknowledgement permet de demander la retransmission d'un seul paquet et non pas de toute la fenêtre. Cela permet de limiter l'impact des pertes de paquet sur les réseaux avec une forte latence.

Sous linux on vérifie l'utilisation de cette option avec :

$ cat /proc/sys/net/ipv4/tcp_sack

Ferm

Vous battez-vous toujours avec vos scripts shell pour configurer les firewall de vos serveurs ? Ne ramez plus, j'ai la solution : Ferm.

Pourquoi ferm ? Ben pourquoi pas ?

Je l'ai choisi car il ne fait qu'une chose (et le fait bien), il remplace vos scripts shell de lancement de firewall. Et c'est tout ! Pas d'interface graphique, pas d'assistance à création de règle, pas de gestion de votre serveur DHCP ...

Donc si votre machine de bureau sert de passerelle vers internet, ou si vous ne connaissez pas bien iptables, ce n'est probablement pas le meilleur outil. Par contre si vous avez l'habitude d'écrire des scripts shell pour gérer votre firewall, ferm est là pour vous simplifier la vie.

Configuration

Ferm génère des règles iptables à partir de son fichier de configuration. Il n'invente rien, il ne fait qu'écrire sous forme hiérarchique les règles iptables et vous permet d'utiliser des variable et des listes. Il faut donc les connaître un peu.

Petit exemple pour vous montrer comment gagner du temps (il se comprend tout seul) :

@def $SERVERS = (10.0.0.2 10.0.0.3);
table filter {
    chain FORWARD {
        policy DROP;
        proto tcp dport (80 443) daddr $SERVERS ACCEPT;
    }
}

On demande à ferm de générer les règles iptables mais sans les mettre dans le firewall (pas fou) :

$ ferm -n --lines firewall.conf

Et on obtient directement nos 4 règles auxquelles on s'attendait :

*filter
:FORWARD DROP [0:0]
-A FORWARD --protocol tcp --dport 80 --destination 10.0.0.2 --jump ACCEPT
-A FORWARD --protocol tcp --dport 80 --destination 10.0.0.3 --jump ACCEPT
-A FORWARD --protocol tcp --dport 443 --destination 10.0.0.2 --jump ACCEPT
-A FORWARD --protocol tcp --dport 443 --destination 10.0.0.3 --jump ACCEPT
COMMIT

On comprend bien qu'on va gagner du temps en scripting. Il faudra toujours écrire ses propres règles, mais elles seront "standardisées" et factorisées. Donc le transfert de compétence d'une personne à l'autre sera facilité. Le transfert de script aussi puisque ferm sait générer des scripts qui devront être poussés et lancés sur d'autres machines. Pratique pour ceux qui veulent une gestion centralisée des firewall de leurs serveurs/routeurs.

Mieux

Vous aurez remarqué que ferm génère des règles de type "sauvegarde iptables". Ce que je suis sur que vous ne faites pas dans vos script. Et pourtant c'est un gain de performance et de sécurité car l'ensemble des règles sera chargé en mémoire d'un coup.

De plus ferm gère lui-même le lancement du firewall au boot de la machine.

La cerise

Et si vous comptez passer à l'ipv6 ! Hé bien surtout ne faites rien ! Réutilisez le même firewall, entourez vos règles de

domain (ip ip6) {
 ....
}

Et voila votre firewall dualstack est prêt.