24. Протокол icmp (Лекция 21)

Тип сообщения – говорит о том, что произошло в сети (какая ошибка или действие по диагностике пытаются выполнить)

Код сообщения – более подробно описан тип ошибки или ее причина и диагностическое действие.

Контрольная сумма – используется для проверки правильности доставки.

4 байта – служебная инфа

Поле данных – фрагмент пакета, при передаче которого возникла ошибка

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

Тип 13 и 14 – для проверки быстродействия сети.

Тип 3 – сообщение об ошибке, когда узел недостижим.

Тип 5 – сообщение о новом маршруте. Позволяет быстрее попасть к необходимой сети.

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

Тип 10 – при подключении компа к сети, чтобы не ждать рассылки о типе маршрутизатора от самого маршрутизатора, комп сам может отправить такой запрос.

Тип 11 – если маршрутизатор отбросил пакет, время жизни которого истекло (при возникновении петли).

Тип 12 – говорит о том, что в заголовке IP какая-то ошибка и маршрутизатор не может отправить такой пакет.

Большая часть пакетов ICMP формируются и отправляется автоматически сетевым оборудованием, но можно применить утилиты своими руками.

Пример использования:

Пример:

25. Транспортный уровень модели osi (Лекция 22)

Разобрал выше

26. Протокол udp (Лекция 23)

TCP – надежная доставка данных

UDP – не обеспечивает надежной доставки данных.

Дейтаграмма – короткое сообщение, которое доставляется быстро.

Зачем нам протокол транспортного уровня, если он не обеспечивает надежность доставки выше, чем IP, почему нельзя использовать просто IP для передачи данных?

Но на транспортном уровне нам необходимо указать порт отправителя и порт получателя. Именно это и делает UDP.

В качестве примера работы UDP рассмотрим систему доменных имен DNS:

В системе DNS есть сервер, который знает, какие IP адреса соответствуют доменным именам и клиент DNS, который хочет получить такую информацию. Клиент DNS отправлет запрос на сервер и спрашивает, какой IP у такого-то сайта. Сервер получает запрос, находит нужный IP и отправляет ответ.

Т.к. взаимодействие происходит по протоколу UDP – нужно всего 2 дэйтаграммы.

Если бы был TCP – нужно было бы больше сообщений: перед тем, как запрашивать IP, нужно было бы установить соединение TCP (для этого нужно 3 сообщения), запросить адрес получить ответ – еще два и потом разорвать соединение – еще 3 или 4 сообщения.

Что произойдет, если запрос потерялся?

Приложение клиента DNS после отправки запроса запускает таймер, если ответ не пришел – таймер сработает и тот же запрос отправляется повторно.

Недостаток в том, что приложение само должно обрабатывать такие ошибки.

27. Протокол tcp. Обеспечение надежности доставки данных (Лекция 24)

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

В протоколе TCP такой поток делится на отдельные части – сегменты.

Гарантия доставки данных в TCP:

Отправитель посылает по сети некоторый сегмент данных. Получатель принимает сегмент и посылает отправителю подтверждение. Затем отправляется следующий сегмент данных и снова ответ в виде подтверждения и т.д.:

Что происходит, если при передаче данных произошла ошибка?

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

В протоколе TCP используется скользящее окно – подтверждается не каждый сегмент, как в рассмотренном выше примере, а несколько сегментов, отправленных друг за другом:

Для примера скользящее окно сравнивается с остановкой и ожиданием (используется на канальном уровне в Wi-Fi).

Остановка и ожидание: отправитель отправил данные и останавливается, пока не получит подтверждение. Приходит подтверждение – снова отправляет данные.

Скользящее окно: отправитель передает порцию данных не дожидаясь подтверждения. Получатель отправляет одно кумулятивное подтверждение. Это означает, что получатель получил последнюю порцию данных и все предыдущие.

Почему на транспортном уровне эффективно использовать скользящее окно?

Почему называется скользящим окном?

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

Причина дублирования сегментов:

Механизм защиты от дублирования:

В TCP нумеруются байты.

В примере 4 сегмента, в первом байты от 0 до 1023, во втором от 1024 до и т.д.

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

Получатель отправляет подтверждение, в которое включает номер следующего первого байта, который он ждет:

Получатель всегда может выставить байты в правильной последовательности.

Как решается проблема дублирования:

Получатель будет видеть, что байт заново отправленного сегмента у него уже есть и игнорирует такой сегмент.

Как же устанавливается соединение?

Отправитель отправляет запрос на установку соединения SYN, также в сегмент включается порядковый номер передаваемого байта. Получатель в ответ передает сообщение SYN, куда включает подтверждение о получении предыдущего сообщения ACK и порядковый номер байта, который он ожидает (7538) + включает в сегмент номер байта в потоке байт (36829).

Дальше пересылается получение подтверждения ACK.

После этого соединение считается установленным.