Какие гарантии предоставляет tcp

8,9. Требования приложений. Сервисы, предоставляемые tcp и udp.

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

Выделяются 3 основных требования, предъявляемых приложениями к транспортному уровню: надежная передача данных, гарантированная скорость передачи и обеспечение доставки данных за определенное время.

Надежная передача данных: некоторые приложения, например приложения эл почты, требуют надежной передачи данных, то есть исключения вероятности потерь данных при передаче. Но сущ вид приложений, толерантных к потерям данных (аудио и видео реального времени). Для таких приложений потеря данных не приводит к сбоям или серьезным потерям качества. Степень толерантности приложения к потере данных определяет максимальную долю данных. которая может быть потеряна, и зависит от назначения приложения и использующейся схемы кодировки.

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

Время передачи: Гарантированное время доставки. И-телефония, виртуальные миры, телеконференции, многопользовательские комп игры. В приложениях, не являющихся приложениями реального времени, временные ограничения на доставку данных не являются столь принципиальными.

Русские Блоги

существоватьЭтот блогВведен механизм управления соединением, который является важным механизмом для обеспечения надежности протокола TCP. В дополнение к механизму существует много реализации механизмов надежности, которые будут описаны в этой статье.

1. Подтвердите механизм ответа (ACK)

Существует два поля в заголовке протокола TCP: серийный номер и серийный номер подтверждения. Эти два поля должны обеспечить подтверждение механизма реагирования.

Отправитель A отправляет множество сегментов данных, которые будут передаваться на приемный конец B. Например, сегмент данных для передачи порядкового номера от 1 до 1000. B Если все данные получают правильно, последовательный номер подтверждения 1001 передается, чтобы сказать A. 1-1000 передается до того, как он будет правильно получен, и в следующий раз он начнет с 1001. Если B только принимает только от 1 до 500, серийный номер подтверждения 501 отправляется в B, а пакеты от 500 до 1000 будут потеряны после получения, а пакеты от 500 до 1000 будут возвращены в B. Надежная передача данных гарантируется.

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

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

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

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

(1) предположить механизм реагирования;

(2) гарантированные данные из порядка;

(3) Убедитесь, что восстановление гарантировано.

2. Механизм повторной передачи тайм-аута

Когда хост A отправляет отчет о данных на хост B, период A a не принимает сигнал подтверждения от B, он будет повторно передан. Есть две причины, почему повторные передачи:

(1) Данные, отправленные в B, потеряны во время процесса передачи, то A. Когда данные снова повторно передаются, она может гарантировать надежную доставку данных;

(2) Если B принимает данные, сигнал подтверждения ACK, отправленный на A, поднимается во время процесса передачи. В это время B — это снова повторно передавать, B будет принимать дубликаты данных, в это время B, это можно сделать в соответствии с Серийный номер в пакете для обеспечения надежности передачи данных.

Как установить время, когда набор тайм-аута?

Если временная настройка слишком длинная, когда дейтаграмма потеряна, это повлияет на эффективность повторной передачи; если настройка времени слишком короткая, большая сумма пакета повторно передается, когда пакет ACK задерживается. Так что на этот раз лучше всего убедиться, что ACK может достичь кратчайшего времени.

Протокол TCP динамически рассчитан на это время повторной передачи времени.

В Linux интервал времени ожидания 500 мс 2 ^ n (n = 0, 1, . ). Если подтверждение ACK получено после первого впервые, подтверждение ACK не получено, то подтверждение ACK не получено в течение 2 * 500 мс, а снова повторно передается; затем подождите 4 * 500 мс и доверенного, вернитесь снова; . когда Количество повторных передач превышает определенный верхний предел, TCP будет учитывать, что сеть или другой партнер ненормально, что заставит соединение.

Следовательно, когда данные передаются, хост a будет устанавливать тревогу после отправки данных, если отчет ACK достигнут до того, как сигнал тревоги не звонит, сигнал тревоги отменяется, а последующая передача данных; если сигнал тревоги — это время ожидания, ACK Газета не прибыла, и A будет повторно передавать данные и сбросить сигнал тревоги для нового значения.

3. Управление трафиком

Если передача передаваемых данных слишком быстро, полученный буфер, вызванный приемным концом, заполнен. В это время передающий конец не получает данные при отправке данных, что приводит к потере пакета, а затем повторной передачи, что приводит к отходу ресурсов и т. Д.

Существует поле «Размер окна» в заголовке протокола TCP, который используется для заполнения размера буфера, вы можете получить буфер. Заполните свой собственный размерный буфер во время пакета ACK, отправленные на другую сторону на стороне клиента и сервера.Когда две стороны начнут обмениваться, терминал передачи A передается на приемную B, а B посылает подтверждение ACK к A, в каком размере «точка B» можно разместить в пакете ACK, чтобы рассказать о ваших собственных возможностях приема Отказ Точно так же, а также может сказать себе через этот метод (размер окна).

Следовательно, приемный конец может получить размер того, сколько данных (размер окна), которые могут получать свой собственный приемный буфер (размер окна), и отправитель контролирует скорость его передачи в соответствии с этим значением. Если окно время, Передача замедляется. Если приемлемый размер буфера принимающей цели составляет 0, в это время, передающий конец перестает передавать данные. Когда размер окна приемного конца не составляет 0, уведомление об обновлении окна — заставить отправителя снова начать передавать данные. Если период времени (время времени возвращается), отправитель не получил уведомления о обновлении приеманного окончания, и данные, сообщаемые на приемную (бит флага PSH в сообщении 1), то получение Конец расскажет отправителю по этому размеру. Если пакет обновленного пакета страницы потерян, отправитель всегда будет отправлять дейтаграмму обнаружения окон.

В приведенном выше TCP контролирует скорость передачи передающего конца через приемную емкость приемного конца, называется контролем трафика. Чем больше окно, тем выше пропускная способность сети.

Размер окна в заголовок TCP вкладывает на 16 битов, а максимальное количество, которое можно представить, составляет 2 ^ 16, что составляет 65535. Он находится в байтах, поэтому размер окна составляет 64 КБ, то есть принятый буфер имеет максимальный буфер Размер 64 КБ, но фактический приемлемый размер буфера не может быть таким маленьким. Следовательно, в 40-байтовом варианте заголовка TCP есть окна расширения окна M, поэтому фактический размер окна является значением значения, оставленного полем окна.

4. Раздвижное окно

В механизме отклика подтверждения после терминала передачи A отправляет дейтаграмму в приемную B, следующий DataG отправляется после ожидания ответа B. Если передача данных обеих сторон слишком длинная, время ожидания времени слишком длинно, и эффективность передачи данных будет низкой. Если A будет продолжать отправлять сегмент 2 данных во время сегмента 1 ожидания 1, при ожидании сегмента данных данных данных 2 сегмент 2 ожидает сегмента данных данных и сегмент 3 данных и т. Д. Ожидание Время каждого сегмента данных перекрывается, так что эффективность передачи данных может быть улучшена.

Но сколько сегментов данных снова отправляется? Получаемая мощность приемного конца может быть известна из вышеописанного размера окна, поэтому сегмент данных размера окна приемного конца может быть передан. Например, размер окна B составляет 4000, а размер одного сегмента данных составляет 1000, поэтому A может отправлять четыре сегмента данных (1, 2, 3, 4) сразу и после получения ответа от сегмента данных 1 Раздвижное окно перемещается повторно передача сегмента 5 данных. Назад.

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

5. Быстрый механизм повторной передачи

Если множество сегментов данных от 1: от 0 до 1000; 2: от 1001 до 2000; 3: от 2001 до 3000; 4: от 3001 до 4000, следующие два потери пакета происходят при передаче B одновременно

(1) Отвечая на сегмент данных ACK потерян. Если ответ ACK из сегмента данных данных ответа, ответ ACK из сегментов данных 2, 3, 4 не теряется, поскольку номер подтверждения сегмента 4 ACK составляет 4001, что указывает на то, что B будет в сегменте данных BLY 1, 2, 3, 4 он был получен, и ответ сегмента 1 данных можно игнорировать проблему потери ACK. Если подтверждение ACK сегмента 4 данных теряется, и отсутствует сегмент сообщений более крупного серийного номера, запускается механизм повторной передачи времени ожидания, а сегмент 4 данных повторно передан. Если ответ ACK из сегментов данных 1, 2, 3, 4 теряется, и механизм повторной передачи тайм-аута также запущен, а также повторная доставка.

（2） Сегмент данных потерян. Например, сегмент 1 данных является пакетом, но 2, 3, 4 не потерян, поэтому B будет включать номер последовательности подтверждения 0 в отчете о подтверждении к сегменту 2, 3, 4, 4. Указывает, что B запрашивает сегмент данных 1. Если B принимает сегмент данных 1 после повторной передачи, номер последовательности подтверждения составляет 4001, поскольку сегмент данных B до 4001 года получает и помещает их в приемный буфер.

Когда вышеупомянутый сегмент данных 1 потерян, если Три часа подряд ACK подтвердил номер подтверждения 0 равен 0, а сегмент 1 данных повторно передан. В это время он еще не достигнет времени повторной передачи тайм-аута в сегменте данных 1. Этот механизм называется «Быстрый реабилитационный механизм» (быстрая повторная передача) 。

Механизмы повторной передачи тайм-аута являются основными гарантиями, и на нем основан механизм быстрой передачи. Когда все отчеты о данных теряются, или все респонденты ACK будут потеряны, будет запущен механизм повторной передачи времени ожидания.

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

(1) Вы можете указать размер скольжения

(2) Скорость передачи передающей концом может контролироваться.

6. Контроль заторов

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

Медленный старт механизма:

Первоначально настроен окно застой составляет 1, после получения ответа ACK, окно перегрузки плюс 1. Определите данные передачи на основе окна перегрузки и получателя получателя.

Хотя первоначальный размер окна застой составляет 1, потому что это рост индекса, он станет все больше и больше (в это время, алгоритм медленного запуска). Таким образом, данные, отправленные в сеть, увеличиваются, и вероятность застой сетевых заложений будет больше.

Следовательно, невозможно увеличить рост окна заторов. Поэтому здесь вводится в один Медленный порог начала (когда начинается TCP, медленный порог начала равен окну Max) Когда окно застой прибывает на этот порог, Окно заторов выросло линейно и 1 (в это время, чтобы избежать алгоритма заторов).

Независимо от стадии медленного запуска или на фазе застой, когда сеть перегружена, Порог медленного запуска уменьшает половину окна застой, когда возникает застой сетевой застой ,Одновременно Окно перегрузки уменьшается до 1 Начните медленно от 1 до начала. (Когда возникает небольшое количество потерь пакетов, мы запускаем только механизм повторной передачи времени на тайм-аут. Когда происходит большое количество потерь пакетов, рассмотрено застой сетевой пакеты, и появилось пороговое значение медленного запуска и окно перегрузки.

Как показано ниже:

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

7. Задержка ответа

Если размер окна приемного конца B составляет 1 м, передающий терминал A передает 500K данных в B, а если B получен сразу после получения данных, окно в сообщении ACK составляет 500к.

Если данные B обрабатываете данные очень быстро, например, в течение короткого периода времени, 500K данных завершены. А мощность обработки B не достигла верхнего предела, то есть больше данных B до B также можно быстро обрабатывать. В это время B можно задерживаться, после завершения обработки данных 500K выполняется ответ, а значение окна в пакете ACK составляет 1 м. Таким образом, в следующий раз вы сможете отправить больше данных в B обработку B. Таким образом, растущая эффективность.

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

Тем не менее, вы не можете задержать, здесь есть два ограничения:

(1) Ограничение количества: Ответ один раз для каждого n пакета (n равно 2);

(2) Ограничение времени: Ответ один раз в максимальном времени задержки (максимальное время задержки, как правило, 200 мс).

8.

Когда хост A передает данные на хост B, B будет выдавать сообщение о ответе ACK к A, а B также могут отправлять пакеты данных в действие, в какую точку B можно установить на пакете ACK, отправленной BY , На, отправьте его на A, что может уменьшить передачу сообщения, тем самым повышая эффективность.

Таким образом, протокол TCP должен обеспечить передачу надежности и повысить производительность. Так что это сложнее.

Обеспечение надежности:

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

Улучшить производительность механизма:

Раздвижное окно, механизм быстрой скидки, механизм отсроченного ответа и механизм ответа на ленту.

9. Проблема клей

Когда данные передаются в транспортный слой TCP, данные могут быть последовательно разряжены в буфере приема в соответствии с серильным номером. Когда уровень приложений считывает данные из буфера, слой приложений видит струнный байтовый поток. Таким образом, какая часть начинается, какая часть заканчивается? Это полный пакет слоя приложений? Если слой приложений многоизмеряется или меньше данных относительно полного пакета, он сформирует вязкую проблему. (В данный момент пакет является пакетом данных о слое приложений)

Поэтому, когда слой приложений считывает данные, ясно, что границы между двумя пакетами ясны.

(1) Отчет о данных, соответствующий фиксированной длине, прикладной слой можно договориться заранее. Например, когда передающий конце передает данные, пакет имеет размер int, а приемный конец также принимается отчетом данного размера INT;

(2) Для растущей дейтаграммы. Поле длины может быть добавлено в заголовок дейтаграммы, а слой приложений может определять длину данных на основе поля при чтении;

(3) Для растущей датаграммы. Также можно добавить отдельный символ в Datagram для различения \ n в протоколе HTTP, который выполнен протоколом слоя приложений.

Для UDP, если данные не доставляются в верхний слой, заголовок данных в заголовке протокола UDP существует, поэтому его можно прочитать в соответствии с этим полем, чтобы прочитать длину сообщения. В то же время UDP — это пакет, который будет доставляться до верхнего слоя. Он имеет четкую границу, а накладной слой либо завершен при получении пакетов UDP или никакой клейкой проблемы не будет.

10. TCP ненормальная ситуация

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

Машина перезагружается:То же самое одинаково;

Машина включена вниз или сетевой кабель отключен:После того, как оба конца a, b установлены, B-терминал вызывает соединение для отключения, потому что питание включается вниз. В это время конец не знает, что соединение B-Terminal было отключено. Когда он записан на B-терминал, обнаружено, что подключение B-терминала не существует, поэтому он отправит RST для восстановления соединения; даже если конец не пишет, TCP имеет встроенный Таймер инактивации, периодически проверяйте состояние соединения однорангового сочетания, как только компоненты подключены, соединение также отключено.

HackWare.ru

Этичный хакинг и тестирование на проникновение, информационная безопасность

Транспортные протоколы TCP и UDP

Оглавление: Компьютерные сети

6. Канальный уровень передачи данных

7. Маршрутизация данных

8. Служебный протокол ICMP

10. Настройка сетевых подключений в командной строке Linux

11. Определение проблем работы сети

12. Туннелизация

Сходства и различия TCP и UDP

В первой части «Как работают компьютерные сети» мы узнали, что для передачи информации используются транспортные протоколы TCP и UDP. В физическом смысле эти протоколы представляют собой сетевые пакеты. Каждый сетевой пакет передаёт небольшой фрагмент информации, поэтому данные разбиваются на много пакетов.

Каждый сетевой пакет обоих протоколов TCP и UDP состоит из двух частей:

• заголовок
• непосредственно данные

В заголовке содержится «служебная информация» (можно сказать, что это метаданные) — порты пункта назначения и исходного узла, номер пакета в потоке, тип пакета и так далее.

Различие между протоколами TCP и UDP в том, что протокол TCP имеет механизм контроля полноты переданных данных — если какой-либо пакет был потерян или повреждён, то предусмотрен механизм для проверки этого факта и повторной отправки пакета. В протоколе UDP такого механизма нет — то есть если потерян пакет протокола UDP, то узел, который его отправил, никогда об этом не узнает, а принимающая сторона никогда не узнает, что ей был отправлен потерянный пакет UDP.

Может возникнуть вопрос, зачем вообще нужен такой ненадёжный протокол UDP, если есть надёжный протокол TCP? Платой за надёжность протокола TCP является то, что в бухгалтерии называется «накладные расходы» (overheads) — суть в том, что для обеспечения механизма контроля доставки пакетов в протоколе TCP отправляется много данных, которые не содержат полезной информации, а служат только для установки и контроля соединения. К примеру, чтобы отправить хотя бы одни пакет с полезными данными в TCP нужно завершить трёхступенчатое рукопожатие, которое заключается в отправке 1 особого пакета от источника к пункту назначения, получения 1 пакета о возможности установить соединения и отправки ещё 1 специального пакета от источника с подтверждением, что всё готово к отправке — за это время с помощью протокола UDP можно было бы отправить уже несколько пакетов с полезными данными.

По этой причине, оба протокола TCP и UDP являются «хорошими» — важно правильно их использовать. Например, при потоковом вещании видео неважно, какой пакет был потерян секунду или две назад. Но при открытии веб-страницы, когда из-за неполных данных могут возникнуть проблемы с обработкой запроса от HTTP протокола, напротив, нужно следить за доставкой и целостностью каждого пакета с данными.

Детальное понимание TCP и UDP имеет значение при:

• анализе сетевого трафика
• настройке сетевого файервола iptables
• понимания и защиты от DoS атак некоторого вида.

К примеру, понимая механизм TCP подключения, можно настроить файлервол (iptables) так, что будут запрещены все новые подключения с сохранением существующих, либо запретить любые входящие подключения с полным разрешением исходящих, понимать и предотвращать ряд DoS атак, понимать SYN и другие виды сканирований — почему они возможны и каков их механизм и т.д..

Протокол TCP

Transmission Control Protocol (TCP, протокол управления передачей) — один из основных протоколов передачи данных интернета, предназначен для управления передачей данных.

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

TCP широко используется во многих интернет-приложениях, включая World Wide Web (WWW), электронную почту, протокол передачи файлов, Secure Shell, одноранговый обмен файлами и потоковое мультимедиа.

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

Итак, механизм TCP предоставляет поток данных с предварительной установкой соединения, осуществляет повторный запрос данных в случае потери данных и устраняет дублирование при получении двух копий одного пакета, гарантируя тем самым, в отличие от UDP, целостность передаваемых данных и уведомление отправителя о результатах передачи.

Алгоритм работы TCP следующий:

1. Устанавливается трёхэтапное рукопожатие между двумя узлами. На этом этапе узлы согласуют два числа — начальные номера первого пакета для каждого из узлов.
2. При отправке пакетов узлы последовательно номеруют их, то есть каждому сетевому пакету присвоен один из последовательных номеров.
3. В дополнении к номеру, для каждого пакета рассчитывается контрольная сумма. Получив пакет, вновь рассчитывается контрольная сумма для полученных данных — если она не совпадает, значит пакет был повреждён при передаче.
4. Итак, поскольку все пакеты имеют последовательные номера, то становится видно если какие-то из них отсутствуют. В этом случае отправляется запрос на повторную отправку пакета.
5. Если для какого-то пакета не совпала контрольная сумма, то отправляется запрос на повторную отправку пакета.

В общем, используя два простых механизма — контрольную сумму и последовательную нумерацию каждого пакета — удаётся достичь надёжности передачи данных и возможности организовать их в правильную последовательность независимо от того, в каком порядке они доставлены.

Всё это возможно с помощью заголовков TCP пакета.

Что такое 1 соединение TCP

Прежде чем изучить структуру заголовка TCP пакета, разберёмся, что такое 1 TCP соединение — это поможет яснее понимать, что именно мы анализируем в Wireshark и сколько TCP соединений нам нужно искать. К примеру, сколько TCP соединений задействуется при открытии 1 страницы веб-сайта? Типичный веб-сайт состоит из 1 страницы HTML кода, нескольких страниц каскадных таблиц стилей CSS и JavaScript файлов, а также пары десятков файлов изображений. Так вот, для получения каждого из этих файлов создаётся новое TCP соединеие. Для каждого из этих соединений выполняется трёхэтапное рукопожатие — это к вопросу о том, какие издержки, «накладные расходы» несёт в себе TCP.

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

Поэтому при анализе трафика в Wireshark при открытии даже одной веб страницы вы увидите множество начатых и завершённых TCP соединений.

Заголовок TCP

• Порт источника — биты 0-15. Это порт источника пакета. Исходный порт изначально был связан напрямую с процессом в отправляющей системе. Сегодня мы используем хеш между IP-адресами и портами назначения и порта источника для достижения этой уникальности, которую мы можем привязать к одному приложению или программе.
• Порт назначения — биты 16-31. Это порт назначения пакета TCP. Как и в случае с портом-источником, он изначально был напрямую связан с процессом в принимающей системе. Сегодня вместо этого используется хеш, который позволяет нам иметь больше открытых соединений одновременно. Когда пакет получен, порты назначения и исходные порты возвращаются в ответе обратно к первоначально отправляющему хосту, так что порт назначения теперь является портом источника, а порт источника является портом назначения.

Порт источника и порт назначения не обязаны быть одинаковыми: к примеру, если делается запрос к 80-му порту сервера, то этот запрос может прийти, например, с порта 34054.

Номера портов на сервере могут использоваться как стандартные, так и произвольные.

• Порядковый номер (Sequence number) — биты 32-63. Поле порядкового номера используется для установки номера в каждом TCP-пакете, чтобы можно было правильно упорядочить поток TCP (например, пакеты приводятся к правильному порядку). Затем в поле ACK возвращается порядковый номер, чтобы подтвердить, что пакет был принят правильно.

Указывает на количество переданных байт, и каждый переданный байт полезных данных (payload) увеличивает это значение на 1.

Если установлен флаг SYN (идёт установление сессии), то поле содержит изначальный порядковый номер — ISN (Initial Sequence Number). В целях безопасности это значение генерируется случайным образом и может быть равно от 0 до 2 32 -1 (4294967295). Первый байт полезных данных в устанавливающейся сессии будет иметь номер ISN+1.

В противном случае, если SYN не установлен, первый байт данных, передаваемый в данном пакете, имеет этот порядковый номер.

• Номер подтверждения (Acknowledgment Number (ACK SN)) — биты 64-95. Это поле используется, когда мы подтверждаем определённый пакет, полученный хостом. Например, мы получаем пакет с одним установленным порядковым номером, и если с пакетом все в порядке, мы отвечаем пакетом ACK с номером подтверждения, равным оригинальному порядковому номеру.

Если установлен флаг ACK, то это поле содержит порядковый номер октета, который отправитель данного сегмента желает получить. Это означает, что все предыдущие октеты (с номерами от ISN+1 до ACK-1 включительно) были успешно получены.

Каждая сторона подсчитывает свой Sequence number для переданных данных и отдельно Acknowledgement number для полученных данных. Соответственно Sequence number каждой из сторон соответствует Acknowledgement number другой стороны.

• Длина заголовка (смещение данных) — биты 96-99. В этом поле указывается длина заголовка TCP пакета и где начинаются фактические данные (полезная нагрузка). Поле имеет размер в 4 бита и указывает заголовок TCP в 32-битных словах. Заголовок должен всегда заканчиваться чётной 32-битной границей, даже с различными установленными опциями (опции могут отсутствовать вовсе, либо их количество может различаться). Это возможно благодаря полю Padding в самом конце заголовка TCP.

Минимальный размер заголовка составляет 5 слов, а максимальный — 15 слов, что даёт минимальный размер 20 байтов и максимум 60 байтов, что позволяет использовать до 40 байтов опций в заголовке. Это поле получило такое имя (смещение данных) из-за того, что оно также показывает расположение фактических данных от начала сегмента TCP.

Итак, длина заголовка определяет смещение полезных данных относительно начала сегмента. Например, Data offset равное 1111 говорит о том, что заголовок занимает пятнадцать 32-битных слова (15 строк*32 бита в каждой строке/8 бит = 60 байт).

• Зарезервировано — биты 100-102. Эти биты зарезервированы для будущего использования.
• Флаги (управляющие биты)
• NS — бит 103. ECN-nonce — concealment protection
• CWR (Congestion Window Reduced) — бит 104. Поле «Окно перегрузки уменьшено» — флаг установлен отправителем, чтобы указать, что получен пакет с установленным флагом ECE
• ECE — бит 105. ECE (ECN-Echo) — Поле «Эхо ECN» — указывает, что данный узел способен на ECN (явное уведомление перегрузки) и для указания отправителю о перегрузках в сети (RFC 3168)
• URG — бит 106. Поле «Указатель важности» задействовано. Если установлено значение 0, не используется Urgent Pointer, если установлено значение 1, то используется Urgent Pointer.
• ACK — бит 107. Этот бит устанавливается для пакета, чтобы указать, что это ответ на другой полученный нами пакет, содержащий данные. Пакет подтверждения всегда отправляется, чтобы указать, что мы фактически получили пакет, и что он не содержит ошибок. Если этот бит установлен, исходный отправитель данных проверит номер подтверждения, чтобы увидеть, какой пакет фактически подтверждён, а затем выгрузит его из буферов.
• PSH — бит 108. Флаг PUSH используется для указания протоколу TCP на любых промежуточных хостах отправлять данные фактическому пользователю, включая реализацию TCP на принимающем хосте. Это протолкнёт все данные, независимо от того, где и сколько из окна TCP было уже передано.
• RST — бит 109. Флаг RESET установлен, чтобы сообщить другому концу разорвать TCP-соединение. Это делается в нескольких различных сценариях, основными причинами которых является то, что соединение по какой-то причине разорвалось, если соединение не существует или если пакет каким-то образом неправильный.
• SYN — бит 110. SYN (или синхронизация номеров последовательности) используется во время первоначального установления соединения. Он устанавливается в двух экземплярах соединения: начальный пакет, который открывает соединение, и ответный пакет SYN/ACK. Он никогда не должен использоваться за пределами этих случаев.
• FIN — бит 111. Бит FIN указывает, что у хоста, который отправил бит FIN, больше нет данных для отправки. Когда другой конец увидит бит FIN, он ответит FIN/ACK. Как только это будет сделано, хост, который первоначально отправил бит FIN, больше не сможет отправлять какие-либо данные. Однако другой конец может продолжать отправлять данные до тех пор, пока они не будет завершаться, и затем отправит пакет FIN обратно и дождётся окончательного FIN/ACK, после чего соединение отправляется в состояние CLOSED.
• Размер окна (Window Size) — биты 112-127. Window Size определяет количество байт данных (payload), после передачи которых отправитель ожидает подтверждения от получателя, что данные получены. Иначе говоря, получатель пакета располагает для приёма данных буфером длиной "размер окна" байт.

По умолчанию размер окна измеряется в байтах, поэтому ограничен 2 16 (65535) байтами. Однако благодаря TCP опции Window scale option этот размер может быть увеличен до 1 Гбайта. Чтобы задействовать эту опцию, обе стороны должны согласовать это в своих SYN сегментах.

• Контрольная сумма — биты 128-143. Поле контрольной суммы — это 16-битное дополнение к сумме всех 16-битных слов заголовка (включая псевдозаголовок) и данных. Если сегмент, по которому вычисляется контрольная сумма, имеет длину не кратную 16-битам, то длина сегмента увеличивается до кратной 16-ти, за счёт дополнения к нему справа нулевых битов заполнения. Биты заполнения (0) не передаются в сообщении и служат только для расчёта контрольной суммы. При расчёте контрольной суммы значение самого поля контрольной суммы принимается равным 0.
• Указатель важности (Urgent pointer) — биты 144-159. 16-битовое значение положительного смещения от порядкового номера в данном сегменте. Это поле указывает порядковый номер октета, которым заканчиваются важные (urgent) данные. Поле принимается во внимание только для пакетов с установленным флагом URG. Используется для внеполосных данных.
• Опции — биты 160-**. Могут применяться в некоторых случаях для расширения протокола. Иногда используются для тестирования. На данный момент в опции практически всегда включают 2 байта NOP (в данном случае 0x01) и 10 байт, задающих timestamps. Вычислить длину поля опции можно через значение поля смещения.

Поле Options является полем переменной длины и содержит необязательные заголовки, которые мы можем захотеть использовать. По сути, это поле всегда содержит 3 подполя. В начальном поле указывается длина поля «Параметры», во втором поле указывается, какие параметры используются, а затем у нас есть фактические параметры. Полный список всех опций TCP можно найти в опциях TCP.

• Заполнение (Padding) — биты**. Поле Заполнение дополняет заголовок TCP, пока весь заголовок не закончится на 32-разрядной границе. Это гарантирует, что часть данных пакета начинается с 32-разрядной границы, и данные в пакете не теряются. Заполнение всегда состоит только из нулей.

Сессия TCP

Рукопожатие TCP (установление подключения TCP)

Для установления соединения TCP использует трёхэтапное рукопожатие.

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

Первый этап, отправка пакета с включённым флагом SYN: активное открытие выполняется клиентом, отправляющим SYN на сервер. Клиент устанавливает порядковый номер сегмента на случайное значение A.

Обратите внимание, что по умолчанию Wireshark показывает относительное значение порядкового номера (Sequence number), чуть ниже вы также можете видеть реальное значение (показано как raw).

Второй этап, отправка пакета с включённым флагом SYN-ACK: В ответ сервер отвечает SYN-ACK. Номер подтверждения установлен на единицу больше принятого Порядкового номера (Sequence number), то есть A+1. Поскольку сервер также будет отправлять данные, то для себя он тоже выбирает Порядковый номер (Sequence number) первого пакета с данными, который будет другим случайным числом B.

Третий этап, отправка пакета с включённым флагом ACK: наконец, клиент отправляет ACK обратно на сервер. Порядковый номер устанавливается равным полученному значению подтверждения, то есть A+1, а номер подтверждения устанавливается на единицу больше, чем принятый порядковый номер, то есть B+1.

На этом этапе и клиент, и сервер получили подтверждение соединения. Шаги 1, 2 устанавливают параметр соединения (порядковый номер) для одного направления, и оно подтверждается. Шаги 2, 3 устанавливают параметр соединения (порядковый номер) для другого направления, и он подтверждается. Таким образом устанавливается полнодуплексная (двухсторонняя) связь.

Передача данных в TCP

PSH-ACK: Клиент отправляет запрос к серверу по HTTP протоколу, поскольку данные поместились в один сетевой пакет TCP, то он имеет флаг PSH, чтобы сервер не ждал продолжение получения данных, а отправил их веб-серверу для выполнения.

ACK: В ответ на принятую информацию сервер отправляет пакет ACK с номером успешно полученных данных.

PSH-ACK: Сервер обработал запрос и отправляет данные — веб страницу

ACK: клиент подтверждает, что данные получены

На последнем скриншоте:

1 — установка соединения

2 — передача данных

3 — завершение соединения

Завершение соединения

Фаза завершения соединения использует четырёхэтапное рукопожатие, причём каждая сторона соединения завершается независимо. Когда конечная точка хочет остановить свою половину соединения, она передаёт пакет FIN, который другой конец подтверждает пакетом с флагом ACK. Поэтому для типичного разрыва требуется пара сегментов FIN и ACK от каждой конечной точки TCP. После того, как сторона, отправившая первый FIN, ответила с последним ACK, она ожидает тайм-аута, прежде чем окончательно закрывает соединение, в течение которого локальный порт недоступен для новых соединений; это предотвращает путаницу из-за задержанных пакетов, доставляемых во время последующих соединений.

Соединение может быть «полуоткрытым», и в этом случае одна сторона завершила свою часть, а другая — нет. Завершившая сторона больше не может отправлять какие-либо данные в соединение, но другая сторона может. Завершающая сторона должна продолжить чтение данных, пока другая сторона также не завершит свою работу.

Также возможно разорвать соединение трёхэтапным рукопожатием, когда хост A отправляет FIN, а хост B отвечает FIN&ACK (просто объединяет 2 шага в один), а хост A отвечает ACK.

Некоторые операционные системы, такие как Linux и H-UX, реализуют полудуплексную последовательность закрытия в стеке TCP. Если хост активно закрывает соединение, но при этом остаются непрочитанными входящие данные, хост отправляет сигнал RST (потеря всех полученных данных) вместо FIN. Это гарантирует приложению TCP, что удалённый процесс прочитал все переданные данные, ожидая сигнала FIN, прежде чем он активно закроет соединение. Удалённый процесс не может различить сигнал RST для прерывания соединения и потери данных. Оба вызывают удалённый стек, чтобы потерять все полученные данные.

Как можно увидеть на скриншоте, завершение TCP соединения также происходит как (Linux с последним ядром):

Клиент: FIN-ACK

Сервер: FIN-ACK

Клиент: ACK

Состояния клиента и сервера

Состояния сеанса TCP
CLOSED	Начальное состояние узла. Фактически фиктивное
LISTEN	Сервер ожидает запросов установления соединения от клиента
SYN-SENT	Клиент отправил запрос серверу на установление соединения и ожидает ответа
SYN-RECEIVED	Сервер получил запрос на соединение, отправил ответный запрос и ожидает подтверждения
ESTABLISHED	Соединение установлено, идёт передача данных
FIN-WAIT-1	Одна из сторон (назовём её узел-1) завершает соединение, отправив сегмент с флагом FIN
CLOSE-WAIT	Другая сторона (узел-2) переходит в это состояние, отправив, в свою очередь сегмент ACK и продолжает одностороннюю передачу
FIN-WAIT-2	Узел-1 получает ACK, продолжает чтение и ждёт получения сегмента с флагом FIN
LAST-ACK	Узел-2 заканчивает передачу и отправляет сегмент с флагом FIN
TIME-WAIT	Узел-1 получил сегмент с флагом FIN, отправил сегмент с флагом ACK и ждёт 2*MSL секунд, перед окончательным закрытием соединения
CLOSING	Обе стороны инициировали закрытие соединения одновременно: после отправки сегмента с флагом FIN узел-1 также получает сегмент FIN, отправляет ACK и находится в ожидании сегмента ACK (подтверждения на свой запрос о разъединении)

Описание данных состояний позволяет лучше понимать информацию, которую показывают программы о состоянии сети, такие как netstat и ss (смотрите также «Как проверить открытые порты на своём компьютере. Что означают 0.0.0.0, :*, [::], 127.0.0.1. Как понять вывод NETSTAT»).

Фильтры Wireshark для TCP

Чтобы увидеть только трафик TCP:

Показать трафик, источником или портом назначения которого является определённый порт, например 8080:

Показать трафик, источником которого является порт 80:

Показать трафик, который отправляется службе, прослушивающей порт 80:

Показать TCP пакеты с включённым флагом SYN:

Показать TCP пакеты с включённым флагом SYN и отключённым флагом ACK:

Аналогично и для других флагов:

• SYN

• ACK

• RST

• FIN

• CWR

• ECE

• URG

• PSH

• NS

Также можно использовать синтаксис вида tcp.flags == 0x0XX, например:

• FIN это tcp.flags == 0x001
• SYN это tcp.flags == 0x002
• RST это tcp.flags == 0x004
• ACK это tcp.flags == 0x010
• Установленные одновременно ACK и FIN это tcp.flags == 0x011
• Установленные одновременно ACK и SYN это tcp.flags == 0x012
• Установленные одновременно ACK и RST это tcp.flags == 0x014

Длина заголовка (смещение данных):

Пакеты с установленными зарезервированными битами:

Вычесленный размер окна:

Фактор масштабирования размера окна:

tcp.window_size_value — это необработанное значение размера окна, считываемое непосредственно из заголовка TCP, тогда как tcp.window_size — это вычисленный размер окна, который основан на том, применимо ли масштабирование окна или нет. Если масштабирование окна не используется или коэффициент масштабирования равен 1 или неизвестно, применимо ли масштабирование окна или нет, потому что трёхэтапное рукопожатие TCP не было захвачено, тогда эти два значения будут одинаковыми. С помощью tcp.window_size_scalefactor вы можете определить, какое из этих условий применимо — если его значение равно -1, то оно неизвестно, если его значение равно -2, тогда масштабирование окна не используется, а все остальные значения представляют фактический размер фактора масштабирования окна.

Чтобы показать пакеты, содержащие какую либо строку, например, строку hackware:

Следовать потоку TCP с номером X:

Фильтровать по номеру потока:

Показать повторные отправки пакетов. Помогает прослеживать замедление производительности приложений и потери пакетов:

Этот фильтр выведен проблемные пакеты (потерянные сегменты, повторную отправку и другие. Этот фильтр проходят пакеты TCP Keep-Alive, но они не являются показателем проблем.

Фильтры для оценки качества сетевого подключения.

Следующие характеристики относятся к TCP фреймам. Причём они не основываются на заголовках фрейма — рассматриваемые характеристики (пропуск данных, дубли) присвоены программой Wireshark исходя из анализа.

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

Фильтр показа фреймов для которых не захвачен предыдущий сегмент:

Это нормально в начале захвата данных — поскольку информация перехватывается не с самого начала сессии.

Для показа фреймов, которые являются ретрансмиссией (отправляются повторно):

Вывод фреймов, которые получены не в правильном порядке:

Виды сканирований Nmap

Мы рассмотрели механизм рукопожатия TCP, напомним его структуру:

• Клиент: SYN
• Сервер: SYN-ACK
• Клиент: ACK

Знаменитый сканер портов Nmap по умолчанию выполняет сканирования с использованием полуотрытых соединений, или его ещё называют SYN сканированием. На самом деле, это не что иное, как отправленный пакет с включённым флагом SYN — то есть Nmap инициирует рукопожатие TCP. Если в ответ приходит пакет с флагами SYN-ACK (то есть удалённый хост отправляет свою часть рукопожатия), то это означает, что порт открыт. Если удалённый хост отвечает пакетом с флагом RST-ACK, то это означает, что порт закрыт.

Такой метод, с одной стороны, является универсальным — любой открытый порт обязательно должен ответить пакетом с флагами SYN-ACK, поскольку это стандарт транспортного протокола TCP. Но при этом Nmap не завершает рукопожатие, то есть не создаётся полноценное соединение и приложение, которое прослушивает просканированный порт, никогда не узнает об этом неудачном TCP рукопожатии, и этот факт не отобразиться в журналах этого приложения.

Пример сканирования портов:

На следующем скриншоте мы можем видеть отправленные и полученные пакеты:

Первая группа пакетов (выделена прямоугольником) — пинг хоста, чтобы определить, доступен ли он. Также на этапе доступности хоста делается запрос к портам 80 и 443 (хотя порт 443 не указан для сканирования), видимо, также для подтверждения того, что хост онлайн.

Если от порта получен пакет SYN-ACK (сервер готов к установке соединения), то Nmap отвечает пакетом с флагом RST для обрыва начатого рукопожатия.

Вторая группа — они отмечены серым и зелёным — это непосредственно сканирование портов — это пакеты с флагом SYN. Серым отмечены те, которые прислали ответ RST-ACK (порт закрыт), а зелёным т е, которые прислали ответ SYN-ACK (порт открыт).

Пакеты RST-ACK, а также пакеты RST (от Nmap) помечены красным.

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

Кроме этого метода, Nmap поддерживает ещё несколько типов сканирования:

Если вы хотите узнать об этих опциях и типах сканирвоания подробнее, то рекомендуется изучить их на справочной странице Nmap: https://kali.tools/?p=1317

Теперь, когда понятна суть сканирований портов, можно предложить меры по защите сервера от сканирований. Если ваш сервер предназначен принимать входящие соединения (например, это веб сервер с SSH), то на 100% защититься от сканирований портов нельзя, поскольку для полуоткрытых соединений используются «легальные» TCP пакеты с флагом SYN, которые являются первой частью рукопожатий. Тем не менее в iptables или fail2ban можно настроить примерно такое правило: «если от одного удалённого хоста поступило более 10 SYN пакетов за указанный промежуток времени, то отклонять его последующие попытки подключения». Это затруднит или даже сделает невозможным массовое сканирование портов на вашем сервере.

Если у вас настроен контроль доступа по IP, то можно запретить SYN пакеты от любого хоста, кроме разрешённых IP, — в этом случае посторонние не только не смогут подключаться, но и не смогут узнать, что порт на самом деле открыт.

Примеры iptables

[БУДЕТ ДОБАВЛЕНО ПОЗЖЕ]

Протокол UDP

Если вы смогли разобраться с TCP и его заголовками, то с UDP вам будет совсем просто.

Протокол пользовательских дейтаграмм (UDP) — это очень простой протокол. Он был разработан для обеспечения очень простой передачи данных без какого-либо обнаружения ошибок. Это так называемый stateless (то есть «без состояния») протокол, это отличает его от протокола TCP, в котором есть понятие соединения (stateful), включающее в себя создания подключения (трёхэтапное рукопожатие) и в котором передача данных выполняется только в рамках данного подключения. Соответственно, для протокола UDP не предусмотрены различные состояния клиента и сервера.

Однако он очень хорошо подходит для приложений типа запрос/ответ, таких как, например, DNS и т. д., поскольку мы знаем, что если мы не получим ответ от DNS-сервера, запрос где-то был потерян. Иногда также стоить использовать протокол UDP вместо TCP, например, когда мы хотим только обнаружение ошибок/потерь, но не заботимся о последовательности пакетов. Это устраняет некоторые издержки, связанные с протоколом TCP.

Природа UDP как протокола без сохранения состояния также полезна для серверов, отвечающих на небольшие запросы от огромного числа клиентов, например DNS и потоковые мультимедийные приложения вроде IPTV, Voice over IP, протоколы туннелирования IP и многие онлайн-игры.

Что такое 1 соединение UDP

Для UDP пакетов понятие «соединение» неправильное, поскольку отправляется один пакет без установки соединения. Если требуется передать поток данных, то отправляется множество UDP пакетов, которые хотя и могут иметь одну общую задачу, с точки зрения транспортного протокола каждый из них является независимым.

В ответ также может прийти один или несколько пакетов UDP. Они приходят на тот же порт, с которого был отправлен исходный UDP пакет — это позволяет определить, что данная датаграмма является ответной на отправленную ранее.

Тем не менее при открытом UDP порте состояние сервера становится LISTEN (сервер ожидает запросов установления соединения от клиента). Также UDP соединение может иметь статус UCONN или ESTAB.

Как можно увидеть, UDP пакет отправлен с порта 42044:

Ответный UDP пакет также пришёл на порт 42044:

Если сравнить с TCP, то минимальное количество пакетов для отправки запроса и получения информации — 10, а для UDP минимальное количество пакетов для отправки запроса и получения информации — 2.

Заголовок UDP

Можно сказать, что заголовок UDP представляет собой очень упрощённый заголовок TCP. Он содержит порты назначения, порты источника, длину заголовка и контрольную сумму, как показано на рисунке ниже.

• Исходный порт — биты 0-15. Это порт источника пакета, описывающий, куда должен быть отправлен ответный пакет. Он может фактически быть установлено на ноль, если значение порта не применимо. Например, иногда нам не требуется ответный пакет, то тогда пакет может быть установлен на нулевой порт источника. В большинстве реализаций он установлен на некоторый номер порта.
• Порт назначения — биты 16-31. Порт назначения пакета. Это требуется для всех пакетов, в отличие от порта источника пакета.

Как и с протоколом TCP — для сервера обычно используется один из стандартных портов (например, порт 53 для DNS серверов), а порт источника выбирается произвольно для каждого соединения, обычно это номера портов с большим номером (десятки тысяч).

• Длина — биты 32-47. Поле длины указывает длину всего пакета в октетах, включая заголовок и части данных. Самый короткий возможный пакет может быть длиной 8 октетов.

Поле, задающее длину всей датаграммы (заголовка и данных) в байтах. Минимальная длина равна длине заголовка — 8 байт. Теоретически, максимальный размер поля — 65535 байт для UDP-датаграммы (8 байт на заголовок и 65527 на данные). Фактический предел для длины данных при использовании IPv4 — 65507 (помимо 8 байт на UDP-заголовок требуется ещё 20 на IP-заголовок).

• Контрольная сумма — биты 48-63. Контрольная сумма — это та же контрольная сумма, что и в заголовке TCP, за исключением того, что она содержит другой набор данных. Другими словами, это дополнение к сумме дополнительных частей заголовка IP, всего заголовка UDP, данных UDP и дополнения нулями в конце, когда это необходимо.

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

Фильтры Wireshark для UDP

Чтобы увидеть только трафик UDP:

Для UDP не используются флаги. Для этого протокола можно только указать порт.

Показать трафик, источником которого является порт 53:

Показать трафик, который отправляется службе, прослушивающей порт 53:

UDP пакет, в котором встречается определённая строка, например, строка hackware:

Порт назначения ИЛИ исходный порт:

Время между пакетами (для выявления проблем сети):

Номер потока (запрос-ответ):

Сравнение UDP и TCP

TCP — ориентированный на соединение протокол, что означает необходимость «рукопожатия» для установки соединения между двумя хостами. Как только соединение установлено, пользователи могут отправлять данные в обоих направлениях.

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

UDP — более простой, основанный на сообщениях протокол без установления соединения. Протоколы такого типа не устанавливают выделенного соединения между двумя хостами. Связь достигается путём передачи информации в одном направлении от источника к получателю без проверки готовности или состояния получателя. В приложениях для голосовой связи через интернет-протокол (Voice over IP, TCP/IP) UDP имеет преимущество над TCP, в котором любое «рукопожатие» помешало бы хорошей голосовой связи. В VoIP считается, что конечные пользователи в реальном времени предоставят любое необходимое подтверждение о получении сообщения.

Русские Блоги

Уровень TCP / IP 4 — подробное объяснение пакетов данных TCP на транспортном уровне

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

(1) Данные приложения делятся на блоки данных, которые TCP считает наиболее подходящими для отправки. Эта часть управляется опцией «MSS» (максимальная длина пакета). Обычно этот механизм также называется механизмом согласования. MSS определяет длину самого большого блока данных, который TCP передает на другой конец. Стоит отметить, что MSS может появляться только в сегменте сообщения SYN. ​​Если одна сторона не получает значение MSS от другой стороны, MSS устанавливается в 536 байтов. Вообще говоря, в случае отсутствия сегментации, чем больше значение MSS, тем лучше, что может улучшить использование сети.

(2) Механизм ретрансляции. Установите таймер и дождитесь пакета подтверждения.

(3) Проверьте заголовок и данные.

(4) TCP сортирует полученные данные и передает их на прикладной уровень.

(5) Принимающая сторона TCP отбрасывает дублирующиеся данные.

(6) TCP также обеспечивает управление потоком. (Предоставляется размером окна, объявленным на каждом конце)

1. Процесс инкапсуляции данных протокола TCP / IP

Принимая TCP или UPD для транспортного уровня, IP для сетевого уровня и Ethernet для канального уровня в качестве примеров, вы можете видеть, что процесс инкапсуляции пакетов в TCP / IP показан на рисунке. Пользовательские данные инкапсулируются протоколом прикладного уровня и передаются на транспортный уровень. Транспортный уровень инкапсулирует заголовок TCP и передает его на сетевой уровень. После того, как сетевой уровень инкапсулирует заголовок IP, он затем передается на уровень канала передачи данных. Уровень канала передачи данных инкапсулирует заголовок кадра Ethernet и В конце кадра он передается на физический уровень, который отправляет данные на физическую линию в виде потока битов.

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

После того, как хост назначения получает пакет данных, как он, наконец, достигает прикладной программы через стеки протоколов всех уровней? Весь процесс показан на рисунке ниже.

Сначала драйвер Ethernet (сетевая карта) определяет, является ли полезная нагрузка кадра данных (полезная нагрузка, относящаяся к фактически переданным данным, кроме заголовка протокола) дейтаграммой протокола IP, ARP или RARP в соответствии с полем «протокол верхнего уровня» в заголовке Ethernet. , А затем передал соответствующее соглашение. Если это дейтаграмма IP, то протокол IP определяет, является ли полезная нагрузка дейтаграммы TCP, UDP, ICMP или IGMP в соответствии с полем «верхнего уровня» в заголовке IP, и затем передает ее в соответствующий протокол для обработки. Если это сегмент TCP или сегмент UDP, протокол TCP или UDP определяет, какой пользовательский процесс должен передать данные прикладного уровня в соответствии с полем «номер порта» заголовка TCP или заголовка UDP. IP-адрес — это адрес, который идентифицирует разные хосты в сети, а номер порта — это адрес, который идентифицирует разные процессы на одном и том же хосте. IP-адрес и номер порта вместе определяют единственный процесс в сети.

Обратите внимание, что хотя для дейтаграмм IP, ARP и RARP требуются драйверы Ethernet для инкапсуляции кадров, они функционально разделены: ARP и RARP принадлежат канальному уровню, а IP — сетевому уровню. Хотя для данных ICMP, IGMP, TCP и UDP требуется, чтобы протокол IP был инкапсулирован в дейтаграммы, функционально ICMP, IGMP и IP принадлежат сетевому уровню, а TCP и UDP — транспортному уровню.

2. TCP / IP пакет

Мы проходим Wireshark Захват пакета: я увидел пять слоев данных:

Первая строка Кадр 3339: кадр данных физического уровня: строка 83 байта, фактический захват 83 байта

Вторая линия Ethernet II: сетевая карта канального уровня, версия протокола Ethernet II, адрес источника: фабричное имя _ серийный номер (адрес сетевой карты), назначение: фабричное имя _ серийный номер (адрес сетевой карты)

Третья строка Интернет-протокола версии 4: IP-пакет сетевого уровня, IPV4, IP-адрес источника: 10.44.13.7; IP-адрес назначения: 10.171.8.154.

Строка 4 Протокол управления передачей: пакет данных TCP транспортного уровня: исходный порт 21000, порт назначения: 52529; Seqсерийный номер: Каждый раз, когда отправляется пакет данных RTP, порядковый номер увеличивается на 1, ACK — это флаг подтверждения в заголовке пакета данных TCP, чтобы подтвердить принятое сообщение TCP, которое является 183589, указывая, что номер подтверждения действителен; длина Len составляет 17 байтов. ;

Данные пятой строки: данные

Формат всего пакета данных показан ниже:

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

Номер кадра Время ИсточникадресЦельадресСоглашение высокого уровня Обзор информации в пакете
No. Time Source Destination Protocol Info
1 0.000000 202.203.44.225 202.203.208.32 TCP 2764 > http [SYN] Seq=0 Len=0 MSS=1460 Порт источника> Порт назначения [Запрос на установление соединения TCP]
Обзор кадра данных первого физического уровня первого физического уровня

Frame 1 (62 bytes on wire, 62 bytes captured) Кадр №1, 62 байта в строке, фактически записано 62 байта
Arrival Time: Jan 21, 2008 15:17:33.910261000 Дата и время захвата
[Time delta from previous packet:0.00000 seconds] Интервал времени между этим пакетом и предыдущим пакетом
[Time since reference or first frame: 0.00 seconds] Интервал между этим пакетом и первым кадром
Frame Number: 1 Номер кадра
Packet Length: 62 bytes Длина кадра
Capture Length: 62 bytes Длина захвата
[Frame is marked: False] Помечен ли этот кадр: нет
[Protocols in frame: eth:ip:tcp] Иерархия протокола, инкапсулированная в кадр
[Coloring Rule Name: HTTP] Название протокола, отмеченное разными цветами: HTTP
[Coloring Rule String: http || tcp.port == 80] Окрашивание Строка символов, показывающая правила:

Информация заголовка кадра Ethernet второго канального уровня второго канального уровня

Ethernet II, Src: AcerTech_5b:d4:61 (00:00:e2:5b:d4:61), Dst: Jetcell_e5:1d:0a (00:d0:2b:e5:1d:0a)
Версия протокола Ethernet II, адрес источника: заводское имя_серийный номер (адрес сетевой карты), назначение: заводское имя_серийный номер (адрес сетевой карты)
Destination: Jetcell_e5:1d:0a (00:d0:2b:e5:1d:0a) Назначение: заводское имя_серийный номер (адрес сетевой карты)
Source: AcerTech_5b:d4:61 (00:00:e2:5b:d4:61) Источник: заводской номер_серийный номер (адрес сетевой карты)
Type: IP (0x0800) Тип протокола верхнего уровня, инкапсулированный во фрейм, — это IP (шестнадцатеричный код 0800). См. Рис. 3.2 на стр. 70 учебника.

третий этаж Информация заголовка IP-пакета сетевого уровня

Internet Protocol, Src: 202.203.44.225 (202.203.44.225), Dst: 202.203.208.32 (202.203.208.32) Интернет-протокол, IP-адрес источника, IP-адрес назначения
Version: 4 Интернет-протокол IPv4 (для этой части см. Структуру поля дейтаграммы IPv4 на рис. 4.15 на стр. 119 этого учебника)
Header length: 20 bytes Длина заголовка IP-пакета
Differentiated Services Field:0x00(DSCP 0x00:Default;ECN:0x00) Поле дифференциального обслуживания
Total Length: 48 Общая длина IP-пакета

Identification:0x8360 (33632) Флаговое поле

Flags: Поле «Отметить» (разрешено ли фрагментировать IP-пакет во время передачи по маршруту, стр. 125 учебника)

Fragment offset: 0 Смещение сегмента (когда IP-пакет сегментируется и передается, идентификатор этого сегмента)
Time to live: 128 Пожизненная TTL
Protocol: TCP (0x06) Протокол верхнего уровня, инкапсулированный в этот пакет, является TCP
Header checksum: 0xe4ce [correct] Контрольная сумма данных заголовка
Source: 202.203.44.225 (202.203.44.225) IP-адрес источника
Destination: 202.203.208.32 (202.203.208.32) IP-адрес получателя

Ниже приведена информация заголовка сегмента данных TCP транспортного уровня.

Transmission Control Protocol, Src Port: 2764 (2764), Dst Port: http (80), Seq: 0, Len: 0 Содержание протокола управления передачей TCP
Source port: 2764 (2764） Имя порта источника (номер порта) (см. Рисунок 5.7 на стр. 149 учебника).
Destination port: http (80) Имя порта назначения http (номер порта 80)
Sequence number: 0 (relative sequence number) Серийный номер (относительный серийный номер)
Header length: 28 bytes Длина головы
Flags: 0x02 (SYN) Поле тега TCP (это поле SYN, которое является запросом на установление соединения TCP)
Window size: 65535 Размер окна управления потоком
Checksum: 0xf73b [correct] Контрольная сумма сегмента данных TCP
Options: (8 bytes) По желанию

3. Пакеты TCP-пакетов

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

Среди них мы фиксируем пакет и видим информацию о данных в заголовке протокола управления передачей:

Transmission Control Protocol, Src Port: 21000, Dst Port:52529, Seq: 12936, ACK 183589 Len: 17 Содержание протокола управления передачей TCP
Source port: 21000 Имя исходного порта (номер порта) (используется для поиска исходного процесса приложения)
Destination port: 52529 Порт назначения
Sequence number: 0 (relative sequence number) Серийный номер (относительный серийный номер, этот серийный номер используется для определения правильного местоположения передаваемых данных, а серийный номер используется для обнаружения потерянных пакетов);

[Next sequence number: 215 (relative sequence number)] # Следующий серийный номер

Acknowledgement number :183589 Это 32-битный серийный номер подтверждения для подтверждения его действительности;
Header length: 32 bytes Длина головы
Flags: 0x02 (SYN) Поле тега TCP (это поле SYN, которое является запросом на установление соединения TCP)
Window size value: 6364 Размер окна управления потоком
Checksum: 0xf73b [correct] Контрольная сумма сегмента данных TCP
Options: (12 bytes) По желанию

Следующие инструкции объясняют подробно:

Исходный порт и порт назначения: 2 байта каждый, 16-битный номер порта плюс 32-битный IP-адрес, вместе составляют адрес, эквивалентный точке доступа к услуге транспортного уровня

Seq серийный номер: 4 байта , Порядковый номер первого байта части данных, отправленной в этом сегменте. В потоке данных, передаваемом по TCP, каждый байт имеет порядковый номер.

1. Предполагая, что определенный порядковый номер равен 300, простое понимание состоит в том, что отправитель сообщает принимающей стороне, что «отправленные мной данные начинаются с 300-го».

2. Предполагая, что данные len = 100 байтов, порядковый номер следующего сегмента равен 400;

Серийный номер подтверждения ACK: 4 байта Является ли порядковый номер первого байта данных, ожидаемых для получения другой стороной в следующий раз, то есть порядковый номер в заголовке следующего сегмента, ожидаемого для получения;

1、 Убедитесь, что серийный номер является последним, что байт данных был успешно получен плюс 1 , Также можно понять, что принимающая сторона сообщает отправляющей стороне, что она хочет получить начальный порядковый номер в следующий раз. Если предположить, что в какой-то момент подтверждено, что серийный номер равен 1000, простое понимание состоит в том, что получатель сообщает отправителю: «Я получил 999-й серийный номер, и в следующий раз, когда я хочу получать данные, начинается с 1000».

2. Поскольку поле порядкового номера имеет длину 32 бита, 4 ГБ данных могут быть пронумерованы, чтобы при повторном использовании порядкового номера данные старого порядкового номера в сети давно исчезали;

В процессе передачи данных:

Первое сообщение отправлено: Seq1 = 1 ACK1 = 1 len1 = 359

Получено первое ответное сообщение: Seq2 = 1 ACK2 = Seq1 + ACK1 = 360, len1 = 17

Следующее сообщение отправлено: Seq3 = ACK2 = Seq1 (последнее отправленное сообщение seq1 + последнее отправленное сообщение len1) = 360 ACK3 = Seq1 + ACK1 = 18 len3 = 0

Два ACK одинаковы: вы должны отправить данные, но мы не получили данные, поэтому вам все равно нужно отправить один и тот же

Длина заголовка(4) : Длина заголовка сообщения (единица измерения: биты) / 32

1000 (переводится в десятичное число 10, 8 * 32/8 = 32, длина заголовка сообщения составляет 32 байта)

Это поле существует, поскольку необязательное поле в заголовке TCP имеет переменную длину

Заголовок не содержит никаких дополнительных полей, а длина составляет 20 байтов, максимальное значение, которое может быть представлено 4 битами, равно 1111, которое преобразуется в 15 в десятичном формате, 15 * 32/8 = 60, поэтому Максимальная длина заголовка составляет 60 байтов.

FlagФлаг бит:

Сумма Nonce: эффективно исключить возможное злоупотребление ECN, RFC 3540
Окно перегруженности уменьшено (CWR): Окно перегруженности уменьшено
   ECN-Echo: знак ECE / ECN
URG: Urgent Pointer действителен (urlpointer). Когда URG = 1, это означает, что это сообщение должно быть передано как можно скорее, а не в исходном порядке очередей. Используемый вместе с полем «аварийный указатель», аварийный указатель указывает порядковый номер последнего байта срочных данных в этом сегменте, так что приемник может знать, какова длина аварийных данных;
ACK: ACK: порядковый номер подтверждения действителен, только если ACK = 1, поле порядкового номера подтверждения имеет смысл;
PSH: когда PSH = 1, это означает, что удаленный TCP запрашивается для немедленной отправки этого сегмента на уровень приложений, вместо ожидания заполнения всего кэша перед его доставкой вверх.
RST: RST: восстановить соединение. Когда RST = 1, это означает, что произошла серьезная ошибка, и соединение должно быть сброшено до восстановления соединения передачи. Бит сброса также используется для отклонения недопустимого сегмента или отказа в открытии соединения;
SYN: синхронный порядковый номер используется для инициирования соединения и используется при установлении соединения. Когда SYN = 1 и ACK = 0, это означает, что это сегмент запроса соединения. Если другая сторона согласна установить соединение, задайте SYN = 1 и ACK = 1 в возвращаемом сегменте сообщения. Следовательно, SYN = 1 указывает, что это запрос соединения или сообщение о принятии соединения, и значение ACK используется для различения, какой тип сообщения;
FIN: отправитель завершает задачу отправки (активно закрывается), которая используется для разъединения соединения.Если FIN = 1, это указывает, что отправляемая строка байтов была отправлена, и запрашивает разъединение соединения передачи;

размер окна (2 байта):(Управление потоком TCP обеспечивается каждым концом соединения через объявленный размер окна. Размер окна — это число байтов, начиная со значения, указанного в поле порядкового номера подтверждения. Это значение является байтом, который ожидает приемная сторона. Размер окна является 16-битное поле, поэтому максимальный размер окна составляет 65535 байт).

Контрольная сумма контрольной суммы(2 байта): контрольная сумма охватывает весь сегмент сообщения TCP, обязательные поля, рассчитанные и сохраненные отправляющей стороной и проверенные принимающей стороной

Срочный указатель Срочный указатель(2 байта): когда флаг Urgent установлен в 1, аварийный указатель действителен

Параметры:Поле параметра позволяет каждому хосту установить максимально допустимую пропускную способность TCP (по умолчанию 536 байт).