Cisco Networking: couche de modèle OSI 5 - séance

La couche session du modèle Open System Interconnection (OSI) définit comment les données sont formatées entre les dispositifs de chaque côté de la liaison. Ceci est effectivement la manière selon laquelle ils maintiennent un canal ouvert entre les deux dispositifs. Cependant, à des niveaux inférieurs du modèle OSI, il n'y a pas de connexion permanente, mais plutôt une série de courtes rafales de données envoyées avant et en arrière.

La couche session maintient une conversation sur un grand nombre de ces éclats de de données en fait, il peut prendre plusieurs salves de données qui vont et viennent juste d'établir la structure qui sera suivie pour cette session.

Un exemple concret de la couche de session pourrait être une paire d'espions échange de messages. Ils auraient à établir un ordre des opérations qui pourraient être utilisés pour transmettre des messages codés avant et en arrière. Ce procédé pour faire passer les messages pourrait être considérée comme une opération de couche de session et peut inclure des mesures telles que l'utilisation d'un convenu de chiffrement pour coder le message.

Le partage de fichiers Windows dispose d'un composant de couche de session lors de l'établissement des sessions, comme le montre la figure suivante.

Le but de l'ordinateur client dans la figure ci-dessous est d'obtenir une liste des actions sur le serveur, mais il doit suivre un processus de configuration de session afin d'obtenir les données souhaitées. Le serveur de ce processus est dans un état constant de l'écoute pour une connexion requests- que le client démarre le processus off, le processus de configuration de session fonctionne comme ceci:

1. Le client envoie une demande de session au serveur.

2. Le serveur reconnaît la demande et comprend dans l'accusé une liste de tous protocole de session en charge.

   
   
   
   
   

   Dans le cas du serveur Windows, la liste inclut les anciens options, moins sécurisés tels que LANMAN, ainsi que la version plus récente et plus sûr NT LANMAN 2 (NT LM 2).

   

3. Le client examine la liste des protocoles pris en charge et choisit protocole de session la plus sûre qu'il prend également en charge.

   À ce stade, il envoie au serveur le protocole de session choisie qu'ils utiliseront et les demandes de procéder à une authentification. Dans ce cas, l'authentification de vérifier un nom d'utilisateur et mot de passe de la base de données du compte utilisateur du serveur.

4. Le serveur crée une chaîne de caractères aléatoires qui est inclus dans le défi de mot de passe et l'envoie au client.

5. Le client prend la chaîne de défi de mot de passe et utilise son propre mot de passe comme une clé de cryptage pour crypter la chaîne aléatoire.

6. La chaîne cryptée maintenant est ensuite envoyé vers le serveur dans un paquet de crédits d'authentification qui comprend également le nom de l'utilisateur.

7. Le serveur récupère le mot de passe de l'utilisateur à partir de sa base de données de compte d'utilisateur, et utilise le mot de passe que la clé de cryptage pour crypter la chaîne de caractères aléatoire qu'il a envoyé au client dans l'étape de défi (étape 4).

8. Le serveur compare le résultat, il calcule le résultat figurant dans le paquet des informations d'authentification.

9. Si les résultats correspondent, comme ils le font dans l'illustration, puis un accusé de réception (ACK) est envoyé au client et la session est maintenant active- mais si elles ne correspondent pas, le serveur envoie un accusé de réception négatif (NACK).

   Si le client reçoit un NACK, alors il serait revenir à l'étape 3 et émettre une nouvelle requête d'authentification.

10. À ce stade, la session est mis en place, et le client peut effectuer la demande de la liste des actions qui sont sur le serveur, qui serait susceptible de conduire à une demande d'une liste de fichiers, puis le contenu d'un fichier spécifique.

    Toutes ces opérations futures seraient effectuées si cette seule session qui vient d'être créé.

Etape 10 dans la liste ci-dessus montre l'évolution de la couche de session et la couche de présentation. A la couche de session, le canal de communication pour les composants de serveur Windows a été créé, mais que la demande réelle a été soumis pour la liste des actions disponibles sur le serveur, la demande a utilisé le canal de communication de couche de session, mais a été effectivement remis grâce à la présentation couche et finalement le service Windows Server de la couche application.