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

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

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

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

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

[[Изображение:Uneex 08 10 08 frbrgeorge.jpg|thumb|240px]]

Краткое содержание предыдущей серии: лектор рассказал, как с его точки зрения структурирован стек ТЦП/ИП, показав естественность его происхождения.
5 уровней, а не 4, потому что речь не только о TCP/IP, а о сетевом взаимодействии как таковом, и аппаратного уровня в TCP/IP нет.
Второе, о чём лектор хотел бы напомнить: свойство инкапсуляции.
Третье: независимость.
Мы можем выбрать некую реализацию на аппаратном уровне, поверх неё можно организовать IP.
TCP может работать поверх чего угодно, в том числе IP, прикладные протоколы тоже необязательно могут работать поверх TCP.
Как следствие, если надо передавать по TCP/IP, то на каждом уровне необходимо независимо резать и оборачивтаь пакеты.

= Лекция =

== Методологические проблемы ==

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

Первый из 5 уровней, тот самый, который не описан в TCP/IP, называется аппаратным, и речь тут идёт о двух вещах:
* Уровень проводов и розеток;
* Уровень кодирования сигнала.

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

По сути, задача аппаратного уровня — превратить аналоговый сигнал в цифровой.
Поскольку дальше мы будем работать с 0 и с 1, и только с ними.
Поскольку дальше мы будем говорить про них, а не про различные напряжения, изменения частот и так далее.
После этого мы можем подходить к этому как программисты, до этого — не можем.
Речь о том, чтобы свести всё к 0 и 1.

Есть книжка ... она издавалась в разных формах, в том числе и на интуите, книжка большая, в ней много чего, и всё, что нужно, там есть.
Ссылка на неё есть на uneex.ru.

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

== Провода и розетки ==

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

Тем не менее, на этом уровне необходимо более-менее описать, с каким носителем имеем дело.
Упомянутая витая пара состоит из попарно скрученных проводов, предназначенных для того, чтобы кодировать передаваемый сигнал, используя какой-то (в случае Ethernet — манчестерский) способ кодирования.
Более того, на этом уровне возникает много забавных проблем.

( Проблема 1. Ниже нет ничего, и мы должны делать передачу из воздуха. )

=== Проблема 1: синхронизация. ===

Есть два устройства — передающее и принимающее.
Передающее передаёт, принимающее принимает.
Передающее передало 37 сигналов, 30 ноликов и 7 единичек.
Вопрос: исходя из каких соображений принимающее решило, что это 30 ноличков и 7 единичек, исходя из чего оно решило, что их 37, исходя из чего оно решило, что они вообще есть?

Первый вопрос относительно простой — пусть 0 обозначается отсутствием напряжение, 1 — наличием напряжения.
Но уже тут возникает вопрос — где кончается 0 и начинается 1?
Должна существовать определённая мерка, которая говорит, что больше определённого порога 1, меньше — 0.
И между ними хорошо было бы иметь некий промежуток, ошибка.

Второй вопрос — почему 37?
Простой ответ — они работают с частотой 10 мегагерц.
Если примем такой способ кодирования, указанный ранее, то ровно за 37 миллионых передали 30 раз 0 и 7 раз единицу, принимающее устройство 30 раз замерило 0, и 7 раз единицу.
Но проблема в том, что мегагерцы разные: все устройства работают с немного разной частотой: передающее устройство передало 3700 0 и 1, принимающее приняло 3770.
Обращаемся к картинке 01010101.
Она нужна для того, чтобы делать синхронизацию.
Прежде чем послать ethernet-фрейм, предварительно посылается последовательность 0 и 1, чтобы принимающее сторона откалибровало своё устройство-приёмник.
В начале именно всё так и работало.
Впоследствии частота стала настолько большая, что это перестало работать.

Хорошо, но что значит, если устройство преедаёт сплошные нули?
Оно действительно передаёт нули или провод перерезали?
Хорошо, давайте использовать биполярное кодирование.
Но при этом всё равно необходим маркер начала передачи.
Зачем он нужен?
Потому же, потому что не можем 3 вольта принимать за 5: мало ли почему у нас начало меняться напряжение.
Мы должны договориться о некоем протоколе, который предваряет и завершает передачу данных.

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

Итого три задачи:
* Вопрос синхронизации
* Вопрос ... ''отсутствия сигнала?'' [[Участник:Hades|Hades]] 21:15, 15 декабря 2008 (UTC)
* Вопрос начала и конца прередачи

Лектор напоминает, что это самый нижний уровень, и тут начинают накладываться самые разные вопросы: например, хотим совмещать питание и передачу данных.
Тогда нужно придумать такую систему кодирования, которая позволяет поверх напряжения передавать данные.
И чтобы это например всегда было и ток тёк.
Есть вариант, когда смена напряжения в одну сторону — 0, в другую — 1.
Это, собственно, и есть манчестерское кодирование.

=== Проблема 2: ошибки ===

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

Здесь опять начинаются всякие разговоры.
Чем больше у нас разных уровней сигнала, тем больше ошибок.
Например, мы решили использовать 20-уровневое кодирование.
Понятно, что ошибки будут тогда почти постоянно.
Более того, внутри этого всего существует множество всяких техник кодирования, про которые лектор даже и не упоминает, чтобы не забивать голову.

Лектор, забегая вперёд, количество передаваемых за раз данных зависит от того, ...

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

Что касается ошибок, есть две вещи:
* Ошибки можно обнаружить;
* Ошибки можно корректировать.

Последнее  обязательно связано с передачей дополнительных данных, первое в некоторых случаях этого не требует.

Например, для обнаружения ошибок можно использовать бит чётности.
Чем плох он: неокоторые ошибки взаимоуничтожаются.
Поэтому на уровне передачи больше, чем несколько битов, используются системы контроля целостности, у которых очень низкая вероятность false-positive.
И тут опять начинается математика.
Всё это развилось буквально за несколько десятков лет.

С обнаружением ошибки есть одна проблема.
Ну, обнаружили мы ошибку. Что делать?
Вообще, надо запрашивать повтор, но мы это так просто не можем сделать.
Например, есть специальный фрейм протокола Ethernet.
Но на аппаратном уровне ничего такого просто нет.
И тогда важной задачей становится коррекция ошибок. Шаманские действия заключаются в том, чтобы передавать больше данных, которые позв. восстановить, например, единичные ошибки. Например, передавать данные в виде матр. n&times;n, и передавать вместе с ними биты чётности. Ещё есть кодирование Шеннона.

На этом систематизированные знания у лектора заканчиваются.

То, что тут было сказано, должно было создать представление о том, что передача данных на физическом уровне — вешь достаточно сложная, и для тестирования провода амперметра недостаточно.

Например, как лектора подключили к домашней сети: монтажники увидели, что соседи поключены, и вкрутили проводки в имеющийся провод.
Кроме того, там у них есть своя специальная разводка.

Кроме того, стандартов витой пары много.

Лектору кажется, что из стека исключена аппаратная часть для того, чтобы не пудрить людям голову.
Это детали, знание которых может пригодиться только специалистам по прокладке сети, остальным же достаточно соблюдать простые нормы, не задумываясь, откуда они берутся.

== Выводы ==

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

От себя лектор добавит, что есть очевидная тенденция разделять эти два уровня: повились стандарты на провода и на всё остальное.
По всей видимости, с передачей данных по витой паре, со стандартом 10 гигабит всё закончится.

Теперь время позадавать какие-нибудь вопросы.

MAC-адрес это какой уровень?

Это уровень интерфейсный, поскольку он решает идентификацию устройства передающего данные в СПД. Интерфейсный уровень решает задачи ...

Какой уровень овечает за IP-адрес отправителя? И можно ли указать другой адрес отправителя?

Можно, но зачем?

Можно ли внутри IP-пакета управлять маршрутизацией?

В IPv6 можно, в IPv4 нет. Есть QoS, и на него можно навесить свою семантику.

Почему некоторые устройства (PCMCIA-карты) так плохо поддерживаются Linux?

Нормально они поддерживаются.
Что касается беспроводных адаптеров, то там есть несколько чипсетов, и они закрытые, только alteros (''atheros''? [[Участник:Hades|Hades]] 21:23, 15 декабря 2008 (UTC)) полностью открытый. Проблема в том, что wi-fi пока ещё является предметом технологического преимущества. Вопрос в итоге к производителям железок, почему они не делают драйвера.

А вот в СКИФе, там же свои протоколы обшения между нодами...

Помимо всего прочего, обратите внимание, что слово Linux здесь не возникло ни разу, поскольку про ОС мы можем говорить только там, где у нас есть некое цифровое представление информации. И дальше мы будем говорить в следующий раз.

= Конспект Kda =

На прошлой лекции лектор пытался не произносить слова TCP/IP.
Было рассказано про то, как структурирован стек протокола TCP/IP.
Была попытка показать естественность его происхождения.
Сеть имеет 5 уровней, а не 4.
Речь шла о сетях, как таковых.
В TCP/IP 4 уровня, т.к. к нему провод не относится.
Также речь шла об инкапсуляции каждого уровня, их независимости.
Еще шла речь об оборачивании данных служебными при переходе на нижний уровень.
Также речь шла об аппаратном уровне.
О нем лектор собирался рассказывать, но наткнулся на препятствие.

Первый из пяти уровень сетевых взаимодействий, не описываемый в TCP/IP — уровень а) «проводов и розеток» и б)кодирования сигнала.
Зачастую уровни не разделяются.
Когда мы говорим о конкретном проводе, говорим также о том, какие данные мы можем передавать.
По коаксиальному кабелю можно гонять как Ethernet, так и кабельное телевидение.
По проводам можно по-разному передавать информацию.
Задача аппаратного уровня — превратить аналоговый сигнал в цифровой.
С точки зрения информации могут быть разные вещи, но с точки зрения сигнала — смысл один.
Задача — свести все к нулям и единицам.

Нельзя строго раздельно рассматривать задачи а) и б).
Когда мы разрабатываем новые провода и розетки, мы задумываемся о том, как будем передавать сигнал.
Есть передача сигнала по электропроводке.
То есть бывает, что есть «корова» и нужно придумать, как ее «доить».
Если мы зайдем на спецресурс и будем смотреть, какие бывают витые пары, мы увидим огромный список с техническими характеристиками, отсылающими на уровень Ethernet.
Систематизации на первый взгляд нет.
На этом уровне мы должны описать, с каким носителем мы имеем дело и как передаем сигнал.
На этом уровне возникает много забавным проблем.
Мы должны делать работающую передачу «из воздуха», т.е. никто этим не управляет.

Задача синхронизации.
Передающее устройство передает, принимающее принимает.
Передатчик передал 37 «сигналов», пусть из них 30 «ноликов».
На каком основании принимающее устройство решило, что нулей 30?
Почему сигналов именно 37?
Пусть единица — положительный сигнал, тогда вопрос: где граница нуля и единицы?
Скорее всего, правильнее так: до определенного порога ноль, до другого порога единица, между ними ошибка.
Исходя из каких соображений сигналов именно 37?
Пусть оба устройства работают на частоте 10 МГц.
Значит, есть 10 млн. колебаний в секунду.
Больше 4 вольт на проводе — единица.
За 37 млн-ых долей прошли сигналы.
Но мегагерцы бывают разные.
Не обязательно два компьютера с одной и той же частотой генерируют эти мегагерцы.
Пусть послали 3700, а приняли 3770 сигналов.
Где-то была ошибка, а где-то и пришло.
Но непонятно, 2000 сигнал превратился в 2010 сигнал у получателя.
Мы не можем попытаться засинхронизировать напряжение в розетке, т.к. могут быть разные источники питания.
Да и то, там герцы, а у нас мегагерцы.
Идея в том, чтобы встроить синхронизацию внутрь провода.
Прежде, чем послать файлик по Ethernet посылается набор нулей и единиц, достаточно длинный для того, чтобы приемник откалибровал свои часы.
Не две машины обращаются к третьему устройству, а передается настроечная последовательность нулей и единиц.
Там мы знаем, что должны идти 0--1 и т.д.
Поначалу все было просто — посылались такие последовательности, и калибровались.
Но потом частоты стали слишком большие, и последовательности потребовались слишком большие.
Договариваемся, как представляется сигнал.
Если пошли нули — непонятно, то ли кончились данные, то ли прошел мужик с топором.
Пусть используем биполярное кодирование — 0 — --5 вольт, 1 — +5 вольт, а 0 вольт — ничего.
Пусть шел длинный ноль, а потом началось «шевеление».
Но принимать «шевеление» за сигнал нельзя.
Пусть мимо проехал сильно излучающий трансформатор или электрический угорь прогрыз изоляцию.
Нужен формат, с помощью которого мы предваряем и завершаем передачу данных.
Нужна совместимость по данным, начало и конец передачи.
У нас есть устройство, с помощью которого мы передаем данные.
Пусть мы хотим запитывать устройство от того же провода, по которому идут данные.
Если мы передаем много нулей, откуда взять питание?
Пусть такая система кодирования, при которой обязательно будет напряжение.
Нет такой ситуации, что ноль — ноль, а единичка — единичка.
Можно ввести кодирование переходом, тогда ширина полосы увеличивается в два раза, но тогда уже можно постоянно запитываться.
Есть Манчестерский код, который применяется в Ethernet 10 Мбит.

Какая еще проблема может быть?
Проблема ошибок при передаче данных.
Есть транспортный уровень, который гарантирует доставку.
Но у нас если ошибка, то уже ошибка.
На практике, ошибки на этом уровне могут привести канал в негодность.
Пока мы дойдем до TCP, будет много преобразований.
Если каждый второй пакет превращается в кашу, то это плохо.
Мы даже не знаем, как это проконтролировать.
Ошибки — порча и штатные ошибки (в случае Ethernet — коллизии).
Мы должны предусмотреть ситуацию одновременной передачи данных двумя абонентами, чтобы с высокой вероятностью распознать «кашу».
Стоимость ошибки на аппаратном уровне большая.
Нужно понять, насколько кодирование устойчиво к ошибкам.
Кодирование сигнала должно быть выбрано таким, чтобы обеспечить минимально возможное количество ошибок.
Здесь начинаются всякие разговоры.
Сначала говорили о двух уровнях, потом о трех.
А если захотим использовать 20 уровней?
Такой извращенный способ кодирования будет приводить к частым ошибкам.
Внутри этого существует множество техник кодирования.

Максимальное количество передаваемых данных зависит от того, насколько хорошо произведена синхронизация.
Поначалу «пилообразный отрезок» был такой длины, чтобы гарантировано синхронизировать устройства.
Манипуляция длиной, чтобы за время передачи не успела произойти рассинхронизация.

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

Но обнаружение ошибок может происходить и на уровне кодирования.
Типичный пример — бит четности.
Пусть на каждые 7 битов 8-й бит — четности.
Если контрольная сумма не сошлась, значит, где-то ошибка.
Может быть, только один приехал неправильно, а, может быть, три.
Но тройная ошибка — редкость.
Чем плоха четность?
Она не может обнаружить двойную ошибку.
Некоторые ошибки взаимно уничтожаются.
На уровне более высоком принято использовать контроль с более хорошим контролем.
Существуют различные алгоритмы вычисления контрольных сумм.
Контрольная сумма высчитывается из большого числа битов.
Идея в том, чтобы формула с низкой вероятностью давала правильный ответ в случае ошибок.
Все это развилось в последние несколько десятков лет.
С обнаружением ошибок есть одна проблема.
Мы не можем на аппаратном уровне сказать отправителю: «Мужик, пошли заново».

В материалах лекции есть ссылка на архитектуру Ethernet.
Она не для того, чтобы ее читать, а чтобы ужаснуться.

На аппаратном уровне важной задачей становится коррекция ошибок.
Шаманские действия заключаются в том, чтобы передавать больше данных, чем мы хотим.
Как устранить одиночную ошибку?
Мы передаем данные в виде матрицы.
Когда четность не совпадает в неком столбце и неком столбце, значит, произошла ошибка.
Мы можем построить кубик любой размерности, приложить еще по одной грани с каждого направления, и тогда можем восстанавливать даже не одну ошибку, а несколько.
Есть Шенноновское кодирование, представляющее собой более общее решение.
С его помощью можно корректировать любое количество ошибок, причем с минимальным количеством избыточной информации.

У провода есть минимальная длина, чтобы влез фрейм.
Есть ограничения на время.

То, что было сказано, должно быть создать представление о том, что передача данных — весьма сложная задача.
Домовые сети.
У лектора пришли люди, разрезали витую пару пополам, примотали провода изолентой.
Этакий «хаб для бедных».
Причем у них был свой стандарт обжимки.

На 10 и 100 Мбит используется две пары из четырех.
Если карточка гигабитная, она не будет работать на кривом шнурке даже на 10 или 100 Мбит.
Скажет, что не видит Ethernet.

Давайте попробуем сделать выводы.
Вывод 1: аппаратный уровень предназначен, чтобы привести к цифре то, что цифрой не является.
Вывод 2: на аппаратном уровне сущетсвует гораздо больше overhead, чем мы можем себе вообразить.
Налицо иллюстрация независимости уровней.
Каким бы кодированием мы бы ни пользовались для провода, с точки зрения интерфейсного уровня это не важно.
Мелкие подробности лучше не знать.
Но бывают ситуации, когда две железки не работают друг с другом, например, потому что одна железка думает о скорости 10 Мбит.

Сейчас есть тенденция разделения уровней.
Будет стандарт 10 Гбит, потом, скорее всего, это закончится, т.к. подошли к пределам передачи данным по проводам.
Вступает в силу, например, поляризация диэлектрика.
Непонятно, какая СПД нас ждет дальше.
Оптоволокно вещь дорогая, ломкая.

Вопросы.
MAC-адрес — уровень интерфейса.
IP-адрес — сетевой уровень.

Рассказ об аппаратном уровне предлагается свернуть.
Слово Linux здесь не возникло ни разу, потому что говорить про операционную систему имеет смысл только когда идет речь о цифровой информации.

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

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

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

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

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

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

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

Просмотры

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

Навигация

инструменты

Разделы

Спецкурсы

9 семестр

7 семестр

5 семестр

3 семестр

Поиск

Инструменты

@@ Строка 1: / Строка 1: @@
 [[Изображение:Uneex 08 10 08 frbrgeorge.jpg|thumb|240px]]
-= Лекция =
+Краткое содержание предыдущей серии: лектор рассказал, как с его точки зрения структурирован стек ТЦП/ИП, показав естественность его происхождения.
-== Вступление ==
-Краткое содержание предыдущей серии: лектор рассказал, как с его точки зрения структурирован стек TCP/IP, показав естественность его происхождения.
 уровней, а не 4, потому что речь не только о TCP/IP, а о сетевом взаимодействии как таковом, и аппаратного уровня в TCP/IP нет.
 Второе, о чём лектор хотел бы напомнить: свойство инкапсуляции.
-Третье: независимость уровней.
+Третье: независимость.
 Мы можем выбрать некую реализацию на аппаратном уровне, поверх неё можно организовать IP.
 TCP может работать поверх чего угодно, в том числе IP, прикладные протоколы тоже необязательно могут работать поверх TCP.
-Как следствие, если надо передавать по TCP/IP, то на каждом уровне необходимо независимо резать и оборачивать пакеты.
+Как следствие, если надо передавать по TCP/IP, то на каждом уровне необходимо независимо резать и оборачивтаь пакеты.
+= Лекция =
 == Методологические проблемы ==