При работе по HTTP 1.1 все соединения считаются постоянными, если не обозначено иное.[1] При этом постоянные соединения не используют сообщения keepalive, а просто позволяют передачу множественных запросов в одном и том же соединении. Тем не менее, время ожидания по умолчанию в httpd для Apache 2.0[2] составляет всего 15 секунд, а для Apache 2.2 лишь 5 секунд.[3] Преимуществом короткого таймаута является возможность быстрее передать клиенту множественным соединением несколько компонентов веб-страницы, а не более долгим методом инициации нескольких серверных процессов или потоков.[4
https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D1%81%D1%82%D0%BE%D1%8F%D0%BD%D0%BD%D0%BE%D0%B5_HTTP-%D1%81%D0%BE%D0%B5%D0%B4%D0%B8%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5
У нас не Apache, ни чего не обозначено, просто открываютсязакрываются сокеты.
Скриншот на котором у вас 3 синих кубика (одинаковые CurClientID) - проверьте в Chrome еще раз, и вы увидите что эти запросы не в 1 соединении идут а в разных.
НО компонент все равно считает что CurClientID у них одинаковый.
HTTP это спецификация протокола, а не реализация его работы...его работа реализуется браузером который, при открытии страницы смотрит DOM и кол-во запрашиваемых файлов, если файлов нужно скачать 20, то он будет их качать по несколько штук в разных соединениях!. по 5-6 файлов, затем еще 5-6 файлов, партиями, но в разных соединениях.
Я не сомневаюсь в ваших знаниях TCP и HTTP, я просто пытаюсь понять...как в разных соединениях могут получаться 2-3 одинаковых CurClientID.
Мне кажется компонент считает подключения браузера не верно..или я совсем не знаю как работает HTTP тогда.
п.с. Откуда берется CurClientID как высчитывается? Открывал ваши pas...там везде "Conn" указан, откуда он берется не понял..
п.п.с. браузер скачал script1.js или script2.js, результат выполнения скрипта - отправка строки request_1 или requets_2.
Обратите внимание что CurClientID при загрузке скрипта и отправки данных из него - разные.
Мне удалось воспроизвести ситуацию когда сервер производит 1 раз событие onConnect (допустим CurClientID будет 123), а затем несколько последовательных onReceive (все CurClientID 123) - это когда я шлю из браузера серверу POST запрос на 50 000 символов, браузер режет его и пропихивает в 1 соединении, это и получается "постоянное соединение" которое организует браузер. В этой ситуации все правильно, 1 клиент, большой объем данных от него, все данные приходят по очереди и у всех onReceive одинаковый CurClientID.
Во всех остальных случаях количество onConnect=количеству onReceive и некоторые CurClientID одинаковые, это ошибка, так не должно быть...если блин onConnect происходит значит что сервер считает это подключение как новое!!! Отчего же он ему тогда дает CurClientID который уже был выдан??
Поиск
Друзья
Администрация