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

16b6c87229eaf58768d25ed7b2bbbf52?s=47 CodeFest
April 06, 2019

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

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

    платформ Видео и Лента Социальная сеть «Одноклассники»
  2. 2.

    OK.RU или почему мы про сетевое будущее 71млн >2 +3

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

    Сегодня вы узнаете 6 Как пришли к мысли, что c

    TCP что-то не так :) Как мы тюнили TCP для разных задач – рецепты Как к этому же пришел Google Какое будущее сетевых протоколов мы видим 2 1 3 4
  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
  5. 9.

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

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

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

    … 1 2 3 w … 1 2 3 w Bandwidth = Packets x Size / sec
  7. 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
  8. 15.

    15 Client Server … RTT 1 2 3 w …

    1 2 3 w 1 2 3 … w Bandwidth = Packets * Size / sec Работа TCP в простой сети
  9. 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 выберите в настройках телефона *
  10. 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
  11. 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 *
  12. 23.

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

    Shaper RTT 250 msec У Netflix sendbuffer = 128 Kb 4
  13. 28.

    Retransmissions Client Server pkt 1 pkt 2 ack 2 ack

    3 ack 1 pkt 3 packet drop pkt 3 28
  14. 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 Будем терять пакеты
  15. 30.
  16. 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)
  17. 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
  18. 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
  19. 36.

    10 t windows size 10 20 40 80 100 RTTx1

    RTTx2 RTTx3 overload 20 40 80 Перегрузка сети 36
  20. 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
  21. 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
  22. 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
  23. 44.

    Модель сети с jitter Client Server … 1 2 3

    w … 1 3 w packet jitter Jitter 2 4 5 4 5 44
  24. 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
  25. 46.

    Delay feedback vs jitter 46 TCP ACK содержит недостаточно информации,

    чтобы разделить эти ситуации 2 BBR минимизирует задержку, толерантен к packet loss, но не любит высокий jitter 1
  26. 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
  27. 53.

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

    load time server processing api.ok.ru DNS lookup 217.20.147.5 53
  28. 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
  29. 57.

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

    TCP Client Server syn+cookie+get TFO syn+ack+data 57
  30. 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
  31. 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
  32. 61.

    Установка TCP + TLS соединения TLS Client Server data clientHello

    serverHello clientFinished serverFinished Client Server syn+cookie+get TCP + TFO syn+ack+data 61
  33. 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
  34. 63.

    Slow-start 10 t windows size 10 20 40 80 160

    100 RTTx1 RTTx2 RTTx3 RTTx4 63
  35. 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
  36. 66.

    Server-side рецепты настрой send/recv buffer 1 выбери congestion control 2

    disable slow-start restart 4 reuse connections 3 TFO & TLS 1.3 5 66
  37. 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
  38. 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
  39. 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 *
  40. 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
  41. 77.

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

    zeroRTT & TLS 1.3 4 переиспользуй соединения 3 распараллель соединения 5 * список может быть длиннее 77
  42. 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
  43. 81.

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

    http2; server_name http://codefest.ru www.http://codefest.ru; ssl on; ...} ничего не поменялось ! enable http2 81
  44. 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
  45. 84.

    Оптимизация HTTP 1.1: connection pool Client Server conn_1 Client Server

    r_api API r_img IMG conn_2 конкуренция ! 84
  46. 87.
  47. 88.

    HTTP 2.0: server push Client Server HTTP 2.0 r_api IMG

    API IMG адаптируйте приложение ! 88
  48. 89.

    HTTP 2.0: отмена загрузки Client Server HTTP 2.0 RESET IMG

    IMG IMG адаптируйте приложение ! 89
  49. 91.

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

    мультиплексирование ? TCP ? server client 91
  50. 92.

    TCP: bufferbloat I5 I4 I3 I2 I1 SendBuffer приоритизация, отмена

    загрузки, server push ? Image A3 A2 A1 ? API 92
  51. 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
  52. 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
  53. 96.

    Трудно внедрять новые CC TCP ACK Frame * есть SACK

    Normal ACK Frame 96 30/70% Upload/download 3g/LTE
  54. 99.

    Так жить нельзя или Нерешенные проблемы TCP head-of-line blocking 1

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

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

    эти детали reordering 1 2 3 4 5 1 2 3 4 5 2% jitter 50 ms 104
  56. 106.

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

    1.1 avg bandwidth Mbit/s mts.arm
 >3% packet loss
 ~600ms RTT
  57. 107.

    Беспроводные сети популярны и нестабильны > 80% используют беспроводной интернет

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

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

    стране, тем больше потребляют видео 1 Крупные игроки оптимизируют приложения под плохую сеть 2 111
  59. 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
  60. 116.

    Краткое содержание серии Беспроводные сети победили и нестабильны 1 TCP

    недоутилизирует канал на нестабильных сетях 3 Потребление контента зависит от скорости интернета 2 Новый протокол
  61. 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
  62. 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
  63. 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 одним протоколом не решить все задачи в таких сетях !
  64. 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 отмена загрузки
  65. 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
  66. 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
  67. 129.

    Pacer 100% 98,40% 85,60% 1 6 11 16 21 PACER

    NO PACER packets Packets probability
  68. 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
  69. 138.

    UT2 multiplexing and prioritisation 1 2 3 4 5 1

    2 3 API IMAGE 1 2 3 нет head-of-line blocking !
  70. 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/
  71. 143.

    Заголовок Forward Error Correction … + K P XOR …

    … … K Reed-Solomon codes N P P А если пропадёт несколько пакетов?
  72. 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 пакетов
  73. 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
  74. 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
  75. 148.
  76. 149.

    UT2 и результаты на ОК Image -10% API -7% User

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

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

    IP Migration 1 2 мультиплексирование и приоритизация 3 целостность данных
  78. 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).
  79. 155.

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

    IP параллельные запросы В тестах забыли про 3 RTT = 0, random loss model 4 модель среды CL + RL
  80. 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:
  81. 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
  82. 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/
  83. 164.

    QUIC сейчас это 1 1.9% всех вебсайтов https://w3techs.com/technologies/details/ce-quic/all/all 2 12%

    всего трафика 3 30% видео трафика в мобильных сетях
  84. 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
  85. 173.

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

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

    Я всё прослушал, что мне теперь делать? используй рецепты TCP:

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

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

    социальной сети «Одноклассники» alexander.tobol@corp.mail.ru
  89. 179.

    Client Server get data=get QUIC Client Server get UT2 data

    fallback to QUIC ! ack data zeroRTT & UDP Amplification
  90. 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
  91. 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