frssoft-site/RU/articles/2023-01-14_64kbps.gmi

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