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

Тестировать - IE это не поддерживает, в Опере некий "интеллектуальный алгоритм" который сам определяет когда использовать pipelining, в FF это по дефолту отключено и включается опциями network.http.pipelining и network.http.proxy.pipelining

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

Сергей
Наибольшую выгоду от Pipelining получат те, у кого время отклика составляет существенную часть от общего времени коннекта. В первую очередь, это обладатели спутникового интернета, потом DSL, потом Dial-Up.

PS Может, здесь и продолжим обсуждение тестирования поддержки Pipelining?
У меня сразу возник вопрос. В логе строки имеют теперь вид:
05.04.2007 11:37:11 # 493/519 >>> URL: http://handycache.ru/forum/Themes/SlickPro_Graphite/images/icons/folder_open.gif
Что означает 519 в # 493/519? Предполагаю, что это относится к Pipelining.

Переформулирую: что означает написание через дробь 493/519? Значит ли это, что данная строка лога относится к строке монитора 519 и этот файл получен по Pipeline в рамках одного соединения после файла, обозначенного в 493 строке монитора?

На мой взгляд, pipelining не будет полноценно использоваться, пока НС не начнет возвращать "HTTP 1.1" в собственных ответах (в тех, где сервером значится HandyCache). Мы должны возвращать клиенту максимально поддерживаемую нами подверсию HTTP (т.е. HTTP 1.1).
Сейчас происходит так. Опера запоминает, что запрошенный хост (а на самом деле НС) отвечает HTTP 1.0, и запоминает его как неподдерживающий HTTP 1.1 и соответственно pipelining. В итоге в процессе следующих обращений к этому хосту pipelining Опера не инициирует.

Еще мне кажется, ничего положительного в поддержку pipeline не привносят формируемые НС заголовки Proxy-Connection.
Насколько я знаю, это изобретение Netscape не регламентировано никакими стандартами и применяется (применялось) только в нетскейповских браузерах. Стандартом HTTP определен заголовок Connection, который обязан понимать любой клиент. С учетом этого предлагаю не использовать Proxy-Connection.
Как работать с заголовком Connection, постараюсь изложить позже.

Если запрос HTTP 1.0, то, собственно, во всех без исключения (по крайней мере, у меня): 304, 403, 404, 430, 200 (НС).
А где он описан? Когда и как его надо использовать? Почему/для каких целей его использует НС?
Я этого за IE не замечал.

НС должен, на мой взгляд, и на запрос HTTP 1.0, и на 1.1 давать ответ HTTP 1.1. Этим НС сообщит браузеру, что он поддерживает 1.1. Имхо, исходя из этого ответа браузер (по крайней мере, Опера) будет в дальнейшем строить взаимоотношения с НС при обращении к тому же хосту.
Такой ответ, собственно, как мне помнится, определен стандартом и/или рекомендациями к нему. Если нужно, могу отыскать.

Михаил
Нужно.
Rick
Тогда так и называть надо эту опцию - Persistent connection.

Михаил
Хорошо, сделаю 1.1

mai62
Тестирую сборку 21 с HTTP 1.1. Опера перестала закрывать соединение после каждого скачанного файла. Работа ускорилась. В общем, постоянные соединения наконец заработали!!! 
Тем не менее, pipelining не наблюдается - НС шлет запрос по открытому соединению только после получения ответа на предыдущий запрос по этому соединению. Надо разбираться.
Как НС определяет, когда открывать новое соединение, а когда слать запрос по существующему?

При ответе "502 Bad gateway/Not connected (HC)" отдается ответ HTTP 1.0. Имхо, тоже заменить на HTTP 1.1.

Да, инфы кот наплакал. Заголовок практически нигде не описан, но вот парадокс: все его знают.

Если занудствовать, то RFC не стандарт, а рекомендация.

Который так же понимается всеми браузерами и серверами.

Осталось еще больше серверов 1.1, которые без этого "жить не могут".

Фигня в том, что нет ясности. Ее действительно нет, нигде нет какого-либо дока который можно было бы считать нормативным и делать как в нем написано. Есть только практика: приходится подстаиваться под то, что понимают *nix и win серверы. А практически все они и понимают Proxy-Connection в запросе и сами отдают Proxy-Connection в ответе. Но ясности как _должно_быть_ правильно нет.

Поиск по слову "Naviscope" дает ссылку на ту тему! Плохо искал...

Вряд ли там дело в заголовке "Proxy-Connection", т.к. ответ "200 From cache" Naviscope обрабатывал нормально:


Скорее проблема была в отсутствии "Content-Length: 0" в ответе "304". Сейчас это поправлено в бете...

Судя по всеобщему молчанию pipelining никто не пользует. Или он не включен. В FF необходимо в адресной строке браузера ввести about:config и включить опции network.http.proxy.pipelining и network.http.pipelining (по умолчанию они отключены).

У меня в Fx3 включен. Но пока не вполне понятно, как выяснить реальное использование режима ("Live HTTP Headers" и "Fiddler" об этом не сообщают). Штука в том, что pipelining (в том числе и over proxy) у меня был включен всегда, при этом никакой путаницы картинок не наблюдалось...

Связь крайне сумнительна. Скорее всего просто FG полностью забивает твой канал (кол-во потоков здесь ни при чём) и браузер спотыкается на таймаутах. Если тебе это критично - в FG можно вручную настроить ограничение

Только по косвенным признакам: перепутанным картинкам, по зависшим соединениям в текущих, по сериям 502 в мониторе: т.е. несколько файлов подряд имеют 502, при этом у некоторых "Отправлено" пусто.
Верный способ - это анализ логов: в рамках одного соединения отправляется несколько запросов. Т.е. запрос1-запрос2-ответ1-ответ2. Не путать с парами запрос1-ответ1-запрос2-ответ2 в рамках одного соединения - это не pipelining, это persistent.
Кстати, опция FF network.http.max-persistent-connections-per-proxy должна иметь значение >0 (по дефолту 4).
Но анализ логов - дело долгое и после каждой страницы их смотреть же не станешь. Поэтому нужно включить pipelining и persistent в FF и отслеживать "ненормальности" и ошибки. А уж затем лезть в логи.

Может быть какой-то из серверов через который у тебя доступ в инет не поддерживает pipelining. Включи ведение лога, открой главную страницу handycache.ru (желательно с рекламой) и проверь по логам наличие цепочек из нескольких запросов-ответов.

Привет, Rick! Я тут в исследовательских целях подгрузил страничку с заведомо большим количеством картинок - и сразу как-то странно стало всё... Запросы внутри соединения уходят кучей - ответы возвращаются не в том же порядке, и при этом ничего не путается! Как такое может быть? Чего-то я недопонимаю... Посмотри этот лог, пожалуйста (может просто криво смотрю - мне такое кол-во текста пока тяжеловато )
P.S. Хотел тебе в ПМ написать, но не нашёл там возможности вложения
P.P.S. Что-то у меня форум перекосячило - не могу вложение прикрепить - отправлю тебе на мыло

Пока не надо - на подходе новый билд. Вот на новой сборке и желательно будет отловить оставшиеся ошибки.

Должно вроде работать с такими настройками. Там от дефолтных настроек надо только разрешить pipelining и он начинает работать.
Я бы так много не ставил. Будут длинные цепочки и ты их замучаешься отслеживать, вполне достаточно дефолтных 4.

Внешний прокси имеется?

Я наблюдаю постоянно.
network.http.pipelining=true
network.http.pipelining.maxrequests=4
network.http.proxy.pipelining=true
network.http.max-persistent-connections-per-proxy=4
network.http.max-persistent-connections-per-server=2

Погоду может портить внешний прозрачный прокси у провайдера.

Сорри, но я понятия не имею в каком файле FF хранит настройки. Ткни плз пальцем.

Дык вот и я его терпеть не могу - пользуюсь только для тестов по необходимости.

NothingAnother, cпасибо.

Действительно и шлет и получает пачками.

Да, и это уже обсуждалось в данной теме выше! Такова уж сущность Pipelining'а - если один запрос тормозит, то ждет вся цепочка! Это не баг, а особенность конвейера!


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


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

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


Что-то не припоминаю в IE такой тонкой настройки...

Выходит, это принципиальный недостаток работы через прокси? Хотя с другой стороны, это недоработка браузера: следовало бы ему для каждого сайта устанавливать новое соединение с прокси-сервером, чтобы избежать подобных тормозов и увеличить производительность. Даже глупо как-то получается... Выходит, преимущество pipelining при открытии страницы, содержащей ссылки на разные сервера, превращается в недостаток из-за тупости браузера?