Web сервер. Не хватает сокетов.

[pvvx]

Сколько тут ахинеи настрочил наш "гура всея ESP". Но так и не ответил на заданный выше вопрос: "почему по вашей версии TIME_WAIT должен приводить к "загрузке страницы с десятком файлов за час""?
Ответ на конкретный вопрос будет? Или и дальше будет такой же невразумительный поток бессознания?

Где петух member прочитал что "TIME_WAIT должен приводить к "загрузке страницы с десятком файлов за час"" ?
При ошибке возможно вообще ни одной странице в час
Написано было однозначно - чтобы уменьшить вероятность появлений ошибок с вырезанным в ESP "TIME_WAIT" необходимо вставить задержки и максимально ограничить трафик на ESP.

 

[enjoynering]

может потому что вы их не закрываете?

 

[pvvx]

может потому что вы их не закрываете?

->

Когда использую интерфейс на 5 сокетов более менее работает, и то не всегда, иногда один файл грузится с ошибкой.
При 3 разрешенных сокетах, вообще все плохо.

Эксплорер на много-файловый HTML может создать десятки соединений.
Если у ESP уже открыты все сокеты, то какой будет ответ эксплореру на следующий запрос открытия сокета?

 

[pvvx]

Если WEB сервер на LwIP будет закрывать TCP сокеты по своей инициативе (первым подавать команду закрытия), то это грозит исчерпанием всех портов для дальнейших соединений из-за перехода закрытых TCP в состояние TIME_WAIT на 200 секунд.
Вырезание TIME_WAIT не поможет - тогда с большой вероятностью рухнет вся сеть Инет.
Из-за таких проблем с TCP постоянно пытаются создать новые HTTP стандарты и работать с UDP...

 

[pvvx]

Пояснение о TCP в состоянии “TIME_WAIT” на кухонном языке, на “банках”:

Кто первым инициировал закрытие TCP соединения, то он должен ждать 200 секунд. И в этот период дублировать закрытие на все приходящие ответы-запросы уже “закрытого соединения” (застрявшие пакеты в сети и если клиент не принял фрейм закрытия – потерялся, …). Иначе возникает множество уязвимостей в HTTP и ошибок, неопределенностей и т.д. у роутеров и прочего сетевого хлама.

Количество портов у сервера на одном IP ограничено, тем более LwIP урезан в сравнении индексов соединений TCP по IP и портам обоих сторон. Для больших серверов мало и полное сравнение всех данных IP портов TCP, т.к. они могут совершать мульон операций открытий-закрытий TCP в сек. Из-за этого простые и кривописанные сервера Web/HTTP в Linux дико боятся DDOS, хотя есть масса решений данного вопроса... А наиболее простейшее для частников - руководствоваться рекомендациям RFC.

Т.е. сервер не любит закрывать соединение первым, а перекладывает это на клиента – пусть у него будет “TIME_WAIT”.

Но большинство прокси перерабатывают HTTP/TCP запросы не соблюдая рекомендации RFC, чтобы не влипнуть в свою нехватку портов, вешая это на HTTP сервер

А у любителей ESP - свои тараканы - у них Arduino головного мозга...

 

[pvvx]

От туда и для дополнительного ускорения в HTTP было сляпано решение “keep-alive”. Но это не решает на 100% “TIME_WAIT”, т.к. серверу HTTP в некоторых случаях всё равно приходиться первым инициировать закрытие TCP соединения…

 

[pvvx]

И чтобы написать сервер HTTP на ESP в соответствии со стандартами только TCP/IP вам необходимо рассчитать, сколько максимально за период в 200 секунд возможно принять-передать транзакций IP пакетов в соответствии с пропускной полосой соединения. И подготовить объем памяти на это кол-во структур TCP для LwIP, а так же учесть производительность обработки таймеров в этом количестве структур. Т.е. PSRAM там не пойдет – имеет слишком медленный доступ для обработки таймеров
По прикидкам для WiFi 2.4ГГц и "бытового" HTTP надо где-то от 2MB быстрой RAM...

 

[pvvx]

По этим причинам в промышленных устройствах (и любых сертифицированных или желаемых оной) нет контроллеров с TCP/IP имеющих менее 2-х MB RAM и WiFi 1TR 2.4ГГц. И то это только для одного "сокета" типа Modbus