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

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

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

Версия 22:32, 8 октября 2008

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

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

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

  • Уровень проводовв и розеток
  • Уровень кодир. сигнала.

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

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

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

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

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

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

Проблема 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. Она нужна для того, чтобы делать синхронизацию. Прежде чем послать eth-фрейм, предварительно посылается посл. 0 и 1, чтобы принимающее устройство откалибровало своё принимающее устройство. В начале именно всё так и работало. Впоследствии частота стала настолько большая, что это перестало работать.

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

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

Итого три задачи:

  • Вопрос синхронизации
  • Вопрос ...
  • Вопрос начала и конца прередачи

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

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

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

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

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

Что касается ошибок, есть две вещи:

  • Ошибки можно обнаружить
  • Ошибки можно корректировать

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

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

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

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

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

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

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

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

Попробуем сделать из этого достойные выводы:

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

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

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

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

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

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

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

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

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

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

Нормально они поддерживаются. Что касается беспроводных адаптеров, то там есть несколько чипсетов, и они закрытые, только alteros полностью открытый. Пробелма в том, что wi-fi пока ещё является предметом технологического преимущества. Вопрос в итоге к производителям железок, почему они не делают драйвера.

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

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


UNИX, осень 2008


Лекции

01 02 03 04 05 06 07 08 09 10 11 12


Календарь

Октябрь
01 08 15 22 29
Ноябрь
05 12 19 26
Декабрь
03 10 17
Семинары

01 02


Календарь

Сентябрь
01
Ноябрь
02


Эта статья является конспектом лекции.

Эта статья ещё не вычитана. Пожалуйста, вычитайте её и исправьте ошибки, если они есть.
Личные инструменты
Разделы