52 lines
9.2 KiB
Plaintext
52 lines
9.2 KiB
Plaintext
|
# "Замеры" жизни под 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
|