Я запустил Google Page Speed, и он говорит, что я набрал 57/100 , потому что мне нужно «Включить Keep-Alive» и «Enable Compression». Я выполнил некоторые поисковые запросы Google, но ничего не могу найти. Я даже связался с моим провайдером домена и попросил их включить его, но они сказали, что он уже включен.
1.) Что такое Keep-Alive?
2.) Как включить его?
Keep-alive использует одно и то же соединение tcp для сеанса HTTP вместо открытия нового с каждым новым запросом. Вам в основном нужно настроить HTTP-заголовок в ответе HTTP
Конфигурировать настройки Apache KeepAlive
Откройте файл конфигурации apaches и найдите следующие настройки. В Centos этот файл называется httpd.conf и находится в /etc/httpd/conf . Следует отметить следующие настройки:
KeepAlive: Включает и выключает KeepAlive. Вставьте «KeepAlive on», чтобы включить его, и «KeepAlive off», чтобы отключить его.
MaxKeepAliveRequests: Максимальное количество запросов на одно постоянное соединение будет обслуживаться. Число от 50 до 75 быть много.
KeepAliveTimeout: . Как долго сервер ожидает новых запросов от подключенных клиентов. Значение по умолчанию — 15 секунд. слишком высокий. Установите значение от 1 до 5 секунд, чтобы избежать процессы, теряющие ОЗУ во время ожидания запросов.
У меня была та же проблема, и после небольшого исследования я обнаружил, что два самых популярных способа сделать это:
- Если у вас нет доступа к конфигурационному файлу вашего веб-сервера, вы можете сами добавлять заголовки HTTP, используя файл .htaccess, добавив эту строку кода:
Набор заголовков Connection keep-alive
- Если вы можете получить доступ к своему конфигурационному файлу Apache, вы можете включить keep-alive там, изменив эти 3 строки в файле httpd.conf, найденном здесь /etc/httpd/conf/
Вы можете прочитать больше из этого источника, который объясняет это лучше меня
Чтобы включить keep-alive через .htaccess, вам нужно добавить следующий код в ваш файл .htaccess:
Чтобы включить конфигурацию KeepAlive, перейдите в конфиг /httpd.conf в конфигурации Apache и установите свойство ниже: KeepAlive On
Когда вы включили «keep-alive», вы сообщаете браузеру вашего пользователя использовать одно TCP/IP-соединение для всех файлов (изображений, скриптов и т.д.), загружая ваш сайт вместо использования соединения TCP/IP для каждого файла . Таким образом, он сохраняет единственное соединение «живой», чтобы сразу извлекать все файлы веб-сайта. Это намного быстрее, чем использование множества соединений. Существуют различные способы обеспечения сохранения жизни. Вы можете включить его с помощью
- Использование/Редактирование файла .htaccess
- Включение этого доступа через веб-сервер (Apache, сервер Windows и т.д.)
Перейдите сюда для получения более подробной информации об этом.
С частью «Включить компрессию» они означают, что вы должны включить сжатие GZIP (если ваш веб-хост еще не включил его, поскольку он в значительной степени по умолчанию в настоящее время). Метод сжатия GZIP позволяет сжать ваши веб файлы до их отправки в браузер пользователей. Это означает, что ваш пользователь должен загружать гораздо более мелкие файлы, чтобы полностью загрузить ваши веб-страницы.
From what I understand, a HTTP connection could either be keep-alive or close .
I sent a HTTP request to a server:
And it responded with:
Essentially, I believe the server is bugged because a response like keep-alive, close is ambiguous.
However, as the receiver, how should we handle such a message? Should we interpret this header value as keep-alive or close ?
4 Answers 4
TL; DR: Chrome interprets this response header as keep-alive and maintain a peristent connection while Firefox closes each connection.
I stumbled over this question as I tried to optimize the page loading time for my website.
In the referenced RFC I didn’t find anything about how multiple entries in the Connection header may be properly handled. It seemed to me like the implementation may choose from two possibilites:
- If there are multiple entries, you may choose that fits best to your needs
- If there is a close inside, you may close the connection after transmission
So, I needed to find out. Let’s make some deeper investigation:
I noticed that Chrome was always sending a HTTP/1.1 request with Connection: keep-alive and my Apache default configuration was always responding with a Connection: close header. So I began investigating and took a look at the TCP segments with Wireshark.
Chrome has to fetch 14 elements to display the website, mostly of them static things like images or css files. And it took in complete 14 TCP connections and that took a lot of time (approximately 1,2 seconds). After each request for an image (e.g.) there came a TCP segment with the FIN flag set to 1.
So what about Chrome vs. Firefox? Chrome seems to have a maximum number of concurrent connections to one server of 6. Firefox has a more granular configuration and distinguishs persistent (maxium of 6, seen in about:config) and non-persistent (the maximum numbers differed a lot in different sources). But wait. Both, Chrome and Firefox are sending HTTP/1.1 request headers with Connection: keep-alive , so both should be limited to 6 (as this is a request for opening up a persistent connection).
I decided to try a simple trick and added the following lines to my .htaccess in the web root folder:
The server now responds with:
Now I took a look at the TCP segments again: There were only 9 connections from Chrome to my server now and only 3 with the FIN flag set to 1. So this trick seemed to work. But why were there those 3 connections, that closed the connection after data transmission? These were the PHP requests, as the HTTP header X-Powered-By: PHP/5.4.11 confirmed.
And what about Firefox? There were still those 14 requests!
How to fix that and get the fcgi processes to work with keep-alive too?
I added the following lines to my virtualhost section of the httpd.conf configuration:
and removed the ones added in the .htaccess . Now the server isn’t sending any confusing — Connection: keep-alive, close , but only Connection: keep-alive and everything works fine!
Conclusion:
A header with the connection field set to
will be interpreted by Chrome as keep-alive while Firefox seems to close each connection. It seems to depend on the actual implementation.
So if you’re willing to implement a client for handling response headers that contain Connection: keep-alive, close , I would propose to try using keep-alive if you need more than one request. The worst thing that may happen: The server will close the connection and you need to connect again (that’s exactly the other option you would have had!)
Большинство современных серверов поддерживает соединения keep-alive . Если на страницах много медиаконтента, то такое соединение поможет существенно ускорить их загрузку. Но мы попробуем использовать keep-alive для куда менее очевидных задач.
Прежде чем переходить к нестандартным способам применения, расскажу, как работает keep-alive . Процесс на самом деле прост донельзя — вместо одного запроса в соединении посылается несколько, а от сервера приходит несколько ответов. Плюсы очевидны: тратится меньше времени на установку соединения, меньше нагрузка на CPU и память. Количество запросов в одном соединении, как правило, ограничено настройками сервера (в большинстве случаев их не менее нескольких десятков). Схема установки соединения универсальна:
- В случае с протоколом HTTP/1.0 первый запрос должен содержать заголовок Connection: keep-alive.
Если используется HTTP/1.1 , то такого заголовка может не быть вовсе, но некоторые серверы будут автоматически закрывать соединения, не объявленные постоянными. Также, к примеру, может помешать заголовок Expect: 100-continue. Так что рекомендуется принудительно добавлять keep-alive к каждому запросу — это поможет избежать ошибок.
Expect принудительно закрывает соединение
Хакер #196. Все о Docker
Иногда даже после корректного завершения запроса схема keep-alive не отрабатывает из-за неопределенных магических особенностей сервера и сценария, к которому обращен запрос. В таком случае может помочь принудительная инициализация соединения путем передачи в первом запросе HEAD.
Запрос HEAD запускает последовательность keep-alive
Как бы забавно это ни звучало, но первый и самый очевидный профит — это возможность ускориться при некоторых видах сканирования веб-приложений. Разберем простой пример: нам нужно проверить определенный XSS-вектор в приложении, состоящем из десяти сценариев. Каждый сценарий принимает по три параметра.
Я накодил небольшой скрипт на Python, который пробежится по всем страницам и проверит все параметры по одному, а после выведет уязвимые сценарии или параметры (сделаем четыре уязвимые точки) и время, затраченное на сканирование.