pozitronik: (Default)
[personal profile] pozitronik
Интересную штуку заметил. Ну то есть как заметил - присутствует она уже сто тысяч миллионов лет.

Если выходить в ЖЖ не через телефон (т.е. через спутник, 3G модем, проводного/беспроводного провайдера или даже напрямую врубая шнурок в магистральный маршрутизатор) - оно работает нормально. Если выходить через телефон (т.е. с телефона напрямую, или любым из возможных способов используя его в качестве точки доступа) - в жежешке не грузятся CSS и JS. Отчего выглядит жежешка... ну вы и сами можете посмотреть, отключив в браузере то и другое самостоятельно.
Единственный вариант объяснения, который мне приходит в голову такой: GGSN (или SGSN, я их путаю) отдаёт, кроме всего прочего, информацию о абонентском терминале - это не баг а фича. Передаются, например, параметры экрана терминала и даже его модель, чтобы сервер мог выдать подходящую страничку. Вообще может отдаваться почти абсолютна вся информация, от местоположения терминала, до его MSISDN - всё зависит от настройки. И абонент этому помешать не может ровно никак, никакие маскировки браузеров и прочее тут не помогут.
Вот и получается, что жежешка подсовывает мне какую-то недоделанную мобильную версию, считая, что я читаю её на мобильнике. То, что мобильники уже давно имеют параметры круче, чем мой первый компьютер когда-то, не учитывается.
Энивей, косяк жеже. Остальные сайты либо вполне корректно обрабатывают информацию о терминале, либо смотрят на версию браузера, либо предлагают выбрать мобильную/десктопную версию вручную.
Вот такие дела.

Date: 2011-12-28 11:23 am (UTC)
From: [identity profile] konstpaus.livejournal.com
у меня, например, каменты не постятся через мобилу

Date: 2011-12-28 06:55 pm (UTC)
From: [identity profile] dibr.livejournal.com
Уровни протоколов не сходяццо: "информацию о терминале" может выдать браузер внутри http, но не любое из "каналообразующего оборудования" по tcp/ip - там просто нет под это места. То есть, если браузер в телефоне - он 99% что сообщает "я маленький и мобильный, сильно не нагружайте", но если браузер - в компьютере, а телефон и всё то, что за ним - просто среда передачи данных, сервер ЖЖ не может знать, что где-то по пути трафика приблудилась мобила, и должен отдавать стандартную страницу.

Подозреваю, что имеет место банальная неустойчивость работы мобильной связи, и половина запросов просто пропадает. Если не загрузился основной html - мы нажмём reload, а если один из дюжины css (вероятность чего выше) - будем наблюдать разнообразные глюки отображения страницы...

Date: 2011-12-28 07:50 pm (UTC)
From: [identity profile] pozitronik.livejournal.com
Ты не уловил мысль.
Ни браузер, ни компьютер в определении мобильности устройства роли не играют в данном случае. Информацию отдаëт именно оборудование опсоса, уж мне-то можно поверить. Вот на каком точно уровне оно отдаëтся - это уж я не помню, если kam_alex подтянется в комменты - может расскажет.

Не важно, в какой роли выступает мобильник, он всë равно есть суть модем, и оборудование опсоса всегда будет отдавать инфу о нем, как о мобиле.

Устойчивость канала тут тоже не при чëм - я свободно смотрю с мобильника ютубы и километровые котопосты на дëти. Это именно косяк жеже.

Я бы мог проверить это, загрузив страничку через мобильник и через модем, а потом сравнив загруженное. Но мне лень перетыкать симку.

Date: 2011-12-28 08:09 pm (UTC)
From: [identity profile] dibr.livejournal.com
> Информацию отдаëт именно оборудование опсоса

Отдаёт, прости, кому? Соседнему оборудованию опсоса? Да и пусть его отдаёт, это их личные половые трудности. Засовывает в ip-пакеты? Так там некуда, "когда коран писали, минных полей не было", нету в tcp/ip никаких "признаков мобильности", а между опсосом и жежешечкой - ещё несколько узлов "обычных провайдеров", со своими, традиционными, канальными протоколами - неизменным до сервера долетит только ip и всё что выше. Модифицирует http-трафик? Теоретически такое возможно (transparent proxy), практически - маловероятно, ибо во-первых нафиг не сдалось опсосу, а во-вторых - когда более-менее серьёзного провайдера ловят на transparent proxy или иной модификации tcp-трафика - об этом громко и шумно шумят (потом, правда, забывают - до следующего эпизода).

> Я бы мог проверить это, загрузив страничку через мобильник и через модем, а потом сравнив загруженное. Но мне лень перетыкать симку

Беглый поиск по "просмотр http заголовки" дал вот этот сервис:
http://http.foxtools.ru/
Там можно посмотреть, что было в http-запросе, видимом сервером. Все нижележащие протоколы (tcp/ip и всё что под ними) - во-первых, веб-сервер не интересуют: с его точки зрения они просто доставляют ему байтики, а во-вторых - один фиг не содержат "информации о терминале": даже если она передаётся внутри опсоса, она будет обрезана при переходе трафика к "обычному" провайдеру.

Date: 2011-12-28 09:15 pm (UTC)
From: [identity profile] pozitronik.livejournal.com
Самостоятельная попытка разобраться навела на яндексовские инструменты определения параметров мобильного устройства, однако там написано, что анализируются заголовки запросов, передаваемые браузером. А я почти уверен, что данные таки модифицируются железом опсоса. Могу быть не прав, а могу быть и прав. Лекцию о том, как устроены мобильные интернеты я слушал пару лет назад, и поскольку это не мой основной профиль - здорово подзабыл тонкости. Возможно, речь шла о модификации HTTP-заголовков только для WAP.
При случае спрошу наших инженеров.

Тем не менее, факт остаётся фактом: при использовании мобильника жежешка часть файлов не отдаёт.

Date: 2011-12-28 09:53 pm (UTC)
From: [identity profile] dibr.livejournal.com
Ну, это же проверяется за пять минут. Сейчас нашёл в интернетах код на php, дампящий содержимое заголовка http-запроса, загрузил себе на сайт (http://dibr.nnov.at/dump.php). Дальше надо зайти на эту страницу через нормальный интернет, и через мобильный, и сравнить результат. Если разницы не видно - значит и сервер её не видит.

Код взял вот отсюда: http://blog.tonycode.com/tech-stuff/http-notes/dumping-http-headers - первый попавшийся по "php dump http header".

Date: 2011-12-28 10:01 pm (UTC)
From: [identity profile] pozitronik.livejournal.com
Я мозгами понимаю, что если информации нет в http-хидерах (а её там нет), то как-то ещё инфу передавать проблематично. Не невозможно, конечно, но всё равно другие способы неудобны.

Но меня всё равно смущает: а) слышанное на лекции б) отсутствие других внятных объяснений, почему через телефон качается одно, а любым другим способом - другое.

Date: 2011-12-28 10:31 pm (UTC)
From: [identity profile] dibr.livejournal.com
Неудобно - это фигня. Не фигня то, что кроме хидеров на этом уровне есть разве что "тело" запроса (get-строка, какие-нибудь пользовательские данные, передаваемые через post), но это не те данные, которые можно так вот влёгкую модифицировать, не сломав при этом половину интернета (это пользовательские данные, не "служебные", там может оказаться что угодно в любом формате). Поэтому в модификацию заголовков я бы ещё кое-как поверил (в конце концов, прокси-серверы заголовок модифицируют вполне штатно, и существуют "прозрачные прокси"), а вот в модификацию "контента" - не верю :-)

А всё, что ниже tcp - для веб-сервера не существует: для него это просто "труба для перекачки байтиков", с базовыми свойствами и методами "трубы" (открыть-закрыть, читать-писать, успех-ошибка, есть соединение - разрыв соединения), и без каких-либо дополнительных свойств.

Date: 2011-12-30 12:14 pm (UTC)
From: [identity profile] pozitronik.livejournal.com
Итак, я только что поговорил с нашим инженером. Он полностью подтвердил мою догадку насчёт того, почему жежешечка отдаёт мне на телефон всякую херню.
Теперь немножечко технической инфы, которая ещё не успела испариться из моих мозгов (если что-то навру - побейте меня через TCP/IP).

Итак, весь траффик WAP/GPRS идёт через особые прокси. Для WAP это wap-proxy, для GPRS - PTPT (Packet Trafic Tarification Platform). Для разъяснения нашего случая можно считать эти узлы логически идентичными.
При аутентификации и создании сессии на эти прокси передаётся информация по абоненту (RADIUS Accounting), которая там и хранится до завершения сессии и отдаётся запросившему серверу (если для этого сервера есть разрешение на передачу данных).

(Вот тут я могу неправильно пересказать - инженер ехал в машине и говорил по hf, временами было плохо слышно, плюс я тупой).

Перед каждым GET-запросом, исходящим от абонента, прокси вставляет свой собственный GET-запрос, типа "а поддерживаешь ли ты мобильные профили?". Если в ответ приходит "Окей, конечна поддерживаю!" в следующий GET (уже тот, который делал пользователь) добавляется заголовок client-profile (у WAP и GPRS они различаются) с данными об абонентском терминале.

Гугленье по умным словам инженера дало мне ссылку на книжку "Mobile Web Services", по ссылке как раз идут картинки с описанием происходящего. Правда, в доступном превью изъяты странички, а само описание приведено для WAP, но логику процесса книжка вполне подтверждает.

Date: 2011-12-30 12:36 pm (UTC)
From: [identity profile] dibr.livejournal.com
О как. То есть, раз мой dump.php не ответил на (невидимый мне) запрос о мобильных профилях, то ему и заголовок client-profile не подсунут, потому я его и не вижу?

В-общем, это конечно "многое объясняет", но на эту тему есть у меня сомнения. Которые, впрочем, не так сложно проверить - модифицировав dump.php так, чтобы он сливал в логи на сервере все запросы, а потом посмотрев, не было ли "лишних" get-запросов :-)

Не факт что успею проверить сегодня, но в каникулы проверю обязательно :-)

Date: 2011-12-30 12:45 pm (UTC)
From: [identity profile] pozitronik.livejournal.com
>модифицировав dump.php так, чтобы он сливал в логи на сервере все запросы
А разве dump.php надо модифицировать? Что если дальше самого веб-сервера в php-либу этот запрос и не уходит(может быть глупость сказал, не знаю, как оно устроено)?

Date: 2011-12-30 02:23 pm (UTC)
From: [identity profile] dibr.livejournal.com
Утверждается (и я хочу это проверить), что:
1. опсос получает от клиента get-запрос на сервер
2. опсос делает серверу _свой_ get-запрос вида "умеешь ли по-мобильному"
3. опсос получает от сервера ответ
4. если получен ответ "да, умею по мобильному" - к запросу клиента пририсовывается "...и всё это - для мобилы!", если получен ответ "чё??" - запрос клиента передаётся as is, без изменений.
5. ответ сервера отдаётся клиенту

При этом:
- веб-сервер видит оба запроса (от опсоса и от клиента)
- если на первый запрос (опсоса) сервер ответил "чё??" - второй запрос идёт as is
- клиент видит ответ только на свой запрос, и если он не модифицирован - то и ответ, очевидно, не модифицирован.

А значит:
- если первый запрос есть, сервер обязан его увидеть (и передать тому "шкрипту", который генерирует странички - это "шкриптовое" дело, генерировать разные страницы для разных клиентов/запросов, сервер сам может отдавать только статику, а это неинтересно). Модифицировав dump - мы сохраним этот запрос
- если на первый запрос нет явного ответа "да, я умею по-мобильному" - во втором запросе, ответ на который мы видим, строки "...мне для мобилы" не будет, соответственно при тесте мы его и не увидим.

Правда, есть нюанс: первый запрос может быть не на dump.php, а на какой-то другой файл/скрипт (допустим, на "корень", то есть index.html). Тогда запрос будет, но dump.php его не увидит. Но тогда можно попробовать модифицировать index.html...

Date: 2011-12-30 02:44 pm (UTC)
From: [identity profile] pozitronik.livejournal.com
Проверяем (я на своём сервере попробую тоже). Ежели ничего не получится - я после январских каникул ещё порасспрашиваю, может это я чего не так понял.

Date: 2011-12-30 08:15 pm (UTC)
From: [identity profile] dibr.livejournal.com
Сделал на dibr.nnov.at dump2.php (дописывает в лог) и dump3.php (выводит содержимое лога после чего стирает лог). При запросе страницы с ноута через мобильный модем в логах оказался один запрос.
Но! Это ничего не значит - опсос может запрашивать index.* (который я трогать не хочу), или какой-то специально выделенный для этого адрес.
Если есть машина с "белым" ip - на неё можно быстренько водрузить простенькую прокси в режиме форвардинга портов, перенаправить её на www.livejournal.com, в hosts у себя прописать адрес прокси как адрес для www.livejournal.com, и посмотреть, что будет в логах прокси. "Белый" ip у меня есть только на рабочей машине (и то не уверен, что там всё не зафайрволлено снизу доверху), а на работе я окажусь уже только после каникул, так что проверю не скоро.
Но тема интересная, если и правда выяснится, что опсосы меняют заголовки проходящего мимо них http - это будет очень, эээ, любопытно :-)

Date: 2011-12-30 09:19 pm (UTC)
From: [identity profile] pozitronik.livejournal.com
Это ещë ничего не значит потому, что ты использовал, как я понимаю, именно мобильный модем. А на радиусе с 99% вероятностью настроено так, чтобы не считать модем мобильным устройством, способным к отображению страничек. У меня, по крайней мере, на модеме с той же симкой грузятся нормальные страницы.
Попробуй загрузить скрипт с телефона, либо я могу, но уже когда приду в себя.

Date: 2011-12-30 09:45 pm (UTC)
From: [identity profile] dibr.livejournal.com
Да без проблем. Подключился ноутом через телефон (телефон не "модемом", а через "общий доступ к интернет", то есть с точки зрения опсоса - это именно телефон вышел в инет, а не кто-то вышел в инет "телефоном"). Один запрос, никаких "мобильностей".

Вышел браузером телефона (опера мини). Один запрос, из мобильностей - user-agent=опера_мини, и две строки вида x-operamini-xxxx=yyyy.

В-общем, опять ой. Нужен решающий эксперимент с белым ip и портмаппером :-)

Date: 2011-12-28 07:05 pm (UTC)
From: [identity profile] sreversor.livejournal.com
А ты каким браузером пользуешься?

Date: 2011-12-28 07:51 pm (UTC)
From: [identity profile] pozitronik.livejournal.com
Только telnet, только молодость!

Date: 2011-12-29 11:13 am (UTC)
From: [identity profile] sreversor.livejournal.com
Купи себе белый IP на свой комп и читай ЖЖ-шку через RDP-клиент на паде. Немного извратно, но будет работать на 146%.

December 2016

S M T W T F S
    123
45678910
1112131415 1617
18192021222324
25262728293031

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 18th, 2025 11:21 am
Powered by Dreamwidth Studios