The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Стабильный релиз прокси-сервера Squid 3.5

17.01.2015 22:39

После года разработки представлена новая стабильная ветка прокси-сервера Squid 3.5, которая по заявлению разработчиков достигла состояния готовности для промышленного использования. После придания ветке 3.5.x статуса стабильной, в ней отныне будут производиться только исправления уязвимостей и проблем со стабильностью, также допускается внесение небольших оптимизаций. Поддержка прошлой стабильной ветки 3.4.x прекращена, пользователям рекомендуется спланировать переход на ветку 3.5.x.

Основные новшества Squid 3.5:

  • Реализован полноценный релей для протокола FTP, позволяющий манипулировать FTP-трафиком, проверять на вирусы при помощи ICAP/eCAP и применять ACL для каналов связи между FTP-клиентом и FTP-сервером. Кэширование передаваемых через FTP данных пока не реализовано, но будет доступно в будущих выпусках. Команды/ответы FTP транслируются в формат HTTP-запросов/ответов, поэтому к ним применимы те же операции, что и для HTTP.
  • Поддержка именованных сервисов, позволяющих упростить запуск в одной системе нескольких экземпляров Squid, которые не пересекаются между собой. При запуске можно связать сервер с определённым именем, которое задаётся через опцию "-n" (по умолчанию привязывается имя "squid"), и в дальнейшем использовать данное имя для остановки или перезапуска избранного сервера. Для унификации конфигурации в файле squid.conf можно использовать макрос ${service_name}.
  • Возможность отправки в хелпер аутентификации дополнительных деталей, помимо минимально необходимых для HTTP-аутенитфикации данных. Например, можно передавать такие параметры, как подсеть клиента, номер порта, запрошенный домен или любые другие данные, которые могут фигурировать в logformat. На основании дополнительных данных в хелпере может быть осуществлёно переключение между базами аутентификации. Для управления передачей дополнительных данных в директиву auth_param добавлен новый параметр key_extras.
  • Поддержка параллелизма каналов для хелперов, позволяющая ускорить связь между squid и хелперами за счёт параллельного выполнения транзакций вместо последовательной обработки запросов (следующий запрос теперь может быть отправлен до того как выдан ответ по предыдущему запросу, в то время как раньше новый запрос отправлялся только после ответа на предыдущий). Параллельные каналы доступны для хелперов Digest authentication, Store-ID и URL-rewrite. Разделение каналов производится на основании содержимого поля channel-ID.
  • Возвращена поддержка опции collapsed_forwarding, которая была доступна в ветке Squid-2, но не попала в релиз Squid 3.0. Опция позволяет включить оптимизацию проброса трафика при наличии большого числа параллельных запросов к одному URL. Оптимизация производится за счёт объединения нескольких запросов к кэшу, в которых фигурирует один URL, до того как Squid узнает о том, должен ли быть прокэширован ответ.
  • Поддержка eCAP 1.0. Использование новой библиотеки libecap позволяет улучшить процесс согласования версий библиотеки 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 добавлена поддержка отправки запросов по HTTPS ("--https"), добавлена команда "--ping" для периодического повтора отправки сообщений, реализованы уровни отладочного вывода.
  • Начальная поддержка протокола PROXY, позволяющего передавать информацию о соединении (например, оригинальный IP-адрес клиента) по всей цепочке проксирования или туннелирования соединения без необходимости модификации и разбора протокола внутри соединения. В настоящее время протокол PROXY может использоваться в Squid для получения HTTP-трафика от прокси на стороне клиента.
  • Удалена поддержка хранилища COSS, вместо которого следует использовать хранилище Rock. Удалены хелпер dnsserver и DNS helper API, на смену которым пришёл встроенный клиент DNS.



  1. Главная ссылка к новости (http://marc.info/?l=squid-anno...)
  2. OpenNews: Стабильный релиз прокси-сервера Squid 3.4
  3. OpenNews: Стабильный релиз новой ветки прокси-сервера Squid 3.3
  4. OpenNews: Стабильный релиз новой ветки прокси-сервера Squid 3.2
  5. OpenNews: Первый стабильный релиз новой ветки прокси-сервера Squid 3.1
  6. OpenNews: Ветка Squid 3.0 объявлена стабильной. Вышел Squid-3.0.STABLE1
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/41481-squid
Ключевые слова: squid, proxy
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (21) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 00:27, 18/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    ftp -- протокол будущего!
     
     
  • 2.2, commiethebeastie (ok), 03:17, 18/01/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    После полного импортозамещения.
     
  • 2.6, Аноним (-), 12:27, 18/01/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Особенно в плане информирования о кодировке имён на сервере ;) Да, мир почти перешёл на UTF-8, но M$-дятлы клиенты остались со своей CP1251 locale.
     
  • 2.8, Нимо Ан (?), 15:03, 18/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вам смешно, а я столько лет, пока это не потеряло всякую актуальность ждал, пока кто-нибудь наконец запилит полноценный FTP proxy (а также SMPT и POP3). И вот, на старости лет дождался... Осталось дождаться реализации протокола ZModem...
     
     
  • 3.9, Аноним (-), 17:23, 18/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вам смешно, а я столько лет, пока это не потеряло всякую актуальность
    > ждал, пока кто-нибудь наконец запилит полноценный FTP proxy (а также SMPT
    > и POP3). И вот, на старости лет дождался... Осталось дождаться реализации
    > протокола ZModem...

    С одной стороны смешно, с другой стороны грустно.
    Уже давно Вам необходимо было разработать спецификации кеширования для протокола FTP.
    Ведь их по моему скромному мнению не было, от того и не реализовывали.
    А может лучше rsync?

     
  • 3.16, Аноним (16), 10:04, 19/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а как же frox?
     
     
  • 4.21, fx (ok), 15:47, 20/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    и delegate ещё
     
  • 3.17, Не аноним (?), 11:34, 19/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А как же nginx? Он всё не умеет только ZModem ;-)
     
     
  • 4.18, Не аноним (?), 11:35, 19/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > А как же nginx? Он не умеет только ZModem ;-)

    fixed

     
     
  • 5.19, Andrey Mitrofanov (?), 11:59, 19/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> А как же nginx? Он не умеет ZModem, ftp://, ldap://, smb://, [запарился - остатки /ets/services сами, угу?]
    > fixed

    overfixed

     
  • 3.20, softfire (?), 13:10, 19/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Джва года? Или может быть даже джвадцать лет?
     

  • 1.3, Dkg (?), 10:06, 18/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Имхо, лучше использовать в составе полноценных решений, таких как Pfsense.
     
  • 1.4, Аноним (-), 10:09, 18/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > вначале осуществляется соединение с целевым сервером, а потом создаётся защищённое соединение между клиентом и прокси

    кажется, это называется "man in the middle"?

     
     
  • 2.7, Аноним (-), 12:29, 18/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Да, но в корпоративных сетях, где за утечкой инфы следят, приемлемо.
     

  • 1.5, Аноним (-), 11:48, 18/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Хорошая штука!
    Жаль только, что чем дальше тем больше трафик уходит в "сторону" шифрования (это плохо для прокси серверов и кеширования соответственно). Ну дык людишки сами виноваты, суют свой нос везде и повсюду :( скоро уже и геморрой от их носов никак не спрячешь ;)
     
     
  • 2.10, DeadLoco (ok), 18:50, 18/01/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Увы, но проблема не так в шифровании траффика, как в динамической его генерации. Кешировать стало почти нечего. В конце 1990-х - начале 2000-х я поднимал сквид с кешем в 64 ГБ, и уровень кеширования достигал 40% от общего трафика. В конце 2000-х этот показатель едва достигал 10%. Сейчас он около 3% - нет ни малейшего смысла заморачиваться с кешированием.

    В настоящее время прокси полезны только для фильтрации и статистики. Учитывая стоимость каналов, экономия траффика не стоит свеч.

     
     
  • 3.11, Аноним (-), 19:19, 18/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Увы, но проблема не так в шифровании траффика, как в динамической его
    > генерации. Кешировать стало почти нечего. В конце 1990-х - начале 2000-х
    > я поднимал сквид с кешем в 64 ГБ, и уровень кеширования
    > достигал 40% от общего трафика. В конце 2000-х этот показатель едва
    > достигал 10%. Сейчас он около 3% - нет ни малейшего смысла
    > заморачиваться с кешированием.
    > В настоящее время прокси полезны только для фильтрации и статистики. Учитывая стоимость
    > каналов, экономия траффика не стоит свеч.

    Согласен. И еще всякие фичи в работе с URL-ми.

     
  • 3.12, Аноним (-), 20:27, 18/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Зато теперь каждый обязан иметь собственный локальный DNS сервер )
     
     
  • 4.14, DeadLoco (ok), 21:11, 18/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Зато теперь каждый обязан иметь собственный локальный DNS сервер )

    Не улавливаю связи.

     

  • 1.13, robux (ok), 20:48, 18/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вопрос не в тему: в новых сквидах есть какой-то нативный способ управления квотами, вместо sams например?
     
     
  • 2.15, Нет (?), 08:22, 19/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Нет.
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру