feat: add network layer course

content/projet_programmation/9_principes_SOLID/index.md

@@ -0,0 +1,185 @@
+---
+title: "PdP: principes SOLID"
+date: 2024-03-28
+tags: ["besoins", "UML", "developpement logiciel"]
+categories: ["Projet de programmation", "Cours"]
+---
+
+C'est un ensemble de principe souvent associés à la programmation objet. Ils
+s'appliquent cependant à toute forme d'architecture. Il sont au nombre de 5 :
+
+ * principe d'inversion des dépendances que nousa vons déjà vu précédement;
+ * principe de responsablité unique;
+ * principe de ségrégation d'interfaces;
+ * principe ouvert/fermé
+ * principe de substitution (de *Liskov*)
+
+## Inversion des dépendances
+
+Utiliser des interfaces comme intermédiaire afin d'inverser les dépendances. LEs
+interfaces utilisées comme intermédiaires permettent de faire écran (masquer
+l'implementation). Elles permettent aussi de proteger les composants de la
+diffusion.
+
+Dans sa **version stricte**, les interfaces ne portent que ce qui est
+nécessaire, mais ça peut être lourd (multiplication des interfaces). Il est donc
+plus courant (et désirable) de généraliser les interfaces.
+
+## Responsablité
+
+Il est question de décomposer pour maîtriser, mais aussi pour limiter les
+responsabilité des composants.
+
+La **responsabilité d'un composant** est un rôle, un objectif, un comportement,
+un ensemble de services qu'il fournit et dont il est le garant. Il faut alors
+favoriser la contruction de composants avec un nombre réduit de responsabilité.
+
+Dans sa version radicalisé (Martin, 2003), il est même question de favoriser les
+composant avec **une seule responsabilité**. Mais attention, il ne faut pas
+appliquer ce principe jusqu'à emietter complètement une architecture (code
+*ravioli*).
+
+Une responsabilité ne se résume pas à une seule fonction (ou une seule action)
+mais plutôt à un ensemble cohérent de fonctions / actions. Voici les critères
+permettant de la caractériser une responsabilité unique:
+
+ * être décrite simplement en lien avec le domaine du programme (et en langage
+   naturel);
+ * être associé à un haut niveau de cohésion dans le composant (ce qui signifie
+   plus de dépendance entre ses éléments);
+ * être identifiée par rapport à la manière récurrente dont le composant est
+   utilisé par les autres composants (féquement utilisé pour **tout** ce qu'il
+   propose);
+ * être associé à sa raison principale la plus probable d'être modifiée (une
+   seule raison principale d'évoluer).
+
+### Son anti-pattern juré: le **blob**
+
+C'est l'inverse de la responsabilité unique : un composant fourre-tout qui
+centralise beaucoup de responsabilité différentes et entourré de composants qui
+ne contiennent que des données ou des processus simples.
+
+
+## Ségrégation d'interfaces
+
+Nous avons vu que la taille d'une dépendance entre deux composants est 
+caractérisée par la quantité d'information qui transite entre eux. nous avonx vu
+que nous devons avant tout les minimiser.
+
+Le principe de ségrégation des interfaces est le principe selon lequel il faut
+favoriser la construction de composants dont les dépendances correspondent à
+ce qu'ils utilisent réellement (ni plus, ni mois). Nous parlons ici d'interfaces
+au sens large, mais au sens d'interfaces de classes.
+
+Il est donc parfois nécessaire de décomposer pour l'appliquer, quitte à
+recomposer ensuite.
+
+## Ouvert / Fermer
+
+Pour tout logiciel, des transformations et des évolutions seront nécessaire et
+appliquées. Il sont dit *ouverts*
+
+Il est aussi préférable de ne pas toucher à ce qui fonctionne bien et est
+utilisé. Ceci pourrait pertuber un écosystème fragile. C'est la partie *fermée*.
+Nous préservons ainsi son fonctionnement, les liens entre les composants, les
+interfaces, les tests etc.
+
+Pour faire évoluer notre logiciel snas pour autant toucher aux composants
+fonctionnels, nous avons alors plusieurs pistes:
+
+ * utiliser l'héritage et ainsi ne pas toucher au composant de base fonctionnel;
+ * utiliser les interfaces pour, par exemple, de nouvelles implémentations
+   (réalisations multiples)
+ * utiliser la généricité, l'usage de composants paramétrés permettant de les
+   adaptés selon l'instanciation de ces partamètres tout en les préservant;
+ * utiliser les plugins.
+
+Il faut donc favoriser la construction de composants ouverts-fermés par rapport
+aux changements les plus probables, ouverts à l'extension et fermé à la
+modification. Toute la difficulté ici est d'obtenir des composants
+ouverts-fermés facile à faire évoluer.
+
+## Substitution de Liskov
+
+Dans une architecture logicielle, il doit être possible d'effectuer des
+remplacement localiser de composants de manière à préserver son fonctionnement.
+La **substitution** est le remplacement d'un élément par un autre similaire
+indépendement du contexte (*context-free*) et sans induire d'autres changements.
+Il faut alors passer par une spécfication, ainsi la variation se fait sur la
+manière de l'implémenter.
+
+Il faut alors favoriser la **construction de composants spécifiés** de manière à
+pouvoir les substituer. Il faut alors faireparticulièrement attention à la
+**précision de la spécification** en fonction du contexte.
+
+### substitution par sous-typage
+
+Un composant substituant sous une spécification \\(S\\) peuvent implémenter plus
+de propriété que requis par \\(S\\) sans pour autant metter à mal les propriétés
+de substitution. En clair *Qui peut le plus peut le moins*.
+
+Une spécification \\(S'\\) est compatible avec une autre \\(S\\) (noté
+\\(S' <: S\\)) si on peut déduire toutes les propriété de \\(S\\) à partir de
+\\(S'\\) et donc si \\(S' \implies S\\).
+
+De manière générale, lorsque \\(S' <: S\\) tout composants qui implémente 
+\\(S'\\) implémente aussi \\(S\\). Ainsi si on considère les spécifications
+comme des types, la compatibilité définis ce qu'est le **sous-typage**.
+
+L'application de la substitution requiert une bonne connaissance de ce qui
+engendre des compatibilités.
+
+### compatibilité 
+
+La compatibilité entre **spécifications de fonctions** dépend en particulier de
+leurs domaines d'entrée et de sorties. La compatibilité entre spécfications de 
+fonctions est donc :
+
+\\[
+(In' \rightarrow Out') <: (In \rightarrow Out')\\\
+\text{si } In <: In' \\\
+\text{et } Out' <: Out
+\\]
+
+Donc:
+
+ * \\(In'\\) a un ensemble d'instances **égal ou plus grand** que \\(In\\);
+ * \\(Out'\\) a un ensemble d'instance **égal ou plus petit** que \\(Out\\);
+
+ Cette règles relatives aux fonctions peuvent se généraliser **aux 
+ conditions**:
+
+  * les **préconditions** \\(Pre\\) d'une spécification \\(S\\) sont les
+    propriétés de notre spécification qui doivent être implémentées par un
+    composant pour qu'ils soit exécuté,  appliqué, activé.
+  * les **postconditions** \\(Post\\) d'une spécification \\(S\\) sont les
+    propriétés de notre spécification qui doivent être implémentées par les
+    résultats, les services rendus, les effets obtenus d'un composant.
+
+\\[
+(Pre', Post') <: (Pre, Post')\\\
+\text{si } Pre <: Pre' \\\
+\text{et } Post' <: Post
+\\]
+
+autrement dit:
+
+ * les préconditions sont plus faible ou égale: **contravariance**;
+ * les postconditions sont plus forte ou égale: **covariance**
+
+### Vérification des substitutions
+
+Liskov introduit des bugs s'il n'est pas bien appliqué. La compréhension est
+donc essentielle sinon des bugs liés aux intentions feront leur apparition, et
+ils sont souvent difficile à trouver.
+
+### Principe de substitution de Liskov
+
+Sans une architecture logicielle, il faut favoriser la construction de
+composants spécifiés au niveau adéquat de précision de manière à ce qu'ils
+soient substituables sous leur spécification de manière satisfaisante dans leur
+contexte de programmation.
+
+Il faudra considérer alors le bon choix de précision des spécifications et la
+vérification des spécifications, des compatibilités ainsi que des aproximations
+qui y sont associés.

content/reseaux_protocoles/4_couche_reseau/index.md

@@ -0,0 +1,443 @@
+---
+title: "Réseaux et Protocole: couche réseau"
+date: 2024-02-21
+tags: ["OSI", "reseau", "control plane", "data plane"]
+categories: ["Réseaux et protocoles", "Cours"]
+mathjax: true
+---
+
+Le but de cette partie et de comprendre ce qui se passe dans la couche réseaux
+matérialisée la quasi-totalité du temps par le **protocole IP**. Comme pour les
+autres couches vue jusqu'à présent, il est encore question **d'encapsulation**
+et de **décapsulation**.
+
+C'est la couche qui se trouve dans les équipements *Internet* pour faire du
+**routage**: le *routeur* examine les entêtes des *paquets IP* afin de
+déterminer leur destination. Deux notions apparaissent alors:
+
+ * le **forwarding** qui consiste à récupérer les paquets sur une *interface* et
+   les renvoyer vers une autre;
+ * le **routage** qui consiste à déterminer la route de la source vers la
+   destination (le chemin complet donc).
+
+Dans ce chapitre nous aborderons les notions de **data plane**, **control plan**
+ou encore de **software defined network** (*SDN*).
+
+## Le *data plane*
+
+C'est la partie responsable du mouvement "réel" des données à travers les
+périphériques réseaux. La logique de routage est implémenter dans chacun des 
+périphérique composant le réseau.
+
+### Les routeurs
+
+Pierre angulaire de l'acheminement des paquets. ils prenne des pacquets sur des
+interfaces en entrée qu'il redirigent vers des interfaces en corties en fonction
+de critères établis. En définitive chaque routeur est indépendant et composé
+d'un *data plane* et d'un *control plane* contenant la **table de routage**.
+
+Pour schématiser, le *control plane* représente le logiciel et le *data plane*
+le matériel.
+
+### Switch fabric
+
+Le *data plane* se compose des ports en entrée et en sortie, au milieu se
+trouve la **switch fabric**. C'est cette partie qui est charger d'acheminer les
+paquets des entrées vers les sorties en fonction de ce que le *control plane*
+veut. Le temps de traitement d'un *datagramme* est de l'ordre de la nanoseconde
+[^traitement].
+
+
+[^traitement]: là ou pour le *control plane* c'est de l'ordre de la
+    milliseconde. Chaque routeur est aussi responsable de son algorithme de
+    routage.
+
+#### ports d'entrée
+
+
+Ils reçoivent les *trames* de la couche liaison. Les entêtes de la couche
+reseaux sont extraites. Deux traitements sont alors possibles:
+
+ * forwarding basé sur **la destination** basé uniquement sur l'adresse de
+   destination;
+ * forwarding **généralisé** basé sur les valeurs de l'entête (une, quelques 
+ unes ou toutes).
+
+ Pour les correspondances sur les adresses, la règle du *longuest prefix match*
+ s'applique. La correspondance se fait sur le prefixe le plus détaillé.
+
+Le *switching rate* est donné par le rapport entre le nombre de paquet en entrée
+et en sorties. Idéaliement il est de 1 ou plus, ce qui signifie que les 
+*datagrammes* en entrée sont traités directement. si ce nombre est inférieur à 1
+alors il y a engorgement à l'entrée. Dans ce cas les paquets sont mis en file
+d'attente dans un *buffer* (à l'entrée).
+
+Il peuvent l'être aussi si les paquets reste bloqués pour diverses raison comme
+par exemple un  *buffer* de sortie plein.
+
+En cas de remplissage du *buffer* alors des **paquets peuvent être perdus**.
+
+#### ports de sortie
+
+Ils reçoivent les *datagrammes* en provenance de la *switch fabric* et les
+acheminent vers leur destination. Là encore nous avons un *buffer** où les
+paquets en attente sont stocké par exemple si les paquets arrivent plus vite que
+le lien ne peut les transmettre.
+
+Ici encore des paquets pevent être perdus en cas de **buffer overflow**.
+
+Les paquets évincés dépendent alors de la stratégie définie :
+
+ * `tail drop` pour refuser les nouveaux datagrammes qui arrivent;
+ * `priority`  pour supprimer des datagrammes en fonction des priorités.
+
+#### Ordonnancement
+
+Il est possible de définir l'ordonnancement des datagrammes et ainsi d;organiser
+une stratégie de priorisation en fonction des besoins. Le plus simple reste
+*FIFO* pour *First In First Out*[^FCFS] où ils sont acheminés en fonction de
+leur ordre d'arrivé.
+
+Il est aussi possible d'ordonnancer suivant la priorité, par *round-robbin*, par
+poids attribués aux paquets ...
+
+[^FCFS]: aussi appelle *First Come First Serve*.
+
+### Le protocole IP
+
+C'est un ensemble de règle définissant:
+
+ * un format de *datagrammes*;
+ * l'adressage;
+ * les conventions d'action sur les paquets;
+ * le protocole ICMP (report d'erreur et signalement de routeurs);
+ * les algorithme de sélection de chemins pour router les paquets (BGP, OSPF).
+
+L'entête d'un datagramme IP fait 20 octets pour sa version v4, elle se compose:
+
+ * *version* du protocole (4 bits);
+ * *longueur de l'entête* -- nombre de mots de 32 bits -- par défaut 5 (4 bits);
+ * *type de services* (8bits);
+ * *longueur totale du datagramme* en octets (16 bits);
+ * données utilisé pour la fragmentation :
+   * *identifiant* ( 16 bits);
+   * *drapeau* (4 bits);
+   * *décallage*  (12 bits);
+ * adresse *source* (32 bits);
+ * adresse *destination* (32 bits);
+ * *options* si besoin (32 bits);
+
+#### L'adresse IP
+
+C'est un identifiant codé sur 32 bits et attribué à chacune des interface des
+hôtes connectés au réseau. Une *interface* représente une connexion entre un
+hôte (ou un routeur) et un lien physique (issu de la couche liaison que nous
+verrons plus tard)
+
+Il existe deux façons de classifier les adresse IP:
+
+ * L'adressage par classes représenté par des classes d'adresses allant de *A* à
+   *E* en fonction des préfixes (1.0.0.0 - 126.255.255.255 pour la classe A par
+   exemple);
+ * *CIDR* pour *Classless Inter Domain Routing* ou les sous-réseaux peuvent
+   avoir des adresses d'une taille arbitraire.
+
+Dasn le second cas, les adresses sont découpés entre le préfixe de sous-réseau
+et la part réserver aux hôtes, par exemple
+
+```text
+192.168.23.0/23
+```
+
+Il existe aussi les adresses publiques et privées (utilisable dans un réseaux
+local). Pour ces dernière 3 classes sont disponibles:
+
+ * 10.0.0.0/8
+ * 172.16.0.0/12
+ * 192.168.0.0/16
+
+##### le sous-réseau
+
+Nous avons parlé de sous-réseaux, c'est la portion d'un réseau ou les hôtes
+peuvent se contacter les uns les autres sans que les datagrammes passent par
+un routeur. Ainsi chaque portion isolée d'un réseau est un sous-réseau. NMous
+pouvons alors créer des "îles".
+
+
+#### Obtenir une adresse IP
+
+Plusieurs moyens sont à la disponision des administrateurs réseaux afin
+d'assigner une adresse IP à une interface.
+
+ * Adresse codée directement "en dur" sur l'interface via, par exemple, le
+   fichier `/etc/network/interfaces`.
+ * Assignée dynamiquement par un serveur *DHCP* *Dynamic Host Configuration 
+   Protocol*.
+
+Pour ce dernier, voici les étapes:
+
+ 1. l'hôte envoie un message de *broadcast* de type `DHCP discover`;
+ 2. les serveurs *DHCP* disponibles répondent avec le message `DHCP Offer` et 
+    fait une proposition;
+ 3. l'hôte répond avec avec un message `DHCP request` au serveur qu'il a retennu
+    avec comme charge utile l'adresse IP qui lui a été proposée;
+ 4. le serveur retenu répond alors avec un message `DHCP ack`.
+
+Le DHCP fait bien plus qu'assigner des adresses IP, il peut aussi définit
+l'adresse de la passerelle (routeur de premier niveau), les adresses des
+serveurs de nom, le masque de réseau etc.
+
+### NAT, *Network Address Translation*
+
+Il est question ici de *"partager"* une adresse IP **publique**. L'agent
+responsable de la translation d'adresse. Il est question de remplacer le port et
+l'adresse IP source. Notre agent responsable -- équipement effectuant la
+translation -- une table de translation est disponible afin de connaitre l'état
+des connexions en cours.
+
+Le NAT n'est utile que pour l'IP v4 dont les adresses routables sont au bord de
+l'epuisement. Il est utilisé intensivement pour les connexions domestiques et
+les réseaux cellulaires. Cependant les problèmes de pénurie ont leur solution:
+IPV6.
+
+Problème supplémentaire, c'est le routeur qui se charge de faire le *NAT*,
+cependant il ne ddevrai pas aller farfouller dans la couche 4 du modèle OSI et
+se cantonner **sa couche 3**. 
+
+### Forwarding généralisé (SDN)
+
+Chaque routeur contient une **table de forwarding**. Lors du forwarding
+généralisé, la correspondance ne se fait pas seulement sur l'adresse de
+destination mais sur l'ensemble de l'entête. Le routeur utilise alors la
+correspondance (*match*), les *actions* et la *priorité*.
+
+ * Les *match* se font sur les couches *lien*, *réseau* et * transport.
+ * Les actions possibles sur les paquets sont *drop*, *copy*, *modify* et *log*.
+ * Les priorité afin de savoir *quoi faire* lorsque plusieurs *match* arrivent.
+ * Enfin, les couteurs sont là afin d'acoir des metriques sur *les bits* et les
+   *paquets* qui passent.
+
+Le principe du SDN est d'unifier **routage**, **pare-feu**, **NAT**,
+**switching** en allant chercher dans toutes les entêtes de ces couches.
+
+## Control plane
+
+Comme nous l'avons vu au début de cette partie, le **control plane** est
+responsable du routage : il détermine le chemin pris par les paquets. Deux
+possibilités s'offre alors à nous:
+
+ 1. un *control plane* dans chaque routeur (ce que nous avons jusqu'ici);
+ 2. un *control plane* centralisé qui pilote un ensemble de routeurs.
+
+Dans le premier cas il est nécessaire d'implémenter le routage par équipement
+individuellement, ce qui peut vite se réveller fastidieux. Dans le second cas,
+les routeurs utilisent un control place distant définis par logiciel. ainsi la
+configuration de tous les routeurs **est unifiée**.
+
+Pour rappel, le routage a pour objectif de déterminer le meilleur chemin à
+prendre pour un paquet donné. Le chemin est en fait un ensemble de routeur par
+lequel le paquet va passer. Le meilleur chemin peut avoir plusieurs sens,
+parlons nous de *moins cher*, de *plus rapide*, *moins congestionné*?
+
+### Algorithme de routage
+
+Il existe bien évidemment plusieurs algorithme de routage avec chacuns
+avantages et inconvénients par exemple :
+
+ * *statique*, les routes changent peu et lentement
+ * *dynamique*, les routes changent rapidement soit périodiquement soit en
+   réponse à des incidents;
+ * algorithme *link-state* ou chaque routeur voit la topologie complète avec les
+   coûts des différents liens;
+ * algorithme décentralisé *distant vector* ou les routeurs ne connaissent au
+   départ que les coûts des liens vers leurs voisins directs. C'est un
+   algorithme dynamique basé sur le calcul, et l'échange d'informations entre
+   routeurs voisins.
+
+
+#### Algorithme de Dijkstra
+
+C'est un algorithme centralisé ou les coûts vers tous les nœuds sont connus à
+l'avance via des messages de type `link-state broadcast`. Tous les nœuds
+détiennent **les mêmes informations**.
+
+Avec ces informations, nous pouvons alors calculer les chemins les *moins 
+chers*" depuis un nœud vers tous les autres. Nous obtenons alors une table de
+*forwarding* complète.
+
+Le processus est **itératif*, ainsi après un nombre \\(K\\) d'itérations., nous
+connaissons le meilleurs chemin vers \\(k\\) destinations. Voici cet algorithme:
+
+```
+// c(x,y) coût entre lien direct entre x et y
+// D[v]   estimation du coût du meilleur chemin vers v depuis la source
+// p(v)   nœud précédent sur le chemin de la source vers v
+// N``    ensemble de nœuds que notre algorithme connais via least-cost path
+
+/* Init */
+N` = u; //compute least-cost path from u to all others nodes}
+for all_node v 
+    if v in all_node()
+        D[v] = c(u,v);
+    else 
+        D[v] = INFINITE;
+
+do 
+    find w not_in N` such D[w] is minimal
+    add w to N`
+    update D[v] for all v adjacent tow and not in N`:
+        D[v] = min(D[v], D[w] + c(w,v))
+until all node in N`
+```
+
+#### Algorithme de Bellman-Ford
+
+Chaque nœud envoie régulièrement sa table de vecteur de distance et leurs coûts
+associés à ses voisins. Lorsque notre nœud reçoit les information de ses
+voisins, il mets à jour sa propre table de vecteurs de distances en réalisant
+des calculs. C'est un algorithme asynchrone, itératif et sans notification de
+l'extérieur.
+
+### Routage intra-ISP: OSPF
+
+Pour l'instant, tout ce que nous avons vu relève du **monde idéal** et ne passe
+pas à l'échelle pour *Internet*:
+
+ * tout le réseau est **identique**;
+ * le réseau est "**plat**".
+
+Dans la vrai vie l existe des **milliards** de destinations et tout un tas de
+**réseaux autonomes**. Il est donc impossible de stocker toutes ces information
+dans une sable de routage ni de gérer de façon unifiés tout ce beau monde. Il
+est donc nécessaire d'agréger des régions appelées **systèmes autonomes** abrégé
+*AS*. nous avons alors deux types de routages:
+
+ * **intra-AS** ou *intra-domaine* pour tout ce qui se trouve dans notre système
+   autonome, le protocole utilisé est forcément le même sur tous les routeurs de
+   notre domaine
+ * **inter-AS** ou *inter-domaine* qui représentens les liens entre différents
+   *AS*
+
+Les liens entre les *AS* sont réalisés par les routeurs de bordures.
+
+#### Protocoles intra-AS
+
+Les protocoles les plus communs sont:
+
+ * **RIP** pour *Routing Information Protocol*, les routeurs échange des
+   *distant vectors* classique toutes les 30 secondes -- n'est plus utilisé
+   aujourd'hui;
+ * **EIGRP** pour *Enhanced Interior Gateway Procolol* qui est lui aussi basé
+   sur les *distant vectors*, c'est à l'origine un protocole propriétaire de
+   Cisco mais ouvert en 2013;
+ * **OSPF** pour *Open Short Path First* qui est un protocole de type
+   *link-state*
+
+Dans le cadre de ce cours nous ne verrons qu'*OSPF* qui est le plus utilisé
+aujourd'hui.Chaque routeur annonce l'état de ces liens directement en utilisant
+le protocole IP (pas d'encapsulation de segment de la couche transport) à tous
+les autre routeur de l'*AS*. Les informations de coûts peuvent provenir de
+différentes métriques comme la bande passante, la latence etc.
+
+Au niveau sécurité ds échanges, tous les messages *OSPF* peuvent être
+authentifiés.
+
+*OSPF* propose deux niveau de **hiérarchie** :
+
+ * *backbone* interconnectant plusieurs zones;
+ * *local area* représentant une zone en particulier, plus localisée.
+
+L'état des liens, comprenant le couple *IP/masque* est enregistré dans une base
+de données. Cette ase est ensuite utilisée pour les calculs. La mise à jour se
+fait par des messages multicasts `link-state-advertisement`. Plusieurs types de
+paquets existent.
+
+ * `hello` pour la découverte des voisins, l'entetien des relations de
+   voisinages. Ces paquets sont envoyés toutes les 10 secondes, si aucune de
+   reponse n'est effectuées au bouts de 4 `hello`, alors l'hote est considéré
+   comme *downn*.
+ * `database description` pour synchroniser les bases de données avec ses
+   voisins.
+ * `link-state-request` pour demander des informations aux voisins.
+ * `link-state-advertisement` pour mettre à jour l'état des liens, il en existe
+   11 types différents de paquets:
+   * type 1: décrire les interfaces du routeur;
+   * type 2: décription ds routeur conectés à un segment (dans une même *area
+     OSPF);
+   * type 3: résumés des information envoyées depuis une autre *area*.
+   * etc.
+ * `link-state-update` qui contient plusieurs `LSA`
+ * `link-state-ack` pour l'acquitement d'un `LSR` ou d'un `LSA`
+
+OSPF est basé sur l'algorithme de Dijkstra: le plus court chemin. Il est calculé
+en fonction de la bande passante du lien. 100Mbit/s a un poind de 1, 10Mbit/s un
+poid de 10 (100/10) et 1000Mbit/s 0.1 (100/1000). Cependant le poind ne peut
+être inférieur à 1, donc 0,1 devient 1. Pour poivoir profiter des poids sur les
+liens suppieur à 100Mbit/s, il faut alors **modifier manuellement la valeur de
+base**.
+
+#### Protocole inter-AS: BGP
+
+BGP pour *Border Gateway Protocol* annonce l'existance d'un réseau, d'une
+destination. Il permet d'obtenir des informations  de routage de ses voisins via
+**eBGP**, de déterminer les routes vers les autres réseaux en fonction des
+information de disponibilités et des politiques ou encore d'avertir ses voisins
+de ses propres réseaux / disponibilités. Par le biais **d'iBGP** il propage les
+information obtenues de ses voisins à tous les routeur *intra-domaine*.
+
+*BGP** utilise les sessions établies via TCP pour communiquer. Plusieurs type de
+messages sont disponibles:
+
+ * **open** pour ouvrir une connexion TCP vers un  hôte BGP distant et
+   s'authentifier;
+ * **update** pour avertir de changement que se soit suppression, ajout ou
+   modification;
+ * **keepalive** pour maintenir la session ouverte;
+ * **notification** pour notifier d'une erreur ou fermer une session.
+
+Une annonce contient un *préfixe* plus un *attribut*. Les deux attributs les
+plus importants sont:
+
+ * *as-path* qui représente le chemin;
+ * *next-hop* qui indique le routeur spécifique pour arriver à une destination
+   définie.
+
+BGP utilise des politique de routage pour déterminer les chemins à annoncer.
+
+Principe de la **patate chaude**: BGP choisira de faire sortir le paquet le plus
+vite possible de son infrastructure, ne prenant pas en comptes les coûts
+intra=domaines
+
+
+### SDN *Software Defined Network
+
+Depuis 2005, des recherches sont menées afin de trouvwr de nouvelles approches
+réseaux. Le *control plane* et le *data plane* se faisaient traditionnellement
+sur les routeurs. Maintenant le controle est éloigné et installe à distance les
+tables de routages. Ainsi la gestion du réseau est facilitée (configuration en
+un seul point, plus de flexibilité, contrôle *openflow* et architcture
+indépendate du vendeur --interopérable).
+
+Le *SDN controller* prend alors trois fonctions:
+ 
+ * *interface layer* offrant l'accès aux API;
+ * *network state management* prenant en compte les information des liens, du
+   *switching;
+ * les communication via les API (Openflow, SNMP).
+
+#### le protocole Openflow
+
+Il s'intercate entre les controlleurs et les *switches* et utilise TCP. Il
+comporte trois types de messages:
+
+ * `controller` vers les `switch` pour demander des information, envoyer des
+   configurations etc.;
+ * asynchrone avec par exemple les paquets à traiter par le conrolleurs,
+   notifier la suppression d'une entrée dans la *table de forwarding*
+ * symetrique
+
+#### ICMP *Internet Control Message Protocol*
+
+C'est un protoboe de contrôle utilisé pour obtenir des informations au niveau du
+réseau (*unreachable host|protocol|port*, *ping*). Il s'intercate entre les
+couches réseau et transport.

content/reseaux_protocoles/5_couche_liaison/index.md

@@ -213,3 +213,55 @@ labels de taille fixe entre l'entête Ethernet et la charge utile.
 
 Le routeur MPSL regarde donc le label pour décider quoi faire avec le paquet: le
 routage est plus rapide (pas de décapsulation) et plus flexible.
+
+## Les réseaux sans fils
+nous distingons deux type de fonctionnements principaux:
+
+ 1. **infrastructure**: une station de base est utiliée par tous les terminaux
+    du réseaux sans-fils pour communiquer;
+ 2. **ah-hoc**: les terminaux de débrouillent entre eux pour s'interconnecter.
+
+### Caractéristiques
+
+L'**aténuation** est la caractéristiques celon laquelle le signal perd en
+puissance à mesure qu'il se propage. Plus la distance est élevée et plus la
+fréquence est haure, plus le signal diminue en intensité (*path loss*).
+
+Le **mutltipath propagation** est lié au fait que le signal sans fils peut être
+réfléchit pat l'environnement (mur par exemple). Les paquets issus de cette
+réflexion vont être reçus avec du délais, il faut qlors que les équipements le
+gèrent.
+
+Le **bruit**: des signaux sont envoyés par d'auyres équipement dans le rayon
+d'action de notre réseau. Il faut alors mesuré le **Rapport signal bruit**. Plus
+il est élevé et meilleure est la qualité de réception.
+
+Les **équipements cachés** Si un obstaacle empêche A de voir C alors que A voit
+B qui voit C, alors il y a des riques de collisions de paquets.
+
+### 802.11
+
+C'est un protocole basé sur l'*infrastructure*, la station de base est
+matérialisée par un **point d'accès**. Le spectre est divisé en canaux
+(*channel*) afinde géger les interférences. chaque équipement doit s'associer
+avec le point d'accès et s'authentifier.
+
+Avant de pouvoir choisir un point d'accès, il faut realiser un scan, deux mode
+sont disponibles:
+
+ * *passive scan*: le point d'accès envoie des trames spécifique pour s'annoncer
+   (*beacon*)
+ * *active scan*: les équipement sont à l'origine de la connexion par le biais
+   des `prove request frame` auxquelle le point d'acces répond par
+   une`association request`;
+
+Cette norme sans fils utilise CSMA (*sense before send*) mais sans détection de
+collision pour éviter les problèmes de medium (aténuation, terminaux cachés, 
+...). Il utilise CSMA/CA pour *collision Avoidance* (l'hôte envoie une 
+`request-to-send`, le point d'accès envoie alors un `CTS` en *broadcast*
+avertissant alors les autres équipement de la transmission à venir.
+
+#### Mobilité dans un même réseau
+
+Si le changement se fait au niveau du *BSS* mais sans changement de sous-réseau,
+alors c'est au *switch* de gérer car les adresses *MAC* sont les mêmes.