Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь FAQ Написать работу КАТЕГОРИИ: АрхеологияБиология Генетика География Информатика История Логика Маркетинг Математика Менеджмент Механика Педагогика Религия Социология Технологии Физика Философия Финансы Химия Экология ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Внутренние и внешние шлюзовые протоколыСодержание книги
Поиск на нашем сайте
Такое решение было найдено для самой крупной на сегодня составной сети — Интернета. Это решение базируется на понятии автономной системы. Автономная система (Autonomous System, AS) — это совокупность сетей под единым административным управлением, обеспечивающим общую для всех входящих в автономную систему маршрутизаторов политику маршрутизации. Обычно автономной системой управляет один поставщик услуг Интернета, самостоятельно выбирая, какие протоколы маршрутизации должны использоваться в некоторой автономной системе и каким образом между ними должно выполняться перераспределение маршрутной информации. Крупные поставщики услуг и корпорации могут представить свою составную сеть как набор нескольких автономных систем. Регистрация автономных систем происходит централизованно, как и регистрация IP-адресов и DNS-имен. Номер автономной системы состоит из 16 разрядов и никак не связан с префиксами IP-адресов входящих в нее сетей. В соответствии с этой концепцией Интернет выглядит как набор взаимосвязанных автономных систем, каждая из которых состоит из взаимосвязанных сетей (рис. 17.20), соединенными внешними шлюзами. Рис. 17.20. Автономные системы Интернета
Основная цель деления Интернета на автономные системы — обеспечение многоуровневого подхода к маршрутизации. До введения автономных систем предполагался двухуровневый подход, то есть сначала маршрут определялся как последовательность сетей, а затем вел непосредственно к заданному узлу в конечной сети (именно этот подход мы использовали до сих пор). С появлением автономных систем появляется третий, верхний, уровень маршрутизации — теперь сначала маршрут определяется как последовательность автономных систем, затем — как последовательность сетей и только потом ведет к конечному узлу. Выбор маршрута между автономными системами осуществляют внешние шлюзы, использующие особый тип протокола маршрутизации, так называемый внешний шлюзовой протокол (Exterior Gateway Protocol, EGP). В настоящее время для работы в такой роли сообщество Интернета утвердило стандартный пограничный шлюзовой протокол версии 4 (Border Gateway Protocol, BGPv4). В качестве адреса следующего маршрутизатора в протоколе BGPv4 указывается адрес точки входа в соседнюю автономную систему За маршрут внутри автономной системы отвечают внутренние шлюзовые протоколы (Interior Gateway Protocol, IGP). К числу IGP относятся знакомые нам протоколы RIP, OSPF и IS-IS. В случае транзитной автономной системы эти протоколы указывают точную последовательность маршрутизаторов от точки входа в автономную систему до точки выхода из нее. ПРИМЕЧАНИЕ Внутри каждой автономной системы может применяться любой из существующих протоколов маршрутизации, в то время как между автономными системами всегда применяется один и тот же протокол, являющийся своеобразным языком «эсперанто», на котором автономные системы общаются между собой. Концепция автономных систем скрывает от администраторов магистрали Интернета проблемы маршрутизации пакетов на более низком уровне — уровне сетей. Для администратора магистрали неважно, какие протоколы маршрутизации применяются внутри автономных систем, для него существует единственный протокол маршрутизации — BGPv4. Протокол BGP Пограничный (внешний) шлюзовой протокол (Border Gateway Protocol, BGP) версии 4 является сегодня основным протоколом обмена маршрутной информацией между автономными системами Интернета. Протокол BGP пришел на смену протоколу EGP[55], использовавшемуся в тот начальный период, когда Интернет имел единственную магистраль. Эта магистраль являлась центральной автономной системой, к которой присоединялись в соответствии с древовидной топологией все остальные автономные системы. Так как между автономными системами при такой структуре петли исключались, протокол EGP не предпринимал никаких мер для того, чтобы исключить зацикливание маршрутов. BGPv4 успешно работает при любой топологии связей между автономными системами, что соответствует современному состоянию Интернета. Поясним основные принципы работы BGP на примере (рис. 17.21). Рис. 17.21. Поиск маршрута между автономными системами с помощью протокола BGP
В каждой из трех автономных систем (AS 1021, AS 363 и AS 520) имеется несколько маршрутизаторов, исполняющих роль внешних шлюзов. На каждом из них работает протокол BGP, с помощью которого они общаются между собой. Маршрутизатор взаимодействует с другими маршрутизаторами по протоколу BGP только в том случае, если администратор явно указывает при конфигурировании, что эти маршрутизаторы являются его соседями. Например, маршрутизатор EG1 в рассматриваемом примере будет взаимодействовать по протоколу BGP с маршрутизатором EG2 не потому, что эти маршрутизаторы соединены двухточечным каналом, а потому, что при конфигурировании маршрутизатора EG1 в качестве соседа ему был указан маршрутизатор EG2 (с адресом 194.200.30.2). Аналогично, при конфигурировании маршрутизатора EG2 его соседом был назначен маршрутизатор EG1 (с адресом 194.200.30.1). Такой способ взаимодействия удобен в ситуации, когда маршрутизаторы, обменивающиеся маршрутной информацией, принадлежат разным поставщикам услуг (ISP). Администратор ISP может решать, с какими автономными системами он будет обмениваться трафиком, а с какими нет, задавая список соседей для своих внешних шлюзов. Протоколы RIP и OSPF, разработанные для применения внутри автономной системы, обмениваются маршрутной информацией со всеми маршрутизаторами, находящимися в пределах их непосредственной досягаемости (по локальной сети или через двухточечный канал). Это означает, что информация обо всех сетях появляется в таблице маршрутизации каждого маршрутизатора, так что каждая сеть оказывается достижимой для каждой. В корпоративной сети это нормальная ситуация, а в сетях ISP нет, поэтому протокол BGP и исполняет здесь особую роль. Для установления сеанса с указанными соседями BGP-маршрутизаторы используют протокол TCP (порт 179). При установлении BGP-сеанса могут применяться разнообразные способы аутентификации маршрутизаторов, повышающие безопасность работы автономных систем. Основным сообщением протокола BGP является сообщение UPDATE (обновить), с помощью которого маршрутизатор сообщает маршрутизатору соседней автономной системы о достижимости сетей, относящихся к его собственной автономной системе. Само название этого сообщения говорит о том, что это — триггерное объявление, которое посылается соседу только тогда, когда в автономной системе что-нибудь резко меняется: появляются новые сети или новые пути к сетям либо же, напротив, исчезают существовавшие сети или пути. В одном сообщении UPDATE можно объявить об одном новом маршруте или аннулировать несколько маршрутов, переставших существовать. Под маршрутом в BGP понимается последовательность автономных систем, которую нужно пройти на пути к указанной в адресе сети. Более формально информация о маршруте (BGP Route) к сети (Network/ Mask length) выглядит так: BGP Route = AS_Path; NextHop; Network/Mask_length; Здесь AS_Path — набор номеров автономных систем, NextHop — IP-адрес маршрутизатора, через который нужно передавать пакеты в сеть Network/Mask_length. Например, если маршрутизатор EG1 хочет объявить маршрутизатору EG2 о том, что в AS 1021 появилась новая сеть 202.100.5.0/24, то он формирует такое сообщение: AS 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. Однако для распространения сообщения о сети 202.100.5.0/24 в другие автономные системы, например в AS 520, протокол OSPF использоваться не может. Маршрутизатор EG3, связанный с маршрутизатором EG4 автономной системы 520, должен пользоваться протоколом BGP, генерируя сообщение UPDATE нужного формата. Для решения этой задачи он не может задействовать информацию о сети 202.100.5.0/24, полученную от протокола OSPF через один из своих внутренних интерфейсов, так как она имеет другой формат и не содержит, например, сведений о номере автономной системы, в которой находится эта сеть. Проблема решается за счет того, что маршрутизаторы EG2 и EG3 также устанавливают между собой BGP-сеанс, хотя они и принадлежат одной и той же автономной системе. Такая реализация протокола BGP называется внутренней (Interior BGP, iBGP), в отличие от основной, внешней (Exterior BGP, eBGP). В результате маршрутизатор EG3 получает нужную информацию от маршрутизатора EG2 и передает ее внешнему соседу — маршрутизатору EG4. При формировании нового сообщения UPDATE маршрутизатор EG3 трансформирует сообщение, полученное от маршрутизатора EG2, добавляя в список автономных систем собственную автономную систему AS 520, а полученный адрес следующего маршрутизатора заменяет адресом собственного интерфейса: 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. Так как в списке автономных систем уже есть номер собственной автономной системы, очевидно, что сообщение зациклилось. Протокол BGP используется сегодня не только для обмена маршрутной информацией между автономными системами, но и внутри них. Протокол ICMP Протокол межсетевых управляющих сообщений (internet Control Message Protocol, ICMP) (RFC;792) является вспомогательным протоколом, использующимся для диагностики и мониторинга сети. Можно представить ряд ситуаций, когда протокол IP не может доставить пакет адресату, например истекает время жизни пакета, в таблице маршрутизации отсутствует маршрут к заданному в пакете адресу назначения, пакет не проходит проверку по контрольной сумме, шлюз не имеет достаточно места в своем буфере для передачи какого-либо пакета и т. д., и т. п. Как мы не раз отмечали, протокол IP доставляет данные, руководствуясь принципом «по возможности», то есть не предпринимает мер для гарантированной передачи данных адресату. Это свойство «необязательности» протокола IP компенсируется протоколами более высоких уровней стека TCP/IP, например TCP на транспортном уровне и в какой-то степени DNS на прикладном уровне. Они берут на себя обязанности по обеспечению надежности, применяя такие известные приемы, как нумерация сообщений, подтверждение доставки, повторная посылка данных. Протокол ICMP также служит дополнением, компенсирующим ненадежность протокола IP, но несколько другого рода. Он не предназначен для исправления возникших при передаче пакета проблем: если пакет потерян, ICMP не может послать его заново. Задача ICMP другая — он является средством оповещения отправителя о «несчастных случаях», произошедших с его пакетами. Пусть, например, протокол IP, работающий на каком-либо маршрутизаторе, обнаружил, что пакет для дальнейшей передачи по маршруту необходимо фрагментировать, но в пакете установлен признак DF (не фрагментировать). Протокол IP, обнаруживший, что он не может передать IP-пакет далее по сети, прежде чем отбросить пакет, должен отправить диагностическое ICMP-сообщение конечному узлу-источнику. Для передачи по сети ICMP-сообщение инкапсулируется в поле данных IP-пакета. IP- адрес узла-источника определяется из заголовка пакета, вызвавшего инцидент. Сообщение, прибывшее в узел-источник, может быть обработано там либо ядром операционной системы, либо протоколами транспортного и прикладного уровней, либо приложениями, либо просто проигнорированы. Важно, что обработка ICMP-сообщений не входит в обязанности протоколов IP и ICMP. Заметим, что некоторые из пакетов могут исчезнуть в сети, не вызвав при этом никаких оповещений. В частности, протокол ICMP не предусматривает передачу сообщений о проблемах, возникающих при обработке IP-пакетов, несущих ICMP-сообщения об ошибках. Такое решение было принято разработчиками протокола, чтобы не порождать «штормы» в сетях, когда количество сообщений об ошибках лавинообразно возрастает. Особенностью протокола ICMP является функциональное разнообразие решаемых задач, а следовательно, и связанных с этим сообщений. Все типы сообщений имеют один и тот же формат (рис. 17.22), однако интерпретация полей существенно зависит от того, к какому типу относится сообщение. Рис. 17.22. Формат ICMP-сообщения
Заголовок ICMP-сообщения состоит из 8 байт: § тип (1 байт) — числовой идентификатор типа сообщения; § код (1 байт) — числовой идентификатор, более тонко дифференцирующий тип ошибки; § контрольная сумма (2 байта) — подсчитывается для всего ICMP-сообщения. Содержимое оставшихся четырех байтов в заголовке и поле данных зависит от значений полей типа и кода. На рис. 17.23 показана таблица основных типов ICMP-сообщений. Эти сообщения можно разделить на две группы (помеченные на рисунке условными символами): § сообщения об ошибках, § сообщения запрос-ответ. Сообщения типа запрос-ответ связаны в пары: эхо-запрос — эхо-ответ, запрос маски - ответ маски, запрос времени — ответ времени. Отправитель сообщения-запроса всегда рассчитывает на получение соответствующего сообщения-ответа. Рис. 17.23. Типы и коды ICMP-сообщений
Сообщения, относящиеся к группе сообщений об ошибках, конкретизируются уточняющим кодом. На рисунке показан фрагмент таблицы кодов для сообщения об ошибке недостижимости узла назначения, имеющей тип 3. Из таблицы мы видим, что это сообщение может быть вызвано различными причинами, такими как неверный адрес сети или узла (код О или 1), отсутствием на конечном узле-адресате необходимого протокола прикладного уровня (код 2 — «протокол недостижим») или открытого порта UDP/TCP (код 3 — «порт недостижим»). Узел (или сеть) назначения может быть также недостижим по причине временной неработоспособности аппаратуры или из-за того, что маршрутизатор не имеет данных о пути к сети назначения. Всего таблица содержит 15 кодов. Аналогичные таблицы кодов существуют и для других типов сообщений об ошибках. Утилита traceroute В качестве примера рассмотрим использование сообщений об ошибках в популярной утилите мониторинга сети traceroute. Когда маршрутизатор не может передать или доставить IP-пакет, он отсылает узлу, отправившему этот пакет, сообщение о недостижимости узла назначения. Формат этого сообщения показан на рис. 17.24. В поле типа помещается значение 3, а в поле кода — значение из диапазона 0-15, уточняющее причину, по которой пакет не был доставлен. Следующие за полем контрольной суммы четыре байта заголовка не используются и заполняются нулями. Рис. 17.24. Формат ICMP-сообщения об ошибке недостижимости узла назначения
Помимо причины ошибки, указанной в заголовке (в полях типа и кода), дополнительная диагностическая информация передается в поле данных ICMP-сообщения. Именно туда помещается заголовок IP и первые 8 байт данных того IP-пакета, который вызвал ошибку. Эта информация позволяет узлу-отправителю еще точнее диагностировать причину ошибки. Это возможно, так как все протоколы стека TCP/IP использующие для передачи своих сообщений IP-пакеты, помещают наиболее важную для анализа информацию в первые 8 байт своих сообщений. В частности, ими вполне могут оказаться первые 8 байт заголовка TCP или UDP, в которых содержится информация (номер порта), идентифицирующая приложение, пославшее потерянный пакет. Следовательно, при разработке приложения можно предусмотреть встроенные средства реакции на сообщения о недоставленных пакетах. ICMP-сообщения об ошибках лежат в основе работы популярной утилиты traceroute для Unix, имеющей в Windows название tracert. Эта утилита позволяет проследить маршрут до удаленного хоста, определить среднее время оборота (RTT), IP-адрес и в некоторых случаях доменное имя каждого промежуточного маршрутизатора. Такая информация помогает найти маршрутизатор, на котором обрывается путь пакета к удаленному хосту. Утилита traceroute осуществляет трассировку маршрута, посылая серию обычных IP- пакетов в конечную точку изучаемого маршрута. Идея метода состоит в следующем. Значение времени жизни (TTL) первого отправляемого пакета устанавливается равным 1. Когда протокол IP первого маршрутизатора принимает этот пакет, то он в соответствии со своим алгоритмом уменьшает значение TTL на 1 и получает 0. Маршрутизатор отбрасывает пакет с нулевым временем жизни и возвращает узлу-источнику ICMP-сообщение об ошибке истечения времени дейтаграммы (значение поля типа равно 11) вместе с заголовком IP и первыми 8 байтами потерянного пакета. Получив ICMP-сообщение о причине недоставки пакета, утилита traceroute запоминает адрес первого маршрутизатора (который извлекает из заголовка IP-пакета, несущего ICMP-сообщение). Затем traceroute посылает следующий IP-пакет, но теперь со значением TTL, равным 2. Этот пакет благополучно проходит первый маршрутизатор, но «умирает» на втором, о чем немедленно отправляется аналогичное ICMP-сообщение об ошибке истечения времени дейтаграммы. Утилита traceroute запоминает адрес второго маршрутизатора и т. д. Такие действия выполняются с каждым маршрутизатором вдоль маршрута вплоть до узла назначения или неисправного маршрутизатора. Мы рассматриваем работу утилиты traceroute весьма схематично, но и этого достаточно, чтобы оценить изящество идеи, лежащей в основе ее работы. Остальные ICMP-сообщения об ошибках имеют такой же формат и отличаются друг от друга только значениями полей типа и кода. Далее приведена копия экранной формы, выведенной утилитой tracert (Windows) при трассировке хоста ds.internic.net [198.49.45.29]: 1. 311 ms 290 ms 261 ms 144.206.192.100 2. 281 ms 300 ms 271 ms 194.85.73.5 3. 2023 ms 290 ms 311 ms moscow-m9-2-S5.relcom.eu.net [193.124.254.37] 4. 290 ms 261 ms 280 ms MSK-M9-13.Relcom.EU.net [193.125.15.13] 5. 270 ms 281 ms 290 ms MSK.RAIL-l-ATM0-155Mb.Relcom.EU.net [193.124.254.82] 6. 300 ms 311 ms 290 ms SPB-RASC0M-l-E3-l-34Mb.Relcom.EU.net [193.124.254.78] 7. 311 ms 300 ms 300 ms Hssill-0.GW1.STK2.ALTER.NET [146.188.33.125] 8. 311 ms 330 ms 291 ms 421.ATM6-0-0.CR2.STK2.A1ter.Net [146.188.5.73] 9. 360 ms |331 ms 330 ms 219.Hssi4-0.CR2.LN01.A1ter.Net [146.188.2.213] 10. 351 ms 330 ms 331 ms 412.Atm5-0.BRl.LNDl.Alter.net [146.188.3.205] 11. 420 ms 461 ms 420 ms 167.ATM8-0-0.CR1.ATL1.A1ter.Net [137.39.69.182] 12. 461 ms 441 ms 440 ms 311.ATM12-0-0.BR1.ATL1.A1ter.Net [137.39.21.73] 13. 451 ms 410 ms 431 ms atlantal-brl.bbnplanet.net [4.0.2.141] 14. 420 ms 411 ms 410 ms viennal-br2.bbnp1anet.net [4.0.3.154] 15. 411 ms 430 ms 2514 ms viennal-nbr3.bbnplanet.net [4.0.3.150] 16. 430 ms 421 ms 441 ms viennal-nbr2.bbnplanet.net [4.0.5.45] 17. 431 ms 451 ms 420 ms cambridgel-brl.bbnplanet.net [4.0.5.42] 18. 450 ms 461 ms 441 M С cambridgel-crl4.bbnplanet.net [4.0.3.94] 19. 451 M С 461 M С 460 M С attbcstoll.bbnplanet.net [206.34.99.38] 20. 501 M С 460 M С 481 M С shutdown.ds.internic.net [198.49.45.29] Последовательность строк соответствует последовательности маршрутизаторов, образующих маршрут к заданному узлу Первое число в строке — число хопов до соответствующего маршрутизатора. Утилита traceroute тестирует каждый маршрутизатор трижды, поэтому следующие три числа в строке — это значения RTT, вычисленные путем посылки трех пакетов, время жизни которых истекло на этом маршрутизаторе. Если ответ от какого-либо маршрутизатора не приходит за заданное время, то вместо времени на экране печатается звездочка (*). Далее идут IP-адрес и доменное имя (если оно имеется) маршрутизатора. Видно, что почти все интерфейсы маршрутизаторов поставщиков услуг Интернета зарегистрированы в службе DNS, а первые два, относящиеся к локальным маршрутизаторам, — нет. Еще раз подчеркнем, что время, указанное в каждой строке, это не время прохождения пакетов между двумя соседними маршрутизаторами, а время, за которое пакет проделывает путь от источника до соответствующего маршрутизатора и обратно. Так как ситуация в Интернете с загрузкой маршрутизаторов постоянно меняется, то время достижимости маршрутизаторов не всегда нарастает монотонно, а может изменяться достаточно произвольным образом. Утилита ping А сейчас давайте рассмотрим представителей другой группы ICMP-сообщений — эхо- запросы и эхо-ответы и поговорим об использовании этих сообщений в известной утилите ping. Эхо-запрос и эхо-ответ, в совокупности называемые эхо-протоколом, представляют собой очень простое средство мониторинга сети. Компьютер или маршрутизатор посылает по составной сети ICMP-сообщение эхо-запроса, указывая в нем IP-адрес узла, достижимость которого нужно проверить. Узел, получивший эхо-запрос, формирует и отправляет эхо-ответ отправителю запроса. Так как эхо-запрос и эхо-ответ передаются по сети внутри IP-пакетов, то их успешная доставка означает нормальное функционирование всей транспортной системы составной сети. Формат эхо-запроса и эхо-ответа показан на рис. 17.25. Поле типа для эхо-ответа равно 0, для эхо-запроса — 8; поле кода всегда равно 0 и для запроса, и для ответа. В байтах 5 и 6 заголовка содержится идентификатор запроса, в байтах 7 и 8 — порядковый номер. В поле данных эхо-запроса может быть помещена произвольная информация, которая в соответствии с данным протоколом должна быть скопирована в поле данных эхо-ответа. Рис. 17.25. Формат ICMP-сообщений типа эхо-запрос и эхо-ответ
Поля идентификатора запроса и порядкового номера используются одинаковым образом всеми сообщениями типа запрос-ответ. Посылая запрос, приложение помещает в эти два поля информацию, которая предназначена для последующего встраивания ее в соответствующий ответ. Сообщение-ответ копирует значения этих полей в свои поля того же назначения. Когда ответ возвращается в пункт отправки сообщения-запроса, то на основании идентификатора он может «найти и опознать» приложение, пославшее запрос. А порядковый номер используется приложением, чтобы связать полученный ответ с соответствующим запросом (учитывая, что одно приложение может выдать несколько однотипных запросов). Утилита ping обычно посылает серию эхо-запросов к тестируемому узлу и предоставляет пользователю статистику об утерянных эхо-ответах и среднем времени реакции сети на запросы. Утилита ping выводит на экран сообщения следующего вида обо всех поступивших ответах: # ping serverl.citmgu.ru Pinging serverl.citmgu.ru [193.107.2.200] with 64 bytes of data: Reply from 193.107.2.200: bytes=64 time=256ms TTL= 123 Reply from 193.107.2.200: bytes=64 time=310ms TTL- 123 Reply from 193.107.2.200: bytes=64 time=260ms TTL- 123 Reply from 193.107.2.200: bytes=64 time=146ms TTL- 123 Из приведенной распечатки видно, что в ответ на тестирующие запросы, посланные узлу server1.mgu.ru, было получено 4 эхо-ответа. Длина каждого сообщения составляет 64 байта. В следующей колонке помещены значения времени оборота (RTT), то есть времени от момента отправки запроса до получения ответа на этот запрос. Как видим, сеть работает достаточно нестабильно — время в последней строке отличается от времени во второй более чем в два раза. На экран выводится также оставшееся время жизни поступивших пакетов. Выводы В то время как задачей протокола IP является передана данных между сетевыми интерфейсами в составной сети, основная задана протоколов TCP и UDP заключается в передаче данных между прикладными процессами, выполняющимися на разных конечных узлах сети. Протокол UDP является дейтаграммным протоколом, работающим без установления логического соединения, он не гарантирует доставку своих сообщений, а следовательно, не компенсирует ненадежность дейтаграммного протокола IP. Системные очереди к точкам входа прикладных процессов называют портами. Порты идентифицируются номерами и однозначно определяют приложение в пределах компьютера. Если процессы представляют собой популярные общедоступные службы, такие как FTP, telnet, HTTP TFTP, DNS и т. п., то за ними централизовано закрепляются стандартные (назначенные) номера. TCP решает задачу надежного обмена данными путем установления логических соединений. Соединение однозначно идентифицируется парой сокетов. Сокетом прикладного процесса называется пара из IP-адреса и номер порта. Для управления потоком в рамках TCP-соединения используется специфический вариант алгоритма скользящего окна. Сторона-получатель передает стороне-отправителю размер окна приема в байтах. Протоколы маршрутизации генерируют для каждого маршрутизатора согласованные таблицы маршрутизации, которые позволяют обеспечить доставку пакета по рациональному маршруту от исходной сети в сеть назначения за конечное число шагов. Адаптивная маршрутизация обеспечивает автоматическое обновление таблиц маршрутизации после изменения конфигурации сети. Адаптивные протоколы маршрутизации делятся на дистанционно-векторные алгоритмы (например, RIP) и алгоритмы состояния связей (например, OSPF). Протоколы маршрутизации Интернета делятся на внешние (EGP), которые переносят маршрутную информацию между автономными системами, и внутренние (IGP), которые применяются только в пределах определенной автономной системы. Протокол ICMP играет в сети вспомогательную роль. Он используется для диагностики и мониторинга сети. Так, в основе работы популярных утилит мониторинга IP-сетей ping и traced лежат ICMP-сообщения. Вопросы и задания 1. Какой объем данных получен в течение TCP-сеанса отправителем TCP-сегмента, в заголовке которого в поле квитанции помещено значение 180005? Известно, что первый полученный байт имел номер 15000. 2. Может ли работать маршрутизатор, не имея таблицы маршрутизации? Варианты ответов: а) может, если выполняется маршрутизация от источника; б) нет, это невозможно; в) может, если в маршрутизаторе задан маршрут по умолчанию; г) может, если выполняется лавинная маршрутизация. 3. Можно ли обойтись в сети без протоколов маршрутизации? 4. Система DNS может использовать для доставки своих сообщений как протокол UDP, так и TCP Какой вариант вы считаете более предпочтительным? Аргументируйте свой ответ. 5. По какой причине в протоколе RIP расстояние в 16 хопов между сетями полагается недостижимым? Варианты ответов: а) поле, отведенное для хранения значения расстояния, имеет длину 4 двоичных разряда; б) сети, в которых работает RIP, редко бывают большими; в) для получения приемлемого времени сходимости алгоритма. 6. Какие параметры сети учитывают метрики, поддерживаемые протоколом OSPF? Варианты ответов: а) пропускная способность; б) количество хопов; в) надежность каналов связи. 7. ICMP-сообщение об ошибке не посылается, если ошибка возникла при передаче IP- пакета: а) несущего ICMP-сообщение об ошибке; б) являющегося последним фрагментом пакета; в) несущего ICMP-запрос; г) упакованного в кадр с широковещательным МАС-адресом. 8. Кому адресовано ICMP-сообщение? Варианты ответов: а) протоколу IP узла-отправителя пакета, вызвавшего ошибку; б) протоколу IP ближайшего маршрутизатора, от которого поступил пакет, вызвавший ошибку; в) протоколу транспортного или прикладного уровня узла-отправителя пакета, вызвавшего ошибку 9. Предложите варианты метрики, которая одновременно учитывает пропускную способность, надежность и задержку линий связи.
|
|||||||||
Последнее изменение этой страницы: 2017-02-05; просмотров: 1321; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 18.118.152.100 (0.016 с.) |