РЪКОВОДСТВО -...

София, 2009

ТТееххннииччеессккии УУннииввееррссииттеетт -- ССооффиияя

ГРИША СПАСОВ, НИКОЛАЙ КАКАНАКОВ, МИТКО ШОПОВ

РЪКОВОДСТВО ЗА ЛАБОРАТОРНИ УПРАЖНЕНИЯ ПО

КОМПЮТЪРНИ МРЕЖИ

ВВииррттууааллннаа ллааббооррааттоорриияя ппоо ррааззппррееддееллееннии

ссииссттееммии ии ккооммппююттъъррннии ммрреежжии

Предговор

Ръководството е предназначено за студенти, изучаващи дисциплината „Компютърни мрежи”, както и за всеки, който иска да разшири практическите си познания в областта. Състои се от десет теми, съпроводени с теоретични бележки, примери, задачи за изпълнение и литература за допълнителна подготовка. Всяка тема е организирана като едно упражнение.

За подготовката на темите са използвани литературни източници от световноизвестни автори, публикувани стандарти, ръководства на мрежова апаратура и софтуер и основно опита на авторите в областта на компютърните мрежи и разпределените системи. Доц. д-р Гриша Валентинов Спасов е дългогодишен преподавател по дисциплината „Компютърни мрежи” в Пловдивския филиал на Техническия университет – София и е защитил дисертация в областта на безжичното предаване на данни. Той е автор на курсове по компютърни мрежи в други учебни заведения в страната. Асистент Николай Руменов Каканаков води упражнения по дисциплината „Компютърни мрежи” от 2004 година и е автор на дисертационен труд за комуникацията в разпределени вградени системи. Инж. Митко Петров Шопов има опит в провеждането на CCNA курсове, работил е като Web програмист и системен администратор. Авторите са участвали в няколко национални научни проекта в областта на компютърните мрежи и разпределените системи.

Повечето практически задачи са базирани на програми и библиотеки с отворен код и са достъпни за читателите. За провеждането на упражненията са необходими основни познания за ОС Linux/Unix и програмиране на езици като C/C++ и Java.

Кратко описание на темите:

Тема 1: Физически слой. Кабелни стандарти и конектори. Автори: Гриша Спасов, Николай Каканаков

Целта на упражнението е да запознае студентите с основните кабелни стандарти за изграждане на локални мрежи. Студентите се запознават с основните предимства и недостатъци на различните преносни среди, както и спецификите на тяхното приложение. Като част от упражнението се включва поставянето на RJ45 конектори и проверка на работоспособността на UTP кабел. Тема 2: Безжични локални мрежи – WLAN. Автори: Борис Рибов, Гриша Спасов

Целта на упражнението е запознаване с физическите и каналните протоколи за безжична комуникация и стандарта IEEE 802.11. Разглеждат се основните топологии за изграждане на безжични мрежи. Представени са начините за определяне на параметрите на средата и загубите в нея. Включено е конфигуриране на точка за достъп и изграждане на тестова безжична мрежа и изследване на пропускателна способност при различни режими. Тема 3: Модеми и GSM. Управление чрез AT команди. Автор: Николай Каканаков

Целта на упражнението е да запознае студентите с устройството и основните функции на телефонен и GSM модем, както и процедурата изграждане на връзка между

два модема. Студентите се запознават и с основните команди за управление на модем (АТ команди) и специфичните команди от спецификацията GSM 7.05/7.07. Тема 4: Адресиране в Интернет. DHCP – същност и конфигурация. Автор: Гриша Спасов

Целта на упражнението е да запознае студентите с адресирането в интернет, структурата и функциите на протокола IP и разделянето на мрежи на подмрежи. Представени са основните функции на протокола DHCP за конфигуриране на хостове в локална мрежа. Студентите се запознават с инсталиране и конфигуриране на DHCP сървър по ОС Linux. Тема 5: Маршрутизиране в интернет. Автори: Митко Шопов, Гриша Спасов

Целта на упражнението е да се представят основните протоколи за маршрутизиране в интернет. Представени са и основните протоколи за маршрутизиране в мобилни ad-hoc мрежи. Студентите се запознават с конфигурирането на Linux станция като маршрутизатор и командите за проверка на маршрутизирането (route, traceroute). Тема 6: Транслиране на адреси (NAT) и защитни стени (Firewall). Автор: Митко Шопов

Целта на упражнението е да се разучи технологията на транслиране на адреси и портове. Представени са основните функции на защитните стени и възможностите им. Студентите се запознават с инструмента iptables под ОС Linux за конфигуриране на NAT и задаване на правила и политики за филтриране на трафик. Тема 7: Изследване на транспортния слой. Следене на трафика. Автор: Николай Каканаков

Целта на упражнението е да запознае студентите с функциите на транспортния слой и основните протоколи, работещи на него. Представени са най-съществените предимства и недостатъците на TCP и UDP. Студентите се запознават с механизмите за следене на трафика и усвояват използването на пакетен анализатор Wireshark (Ethereal) и създаването на филтри за него. Тема 8: Симулационно изследване на мрежови протоколи Автор: Митко Шопов

Целта на упражнението е да запознае студентите със симулационното изследване като метод за верифициране на компютърни мрежи и комуникационни протоколи. Студентите се запознават с възможностите и работата на мрежовия симулатор NS-2 и скриптовите езици Tcl, OTcl. Тема 9: Сокети – приложение. Автори: Николай Каканаков, Митко Шопов

Целта на упражнението е да запознае студентите с понятието сокет и основните функции на сокетите в операционната система. Разглеждат се основните функции за програмиране на BSD сокети на и Java Socket Interface. Тема 10: Приложен слой. World Wide Web. Протокол HTTP Автори: Митко Шопов, Николай Каканаков

Целта на упражнението е да запознае студентите с механизма на работа на World Wide Web и протокола HTTP. Разглеждат се основните функции на Web сървър и браузер и инсталирането и конфигурирането на Web сървър Apache.

Виртуална Лаборатория по Компютърни Мрежи и Разпределени Системи

Стр.4 Тема 1

Физически слой. Кабелни стандарти и конектори

Съдържание Тема 1 Физически слой. Кабелни стандарти и конектори ...................................... 7 Цел на упражнението ............................................................................................... 7 Теоретична част ........................................................................................................ 7 Кабелни стандарти за Ethernet, Fast Ethernet и Gigabit Ethernet ....................... 7 Категория 5 неекранирана усукана двойка ......................................................... 9 Прав (straight) и кръстосан (crossover) UTP кабел ........................................... 10 Конектори ............................................................................................................. 12 Поставяне на RJ45 конектор............................................................................... 12 Проверка на работоспособността на UTP кабел .............................................. 12

Задачи за изпълнение ............................................................................................. 13 Допълнителна литература ..................................................................................... 13

Тема 2 Безжични локални мрежи – WLAN ............................................................ 14 Цел на упражнението ............................................................................................. 14 Теоретична част ...................................................................................................... 14 Топологии на мрежите, работещи по IEEE 802.11 .......................................... 15 Определяне на радиопараметрите на средата................................................... 17 Настройка и задаване на режимите на работа .................................................. 22


Тема 3 Модеми и GSM. Управление чрез AT команди......................................... 26 Цел на упражнението ............................................................................................. 26 Теоретична част ...................................................................................................... 26 Устройство и функции на модем ....................................................................... 26 Видове модеми ..................................................................................................... 27 Процедура за предаване на данни между два модема ..................................... 29 Основни АТ команди .......................................................................................... 30 GSM модеми......................................................................................................... 31


Тема 4 Адресиране в интернет. DHCP– същност и конфигурация..................... 34 Цел на упражнението ............................................................................................. 34 Теоретична част ...................................................................................................... 34 Адресиране в интернет. IPv4 и IPv6. ................................................................. 34 Dynamic Host Configuration Protocol (DHCP) ................................................... 37 Разделяне на подмрежи ....................................................................................... 44


Тема 5 Маршрутизиране в интернет ...................................................................... 47 Цел на упражнението ............................................................................................. 47


Стр.5 Тема 1


Теоретична част ...................................................................................................... 47 Маршрутизиране.................................................................................................. 47 Автономни системи ............................................................................................. 48 Интериорни маршрутизиращи протоколи ........................................................ 49 Маршрутизиращи протоколи за мобилни ad-hoc мрежи (MANET)............... 51 Конфигуриране на Linux станция за работа като маршрутизатор ................. 53 Проверка на маршрутизирането......................................................................... 54


Тема 6 Транслиране на адреси (NAT) и защитни стени (Firewall) ...................... 56 Цел на упражнението ............................................................................................. 56 Теоретична част ...................................................................................................... 56 Транслиране на адреси (NAT)............................................................................ 56 Защитни стени (Firewall)..................................................................................... 58 Демилитаризирани зони (DMZ) ......................................................................... 60 Конфигуриране на ОС Linux в режим на защитна стена ................................ 61


Тема 7 Изследване на транспортния слой. Следене на трафика ......................... 67 Цел на упражнението ............................................................................................. 67 Теоретична част ...................................................................................................... 67

Transmission Control Protocol (TCP)................................................................... 67 User Datagram Protocol (UDP)............................................................................. 71 Следене на трафика. ............................................................................................ 72


Тема 8 Симулационно изследване в компютърните мрежи ................................ 75 Цел на упражнението ............................................................................................. 75 Теоретична част ...................................................................................................... 75 Въведение в NS-2................................................................................................. 77 Основи компоненти на мрежовия симулатор NS............................................. 79 Реализиране на нов протокол ............................................................................. 83 Въведение в TCL скрипта ................................................................................... 83 Скриптове на NS-2............................................................................................... 84 Инструменти за визуално представяне на резултатите от симулацията ....... 86


Тема 9 Сокети – приложение .................................................................................. 88 Цел на упражнението ............................................................................................. 88 Теоретична част ...................................................................................................... 88


Стр.6 Тема 1


Мрежови сокети ................................................................................................... 88 Използване на сокети .......................................................................................... 89 Адресиране на сокети.......................................................................................... 90 Описание на основните функции за работа със сокети в С/С++.................... 91 Интерфейс за работа със сокети в Java.............................................................. 93


Тема 10 Приложен слой. World Wide Web. Протокол HTTP .............................. 96 Цел на упражнението ............................................................................................. 96 Теоретична част ...................................................................................................... 96 Протокол за трансфер на хипертекст – HTTP ................................................ 100 Език за хипертекст – HTML ............................................................................. 102 Инсталиране и настройване на Apache Web сървър ...................................... 103

Задачи за изпълнение ........................................................................................... 105 Допълнителна литература ................................................................................... 105


ТЕМА 1 ФИЗИЧЕСКИ СЛОЙ. КАБЕЛНИ СТАНДАРТИ И КОНЕКТОРИ

ЦЕЛ НА УПРАЖНЕНИЕТО Целта на упражнението е да запознае студентите с основните кабелни

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

ТЕОРЕТИЧНА ЧАСТ Физическият слой на OSI модела включва преносната среда и сигналите с

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

Основните преносни среди, използвани в компютърните мрежи, са меден проводник (коаксиален и усукана двойка), оптично влакно и въздух (безжични мрежи). Коаксиален кабел, усукана двойка и оптичен кабел са показани съответно на фигури 1.1, 1.2 и 1.3.

Фиг.1.1. Тънък коаксиален кабел.

Фиг.1.2. Неекранирана усукана двойка.

Фиг.1.3. Оптичен кабел.

Кабелни стандарти за Ethernet, Fast Ethernet и Gigabit Ethernet Основните кабелни стандарти за фамилията Ethernet са следните: • 10BASE5 – Thick Ethernet или Thicknet – това е първият стандартен кабел

Тема 1Стр.7 Физически слой. Кабелни стандарти и конектори


Стр.8 Тема 1


при създаването на стандарта IEEE 802.3 (Ethernet). • 10BASE2 – Thin Ethernet, Thinnet или Cheapernet – подобен на 10BASE5.

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

• 10BASE-T – използва напълно нова преносна среда (IEEE 802.3i) – използва два неекранирани чифта (усукана двойка), категория 3 (UTP): един чифт за предаване, един – за получаване.

• 10BASE-F – отговаря на три различни спецификации за пренос по оптична среда: 10BASE-FL (Fiber Link) и е най-популярният 10-Mbps стандарт за оптична комуникация. 10BASE-FP и 10BASE-FB не се използват отдавна (P е за пасивен; B – за backbone).

• 100BASE-T е 10BASE-T за Fast Ethernet, с оригиналния Ethernet MAC, но на 10 пъти по-висока скорост. Позволява три различни физически реализации, част от IEEE 802.3u: 100BASE-TX, използващ два чифта Category 5 UTP или Type 1 STP кабел, и е най-популярният за хоризонтално окабеляване; 100BASE-FX, използващ две нишки оптично влакно тип multimode, и е най-популярният за вертикално или гръбначно окабеляване; 100BASE-T4 използва четири чифта Category 3 или по-висока категория кабел и се прилага много рядко, за евтини решения.

• Gigabit или 1000-Mb Ethernet е публикуваният през 1998г. IEEE 802.3z стандарт, описващ Gigabit Ethernet MAC и три физически реализации: 1000BASE-SX – оптика за хоризонтално окабеляване, 1000BASE-LX – оптика за вертикално или гръбначно окабеляване, 1000BASE-CX – меден кабел (Copper-Twinax) и 1000BASE-T.

Табл.1.1. Категории кабели неекранирана усукана двойка (UTP)

Тип Честотна лента Приложение

Category 1 1 MHz Телефонен кабел Category 2 4 MHz Данни до 4 Mbps (LocalTalk) Category 3 16 MHz Данни до 10 Mbps (Ethernet) Category 4 20 MHz Данни до 20 Mbps (16 Mbps Token Ring) Category 5 100 MHz Данни до 100 Mbps (Fast Ethernet) Category 5е 100 MHz Подобрен вариант на САТ5. Category 6 250 MHz Данни до 100 Gbps (Gigabit Ethernet)

Category 7 до 600 MHz Нов стандарт за предаване с високи скорости по 100 Ohm UTP.

Какво означават кодовете на кабелните стандарти? Числото в началото (10, 100, 1000) показва скоростта на предаване в Mbps. Текстът в средата показва типа на предаване: BASE = теснолентово; BROAD = широколентово.


Последното число показва максималната дължина на сегмента: 5 означава 500m, 2 – 200m и т.н. В по-новите стандарти последните цифри са заместени от букви. Например, в 10BASE-T T означава unshielded twisted-pair (неекранирана усукана двойка) кабел; в 100BASE-T4 T4 показва, че има четири такива двойки.

Коаксиалният кабел вече не се използва поради възможността за създаване само на топологии тип шина с него. Екранираната усукана двойка (STP) е сравнително по-шумоустойчив кабел и се препоръчва за вътрешно окабеляване при наличие на повече източници на шум. STP кабелът се заземява само в единия край. CAT5 STP patch панелите обикновено предоставят заземяване (концентраторите и комутаторите – не). За външно окабеляване между сгради се препоръчва оптично влакно. Цената на кабела в сравнение с останалата мрежова апаратура е относително ниска. Изборът на подходящ кабел минимизира грешките при предаване, т.е. по-добра пропускателна способност. Оптиката е най-скъпото решение, но е напълно неповлияна от електромагнитни въздействия.

Категория 5 неекранирана усукана двойка Категория 5 неекранирана усукана двойка (CAT5 UTP) е кабел, съдържащ 4

усукани двойки проводници. Всеки проводник може да бъде от една нишка или многонишков и обикновено се наричат solid и flex. Най-често solid се използват за прекарване на мрежа през стени или на открито, а flex – за разстоянието от розетката до крайната станция. Чифтовете от проводници са оцветени, за да може да се разпознае всеки проводник в двата края на кабела. Още повече, те обикновено са оцветени кодиращо по двойки.

Чифт #1: Бяло/синьо Синьо

Чифт #2: Бяло/оранжево Оранжево

Чифт #3: Бяло/зелено Зелено

Чифт #4: Бяло/кафяво Кафяво

Фиг.1.4. Подреждане на чифтовете в CAT5 UTP.



Обикновено CAT5 UTP кабелите съдържат 4 проводника, оцветени изцяло и още толкова, оцветени на ленти. Така чифтът се състои от един проводник с даден цвят и един със същия цвят и бяло на ленти. Най-често използваната схема на оцветяване е тази на EIA/TIA Standard 568B.

Фиг.1.5. Подреждане на чифтовете при T568-А и T568-B.

Табл.1.2. T568-A Cabling

Pin# Pair# Function Wire Color Used with 10/100 BASE-T Ethernet?

1 3 Transmit White/Green Yes 2 3 Transmit Green Yes 3 2 Receive White/Orange Yes 4 1 Not used Blue No 5 1 Not used White/Blue No 6 2 Receive Orange Yes 7 4 Not used White/Brown No 8 4 Not used Brown No

Прав (straight) и кръстосан (crossover) UTP кабел При свързването на две комуникиращи крайни устройства е необходимо Tx

на единия да е свързан с Rx на другия и обратно (фигура 1.8). Затова се прави така наречения "Crossover" кабел. При него е нужно да се промени подредбата на проводниците само на единия край на кабела, а другия край да е със стандартна подредба. Когато, обаче, две устройства комуникират през мрежово оборудване (комутатор, концентратор, маршрутизатор) това кръстосване се извършва от него. За да не се получават недоразумения се приема, че две



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

Фиг.1.6. Стандартен и кръстосан UTP.

Табл.1.3. Подредба на проводниците при прав и кръстосан кабел.

Standard End

Pin 1 White/Orange

Pin 2 Orange

Pin 3 White/Green

Pin 4 Blue

Pin 5 White/Blue

Pin 6 Green

Pin 7 White/Brown

Pin 8 Brown

Crossover End

Pin 1 White/Green

Pin 2 Green

Pin 3 White/Orange

Pin 4 Blue

Pin 5 White/Blue

Pin 6 Orange

Pin 7 White/Brown

Pin 8 Brown



Фиг.1.7. Разрез на RJ45 при правия край

Фиг.1.8. Разрез при кръстосания край

Конектори Най-използваните за кабел CAT5 UTP конектори са RJ45. RJ означава

Registered Jack, а 45 показва схемата за номериране на пиновете. Спецификацията на IEEE за Ethernet 10Base-T и 100Base-T изисква да се използват два чифта, от които единият е на пинове 1 и 2, а другият – на 3 и 6.

Поставяне на RJ45 конектор За поставянето на RJ45 конектор на стандартен UTP CAT5 (CAT5e) кабел се

използват специални клещи. Кабелът се оголва около 15mm, като се внимава да не се наранят проводниците вътре. Оголените проводници се развиват и се изпъват плътно един до друг. Изпънатите проводници се подравняват и се подреждат по желания начин (T568-А или T568-B). Подредените кабели се пъхат в конектора, както е показано на фигура 1.9. Прави впечатление, че проводниците са подравнени и подредени плътно един до друг. При кръстосания край само подредбата на оранжевия и зеления чифт е разменена.

Фиг.1.9. Поставяне на конектор.

Проверка на работоспособността на UTP кабел За правилната работа на UTP кабел е необходимо той да не е прекъснат,



Стр.13 Тема 1


правилно да е подреден при поставянето на конектора, металните пластини на конектора да дават добър контакт с всички проводници. Първото ниво на проверка е оглед на конектора и проверка за целостта на кабела. Второ ниво е „прозвъняване” на проводниците, което може да бъде извършено с обикновен омметър. Разпространени са също и кабелни тестери. Те проверяват свързаността и правилната подредба при конекторите. Някои по-съвременни решения позволяват откриването на точното място на прекъсване (ако има такова). Обикновено тестерът дава различни сигнали, ако няма свързаност или ако е неправилно свързването. Тест може да се проведе по различен начин. Например, „бягаща единица”, прозвъняване на всички едновременно, прозвъняване чифт по чифт и др.

ЗАДАЧИ ЗА ИЗПЪЛНЕНИЕ 1. Запознаване с основните кабелни стандарти за Ethernet. 2. Запознаване с категориите кабели неекранирана усукана двойка. 3. Запознаване с RJ45 конектор за UTP. 4. Запознаване с „прав” (straight) и „кръстосан” (crossover) кабел и

приложението им. 5. Окабеляване с UTP. Поставяне на RJ45 конектор. 6. Проверка на работоспособността на UTP кабел. Тестери.

ДОПЪЛНИТЕЛНА ЛИТЕРАТУРА Повече за кабелните стандарти – на следните адреси: • http://www.zytrax.com/tech/layer_1/cables/cables_faq.htm • http://standards.ieee.org/ • http://www.networkdictionary.com/networking/EthernetCableStandardsSpecifi

cations.php


ТЕМА 2 БЕЗЖИЧНИ ЛОКАЛНИ МРЕЖИ – WLAN

ЦЕЛ НА УПРАЖНЕНИЕТО Целта на упражнението е запознаване с физическите и каналните протоколи

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

ТЕОРЕТИЧНА ЧАСТ Когато се налага използването на висока пропускателна способност при

изискване за мрежова свързаност между устройствата в относително малки пространства и площи, тогава се използва WLAN по стандарта IEEE 802.11. На фигура 2.1 е показана зависимостта на пропускателната способност, която се изисква (нанесена по абсцисата) и обхвата на действие на дадената технология (по ординатата). Засичането дава обсега на действие на различните системи за безжичен достъп, които са актуални в момента.

Фиг.2.1.

Като първа ревизия IEEE 802.11 се е утвърдил през 1997г., като оттогава са въведени множество допълнения към него (ревизии), означаващи се със съответна буква след името на стандарта:

• IEEE 802.11 - Първоначална версия на стандарта, способна да обслужва скорости от 1 и 2 Mbps, като работи в диапазона 2.4 GHz,

• IEEE 802.11a – Разширение, способно да обслужва скорости до 54 Mbps, работейки в диапазона около 5GHz,

• IEEE 802.11b - Представеният през 1999г. стандарт 802.11b е способен да предава със скорости до 11 Mbps, работейки в диапазона 2.4 GHz,

Тема 2Стр.14 Безжични локални мрежи – WLAN


• IEEE 802.11c - Дефинира работата “безжичен мост” – wireless bridge, • IEEE 802.11d - Дефинира стандартите за фирмите, разработващи

безжични продукти в различните страни, • IEEE 802.11e - Дефинира разширение към нивото за контрол на

съобщителната среда за въвеждане ”качество на услугите” (QoS), • IEEE 802.11f - Дефинира протокола “Inter Access Point Protocol” (IAPP), • IEEE 802.11g – Разширение, способно да обслужва скорости до 54 Mbps,

работейки в диапазона 2.4 GHz, • IEEE 802.11i - Подобрение на метода за криптиране, • IEEE 802.11j - 802.11 разширение за използване в Япония, • IEEE 802.11n - Нов стандарт от 2005г. със скорости на предаване до 100

Mbps.

Терминология, която ще се използва: • AP (Access Point) – точка за достъп до опорната мрежа, • SSID (Service Set Identifier) – идентификатор на набора от услуги (име на

мрежата), • WEP (Wired Equivalent Privacy) – еквивалент на сигурността на кабелна

мрежа, • dB – мярка за отношение между два сигнала.

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

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

AD-HOC (всеки с всеки) В този режим, който е най-често срещан при връзка на мобилни устройства

помежду си (laptop, palmtop и др.), не е необходимо определено безжично устройство в мрежата да синхронизира достъпа до канала. Това не е често срещан режим на работа поради ниската производителност и възможността за колизии.

A

Фиг.2.2.



Access Point – Client (точка за достъп - клиент) Практически това е най-често срещаната топология на свързване на

устройствата при безжичните мрежи. Множество мобилни устройства изпoлзват услугите на една базова станция (наричана точка за достъп или АP “Access Point”). Точката за достъп (AP) управлява всички клиенти, асоциирани към нея. Тя казва на клиента на кой канал да предава, кога да предава и в зависимост от зададените правила може да се даде приоритет на някои клиенти пред други (QoS). Няма опасност от колизии на “скрити терминали” поради факта, че всички клиенти трябва да се асоциират към AP за достъп до мрежата, тоест AP вижда абсолютно всички клиенти докато те помежду си може да не се виждат.

Фиг.2.3.

WDS – Wireless Distributed System (безжично разпределена система) Безжично разпределените системи имат топологията на AP-Client, като всяко

AP формира зони на чуваемост. Разликата спрямо топологията AP-Client е тази, че различните AP комуникират безжично помежду си, за да осигурят достъп до опорната мрежа. Необходимо е всички AP да работят на един и същи радиоканал, както и в списъка на всяко да са зададени MAC адресите на останалите, които формират WDS мрежата.

Фиг.2.4.

Repeater (Повторител) Когато трябва да се разшири зоната на чуваемост, се използват AP в режим

на “повторител”. Повторителят работи на същия канал, на който работи и AP и



така се осъществява достъпът до опорната мрежа. В повторителя се задава MAC адресът на опорното AP, като по този начин той симулира прозрачно опорното AP в отдалечената зона. В отдалечената зона се чува опорното AP с неговото оригинално име и параметри. Само физическият MAC адрес се различава, като в отдалечената мрежа MAC адресът е този на устройството “повторител”.

Фиг.2.5.

Bridge (Мост) Предназначен е за прозрачно свързване на 2 мрежови сегмента, като по този

начин могат да се свържат безжично локалните мрежи на отдалечени офиси. Безжична връзка е възможна само между двете устройства, които работят в режим “AP Bridge”, като по този начин те прехвърлят прозрачно всеки пакет от единия локален LAN сегмент към отдалечения.

Фиг.2.6.

Определяне на радиопараметрите на средата

Децибел (dB) Децибелът се използва за изразяване на относителната разлика в нивото

между два сигнала. dB = 10log10(P1/P2) – отнася се по мощност (1) dB = 20log10(U1/U2) – отнася се по напрежение или ток (2) Използва се поради 2 причини: • Да се представят големите порядъци чрез по-малки и по-лесни за работа

числа,



• Затихването и усилването на сигнала в звената може да се представи чрез по-прости действия – изваждане и събиране.

Предавател10mW10dBm

Усилвател

100 пъти20dB

Загуби по кабел и среда

31622 пъти45dB

Приемник

Мощност на входа:0,0316mW

-15dBm

+10dbm

+30dbm

-15dbm

Фиг.2.7.

На фигура 2.7 е представен пример за употреба на понятието децибел. Целта е да се сравни работата по традиционния начин – с отношения, и облекчението, което предлага работата в децибели. На примера мощността на излъчващ предавател е 10 mW, което спрямо някаква приета опорна единица се превръща в децибели. При безжичните мрежи по IEEE 802.11 като реперна единица се приема 1 mW с оглед на това, че всички допустими предавани мощности от крайни устройства не надвишават 1W. След превръщането на предаваната мощност чрез (1) се получава, че мощността от предавателя възлиза на +10 dbm. За изчислението на мястото на P1 е заместена мощността на предавателя в миливата, а на мястото на P2 е заместена приетата опорна стойност, която, както се уточни по-горе, е 1 mW. Изходната стойност, която се получава след изчисление, се измерва в dBm (на практика това са децибели, отнесени спрямо миливат – последното “m” след dB указва това).

Следва усилвател, чието усилване е 100 пъти. Изразено в децибели то се пресмята пак по формула (1), като тук отношението P1/P2=100. Като резултат от изчислението става видно, че усилването на звеното възлиза на 20dB.

След това е звено, което представя загубите по свързващите кабели и средата. Изчислението на загубите в средата ще се разгледа по-нататък. Тук се дава пример с една типична стойност от 31622 пъти. След преобразуване чрез формула (1) загубите в средата по мощност възлизат на 45dB.

Цел на примера е да се определи колко е мощността на входа на приемника. Ако се работи с отношения, ще имаме по-сложни умножения и деления с големи порядъци. Ако се работи в децибели, ще имаме сумиране на усилването на усилвателя и изваждането на загубите от средата от стойността на предавателя. Това възлиза на: RX = 10dbm + 20dB – 45dB = -15dbm (3)




Безжични локални мрежи – WLAN

Сега вече може да преобразуваме стойността чрез антилогаритмуване на база на (1), при което ще се получи 0,03162mW. В повечето случаи не е и необходимо преобразуването в mW поради факта, че в техническата документация всички радиопараметри на крайните устройства се дават в dBm, а усилването на антените и загубата в свързващите кабели също се дава в dB.

Превръщане на мерните единици Превръщане на единиците за мощност от миливат към dbm:

P (dbm) = 10*log(Pmw) (4)

Пример: 23.01 dbm = 10*log (200mW) Превръщане на разстоянията от футове в метри и от мили в километри и

обратно: 1 Meter = 1 Feet * 0.3048 (5) 1 Km = 1 Mile * 1.609344 (6)

Пресмятане на параметрите на линково радиотрасе Изходната мощност от антената на дадена станция може да се пресметне

използувайки следната зависимост: EIRP = TX Power – Coax Cable Loss + TX Antenna Gain (7)

където: EIRP се изчислява в dbm, TX Power – изходната мощност на предавателя в dbm, Coax Cable Loss – загуби в свързващия антената фидер в dB, TX Antenna Gain – усилване на предавателната антена в dB. Нивото на приетия входен сигнал до входа на приемника се изчислява по

следната зависимост: RX Signal = EIRP – FSL + RX Antenna Gain – Coax Cable Loss (8)

където: RX Signal се изчислява в dbm, EIRP – стойността, изчислена от (7), FSL – стойността на загубите в средата (виж т.4.4), RX Antenna Gain - усилване на приемната антена в dB, Coax Cable Loss – загуби в свързващия антената фидер в dB. За да може едно проектирано трасе да работи гарантирано, е необходимо да

се въведе оперативен запас. Той се изчислява по следната зависимост: SOM = Rx signal level - Rx sensitivity (9)

където:


SOM e оперативният презапас в dB (виж по-долу), Rx signal level – ниво на приетия сигнал по (8), Rx sensitivity – чувствителност на приемника (взима се от техническата

спецификация на радиооборудването) Нива на SOM: • Повече от 20db – напълно достатъчно за гарантирана връзка, • Около 14db е типичната стойност, която трябва да презапасим, • Стойности на SOM около и под 10db също дават добри резултати при

незашумена среда.

Пресмятане на загубите в средата

Фиг.2.8.

За да може едно трасе да бъде проектирано, трябва да се вземат под внимание загубите на радиоенергия в свободното пространство. Фигура 2.8 дава нагледна представа за методиката за изчисление за честоти 2.4GHz и 5.8GHz. Таблицата в долната част на фиг. 2.8 представя примерни стойности за затихването в средата за типична дистанция от 2, 4, 6, 10 и 20 мили. Формулата, по която се пресмята затихването в средата, е следната: FSL = 36,6 + 20log F + 20log D (10)

където: FSL е затихването в средата в dB, F – честотата в MHz, D – разстоянието между приемника и предавателя в мили.

Параметри на радио оборудването Най-важните параметри на използваното радиооборудване са два: мощност

на предавателя и гранична чувствителност на приемника. И двата параметъра





се дават в техническата спецификация за конкретния модел. Мощността на предавателя е в dBm, като типичните стойности са от порядъка на +18dbm до +20dbm (в порядъка 63 до 100mW). На пазара се срещат и радиоустройства, които поддържат и по-голяма изходна мощност.

Друг важен параметър е чувствителността на приемника. Тя също се дава в dbm и представлява приетата входна мощност, достатъчна за правилното декодиране на полезния сигнал. Типичните стойности са между –75dВm и –100dВm (знакът „минус” означава, че мощността е под опорната стойност от 1 mW). Колкото по-малка е стойността (по-отрицателна), толкова чувствителността на приемника е по-добра, което означава, че е необходима по-малко полезна приета енергия, за да бъдат възстановени данните.

Пример за прилагане на знанията от текущата точка Зададеният пример цели да демонстрира използването на зависимостите,

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

Мощност на предавателите – 100 mW, Чувствителност на приемниците – -89 dВm, Усилване на антените – 12 dB, Загуби в свързващите фидери – 1 dB, Работен честотен диапазон – 2.44 GHz. Решение: А) Пресмята се изходната мощност в dbm чрез (1):

P = 10log(100) = 20dbm (11)

B) Пресмята се изотропно излъчената мощност чрез (7): EIPR=TX Power–Coax Cable Loss+TX Antenna Gain=20–1+12=31dbm (12)

C) Пресмята се необходимият сигнал в приемника, нужен за правилно декодиране на данните чрез (9). Взема се предвид и оперативен презапас от 14db. RX_signal = SOM + RX_sensitivity = 14 + (-89) = -75dbm (13)

D) Определя се необходимата стойност за FSL по (8): FSL = EIRP – RX Signal + RX Antenna Gain – Coax Cable Loss = 31 - (-75) +12 – 1 = 117 dB (14)

E) Чрез зависимостта (10) се определя какво е разстоянието в мили на база на известните параметри: log D=(FSL–36,6–20logF)/20={117– 36,6–20log(2440)}/20 = 0,6326 (15)

D = 10 0,6326 = 4,29 мили F) След преобразуването в километри чрез (6) се получава:


D(km) = D(mil)*1,609344 =4,29 * 1,609344 = 6,9km (16)

Извод: От решението става ясно, че с даденото оборудване може да се постигне ефективно разстояние от 6,9 km.

Настройка и задаване на режимите на работа Настройка на параметрите и режимите на работа на точката за достъп става

чрез Web интерфейса, който тя предлага. За целта трябва да се влезе чрез Web браузър в администраторския панел, използвайки IP адреса за администрация. Подразбиращият се адрес е 192.168.2.1, а подразбиращото се потребителско име admin и парола 1234. За целта на станцията, от която ще администрираме, трябва да имаме въведен IP работен адрес от същата под-мрежа. Тоест IP адрес от 192.168.2.х би ни свършил работа с маска 255.255.255.0. Трябва да се внимава х да не съвпада с адреса на безжичното устройство.

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

Фиг.2.9.

След това може да продължим със задаването на режима на работа от MODE, както и на стандарта, по който ще се работи: IEEE 802.11b или IEEE 802.11g от полето BAND. Работният канал може да се избере от Channel Number. Ако трябва да се фиксира работна скорост, това става от менюто ADVANCED SETTING и оттам в полето Data Rate се задава изискваната работна скорост. При необходимост от филтриране по MAC адрес е необходимо да се избере менюто с име MAC Filtering (Фигура 2.11).



Фиг.2.10.

Чрез описване на MAC адресите е възможно да бъде санкциониран достъпът само до определени клиенти.

Фиг.2.11.

ЗАДАЧИ ЗА ИЗПЪЛНЕНИЕ 1. Да се конфигурира инфраструктурна мрежа от тип AP-Client като се използва топологията от фигура 2.12. 2. Да се настрои работният канал на AP1 на 1-ви, и да се използва за име на мрежата TEST. 3. Да се настрои филтърът по MAC адрес за дадените устройства. 4. Да се измери пропускателната способност за различните скорости и



режими на работа: - при 1, 5.5 и 11 Mbps за тип на работа по стандарта IEEE 802.11b. - при 6 и 54 Mbps за тип на работа по стандарта IEEE 802.11g.

5. Да се анализират резултатите.

Лабораторна постановка Топология на мрежата, която ще се използва за провеждане на

упражнението, е дадена на фигура 2.12.

1. SERVER2. CLIENT

3. CLIENT

AP2 AP1

Фиг.2.12.

В така изградената мрежа имаме една работна станция (1), която ще използваме като сървър, и на нея ще бъде стартирано сървърно приложение за генериране на данни по мрежата. Тези данни ще се измерват от отдалечените PC, свързани посредством безжична връзка към общата локална мрежа. Това може да бъде работна станция (2), свързана чрез мрежовия жичен интерфейс към безжично устройство (AP2), което е настроено да работи като клиент в безжичната мрежа, асоциирайки се към AP1. Сървърът (1) е свързан към безжичната мрежа посредством безжично устройство (AP1), което работи в режим “точка за достъп”(AP). Възможно е мобилно устройство (3) с вграден безжичен интерфейс също да бъде използвано за измерванията. Това може да е laptop или palmtop.

Указания За измерване на пропускателната способност ще се използва външно

конзолно приложение, което може да бъде намерено в директория NetCPS. За измерването се използват 2 станции, като едната се конфигурира като сървър (1) а другата като клиент за NetCPS (3). Това става чрез съответни параметри на приложението, дадени по-долу:

netcps [options] [Remote host] , където option е параметър и се задава с тире, а Remote host е IP адресът с

който трябва да се осъществи връзка. Netcps – server





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

След изпълнение на командата се получава статистика за пиковата и средната трансферна скорост по канала. Примерът е даден за Ethernet мрежа 100 Mbps: C:\Temp\Shared>netcps 192.168.0.2 NetCPS 1.0 - Entering client mode. Press ^C to quit Connecting to 192.168.0.2 port 4455... Connected! ---> CPS 7651328.00 KPS: 7472.00 MPS: 7.30 Avrg CPS 7456805.50 KPS: 7282.04 MPS: 7.11 Peek CPS 7652352.00 KPS: 7473.00 MPS: 7.30 Done. 104857600 Kb transferred in 14.06 seconds.

ДОПЪЛНИТЕЛНА ЛИТЕРАТУРА • Beasley, J., “Networking”, Second Edition, Pearson Education, 2009, ISBN-

13: 978-0-13-135838-6. • Halsall, F., “Computer Networking and the Internet”, Fifth Edition, Pearson

Education, 2005, ISBN 0-321-26358-8. • Roshan, J. and J. Leary, “802.11 Wireless LAN Fundamentals”, Cisco Press,

2003, ISBN: 1-58705-077-3 • Basagni, S., M. Conti, S. Giodano, and I. Stojmenovic, “Mobile Ad-hoc

Networking”, Wiley, 2004, ISBN 0-471-37313-3.


ТЕМА 3 МОДЕМИ И GSM. УПРАВЛЕНИЕ ЧРЕЗ AT КОМАНДИ

ЦЕЛ НА УПРАЖНЕНИЕТО Целта на упражнението е запознаването на студентите с устройството и

основните функции на телефонен и GSM модем, както и с процедурата за изграждане на връзка между два модема. Разгледани са и с основните команди за управление на модем (АТ команди) и специфичните команди от спецификацията GSM 7.05/7.07.

ТЕОРЕТИЧНА ЧАСТ Телефонните линии са проектирани да предават тонални (аналогови)

сигнали. За да се използват за предаване на данни от цифрово устройство, е необходимо тези сигнали да се преобразуват. Преобразуването на цифровите сигнали в тонални за предаване на данни се нарича модулация, а устройството – модулатор. Обратното преобразуване е демодулация, а устройството – демодулатор. За предаването на данни в двете посоки по телефонна линия е необходимо всяко от комуникиращите устройства да има модулатор и демодулатор. Комбинираните модулиращи и демодулиращи устройства се наричат модеми.

Устройство и функции на модем Функционално модемът се състои от три части (фигура 3.1): Micro-Controller

Unit (MCU), Data Pump Unit (DPU), Direct Access Arrangement (DAA).

Фиг.3.1. Устройство на модем

• MCU е вграден контролер, който извършва компресията и корекцията на грешки на данните. Той имплементира АТ командите и интерфейса за връзка с предаващото устройство.

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

• DAA представлява физическия интерфейс към телефонната линия и филтрите за ограничаване на честотната лента. Той изпълнява

Тема 3Стр.26 Модеми и GSM. Управление чрез AT команди



Модеми и GSM. Управление чрез AT команди

аналоговите функции на модема – открива наличност на линията, сигнал „заето” и други.

BaudRate и BitRate Приети са три основни мерни единици за представяне на скоростта на

предаване. Величината бода за секунда е свързана с изменението на сигнала по физическата линия. При различните методи на модулация може да се предава различно количество информация за едно значение, затова този метод не е популярен. Най-популярната единица за измерване на пропускателната способност е бита за секунда. Тя е общоприета за измерване скоростта на предаване на данни. В модемите се въвежда една допълнителна величина, която представя скоростта на предаване на потребителските данни, като отчита предаването на служебна информация – символ в секунда. Един символ се равнява на повече от осем бита – 7 или 8 даннови, един стартов и 1 или 2 стопови бита.

Видове модеми Аналоговите модеми се разделят на три вида: хардуерни, софтуерни и Win

модеми. При хардуерните модеми са реализирани и трите основни части. Това ги прави по-бързи и платформено независими. При Win модемите са реализирани само DPU и DAA, като компресията и корекцията на грешките, както и имплементацията на АТ командите, се извършват от драйверна програма, работеща на процесора на потребителската станция. При софтуерните модеми само DAA се реализира физически и всички останали функции се изпълняват от драйверна програма. Последните два вида се използват при необходимост от ниска консумация и намаляване на апаратната част (най-често при мобилни компютърни системи).

При аналоговите модеми за предаване на данни се използва честотна лента за предаване на глас, която не надвишава 3.3kHz. При тази честота съвременните методи за модулация позволяват скоростта на едновременно предаване на данни в двете посоки да достигне 33.6kb/s.

Има създадени методи за предаване на данни по телефонни проводници без използване на честотното ограничение, което позволява много по-високи скорости, зависещи от сечението на проводника и дължината на линията. За целта се използват DSL модеми. Всъщност DSL е фамилия за модемни технологии за високоскоростно предаване на данни по телефонна линия. Най-популярните реализации на DSL са: HDSL, ADSL, VDSL. В тях се комбинира предаването на данни с предаването на глас, тъй като за двете се използват различни честотни ленти (фигура 3.3). Основният недостатък на ADSL (фигура 3.2) е наличието на NID (Network Interface Device) и splitter при клиента. Това


са устройства, които се инсталират и конфигурират само от доставчика и цената им е относително висока.

Фиг.3.2. ADSL архитектура.

Фиг.3.3. Разпределение на честотите при ADSL.

Друг популярен начин на високоскоростно предаване на данни е през кабелен модем (кабелна телевизия). Архитектурата на предаване през кабелен модел е показана на фигура 3.4, а разпределението на честотите – на фигура 3.5.

Фиг.3.4. Архитектура за кабелно предаване.

Фиг.3.5. Разпределение на честотите при кабелно предаване.

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



честотната лента е обща и увеличаването на потребителите силно влияе на връзката на отделния потребител. За сметка на това кабелното предаване има по-добри характеристики като разстояние и честотна лента (broadband).

Процедура за предаване на данни между два модема При предаването на данни по телефонната мрежа предаващата и приемащата

станция се разделят на две части – DTE (data terminal equipment) и DCE (data circuit-terminating equipment). Първата включва потребителската или сървърната машина, а втората – модема. Виж фигура 3.6.

Фигура 3.6 показва последователността от сигнали при осъществяването на връзка, предаването на данни и разпадането на връзката. Използва се факта, че набиращият модем има автоматично избиране, а отговарящият – автоматичен отговор.

Фиг.3.6. Процедура за свързване на два модема.

Когато DTE е готово да извърши или приеме трансфер на данни, то установява сигнала DTR в “1” и локалното DCE отговаря с установяване на DSR в “1”. Връзката започва да се създава, когато набиращото DTE изпрати номера на отдалеченото устройство към модема. Когато модемът на отговарящото устройство засече сигнал “звънене” по линията, той установява сигнала RI в “1” и съответното DTE отговаря с RTS = “1”. След това набиращият модем изпраща носеща честота по линията в отговор и след кратко изчакване изпраща към локалното си DCE сигнал CTS = “1”. Това е знак да се подготвят данните за изпращане. Когато набиращият модем засече носещата


честота, установява сигнал CD в “1”. В този момент връзката е осъществена и прехвърлянето на данни може да започне. Обикновено то започва с предаване на кратко съобщение “покана за изпращане” от устройството, което подава заявка за данни. След това съобщение получаващото DТE установява RTS в “0”, в резултат на което локалното DCE спира изпращането на носещата честота и установява CTS в “0”. От другата страна се засича липсата на носеща честота и се установява CD в “0”. Така започва предаването на данните. Тези действия се повтарят при всяко изпращане на съобщение. След завършване на цялата трансакция започва процедура по разпадане на връзката. Началото й е с установяване и от двете DTE на сигнала RTS в “0”, което предизвиква спиране на предаването на носещата честота и от двата модема. В отговор на това и двата модема установяват CD в “0”. След това двете DTE установяват сигналите си DSR в “0” и в отговор модемите установяват DTR в “0”. Така връзката е прекратена.

Основни АТ команди Фирмата Hayes произвежда едни от първите “интелигентни” модеми и

въвежда система от команди за управлението им. Повечето съвременни производители поддържат тези команди, които се възприемат като стандарт. Различните модеми поддържат различен набор от команди, затова ще разгледаме само някои от най-често използваните. АТ командите се въвеждат с префикс “АТ” и завършват с ”<CR>” (= 0x0D). Всяка подадена команда се потвърждава с “ОК” или “ERROR”. Ако се подадат повече от една команда на един и същ ред, се разделят със символа “;”. Команда, която в момента е в изпълнение се прекъсва от подаване на символ по серийния порт.

Някои основни команди за управление на модем са дадени по-долу: А/ – повторение на последната команда. +++ – последователност, която кара модема принудително да премине в команден режим от режим на предаване (обратната команда е О). АТH – прекъсване на линията. АТА – отговор на обаждане. АТD [номер] – набиране на телефонен номер. Използва се с допълнителни модификатори. Р – импулсно набиране; Т – тонално набиране; , – пауза; R – набира се последният набран номер. АТZ – връща настройките по подразбиране на модема. АТIn – дава информация за модема I0 – връща идентификационния код на модема; I5 – връща страната производител (или нейния код); I6 – връща модела на модема; АТL – управлява силата на звука (говорителя). АТM – спиране и пускане на звука (говорителя). М0 – спира звука напълно, М2 – включва звука за постоянно, М1 – звукът е пуснат до установяване на връзката.


GSM модеми GSM комуникацията сериозно се различава от стандартната телефония.

Въпреки това тя е създадена, за да я замести, използвайки радиовълни за преносна среда. Затова при създаването на GSM оборудване са запазени някои основни идеи от телефоните. Например управлението чрез АТ команди и сериен интерфейс за достъп до оборудването.

Най-важната характеристика на GSM комуникацията е, че това е мрежа от клетки. Мобилното устройство използва най-близката клетка за предаване на информацията. Основните елементи на GSM мрежата са: мобилна станция (MS), модул за идентификация на потребителя (SIM), базова приемо-предаваща станция (BTS), контролер на базова станция (BSC), транскодер и адаптер (TRAU), център за превключване на мобилни услуги (MSC), домашен регистър (HLR), гост регистър (VLR), регистър за идентификация на оборудване (EIR), публична наземна мобилна мрежа (PLMN) – фигура 3.7.

Фиг.3.7. Архитектура на публична наземна мобилна мрежа.

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

BSC е централно устройство на група от съседни BTS и изпълнява контролиращи функции. Понятието BSS – базова подсистема – се отнася до BSC и прилежащите му BTS. TRAU извършва компресия на данните и управление на честотния спектър за предаване. Архитектурно той е част от BSS и се представя като „черна кутия”. MSC служи за маршрутизиране на



информацията, пристигаща от множество BSC. HLR е голяма база от данни за потребителите на дадената мобилна мрежа. VLR е приложена, за да не се претоварва HLR. Тя съдържа информацията само за тези потребители, които са текущо вързани към мрежата. EIR е база от данни на идентификационните номера на телефоните, не на потребителите. Това се налага за борба с кражбата на мобилни телефони. При кражба може да се забрани достъпът до мрежата не само по SIM, но и по идентификация на апарата.

Специфични АТ команди за GSM модем Всеки GSM модем освен основните АТ команди поддържа и специфични

команди. Специфичните GSM команди са описани в спецификацията GSM_7.07, а специфичните за SMS съобщения – в GSM_7.05 и започват с префикса “AT+C”. Освен основните АТ команди и специфичните GSM команди повечето съвременни мобилни устройства поддържат и факс команди („АТ+F”), GPRS команди („АТ*”) и така наречени „потребителски” команди, които отговарят само за конкретния производител и управляват специфични настройки на телефона (модема). За Siemens тези команди са с префикс „АТ^S”.

Пример за специфични GSM команди: AT+CGMI – код на производителя; AT+CGMM – модел на устройството; AT+CGSN – идентификация на телефона – IMEI; AT+CHUP – прекъсва настоящите разговори; AT+CLIP – заявка за използване на показването на номера на набиращия: AT+CLIP? – показва текущата настройка; AT+CLIP=n – променя настройките, като n=0 изключва, а 1 включва. AT+CLIR – заявка за INCOGNITO при набиране: AT+CLIR? – показва текущата настройка; AT+CLIR= n – променя настройките, като 0 – по настройки от мрежата, 1 – включено, 2 – изключено; AT+CLVL – управление на нивото на звука (виж тест на командата за поддържаните нива). AT+CVIB – управление на вибрациите (виж тест). АТ+CMGL – показване на списък с SMS съобщения (виж Test командата); АТ+CMGR – прочитане на SMS (виж Test командата); АТ+CMGS – изпращане на SMS (виж Test командата); АТ+CNMI – показване на пристигащ SMS; * По спецификация командите са четири типа: за тест, за изпълнение, за четене и за запис.





ЗАДАЧИ ЗА ИЗПЪЛНЕНИЕ 1. Запознаване с устройство и функции на модем. 2. Запознаване с процедурата за връзка между два модема. 3. Запознаване с основните АТ команди и подаване на АТ команди през

HyperTerminal. 4. Запознаване с GSM модеми и със специфични AT команди за GSM модеми. 5. Използване на АТ команди.

Стандартни: набиране, отговор на обаждане, прекъсване на линията. Специфични за GSM: получаване на информация за марката, модела и идентификационния номер на апарата, променяне на вътрешни настройки – ниво на звука, език, прочитане на списък с SMS, изпращане на SMS.

6. Разучаване на SMS PDU формата и декодиране на съобщения.

ДОПЪЛНИТЕЛНА ЛИТЕРАТУРА • Стандарти за GSM – http://www.etsi.org/ (GSM 02.30, 02.82, 03.38, 03.40,

03.41, 04.08, 04.11, 07.05, 07.07) • Heine, G., “GSM Networks – Protocols, Terminology and Implementation”,

Artech House, 1998, ISBN: 0-890-06471-7. • Tanenbaum, A., “Computer Networks, Fourth Edition”, Prentice Hall 2003,

ISBN: 0-13-066102-3. • Формат на SMS PDU – http://www.dreamfabric.com/sms/. • Въведение в GSM – http://www.gsmfavorites.com/documents/.


ТЕМА 4 АДРЕСИРАНЕ В ИНТЕРНЕТ. DHCP– СЪЩНОСТ И КОНФИГУРАЦИЯ

ЦЕЛ НА УПРАЖНЕНИЕТО Целта на упражнението е да запознае студентите с адресирането в интернет,

структурата и функциите на протокола IP и разделянето на мрежи на подмрежи. Представени са основните функции на протокола DHCP за конфигуриране на хостове в локална мрежа. Запознават се студентите с инсталиране и конфигуриране на DHCP сървър под ОС Linux.

ТЕОРЕТИЧНА ЧАСТ Интернет протоколът (IP) е едно от най-важните средства, чрез които е

изградена мрежата интернет. Неговите основни функции са: • да дефинира базова единица за пренос на информация (дейтаграма), • да дефинира схемата за адресация в интернет, • да осигури намирането на пътя на дейтаграмата (маршрутизация).

Адресиране в интернет. IPv4 и IPv6. Адресирането в интернет се базира на IPv4. Съществуват експериментални

мрежи, които се базират на IPv6. Заглавните части на двата стандарта са показани на фигури 4.1 и 4.2.

Фиг.4.1. IPv4 Header

IP адресът във версия 4 (IPv4) представлява 32-битово число, което уникално идентифицира всеки хост в интернет и е прието да се записва като четири десетични цифри, разделени с точки. Схемата на адресиране е йерархична, логически адресите се състоят от две части: мрежова част и хост част. Стойностите за хост частта, които се състоят само от нули или само от единици, са резервирани и не адресират хост в мрежата. IP адрес, който има хост част само нули, показва адреса на мрежата, а адрес, чиято хост част е само единици, се използва за broadcast адрес – адресиране на всички хостове в дадена мрежа.

Тема 4 Стр.34 Адресиране в интернет. DHCP– същност и конфигурация


Освен това адресите на мрежи 0.0.0.0 и 127.0.0.0 също са резервирани. Първият се нарича “маршрут по подразбиране”, а вторият – локален адрес (local loop). Обикновено адрес 127.0.0.1 се присвоява на локалния интерфейс и служи за тестването му.

Фиг.4.2. IPv6 Header

За удовлетворяване на различните нужди на потребителите се осигуряват пет класа адреси, означени с латинските букви от A до E. Адресите от клас А имат 8 бита за мрежова част и 24 – за хост. Първият байт на адреса винаги започва с ‘0’. На практика има 128 мрежи от този клас и 224 -2 хоста във всяка от тях. Този клас адреси могат да бъдат познати по стойността на първия байт – от 1 до 126.

При адресите от клас В най-старшите два бита заемат винаги стойностите ‘10’. Използват се 14 бита за мрежова част и 16 – за хост. Следователно има 214 мрежи от клас В с по 216 -2 хоста. Първият байт на адресите от клас В заема стойности от 128 до 191.

При адресите от клас С най-старшите 3 бита заемат стойностите ‘110’, следващите 21 бита се използват за адрес на мрежата, а оставащите 8 бита - за адрес на хост. Следователно има 221 мрежи от клас С, всяка с по 254 хоста. Първият байт заема стойности от 192 до 223.

Адресите от клас D се използват за адресиране на групи от компютри – multicast. Първите четири бита на първия байт са ‘1110’, а всички останали 28 бита показват адрес на група от компютри. За повече информация RFC 3171 или http://www.iana.org/assignments/multicast-addresses.

Освен разделянето на адресите на класове е предвидено и друго средство за по-нататъшно разделяне на всяка мрежа на подмрежи. Това се осъществява чрез маска - subnet mask. Маската е 32-битово число, което се състои от последователност от единици, последвана от последователност от нули. Винаги поредиците от единици и от нули са непрекъснати и тази от нули следва тази от единици.(Не може да има единици след започване на нулите. Например


http://www.iana.org/assignments/multicast-addresses


“11111100000” е част от валидна маска, “1110000110” – не). Чрез тази маска се извършва изместване на разделителната линия между мрежовата и хост частите. Чрез прилагане на побитово “И” между адреса и маската се отделя мрежовата част. Така можем, притежавайки мрежа от даден клас, да я разделим на няколко мрежи. Разделянето на подмрежи подпомага работата на мрежовото оборудване и ограничава broadcast домейните.

Фиг.4.3. Адресите от клас Е са резервирани за бъдещо ползване.

Бързото изчерпване на мрежите от клас В налага някои големи организации да вземат няколко мрежи от клас С. От друга страна, големият брой мрежи от клас С прави таблиците за маршрутизация тежки и големи. Това довежда до възникването на т.нар. супермрежи и появата на безкласова маршрутизация ( Classless Inter-Domain Routing – CIDR). Супермрежа се нарича група от мрежи, които се определят от последователни IP адреси. Всяка супермрежа има уникален супермрежов адрес, който се състои от старшите битове, които са общи за цялата група от последователни адреси. Например за групата адреси от 194.141.0.0 до 194.141.7.0 общи са първите 21 бита, следователно адресът на супермрежата се задава със следния адрес и маска – 194.141.0.0/21.

Друго решение на изчерпващото се адресно пространство е въвеждането на т.нар. частни IP адреси. За да може да функционира интернет, е необходимо всеки хост, свързан към глобалната мрежа, да притежава уникален IP адрес. За мрежите, които обаче не са свързани към интернет може да се използват кои да е мрежови адреси, стига да не се повтарят вътре в самата мрежа. Използването на кои да е IP адреси е опасно, понеже мрежата може евентуално да бъде свързана към интернет. Поради тази причина са резервирани три блока от IP адреси, които могат да бъдат използвани за адресиране на хостовете в частните мрежи. Пакети, които съдържат адрес принадлежащ на някои от тези три блока, няма да бъдат маршрутизирани от гръбначните маршрутизатори в интернет. Описание на тези адреси може да бъде намерено в документа RFC 1918.




Адресиране в интернет. DHCP– същност и конфигурация

Табл.4.1. Частни IP адреси Network Class IP address range

Class A 10.0.0.0 /8 Class B 172.16.0.0 /12 Class C 192.168.0.0 /16

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

Dynamic Host Configuration Protocol (DHCP) Услугата DHCP централизира и управлява разпределението на информация

за конфигурирането на TCP/IP, като задава автоматично IP адреси и друга информация за параметрите на TCP/IP на компютри, които са настроени като DHCP клиенти. Използването на DHCP може да отстрани голяма част от проблемите, свързани с ръчното конфигуриране на TCP/IP. В това упражнение се разглеждат необходимите умения и се дава информация за инсталирането и конфигурирането на услугата DHCP. В него се разглеждат и DHCP договорите.

Въведение в DHCP DHCP представлява TCP/IP стандарт за опростяване на управлението на IP

конфигурацията. DHCP е разширение на протокола BOOTP (Bootstrap Protocol), който е базиран на UDP/IP (User Datagram Protocol/Internet Protocol). ВООТР позволява на хостовете да се самоконфигурират динамично по време на началното си зареждане. Всеки път, когато даден DHCP клиент се стартира, той иска адресна информация за IP от DHCP сървър. Тази информация включва следното:

• IP адрес, • маска на подмрежата, • адрес на подразбиращия се шлюз /default gateway/, • адрес на DNS сървър, • незадължителни параметри, като име на домейн, WINS сървър. Когато някой DHCP сървър получи заявка за IP адрес, той избира адресна

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




Ръчно срещу автоматично конфигуриране на TCP/IP За да разберем какви са предимствата на услугата DHCP при кон-

фигурирането на TCP/IP за клиент, ще съпоставим ръчния метод за конфигуриране на TCP/IP с автоматичния метод с използване на DHCP, както е показано в таблица 4.2. Табл.4.2. Ръчно конфигуриране на TCP/IP Конфигуриране на TCP/IP с използване на

DHCP

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

Отпада необходимостта потребителите да получават от администратор адресна информация за конфигуриране на TCP/IP. Услугата DHCP осигурява цялата необходима информация за всички клиенти.

Ръчното въвеждане на адреса, маската на подмрежата или шлюза по подразбиране може да доведе до проблеми, вариращи от затруднени комуникации, ако е въведен некоректен шлюз по подразбиране или маска на подмрежата, до проблеми, свързани с дублирането на адреси.

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

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

Наличието на сървъри, на които работи услугата DHCP, отстранява допълнителната работа, която е свързана с ръчното конфигуриране на адреси, маски и шлюзове при преместването на компютри. Един DHCP сървър може да се грижи за множество различни мрежи едновременно.

Настройването на DHCP в дадена мрежа има следните предимства: сигурна и надеждна конфигурация; DHCP намалява конфигурационните грешки, причинявани от ръчно конфигуриране на IP адреси, като например типографски грешки или конфликти, причинени от вече зададени IP адреси, които по някаква причина се задават и на някой друг компютър; намаляване на мрежовата администрация; TCP/IP конфигурацията е централизирана и автоматизирана; мрежовите администратори могат централно да дефинират глобални и подмрежови специфични TCP/IP конфигурации. Клиентите могат автоматично да си настроят най-различни опции за TCP/IP, като използват настройките на DHCP сървъра. Промяната на адресите за клиентските конфигурации, които трябва да се правят често, като например клиенти, които често се движат от подмрежа в подмрежа, може да се правят ефикасно и автоматично. Повечето маршрутизатори могат да приемат DHCP конфигурационни поръчки, елиминирайки изискването да се прави отделен сървър за всяка подмрежа.


DHCP Lease Process Услугата DHCP предоставя адресна информация за IP на клиентските

компютри. Предоставянето на адресна информация за IP се нарича DHCP договор (lease). Процесът на създаване на DHCP договор се изпълнява, когато се случи едно от следните събития:

• TCP/IP се инициализира за първи път на даден DHCP клиент, • отказана е заявка на клиент за даден IP адрес, може би защото DHCP

сървърът е прекратил разрешението за използване, • клиентът, който преди това е получил разрешение за използване на някой

IP адрес, току-що го е освободил и изисква нов. Един DHCP договор може да бъде прекъснат ръчно, като се изпълни от командния ред командата ipconfig /release. След това с ipconfig /renew се прави заявка за нов IP адрес (нов договор).

Фиг.4.4. DHCP алгоритъм на обслужване на заявките

DHCP клиентът чака една секунда за оферта. Ако той не получи оферта, то изпраща съобщение 4 пъти на интервал от 2, 4, 8 и 16 секунди. Ако клиентът не получи оферта след четирите направени заявки, той използва IP адрес от резервирания интервал между 169.254.0.1 до 169.254.255.254. Така е сигурно, че клиентите на подмрежа, която няма DHCP сървър, могат да комуникират един с друг, като освен това DHCP клиентът продължава да се опитва да намери DHCP сървър всеки 5 минути. Когато DHCP сървър стане видим, клиентите получават валидни IP адреси, което им позволява да комуникират с хостовете във и извън техните подмрежи. DHCP използва четиристъпков процес за договаряне на информацията за IP адресирането на DCHP клиентите.





DHCPDISCOVER Първата стъпка в процеса за създаване на DHCP договор е DHCPDISCOVER

(DHCP откриване). В началото клиентът инициализира ограничена версия на TCP/IP и изпраща съобщение DHCPDISCOVER до всички (broadcast), с което търси местоположението на DHCP сървър и адресна информация за IP. Тъй като клиентът не знае IP адреса на DHCP сървър, той използва 0.0.0.0 като адрес на изпращача и 255.255.255.255 като адрес на получателя. Съобщението DHCPDISCOVER съдържа хардуерния адрес и името на компютъра на клиента, така че DHCP сървърите да могат да определят кой клиент изпраща заявката.

DHCPOFFER Втората стъпка в процеса за създаване на DHCP договор е DHCPOFFER

(DHCP предложение). Всички DHCP сървъри, които получат заявката за IP параметри и могат да предложат валидна конфигурация за клиента, изпращат bгоаdсаst-съобщение DHCPOFFER, включващо следната информация:

• хардуерния адрес на клиента, • IP адреса, който предлагат, • маска на подмрежата, • продължителността на DHCP договора, • идентификатор на сървъра (IP адреса на предлагащия DHCP сървър). DHCP сървърът изпраща brоаdсаst съобщение, защото клиентът все още

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

DHCPREQUEST Третата стъпка в процеса за създаване на DHCP договор се изпълнява, след

като клиентът приеме DHCPOFFER от поне един DHCP сървър и избере IP адрес. Клиентът изпраща bгоаdсаst съобщение DHCPREQUEST (DHCP заявка) до всички DHCP сървъри, показващо, че е приел определена оферта. Съобщението DHCPREQUEST включва идентификатора на сървъра (IP адреса), чиято оферта е приел клиентът. Тогава всички останали DHCP сървъри оттеглят офертите си и запазват своите IP адреси за следващата заявка за IP договор от други клиенти.

DHCPACK Последната стъпка в един успешен процес за създаване на DHCP договор се

изпълнява, когато DHCP сървърът, подал приетата оферта, изпраща bгоаdсаst-съобщение за успешно потвърждение към клиента под формата на съобщение




DHCPАСК (DHCP потвърждение). Това съобщение съдържа валиден DHCP договор за даден IP адрес, а може да включва и друга конфигурационна информация. Когато DHCP клиентът получи потвърждението, ТСР/IР е напълно инициализиран и клиентът се счита за свързан DHCP клиент. След като вече е свързан, клиентът може да използва TCP/IP, за да комуникира в мрежата.

DHCPNACK Ако заявката DHCPREQUEST е неуспешна, DHCP сървърът изпраща

bгоаdсаst съобщение за отказ (DHCPNACK). Това става в следните случаи: • клиентът се опитва да поднови DHCP договора за своя предишен IP

адрес, но този IP адрес вече не е достъпен, • IP адресът е невалиден, защото клиентският компютър е бил преместен в

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

Автоматично подновяване на договора През определени интервали DHCP клиентът пробва да поднови своя

договор, за да се подсигури, че ползва най-новата информация. DHCP клиентът се опитва да поднови своя договор, когато измине половината от срока на договора, чрез изпращането на съобщение DHCPREQUEST до сървъра. Ако DHCP сървърът е достъпен, той подновява договора със съобщение DHCPACK и регистрира нов срок на договора и актуализирани параметри на конфигурацията. Ако DHCP сървърът не е достъпен, клиентът продължава да използва настоящата конфигурация и DHCP клиентът не може да поднови своя договор. Той започва процедура по периодично разпръскване на съобщения DHCPDISCOVER до всички компютри в локалния сегмент и приема договор, пратен от който и да е DHCP сървър.

Ръчно подновяване на договора Може да се използва командата ipconfig /renew за ръчно подновяване на

TCP/IP конфигурацията. В този случай, клиентът най-напред пробва да се свърже с последния използван DHCP сървър. За да се изпрати наново заявка за търсене на DHCP сървъри в мрежата е необходимо предварително да освободим следите от предишната конфигурация. За целта се изпълнява командата ipconfig /release. Тази команда изпраща DHCPRELEASE съобщение до DHCP сървър да премахне договора.

Подновяване и прекратяване на DHCP договор Всички DHCP клиенти се опитват да подновяват своя DHCP договор, когато




изтече 50% от времето, в което могат да използват IP конфигурацията си. За да поднови своя договор, DHCP клиентът изпраща съобщение DHCPREQUEST директно към DHCP сървъра, с който е сключил DHCP договор. Ако DHCP сървърът е достъпен, той подновява разрешението за използване и изпраща на клиента съобщение DHCPАСК с новото време на договора и някои основни конфигурационни параметри. След като получи потвърждението, клиентът подновява своята конфигурация.

Всеки път, когато даден DHCP клиент се рестартира, той се опитва да получи същия IP адрес от оригиналния DHCP сървър. Ако заявката за сключване на договор е неуспешна, а времето, в което може да се използва старата конфигурация все още не е изтекло, DHCP клиентът продължава да използва същия IP адрес, до следващия опит за подновяване на договора.

Ако даден DHCP клиент не може да поднови договора си с оригиналния DHCP сървър за 50% или 87.5% от времето на договора, клиентът изпраща bгоаdсаst съобщение DHCPREQUEST, за да установи контакт с някой достъпен DHCP сървър. Всеки DHCP сървър може да отговори със съобщение DHCPАСК (като по този начин поднови договора) или със съобщение DHCPNACK (принуждавайки DHCP клиента да се инициализира отново и да сключи договор за използване на друг IP адрес).

Ако DHCP договорът е изтекъл или е получено съобщение DHCPNACK, DHCP клиентът трябва незабавно да преустанови използването на този IP адрес. След това DHCP клиентът започва нов процес за сключване на DHCP договор, за да получи разрешение за използване на нов IP адрес.

DНСР клиентите на Microsoft не инициират съобщения DHCPRELEASE, когато се изключват. Ако клиентът остане изключен до изтичането на срока на договора му (и разрешението за използване не е подновено), DНСР сървърът може да зададе IP адреса на този клиент на друг клиент, след като изтече срокът на предишния договор. Клиентът има по-добри шансове да получи същия IP адрес по време на инициализацията, ако не изпраща съобщение DHCPRELEASE.

Изисквания за сървъра, предоставящ услугата DHCP • IP адрес, маска на подмрежата, шлюз по подразбиране и други параметри

на ТСР/IР. DHCP сървърът не може да бъде едновременно и DНСР клиент на един и същ мрежови интерфейс,

• инсталирано DHCP сървърно приложени, • активирана DHCP област. Областта представлява група от IP адреси,

които могат да бъдат раздавани за използване на клиенти. Проверката за работещ DНСР сървър се осъществява в няколко стъпки.




Проверява се дали е стартиран процесът на DHCP сървърното приложение. При Linux/Unix това най-често е процесът dhcpd. Проверката може да стане, чрез изпълняването на следната команда като суперпотребител (root):

рs –ax | grep dhcpd За целта на упражнението при стартиран процес на DHCP сървъра, той

следва да бъде терминиран. За целта се използва командата: kill {номер на процес}

В текстов редактор се зарежда файлът /etc/dhcpd.conf, който съдържа конфигурационните параметри на DHCP сървъра. В него се добавят области от IP адреси.

Примерен конфигурационен файл на DHCP за SmoothWall 3.0 Express subnet 192.168.2.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; option domain-name "например.ком"; option routers 192.168.2.1; option domain-name-servers 194.141.39.9; range dynamic-bootp 192.168.2.100 192.168.2.200; default-lease-time 3600; max-lease-time 7200; host 1 { hardware ethernet 00:D0:59:C0:8C:D1; fixed-address 192.168.2.4; } host 2 { hardware ethernet 00:A0:C9:EB:95:5E; fixed-address 192.168.2.2; } }

Създаване на DHCP област Следващата стъпка след като услугата DHCP е инсталирана и работи, е да

създадем област. Тя тря6ва да 6ъде създадена преди даден DHCP сървър да предостави адрес на DHCP клиент. Областта представлява пул с валидни IP адреси, които могат да се предоставят на DHCP клиенти.

Когато се създава DHCP област, трябва да бъдат спазени следните правила: • тря6ва да създадете най-малко една област за всеки DHCP сървър, • трябва да изключите статичните IP адреси от областта, • можете да създадете множество области на един DHCP сървър, за да

централизирате администрирането и едновременно с това да задавате IP адреси, специфични за конкретната подмрежа. Можете да задавате само една област за дадена подмрежа,

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




едни и същи IP адреси не съществуват в повече от една област, за да не допуснете дублирането на IP адреси.

Разделяне на подмрежи Често се налага IP мрежите да се разделят на по-малки части, наречени

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

Подмрежите се въвеждат чрез мрежова маска (subnet mask), която е с формат на IP адрес, т.е. представлява 32-битово двоично число, записвано за удобство като четири десетични числа, разделени с точки. Маската се състои от две последователни полета от единици и нули, като полето с единици започва от най-старшия бит. Например, за мрежа от клас В маската може да има вида 11111111 11111111 11111111 00000000 или представена за удобство 255.255.255.0. Полето с единици определя мрежовата част на IP адрес, към който се прилага маската, а полето с нули - адреса на хоста. Чрез мрежова маска се извършва преместване на разделителната линия между двете части на адреса, дефинирана от съответния адресен клас А, В или С.

Да допуснем, че разполагаме с мрежа от клас В с IP адрес 131.24.0.0, т.е. с над 64 000 адреса на хостове. Тази мрежа може да се раздели на 256 подмрежи, като се вземат битове от хост частта на адреса и се използват като поле "подмрежа", както е показано на фигура 4.5.

Адрес на мрежа от клас В 1 0 Мрежа Мрежа Хост Хост Адрес на мрежа от клас В след прилагане на мрежова маска 255.255.255.0 1 0 Мрежа Мрежа Подмрежа Хост

Фиг.4.5. Подмрежови адреси

За целта се използва мрежова маска 255.255.255.0. В тази маска полето с единици включва старшите три байта на IP адреса, което означава, че тези байтове се използват за адрес на мрежа. Полето с нули включва най-младшия байт на IP адреса, който се използва за адрес на хост. В този пример старшите 8 бита от хост адреса служат за въвеждане на мрежова маската, а младшите - за адреса на хоста след разделянето на подмрежи. Следователно адресът 131.24.1.71 отговаря на хост 71 от мрежа 131.24, подмрежа 1, а адресът 131.24.8.5 отговаря на хост 5 от мрежа 131.24, подмрежа 8 и т.н.

Нека разгледаме един пример за мрежа от клас А (фигура 4.6). Мрежова маска 255.255.0.0 се прилага на 8 подмрежови бита за адреса на мрежа 34.0.0.0




и въвежда 256 подмрежи.

Адрес на мрежа от клас А 34.0.0.0

0 0 1 0 0 0 1 0 00000000 00000000 00000000 Адрес на мрежа Адрес на хост

Мрежова маска:1 1 1 1 1 1 1 1 11111111 00000000 00000000 Адрес на мрежа Адрес на

подмрежа Адрес на хост

Фиг.4.6. Мрежова маска на мрежа от клас А

Нека да разгледаме и един пример за мрежа от клас С. Да разделим на осем подмрежи мрежата от клас C с адрес 192.12.122.0. Използвайки първите три бита на четвъртия октет за мрежовата част на адреса, получаваме следната мрежова маска:

11111111.11111111.11111111.11100000 или 255.255.255.224 Мрежова маска 255.255.255.224 осигурява осем подмрежи, защото старшите

три бита на четвъртия октет се използват за създаване на осем подмрежови адреса. За адресиране на хостовете във всяка от тези подмрежи се използват най-младшите пет бита на IP адреса. Тъй като стойността 00000 на тези битове се използва за адрес на самата подмрежа, а стойността 11111 — за предаване до всички (broadcast), всяка от тези подмрежи включва 30 хост адреса.

ЗАДАЧИ ЗА ИЗПЪЛНЕНИЕ 1. Запознаване с адресирането в интернет. Класове адреси. Маска. 2. Даден е мрежов адрес. Да се определят класът и мрежата, в която е адресът. Тази мрежа да се раздели на 5 подмрежи, всяка с по 200 хоста. Да се изпишат областите на всяка подмрежа и съответната мрежова маска, както и да се даде пример за хост от всяка мрежа със съответната мрежова маска. 3. Запознаване с командите ping и ifconfig (ipconfig). 4. Да се провери дали на дадена машина работи DHCP сървър

(Linux/Windows). 5. Да се прекрати работата на дадения DHCP сървър и да се извършат следните промени: IP address range – 192.168.5.0 ÷ 192.168.5.55, network mask 255.255.255.0 и да се зададат 2 IP адреса в статичен запис на DHCP. Да се увеличи максималното време, за което се отпускат съответните адреси. За целта да се разгледат какви са възможностите на DHCP сървърът. 6. Да се разгледат архивите на DHCP сървъра. 7. Да се направи разлика между DHCP клиент за ОС Windows и ОС Linux.




ДОПЪЛНИТЕЛНА ЛИТЕРАТУРА • Боянов, К., Х. Турлаков, Д. Тодоров, Л. Боянов, В. Димитров, В. Желязков,

„Принципи на работа на компютърните мрежи. Интернет”, Апиинфоцентър „Котларски”, София, 2003, ISBN: 954 9713-06-7.

• Онлайн курс за разделяне на мрежи на подмрежи – http://www.freesoft.org/CIE/Course/Subnet/

• RFC DHCP документ – http://tools.ietf.org/html/rfc2131 • Howto документ за конфигурирането на DHCP сървър под ОС Linux –

http://tldp.org/HOWTO/DHCP/


ТЕМА 5 МАРШРУТИЗИРАНЕ В ИНТЕРНЕТ

ЦЕЛ НА УПРАЖНЕНИЕТО Целта на упражнението е да се представят основните протоколи за

маршрутизиране в интернет. Представени са и основните протоколи за маршрутизиране в мобилни ad-hoc мрежи. Студентите се запознават с конфигурирането на Linux станция като маршрутизатор и командите за проверка на маршрутизирането (route, traceroute).

ТЕОРЕТИЧНА ЧАСТ

Маршрутизиране Процесът на придвижването на пакет информация от един физически

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

Фиг.5.1. Пример за маршрутизиране.

В маршрутизиращата таблица се поддържа списък на най-добрите пътища до различни мрежи. За определянето на понятието най-добър маршрут се използват т.нар. мерни единици (metrics). Мерните единици представляват или оценка, или стойност на даден параметър на мрежовата връзка. Най-често използваните в маршрутизиращите протоколи мерни единици са:

• Hop count (брой преходи). Това е най-разпространената мерна единица.

Тема 5 Стр.47 Маршрутизиране в интернет



Маршрутизиране в интернет

Тя измерва броя маршрутизатори, през които преминават пакетите от мрежата източник до мрежата получател.

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

• Bandwidth (пропускателна способност). Тази единица измерва наличния капацитет на мрежовата връзка. Например, 10Mbps Ethernet връзката е за предпочитане пред 64К връзка.

• Reliability (надеждност). Тази единица осигурява оценка на надеждността на мрежовите връзки. Някои връзки излизат от строя по-често, отколкото други, така че се предпочитат по-надеждните връзки. Друг параметър на надеждността е времето, необходимо за възстановяване на повредена връзка.

• Communication cost (цена на комуникацията). Понякога доставянето на информация за най-краткото възможно време не е основната цел. Често целта е минимизиране цената на мрежовия транспорт.

Различните маршрутизиращи протоколи използват различни мерни единици. Някои от тях позволяват да се използват комбинации от мерни единици и да се задават различни нива на значимост за всяка мерна единица, така че да се намери оптималният маршрут.

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

Автономни системи Автономните системи (AS) представляват група от IP мрежи и

маршрутизатори под контрола на една или няколко организации, придържащи се към единни, ясно дефинирани правила за маршрутизиране в интернет (RFC-1930). Обикновено организациите, които контролират AS, са доставчиците на интернет услуги (ISP). Всяка автономна област притежава уникален AS номер, който се отпуска от организацията IANA. Автономните области се разделят на три групи:

• Multihomed AS – това са автономни системи, които имат връзка към




повече от един доставчик (ISP). По този начин автономната система остава свързана дори при напълно отпадане на някой от доставчиците.

• Stub AS – това са автономни системи, поддържащи връзка към един-единствен доставчик (ISP).

• Transit AS – този тип автономни системи осигуряват връзка между мрежи, свързани към тях. Доставчиците на интернет услуги (ISP) са винаги автономни системи от този тип.

В рамките на автономните системи се използват т.нар. интериорни маршрутизиращи протоколи (Interior Gateway Protocol – IGP). Този тип протоколи се разделя на дистанционно-векторни и протоколи със следене на връзката. За маршрутизиране между автономните системи се използват т.нар. екстериорни маршрутизиращи протоколи, пример за които е протоколът Border Gateway Protocol – BGP. Интериорни маршрутизиращи протоколи

Съществуват два основни метода за конфигурирането на един маршрутизатор и въвеждането на необходимата информация в маршрутизиращата му таблица – статично и динамично.

Статично маршрутизиране – изисква ръчно конфигуриране на всички пътища в мрежата. Работи най-добре в малки мрежи със сравнително постоянна топология. Ако в мрежата възникне промяна, това налага ръчно реконфигуриране. Ако такова не бъде извършено, маршрутизирането няма да бъде коректно. Ако е приложено статично маршрутизиране и маршрутизатор излезе от строя, мрежата трябва да се реконфигурира ръчно, така че да заобиколи отпадналия мрежови сегмент. В големи мрежи статичните пътища се използват предимно за повишаване на сигурността – като резервни пътища, в случай че отпадне динамично наученият маршрут.

Динамично маршрутизиране – използва маршрутизиращи протоколи за автоматично построяване на маршрутизиращите таблици. При възникване на промяна в топологията, свързана с отпадането на един или повече пътища, маршрутизаторите трябва да обновят своята таблица и да намерят алтернативен път, за да доставят пакетите до назначението им. Това се осъществява с използването на един от двата основни маршрутизиращи алгоритъма: дистанционно-векторен (distance-vector) и със следене на връзката (link-state). В зависимост от това кой от двата се използва, маршрутизиращите протоколи се делят на дистанционно-векторни и протоколи със следене на връзката.

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




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

Най-типичният пример за дистанционно-векторен маршрутизиращ протокол е RIP протоколът. Този протокол използва броя преходи като метрика (максималният брой е 15). Новата информация се обменя само между съседните маршрутизатори. При RIPv1 (RFC-1058) информацията се разпространява чрез broadcast пакети. Структурата на заглавната част е показана на таблица 5.1. Табл.5.1. Заглавна част на RIP пакетите.

RIP packet header

Command (1) Version (1) Must be zero (2)

Address family identifier (2) Must be zero (2) IP address (4)

Must be zero (4) Must be zero (4)

Metric (4)

В по-новата му версия RIPv2 (RFC-2453) вече се използва multicast адрес (224.0.0.9). Добавена е и поддръжка на (Variable Length Subnet Masking – VLSM), като по този начин се позволява по-добро оползотворяване на адресното пространство. Добавена е поддържа на автентификация, първоначално чрез предаване на ключ в чист вид, а по-късно и криптиран – MD5. Има възможност за балансирано натоварване в случай на повече пътища с най-добра метрика. Използва се циклично обхождане на пътищата в маршрутизиращата таблица. Поради избора на метриката балансираното натоварване не винаги е ефикасно. Версията на протокола RIPng (RFC-2080) представлява разширение на оригиналния протокол за поддръжка на IPv6. Други примери за дистанционно-векторни протоколи са IGRP и подобрената му версия EIGRP, които са фирмени протоколи и няма да бъдат разглеждани.

Протоколи със следене на връзката. Носят маршрутната информация до всички възли в мрежата. Тази маршрутна информация съдържа само




маршрутите до директно свързаните мрежи. Дори когато тази информация се изпраща до всички маршрутизатори в мрежата, техният намален размер води до по-ефикасен обмен на данни. Тези протоколи могат да използват multicast или unicast адресиране, което редуцира цялостния мрежови трафик. Всеки маршрутизатор съхранява най-добрия маршрут до мрежа с определено ID. Това води до намаляване на конвергенцията, когато даден маршрутизатор или мрежови сегмент излезе от строя. Единственият недостатък на тези протоколи е, че те изискват много повече планиране, конфигуриране, памет и процесорна мощ. Всеки маршрутизатор разполага с пълната топология на мрежата и на тази база посредством разновидност на алгоритъма на Dijkstra (Short Path First – SPF) изчислява най-кратките пътища до всеки един хост. Този тип протоколи са значително по-мащабируеми и могат да бъдат използвани в големи мрежи. Примери за протоколи със следене на връзката са OSPF (RFC-2328) и IS-IS. Табл.5.2. Заглавната част на OSPF пакетите.

OSPF packet header

Version (1) Type Message Length Source Router IP Address

Area ID Checksum Authentication Type

Authentication Octets (0-3) Authentication Octets (4-7)

При първоначалното пускане на OSPF протокола мрежата се наводнява от т.нар. LSA пакети, за да може всеки маршрутизатор да научи за цялостната топология, която се съхранява в база данни, идентична за всички маршрутизатори в мрежата. На следващата стъпка се изпълнява SPF алгоритъмът за построяване на дърво, което съдържа най-кратките пътища до всяка мрежа. Използва се цена като метрика. След тази фаза се обменят пакети само при промяна на състоянието на някоя от връзките. За откриване на такива промени се поддържа съседство между маршрутизаторите посредством обмяната на кратки – ‘hello’ съобщения, с използване на multicast адреси. Маршрутизиращи протоколи за мобилни ad-hoc мрежи (MANET)

Динамичната природа на мобилните разпределени мрежи води до честа и непредсказуема промяна на мрежовата топология, което затруднява и усложнява маршрутизирането. Маршрутизиращите протоколи трябва да отговарят на редица изисквания:

• да поддържат разумно малки маршрутизиращи таблици, • да могат да избират най-добрия път (това може да е най-бързият, най-

надеждният, с най-висока пропускателна способност, или икономически




най-изгодният), • да обновяват таблицата си в случай на изключване, преместване или

включване на нов възел в мрежата, • да изискват малко количество обменени съобщения и кратко време за

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

мрежи се разделят в няколко категории в зависимост от алгоритмите за построяване на маршрутизиращите си таблици и специфичните изисквания: проактивни (table-driven), реактивни (on-demand), хибридни, йерархични, географски, за минимална изразходвана мощност (power-aware), multicast, географски multicast (geocasting) и други.

Проактивни (table-driven). Проактивните маршрутизиращи протоколи поддържат информация за пътищата между кои да е две станции в мрежата. Тъй като тази информация обикновено се пази в таблици, те се наричат още table-driven протоколи. Предимството на проактивните маршрутизиращи протоколи е минималното време за използване на маршрута, тъй като той е наличен и може да се използва веднага. Недостатък е необходимостта от поддържане на таблици, което изисква мобилните устройства да имат по-голям капацитет от памет, да обменят често маршрутизиращи съобщения, което не позволява преминаването им в енергийно спестяващ режим. Подходящи са в случаите когато се цели качество на услугата (QoS). Към проактивните протоколи принадлежат Destination-Sequenced Distance-Vector (DSDV), Wireless Routing Protocol (WRP), Optimized Link State Routing (OLSR), Cluster-head Gateway Switch Routing (CGSR), Topology broadcast reverse path forwarding (TBRPF) и други.

Реактивни (on-demand). Реактивните маршрутизиращи протоколи изграждат път между два възела само при нужда от комуникация между тях. Обикновено това се осъществява посредством процедура за откриване на нов път, инициирана от източника на информацията и използваща механизма на наводняването (flooding). Веднъж открит, маршрутът се пази докато е наличен и докато се използва. След определен период, без да бъде използван, той се отстранява и при следваща необходимост се търси наново. Основният им недостатък е свързан с времето, необходимо за първоначално откриване на път. Тези протоколи се характеризират с минимални изисквания към ресурсите на мобилните устройства. Няма изискване за поддържане на свързаност със съседните устройства, което позволява преминаването в енергийно спестяващ режим. Към този тип протоколи спадат: Ad-hoc On-demand Distance Vector (AODV), Dynamic Source Routing (DSR), Temporary Ordered Routing Algorithm (TORA), Location-aided Routing (LAR), Ant-colony-based Routing Algorithm




(ARA), Flow Oriented Routing Protocol (FORP), Cluster-based Routing Protocol (CBRP) и други.

Хибридни. Този тип протоколи имат за цел да спечелят от предимствата на другите два, използвайки както реактивен, така и проактивен подход. Около всяка станция се формира зона, вътре в която се използва проактивно маршрутизиране, а за всяко съобщение към станция извън зоната на източника се прилага реактивно маршрутизиране. Типичен представител на този клас е Zone Routing Protocol (ZRP).

Йерархични. При този тип протоколи се поддържа йерархичност. Обикновено мрежата се разделя на клъстери и за всеки клъстер се избира главен възел, през който ще се осъществява комуникацията с останалите клъстери. Примери за йерархични протоколи са: Cluster Based Routing Protocol (CBRP), Global State Routing (GSR), Fisheye State Routing (FSR), Hierarchical State Routing (HSR) и други.

Географски. При този тип протоколи е известна зоната, в която се намира адресатът на съобщението. Използва се оптимизиран вариант на механизма на наводнението (flooding). Първият е с дефинирането на зона на наводнението. При него даден възел препредава получено съобщение само ако се намира в зоната на наводнение. За целта се разчита на това всяка станция да е способна да определи своето географско местоположение посредством GPS устройство. При втория подход всяка станция препредава получено съобщение само ако се намира по-близо да получателя от станцията от която е получил съобщението. Примери за географски протоколи са: Location-Aided Routing protocol (LAR), Distance routing effect algorithm for mobility (DREAM), Greedy Perimeter Stateless Routing (GPSR) и други. Конфигуриране на Linux станция за работа като маршрутизатор

За да може една машина с инсталирана дистрибуция на OS Linux да се използва като маршрутизатор, тя трябва да разполага поне с два физически мрежови интерфейса. Те трябва да бъдат правилно конфигурирани, да бъдат добавени съответните пътища в маршрутизиращата таблица и да бъде разрешено маршрутизирането. Следващите редове демонстрират поредицата от команди за изпълнение на тези задачи. # конфигуриране на интерфейсите на маршрутизатора $ ifconfig eth0 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255 $ ifconfig eth1 172.16.0.1 netmask 255.255.0.0 broadcast 172.16.255.255 # добавяне на двете мрежи в таблицата на маршрутизатора $ route add –net 192.168.0.0 $ route add –net 172.16.0.0 # добавяне на път по подразбиране $ route add default gw 192.168.0.1 # проверка дали е разрешено маршрутизирането.

$ cat /proc/sys/net/ipv4/ip_forward # ако горният ред върне стойност ‘1’ следователно маршрутизирането # е разрешено в противен случай трябва да се изпълни командата $echo 1 > /proc/sys/net/ipv4/ip_forward

Проверка на маршрутизирането ifconfig – Команда, която служи за настройка и проверка на настройките на

мрежовите интерфейси. USAGE: ifconfig [-a] [-i] [-v] [-s] <interface> [[<AF>] <address>] [add <address>[/<prefixlen>]] [del <address>[/<prefixlen>]] [[-]broadcast [<address>]] [[-]pointopoint [<address>]] [netmask <address>] [dstaddr <address>] [tunnel <address>] [outfill <NN>] [keepalive <NN>] [hw <HW> <address>] [metric <NN>] [mtu <NN>] [[-]trailers] [[-]arp] [[-]allmulti] [mem_start <NN>] [io_addr <NN>] [irq <NN>] [media <type>] [txqueuelen <NN>] [[-]dynamic] [up|down] ...

traceroute – Команда, която служи за проследяване на маршрута, през който се минава за достигане до даден IP адрес. USAGE: traceroute [-dFInrvx] [-g gateway] [-i iface] [-f first_ttl] [-m max_ttl] [ -p port] [-q nqueries] [-s src_addr] [-t tos] [-w waittime] [-z pausemsecs] host [packetlen]

netstat (route) – netstat е полезен инструмент за проверка на конфигурацията и работата на мрежата. Всъщност това са няколко инструмента събрани заедно. Когато стартираме netstat с флага –r, ще бъде отпечатана таблицата с маршрути в ядрото по начин, аналогичен на командата route (таблица 5.3). Табл.5.3. Примерна маршрутизираща таблица. Destination Gateway Genmask Flags MSS Window irtt Iface 172.16.2.0 172.16.1.1 255.255.255.0 UG 40 0 0 eth1 172.16.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo

Опцията “–n” указва на netstat да отпечатва адресите като IP номера в десетично-точков формат, вместо да използва символните имена на хостове и мрежи. Втората колона от резултата от netstat показва шлюза, към който сочи маршрута. Ако не се използва шлюз, се извежда звезда. Третата колона показва мрежовата маска за този маршрут. Когато е даден IP адрес, за който се търси подходящ маршрут, ядрото преминава през всеки от записите в таблицата с маршрути, като извършва побитово AND на адреса и маската, преди да го сравни с целта на маршрута. Четвъртата колона отпечатва следните флагове, които описват маршрута:


G – Маршрутът използва шлюз; U – Интерфейсът, който ще се използва,е активен (up); H – През този маршрут може да се достигне само един хост; D – Този маршрут е създаден динамично; M – Записът е модифициран от ICMP съобщение за пренасочване; ! – Маршрутът е отхвърлящ и дейтаграмите ще бъдат игнорирани.

ЗАДАЧИ ЗА ИЗПЪЛНЕНИЕ 1. Запознаване с видовете маршрутизиращи протоколи – приложение,

предимства и недостатъци. 2. Да се конфигурира Linux станция като маршрутизатор, като се използва

схемата, дадена на фигура 5.2. Интерфейсът на маршрутизатора, включен към мрежата на университета, да се конфигурира чрез DHCP.

3. Запознаване с командите: tracert (traceroute), ifconfig (ipconfig), netstat (route) и тяхното действие.

4. Да се проследи маршрутът до отдалечена станция чрез tracert (traceroute). Пример: www.google.com, www.microsoft.com, и т.н.

5. Да се наблюдават маршрутните таблици на маршрутизираща и локална станция с командата netstat и ключове: “-nr”, “-sp IP”.

Фиг.5.2. Схема на опитната постановка

ДОПЪЛНИТЕЛНА ЛИТЕРАТУРА • Tanenbaum, A., “Computer Networks, Fourth Edition”, Prentice Hall 2003,

ISBN: 0-13-066102-3. • Basagni, S., Conti, M., Giordano, S., Stojmenovic, I. “Mobile Ad Hoc

Networking”, IEEE Press 2004, ISBN: 0-471-37313-3. • RFC документите могат да бъдат намерени на адрес – http://www.rfc-

editor.org/rfc.html • Конфигуриране на Linux станция като маршрутизатор –

http://tldp.org/HOWTO/HOWTO-INDEX/networking.html

Тема 5 Стр.55 Маршрутизиране в интернет



Транслиране на адреси (NAT) и защитни стени (Firewall)

ТЕМА 6 ТРАНСЛИРАНЕ НА АДРЕСИ (NAT) И ЗАЩИТНИ СТЕНИ (FIREWALL)

ЦЕЛ НА УПРАЖНЕНИЕТО Целта на упражнението е да се разучи технологията на транслиране на

адреси и портове. Представени са основните функции на защитните стени и възможностите им. Студентите се запознават с инструмента iptables под ОС Linux за конфигуриране на NAT и задаване на правила и политики за филтриране на трафик.

ТЕОРЕТИЧНА ЧАСТ Наред с конфигурирането на устройствата в мрежата и настройването на

маршрутизирането между тях съществуват още две важни изисквания към конфигурирането на мрежовия слой – транслиране на мрежовите адреси (NAT) и изграждане на сигурни и защитени мрежи посредством конфигурирането на защитни стени (Firewall). Именно те са обект на разглеждане на това упражнение.

Транслиране на адреси (NAT) В самата зора на интернет, когато е бил проектиран протоколът IPv4,

авторите му не са имали дори приблизителна представа за мащаба, в който ще се развие световната мрежа, и съответно нуждата от IP адреси. След последвалото бързо разпространение определените за целта 32-битови адреси много бързо започнали да се изчерпват и скоро станало ясно, че трябва да се намери бързо решение на проблема, който заплашвал да ограничи разпространението на интернет. Сред възможните решения били: проектиране на нова версия на протокола, поддържаща по-голяма адресация (IPv6), това решение изисквало време; преминаване към безкласово маршрутизиране, което да позволи по-пълноценно използване на съществуващите адреси – по-голяма част от мрежите от клас А и B обаче вече били раздадени; третата възможност, която ще бъде разгледана в следващите редове, била използване на частни IP адреси и транслиране на адресите (NAT) [RFC 3022].

Резервирани били част от останалите нераздадени адреси, т.нар. частни адреси [RFC1918], които нямало да бъдат маршрутизирани от гръбначните маршрутизатори, а ще бъдат използвани само за локални мрежи. По този начин на всяка организация ще бъде отпускан един (или поне ограничен брой) реален IP адрес за интернет трафик. В рамките на мрежата на организацията всеки компютър има уникален адрес, който се използва за вътрешно маршрутизиране. Когато даден пакет трябва да напусне мрежата на организацията, преди да бъде подаден към мрежата на доставчика на интернет (ISP) се извършва транслиране


на адреса. Механизмът на работа на NAT е показан на фигура 6.1. В рамките на

вътрешната мрежа всеки компютър има уникален адрес от вида 10.x.y.z. Когато пакет напуска мрежата на организацията, той преминава през машина, извършваща транслиране на адреси. Там частният IP адрес на източника (10.0.0.1) се заменя с реалния IP адрес, отпуснат на организацията (198.60.42.12). Обикновено машината, която извършва транслиране на адресите, се комбинира заедно със защитна стена (firewall), а доста често това е и машината, която извършва маршрутизирането навън.

Фиг.6.1. Примерна конфигурация и механизъм на работа на NAT

След като бе разгледано как пакетът се пуска навън, следва да се разгледа как се получава отговорът. След транслирането на адреса отговорът ще се получи не от истинския адресант, а от машината с IP адрес 198.60.42.12. Приетото решение на проблема е да се използват номерата за порт на източника. Всеки TCP или UDP пакет съдържа в себе си две 16-битови числа, указващи номерата на портовете на източника и получателя. Машината, която извършва NAT, поддържа таблица с размер 65536 реда, в която записва двойката (source IP, source port) за всеки изходящ пакет. След това се извършва замяна както на IP адреса, така и на оригиналния порт номер на източника, и пакетът се пуска навън. Когато се получи отговорът, порт номера на получателя ще се използва като индекс в NAT таблицата, за да се извлече IP адресът и порт номера на компютъра от вътрешната мрежа, до който е предназначен този отговор.

Едно друго приложение на транслирането на адреси, което е открито впоследствие, е свързано с факта, че NAT скрива структурата на вътрешната мрежа, и по този начин може да се използва за повишаване на сигурността.

Въпреки, че NAT успява да намали натиска, свързан с изразходването на IP адресите, това не е идеално решение и крие редица проблеми и недостатъци. Най-важните от тях са:

• Първо, транслирането на адреси нарушава архитектурния модел на IP, според който всеки IP адрес уникално идентифицира една-единствена

Тема 6Стр.57 Транслиране на адреси (NAT) и защитни стени (Firewall)




машина в интернет. Цялата софтуерна структура на интернет се крепи на този факт. Посредством NAT хиляди машини могат да използват адреса 10.0.0.1.

• Второ, NAT променя интернет от безвръзково ориентирана мрежа в един вид връзко ориентирана. Проблемът е свързан с това, че NAT поддържа информация за съответствието на всяка връзка, преминала през него. Ако се получи срив в NAT машината, всички TCP връзки ще бъдат разрушени.

• Трето, NAT нарушава най-фундаменталното правило за разделянето на отделните слоеве. По този начин, ако по-късно излезе нова версия на TCP, която използва 32-битови номера на портове или бъде използван друг транспортен протокол, транслирането ще пропадне.

• Четвърто, някои приложения включват IP адресите в тялото на текста. Получателят извлича тези адреси и ги използва. Тъй като NAT няма никакви знания за съдържанието на пакетите, той не може да ги замени и всякакъв опит за връзка с отдалечения сайт ще пропадне. FTP е пример за такъв протокол и освен ако не се вземат допълнителни мерки, няма да работи заедно с NAT.

• И последно, тъй като порт номерата са 16-битови, то най-много 65,536 машини могат да бъдат скрити зад един IP адрес. Реално те са по-малко, тъй като част от порт номерата са резервирани. Решение на този проблем все пак е използването на повече от един реален IP адрес.

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

Защитни стени (Firewall) Възможността да свържете кои да е два компютъра, независимо от това къде

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

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

Необходимо е решение, което да осигури защита на вътрешната мрежа от


безбройните опасности, които крие интернет. Такова решение представляват „защитните стени” (Firewall) (фигура 6.2). Терминът „защитна стена” (Firewall) е много обширно понятие, което включва механизми за предпазване на различни слоеве от OSI модела. В това упражнение акцентът пада върху защитни стени на мрежовия слой (network layer firewall). Този тип защитни стени работят като пакетни филтри, вземащи решение кои пакети могат да преминат през тях на база на конфигурирани от администратора правила. Тези правила могат да използват информацията от IP хедъра, както и номерата на портовете. Предимство пред защитните стени от по-горните слоеве е, че работят много бързо и прозрачно за потребителите.

Фиг.6.2. Пример за защитна стена, състояща се от два пакетни филтъра.

Основно защитните стени на мрежовия слой се делят на две категории: със запазване на състоянието (stateful firewall) и без запазване на състоянието (stateless firewall). Stateful защитните стени използват информацията за състоянието на връзката (established, initiation, handshaking, data, breaking down the connection) като част от техните правила. Примерно само хостове от вътрешната мрежа да могат да установяват нова връзка на даден порт. Stateless защитните стени извършват филтрирането на пакети без значение от състоянието на връзката. Това ги прави по-малко защитени.

Не е необходимо да имате сложна, специално посветена машина за защитна стена. Всеки нормален компютър, на който работи операционна система, поддържаща филтриране на пакети и маршрутизиране, може да бъде използвана за защитна стена на мрежовия слой. Подходящи операционни системи са Linux, Solaris, BSD/Unix или Windows Server.

Съществуват две основни политики при конфигурирането на защитна стена. Първата е по-защитна и при нея всички пакети, които не отговарят на нито едно правило се филтрират/блокират. При втората политика по подразбиране всеки пакет се пуска, освен ако не изпълни някое от защитните филтриращи правила.



Демилитаризирани зони (DMZ) В компютърните мрежи с термина „демилитаризирана зона” (DMZ) се

означава област от мрежата, която е разположена между вътрешната мрежа на организацията и интернет. Достъп до демилитаризираната зона е разрешен, както от вътрешната така и от външната мрежа, но от демилитаризираната зона връзки могат да бъдат изграждани само навън. Това позволява в DMZ мрежата да бъдат поставяни хостове, предоставящи услуги в интернет, като същевременно се защити вътрешната мрежа в случай на компрометиране на някои от сървърите в DMZ. Демилитаризираната зона обикновено се използва за сървъри, които трябва да бъдат достижими отвън: e-mail, Web, DNS и други. Обикновено връзките от външната мрежа към DMZ се контролират чрез транслиране на адреси и портове (NAT).

Фиг.6.3. Топология на мрежа с демилитаризирана зона (DMZ).

Най-лесният начин за създаване на демилитаризирана зона е чрез конфигуриране на защитната стена (firewall) така, че отделните мрежи се свързват към различни нейни портове. Този вариант е подходящ за мрежи, които нямат много строги изисквания към сигурността. В противен случай е препоръчително да се използва подходът с две защитни стени (firewalls), като DMZ зоната се намира посредата и е свързана и с двата защитни маршрутизатора (фигура 6.3). По този начин се избягва възможността за инцидентно погрешно конфигуриране на защитната стена, както и устойчивост в случай на пробив във външната защитна стена.





Конфигуриране на ОС Linux в режим на защитна стена Netfilter – Представлява рамка (framework) за достъп до пакетите извън

стандартния сокет интерфейс на Berkeley. Състои се от няколко части: • Всеки протокол дефинира т.нар. "hooks", с които се осъществява достъп

до предварително дефинирани точки в пътя на пакета по протоколния стек. Във всяка от тези точки протоколът ще извика функция от netfilter рамката с номер на пакет и hook номер. Обикновено се реализират като отделни модули, които се зареждат към ядрото.

• Части от ядрото може да се регистрират да следят различните точки за достъп за различни протоколи. По този начин, след като се „улови” пакет, се проверява дали има някой регистрирал се за тази точка и протокол. Ако има такива, на всеки му се дава шанс да прегледа и евентуално промени пакета и след това да вземе решение да: блокира пакета (NF_DROP), да го пропусне към следващия (NF_ACCEPT), или направо към края (NF_STOLEN), да го буферира в потребителското пространство (NF_QUEUE).

• Пакетите, буферирани в потребителското пространство, се събират от драйвера ip_queue и се изпращат до потребителски процес, където се обработват асинхронно.

Iptables – Представлява потребителски инструмент, използван от администраторите за дефиниране на правила за филтриране на пакети и транслиране на адреси. В практиката често под името iptables се разбира цялата инфраструктура, включваща netfilter, следене на връзките, транслиране на адресите и самия инструмент.

Netfilter/Iptables инфраструктурата позволява на администраторите да дефинират правила, прилагани върху преминаващите през защитната стена пакети. Тези правила се групират във вериги (chains) – всяка верига представлява подреден списък от правила. Веригите се групират в таблици – всяка таблица е свързана с различен вид обработка над пакетите.

Всяко правило дефинира условие и цел. Целта се прилага върху всички пакети, които изпълняват условието. Всеки пакет преминава през поне една верига и се сравнява последователно с всяко от правилата във веригата. Ако се получи съвпадение, обхождането на веригата спира и се прилага съответното правило. Ако пакетът не изпълни нито едно условие, тогава се прилага подразбиращата се политика на веригата. Целта на някое правило от веригата може да бъде нова верига. В този случай пакетът ще продължи да се сравнява с правилата на първата верига, ако премине през втората верига без съвпадение. Не съществува ограничение за влагането на веригите една в друга. Съществуват три основни вериги (INPUT, OUTPUT и FORWARD), но потребителят може да


създава неограничен брой нови вериги. Веригите се обединяват в таблици. Съществуват три вградени таблици

(FILTER, NAT и MANGLE), всяка от които съдържа някои предефинирани вериги. Също както при веригите, потребителите могат да създават нови таблици. Администраторът има възможност да създава и премахва потребителски създадени вериги във всяка таблица. Първоначално всички вериги са празни. Пътят на пакетите през отделните таблици е илюстриран на фигура 6.4.

Фиг.6.4. Поток на пакетите в Netfilter/IPTABLES

Filter table – тази таблица се използва за филтриране на пакетите (блокиране или разрешаване). Всеки пакет преминава през тази таблица, като задължително преминава през една от следните предефинирани вериги:





• INPUT – всички пакети, предназначени за защитната стена, преминават през тази верига, затова понякога се нарича още LOCAL_INPUT.

• OUTPUT – всички пакети, произлизащи от защитната стена, преминават през тази верига. Аналогично понякога се нарича още (LOCAL_OUTPUT).

• FORWARD – всички преминаващи през защитната стена пакети (такива които се маршрутизират) преминават през тази верига.

Nat table – използва се за правила за промяна на адресите и порт номерата на пакетите (транслиране на адреси). През тази верига винаги преминава първият пакет на всяка нова връзка. В зависимост от взетото решение следващите пакети ще преминават или няма да преминават отново през тази таблица. Съдържа следните предефинирани вериги:

• PREROUTING – входящите пакети преминават през тази верига, преди да се вземе решение за маршрутизирането им. Тук се осъществява т.нар. DNAT (транслиране на адреса на получателя).

• POSTROUTING – изходящите пакети преминават през тази верига, след като е взето решението за маршрутизирането им. Тук се осъществява т.нар. SNAT (транслиране адреса на източника).

• OUTPUT – тук се осъществява ограничен DNAT над локално генерираните пакети.

Mangle table – използва се за промяна на допълнителните полета в хедъра на пакета. Всички пакети преминават през тази таблица. Поради специфичните й задачи съдържа всички възможни предефинирани вериги:

• PREROUTING – всички пакети, влизащи в системата (фигура 6.4), • INPUT – всички пакети предназначени за системата, • FORWARD – всички пакети, преминаващи през системата, • OUTPUT – всички пакети, произлизащи от системата, • POSTROUTING – всички пакети, напускащи системата. Всяко правило си има цел. Целта може да бъде потребителска верига или

някоя от предефинираните цели: ACCEPT – тази цел указва на netfilter да приеме пакета. В зависимост от

веригата това може да означава различни действия над пакета. Примерно, пакет, приет от INPUT веригата, се позволява да бъде получен от хоста; на пакет, приет от OUTPUT веригата се разрешава да напусне хоста; на пакет, приет от FORWARD веригата, му се разрешава да бъде маршрутизиран.

DROP – тази цел указва на netfilter да блокира пакета и да не го обработва повече. На източника не се изпраща никакъв отговор и за него блокирането се




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

от ръководството за iptables – QUEUE, RETURN, REJECT, LOG, ULOG, DNAT, SNAT, MASQUERADE. От тях по-интересна е последната:

MASQUERADE – това е специална, ограничена форма на SNAT за мрежи, чийто външен IP адрес е динамичен (често срещано условие). В този случай вместо да се сменя SNAT правилото при смяна на адреса се използва автоматично адресът на изходящия интерфейс при транслирането. Следене на състоянието на връзките

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

Следенето на състоянието на връзката класифицира всеки пакет към едно от следните четири състояния: NEW (опит за изграждане на нова връзка), ESTABLISHED (част от вече изградена връзка), RELATED (свързан, но не задължително част от същата връзка) и INVALID (не е част от съществуваща връзка, нито заявка за нова връзка). Нормално първият пакет ще бъде класифициран като NEW, отговорът като ESTABLISHED и ICMP съобщение като RELATED. ICMP съобщение, което не се отнася за някоя от съществуващите връзки, ще бъде класифицирано като INVALID.

Чрез включването на допълнителни модули статутът на връзката може да се пренесе до приложно ниво, като по този начин едно приложение може да разбира, че две връзки са зависими. Примерно FTP протоколът установява първоначално контролна връзка и след това данните се предават по отделна връзка. Когато е включен модулът ip_conntrack_ftp, пакетите по връзката за данни ще бъдат класифицирани като RELATED вместо като NEW.

Инструментът iptables също може да извлича полза от знанието за състоянието на връзката за съставяне на по-гъвкави и по-мощни правила за филтриране. Примерно правило може да разрешава пакети в състояние NEW само от вътрешната мрежа, но пакети в състояние RELATED и ESTABLISHED – в двете посоки. По този начин не се позволява изграждането на нови връзки отвън. Това обаче няма да попречи на изграждането на нова FTP връзка за данни, тъй като тя ще бъде класифицирана като RELATED спрямо съществуваща контролна връзка.

По-долу е показан форматът на командата IPTABLES. За пълен списък от възможните опции към командата използвайте ръководството за iptables.




NAME iptables - administration tool for IPv4 packet filtering and NAT SYNOPSIS iptables [-t table] -[ADC] chain rule-specification [options] iptables [-t table] -I chain [rulenum] rule-specification [options] iptables [-t table] -R chain rulenum rule-specification [options] iptables [-t table] -D chain rulenum [options] iptables [-t table] -[LFZ] [chain] [options] iptables [-t table] -N chain iptables [-t table] -X [chain] iptables [-t table] -P chain target [options] iptables [-t table] -E old-chain-name new-chain-name

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

отвън. # iptables -N block # iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT # iptables -A block -m state --state NEW -i ! ppp0 -j ACCEPT # iptables -A block -j DROP ## Jump to that chain from INPUT and FORWARD chains. # iptables -A INPUT -j block # iptables -A FORWARD -j block

Пример2: Правило, блокиращо всички ICMP съобщения от дадена мрежа. # iptables -A INPUT --src 192.168.2.0 /24 -p icmp -j DROP

ЗАДАЧИ ЗА ИЗПЪЛНЕНИЕ

1. Дайте поне по една причина, поради която е необходимо да се настрои защитната стена да проверява входящия и изходящия трафик. В кои случаи това ще бъде ефикасно и в кои няма да бъде?

2. Избройте няколко причини защо е необходимо да се използва транслиране на адреси (NAT).

3. Избройте част от недостатъците, породени от използването на NAT. 4. Какво представлява демилитаризираната зона и по колко различни начина

може да бъде конфигурирана. 5. С помощта на инструментат IPTABLES и опитната постановка от фигура

6.5, конфигурирайте защитна стена, така че да се блокират ICMP съобщенията от всички хостове във вътрешната мрежа, без един. Направете проверка за коректността на резултата.

6. Да се изпълни условието на задача 5, като се използва вграденият в Windows XP firewall.

7. С помощта на инструмента IPTABLES и опитната постановка от фигура


6.5, конфигурирайте транслиране на адресите на хостовете от вътрешната мрежа да използват външния IP адрес на маршрутизатора.

8. Направете проучване какви други решения за конфигуриране на защитни стени съществуват.

Фиг.6.5. Схема на опитната постановка

ДОПЪЛНИТЕЛНА ЛИТЕРАТУРА • RFC документите могат да бъдат намерени на адрес: http://www.rfc-

editor.org/ • Tanenbaum, A., “Computer Networks, Fourth Edition”, Prentice Hall 2003,

ISBN: 0-13-066102-3. • Ръководства за използването на iptables могат да бъдат намерени на

адрес: http://www.netfilter.org/documentation/ • Ръководства за конфигуриране на Linux като защитна стена са достъпни

на адрес: http://www.tldp.org/howto/Firewall-HOWTO.html




Изследване на транспортния слой. Следене на трафика

ТЕМА 7 ИЗСЛЕДВАНЕ НА ТРАНСПОРТНИЯ СЛОЙ. СЛЕДЕНЕ НА ТРАФИКА

ЦЕЛ НА УПРАЖНЕНИЕТО Целта на упражнението е да запознае студентите с функциите на

транспортния слой и основните протоколи, работещи на него. Представени са основните предимства и недостатъци на TCP и UDP. Студентите се запознават с механизмите за следене на трафика и усвояват използването на пакетен анализатор Wireshark (Ethereal) и създаването на филтри за него.

ТЕОРЕТИЧНА ЧАСТ Транспортният слой осигурява пренасянето на съобщения от източника до

приемника. Управлява обмена на данни и осъществява връзка от тип “от край до край” (end-to-end). Проверява за грешки, дублиране и загуба при предаване на съобщенията. Най-важните протоколи, обслужващи транспортния слой, са Transmission Control Protocol (TCP) и User Datagram Protocol (UDP).

Transmission Control Protocol (TCP) Осигурява надеждно предаване на данните между предавателя (source) и

приемника (destination) чрез установяване на връзка (connection-oriented protocol). Това означава, че гарантира предаването на информацията до получателя. TCP протоколът представлява множество правила за осъществяване на надежден информационен обмен между приложните слоеве на два хоста.

Всеки TCP сегмент е разделен на две части: заглавна част с фиксиран размер 20 байта (пет 32-битови думи) и данни с максимална дължина 65495 байта. Заглавната част съдържа необходимата информация за идентификация и контрол. На фигура 7.1 е показан форматът на TCP сегмента.

0 4 10 16 24 31

Порт на подателя Порт на получателя Последователен номер Номер на потвърждение

HLEN Запазени Кодове Прозорец Контролна сума Показалец „спешно”

Опции Допълване Данни

... Фиг.7.1. Формат на TCP сегмента.




• Порт на подателя – 2 байта.

• Порт на получателя – 2 байта.

• Последователен номер – 4 байта, показва мястото на данните от сегмента в рамките на изпращания поток.

• Номер на потвърждение – 4 байта, съдържа следващия номер на потвърждение, което се очаква да бъде получено от подателя.

• HLEN (дължина на заглавната част) – 4 бита, определя дължината на заглавната част на сегмента в 32-битови думи. То е задължително, защото определя началото на полето на данните в рамките на TCP сегмента и затова се нарича още Data Offset.

• Запазени – 6 бита, запазено за бъдеща употреба.

• Кодове – 6 бита, определят се целта и съдържанието на сегмента. На таблица 7.1 са показани използваните флагове.

• Прозорец – 16 бита, стойността указва на източника колко байта могат да бъдат изпратени и съответно приети без препълване на входния буфер след последния потвърден номер на байт (ако е установен флаг ACK).

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

• Показалец “спешно” – 16 бита, се използва да укаже позицията на първия байт на спешните данни спрямо началото на полето данни.

• Опции – не е задължително да присъстват.

• Допълване – служи за допълване до 32-битова дума Табл.7.1. Кодове и значението им Бит Значение, ако е 1

URG Има неотложни данни ACK Има потвърждение PSH Заявка за ‘push’ RST Реинициализиране на връзката SYN Сегментът е част от създаване на връзкаFIN Сегментът е част от разпадане на връзка

Създаване на TCP връзка. За създаване на TCP връзка между две приложни програми, които се

изпълняват на два различни хоста, се използва връзка от тип “от край до край”.




Данните, обменяни между приложните програми по протокола TCP, се обслужват като поток от байтове (byte stream service). Обменът на информация, който осъществява TCP между двата края на връзката, се извършва посредством сегменти. TCP сегментът се състои от заглавна част на TCP и TCP данни. При предаване TCP получава данни от сесийния слой, разделя ги на части, опакова ги заедно с адреса на приемника в сегменти и ги изпраща на IP протокола. Той от своя страна опакова сегментите в дейтаграми и извършва маршрутизирането на всяка дейтаграма. При приемането IP протоколът разопакова пристигналите дейтаграми, след което предава получените сегменти на TCP протокола, който сглобява и подрежда данните от сегментите в съобщения към по-горните слоеве.

Всеки край на TCP връзката се идентифицира с IP адреса на съответния хост и с номер на порт, който се определя от съответната приложна програма, използваща тази връзка. Комбинацията от адреса на хоста и номера на порта се нарича гнездо (socket). Всеки TCP сегмент съдържа номерата на портовете на източника и на приемника, така се определя за коя приложна програма е предназначен съответният сегмент. Комбинацията от гнездото на източника и гнездото на приемника е уникална и идентифицира TCP връзката. Това позволява едно гнездо да се използва едновременно от няколко TCP връзки. Съответствието между номера на порт и приложна програма се осъществява локално във всеки хост.

Използвани портове: - до 256 се наричат добре известни портове, - 256-1023 се използват от компаниите за продажба на приложения, - над 1023 се използват свободно.

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

всеки един от тях да изпрати на другия началния номер (initial sequence number) на байтовата последователност, която ще изпраща, и съответно да получи потвърждение за получаване на този номер. Процедурата за установяване на връзка се нарича Three Way Handshake и в нормалния случай е следната:

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

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


SYN.

• Клиентът трябва да потвърди, т.е. да прати сегмент с ACK за получаването на SYN.

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

• Хостът, който затваря връзката, изпраща FIN сегмент,

• Другият потребител изпраща сегмент с потвърждение ACK и FIN. Може връзката да бъде прекратена безусловно. Тогава се установява флаг

RST, който в заглавната част идентифицира сегмент за прекратяване на връзката. Той се изпраща от протокола TCP, когато по връзката се получи некоректен сегмент, в който IP адресът и номерът на порта на изпращача или получателя не съвпадат с тези на съответната връзка.

Фиг.7.2. „Тристранно ръкостискане”.

Освен основните предимства, като следене на връзката, потвърждения, повторно предаване на изгубени сегменти, TCP има вградени и допълнителни алгоритми за повишаване качеството на предаване. Пример за това са: алгоритъм на Нагъл, забавеният старт и други. Алгоритъмът на Нагъл се грижи да не пътуват по мрежата множество пакети с даннова част 1-2 байта. Когато приложението изпраща данните байт по байт, първият байт се изпраща, а останалите се буферират, докато се получи потвърждение за първия байт. След това се изпращат всички буферирани данни в един сегмент и се започва буферирането до получаване на потвърждение. Алгоритъмът позволява да се

Тема 7 Стр.70 Изследване на транспортния слой. Следене на трафика




изпратят данните и преди получаване на потвърждение, ако буферът се е напълнил до размер >= на половината от размера на прозореца. Въпреки големите достойнства на този алгоритъм има случаи, в които е по-добре да е изключен. Такива са системите за отдалечен достъп като telnet, SSH, RDP, VNC, X Window. Алгоритъмът на забавения старт е свързан с понятието „congestion window”. Освен прозореца, указващ колко място има в буфера получаващият, предаващият поддържа и втори прозорец. Той указва колко байта има готовност да изпрати, без да претовари мрежата. Така реалната стойност на прозореца се избира като минималното от двата прозореца. При изграждане на връзката “congestion window” се установява със стойността на MSS. Изпраща се един максимален сегмент и ако той се потвърди преди да изтече таймаут, стойността на прозореца се прави 2 пъти MSS. Той расте, докато се достигне таймаут или се достигне размерът на прозореца, даден от получателя.

User Datagram Protocol (UDP). UDP не е ориентиран към установяване на връзка (connectionless) и е

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

0 16 31

Порт на подателя Порт на получателя Дължина на съобщението Контролна сума

Данни ...

Фиг.7.3. UDP сегмент.

В общия случай UDP не поддържа контрол на потока, контрол на грешките, изграждане на виртуална връзка и повторно предаване на загубени пакети. Всичко, което предоставя, е интерфейс към мрежовия слой със мултиплексиране между приложенията (по порт). Така се дава основа за изграждане на приложения, които имат изисквания много различни от възможностите на TCP. Прилага се за request/reply комуникация, при която няма значение дали е загубен (сгрешен) пакетът заявка или отговор. Например отдалечено извикване на процедури, където чрез UDP се гарантира предаване на по-малко на брой и по-прости съобщения.

Друго приложение е използването му за база за изграждане на протоколи за работа в реално време, например RTP. Той е протокол за работа в реално време, използва се за поточно audio и video. Позицията му в протоколния стек е малко странна, тъй като има функции от транспортния слой и от приложния (фиг. 7.4).


Фиг.7.4. Място на RTP в TCP/IP стека.

Основната функция на RTP е да мултиплексира няколко мултимедийни потока в реално време в един поток от UDP съобщения. Този поток може да бъде изпратен до unicast адрес или до multicast. Тъй като се използват нормални UDP сегменти, маршрутизаторите ги третират нормално и не може да се гарантира минимално закъснение. За целта се прилага QoS. RTP използва номериране на данните, за да се откриват загуби на пакети, но не се изисква повторно предаване. Вместо това се прави апроксимация на загубения пакет по съседните. Това е удобно при предаването на глас и видео, тъй като разликата между два съседни кадъра обикновено е малка.

Следене на трафика. Програмите за следене на трафика и анализ на мрежата събират информация

за мрежата по два начина: monitoring и залавяне на пакети. • Monitoring – не събира пакети, а само статистика за трафика през даден

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

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

За какво могат да се ползват програмите за следене на трафика:

• Откриване и диагностициране на проблеми в мрежата,

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

Тема 7 Стр.72 Изследване на транспортния слой. Следене на трафика

• Проследяване на пробиви в сигурността,

• Проверка работоспособността на протокол,

• Обучение за структурата и капсулиране на протоколите.

Програмата Ethereal Ethereal е програма за следене на трафика и анализиране на пакети с

графичен интерфейс. Тя позволява интерактивно да се следят пакети в реално време или от предварително запазен файл. Ethereal поддържа голям набор от capture формати, а стандартният му е libpcap, който се използва и от tcpdump.

За стартиране на capture трябва първо да изберем интерфейс от менюто “Capture->Interfaces”. След това можем да изберем филтър, да настроим условия за спиране, съхранени във файл. Можем да изберем дали да следим в реално време или просто да пълним файл с данни. Избирането на филтър помага да не „залавяме” прекалено голям набор от пакети, ако не ни интересуват. Синтаксисът на capture филтъра е следният: [not] primitive [and|or [not] primitive ...] Като primitive е едно от следните: [src|dst] host <host> ether [src|dst] host <ehost> gateway host <host> [src|dst] net <net> [{mask <mask>}|{len <len>}] [tcp|udp] [src|dst] port <port> less|greater <length> Примери: ether host 08:00:08:15:ca:fe – целият трафик от МАС адрес address 08:00:08:15:ca:fe host 192.168.0.10 – целият трафик от IP адрес 192.168.0.10 tcp port 80 – целият трафик на TCP порт 80 (http) от всички възли host 192.168.0.10 and not tcp port 80 – целият трафик от 192.168.0.10 с изключение на http

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

След като сме стартирали следенето и сме „заловили” изследвания трафик, можем да управляваме визуализирането на пакетите чрез display филтър. Този филтър представлява регулярен логически израз (подобен на регулярните изрази в езика Perl). Всяко поле на пакета (независимо от кой протокол – канален, мрежов, транспортен, приложен) може да бъде сравнено с дадена стойност. Може да се използват ключовите думи contains и matches, в зависимост дали търсим пълно съвпадение (matches) или полето съдържа даден

подниз (contains). За сравнението и за логическите операции могат да се използват оператори, като в езика С, или абревиатури от английски: eq == Equal ne != Not Equal gt > Greater Than lt < Less Than ge >= Greater than or Equal to le <= Less than or Equal to AND && логическо И OR || логическо ИЛИ NOT ! логическо отрицание XOR ̂^ логическо изключващо ИЛИ

Чрез менюто “Statistics” може да се наблюдават допълнителни статистики за заловените пакети, като натоварване, разпределение по големина или по протокол, скорост, пропаднали пакети, BER и други (за повече информация виж Ethereal Help).

Един от най-често използваните филтри е този, който филтрира едно TCP съединение от изграждането на връзката, през обмена на данни, до затварянето на връзката. Поради тази причина за проследяването на такова съединение е изнесена отделна процедура в менюто “Analyze”.

ЗАДАЧИ ЗА ИЗПЪЛНЕНИЕ 1. Разучаване на структурата на TCP и UDP сегмента. 2. Разучаване на програма за следене на трафика, видове статистики. 3. Разгледайте кои приложни протоколи използват TCP и кои UDP (чрез

следене на трафика тип мониторинг). 4. Напишете филтър за отделяне на едно TCP съединение, заедно с

изграждането и затварянето на връзката. 5. Разучете процедурата по създаване и прекратяване на TCP връзка – Three

Way Handshake. Създайте display филтър за това. 6. Проследете договарянето на големината на прозореца при едно TCP

съединение. ДОПЪЛНИТЕЛНА ЛИТЕРАТУРА

• RFC документите могат да бъдат намерени на адрес – http://www.rfc-editor.org/ {rfc768(UDP), std007(TCP), rfc3551(RTP)}

• Herrin, G., website: http://www.cs.unh.edu/cnrg/gherrin/, Linux IP Networking: A Guide to the Implementation and Modification of the Linux Protocol Stack.

• Tanenbaum, A., “Computer Networks, Fourth Edition”, Prentice Hall 2003, ISBN: 0-13-066102-3.

• Документация на програмата за следене на трафика – http://www.wireshark.org/docs/



Симулационно изследване в компютърните мрежи

ТЕМА 8 СИМУЛАЦИОННО ИЗСЛЕДВАНЕ В КОМПЮТЪРНИТЕ МРЕЖИ

ЦЕЛ НА УПРАЖНЕНИЕТО Целта на упражнението е да запознае студентите със симулационно

изследване като метод за верификация на компютърни мрежи и комуникационни протоколи. Представени са особеностите на мрежовия симулатор NS-2, скриптовите езици Tcl, OTcl, чрез създаване/модифициране на симулационни сценарии с цел по-пълното разбиране на работата на мрежовите протоколи от слоевете на OSI модела.

ТЕОРЕТИЧНА ЧАСТ Съществуват няколко основни подхода за верификация на работата на една

нова система, компютърна мрежа, топология или комуникационен протокол, наложили се както в теорията така и в практиката:

• аналитично изследване,

• симулационно изследване,

• насочени експерименти,

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

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

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

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




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

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

От разгледаните подходи за верификация на комуникационни протоколи в текущото упражнение се разглежда методът на симулационния анализ. Симулацията по своята същност представлява програмна реализация на модел на симулираната система. Със система в контекста на симулатора NS-2 се обозначава група от обекти със предефинирано множество от взаимодействия между тях. Съществуват четири основни класа симулационни модели: непрекъснати във времето; дискретни; използващи теорията на опашките; хибридни. Непрекъснатият във времето модел е този, при който промените в състоянието се задават от променящи се във времето сигнали или променливи, докато дискретният модел променя състоянието си в следствие на възникването на определено събитие.

Симулационният процес се състои от следните дискретни стъпки, необходими за да се използва пълния потенциал на симулационния анализ и постигането на максимален резултат:

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

• формулиране на модел за решаване на поставената задача;

• формулиране на симулационен модел за решаване на задачата;

• реализиране на модела за избрания симулационен инструмент;

• проектиране на симулационните сценарии на изследването;




• проверка на валидността на модела;

• изпълнение на експериментите. Най-много време обикновено се губи в стъпките 2, 3 и 4 от симулацията

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

Въведение в NS-2 Мрежовият симулатор NS (NS-2 – последната актуална версия) представлява

събитийноориентиран дискретен симулатор, разработен в университета Berkley. Възприет добре от академичната общност, той се е превърнал в един от най-предпочитаните инструменти за симулиране на глобални и локални мрежи поради възможността за добавяне на разширения (отворен код). Наред с официално поддържаните протоколи от каналния слой, маршрутизиращи и мултикаст протоколи, протоколи за ad-hoc комуникация, протоколи от приложния слой и механизми за управление на опашки съществуват и редица разширения и реализации невключени в основната дистрибуция, но налични в интернет.

В своята реализация NS използва за основа два програмни езика: C++ и OTcl (обектно-ориентирано разширение на Tcl), съчетавайки предимствата, които има всеки от тях. В основата му са заложени две йерархии от класове, компилираните C++ класове и интерпретираните OTcl класове, с пълно съответствие между двете йерархии.

Компилираната йерархия от C++ класове позволява постигането на ефективност и намаляване на времето за изпълнение на симулациите. Използва се главно при детайлното дефиниране на протоколи и операциите, които те поддържат. Това позволява да се намали времето за обработка на пакети и събития, както и необходимата памет.

Йерархията от OTcl класове от своя страна позволява лесно и бързо дефиниране на топологията, протоколите и приложенията, които ще бъдат симулирани (тяхната функционалност трябва да е зададена предварително в C++ йерархията от класове). По-голяма част от дадено изследване обикновено е свързано с малка промяна на параметрите и конфигурациите или с бързо създаване на различен набор сценарии, което е многократно ускорено от използването на скриптов език за тази цел. Именно тук се задава и видът и формата на изходните файлове, които ще бъдат генерирани и анализирани след протичане на симулацията.

В най-опростения модел показан на фигура 8.1, симулаторът NS е представен като интерпретатор на Otcl, който притежава планировчик на


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

Фиг.8.1. Абстрактен модел на работата на NS-2 симулатора.

Един от основните компоненти на NS е планировчикът на мрежовите събития. Както вече бе споменато по-горе, NS представлява дискретен събитиен симулатор, което означава, че времето в симулатора протича в пряка зависимост от времената на зададени събития. Събитията се управляват от планировчик (scheduler). Съществуват различни реализации на планировчик – list, heap, calendar queue (по подразбиране), real-time. Събитие в NS се дефинира с пакет, притежаващ уникален идентификатор (ID), планирано време на изпращане и обект/възел, който да го обработи. Планировчикът поддържа дискретно симулационно време, като стартира последователно всички събития, предвидени за текущото време, след което се преминава на следващото най-скорошно събитие. Мрежовите компоненти комуникират помежду си чрез обмяна на пакети, но това не консумира от симулационното време. Задаването на комуникационното закъснение отново става чрез събитие. Например, компонент, симулиращ мрежов комутатор със закъснение 20 микросекунди ще създаде събитие за всеки получен пакет с време на изпълнение 20 микросекунди по-късно. Когато всички събития преди това време бъдат обработени, ще се стартира операцията по изваждане на пакета от изходящата опашка на комутатора и добавянето му към тази на следващия възел от пътя му. За пояснение следва да се добави, че в NS съществуват две нотации за времето – процесорно и симулационно време. Процесорното време е реалното време на изпълнение на задачите, докато симулационното време е вътрешно системно време. Симулационното време се управлява от планировчика на събитията.

Тема 8 Стр.78 Симулационно изследване в компютърните мрежи


Основи компоненти на мрежовия симулатор NS

Инициализиране на симулатора Проектирането на всяка симулация започва със създаването на инстанция на

симулатора и нейната инициализация. За целта се използва Tcl примитивът: set ns [new Simulator]

Инициализиращата процедура изпълнява следните действия:

• Инициализиране на формата на пакетите;

• Създаване на планировчик на събитията;

• Създаване на “null agent” – този специален обект служи за освобождаване на отпадналите пакети, а също така и като назначение за пакети, които няма да бъдат преброявани или регистрирани.

Създаване на топология Следващата стъпка е в проектирането на топологията, която е свързана със

създаването на мрежовите възли (nodes) и изграждане на връзките (links) между тях. Това е т.нар. физическа топология на симулираната мрежа.

Създаването на нов възел се осъществява с използването на Tcl примитива: $ns node

Фиг.8.2. Структура на възел в NS.

В резултат се инстанциира и инициализира нов обект със следните вътрешни променливи (фигура 8.2):



• Адрес – представлява идентификатор (ID) на възела, чиято първоначална стойност е 0 и се увеличава последователно с 1 при добавянето на нов възел;

• Списък на съседите – съхранява идентификаторите на директно свързаните възли;

• Списък на агентите – съхранява всички прикрепени към възела транспортни агенти;

• Тип на възела – указва типа на възела: unicast, multicast и т.н.;

• Маршрутизиращ модул.

Създаване на връзка (link) Създаването на връзките между възлите в мрежата е вторият етап от

създаването на топологията. Връзките в NS се делят на следните типове: point-to-point и multipoint, симплекс и пълен дуплекс, Ethernet, Wireless и broadcast преносна среда. Съществуват и други, по-сложни типове връзки.

Създаването на новa връзка сe oсъществява с Tcl примитива: $ns simplex-link node0 node1 bandwidth delay queue_type

Тук simplex-link указва типа на линията, node0 и node1 са възлите, които ще бъдат свързани, bandwidth и delay са параметри на линията, указващи съответно пропускателната способност и закъснението за предаване на един бит по линията. Последният параметър queue_type е специфичен за NS и указва дисциплината за обслужване на опашката. В NS опашките не са част от самите възли, а са привързани към връзките.

Фиг.8.3. Композитна конструкция на обект от тип връзка в NS.

Типът връзка в NS се състои от последователност от конектори. Конекторите генерират пакети само до един получател. Това е или възел от списъка със съседи, или т.нар. drop-target, която служи за унищожаване на пакета. Съществуват следните конектори, които могат да бъдат използвани, всеки





притежаващ специфични особености и характеристики (фигура 8.3):

• Networkinterface – добавя идентификатора на входящия интерфейс към пакета (използва се от multicast маршрутизиращи протоколи).

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

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

• Queues – моделира изходящите буфери на възела.

• TTLChecker – декрементира полето TTL на всеки пакет, преминаващ през линията. При положителна стойност на полето след декрементацията се пуска да продължи, в противен случай пакетът се унищожава. Стои на последно място между изходящата опашка и следващия възел от връзката.

Управление на опашките и разпределяне на пакетите Когато се говори за опашки в контекста на мрежовия симулатор NS, се има

предвид места, в които пакетите могат да престояват или да бъдат унищожавани. Процесът на планиране на пакетите е свързан с вземането на решение кои пакети трябва да бъдат обслужени и кои да бъдат унищожени. Управлението на опашките/буферите в този контекст се отнася към дисциплините за регулиране на заетостта на конкретна опашка. Примери за дисциплини на обслужване са drop-tail (FIFO), RED, CBQ (включва приоритети и round-robin планировчик) и вариации на Fair Queuing като Fair Queuing (FQ), Stochastic Fair Queuing (SFQ), на Round-Robin – Weighted Round-Robin (WRR), Packet-by-packet Round-Robin (PPRR) и Deficit Round-Robin (DRR).

Дефиниране на трафик В NS симулатора топологията задава само физическите възли и връзките

между тях. При дефинирането на мрежовия трафик се изгражда нов вид свързаност между възлите. Задават се всички двойки от възли (източник-получател), които дефинират логическия поток на информация/пакети в мрежата. Конкректният път на пакетите се определя по време на симулацията от избрания маршрутизиращ протокол. Създаването на трафик изисква създаването на два агента – за източник и за назначение. Агентите представляват реализация на транспортен протокол и затова могат да работят




на различни слоеве. Транспортен агент Агент в NS се нарича крайната точка, в която се констриуират или

консумират обменяните в мрежата пакети. Базовият клас Agent притежава вътрешно състояние, което служи за попълване на служебните полета в пакетите, преди да бъдат изпратени. Параметрите на състоянието му включват:

• addr_ node – адреса на източника;

• dst_ – адреса на желания получател на пакета;

• size_ packet – размера на пакета в байтове;

• type_ type – типа на изпращания пакет;

• fid_ – идентификатор на потока;

• prio_ – полето за приоритет;

• flags_ – поле за флагове (еквивалентно на полето в IP хедъра);

• defttl_ – подразбиращата се стойност за TTL. Примери за транспортни агенти са: UDP, TCP, TCP_Reno, TCP Vegas, TCP

Full, SCTP, SRM, PLM и други. Приложения Приложенията работят върху транспортните агенти. В NS съществуват два

типа приложения – генератори на трафик и симулиращи реален трафик Реализацията на приложения в NS използва API функции, за да се обвърже с агент на транспортно ниво по аналогия със сокетите в реалните системи.

TrafficGenerator е абстрактен клас, използван от приложенията тип генератори на трафик. Съществуват четири приложения от този тип:

• Exponential On/Off – този генератор е от типа On/Off. В периодите на On изпраща пакети с фиксиран темп и размер на пакетите. През Off периодите не се пращат пакети. И On и Off периодите се определят на база на експоненциалното разпределение.

• Pareto On/Off – идентичен с експоненциалния, с тази разлика, че On/Off периодите се определят от разпределението на Pareto.

• CBR Traffic – генерира периодичен трафик с фиксирана скорост и размер на пакетите. Може да се настрои да включва леко изменение в периода на изпращане.

• Traffic Trace – генерира трафик по зададен trace файл. Всеки ред от файла се състои от две 32-битови числа, задаващи времето до изпращането на

следващия пакет и размера на пакета. Примери за приложения, симулиращи реални протоколи, реализирани в NS

са telnet, FTP, Web Cache, Pack-MIME HTTP.

Реализиране на нов протокол За описание на протоколи се използва програмният език С++. Концепцията

на симулатора е на базата на съществуваща базова функционалност да се добави нова функционалност по метода на наследяването. Така, без да променяме основата на симулатора, верифицираме новия протокол. Повече информация за реализирането на нов протокол в мрежовия симулатор NS може да намерите в следния документ: (http://masimum.dif.um.es/nsrt-howto/pdf/nsrt-howto.pdf).

Въведение в TCL скрипта Скрипт езикът TCL (Tool Command Language) притежава сравнително прост

синтаксис и е лесен за интегриране с други езици. Обектно-ориентираната му версия се нарича OTcl. Следващите редове имат за цел запознаване с основните синтактични конструкции и операции на Tcl. Редовете, започващи със символа # (диез), са коментари.

set a 0 # еквивалентно на а = 0 при С/С++ set x $a # еквивалентно на x = a при С/С++ # Математически операции: set y [expr $a + $b] # еквивалентно на y = a + b при С/С++ set z [expr 1 / 50] # z има стойност 0 set w [expr 1.0 / 50.0] # z има стойност 0.02 # Работа със файлове: set file1 [open filename w] puts $file1 “test” # записва думата test във файла file1 # Извикване на UNIX/LINUX команди: [exec] exec <име на команда> # Дефиниране на условни преходи:[ if, else] if { условие } { # ... изпълнение на някакви команди } else { # ... изпълнение на някакви команди } # Дефиниране на цикли: [for] for { set i 0 } { $i < 10} { incr i } { # ... изпълнение на някакви команди }




# Дефиниране на процедури: [proc, global, return] proc my_procedure {parameter1 parameter2 … } { global var1 var2 set ret 0 # ... изпълнение на някакви команди return $ret } # Дефиниранe на клас в Otcl Class AgentGen . . . AgentGen instproc default_options { } { $self instvar opt_info . . .

Tcl променливите нямат тип, типът им зависи от стойността, която им бъде присвоена. В горната дефиниция на процедура var1 и var2 са променливи външни за процедурата. За да могат да бъдат използвани вътре в тялото на процедурата, се дефинират като глобални с ключовата дума global.

Декларирането на нов клас става с използването на ключовата дума class, следвана от името на класа. Методите на класа се декларират чрез ключовата дума instproc, пред която стои името на класа, а след нея – името на самата функция и нейните параметри. Функцията init е запазена за конструктор на класа. Променливата self е указател към самия клас, също както this при С++ и Java. Чрез ключовата дума superclass се указва, че даден клас наследява друг такъв клас.

Скриптове на NS-2 Различните задачи изискват подготовката на различни симулационни

сценарии под формата на скрипт програма. В следващите редове е разгледан пример, представящ сценарии с безжични станции, комуникиращи по стандарта IEEE 802.11, разположени в конфигурация, позволяваща проявяването на проблема със скрития терминал/станция. Примерът е непълен. Целият текст на примера, както и повече примери за изследването на редица комуникационни протоколи в различни конфигурации и топологии ще намерите в поддиректорията /tcl/ex/ и /tcl/edu/ на основната директория на симулатора.

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

Проблемът със скритата станция при IEEE 802.11

#Copyright (c) 1997 Regents of the University of California. # All rights reserved. 1. Mac/Simple set bandwidth_ 1Mb 2. 3. set MESSAGE_PORT 42 4. set BROADCAST_ADDR -1 5. set val(prop) Propagation/TwoRayGround ;# radio-propagation model 6. set val(netif) Phy/WirelessPhy ;# network interface type 7. set val(mac) Mac/Simple 8. set val(ifq) Queue/DropTail/PriQueue ;# interface queue type 9. set val(ll) LL ;# link layer type 10. set val(ant) Antenna/OmniAntenna ;# antenna model 11. set val(ifqlen) 32768 ;# max packet in ifq 12. set val(rp) DumbAgent 13. 14. set ns [new Simulator] 15. set f [open sht-temp.tr w] 16. $ns trace-all $f 17. $ns eventtrace-all 18. set nf [open sht-temp.nam w] 19. $ns namtrace-all-wireless $nf 700 200 20. set topo [new Topography] 21. $topo load_flatgrid 700 200 22. …………………… 23. 24. set mac0 [new Mac/Simple] 25. $ns node-config -adhocRouting $val(rp) -llType $val(ll) \

-macType $val(mac) -ifqType $val(ifq) \ -ifqLen $val(ifqlen) -antType $val(ant) \ -propType $val(prop) -phyType $val(netif) \ -channelType Channel/WirelessChannel \ -topoInstance $topo -agentTrace OFF -routerTrace OFF \ -macTrace ON -movementTrace OFF

26. 27. for {set i 0} {$i < 3} {incr i} { 28. set node_($i) [$ns node] 29. $node_($i) random-motion 0 30. } 31. …………………… 32. 33. $ns at 0.25 "$node_(2) setdest 500.0 30.0 10000.0" 34. 35. # subclass Agent/MessagePassing to make it do flooding 36. Class Agent/MessagePassing/Flooding -superclass Agent/MessagePassing 37. Agent/MessagePassing/Flooding instproc recv {source sport size data} { 38. $self instvar messages_seen node_ 39. global ns BROADCAST_ADDR 40. 41. # extract message ID from message 42. set message_id [lindex [split $data ":"] 0] 43. puts "\nNode [$node_ node-addr] got message $message_id\n" 44. 45. if {[lsearch $messages_seen $message_id] == -1} { 46. lappend messages_seen $message_id 47. $ns trace-annotate "[$node_ node-addr] received {$data} from $source" 48. $ns trace-annotate "[$node_ node-addr] sending message $message_id" 49. $self sendto $size $data $BROADCAST_ADDR $sport 50. } else { 51. $ns trace-annotate "[$node_ node-addr] \ 52. received redundant message $message_id from $source" 53. } 54. } 55. Agent/MessagePassing/Flooding instproc send_message {size message_id data port} {

56. $self instvar messages_seen node_ 57. global ns MESSAGE_PORT BROADCAST_ADDR 58. 59. lappend messages_seen $message_id 60. $ns trace-annotate "[$node_ node-addr] sending message $message_id" 61. $self sendto $size "$message_id:$data" $BROADCAST_ADDR $port 62. } 63. 64. for {set i 0} {$i < 3} {incr i} { 65. set a($i) [new Agent/MessagePassing/Flooding] 66. $node_($i) attach $a($i) $MESSAGE_PORT 67. $a($i) set messages_seen {} 68. } 69. 70. $ns at 0.1 "$a(0) send_message 500 1 {first_message} $MESSAGE_PORT" 71. $ns at 0.101 "$a(2) send_message 500 2 {second_message} $MESSAGE_PORT" 72. 73. $ns at 0.2 "$a(0) send_message 500 11 {eleventh_message} $MESSAGE_PORT" 74. $ns at 0.2 "$a(2) send_message 500 12 {twelfth_message} $MESSAGE_PORT" 75. 76. $ns at 0.35 "$a(0) send_message 500 3 {third_message} $MESSAGE_PORT" 77. $ns at 0.351 "$a(2) send_message 500 4 {fourth_message} $MESSAGE_PORT" 78. 79. $ns at 0.45 "$a(0) send_message 500 13 {thirteenth_message} $MESSAGE_PORT" 80. $ns at 0.45 "$a(2) send_message 500 14 {fourteenth_message} $MESSAGE_PORT" 81. 82. for {set i 0} {$i < 3} {incr i} { 83. $ns initial_node_pos $node_($i) 30 84. $ns at 4.0 "$node_($i) reset"; 85. } 86. 87. $ns at 4.0 "finish" 88. $ns at 4.1 "puts \"NS EXITING...\"; $ns halt" 89. 90. …………………… 91. 92. proc finish {} { 93. global ns f nf val 94. $ns flush-trace 95. close $f 96. close $nf 97. } 98. puts "Starting Simulation..." 99. $ns run

Инструменти за визуално представяне на резултатите от симулацията При изпълнението на скрипта по-горе, симулиращ проблема със скритата

станция, се генерират два изходни файла: sht-temp.tr и sht-temp.nam. Първият представлява запис на всички събития, записани във формат на NS, представен в документацията. Може да бъде обработен с различни инструменти за извличане на необходимата информация, най-често се използват Awk, Perl, XGraph и GnuPlot. Вторият файл е предназначен за мрежовия аниматор – NAM, инструмент, позволяващ визуализиране на протичането на симулацията с възможност за стопиране, пускане и промяна на скоростта и посоката на протичане на симулацията, маркиране и следене на пакети и промяна на разположението на мрежовите възли в топологията. Различните потоци са


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

ЗАДАЧИ ЗА ИЗПЪЛНЕНИЕ

1. Запознаване с основните функции и възможности на симулатора NS-2. 2. Реализиране на програма на Tcl за изчисляване на числата на Фибуначи. 3. Да се стартира примерният симулационен скрипт, представящ проблема със

скрития терминал, и да се наблюдава резултатът с помощта на инструмента NAM.

4. Да се реализира симулационният сценарий, представен на фигурата по-горе

и да се наблюдава резултата с помощта на инструмента NAM. Да се изследва поведението на мрежата, като се променя пропускателната способност и политиката за управление на опашки на линията между възел 2 и 3.

ДОПЪЛНИТЕЛНА ЛИТЕРАТУРА

• NS-2 – http://www.isi.edu/nsnam/ns/ns-documentation.html

• NAM – Network Animator: http://www.isi.edu/nsnam/nam

• TCL – http://dev.scriptics.com/man/tcl8.2.3/

• OTCL – http://bmrc.berkeley.edu/research/cmt/cmtdoc/otcl/tutorial.html




Сокети – приложение

ТЕМА 9 СОКЕТИ – ПРИЛОЖЕНИЕ

ЦЕЛ НА УПРАЖНЕНИЕТО Целта на упражнението е студентите да се запознаят с понятието сокет,

основните функции на сокетите в операционната система и да се учат да използват основните функции за програмиране на BSD сокети на и Java Socket Interface.

ТЕОРЕТИЧНА ЧАСТ Сокетите са средство за локална и мрежова комуникация между два процеса.

За пръв път тази идея се появява в BSD 4.2, а сега е разпространена в повечето операционни системи като стандарт за комуникация. От гледна точка на програмирането е необходима абстракция, която да представи взаимодействието на процеси през мрежата. Тази абстракция цели да капсулира управлението на TCP/IP стека и предаването на данни. За да се направи програмирането по-лесно, в UNIX за пръв път се появява абстракцията сокет и мрежата се използва по подобие на взаимодействието с В/И устройствата и файловете. В UNIX се спазва идеологията всички В/И операции да се извършват като достъп до файл. Използва се файлов дескриптор и операциите за четене и запис във файл. Тъй като сокетите се появяват за пръв път точно в UNIX, те също спазват тази идеология: създава се дескриптор на сокета, който е от същото множество цели числа, както и файловите дескриптори. При някои операционни системи (Windows) функциите за работа със сокети са отделени от тези за работа с файлове и дескрипторите са отделни, но схемата на работа се запазва. В операционната система интерфейсът за сокети се състои от набор потребителски библиотеки и функции, както и от набор системни извиквания на ядрото. В по-ранните версии на Windows работата със сокети е била реализирана по различен от популярния начин – така наречените “Berkeley sockets”. По-късно Майкрософт добавят библиотека за сокети, която е напълно в съответствие с “Berkeley sockets”. Това е “winsock2” библиотеката.

Наследено от UNIX, има два различни домейна за обхват на сокета – локални (PF_UNIX) и мрежови (PF_INET). При локалните се адресира чрез пълния път до процеса, а с мрежовите ще се запознаем подробно в този материал.

Мрежови сокети Мрежовите сокети функционират като крайна точка за комуникация. Всеки

сокет е една входна точка, а една двойка свързани сокети уникално идентифицира една двупосочна връзка от край до край. Всяка крайна точка се


идентифицира с двойката (адрес, порт). Мрежовите сокети могат да се използват и за локална междупроцесна комуникация ((localhost, port1), (localhost, port2)).

Мрежовите сокети са три основни типа: - Поточни сокети – използват TCP за транспортен протокол, т.е.

надежден, - Дейтаграмни сокети – използват UDP, т.е. ненадежден, изпращат се

съобщения, - RAW сокет – асоциира се с IP протоколен номер и получава целия

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

Използване на сокети Използването на сокети се базира на архитектурата клиент/сървър. Единият

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

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

Фиг.9.1. Поточни сокети.

Клиентската станция извършва следните действия за осъществяване на комуникация:

Тема 9 Стр.89 Сокети – приложение


1. Създаване на сокет и получаване на дескриптор от ОС. 2. Свързване на сокета към сървърен сокет. 3. Трансфер на данни. 4. Затваряне на сокета.

Сървърната станция извършва следните действия за осъществяване на комуникация: 1. Създаване на сокет и получаване на дескриптор от ОС. 2. Обвързване на сокета с локален адрес и порт. 3. “Слушане” за клиентски заявки и добавяне на заявките в опашка за обработване. 4. Приемане на заявка от опашката. (Създава се нов сокет по време на обмена.) 5. Трансфер на данни. 6. Затваряне на сокета.

За дейтаграмни сокети ролите на клиента и сървъра са показани на фиг. 9.2.

Фиг.9.2. Дейтаграмни сокети.

Адресиране на сокети За да адресираме един сокет, ни е необходимо да зададем мрежов адрес,

порт, домейн на адреса. Това се постига с използването на структура от данни. struct in_addr {unsigned long s_addr;}; struct sockaddr_in{ short sin_family; //АF_UNIX | АF_INET u_short sin_port; // port number struct in_addr sin_addr; // address char sin_zero[8]; // padding };

За да се поддържа универсална структура, независимо от използваните протоколи, се прилага структурата “in_addr”. За различните протоколни реализации тя има еднакъв размер и двоично подреждане, но полетата вътре може да са различни. Затова има и поле за подравняване на адреса на сокета – “sin_zero”. Както се вижда в структурата, адресът се записва като цяло положително число от тип long. Поддържат се функции за превръщането му в





dotted-decimal и обратно. unsigned long inet_addr(char *) char *inet_ntoa(unsigned long)

Описание на основните функции за работа със сокети в С/С++ Създаване на сокет – извършва се и при клиента, и при сървъра.

s = socket (domain, type, protocol)

s – дескриптор на сокета. domain – PF_UNIX или PF_INET. type – SOCK_STREAM, SOCK_DGRAM, SOCK_RAW. protocol – обикновено се оставя 0, защото се подразбира от типа на сокета,

но може да се зададе при RAW сокети – IP, IPX. Обвързване на сокет с локален адрес и порт – използва се основно при

сървъра, но е възможно и при клиента. int bind(int s, struct sockaddr *addr, int addrlen);

s – дескриптор на сокета. addr – указател към структура, съдържаща локалния адрес. За клиента обикновено не е необходимо да се използва тази операция, тъй

като той използва свободен порт, предоставен от ОС и мрежовия адрес по подразбиране. Затваряне – извършва се при клиента и сървъра.

int close(int s);

Затваря сокета като файл. Унищожава дескриптора. int shutdown(int s, int how);

В зависимост от стойността на how може да прекъсне връзката в едната, в другата или и в двете посоки. (0 – затваря за получаване, 1 – затваря за пращане, 2 – затваря и в двете посоки.) Свързване към сокет – извършва се при клиента, за да се свърже към

съществуващ сървърен сокет. int connect(int s, struct sockaddr *addr, int addrlen);

s – дескриптор на сокета. addr – указател към структура, съдържаща адреса на сървъра. Слушане на определен порт – при сървъра. Поставя сървърния сокет в

режим на чакане на заявки. При приемане на заявка я поставя в опашка за обработване. int listen(int s, int backlog);

s – дескриптор на сокета.




backlog – задава големината на опашката за приеманите заявки. Приемане на заявка за обработка – при сървъра. Взема се заявка от

опашката за обработване и се създава нов сокет за нея. Така се създава двойка сокети, които комуникират и се освобождава сървърният сокет да слуша отново. int s1 = accept(int s, struct sockaddr *addr, int *addrlenptr);

s – дескриптор на сокета. addr – указател към структура, съдържаща адреса на клиента. Връща дескриптор на новосъздаден сокет – s1. Предаване на данни – от двата хоста. За предаване на данни могат да се използват познатите ни функции за работа

с файлове. Подават се дескриптор, буфер за данни и дължина на буфера. int write(int s, char *msg, int msglen); int read(int s, char *msg, int msglen);

Същите като предходните, но имат допълнително поле за настройки на сокета. int send(int s, char *msg, int msglen, int flags); int recv(int s, char *msg, int msglen, int flags);

Функции за предаване на данни при дейтаграмни сокети, където няма поддържане на връзката и всяка дейтаграма пътува независимо до адреса. int sendto(int s, char *msg, int msglen, int flags, struct sockaddr *addr, int addrlen); int recvfrom(int s, char *msg, int msglen, int flags, struct sockaddr *addr, int *addrlenptr);

За разлика от дейтаграмните, при поточните сокети, маршрутът се избира еднократно, след което се записва в сокета и се използва по време на трансфера. Тоест функциите CONNECT и ACCEPT извършват изграждането на TCP връзката. Проверка и промяна на опциите на сокета.

int getsockopt(int s, int level, int optname, void *optval, int *optlenptr); int setsockopt(int s, int level, int optname, void *optval, int optlen);

level – ниво на протокола: SOL_SOCKET, IPPROTO_TCP, IPPROTO_IP. optname – име на опцията: SO_REUSEADDR, SO_ERROR,

SO_BROADCAST и други. optval – стойността на конкретната опция. Помощни функции. При мрежовото програмиране винаги е необходимо да се реши един важен

проблем. Това е последователността на обработка на данните – от старши към младши байт или обратно. Проблемът е наследство от различното представяне




на данните в различни компютърни архитектури. В Intel архитектурите и подобните на тях данните се обработват в Little-endian, докато в Macintosh – в Big-endian. Прието е данните по мрежата да се предават в Big-endian и затова при всички Intel и подобни архитектури е необходимо да се извършва преобразуване. За целта се използват няколко функции: htonl() – 32 битово число от Little в Big-endian (host-to-network long); ntohl() – 32 битово число от Big в Little-endian (network-to-host long); htons() – 16 битово число от Little в Big-endian (host-to-network short); ntohs() – 16 битово число от Big в Little-endian (network-to-host short).

Специфични функции за WinSock интерфейса. В този интерфейс са добавени няколко специфични функции за адаптиране

(таблица 9.1). • Преди да се използва сокет в дадена програма, трябва да се зареди

WinSock.dll и да се инициализира, • Преди да се затвори приложението, трябва да се освободят ресурсите,

заети от сокет интерфейса, • При възникване на грешка трябва да се обърнем към специфична

функция, която ни показва коя точно е грешката. Табл.9.1. Специфични функции на WinSock.dll

Функция Описание

WSAStartup() Инициализира библиотеката за работа със сокети и проверява дали е налична съответната версия на сокет интерфейса.

WSACleanup() Освобождава заетите от приложението сокети и прекратява връзката с библиотеката.

WSAGetLastError()

Връща кода на последната грешка, възникнала при работата със сокет интерфейса. Трябва да се извиква веднага при възникване на грешка, за да не се презапише грешката от следващата възникнала.

Обикновено се използва следният код в началото на приложението и нататък се програмира по подобие на „Berkeley sockets”. WSADATA wsadata; WSAStartup (MAKEWORD(1,1), &wsadata); // Version 1.1 required

Интерфейс за работа със сокети в Java Програмирането на сокети в Java се извършва чрез специализиран пакет,

съдържащ API функции и класове. Този пакет се нарича “java.net”. За


адресирането на сокетите се предлагат няколко класа – InetAddress и SocketAddress и техни наследници. Първият предлага адресиране чрез IP адрес, като има имплементирани наследници за IPv4 и IPv6. Адресът може да му се подава директно в dotted decimal формат или като long число. Вторият клас и неговите наследници капсулират IP адреса и номера на порт в един обект. Удобен е за работа и позволява използването на име на хост вместо IP адреса. Поточни сокети. За работа с поточни сокети Java предлага два класа – Socket и ServerSocket.

Класът ServerSocket представлява сокет, на който сървърното приложение „слуша” и приема заявки. Класът Socket предоставя крайната точка за комуникация между клиента и сървъра. При клиента този клас се използва за създаване на сокет и свързване към сървъра, а при сървъра – при получаване на заявка на ServerSocket обекта (фигура 9.3).

Фиг.9.3. Изграждане на TCP връзка.

След като се установи TCP връзката, се асоциират InputStream и OutputStream към нея. Дейтаграмни сокети. При работа с дейтаграмни сокети в Java се използват два основни класа –

DatagramSocket и DatagramPacket. Първият клас капсулира сокет интерфейса и връзката към UDP. Поддържа функции за изпращане и получаване. Има реализиран подклас за multicast съобщения. Другият клас представя самия UDP пакет, заедно с адреса, порта и данните. Приложението създава дейтаграмен сокет, след което създава пакет, привързва го към сокета и го управлява, използвайки функциите на класа DatagramSocket (фигура 9.4).



Фиг.9.4. Работа на дейтаграмни сокети.

ЗАДАЧИ ЗА ИЗПЪЛНЕНИЕ 1. Запознаване с понятието сокет. 2. Запознаване с основните типове сокети и тяхното приложение. 3. Запознаване с основните функции за работа със сокети под Linux. 4. Запознаване с основните класове на Java за работа със сокети. 5. Създаване на клиент/сървър приложение с поточни сокети. 6. Създаване на клиент/сървър приложение с дейтаграмни сокети.

ДОПЪЛНИТЕЛНА ЛИТЕРАТУРА • Описание на класовете за работа със сокети на Java на адрес:

http://java.sun.com/j2se/1.4.2/docs/api/java/net/package-summary.html. • Stevens, W., „UNIX Network Programming, Volume 1, Second Edition:

Networking APIs: Sockets and XTI,” Prentice Hall, 1998, ISBN: 0-13-490012-X.

• Harold, E., „Java Network Programming 3rd Ed.,” O’Reilly, 2004, ISBN: 0-596-00721-3.



ТЕМА 10 ПРИЛОЖЕН СЛОЙ. WORLD WIDE WEB. ПРОТОКОЛ HTTP

ЦЕЛ НА УПРАЖНЕНИЕТО Целта на упражнението е запознаването на студентите с механизма на работа

на World Wide Web и протокола HTTP, с основните функции на Web сървър и браузер, както и инсталирането и конфигурирането на Web сървър Apache.

ТЕОРЕТИЧНА ЧАСТ Световната мрежа World Wide Web (WWW) представлява разпределена

информационна система, работеща върху световната компютърна мрежа интернет. Към момента Web трафикът съставлява около 80% от общия трафик в интернет. Създатели на системата са колектив от учени с ръководител Тим Лий, работещи в Европейската лаборатория по приложна физика в Женева (CERN). Принципът на работа се основава на клиент-сървър комуникация, използваща протокол за трансфер на хиперинформация HTTP (HyperText Transfer Protocol). HTTP е стандартизиран протокол от приложния слой на TCP/IP протоколния стек, който позволява работа със структурирано разпределени данни, описани чрез езика за хипертекст HTML (HyperText Markup Language). През 1994 година CERN и M.I.T. основават W3C .

Принцип на работа За да работи една Web информационна система, е необходимо да има

правилно инсталиран, конфигуриран и стартиран Web сървър. Компютърната система, на която е инсталиран, трябва да има правилно зададени TCP/IP настройки и връзка към интернет, публичен IP адрес и име, под което да бъде откривана. В зависимост от вида на сървъра и работещите на него Web приложения може да са необходими допълнителни настройки, както и връзка към база от данни. Клиентската програма, най-често Web браузер, изпраща заявки към сървъра в точно определен формат. Сървърът обработва тези заявки и връща обратно резултата. Най-често комуникацията със сървъра е по протокола HTTP, но е възможно също така да е по FTP, Gopher, WAIS, FISH и други.

Фиг.10.1. Пример за унифициран идентификатор на ресурс (URI)

Тема 10 Стр.96 Приложен слой. World Wide Web. Протокол HTTP



Приложен слой. World Wide Web. Протокол HTTP

Обработката на заявките от сървъра става по дисциплината URI (Унифициран идентификатор на ресурса – фигура 10.1). За достъп до отделните обекти се използва техният адрес, зададен чрез URL (Uniform Resource Locator) или URN (Uniform Resource Name).

Една типична HTTP сесия включва следните четири стъпки: • Клиентът инициира ТСР връзка на указания порт (порт 80 по подразбиране), • Клиентът изпраща заявка за използване на определен ресурс, • Сървърът отговаря с резултата от получената и изпълнена заявка, • Сървърът прекратява връзката след изпълнението на заявката.

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

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

Клиент-сървър архитектурата, около която е изградена Web мрежата, се състои от две части: клиентска – която в този случай най-често е представена от Web браузер, и сървърна – представена от Web сървър.

Клиентска част Ще разгледаме най-типичния пример за програма, работеща от страна на

клиента – Web браузер. Популярни браузери са: Mozilla, Firefox, Opera, Internet Explorer, Netscape Navigator, Lynx (текстов). Когато клиент щракне върху хиперлинк, Web браузерът изпълнява следната поредица от стъпки:

• Определя се URI идентификаторът, • Открива се IP адресът на сървъра след консултация с DNS, • Отваря се TCP връзка към сървъра, • Изпраща се HTTP заявка, • Получава се отговор, • TCP връзката се освобождава, • Браузерът визуализира съдържанието на страницата или извиква помощна програма.


Устройството на всеки браузер най-общо включва следните съставни елементи:

• HTTP клиент, • HTML интерпретатор, • Helper приложения и plug-in модули.

За да може браузерът да визуализира правилно информацията от страницата, тя е представена чрез специален език – HTML, който е разгледан по-надолу. Съвременните разпределени документи вече включват звук, графика и обекти, което изисква включването на допълнителни приложения за визуализирането им. Браузерът определя типа на сваления файл с помощта на включения в отговора MIME (Multipurpose Internet Mail Extensions) тип. Ако той е от вградените типове, файла се визуализира директно. В противен случай браузерът се консултира със своята MIME таблица. Таблицата асоциира MIME типовете с приложенията за визуализирането им. Форматът на записите в MIME таблицата е следният:

MIME type ::= type / subtype Основните MIME типове са: • text – текстова информация, • image – изображения, • video – видео, • audio – аудио, • application – обекти, които се обработват извън браузера, • multipart – съобщение съдържащо повече от една част.

Примерни MIME типове: text/html; text/plain; text/css; image/gif; image/jpeg; image/bmp; video/mpeg; audio/x-mpeg; application/pdf; application/msword; application/zip; application/octet-stream; multipart/mixed

Фиг.10.2. Работа на браузера с plug-ins и helper приложения.



Приложенията, използвани от браузера, могат да бъдат от два типа: plug-in модул или helper приложение (фигура 10.2). Plug-in представлява модул, който при необходимост се зарежда в рамките на паметта на браузера. Това позволява директен достъп до текущата страница, като за целта обаче е необходим интерфейс за комуникация между браузера и plug-in модула, различен за различните браузери. Пример за plug-in е macromedia flash player. Помощните приложения от своя страна са самостоятелни програми, изпълнявани като отделни процеси. Те не се нуждаят от интерфейс, като вместо това получават съдържанието през временно създаден файл. Примери за помощни приложения: Adobe Acrobat reader , QuickTime player и MS Word.

Сървърна част Най-общо сървърната част е представена от програма (Web сървър), която

слуша на определен порт за постъпващи заявки, получава и обработва заявките и връща резултат. Най-популярните решения за Web сървър са: Apache, IIS, Tomcat.

Устройството на Web сървъра включва следните основни компоненти (фигура 10.3):

• listener – служи за приемане на TCP заявката; • workers – обработват постъпващите HTTP заявки.

Фиг.10.3. Устройство на Web сървър.

Действията, които се изпълняват от Web сървъра, включват: • Приема TCP връзка, • Извлича името на файла от заявката, • Намира файла на диска, • Изпраща файла на клиента, • Затваря връзката.

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





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

динамично съдържание (CGI, PHP, JSP, ASP, и т.н.), • Определя MIME типа, който да включи в отговора, • Изпълняване на различни задачи, като създаване на профил на

потребителя, събиране на определена статистика и други, • Връща отговора на клиента, • Добавя запис в журналните файлове (logs).

Протокол за трансфер на хипертекст – HTTP Протоколът за трансфер на хипертекст HTTP е създаден през 1990г., а през

1993г. излиза първата работна спецификация на HTTP 1.0. Актуалната му версия е HTTP 1.1. По-долу са изброени основните характеристики на HTTP протокола:

• Глобално URI – HTTP се основава на механизма за идентифициране URI. HTTP включва URI във всяка трансакция за идентифициране на ресурсите в Web;

• Обмен по схемата заявка-отговор – клиентът отправя HTTP заявка и получава отговор от сървъра. Посоката на потока е винаги от клиента към сървъра, сървърът никога не инициира Web трафик;

• Липсва съхраняване на състоянието – HTTP представлява stateless протокол, т.е. не пази информация за състоянието на сесията между клиента и сървъра. В началото това е целяло да не натоварва сървъра със задачата за пазене на сесия. По-късно обаче, с появата на приложения като електронната търговия (e-commerce), това се оказало проблем, който бил разрешен с въвеждането на т.нар. cookies, които представляват файлове от страна на клиента, свързани със запомнянето на състоянието на връзката.

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




в трансакциите може да облекчи комуникацията между клиента и сървъра по няколко начина: o Информацията за кодирането на съдържанието би могла да облекчи обработката;

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

o Сървърът може да укаже времето на последното модифициране на ресурса, което да се използва при управление на кеширането.

HTTP протоколът поддържа различни методи за заявка от страна на клиента. Методът на заявка служи, за да укаже на сървъра какво действие трябва да извърши над заявения ресурс. По-важните методи са:

• GET – заявка за получаване на ресурс, • POST – заявка за предаване на данни към даден ресурс, • PUT – заявка за поставяне на ресурс на даден URI, • DELETE – заявка за изтриване на ресурс.

Структурата на заявката включва: • заглавна част (header) o поддържани типове (MIME), o поддържани кодирания (encoding), o поддържани кодови таблици (charset), o дата и час, o идентификация на потребителя, • тяло на съобщението (body)

При осъществяване на връзка и обмен между клиента и сървъра всяка заявка се характеризира със собствен код на състоянието, който указва дали заявката е обслужена коректно, или е възникнала грешка. По-долу са изброени по-важните кодове и групи от кодове:

• 1xx – информационни: o 100 – Continue; 101 – Switching protocol; • 2xx – успех: o 200 (OK); 201 (Created); 202 (Accepted); 204 (No New Content); • 3xx – пренасочване: o 301 (Moved Permanently); 302 (Moved Temporarily); • 4xx – клиентска грешка: o 400 (Bad Request); 401 (Unauthorized); 403 (Forbidden); 404 (Not Found); • 5xx – грешка при сървъра: o 500 (Internal Server Error); 501 (Not Implemented); 503 (Service

Unavailable).

Език за хипертекст – HTML Езикът за хипертекс HTML позволява създаването на Web страници, които

включват текст, изображения, хипервръзки към други страници и др. Използва се за описване на това как трябва да бъде форматирана страницата от страната на клиента. За целта се употребяват предварително дефинирани тагове. Повечето тагове спазват синтаксиса: <име_на_таг> за начало и </име_на_таг> за край. Таблица 10.1 включва някои от най-популярните HTML тагове. Повече информация за HTML и различните тагове може да получите на официалния сайт на WWW консорциума (http://www.w3c.org/). Табл.10.1. HTML тагове

Таг Описание <html>…</html> Дефинира началото и края на HTML кодирана страница <head>…</head> Отделя заглавната част на Web страницата <title>…</title> Задава заглавието на страницата <body>…</body> Отделя тялото на страницата <hn>…</hn> Отделя заглавна част от ниво n … Определя текста посредата да се визуализира като bold … Определя текста посредата да се визуализира като italic <center>…</center> Определя текста да е центриран хоризонтално <ul>…</ul> Огражда неподреден списък <ol>…</ol> Огражда подреден (номериран) списък <li>…</li> Огражда един елемент от списък Предизвиква преминаване на нов ред … Отделя параграф <hr> Вмъква хоризонтална линия <img src=”…”> Вмъква изображение <a href=”…”>…</a> Вмъква хиперлинк

xHTML С времето HTML езикът постоянно се развива. Последната му версия

xHTML (extended hypertext markup language) е силно повлияна от XML езика и заимства много от концепциите му. Като начало таговете вече нямат предефинирано значение. За да се запази съвместимост с HTML 4, значението на вече използваните тагове се задава в XSL файлове. Съществуват 6 основни разлики между xHTML и HTML 4:

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

• стойностите на всички атрибути трябва да се ограждат в кавички; • таговете трябва да са правилно вложени един в друг;




• всеки документ трябва да указва своя формат. Повече за xHTML и разликите му с HTML 4 може да научите от страницата

на WWW консорциума (www.w3c.org).

Инсталиране и настройване на Apache Web сървър Една от най-популярните реализации на Web сървър е Apache Web сървърът.

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

Под ОС Windows За целите на упражнението ще бъде разгледана само инсталацията под ОС

Windows ХР. Инсталационните файлове могат да бъдат намерени на официалната страница на Apache проекта (http://httpd.apache.org). Свалете ги на сървърната машината и ги стартирайте. По време на инсталацията ще бъдете попитани за име на домейн и име на сървър. В случай, че не разполагате с такива, въведете localhost и на двете места. Инсталационната програма използва тези стойности, за да създаде конфигурационен файл. Винаги можете по-късно да ги промените ръчно. След успешното инсталиране сървърът ще се стартира по подразбиране. Това може да бъде променено от Control Panel Administrative Tools Services.

Ако искате да направите промени по конфигурацията на сървъра, е необходимо да отворите в текстов редактор файла httpd.conf (стандартно се намира в C:\Program Files\Apache Group\Apache\conf\httpd.conf). Всеки път, когато модифицирате конфигурацията, е необходимо да рестартирате сървъра след това, за да бъдат възприети промените. Редовете, маркирани с диез (#) представляват коментари.

За да проверите дали правилно сте инсталирали и конфигурирали Web сървъра, заредете http://localhost/ в адресното поле на Web браузер. Ако всичко е наред, трябва да ви се зареди стандартна страница на Apache. Стандартно Web страниците се намират в C:\Program Files\Apache Group\Apache\httpdocs\.

Под ОС Unix/Linux Съществуват няколко начина да инсталирате Apache под Unix/Linux. Ако

разполагате с графична среда можете да използвате пакетен мениджър. В противен случай може да използвате някое от конзолните приложения за различните дистрибуции (apt-get, rpm, и т.н.). Общото при тези методи е, че инсталирате предварително компилирана версия. Най-универсалният начин за инсталиране обаче си остава чрез собственоръчното компилиране на изходните файлове на сървъра. Те се разпространяват свободно и са налични през Web сайта на Apache проекта (http://httpd.apache.org). Обикновено се




разпространяват архивирани и за целта е необходимо след свалянето да бъдат разкомпресирани. След това трябва да изберете директорията с разкомпресираните изходни файлове за текуща директория.

Следващата стъпка е конфигуриране на инсталацията за конкретната платформа и изисквания. За целта използвате включения в дистрибуцията скрипт файл configure. Ако желаете да използвате стандартните настройки, стартирайте скрипта. В противен случай следва да му подадете като параметри от командния ред различните настройки. Една от най-важните настройки е тази, указваща къде ще бъде инсталиран Web сървърът “--prefix”. Съществуват и допълнителни настройки, указващи къде да бъдат създадени различните конфигурационни файлове и т.н.

Ако желаете да включите модули различни от стандартните, използвайте опцията --enable-module, където module трябва да бъде заменено с името на модула, който желаете да включите. Понякога е нужно да укажете и пътя до компилатора, библиотеките и хедърните файлове. Примерно, следващият ред указва, че сървърът ще бъде инсталиран в /usr/local/bin/apache директорията, а също и че два модула ще бъдат допълнително включени (mod_rewrite и mod_speling): $./configure --prefix=/usr/local/bin/apache \ --enable-rewrite=shared \ --enable-speling=shared

След конфигурирането на инсталацията се преминава и към компилирането на изходните файлове и инсталирането на Apache HTTP сървъра. Това се изпълнява от следващите две команди. $ make $ make install

Ако желаете да направите промени по конфигурацията на сървъра, е необходимо да отворите в текстов редактор файла httpd.conf. В текущия той следва да се намира в директорията PREFIX/conf/, където PREFIX е указаната на configure скрипта директория. Ако е инсталиран по някой от другите методи, може да се намира в директорията /etc/apache/. Отново след всяка промяна е необходимо да рестартирате сървъра, за да бъдат възприети промените. $ vi PREFIX/conf/httpd.conf

След инсталирането на сървъра той се стартира автоматично. Вие можете да го управлявате ръчно, като използвате командата apachectl, която е показана по-долу. Освен start поддържани опции са restart и stop. $ PREFIX/bin/apachectl start

Повече информация за настройката и инсталирането на Apache Web сървъра може да потърсите в директорията /PREFIX/docs/manual или на адрес http://httpd.apache.org/docs/.




ЗАДАЧИ ЗА ИЗПЪЛНЕНИЕ 1. Инсталирайте и настройте Apache Web сървър. 2. Създайте примерен HTML документ и го добавете на подходящото място

заедно с ресурсите към него. 3. Изпълнете следните стъпки:

- стартирайте Web сървъра; - стартирайте анализатор на трафик; - отворете браузер и заредете пътя до създадения в предходната точка документ. - разгледайте обменените между клиента и сървъра пакети.

4. Използвайки програмната реализация от Тема 9, напишете елементарен Web сървър, обслужващ единствено заявката GET и статично съдържание. Изпълнете задача 3 за създадения сървър.

5. Реализиране на собствен многонишков Web сървър, поддържащ GET заявки. Език за програмиране по избор. Изисквания към сървъра: - да получава конфигурационните си параметри през файл; - конфигурационните параметри да включват: root директория; номер на порт; максимален брой на worker нишките. - да съхранява журнална информация (log) във файл; - да връща в отговор поискания файл или подходящо съобщение за грешка; - да включва правилния MIME тип. - Изпълнете отново задача 3 за новосъздадения сървър.

ДОПЪЛНИТЕЛНА ЛИТЕРАТУРА • Боянов, К., Х. Турлаков, Д. Тодоров, Л. Боянов, В. Димитров, В. Желязков,

„Принципи на работа на компютърните мрежи. Интернет”, Апиинфоцентър „Котларски”, София, 2003, ISBN: 954 9713-06-7.

• Krishnamurthy, B., J. Rexford, „Web Protocols and Practice: HTTP/1.1, Networking Protocols, Caching, and Traffic Measurement,” Addison-Wesley, 2001, ISBN-10: 0201710889.

• World Wide Web Consortium – http://www.w3.org/ • Apache Web Server official website – http://httpd.apache.org • Apache Web Server documentation site – http://httpd.apache.org/docs/ • Example of a simple multithreaded Web server –

http://java.sun.com/developer/technicalArticles/Networking/Webserver/

РЪКОВОДСТВО -...

Documents