4. ПЛАН
1. Протоколы транспортного уровня TCP и UDP.
2. Порты.
3. Протокол UDP.
4. Фрагмент TCP-сегмента.
5. Логическое соединения-основа надёжности TCP.
6. Последовательный и подтвержденный номер.
7. Окно приёма.
8. Накопительный принцип квитирования.
9. Время ожидания квитанции.
10. Управление окном приема.
5. Рекомендуемая и использованная литература
1.В.Г.Олифер ,Н.А.Олифер Компьютерные сети СПБ.Питер 2017.
2.Таненбаум Э.Компьютерные сети Питер 2016.
3.Мансимов А.И.Основы информатики Баку 2018.
4.Мансимов А.И.Основы компьютерных сетей Баку 2017.
5.Mənsimov H.İ.Komputer səbəkələrinin əsaslari Baki 2019.
6.Бройдо В.П. Информационно-вычислительные сети.СПб, Питер,2010.
7.Истомин Е.П. Вычислительные системы, сети и телекоммуникации.СПб, Питер, 2017.
8.Кузин А.В.Компьютерные сети, Инфра-М.,2011.
9.Еленев Д.В.Компьютерные сети. Самара, Издательство СГАУ.
6. Как уже было отмечено, главная задача транспортного уровня заключается в
передаче данных между прикладными процессами. Эту задачу решают
протокол управления передачей (Transmission Control Protocol, TCP),
описанный в RFC 793, и протокол пользовательских дейтаграмм (User
Datagram Protocol, UDP), описанный в RFC 768.Протоколы TCP и UDP имеют
много общего.Тот и другой обеспечивают интерфейс с вышележащим
прикладным уровнем, передавая данные, поступающие на входной
интерфейс хоста, соответствующему приложению.При этом оба протокола
используют концепции порт и сокет. Они оба также поддерживают интерфейс
с нижележащим сетевым уровнем IP, упаковывая свои PDU в IP-
пакеты.Протокольные сущности TCP UDP, как и в случае протоколов
прикладного уровня, устанавливается только на конечных узлах. Однако, как
мы увидим далее, различий между TCP и UDP гораздо больше, чем сходств.
7. ПОРТЫ
Каждый компьютер может выполнять несколько процессов, более того,
прикладной процесс тоже может иметь несколько точек входа,
выступающих в качестве адреса назначения для пакета данных.Поэтому
после того, как пакет средствами протокола IP доставлен на сетевой
интерфейс компьютера-получателя, данные необходимо переправить
конкретному процессу-получателю.
8. Существует и обратная задача: пакеты, которые отправляют в сеть
разные приложения, работающие на одном конечном узле,
обрабатываются общим для них протоколом IP. Следовательно, в стеке
должно быть предусмотрено средство сбора пакетов от разных
приложений для передачи протоколу IP.Эту проблему выполняют
протоколы TCP и UDP.
9. Процедура приема данных протоколами TCP и UDP, поступающих от
нескольких различных прикладных служб, называется
мультиплексированием.Обратная процедура-процедура распределения
протоколами TCP и UDP поступающих от сетевого уровня пакетов между
набором высокоуровневых служб-называется
демультиплексированием(смотри слайд).
10.
11. Протоколы TCP UDP ведут для каждого приложения две очереди: очередь
пакетов, поступающих данному приложению из сети, и очередь пакетов,
отправляемых данным приложением в сеть.Пакеты, поступающие на
транспортный уровень, организуется операционной системой в виде множестве
очередей к точкам входа различных прикладных процессов. В терминологии
TCP/IP такие системные очереди называются портами, причем входная и
выходная очереди одного приложения рассматривается как один порт.Для
однозначной идентификации портов им присваивают номера.Номера портов
используется для адресации приложений.
12. Если процессы представляют собой популярные общедоступные службы, такие
как FTP, telnet, HTTP, TFTP, DNS и т. п., то за ним закрепляются стандартные,
назначенные номера, также называемые хорошо известными (well-known)
номерами портов.Эти номера закрепляются и публикуется в стандартах
Интернета(RFC 1700, RFC 3232).Так, номер 21 закреплен за службой
удаленного доступа к файлам FTP, а 23 – за службой удаленного управления
telnet.Назначенные номера являются уникальными в пределах Интернета и
назначаются приложениям централизованно из диапазона от 0 до 1023.
13. Для тех приложений, которые еще не стали столь распространенными, чтобы
закреплять за ними стандартные номера, номера портов назначаются
разработчиками этих приложений или операционной системой локально в ответ
на поступление запроса от приложения.На каждом компьютере операционная
система ведет список занятых и свободных номеров портов.При поступлении
запроса от приложения, выполняемого на данном компьютере, операционная
система выделяют ему первый свободный номер. Такие номера называют
динамическими.
14. В дальнейшем все сетевые приложения должны адресоваться к данному
приложению с указанием назначенного ему номера порта.После того как
приложение завершит работу, выделенный ему локальный номер порта
возвращается в список свободных и может быть назначен другому
приложению.Динамические номера является уникальными в пределах
каждого компьютера, но при этом обычной ситуацией является
совпадением номеров портов приложений, выполняемых на разных
компьютерах. Как правило, клиентские части известных приложений (DNS,
WWW, FTP, telnet и др.) получают динамические номера портов от ОС .
15. Все, что было сказано о портах, в равной степени относится к обоим
протоколом транспортного уровня (TCP и UDP).В принципе нет никакой
зависимости между назначением номеров для приложений, используемых
протоколов TCP, и приложений, работающих с протоколом UDP.Приложения,
которые передают данные на уровень IP по протоколу UDP, получают номера,
называемые UDP-портами.Аналогично приложениям, обращающимся к
протоколу TCP, выделяются TCP-порты.
В том и другом случаях это могут быть как назначенные, так и динамические
номера.Диапазоны чисел, из которых выделяется номера TCP- и UDP-портов,
совпадают: от 0 до 1023 для назначенных и от 1024 до 65535 для
динамических .Однако никакой связи между назначенными портами TCP и
UDP-портов нет.Даже если номера TCP и UDP-портов совпадают, они
идентифицируется разные приложения.
16. Например, одному приложению может быть назначен TCP-порт 1750, а
другому - UDP-порт 1750.В некоторых случаях, когда приложение может
обращаться по выбору протоколу TCP или UDP (например, таким
приложениям является DNS), ему , исходя из удобства запоминания,
назначаются совпадающие номера TCP и UDP-портов (в данном примере
– это номер 53).
17. ПРОТОКОЛ UDP
Протокол UDP, являясь дейтаграммным протоколом, реализует сервис по
возможности, то есть не гарантирует доставку своих сообщений, а,
следовательно, никоим образом не компенсирует надёжность дейтаграммного
протокола IP.
Единица данных протокола UDP называется UDP-дейтаграммой, или
пользовательской дейтаграммой.Каждая дейтаграмма переносит отдельное
пользовательское сообщение(смотри слайд).Это приводит к естественному
ограничению: длина дейтаграммы UDP не может превышать длины поля
данных протокола IP, которое, в свою очередь, ограничено размерам кадра
технологии нижнего уровня.Поэтому если UDP-буфер переполняется, то
данные приложения отбрасывается.
Заголовок UDP, состоящий из четырех 2-байтовых полей, содержит номера
портов отправителя и получателя, контрольную сумму и длину дейтаграммы.
18. Формирование дейтаграммы протокола UDP
Ниже приведен пример заголовка UDP с
заполненными полями:
Source Port =0*0035
Destination Port =0*0411
Total length =132 (0*84) bytes
Checksum = 0*5333
19. В этой UDP-дейтаграмме поле данных, длина которого, как следует из
заголовка, равна (132-8) байт, помешено сообщение DNS-сервера.Это
можно видеть по номеру порта источника (Source Port =0*0035), что в
шестнадцатеричном формате равно стандартному номеру DNS-сервера -
53.
20. Судя по простоте заголовка, протокол UDP очень сложным не
является.Действительно, его функции сводятся к мультиплексированию и
демультиплексированию данных между сетевым и прикладным уровнями.
21. Давайте рассмотрим, как протокол UDP решает задачу
демультиплексирования.Казалось бы, для этой цели достаточно использовать
номера портов.Кадры несущие UDP-дейтаграммы, пребывают на сетевой
интерфейс хоста, последовательно обрабатываются протоколами стека и,
наконец, поступают в распоряжение протокола UDP. UDP извлекает из
заголовка номер порта назначения и передает данные на соответствующий
порт соответствующему приложению, то есть выполняет
демультиплексирование.
22. Это решение выглядит очень логично и просто, однако оно неработоспособно в
ситуации, когда на одном конечном узле выполняется несколько копий одного и
того же приложения.Пусть, например, на одном хосте запущены два DNS-
сервера, причем оба используют для передачи своих сообщений протокол UDP
(смотри слайд).DNS-сервер имеет хорошо известный UDP-порт 53.В тоже
время у каждого из DNS-серверов могут быть свои клиенты, собственные базы
данных, собственные настройки.Когда на сетевой интерфейс данного
компьютера придет запрос от DNS-клиента, в UDP-дейтаграмме будет указан
номер порта 53, который в равной степени относится к обоим DNS-серверам –
так кому же из них протокол UDP должен передать запрос?Чтобы снять
неоднозначность, применяют следующий подход.Разным копиям одного
приложения, даже установленным на одном компьютере, присваивают разные
IP-адреса.В данном примере DNS-сервер1имеет IP-адрес IP1, DNS-сервер 2-
IP-адрес IP2.
23. Демультиплексирование протокола UDP на основе сокетов
Таким образом,
однозначно
определяет
прикладной
процесс в сети
пара,
называемая
UDP-cокетом.
Таким
образом,пр
-отокол
UDP
выполняет
демультипл
ексировани
е на основе
24. ФОРМАТ TCP-СЕГМЕНТА
Информация, поступающая к протоколу TCP от протоколов более
высокого уровня, рассматривается протоколом TCP как
неструктурированный поток байтов. Поступающие данные буферизуется
средствами TCP.Для передачи на сетевой уровень из буфера вырезается
некоторая непрерывная часть данных, которая называется сегментом и
снабжается заголовком (смотри слайд).
25. Формирование TCP-сегментов из потока байтов
Заголовок TCP-сегмента содержит значительно
больше полей, чем заголовок UDP, что отражает
более развитые возможности первого протокола:
ПОРТ ИСТОЧНИКА(sourc port)-занимает 2 байта и
идентифицирует процеcс-отправитель.
ПОРТ ПРИЕМНИКА(destination port)-занимает 2
байта и идентифицирует процесс-получатель.
ПОСЛЕДОВАТЕЛЬНЫЙ НОМЕР(sequence number)-
занимает 4 байта и представляет собой номер
байта, который определяет смещение сегмента
относительно потока отправляемых данных
(другими словами, номер первого байта данных в
сегменте).
26. ПОДТВЕРЖДЕННЫЙ НОМЕР (acknowledgement number)-занимает 4
байта и содержит максимальный номер байта в полученном сегменте,
увеличенный на единицу.Именно это значение используется в качестве
квитанции. Если установлен контрольный бит ACK, то это поле содержит
следующий номер очереди, который отправитель данного сегмента
желает получить в обратном направлении.
27. ДЛИНА ЗАГОЛОВКА (hlen)-занимает 4 бита и представляет собой длину
заголовка TCP-сегмента, измеренную в 32-битовых словах.Длина
заголовка не фиксирована и может изменяться в зависимости от
значений, устанавливаемых в поле параметров.
РЕЗЕРВ (reserved) –занимает 6 бит.
28. КОДОВЫЕ БИТЫ(code bits) числом 6 содержат служебную информацию о типе
данного сегмента.Положительное значение сигнализируется установкой этих
битов в единицу:
URG-срочное сообщение
ACK-квитанция на принятый сегмент
PSH-запрос на отправку сообщения без ожидания заполнения
буфера(протокол TCP может выжидать заполнения буфера перед отправкой
сегмента, но если требуется срочная передача, то приложение сообщает об
этом протоколу TCP с помощью данного бита )
RST-запрос на восстановление соединения
SYN-сообщение, используемое для синхронизации счетчиков переданных
данных при установлении соединения
FIN-признак достижения передающей стороной последнего байта в потоке
передаваемых данных
29. ОКНО (window)-занимает 2 байта и задает количество байтов данных,
ожидаемых отправителем данного сегмента, начиная с байта, номер которого
указан в поле подтвержденного номера.
КОНТРОЛЬНАЯ СУММА (checksum)-занимает 2 байта.
УКАЗАТЕЛЬ СРОЧНОСТИ (urgent pointer)-занимает 2 байта и указывает на
конец данных, которые необходимо срочно принять, несмотря на переполнение
буфера.Указатель срочности используется совместно с кодовым битом URG.То
есть если какие-то данные необходимо переслать приложению-получателю вне
очереди, то приложение-отправитель должно сообщить об этом протоколу TCP
путем установки в единицу бита URG.
ПАРАМЕТРЫ (options) имеют переменную длину и могут вообще
отсутствовать.Максимальная величина поле составляет 3 байта: оно
используется для решения вспомогательных задач, например для выбора
максимального размера сегмента.Поле параметров может располагаться в
конце заголовка TCP, его длина кратна 8 бит.
33. Логические соединения-основа надежности TCP
Основным отличием TCP от UDP является то, что на протокол TCP
возложена дополнительная задача-обеспечить надежную доставку
сообщений, используя в качестве основы ненадежный дейтаграммный
протокол IP.
34. На слайде показаны сети, соединенными маршрутизаторами, на которых
установлен протокол IP. Установленные на конечных узлах протокольные
модули TCP решают задачу обеспечения надежного обмена данными путем
установления между собой логических соединения.Благодаря логическому
соединению TCP следит, чтобы передаваемые сегменты не были потеряны, не
были продублированы и пришли получателю в том порядке, в которым были
отправлены.
При установлении логического соединения модули TCP договариваются между
собой о параметрах процедуры обмена данными.В протоколе TCP каждая
сторона соединения посылает противоположной стороне следующие
параметры:
Максимальный размер сегмента, который она готова принимать
Максимальный объем данных(возможно несколько сегментов), которые она
разрешает другой стороне передавать в свою сторону
35. Начальный порядковый номер байта, с которого она начинает отсчет потока
данных в рамках данного соединения.
В результате переговорного процесса модулей TCP тс двух сторон соединения
определяются параметры соединения.Один из них остаются постоянными в
течение всего сеанса связи, а другие адаптивно изменяются.В частности, в
зависимости от загрузки буфера принимающей стороны, а также надежности
работы сети динамически изменяется размер окна отправителя.Создание
соединения означает также выделение операционной системой на каждой
стороне соединения определенных системных ресурсов: для организации
буферов, таймеров, счетчиков.Эти ресурсы будут закреплены за соединением с
момента создания и до момента разрыва.
ЛОГИЧЕСКОЕ TCP – СОЕДИНЕНИЕ ОДНОЗНАЧНО ИДЕНТИФИЦИРУЕТСЯ
ПАРОЙ СОКЕТОВ.
37. Каждый сокет одновременно может участвовать в нескольких
соединениях. Так если (IP1, n1), (IP2, n2), (IP3, n3)-сокеты трех разных
приложений, где IP1, IP2, IP3-их IP-адреса, а n1, n2, n3-номера их TCP-
портов, то возможно образование следующих соединений:
38. Соединение 1-(IP2, n2),(IP1, n1)
Соединение 2-(IP1, n1),(IP3, n3)
Соединение 3-(IP2, n2),(IP3, n3).
На слайде показаны соединения 1 и 3,
образованные сокетом (IP2, n2).
40. А теперь рассмотрим на примере, как протокол TCP выполняет
демультиплексирование.Пусть некий поставщик услуг оказывает услугу по
веб-хостингу, то есть на его компьютере клиенты могут устанавливать свои
веб-серверы.Веб-сервер основан на протоколе прикладного уровня HTTP,
который, в свою очередь, использует протокол TCP.TCP ожидает запросы от
веб-клиентов(браузеров), прослушивая хорошо известный порт 80.
41. На слайде показан вариант хостинга с двумя веб-серверами – сервером www1,
model.ru, имеющим IP-адрес IP1, и сервером www2.tour.ru с адресом
IP2.Каждому из них может обращаться множество клиентов, причем клиенты
могут одновременно работать как сервером WWW1, так и с сервером
WWW2.Работа каждого клиента требует сохранения прочитанных страниц,
параметров и настроек сеанса связи, то есть образования отдельного
логического соединения.
ТАКОЕ СОЕДИНЕНИЕ СОЗДАЕТСЯ ПРОТОКОЛОМ TCP ДЛЯ КАЖДОЙ ПАРЫ
КЛИЕНТ-СЕРВЕР.
42. На рисунке показаны два браузера, имеющие соответственно сокеты (IPk, nk) и
(IPm, nm).Пользователь браузера К обращается одновременно к серверам
WWW1 и WWW2.Наличие отдельных соединений для работы с каждым из этих
серверов гарантирует разделение информационных потоков- у пользователя
никогда не возникает вопроса, каким сервером ему была послана та или иная
страница. Одновременно с пользователем браузера К с сервером WWW2
работает пользователь m. И в этом случае отдельные логические соединения, в
рамках которых идет работа обоих пользователей, позволяют изолировать их
информационные потоки.На рисунке показаны буферы, количество которых
определяется не числом веб-серверов и не числом клиентов, а числом
логических соединений.Сообщения в эти буферы направляются в зависимости
от значений сокетов как отправителя так и получателя.
ТАКИМ ОБРАЗОМ, ПРОТОКОЛ ТСР ОСУЩЕСТВЛЯЕТ
ДЕМУЛЬТИПЛЕКСИРОВАНИЕ НА ОСНОВЕ СОЕДИНЕНИЙ.
44. ПОСЛЕДОВАТЕЛЬНЫЙ И ПОДТВЕРЖДЕННЫЙ НОМЕР
В рамках установленного соединения в протоколе ТСР правильность передачи
каждого сегмента должна подтверждаться квитанцией от
получателя.Квитирование- это один из традиционных методов обеспечения
надежной связи .В протоколе ТСР используется частный случай квитирования-
алгоритм скользящего окно.
Алгоритм скользящего окна в протоколе ТСР имеет особенность.Хотя единицей
передаваемых данных является сегмент, окно определено на множестве
нумерованных байтов неструктурированного потока данных, поступающих с
верхнего уровня и буферизуемых протоколом ТСР.
При установлении соединения обе стороны договариваются о начальном
номера байта, с которого будет вестись отсчет в течение всего данного
соединения.У каждой стороны свой начальный номер.Идентификатор каждого
сегмента является номер его первого байта.Нумерация байтов в пределах
сегмента осуществляется так, что первый байт данных сразу вслед за
заголовком имеет наименьший номер, а следующие за ним порядковые
57. Пограничный (внешний) шлюзовой протокол (Border Gateway Protocol, BGP) версии 4 является сегодня
основным протоколом обмена маршрутной информацией между автономными системами Интернета.
Протокол BGP пришел на смену протоколу EGP1, использовавшемуся в тот начальный период, когда
Интернет имел единственную магистраль. Эта магистраль являлась центральной автономной системой, к
которой присоединялись в соответствии с древовидной топологией все остальные автономные системы. Так
как между автономными системами при такой структуре петли исключались, протокол EGP не предпринимал
никаких мер для того, чтобы исключить зацикливание маршрутов.
58. В каждой из трех автономных систем (AS 1021, AS 363 и AS 520) имеется несколько маршрутизаторов,
исполняющих роль внешних шлюзов. На каждом из них работает протокол BGP, с помощью которого они
общаются между собой.
Маршрутизатор взаимодействует с другими маршрутизаторами по протоколу BGP только в том случае,
если администратор явно указывает при конфигурировании, что эти маршрутизаторы являются его
соседями. Например, маршрутизатор EG1 в рассматриваемом примере будет взаимодействовать по
протоколу BGP с маршрутизатором EG2 не потому, что эти маршрутизаторы соединены двухточечным
каналом, а потому, что при конфигурировании маршрутизатора EG1 в качестве соседа ему был указан
маршрутизатор EG2 (с адресом 194.200.30.2). Аналогично, при конфигурировании маршрутизатора EG2 его
соседом был назначен маршрутизатор EG1 (с адресом 194.200.30.1).
59. Такой способ взаимодействия удобен в ситуации, когда маршрутизаторы, обменивающиеся маршрутной
информацией, принадлежат разным поставщикам услуг (ISP). Администратор ISP может решать, с какими
автономными системами он будет обмениваться трафиком, а с какими нет, задавая список соседей для своих
внешних шлюзов. Протоколы RIP и QSPF, разработанные для применения внутри автономной системы,
обмениваются маршрутной информацией со всеми маршрутизаторами, находящимися в пределах их
непосредственной досягаемости (по локальной сети или через двухточечный канал). Это означает, что
информация обо всех сетях появляется в таблице маршрутизации каждого маршрутизатора, так что каждая
сеть оказывается достижимой для каждой. В корпоративной сети это нормальная ситуация, а в сетях ISP нет,
поэтому протокол BGP и исполняет здесь особую роль.
60. ля установления сеанса с указанными соседями BGP-
маршрутизаторы используют протокол TCP (порт 179).
При установлении BGP-сеанса могут применяться
разнообразные способы аутентификации
маршрутизаторов, повышающие безопасность работы
автономных систем.
Основным сообщением протокола BGP является
сообщение UPDATE (обновить), с помощью которого
маршрутизатор сообщает маршрутизатору соседней
автономной системы о достижимости сетей,
относящихся к его собственной автономной системе.
Само название этого сообщения говорит о том, что это
— триггерное объявление, которое посылается соседу
только тогда, когда в автономной системе что-нибудь
резко меняется: появляются новые сети или новые
пути к сетям либо же, напротив, исчезают
существовавшие сети или пути.
61. В одном сообщении UPDATE можно объявить об
одном новом маршруте или аннулировать несколько
маршрутов, переставших существовать. Под
маршрутом в BGP понимается последовательность
автономных систем, которую нужно пройти на пути к
указанной в адресе сети. Более формально
информация о маршруте (BGP Route) к сети (Network/
Maskjength) выглядит так:
BGP Route = AS_Path; NextHop; Network/Maskjength;
Здесь AS_Palh — набор номеров автономных систем,
NextHop — IP-адрес маршрутизатора, через который
нужно передавать пакеты в сеть Network/Maskjength.
Например, если маршрутизатор EG1 хочет объявить
маршрутизатору EG2 о том, что в AS 1021 появилась
новая сеть 202.100.5.0/24, то он формирует такое
сообщение:
62. S 1021; 194.200.30.1; 202.100.5.0/24,
после чего передает его маршрутизатору EG2
автономной системы AS 363 (с которым у него,
конечно, должен быть установлен BGP-сеанс).
Маршрутизатор EG2, получив сообщение UPDATE,
запоминает в своей таблице маршрутизации
информацию о сети 202.100.5.0/24 вместе с адресом
следующего маршрутизатора 194.200.30.1 и отметкой
о том, что эта информация была получена по
протоколу BGP. Маршрутизатор EG2 обменивается
маршрутной информацией с внутренними шлюзами
системы AS 363 по какому-либо протоколу группы IGP,
например OSPF. Если у EG2 установлен режим
перераспределения маршрутов BGP в маршруты
OSPF, то все внутренние шлюзы AS 363 узнают о
существовании сети 202.100.5.0/24 с помощью
объявления OSPF, которое будет внешним. В качестве
адреса следующего маршрутизатора маршрутизатор
EG2 начнет теперь объявлять адрес собственного
внутреннего интерфейса, например 192.17.100.2.
63. Однако для распространения сообщения о сети
202.100.5.0/24 в другие автономные системы,
например в AS 520, протокол OSPF использоваться не
может. Маршрутизатор EG3, связанный с
маршрутизатором EG4 автономной системы 520,
должен пользоваться протоколом BGP, генерируя
сообщение UPDATE нужного формата. Для решения
этой задачи он не может задействовать информацию о
сети 202.100.5.0/24, полученную от протокола OSPF
через один из своих внутренних интерфейсов, так как
она имеет другой формат и не содержит, например,
сведений о номере автономной системы, в которой
находится эта сеть.
64. Проблема решается за счет того, что маршрутизаторы
EG2 и EG3 также устанавливают между собой BGP-
сеанс, хотя они и принадлежат одной и той же
автономной системе. Такая реализация протокола
BGP называется внутренней (Interior BGP, iBGP), в
отличие от основной, внешней (Exterior BGP, eBGP). В
результате маршрутизатор EG3 получает нужную
информацию от маршрутизатора EG2 и передает ее
внешнему соседу — маршрутизатору EG4. При
формировании нового сообщения UPDATE
маршрутизатор EG3 трансформирует сообщение,
полученное от маршрутизатора EG2, добавляя в
список автономных систем собственную автономную
систему AS 520, а полученный адрес следующего
маршрутизатора заменяет адресом собственного
интерфейса:
65. AS 363, AS 1021; 132.15.64.3; 202.100.5.0/24.
Номера автономных систем позволяют исключать
зацикливание сообщений UPDATE. Например, когда
маршрутизатор EG5 передаст сообщение о сети
202.100.5.0/24 маршрутизатору EG6, то последний не
будет его использовать, так как оно будет иметь вид:
AS 520, AS 363, AS 1021; 201.14.110.3; 202.100.5.0/24.
Так как в списке автономных систем уже есть номер
собственной автономной системы, очевидно, что
сообщение зациклилось.
66. Протокол BGP используется сегодня не только для
обмена маршрутной информацией между
автономными системами, но и внутри них.
