Редактирование: UNИX, осень 2008, 04 лекция (от 22 октября)

Материал из eSyr's wiki.

Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.

ПРЕДУПРЕЖДЕНИЕ: Длина этой страницы составляет 42 килобайт. Страницы, размер которых приближается к 32 КБ или превышает это значение, могут неверно отображаться в некоторых браузерах. Пожалуйста, рассмотрите вариант разбиения страницы на меньшие части.

Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.

= Лекция =
== Вступление ==
Сегодня по плану интерфейсный уровень.

Лектор напоминает, что:
* на первой лекции он набросал происхождение TCP/IP, как он понимает
* на второй попытался углубиться в аппаратный уровень. Углубление было непрофессиональное, поскольку пришлось столкнуться с большим количеством не систиматизированной документации, и не смог сделать из неё выжимку. Если кто заглядывал в доку по Fast Ethernet, то там очень много уровней завязано на интерфейсный уровень. Сам Fast Ethernet имеет много подуровней, и одни из них принадлежат совсем аппаратному уровню, есть подуровню, которым должен отвечать интерфейсный уровень, и тем самым принцип независимости уровней нарушается. Нарушается он не так сильно, можно провести границу, но производитель её не проводит. Также важно заметить, что именно с интерфейсного уровня начинается разговор об ОС как таковой, поскольку то, что касается проводов, никак не контролируется ОС, а вот что касается интерфейсов...  .

== Мифы и легенды Быстрого Эзернета ==
На самом деле, выглядит всё достаточно просто. Раньше, когда рассказывали про интерфейсный уровень, лектор упоминал про token ring, но сейчас ему лень про него рассказывать, да и оно нигде не используется. С другой стороны, то, что сейчас имеется, практически невозможно изучать. Поэтому приходиться довольствоваться разного рода мифами, которым и приходится в той или иной мере доверять, и это надо учитывать: то, что будет рассказывать, это не точно Fast Ethernet, это некий набор мифов, которые так и надо воспринимать.

Что имеем на интерфейсном уровне: есть кабель, воткнули его разными концами в интерфейсы. СПД служит для общения, и через неё любое устройство может обратиться к любому. Исключая довольно важные подробности, лектор скажет, что данные, ходящие по сети, достаются любому устройству в среде. Это значит, что перед нами в полный рост сразу встают две проблемы:
* Идентификация
* Дисциплина доступа к среде

=== Данные - пакеты ===
С чего начать? С дисциплины, с того, каким образом данные передаваемые в Ethernet. Передаются они в виде пакетов (фреймов). (долька колбасы с бутербродом) С точки зрения дисциплины всё более-менее понятно: мы должны данные нарезать на куски и по кусочку в СПД скармливать. Видимо, придётся вспомнить token ring, для того, как такая дисциплина может быть реализована. Мы можем сделать как: Если у нас топология в виде кольца, то можно было бы принять следующее решение: у нас есть пропускная способность сети, её можно изобразить в виде паровозика с вагончиками, которые ходят по кругу. И дисциплина тогда такая: ждём, пока паровозик до на доедет, смотрит, есть ли свободный вагон, кладёт туда данные с надписью "на деревню дедушке", и далее когда паровоз до него доходит, он проверяет данные и забирает их себе. Если перевести это на более прибл. к реальности язык, то по кругу ходит маркер, и за ним идут данные. Чем эта архитектура хороша? У нас есть гарантированное время, за которое один паровоз довозит пакет до другого. Время доставки пакета, если не учитывать порчу по ходу, гарантировано. Это всё хорошо, но тут есть один недостаток: пропускная способность такого железнодорожного упражнения очень низкая. Кроме того, она надёжна настолько, насколько надёжны её узлы.

Лектор просит заметить, что тут мы имеем дело в единой СПД.

=== Идентификация. MAC ===
Что же касается Ethernet, тут все по-другому. Если узел хочет передавать данные, то он их передаёт. Чуть выше есть уровень MAC комплект протоколов, которые контролируют передачу данных в СПД. Мы её запомним как MAC-адрес, который решает проблему идентификации. MAC-адрес состоит из 6 октетов, и первые несколько (3) соответствуют производителю, последние три — аппаратный номер устройства. Тем самым производитель карт соблюдает один очень простой закон: любая карта имеет уникальный MAC-адрес. Когда лектор работал в сетевой компьютерной помощи, был случай, когда клиентом были закуплены карты с одинаковыми маками. Мы взяли и одним махом решили проблему идентификации устройств.

Помимо того, что MAC-адрес отвечает конкретному устройству в сети, есть ещё широковещательный MAC-адрес, который состоит из 48 единиц и предназначен всем устройствам сети. Это адрес, посылая по которому eth-фрейм мы можем рассчитываем, что его получат и обработают все машины в СПД. Бывают ситуации, когда MAC-адрес адресата неизвестен, и нам нужно MAC-адрес выяснить, или у нас широковещание происходит. Во всех этих случаях, если польз. езернетом, посыл. широк. запрос. Если же польз. TCP/IP поверх этого, то оно исп. разве что для ARP и DHCP/BOOTP. Мы говорили, что если бы интернет базировался на одной СПД, то тут всё уже есть. И в сетях базир. на лок. сетях, очень часто исп. широковещание.

Пакет уровня интерфейса помимо различных служебных полей имеет два обязательных поля: MAC отправителя и получателя. В случае, если MAC получателя известен, то там будет стоят его MAC. Сетевые карты устроены так, что они могут отбрасывать те пакеты, которые содержат чужие адреса получателя. В какой-то момент, стало понятно, что это не всегда удобно, и появились карты, которые умеют фильтровать, а умеют и не фильтровать (promiscuous mode). Если наша задача — разглядеть все данные в сети, то сетевая карта способна рассказать компьютеру о том, какие пакеты ходят все.  Зачем это бывает нужно: в отладочных целях и подглядывать чужие пароли. И уж если у нас есть карточка, просмотрим все пакеты в сети, то мы можем посмотреть все пароли и обогатимся. Есть утилита '''tcpdump''', она нужна для первого. Более интересно смотреть на выдачу '''tcpdump''', когда идёт обмен TCP/IP, но и про Ethernet там есть.

Есть метод выявления компьютеров, которые сканируют сеть. Методика очень простая: берёте и заставляем генерировать некий компьютер фреймы, которые предназначены несуществующему абоненту, и потом меряете скорость отклика.

Возвращаясь к идентификации. Задача уже решена. Мы решили идентифицировать все сетевые устройства, работающие с данным типом СПД. Какое бы устройство к СПД не подцепили, оно всегда найдёт общий язык с другими.

=== Коллизии ===
Замечательно, в начале мы описали способ организации кольца, когда есть маркер. А если маркера нет? Что делать в этом случае? Вырабатывая некую дисциплину доступа, которая в случае eth заключается в следующем: СПД Ethernet должна поддерживать определение занятости: карта должна уметь определять, идут данные по сети или нет (определение занятости, carrier sense). Это самое "оно смотрит" должно иметь поддержку именно на аппаратном уровне. Для нас важно, что это определение занятости проходит.

Тут есть два пути:
* Мы посмотрели, что среда не занята и начали передавать пакет
* Среда занята, и надо что-то делать, например, дожидаться конца занятости.
Давайте выясним, что будет, если увидим, что не занята, и начнём передавать пакет. Существует проблема, что одновременно два компьютера проверили и начали предавать пакеты. То есть, возможна вероятность коллизии. Эту ситуацию тоже нужно аппаратно ловить, нужно место, где попытка передачи привела к коллизии, collision detection. В этом случае, необходимо придумать алгоритм, по которому будем работать.

Мы видим, что среда занята, и ждём. Видим, что освободилась, начинаем передавать. Видим, что коллизия, и прекращаем передачу.

Понятно, что при таком алгоритме есть вероятность, что из коллизии не выйдут. Поэтому есть костыль: случайная задержка при повторе. Когда мы выяснили что СПД занята, мы ждём случайное время и следующая посылка будет по прохождении этого таймаута. Если вдруг повторная передача данных приводит опять к конфликту, то максимум времени задержки увеличивается.

=== Разделение СПД ===
Дело даже не в том, какой алгоритм обработки ситуаций занятости и конфликтов, дело в том, что производительность такого рода СПД при загрузке по времени 20 процентов, то это загруженная сеть и выше поднимать загрузку бесполезно.

Все видят единую СПД, если Ethernet коаксиальный. Если длины кабеля не хватало, то ставили репитер. Но при этом абонентам одного сегмента совершенно необязательно видеть пакеты, идущие от одной машины к машине другого сегмента. В случае же постановки ретранслятора точно встаёт такой вопрос. По двум причинам:
* Это администратор
* Это злоумышленник
Низачем. Другим на другие ноды транслировать трафик не нужно. В какой-то момент, устройства, которые просто ретранслировали, и устройства, обладающие свойством фильтрации, различались по стоимости раз в 10: хабы стоили 30 долларов, а коммутаторы — 300 долларов.

Что касается устройства под названием свич.

Как сделать так, на основе чего принять решение, что на определенном соске находится абонент, и ему не нужно видеть фрейм, идущих от одной ноды к другой. Очевидно, такое устройство составляет карту мак-адресов. MAC-адреса берутся потому, что в каждом фрейме есть адрес отправителя. И свич занимается поддержкой таблиц. Дальше картина ясна:
* если широковещательный фрейм, то он идёт во все порты
* если он предназначен известному адресату, то он транслируется в нужный порт
* если неизвестен адрес, то во все, кроме того, откуда пришёл.

Таким образом мы можем поднять загрузку сети до более серьёзных параметров. Поскольку мы имеем не единую СПД, а довольно забавную вещь.

Если вы злоумышленник, и ваша задача — подглядеть чужой трафик, то можно сделать следующее: сгенерировать поток фреймов с разнообразными мак-адресами, их должно быть столько, чтобы у устройства кончилась память. После чего случится одно из двух: либо перестанет работать, либо перестанет фильтровать. Но всё это уже небезопасно.

=== Команда ip ===
//Есть команда ifconfig, но про нее не будем говорить, т.к. она устарела.

Что к этому можно добавить отношении Ethernet: есть замечательная команда '''ip''', у которой есть параметр link, и увидите, что всё не так просто, как лектор только что рассказал, поскольку у этой команды много разных команд. Чем можно управлять: есть довольно забавный параметр у каждого интерфейса под названием...

Традиционно, со времён unix сетевые устройства не стандартно в каталоге устройств, а совершенно отдельно являются под собственными именами. В линуксе принято называть ethernet-карточки именами ethN.

В выводе '''ip link''' будет как минимум один интерфейс, lo. Он устр. след. обр: всё, что вы туда посылаете, немедленно оттуда получаете, очень удобно для установление соединения с самим собой.

В какой-то момент в линуксе появилась команда '''ifrename''', которая позволяет переименовывать интерфейсы. ip тоже умеет переименовывать: '''ip link set DEV name NEWNAME'''.

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

Ещё есть параметр MTU. Наша СПД ограничивает максимальный размер одного пакета. Это величина управляемая, и для некоторых интерфейсов, пользующихся другими СПД, размер может быть другой. Если ваш маршрут перекладывает пакеты из одной СПД в другую, то, для того, чтобы такое переложить, надо порезать фрейм на части и послать два.

(обсуждение нарезания пакетов)

Тут мы упомянули, что СПД могут быть не только провода и воздух, но и сам сетевой трафик. То есть, берёте ethernet-фрейм, складываете более высокоуровневый пакет, шифруете и посылаете по городам и весям. При этом есть довольно забавный маршрут пакета, но сам пакет об этом ничего не знает.

== VLAN ==
Осталось 15 минут про другие СПД.

Раз уж заговорили о свичах. Есть стандарт, которая в быту называется VLAN. Это достаточно простая модификация Ethernet, которая позволяет организовать такую штуку: можно организовать с помощью одного устройства несколько недоступных друг другу ethernet-сегментов. Обмен данными между сетями, прин. разным VLAN-ам, запрещён. В такой форме никакого изменения в Ethernet не нудно, это исключительно мозги свича.

Проблема возникает тогда, когда организуется каскад. В этом случае будут ходит не совсем ethernet-фреймы, а ethernet-фреймы, покрашенные в разные цвета. Это достигается добавлением 1 байта. Сейчас больше не выпускают карты, которые не понимают, что такое VLAN. И на стороне компьютера можно организовать два различных интерфейса, базирующихся на одном настоящем, по которому приезжают пакеты, принадлежащие разным VLAN.

Это позволяет организовать вот эти каскады. Чем это удобно? Это позволяет сосредоточить управление сетью на одной железке. На факультете этих VLAN'ов десятка полтора. Они разруливаются на центральном свиче. А приезжают они на bsd-машину, у которых подняты все эти интерфейсы. VLAN --- это такая СПД, которая позволяет разделить и гарантировать непроникновение.

В следующий раз договариваем про WiFi. И начнём разговаривать про IP. Маршрутизация на через раз.

= Конспект Kda =

Важно заметить, что с интерфейсного уровня начинается работа ОС, как таковой.
На уровне проводов ОС нет.
На поверхности это выглядит крайне плоско.
Пример - Ethernet.
Ранее был рассказ о Token Ring, но сейчас, кажется, он нигде не используется.
Остроумное решение, отжившее свой век.
То, что сейчас находится в реальной эксплуатации, невозможно изучать.
Пример — 400-Кб документация по Fast Ethernet.

На руках мы имеем две вещи.
Первая — у нас есть некий провод, который воспринимается с точки зрения компьютера как ?.
Ранее рисовалась шина на картинка по эзернет, сейчас — звезда.
Есть СПД, которая служит для общения, и можно обратиться к любому устройству.
Данные, бегающие по СПД доступны любому устройству в сети.

Проблема дисциплины.

Мы должны нарезать данные на кусочки и передавать по сети.
Вспомним про Token Ring.
Если у нас есть компьютеры, связанные кольцом.
Представим, что есть железная дорога, по ней паровозик, каждый сегмент вмещает некоторое количество вагончиков.
Вагончики могут быть реальными и мнимыми.
Ждем, пока доезжает паровоз, в первый же незанятый вагончик кладем данные, паровоз едет дальше.
Каждый раз смотрим, есть ли пакеты для нас, если есть, забираем.
Если забыть про метафору, по этому кругу гоняется маркер, специальный управляющий пакет — сигнал начала последовательности.
С какой-то частотой прибывают пакеты, а также убывает.
Передаем, изымаем, а если есть свободный слот, то ставим свой пакет, если нужно что-то передать.
Чем такая архитектура хороша?
Всегда есть гарантированное время, за которое паровоз довозит данные.
Исключение — сеть перегружена.
Но до этого время доставки пакета гарантировано.
Это хорошо, но есть крупный недостаток — время доставки высокое.
Скорее, пропускная способность очень низкая.
Чтобы послать второй пакет, нужно снова дожидаться паровоза.
С этой архитектурой упражнялись.
Но надо учитывать, что надежность зависит от всех узлов.
Со временем перестали использовать.
Политика гарантирует некоторую скорость доставки.

Что же касается Ethernet, там ситуация другая.
Все просто.
Есть некий компьютер, который хочет передать данные, и он передает.
Что он использует?
Есть подуровень Media Access Control (MAC).
Это комплект низкоуровневых протоколов, определяющих доступ к СПД.
Чаще всего под MAC подразумевают только MAC-адрес.
Он решает проблему идентификации в Ethernet-сетях.
Это — 6 октетов (современных байтов).
Когда они использовали 8 битов, байт еще не был 8-битным.
7-битный байт долго жил.
В адресе кодируется производитель (3 байта) и номер устройства (последние 3 байта).
Любая карта имеет уникальный MAC-адрес.
Если производитель выпустил больше 16 млн устройств, то он получит еще один номер.
Вряд ли есть 16 млн производителей карт.

Был случай закупки карт с одинаковыми адресами.
В сети китайских карт с одинаковыми адресами иногда что-то передавалось.
Когда адрес устарел, он обновляется.
«Кто первый встал, того и тапки».

Мы решили проблему идентификации устройств в СПД.
Помимо того, что MAC адрес отвечает одному устройству в сети, есть широковещательный адрес, отвечающий любому устройству в сети, состоит из одних единиц.
Такое сообщение обработают все устройства.
Бывают ситуации, когда MAC адрес неизвестен.
Нужно его выяснить, или что-то передать, или у нас широковещание — передаем всем сразу.
Есть протокол ARP, когда посылают широковещательный запрос, а один отвечает (обратное разрешение адреса).
Ранее широковещательный адрес использовался весьма основательно, но для вещей более высокого уровня.
Если бы СПД была одна, то у нас уже все есть (в частности, уникальный идентификатор).
Как происходит работа? Каждый фрейм (пакет интерфейсного уровня) имеет помимо других служебных полей адрес отправителя и получателя.
Как правило, свой адрес известен.
Если получатель известен, будут стоять оба адреса.
Сетевые карты так устроены, что они отбрасывают на аппаратном уровне ненужные фреймы.
Потом стали производить сетевые карты с возможностью взаимодействия со всеми (promiscuous).
Что это дает пользователю?
Если работать с данными, ничего хорошего.
Если следить за сетью, такая карта способна позволить подглядывать за сетью.
В отладочных целях, а также подглядывать чужие пароли.
Есть такая утилита tcpdump, она предназначена для первого пункта.
Она переводит карточку в режим promiscuous.
Более интересно смотреть на его выдачу, когда идет обмен TCP/IP, но даже на нашем уровне может быть интересно.

Есть метод выявления людей, которые сканируют сеть.
Методика простая: вы заставляете некий компьютер генерировать фреймы для несуществующих компьютеров, большие, неправильные.
Затем проверяем время отклика.
Если абоненты отвечают быстро, а один долго, то он — тот самый негодяй.
Можно послать ему особый фрейм.

Какое бы устройство ни прицепилось, они друг друга всегда найдут.
В случае, когда СПД едина и любое устройство может послать любой пакет нужно вырабатывать дисциплину доступа к среде.
Первое: СПД должна поддерживать определение занятости.
Сама сетевая карта должна распознавать, идет ли передача данных по сети.
Всякий раз, когда устройство хочет передать фрейм, оно смотрит, не передает ли кто-то в этот момент.
Поддержка на аппаратном уровне — важна.
Просто так мы не определим.
Есть два пути.
Первый путь — определили, что среда не занята и передаем.
Второй путь — среда занята, и мы ожидаем конца передачи.

Рассмотрим первый путь.
Даже если среда не занята, существует проблема атомарности.
Допустим, есть такой же человек как мы.
Два устройства передают пакеты одновременно.
Проблема в том, что когда мы приняли решение о свободной среде, может случиться коллизия.
Эту ситуацию нужно аппаратно ловить.
Во-первых, получение информации о свободной среде.
Во-вторых, получение информации о конфликте.
Допустим, среда занята.
Мы ждем.
Когда среда свободна, передаем наш пакет.
Когда мы выяснили, что передавая пакет, мы вошли в конфликт, мы должны передать пакет снова.
Если так действовать, из конфликта оба не выйдут.
Третье — костыль — случайное время ожидания перед повтором.
Когда передача невозможна, мы ждем случайное время, генерируемое из неких данных.
Следующая попытка по истечении таймаута.
В следующий раз, предположительно, будет передача данных в разное время.
Мы избежим проблемы вечного конфликта.
В одной книге отрицается наличие случайного времени задержки.
Если вдруг повторная передача данных приводит опять к конфликту, время задержки увеличивается.
Блок схема получается достаточно непростая, но общий алгоритм вполне ясен.

При 20% загрузке считается, что допустимо.
Если на треть загружено, то Ethernet перегружен, т.к. много повторных посылок.
Если на половину загружено, то сеть неработоспособна.
Скорость очень низкая.
Это не значит, что Ethernet плохая сеть, просто нельзя получить скорость делением мегабитов.
До сих пор мы исходили из общедоступности данных, передающихся в сети.
Если исходя из длины коаксиального кабеля или надежности нам приходило в голову, что нужно сделать две сети, являющихся одной СПД, мы ставим репитер (повторитель, хаб).
Повторитель обладал тупым свойством: он видел все пакеты и ретранслировал пакеты в обе стороны.
Абонентам одного сегмента необязательно видеть пакеты, передаваемые внутри другого сегмента.
Это стало более ясно, когда мы стали соединять сети звездой.
Зачем видеть чужие пакеты?
Первый вариант — системный администратор, следящий за функционированием сети.
Второй вариант — злоумышленник.

Устройства, обладающие функцией фильтрации, стоили раз в 10 дороже.
На сегодняшний день невозможно купить устройство на витой паре, которое не было бы свитчем.
Сейчас все дешево.
И на шине, и на звезде были и хабы, и свитчи.
Разниица в том, что свитч — более интеллектуальное устройство.
Как понять, где находится абонент, которому не нужно видеть пакет?
Свитч должен обладать таблицей адресов компьютеров.
Для каждого порта составляется таблица адресов устройств, которые на этом порту засветились.
Их может быть более одного.
Для 10-мегабитного Ethernet можно было сделать чуть ли не пять каскадов.
Если идет широковещательный фрейм, он транслируется всюду.
Если же он предназначен известному адресату, он ретранслируется по назначению.
Если неизвестному адресату, ретранслируем широковещательно и ждем ответа, а тогда запоминаем нужный порт.
Мы можем поднять загрузку сети до существенно более высоких параметров.
Фактически, мы имеем уже не одну СПД, а сложную коммутируемую систему.
Загрузка возможна порядка 80%.
Идея в том, что если у нас нормальная сеть без злоупотребления широковещательными пакетами, все хорошо.

Если мы — злоумышленник, то мы можем поступить простым способом — заставить компьютер сгенерировать поток фреймов с разными адресами.
Их должно быть столько, чтобы у устройства кончилась память.
Устройство может перестать работать.
Будет плохо.
Либо перестанет фильтровать и начнет работать как хаб.
Тогда мы сможем наблюдать трафик.
Если устройство стоит хотя бы 50 долларов, порт будет зафиксирован, и могут прийти к нам.

Мы сильно повышаем быстродействие сети.
Что можно добавить относительно Ethernet?
У нас есть ip link.
Мы увидим, что все не так просто, как было только что рассказано.
У этой команды много подкоманд.
Чем можно управлять?
Традиционно сетевые устройства не стандартизованы, а появляются под собственными именами.
В Линуксе принято называть eth.
Скорее всего, будет eth0.
Как минимум будет один lo (loopback).
Он есть всегда, даже если нет ни одной сетевой карты.
Есть команда ifconfig, но про нее не будем говорить, т.к. она устарела.
Сетевое устройство очень плохо подчиняется файловым операциям ввода-вывода.
Loopback устроен так, что все, что мы туда посылаем, тут же получаем обратно.
Появилась команда ifrename, может случиться так, что не будет ни одного eth, а произвольное имя.

Сетевой интерфейс бывает поднят и опущен.
Мы обрабатываем пакеты, которые этим сетевым интерфейсом обрабатываются.
Сетевая карта может быть либо активной, либо неактивной для нашей ОС.
Еще один параметр — MTU.
Идея в том, что наша СПД ограничивает максимальный размер одного пакета.
Будем считать, что MTU — размер фрейма.
Почему 1500 — сложный вопрос.
Существует теория на этот счет.
Для некоторых интерфейсово может быть другой размер.
Если маршрутизатор перекладывает пакеты из одной среды в другую, где MTU меньше, его нужно порезать и послать два пакета.
Либо сбросить и отправить ошибку.

СПД может быть любой.
Может быть даже сам сетевой трафик.
Берем фрейм, складываем его в какой-то пакет и отправляем.
Внезапно он натыкается на ПО, которое его расшифровывает и отправляет в сеть.
На пути могут быть разные сети, поэтому размер должен быть меньше.

Есть такая вещь, как VLAN.
Если есть устройство, поддерживающее VLAN, мы можем организовать поддержку нескольких независимых друг от друга сетей на одном устройстве.
Портам приписываются VLAN'ы.
Между соседними VLAN нет связи.
Все обеспечивают мозги свитча.
Между свитчем и маршрутизатором будут ходить фреймы, «покрашенные» в два цвета — синий и желтый.
Все сегодняшние сетевые карты такой фрейм примут и либо распознают VLAN, либо просто примут фрейм.
Можно организовать два различных сетевых интерфейса на одном компьютере.
Это позволяет сосредоточить управление сетью на одной железке.
Если сеть не очень нагружена, может быть Линукс, если средней степени загруженности лучше Солярис.
У нас на факультете десятка полтора VLAN'ов, например, у каждого класса.
VLAN'ов ограниченное число.
Главная проблема маршрутизации в том, что перекидывающее устройство должно обладать дикой производительностью.
Компьютер с этим не справляется.
В следующий раз разговариваем про Wi-Fi и про IP.
Маршрутизация потом.

Пожалуйста, обратите внимание, что все ваши добавления могут быть отредактированы или удалены другими участниками. Если вы не хотите, чтобы кто-либо изменял ваши тексты, не помещайте их сюда.
Вы также подтверждаете, что являетесь автором вносимых дополнений, или скопировали их из источника, допускающего свободное распространение и изменение своего содержимого (см. eSyr's_wiki:Авторское право).
НЕ РАЗМЕЩАЙТЕ БЕЗ РАЗРЕШЕНИЯ ОХРАНЯЕМЫЕ АВТОРСКИМ ПРАВОМ МАТЕРИАЛЫ!

Описание изменений:

Отменить | Справка по редактированию (в новом окне)

Шаблоны, использованные на этой странице:

Получено с http://esyr.us/wiki/UN%D0%98X%2C_%D0%BE%D1%81%D0%B5%D0%BD%D1%8C_2008%2C_04_%D0%BB%D0%B5%D0%BA%D1%86%D0%B8%D1%8F_%28%D0%BE%D1%82_22_%D0%BE%D0%BA%D1%82%D1%8F%D0%B1%D1%80%D1%8F%29

Редактирование: UNИX, осень 2008, 04 лекция (от 22 октября)

Материал из eSyr's wiki.

Просмотры

Личные инструменты

Навигация

инструменты

Разделы

Спецкурсы

9 семестр

7 семестр

5 семестр

3 семестр

Поиск

Инструменты

@@ Строка 15: / Строка 15: @@
 === Данные - пакеты ===
-С чего начать? С дисциплины, с того, каким образом данные передаваемые в Ethernet. Передаются они в виде пакетов (фреймов). (долька колбасы с бутербродом) С точки зрения дисциплины всё более-менее понятно: мы должны данные нарезать на куски и по кусочку в СПД скармливать. Видимо, придётся вспомнить token ring, для того, как такая дисциплина может быть реализована. Мы можем сделать как: Если у нас топология в виде кольца, то можно было бы принять следующее решение: у нас есть пропускная способность сети, её можно изобразить в виде паровозика с вагончиками, которые ходят по кругу. И дисциплина тогда такая: ждём, пока паровозик до наc доедет, смотрит, есть ли свободный вагон, кладёт туда данные с надписью "на деревню дедушке", и далее когда паровоз до него доходит, он проверяет данные и забирает их себе. Если перевести это на более прибл. к реальности язык, то по кругу ходит маркер, и за ним идут данные. Чем эта архитектура хороша? У нас есть гарантированное время, за которое один паровоз довозит пакет до другого. Время доставки пакета, если не учитывать порчу по ходу, гарантировано. Это всё хорошо, но тут есть один недостаток: пропускная способность такого железнодорожного упражнения очень низкая. Кроме того, она надёжна настолько, насколько надёжны её узлы.
+С чего начать? С дисциплины, с того, каким образом данные передаваемые в Ethernet. Передаются они в виде пакетов (фреймов). (долька колбасы с бутербродом) С точки зрения дисциплины всё более-менее понятно: мы должны данные нарезать на куски и по кусочку в СПД скармливать. Видимо, придётся вспомнить token ring, для того, как такая дисциплина может быть реализована. Мы можем сделать как: Если у нас топология в виде кольца, то можно было бы принять следующее решение: у нас есть пропускная способность сети, её можно изобразить в виде паровозика с вагончиками, которые ходят по кругу. И дисциплина тогда такая: ждём, пока паровозик до на доедет, смотрит, есть ли свободный вагон, кладёт туда данные с надписью "на деревню дедушке", и далее когда паровоз до него доходит, он проверяет данные и забирает их себе. Если перевести это на более прибл. к реальности язык, то по кругу ходит маркер, и за ним идут данные. Чем эта архитектура хороша? У нас есть гарантированное время, за которое один паровоз довозит пакет до другого. Время доставки пакета, если не учитывать порчу по ходу, гарантировано. Это всё хорошо, но тут есть один недостаток: пропускная способность такого железнодорожного упражнения очень низкая. Кроме того, она надёжна настолько, насколько надёжны её узлы.
 Лектор просит заметить, что тут мы имеем дело в единой СПД.