Save 37% off PRO during our Black Friday Sale! »

CodeFest 2019. Александр Тоболь (Одноклассники) — TCP умер или будущее сетевых протоколов

CodeFest 2019. Александр Тоболь (Одноклассники) — TCP умер или будущее сетевых протоколов

В докладе мы поговорим про эволюцию и настройки сетевого стека TCP/IP в linux и Android, iOS в контексте мобильных сетей, разберем проблемы TCP в плохих сетях, я поделюсь опытом ОК в написании своих сетевых протоколов в user space поверх UDP. Также рассмотрим развитие QUIC и проблемы UDP и User Space протоклов.

TCP был впервые имплементирован в 70-х годах и прекрасно справлялся со своей задачей в эру проводного интернета. Но беспроводные сети отличаются переменной пропускной способностью, высоким packet loss, сменой IP и MTU на лету и прочими вещами, которые приводят к деградации TCP-соединения. В социальной сети «Одноклассники» более 30 млн человек ежедневно заходят используя мобильные сети. Средний packet loss в этих сетях порядка 1-3%, но бывают сети и с потерями до 10-15%. Кроме этого в мобильных сетях высокие значения jitter-а и RTT. Это всё приводит к тому, что канал утилизируется не полностью, а передача данных работает медленнее, чем могла бы.

Мы поговорим про проблемы TCP, его tuning. Рассмотрим эволюцию TCP стека для ускорения передачи данных от cubic congestion control до BBR cc, а так же tail loss probe, tcp fast open, zeroRTT handshake в TLS 1.3, как это настроить и как это работает ;) Но многие улучшения TCP не достаточно быстро оказывается в продакшене как на серверах, так и на конечных устройствах пользователей. Поэтому мы рассмотрим дальнейшее развитие сетевого стека в сторону userSpace протоколов типа QUIC. И расскажу про экспертизу OK.ru в реализации собственных протоколов передачи данных поверх UDP.

16b6c87229eaf58768d25ed7b2bbbf52?s=128

CodeFest

April 06, 2019
Tweet

Transcript

  1. TCP мертв, или будущее сетевых протоколов Александр Тоболь, Руководитель разработки

    платформ Видео и Лента Социальная сеть «Одноклассники»
  2. OK.RU или почему мы про сетевое будущее 71млн >2 +3

    более половины используют мобильные устройства Стриминг Tbit/s Tbit/s Видео MAU 2 *
  3. Видео и Лента Новостей в ОК 3

  4. TCP мёртв как протокол взаимодействия с пользователями интернета

  5. Скорость развития IT 5 1 1974 TCP >10 1990 Codecs

    1971 >40 CPU 10 iPhones 2007
  6. Сегодня вы узнаете 6 Как пришли к мысли, что c

    TCP что-то не так :) Как мы тюнили TCP для разных задач – рецепты Как к этому же пришел Google Какое будущее сетевых протоколов мы видим 2 1 3 4
  7. Сегодня вы НЕ узнаете 7 Прикладной уровень Уровень представления Сеансовый

    уровень Транспортный уровень Набор интерфейсов, позволяющий получить доступ к сетевым службам Преобразует данные в общий формат для передачи по сети Поддерживает взаимодействие между удалёнными процессами Управляет передачей данных по сети, подтверждение передачи Маршрутизация, управление потоками данных, адресация сообщений Формирование кадров, управление доступом к среде Обеспечивает битовый протоколы передачи информации Сетевое уровень Канальный уровень Физический уровень будем разбирать сеть на реальных примерах ÷ ÷ ÷ ÷ ø ö ç ç ç ç è æ + ÷ ø ö ç è æ + = ) 32 1 ( 8 3 3 , 1 min 3 2 1 , min ) ( 2 0 max p p bp T bp RTT RTT W p B
  8. Тюнинг TCP или как мы стали замечать, что TCP не

    идеален
  9. Задача сетевого протокола или Данные передаются пакетами 9 1 2

    3 4 5 6 Data 1 2 3 4 5 6 Data обеспечить обмен данными без искажений *
  10. Реальный мир сетей 10

  11. Модель сети без потерь 11 round-trip time BW bandwidth RTT

  12. Простая модель сети – RTT 12 round-trip time RTT Client

    Server RTT
  13. Простая модель сети - Bandwidth 13 bandwidth BW Client Server

    … 1 2 3 w … 1 2 3 w Bandwidth = Packets x Size / sec
  14. Передача данных и TCP 14 Application TCP IP Ethernet OS

    NIC Application Data TCP segments 1 2 3 4 5 IP datagrams 1 2 3 4 5 Ethernet frames 1 2 3 4 5 MSS MTU Задачи TCP Целостность данных 1 Уведомление о результате передачи 2
  15. 15 Client Server … RTT 1 2 3 w …

    1 2 3 w 1 2 3 … w Bandwidth = Packets * Size / sec Работа TCP в простой сети
  16. Профили сети 16 2G 3G LTE WIFI 3 ms 90/30Mbit/s

    13 ms 90/20Mbit/s 21 ms 22/3 Mbit/s 173 ms 20/10 Kbit/s выберите в настройках телефона *
  17. Задачка про медленный интернет или как мы запускали видео в

    2013
  18. Сможет ли пользователь посмотреть видео? 18 250 Msec bandwidth ???

    400 Mbit/s 1080 FullHD round-trip time
  19. Ответ зависит от send/recv buffer 19 Client Server RTT =

    250ms send buffer = 128Kb 1% bandwidth = buffer size / RTT bandwidth = 128 x 8 / 0.25 = 4 Mbit/sec
  20. Пример увеличения buffer size 20 64Kb 128Kb 256Kb 10Mb 1640

    ms 1100 ms 733 ms 12Mb 1780 ms 1200 ms 830 ms bandwidth 54 Mbit/sec 80 Mbit/sec 115 Mbit/sec sysctl net.inet.tcp.recvspace=262144 net.inet.tcp.doautorcvbuf: 1 net.inet.tcp.autorcvbufmax: 2097152 *
  21. fast.com от Netflix over TCP 21 1 Идём на сайт

    fast.com
  22. fast.com от Netflix over TCP 22 2Включаем Shaper трафика

  23. fast.com от Netflix over TCP 23 3Снова измеряем трафик с

    Shaper RTT 250 msec У Netflix sendbuffer = 128 Kb 4
  24. Высокая пропускная способность сети 2 Сети с высоким RTT 1

    Подними send buffer size 24 Рецепт
  25. TCP не идеален в случае сетей с потерями

  26. Модель сети с потерями 26 round-trip time BW bandwidth RTT

    PL packet loss
  27. Потеря пакета Client Server … 1 2 3 w …

    1 3 w 27 PL packet loss
  28. Retransmissions Client Server pkt 1 pkt 2 ack 2 ack

    3 ack 1 pkt 3 packet drop pkt 3 28
  29. % 0 0.96 20 ms 1.01 Mbit/s 99% Mbit/s download

    upload RTT loss utilization % 5 0.75 20 ms 0.73 Mbit/s 74% Mbit/s % 0.39 220 ms 0.50 Mbit/s 45% Mbit/s 5 29 Будем терять пакеты
  30. Utilization Packet Loss 1% 5% 3% 100% 0% 30 Кривая

    неэффективности TCP
  31. Congestion control не путаем с flow control

  32. 32 Sliding window Congestion control, CWND, network overload, state 2

    Flow control, RWND, send/recv back pressure, window field 1 1 2 3 4 5 6 7 8 9 min(CWND, RWND)
  33. Bottle neck router Window via Feedback Congestion Control или перегрузка

    сети 33
  34. wnd=1 wnd=4 Client Server pkt 1 pkt 2 ack 2

    ack 3 ack 1 pkt 3 Client Server 34 TCP congestion window
  35. Client Server RTT 1 2 1 2 CWND 1 2

    3 1 2 3 4 4 1 2 3 4 5 6 7 8 Разгон окна 35
  36. 10 t windows size 10 20 40 80 100 RTTx1

    RTTx2 RTTx3 overload 20 40 80 Перегрузка сети 36
  37. min RTT delay loss Network overloding model 37

  38. 1 2 3 4 5 1 2 3 1 2

    Bottle neck router 10 t windows size 10 20 40 80 100 RTTx1 RTTx2 RTTx3 packet drop 20 40 80 38 Packet loss model by router
  39. packet loss != congestion packet loss 39 Legacy CC algorithms

  40. Congestion Control - evolution Slow Start and Congestion Avoidance Tahoe

    1988 год Fast Recovery after Fast Retransmit Reno 1990 год New Fast Recovery Algorithm New
 Reno 1996 год loss Fast Long- Distance Networks linux 2.6.19 Cubic 2006 год bandwidth- delay product (BDP) BBR 2016 год New Fast Recovery Algorithm PCC 2015 год loss/ delay delay Wireline and wireless networks West wood+ 2001 год loss congestion loss random loss 40
  41. BBR Congestion Control или Google нам поможет

  42. 42 Cubic vs BBR: feedback Cubic BBR

  43. Cubic vs BBR: delay 43 Cubic BBR delay loss 100

    delay, ms 200 0 time, sec 2 4 6 300 400 500 Packet Loss
  44. Модель сети с jitter Client Server … 1 2 3

    w … 1 3 w packet jitter Jitter 2 4 5 4 5 44
  45. Как потрогать Jitter PING codefest.ru (78.155.217.193): 56 data bytes icmp_seq=11

    ttl=43 time=117.177 ms icmp_seq=12 ttl=43 time=132.868 ms icmp_seq=13 ttl=43 time=176.413 ms icmp_seq=14 ttl=43 time=225.981 ms 50 ms avg jitter 117ms to 132ms = 15ms 132ms to 176ms = 44ms 176ms to 225ms = 79ms
 (14 + 44 + 79) / 3 = 46ms 45
  46. Delay feedback vs jitter 46 TCP ACK содержит недостаточно информации,

    чтобы разделить эти ситуации 2 BBR минимизирует задержку, толерантен к packet loss, но не любит высокий jitter 1
  47. Какой СС выбрать? или статистика и практика

  48. Other API Music Photo Video Тбит/сек видео трафик >2 Трафик

    в ОК 48
  49. Рецепты Congestion control-а соберите статистику ! Algorithm Network AppProfile Server

    westwood+ high latency networks speed API cubic high bandwith/long RTT stability Photo BBR high random loss streaming Video 49
  50. Практика: BBR и video +6% суммарное время смотрения Kernel Setting

    Linux 4.9+ net.ipv4.tcp_congestion_control=bbr 50
  51. Установка соединения и тут не идеально

  52. Профилирование старта приложения 52

  53. Выполнение запроса API Request TLS Connection est. Request Response t

    load time server processing api.ok.ru DNS lookup 217.20.147.5 53
  54. Latency numbers in mobile networks RTT/ms 3G 4G Radio 50-2000ms

    200-2000ms 50-100ms DNS lookup 1 RTT 200ms 100ms TCP handshake 1 RTT 200ms 100ms TLS handshake 1-2 RTT 200-400ms 100-200ms HTTP request 1 RTT 200ms 100ms Result 4-5 RTT 1-3.5 sec 450-700 ms 54
  55. Установка TCP соединения API Request Connection est. t DNS lookup

    55
  56. TCP handshake Client Server syn syn+ack ack+get data TCP 56

  57. TFO: TCP Fast Open Client Server syn syn+ack ack+get data

    TCP Client Server syn+cookie+get TFO syn+ack+data 57
  58. TFO: server /* create the socket */ fd = socket();

    /* connect and send out some data */ sendto(fd, buffer, buf_len, MSG_FASTOPEN, ...); /* write more data */ send(fd, buf, size); Version Check Linux kernel 4.1+ net.ipv4.tcp_fastopen = 3 Check tcp_fastopen ! 58
  59. Установка TLS соединения API Request Connection est. t DNS lookup

    TLS 59
  60. TLS или почему так долго? $ ping google.com 64 bytes

    from 173.194.73.139: icmp_seq=5 ttl=44 time=211.847 ms round-trip min/avg/max/stddev = 209.471/220.238/266.304/19.062 ms HTTP = 230ms
 HTTPS = 800ms
 RTT = 220ms
 $ curl -o /dev/null -w "HTTP time taken: %{time_connect}\nHTTPS time taken: % {time_appconnect}\n" -s https://www.google.com HTTP time taken: 0,231 HTTPS time taken: 0,797 60
  61. Установка TCP + TLS соединения TLS Client Server data clientHello

    serverHello clientFinished serverFinished Client Server syn+cookie+get TCP + TFO syn+ack+data 61
  62. zeroRTT TLS 1.3 TLS 1.3 Client Server session ticket +

    get data /* NGINX >=1.13.0 */ ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3; 62
  63. Slow-start 10 t windows size 10 20 40 80 160

    100 RTTx1 RTTx2 RTTx3 RTTx4 63
  64. Установка соединения DNS resolve 1 connection establishment 2 TLS 3

    slow start 4 Reuse Connections 64
  65. Reuse connections: Slow-Start Restart /* disable slow-start restart */ sysctl

    -w net.ipv4.tcp_slow_start_after_idle=0 10 t windows size 10 20 40 80 100 RTTx1 RTTx2 RTTx3 slow-start 10 20 40 65
  66. Server-side рецепты настрой send/recv buffer 1 выбери congestion control 2

    disable slow-start restart 4 reuse connections 3 TFO & TLS 1.3 5 66
  67. Что там у клиентов? или Client-side Congestion Control и send/recv

    buffer size
  68. Default buffer size Default Check Linux 16kb/80kb net.ipv4.tcp_wmem Android 512kb

    socket.getReceiveBufferSize() iOS auto SO_RCVBUF = 4295098368 MacOS 128kb/128kb+auto net.inet.tcp.sendspace 68
  69. Default congestion control понять и простить? ! Default Check Linux

    Cubic ipv4.tcp_congestion_control Android Cubic kernel auditor iOS Cubic но это не точно macOS Cubic net.inet.tcp.use_newreno 69
  70. TFO: client Version Check Android 9+ (8.1.0 еще нет) tcp_fastopen

    = 1 iOS 9+ documentation 70 -10% – 1 RTT TFO dec 2014, production in 2018 *
  71. Android by versions или возьми zeroRTT с собой TLS 1.3

    not enabled by default 4.x 9.x 6.x 5.x 7.x 8.x 71
  72. Ускорение загрузки или как мы точно убедились, что TCP не

    эффективен
  73. Параллельная загрузка Server 40Мб 10Мб 10Мб 10Мб 10Мб range-request 40Мб

    73
  74. Результат ускорения загрузки upload speed x3 74

  75. Client-side рецепты возьми TLS 1.3 с собой 1 распараллель соединения

    2 75 забудь про TFO ;) 3
  76. Так можно жить или Client-side и Server-side рецепты Client-side Server-side

  77. Рецепты TCP настрой send/recv buffer 1 выбери congestion control 2

    zeroRTT & TLS 1.3 4 переиспользуй соединения 3 распараллель соединения 5 * список может быть длиннее 77
  78. HTTP 1.1 vs HTTP 2.0 или кто убил TCP

  79. Стеки 2000 и 2020 HTTP/1.1 SSL/TLS TCP HTTP/2.0 TLS 1.3

    TCP Application 2000 Application 2020 … WiFi Mobile … WiFi Mobile 79
  80. HTTP 1.1 vs HTTP/2 80

  81. Включил HTTP 2.0 на nginx server { listen 443 ssl

    http2; server_name http://codefest.ru www.http://codefest.ru; ssl on; ...} ничего не поменялось ! enable http2 81
  82. HTTP 1.1 Client Server HTTP 1.1 r_api API r_img IMG

    82
  83. Оптимизация HTTP 1.1: batching Client Server HTTP 1.1 r_api API

    r_img IMG задержки или зависимость ! batching Client Server r_api + r_img API + IMG 83
  84. Оптимизация HTTP 1.1: connection pool Client Server conn_1 Client Server

    r_api API r_img IMG conn_2 конкуренция ! 84
  85. HTTP 1.1: как отменить загрузку? Client Server HTTP 1.1 IMG

    IMG ? 85
  86. HTTP 2.0 отличия бинарный, сжатие заголовков 1 мультиплексирование 2 отмена

    загрузки 4 приоритизация 3 server push 5 86
  87. HTTP 2.0 мультиплексирование и приоритизация Client Server HTTP 2.0 r_api

    r_img IMG API IMG адаптируйте приложение ! 87
  88. HTTP 2.0: server push Client Server HTTP 2.0 r_api IMG

    API IMG адаптируйте приложение ! 88
  89. HTTP 2.0: отмена загрузки Client Server HTTP 2.0 RESET IMG

    IMG IMG адаптируйте приложение ! 89
  90. HTTP 2.0 over TCP или как все испортить

  91. TCP: Head-of-line blocking API_1 API_2 API_1 API_2 TCP HTTP2.0 и

    мультиплексирование ? TCP ? server client 91
  92. TCP: bufferbloat I5 I4 I3 I2 I1 SendBuffer приоритизация, отмена

    загрузки, server push ? Image A3 A2 A1 ? API 92
  93. HTTP/2 поверх TCP head-of-line blocking buffering packet loss variable bandwidth

    stream cancelation & head-of-line blocking 1 2 prioritization & buffering 3 multiplexing & head-of-line blocking Doesn’t work: server push & buffering 4 93
  94. TCP за кадром или другие проблемы

  95. Timeline TCP RFC 1974 TCP 2014 TFO RFC 7413 окостенелость,

    высокий time to client 2013 TLP draft-dukkipati- tcpm-tcp-loss- probe-01 2016 RACK draft-ietf-tcpm- rack-03.html 2018 BBR draft-cardwell-iccrg- bbr-congestion- control-00 95
  96. Трудно внедрять новые CC TCP ACK Frame * есть SACK

    Normal ACK Frame 96 30/70% Upload/download 3g/LTE
  97. TCP: IP migration Server 97

  98. TCP: IP migration Client Server IP1 IP1 DATA1 IP2 DATA2

    P1 > P2 IP1 IP2 98
  99. Так жить нельзя или Нерешенные проблемы TCP head-of-line blocking 1

    buffer bloat 2 окостенелость и долгая доставка оптимизаций клиентам 4 нет IP migration 3 мало информации в ACK для CC 5 99 высокий RTT + packet loss приводит к низкой утилизации сети 6
  100. История болезни или краткое содержание предыдущей серии

  101. Мобильный мир победил 101 TCP/IP 1974

  102. TCP и беспроводные технологии 1974 TCP 1998 WiFi 1991 2G

    1998 3G 2008 4G 2020 5G 102
  103. В 80% случаев конечный пользователь выглядит так Server 103

  104. Реальный мир packet loss 0.6% * TCP/IP скрывает от вас

    эти детали reordering 1 2 3 4 5 1 2 3 4 5 2% jitter 50 ms 104
  105. Скорость получения данных по TCP в России 20Кbit/sek 10Mbit/sec

  106. Мобильный интернет 0.6 % 200ms avg packet loss avg RTT

    1.1 avg bandwidth Mbit/s mts.arm
 >3% packet loss
 ~600ms RTT
  107. Беспроводные сети популярны и нестабильны > 80% используют беспроводной интернет

    1 Параметры беспроводных сетей динамично меняются 2 Фиксированный ассиметричный канал, смена IP адреса 4 Беспроводные сети имеют высокие показатели packet loss, jitter, reordering 3 * обычно мы это игнорируем и TCP как-то разгребет 107
  108. Потребление зависит от скорости интернета или быстрее получил больше посмотрел

  109. Потребление мобильного видео в зависимости от bandwidth https://opensignal.com/reports/2018/09/state-of-mobile-video 109

  110. Популярные приложения в плохих сетях * скриншоты экранов после скачивания

    ~10 Кб * адаптивное качество
  111. Потребление зависит от скорости интернета Чем выше скорость интернета в

    стране, тем больше потребляют видео 1 Крупные игроки оптимизируют приложения под плохую сеть 2 111
  112. TCP в нестабильных сетях или кривая неэффективности TCP

  113. % 0 0.96 20 ms 1.01 Mbit/s 99% TCP и

    простой тест Mbit/s download upload RTT loss utilization % 5 0.75 20 ms 0.73 Mbit/s 74% Mbit/s Mbit/s % 0.31x2 220 ms 0.31x2 Mbit/s 62% 5 % 0.39 220 ms 0.50 Mbit/s 45% Mbit/s 5 113
  114. Кривая неэффективности TCP Utilization Packet Loss x Connections 1% 5%

    3% 5%x2 5%x3 100% 0% 5%x4 95%
  115. Эффективность TCP until your packet loss 0% or RTT <10ms

    everything is OK !
  116. Краткое содержание серии Беспроводные сети победили и нестабильны 1 TCP

    недоутилизирует канал на нестабильных сетях 3 Потребление контента зависит от скорости интернета 2 Новый протокол
  117. Варианты решения или куда писать новый протокол?

  118. Варианты? новый протокол рядом с TCP, UDP 1 SCTP over

    UDP 2 head-of-line blocking for stream New protocol over UDP 3 4-way handshake кол-во стримов определяется на старте no IP migration https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol
  119. User space vs kernel Server Client Increasing TCP's Initial Window

    + - TCP Fast Open + 50/50
 IOS, Android TLP (Tail loss probe) + - Early Retransmit for TCP + - RACK: a time-based fast loss detection algorithm for TCP + - TLS 1.3 + FIZZ
  120. OKMP и UT2 или наш опыт написания UDP протоколов

  121. 2.5 % 900 ms 0.2 Mbit/s EGDE Мобильные сети BW/PL/RTT

    0.5 % 550 ms 1.0 Mbit/s 3G 0.7 % 220 ms 2.0 Mbit/s LTE 0.5 % 110 ms 2.2 Mbit/s WiFi одним протоколом не решить все задачи в таких сетях !
  122. Задачи протокола 3G/LTE WIFI Ethernet MobileApp WEB Video Photo API

    Live
  123. OKMP и UT2 0 100 200 300 400 500 600

    700 800 900 1000 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Video 1 2 низкие задержки стриминг видео OKMP 0 100 200 300 400 500 600 700 800 900 1000 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Feed 1 2 планировщик импульсная передача UT2 3 отмена загрузки
  124. OKMP: результаты 1 задержка стриминга до 1 сек 2 FullHD-стриминг

    https://habr.com/ru/company/oleg-bunin/blog/413479/ LIVE
  125. UT2 или протокол импульсной передачи в мобильных сетях

  126. UT2: предметная область 0 100 200 300 400 500 600

    700 800 900 1000 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Feed 1 2 планировщик импульсная передача UT2 3 отмена загрузки 4 5 TLP и soft FEC IPMigration 6 zeroRTT
  127. как написать UDP протокол

  128. UT2: self-made UDP int s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP); sendto(s,

    buffer, strlen(buffer) + 1, 0, (struct sockaddr*)&sa, sizeof(struct sockaddr_in)); 1 1 2 sendto(s, buffer, strlen(buffer) + 1, 0, (struct sockaddr*)&sa, sizeof(struct sockaddr_in)); 2
  129. Pacer 100% 98,40% 85,60% 1 6 11 16 21 PACER

    NO PACER packets Packets probability
  130. MTU как с ним работать

  131. MTU fragmentation 1100 400 1100 1 2 сеть 1500 1500

    Header 4 bytes Data Header
  132. MTU discovery int val = IP_PMTUDISC_DO; setsockopt(fd, IPPROTO_IP, IP_MTU_DISCOVER, &val,

    sizeof(val));
 //выставляем пакетам флаг DF 256 bytes MTU of Network Interface set packet size 1500 bytes 1100 400 1100 1 2 1100 400 1100 1 2 set packet size
 1100 bytes 1100 1100 1100 1100 1100 1100
  133. MTU distribution 1350 bytes 99% users <

  134. IP Migration CID и запомни IP на сервере

  135. UT2: IP migration Client Server IP1 CUID DATA1 IP1 IP2

    CUID DATA2 IP2 IP1 > IP2
  136. Multiplexing and prioritisation без head-of-line blocking-а

  137. Multiplexing API_1 IMAGE_1 VIDEO IMAGE_2 API_2 API_3 1 2 3

    4 5 1 2 3 1 2
  138. UT2 multiplexing and prioritisation 1 2 3 4 5 1

    2 3 API IMAGE 1 2 3 нет head-of-line blocking !
  139. UT2: scheduler IMAGE API IMAGE IMAGE API IMAGE IMAGE A

    I A I
  140. Исправление ошибок SACK, NACK, FEC

  141. Packet loss 1–3% потерь на беспроводных сетях — это норма!

  142. Packet Loss: fast retransmit Client Server pkt 1 pkt 2

    ack 2 ack 3 ack 1 pkt 3 packet drop pkt 3 retransmit period https://habr.com/ru/company/oleg-bunin/blog/413479/
  143. Заголовок Forward Error Correction … + K P XOR …

    … … K Reed-Solomon codes N P P А если пропадёт несколько пакетов?
  144. 1 2 3 4 5 6 7 8 9 10

    11 12 13 14 15 16 17 18 19 20 21 Packet gap avg packet gap 6 пакетов
  145. TLP: tail loss probe and soft FEC slow delivery TLP/FEC

    to TCP production ! Client Server 1 ack 5 5 … 6 10 … 1 2 FEC (loss data) loss probe (packet number) TLP RTT + jitter loss probe 10
  146. DNS cache Cache 1 IP Migration 2

  147. Checklist for self-made protocols Pacer 1 MTU discovery 2 30/70

    % upload/download 3g/LTE Error correction 3 Flow control, CC 4 IP Migration 5 Optional: TLP, DNS cache 6
  148. None
  149. UT2 и результаты на ОК Image -10% API -7% User

    activity +1% просто мерить нельзя, так как запросов выполняется больше !
  150. QUIC или решение от Google

  151. QUIC HTTP/2 TLS TCP HTTP/2 QUIC IP UDP FEC и

    IP Migration 1 2 мультиплексирование и приоритизация 3 целостность данных
  152. Why QUIC not so quick? или UDP хейтеры

  153. Why QUIC not so quick? While Google-reported performance for QUIC

    is promising — 3% page load time (PLT) improvement on Google search and 18% reduction in buffer time on YouTube — they are aggregated statistics and not reproducible by others (such as ourselves).
  154. Why QUIC not so quick? https://www.kth.se/social/files/573b9e20f276545953b688f3/Performance%20testing%20TCP%20and%20QUIC.pdf

  155. Why QUIC not so quick? 1 2 установки соединений, смены

    IP параллельные запросы В тестах забыли про 3 RTT = 0, random loss model 4 модель среды CL + RL
  156. UDP скепсис или nat, user space

  157. UDP availability 3 % no UDP available VOIP (webRTC) 1

    2 games 4 DNS NTP 3
  158. Reuse connections: NAT unbinding 0 20 40 60 80 100

    0 50 100 150 200 250 300 Probability Sec ping-pong 15-30sec 50% TCP: SYN, ACK, FIN UDP:
  159. NAT unbinding - IP Migration :32421 :32421 :21639

  160. User space protocol

  161. Будущее HTTP/1.1 SSL/TLS TCP IPv4 HTTP/2.0 TLS 1.3 TCP IPv6

    2000 2020 HTTP/3.0 QUIC IPv6 202X HTTP/3 https://mailarchive.ietf.org/arch/msg/quic/RLRs4nB1lwFCZ_7k0iuz0ZBa35s
  162. QUIC повсюду не, не слышал…

  163. TCP умер для search 1 2 youtube 3 google.com google

    drive 4 wwdc coming soon 5 https://datatracker.ietf.org/doc/draft-ietf-quic-transport/
  164. QUIC сейчас это 1 1.9% всех вебсайтов https://w3techs.com/technologies/details/ce-quic/all/all 2 12%

    всего трафика 3 30% видео трафика в мобильных сетях
  165. QUIC как проверить?

  166. QUIC как проверить?

  167. UDP performance или ложка дегтя

  168. UDP performance issue Generic Segmentation Offloading for UDP 1 2

    zerocopy socket support also on Linux https://lwn.net/Articles/752184/ https://lwn.net/Articles/655299/ 0.25 throughput
  169. Еще немного будущего или multicast и multipath

  170. Multipath Server

  171. IPv6 multicast over UDP/QUIC CDN и p2p для видео будут

    не нужны !
  172. Выводы или о чем сегодня было

  173. Крупно TCP не так плох, если его правильно готовить 1

    2 не верьте хейтерам UDP и user space протоколов – пробуйте, это ближайшее будущее 3 но TCP умер и почти не развивается
  174. Я всё прослушал, что мне теперь делать? используй рецепты TCP:

    TFO, send/recv buffer, TLS1.3, CC… 1 2 проверь UDP check list 4 готовьте свою инфраструктуру под QUIC если нет ресурсов? 5 соберите профили сети и профили нагрузки делайте self-made user space протоколы (нет) 3
  175. Кто думает что TCP не умер ? сеть можно и

    нужно трогать руками !
  176. Спасибо! АЛЕКСАНДР ТОБОЛЬ Руководитель разработки платформ Видео и Лента в

    социальной сети «Одноклассники» alexander.tobol@corp.mail.ru
  177. Вопросы

  178. true ZeroRTT or zeroRTT vs UDP amplification

  179. Client Server get data=get QUIC Client Server get UT2 data

    fallback to QUIC ! ack data zeroRTT & UDP Amplification
  180. UT2 vs QUIC или зачем пилить свое

  181. TCP vs UT2 vs QUIC TLS + TCP QUIC UT2

    Radio DNS lookup 1 RTT 1 0 TCP handshake 1 RTT 0.5 0 TLS handshake 1-2 RTT 0 0 request 1 RTT 1 1 Result 4-5 RTT 2.5 RTT 1 RTT
  182. Полезные ссылки на ОК Подкаст про сетевую оптимизацю 3 https://sdcast.ksdaemon.ru/2019/01/sdcast-97/

    Миллион видеозвонков в сутки или «Позвони маме!» 1 https://habr.com/ru/company/oleg-bunin/blog/428217/ Пишем свой протокол поверх UDP 2 https://habr.com/ru/company/oleg-bunin/blog/413479/ Увеличение скорости передачи данных в плохих сетях 4 https://linuxpiter.com/materials/2476