|
|
| (не показано 6 промежуточных версий 4 участников) |
| Строка 1: |
Строка 1: |
| − | == Блок 1. == | + | = Ищите конспекты тут [http://neerc.ifmo.ru/wiki/index.php?title=%D0%9A%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E%D1%82%D0%B5%D1%80%D0%BD%D1%8B%D0%B5_%D1%81%D0%B5%D1%82%D0%B8 Компьютерные сети] = |
| − | === 1. Коммутация на канальном уровне. ===
| |
| − | === 2. Сети с общей средой передачи данных (подуровень MAC, протоколы). ===
| |
| − | === 3. Физическое кодирование. ===
| |
| − | === 4. Модель OSI. Канальный уровень (сервисы, подуровни). ===
| |
| − | === 5. Модель OSI. Канальный уровень (протоколы). ===
| |
| − | На канальном уровне нужно передавать данные с сетевого уровня. При этом требуется, чтобы кадры не дублировались, и сохранялся порядок. Ниже представлены протоколы с различными допущениями о канале от самого простого случая (с идеальным каналом) к более сложным. Сначала даётся краткое словесное описание, затем сишный псевдокод, из которого всё понятно.
| |
| − | | |
| − | TODO: хорошо бы эти картиночки заменить на текст, но мне пока как-то не хочется этим заниматься.
| |
| − | | |
| − | ==== Общие объявления ====
| |
| − | [[Файл: Networks Link Layer Protocols Definitions.png]] | |
| − | | |
| − | [[Файл: Networks 1.5 Definitions.png]]
| |
| − | | |
| − | ==== Неограниченный симлексный протокол ====
| |
| − | Данные передаются в одном направлении. Время обработки равно нулю, буфер бесконечен, канал идеальный. Отправитель просто постоянно шлёт данные, получатель постоянно читает.
| |
| − | | |
| − | [[Файл: Networks 1.5 Protocol1.png]]
| |
| − | | |
| − | ==== Симлексный протокол с ожиданием ====
| |
| − | Всё то же самое, только теперь считаем, что получатель обрабатывает данные не моментально, поэтому посылающий не может постоянно слать данные. Для этого получатель будет слать подтверждение, а отправитель будет его дожидаться, прежде чем послать следующий пакет. Канал считаем идеальным.
| |
| − | | |
| − | [[Файл: Networks 1.5 Protocol2.png]]
| |
| − | | |
| − | ==== Симплексный протокол для замушлённых каналов ====
| |
| − | Теперь перестаём верить в идеальный канал, кадры могут теряться и искажаться (в том числе служебные). Проверку искажения кадра будем проводить уровнем ниже (сверять checksum). Чтобы обнаружить потерю кадра, запустим таймер и будем ждать подтверждение. Если подтверждения нет, а наступил таймаут, то кадр считаем потраченным и посылаем заново. Есть проблема: может потеряться подтверждение, в таком случае произойдёт дублирование кадра. Для этого добавим порядковый номер кадра и подтверждения. В этом случае принимающий будет знать, какой порядковый номер он ждёт, и игнорировать кадры с неправильным номером. Нетрудно понять, что для порядкового номера хватит одного бита.
| |
| − | | |
| − | [[Файл: Networks 1.5 Protocol3.1.png]]
| |
| − | | |
| − | [[Файл: Networks 1.5 Protocol3.2.png]]
| |
| − | | |
| − | ==== Протоколы скользящего окна ====
| |
| − | Симплексные протоколы — это плохо, потому что данные хотим посылать в обе стороны, а если сделать два отдельных канала, то получится дороже. В случае с дуплексными протоколами в обе стороны могут ходить и обычные кадры, и служебные (ACK). В заголовке кадра будем хранить kind, чтобы различать типы кадров. Есть техника piggybacking: если мы хотим послать подтверждение и обычный кадр, то пошлём их вместе (подтверждение положим в поле ACK в заголовке кадра). В таком варианте нужно заводить отдельный таймер на тот случай, когда от нас ждут подтверждение, а мы не хотим посылать обычный кадр (в этом случае мы просто пошлём кадр с подтверждением). То есть, если нам пришло сообщение, то мы либо довольно скоро захотим сами что-то послать и приложим подтверждение, либо просто пошлём подтверждение по тику таймера.
| |
| − | | |
| − | Следующие три протокола относятся к протоколам скользящего окна. Суть в том, чтобы хранить два окна (диапазона порядковых номеров кадров) — посылающее и принимающее. Окно хранит номера кадров, которые мы можем послать/принять. Когда сетевой уровень просит что-то послать, мы даём очередному кадру номер, равный верхней границе посылающего окна, и увеличиваем эту границу. При получении подтверждения увеличиваем нижнюю границу. При получении пакета из принимающего окна оно сдвигается на единицу. При получении пакета не из принимающего окна такой пакет игнорируется.
| |
| − | | |
| − | Это всё общая идея, перейдём к конкретным реализациям.
| |
| − | | |
| − | ===== Однобитовое окно =====
| |
| − | Простейший вариант, когда размер окна равен единице. В этом случае после отправки одного пакета мы не будем отправлять следующий, пока не получим подтверждения о доставке первого.
| |
| − | | |
| − | [[Файл: Networks 1.5 Protocol4.1.png]]
| |
| − | | |
| − | [[Файл: Networks 1.5 Protocol4.2.png]]
| |
| − | | |
| − | ===== Протоколы с возвратом на N =====
| |
| − | Если у нас есть большая пропускная способность, небольшие кадры и большое время прохождения сигнала, то пропускная способность будет использоваться очень слабо, так как большую часть времени мы будем ждать подтверждение, прежде чем посылать очередной кадр. Поэтому будем посылать сразу много кадров не дожидаясь доставки/потери предыдущего. Размер посылающего окна больше единицы (но ограничен какой-нибудь константой).
| |
| − | | |
| − | Есть два подхода к обработке ошибок. Первый называется возвратом на N. Если с каким-то из посланных кадров случилась беда, то все остальные посланные кадры игнорируются, что соответствует единичному размеру входящего окна. Через какое-то время проигнорированные кадры будут перепосланы отправителем. Это плохо в ситуации, когда возможно большое количество ошибок.
| |
| − | | |
| − | В реализации есть ещё одно нововведение: у сетевого уровня не всегда есть данные для передачи, поэтому он будет генерить событие, когда хочет что-то передавать. Также его можно выключить, чтобы он ничего не генерил, если у нас заполнено всё окно.
| |
| − | [[Файл: Networks 1.5 Protocol5.1.png]]
| |
| − | | |
| − | [[Файл: 2015-04-02-14-00-07_selection.png]]
| |
| − | | |
| − | [[Файл: Networks 1.5 Protocol5.3.png]]
| |
| − | | |
| − | [[Файл: Networks 1.5 Protocol5.4.png]]
| |
| − | | |
| − | ===== Протоколы с выборочным повтором =====
| |
| − | Второй вариант обработки ошибок называется выборочным повтором. Если потерялся/повредился кадр, то все следующие за ним получатель не игнорирует, а буферизует и шлёт на них подтверждения. Сломанный кадр будет перепослан, после чего получатель сможет восстановить нужную последовательность. Доставленные кадры перепосылать не потребуется.
| |
| − | | |
| − | Также можно посылать отрицательное подтверждение (NAK), в этом случае отправитель перепошлёт потерянный кадр до истечения таймаута.
| |
| − | | |
| − | [[Файл: Networks 1.5 Protocol6.1.png]]
| |
| − | | |
| − | [[Файл: Networks 1.5 Protocol6.2.png]]
| |
| − | | |
| − | [[Файл: Networks 1.5 Protocol6.3.png]]
| |
| − | | |
| − | [[Файл: Networks 1.5 Protocol6.4.png]]
| |
| − | | |
| − | ==== Верификация протоколов ====
| |
| − | Нам про это очень мало рассказывали.
| |
| − | | |
| − | ===== Конечные автоматы =====
| |
| − | Состояние процесса будет хранить в себе значения всех переменных в программе. Также будет состояние канала (какой кадр передаётся и передаётся ли). Множество переходов — все возможные переходы между состояниями вследствие каких-либо событий. Также пометим начальные состояния. Получим автомат, в котором можно анализировать достижимость различных состояний. Возможны следующие ошибки:
| |
| − | * состояние, в котором нельзя определить, куда переходить (неполнота протокола)
| |
| − | * состояние, из которого нет выхода (тупик)
| |
| − | * состояние с переходом по событию, которое никогда не может произойти (лишний переход).
| |
| − | | |
| − | Анализ достижимости позволяет обнаружить такие проблемы.
| |
| − | | |
| − | ===== Сети Петри =====
| |
| − | Нам про это два слова сказали, так что вряд ли понадобится. Есть в Таненбауме, если очень нужно.
| |
| − | | |
| − | === 6. Модель OSI. Канальный уровень (контроль и исправление ошибок). ===
| |
| − | === 7. Модель OSI. Канальный уровень (мосты). ===
| |
| − | === 8. Модель OSI. Физический уровень (введение). ===
| |
| − | === 9. Модель OSI. Физический уровень (проводные сети). ===
| |
| − | === 10. Модель OSI. Физический уровень (оптоволоконные сети). ===
| |
| − | === 11. Ethernet. ===
| |
| − | === 12. Bluetooth. ===
| |
| − | === 13. Виртуальные локальные сети. ===
| |
| − | Тут всё понятно написано: [http://xgu.ru/wiki/VLAN Xgu.ru {{---}} VLAN]
| |
| − | | |
| − | Ещё ссылка: [http://www.intuit.ru/studies/courses/3591/833/lecture/14258 intuit.ru {{---}} VLAN]
| |
| − | | |
| − | === 14. Протоколы стандарта 802.11*. ===
| |
| − | | |
| − | == Блок 2. ==
| |
| − | | |
| − | === 1. Модель OSI. Сетевой уровень (введение, сервисы). ===
| |
| − | * Сетевой уровень решает задачу доставки пакетов от отправителя до получателя.
| |
| − | * Сетевой уровень прокладывает маршрут на всём протяжении следования информации.
| |
| − | * Сетевой уровень должен обеспечить независимость предоставления своих сервисов от низлежащих технологий.
| |
| − | * Сетевой уровень обеспечивает распределение нагрузки на маршрутизаторы и линии связи.
| |
| − | | |
| − | Сетевой уровень оперирует пакетами. Наиболее известный протокол сетевого уровня — IP. На сетевом уровне работают маршрутизаторы.
| |
| − | | |
| − | Задачи, ставившиеся при разработке сервисов сетевого уровня:
| |
| − | * Сервисы сетевого уровня не должны зависеть от технологии маршрутизатора.
| |
| − | * Транспортный уровень должен быть независим от количества, типа и топологии присутствующих сетей с маршрутизаторами.
| |
| − | * Сетевые адреса, доступные транспортному уровню, должны использовать единую систему нумерации в локальных и глобальных сетях.
| |
| − | | |
| − | Возможны два типа сервисов:
| |
| − | * Маршрутизатор только перемещает пакет с места на место, подсеть изначально обладает ненадёжностью, и хосты должны сами учитывать ошибки и управлять потоком. Каждый пакет содержит адреса отправителя и получателя, в таблицах коммутации на маршрутизаторах указано, куда пересылать пакет в зависимости от получателя.
| |
| − | * Надёжный, ориентированный на соединение сервис, с обеспечением качества обслуживания. Предварительно устанавливается виртуальный канал, по которому в дальнейшем пойдут всё пакеты. Это позволяет сразу договориться о маршруте следования и о различных параметрах.
| |
| − | | |
| − | Принципиальные отличия представлены в таблице:
| |
| − | [[Файл: Networks 2.1 Comparison.png]]
| |
| − | | |
| − | Ещё раз вкратце: сетевой уровень прежде всего должен прокладывать маршрут между узлами. Если на канальном уровне мы просто передавали пакет с одного конца провода на другой, то на сетевом мы уже хотим передавать данные по большой сети, то есть не факт, что напрямую. Помимо этого хорошо бы стараться равномерно распределять нагрузку на узлы. Ещё одна проблема для сетевого уровня состоит в том, что разные узлы могут находиться в разных сетях, с разными гарантиями от канального уровня.
| |
| − | Есть два подхода: дейтаграмный и с установлением канала. В первом случае мы не тратим время на установку соединения, не боимся отказа узла. Во втором случае получаются поменьше пакеты, не нужно каждый раз думать, куда пересылать пакет, можно боговорить параметры передачи (для обеспечения QoS, например).
| |
| − | | |
| − | === 2. Модель OSI. Сетевой уровень (алгоритмы маршрутизации). ===
| |
| − | === 3. Модель OSI. Сетевой уровень (алгоритмы борьбы с перегрузкой). ===
| |
| − | === 4. Модель OSI. Сетевой уровень (качество обслуживания). ===
| |
| − | === 5. Модель OSI. Сетевой уровень (объединение сетей). ===
| |
| − | === 6. Мультикаст. Мультикаст маршрутизация. ===
| |
| − | === 7. IPv4. Основы. ===
| |
| − | === 8. IPv4. Маршрутизация. ===
| |
| − | === 9. Управляющие протоколы Internet. ===
| |
| − | === 10. Протоколы внешнего и внутреннего шлюза. ===
| |
| − | === 11. IPv6. ===
| |
| − | === 12. Модель OSI. Транспортный уровень (сервисы, примитивы, элементы транспортных протоколов). ===
| |
| − | === 13. TCP/IP. UDP. ===
| |
| − | === 14. TCP/IP. TCP (принцип работы, основы). ===
| |
| − | === 15. TCP/IP. TCP (модификации). Производительность транспортного уровня. ===
| |
| − | === 16. SCTP (основы, свойства, отличия). ===
| |
| − | '''SCTP''' ('''Stream Control Transmission Protocol''' {{---}} протокол передачи с управлением потока) {{---}} протокол транспортного уровня. Выполняет те же функции, что и протоколы TCP и UDP. Но объединяет при этом их преимущества, лишает недостатков и добавляет новые возможности.
| |
| − | | |
| − | Отличия от протоколов TCP и UDP:
| |
| − | | |
| − | [[Файл:SctpTable.png]]
| |
| − | | |
| − | Основные преимущества (пояснения к таблице):
| |
| − | * Сохранение границ {{---}} в протоколе TCP данные передаются непрерывным потоком байт, читаются так же, поэтому программист должен сам следить за тем, как расставлять границы в этом потоке и разделать куски данных. SCTP позволяет ставить границы и обрабатывать данные пакетами, как в UDP. Но при этом гарантирует порядок доставки пакетов, обеспечивает надёжность и ориентирован на соединения. Упорядоченность пакетов, кстати, можно отключить для повышения скорости.
| |
| − | * Multihoming (''многолинейность, множественная адресация'', см. иллюстрацию ниже) {{---}} SCTP позволяет устанавливать соединение к одному серверу по разным линиям связи (например, по Wi-Fi и по Ethernet). Таким образом, если одна линия связи отвалится (скорей всего Wi-Fi), то соединение не разорвётся. Это так же позволяет передавать данные сразу по нескольким линиям, что увеличивает скорость передачи. Если в TCP одна линия связи оборвётся, то соединение будет потеряно, придётся устанавливать новое.
| |
| − | | |
| − | [[Файл:Multihoming.png]]
| |
| − | | |
| − | * Multithreading (''многопоточность'') {{---}} позволяет передавать несколько потоков в рамках одной ассоциации (ассоциацией в SCTP называется соединение между двумя хостами). Например в TCP данные и служебная информация передаются по одному соединению. Поэтому задержка в получении служебнной информации может быть вызвана текущей передачей данных (например, ACK может не прийти вовремя, поэтому мы пошлём дупликат). Такая проблема называется ''head-of-line blocking, HOL''. Многопоточность позволяет передавать эти данные независимо, что приведёт к лучшему использованию доступных ресурсов.
| |
| − | * 4-way handshake {{---}} протокол TCP подвержен SYN-flood атакам. Злоумышленник шлёт много пакетов в короткое время для запроса TCP соединения (запрос на соединение помечен битом SYN в заголовке, поэтому и SYN-flood). Но при этом не подтверждает установление соединения. Таким образом на сервере образуются полуоткрытые соединения. Они закрываются сами по истечению таймаута. Но цель злоумышленника состоит в том, чтобы создать как можно больше таких соединений, не давая тем самым создавать новые валидные соединения из-за ограничения в их количестве на стороне сервера (сервер не может иметь бесконечное число соединений, а если сделать таймаут на обрыв слишком маленьким, то валидные соединения могут отваливаться раньше времени, что тоже нехорошо, и это всё делает syn-атаки возможными). В SCTP используется не тройное рукопожатие, а четверное (из разряда: "я хочу установить соединение - ты точно хочешь установить соединение? - да, я точно хочу установить соединение - ну тогда ладно"). Таким образом за короткий промежуток времени нельзя создать много новых соединений.
| |
| − | | |
| − | [[Файл:Synfloodsctp.png]]
| |
| − | | |
| − | * В SCTP не бывает полузакрытых соединений, как в TCP. Если мы закрываем соединение, то сразу в обе стороны.
| |
| − | | |
| − | К сожалению, несмотря на все преимущеста, протокол SCTP не получил пока широкого распространения. Это связано с инертностью (TCP работает, зачем менять?) и сложностью поддержки на аппаратном уровне (например, вся обёртка сетевых протоколов, те же фаерволы, имеют правила в духе "пропускать только UDP, TCP" пакеты; для примера можно вспомнить, как это используется в NAT).
| |
| − | | |
| − | == Блок 3. ==
| |
| − | | |
| − | === 1. Служба DNS. Пространство имен в Internet. ===
| |
| − | === 2. Служба электронной почты. ===
| |
| − | === 3. WWW. HTTP. Основы и развитие. ===
| |
| − | Таненбаум 5 издание
| |
| − | | |
| − | 685 - 692 www, архитектура, клиентская часть,
| |
| − | | |
| − | 695 - 698 серверная часть
| |
| − | | |
| − | 724 - 727 http
| |
| − | | |
| − | 731 - 733 кеширование
| |
| − | | |
| − | === 4. FTP. Telnet. SSH. ===
| |
| − | === 5. Авторизация. Аутентификация. Аудит. Radius. Diameter. ===
| |
| − | === 6. Шифрование. Алгоритмы с симметричным ключом. ===
| |
| − | === 7. Шифрование. Алгоритмы с открытым ключом. ===
| |
| − | === 8. Шифрование. Цифровые подписи. ===
| |
| − | === 9. Шифрование. Системы управления открытыми ключами. ===
| |
| − | === 10. TLS. IPsec. Основы, отличия. IPv6 и шифрование. ===
| |
| − | === 11. Протоколы аутентификации. ===
| |
| − | === 12. Firewall. Концепция, примеры. ===
| |
| − | === 13. SIP. Телефония поверх IP. ===
| |
| − | === 14. Одноранговые сети. ===
| |
| − | === 15. Сетевые атаки. Классификация, описания. ===
| |
| − | === 16. Мультимедиа поверх IP. RTSP. ===
| |
