Универзитет Сингидунум
Факултет за информатику и рачунарство

Рачунарске мреже

Младен Веиновић, Александар Јевремовић

6.2.1.2.2. Управљање везом


Протокол за пренос хипертекста не дефинише стање веза (енгл. stateless), нити се то захтева од стране клијентске и серверске имплементације. То у пракси значи да сервер на сваки захтев гледа ван контекста, односно да се за сваки нови захтев (од стране истог клијента ка истом серверу, чак и ка истом или директно референцираном ресурсу) остварује потпуно нова веза. Овакав приступ се могао сматрати оптималним (по погледу једноставности протокола и његове имплементације) у раним фазама развоја Веба када се он углавном користио за пристум једноставним, статичним документима. Међутим, појавом Веб апликација контекст сесије је постао захтевана функција протокола за пренос хипертекста. Контекст сесије код Веб апликација је значајан јер самој апликацији пружа информације о томе да ли се корисник успешно ауторизовао, да ли се налази у неком од корака сложене активности, и томе слично.

Подршка за сесију није уграђена директно у протокол за пренос хипертекста већ је реализована у виду спецификације функција клијентске и серверске имплементације. Серверска имплементација је проширена посебним функцијама које омогућавају контекст сесије кроз резервисање наменског, трајнијег меморијског простора за сваког појединачног клијента. Са друге стране, задатак клијента јесте чување и достављање идентификатора сесије при сваком захтеву ка серверу.

Идентификатор сесије генерише сервер поштујући одређена функционална и безбедносна правила. Након генерисања идентификатора потребно га је доставити клијенту, а затим наводити при сваком захтеву у току те сесије. У пракси су популарна два начина чувања и прослеђивања идентификатора сесије серверу. Први начин подразумева аутоматизовано додавање идентификатора сесије делу резервисаном за упит свих униформних локатора ресурса у документима који се шаљу клијенту. Лошу страну оваквог приступа чине проблеми који произилазе из потребе за изменом свих хипертекстуалних докумената који се шаљу клијенту. Други приступ, који се данас најчешће среће у пракси, подразумева размену идентификатора сесије у виду колачића протокола за пренос хипертекста.

Колачићи (енгл. cookies) протокола за пренос хипертекста представљају механизам за дефинисање стања везе остварене протоколом за пренос хипертекста. Они се размењују у оквиру заглавља порука протокола за пренос хипертекста, а дефинисани су називом и вредношћу (садржајем). Колачићи се иницијално креирају на страни сервера и шаљу се клијенту који их, затим, шаље серверу у оквиру наредних захтева. За слање колачића од клијента ка серверу додаје се Set-Cookie поље у заглавље поруке, а за слање од клијента ка серверу поље Cookie. У оквиру једне поруке може се послати више колачића.

Поред назива и садржаја колачића, за сваки од њих се дефинише и његов домет - који је период важења колачића и на које домене и шеме униформних идентификатора ресурса се он примењује. Вредност колачића је могуће мењати у току сесије једноставним поновним задавањем његове нове вредности. У ситуацијама када је потребно укинути одређени колачић (на пример, у ситуацији када је потребно прекинути сесију) то се чини тако да сервер поново задаје колачић са истим параметрима (називом колачића, доменима и шемама), али са временом истицања у прошлости. Колачићи сами по себи не представљају безбедносну претњу за клијента и сервер, с тим да су се због одређених пропуста у имплементацијама за њих раније везивали безбедносни и приватносни проблеми.


Слика 5.2.1.2.1-5. Пример чувања идентификатора сесије у виду колачића

Меморијски простор сесије омогућава формирање контекста између различитих захтева корисника у току ње. Прекид сесије је могућ на два начина: иницирањем прекида од стране корисника и неактивношћу корисника у току времена задатог у подешавању сервера (на пример, подразумевана вредност од 1.440 секунди на Apache серверима са PHP програмским језиком). Безбедносни проблем који је везан за сесије код Веб апликација јесте њихова отмица (енгл. session hijacking), односно преузимање тренутног стања корисничке апликације од стране нападача.

У раним фазама Веба на њему су се углавном налазили једноставни хипертекстуални документи, без укључених спољних садржаја (слика, додатних технологија и томе слично), јер су и сами кориснички клијенти били једноставне конзолне апликације. У складу са тим, раније верзије протокола за пренос хипертекста подразумевале су упостављање и раскидање везе протокола транспортног слоја за сваки захтев/одговор пар порука.

Данас, међутим, овакво понашање не представља оптимално коришћење комуникационих канала јер хипертекстуални документи често укључују велики број спољних садржаја (слике, дефиниције стилова, и сл. који се најчешће налазе на истом серверу), а сам протокол за контролу преноса подразумева додатних пет порука за сваки захтев/одговор (три поруке за успостављање везе и две поруке за њен раскид).


Слика 5.2.1.2.1-6. Пример конзолног Веб браузера

У верзији 1.1 протокола за пренос хипертекста представљена је могућност успостављања трајних веза (енгл. persistent connection), односно веза којима се након успостављања може послати више захтева и одговора. Коришћење трајних веза нуди бројне погодности:

  1. смањује се број успостављених веза протокола за контролу преноса, што смањује заузеће централног процесора и меморије на клијенту и серверу, као и заузеће комуникационих канала;

  2. смањује се време потребно за учитавање докумената кроз уклањање времена потребног за успостављање и раскид појединачних веза протокола на транспортном слоју;

  3. омогућава се слање вишеструких захтева истом везом, без потребе да се пре слања наредног захтева чека на одговор на претходни, што умањује време потребно за учитавање докумената са великим бројем спољних садржаја;

  4. олакшава се будући развој протокола и придружених технологија елиминисањем пенала у виду затварања везе протокола за контролу преноса због покушаја коришћења функционалности које друга страна још увек не подржава.

Коришћење трајних веза се у верзији 1.1 протокола подразумева, а у случају да клијент или сервер не подржавају ову верзију и трајне везе, комуникација се врши успостављањем појединачних веза за сваки пар порука. За иницирање затварања трајне везе користи се параметар Connection у заглављу поруке. Наравно, клијент и сервер се сматрају слободним да самоиницијативно затворе везу после одређеног времена неактивности друге стране.

 
Internet marketing
Преузмите ПДФ целе књиге
Заштита у рачунарским мрежама
Овладајте Веб развојем и РНР програмирањем
Овладајте савременим базама података
Обратите се ауторима:
Ваша имејл адреса:
Ваше име:
Порука:
Безбедносни код:
Captcha
Research Gate
Слика [Chapter:Number]