TCP был впервые имплементирован в 70-х годах и прекрасно справлялся со своей задачей в эру проводного Интернета. Но беспроводные сети отличаются переменной пропускной способностью, высоким random packet loss, сменой IP и MTU на лету и прочими вещами, которые приводят к деградации TCP-соединения. Поэтому Одноклассники и Google активно занимаются оптимизацией сетевого взаимодействия (новые алгоритмы congestion control) и, в качестве крайней меры, переводом сетевого взаимодействия с TCP на UDP.

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

Мы поговорим о сетевых стеках iOS/Android, проблемах TCP и полностью пройдем путь перевода приложения на UDP.

В докладе будут:
- проблемы беспроводных сетей и стека TCP/IP;
- перевод с TCP на UDP сетевого взаимодействия (API, images, video streaming);
- написание своих UDP-протоколов.

А также: как отменить запрос на фото в своем приложении, если это фото больше не нужно, а запрос уже ушел на сервер, что при этом произойдет с вашим TCP-соединением?

Будут раскрыты: Head-of-line blocking, forward error correction (FEC), fast retransmit vs negative ack, MTU discovery, IPMigration, packet pacer... и многое другое:
- рассмотрим особенности и +/- протокола QUIC от Google;
- напишем протокол, ориентированный на беспроводные сети Wi-Fi и 2/3/4G.

Все будет рассказано на примере OKLive — первого Android-приложения для мобильного стриминга в качестве 1080p и основного клиента Одноклассников.

Пример для тех, кто дочитал ;)
У вас есть приложение — аналог Инстаграм. Открывая приложение, пользователь видит ленту из первых 3 фото на экране ;)
Вам надо как можно быстрее отобразить фото в плохой сети (как Wi-Fi на некоторых конференциях).
RTT 200 мс, фото 200 кб, сеть 1 Мбит/сек, packetLoss 5% (bulk loss) ;)
Варианты решения:
- скачать последовательно по TCP/HTTP1.1 без pipeline, тогда, пока выполняется следующий запрос (за RTT), канал будет простаивать;
- скачать параллельно в 3 потока по TCP/REST;
- скачать последовательно в pipeline HTTP2/TCP;
- скачать по QUIC/UDP.

А что делать, если запросы уже ушли, а пользователь проскроллил дальше, не дожидаясь ответа?
Как отменить запрос? На TCP? На UDP?
К концу доклада вы сможете посчитать время всех вариантов и выбрать подходящий для себя способ.