Video: Netwerken voor beginners deel 1: Infrastructuur en IP plan 2024
De sessielaag van het Open System Interconnection (OSI) -model bepaalt hoe de gegevens tussen beide apparaten worden geformatteerd van de link. Dit is effectief de manier waarop ze een open kanaal tussen de twee apparaten onderhouden. Op lagere niveaus van het OSI-model is er echter geen permanente verbinding, maar een reeks korte bursts van gegevens die heen en weer worden verzonden.
De sessielaag onderhoudt een gesprek over veel van deze bursts van gegevens; in feite kan het meerdere bursts van data nodig hebben om heen en weer te gaan, alleen om de structuur vast te stellen die voor die sessie zal worden gevolgd.
Een realistisch voorbeeld van de sessielaag kan een spionnenpaar zijn die berichten uitwisselt. Ze zouden een volgorde van bewerkingen moeten vaststellen die zou worden gebruikt om gecodeerde berichten heen en weer door te geven. Dit proces voor het doorgeven van de berichten kan worden beschouwd als een sessie-laagbewerking en kan stappen omvatten zoals het gebruiken van een afgesproken cijfer om het bericht te coderen.
Windows-bestandsdeling bevat een sessielaagcomponent bij het tot stand brengen van sessies, zoals weergegeven in de volgende afbeelding.
Het doel van de clientcomputer in de onderstaande afbeelding is om een lijst met shares op de server te krijgen, maar deze moet een sessie-instellingsproces volgen om de gewenste gegevens te krijgen. De server in dit proces bevindt zich in een constante staat van luisteren voor verbindingsverzoeken; wanneer de client het proces opstart, verloopt het installatieproces van de sessie als volgt:
-
De client verzendt een sessieverzoek naar de server.
-
De server bevestigt de aanvraag en neemt in de bevestiging een lijst op van alle ondersteunde sessieprotocollen.
In het geval van de Windows-server bevat de lijst oudere, minder veilige opties zoals LANMAN, evenals de nieuwere en veiligere NT LANMAN-versie 2 (NT LM 2).
-
De client beoordeelt de lijst met ondersteunde protocollen en kiest het meest veilige sessieprotocol dat ook wordt ondersteund.
Op dit moment verzendt het de server het gekozen sessieprotocol dat ze zullen gebruiken en verzoekt om een authenticatie uit te voeren. In dit geval verifieert de authenticatie een gebruikersnaam en wachtwoord van de gebruikersaccountdatabase van de server.
-
De server maakt een willekeurige reeks tekens die deel uitmaakt van de wachtwoorduitdaging en verzendt deze naar de client.
-
De client neemt de wachtwoorduitdagingsreeks en gebruikt zijn eigen wachtwoord als versleutelingscode om de willekeurige tekenreeks te coderen.
-
De nu gecodeerde reeks wordt vervolgens teruggestuurd naar de server in een authenticatie-inlogpakket dat ook de gebruikersnaam van de gebruiker bevat.
-
De server haalt het gebruikerswachtwoord op uit de gebruikersaccountdatabase en gebruikt het wachtwoord als de coderingssleutel om de willekeurige tekenreeks die het naar de client stuurde in de uitdagingsstap te versleutelen (stap 4).
-
De server vergelijkt het resultaat dat is berekend met het resultaat dat wordt vermeld in het verificatie-referentiepakket.
-
Als de resultaten overeenkomen, zoals in de illustratie, wordt een bevestiging (ACK) naar de client verzonden en is de sessie nu actief; maar als ze niet overeenkomen, stuurt de server een negatieve bevestiging (NACK).
Als de client een NACK ontvangt, gaat deze terug naar stap 3 en geeft een nieuw authenticatieverzoek af.
-
Op dit punt wordt de sessie ingesteld en de client kan de aanvraag uitvoeren voor de lijst met shares die zich op de server bevinden, wat waarschijnlijk zou leiden naar een lijst met bestanden en vervolgens naar de inhoud van een specifieke het dossier.
Al deze toekomstige operaties worden uitgevoerd tijdens deze enkele sessie die zojuist is gemaakt.
Stap 10 in de voorgaande lijst toont de wijziging van de sessielaag en de presentatielaag. Op de sessielaag werd het communicatiekanaal met de Windows-servercomponenten vastgesteld, maar omdat het daadwerkelijke verzoek werd ingediend voor de lijst met beschikbare shares op de server, gebruikte het verzoek het communicatiekanaal van de sessielaag, maar werd het daadwerkelijk doorgeleverd aan de presentatie. laag en uiteindelijk de toepassingslaag Windows Server-service.
