Что происходит если часть сообщения с использованием tcp не доставляется на конечный хост

ИТ База знаний

Полезно

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

🔥 Популярное

Модель OSI – это просто!

TCP и UDP – в чем разница?

👌 Похожее

Топ 5 инструментов моделирования сетей в 2020 году

DNS: what is it and how it works?

Проектирование и монтаж СКС

Что такое оптическое волокно?

Установление и прекращение TCP соединения

3 часть. СИН-АК-СИНАК

Полный курс по Сетевым Технологиям

В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer

Установление TCP-соединения происходит до того, как любая из других функций TCP сможет начать свою работу. Установление соединения относится к процессу инициализации полей «Sequence» и «Acknowledgment» и согласования используемых номеров портов. На рисунке 5 показан пример процесса установления соединения.

TCP сообщает об установлении соединения, используя 2 бита в полях флагов заголовка TCP. Эти биты, называемые флагами SYN и ACK, имеют особенно интересное значение. SYN означает «синхронизировать порядковые номера», что является одним из необходимых компонентов при инициализации TCP.

Восстановление после ошибок и надежность

TCP обеспечивает надежную передачу данных, что также называется reliability or error recovery. Для обеспечения надежности TCP нумерует байты данных, используя поля «Sequence» и «Acknowledgment» в заголовке TCP. TCP обеспечивает надежность в обоих направлениях, используя поле Sequence Number одного направления в сочетании с полем Acknowledgment в противоположном направлении.

Однако этот пример не исправляет никаких ошибок; он просто показывает основы того, как хост-отправитель использует поле порядкового номера для идентификации данных, а хост-получатель использует прямые подтверждения для подтверждения данных. Более интересное обсуждение вращается вокруг того, как использовать эти же инструменты для восстановления ошибок. TCP использует поля «Sequence» и «Acknowledgment«, чтобы принимающий хост мог заметить потерю данных, попросить отправляющий хост повторно отправить, а затем подтвердить, что повторно отправленные данные прибыли.

Существует множество вариантов того, как TCP выполняет исправление ошибок. На рисунке 8 показан только один такой пример, детализация которого аналогична предыдущему. Веб-браузер снова отправляет три сегмента TCP, снова по 1000 байт каждый, снова с легко запоминающимися порядковыми номерами. Однако в этом примере второй сегмент TCP не может пройти через сеть.

Рисунок указывает на три набора идей, лежащих в основе того, как думают два хозяина. Во-первых, справа сервер понимает, что он не получил все данные. Два полученных сегмента TCP содержат байты с номерами 10001999 и 30003999. Очевидно, сервер не получил байты, пронумерованные между ними. Затем сервер решает подтвердить все данные вплоть до потерянных, то есть отправить обратно сегмент с полем подтверждения, равным 2000.

Наконец, обратите внимание, что сервер может подтверждать не только повторно отправленные данные, но и любые предыдущие данные, которые были получены правильно. В этом случае сервер получил повторно отправленный второй сегмент TCP (данные с порядковыми номерами 20002999), и сервер уже получил третий сегмент TCP (данные с номерами 30003999). Следующее поле подтверждения сервера подтверждает данные в обоих этих сегментах с полем подтверждения, равным 4000.

Управление потоком с использованием окон

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

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

Начнем с первого сегмента, отправленного сервером на ПК. Поле Acknowledgment должно быть вам знакомо: оно сообщает ПК, что сервер ожидает следующий сегмент с порядковым номером 1000. Новое поле, поле окна, установлено на 3000. Поскольку сегмент передается на ПК, это значение сообщает ПК, что ПК может послать не более 3000 байтов по этому соединению до получения подтверждения. Итак, как показано слева, ПК понимает, что может отправлять только 3000 байтов, и прекращает отправку, ожидая подтверждения, после отправки трех 1000-байтовых сегментов TCP.

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

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

Онлайн курс по Кибербезопасности

Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии

Источник

Устранение неполадок подключения TCP/IP

Вы можете встретить ошибки подключения в конце приложения или ошибках времени. Наиболее распространенные сценарии:

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

TCP определяется как протокол, ориентированный на подключение и надежный. Одним из способов обеспечения надежности TCP является процесс рукопожатия. Создание сеанса TCP начнется с трехначерного рукопожатия, а затем с передачи данных, а затем с четырехнабного закрытия. Четырех способ закрытия, в котором отправитель и приемник соглашаются на закрытие сеанса, является изящным закрытием. После закрытия в 4-м режиме на сервере будет 4 минуты времени (по умолчанию), в течение которых будут обрабатываться все ожидающих пакеты в сети, это TIME_WAIT состояние. После завершения TIME_WAIT состояния все ресурсы, выделенные для этого подключения, будут освобождены.

Сброс TCP — это резкое закрытие сеанса; это приводит к немедленному отпусту ресурсов, выделенных для подключения, и стирается вся другая информация о подключении.

Сброс TCP идентифицирован флагом RESET в заглавной загонке 1 TCP.

Трассировка сети в источнике и пункте назначения позволяет определить поток трафика и узнать, в какой момент наблюдается сбой.

В следующих разделах описаны некоторые сценарии, когда вы увидите сброс.

Капли пакетов

Когда один одноранговой TCP отправляет пакеты TCP, для которых нет ответа, полученного с другого конца, одноранговая служба TCP в конечном итоге перенаправляет данные, а когда ответа не получено, сеанс завершится отправкой сброса ACK (это означает, что приложение признает все данные, которые обмениваются до сих пор, но из-за сброса пакета подключение закрывается).

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

Если начальное рукопожатие TCP не удается из-за перепадов пакетов, вы увидите, что пакет TCP SYN переназначяется только три раза.

Источник, подключающийся к порту 445:

Сторона назначения: применяя тот же фильтр, пакеты не видятся.

Для остальных данных TCP повторно передает пакеты пять раз.

След сторон 192.168.1.62:

Боковой след назначения 192.168.1.2:

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

Если вы видите, что пакеты SYN достигают пункта назначения, но пункт назначения по-прежнему не отвечает, убедитесь, что порт, к который вы пытаетесь подключиться, находится в состоянии прослушивания. (Выход Netstat поможет). Если порт прослушивается, а ответа нет, может произойть падение WFP.

Неправильный параметр в загонке TCP

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

В этом случае вам снова потребуется помощь сетевой группы, чтобы определить любое устройство, которое изменит пакеты или переиграет пакеты в пункт назначения. Наиболее распространенными являются устройства RiverBed или ускорители WAN.

Сброс сторон приложения

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

Сброс приложения — это те, где вы видите флаг подтверждения, установленный вместе с 1 флагом сброса. Это означает, что сервер признает получение пакета, но по каким-либо причинам он не принимает подключение. Это когда приложение, которое получило пакет, не понравилось то, что он получил.

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

Сторона источника

На трассировку в сторону назначения

Вы также видите пакет флага ACK+RST в случае, если syn пакета создания TCP отправляется. Пакет TCP SYN отправляется, когда клиент хочет подключиться к определенному порту, но если пункт назначения/сервера по какой-либо причине не хочет принимать пакет, он отправляет пакет ACK+RST.

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

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

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

Затем можно просмотреть журналы событий безопасности, чтобы просмотреть падение пакета на определенном порт-IP и связанный с ним фильтровый ID.

Источник

Что такое TCP/IP и как работает этот протокол

Протокол TCP/IP – это целая сетевая модель, описывающая способ передачи данных в цифровом виде. На правилах, включенных в нее, базируется работа интернета и локальных сетей независимо от их назначения и структуры.

Что такое TCP/IP

Произошло наименование протокола от сокращения двух английских понятий – Transmission Control Protocol и Internet Protocol. Набор правил, входящий в него, позволяет обрабатывать как сквозную передачу данных, так и другие детали этого механизма. Сюда входит формирование пакетов, способ их отправки, получения, маршрутизации, распаковки для передачи программному обеспечению.

Стек протоколов TCP/IP был создан в 1972 году на базе NCP (Network Control Protocol), в январе 1983 года он стал официальным стандартом для всего интернета. Техническая спецификация уровней взаимодействия описана в документе RFC 1122.

В составе стека есть и другие известные протоколы передачи данных – UDP, FTP, ICMP, IGMP, SMTP. Они представляют собой частные случаи применения технологии: например, у SMTP единственное предназначение заключается в отправке электронных писем.

Уровни модели TCP/IP

Протокол TCP/IP основан на OSI и так же, как предшественник, имеет несколько уровней, которые и составляют его архитектуру. Всего выделяют 4 уровня – канальный (интерфейсный), межсетевой, транспортный и прикладной.

Канальный (сетевой интерфейс)

Аппаратный уровень обеспечивает взаимодействие сетевого оборудования Ethernet и Wi-Fi. Он соответствует физическому из предыдущего стандарта OSI. Здесь задача состоит в кодировании информации, ее делению на пакеты и отправке по нужному каналу. Также измеряются параметры сигнала вроде задержки ответа и расстояния между хостами.

Межсетевой (Internet Layer)

Интернет состоит из множества локальных сетей, объединенных между собой как раз за счет протокола связи TCP/IP. Межсетевой уровень регламентирует взаимодействие между отдельными подсетями. Маршрутизация осуществляется путем обращения к определенному IP-адресу с использованием маски.

Если хосты находятся в одной подсети, маркируемой одной маской, данные передаются напрямую. В противном случае информация «путешествует» по целой цепочке промежуточных звеньев, пока не достигнет нужной точки. Назначение IP-адреса проводится по стандарту IPv4 или IPv6 (они не совместимы между собой).

Транспортный уровень (Transport Layer)

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

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

Прикладной уровень (Application Layer)

Здесь объединены 3 уровня модели OSI – сеансовый, представления и прикладной. На него ложатся задачи по поддержанию сеанса связи, преобразованию данных, взаимодействию с пользователем и сетью. На этом уровне применяются стандарты интерфейса API, позволяющего передавать команды на выполнение определенных задач.

Возможно и использование «производных» протоколов. Например, для открытия сайтов используется HTTPS, при отправке электронной почты – SMTP, для назначения IP-адресов – DHCP. Такой подход упрощает программирование, снижает нагрузку на сеть, увеличивает скорость обработки команд и передачи данных.

Порты и сокеты – что это и зачем они нужны

Процессы, работающие на прикладном уровне, «общаются» с транспортным, но они видны ему как «черные ящики» с зашифрованной информацией. Зато он понимает, на какой IP-адрес адресованы данные и через какой порт надо их принимать. Этого достаточно для точного распределения пакетов по сети независимо от месторасположения хостов. Порты с 0 до 1023 зарезервированы операционными системами, остальные, в диапазоне от 1024 до 49151, условно свободны и могут использоваться сторонними приложениями.

Комбинация IP-адреса и порта называется сокетом и используется при идентификации компьютера. Если первый критерий уникален для каждого хоста, второй обычно фиксирован для определенного типа приложений. Так, получение электронной почты проходит через 110 порт, передача данных по протоколу FTP – по 21, открытие сайтов – по 80.

Преобразование IP-адресов в символьные адреса

Технология активно используется для назначения буквенно-цифровых названий веб-ресурсов. При вводе домена в адресной строке браузера сначала происходит обращение к специальному серверу DNS. Он всегда прослушивает порт 53 у всех компьютеров, которые подключены к интернету, и по запросу преобразует введенное название в стандартный IP-адрес.

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

Источник

Головоломки TCP

Необходимые условия

Эти головоломки подразумевают наличие базовых знаний о работе TCP на Unix-подобных системах. Но вам не нужно быть мастером, чтобы вникнуть в них. Например:

nc(1) очень простая программа. Мы будем использовать её в двух режимах:

Разминка: нормальный разрыв TCP

Начнём с базовой ситуации. Представим, что мы настроили сервер на kodos :

Теперь я устанавливаю соединение на kang :

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

Нажмём CTRL-C на kodos :

А вот что мы видим на kang :

Что случилось? Давайте разберемся:

Вот так, согласно netstat, выглядит финальное состояние:

На kang для этого соединения нет никаких исходящих данных.

Промежуточные состояния проходят очень быстро, но вы можете отследить их с помощью DTrace TCP provider. Поток пакетов можно посмотреть с помощью snoop(1m) или tcpdump(1).

Головоломка 1: Перезапуск электропитания

Что случится с установленным неактивным TCP подключением при перезапуске питания одной из систем?

Давайте проверим. Устанавливаем подключение:

Для эмуляции перезапуска электропитания я воспользуюсь функцией «reboot» из VMware. Обратите внимание, что это будет настоящий перезапуск — всё, что приводит к постепенному выключению, больше похоже на первый пример.

Спустя 20 минут kang всё в том же состоянии:

Если оставить всё как есть, то kang никогда не узнает, что kodos был перезагружен.

Другой источник содержит чуть больше подробностей:

Головоломка 2: Отключение электропитания

Что случится, если конечная точка TCP соединения отключится от сети на какое-то время? Узнают ли об этом остальные узлы? Если да, то как? И когда?

Вновь установим соединение с помощью nc :

Теперь внезапно выключим питание kodos и попытаемся отправить данные с kang :

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

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

Головоломка 3: Нарушение соединения без его падения

Подсказка: рассмотрим вышеописанный случай, когда соединение застряло в статусе ESTABLISHED. Справедливо считать, что ответственность за решение этой проблемы несёт приложение, так как оно держит сокет открытым и может обнаружить посредством отправки данных, когда соединение было прервано. Но что если приложение уже не держит сокет открытым?

В разминке мы рассматривали ситуацию, когда nc на kodos закрыло сокет. Мы сказали, что nc на kang прочитало 0 (указатель окончания передачи) и закрыло сокет. Допустим, сокет остался открытым. Очевидно, что из него невозможно было бы читать. Но касательно TCP ничего не говорится о том, что вы не можете отправлять дополнительные данные той стороне, которая послала вам FIN. FIN означает лишь закрытие потока данных в том направлении, по которому был послан FIN.

Сперва настроим подключение:

Теперь убедимся, что на обеих сторонах подключение находится в статусе ESTABLISHED:

На kodos применим CTRL-C для процесса nc :

На kang сразу увидим следующее:

Теперь посмотрим на статус подключений TCP:

Давайте подождём минуту и вновь проверим статус TCP-подключений. Выяснилось, что на kodos подключение полностью пропадает, но всё ещё существует на kang :

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

Это то же самое, что мы видели в Головоломке 1: write() успешно выполняется, так как TCP-стек ещё не знает, что соединение закрыто. Но затем идёт RST, который пробуждает находящийся в poll() тред, и последующий запрос read() возвращает ECONNRESET.

Заключение

TCP обычно представляется нам как протокол, который поддерживает абстракцию — «TCP-соединение» — между двумя системами. Мы знаем, что из-за некоторых программных или сетевых проблем соединение упадёт. Но не всегда очевидно, что бывают случаи возникновения сбоев самой абстракции, из-за чего системы расходятся во мнении по поводу состояния подключения. Например:

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

Кроме того, дескриптор файла «оторван» от соответствующего TCP-соединения. Соединения существуют (в разных, связанных с закрытием состояниях) даже тогда, когда приложение закрыло дескриптор файла. А иногда дескриптор файла может быть открыт, хотя TCP-соединение было закрыто в результате ошибки.

Остальные уроки, о которых стоит помнить:

Некоторые малоизвестные моменты:

Источник