frssoft-site/RU/articles/2023-01-14_64kbps.gmi
2023-08-08 14:15:17 +03:00

52 lines
9.2 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# "Замеры" жизни под 64 kbit/s интернетом основанные на личном опыте
Поправка: Скорость не постоянная. В среднем 5-6 Кбайт/с на самом деле.
Поправка 2: Отдача 32 kbit
В общем, шёл 14 день, как я выживаю на медленном интернете, в виду финансовых проблем (и не только). Такой интернет примерно симулирует олдовый средний интернет через dial-up модем.
=> gemini://gemi.dev/cgi-bin/wp.cgi/view/ru?Коммутируемый+доступ Немного о скоростях dial-up на Gemipedia
В целом, 64kbps в современном вебе просто уже с трудом справляется, вероятность что, что-то отвалится по таймауту довольно высока, особенно при активной параллельной загрузке, пожалуй просто приведу список, как ведет себя что-либо при такой скорости (возможно будет пополняться).
___
Обычные сайты "большого" веба - весьма всё плохо, если зайти на сайт с отключенными картинками, можно успеть выпить чашку чая пока он загружается... Если отключить вообще всё, кроме стилей, то уже намного лучше, но потребуется от 10 секунд. С сжимающими прокси загружаются гораздо лучше, у многих сайтов не минифицирован JS и CSS, так же редка поддержка сжатия brotli на серверах, да и на клиентских браузерах не всегда присутствует\запрашивается.
Сайты смолвеба (HTML) - открываются довольно шустро, даже в links они открываются быстрее (а, он умеет прямо на лету отображать загружаемый html).
RSS (XML) - same смолвеб, исключая длинные фиды
gemini/gopher/finger - открываются почти нативно без ожидания, ну оно и понятно, голый текст в основном, но думаю с сжатием они бы открывались вообще на скорости ракеты! Правда вот gemini из-за шифрования TLS открывается несколько дольше, но это в целом про любой обмен данными, где нужно дополнительно сделать секьюрити рупожатие и обменяться ключами.
I2P - Для работы необходимо поставить в конфигах самый минимальный bandwidth 32 kbps, иначе он съедаёт всю скорость канала и сам же отваливается. Первичная инициализация может быть _значительно_ дольше. Когда роутеров достаточно и i2pd уже проинициализован, не все ноды открываются сразу, нужно "пнуть" соединение с i2p сайтом несколько раз, предварительно подождав минуту-две. В целом, сайты могут открываться, но я очень рекомендую отключить вообще все плюшки и делать это через консольные браузеры. Стриминг (i2p радио) на такой скорости просто отваливается по таймауту или EOF. Проблема в основном с коннектом к outbound tunnels, многие из них failed. Так же, пользоваться клирнетом, пока I2P включен не выйдёт - будет отвал по таймауту.
Yggdrasil v4 - очень нестабильно, но относительно (значительно быстрее I2P) быстро работает. Довольно легко теряются соединения с пирами.
ssh -C - работает, иначе как бы я юзал пабникс? :) Но, есть парочка нюансов, если вдруг из output полезет гора текста в терминал, то можно довольно долго наблюдать, пока он его весь выведет. Ввод очень сильно лагает (сказывается скорость 32 кбита на аплинк), особенно если параллельно программа выводит какие-то изменяющиеся данные, буквально ~1 секунда на символ.
git clone; git push - работает вполне сносно, разве что git clone на больших репозиториях стоит выполнять с --depth 1. А коммиты посылать мелкими порциями, а не одним огромным, хотя git всё равно пакует в один архив при отправке\получении.
Pleroma/Mastodon и другие JSON API\ActivityPub (Get) - работает вполне неплохо (+ сжатие), но response довольно долгий, а вот их оригинальные вебни в основном не предусматривают использование такого медленного коннекта, но думаю, если сравнивать с тем, что есть у централизованных сервисов, эти вебни будут меньше
Matrix - работает, но сообщения долго отправляются иногда, так же вероятность словить "Матрикс момент" (с), связанный с тем, что сообщение пришло, а ключей к нему нет для расшифровки повышается в разы
Jabber/IRC/netcat chat/others text messengers - работают нативно, как раз были созданы в условиях низкоскоростных передач :)
Jitsi Meet - присоединяется к конференции (если это приложение, в случае вебни придётся ждать вечность), но не юзабельно: от собеседников слышно примерно часть от одного слова, а на отправку примерно так же. (Естественно, audio-only)
Mumble - Работает на самом низком пресете качества. Присоединяется к комнате, собеседников слышно через слово, возможно если попросить их убавить у себя качество, то будет нормально. Переодически возможны переподключения. Чат стабилен.
HedgeDoc - После ожидания минут 4-5 страница с колабаративным документом таки загрузится, в принципе работает, но довольно сильно пролагивает, быстро редактировать документ не получится вместе.
OpenStreetMap - Медленно, но работает, на такой случай лучше использовать оффлайн карты
Любая не сжатая медиа - долго, можно сразу поставить на загрузку и пережидать прогон мегабайтов по кбитному каналу в IRL (попить чай не спеша например)
Аудио пожатое (mono) - 8kbps, 16, 32 => fine, pretty good; 64 => работает, но с всё таки прерываясь на пределе в буферизацию
Видео пожатое - HEVC 128x96 с битрейтом в 64, 12 кадров в секунду, работает, но смотрибельность оставляет желать лучшего, если вы любитель высококачественного и владелец мониторов высокого разрешения.
У обоих пунктов выше, желательно при реалтаймовой передаче использовать mpegts с модифицированным размером пакета, например -ts_packetsize 1024, но я пока не уверен помогает ли это. Вот, для примера можете посмотреть скрипты [CGI], для перекодирования с помощью ffmpeg
=> https://gitea.phreedom.club/localhost_frssoft/transcoders_cgi.git [CGI]
___
=> .. back