Различия между версиями 11 и 12
Версия 11 от 2008-07-03 01:16:07
Размер: 5769
Редактор: Allena
Комментарий:
Версия 12 от 2008-07-03 01:18:02
Размер: 17437
Редактор: PavelSutyrin
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 2: Строка 2:
Поднимаемся на уровень TCP.
Строка 4: Строка 3:
Итак, проблема заключается в том, что есть возможность отправить пакет абоненту, но не гарантировать доставку. На данном уровне возникает 5 задач: {02:49:55}

Поднимаемся на уровень TCP. Напоминаю, в чем проблема. Разумеется, мы можем
доставить пакет до нашего абонента, скажем так, у нас есть такая возможность,
вопрос в том, эта возможность вообще случилась, или ее не случилось?
Строка 8: Строка 11:
 * Если сообщение большое, нужно разбить его на пакеты так, чтобы абонент затем мог восстановить исходные данные. То есть, пакет доставлен, или не доставлен? И это вопрос важный, вопрос
качества нашего сетевого всего. Соответственно, было бы очень неплохо для
отслеживания качества а также и по всяким другим причинам при передаче данных,
точнее при обмене данными получать подтверждения о том, что переданные с нашей
стороны данные получены. Это раз. Вот абонент получил данные, он отправляет
подтверждение. Мы получили подтверждение -- отправляем следующий кусок.
Строка 10: Строка 18:
 * Если отправленное сообщение было разбито на несколько пакетов, то на стороне абонента должен быть механизм проверки все ли пакеты пришли и механизм сборки сообщения из пакетов.  * Если сообщение большое, нужно разбить его на пакеты так, чтобы
 абонент затем мог восстановить исходные данные.
Строка 12: Строка 21:
 * Перед тем как отправлять данные нужно удостовериться, что абонент существует и может их принять.  * Если отправленное сообщение было разбито на несколько пакетов,
 то на стороне абонента должен быть механизм проверки все ли
 пакеты пришли и механизм сборки сообщения из пакетов.

Надо предусмотреть ситуацию, когда мы отправили, абонент ничего не получил.
Вот мы берем, распиливаем нашу информацию на четыре пакеты, эти четыре пакета
последовательно отпралвяем, 1-й, 2-й приходят, 3-й не приходит, 4-й приходит.
Это уже вопрос манипулирования потоком данных. Мы должны предсумотреть
механизм объединения этих четырех пакетов в поток так, чтобы наш получатель
понял, что он не получил именно 3-й пакет, что тот 4-й, который он получил, он
именно 4-й. А не то в результате причуд маршрутизации сначала придет 4-й, а
потом 3-й, например. Чтобы не перемешались наши стрелочки и наше повидло.

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

Далее, было бы неплохо, перед тем как передавать данные, а может быть не
далее, может быть с этого стоит начать, перед тем как передавать данные,
убедиться, в том, что есть кому их принимать. Понимаете, да, вот у нас есть
абонент, который неизвестно, есть он на свете или нет, вот неизвестно,
существует ли абонент под названием 158.250.10.1, мы этого не знаем, где-то
вот тут вот (показывает на середину маршрута?) мы прекратили маршрут мы
прекратили об этом знать. Это вопрос о подключении, нам нужно подключаться к
абоненту, то есть прежде чем начать передавать данные, обменяться с этим
абонентом всякой информацийе, в том числе о том, существует ли он на свете,
это очень важная информация, если такой абонент нам ответил, то наверное, он
существует, или перед ним стоит (?).
Строка 16: Строка 51:
Возникает вопрос -- всегда ли необходимо решение всех 5 задач? Если вся информация, которую надо передать, помещается в один пакет(датаграмму), то можно выбрать более простой путь. Поэтому на уровне TCP существуют два протокола: надёжный, TCP и ненадежный, UDP. Возникает вопрос -- всегда ли необходимо решение всех 5
задач? Если вся информация, которую надо передать, помещается
в один пакет(датаграмму), то можно выбрать более простой
путь. Поэтому на уровне TCP существуют два протокола: надёжный,
TCP и ненадежный, UDP.
Строка 18: Строка 57:
Протокол TCP начинается с подключения. Процедура подключения двухсторонняя. Что я сказал? Надежность, подключение, подтвеждение, ну и манипуляция потоками
данных, когда мы передаем сразу два потока данных, было бы неплохо сделать
так, чтобы они друг от друга отличались. Балансировка не тут. Тут
исключительно вопрос о качестве канала, вот в ipv6 есть балансировка нагрузки
встроенная в ip, ну, не в ip, а в соотв. уровень. (...) Дело не в балансировке, а в
подборе нагрузки, там окно, но я не хочу про него говорить, это слишком круто
для той темы, которую мы сейчас затронули. Значит да, возвращаясь к нашим
баранам.
Строка 20: Строка 66:
TCP устроен по принципу подтверждений. После получения TCP-пакета отсылается подтверждение получения. Если подтверждения не получено в течении определенного времени(таймаута), происходит извещение об ошибке. Этот процесс симметричен. Подтверждения могут совмещаться с данными. Итак, хорошо, давайте впишем:
Строка 22: Строка 68:
Все TCP-пакеты пронумерованы. Есть понятие seqno.В каждом их два, и они увеличиваются на размер переданных данных. Это позволяет как устанавливать последовательность пакетов, так и диагностировать потерю или дублирование пакета.  * подключение
 * подтверждение доставки
 * контроль за целостностью данных
 * различение потоков данных (манипуляция каналами)
 * отслеживание качества канала
Строка 24: Строка 74:
Везде считается checksum. Вот эти 5 задач хотелось бы решить на том уровне, на котором мы занимаемся
решением вопросами доставки. Вот они здесь все и перечислены, качество с
одной стороны, а сами потоки с другой стороны. У меня вопрос, риторический,
т.к. многие знают на него ответ. А в действительности эти 5 требований,
дейсвительно ли их каждый раз нужно реализовывать, когда мы обеспечиваем
доставку?
Строка 26: Строка 81:
Для отслеживания состояния канала используется довольно хитрая технология -- сначала идет обмен маленькими пакетами, затем размер пакетов постепенно увеличивается. Да, вы в курсе ответа на этот вопрос, что помимо TCP существует еще и UDP.
Мы согласились, что не всегда это надо, вопрос, когда это не надо.
Когда это не столь критично? А когда это не столь критично? Я могу вообразить
ситауцию, когда это абсолютно бессмысленно. У нас есть пакет. Предположим, мы
хотим послать один пакет. Зачем нам организация из него потока данных, он
один? Зачем нам отслеживание качества канала? Мы его уже послали. Один пакет.
Вот если бы его было, там, 1000, мы бы как-то сбалансировали это дело, а если
он один, вот как мы его послали, не зная о том, кто с той стороны, так мы его
и послали. Зачем нам подключение, ну послали мы его. Короче говоря, если
цельность данных и... короче, если вся информация, которую мы собираемя
передавать, умещается в один акт передачи данных ,скорее всего, ничего из
вышеперечисленного делать не нужно, но может быть и стоит это сделать, но
стоит переложить на вышележащий протокол. Ну пускай там наверху проверят, что
там можно проверить. checksum проверит и на udp, не волнуйтесь. Пускай на
протоколе уровнем выше, в случае если... да ничего нельзя сделать. Ну вот не
дошел один-единственный пакет, ну как наш абонент узнает, что до него этот
пакет не дошел?
Строка 28: Строка 99:
А в случае, если с соединеием, если не дошел первый пакет. Он первый, вот он
не дошел. Как у нас абонент узнает, что до него не дошел первый пакет?
Еще раз, когда соединение устаналивается, то должен сначал первый пакет дойти.
(Таймаут). Анекдот рассказываю. Два мужика купили много водки, пили, пили,
пили, один говорит: меня сморило, я тут посплю, а когда я захочу выпить, ты
меня разбуди. Друг, как же я узнаю, когда ты захочешь пить? Чудак, ты меня
разбуди. Так вот, такая же история. Как абонент узнает, что до него не дошел первый
пакет соединения? Как второй не дошел -- понятно, до него дошел первый, он ждет второго, а
первый он как узнает?
Строка 29: Строка 109:
Для решения задачи разделения данных вводится еще одно понятие -- порт. Оно придумано по аналогии с портами ввода-вывода. Соединение между клиентом и сервером происходит по определенному порту. Например, при соединении, на одной из машин используется 22 порт, на другой -- случайный. Это позволяет разделять потоки даже в случае нескольких соединений между двумя машинами. Короче говоря, если все данные, которые мы хотим переслать, умещаются в один
пакет, так называемую датаграмму, это такая монада, самодостаточная, в этом
случае нам нечего проверять и устанавливать, потому что проверка и
установления это тоже такая своеобразная датаграмма, ну и какая разница, так
мы две пошлём, а так одну. (А как мы узнаем, доёдет эта передача одного
пакета, или не дойдёт?.) А она ненадёжная. Соединеия не произошло.
Единственное, Жень, я понимаю, о чем вы думаете, это на уровне прикладном
организовать подтверждение какое-нибудь, если мы того хотим, и так сказать,
очень много протоколов, работающих на udp так и делают. Допустим, какой-нибудь
dns, допустим -- запрос-ответ, вот вам потдверждение, ответ пришел, значит
подтверждение.
Строка 31: Строка 121:
Система портов -- переходной уровень между TCP и урофнем приложений. Согласно некоторым договоренностям разные типы приложений слушают разные порты. Другого способа определить, к какому порту нужно подключаться -- не существует. Есть организация IANA, регистрирующая порты. Список приложений и использующихся ими портов всегда можно увидеть по cat /etc/services. Так вот, именно по этой причине если не уровне IP куча всяких протоколов, там
есть еще всякие туннелирования специальные несколько штук, 2tp (?) модные
нынче, то на уровне TCP их всего два. Один из них все эти 5 свойств, которые
мы перечислили, поддерживает и называется он TCP, а другой из них ни одного из
них не поддерживает, потому что там все зключено в одной посылке данных, и
назыается он UDP.

{03:00:50}

TCP

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

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

Почему лектор говорит, что порт это переходный уровень между TCP и уровнем приложений? Потому что согл. нек. договорённостям, рахные типы приложений сидят на разных портах. Почему так? Да потому что никакого другого способа определить, как подключаться к определённому порту, нет. Есть организация IANA, котрая регистрирует эти порты (cat /etc/services).
Строка 37: Строка 142:
Они нужны для разных вещей. Например, при задаче широковещания не нужны ни сообщения о доставке, ни сообщения об ошибках. Другой случай --- маленькие пакеты, на которые всегда должен быть какй-то ответ. Ещё один юзкейс --- медленные обработка и ответ. Они нужны для разных вещей. Например, при задаче широковещания не нужны не сообщ. о доставке, ни сообщ. об ошибках. Другой случай --- маленькие пакеты, на которые всегда должен быть какй-то ответ. Ещё один юзейс --- медленные обработка и ответ.
Строка 44: Строка 149:
|| 20 || 1 || 1 || 1 || || 1 || PavelSutyrin || 03.06.2008 || || 0 || 1 || 1 || 1 || || 1 || PavelSutyrin || 03.06.2008 ||

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

{02:49:55}

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

  • Нужно обеспечить подтверждение получения данных.

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

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

Надо предусмотреть ситуацию, когда мы отправили, абонент ничего не получил. Вот мы берем, распиливаем нашу информацию на четыре пакеты, эти четыре пакета последовательно отпралвяем, 1-й, 2-й приходят, 3-й не приходит, 4-й приходит. Это уже вопрос манипулирования потоком данных. Мы должны предсумотреть механизм объединения этих четырех пакетов в поток так, чтобы наш получатель понял, что он не получил именно 3-й пакет, что тот 4-й, который он получил, он именно 4-й. А не то в результате причуд маршрутизации сначала придет 4-й, а потом 3-й, например. Чтобы не перемешались наши стрелочки и наше повидло.

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

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

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

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

Что я сказал? Надежность, подключение, подтвеждение, ну и манипуляция потоками данных, когда мы передаем сразу два потока данных, было бы неплохо сделать так, чтобы они друг от друга отличались. Балансировка не тут. Тут исключительно вопрос о качестве канала, вот в ipv6 есть балансировка нагрузки встроенная в ip, ну, не в ip, а в соотв. уровень. (...) Дело не в балансировке, а в подборе нагрузки, там окно, но я не хочу про него говорить, это слишком круто для той темы, которую мы сейчас затронули. Значит да, возвращаясь к нашим баранам.

Итак, хорошо, давайте впишем:

  • подключение
  • подтверждение доставки
  • контроль за целостностью данных
  • различение потоков данных (манипуляция каналами)
  • отслеживание качества канала

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

Да, вы в курсе ответа на этот вопрос, что помимо TCP существует еще и UDP. Мы согласились, что не всегда это надо, вопрос, когда это не надо. Когда это не столь критично? А когда это не столь критично? Я могу вообразить ситауцию, когда это абсолютно бессмысленно. У нас есть пакет. Предположим, мы хотим послать один пакет. Зачем нам организация из него потока данных, он один? Зачем нам отслеживание качества канала? Мы его уже послали. Один пакет. Вот если бы его было, там, 1000, мы бы как-то сбалансировали это дело, а если он один, вот как мы его послали, не зная о том, кто с той стороны, так мы его и послали. Зачем нам подключение, ну послали мы его. Короче говоря, если цельность данных и... короче, если вся информация, которую мы собираемя передавать, умещается в один акт передачи данных ,скорее всего, ничего из вышеперечисленного делать не нужно, но может быть и стоит это сделать, но стоит переложить на вышележащий протокол. Ну пускай там наверху проверят, что там можно проверить. checksum проверит и на udp, не волнуйтесь. Пускай на протоколе уровнем выше, в случае если... да ничего нельзя сделать. Ну вот не дошел один-единственный пакет, ну как наш абонент узнает, что до него этот пакет не дошел?

А в случае, если с соединеием, если не дошел первый пакет. Он первый, вот он не дошел. Как у нас абонент узнает, что до него не дошел первый пакет? Еще раз, когда соединение устаналивается, то должен сначал первый пакет дойти. (Таймаут). Анекдот рассказываю. Два мужика купили много водки, пили, пили, пили, один говорит: меня сморило, я тут посплю, а когда я захочу выпить, ты меня разбуди. Друг, как же я узнаю, когда ты захочешь пить? Чудак, ты меня разбуди. Так вот, такая же история. Как абонент узнает, что до него не дошел первый пакет соединения? Как второй не дошел -- понятно, до него дошел первый, он ждет второго, а первый он как узнает?

Короче говоря, если все данные, которые мы хотим переслать, умещаются в один пакет, так называемую датаграмму, это такая монада, самодостаточная, в этом случае нам нечего проверять и устанавливать, потому что проверка и установления это тоже такая своеобразная датаграмма, ну и какая разница, так мы две пошлём, а так одну. (А как мы узнаем, доёдет эта передача одного пакета, или не дойдёт?.) А она ненадёжная. Соединеия не произошло. Единственное, Жень, я понимаю, о чем вы думаете, это на уровне прикладном организовать подтверждение какое-нибудь, если мы того хотим, и так сказать, очень много протоколов, работающих на udp так и делают. Допустим, какой-нибудь dns, допустим -- запрос-ответ, вот вам потдверждение, ответ пришел, значит подтверждение.

Так вот, именно по этой причине если не уровне IP куча всяких протоколов, там есть еще всякие туннелирования специальные несколько штук, 2tp (?) модные нынче, то на уровне TCP их всего два. Один из них все эти 5 свойств, которые мы перечислили, поддерживает и называется он TCP, а другой из них ни одного из них не поддерживает, потому что там все зключено в одной посылке данных, и назыается он UDP.

{03:00:50}

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)