Протокол транспортного уровня UDP, общее описание.

 

Протокол User Datagram Protocol (UDP) обеспечивает неориентированную на соединение службу доставки дейтаграмм по принципу "максимального усилия". Это означает, что получение всей дейтаграммы или правильной последовательности не гарантируется. Протокол UDP используется приложениями, не требующими подтверждения. Обычно такие приложения передают данные небольшого объема за один раз. К примеру, это: сервис имен Net­BIOS, сервис SNMP, сервис дейтаграмм NetBIOS.

 

Порты протокола UDP.

Для использования протокола UDP приложение должно знать IP- адрес и номер порта получателя. Порт действует как мультиплексная очередь сообщений, то есть он может получать несколько сообщение одновременно. Важно отметить, что порты UDP отличаются от портов TCP несмотря на использование одних и тех же значений номеров.

 

Описание работы UDP.

Порт UDP легче всего представить в виде очереди. В большинстве реализаций, когда прикладная программа "договаривается" с операционной системой об использовании данного порта, операционная система создает внутреннюю очередь, которая хранит приходящие сообщения. Часто приложение может указать или изменить размеры очереди. Когда узел получает дейтаграмму по UDP-протоколу, он проверяет, нет ли порта назначения с таким номером среди используемых портов. Если таких портов нет, UDP посылает ICMP- сообщение об ошибке "порт недоступен" и уничтожает дейтаграмму. Если есть, UDP добавляет новую дейтаграмму в очередь порта, где прикладная программа может ее получить. Если очередь порта уже переполнена, то тогда UDP уничтожает новую дейтаграмму.

 

Сравнение производительности TCP и UDP.

Последовательность действий (запросов и ответов) для протоколов TCP и UDP представлена на рис. 5.4. Как видно из рисунка, передача

Рис.5.4 Последовательность запросов и ответов в TCP и UDP. SYN -пакет синхронизации, DB - блок данных, ACK- подтверждение.

началась в момент времени t₀ по обоим протоколам. К моменту времени t1 протокол UDP завершил передачу, в то время, как по протоколу TCP передача закончится только к моменту времени t2. Легко получить разницу во времени ∆t = t2 —t1.

Таким образом, протокол UDP работает быстрее, чем TCP. Данные по протоколу UDP отсылаются получателю друг за другом и не требуется получение подтверждения об успешной доставке данных получателю. UDP не тратит время на установление связи в несколько этапов. Стоит отметить, что TCP путем механизма подтверждений гарантирует успешную доставку данных получателю, в то время, как данные посланные через UDP могут и не дойти до адресата.

 

Лабораторная работа №3

Цель: провести анализ производительности протоколов TCP и UDP для заданной конфигурации сети, и на основании полученных результатов сделать заключение о том, какой протокол предпочтительнее использовать.

Порядок выполнения работы

1. В качестве схемы сети взять результат выполнения соответствующего варианта лабораторной работы №1.

2. Протестировать отправку по UDP и по TCP 20 сообщений с K1 на K3.

3. Объяснить, анализируя вывод программы, какой протокол выгоднее использовать с точки зрения скорости доставки информации и дополнительных накладных расходов.

4. Протестировать отправку по UDP и по TCP 20 сообщений с K2 на K1.

5. Проанализировать статистику отправки пакетов по протоколам UDP и TCP и определить дополнительные расходы по обеспечению надежной передачи в протоколе TCP.

6. Проанализировать время соединения, сделать вывод о том, какой протокол быстрее справился с поставленной задачей.

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

Отчет должен содержать: анализ производительности протоколов TCP и UDP для заданной конфигурации сети при коэффициенте пропускания равном 100, расчет дополнительных расходов для протокола TCP по пересылке пакетов и анализ производительности сети для обоих протоколов, анализ времени соединения. В отчете также необходимо привести вывод о том, какой протокол предпочтительнее использовать в данной конфигурации сети.

 

Варианты заданий

Вариант 1. В качестве файла со схемой сети использовать результат выполнения лабораторной работы 1, вариант 1. Обозначения в задании: K1 - Boss, K2 - Hacker, K3 - OFFICE2 pc1.

Вариант 2. В качестве файла со схемой сети использовать результат выполнения лабораторной работы 1, вариант 2. Обозначения в задании: K1 - BIG BOSS, K2 - M_CH_S, K3 - OFFICE1 pc4.

Вариант 3. В качестве файла со схемой сети использовать результат выполнения лабораторной работы 1, вариант 3. Обозначения в задании: K1 - Boss, K2 - Hacker, K3 - OFFICE2 pc1.

Вариант 4. В качестве файла со схемой сети использовать результат выполнения лабораторной работы 1, вариант 4. Обозначения в задании: K1 - BIG BOSS, K2 - M_CH_S, K3 - OFFICE1 pc4.

Вариант 5. В качестве файла со схемой сети использовать результат выполнения лабораторной работы 1, вариант 5. Обозначения в задании: K1 - MegaBoss, K2 - Manager2, K3 - FileServer.

Вариант 6. В качестве файла со схемой сети использовать результат выполнения лабораторной работы 1, вариант 6. Обозначения в задании: K1 - Manager3, K2 - PrintServer, K3 - MicroBoss.

 

Пример выполнения лабораторной работы

Файл со схемой сети: lab4_sample.jfst. Компьютер PC1 имеет IP- адрес 192.168.0.1. Компьютер PC2 имеет IP-адрес 192.168.0.2. Задание:

1. В качестве схемы сети взять результат выполнения соответствующего варианта лабораторной работы №1.

2. Установить коэффициент пропускания всех линий равный 100.

3. Протестировать отправку по UDP и по TCP 20 сообщений с K1 на K3.

4. Проанализировать статистику отправки пакетов по протоколам UDP и TCP и определить дополнительные расходы по обеспечению надежной передачи в протоколе TCP.

5. Объяснить, анализируя вывод программы, какой протокол выгоднее использовать с точки зрения скорости доставки информации и дополнительных накладных расходов.

6. Проанализировать время соединения, сделать вывод о том, какой протокол быстрее справился с поставленной задачей.

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

 

1. Убедимся, что коэффициент пропускания на всех линиях (в том числе между PC1 и PC2) равен 100.

2. Выберем PC1 и запустим на нем UDP-приложение (UPD-сервер), выбрав в качестве прослушиваемого порт 7.

Программа выдаст следующее сообщение: pc1 Application is now listening on port 7.

3. Выберем PC2 и пошлем через UDP-приложение 20 сообщений со строкой "гsh"на PC1. Программа выдаст похожее на следующее сообщение (для первого из двадцати сообщений):

рс2 Start sending echo message 'rsh' to 192.168.0.1:7

pc2 Created UDP packet for 192.168.0.1:7.

pc1 Created ARP Response packet to 192.168.0.2

pc1 Sending packet from ProtocolStack (to 192.168.0.2).

pc2 Sending packet from ProtocolStack (to 192.168.0.1).

pc1 ProtocolStack received packet from local Interface,

pc1 Confirmed Packet is for this Network Layer Device,

pc1 UDP packet received from 192.168.0.2:3000 message:"rsh". UDP Port 7 has status "busy" from now.

pc1 Application Recieving echo message 'rsh' from client,

pc1 Application Sending echo message 'rsh' to client,

pc1 Created UDP packet for 192.168.0.2:3000.

pc1 Sending packet from ProtocolStack (to 192.168.0.2).

pc2 ProtocolStack received packet from local Interface.

pc2 Confirmed Packet is for this Network Layer Device. pc2 UDP packet received from 192.168.0.1:7 message: "rsh".

pc2 Recieving echo message 'rsh' from server,

pc1 Server closing connection. Now listening on 7.

pc1 Application is now listening on port 7.

4. Выберем меню статистики узла PC1 и проверим, сколько UDP дейтаграмм он получил и отправил. Будет выведен следующий результат:

"Received UDP segments: 20", что означает, что получено 20 UDP дейтаграмм, и

"Sent UDP segments: 20", что означает, что отправлено 20 UDP дейтаграмм. При заданных параметрах сети процент потерь равен 0%.

5. Выберем PC1 и запустим на нем TCP-приложение (TCP-сервер), выбрав в качестве прослушиваемого порт 8.

Программа выдаст следующее сообщение:

pс1 Application is now listening on port 8.

6. Выберем PC2 и пошлем через TCP-приложение 20 сообщений со строкой "ррр"на PC1. Программа выдаст похожее на следующее сообщение (для первого из двадцати сообщений, дошедших до PC1):

рс2 Connecting to host 192.168.0.1:8.

Please wait...

pc2 TCP SYN-packet for 192.168.0.1:8.

pс1 ProtocolStack received packet from local Interface,

pс1 Created ARP Response packet to 192.168.0.2

pс1 Sending packet from ProtocolStack (to 192.168.0.2).

pc2 ProtocolStack received packet from local Interface.

pc2 Sending packet from ProtocolStack (to 192.168.0.1).

pс1 ProtocolStack received packet from local Interface,

pс1 TCP SYN-packet received from 192.168.0.2:3000.

TCP Port 8 has status "busy" from now.

pс1 Created TCP SYN-packet for 192.168.0.2:3000.

pс1 Sending packet from ProtocolStack (to 192.168.0.2).

pc2 TCP SYN-packet with ACK received from 192.168.0.1:8.

TCP Port 3000 still has status "busy".

pc2 Created TCP acknowledgement packet for 192.168.0.1:8.

pc2 Sending packet from ProtocolStack (to 192.168.0.1).

pс1 TCP packet with establishing connection ACK received from 192.168.0.2:3000. Connection confirmed! New TCP connection established!

pc2 Start sending echo message 'ppp' to 192.168.0.1:8

pc2 Created TCP data packet for 192.168.0.1:8.

pc2 Sending packet from ProtocolStack (to 192.168.0.1).

pс1 ProtocolStack received packet from local Interface,

pс1 Created TCP acknowledgement packet

for 192.168.0.2:3000. pс1 Sending packet from ProtocolStack

(to 192.168.0.2).

pc2 ProtocolStack received packet from local Interface.

pc2 TCP packet with establishing connection ACK

received from 192.168.0.1:8. Connection confirmed!

pс1 TCP packet with data received from 192.168.0.2:3000.

Passing data to application program,

pс1 Recieving echo message 'ppp' from client,

pс1 Sending echo message 'ppp' to client.

 

7. Выберем меню статистики узла PC1 и проверим, сколько TCP сегментов он получил и отправил. Будет выведен следующий результат: "Received TCP segments: 45", "Sent TCP segments: 43", "Sent TCP ACKs: 23", что означает, что отправлено 23 подтверждения, также будет нулевая статистика по отосланным и принятым дубликатам. Выберем меню статистики узла PC2 и проверим, сколько TCP сегментов он получил и отправил. Будет выведен следующий результат: "Received TCP segments: 43", "Sent TCP segments: 45", "Sent TCP ACKs: 23", что означает, что отправлено 23 подтверждения, также будет нулевая статистика по отосланным и принятым дубликатам. Из этого можно сделать вывод о том, что для хорошей линии передач излишне проводить загрузку канала подтверждениями о получении сегментов, которые занимают около 50% сегментов, задействованных в обмене информацией, однако, были доставлены все 20 сообщений, что удовлетворяет требованиям по процентам потерь.

8. В результате анализа полученных результатов можно сделать следующие выводы. В условиях качественного обеспечения передачи UDP протокол показал себя с хорошей стороны, так как все дейтаграммы дошли до адресатов.

По времени было затрачено 32ms. Не тратилось время на установление соединения и на подтверждения получения пакетов.

Результаты проведенной работы по протоколу TCP говорят о неэффективном использовании им (данным протоколом) качественных линий, так как дополнительное время тратится на подтверждение пакетов, а также на установление и разрыв связи.

По времени передача по протоколу TCP заняла 74.4ms, что в 2.5 раза больше, чем время затраченное при передаче через UDP. Таким образом, применение протокола оправдано в случаях, требующих гарантированного получения адресатом всей посылаемой информации (к примеру, проверка электронной цифровой подписи).

5.5.4 Контрольные вопросы

1. Какой из протоколов транспортного уровня обеспечивает надежную доставку данных? За счет какого механизма обеспечивается гарантия доставки?

2. Назовите ситуации, в которых применение протокола UDP является целесообразным.

3. Назовите ситуации, в которых применение протокола TCP является неелесообразным.

4. Чем в TCP обеспечивается надежность работы по передаче данных?

5. Сколькими пакетами обмениваются во время UDP-соединения клиент и сервер?

6. Сколькими пакетами обмениваются во время TCP-соединения клиент и сервер? Какие существуют пакеты TCP?

 

Лабораторная работа №4

Цель: провести анализ надежности и производительности протоколов TCP и UDP в условиях потерь в линии связи.

Порядок выполнения работы

1. В качестве схемы сети взять результат выполнения соответствующего варианта лабораторной работы №1. Установить коэффициенты потерь при прохождения пакетов согласно вашему варианту

2. Подсчитать процент потерь пакетов при использовании протоколов TCP и UDP. Подсчитать дополнительные расходы протокола TCP на обеспечение надежной передачи.

3. Проанализировать время соединения, сделать вывод о том, какой протокол быстрее справился с поставленной задачей (необходимо учитывать требуемую надежность).

4. Определить состояние, при котором сеть начинает удовлетворять требованиям по потерям пакетов. Для этого подобрать такие значения коэффициентов пропускания, при которых будет теряться не более 7% пакетов в потоколе TCP.

Отчет должен содержать: анализ производительности протоколов TCP и UDP для заданной конфигурации сети и заданном коэффициенте пропускания канала, расчет процента потерь пакетов и анализ производительности сети для обоих протоколов в условиях недоброкачественных линий передач. оценку удовлетворения сетью критерия 7% по потере пакетов, анализ времени соединения. В отчете также необходимо привести вывод о том, какой протокол предпочтительнее использовать в данной конфигурации сети.

 

Варианты заданий

Вариант 1. В качестве файла со схемой сети использовать результат выполнения лабораторной работы 1, вариант 1. Установите коэффициент прохождения пакетов между узлами Connector и Boss_R равный 82.

Обозначения в задании: K1 - Boss, K2 - Hacker, K3 - OFFICE2 pc1.

Вариант 2. В качестве файла со схемой сети использовать результат выполнения лабораторной работы 1, вариант 2. Установите коэффициент прохождения пакетов между узлами H_OFFICE1 и OFF_R равный 71.

Обозначения в задании: K1 - BIG BOSS, K2 - M_CH_S, K3 - OFFICE1 pc4.

Вариант 3. В качестве файла со схемой сети использовать результат выполнения лабораторной работы 1, вариант 3. Установите коэффициент прохождения пакетов между узлами Connector и Hacker рваным 75.

Обозначения в задании: K1 - Boss, K2 - Hacker, K3 - OFFICE2 pc1. Вариант 4. В качестве файла со схемой сети использовать результат выполнения лабораторной работы 1, вариант 4. Установите коэффициент прохождения пакетов между узлами BOSS HUB и R2 равный 85.

Обозначения в задании: K1 - BIG BOSS, K2 - M_CH_S, K3 - OFFICE1 pc4.

Вариант 5. В качестве файла со схемой сети использовать результат выполнения лабораторной работы 1, вариант 5. Установите коэффициент прохождения пакетов между узлами HBosses и center равным 80.

Обозначения в задании: K1 - MegaBoss, K2 - Manager2, K3 - FileServer.

Вариант 6. В качестве файла со схемой сети использовать результат выполнения лабораторной работы 1, вариант 6. Установите коэффициент прохождения пакетов между узлами HManagers и center равным 78.

Обозначения в задании: K1 - Manager3, K2 - PrintServer, K3 - MicroBoss.

 

Пример выполнения лабораторной работы

Файл со схемой сети: lab4_sample.jfst. Компьютер PC1 имеет IP- адрес 192.168.0.1. Компьютер PC2 имеет IP-адрес 192.168.0.2. Задание:

1. Установить коэффициент пропускания всех линий равный 100.

2. Протестировать отправку по UDP и TCP 20 сообщений с PC2 на PC1.

3. Объяснить, анализируя вывод программы, какой протокол выгоднее использовать с точки зрения скорости доставки информации.

4. Установить коэффициент пропускания 65.

5. Протестировать отправку по UDP и TCP 20 сообщений с PC2 на PC1.

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

7. Подсчитать процент потерь пакетов.

8. Проанализировать время соединения, сделать вывод о том, какой протокол быстрее справился с поставленной задачей (необходимо учитывать требуемую надежность).

9. Определить состояние, при котором сеть начинает удовлетворять требованиям по потери пакетов. Для этого подобрать такие значения коэффициентов пропускания в линии связи, при которых будет теряться не более 7% пакетов.

 

Порядок выполнения работы будет следующим:

1. Убедимся, что коэффициент пропускания на всех линиях (в том числе между PC1 и PC2) равен 65.

2. Выберем PC1 и запустим на нем UDP-приложение (UPD-сервер), выбрав в качестве прослушиваемого порт 7.

Программа выдаст следующее сообщение:

pc1 Application is now listening on port 7.

3. Выберем PC2 и пошлем через UDP-приложение 20 сообщений со строкой "гsh"на PC1. Программа выдаст похожее на следующее сообщение (для первого из двадцати сообщений):

рс2 Start sending echo message 'rsh' to 192.168.0.1:7

pc2 Created UDP packet for 192.168.0.1:7.

pc1 Created ARP Response packet to 192.168.0.2

pc1 Sending packet from ProtocolStack (to 192.168.0.2).

pc2 Sending packet from ProtocolStack (to 192.168.0.1).

pc1 ProtocolStack received packet from local Interface,

pc1 Confirmed Packet is for this Network Layer Device,

pc1 UDP packet received from 192.168.0.2:3000 message:"rsh". UDP Port 7 has status "busy" from now.

pc1 Application Recieving echo message 'rsh' from client,

pc1 Application Sending echo message 'rsh' to client,

pc1 Created UDP packet for 192.168.0.2:3000.

pc1 Sending packet from ProtocolStack (to 192.168.0.2).

pc2 ProtocolStack received packet from local Interface.

pc2 Confirmed Packet is for this Network Layer Device. pc2 UDP packet received from 192.168.0.1:7 message: "rsh".

pc2 Recieving echo message 'rsh' from server,

pc1 Server closing connection. Now listening on 7.

pc1 Application is now listening on port 7.

4. Выберем меню статистики узла PC1 и проверим, сколько UDP дейтаграмм он получил и отправил. Будет, с большой вероятностью, выведен следующий результат: "Received UDP segments: 13", что означает, что получено 13 UDP дейтаграмм, и "Sent UDP segments: 13", что означает, что отправлено 13 UDP дейтаграмм.

5. Выберем меню статистики узла PC2 и проверим, сколько UDP дейтаграмм он получил и отправил за все время нашего опыта. Будет, с большой вероятностью, выведен следующий результат: "Received UDP segments: 26", что означает, что получено 26 UDP сегментов, и "Sent UDP segments: 40", что означает, что отправлено 40 UDP сегментов. При заданных параметрах сети процент потерь больше, чем 7%, что не удовлетворяет требованиям.

Можно попробовать использовать протокол TCP.

6. Выберем PC1 и запустим на нем TCP-приложение (TCP-сервер), выбрав в качестве прослушиваемого порт 8. Коэффициент предачи линии установим 100%. (Потери отсутствуют).

Программа выдаст следующее сообщение:

pс1 Application is now listening on port 8.

7. Выберем PC2 и пошлем через TCP-приложение 20 сообщений со строкой "ррр"на PC1. Программа выдаст похожее на следующее сообщение (для первого из двадцати сообщений, дошедших до PC1):

рс2 Connecting to host 192.168.0.1:8.

Please wait...

pc2 TCP SYN-packet for 192.168.0.1:8.

pс1 ProtocolStack received packet from local Interface,

pс1 Created ARP Response packet to 192.168.0.2

pс1 Sending packet from ProtocolStack (to 192.168.0.2).

pc2 ProtocolStack received packet from local Interface.

pc2 Sending packet from ProtocolStack (to 192.168.0.1).

pс1 ProtocolStack received packet from local Interface,

pс1 TCP SYN-packet received from 192.168.0.2:3000.

TCP Port 8 has status "busy" from now.

pс1 Created TCP SYN-packet for 192.168.0.2:3000.

pс1 Sending packet from ProtocolStack (to 192.168.0.2).

pc2 TCP SYN-packet with ACK received from 192.168.0.1:8.

TCP Port 3000 still has status "busy".

pc2 Created TCP acknowledgement packet for 192.168.0.1:8.

pc2 Sending packet from ProtocolStack (to 192.168.0.1).

pс1 TCP packet with establishing connection ACK received from 192.168.0.2:3000. Connection confirmed! New TCP connection established!

pc2 Start sending echo message 'ppp' to 192.168.0.1:8

pc2 Created TCP data packet for 192.168.0.1:8.

pc2 Sending packet from ProtocolStack (to 192.168.0.1).

pс1 ProtocolStack received packet from local Interface,

pс1 Created TCP acknowledgement packet

for 192.168.0.2:3000. pс1 Sending packet from ProtocolStack

(to 192.168.0.2).

pc2 ProtocolStack received packet from local Interface.

pc2 TCP packet with establishing connection ACK

received from 192.168.0.1:8. Connection confirmed!

pс1 TCP packet with data received from 192.168.0.2:3000.

Passing data to application program,

pс1 Recieving echo message 'ppp' from client,

pс1 Sending echo message 'ppp' to client.

 

11. Обнулим статистику узла PC1 и PC2. Теперь установим коэффициент пропускания 60 и снова пошлем с PC2 на PC1 20 TCP сегментов.

12. Выберем PC2 и пошлем через TCP-приложение 20 сообщений со строкой "ррр"на PC1.

Программа, в нашем случае, выдаст следующее сообщение:

рс2 Packet lost due to physical link problems!

pс1 Server awaiting connection timeout!

Now server is listening to port: 8.

pc2 Connection timeout! Closing connection

to host: 192.168.0.1:8.

Это говорит о том, что на PC2 было закрыто подключение к PC1 и на PC1 было закрыто подключение к PC2, т.к. качество линий в данном примере не позволяет обмениваться информацией за установленные программой на соединение промежутки времени. При таких параметрах сеть не удовлетворяет требуемым условиям по потерям: не более 7%.

Если проверить статистику PC2, то можно увидеть, что было отправлено 14 дубликатов, а получено 27 дубликатов. В то время, как было отправлено 10 сегментов, а получено 11.

13. Обнулим статистику узла PC1 и PC2. Теперь установим коэффициент пропускания 88 и снова пошлем с PC2 на PC1 5 TCP сегментов.

14. Выберем меню статистики узла PC2 и проверим, сколько TCP сегментов он получил и отправил за время нашего опыта. Будет, с большой вероятностью, выведен результат такой, что было отправлено 14 TCP сегментов, 8 дубликатов, 6 подтверждений, также было получено 10 сегментов.

15. В результате анализа полученных результатов можно сделать следующие выводы:

В условиях качественного обеспечения передачи UDP протокол показал себя с хорошей стороны, так как все дейтаграммы дошли до адресатов.

По времени было затрачено 32ms. Не тратилось время на установление соединения и на подтверждения получения пакетов. При плохом качестве линий не все пакеты дошли до пунктов назначения. Оправданием использования UDP на плохих линиях может стать только то, что информация за время задержки или потери станет неактуальна, и ее можно не передавать (к примеру, видеоконференция через Интернет).

Результаты проведенной работы по протоколу TCP говорят о неэффективном использовании им (данным протоколом) качественных линий, так как дополнительное время тратится на подтверждение пакетов, а также на установление и разрыв связи. В условиях некачественной физической линии использование TCP явно предпочтительнее, так как "потерявшиеся" сегменты пересылаются и, в конечном счете, доходят до адресата. По времени передача по протоколу TCP заняла 344ms, что в 10.75 раза больше, чем время затраченное при передаче через UDP. Таким образом, применение протокола оправдано в случаях, требующих гарантированного получения адресатом всей посылаемой информации (к примеру, проверка электронной цифровой подписи).

Очевидно, что при использовании UDP сеть начинает удовлетворять семипроцентному критерию по потере пакетов при коэффициенте пропускания между узлами PC1 и PC2 не менее 93%. Если использовать TCP, то критерий по потере пакетов удовлетворяется при коэффициенте пропускания между узлами PC1 и PC2, принадлежащем интервалу от 60 до 65.

 

5.6.4 Контрольные вопросы

1. Какой из протоколов транспортного уровня обеспечивает надежную доставку данных? За счет какого механизма обеспечивается гарантия доставки?

2. Назовите ситуации, в которых применение протокола UDP является нецелесообразным.

3. Назовите ситуации, в которых применение протокола TCP является целесообразным.

4. Чем в TCP обеспечивается надежность работы по передаче данных?

5. Сколькими пакетами обмениваются во время UDP-соединения клиент и сервер?

6. Сколькими пакетами обмениваются во время TCP-соединения клиент и сервер? Какие существуют пакеты TCP?

 

 

6. УРОВЕНЬ ПРИЛОЖЕНИЙ: ПРОТОКОЛЫ TELNET И SNMP

6.1. Уровень приложений стека протоколов TCP/IP

Уровень приложений модели стека протоколов TCP/IP выполняет следующие функции.

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

• Имеет дело с формой представления передаваемой по сети информацией, не меняя при этом ее содержания. За счет этого информация, передаваемая уровнем приложений одной системы, всегда понятна уровню приложений другой системы. С помощью средств данного уровня протоколы уровня приложений могут преодолеть синтаксические различия в представлении данных.

• Может выполнять шифрование и дешифрование данных.

• Предоставляет набор разнообразных протоколов, с помощью которых пользователи сети получают доступ к разделяемым ресурсам, таким как файлы, принтеры или гипертекстовые Web- страницы, а также организуют свою совместную работу, например, с помощью протокола электронной почты.

Обобщая можно сказать, что прикладной уровень стека протоколов TCP/IP объединяет все службы, предоставляемые системой пользовательским приложениям. Прикладной уровень реализуется программными системами, построенными в архитектуре клиент- сервер, базирующимися на протоколах нижних уровней. И в отличие от протоколов остальных трех уровней стека протоколов TCP/IP, протоколы прикладного уровня описывают работу конкретного приложения и не способны к передаче данных по сети. Этот уровень постоянно расширяется т.к. наравне со старым, прошедшими многолетнюю эксплуатацию сетевыми протоколами типа TELNET, FTP, TFTP, DNS, SNMP создаются сравнительно новые такие, например, как протокол передачи гипертекстовой информации HTTP. Уровень приложений модели стека TCP/IP соответствует совокупности трех уровней модели OSI: сеансового уровня, уровня представлений и прикладного уровня. В этой главе рассмотрены два прикладных протокола: SNMP - простой протокол управления сетью и TELNET - протокол для создания незащищенного соединения с серверным программным обеспечением.

 

Протокол SNMP

С любой сети функционирует большое количество узлов, маршрутизаторов и имеется широкий набор программных средств. Сеть сохраняет работоспособность благодаря жесткой протокольной регламентации, требующей разработки средств контроля и управления. Функции диагностики сети возложены на ICMP, а функции управления на SNMP (Sii^e Network Management Protocol - RFC1157). Чаще всего управляющая прикладная программа воздействует на сеть по цепочке: SNMP, UDP, IP, физическая сеть. Управление сетью - это процесс управления отказами, контроля конфигураций, мониторинга производительности, обеспечения защиты и учета деятельности в сети передачи данных. Наиболее важным объектом управления обычно является маршрутизатор. Каждому управляемому объекту присваивается уникальный идентификатор.

Протокол SNMP использует UDP в качестве транспортного протокола и предназначен для использования сетевыми управляющими станциями. Он позволяет управляющим станциям собирать информацию о положении в сети. Протокол определяет формат данных, а их обработка и интерпретация остаются на усмотрение управляющих станций или менеджера сети.

Приложения управления сетью называемые менеджерами, общаются с программным обеспечением сетевых устройств, называемым агентами. SNMP - это протокол типа "запрос-отклик", то есть на каждый запрос, поступивший от менеджера, агент должен передать отклик. Под запросом будем понимать передачу информации от менеджера к агенту с целью получения параметров объекта управления. Под откликом будем понимать ответ агента, на запрос менеджера, содержащий требуемые параметры. Обмен данными между менеджером и агентом дает возможность менеджеру собирать стандартный набор информации, который определен в базе данных информации для управления сетью - MIB. Порция информации, существующая в базе данных, называется объектом.

Алгоритмы управления в сети обычно описывают в нотации ASN.1 (Ab­stract Syntax Notation). Все объекты в сети разделены на 10 групп и описаны в MIB: система, интерфейсы, обмены, трансляция адресов, IP, ICMP, TCP, UDP, EGP, SNMP. В группу "система" входит название и версия оборудования, операционной системы, сетевого программного обеспечения и пр. В группу "интерфейсы" входит число поддерживаемых интерфейсов, тип интерфейса, работающего под управлением IP (Eth­ernet, LAPB и т.д.), размер дейтаграмм, скорость обмена, адрес интерфейса. IP-группа включает время жизни дейтаграмм, информацию о фрагментации, маски подсетей и т.д. В TCP-группу входит алгоритм повторной пересылки, максимальное число повторных пересылок и пр.

Протокол SNMP имеет достаточно простую структуру и включает в себя следующие команды:

• Get-request используется менеджером для получения от агента значения какого-либо параметра по его имени;

• GetNext-request используется для извлечения значения следующего объекта (без указания его имени) при последовательном просмотре таблицы объектов;

• Set используется менеджером для изменения значения какого- либо объекта. С помощью команды Set происходит собственно управление устройством. Агент должен понимать смысл значения объекта, который используется для управления устройством, и на основании этих значений выполнять реальное управляющее воздействие - отключить порт, установить IP адрес и т.п.

• Команда Set пригодна также для установки условия, при выполнении которого агент SNMP должен послать менеджеру соответствующее сообщение. Может быть определена реакция на такие события, как инициализация агента, рестарт агента, обрыв связи, восстановление связи, неверная аутентификация, потеря ближайшего маршрутизатора и др. Если происходит любое из этих событий, то агент инициализирует прерывание (trap). Если запросом Set устанавливаются значения сразу нескольких объектов, то в случае ошибки все объекты останутся без изменений;

• Get-response обеспечивает передачу ответа на команды Get-re­quest, GetNext-request или Set от агента SNMP менеджеру. Get- response возвращает значения запрошенных объектов, только в случае успешного выполнения команд Get, GetNext или Set;

• Trap используется агентом для сообщения менеджеру о возникновении особой ситуации.

Схема иллюстрирующая обмен данными между SNMP менеджером и SNMP агентом представлена на рисунке 6.1. Прямоугольниками с числами обозначены порты на которых менеджер и/или агент ожидает дейтаграммы пользователя. Обычно SNMP агент использует 161 порт для ожидания запросов get, get-next или set, а SNMP менеджер - 162 порт для ожидания прерываний (trap). Объектом управления является любое сетевое устройство поддерживающее протокол SNMP,

 

 

Рис. 6.1 Схема запросов/откликов SNMP. на котором запущен SNMP агент.

 

Управляющая база данных MIB

Вся управляющая информация для контроля сетевых устройств (маршрутизаторы, коммутаторы и т.п.) концентрируется в базе данных MIB (Management Information Base, RFC1212, RFC1213). Каждая порция информации, существующая в базе данных, называется объектом. База данных информации для управления сетью содержит объекты, которые нужны менеджеру для управления сетью.

MIB выглядит как дерево с раздельными пунктами данных в качестве выходов. Идентификатор объекта однозначно идентифицирует MIB- объект в дереве. Объект обозначается, как последовательность чисел, разделенных точкой. Объекты организуются иерархически и их части могут принадлежать различным организациям. Верхний уровень идентификаторов MIB объектов установлен ISO/IEC. Объекты более низкого уровня выделяются специальными организациями. MIB дерево постоянно расширяется, как результат экспериментов частных разработок. Производители, например, могут определить свои личные ветви для включения образов своих продуктов. Такие деревья MIB не стандартизируются, а носят характер экспериментальных деревьев. Пример части такого дерева приведен на рисунке 6.2. Из этого рисунка

Рис. 6.2 ДеревоMIB

 

 

видно, что например для узла snmpV2 идентификатор объекта будет: 1.3.8.1.6

 

Протокол TELNET

Для обеспечения удаленного доступа к сетевому устройству с помощью командного интерпретатора используется протокол TELNET (RFC854). Протокол TELNET - это сетевой протокол типа "клиент- сервер". TELNET обеспечивает незащищенное соединение, т.е. все данные передаются в открытой форме в том числе и пароли. TEL­NET использует TCP в качестве транспортного протокола. Общепринято, что TELNET-сервер ожидает соединения на 23 порту. TELNET позволяет пользователю установить TCP-соединение с сервером и затем передавать коды нажатия клавиш так, как если бы работа проводилась на консоли сервера. Для входа в командный режим обычно нужна аутентификация - ввод имени пользователя и его пароля). TELNET предлагает три услуги:

• определяет сетевой виртуальный терминал (NVT - network virtual terminal), который обеспечивает стандартный интерфейс доступа к удаленной системе;

• включает механизм, который позволяет клиенту и серверу согласовать опции обмена;

• обеспечивает соединение, при котором любая программа (например FTP) может выступать в качестве клиента.

Протокол TELNET позволяет обслуживающей машине рассматривать все удаленные терминалы как стандартные "сетевые виртуальные терминалы" строчного типа, работающие в кодах ASCII, а также обеспечивает возможность согласования более сложных функций (например, локальный или удаленный эхо-контроль, страничный режим, высота и ширина экрана и т. д.). На прикладном уровне над протоколом TELNET находится либо программа поддержки реального терминала, либо прикладной процесс в обслуживающей машине, к которому осуществляется доступ с терминала. Формат NTV достаточно прост.

Для данных используются 7-битовые ASCII коды. А октеты из восьми бит зарезервированы для командных последовательностей. В упрощенном варианте протокол TELNET работает следующим образом: Между клиентом и сервером устанавливается TCP соединение. Клиент посылает серверу символ перевода строки для того, чтобы сервер знал что это клиент хочет соединится по TELNET.

В ответ сервер посылает приглашение ввода имени (например: login) и ждет ввода имени пользователя. После ввода сервер посылает приглашение ввода пароля (например: password) и ждет ввода пароля. Если введенные имя и пароль корректны то TEL- NET-сервер переходит в режим ввода. В этом режиме любой введенный текст пересылается удаленному сетевому устройству.

Ввод может производиться посимвольно или построчно. При посимвольном режиме каждый введенный символ пересылается немедленно, при построчном режиме отклик на каждое нажатие клавиши производится локально, а пересылка выполняется лишь при нажатии клавиши <Enter>. В режиме ввода TELNET-сервер выдает какое-либо приглашение (например: telnet>), и ожидает ввода команд пользователя. При вводе команды quit сервер разрывает соединение.

 

6.2. Лабораторная работа №5

 

Цель: на примере протоколов SNMPI и TELNET ознакомиться с уровнем приложений стека протоколов TCP/IP.

 

6.2.1 Порядок выполнения работы

1. На компьютере К1 запустить SNMP агента. Порт и имя группы доступа выбираются студентом;

2. С компьютера К2 отправить запрос(ы) get, и получить переменные П1, П2, П3. Сравнить полученные значения с реальными;

3. С компьютера К2 отправить запрос(ы) getnext для переменных П1, П2, П3. Объяснить полученные результаты;

4. На компьютере К1 с помощью диалога "Set TCP/IP Properties" изменить IP адрес, маску подсети и шлюз по умолчанию. С компьютера К2 с помощью запросов set вернуть К1 в исходное состояние. Проверить результаты посредством SNMP;

5. На компьютере К2 запустить TELNET сервер. Порт и пароль выбрать самостоятельно;

6. С компьютера К3 по протоколу TELNET подключиться к компьютеру К2. Удалить все значения из таблицы маршрутизации и ARP таблицы. Добавить в таблицу маршрутизации и ARP таблицу записи необходимые для корректной работы компьютера К2;

7. С помощью команды TELNET-сервера snmp запустить SNMP агента на К3. Проверить работоспособность snmp-сервера: с компьютера К2 попытаться получить значение SNMP переменной П2;

В отчет необходимо включить схему сети, все вводимые параметры (порт, имя группы доступа и др.), отправляемые запросы и получаемые ответы. Для протокола TELNET необходимо привести сообщения выводимые в TELNET-консоль.

 

Варианты заданий

Вариант 1. Файл со схемой сети lab1_var1.jfst.

Обозначения в задании: Компьютеры К1 - OFFICE2 pc1; К2 - Boss; К3 - Hacker. SNMP переменные П1 - Counter.InputIP; П2 - IP.AllInterfaces; П3 - IP.Address_Eth0.

Вариант 2. Файл со схемой сети lab1_var2.jfst.

Обозначения в задании: Компьютеры К1 - OFFICE1 pc4; К2 - BIG BOSS; К3 - M_CH_S. SNMP переменные П1 - Counter.OutputIP; П2 - IP.ARPTable; П3 - IP.SubnetMask_Eth0. Вариант 3. Файл со схемой сети lab1_var3.jfst.

Обозначения в задании: Компьютеры К1 - OFFICE2 pc2; К2 - Hacker; К3 - Boss. SNMP переменные П1 - Counter.ARP; П2 - IP.DefaultGateway;

П3 - SNMP.CommunityName.

Вариант 4. Файл со схемой сети lab1_var4.jfst.

Обозначения в задании: Компьютеры К1 - BIG BOSS; К2 - OFFICE1 pc1; К3 - OFFICE1 pc3. SNMP переменные П1 - Counter.InputTCP; П2 - IP.Address_Eth0; П3 - SNMP.revision.

Вариант 5. Файл со схемой сети lab1_var5.jfst.

Обозначения в задании: Компьютеры К1 - FileServer; К2 - Manager1; К3 - MegaBoss. SNMP переменные П1 - Counter.OutputTCP; П2 - IP.SubnetMask_Eth0; П3 - IP.DefaultGateway.

Вариант 6. Файл со схемой сети lab1_var6.jfst.

Обозначения в задании: Компьютеры К1 - PrintServer; К2 - Manager3; К3 - MicroBoss. SNMP переменные П1 - Counter.Recei