• Новости
• Блоги
• Аналитика
• Новости компаний
• В СНГ и в мире
• Анонсы

TCP-протокол: обратная сторона стандарта

Стандарт фиксирует лучшее из достигнутого и делает его обязательной нормой. С течением времени меняются реалии, пересматриваются требования, появляются новые возможности. Но старые стандарты могут затормозить развитие.

В мире многое делается неоптимально. Мы сначала нагреваем воздух в квартирах и офисах отопительными батареями, а потом охлаждаем его, открывая окна или включая кондиционеры. Поздно вечером в метро ходят пустые составы, хотя в это время суток можно было бы перевезти всех пассажиров в одном вагоне. В загородном гипермаркете продаются яблоки, привезенные с другого полушария, а в соседнем саду висят более вкусные, но почему-то никому ненужные.

Это происходит потому, что так сложились стандарты и бизнес-процессы. Какие-то вещи делаются не как лучше, а как заведено. Люди вообще не очень любят меняться и менять свою деятельность и стандарты, по которым она осуществляется. А если есть возможность стандарта не менять, достигая при этом сносного результата, почти наверняка этот стандарт никогда не поменяется. То есть повсеместно применяется старинная программистская мудрость «работает – не трогай».

Все вышеописанное произошло и со стеком протоколов TCP/IP. Когда он разрабатывался в начале 70-х гг., мир был совсем другим. Существовавшие тогда наземные сети передачи данных состояли из крайне низкоскоростных междугородних каналов, объединявших сравнительно высокоскоростные локальные сети, построенные на основе технологии Ethernet. Не было ни беспроводных, ни спутниковых сетей передачи данных. Поэтому вполне естественно, что создатели механики протокола TCP/IP не предусмотрели их наличия. И так же вполне естественно, что когда беспроводные и спутниковые сети появились, стандарт TCP/IP никто не стал перестраивать для оптимальной работы в этих сетях. Поэтому если вы злитесь, что на вашем телефоне долго грузится видео или мобильный сайт, знайте – все могло бы работать гораздо быстрее, если бы люди не ленились своевременно адаптировать стандарты при появлении новых условий их применения и внедрении новых технологий.

Подвох «плавающего окна»

В чем же кроется проблема медленной работы TCP/IP на мобильных? Дело в механизме «плавающего окна», который применяется для регулирования скорости передачи данных между передающим устройством (в нашем случае CDN-сервером) и принимающим устройством (мобильным телефоном или планшетом). Упрощенно этот алгоритм можно описать следующим образом: сначала сервер передает небольшой объем данных и ждет подтверждения его доставки. Если оно получено, то сервер передает вдвое больший размер данных (или, в терминологии TCP/IP, вдвое увеличивает окно) и ждет подтверждения корректности доставки. Когда получено и оно, сервер опять вдвое увеличивает окно – пока не будет достигнут предел пропускной способности канала и подтверждения о корректности доставки данных перестанут приходить. После этого размер окна устанавливается равным значению, при котором доставка данных произошла без проблем, и далее не меняется. Таким образом TCP/IP регулирует скорость передачи данных, подстраивая ее под реально доступные полосы пропускания.

Механизм «плавающего окна» отлично работает в наземных сетях, в которых задержки при передаче данных незначительны. В этом случае размер окна повышается до эффективных значений за доли секунды, а значит, скорость передачи данных довольно быстро сравнивается с реально доступной скоростью канала связи.

Совсем по-другому работает механизм «плавающего окна» в беспроводных и спутниковых сетях, где задержки передачи данных гораздо больше, чем в наземных каналах. В сетях 3G задержки на последней миле достигают 100 – 200 мс, на спутниковых каналах – около 600 мс, и механизм «плавающего окна» может выводить TCP-соединение на оптимальную скорость несколько секунд, а в случае спутниковых каналов – и того больше. Это значит, что когда ваш мобильный долго грузит данные с сервера, он в первые несколько секунд с начала загрузки некоторой единицы контента использует не всю доступную ему полосу пропускания, а только ее часть. Особенно хорошо это заметно при загрузке сайтов: объектов там много, причем иногда они физически находятся на разных серверах, поэтому пока все они загрузятся с неоптимальной скоростью, может пройти много времени.

Есть ли выход?

Конечно, в последние годы ученые и компьютерные инженеры предложили массу вариантов решения этой проблемы. Предлагалось перейти на новые транспортные протоколы вместо TCP или же внести в него изменения, которые бы позволили избежать имеющихся проблем. Однако стандарт стека TCP/IP сейчас есть в каждом устройстве, подключенном к интернету, и нет такой силы, которая бы заставила всех пользователей изменить программное обеспечение стека TCP/IP одновременно на всех устройствах, поэтому внести изменение в стандарт не представляется возможным.

Сейчас есть несколько проектов, которые так или иначе помогают устранить вышеописанные недостатки TCP/IP и, в частности, ускорить доставку контента на мобильные. Наиболее известны из них проекты Google – SPDY и QUIC. Протокол SPDY использует в качестве транспорта безопасную и, как следствие, еще менее быструю версию стандартного протокола TCP – протокол TLS. Но при этом протокол SPDY позволяет ускорить загрузку веб-страниц путем их сжатия, объединения объектов и т.п., т.е. не решает проблемы TCP, а минимизирует их последствия. Протокол SPDY уже получил хорошее внедрение: его поддерживают практически все браузеры и веб-серверы, на его основе был разработан новый стандарт протокола HTTP.

Разработчики протокола QUIC, напротив, полностью отказались от TCP и используют в качестве транспортного протокола UDP, реализуя функции по контролю целостности передачи информации. Такой подход существенно сложнее, чем тот, который применяется в SPDY, но зато сулит б'ольшую выгоду, т.к. позволяет избежать проблем, унаследованных от TCP. Однако пока проект не получил существенного распространения и поддерживается только в браузере Chrome и в веб-сервере, распространяемом Google.

* * * 

Я бы не стал бы делать ставку на то, что проблема неоптимальной скорости загрузки данных на мобильные будет решена на протокольном уровне в обозримом будущем, т.к. внедрение новых стандартов взамен старых и работающих – дело практически безнадежное. Фактически эта проблема сейчас решается по-другому: создаются мобильные версии веб-сайтов, чтобы минимизировать обмен данными между сервером и мобильным устройством. Также повсеместно разрабатываются мобильные приложения, разработчики приложений стараются предзагружать любую информацию, которая может понадобиться при его работе. Таким образом эффект от медлительности загрузки несколько сглаживается для пользователей.

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