The OpenNET Project / Index page

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

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

После года разработки представлена новая стабильная ветка прокси-сервера 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
Тип: Программы
Ключевые слова: squid, proxy
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Линейный вид | Ajax | Показать все | RSS
 
  • 1.1, Аноним, 00:27, 18/01/2015 [ответить] [смотреть все]
  • +6 +/
    ftp -- протокол будущего!
     
     
  • 2.2, commiethebeastie, 03:17, 18/01/2015 [^] [ответить] [смотреть все] [показать ветку]
  • +4 +/
    После полного импортозамещения.
     
  • 2.6, Аноним, 12:27, 18/01/2015 [^] [ответить] [смотреть все] [показать ветку]
  • +3 +/
    Особенно в плане информирования о кодировке имён на сервере Да, мир почти пер... весь текст скрыт [показать] [показать ветку]
     
  • 2.8, Нимо Ан, 15:03, 18/01/2015 [^] [ответить] [смотреть все] [показать ветку]  
  • –1 +/
    Вам смешно, а я столько лет, пока это не потеряло всякую актуальность ждал, пока... весь текст скрыт [показать] [показать ветку]
     
     
  • 3.9, Аноним, 17:23, 18/01/2015 [^] [ответить] [смотреть все]  
  • +1 +/
    С одной стороны смешно, с другой стороны грустно Уже давно Вам необходимо было ... весь текст скрыт [показать]
     
  • 3.16, Аноним, 10:04, 19/01/2015 [^] [ответить] [смотреть все]  
  • +1 +/
    а как же frox?
     
     
  • 4.21, fx, 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 [^] [ответить] [смотреть все]  
  • +/
    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, 18:50, 18/01/2015 [^] [ответить] [смотреть все] [показать ветку]  
  • +2 +/
    Увы, но проблема не так в шифровании траффика, как в динамической его генерации. Кешировать стало почти нечего. В конце 1990-х - начале 2000-х я поднимал сквид с кешем в 64 ГБ, и уровень кеширования достигал 40% от общего трафика. В конце 2000-х этот показатель едва достигал 10%. Сейчас он около 3% - нет ни малейшего смысла заморачиваться с кешированием.

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

     
     
  • 3.11, Аноним, 19:19, 18/01/2015 [^] [ответить] [смотреть все]  
  • +/
    Согласен И еще всякие фичи в работе с URL-ми ... весь текст скрыт [показать]
     
  • 3.12, Аноним, 20:27, 18/01/2015 [^] [ответить] [смотреть все]  
  • –1 +/
    Зато теперь каждый обязан иметь собственный локальный DNS сервер )
     
     
  • 4.14, DeadLoco, 21:11, 18/01/2015 [^] [ответить] [смотреть все]  
  • +1 +/
    > Зато теперь каждый обязан иметь собственный локальный DNS сервер )

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

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

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:


      Закладки на сайте
      Проследить за страницей
    Created 1996-2017 by Maxim Chirkov  
    ДобавитьРекламаВебмастеруГИД  
    Hosting by Ihor