Действительно, есть ретрансмиссия. Я смотрел трафик, но очевидно недостаточно внимательно.
Сначала приходит пакет, в котором только HTTP 302 и Location, затем приходит пакет с нормальным ответом сайта.
Однако система не отбрасывает второй пакет, а своеобразно объединяет с первым.
Т.е. приходят пакеты
1
HTTP/1.1 302 Found
Connection: close
Location: http://95.167.13.50/?st=0&dt=192.237.142.117&rs=grani.ru/
В описанном мной случае смысл кэшировать DNS определенно есть, равно как есть смысл кэшировать DNS в браузере.
Без кэширования DNS происходило бы следующее:
— пришел запрос на www.example.com/, дернули DNS, только после получения ответа DNS можем обрабатывать запрос
— пришел запрос на www.example.com/scripts.js, дернули DNS, только после получения ответа DNS можем обрабатывать запрос
— пришел запрос на www.example.com/style.css, дернули DNS, только после получения ответа DNS можем обрабатывать запрос
и т.д.
Очевидно, что даже при наличии локального DNS вносятся заметные задержки.
HTTP Keep-Alive конечно сгладил бы негативный эффект, но не отменил бы его.
Вообще в данном случае прокси, кэшируя DNS, делает тоже самое, что и браузер.
При работе через прокси браузер не посылает DNS запросы, это делает прокси.
Поэтому и кэшировать DNS тоже должен прокси.
Что касается TTL, то я уверен, что 3proxy (как и браузер) учитывает его в алгоритме кэширования.
Без кэширования DNS-запросов прокси будет дергать DNS на каждый запрос. Очевидно, это будет приводить к задержкам.
А в чем вообще проблема с кэшированием в данном случае? Это же собственный прокси для собственного серфинга. Без использования прокси тоже самое кэширование DNS делает сам браузер.
Если какой-то CA начнет так делать, то сертификат этого CA будет отозван из списка доверенных.
Ростелеком, когда начинает лезть в https, подписывает все своим собственным сертификатом, выданным для *.rt.ru. Либо у РТ нет своего CA, либо они им не рискуют.
Отправка URL и Host разными пакетами.
Можно просто сначала вызвать send для первой строки запроса (HTTP-метод и URL), а затем обычным образом отправлять остальную часть запроса.
Никак. Когда они залазят в https, пользователи видят в браузерах сообщение о подмене сертификата.
Они несколько раз включали такой механизм для https-сайтов из реестра, потом отключали.
Тут я несколько иное описал — подробное изучение конкретного метода блокировки у конкретного провайдера (одного из крупнейших в РФ). И выводы о способах его обхода.
Вода действительно везде питьевая, если не указано иное. Иногда хлорированная правда. Пил эту воду две недели, литрами, проблем не было.
Автору: вот этому условию
стоимостью проживания, которая бы не превышала привычную мне в Питере
Израиль скорее всего не удовлетворит. Там довольно дорого. К примеру проезд на автобусе по городу 6,90 шекелей, что по нынешнему курсу больше 80 руб. При этом все города небольшие, например Тель-Авив пешком можно пройти весь.
Примерно такого порядка и все остальные цены.
Странно, что один из самых дорогих (если не самый дорогой) сервисов популярнее остальных.
Раньше Яндекс.Деньги еще и по качеству и скорости обслуживания уступали конкурентам, сейчас не знаю, давно не пользовался.
Тарифы, как я вижу, так и остались выше, чем у конкурентов.
И в статье все-таки не хватает банковских сервисов — Qiwi, кошелек ТКС, кошелек ПСКБ. По ним нет возможности получить отчетность?
Забавно, один закон обязывает популярных блогеров размещать персональные данные, а другой запрещает делать это на зарубежных серверах.
Впрочем, другой еще не вступил в силу.
Это может быть выгодно только при условии, что потом можно найти применение самим Яндекс.Деньгам.
Превратить их в живые деньги будет стоить +3%, итого 5%, что очень дорого. Или есть более выгодные способы? Карта Яндекс.Денег — это не живые деньги.
Да и непонятно поддерживает ли их интерфейс оплаты мультиязычность. Выбора языка там нигде не видно. Вряд ли в Чехии будет удобен русскоязычный интерфейс)
Этот продукт и не пытается заявить о себе, как о серьезной многофункциональной CRM.
Тем не менее, эта система позволяет организовать удобное хранение всех необходимых данных, а пользователю не составит труда разобраться в интерфейсе.
Программист же может рассматривать ее как достойный фреймворк для собственных разработок, для этого я и попытался описать ее архитектуру.
65536 это лишь размер кэша, но не время кэширования.
Сначала приходит пакет, в котором только HTTP 302 и Location, затем приходит пакет с нормальным ответом сайта.
Однако система не отбрасывает второй пакет, а своеобразно объединяет с первым.
Т.е. приходят пакеты
Это наблюдается и в Windows и в Linux.
Но приведенное вами правило действительно решает вопрос.
Добавлю в пост :)
Без кэширования DNS происходило бы следующее:
— пришел запрос на www.example.com/, дернули DNS, только после получения ответа DNS можем обрабатывать запрос
— пришел запрос на www.example.com/scripts.js, дернули DNS, только после получения ответа DNS можем обрабатывать запрос
— пришел запрос на www.example.com/style.css, дернули DNS, только после получения ответа DNS можем обрабатывать запрос
и т.д.
Очевидно, что даже при наличии локального DNS вносятся заметные задержки.
HTTP Keep-Alive конечно сгладил бы негативный эффект, но не отменил бы его.
Вообще в данном случае прокси, кэшируя DNS, делает тоже самое, что и браузер.
При работе через прокси браузер не посылает DNS запросы, это делает прокси.
Поэтому и кэшировать DNS тоже должен прокси.
Что касается TTL, то я уверен, что 3proxy (как и браузер) учитывает его в алгоритме кэширования.
А в чем вообще проблема с кэшированием в данном случае? Это же собственный прокси для собственного серфинга. Без использования прокси тоже самое кэширование DNS делает сам браузер.
Ну или попробуйте разные описанные варианты, в частности передачу заголовка Host в отдельном пакете.
Ростелеком, когда начинает лезть в https, подписывает все своим собственным сертификатом, выданным для *.rt.ru. Либо у РТ нет своего CA, либо они им не рискуют.
Они несколько раз включали такой механизм для https-сайтов из реестра, потом отключали.
Если плагины имеют права на модификацию заголовков, то это возможно. В таком случае и прокси не понадобится.
До сих пор никак не могу отвыкнуть от от Shift+Insert :)
Вода действительно везде питьевая, если не указано иное. Иногда хлорированная правда. Пил эту воду две недели, литрами, проблем не было.
Автору: вот этому условию Израиль скорее всего не удовлетворит. Там довольно дорого. К примеру проезд на автобусе по городу 6,90 шекелей, что по нынешнему курсу больше 80 руб. При этом все города небольшие, например Тель-Авив пешком можно пройти весь.
Примерно такого порядка и все остальные цены.
Раньше Яндекс.Деньги еще и по качеству и скорости обслуживания уступали конкурентам, сейчас не знаю, давно не пользовался.
Тарифы, как я вижу, так и остались выше, чем у конкурентов.
И в статье все-таки не хватает банковских сервисов — Qiwi, кошелек ТКС, кошелек ПСКБ. По ним нет возможности получить отчетность?
Как описано здесь habrahabr.ru/post/228617/
Впрочем, другой еще не вступил в силу.
Превратить их в живые деньги будет стоить +3%, итого 5%, что очень дорого. Или есть более выгодные способы? Карта Яндекс.Денег — это не живые деньги.
Да и непонятно поддерживает ли их интерфейс оплаты мультиязычность. Выбора языка там нигде не видно. Вряд ли в Чехии будет удобен русскоязычный интерфейс)
Тем не менее, эта система позволяет организовать удобное хранение всех необходимых данных, а пользователю не составит труда разобраться в интерфейсе.
Программист же может рассматривать ее как достойный фреймворк для собственных разработок, для этого я и попытался описать ее архитектуру.