first connection thru http / https #56
Comments
Нету. |
Плохо, но это же возможно реализовать? Ведь так? |
Браузер ожидает работу по протоколу http. Если по пути протокол изменится на https, ничего хорошего не произойдёт К тому же youtube при подключении по http редиректит подключение на https, что у вас и происходит в первом логе Что именно не так? |
Логика хождения пакетов в достаточной степени мне понятна чтобы делать логические умозаключения ) И поясняю, что мне не нравится
И для пояснения между accept: fd=5,6 и accept: fd=7 ожидание редиректа от 108.177.14.198:80 около 20 секунд и да дальше хост редиректит на 142.250.150.198:443 ... те пакет то для браузера с редиректом приходит, только ciadpi не сообщает браузеру об этом никак и он, браузер так и висит в мучительном ожидании. Т.е - сама ciadpi , предположительно, этот момент некорректно отрабатывает или чето-то по настройкам не монимаю и этот моент как то можно обойти, но разраб ответом выше же сказал, что нет такой возможности ) Я почему просто так "настаиваю", smarttube, иного просто не знаю, единственное приложение с наличием вкладки настроек proxy без root и дополнительных приложений, требующих этот самый root и, самое забавное, при встроеном тесте в smarttube, после указания настроек proxy, ciadpi отрабатывает корректно Но, в этом случае идет прямая указка при отправке пакетов на https, но дальше )))) Дальше старые песни о главном....ни видео ни корректно отрабатываемых соединений. Те, получается, что ciadpi работает только и исключительно с браузером и то только при явном указании (use https only) |
Есть такой вариант - при получении HTTP-запроса не давать ему дальнейший ход, а отправлять на клиент редирект на HTTPS |
Подампил я из интереса трафик, воспроизвёл ситуацию - и нет, ответ не приходит. Сервер не отвечает на фрагментированный http GET. И виноват в этом disorder, так как со split сервер отвечает Иными словами, в вашем случае может помочь замена на split
Или вам нужно именно отдельное приложение для youtube'а? Если да, то поделитесь, зачем, если не секрет? |
Благодарю за тыканье носом ) Смена split немного уличшила ситуацию и теберь в браузере - да, все редиректиться должным образом, но ... smarttube даже начал что то прожевывать, но ... |
|
Судя по коду, подобные ситуации должны нормально обрабатываться. Как это проявляется для конечного пользователя? Вообще вы можете попробовать снять дамп до bydpi и после, он может что-нибудь прояснить |
192.168.0.1 это android tv + smarttube за пределами хоста с docker Просто tcpdump'ом логнул |
Жестоко конечно. Опция -w всегда предпочтительнее Пока могу сказать только то, что в дампе я так и не нашёл фрагментации пакетов (скорее я не нашёл, нежели её нет, но не факт), и подозрительно большое количество некорректных чексумм (что может быть косяком tcpdump) Ну и таки вы на самый интересный вопрос не ответили - как это проявляется у пользователя? |
Это потому, что сам docker на linux машине крутится, а в нее прокинут физический сетевой адаптер из основной системы и некогда мне было на тестовой машине gro offload на адаптере крутить, но это ни на что не влияет, те до применяемого DPI со стороны провайдера эта машина эти же функции исправно выполняла.
А у пользователя в браузере все исправно работает, а при использовании smarttube нет видео и ролики загружаются фрагментарно, не воспроизводятся, могут подгрузиться и тишина или подргужаются, и на буфферизации снова ресетятся при этом в логах bydpi это все сопровождается изрядным количеством нижеуказанных ошибок. При этом, ограничение длинны пакета в самой bydpi до, как в текущем примере, 4096 байт ни на что не влияют |
Буфер сокета заполнен, это может значить, что клиент/сервер медленно читают данные или есть проблемы с сетью, ничего критичного.
Это может быть связано с борьбой Google со сторонними загрузчиками. |
Не знаю насчёт smarttube, но в случае с браузером это Гугл рукожоп... В случае с браузером решение заключается в том, чтобы включить настройку "Всегда использовать безопасные соединения" в |
Может я кривосмотрящий, но тогда с легкостью можно закрыть данный реквест.
Если браузере или smarttube указать socks 5 и ... ничего не делать, просто вбив или попробовав указать youtube.com, то сначала оба лезут по умолчанию на 80, а не на 443 и получается следующее
Но стоит ручками указать https:// .... и тут же пошло все по трубам ютюба )))
Есть ли какая либо возможность подставлять изменять автоматом приходящие http на https в самом бинарнике, а не руками потому, что в браузере да, не развалюсь, но вот тот же smarttube заставить делать иначе не получается, а такое у самой прокси похоже потому, что при http - > new conn: fd=6, addr=64.233.165.198:80 ... и отсюда, похоже, редирект на new conn: fd=16, addr=173.194.221.198:443 .... а в таком случае у многих, кто не далек от темы "не будет работать"
The text was updated successfully, but these errors were encountered: