Участник:Shersh/Билеты к экзамену по сетям

Блок 1.

5. Модель OSI. Канальный уровень (протоколы).

Удобнее всего будет привести протоколы в виде псевдокода (хотя это валидный сишный код, кажется). От самого простого к более сложным.

TODO: хорошо бы эти картиночки заменить на код, но мне пока как-то не хочется этим заниматься.

Общие объявления

Неограниченный симлексный протокол

Данные передаются в одном направлении. Время обработки равно нулю, буфер бесконечен, канал идеальный.

Симлексный протокол с ожиданием

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

Симплексный протокол для замушлённых каналов

Теперь перестаём верить в идеальный канал, кадры могут теряться и искажаться (в том числе служебные). Введём порядковые номера для сообщений и будем посылать их в подтверждениях. Если нам пришло подтверждение с тем же номером, что и у отправленного кадра, то всё ок. В псевдокоде для простоты порядковый номер — 0 или 1. Также будем запускать таймер, чтобы понимать, что сообщение потерялось.

Протоколы скользящего окна

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

Протоколы с возвратом на N

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

Возврат на n подразумевает, что если бы повреждён какой-то кадр (не пришло подтверждение/не сошлась checksum), то все кадры с большими номерами игнорируются, подтверждения на них не посылаются. Отправитель должен будет перепослать испорчённый кадр и все за ним.

Альтернативный вариант (выборочный повтор) — буферизовать все кадры после ошибочного. В таком случае отправитель перепошлёт только испорченные кадры. Можно послать отрицательное подтверждение (NAK) для испорченного кадра, в этом случае отправитель сразу же перепошлёт повреждённый кадр.

TODO

Протоколы с выборочным повтором

TODO

Верификация протоколов

TODO

13. Виртуальные локальные сети.

Тут всё понятно написано: Xgu.ru — VLAN

Ещё ссылка: intuit.ru — VLAN

Блок 2.

1. Модель OSI. Сетевой уровень (введение, сервисы).

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

Сетевой уровень оперирует пакетами. Наиболее известный протокол сетевого уровня — IP. На сетевом уровне работают маршрутизаторы.

Задачи, ставившиеся при разработке сервисов сетевого уровня:

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

Возможны два типа сервисов:

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

Принципиальные отличия представлены в таблице:

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

16. SCTP (основы, свойства, отличия).

SCTP (Stream Control Transmission Protocol — протокол передачи с управлением потока) — протокол транспортного уровня. Выполняет те же функции, что и протоколы TCP и UDP. Но объединяет при этом их преимущества, лишает недостатков и добавляет новые возможности.

Отличия от протоколов TCP и UDP:

Основные преимущества (пояснения к таблице):

• Сохранение границ — в протоколе TCP данные передаются непрерывным потоком байт, читаются так же, поэтому программист должен сам следить за тем, как расставлять границы в этом потоке и разделать куски данных. SCTP позволяет ставить границы и обрабатывать данные пакетами, как в UDP. Но при этом гарантирует порядок доставки пакетов, обеспечивает надёжность и ориентирован на соединения. Упорядоченность пакетов, кстати, можно отключить для повышения скорости.
• Multihoming (многолинейность, множественная адресация, см. иллюстрацию ниже) — SCTP позволяет устанавливать соединение к одному серверу по разным линиям связи (например, по Wi-Fi и по Ethernet). Таким образом, если одна линия связи отвалится (скорей всего Wi-Fi), то соединение не разорвётся. Это так же позволяет передавать данные сразу по нескольким линиям, что увеличивает скорость передачи. Если в TCP одна линия связи оборвётся, то соединение будет потеряно, придётся устанавливать новое.

• Multithreading (многопоточность) — позволяет передавать несколько потоков в рамках одной ассоциации (ассоциацией в SCTP называется соединение между двумя хостами). Например в TCP данные и служебная информация передаются по одному соединению. Поэтому задержка в получении служебнной информации может быть вызвана текущей передачей данных (например, ACK может не прийти вовремя, поэтому мы пошлём дупликат). Такая проблема называется head-of-line blocking, HOL. Многопоточность позволяет передавать эти данные независимо, что приведёт к лучшему использованию доступных ресурсов.
• 4-way handshake — протокол TCP подвержен SYN-flood атакам. Злоумышленник шлёт много пакетов в короткое время для запроса TCP соединения (запрос на соединение помечен битом SYN в заголовке, поэтому и SYN-flood). Но при этом не подтверждает установление соединения. Таким образом на сервере образуются полуоткрытые соединения. Они закрываются сами по истечению таймаута. Но цель злоумышленника состоит в том, чтобы создать как можно больше таких соединений, не давая тем самым создавать новые валидные соединения из-за ограничения в их количестве на стороне сервера (сервер не может иметь бесконечное число соединений, а если сделать таймаут на обрыв слишком маленьким, то валидные соединения могут отваливаться раньше времени, что тоже нехорошо, и это всё делает syn-атаки возможными). В SCTP используется не тройное рукопожатие, а четверное (из разряда: "я хочу установить соединение - ты точно хочешь установить соединение? - да, я точно хочу установить соединение - ну тогда ладно"). Таким образом за короткий промежуток времени нельзя создать много новых соединений.

• В SCTP не бывает полузакрытых соединений, как в TCP. Если мы закрываем соединение, то сразу в обе стороны.

К сожалению, несмотря на все преимущеста, протокол SCTP не получил пока широкого распространения. Это связано с инертностью (TCP работает, зачем менять?) и сложностью поддержки на аппаратном уровне (например, вся обёртка сетевых протоколов, те же фаерволы, имеют правила в духе "пропускать только UDP, TCP" пакеты; для примера можно вспомнить, как это используется в NAT).