Отличить клиентов за NAT'ом

Второй раз советую FingerprintJs или аналоги.

Так задача то плевая, если разобраться. Там в пакете всего одно поле, которое различает клиентов друг от друга (правда уже не помню какое). Юзать целый комбайн ради вместо элеметарновго var1 == var2

Похоже, что такая элементарщина в рамках хттп - проблема, на стековерфлоу тоже руками разводят. Ладно, пох, буду клиентов тормозить специально на некоторых этапах + выделять ресуры на короткое время. В связи с этим вопрос - клиент прислал мне запрос, я должен ему ответить, если просто буду мариновать его ничего не отвечая, то он просто отвалится. Что я могу слать клиенту в этот период намеренного маринования? Какой-то заголовок ни о чём, мол не волнуйся, подожди, скоро все будет (секунд 7, например, надо его помариновать).

Ничего ему слать не надо, почитай как HTTP long poll работает.

А что HTTP уже не поверх TCP работает? Что мешает дальше разделять TCP сессии?

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

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

Поставить тцп-прокси перед веб-сервером которое будет смотреть что там в пакетах…

Я смутно знаком с tcp/ip, но разве у двух разных клиентов за натом в общем случае в пакете будет какая-либо разница кроме чем номер исходящего порта? И http не обязывает держать открытым это соединение, можно оборвать и подключаться заново.

Я смутно знаком с tcp/ip, но разве у двух разных клиентов за натом в общем случае в пакете будет какая-либо разница кроме чем номер исходящего порта?

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

разве у двух разных клиентов за натом в общем случае в пакете будет какая-либо разница

Нет.

Куки для этого есть.

плюсую. но только если клиент принимает куки.

Remote port же.

Это как повезёт.

• идентификация по ip адресу ошибочна
• для чего нужно?

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

нафиг тебе адрес, генерь GUID для новых клиентов и клади в куку.

лучше конечно GUID еще и ЭЦП подписать.

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

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

Можно установить фейковое соединение WebRTC и сравнить icecandindates.