Различия между версиями 17 и 18
Версия 17 от 2008-07-03 02:08:32
Размер: 26104
Редактор: PavelSutyrin
Комментарий:
Версия 18 от 2008-07-03 03:21:16
Размер: 26319
Редактор: eSyr
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 170: Строка 170:
(tcp host esyr.ru) (esc_...) а теперь второе окошечко, и скажем telnet.
Вот тут esc_ работать не будет... вовсю тут фигачат... вот оно здесь началось,
вот мы со своего адреса пошли на host telecom на 22, вот наш sequence number
нулевой длины, вот они пришёл с нулевым seqn обратно, и вот он пошел дальше
(tcpdump host esyr.ru) (Esc+_ --- вставить последний аргумент предыдущей команды в место курсора) а теперь второе окошечко, и скажем telnet.
Вот тут Esc+_ работать не будет... вовсю тут фигачат... вот оно здесь началось,
вот мы со своего адреса пошли на msk-f41.host-telecom на 22, вот наш sequence number
с окном нулевой длины, вот они пришёл с нулевым окном обратно, и вот он пошел дальше
Строка 187: Строка 187:
Мы сначала подключились по этому (?) ip-шнику на 80-й порт, а потом
подключились по этому (?) ip-шнику на 22 порт, и в случае 22 нас ожидал
Мы сначала подключились по этому (89.188.104.91) ip-шнику на 80-й порт, а потом
подключились по этому (89.188.104.91) ip-шнику на 22 порт, и в случае 22 нас ожидал
Строка 191: Строка 191:
Кстати, вы ключи обновили?... Ключи обновили?... (Черт!)

Поскольку установление подключения двусторонее, то когда происходит
Кстати, вы ключи обновили? --- М? --- Ключи обновили? --- Да, конечно. --- (Черт!)

Поскольку установление подключения двустороннее, то когда происходит

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

{02:49:55}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{03:00:50}

TCP

Я не знаю, нужно ли в рамках этого курса рассказывать, как устроено трехуровневое подключение по TCP, поэтому я расскажу довольно коротко про это. Все начинается с установления подключения, т.е. инициатор подключается.. условно говоря, клиент подключается к серверу, и прежде чем вот это подключение не произойдет, ничего другого не может начаться. При этом надо знать, что подключение по TCP двустороннее, т.е. данные передаются в обе стороны. Клиентом мы называем программу, которая хочет, сервером -- которая может. Клиент -- это тот, кто инициирует подключение, а сервер, этот кто на него отвечает. TCP -- это двустороннее подключение. Данные передаются как от клиента к серверу, так и от сервера к клиенту.

Второе. TCP устроен по принципу подтверждение, каждый TCP-пакет, который может быть гораздо больше, чем IP пакет, после того как он принят сервером, на него генерируется подтверждение, дескать, все принято, все хорошо, или, если он побился по дороге или пришло что-то из того же потока данных но не соответствующее ожиданиям, то вместо подтверждения приходит ошибка, или же, если в какой-то момент произошёл таймаут, и очередного пакета внутри потока данных не пришло, то также приходит вместо подтверждения ошибка, ты что мне шлёшь 12-й, я хочу 3-й. Это процесс симметричный, клиент с сервером играют в волейбол, когда ты посылаешь пакет серверу, он тебе посылает ответ, то бишь подтверждение, и в нём какие-то свои данные, хотя может и голове подтверждение придти, но их можно объединять. Данные, связанные с управлением и собственно данные можно объединять. (Коробка из двух частей, каждый раз передаётся что-нибудь в одну сторону, а заодно и подтверждение чего-то, переданного в прошлый раз в обратную сторону.)

Все TCP-пакеты пронумерованы, есть понятие seqn (sequence number), и в каждом TCP-соединении их два, в каждую сторону передачи, это произвольно взятые числа, которые каждый раз увеличиваются на объём переданных данных. Это одновременно позволяет вычислять последовательность пакетов и позволяет выяснять, что пропало и не сдублировался ли пакет, такое волшебное число. Везде считается контрольные суммы, что касается отслеживания. сост канала, то тут довольно хитрая технология, в описание вдаваться не буду, суть такая: поначалу обмен идёт маленькими пакетами, и чем успешнее идет обмен, чем больше данных готова принять принимающая сторона, тем больше данных готов отправить отправитель.

(tcpdump host esyr.ru) (Esc+_ --- вставить последний аргумент предыдущей команды в место курсора) а теперь второе окошечко, и скажем telnet. Вот тут Esc+_ работать не будет... вовсю тут фигачат... вот оно здесь началось, вот мы со своего адреса пошли на msk-f41.host-telecom на 22, вот наш sequence number с окном нулевой длины, вот они пришёл с нулевым окном обратно, и вот он пошел дальше увеличиваться, тык-тык-тык.

Для того, чтобы выполнить задачу разделения данных, к паре (адрес отправителя, адрес получателя) появляется ещё одно понятие --- порт. Оно участвует в TCP, и оно же еще немножко помогает на уровне интерпретации данных.

Придумано оно по аналогии с портами ввода-вывода обычного компьютера. Когда происходит установление соединения, то клиент подключается не просто к ip, но к определенному ip и определенному порту этого самого сервера, что мы только что проделали с помощью программы telnet, которая для этого как раз и не предназначалась никогда. В качестве тестировщика она подходит.

Мы сначала подключились по этому (89.188.104.91) ip-шнику на 80-й порт, а потом подключились по этому (89.188.104.91) ip-шнику на 22 порт, и в случае 22 нас ожидал какой-то сервер, какой-то OpenSSH, какой-то Debian, понимаете ли...

Кстати, вы ключи обновили? --- М? --- Ключи обновили? --- Да, конечно. --- (Черт!)

Поскольку установление подключения двустороннее, то когда происходит ответное установление подключения от сервера к клиенту, оно происходит также по определенному порту, который клиент ему просто сообщает, здесь порт получателя это ssh (22), а у клиента это 44670, и он тут везде сохраняется, как и порт ssh. Если вы устанавливаете следующее подключение к тому же хотя бы, серверу, в качестве порта отправителя используется произвольное другое число, именно поэтому вы можете различить эти два потока данных, даже если адрес получателя, порт получателя и ip отправителя у них одинаковый, а вот порт отправителя у них разный, потому что каждое TCP-соединение использует свой собственный порт для идентификации отправителя.

Так что эта четверка (адрес и порт отправителя, адрес и порт получателя) и есть некий такой TCP-адрес, адрес уровня транспорта, идентификатор, вернее так. TCP. Да.

Почему лектор говорит, что порт это такой переходный уровень между TCP и уровнем приложений? Дело в том, что согласно некоторой договорённостям, разные типы приложений сидят на разных портах, можем ожидать, как интерпретировать данные, которые посыпятся на определенный порт, т.е. при подключении по 80 порту то что мы передаем будет интерпретироваться как HTTP-запросы, а по порту 22 нас ждет Secure Shell. Почему так? Да потому что никакого другого способа указать клиенту, по какому порту как подключаться, мы не имеем. Мы можем, конечно, словами сказать, вот у меня есть сервер, ты подключайся, пожалуйста, по порту 9090. Лектор на стриме завёл барахло, на 9090 порту, кто знал, тот ходил.

Существует организация IANA, в которой вы можете зарегистрировать своё приложение, сказав: пускай теперь такой-то порт теперь исключительно вот для этого используется. (cat /etc/services). Known ports, так называемые. Как вы могли заметить, временный порт выбирается достаточно большим, кажется он должен быть больше 32000, есть такая традиция, в некоторых случаях это нужно.

Вопросы

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

В них нет почти ничего общего. Нет, ip и порт есть, даже порт отправителя, что удивительно. Если на прикладном уровне не сделано своей поддержки подтверждений, мы можем свой udp-пакет послать вникуда, и он уйдёт вникуда, есть класс задач, где только так себя и нужно вести, например широковещание, не хватало нам от всех клиентов, которые смотрят наше потоковое видео, получать подтверждения и сообщения об ошибках, и обрабатывать их. Другая область применения, когда сам факт обмена данных заключается в посылке очень маленьких пакетов, а сама работа на прикладном уровне подразумевает, что будет отчет, типичный пример -- это dns, незачем из одного пакета делать 4. И если мы ждем ответа от dns-сервера, то его можно ждать и на прикладном уровне, с тем же успехом, как ждать установления tcp-соединения. Траффик экономится, и чем выше уровень DNS-сервера, тем выгоднее экономить его. Сетевые файловые системы, NFS, раньше использовали UDP. Тут забавная ситуация. Если у вас очень медленный (по времени ответа) канал, то в действительности по нему удобно гонять, как ни странно, именно udp. Надо оценивать, в том числе и случай возникновения ошибки, т.к. если мы узнаем о ней поздно, то уже можем успеть послать много лишних пакетов. В современности среды передачи данных работают все быстрее, компьютеры работают еще быстрее, а надёжность не повышается, на 1000 пакетов один зажёвывается. И получается, что с установлением соединения теперь получается быстрее.

{03:27:40}


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

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

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

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

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

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

Level

Maintainer

Start date

20

1

1

1

1

03.07.2008


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