Cisco Networking: OSI Model Layer 5 - Session - dummies

Sessionlaget i Open System Interconnection (OSI) -modellen definerer hvordan dataene formateres mellom enhetene på hver side av lenken. Dette er effektivt måten de opprettholder en åpen kanal mellom de to enhetene på. På lavere nivåer av OSI-modellen er det imidlertid ingen permanent forbindelse, men snarere en rekke korte datautbrudd sendes frem og tilbake.

Sessionslaget opprettholder en samtale over mange av disse datautbruddene; Faktisk kan det ta flere utbrudd av data som går frem og tilbake bare for å etablere strukturen som vil bli fulgt for den økten.

Et ekte eksempel på øktlaget kan være et par spioner som utveksler meldinger. De måtte etablere en operasjonsordre som ville bli brukt til å sende kodede meldinger frem og tilbake. Denne prosessen for å sende meldingene kan betraktes som en øktlagsoperasjon og kan inkludere trinn som å bruke en avtalt chiffer for å kode inn meldingen.

Windows-fildeling har en øktlagskomponent når du etablerer økter, som vist i den følgende figuren.

Målet med klientdatamaskinen i figuren nedenfor er å få en liste over aksjer på serveren, men den må følge en oppsettprosess for å få de ønskede dataene. Serveren i denne prosessen er i konstant tilstand for å lytte etter tilkoblingsforespørsler; Etter hvert som klienten starter prosessen, går sessionsoppsettprosessen slik:

1. Klienten sender en øktforespørsel til serveren.

2. Serveren bekrefter forespørselen og inkluderer i bekreftelsen en liste over alle støttede øktprotokoller.

   I tilfelle av Windows-serveren inneholder listen eldre, mindre sikre alternativer som LANMAN, samt nyere og sikrere NT LANMAN versjon 2 (NT LM 2).

   

3. Klienten vurderer listen over støttede protokoller og velger den sikreste øktprotokollen som den også støtter.

   På dette punktet sender den serveren den valgte øktprotokollen som de skal bruke og forespørsler om å utføre en godkjenning. I dette tilfellet vil verifiseringen verifisere et brukernavn og passord fra serverens brukerkonto database.

4. Serveren oppretter en tilfeldig streng av tegn som er inkludert i passordutfordringen og sender den til klienten.

5. Klienten tar passordutfordringsstrengen og bruker sitt eget passord som en krypteringsnøkkel for å kryptere den tilfeldige strengen.

6. Den nå krypterte strengen sendes deretter tilbake til serveren i en pakke med godkjenningsinformasjon, som også inneholder brukerens brukernavn.

7. Serveren henter brukerens passord fra sin brukerkonto database, og bruker passordet som krypteringsnøkkel for å kryptere den tilfeldige tegnstrengen som den sendte til klienten i utfordringsstrinnet (trinn 4).

8. Serveren sammenligner resultatet det beregnet til resultatet som er oppført i godkjennings-legitimasjonspakken.

9. Hvis resultatene samsvarer, slik de gjør i illustrasjonen, sendes en bekreftelse (ACK) til klienten, og økten er nå aktiv. men hvis de ikke samsvarer, sender serveren en negativ bekreftelse (NACK).

   Hvis klienten mottar en NACK, vil den gå tilbake til trinn 3 og utstede en ny autentiseringsforespørsel.

10. På dette tidspunktet er økten opprettet, og klienten kan utføre forespørselen for listen over aksjer som er på serveren, som sannsynligvis vil føre til en forespørsel fra en liste over filer, og deretter innholdet i en bestemt fil.

    Alle disse fremtidige operasjonene vil bli gjennomført selv om denne ene økten som nettopp er opprettet.

Trinn 10 i forrige liste viser endringen fra øktlaget og presentasjonslaget. På øktlaget ble kommunikasjonskanalen til Windows-serverkomponentene etablert, men da den faktiske forespørselen ble sendt til listen over aksjer som var tilgjengelige på serveren, brukte forespørselen siktlagskommunikasjonskanalen, men ble faktisk levert gjennom til presentasjonen lag og i siste instans applikasjonslaget Windows Server-tjenesten.