После года разработки представлена (http://marc.info/?l=squid-announce&m=142148228920406&w=2) новая стабильная ветка прокси-сервера Squid 3.5 (http://wiki.squid-cache.org/Squid-3.5), которая по заявлению разработчиков достигла состояния готовности для промышленного использования. После придания ветке 3.5.x статуса стабильной, в ней отныне будут производиться только исправления уязвимостей и проблем со стабильностью, также допускается внесение небольших оптимизаций. Поддержка прошлой стабильной ветки 3.4.x прекращена, пользователям рекомендуется спланировать переход на ветку 3.5.x.
Основные новшества (http://www.squid-cache.org/Versions/v3/3.5/RELEASENOTES.html) Squid 3.5:
- Реализован (http://wiki.squid-cache.org/Features/FtpRelay) полноценный релей для протокола FTP, позволяющий манипулировать FTP-трафиком, проверять на вирусы при помощи ICAP/eCAP и применять ACL для каналов связи между FTP-клиентом и FTP-сервером. Кэширование передаваемых через FTP данных пока не реализовано, но будет доступно в будущих выпусках. Команды/ответы FTP транслируются в формат HTTP-запросов/ответов, поэтому к ним применимы те же операции, что и для HTTP.
- Поддержка именованных сервисов (http://wiki.squid-cache.org/MultipleInstances), позволяющих упростить запуск в одной системе нескольких экземпляров Squid, которые не пересекаются между собой. При запуске можно связать сервер с определённым именем, которое задаётся через опцию "-n" (по умолчанию привязывается имя "squid"), и в дальнейшем использовать данное имя для остановки или перезапуска избранного сервера. Для унификации конфигурации в файле squid.conf можно использовать макрос ${service_name}.
- Возможность отправки в хелпер аутентификации дополнительных деталей, помимо минимально необходимых для HTTP-аутенитфикации данных. Например, можно передавать такие параметры, как подсеть клиента, номер порта, запрошенный домен или любые другие данные, которые могут фигурировать в logformat. На основании дополнительных данных в хелпере может быть осуществлёно переключение между базами аутентификации. Для управления передачей дополнительных данных в директиву
auth_param (http://www.squid-cache.org/Doc/config/auth_param/) добавлен новый параметр key_extras.
- Поддержка параллелизма каналов для хелперов, позволяющая ускорить связь между squid и хелперами за счёт параллельного выполнения транзакций вместо последовательной обработки запросов (следующий запрос теперь может быть отправлен до того как выдан ответ по предыдущему запросу, в то время как раньше новый запрос отправлялся только после ответа на предыдущий). Параллельные каналы доступны для хелперов Digest authentication, Store-ID и URL-rewrite. Разделение каналов производится на основании содержимого поля channel-ID.
- Возвращена поддержка опции collapsed_forwarding (http://wiki.squid-cache.org/Features/CollapsedForwarding), которая была доступна в ветке Squid-2, но не попала в релиз Squid 3.0. Опция позволяет включить оптимизацию проброса трафика при наличии большого числа параллельных запросов к одному URL. Оптимизация производится за счёт объединения несколько запросов к кэшу, в которых фигурирует один URL, до того как Squid узнает о том, должен ли быть прокэширован ответ.
- Поддержка eCAP 1.0 (http://wiki.squid-cache.org/Features/eCAP). Использование новой библиотеки libecap (http://www.e-cap.org/) позволяет улучшить процесс согласования версий библиотеки eCAP и загруженного адаптера eCAP, используемого для взаимодействия с антивирусным пакетом.- Переработана организация перехвата шифрованных HTTPS-сеансов (ssl_bump), вместо режимов перехвата ("modes") введены в обиход действия ("actions"), которые в том числе можно использоваться в ACL. Режим "server-first", при котором вначале осуществляется соединение с целевым сервером, а потом создаётся защищённое соединение между клиентом и прокси, теперь доступен как действие "bump". Режим "none", при котором создаётся TCP-туннель без дешифровки трафика, теперь доступен как действие "splice". Для обеспечения обратной совместимости добавлено действие "peek-and-splice", при котором решение о типе создаваемого вначале соединения (клиент-прокси или прокси-сервер) принимается на основе SSL hello-сообщений. Добавлены действия "peek" и "stare" для получения клиентского или серверного сертификата с сохранением возможности дальнейшего применения режимов "splice" и "bump" для соединений. Добавлено действие "terminate" для закрытия соединений к клиенту или серверу.
- В хранилище Rock и в разделяемой памяти обеспечена возможность кэширования больших объектов (более 32Кб).
- Поддержка расширенного управления принятием решения о выдаче данных из кэша (HIT/MISS). Добавлены новые директивы: "send_hit" для включения отправки прокэшированного контента на основе выбора ACL, в котором могут учитываться параметры запроса или детали ответа; "store_miss" для включения кэшировния MISS-ответов на основе ACL.
- Обновлена утилита squidclient (http://www.squid-cache.org/Versions/v3/3.5/manuals/squidclie...), в которую помимо протокола HTTP добавлена поддержка отправки запросов по HTTPS ("--https"), добавлена команда "--ping" для периодического повтора отправки сообщений, реализованы уровни отладочного вывода.
- Начальная поддержка протокола PROXY (http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt), позволяющего передавать информацию о соединении (например, оригинальный IP-адрес клиента) по всей цепочке проксирования или туннелирования соединения без необходимости модификации и разбора протокола внутри соединения. В настоящее время протокол PROXY может использоваться в Squid для получения HTTP-трафика от прокси на стороне клиента.- Удалена поддержка хранилища COSS, вместо которого следует использовать хранилище Rock. Удалены хелпер dnsserver и DNS helper API, на смену которым пришёл встроенный клиент DNS.
URL: http://marc.info/?l=squid-announce&m=142148228920406&w=2
Новость: http://www.opennet.me/opennews/art.shtml?num=41481
ftp -- протокол будущего!
После полного импортозамещения.
Особенно в плане информирования о кодировке имён на сервере ;) Да, мир почти перешёл на UTF-8, но M$-дятлы клиенты остались со своей CP1251 locale.
Вам смешно, а я столько лет, пока это не потеряло всякую актуальность ждал, пока кто-нибудь наконец запилит полноценный FTP proxy (а также SMPT и POP3). И вот, на старости лет дождался... Осталось дождаться реализации протокола ZModem...
> Вам смешно, а я столько лет, пока это не потеряло всякую актуальность
> ждал, пока кто-нибудь наконец запилит полноценный FTP proxy (а также SMPT
> и POP3). И вот, на старости лет дождался... Осталось дождаться реализации
> протокола ZModem...С одной стороны смешно, с другой стороны грустно.
Уже давно Вам необходимо было разработать спецификации кеширования для протокола FTP.
Ведь их по моему скромному мнению не было, от того и не реализовывали.
А может лучше rsync?
а как же frox?
и delegate ещё
А как же nginx? Он всё не умеет только ZModem ;-)
> А как же nginx? Он не умеет только ZModem ;-)fixed
>> А как же nginx? Он не умеет ZModem, ftp://, ldap://, smb://, [запарился - остатки /ets/services сами, угу?]
> fixedoverfixed
Джва года? Или может быть даже джвадцать лет?
Имхо, лучше использовать в составе полноценных решений, таких как Pfsense.
> вначале осуществляется соединение с целевым сервером, а потом создаётся защищённое соединение между клиентом и проксикажется, это называется "man in the middle"?
Да, но в корпоративных сетях, где за утечкой инфы следят, приемлемо.
Хорошая штука!
Жаль только, что чем дальше тем больше трафик уходит в "сторону" шифрования (это плохо для прокси серверов и кеширования соответственно). Ну дык людишки сами виноваты, суют свой нос везде и повсюду :( скоро уже и геморрой от их носов никак не спрячешь ;)
Увы, но проблема не так в шифровании траффика, как в динамической его генерации. Кешировать стало почти нечего. В конце 1990-х - начале 2000-х я поднимал сквид с кешем в 64 ГБ, и уровень кеширования достигал 40% от общего трафика. В конце 2000-х этот показатель едва достигал 10%. Сейчас он около 3% - нет ни малейшего смысла заморачиваться с кешированием.В настоящее время прокси полезны только для фильтрации и статистики. Учитывая стоимость каналов, экономия траффика не стоит свеч.
> Увы, но проблема не так в шифровании траффика, как в динамической его
> генерации. Кешировать стало почти нечего. В конце 1990-х - начале 2000-х
> я поднимал сквид с кешем в 64 ГБ, и уровень кеширования
> достигал 40% от общего трафика. В конце 2000-х этот показатель едва
> достигал 10%. Сейчас он около 3% - нет ни малейшего смысла
> заморачиваться с кешированием.
> В настоящее время прокси полезны только для фильтрации и статистики. Учитывая стоимость
> каналов, экономия траффика не стоит свеч.Согласен. И еще всякие фичи в работе с URL-ми.
Зато теперь каждый обязан иметь собственный локальный DNS сервер )
> Зато теперь каждый обязан иметь собственный локальный DNS сервер )Не улавливаю связи.
Вопрос не в тему: в новых сквидах есть какой-то нативный способ управления квотами, вместо sams например?
Нет.