Ошибка: [Errno 10053]

Ответ 1

Из Список кодов Windows Sockets:

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

Произошел тайм-аут или другая ошибка сетевого уровня. Это ваша операционная система, закрывающая сокет, на самом деле ничего общего с Python или Flask.

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

Ответ 2

Здравствуйте, Это проблема с реализацией Python 2 модуля SocketServer, он отсутствует в Python 3 (где сервер продолжает обслуживать).

У вас есть 3 варианта:

Не используйте встроенный сервер для производственных систем (в конце концов, это сервер разработки). Используйте надлежащий сервер WSGI, например, gunicorn или uWSGI.

Включить поточный режим с помощью app.run(threaded = True); поток умирает, но новый создается для будущих запросов,

Переход на Python 3.

Поэтому всякий раз, когда есть ошибка, например

error: [Errno 10053] An established connection was aborted by the software in your host machine

Сервер будет перезапущен, если вы сделали это как app.run(threaded = True).

Ответ 3

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

Ответ 4

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

time.sleep(10)
data = s.recv(1024)
s.close()

Это работает для меня.

Ответ 5

Я только что испытал точно такую ​​же проблему. В отличие от наиболее употребимого ответа, проблема имеет много общего с Python и Flask, и это не проблема Windows. Очень легко воспроизвести:

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

Кроме того, это никогда не случалось с микрофреймом для бутылок, например.

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

Ответ 6

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

Ответ 7

Эта ошибка может возникать независимо от Flask, Python 2, Python 3 или HTTP - это может происходить просто на уровне сокета, и это будет сильно зависеть от вашей точной ситуации.

Например, мое приложение использует Ethernet-устройство/устройство, которое использует сырые сокеты для управления и управления, и я использую метод create_connection в модуле socket. Я последовательно получаю "Errno 10053" после попытки отправить сообщение после периода бездействия трафика. Сроки проверки показали, что эта ошибка возникла после попытки отправить сообщение после четырех минут бездействия. На следующей странице указано время ожидания 240 секунд = 4 мин:

https://support.microsoft.com/en-us/help/170359/how-to-modify-the-tcp-ip-maximum-retransmission-time-out

Решение в моем сценарии состояло в том, чтобы обеспечить, чтобы сообщения на устройстве не занимали более четырех минут. Я просто отправляю небольшое сообщение на устройство каждые 60 секунд, чтобы избежать ошибки 10053 - это действует как "постоянный" на уровне протокола (не связанный с TCP keepalive). В этом случае, возможно, проблема связана с устройством Ethernet и тем, как они реализовали TCP. Тем не менее, уровень поддержки на уровне протокола может быть жизнеспособным вариантом во многих случаях.