Oc-windows.ru

IT Новости из мира ПК
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Phproxy remove client

Phproxy remove client

GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.

Clone with HTTPS

Use Git or checkout with SVN using the web URL.

Downloading

Want to be notified of new releases in PHProxy/phproxy ?

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio

Latest commit

Files

Permalink

TypeNameLatest commit messageCommit time
Failed to load latest commit information.
filesfixes some errorsOct 22, 2018
.gitignoreUpdate .gitignoreMay 16, 2018
LICENSE.mdupdate of docsOct 21, 2015
README.mdUpdate README.mdMay 17, 2018
edit.phpAdded custom user agentAug 21, 2018
index.phpAdd data-cfsrc supportJan 10, 2019

PHProxy is a web HTTP proxy written in PHP. It is designed to bypass proxy restrictions through a web interface very similar to the popular CGIProxy. The only thing that PHProxy needs is a web server with PHP installed (see Requirements below). Be aware though, that the sever has to be able to access those resources to deliver them to you.

Originaly developed in SourceForge during 2002-2007 and then abandoned. This project needs to live and it’s development is continued here.

  • Create an issue: https://github.com/PHProxy/PHProxy/issues/new

This source code is released under the GPL. A copy of the license is provided in this package in the filename LICENSE.md .

  • PHP version > 5
  • safe_mode turned off or at least having the fsockopen() function not disabled
  • OpenSSL for support for secure connections (https)
  • Zlib for output compression
  • file_uploads turned On for HTTP file uploads.

Copy the files of the repository in your public web server folder or to a directory of your liking (prefrebly in its own directory).

You simply supply a URL to the form and click Browse. The script then accesses that URL, and if it has any HTML contents, it modifies any URLs so that they point back to the script. Of course, there is more to it than this, but if you would like to know more in detail, view the source code.

Bugs and Limitations

PHP is restrictive by nature, and as such, some problems arise that would have not if this project were otherwise coded in another programming language. The first example of this is the dots in incoming variable names from POST and GET methods. In a normal programming language, this wouldn’t be a problem as these variables could be accessed normally as they are supplied, with dots included. In PHP, however, dots in GET, POST, and COOKIE variable names are magically transformed into underscores because of register_globals . Things like Yahoo! Mail which has dots in variable names will not work. There’s no easy way around this, but luckily, I have provided the solutions right here:

  1. I’ve already taken care of cookies by manually transforming the underscores manually into dots when needed.
  2. For GET variables, this shouldn’t be a huge problem since the URLs are URL-encoded into the url_var_name. The only time this should be an issue is when a GET form uses dots in input names, and this could be recitified by using $_SERVER[‘QUERY_STRING’], and parsing that variable. But this, luckily, doesn’t happen too often.
  3. As for POST data, one solution is to use $HTTP_RAW_POST_DATA. But then, this variable might not be available in certain PHP configurations, and it would need further parsing, and it still doesn’t account for uploaded FILES. This is extremely impractical and ugly.

The best thing you could do if you have enough control over your Web server and can compile custom builds of PHP is to delete a single line in a PHP source code file called «php_variables.c» located in the «main» directory. The function in question is called «php_register_variable_ex». I’ve only checked this with PHP v4.4.4 and the exact line to delete is 117th line which basically consists of this:

Now just compile and install PHP and everything should be fine. Just make sure that you have register_globals off or something might get messed up.

Another problem facing many Web proxies is support for JavaScript. The best thing you could do right now is to have the JavaScript disabled on your browsing options as most sites degrade gracefully, such as Gmail.

A third limitation for Web proxies is content accessed from within proxied Flash and Java applications and such. Since the proxy script doesn’t have access to the source code of these applications, the links which they may decide to stream or access will not be proxified. There’s no easy solution for this right now.

PHProxy also doesn’t support FTP. This may or may not be introduced in future releases, but there are no current plans for FTP support.

Проксируем и спасаем

ноября мир изменился и больше никогда не будет таким же как прежде. В российском интернете появилась цензура — общеизвестный уже список запрещенных сайтов. Для одних это важнейшая политическая тема, для других повод изучить технологии шифрования и защиты анонимности, для третьих просто очередной странный закон, который приходится исполнять на бегу. Мы же поговорим о технологическом аспекте.

В данном пособии мы узнаем как быстро и просто сделать рабочее зеркало любого сайта, что позволяет сменить IP и назначить любое доменное имя. Мы даже попробуем спрятать домен в url, после чего можно сохранить локально полную копию сайта. Все упражнения можно сделать на любом виртуальном сервере — лично я использую хостинг Хетцнер и OS Debian. И конечно мы будем использовать лучший веб-сервер всех времен и народов — NGINX!

К этому абзацу пытливый читатель уже приобрел и настроил какой нибудь выделенный сервер или просто запустил Linux на старом компьютере под столом, а так же запустил Nginx последней версии со страничкой «Save me now».

Перед началом работы необходимо скомпилировать nginx c модулем ngx_http_substitutions_filter_module, прежнее название — substitutions4nginx.

Дальнейшая конфигурация будет показана на примере сайта www.6pm.com. Это сайт популярного онлайн магазина, торгующего товарами с хорошими скидками. Он отличается категорическим нежеланием давать доступ покупателям из России. Ну чем не оскал цензуры капитализма?

У нас уже есть работающий Nginx, который занимается полезными делом — крутит сайт на системе Livestreet о преимуществах зарубежного шоппинга. Чтобы поднять зеркало 6pm прописываем DNS запись с именем 6pm.pokupki-usa.ru который адресует на IP сервера. Как вы понимаете, выбор имени для суб-домена совершенно произволен. Это имя будет устанавливаться в поле HOST при каждом обращении к нашему новому ресурсу, благодаря чему на Nginx можно будет запустить виртуальный хостинг.

В корневой секции конфигурации nginx прописываем upstream — имя сайта-донора, так будем его называть в дальнейшем. В стандартных гайдах сайт обычно называется back-end, а reverse-proxy называется front-end.

Дальше нужно создать секцию server, вот как она выглядит

Стандартные директивы listen и server определяют имя виртуального хоста, при обращении к которому будет срабатывать секция server. Файлы логов лучше сделать отдельными.

Объявляем корневой локейшин, указываем путь до его хранилища — root /var/www/6pm; затем используем try_files. Это очень важная директива nginx, которая позволяет организовать локальное хранилище для загруженных файлов. Директива сначала проверяет нет ли файла с именем $uri и если не находит его — переходит в именованный локейшин @ static

$uri — переменная nginx, которая содержит путь из HTTP запроса

Префикс “@” задаёт именованный location. Такой location не используется при обычной обработке запросов, а предназначен только для перенаправления в него запросов. Такие location’ы не могут быть вложенными и не могут содержать вложенные location’ы

В нашем случае конструкция используется только для подмены файла robots.txt, чтобы запретить индексацию содержимого сайта. Однако таким образом делается зеркалирование и кеширование в nginx.

include ‘6pm.conf’ — логика модуля substitutions.

proxy_cookie_domain — новая функция, которая появилась в nginx версии 1.1.15, без этой директивы приходилось делать так. Больше не нужно ломать голову, прописываете одну строчку и куки просто начинают работать.

proxy_set_header Accept-Encoding «»; — очень важная команда, которая заставляет сайт донор отдавать вам контент не в сжатом виде, иначе модуль substitutions не сможет выполнить замены.

proxy_set_header Host — еще одна важная команда, которая в запросе к сайту донору выставляет правильное поле HOST. Без нее будет подставляться имя нашего прокси сервера и запрос будет ошибочным.
proxy_pass — прямая адресация не работает в именованном локейшине, именно поэтому мы прописали адрес сайта донора в директиве upstream.
proxy_redirect — многие сайты используют редиректы для своих нужд, каждый редирект нужно отловить и перехватить здесь, иначе запрос и клиент уйдет за пределы нашего уютного доменчика.

Теперь посмотрим содержимое 6pm.conf. Я не случайно вынес логику трансформации в отдельный файл. В нем можно разместить без какой либо потери производительности тысячи правил замены и сотни килобайт фильтров. В нашем случае мы хотим лишь завершить процесс проксирования, поэтому файл содержит всего 5 строк:

Меняем коды google analytics:

Уверяю, что это самая безобидная шалость из возможных. У нас появится статистика посещений, а у сайта донора эти визиты — исчезнут.

Меняем все прямые ссылки на новые.

Как правило, в нормальных сайтах все картинки лежат на CDN сетях, которые не утруждают себя проверкой источника запросов, поэтому достаточно замены ссылок только основного домена. В нашем случае 6pm выпендрился и разместил часть картинок на доменах, которые отказывают посетителям из России. К счастью, модуль замены поддерживает регулярные выражения и не составляет никакого труда написать общее правило для группы ссылок. В нашем случае обошлось даже без regexp, просто поменяли два символа в домене. Получилось так:

Единственное, но очень серьезное ограничение модуля замены — он работает только с одной строкой. Это ограничение заложено архитектурно, поскольку модуль работает на этапе, когда страница загружена частично (chunked transfer encoding) и нет никакой возможности выполнить полнотекстовый regexp.

Все, можно посмотреть на результат, все работает, даже оплата заказа проходит без затруднений.

Итак, мы перекинули сайт на новый IP адрес и новый домен. Это было простой задачей. Можно ли запроксировать сайт не в новый домен, а в поддиректорию существующего? Это сделать можно, но возникают сложности. Для начала вспомним какие бывают html ссылки:

  1. Абсолютные ссылки вида «www.example.com/some/path»
  2. Ссылки относительно корня сайта вида «/some/path»
  3. Относительные ссылки вида «some/path»

С п.1 все просто — мы заменяем все ссылки на новый путь с поддиректорией
С п.3 так же просто — мы ничего не трогаем и все работает само если не использовался атрибут base href. Если этот атрибут используется, что бывает крайне редко в современных сайтах, то достаточно его заменить и все будет работать.

Настоящая сложность возникает с п.2. из-за того что мы должны изменить кучу ссылок вида /. на /subdomain/. . Если сделать это в лоб, то сайт скорее всего полностью перестанет работать, ибо такая замена сломает множество конструкций использующих слеш, что испортит почти все скрипты javascript.

Теоретически можно написать достаточно общий универсальный regexp, который сумеет выбрать исключительно нужные паттерны для замены, на практике гораздо проще написать несколько простых regexpов, которые будут по частям переводить нужные ссылки.

Вернемся к нашему пациенту:

Конфигурация сервера претерпела некоторые изменения.

Во-первых, вся логика перенесена из директивы sever напрямую в location. Нетрудно догадаться, что мы решили создать директорию /6pm в которую будем выводить проксируемый сайт.

proxy_cookie_path / /6pm/ — переносим куки из корня сайта в поддиректорию. Это делать не обязательно, но в случае если проксируемых сайтов окажется много, их куки могут пересечься и затереть друг друга.

rewrite ^/6pm/(.*) /$1 break; — эта магия вырезает из клиентского запроса поддиректорию, которую мы добавили, в результате директива proxy_pass отправляет на сервер-донор корректное значение.

Чуть сложнее стало ловить редиректы. Теперь все ссылки на корень нужно перебросить на /6pm.

Посмотрим на логику трансформации:

Во-первых, мы включили фильтрацию файлов css и javascript (парсинг html включен по-умолчанию)
Во-вторых, начинаем аккуратно находить и заменять разные типы ссылок относительно корня. Нам попался средней сложности сайт, в котором часть скриптов содержат такие пути.

К сожалению, мне не удалось до конца написать фильтр для случая поддиректории. Я не дошел до преобразования динамических запросов скриптов корзины с покупками, хотя не сомневаюсь что это решаемо. Просто моих знаний в Javascript не достаточно чтобы выполнить необходимую отладку, буду рад советам как запустить корзину покупок, которая сейчас в упомянутом примере не работает.

В любом случае, это, возможно, первый гайд, в котором описан метод проксирования в поддиректорию.

Проксирование запросов в nginx с помощью proxy_pass

Хочу рассказать об одной полезной возможности nginx, которую регулярно использую в своих делах. Речь пойдет о настройке проксирования запросов на удаленный сервер с помощью nginx и директивы proxy_pass. Я приведу примеры различных настроек и расскажу, где сам использую данный модуль популярного веб сервера.

Введение

Немного расскажу своими словами о том, как работает модуль ngx_http_proxy_module. Именно он реализует весь функционал, о котором пойдет речь. Допустим, у вас в локальной или виртуальной сети есть какие-то сервисы, не имеющие прямого доступа из интернета. А вы хотите таковой иметь. Можно пробрасывать нужные порты на шлюзе, можно что-то еще придумывать. А можно сделать проще всего — настроить единую точку входа на все свои сервисы в виде nginx сервера и с него проксировать различные запросы к нужным серверам.

Расскажу на конкретных примерах, где я это использую. Для наглядности и простоты буду прям по порядку перечислять эти варианты:

  1. Ранее я рассказывал о настройке чат серверов — matrix и mattermost. В этих статьях я как раз рассказывал о том, как проксировать запросы в чат с помощью nginx. Прошелся по теме вскользь, не останавливаясь подробно. Суть в том, что вы настраиваете на любом виртуальном сервере эти чаты, помещаете их в закрытые периметры сети без лишних доступов и просто проксируете запросы на эти сервера. Они идут через nginx, который у вас смотрит во внешний интернет и принимает все входящие соединения.
  2. Допустим, у вас есть большой сервер с множеством контейнеров, например докера. На нем работает множество различных сервисов. Вы устанавливаете еще один контейнер с чистым nginx, на нем настраиваете проксирование запросов на эти контейнеры. Сами контейнеры мапите только к локальному интерфейсу сервера. Таким образом, они будут полностью закрыты извне, и при этом вы можете гибко управлять доступом.
  3. Еще один популярный пример. Допустим, у вас есть сервер с гипервизором proxmox или любым другим. Вы настраиваете на одной из виртуальных машин шлюз, создаете локальную сеть только из виртуальных машин без доступа в нее извне. Делаете в этой локальной сети для всех виртуальных машин шлюз по-умолчанию в виде вашей виртуальной машины со шлюзом. На виртуальных серверах в локальной сети размещаете различные сервисы и не заморачиваетесь с настройками фаервола на них. Вся их сеть все равно не доступна из интернета. А доступ к сервисам проксируете с помощью nginx, установленным на шлюз или на отдельной виртуальной машине с проброшенными на нее портами.
  4. Мой личный пример. У меня дома есть сервер synology. Я хочу организовать к нему простой доступ по https из браузера по доменному имени. Нет ничего проще. Настраиваю на сервере nginx получение бесплатного сертификата Let’s encrypt, настраиваю проксирование запросов на мой домашний ip, там на шлюзе делаю проброс внутрь локалки на synology сервер. При этом я могу фаерволом ограничить доступ к серверу только одним ip, на котором работает nginx. В итоге на самом synology вообще ничего не надо делать. Он и знать не знает, что к нему заходят по https, по стандартному порту 443.
  5. Допустим, у вас большой проект, разбитый на составные части, которые живут на разных серверах. К примеру, на отдельном сервере живет форум, по пути /forum от основного домена. Вы просто берете и настраиваете проксирование всех запросов по адресу /forum на отдельный сервер. Точно так же можно без проблем все картинки перенести на другой сервер и проксировать к ним запросы. То есть вы можете создать любой location и переадресовывать запросы к нему на другие сервера.

Надеюсь в общем и целом понятно, о чем идет речь. Вариантов использования много. Я привел самые распространенные, которые пришли в голову и которые использую сам. Из плюсов, которые считаю наиболее полезными именно из своих кейсов, отмечу 2:

  • Вы без проблем можете настроить https доступ к сервисам, при этом совершенно не трогая эти сервисы. Вы получаете и используете сертификаты на nginx сервере, используете https соединение с ним, а сам nginx уже передает информацию на сервера со службами, которые могут работать по обычному http и знать не знают о https.
  • Вы очень легко можете менять адреса, куда проксируете запросы. Допустим у вас есть сайт, его запросы проксируются на отдельный сервер. Вы подготовили обновление или переезд сайта. Отладили все на новом сервере. Теперь вам достаточно на сервере nginx изменить адрес старого сервера на новый, куда будут перенаправляться запросы. И все. Если что-то пойдет не так, можете оперативно вернуть все обратно.

С теорией закончил. Перейдем теперь к примерам настройки. В своих примерах я буду использовать следующие обозначения:

blog.zeroxzed.ruдоменное имя тестового сайта
nginx_srvимя внешнего сервера с установленным nginx
blog_srvлокальный сервер с сайтом, куда проксируем соединения
94.142.141.246внешний ip nginx_srv
192.168.13.31ip адрес blog_srv
77.37.224.139ip адрес клиента, с которого я буду заходить на сайт

Настройка proxy_pass в nginx

Рассмотрим самый простой пример. Буду использовать свой технический домен zeroxzed.ru в этом и последующих примерах. Допустим, у нас есть сайт blog.zeroxzed.ru. В DNS создана A запись, указывающая на ip адрес сервера, где установлен nginx — nginx_srv. Мы будем проксировать все запросы с этого сервера на другой сервер в локальной сети blog_srv, где реально размещается сайт. Рисуем конфиг для секции server.

Заходим по адресу http://blog.zeroxzed.ru. Мы должны попасть на blog_srv, где тоже должен работать какой-то веб сервер. В моем случае это будет тоже nginx. У вас должно открыться содержимое, аналогичное тому, что вы увидите, набрав http://192.168.13.31 в локальной сети. Если что-то не работает, то проверьте сначала, что по адресу директивы proxy_pass у вас все корректно работает.

Посмотрим логи на обоих сервера. На nginx_srv вижу свой запрос:

Как мы видим, запрос сначала пришел на nginx_srv, был переправлен на blog_srv, куда он пришел уже с адресом отправителя 94.142.141.246. Это адрес nginx_srv. Реальный же ip адрес клиента мы видим только в самом конце лога. Это неудобно, так как директива php REMOTE_ADDR не будет возвращать настоящий ip адрес клиента. А он очень часто бывает нужен. Мы это дальше исправим, а пока создадим в корне сайта на chat_srv тестовую страничку для проверки ip адреса клиента следующего содержания:

Назовем ее myip.php. Перейдем по адресу http://blog.zeroxzed.ru/myip.php и проверим, как сервер определит наш адрес. Никак не определит 🙂 Он покажет адрес nginx_srv. Исправляем это и учим nginx передавать реальный ip адрес клиента на сервер.

Передача реального ip (real ip) адреса клиента в nginx при proxy_pass

В предыдущем примере мы на самом деле передаем реальный ip адрес клиента с помощью директивы proxy_set_header, которая добавляет в заголовок X-Real-IP настоящий ip адрес клиента. Теперь нам нужно на принимающей стороне, то есть blog_srv сделать обратную замену — заменить информацию об адресе отправителя на ту, что указана в заголовке X-Real-IP. Добавдяем в секцию server следующие параметры:

Полностью секция server на blog_srv в самом простом варианте получается следующей:

Сохраняем конфиг, перечитываем его и снова проверяем http://blog.zeroxzed.ru/myip.php. Вы должны увидеть свой реальный ip адрес. Его же вы увидите в логе web сервера на blog_srv.

Дальше рассмотрим более сложные конфигурации.

Передача https через nginx с помощью proxy pass

Если у вас сайт работает по https, то достаточно настроить ssl только на nginx_srv, если вы не беспокоитесь за передачу информации от nginx_srv к blog_srv. Она может осуществляться по незащищенному протоколу. Рассмотрю пример с бесплатным сертификатом let’s encrypt. Это как раз один из кейсов, когда я использую proxy_pass. Очень удобно настроить на одном сервере автоматическое получение всех необходимых сертификатов. Подробно настройку let’s encrypt я рассматривал отдельно. Сейчас будем считать, что у вас стоит certbot и все готово для нового сертификата, который потом будет автоматически обновляться.

Для этого нам надо на nginx_srv добавить еще один location — /.well-known/acme-challenge/. Полная секция server нашего тестового сайта на момент получения сертификата будет выглядеть вот так:

Перечитывайте конфиг nginx и получайте сертификат. После этого конфиг меняется на следующий:

Проверяем, что получилось.

Наш сайт работает по https, при том, что мы вообще не трогали сервер, где этот сайт располагается. Конкретно с web сайтом это может быть не так актуально, но если вы проксируете запросы не на обычный сайт, а на какой-то нестандартный сервис, который трудно перевести на https, это может быть хорошим решением.

Проксирование определенной директории или файлов

Рассмотрим еще один пример. Допустим, у вас форум живет в директории http://blog.zeroxzed.ru/forum/, вы хотите вынести форум на отдельный web сервер для увеличения быстродействия. Для этого к предыдущему конфигу добавьте еще один location.

Еще одно популярное решение. Вы можете отдавать картинки с одного сервера, а все остальное с другого. В моем примере, картинки будут жить на том же сервере, где nginx, а остальной сайт на другом сервере. Тогда у нас должна быть примерно такая конфигурация локаций.

Чтобы все это работало корректно, необходимо, чтобы сам сайт умел правильно размещать свои изображения. Вариантов это организовать множество. Можно как на сервере монтировать сетевые паки различными способами, так и программистам изменять код для управления размещением изображений. В любом случае, это комплексный подход к работе с сайтом.

Существует очень много директив для управления прокси-соединениями. Все они описаны в соответствующей документации nginx. Я не большой специалист по настройке nginx. В основном использую свои готовые конфиги, зачастую даже не вникая в суть, если получается сразу решить задачу. Подсматриваю что-то у других, записываю к себе, стараюсь разобраться.

Особое внимание следует уделить директивам кэширования proxy_cache, если в этом есть потребность. Можно существенно увеличить отклик веб сайта, если подходящим образом настроить отдачу кэша. Но это тонкий момент и нужно настраивать в каждом конкретном случае отдельно. Готовых рецептов тут не бывает.

Более подробно о комплексной настройке nginx читайте в отдельной большой статье с моими личными примерами.

Заключение

На этом у меня все. Не рассмотрел еще один возможный вариант, когда вы проксируете https сайт и передаете инфу на бэкенд тоже по https. Нет под рукой готового примера, чтобы проверить, а заочно не стал рисовать конфиг. По идее, ничего сложного в этом нет, настраиваете nginx на обоих серверах с одним и тем же сертификатом. Но наверняка не скажу, что все заработает при этом. Возможно, есть какие-то нюансы с таким проксированием. Мне обычно не приходится так делать.

Как я уже писал в начале, в основном проксирую запросы с одного внешнего веб сервера на закрытый периметр сети, куда нет никому доступа. В этом случае у меня нет необходимости использовать https при передаче запросов на бэкенд. В качестве бэкенда не обязательно будет отдельный сервер. Это запросто может быть контейнер на этом же сервере.

Посторонним В.

воскресенье, 31 января 2016 г.

AcePHProxy: обновление до 0.6.4

  • вывод содержимого (.torrent-файлов) из спец. папки как плейлиста
  • вывод .torrent-файлов, состоящих из нескольких видео, как плейлиста
  • эффективное использование памяти
  • слегка обновленный интерфейс

Ложка дегтя

  • магнет-ссылки проигрывать не умеет
  • если торрент предоставляет отдельный файл субтитров или звуковой дорожки, они не подцепляются

Еще с того момента, как мне удалось первый раз запустить воспроизведение из .torrent-файла, стало ясно, что без перемотки жить грустно.

  1. понять, чего не хватает XBMC для поддержки перемотки
  2. написать скрипт, выдающий тестовый видеофайл так, чтобы работала перемотка
  3. интегрировать результаты исследований в AcePHProxy

Как же выдать видео по HTTP с поддержкой перемотки

  1. XBMC делает HEAD запрос, чтобы получить ответные заголовки с информацией о содержимом (код ответа, а то может такого контента и нет, версия протокола HTTP, размер контента, контент-тип, поддержка Ranged-запросов и т.д.). Если HEAD не поддерживается сервером, делает запрос с заголовком Range: bytes=0-0
  2. Дальше начинаются реальные запросы данных. Первый такой запрос идет с заголовком «Range: bytes=0-«, т.е. запрашивается файл целиком. Обозначу этот запрос «А». Скоро он будет сброшен (передача отменится). Важно заметить, что ответный заголовок HTTP/1.1 206 Partial Content, а не HTTP/1.1 200 OK!
  3. К этому моменту XBMC уже знает длину содержимого, и делает второй запрос данных («Б»), запрашивает около 1Мб с конца файла (Range: bytes=1455123456-). «А» еще активен, т.е. запросы идут параллельно, и далее будет описано, почему это является проблемой.
  4. Коннект «А» отменяется, открывается «В», запрашивается диапазон «Range: bytes=4108-«, почти с начала файла. «Б» еще активен
  5. Коннект «Б» отменяется. делается запрос «Г» с диапазоном «Range: bytes=1455123456-«, т.е. опять с конца файла, почти с того же места, разница в несколько байт.
  6. Через некоторое время без видимых причин коннект «В» отменяется и далее активен только коннект «Г», запрошенный конец файла докачивается целиком
  7. И наконец следует последний запрос «Д» с диапазоном «Range: bytes=4108-«, который и остается активен до конца.

Платите за 100Мбит-ный интернет, чтобы фильмы и сериалы качались быстрее?
Я комфортно смотрю фильмы онлайн при своем 8Мбит-ном интернете.
С каналом 48Мбит, конечно, повеселее. Для сравнения — при 8Мбит фильм запускается за 35-50сек (пребуферизация, подгрузка нужных частей видеофайла), а при 48Мбит — за 5-10 сек.
Или вот еще выгода: иногда скачанный торрент не совсем удачен (оригинальная озвучка по громкости равна переводу и разобрать родную речь в этой мешанине сложно), в данном случае достаточно скачать другой вариант того же торрента и можно тут же запускать просмотр.

Раз уж речь о просмотре торрентов, есть еще прога MediaGet, как однопользовательская альтернатива этому софту. Кстати я и ее пытался отреверсить, однако там ничего интересного не оказалось.

Немного о других улучшениях

Папка с торрент-файлами: в коде прописана папка, в которую можно скидывать .torrent-файлы, AcePHProxy по ее содержимому сформирует плейлист, для этого надо обратиться к софту по спец.ссылке http:// :8000/playlist

И немного статистики в интерфейсе: версия софта, аптайм, потребление памяти и т.д. На скрине выше в колонке Client — uptime каждого клиента и число скачанных им за время подключения мегабайт.

О дегте

Очень хотелось мне научить софтину открывать содержимое по INFOHASH, оно же магнет-ссылка, потому что в автоматическом режиме каким-нибудь краулером (ботом-поисковиком) найти в сети магнет-ссылку куда проще, чем готовый .torrent-файл для скачивания. И это открыло бы новые возможности для автоматизации домашней мультимедиа. Сам AceServer не умеет открывать INFOHASH до сих пор. хоть и заявлена поддержка, поэтому я искал обходные пути. Их было два. но однотипные.

  1. сформировать простейший .torrent-файл с содержимым
    magnet:?xt=urn:btih:
  2. скормить магнет-ссылку rTorrent-у, тот сделает torrent-файл, который и можно будет взять в папке session. Я даже специально обновил rtorrent до 0.9.2 (ох непросто это было)

Наивный землянин.. Первый способ конечно никуда не годен, это было бы слишком просто.
Второй способ подавал надежды. rTorrent нормально съел ссылку в том виде, в каком она описана в первом способе, чем порадовал меня. И даже .torrent файл я нашел в папке session. Однако при попытке скормить его AceStream я получил ошибку «announce, nodes and announce-list missing».

Впрочем, буквально на днях мне удалось через сайт http://magnet2torrent.me/ сделать из магнет-ссылки работающий в Ace торрент, но там кроме инфохэша еще адреса трекеров были, а это уже «и я так могу». Тем не менее, кажется еще не все потеряно 😉

1. объявление о своем присутствии в сети по DLNA
2. если DLNA будет слишком сложно, можно сделать спецссылку для выдачи RSS-плейлиста
3. хэндлер для приема поисковых запросов, поиск в инете и выдача плейлиста из найденного
4. научить проигрывать magnet-ссылки

Читать еще:  Php ведущие нули
Ссылка на основную публикацию
Adblock
detector