Я «товарищ из региона».
У нас тут и большая тройка, и Yota — все с 4G.
Вообще если посмотреть карты покрытия, то 4G есть во многих регионах, причем не только в областных центрах.
На самом дело вполне реально для нормального фрилансера.
Под «нормальным» понимаю достаточный опыт фриланса в целом и достаточный опыт в своей специализации.
Реально необходим только более-менее нормальный письменный английский, без этого будет сложно. С разговорным английским конечно будет комфортнее и больше доступных заказов, но он не является необходимостью.
С индусами конкурировать не нужно, Азия — сама по себе, Восточная Европа — сама по себе, это разные категории фрилансеров, работающие с разными категориями заказчиков.
Это из личного опыта. Я — среднестатистический фрилансер с fl.ru. Просто пришел на odesk и начал оставлять заявки. Все как на обычной бирже — несколько дешевых заказов, первые отзывы, потом уже не проблема брать нормальные проекты, приходят приглашения в проекты и т.д.
Израиль, аэропорт Бен-Гурион.
Wi-Fi свободный и бесплатный, скорость нормальная.
Розетки можно найти на стенах, персонал не возражает по поводу их использования.
Когда-то искал наиболее выгодный вариант среди приличных. Им оказался onpay.ru.
Пользуюсь до сих пор в нескольких проектах.
Не реклама, я реальный пользователь.
Действительно, есть ретрансмиссия. Я смотрел трафик, но очевидно недостаточно внимательно.
Сначала приходит пакет, в котором только 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-сайтов из реестра, потом отключали.
Тут я несколько иное описал — подробное изучение конкретного метода блокировки у конкретного провайдера (одного из крупнейших в РФ). И выводы о способах его обхода.
А в чем проблема класть зарядное устройство на 2 А?
У нас тут и большая тройка, и Yota — все с 4G.
Вообще если посмотреть карты покрытия, то 4G есть во многих регионах, причем не только в областных центрах.
Под «нормальным» понимаю достаточный опыт фриланса в целом и достаточный опыт в своей специализации.
Реально необходим только более-менее нормальный письменный английский, без этого будет сложно. С разговорным английским конечно будет комфортнее и больше доступных заказов, но он не является необходимостью.
С индусами конкурировать не нужно, Азия — сама по себе, Восточная Европа — сама по себе, это разные категории фрилансеров, работающие с разными категориями заказчиков.
Это из личного опыта. Я — среднестатистический фрилансер с fl.ru. Просто пришел на odesk и начал оставлять заявки. Все как на обычной бирже — несколько дешевых заказов, первые отзывы, потом уже не проблема брать нормальные проекты, приходят приглашения в проекты и т.д.
Wi-Fi свободный и бесплатный, скорость нормальная.
Розетки можно найти на стенах, персонал не возражает по поводу их использования.
Пользуюсь до сих пор в нескольких проектах.
Не реклама, я реальный пользователь.
Например к API Google AdWords получить доступ сложнее.
Запретим ножи?
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-сайтов из реестра, потом отключали.