Изменения в «LecturesCMC/LinuxNetwork2013/Conspects/01»

TCP/IP за 40 минут

Введение

Первая вещь -- пощупать руками передачу данных между компьютерами.

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

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

Предполагается, что у вас будет установлен VirtualBox. Он сравнительно прост в настройке и использовании, и прост для целей моделирования простейших топологий. Офсайт virtualbox.org

Вы могли заметить, что на сайте uneex.ru уже лежит образ размером 70 мегабайт, этот образ надо распаковть, проимпортировать в VirtualBox и вы получите тоже самое, на чем лектор будет делать свои примеры.

Этим этот курс будет отличаться от курсов 2004 и 2008 года, а также курса 2010 года для NetCracker. Для NetCracker было все наоборот -- люди по rdesktop смотрели на действия лектора, производимые на его машине.

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

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

Есть много компьютеров в разных местах.

Задача -- надо передавать между ними информацию.

С чего начать?

• Имена компьютеров? нет
• Протокол? нет
• Канал связи? Да. Надо подумать, будем ли мы возить жесткие диски на самосвалах между деревнями. Между прочим, есть RFC на tcp/ip по голубиной почте.

1. Среда передачи данных

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

Логичное предложение -- оцифровать.

В этом случае возникают две задачи.

• Описать среду передачи данных -- провода,скрученные провода, воздух, почтовых голубей(чтоб не дохли, как московские). Описать параметры носителя. Допустим изобрели провода, по которым можно передавать.
• Что является данными внутри проводов? Как кодировать данные? Кодировать можно по разному. Нолик -- отсутствие напряжения, единица -- наличие. Но что значит много ноликов за секунду? Это много ноликов или мышка провод перегрызла? Сколько раз в секунду замерять напряжение? 300, 1200, 4800, 9600 раз в секунду?

На этом остановится нельзя. Теперь надо воткнуть провод в компьютер.

2. Подключение к среде передачи данных

Идея в том, что передавать данные должны именно компьютеры. Есть среда передачи данных в которой ровно два компьютера. Как мы организуем процесс использования этой среды?

Означает ли целая секунда нулей на проводе 19200 нулей или означает, что никто ничего не передает?

Как определять

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

Вторая подзадача понятна -- дисциплина использования среды. А первую лектор не помнит. Назовем это

• процесс передачи
• дисциплина использования

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

Теперь про дисциплину использования. Предположим. что у нас не три провода, а все таки локальная сеть. Помимо того что здесь надо решать задачу идентификации -- кто отправитель, кто получатель (хотя это мы можем передать при передаче). Нужно также описать протокол, согласно которому компьютеры будут передавать данные когда можно и не будут когда нельзя.

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

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

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

Целостность? Это можно решить на уровне интерпретирующих инструментах и часто так и делается.

Что в этих задачах предполагается? Мы пока описали процесс передачи на единой среде передачи данных. У всех абоннентов есть информация о том, кто является абоннентом. Идеальная ситуация, все знают про всех.

3. Объединение различных СПД

Этап три -- различные среды передачи данных объединить в единую сеть. Надо научиться передавать из одной в другую, минуя самосвалы, голубей и вайфай.

Объединение многих сред передачи данных, читай локальных сетей (хотя это чуть более узкое понятие) в глобальную сеть.

Вот здесь возникает задача, про которую сказали сначала -- научиться идентифицировать всех абонентов глобальной сети. Глобальная сеть всегда меняется. Только отъявленные гики могут захотеть список всех абоеннтов интернета и это им ничем не поможет.

• идентификация
• обеспечение возможности доставки данных от отправителя к получателю. В рамках одной СПД это подразумевается по умолчанию. Но в случае нескольких СПД это неочевидно. На сайте написано "планирование доставки данных", но это эвфемизм слова маршруты. Задача довольно сложная. Тем не менее, если мы хотим чтобы данные передавались, мы должны описать правило, согласно которому данные от абонента А могут дойти до Б. Если у нас есть полная карта сети где-то, то это где-то может посмотреть и решить как передавать. Проблема в том, чтобы хранить всю карту. И второй недостаток -- интернет большой, и у заплонированного маршрута какое-нибудь звено может отвалиться. Другой вариант -- не знать как именно дойдут данные до адресата, но знать, кому их следующему переслать. Динамическое построение маршрута. Правда, так данные тоже могут не дойти, ну что ж.

4. Работа с потоками данных

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

Допустим мы передаем различные данные одновременно. Грузим картинку и шлем почту. Фактически, три разных потока данных, которые бы очень хотелось не смешивать по дороге. Тем самым вводится понятие поток данных как таковой. Более тонкие вещи связанные с потоком данных -- не факт, что принимающая сторона сможет принимать данные с той же скоростью, с которой их отправляют. С одной стороны сервер с гигабитом, а на другом пользователем с адслем. Если ему фигачится фильм со скоростью 3 мегабита, а у него 64 килобита, то куда все девается? Накапливается посередине интернета? Нет. Но могут постоянно срабатывать механизмы контроля целостности. Но лучше бы чтобы у потока данных было известно, с какой скоростью по нему можно передавать. Еще одна проблема -- джиттер, неравномерность скорости передачи. Хочется по мере возможности сделать гарантированную пропускную способность, хотя просто так предоставить такие гарантии в интеренет нельзя. Все это так или иначе относится к управлению потоками.

5. Интерпретация данных

Ну и наконец последний пункт. Что мы передаем и зачем? Здесь до сих пор не написано, что это были за данные? А мы и не знаем, нас на тех уровнях это не интересовало. Далее идет интерпретация данных, ради которой все и затевалось. Теперь можем говрить -- все ребята, мы сделали все что могли. Какие бывают проблемы интерпретации? Это проблемы проотоклов.

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

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

Связывание и интерпретация.

Связывание -- до прикладных протоколов.

Интерпретация -- пережёвывание данных приложениями. Если хватит времени, поговорим про аспекты интерпретации, которые есть везде, например DNS -- протокол прикладного уровня, но без него никуда.

Вот вам уже совсем готовая схема, как может функционировать компьютерная сеть.

Готовая схема

Давайте посмотрим на уже совсем готовую схему, и те, кто уже слушал предыдущий курс -- компьютерные сети, давайте приложим этот механим к той самой модели ISO/OSI. Уровни:

1. аппаратный
2. канальный
3. сетевой
4. транспортный
5. сеансовый
6. уровень представления данных
7. прикладной

Как это все расклдывается в нарисованную схему. Первые три уровня матчатся напрямую. Дальше сложнее.

С точки зрения ISO/OSI транспортный уровень обеспечивает надежную доставку пакетов и более ничего. Управление потоками данных это уже пятый, сеансовый уровень. Они говорят, что в завсисмости от приложений потоки данных могут быть сильно разными, и они вообще то правы.

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

Вспоним модель TCP/IP, у неё следующие уровни:

1. аппаратный;
2. интерфейсный; Cisco "считает", что уровня четыре, объединяя аппаратный и интерфейсный. Лектор и "все остальные" "считают", что уровней пять.
3. сетевой;
4. транспортный;
5. прикладной.

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

Типичный пример когда нам не хватает инструментария TCP/IP -- это пресловутое шифрование. Если у вас на сайте включен ssl, то если у вас один ip-адрес, то у вас может быть только один сертификат. А это очень неудобно, потому что сайтов может быть много. Потому что шифрование происходит на неудоном уровне. В ssl третьей версии сделали костыль на эту тему. Осталось только распространить этот костыль по всему миру и все будут счастливы.

Если кто не понял, за эти 40 минут лектор рассказал TCP/IP как оно есть.

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

Две вещи, которые несомненно нужно рассказать, когда мы говорим про сети.

Первое -- уровни сетевые про которые мы говрим не зависят друг от друга практически. Когда мы решаем задачу на уровне N, мы не заморачиваемся тем, как она решена на уровне N-1. Задачи предыдущих уровней просто считаются решенными. Когда мы присваиваем компьютеру айпи-адрес, нам все равно, какой у него мак-адрес.

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

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

Второе -- инкапсуляция пакетов. Если у нас есть СПД, которой пользуются сразу несколько абонентов, возникает вопрос, как сделать так, чтобы они могли ей пользоваться "одновременно". Если СПД это полный граф из проводов, то все отлично. Но это неоправданно большое количество проводов. Значит у СПД есть максимальная пропускная способность, и не все абоненты одновременно могут ей воспользоваться. Далее есть два решения.

• Коммутация каналов, как при телефонном звонке. Звоните из Нагатино в Долгопрудный. Ещё несколько человек могут сделать такэже, пока не кончатся каналы на какой-то из задействованных телефонных станций.

Очередной человек обнаружит, что там занято -- час, другой, как будто абонент там занят, а на самом деле не абонент занят, а каналы кончились.

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

стороне получателя складывание этих кусочков в единое целое.

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

Какие данные надо навесить на пакет кроме пользовательских?

1. отправитель
2. получатель
3. номер в потоке если есть потоке
4. итд

Здесть возникает одно забавное явление, которое в случае с коммутацией пакетов хорошо объяснимо, но плохо понимаемо народом. Инкапсуляция.

Смотрите как все устроено. На самом верхнем уровне есть файл. Файл невозможно целиком затолкать в дырочку, поэтому он режется на части и по частям засовывается на транспортный уровень.

На транспортном уровне мы смотрим на его размер. Если он слишком большой чтобы пролезть на сетевом уровне, мы снова его режем на куски. Здесь на части уже режутся пользовательские данные + метаинформация. Нарезание на куски называется фрагментация. Заворачивание в пакеты более низкого уровня называется инкапсуляцией.

Так все путешествует до уровня проводов.

По проводам до соседней машины.

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

Каждый раз при переходе на более нижний уровень у нас может происходить фрагментация и всегда происходит инкапсуляция.

На каком из этих уровней преедается больше всего нулей и единиц? На первом, если там все ещё будут нули и единицы. Там будут же маркеры начала и конца передачи, как минимум.

Все остальное про эти ваши сетевые протоколы -- это подробности вот этого.

Заключение

В следующий раз у нас полторы темы. Что-нибудь про аппаратный уровень и ещё полтемы про то, как вообще делать примеры. Базисы по работе с командной строкой. Ссылки на лекции позапрошлого года лежат на страничке нашей лекции.