Запрос на открытие tcp сокета ошибка

Обновлено: 08.07.2024

Состояние соединения TCP и изучение соответствующих команд

Что такое протокол TCP

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

Чтобы понять состояние соединения TCP, вы должны сначала понять, что происходит с трехсторонним рукопожатием и четырехсторонней волной TCP.На следующем рисунке показана диаграмма перехода состояний трехстороннего рукопожатия и четырехсторонней волны TCP (рисунок из статьи «Zhuhu»)."Три рукопожатия, четыре волны" Вы действительно понимаете?》）：

Не путайте клиент / сервер на рисунке с клиентским сервером в проекте: сторона, которая инициирует соединение или активно закрывает соединение, является клиентом, а пассивная - сервером. Служба может выступать как клиентом, так и сервером.

TCP трехстороннее рукопожатие

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

Первое рукопожатие: клиент сначала отправляет пакет SYN (j) в качестве запроса на установление соединения, подтверждая, является ли его способность отправки нормальной
Второе рукопожатие: Сервер отвечает ответом подтверждения пакета ACK (j + 1) на пакет SYN Клиента и отправляет пакет SYN (k) Клиенту, чтобы указать, что ему нужно установить соединение, подтверждая свою собственную передачу, подтверждая, что у него есть возможности приема. способность
Третье рукопожатие: после приема пакета SYN + ACK Клиент отправляет ответ подтверждения пакета ACK (k + 1), указывающий, что его возможности приема являются нормальными. В это время три установления связи завершены, чтобы установить надежное соединение

Четыре волны TCP

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

Первая волна раздач: клиент отправляет пакет FIN для запроса на отключение
Вторая волна: Когда Сервер получает пакет FIN, он немедленно отвечает ACK для подтверждения ответа, указывая, что я получил ваш запрос на закрытие соединения. В настоящее время Сервер имеет возможность получать данные
Третья волна: через некоторое время, когда сервер подтверждает, что данные на клиенте приняты, он отправляет пакет FIN, чтобы закрыть соединение и больше не получать данные
Четвертая волна: когда Клиент получает FIN, он немедленно отвечает ACK для подтверждения, а затем ожидает 2MSL, чтобы закрыть соединение

Состояние TCP-соединения

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

LISTEN (сервер): прослушивание запросов на подключение от удаленного порта TCP.После запуска сервера он находится в состоянии LISTEN для отслеживания запросов TCP от разных клиентов и установления соединения.
SYN-SENT (клиент): во время трехстороннего рукопожатия клиент находится в состоянии ожидания установления соединения после отправки SYN для запроса
SYN_RCVD (сервер): во время трехстороннего установления связи, когда сервер получает сигнал SYN от клиента, он отправляет флаги ACK и SYN клиенту для установления соединения, и сервер находится в состоянии SYN_RCVD
УСТАНОВЛЕН (сервер и клиент): после успешного трехстороннего рукопожатия клиент и сервер находятся в состоянии передачи данных
FIN-WAIT-1 (клиент): при четырехкратном махании клиент отправляет запрос FIN прерывания FIN для получения подтверждения прерывания от сервера
CLOSE_WAIT (Сервер): при четырехкратном колебании Клиент получает от клиента ответ на запрос FIN и отвечает ACK, чтобы подтвердить состояние отправки пакета FIN
FIN-WAIT-2 (Клиент): Когда четыре раза размахивают, когда Клиент получает ACK ответа Сервера на FIN, а затем получает пакет FIN от Сервера.
LAST_ACK (сервер): при четырехкратном колебании сервер отправляет запрос FIN для закрытия соединения до состояния перед закрытием соединения
TIME_WAIT (клиент): когда клиент машет четыре раза, клиент отвечает ACK на FIN сервера в состояние до закрытия соединения, также известное как состояние 2MSL
ЗАКРЫТЬ (сервер и клиент): состояние после закрытия соединения между сервером и клиентом

При нормальных обстоятельствах процесс перехода состояния клиента выглядит следующим образом:

В нормальных условиях процесс перехода состояния сервера выглядит следующим образом:

Некоторые проблемы в TCP трехстороннем рукопожатии и четырехстороннем переходе состояния волны

Что такое MSL?

Что такое TTL?

Что такое RTT?

Что такое MTU?

Что такое MSS?

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

При четырехкратном махании, почему Клиент не закрывает соединение сразу после завершения ACK для Сервера, и должно быть состояние TIME_WAIT (2MSL)?

Как улучшить, если на сервере много TIME_WAIT?

Как улучшить, если на сервере много CLOSE_WAIT?

SYN FLOOD атака

О сокете

Одно TCP-соединение соответствует одному сокету
Уникальный идентификатор сокета:
Служба TCP в состоянии прослушивания может взаимодействовать с сокетами от нескольких клиентов одновременно
Разные процессы могут прослушивать один и тот же порт, если их протоколы (TCP / UDP) разные
Один процесс может открывать и закрывать несколько сокетов
Дочерний процесс может наследовать все файловые дескрипторы (FD) от родительского процесса, поэтому, если между различными процессами или потоками существуют отношения родитель-потомок, вы можете использовать один и тот же сокет
Службе TCP в состоянии прослушивания нужен только один порт прослушивания, но можно установить несколько сокетов
Число соединений с сокетами, которые могут быть созданы портом на сервере, теоретически не имеет верхнего предела, это зависит от объема памяти системы и верхнего предела файловых дескрипторов, которые могут быть созданы. Его можно установить, изменив верхний предел файловых дескрипторов.

Связанные команды в соединении TCP

команда netstat

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

Введение параметра

Список всех соединений TCP:

Только список подключений, которые слушают:

Просмотр имени процесса и имени пользователя в мониторинге

Посмотреть сетевой интерфейс:

Тот же эффект, что и для ifconfig и ip a

Статистика TCP каждого состояния подключения информации:

команда ping

Команда ping используется для проверки доступности сети к хосту назначения. Она может получить имя домена или IP-адрес и не может проверить порт. Она работает на третьем уровне эталонной модели OSI - сетевом уровне.

Команда ping и команда traceroute реализованы по протоколу ICMP, хотя инструмент ping также может его обнаружить, но из-за ограничения заголовка ip, ping не может полностью записать проходящий маршрутизатор. Таким образом, traceroute просто заполняет этот недостаток, поэтому, если вы хотите запросить всю информацию о маршрутизации, вам все равно нужен traceroute

команда traceroute

Принцип raceroute заключается в использовании механизма уведомления ICMP с истекшим сроком действия ttl. Каждый раз при непрерывном увеличении ttl для непрерывного обнаружения маршрута следующего прыжка traceroute отправляет дейтаграмму с номером порта> 30000, поэтому, когда он достигает хоста назначения, он получает порт недоступным. ICMP ответил, что хост-источник знает, что хост может быть подключен.

Команда raceroute позволяет отслеживать маршрутизацию сетевых пакетов и время, потребляемое каждым шлюзом. Размер пакета по умолчанию составляет 40 байт.
Выходные данные raceroute увидят, что есть несколько строк, обозначенных звездочками, возможно потому, что брандмауэр заблокировал возвращаемую информацию ICMP, поэтому мы не можем получить какие-либо связанные пакеты данных для возврата данных
Каждый раз, когда пакет данных поступает в один и тот же пункт назначения из определенного источника, путь, по которому он идет, может отличаться, но в основном маршрут, по которому проходит большую часть времени, является одним и тем же.
По умолчанию каждый прыжок будет отправлять 3 пакета, но это может быть не тот же IP-адрес, поскольку между двумя шлюзами может быть стратегия балансировки нагрузки, поэтому в некоторых записях может быть 2 или 3 IP-адреса.
Список маршрутов, которые могут быть записаны заголовком ip, очень ограничен, поэтому traceroute увеличивает скорость отправки ttl, поэтому traceroute возвращается медленнее, чем дальше назад traceroute
Описание основных параметров:

команда lsof

lsof (список открытых файлов) - это инструмент для просмотра текущих системных файлов. В среде Linux все существует в форме файла. Через этот файл вы можете не только получать доступ к обычным данным, но также получать доступ к сетевым подключениям и оборудованию. Например, сокеты протокола управления передачей (TCP) и протокола пользовательских дейтаграмм (UDP) и т. Д., Система выделит дескриптор файла для приложения в фоновом режиме, дескриптор файла предоставляет много информации о самом приложении. ,

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

Информацию о состояниях сеанса TCP, трёх этапах соединения и об этапах его завершения можно найти в Википедии.
Программы, как правило, взаимодействуют с сокетами, используя read , write , connect , bind , listen и accept . Помимо этого, есть также send и recv , но в наших примерах они будут вести себя как read и write .
Я буду использовать в этой статье poll . Хотя многие системы используют что-то более эффективное, например, kqueue или epoll , в рамках нашей задачи все эти инструменты будут эквивалентны. Что касается приложений, использующих операции блокирования, а не какой-либо из этих механизмов: один раз поняв, как ошибки TCP отражаются на poll , вам будет проще догадаться, какой эффект они окажут на любые операции блокирования.

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

Как сервер. В этом режиме nc создаст сокет, будет прослушивать его, вызовет accept и заблокирует, пока не будет установлено соединение.
Как клиент. В этом режиме nc создаст сокет и установит соединение с удалённым сервером.

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

(Напоминаю, что в этих примерах я использую truss для вывода системных вызовов, которые делает nc . Информация о времени выводится с помощью флага - d , а -t позволяет выбрать, какие из вызовов мы хотим увидеть.)

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

На kodos мы видим:

Подключение TCP находится в состоянии ESTABLISHED, а оба процесса в poll . Мы можем увидеть это на каждой системе с помощью netstat :

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

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

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

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

Осуществляя выход из процесса, мы отправили SIGINT на сервер. После выхода закрылись дескрипторы файлов.
Когда закрывается последний дескриптор для сокета ESTABLISHED , стек TCP на kodos отправляет через соединение FIN и переходит в состояние FIN_WAIT_1 .
Стек TCP на kang получает пакет FIN, переводит собственное соединение в состояние CLOSE_WAIT и отправляет в ответ ACK. Пока клиент nc блокирует сокет — он готов к чтению, ядро будит этот тред с помощью POLLIN .
Клиент nc видит POLLIN для сокета и вызывает read , который тут же возвращает 0. Это означает конец соединения. nc решает, что мы закончили работу с сокетом, и закрывает его.
Тем временем, стек TCP на kodos получает ACK и переходит в состояние FIN_WAIT_2 .
Пока клиент nc на kang закрывает свой сокет, стек TCP на kang отправляет FIN на kodos . Соединение на kang переходит в состояние LAST_ACK .
Стек TCP на kodos получает FIN, соединение переходит в состояние TIME_WAIT , и стек на kodos подтверждает FIN.
Стек TCP на kang получает ACK для FIN и полностью удаляет соединение.
Спустя две минуты соединение TCP на kodos закрывается, и стек полностью удаляет соединение.

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

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

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

Выводы: Мы увидели нормальный путь прохождения системных вызовов во время установки и закрытия соединения. Обратите внимание, что kang незамедлительно обнаружил факт закрытия соединения на kodos — он был разбужен из poll , а возвращение нуля read обозначило завершение потока передачи. В этот момент kang решил закрыть сокет, что привело к закрытию соединения с kodos . Мы вернёмся к этому позже и посмотрим, что будет, если kang не станет закрывать сокет в этой ситуации.

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

Поскольку в процессе запланированной перезагрузки многие процессы завершаются корректным образом (с использованием команды “reboot”), то результат будет такой же, если ввести в консоль kodos команду “reboot” вместо завершения работы сервера с помощью CTRL-C. Но что случится, если в предыдущем примере мы просто отключим электропитание для kodos ? В конечном итоге kang об этом узнает, верно?

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

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

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

Мы склонны верить, что работа TCP заключается в постоянном поддержании абстракции (а именно, TCP-соединения) между несколькими системами, так что подобные случаи сломанной абстракции выглядят удивительно. И если вы считаете, что это какая-то проблема nc(1), то вы ошибаетесь. «netstat» на kodos не показывает никакого соединения с kang , но при этом kang покажет полностью рабочее подключение к kodos :

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

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

Эта ошибка не означает какую-то конкретную проблему с вызовом read . Она лишь говорит о том, что сокет был отключён. По этой причине большинство операций с сокетом приведут к ошибке.

Жесткое отключение энергии сильно отличается от аккуратного выключения. При тестировании распределённых систем нужно отдельно проверять и этот сценарий. Не ждите, что всё будет так же, как и при обычной остановке процесса (kill).
Бывают ситуации, когда одна сторона уверена, что TCP-соединение установлено, а другая — не уверена, и эта ситуация никогда не будет решена автоматически. Управлять решением таких проблем можно с использованием keep-alive для соединений на уровне приложения или TCP.
Единственная причина, по которой kang всё-таки узнал об исчезновении удалённой стороны, заключается в том, что он отправил данные и получил ответ, сигнализирующий об отсутствии подключения.

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

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

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

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

системе потребовалось 5 минут на осознание ситуации,
статус ошибки был ETIMEDOUT.

На этот раз вместо того, чтобы описывать вам специфическую ситуацию и спрашивать, что происходит, я поступлю наоборот: опишу некое наблюдение и посмотрю, сможете ли вы понять, как такое произошло. Мы обсуждали несколько ситуаций, в которых kang может верить, что он подключён к kodos , но kodos об этом не знает. Возможно ли для kang быть подключённым к kodos так, чтобы kodos не знал об этом в течение неопределённого срока (т.е. проблема не решится сама собой), и при этом не было бы отключения или перезапуска электропитания, никакой другой ошибки операционной системы kodos или сетевого оборудования?

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

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

Чтобы продемонстрировать это, мы не можем использовать nc на kang , потому что оно автоматически закрывает сокет после получения 0. Поэтому, я написал демо-версию nc , под названием dnc, которая пропускает этот момент. Также dnc явным образом выводит системные вызовы, которые она совершает. Это даст нам шанс отследить состояния TCP.

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

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

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

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

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

Это имеет смысл: kudos отправил FIN на kang . FIN_WAIT_2 показывает, что kodos получил ACK от kang в ответ на посланный им FIN, а CLOSE_WAIT показывает, что kang получил FIN, но не отправил FIN в ответ. Это вполне нормальное состояние TCP-подключения, которое может длится бесконечно. Представьте, что kodos отправил запрос kang и не планировал отправлять ничего больше; kang может часами счастливо отправлять данные в ответ. Только в нашем случае kodos фактически закрыл сокет.

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

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

Вопрос вдогонку: что случится, если в этой ситуации kang отправит данные к kodos ? Не забывайте, kang всё ещё считает, что соединение открыто, хотя на стороне kodos оно уже завершено.

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

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

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

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

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

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

Некоторые пользователи Windows сталкиваются с кодом ошибки 10053 при попытке подключить свой компьютер с помощью почты SMTP или при попытке выполнить команду Winsock. Эта проблема обычно связана с ограничениями маршрутизатора, чрезмерно защищающими брандмауэрами или прокси-серверами и VPN.

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

Метод 1. Отключение или удаление избыточных антивирусных программ (если применимо)

Если вы используете сторонний пакет, вы сталкиваетесь с кодом ошибки 10053 при попытке выполнить определенное действие, связанное с вашим почтовым клиентом (например, загрузка или отправка электронной почты через VPOP3), скорее всего, эта проблема вызвана вашим программа-антивирус.

Щелкните правой кнопкой мыши значок Avast на панели задач, чтобы временно отключить Avast

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

Откройте диалоговое окно «Выполнить», нажав клавиши Windows + R. Затем введите «appwiz.cpl» в текстовое поле и нажмите Enter, чтобы открыть меню «Программы и файлы».Введите appwiz.cpl и нажмите Enter, чтобы открыть страницу установленных программ.
Зайдя в меню «Программы и компоненты», прокрутите список установленных программ и найдите проблемный антивирус или брандмауэр, вызывающий конфликт.
Когда вы его увидите, щелкните его правой кнопкой мыши и выберите «Удалить» из появившегося контекстного меню, чтобы начать процесс удаления.Удаление антивируса
После завершения операции перезагрузите компьютер и дождитесь завершения следующего запуска.
После того, как компьютер загрузится, следуйте инструкциям, относящимся к вашему антивирусу, чтобы удалить все остаточные файлы, оставшиеся после установки стороннего антивируса.
Как только вам удастся полностью удалить сторонний пакет безопасности из вашего AV, перейдите к следующему потенциальному исправлению ниже.

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

Метод 2: Выполнение полного сброса TCP / IP

Если код ошибки 10053 возникает сразу после разрыва соединения TCP / IP в Windows, скорее всего, это проблема с тайм-аутом передачи данных или ошибкой протокола. Как выясняется, это, скорее всего, вызвано сбоями в работе сетевого адаптера или классическим случаем неправильного диапазона DNS.

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

Если вы не знаете, как это сделать, следуйте приведенным ниже инструкциям, чтобы выполнить полный сброс TCP / IP из командной строки с повышенными привилегиями:

Откройте диалоговое окно «Выполнить», нажав клавиши Windows + R. Затем введите cmd внутри текстового поля и нажмите Ctrl + Shift + Enter, чтобы открыть командную строку с повышенными правами. По запросу UAC (Контроль учетных записей пользователей) нажмите Да, чтобы предоставить доступ администратора.Запуск командной строки
Как только вы войдете в командную строку с повышенными привилегиями, введите следующие команды по порядку и нажмите Enter после каждой, чтобы выполнить полный сброс TCP / IP: ipconfig / flushdns nbtstat -R nbtstat -RR netsh int reset all netsh int ip reset netsh winsock сброс настроек
После успешной обработки каждой команды закройте командную строку с повышенными привилегиями и перезагрузите компьютер.
После завершения следующего запуска повторите действие, которое ранее вызывало код ошибки 10053, и посмотрите, устранена ли проблема.

Метод 3: перезагрузка или сброс маршрутизатора / модема

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

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

В случае, если этот сценарий применим, есть два способа решить проблему и избежать получения кода ошибки 10053:

Если вы планируете или применяете этот метод, мы советуем начать с простого перезапуска и переходить ко второй процедуре только в том случае, если первое вспомогательное руководство (A) не решает проблему:

A. Перезагрузка роутера / модема

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

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

Перезагрузка роутера

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

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

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

Б. Сброс маршрутизатора / модема

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

В этом случае вам следует сбросить маршрутизатор или модем до заводского состояния, восстановить доступ в Интернет и посмотреть, закончится ли эта операция исправлением ошибки 10053.

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

Сброс маршрутизатора

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

После завершения процедуры сброса дождитесь восстановления доступа к Интернету, затем посмотрите, исправлен ли теперь код ошибки 10053. Имейте в виду, что если ваш интернет-провайдер использует PPPoE, вам нужно будет повторно вставить правильные учетные данные, прежде чем доступ в Интернет будет восстановлен.

Если этот сценарий неприменим или вы уже пробовали это безуспешно, перейдите к следующему потенциальному исправлению ниже.

Метод 4: отключите прокси или VPN-соединение (если применимо)

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

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

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

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

A. Удаление VPN на уровне системы

Нажмите клавишу Windows + R, чтобы открыть диалоговое окно «Выполнить». Как только вы окажетесь внутри, введите appwiz.cpl в текстовое поле и нажмите Enter, чтобы открыть меню «Программы и компоненты». Когда вам будет предложено UAC (Контроль учетных записей пользователей), нажмите Да, чтобы предоставить доступ администратора.Введите appwiz.cpl и нажмите Enter, чтобы открыть страницу установленных программ.
Как только вы окажетесь на экране «Программы и компоненты», найдите VPN-клиент в списке установленных приложений. Когда вы найдете его, щелкните его правой кнопкой мыши и выберите «Удалить» из появившегося контекстного меню.Удаление инструмента VPN
Находясь внутри экрана установки, следуйте инструкциям на экране, чтобы завершить процесс установки, затем перезагрузите компьютер после завершения операции и посмотрите, будет ли проблема устранена после завершения следующего запуска.

Б. Отключение прокси-сервера

Откройте диалоговое окно «Выполнить», нажав клавиши Windows + R. Внутри текстового поля введите inetcpl.cpl и нажмите Enter, чтобы открыть вкладку «Свойства Интернета». Когда вам будет предложено UAC (Контроль учетных записей пользователей), нажмите Да, чтобы предоставить доступ администратора.Диалог запуска: inetcpl.cpl
Как только вы окажетесь на экране свойств Интернета, перейдите на вкладку «Подключение» в горизонтальном меню в верхней части экрана, затем нажмите «Настройки локальной сети» (прямо под настройками локальной сети).
Откройте настройки LAN в Internet Options
Как только вы войдете в настройки локальной сети (LAN), войдите в категорию прокси-серверов и снимите флажок, связанный с Use a proxy server for your LAN.
Отключение прокси-сервера
После успешного отключения прокси-сервера перезагрузите компьютер и посмотрите, будет ли проблема устранена после завершения следующего запуска.

В распределенных системах управления обмен данными является одним из ключевых моментов работы системы. Контроллер CPM723-01 позволяет отправлять и получать данные по промышленному протоколу Modbus TCP на базе протокола TCP/IP с использованием двух портов Ethernet и по протоколу Modbus RTU/ACSII на базе последовательных сетей RS-485/ RS-232 с помощью коммуникационных модулей NIM741/NIM742. Кроме того, система исполнения контроллера CPM723-01 поддерживает механизм сетевого обмена данными между контроллерами, принадлежащими одной подсети, средствами специального протокола прикладного уровня CODESYS V3.

Взаимодействие между устройствами в рамках стека TCP/IP осуществляется с помощью связки IP адреса и порта.

Для заданияIP адресав настоящее время чаще всего используется протокол IPv4. Для него IP-адрес записывается в виде 32-битной формы, представляемой в символьной форме mmm.nnn.ppp.qqq: адрес, разбитый на четыре поля, разделённых точками, по одному байту в поле, например, 192.168.102.101. Номер порта задается в диапазоне от 0 до 65535.

Пара адрес и порт образует сокет (с английского socket – «гнездо»). Сокет – является программным интерфейсом, который обеспечивает обмен данными между устройствами на низком уровне (рис. 2).

Рис. 2. Общение с помощью сокетов.

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

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

TCP сокеты

TCP сокеты используют TCP-соединения, в которых на транспортном уровне (рис. 1) обеспечивается надёжная доставка данных. TCP протокол отвечает за установление и поддержание соединения, сегментацию, доставку и буферизацию данных, упорядочивание и избавление от дублированных TCP-сегментов данных, контроль ошибок и скорости передачи. Схема работы простого TCP сокета представлена на рисунке 3.

Для удобства в качестве функций, указанных на диаграмме, используются функции, из системной библиотеки SysSocket 3.х.x.x, которая позволяет создавать сокеты на устройствах, поддерживающих платформу CODESYS V3 в том числе на контроллере CPM723-01 модульной линейки Fastwel I/O.

Cерверный TCP сокет

Рассмотрим работу серверного сокета (рис. 3). Будем считать, что существует отдельная программа, исполняемая в контроллере, которая организует обмен данными с помощью сокетов.

Рис. 3. Работа простого TCP сокета

Инициализация сокета

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

Далее сокет сервера привязывается к определенному IP-адресу и порту с помощью функции SysSockBind() . Для привязки к определенному IP-адресу функция SysSockBind() ссылается на структуру SOCKADDRESS , в которой хранятся заданный адрес сокета для привязки.

После успешной привязки к адресу функция SysSockListen() включает прослушивание входящих соединений (ожидание подключений клиентов к серверу). Функцией SysSockListen() также определяется максимальное количество подключений к серверу. Например, если максимальное количество подключений равно 3, и если 3 клиента уже подключились к серверу, то 4-тому будет отказано в подключении.

Обмен данными

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

Затем отправляет данные с помощью функции SysSockSend() :

Обработка новых подключений

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

1. Программа может закрыть клиентское соединение. В таком случае, в следующих циклах программы сервер будет ожидать подключения с новым клиентом. Такой режим работы не является эффективным, так как контроллеру придется во время каждого цикла закрывать клиентское соединение и подключать нового (или того же самого что и в предыдущем цикле) клиента.
2. Программа может не закрывать клиентский сокет, а сохранить установленное соединение. В таком случае, один раз установив соединение, клиент будет постоянно отправлять и получать данные от сервера. Такой режим работы более эффективный, но может возникнуть ситуация, когда все клиентские соединения будут заняты, и новый клиент не сможет подключиться к серверу. Решить данную ситуацию можно различными способами. Один из вариантов – следить за последним временем активности клиентских сокетов, и отключать самое старое соединение в случае, если в очереди обнаружился новый клиент (рис. 4).

Рис. 4. Обработка подключения нового клиента

Закрытие соединения

В рабочем режиме работы серверный сокет всегда остается открытым. Закрытие серверного сокета может происходить при внешнем событии, или при возникновении критических ошибок. Ошибки при создании и работе сокетов отображаются в системном идентификаторе result, который имеет тип структуры RTS_IEC_RESULT. Обозначение кодов ошибок описано в системной библиотеке CmpErrors Interfaces в глобальных константах Errors (рис. 5).
Для закрытии сокетного соединения используется фукнция SysSockClose() :

Рис. 5. Расшифровка кодов ошибок работы сокетов

Клиентский TCP сокет

Схема работы клиентского сокета отображена на рисунке 3 справа.

Инициализация клиента

Функция SysSockCreate() создает системный идентификатор сокета. Также, как и для сервера, для клиента необходимо создать потоковый сокет:

Зная IP-адрес и порт сервера, клиент с помощью SysSockConnect() подключается к серверному сокету:

Обмен данными

Обмен данными между клиентом и с помощью функций SysSockSend() и SysSockRecv() :

Закрытие соединения

После обмена данными сокет может быть закрыт с помощью с помощью SysSockClose() :

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

Особенности сокетов TCP

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

UDP сокеты

Серверный UDP сокет

На рисунке 6 показана схема работы простого UDP сокета.

Инициализация сервера

Также, как в случае TCP сокетов, системный идентификатор UDP сокета создается с помощью функции SysSockCreate() :

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

Обмен данными

Рис. 6. Схема работы простого UDP сокета.

Закрытие соединения

После отправки данных, сокет сервера снова переходит к функции SysSockRecvFrom() и остается незакрытым.

Но в случае необходимости серверный сокет можно закрыть аналогично TCP сокету:

Клиентский UDP сокет

Инициализация клиента

Обмен данными

В отличие от TCP сокетов, при использовании UDP протокола клиентский сокет не устанавливает соединения с сервером, а сразу после создания клиентского сокета переходит к обмену данными с помощью функций SysSockSendTo() и SysSockRecvFrom() :

Закрытие соединения

После обмена данными сокет может быть закрыт с помощью с помощью SysSockClose() :

Дополнительные настройки сокетов

На рисунке 3 и 6 показана работа простых серверного и клиентского сокетов. Но на деле, такая простая схема имеет некоторые ограничения и недостатки.

Блокирующий режим

По умолчанию, некоторые функции библиотеки SysSocket являются блокирующими. Это значит, что вызов функции не возвращает управление коду, до тех пор, пока он не выполнится. Блокирующими функциями являются SysSockAccept() , SysSockSend() , SysSockRecv() , SysSockSendTo() , SysSockRecvFrom() и так далее.

Например, сервер включает прослушивание входящих соединений с помощью неблокирующей функции SysSockListen() , сразу после которой идет вызов SysSockAccept() . И до тех пор, пока в очереди установленных соединений не появится хотя бы одно подключение, программа не будет исполняться дальше. Такой режим работы также называется синхронным.

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

Для того чтобы использовать функции в неблокирующем режиме, необходимо после создания сокета SysSockCreate() вызвать функцию SysSockIoctl() с входным аргументом SOCKET_FIONBIO , которая является командой перевода сокета в неблокирующий режим. При неблокирующим (асинхронном) режиме функция возвращает управление программе вне зависимости от того, закончена операция приема/передачи или нет:

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

Подключение несколько клиентов

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

Если хотя бы один сокет клиента готов, например, к отправке данных, SysSockSelect() сообщит об этом программе и соединение с данным клиентом будет установлено. Схема работы серверного сокета с использованием SysSockSelect() показана на рисунке 5.

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

Рис. 7. Схема работы сокетов с использованием функции SysSockSelect()

Программа сокетов для CPM723

В проектах TCP_UDP_Sockets.project и 2xPLCs_Sockets.project, входящих в комплект поставки программного обеспечения Fastwel I/O, реализованы программы TCP сокетов и UDP сокетов на языках ST и CFC стандарта МЭК 61131-3.

Структура проекта TCP_UDP_Sockets.project указана на рисунке 8. В данном проекте реализовано два проекта для UDP и TCP сокетов, для работы в рамках одного контроллера CPM723-01. В первом проекте CPM723_LOCAL_CFC работа сокетов реализована с помощью функциональных блоков, вызываемых в программах (язык CFC). Во втором проекте CPM723_LOCAL_ST работа сокетов реализована в программах (язык ST).

Рис. 8. Структура проекта TCP_UDP_Sockets.project

В проекте 2xPLCs_Sockets.project реализован пример для двух контроллеров CPM723-01, обменивающихся данными по протоколу TCP. На первом контроллере ClientsTCP реализованы TCP сокеты клиентов, на втором контроллере ServerTCP – TCP сокет сервера. Структура проекта указана на рисунке 9.

Рис. 8. Структура проекта TCP_UDP_Sockets.project

Заключение

Сокеты отвечают за обмен данными между различными устройствами и процессами. На базе обмена данными по сокетам можно создавать протоколы стека TCP/IP более высокого уровня.

Читайте также: