diff --git a/content/projet_programmation/9_principes_SOLID/index.md b/content/projet_programmation/9_principes_SOLID/index.md new file mode 100644 index 0000000..d98e176 --- /dev/null +++ b/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. diff --git a/content/reseaux_protocoles/4_couche_reseau/index.md b/content/reseaux_protocoles/4_couche_reseau/index.md new file mode 100644 index 0000000..57fc7b8 --- /dev/null +++ b/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. diff --git a/content/reseaux_protocoles/5_couche_liaison/index.md b/content/reseaux_protocoles/5_couche_liaison/index.md index 7888b9c..82775ee 100644 --- a/content/reseaux_protocoles/5_couche_liaison/index.md +++ b/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.