Модул tcp/ip компютърни комуникации



Дата25.08.2016
Размер247.96 Kb.
#7258

Модул 3. TCP/IP-стек



1.1.1.Мрежов протокол IP (Internet Protocol).


Структурата на протоколния стек IP и мястото му в еталонната архитектура е представена на фиг.5.14

фиг.1.1

Мрежовото ниво на протоколния стек TPC/IP включва протоколите, предствени на фиг.1.1:



IP (Internet Protocol) e дейтаграмен мрежов протокол, осигуряващ несвързано мрежово обслужване. IP е протокол, който осигурява маршрутизирането на дейтаграмите от адреса-източник до целевия адрес, без да носи отговорност за достоверността на преноса на информацията и отстраняването на възникнали при предаването грешки. Протокола поддържа йерархична адресна логика и осигурява глобален обмен на еднопосочни съобщения (дейтаграми).

ICMP (Internet Control Message Protocol) e протокол за обмен на служебни съобщения на мрежово ниво. Използва се за управление и диагностика на състоянието на мрежовите съединения и обработване на аварийни ситуации.

ARP (Address Resolution Protocol) e протокол за намиране на адресно съответствие по валиден IP адрес. Той съпоставя IP (мрежовия адрес) на системата с нейния канален (физически) адрес (МАС-адрес).

RARP (Reverse Address Resolution Protocol) e протокол за намиране на адресно съответствие по валиден MAC адрес. Този протокол извежда съответствието между известен канален (физически) адрес (МАС-адрес) и присвоения на системата IP-адрес (мрежов адрес)

1.1.2.Структура на IP адреси.


Адресната логика на протокол IP е йерархична. Адресното поле на протоколната спецификация е 32-битово като са дефинирани 3 базови формата (класове) адреси A,B, и C. Всеки клас се интерпретира и използва за адресиране в условията на различни по структура и размерност мрежови конфигурации - фиг.5.15

Първите 4 бита от адреса определя класа на мрежа. Останалите 24 бита се разделят на две части: мрежов идентификатор (network identifier - netid) и идентификатор на краен компютър (host identifier - hostid).

Адресите от клас А са със 7-битово поле на netid и 24-битово поле за hostid.

Адресите от клас B са с 14-битово поле на netid и 16-битово поле за hostid.

Адресите от клас C са с 21-битово поле на netid и 8-битово поле за hostid.

Клас А-адресите се използват при мрежови конфигурации с голям брой крайни компютри (до 224), докато клас C-адресите позволяват идентификация на голям брой подмрежи с относително малко крайни компютри във всяка от подмрежите (до 256). Един типичен пример за клас А мрежа ARPANET, a пример за клас C мрежа е една малка корпоративна мрежа в завод, училище, общинска администрация и т.н.

Когато полето hosted е нула , то адреса се нарича адрес на мрежа (подмрежа). Когато полето hosted е запълнено с 1, то адреса , който се формира адресира едновременно всички крайни компютри в текущата. Такъв адрес се нарича общ или групов адрес (broadcast address).

За целите на по-ефективното и разбираемо представяне на IP адресите, 32-битовия адрес е разделен на 4 октета, като стойността на всеки октет се представя с дедетичния си еквивалент. Октетите се разделят с точка, например

00001010 00000000 00000000 00000000 = 10.0.0.0 = Клас А : netid = 10

(ARPANET)

10000000 00000010 00000011 00000011 = 128.2.3.3 = Клас B : netid=128.2

hosted=3.3

11000001 00000000 00000101 11111111 = 193.0.5.256 = Клас C : netid= 193.0.5

hosted=до всички

крайни компютри

в подмрежа 193.0.5

(broadcast address)

1.1.3.Формат на IP дейтаграмите


Мрежовият протокол IP поддържа формат на пакетите (дейтаграмите), предствен на фиг.5.16

Ф
Битова последователност (0-15)
ормат на IP пакета






0







3

4







7

8







11

12







15

Version

Header Length

Type of Service

Total Length

Identification

D

M

R

Fragment Offset

Time to Live

Protocol

Header Checksum

Source IP address

Source IP address

Destination IP address

Destination IP address

Options

Options

Data

Фиг. 1.2

Описание на полетата на IP пакета (datagram):

1) Version – версия;

2) Header Length – дължина на заглавната част;

3) Type of Service – тип на услугата;

4) Total Length – обща дължина;

5) Identification – идентификация;

6) Fragment Offset – отместване на фрагмента;

7) Time to Live – време на живот;

8) Protocol – протокол;

9) Header Checksum – контролна сума на заглавната част;

10) Source IP address – IP адрес на източника;

11) Destination IP address – IP адрес на получателя;

12) Options – допълнение;

13) Data – потребителски данни.


  1. Version – версия съдържаща текуща версия на IP протокола. Текущата версия е 4-та - IP v.4

  2. Header Length – дължина на заглавната част – съдържа действителния размер на заглавието на пакета, представен като брой 32-битови думи. Минималната дължина на пакета, ако не се използват допълнителните полета е 5 32-битови думи.

  3. Type of Service – тип на услугата – поле, в което компютъра-източникът заявява тип на мрежовата услугата за текущата приложна сесия: висока надеждност; минимално времезакъснение; висока пропускателна способност; прилагане на схема с приоритети.

  4. Total Length – пълна дължина на пакета (заглавната част и потребителските данни). Максимално допустимия размер на пакета е 65 535 бита

  5. Identification – идентификация – обикновено едно съобщение се предава под формата на поредица от няколко пакета. Това поле служи идентификация за принадлежност на пакетите към едно и също приложно съобщение.

Битове D,M и R – свързани са с т.н. фрагментация на данните.

D – Don’t Fragment – не фрагментирай този пакет. Ако този флаг е усановен в “1” при достигане на мрежа с по-малък размер на пакета, текущия пакет няма да бъде фрагментиран, а ще бъде отхвърлен от тази мрежа. Налага се маршрутизиране по друг път.

M More Fragments – когато бит М е установен в “1”, то текущия пакет е част (един фрагмент) от по-голям пакет и след него следват още фрагменти.

R – Reserved – резервиран флаг.



  1. Fragment Offset – отместване на сегмента. Записва се информация за позицията на полето за данни от текущия фрагмент в оригиналния пакет. Отместването от началото на съобщението се представя като число кратно на 8 октета.

    Пример

    Нека приложно съобщение от 1000 октета да се транспортира през подмрежа, с максимален размер на пакета – 256 октета. Приемаме, че размера на заглавието е 20 октета (5 32-битови думи) и за потребителската информация остават – 236 октета.

    Тъй като отместването е каратно на 8 октета, то 29 Х 8 = 232. 29 е най-близкото цяло число, с което може да се представи отместването(Fragment Offset). Ако изберем 30, то 30 Х 8 = 240 октета, при максимум 236. Тогава съобщението от 1000 октета, ще се предаде като полседователност от 5 пакета: 4 Х 232 октета и 1 Х 72 октета, а отместването ще е картно на 29. Стойностите на полетата, свързани с фрагментирането е представена в таблицата

      No на пакет

      1

      2

      3

      4

      5

      Identification

      20

      20

      20

      20

      20

      Total Length

      252

      252

      252

      252

      92

      Fragment Offset

      0

      29

      58

      87

      116

      M-flag

      1

      1

      1

      1

      0





  1. Time to Live – време на живот. Стойността се установява във възела-източник и се намалява при преминаването през всеки следващ мрежов възел. След достигане на стойност 0, пакетът се унищожава.

  2. Protocol – записва се типа на протокола от по-“високо” ниво, който се съдържа тялото на пакета. Използва се за протоколна идентификация в целевия възел.

  3. Header Check sum – контролна сума

  4. Source IP address – IP адрес на източника (32 битово число).

  5. Destination IP address - IP адрес на получателя (32 битово число).

1 - 11са задължителни полета.

  1. Options – допълнителни възможности. Формата им зависи от приложението:

  • за сигурност (Security) – полето за DATA от пакета е възможно да се криптографира. В Options се специфицира типа на кодирането.

  • Source Routing – маршрутизиране от източника. В Options се описва маршрута и по този начин се изключва , маршрутизиращата логика във възлите.

  • Route Recording – запис на маршрута. В Options се записва информация за маршрута (трасиране на маршрута).

  • Time Stamp – маркер за време – при желание да проверим времато за транспорт на пакета

    Първият байт на полето Options определя текущо използваната допълнителна възможност.


1.1.4.Протоколно взаимодействие


На фиг.1.3 е представено взаимодействието на базовия мрежов протокол IP и свързаните с него транспортни протоколи, осигуряващи свързано мрежово обслужване за приложните заявки.


фиг.1.3

Осигуряването на ориентирано към връзката мрежово обслужване се реализира в този протоколен стек на транспортно ниво, тъй като базовия мрежов протокол е дейтаграмен, т.е. не ориентиран към връзката. Във взаимодействието участват два основни транспортни протоколи:



ТСР (Transmission Control Protocol) e ориентиран към връзката транспортен поротокол с две основни функции:

  • Да осъществява управление на предаването на информационни потоци, като открива грешки, получени или неполучени пакети и осигурява тяхното повторно предаване.

  • Мултиплексиране на точките на достъп до мрежово обслужване при поддържането на приложните заявки.

Протоколът IP осигурява еднопосочното предаване на дейтаграми от адреса-източник до целевия адрес. Транспортният протокол TCP осигурява управлението на потока кадри и отстраняване на грешки.

На транспортното ниво в разглеждания протоколен стек освен TCP оперира и протокол за обмен на потребителски пакети UDP (User Datagram Protocol). Този транспортен протокол е дейтаграмен, т.е. не предоставя механизъм за установяване на връзка и се използва за услуги, свързани с управление на мрежовите устройства и обмен на служебни съобщения.




1.1.5.Протокол IMCP


На мрежово ниво в разглежданият протоколен стек функционира протокола ICMP (Internet Control Message Protocol) – фиг.1.4.


фиг.1.4


. Протоколните съобщения на ICMP се пренасят в DATA-полето на IP-дейтаграмите и се използват за обмен на информация за грешки и управляваща информация.

Протоколът използва множество от командни примитиви, които дават информация за състоянието на мрежовото съединение:



  • Destination Unreachable (недостижим IP адрес);

  • Time  to Live Exceeded (изтекло време на “живот”)

  • Parameter Problem (проблеми при съставянето на дейтаграмите)

  • Redirect (пренасочване на дейтаграми)

  • Echo (заявка тест на IP адрес)

  • Echo Reply (потвърждение за тест на IP адрес)

  • Timestamp (заявка за времеви маркер)

  • Timestamp Reply (потвърждение на времеви маркет)

  • Information Request (заявка за информация за състояние)

  • Information Reply (потвърждение за информация за състояние)

  • Address Request (заявка за адресна информация)

  • Address Reply (потвърждение за адресна информация)

Тази служебна информация се използва от приложенията за целите на анализ на състоянието на мрежовото съединение и обработване на ситуации на отказ.

1.1.6.Протоколи ARP и RARP


Един от основните проблеми при реализирането на мрежови съединения между компютри, включени в локални мрежови конфигурации е проблема за взаимодействието между мрежови и канални адреси. Глобалният пренос се осъществява по мрежов адрес, докато мрежовия пакет, се транспортира в локалната мрежа в съответствие с конкретния канален протокол.

ARP се използва за построяване на необходимата за мрежовото съединение таблиcа на съответствието между присвоените на компютрите от локалната мрежа IP-адреси и MAC-адресите. Тази таблица позволява установяването на мрежови съединения, основани на преносната среда в локалната мрежа, например IEEE 802.3 Ethernet. При известен целеви IP адрес, за установяване на съединението е необходимо да се извлече от ARP-таблицата, съответстващия му MAC-адрес. Ако в ARP таблицата няма информация за това съответвествие, то се изпраща IP-дейтагрма с целеви адрес, търсения целеви адрес, която се пакетира в broadcast MAC-кадър. Този кадър достига до всички MAC-адреси в локалната мрежа, т,е достига и до компютъра, чиито IP адрес е целевия IP адрес. Компютърът, потвърждава дейтаграмата, като на канално ниво се формира кадър с канален целеви адрес, адреса на инициатора на мрежовото съединение и канален адрес-източник – търсения MAC-адрес. Пристигайки потвърждението при иницииращия компютър, неговата ARP-таблица се актуализира с липсващия MAC-адрес и са осигурени условията за установяване на мрежово съединение в MAC-преносната среда – фиг.1.5.



фиг.1.5
Протоколът RARP (Reverse Address Resolution Protocol) е “обратен” по функционалност на ARP. При този протокол се решава обратната задача, по известен MAC-адрес де се получи информация за съответстващия му IP-адрес. Използва се аналогичен подход, като се изпраща broadcast IP-дейтаграма, която достига мрежовото нива и в потвърждението се съдържа търсения IP адрес - фиг.1.6


фиг. 1.6


Протоколният стек IP v.4 е в основата на изграждането на глобалната мрежова среда INTERNET , както за проектирането на IP-базирани ведомствени мрежови конфигурации- INTRANET мрежови среди.

1.2.Маршрутизиране в среда на глобалната мрежова среда INTERNET


Глобалната мрежова среда INTERNET се изгражда, основавайки се архитектурни принципи близки до тези специфицирани в Еталонния модел, но отразяващи специфичните особенности на публичния характер на мрежовата конфигурация, броя потребители и случайния характер на приложното натоварване.

фиг.1.7


На фиг.5.21 е представена базовата топологична структура на INTERNET. Основният структурен елемент е Автономната система. Автономната система представя и съответства на корпоративна мрежова конфигурация. Организационно структурата на глобалната мрежа се поддържа от международна организация Network Information Center (interNIC). Корпоративните мрежови конфигурация се асоциират в средата на INTERNET под формата на Автономни системи. На всяка автономна система се присвоява 16-битов уникален идентификатор, който се използва при маршрутизирането.

фиг.1.7


На фиг. 5.22 е представена структурата на протоколните спецификации в INTERNET по отношение на топологичната схема на мрежовата среда. Автономните системи си взаимодействат по между си на базата на “външни” протоколи –Exterior Routing Protocols, а вътрешните за автономната система маршрутизатори си взаимодействат по “вътрешни” протоколи” – Interior Routing Protocols.

Към групата на “вътрешните” протоколи спадат протоколите, представени на фиг.5.23. В рамките на една Автономна система оперира един “вътрешен” протокол. Изборът на маршрутизиращ протокол се определя от характера на информационното натоварване в корпоративната мрежа и специфичните особености на конкретния представител на маршрутизиращите протоколи - фиг.1.7



фиг.1.8


фиг.1.9


Вътрешният” протокол RIP е дефиниран в препоръка RFC 1058. Базовите характеристики на RIP са:

  • Векторен алгоритъм. Големината на вектора указва разстоянието(в метрични единица) до целевия адрес , а посоката указва кой е следващия възел от маршрута .

  • Метрична оценка на маршрута – метрика тип “преход (hop count).

  • Максимален брой преходи до целевия адрес в таблицата – 15 прехода.

  • Маршрутните таблици се актуализират на всеки 30 секунди (по подразбиране)

Вътрешният” протокол IGRP e векторен маршрутизиращ протокол, разработен от фирмата CISCO..При IGRP маршрутните таблици се актуализират през интервали от 90 секунди, като интервала зависи от “размерността” на автономната система. Ключовите характеристики на IGRP са:

  • От гледна точка на механизма на функциониране:

    • Адаптивност към промените в топологията.

    • Адаптивност по отношение на метриката за формиране на големината на векторите и запълване на маршрутните таблици.

    • Приложимост и адаптивност към “размерността” на мрежата.

IGRP използва комбинация от променливи при формиране на метричната оценка за големината на вектора от маршрутната таблица.

  • Базовите променливи при метричната оценка, използвани от IGRP са:

    • Bandwidth – пропускателна способност;

    • Delay – времезадръжка;

    • Load –комуникационно натоварване

    • Reliability – устойчивост и надеждност на маршрута

    • MTU – максимален размер на пакета в байтове;

Векторните алгоритми (известни още като Bellman-Ford алгоритми) изпращат периодично копия на маршрутизиращите таблици между маршрутизаторите. По този начин се актуализира информацията за промени в топологията на мрежата.

Маршрутизаторът получава от всеки съседен маршрутизатор маршрутизиращата му таблица. Приемайки текущата таблица, маршрутизаторът добавя големините на векторите, към текущите големини от собствената си таблица и след актуализирането я изпраща на съседните на него маршрутизатори. Така стъпка по стъпка се допълва информацията в таблицата до достигане на големина на вектора : 15 метрични единици.

Чрез обхождането на мрежата и пресмятането на векторните разстояние, на маршрутизаторите се предоставя възможност да намерят най-краткия път към целевата подмрежа

“Вътрешният” протокол OSPF е маршрутизиращ протокол от OSI стека. Този протокол оперира с метрика “състояние на линията”. При OSPF се построява във всеки маршрутизатор пълен граф на топологията на мрежата като се въвежда метрика за оценка и натрупване на информация за състоянието на комункационните линии. Тази информация се актуализира през определен период от време, като маршрутизирането се реализира след пресмятане най-късия път до целевата подмрежа и се указва следващият възел по маршрута, формиран при анализа на натоварването.



2.Транспортно ниво
Функционалност на транспортното ниво


Транспортното ниво е ниво на синхронизация. Мрежовото ниво е нивото на информационния пренос, детерминиран от ограниченията на комуникационната подсистема. Транспортното ниво поддържа приложните заявки за обмен на информация и в средата на ограниченията на мрежовото ниво, осигурява заявеното качество на обслужване на приложните процеси. Транспортното ниво има за задача да осъществи прозрачен обмен на данни между сеансовите обекти и да ги освободи от изпълнението на функции по организиране на ефективното и надеждно предаване на данни.

2.1.Обща характеристика на транспортните протоколи


Транспортният слой определя параметрите на качеството на мрежовото обслужване при предаването на данни, производителността на мрежата, подходящо мултиплексиране на мрежовите съединения и др. Тези параметри отчитат заявеното от обектите на сеансовото ниво качество на обслужване от една страна и от друга отчитат реалните характеристики и възможности на комутационната подсистема, управлявана от мрежовия слой.

Функционалността на транспортното ниво е свързана с:



  • Мултиплексиране на точките на достъп до мрежовото съединение – установяване на няколко транспортни съединения на база на едно мрежово съединение;

  • Контрол на качеството на обслужване – следи за достоверното предаване на информацията, управлението на потока кадри, буфериране, откриване и корекция на грешки, контрол на времевите характеристики на информационния пренос и запълването на пропускателната способност на мрежовите съединения;

  • Установяване поддържане и разпадане на транспортните съединения.

Транспортното ниво има синхронизиращи функции при използването на услугите на мрежовите съединение при зададено качество на обмена, зададено от сеансовото ниво.

“Високите” нива са част от операционната система, под управлението на която работи компютъра или са приложение за операционната система, докато транспортното ниво е относително независимо от локалната операционна система, тъй като при него функционалността се определя от комуникационната подсистема (първите три нова от Еталонния модел). Транспортното ниво се организира в локалната архитектура като самостоятелен елемент в състава на мрежовото системно програмно осигуряване



От архитектурен аспект ТН (транспортното ниво) е първото от нивата, което реализира съединение точка – точка (Point to Point), от гледна точка на приложенията –фиг.2.1




приложен процес

приложен процес















Преносна среда

(комуникационна подсистема)

Фиг. 2.1


Съединението между приложните процеси се реализира на базата на транспортното ниво. На приложенията се предоставя за използване виртуално съединение, като комуникацията в “ниските” нива остава прозрачна. Независимо от разстоянието между тези двата крайни компютъра, функционалността на транспортния протокол е една и съща.

Всички приложно-ориентирани нива от Еталонния модел се основават на транспортното, като достоверна комуникационна среда – фиг.2.2







OS



4

3

2

1

Фиг. 2.2

Транспортното ниво трябва да осигурява баланса между изискванията за комуникационни услуги на приложните нива и реалните възможности на мрежата.


2.2.Мултиплексиране на мрежови съединения


За ориентираните към връзката транспортни протоколи се реализира функцията управление на потока. Подобно на каналното ниво, транспортното ниво осигурява достъпа до мрежовите съединения.

За дейтаграменните протоколи на мрежово ниво е необходима допълнителна функционалност за осигуряване на достоверно приложно обслужване. Особеността е, че тази функция е реализирана от транспортния протокол. Транспортното ниво буферира мрежовото съединение с цел поддържането на множествените приложни заявки (множествен достъп). За тази цел транспортните протоколи използват логика за управление на “независими” буфери, които се наричат Socket (позиция). Socket е област от паметта. Ресурс, който се заема динамично от транспортния протокол със средствата на текущата операционна система.

Механизмът за обработка на Socket е представен чрез фиг.2.3.





RAM

App1(приложение)

App2(приложение)




Socket N@1, T@1

Socket N@1, T@2




Фиг. 2.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 се разделят от транспортното ниво и достоверно се насочват към съответното приложение


2.3.Представители на транспортните протоколи.


Функционалността на транспортните протоколи зависи от възможностите на мрежовото ниво да осигури ориентирано към връзката мрежово обслужване. Ако за протоколния стек X.25 необходимостта от функционалност на транспортно ниво се свежда до поддържането на частни сценарии за мрежово обслужване, то при IP - протоколният стек, дейтаграмния характер на мрежовото съединение предполага развиването на “богат” функционално транспортен слой.

В IP - протоколния стек (виж. 5.4.5) транспортният слой е изграден от два протокола TCP(Transport Control Protocol) и UDP(User Datagram Protocol) – фиг.2.4[].


фиг.2.4


На фиг.2.5 е представен формата на TCP-протоколната спецификация

фиг.2.5


Предназначението на полетата на TCP-сегмента е:

  • Source Port—Идентификатор на порта-инициатор на транспортното съединение;

  • Destination PortИдентификатор на целевия порт

  • Sequence Number—Последователен номер на сегмента

  • Acknowledgment Number—Номер за потвърждение

  • HLEN—Размер на пакета в 32-битови думи

  • Reserved—Не се използва

  • Code Bits—Използва се като указател за край на сесията на обмен

  • Window—Размер на прозореца, брой октети предадени без потвърждение

  • Checksum—Контролна сума на заглавната част и данните

  • Urgent Pointer—Указател за спешни данни

  • Option—максимален размер на TCP сегмента

  • Data—Приложно съобщение, данни за TCP- протокола

фиг.2.6


И двата протокола TCP и UDP използват идентификатори за номер на порт (socket) за целите на достоверния обмен на информацията с протоколите и услугите от “високите” нива – фиг.2.6 Портовете се използват за целите на мултиплексирането на мрежовото съединение.

Мрежовите приложенията се разработват в условията на известна схема за разпределение на портовете, дефинирана в препоръка RFC 1700. Например, отдалеченият терминален достъп (приложната услуга TELNET) се реализира с използването на стандартизиран порт номер 23. Сесиите на обмен, за които няма предвиден стандартно номер се реализират на базата на случайно присвояване на номер на порт при постъпване на заявката от множеството на незаетите портове.

Разпределението на TCP и UDP портовете е представено на фиг.2.7

фиг.2.7


Някой от портовете са резервирани от двата протокола и приложенията не могат да използват тези портове. Принципа на разпределение на портовете е следния:

  • портове с номера до 255 са предоставени за общо използване.

  • Портове с номера от 256 до 1023 са за системни приложения.

  • Портове с номера над 1023 са недефинирани.

фиг.2.8


Крайните компютри използват портовете , за да достигнат до желаното приложени, като в полето за целеви порт (Dest. port) се указва номера на порта, с който се адресира на транспортно ниво приложението – номер 23 – приложение TELNET – фиг.2.8.

Установяването на TCP съединението в двете крайно точки (компютри) се реализира на три стъпки по последователността, показана на фиг.2.9



Фиг.2.9


Процедурата е фактически тест на логиката за потвърждение на протокола, като се обменя един празен сегмент в двете посоки и се изчаква двупосочно потвърждение за него преди да стартира обмена на реална информация.

Протокола TCP поддържа два механизма за потвърждение, които се различава по размера на прозореца. При размер на прозореца =1, се реализира единично потвърждение, при размер на прозореца по-голям от единица потвърждението е от тип “пълзящ” прозорец – фиг.2.10



фиг.2.10


Двата подхода се прилагат в зависимост от типа на приложната сесия, качеството на мрежовото обслужване и допълнителни системни изисквания за надеждност и на транспортното съединение.

Една примерна процедурна последователност за дуплексно управление на потока сегменти при TCP е представена на фиг.2.11



фиг.2.11


В полето за номер на сегмента се записва номера на текущо изпратения сегмент, а в полето за потвърждение се указва номера на сегмента, който се очаква да бъде предаден, с което се потвърждава текущо предавания сегмент.

На фиг.2.12 е представен формата на UDP-сегмента



фиг.2.12


Сравнявайки този формат с формата на TCP сегмента (фиг.2.5) се наблюдава отсъствие на полета за контрол на потока и корекция на грешки. Това е характерно за дейтаграмните протоколи. Във функционалността на сегмента е съхранена възможността за мултиплексиране на мрежовите съединения

Приложните услуги основани на базата на IP-протоколния стек са представени на фиг. 2.13



ПРИЛОЖНИ УСЛУГИ

HTTP

SMTP

FTP

TELNET

SNMP

UDTP

и т.н.

TCP

UDP







Internet IP v 4.0

Фиг.2.13

Една част от услугите изискват ориентирано към връзката мрежово съединение и се поддържат на транспортно ниво от протокол TCP:



  • World Wide Web–HTTP (Hiper Text Transfer Protocol) протокол;

  • Електронна поща (MAIL)– поддържа се от протокол SMTP (Simple Massage Transport Protocol);

  • Обмен на файлове – FTP (File Transfer Protocol) протокол;

    Втора група приложни услуги не поставят изискването на свързано мрежово обслужване. Тогава на транспортно ниво се използва протокола UDP:



  • Отдалечено администриране на устройства - SNMP (Simple Network Management Protocol) протокол;

  • UDTP (User Define Transport Protocol) – този протокол позволява допълнително дефиниране на протоколна спецификация на приложно ниво


2.4.Транспортни стекове за локални мрежи.


Комуникацията в локалните мрежите се характеризира с висока пропускателна способност, пренебрежимо малки транспортни времезакъснения и висока интензивност на приложните заявки за обмен.

В локалните мрежи най-често се използват три транспортни стека (групи протоколи), основани на MAC протоколната спецификация, покриваща “ниските” мрежови нива – фиг.2.14




4

Novell SPX

TCP

IBM NetBIOS

3

IPX

IP




2

LLC (HDLC)

1

MAC

Фиг.2.14


    Протоколният стек IPX/SPX е разработен от фирмата Novell, транспортният протокол в този стек е SPX (Service Protocol Exchange) – използван като уникален адрес т.н. РАР@. За този тип адрес е валидно съответствието:

IPX@  PAP@  MAC@

С цел повишаване на производителността на транспортната система, като мрежов адрес се използва уникалния MAC адрес. По този начин се намаляват “разходите” за адресно преобразуване и изграждане на протоколните спецификации. IPX е дайтаграмен мрежов протокол, докато SPX осигурява ориентирано към връзката мрежово обслужване.



Транспортното ниво завършва функционално комуникационните мрежови слоеве. Това ниво има важна роля в процесите на синхронизация на приложните изисквания и реалния комуникационен потенциал на преносната среда.
Каталог: docs -> Bachelor -> IV%20Kurs -> Sem%20VIII -> KIK
KIK -> Дисциплина: Компютърни мрежи Упражнение 11 Дисциплина: Компютърни комуникации Упражнение 11
KIK -> Модул Frame Relay Компютърни комуникации
KIK -> Модул ppp & isdn компютърни комуникации
KIK -> Дисциплина: Компютърни мрежи Упражнение 12 Дисциплина: Компютърни комуникации Упражнение 12
KIK -> Модул атм компютърни комуникации
KIK -> Дисциплина: Компютърни комуникации Упражнение 8
KIK -> Дисциплина: Компютърни мрежи Упражнение 10 Дисциплина: Компютърни комуникации Упражнение 10
KIK -> Модул 2 Методически аспекти при изучаването и проектиране на компютърно базирани комуникационни системи (кбкс)
KIK -> Модул Компютърни мрежи – комуникационната подсистема като обект за проектиране


Сподели с приятели:




©obuch.info 2024
отнасят до администрацията

    Начална страница