Slide 1

Slide 1 text

TCP мертв, или будущее сетевых протоколов Александр Тоболь, Руководитель разработки платформ Видео и Лента Социальная сеть «Одноклассники»

Slide 2

Slide 2 text

OK.RU или почему мы про сетевое будущее 71млн >2 +3 более половины используют мобильные устройства Стриминг Tbit/s Tbit/s Видео MAU 2 *

Slide 3

Slide 3 text

Видео и Лента Новостей в ОК 3

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Скорость развития IT 5 1 1974 TCP >10 1990 Codecs 1971 >40 CPU 10 iPhones 2007

Slide 6

Slide 6 text

Сегодня вы узнаете 6 Как пришли к мысли, что c TCP что-то не так :) Как мы тюнили TCP для разных задач – рецепты Как к этому же пришел Google Какое будущее сетевых протоколов мы видим 2 1 3 4

Slide 7

Slide 7 text

Сегодня вы НЕ узнаете 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

Slide 8

Slide 8 text

Тюнинг TCP или как мы стали замечать, что TCP не идеален

Slide 9

Slide 9 text

Задача сетевого протокола или Данные передаются пакетами 9 1 2 3 4 5 6 Data 1 2 3 4 5 6 Data обеспечить обмен данными без искажений *

Slide 10

Slide 10 text

Реальный мир сетей 10

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Простая модель сети - Bandwidth 13 bandwidth BW Client Server … 1 2 3 w … 1 2 3 w Bandwidth = Packets x Size / sec

Slide 14

Slide 14 text

Передача данных и 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

Slide 15

Slide 15 text

15 Client Server … RTT 1 2 3 w … 1 2 3 w 1 2 3 … w Bandwidth = Packets * Size / sec Работа TCP в простой сети

Slide 16

Slide 16 text

Профили сети 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 выберите в настройках телефона *

Slide 17

Slide 17 text

Задачка про медленный интернет или как мы запускали видео в 2013

Slide 18

Slide 18 text

Сможет ли пользователь посмотреть видео? 18 250 Msec bandwidth ??? 400 Mbit/s 1080 FullHD round-trip time

Slide 19

Slide 19 text

Ответ зависит от 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

Slide 20

Slide 20 text

Пример увеличения 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 *

Slide 21

Slide 21 text

fast.com от Netflix over TCP 21 1 Идём на сайт fast.com

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

fast.com от Netflix over TCP 23 3Снова измеряем трафик с Shaper RTT 250 msec У Netflix sendbuffer = 128 Kb 4

Slide 24

Slide 24 text

Высокая пропускная способность сети 2 Сети с высоким RTT 1 Подними send buffer size 24 Рецепт

Slide 25

Slide 25 text

TCP не идеален в случае сетей с потерями

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

Retransmissions Client Server pkt 1 pkt 2 ack 2 ack 3 ack 1 pkt 3 packet drop pkt 3 28

Slide 29

Slide 29 text

% 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 Будем терять пакеты

Slide 30

Slide 30 text

Utilization Packet Loss 1% 5% 3% 100% 0% 30 Кривая неэффективности TCP

Slide 31

Slide 31 text

Congestion control не путаем с flow control

Slide 32

Slide 32 text

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)

Slide 33

Slide 33 text

Bottle neck router Window via Feedback Congestion Control или перегрузка сети 33

Slide 34

Slide 34 text

wnd=1 wnd=4 Client Server pkt 1 pkt 2 ack 2 ack 3 ack 1 pkt 3 Client Server 34 TCP congestion window

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

10 t windows size 10 20 40 80 100 RTTx1 RTTx2 RTTx3 overload 20 40 80 Перегрузка сети 36

Slide 37

Slide 37 text

min RTT delay loss Network overloding model 37

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

packet loss != congestion packet loss 39 Legacy CC algorithms

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

BBR Congestion Control или Google нам поможет

Slide 42

Slide 42 text

42 Cubic vs BBR: feedback Cubic BBR

Slide 43

Slide 43 text

Cubic vs BBR: delay 43 Cubic BBR delay loss 100 delay, ms 200 0 time, sec 2 4 6 300 400 500 Packet Loss

Slide 44

Slide 44 text

Модель сети с jitter Client Server … 1 2 3 w … 1 3 w packet jitter Jitter 2 4 5 4 5 44

Slide 45

Slide 45 text

Как потрогать 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

Slide 46

Slide 46 text

Delay feedback vs jitter 46 TCP ACK содержит недостаточно информации, чтобы разделить эти ситуации 2 BBR минимизирует задержку, толерантен к packet loss, но не любит высокий jitter 1

Slide 47

Slide 47 text

Какой СС выбрать? или статистика и практика

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

Рецепты 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

Slide 50

Slide 50 text

Практика: BBR и video +6% суммарное время смотрения Kernel Setting Linux 4.9+ net.ipv4.tcp_congestion_control=bbr 50

Slide 51

Slide 51 text

Установка соединения и тут не идеально

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

Выполнение запроса API Request TLS Connection est. Request Response t load time server processing api.ok.ru DNS lookup 217.20.147.5 53

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

Установка TCP соединения API Request Connection est. t DNS lookup 55

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

Установка TLS соединения API Request Connection est. t DNS lookup TLS 59

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

Установка TCP + TLS соединения TLS Client Server data clientHello serverHello clientFinished serverFinished Client Server syn+cookie+get TCP + TFO syn+ack+data 61

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

Slow-start 10 t windows size 10 20 40 80 160 100 RTTx1 RTTx2 RTTx3 RTTx4 63

Slide 64

Slide 64 text

Установка соединения DNS resolve 1 connection establishment 2 TLS 3 slow start 4 Reuse Connections 64

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

Server-side рецепты настрой send/recv buffer 1 выбери congestion control 2 disable slow-start restart 4 reuse connections 3 TFO & TLS 1.3 5 66

Slide 67

Slide 67 text

Что там у клиентов? или Client-side Congestion Control и send/recv buffer size

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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 *

Slide 71

Slide 71 text

Android by versions или возьми zeroRTT с собой TLS 1.3 not enabled by default 4.x 9.x 6.x 5.x 7.x 8.x 71

Slide 72

Slide 72 text

Ускорение загрузки или как мы точно убедились, что TCP не эффективен

Slide 73

Slide 73 text

Параллельная загрузка Server 40Мб 10Мб 10Мб 10Мб 10Мб range-request 40Мб 73

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

Client-side рецепты возьми TLS 1.3 с собой 1 распараллель соединения 2 75 забудь про TFO ;) 3

Slide 76

Slide 76 text

Так можно жить или Client-side и Server-side рецепты Client-side Server-side

Slide 77

Slide 77 text

Рецепты TCP настрой send/recv buffer 1 выбери congestion control 2 zeroRTT & TLS 1.3 4 переиспользуй соединения 3 распараллель соединения 5 * список может быть длиннее 77

Slide 78

Slide 78 text

HTTP 1.1 vs HTTP 2.0 или кто убил TCP

Slide 79

Slide 79 text

Стеки 2000 и 2020 HTTP/1.1 SSL/TLS TCP HTTP/2.0 TLS 1.3 TCP Application 2000 Application 2020 … WiFi Mobile … WiFi Mobile 79

Slide 80

Slide 80 text

HTTP 1.1 vs HTTP/2 80

Slide 81

Slide 81 text

Включил HTTP 2.0 на nginx server { listen 443 ssl http2; server_name http://codefest.ru www.http://codefest.ru; ssl on; ...} ничего не поменялось ! enable http2 81

Slide 82

Slide 82 text

HTTP 1.1 Client Server HTTP 1.1 r_api API r_img IMG 82

Slide 83

Slide 83 text

Оптимизация 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

Slide 84

Slide 84 text

Оптимизация HTTP 1.1: connection pool Client Server conn_1 Client Server r_api API r_img IMG conn_2 конкуренция ! 84

Slide 85

Slide 85 text

HTTP 1.1: как отменить загрузку? Client Server HTTP 1.1 IMG IMG ? 85

Slide 86

Slide 86 text

HTTP 2.0 отличия бинарный, сжатие заголовков 1 мультиплексирование 2 отмена загрузки 4 приоритизация 3 server push 5 86

Slide 87

Slide 87 text

HTTP 2.0 мультиплексирование и приоритизация Client Server HTTP 2.0 r_api r_img IMG API IMG адаптируйте приложение ! 87

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

HTTP 2.0 over TCP или как все испортить

Slide 91

Slide 91 text

TCP: Head-of-line blocking API_1 API_2 API_1 API_2 TCP HTTP2.0 и мультиплексирование ? TCP ? server client 91

Slide 92

Slide 92 text

TCP: bufferbloat I5 I4 I3 I2 I1 SendBuffer приоритизация, отмена загрузки, server push ? Image A3 A2 A1 ? API 92

Slide 93

Slide 93 text

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

Slide 94

Slide 94 text

TCP за кадром или другие проблемы

Slide 95

Slide 95 text

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

Slide 96

Slide 96 text

Трудно внедрять новые CC TCP ACK Frame * есть SACK Normal ACK Frame 96 30/70% Upload/download 3g/LTE

Slide 97

Slide 97 text

TCP: IP migration Server 97

Slide 98

Slide 98 text

TCP: IP migration Client Server IP1 IP1 DATA1 IP2 DATA2 P1 > P2 IP1 IP2 98

Slide 99

Slide 99 text

Так жить нельзя или Нерешенные проблемы TCP head-of-line blocking 1 buffer bloat 2 окостенелость и долгая доставка оптимизаций клиентам 4 нет IP migration 3 мало информации в ACK для CC 5 99 высокий RTT + packet loss приводит к низкой утилизации сети 6

Slide 100

Slide 100 text

История болезни или краткое содержание предыдущей серии

Slide 101

Slide 101 text

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

Slide 102

Slide 102 text

TCP и беспроводные технологии 1974 TCP 1998 WiFi 1991 2G 1998 3G 2008 4G 2020 5G 102

Slide 103

Slide 103 text

В 80% случаев конечный пользователь выглядит так Server 103

Slide 104

Slide 104 text

Реальный мир packet loss 0.6% * TCP/IP скрывает от вас эти детали reordering 1 2 3 4 5 1 2 3 4 5 2% jitter 50 ms 104

Slide 105

Slide 105 text

Скорость получения данных по TCP в России 20Кbit/sek 10Mbit/sec

Slide 106

Slide 106 text

Мобильный интернет 0.6 % 200ms avg packet loss avg RTT 1.1 avg bandwidth Mbit/s mts.arm
 >3% packet loss
 ~600ms RTT

Slide 107

Slide 107 text

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

Slide 108

Slide 108 text

Потребление зависит от скорости интернета или быстрее получил больше посмотрел

Slide 109

Slide 109 text

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

Slide 110

Slide 110 text

Популярные приложения в плохих сетях * скриншоты экранов после скачивания ~10 Кб * адаптивное качество

Slide 111

Slide 111 text

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

Slide 112

Slide 112 text

TCP в нестабильных сетях или кривая неэффективности TCP

Slide 113

Slide 113 text

% 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

Slide 114

Slide 114 text

Кривая неэффективности TCP Utilization Packet Loss x Connections 1% 5% 3% 5%x2 5%x3 100% 0% 5%x4 95%

Slide 115

Slide 115 text

Эффективность TCP until your packet loss 0% or RTT <10ms everything is OK !

Slide 116

Slide 116 text

Краткое содержание серии Беспроводные сети победили и нестабильны 1 TCP недоутилизирует канал на нестабильных сетях 3 Потребление контента зависит от скорости интернета 2 Новый протокол

Slide 117

Slide 117 text

Варианты решения или куда писать новый протокол?

Slide 118

Slide 118 text

Варианты? новый протокол рядом с 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

Slide 119

Slide 119 text

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

Slide 120

Slide 120 text

OKMP и UT2 или наш опыт написания UDP протоколов

Slide 121

Slide 121 text

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 одним протоколом не решить все задачи в таких сетях !

Slide 122

Slide 122 text

Задачи протокола 3G/LTE WIFI Ethernet MobileApp WEB Video Photo API Live

Slide 123

Slide 123 text

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 отмена загрузки

Slide 124

Slide 124 text

OKMP: результаты 1 задержка стриминга до 1 сек 2 FullHD-стриминг https://habr.com/ru/company/oleg-bunin/blog/413479/ LIVE

Slide 125

Slide 125 text

UT2 или протокол импульсной передачи в мобильных сетях

Slide 126

Slide 126 text

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

Slide 127

Slide 127 text

как написать UDP протокол

Slide 128

Slide 128 text

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

Slide 129

Slide 129 text

Pacer 100% 98,40% 85,60% 1 6 11 16 21 PACER NO PACER packets Packets probability

Slide 130

Slide 130 text

MTU как с ним работать

Slide 131

Slide 131 text

MTU fragmentation 1100 400 1100 1 2 сеть 1500 1500 Header 4 bytes Data Header

Slide 132

Slide 132 text

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

Slide 133

Slide 133 text

MTU distribution 1350 bytes 99% users <

Slide 134

Slide 134 text

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

Slide 135

Slide 135 text

UT2: IP migration Client Server IP1 CUID DATA1 IP1 IP2 CUID DATA2 IP2 IP1 > IP2

Slide 136

Slide 136 text

Multiplexing and prioritisation без head-of-line blocking-а

Slide 137

Slide 137 text

Multiplexing API_1 IMAGE_1 VIDEO IMAGE_2 API_2 API_3 1 2 3 4 5 1 2 3 1 2

Slide 138

Slide 138 text

UT2 multiplexing and prioritisation 1 2 3 4 5 1 2 3 API IMAGE 1 2 3 нет head-of-line blocking !

Slide 139

Slide 139 text

UT2: scheduler IMAGE API IMAGE IMAGE API IMAGE IMAGE A I A I

Slide 140

Slide 140 text

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

Slide 141

Slide 141 text

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

Slide 142

Slide 142 text

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/

Slide 143

Slide 143 text

Заголовок Forward Error Correction … + K P XOR … … … K Reed-Solomon codes N P P А если пропадёт несколько пакетов?

Slide 144

Slide 144 text

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 пакетов

Slide 145

Slide 145 text

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

Slide 146

Slide 146 text

DNS cache Cache 1 IP Migration 2

Slide 147

Slide 147 text

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

Slide 148

Slide 148 text

No content

Slide 149

Slide 149 text

UT2 и результаты на ОК Image -10% API -7% User activity +1% просто мерить нельзя, так как запросов выполняется больше !

Slide 150

Slide 150 text

QUIC или решение от Google

Slide 151

Slide 151 text

QUIC HTTP/2 TLS TCP HTTP/2 QUIC IP UDP FEC и IP Migration 1 2 мультиплексирование и приоритизация 3 целостность данных

Slide 152

Slide 152 text

Why QUIC not so quick? или UDP хейтеры

Slide 153

Slide 153 text

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

Slide 154

Slide 154 text

Why QUIC not so quick? https://www.kth.se/social/files/573b9e20f276545953b688f3/Performance%20testing%20TCP%20and%20QUIC.pdf

Slide 155

Slide 155 text

Why QUIC not so quick? 1 2 установки соединений, смены IP параллельные запросы В тестах забыли про 3 RTT = 0, random loss model 4 модель среды CL + RL

Slide 156

Slide 156 text

UDP скепсис или nat, user space

Slide 157

Slide 157 text

UDP availability 3 % no UDP available VOIP (webRTC) 1 2 games 4 DNS NTP 3

Slide 158

Slide 158 text

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:

Slide 159

Slide 159 text

NAT unbinding - IP Migration :32421 :32421 :21639

Slide 160

Slide 160 text

User space protocol

Slide 161

Slide 161 text

Будущее 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

Slide 162

Slide 162 text

QUIC повсюду не, не слышал…

Slide 163

Slide 163 text

TCP умер для search 1 2 youtube 3 google.com google drive 4 wwdc coming soon 5 https://datatracker.ietf.org/doc/draft-ietf-quic-transport/

Slide 164

Slide 164 text

QUIC сейчас это 1 1.9% всех вебсайтов https://w3techs.com/technologies/details/ce-quic/all/all 2 12% всего трафика 3 30% видео трафика в мобильных сетях

Slide 165

Slide 165 text

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

Slide 166

Slide 166 text

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

Slide 167

Slide 167 text

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

Slide 168

Slide 168 text

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

Slide 169

Slide 169 text

Еще немного будущего или multicast и multipath

Slide 170

Slide 170 text

Multipath Server

Slide 171

Slide 171 text

IPv6 multicast over UDP/QUIC CDN и p2p для видео будут не нужны !

Slide 172

Slide 172 text

Выводы или о чем сегодня было

Slide 173

Slide 173 text

Крупно TCP не так плох, если его правильно готовить 1 2 не верьте хейтерам UDP и user space протоколов – пробуйте, это ближайшее будущее 3 но TCP умер и почти не развивается

Slide 174

Slide 174 text

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

Slide 175

Slide 175 text

Кто думает что TCP не умер ? сеть можно и нужно трогать руками !

Slide 176

Slide 176 text

Спасибо! АЛЕКСАНДР ТОБОЛЬ Руководитель разработки платформ Видео и Лента в социальной сети «Одноклассники» [email protected]

Slide 177

Slide 177 text

Вопросы

Slide 178

Slide 178 text

true ZeroRTT or zeroRTT vs UDP amplification

Slide 179

Slide 179 text

Client Server get data=get QUIC Client Server get UT2 data fallback to QUIC ! ack data zeroRTT & UDP Amplification

Slide 180

Slide 180 text

UT2 vs QUIC или зачем пилить свое

Slide 181

Slide 181 text

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

Slide 182

Slide 182 text

Полезные ссылки на ОК Подкаст про сетевую оптимизацю 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