+++

title = "Qualité de Service et auto-hébergement : principes de base"
date = 2011-04-04
aliases = [ "post/2011/04/04/Qualité-de-Service-et-auto-hébergement-:-principes-de-base"]
[taxonomies]
tags = [ "internet", "rézo" ]
+++

Jeune macaque aventurier, tu t'auto-héberges pour prouver que tu as une paire de testicules en béton et continuer de faire des choses sales sur le Ouaib en toute impunité ou presque, et à cette fin, tu as probablement chez toi une magnifique connexion ADSL avec 8Mbits de bande passante descendante et un tout petit mégabit de bande passante montante, par beau temps et quand le vent porte dans la bonne direction. On va pas aller bien loin avec ça… D'ailleurs, je tiens à remercier personnellement, et pour la 12 748ème fois cette année, France Télécom pour avoir fait le choix débile de l'ADSL plutôt que du SDSL il y a de cela environ une quinzaine d'années…

<!-- more -->

Bref, tu vas rapidement te retrouver avec un souci majeur : comment rendre les différentes choses que tu héberges chez toi accessibles dans un temps raisonnable pendant que ~~bittorrent tourne à donf !~~ ta ligne est occupée d'autre part ? Comment faire pour être certain que ton blog/forum/site sur l'échangisme animalier continuera d'être accessible alors que tu envoies les photos de ta dernière partie fine en pièce jointe dans un message ?

La réponse est simple jeune macaque, il te faut faire de la qualité de service©.

# Qualité de KÔA ?

Sans m'attarder sur les principaux algorithmes, implémentations, etc, je vais simplement faire un tout petit rappel sur les principes de base du bouzin. Ce qui nous intéresse, c'est bien de faire de la qualité de service en sortie, sur le lien montant donc, histoire de garantir que la messagerie instantanée passera avant le passionnant blog vidéo de ta petite sœur. Ça peut paraître évident mais on ne peut pas faire de QoS en entrée, seulement en sortie. Si le facteur bourre ta boîte aux lettres avec des colis, des recommandés et des lettres, tu ne peux rien y faire (à part lui lâcher ton doberman au cul chaque fois qu'il se pointe). Par contre, tu peux très bien déterminer quel type de courrier tu envoies et de quelle manière.

C'est donc un peu le principe de base : réserver de la bande passante dédiée à certaines applications, réserver de la bande passante garantie à d'autres, plafonner l'utilisation de certaines applis, donner la priorité à des flux plutôt qu'à d'autres en fonction de leur importance ou de leur fonctionnement.

#  Tonton hylobates, c'est quoi une classe de service ?

Au fin fond d'IPv4/IPv6, il existe un champs qui porte le doux nom de ToS/Traffic Class et qui permet de faire de classifier simplement le traffic.

Les 6 premiers bits de ce champs permettent donc de définir des classes de service de la plus prioritaire à la moins prioritaire (c'est ce qu'on appelle le DSCP). Les 2 bits restants sont inutilisés pour le moment (mais on trouve des notations sur 8 bits aussi). Si tu sens venir le truc merdique, tu as tout-à-fait raison : en fait les normes correspondantes à ce codage ont été conçues pour être rétro-compatible avec les précédentes méthodes de qualité de service. D'où un gros bordel au décodage… Mais pas de panique, avec un tableau de correspondance tout con, on s'en sort à merveille !

Voici donc toutes les classes DiffServ :

<table>
<tr><td>Binaire</td><td>Classe</td><td>DSCP (6bits) dec - hex</td><td>DiffServ (8bits) dec - hex</td></tr>
<tr><td>000000</td><td>BE</td><td>0 - 0x00</td><td>0 - 0x00</td></tr>
<tr><td>001010</td><td>AF11</td><td>10 - 0x0a</td><td>40 - 0x28</td></tr>
<tr><td>001100</td><td>AF12</td><td>12 - 0x0c</td><td>48 - 0x30</td></tr>
<tr><td>001110</td><td>AF13</td><td>14 - 0x0e</td><td>56 - 0x38</td></tr>
<tr><td>010010</td><td>AF21</td><td>18 - 0x12</td><td>72 - 0x48</td></tr>
<tr><td>010100</td><td>AF22</td><td>20 - 0x14</td><td>80 - 0x50</td></tr>
<tr><td>010110</td><td>AF23</td><td>22 - 0x16</td><td>88 - 0x58</td></tr>
<tr><td>011010</td><td>AF31</td><td>26 - 0x1a</td><td>104 - 0x68</td></tr>
<tr><td>011100</td><td>AF32</td><td>28 - 0x1c</td><td>112 - 0x70</td></tr>
<tr><td>011110</td><td>AF33</td><td>30 - 0x1e</td><td>120 - 0x78</td></tr>
<tr><td>100010</td><td>AF41</td><td>34 - 0x22</td><td>136 - 0x88</td></tr>
<tr><td>100100</td><td>AF42</td><td>36 - 0x24</td><td>144 - 0x90</td></tr>
<tr><td>100110</td><td>AF43</td><td>38 - 0x26</td><td>152 - 0x98</td></tr>
<tr><td>101110</td><td>EF</td><td>46 - 0x2e</td><td>184 - 0xb8</td></tr>
</table>

Pour calculer facilement un DiffServ, il suffit en fait d'avoir le nombre binaire et de faire une petite conversion sur 6 bits ou 8 bits (ce qu'on peut faire très facilement dans une console Python) :
```
>>> # Classe AF41 en DSCP (6 bits)
... 
>>> print(hex(0b100010))
0x22
>>> # Classe AF41 en DiffServ (8 bits)
... 
>>> print(hex(0b100010*4))
0x88
```

Bon alors qu'est-ce que ça veut dire tout ce charabia en langage de singe ? Simple.

BE = Best Effort. En gros, c'est le mode de QoS d'Internet, ton routeur achemine ce qu'il peut, comme il peut, quand il peut. C'est le mode par défaut, n'importe quel ordi émet des paquets avec le champs ToS à 0.

AF = Assured Forwarding. Ce sont nos classes de services, réparties en 4 grandes familles (AF1, AF2, AF3, AF4) correspondant à des priorités de traffic (Bronze, Silver, Gold, Platinium). Dans chaque famille, on va définir également une priorité de drop, qui permettra en cas de congestion de sacrifier certains types de traffic au profit d'autres (en l'occurence AF11 est low drop et sera donc moins prioritaire que AF21, mais droppé après AF13 en cas de congestion).

EF = Expedited Forwarding. C'est le traffic qu'il faut envoyer de suite sans traîner et sans réfléchir. C'est typiquement le cas pour les applications de voix sur IP : il faut expédier le plus vite possible les paquets quoiqu'il arrive.

Et ben voilà, je te laisse digérer tous ces bits, la prochaine fois on verra comment marquer intelligemment les paquets avec les bonnes classes grâce à iptables et comment vérifier que tu as pas fait une connerie derrière.