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.

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
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