Исторический взгляд на скорость вычислений и передачи данных

[realeugene]

bondkim137 в сообщении #1704582 писал(а):

но вот в межконтинентальных кабелях и сопутствующей проводной инфраструктуре пакеты прекрасно теряются уже после всех FEC

Ну пакеты теряются по самым разным причинам. Тут многие жалуются, что у них форум вообще грузится по полстраницы. Ослабление сигнала в физической линии тут явно ни при чём. Да и в межконтинентальной связи скорее всего расчётная вероятность потери пакета из-за шума крайне низка. Просто где-нибудь очереди переполняются и лишние пакеты выкидываются.

[bondkim137]

realeugene, форум медленно грузится из-за того, что его хостинг находится за пределами РФ, а в свете последних политических метаморфоз доступ к зарубежным ресурсам урезается. К проблеме это отношения не имеет.

А в межконтинентальной связи вероятность потери пакета действительно невелика, но если вы бы переслали вразумительного размера файл по ней без перепосылки, то явно не обрадовались бы результату. По разным оценкам, при отсутствии перегруженности вероятность потерять пакет на магистрали там ниже $10^{-4}$. Это мало, но без перепосылки вы даже средневзятое качественное фото со своего телефона с далеко ненулевой вероятностью угробите (можете сами посчитать).

Ну а касательно темы - тоже можете сами посчитать оценки результирующей пропускной способности канала в случае применения протоколов, стопорящихся на пересылку при каждой подобной потере при характерном round-world-trip между лондоном и сиднеем например.

Заодно поймете, зачем в IT индустрии доставки толстых данных используются CDN-ы с локальным присутствием.

[Dmitriy40]

Разве протоколы стопорят пересылку при необходимости перепосылки? По моему даже древние модемные протоколы продолжали слать поток дальше, просто вместо очередного нового пакета вставляли вне очереди нужный к перепосылке. Т.е. скорость падает всего лишь на величину частоты ошибок (ну чуть-чуть больше из-за служебных сообщений). И величина задержки ответа большой роли не играет (работал же спутниковый асимметричный интернет с бешеным лагом в down канале и up каналом через модем и ничего). Ждать подтверждения каждого пакета и только потом слать следующий - мягко говоря неудачная мысль.

[bondkim137]

Dmitriy40
потоковые сетевые протоколы используют окно пакетов, которое двигается. По репортам с битовой маской в продвинутых протоколах отправляющая сторона принимает решение о ретрансмите определенных пакетов. Это помогает стопориться реже. Но т.к. окно ограничено (в отличие от torrent-протоколов, например), а ретрансмиты тоже умеют теряться, замедление при потерях все равно происходит и сильно зависит от latency.

В классическом TCP репорт содержит лишь информацию о последнем пакете, до которого получены все. Т.е. окно тоже есть, но в случае потерь оно условно целиком перепосылается, потому все жестко стопорится. В RFC2018 в TCP тоже засунули маску, хотя и довольно примитивную, пожатую по сути RLE. Стало заметно лучше, но все равно сильно отстает от различных RUDP (Reliable UDP) решений, например QUIC и SCTP. Последний встроен во все браузеры внутри WebRTC. Разработчики требовательных сервисов его часто используют, но порог входа там пока что довольно высокий. Ретрансмит в железе (USB/PCIE и т.д.) с масками не заморачивается - там потери обычно редки, а пинг маленький.

Совсем продвинутые проприетарные протоколы умеют использовать несколько ip-соединений, сравнивают их roundworld/ping (сумма latency в обе стороны) благодаря чему умеют определять рост очереди пакетов на всем маршруте еще до того, как пойдут потери в т.ч. из-за конкурентных перегрузок - в результате более ловко управляют окном и вообще кол-вом пакетов, находящихся в пути.

[bondkim137]

Вдогонку, вчера засыпал уже

В модемах на пике совершенства использовался протокол V.42, у него тоже было небольшое окно и битовая маска с избирательной перепосылкой, он сидел ниже IP, потому потери в линии протокол TCP не видел. В протоколе сидел в т.ч. реордеринг, потому для TCP в случае проблем канал просто кратковременно замораживался. В этом смысле V.42 был умнее обычного TCP и использовал технологию, похожую на TCP 2018, но значительно раньше. Стоит отметить, что задержка на аналоговом аудиоканале в рамках города там была очень небольшая, значительно меньше, чем в типичных глобальных IP-сетях.

А для гео-спутников (из-за большой задержки) IP вообще не получается инкапсулировать в лоб. Потому там, условно говоря, все работает через две прокси: первая на земле, не далеко от отправляющего данные сервера, там полностью реализуется TCP, а затем по внутреннему протоколу данные доставляются через спутник в плату DVB-S по дата-каналу внутри DVB, с лютым FEC, огромными окнами и встроенной перепосылкой, с обратным тонким каналом через наземную связь. У клиента вторая прокся снова локально реализует TCP для совместимости с TCP-стеком операционки. В итоге TCP не сходит с ума из-за задержек - для него канал выглядит как прокся-тугодум с медленной реакцией, в которой вообще ничего не теряется, но пропускная способность которой зависит от погоды (в прямом смысле). В итоге в хорошую погоду DVB-S благодаря FEC может выдерживать десятки минут между разовыми потерями, и все работает замечательно. А в плохую погоду все работает паршиво (результирующая пропускная способность падает кратно и периодически стопорится), даже при небольших потерях (в %), но частых - из-за большой задержки, собственно.