[Перевод] Ужасы работы с Интернетом в Антарктиде (и как это исправить), часть 1
Часть этого поста я написал, всё ещё находясь в Антарктиде, но уеду, ещё не закончив его.
Я просматривал свои старые черновики постов и понял, что этот почти завершён.
Надеюсь, читателям покажется интересным этот беглый взгляд на реальный опыт пользования Интернетом в условиях ограниченной полосы пропускания.
В течение 14 месяцев работы в Антарктиде доступ в Интернет у меня был только через крайне ограниченное число спутниковых каналов, предоставленных Антарктической программой США (United States Antarctic Program).
В начале поста нужно дать особое примечание:
Хотя я был ИТ-сотрудником United States Antarctic Program, всё, о чём я буду говорить в этом посте, основано или на публично доступной информации, или на моих личных наблюдениях как обычного участника программы, живущего во льдах.
При написании поста не использовалась информация с ограниченным доступом и непубличная информация.
При приёме на работу я подписал условия, ограничивающие публичное раскрытие непубличной информации о материалах, связанных с информационными технологиями. Я намерен полностью соблюдать эти ограничения. Такие ограничения типичны для сдельной работы на правительство США.
Маловероятно, что я смогу ответить на дополнительные вопросы по темам, обсуждаемым в этом посте. Я тщательно старался писать максимально подробно, не допуская при этом раскрытия непубличной информации о правительственных ИТ-системах.
Данная информация отражает мой личный опыт нахождения в Антарктиде с августа 2022 года по декабрь 2022 года в Мак-Мердо, а затем с декабря 2022 года по ноябрь 2023 года на Южном полюсе.
Технологии быстро развиваются, поэтому я не буду заявлять, что обстоятельства моего конкретного опыта будут актуальны всегда. В будущем, когда я уже давно забуду об этом посте, не сердитесь на меня за то, что реальный опыт ИТ в Антарктиде будет отличаться от представленного в статье.
Отлично, а теперь приступим к делу.
Начнём с того, что даже получить хоть какой-то Интернет на Южном полюсе — это нетривиальная инженерная задача! Если вам скучно, почитайте страницу South Pole Satellite Communications на публичном веб-сайте USAP.gov, чтобы узнать об ограниченном количестве спутников, доступных для применения на полюсе.
Обтекатели антенн на Южном полюсе. В этих обтекателях содержится всё оборудование, необходимое для общения с внешним миром через наши первичные спутники.
Если вам любопытно, можете изучить и Antarctic Subsea Cable Workshop 2021 года, чтобы в общем виде понять трудности, связанные с прокладыванием традиционного оптоволокна на континент.
Должен сказать, что не обладаю никакими полномочиями, чтобы рассуждать о перспективах связи в Антарктиде! Серьёзно, я был низкоуровневым сезонным ИТ-сотрудником в крупной сложной организации. Не пишите мне письма с предложениями совершенствования доступа к Интернету в Антарктиде, я не в той должности, чтобы что-то с этим сделать.
Я согласен с консенсусом по этому вопросу: существует огромный интерес в улучшении связи с американскими исследовательскими станциями в Антарктиде. Я могу лишь выдвинуть робкую гипотезу, что рано или поздно найдутся инженерные решения этих проблем. Когда-нибудь в Антарктиде появится более совершенная связь или благодаря улучшению спутниковых технологий, или посредством прокладки на континент оптоволокна.
Но такая ситуация сложится лишь в будущем. На настоящий момент связь в Антарктиде крайне ограничена. Что я под этим подразумеваю?
До очень недавнего времени почти тысяча людей в Мак-Мердо плюс множество научных проектов и операционных нагрузок зависели от группы каналов, представлявших всей станции суммарную скорость лишь в несколько десятков мегабитов в секунду. Для сравнения: общая для всех полоса пропускания на полюсе меньше, чем у одного человека, подключенного к стандартной 4G-сети в городской части США.
Однако ситуация улучшается! Недавно Национальный научный фонд (NSF) объявил о важных разработках на Мак-Мердо и Палмере, касающихся Starlink.
Я в курсе, что реальная ситуация со связью на Мак-Мердо и Палмере сейчас лучше, чем была даже год назад.
Но на октябрь 2023 года ситуация на Южном полюсе была довольно отчаянной. Насколько я знаю, о похожих разработках касательно Starlink пока не было заявлено для станции на Южном полюсе.
На октябрь 2023 года на Южном полюсе имелись все эти ограничения плюс связь была доступна лишь на несколько часов в день, когда спутники поднимались над горизонтом и станции позволялось их использовать. Обычно график спутников сдвигается вперёд (на более ранее время) примерно на 4 минуты за день из-за разницы между звёздным и солнечным (поясным) временем.
Текущий график спутников можно найти онлайн на странице South Pole Satellite Communications публичного веб-сайта USAP.gov. Вот пример графика за октябрь 2023 года:
График спутников для Южного полюса на две недели в октябре 2023 года.
Этими маленькими прерывистыми каналами связи с внешним миром пользуются все люди на полюсе для научных, операционных и общественных целей.
Ещё сильнее усложняет ситуацию и неизбежная физика этой связи. Такие спутники находятся на высокой орбите, в тысячах километров. Из-за этого существуют высокие задержки. Если вы пользовались потребительскими спутниковыми тарелками наподобие HughesNet или ViaSat, то вы меня поймёте.
В моём кабинете на Южном полюсе время прохождения сигнала туда и обратно составляло примерно 750 миллисекунд. Это общее время с момента отправки пакета с полюса до попадания пакета в наземную точку США и получения на полюсе. Почти в десять раз больше, чем время перемещения пакетов туда и обратно между Восточным и Западным побережьями США (до 75 мс). И это примерно в тридцать раз больше, чем стандартная задержка нормального домашнего подключения по наземному кабелю или оптоволокну к большинству сетей доставки контента (до 25 мс).
Я не могу передать, насколько это раздражает. В моей собственной городской квартире пакет туда и обратно до Fastly, Cloudflare, CloudFront, Akamai и Google проходит за 3 мс. На Южном полюсе задержка более чем в двести пятьдесят раз больше.
Я не могу вдаваться в подробности того, как USAP реализует приоритетизацию, шейпинг и так далее, потому что не имею права делиться этой информацией. Достаточно сказать, что если вы инженер корпоративной сети, привыкший работать в условиях ограниченных полос пропускания, то с оборудованием, инструментами и методиками управления связью в Антарктиде вы почувствуете себя, как дома.
Любой человек, который попытается подключиться к Интернету для общественного пользования на Южном полюсе на октябрь 2023 года, с большой вероятностью столкнётся со следующим:
Средняя задержка передачи данных туда и обратно примерно 750 миллисекунд с нарушением синхронизации между пакетами иногда на много секунд.
Скорости на конечных устройствах от пары Кбит/с (да, я не опечатался) до 2 Мбит/с в очень хороший день.
Чрезвычайная перегруженность, очерёдность и потери пакетов, намного превосходящие наихудшие характеристики пересыщенных каналов Интернет-провайдеров или переполненных сетевой буферизацией домашних маршрутизаторов в США.
Ограниченная доступность, частые отключения и периодические перерывы на техобслуживание.
Эти ограничения ужасно влияют на процесс пользования современным вебом! Некоторых из них невозможно избежать. Описанные выше характеристики каналов действительно не впечатляют, но в большой степени на конечного пользователя влияет и структура веба и приложений, не учитывающая медленные/прерывистые каналы связи.
Если вы разработчики приложений и читаете это, то можете ли не задумываясь сказать, как будет себя вести ваше приложение на канале с доступной полосой пропускания 40 Кбит/с, задержкой 1000 мс, неустойчивой синхронизацией длительностью до 2000 мс, уровнем потери пакетов 10% и полным отключением связи на 15 секунд через каждые несколько минут?
Вероятно, не особо хорошо! Тем не менее, именно такие реальные условия возникали у меня в определённых обстоятельствах на Южном полюсе. Обычно ситуация лучше, но такое случается, и случается достаточно часто, чтобы воспринимать это серьёзно.
Вот, что происходит, когда у тебя есть узенький канал, который приходится делить с высоко приоритетными операционными потребностями плюс с десятками обычных пользователей. Операционные потребности имеют огромный приоритет, а пользователям приходится собирать оставшиеся крохи.
Я не ожидаю чудес! Разумеется, какие бы гениальные разработки на стороне клиента мы ни создали, они не способны обеспечить в таких условиях, допустим, возможность видеоконференций в реальном времени. Но передавать несколько байтов текста туда и обратно должно быть возможно! Я знаю, что это возможно, потому что некоторым приложениям всё равно удаётся делать это. А другим нет.
Подробный пример из реального мира
Находясь однажды на Южном полюсе, я пытался загрузить в браузере веб сайт <$enterprise_collaboration_platform>. Он огромен! Лишь для рендеринга главного экрана ему нужно загрузить примерно 20 МБ Javascript! И, разумеется, приложение обновлялось с последнего раза, когда я его загружал, поэтому все кэшированные браузером ресурсы уже устарели и их нужно было загружать заново.
Ну ладно, пусть медленно, но рано или поздно он заработает… ведь правда? Браузеры достойно справляются с работой в условиях медленного Интернета. Внутри них протоколы достойно справляются с управлением перегрузками. Я должен получать стабильный ручеёк данных. Он будет подвергаться согласованию окон приёма и передачи между клиентом и сервером, зависящих от текущего уровня забитости канала; также на показатели влияет шейпинг, выполняемый промежуточным ПО.
Это сложное веб-приложение, поэтому разработчику приложения также нужно реализовать собственную логику повторных попыток. Это позволяет восстанавливаться в случаях сбоя отдельных ресурсов, особенно при длинных многосекундных полных разрывах связи. Но рано или поздно, если дать системе достаточно времени, передача должна завершиться.
К сожалению, на этом моменте всё ломается и начинает очень раздражать. Разработчики реализовали где-то в приложении глобальный триггер сбоев. Если приложение не загрузилось в пределах заданных разработчиком параметров (времени? количества попыток? точно я не знаю), то приложение останавливается, сдаётся, перенаправляет пользователя на страницу ошибки, сбрасывает весь прогресс загрузки, а при повторной попытке реализует агрессивные контрмеры, уничтожающие кэш.
Приложение загружалось недостаточно быстро, и разработчики решили, что оно должно сдаться, а не пытаться загрузиться медленно.
Не могу передать, насколько это бесило! Условия связи на Южном полюсе никогда бы не соответствовали ожиданиям инженеров, использующих надёжное наземное Интернет-подключение. Прописывать единственное статическое глобальное значение ожидания загрузки 20 МБ Javascript — плохая идея. Почему бы не позволить мне загружать их в моём собственном темпе? Будет готово, когда будет готово. Как бы медленно ни двигались данные, пока они двигаются, не мешайте им.
Но разработчики решили, что если приложение не загрузилась в рамках заданных ими параметров, то я вообще не могу им пользоваться. И надо сказать, что по большей мере это приложение для обмена сообщениями. Когда приложение запущено и я общаюсь с друзьями, настоящая полезная нагрузка контента измеряется в байтах.
Оказалось, что скорость Интернета на Южном полюсе была ровно на грани того, что разработчики приложения посчитали «приемлемым». То есть если бы я продолжал перезагружать страницу и позволял ей заново скачивать те же 20 МБ Javascript, и если бы я продолжал мириться с уничтожающими кэш фокусами разработчиков, то когда-нибудь всё бы успешно завершилось, не успев добраться до искусственного критерия сбоя.
Из-за всего этого я продолжал тратить лишний трафик на все эти бесполезные перезагрузки, и иногда требовались часы, прежде чем я мог начать пользоваться приложением. Если бы разработчики оставили процесс в покое, то я бы мог завершить передачу всех необходимых данных за 15 минут. Спустя множество часов (и позорного количества попыток перезапуска Javascript) я смог наконец отправить друзьям короткое текстовое сообщение.
Успешная загрузка веб-приложения спустя множество повторных попыток. 809 HTTP-запросов, 51,4 МБ переданных данных и 26,5 минуты загрузки…
…и всё это для того, чтобы я мог отправить HTTPS POST на 1.8 КБ
…содержащий 6-байтное сообщение
Действительно ли это веб-приложение обязано весить 20 МБ? Что же такое там загружается, чего нельзя отложить на нужный момент или добавить в «опциональный» пакет с аддоном? Есть ли облегчённая версия для пользователей с узким каналом?
За 14 месяцев в Антарктиде я собрал десятки примеров подобных приложений с искусственными ограничениями, из-за которых ими невозможно или почти невозможно пользоваться.
В оставшейся части поста я поделюсь своими самыми серьёзными печалями и расскажу о том, что можно было бы сделать для устранения проблем.
Я понимаю, что не каждое приложение обязано всё это реализовывать! Если вы создаёте малопопулярное, ещё только развивающееся приложение, то я не жду, что вы будете тратить всё время разработки на оптимизацию кода под чудаков из Антарктиды.
Да, Антарктида — это пограничный случай! Да, задержки в 750 мс / потеря 10% пакетов / 40 Кбит/с — довольно экстремальные условия. Но Южный полюс — это не уникально плохая с точки зрения связи точка. Существуют коммерческие морские суда, на которых для получения нескольких сотен драгоценных Кбит/с используются древние системы Inmarsat. Прямо сейчас где-то в далёкой глуши в горах есть исследовательская станция, пытающаяся загрузить ваше приложение через Thales MissionLink с помощью сети Iridium Certus со скоростью в несколько десятков Кбит/с. Есть люди с неправильно настроенными маршрутизаторами, люди с неустойчивым WiFi, люди, застрявшие в местах, где провайдер беспроводного Интернете обеспечивает некачественный сервис. Люди, до сих пор использующие коммутируемые Интернет-соединения по гнилым медным телефонным линиям.
Об этих людях стоит подумать. По крайней мере, вам стоит постараться не мешать им пользоваться вашими продуктами.
Ниже я приведу примеры шаблонов разработки, регулярно вызывавших у меня грусть на Южном полюсе.
Жёстко заданные таймауты и размеры блоков
Как и в показанном выше примере, не нужно жёстко задавать допущения о времени передачи полезной нагрузки или о количестве передаваемого за один запрос.
Если вы можете замерить, движутся ли байты, и если они движутся, то оставьте их в покое, как бы медленно они не передавались. Возможно, добавьте UI, показывающий, что происходит.
Если вы выполняете HTTPS-вызов, в случае сбоя вызова откатитесь к более долгому таймауту. Возможно, ему просто нужно больше времени в текущих сетевых условиях.
Если вам сложно передавать большие объёмы данных в одном HTTPS-вызове, разбивайте их на части. Делите контент на блоки, передавайте за раз небольшие блоки и тщательно отслеживайте прогресс, чтобы обеспечить возможность возобновления и повторной попытки передачи маленьких частей без потери всего предыдущего прогресса. Медленный стабильный инкрементный прогресс лучше, чем единовременная попытка передать огромный объём данных.
Если вы не можете успешно выполнить HTTPS-вызов, поработайте над устранением проблем. Попробуйте DNS, ICMP, HTTP (без TLS), HTTPS до последней известной конечной точки хорошего статуса и так далее. Эта информация может оказаться полезной при устранении проблем и это лучше, чем вслепую повторно выполнять один и тот же сквозной HTTPS-вызов. Этот HTTPS-вызов требует правильной работы кучи внутренних технологий. Очевидно, что они не работают, как нужно, поэтому вам следует попытаться понять, почему, и сообщить об этом пользователю.
Пример 1: скачивание метаданных в приложении
Популярное десктопное приложение пытается при запуске скачать информацию о конфигурации с веб-сайта разработчика. Для HTTPS-вызова установлен жёстко заданный таймаут. При его сбое приложение не будет работать. Оно просто бесконечно пытается сделать тот же самый вызов с теми же параметрами. Оно остаётся на странице загрузки, не сообщая пользователю о том, что же не так. Я узнал о происходящем, прочитав логи.
Фрагмент лога отладки коммерческого десктопного приложения, на котором видно, что запрос прекращается спустя 15 секунд.
К счастью, если продолжить попытки, вызов рано или поздно пробьётся через сеть на Южном полюсе.
Раздражает то, что какое-то единственное жёстко прописанное значение таймаута, встретившееся в идеально работающем приложении корпоративного уровня, делает его практически неработающим. Разработчики могли бы сделать следующее:
Откатываться к постепенно увеличивающимся значениям таймаута, чтобы попытаться получить успешный результат.
Поработать над устранением проблем соединения, чтобы побольше знать о сетевом окружении, и действовать соответствующе.
Показать UI, объясняющий, что происходит.
Если приложение не может получить актуальную конфигурацию, то оно могло бы использовать кэшированную конфигурацию или конфигурацию со стандартными значениями, а не просто отказываться загружаться.
Создать механизм, позволяющий пользователю вручную скачивать и устанавливать требуемые данные, обходя встроенную (наивную) логику скачивания приложения.
Пример 2: чат-приложения
Популярное чат-приложение («Приложение 1») создаёт веб-сокет для отправки и получения данных. Процесс инициализации этого веб-сокета использует жёстко заданный таймаут в 10 секунд. При холодном запуске, когда сеть особенно перегружена, эта настройка веб-сокета может иногда занимать больше десяти секунд! Нам нужно выполнить полный TCP handshake, затем подготовить TLS-сессию, настроить веб-сокет, провести первоначальную отправку сигналов по веб-сокету. Вспомним о том, то при определённых условиях каждая передача данных туда и обратно на Южном полюсе может занимать несколько секунд!
В случае истечения таймаута в 10 секунд приложение просто не работает. Оно переходит в очень долгое состояние паузы, а затем повторяет попытку. UI не показывает чётко, что происходит.
Фрагмент лога отладки Чат-приложения 1, в котором виден жёстко прописанный таймаут в 10 секунд. На самом деле, в это время у нас был доступ к Интернету, просто сеть оказалась слишком перегружена, чтобы выполнить за этот период целиком TCP handshake + TLS negotiation + настройку веб-сокета + запрос. Если бы ей дали ещё несколько секунд, возможно, она бы справилась.
С другой стороны, конкурирующее чат-приложение («Приложение 2») чрезвычайно хорошо справляется с крайне плохими условиями сети! В нём есть несколько стратегий по отправке сетевых запросов с целью обеспечения устойчивости к определённым типам ухудшений условий. Оно активно многократно использует уже открытые соединения. Динамически настраивает таймауты. В случае сбоя оно умным образом выбирает интервалы повторных попыток. И при всём этом присутствует чёткий UX, объясняющий текущее состояние сети.
В результате я могу часто пользоваться Приложением 2 тогда, когда не могу пользоваться Приложением 1. А ведь они оба просто передают обычный текст! Всего несколько байтов контента! Когда я не могу использовать Приложение 2, оно хотя бы говорит, что пытается сделать. Приложение 1 написано наивно, с жёстко заданными допущениями о связи, которые не соблюдаются на Южном полюсе. Приложение 2 написано хорошо, оно правильно реагирует на все условия, с которыми встречается в реальной жизни.
Пример 3: инкрементальная передача
Шанс рассказать о моём собственном тулчейне публикаций в блог!
Сайт, на котором выложен оригинал статьи — это статичный блог на Jekyll. Ресурсы хранятся на S3, а передаются через CloudFront. Я собрал статические файлы локально на своём ноутбуке и загружаю их напрямую в S3. Ничего сложного. Никаких серверов, окружений QA, систем сборки, автоматизированных хуков, ничего динамического.
Учтя крайние сетевые ограничения Южного полюса, я написал на Python скрипт для публикации на S3; он хорошо работает в таких сложных условиях. Он использует S3 API для загрузки ресурсов небольшими блоками. Он обнаруживает и возобновляет сбои загрузки, не теряя прогресса. Перед публикацией новой версии он ждёт, пока всё не будет надёжно загружено.
Если это смог сделать я в двухстах строках Python, работая в одиночку, для своего маленького хобби-блога… то, конечно, справится и ваша команда разработчиков крупного веб-приложения.
Благодаря проактивной разработке можно обеспечить потрясающие улучшения удобства пользования. На полюсе у меня были друзья, имевшие блоги на коммерческих платформах, часто публиковавшие большие файлы на сайтах соцсетей. Им приходилось тщательно планировать свой день, чтобы максимизировать вероятность единоразовой загрузки при помощи плохо спроектированных инструментов публикации платформы во время спутникового окна. Часто для этого требовалось множество попыток, и не всегда было чётко понятно, что происходит на каждом этапе процесса. (Контент передаётся? Загрузка закончилась? Безопасно ли снова нажимать на «Опубликовать»/нужно ли это делать?).
Я же тем временем мог пользоваться любой доступной связью. Время от времени я загружал несколько килобайтов, когда это было удобно. В случае сбоя конкретного разбитого на блоки POST у меня не возникало никаких проблем! Я мог позже повторить или возобновить его с минимальной потерей прогресса. А когда всё было готово, я мог безопасно опубликовать новую версию.
Мой скрипт для публикации этого блога, работающий в условиях прерывистого и ненадёжного Интернета.
Собственный код скачивания
Если вы собираетесь создать для своего приложения скачиватель, то вам нужно будет достичь высокой планки качества. В противном случае он будет терпеть неудачу раздражающим или катастрофическим образом.
Самый главный совет от меня: разрешите пользователю отказаться от вашего встроенного в приложение скачивания и воспользоваться своим, если это возможно.
Дайте ссылку для скачивания вручную; в идеале она должна вести к файлу дифференциального патча, который собиралось скачать приложение. Не наказывайте пользователя, заставляя его скачивать установщик целиком только потому, что скачиватель патчей в вашем приложении не соответствует его потребностям.
Это даст следующие преимущества:
В случае неудачи вашего скачивателя пользователь всё равно сможет получить файл вручную при помощи более надёжного скачивателя, например, веб-браузера.
Пользователь сможет скачать файл один раз и перенести его на несколько устройств.
Пользователь сможет скачать файл на компьютере, где не установлено приложение.
Пользователь сможет гибко планировать скачивание и управлять им с учётом условий и ограничений.
Почему это так важно для пользователей на Южном полюсе?
Скачивание возможно на Южном полюсе, но на него накладываются уникальные ограничения. Самое серьёзное из них — наличие Интернета не 24×7. Пока я находился там, я знал, что в конкретное время потеряют доступ к Интернету!
Такова печальная реальность: большинство приложений выполняло скачивание самостоятельно, поэтому мы ничего не могли сделать с этими разрывами связи. Нам просто приходилось сидеть и наблюдать сбои скачивания, часто приводящие к полной потере прогресса.
Допустим, ежедневно у меня есть четырёхчасовое окно, в течение которого я могу выполнять загрузки (очень медленные!). Если общий объём данных, которые я могу скачать за эти четыре часа, меньше, чем общий размер скачиваемой полезной нагрузки, то я никак не смогу закончить загрузку за один раз! Мне придётся разделить её на несколько окон доступа к Интернету. А приложения часто не дают мне этого делать.
И всё это даже не учитывая того факта, что в это время доступ может быть ненадёжным! Что, если связь прервётся и мне придётся возобновлять скачивание? Что, если мои планы поменялись и мне нужно поставить его на паузу? Я бы не хотел терять весь тот маленький прогресс, которого уже достиг.
У многих современных приложений есть самодельные внутренние скачиватели больших полезных нагрузок. Под «внутренним скачивателем» я подразумеваю систему, получающую контент для автоматических обновлений, патчей, обновлений баз данных контента и так далее. При этом чаще всего бывает так, что приложение прозрачно для пользователя скачивает контент, не заставляя его заниматься внутренними подробностями наподобие URL или сырого файла. К этому относятся и паттерны UI типа Check for updates, Click here to download new version и так далее.
Уведомление о скачивании внутри популярного чат-приложения. Очевидно, это приложение хочет скачать в фоновом режиме 83 МБ данных! Для Южного полюса это большая нагрузка. Учтёт ли UI уникальные ограничения Полюса?
К сожалению, большинство таких скачивателей ужасно плохо справляются с задачей! У многих из них отсутствует функция паузы/возобновления, уведомления о состоянии, логика повторных попыток и отслеживание прогресса. Многие из них имеют раздражающие ограничения, например, лимит времени на скачивание полезной нагрузки. В условиях быстрого Интернета большинство подобных проблем может лишь слегка напрягать, но на Южном полюсе они могут стать для приложения вопросом жизни или смерти.
К сожалению, никаких шансов нет. Отсутствует указание скорости, расчётное время завершения скачивания, кнопка отмены, отображение URL (чтобы мы могли выполнить скачивание вручную) и способа добраться до самого файла.
Всегда печально смотреть на подобные интерфейсы, потому что я знаю, сколько времени и ресурсов канала будет потрачено.
Чёрт, неудача! Этого можно было ожидать: непрерывная загрузка 83 МБ — сложная задача. К сожалению, весь прогресс был потерян, и теперь приложение даже не предлагает при повторной попытке патч — размер скачивания вырос до 133 МБ, размера полного установщика.
Каждое приложение, содержащее внутренний скачиватель, должно стремиться конкурировать с невероятно высокой планкой удобства использования: с веб-браузерами.
Задумайтесь: у каждого современного веб-браузера есть менеджер загрузок с функциями прекращения, паузы и возобновления. Они позволяют повторно выполнять неудачные загрузки (если URL не содержит токен со сроком жизни). Они чётко показывают текущий статус, скорость скачивания и оценку оставшегося времени. Они позволяют выбирать место сохранения файла, чтобы вы при необходимости вы могли его копировать. И в них нет произвольных ограничений по параметрам! Если вы действительно хотите скачать многогигабайтный файл при скорости 60 Кбит/с, то вперёд!
Полнофункциональный процесс скачивания в популярном веб-браузере. Скачивается установщик приложения с сайта разработчика. Обратите внимание на статус, скорость, приблизительное оставшееся время, полный URL и на кнопки паузы/отмены.
Частично загруженный файл показанного выше скачивания.
Во второй части статьи я приведу другие раздражающие примеры работы приложений с Интернетом.
Habrahabr.ru прочитано 6275 раз
