diff --git a/content/projet_programmation/9_principes_SOLID/index.md b/content/projet_programmation/9_principes_SOLID/index.md deleted file mode 100644 index d98e176..0000000 --- a/content/projet_programmation/9_principes_SOLID/index.md +++ /dev/null @@ -1,185 +0,0 @@ ---- -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 deleted file mode 100644 index 57fc7b8..0000000 --- a/content/reseaux_protocoles/4_couche_reseau/index.md +++ /dev/null @@ -1,443 +0,0 @@ ---- -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 82775ee..7888b9c 100644 --- a/content/reseaux_protocoles/5_couche_liaison/index.md +++ b/content/reseaux_protocoles/5_couche_liaison/index.md @@ -213,55 +213,3 @@ 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.