Различия между версиями 5 и 6
Версия 5 от 2008-07-03 00:30:14
Размер: 6526
Редактор: Allena
Комментарий:
Версия 6 от 2008-07-03 00:35:48
Размер: 6550
Редактор: PavelSutyrin
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 40: Строка 40:
|| 0 || 1 || 1 || 1 || || 1 || || || || 0 || 1 || 1 || 1 || || 1 || PavelSutyrin || 03.06.2008 ||

Транспортный уровень

Поднимаемся на уровень TCP.

Итак, проблема заключается в том, что есть возможность отправить пакет абоненту, но не гарантировать доставку. На данном уровне возникает 5 задач:

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

сборки сообщения из пакетов.

  • Перед тем как отправлять данные нужно удостовериться, что абонент существует и может их принять.
  • Обеспечить возможность манипулирования потоками данных.

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

TCP

Вопрос: а в действительности ли каждые из 5 требований нужно реализовывать, когда мы хотим передавать данные? Если вся информация, которую мы хтим отправить, помещается в один пакет (датаграмму), то, возможно всё это использовать не надо. Поэтому, на уровне TCP есть всего два протокола: надёжный TCP и ненадёжный UDP. TCP начинается с уст. подключения, и, прежде чем процедура подкл. не произойдёт, ничего не может начться. при этом, процедура подключения двусторонняя. То есть, данные передаются в обе стороны. TCP устроен по принципу подтверждений. Каждый TCP-пакет, после того, как он принят сервером, на него генерируется подстверждение, что он принят, в проивном случае (сразу или по таймауту) происходит извещ. об ошибке. При этом процесс симметричный. Более, того подтв. могут совмещаться с данными. Все TCP-пакеты пронумерованы, есть понятие seqno, и в каждом их два, увеличиваются они на размер переданных данных. Это одновременно позволяет вычислять последовательность пакетов и позволяет выяснять, что пропало и не сдублировался ли пакет. Везде считается checksum, что касается отслеж. сост канала, то тут довольно хитрая технология, в которой поначалу обмен идёт маленькими пакетами, но далее размер увеличивается.

Для того, чтобы выполнить задачу разделения данных, появляется ещё одно понятие --- порт. Придумано оно по аналогии с портами ввода-вывода. Когда происх. соед. между клиентом и сервером, то происх. соед. по определённому порту. Когда происх. пдоключение, то у сервера порт 22, а у клиента случайный, (44670), что пзволяет разделять потоки даже в случяае нескольких подключений между двумя машинами.

Почему лектор говорит, что порт это переходный уровень между TCP и уровнем приложений? Потому что согл. нек. договорённостям, рахные типы приложений сидят на разных портах. Почему так? Да потому что никакого другого способа определить, как подключаться к определённому порту, нет. Есть организация IANA, котрая регистрирует эти порты (cat /etc/services).

Вопросы

В чём разница между TCP-пакетами и UDP-датаграммами?

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


Сведения о ресурсах

Готовность (%)

Продолжительность (ак. ч.)

Подготовка (календ. ч.)

Полный текст (раб. д.)

Предварительные знания

Level

Maintainer

Start date

0

1

1

1

1

PavelSutyrin

03.06.2008


PspoClasses/080702/05TCP (последним исправлял пользователь eSyr 2009-03-22 23:06:33)