За ориентираните към връзката транспортни протоколи се реализира функцията управление на потока. Подобно на каналното ниво, транспортното ниво осигурява достъпа до мрежовите съединения.
За дейтаграменните протоколи на мрежово ниво е необходима допълнителна функционалност за осигуряване на достоверно приложно обслужване. Особеността е, че тази функция е реализирана от транспортния протокол. Транспортното ниво буферира мрежовото съединение с цел поддържането на множествените приложни заявки (множествен достъп). За тази цел транспортните протоколи използват логика за управление на “независими” буфери, които се наричат Socket (позиция). Socket е област от паметта. Ресурс, който се заема динамично от транспортния протокол със средствата на текущата операционна система.
Механизмът за обработка на Socket е представен чрез фиг.6.3.
-
RAM
|
App1(приложение)
|
App2(приложение)
|
|
Socket N@1, T@1
|
Socket N@1, T@2
|
|
Фиг. 6.3
Приложенията App1 и App2, подават заявки за транспортно обслужване, съответно в моменти от времето t1 и t2 . Заявките са за съединения с крайни компютри с целеви мрежови адреси N@k и N@j. За поддържане на заявките е необходимо установяването на две мрежови съединения: N@k - N@1 и N@j - N@1 . Транспортният протокол осигурява два свободни буфера (socket), съответно с транспортни адреси T@1 (за приложение App1) и T@2 (за приложение App2). По този начин, мрежовите пакети от двете приложни сесии, насочени към мрежов N@1 се разделят от транспортното ниво и достоверно се насочват към съответното приложение
6.3.Представители на транспортните протоколи.
Функционалността на транспортните протоколи зависи от възможностите на мрежовото ниво да осигури ориентирано към връзката мрежово обслужване. Ако за протоколния стек X.25 необходимостта от функционалност на транспортно ниво се свежда до поддържането на частни сценарии за мрежово обслужване, то при IP - протоколният стек, дейтаграмния характер на мрежовото съединение предполага развиването на “богат” функционално транспортен слой.
В IP - протоколния стек (виж. 5.4.5) транспортният слой е изграден от два протокола TCP(Transport Control Protocol) и UDP(User Datagram Protocol) – фиг.6.4[].
фиг.6.4
На фиг.6.5 е представен формата на TCP-протоколната спецификация
фиг.6.5
Предназначението на полетата на TCP-сегмента е:
-
Source Port—Идентификатор на порта-инициатор на транспортното съединение;
-
Destination Port – Идентификатор на целевия порт
-
Sequence Number—Последователен номер на сегмента
-
Acknowledgment Number—Номер за потвърждение
-
HLEN—Размер на пакета в 32-битови думи
-
Reserved—Не се използва
-
Code Bits—Използва се като указател за край на сесията на обмен
-
Window—Размер на прозореца, брой октети предадени без потвърждение
-
Checksum—Контролна сума на заглавната част и данните
-
Urgent Pointer—Указател за спешни данни
-
Option—максимален размер на TCP сегмента
-
Data—Приложно съобщение, данни за TCP- протокола
фиг.6.6
И двата протокола TCP и UDP използват идентификатори за номер на порт (socket) за целите на достоверния обмен на информацията с протоколите и услугите от “високите” нива – фиг.6.6 Портовете се използват за целите на мултиплексирането на мрежовото съединение.
Мрежовите приложенията се разработват в условията на известна схема за разпределение на портовете, дефинирана в препоръка RFC 1700. Например, отдалеченият терминален достъп (приложната услуга TELNET) се реализира с използването на стандартизиран порт номер 23. Сесиите на обмен, за които няма предвиден стандартно номер се реализират на базата на случайно присвояване на номер на порт при постъпване на заявката от множеството на незаетите портове.
Разпределението на TCP и UDP портовете е представено на фиг.6.7
фиг.6.7
Някой от портовете са резервирани от двата протокола и приложенията не могат да използват тези портове. Принципа на разпределение на портовете е следния:
-
портове с номера до 255 са предоставени за общо използване.
-
Портове с номера от 256 до 1023 са за системни приложения.
-
Портове с номера над 1023 са недефинирани.
фиг.6.8
Крайните компютри използват портовете , за да достигнат до желаното приложени, като в полето за целеви порт (Dest. port) се указва номера на порта, с който се адресира на транспортно ниво приложението – номер 23 – приложение TELNET – фиг.6.8.
Установяването на TCP съединението в двете крайно точки (компютри) се реализира на три стъпки по последователността, показана на фиг.6.9
Фиг.6.9
Процедурата е фактически тест на логиката за потвърждение на протокола, като се обменя един празен сегмент в двете посоки и се изчаква двупосочно потвърждение за него преди да стартира обмена на реална информация.
Протокола TCP поддържа два механизма за потвърждение, които се различава по размера на прозореца. При размер на прозореца =1, се реализира единично потвърждение, при размер на прозореца по-голям от единица потвърждението е от тип “пълзящ” прозорец – фиг.6.10
фиг.6.10
Двата подхода се прилагат в зависимост от типа на приложната сесия, качеството на мрежовото обслужване и допълнителни системни изисквания за надеждност и на транспортното съединение.
Една примерна процедурна последователност за дуплексно управление на потока сегменти при TCP е представена на фиг.6.11
фиг.6.11
В полето за номер на сегмента се записва номера на текущо изпратения сегмент, а в полето за потвърждение се указва номера на сегмента, който се очаква да бъде предаден, с което се потвърждава текущо предавания сегмент.
На фиг.6.12 е представен формата на UDP-сегмента
фиг.6.12
Сравнявайки този формат с формата на TCP сегмента (фиг.6.5) се наблюдава отсъствие на полета за контрол на потока и корекция на грешки. Това е характерно за дейтаграмните протоколи. Във функционалността на сегмента е съхранена възможността за мултиплексиране на мрежовите съединения
Приложните услуги основани на базата на IP-протоколния стек са представени на фиг. 6.13
ПРИЛОЖНИ УСЛУГИ
|
HTTP
|
SMTP
|
FTP
|
TELNET
|
SNMP
|
UDTP
|
и т.н.
|
TCP
|
UDP
|
|
|
Internet IP v 4.0
|
Фиг.6.13
Една част от услугите изискват ориентирано към връзката мрежово съединение и се поддържат на транспортно ниво от протокол TCP:
Сподели с приятели: |