O protocolo QUIC é moi interesante de ver, polo que nos encanta escribir sobre el. Pero se as publicacións anteriores sobre QUIC eran máis de natureza histórica (historia local, se queres) e hardware, hoxe estamos encantados de publicar unha tradución dun tipo diferente: falaremos da aplicación real do protocolo en 2019. Ademais, non estamos a falar de pequenas infraestruturas baseadas nun chamado garaxe, senón de Uber, que opera en case todo o mundo. Como os enxeñeiros da compañía tomaron a decisión de usar QUIC na produción, como realizaron as probas e o que viron despois de lanzalo na produción, por debaixo do corte.
As imaxes pódense facer clic. Disfruta da lectura!
Uber ten unha escala global, concretamente 600 cidades de presenza, en cada unha das cales a aplicación depende integramente da Internet sen fíos de máis de 4500 operadores de telefonía móbil. Os usuarios esperan que a aplicación non só sexa rápida, senón que sexa en tempo real; para conseguilo, a aplicación Uber necesita unha baixa latencia e unha conexión moi fiable. Ai, pero a pila non funciona ben en redes sen fíos dinámicas e propensas a perdas. Démonos conta de que neste caso, o baixo rendemento está directamente relacionado coas implementacións de TCP nos núcleos do sistema operativo.
Para resolver o problema, aplicamos , un moderno protocolo de multiplexación de canles que nos proporciona máis control sobre o rendemento do protocolo de transporte. Actualmente o grupo de traballo estandariza QUIC como .
Despois de probas exhaustivas, chegamos á conclusión de que a implementación de QUIC na nosa aplicación daría lugar a unhas latencias de cola máis baixas en comparación co TCP. Observamos unha redución no intervalo do 10-30% para o tráfico HTTPS nas aplicacións de condutores e pasaxeiros. QUIC tamén nos deu control de extremo a extremo sobre os paquetes de usuarios.
Neste artigo, compartimos a nosa experiencia na optimización de TCP para aplicacións Uber mediante unha pila compatible con QUIC.
A última tecnoloxía: TCP
Hoxe, TCP é o protocolo de transporte máis utilizado para entregar tráfico HTTPS en Internet. TCP proporciona un fluxo fiable de bytes, co que fai fronte á conxestión da rede e ás perdas de capa de enlace. O uso xeneralizado de TCP para o tráfico HTTPS débese á ubicuidade do primeiro (case todos os sistemas operativos contén TCP), á súa dispoñibilidade na maioría das infraestruturas (como equilibradores de carga, proxies HTTPS e CDN) e á funcionalidade lista que está dispoñible. en case a maioría das plataformas e redes.
A maioría dos usuarios usan a nosa aplicación en calquera lugar, e as latencias de cola TCP non estaban nin preto das demandas do noso tráfico HTTPS en tempo real. En pocas palabras, usuarios de todo o mundo experimentaron isto. A figura 1 mostra os atrasos nas principais cidades:
Figura 1: a latencia de cola varía nas principais cidades de Uber.
Aínda que a latencia nas redes indias e brasileiras foi maior que en EE. UU. e Reino Unido, a latencia de cola é significativamente superior á latencia media. E isto é certo incluso para os EUA e o Reino Unido.
Rendemento TCP ao aire
TCP foi creado para cableado redes, é dicir, con énfase nas ligazóns altamente previsibles. Porén, sen fíos as redes teñen as súas propias características e dificultades. En primeiro lugar, as redes sen fíos son susceptibles de sufrir perdas debido á interferencia e a atenuación do sinal. Por exemplo, as redes wifi son sensibles aos microondas, bluetooth e outras ondas de radio. As redes móbiles sofren perda de sinal () debido á reflexión/absorción do sinal por obxectos e edificios, así como desde dos veciños . Isto leva a máis significativa (4-10 veces) e máis diversa e perda de paquetes en comparación cunha conexión por cable.
Para combater as flutuacións e as perdas de ancho de banda, as redes móbiles normalmente usan grandes búfers para as ráfagas de tráfico. Isto pode levar a unha cola excesiva, o que significa atrasos máis longos. Moitas veces, TCP trata esta cola como un desperdicio debido a un tempo de espera prolongado, polo que TCP tende a transmitir e, polo tanto, encher o búfer. Este problema coñécese como (), e isto é moi Internet moderno.
Finalmente, o rendemento da rede móbil varía segundo o operador, a rexión e a hora. Na figura 2, recollemos os atrasos medios do tráfico HTTPS entre as celas dentro dun rango de 2 quilómetros. Datos recollidos para dous principais operadores de telefonía móbil en Delhi, India. Como podes ver, o rendemento varía dunha célula a outra. Ademais, a produtividade dun operador difire da produtividade do segundo. Nisto inflúen factores como os patróns de entrada na rede tendo en conta o tempo e a localización, a mobilidade dos usuarios, así como a infraestrutura de rede tendo en conta a densidade da torre e a proporción de tipos de rede (LTE, 3G, etc.).
Figura 2. Retrasos tomando como exemplo un raio de 2 km. Delhi, India.
Ademais, o rendemento das redes móbiles varía co tempo. A figura 3 mostra a latencia media por día da semana. Tamén observamos diferenzas a menor escala, dentro dun só día e hora.
Figura 3. Os atrasos de cola poden variar significativamente entre días, pero para o mesmo operador.
Todo o anterior fai que o rendemento TCP sexa ineficaz nas redes sen fíos. Non obstante, antes de buscar alternativas ao TCP, queriamos desenvolver unha comprensión precisa dos seguintes puntos:
- é TCP o principal culpable das latencias de cola nas nosas aplicacións?
- As redes modernas teñen atrasos de ida e volta (RTT) significativos e variados?
- Cal é o impacto do RTT e a perda no rendemento do TCP?
Análise de rendemento TCP
Para comprender como analizamos o rendemento de TCP, vexamos como TCP transfire os datos dun remitente a un receptor. En primeiro lugar, o remitente establece unha conexión TCP, realizando unha conexión de tres vías : O remitente envía un paquete SYN, espera un paquete SYN-ACK do receptor e despois envía un paquete ACK. Un segundo e un terceiro pase adicional gástase para establecer a conexión TCP. O destinatario confirma a recepción de cada paquete (ACK) para garantir unha entrega fiable.
Se se perde un paquete ou ACK, o remitente retransmite despois dun tempo de espera (RTO, ). O RTO calcúlase de forma dinámica en función de varios factores, como o atraso RTT esperado entre o remitente e o destinatario.
Figura 4. O intercambio de paquetes sobre TCP/TLS inclúe un mecanismo de retransmisión.
Para determinar o rendemento do TCP nas nosas aplicacións, monitorizamos os paquetes TCP utilizando durante unha semana sobre o tráfico de combate procedente de servidores de borde indio. Despois analizamos as conexións TCP usando . Ademais, creamos unha aplicación para Android que envía tráfico emulado a un servidor de proba, imitando o máximo posible o tráfico real. Os teléfonos intelixentes con esta aplicación distribuíronse a varios empregados, que recolleron rexistros durante varios días.
Os resultados de ambos experimentos foron consistentes entre si. Vimos altas latencias RTT; os valores da cola eran case 6 veces máis altos que o valor medio; a media aritmética dos atrasos é superior a 1 segundo. Moitas conexións tiñan perdas, o que fixo que TCP retransmitise o 3,5% de todos os paquetes. En zonas congestionadas, como aeroportos e estacións de tren, vimos perdas do 7%. Estes resultados poñen en dúbida a sabedoría convencional que se usan nas redes móbiles reducir significativamente as perdas a nivel de transporte. Abaixo amósanse os resultados das probas da aplicación "simulador":
Métricas da rede
Os valores
RTT, milisegundos [50 %, 75 %, 95 %, 99 %]
[350, 425, 725, 2300]
Diverxencia RTT, segundos
De media ~1,2 s
Perda de paquetes en conexións inestables
Media ~3.5 % (7 % en áreas sobrecargadas)
Case a metade destas conexións tiveron polo menos unha perda de paquetes, a maioría deles paquetes SYN e SYN-ACK. A maioría das implementacións de TCP usan un valor RTO de 1 segundo para os paquetes SYN, que aumenta exponencialmente para as perdas posteriores. Os tempos de carga das aplicacións poden aumentar debido a que TCP tarda máis en establecer conexións.
No caso dos paquetes de datos, os valores RTO elevados reducen moito a utilización útil da rede ante a presenza de perdas transitorias nas redes sen fíos. Descubrimos que o tempo medio de retransmisión é de aproximadamente 1 segundo cun atraso de cola de case 30 segundos. Estas altas latencias a nivel TCP causaron tempo de espera HTTPS e solicitudes de novo, aumentando aínda máis a latencia e a ineficiencia da rede.
Mentres que o percentil 75 do RTT medido roldaba os 425 ms, o percentil 75 do TCP era de case 3 segundos. Isto suxire que a perda fixo que TCP tardase entre 7 e 10 pases para transmitir correctamente os datos. Isto pode ser consecuencia do cálculo ineficiente do RTO, a incapacidade do TCP para responder rapidamente á perda. na xanela e a ineficiencia do algoritmo de control de conxestión, que non distingue entre perdas sen fíos e perdas por conxestión da rede. Abaixo amósanse os resultados das probas de perda TCP:
Estatísticas de perda de paquetes TCP
Valor
Porcentaxe de conexións con polo menos 1 perda de paquetes
45%
Porcentaxe de conexións con perdas durante a configuración da conexión
30%
Porcentaxe de conexións con perdas durante o intercambio de datos
76%
Distribución dos atrasos na retransmisión, segundos [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
Distribución do número de retransmisións para un paquete ou segmento TCP
[1,3,6,7]
Aplicación de QUIC
Desenvolvido orixinalmente por Google, QUIC é un protocolo de transporte moderno multiproceso que se executa enriba de UDP. Actualmente está en QUIC (xa escribimos que hai, por así dicir, dúas versións de QUIC, curiosas - aprox. tradutor). Como se mostra na Figura 5, QUIC colócase baixo HTTP/3 (de feito, HTTP/2 enriba de QUIC é HTTP/3, que agora se está estandarizando intensamente). Substitúe parcialmente as capas HTTPS e TCP mediante o uso de UDP para formar paquetes. QUIC só admite a transferencia de datos segura xa que TLS está totalmente integrado en QUIC.
Figura 5: QUIC execútase baixo HTTP/3, substituíndo a TLS, que anteriormente se executaba baixo HTTP/2.
Abaixo amósanse os motivos que nos convenceron de usar QUIC para a amplificación TCP:
- Establecemento de conexión 0-RTT. QUIC permite a reutilización de autorizacións de conexións anteriores, reducindo o número de apretóns de mans de seguridade. No futuro admitirá 0-RTT, pero aínda será necesario un protocolo de conexión TCP de tres vías.
- superando o bloqueo HoL. HTTP/2 usa unha conexión TCP por cliente para mellorar o rendemento, pero isto pode provocar o bloqueo de HoL (cabeza de liña). QUIC simplifica a multiplexación e envía solicitudes á aplicación de forma independente.
- control de conxestión. QUIC reside na capa de aplicación, facilitando a actualización do algoritmo de transporte principal que controla o envío en función de parámetros de rede (número de perdas ou RTT). A maioría das implementacións TCP usan o algoritmo , que non é óptimo para o tráfico sensible á latencia. Algoritmos desenvolvidos recentemente como , modela con máis precisión a rede e optimiza a latencia. QUIC permítelle usar BBR e actualizar este algoritmo a medida que se usa. .
- reposición de perdas. QUIC chama a dous TLP () antes de que se active o RTO, mesmo cando as perdas son moi notables. Isto é diferente das implementacións de TCP. TLP retransmite principalmente o último paquete (ou o novo, se o hai) para activar a reposición rápida. O manexo dos atrasos de cola é especialmente útil para a forma en que Uber opera a súa rede, é dicir, para transferencias de datos curtas, esporádicas e sensibles á latencia.
- ACK optimizado. Dado que cada paquete ten un número de secuencia único, non hai ningún problema paquetes cando son retransmitidos. Os paquetes ACK tamén conteñen tempo para procesar o paquete e xerar un ACK no lado do cliente. Estas funcións garanten que QUIC calcule RTT con máis precisión. ACK en QUIC admite ata 256 bandas , axudando ao remitente a ser máis resistente á mestura de paquetes e a utilizar menos bytes no proceso. ACK selectivo () en TCP non resolve este problema en todos os casos.
- migración de conexión. As conexións QUIC identifícanse mediante un ID de 64 bits, polo que se un cliente cambia os enderezos IP, o ID de conexión antigo pode seguir utilizándose no novo enderezo IP sen interrupcións. Esta é unha práctica moi común para aplicacións móbiles onde o usuario cambia entre conexións wifi e móbil.
Alternativas a QUIC
Consideramos enfoques alternativos para resolver o problema antes de escoller QUIC.
O primeiro que tentamos foi despregar TPC PoPs (Puntos de presenza) para finalizar as conexións TCP máis preto dos usuarios. Esencialmente, os PoP finalizan unha conexión TCP cun dispositivo móbil máis próximo á rede móbil e proxy o tráfico devolve á infraestrutura orixinal. Ao finalizar o TCP máis preto, podemos reducir potencialmente o RTT e garantir que o TCP responde máis a un ambiente sen fíos dinámico. Non obstante, os nosos experimentos demostraron que a maior parte do RTT e da perda proceden de redes móbiles e o uso de PoPs non proporciona unha mellora significativa do rendemento.
Tamén analizamos a sintonización dos parámetros TCP. Configurar unha pila TCP nos nosos servidores de borde heteroxéneos foi difícil porque TCP ten implementacións dispares en diferentes versións do SO. Foi difícil implementar isto e probar diferentes configuracións de rede. Non foi posible configurar TCP directamente en dispositivos móbiles por falta de permisos. Máis importante aínda, funcións como conexións 0-RTT e predición RTT mellorada son fundamentais para a arquitectura do protocolo e, polo tanto, é imposible conseguir beneficios significativos axustando TCP só.
Finalmente, avaliamos varios protocolos baseados en UDP que solucionan problemas de transmisión de vídeo; queriamos ver se estes protocolos axudarían no noso caso. Desafortunadamente, carecían moito de moitas opcións de seguranza e tamén requirían unha conexión TCP adicional para os metadatos e a información de control.
A nosa investigación demostrou que QUIC é quizais o único protocolo que pode axudar co problema do tráfico de Internet, tendo en conta tanto a seguridade como o rendemento.
Integración de QUIC na plataforma
Para integrar con éxito QUIC e mellorar o rendemento das aplicacións en ambientes de conectividade pobres, substituímos a pila antiga (HTTP/2 sobre TLS/TCP) polo protocolo QUIC. Usamos a biblioteca da rede de , que contén a versión orixinal de Google do protocolo - gQUIC. Esta implementación tamén se mellora constantemente para seguir a última especificación IETF.
Primeiro integramos Cronet nas nosas aplicacións de Android para engadir compatibilidade con QUIC. A integración levouse a cabo de xeito que se reducira ao máximo os custos migratorios. En lugar de substituír completamente a antiga pila de rede que usaba a biblioteca , integramos Cronet BAIXO o marco da API OkHttp. Ao facer a integración deste xeito, evitamos cambios nas nosas chamadas de rede (que son utilizadas por ) a nivel de API.
De xeito semellante ao enfoque dos dispositivos Android, implementamos Cronet nas aplicacións de Uber en iOS, interceptando o tráfico HTTP da rede. usando . Esta abstracción, proporcionada pola Fundación iOS, xestiona os datos URL específicos do protocolo e garante que podemos integrar Cronet nas nosas aplicacións iOS sen custos de migración significativos.
Completando QUIC en Google Cloud Balancers
No lado do backend, a infraestrutura de equilibrado de carga de Google Cloud proporciona a finalización QUIC, que utiliza cabeceiras en respostas ao soporte QUIC. En xeral, o equilibrador engade un encabezado alt-svc a cada solicitude HTTP, e isto xa valida o soporte QUIC para o dominio. Cando un cliente de Cronet recibe unha resposta HTTP con esta cabeceira, usa QUIC para as solicitudes HTTP posteriores a ese dominio. Unha vez que o equilibrador completa o QUIC, a nosa infraestrutura envía explícitamente esta acción a través de HTTP2/TCP aos nosos centros de datos.
Desempeño: Resultados
O rendemento da saída é o principal motivo da nosa procura dun mellor protocolo. Para comezar, creamos un stand con para saber como se comportará QUIC baixo diferentes perfís de rede. Para probar o rendemento de QUIC en redes do mundo real, realizamos experimentos mentres conducíamos por Nova Delhi utilizando un tráfico de rede emulado moi similar ás chamadas HTTP na aplicación de pasaxeiros.
Experimento 1
Equipo para o experimento:
- proba os dispositivos Android con pilas OkHttp e Cronet para asegurarnos de que permitimos o tráfico HTTPS a través de TCP e QUIC respectivamente;
- un servidor de emulación baseado en Java que envía o mesmo tipo de cabeceiras HTTPS nas respostas e carga os dispositivos cliente para recibir solicitudes deles;
- proxys de nube que están fisicamente situados preto da India para finalizar as conexións TCP e QUIC. Mentres que para a terminación de TCP usamos un proxy inverso , foi difícil atopar un proxy inverso de código aberto para QUIC. Creamos un proxy inverso para QUIC mediante a pila básica de QUIC de Chromium e en cromo como código aberto.
Figura 6. O conxunto de probas de estrada TCP vs QUIC consistía en dispositivos Android con OkHttp e Cronet, proxies de nube para finalizar conexións e un servidor de emulación.
Experimento 2
Cando Google fixo QUIC dispoñible con , utilizamos o mesmo inventario, pero cunha modificación: en lugar de NGINX, tomamos equilibradores de carga de Google para finalizar as conexións TCP e QUIC dos dispositivos, así como para enrutar o tráfico HTTPS ao servidor de emulación. Os equilibradores distribúense por todo o mundo, pero usan o servidor PoP máis próximo ao dispositivo (grazas á xeolocalización).
Figura 7. No segundo experimento, queriamos comparar a latencia de finalización de TCP e QUIC: usando Google Cloud e usando o noso proxy de nube.
Como resultado, agardábannos varias revelacións:
- a terminación mediante PoP mellorou o rendemento TCP. Dado que os equilibradores finalizan as conexións TCP máis preto dos usuarios e están moi optimizados, isto resulta en RTT máis baixos, o que mellora o rendemento TCP. E aínda que QUIC foi menos afectado, aínda superou ao TCP en canto á redución da latencia da cola (un 10-30 por cento).
- colas están afectadas . Aínda que o noso proxy QUIC estaba máis lonxe dos dispositivos (uns 50 ms de latencia superior) que os equilibradores de carga de Google, ofreceu un rendemento similar: unha redución do 15 % da latencia fronte a unha redución do 20 % no percentil 99 para TCP. Isto suxire que a transición da última milla é un pescozo de botella na rede.
Figura 8: Os resultados de dous experimentos mostran que QUIC supera significativamente a TCP.
Combate o tráfico
Inspirados pola experimentación, implementamos compatibilidade QUIC nas nosas aplicacións para Android e iOS. Realizamos probas A/B para determinar o impacto do QUIC nas cidades onde opera Uber. En xeral, observamos unha redución significativa dos atrasos de cola en ambas rexións, operadores de telecomunicacións e tipo de rede.
Os gráficos seguintes mostran as melloras porcentuais nas colas (percentís 95 e 99) por macrorrexión e diferentes tipos de rede: LTE, 3G, 2G.
Figura 9. Nas probas de batalla, QUIC superou a TCP en termos de latencia.
Só cara adiante
Quizais este sexa só o comezo: o lanzamento de QUIC en produción proporcionou oportunidades incribles para mellorar o rendemento das aplicacións en redes estables e inestables, a saber:
Aumento da cobertura
Unha vez analizado o rendemento do protocolo no tráfico real, vimos que aproximadamente o 80% das sesións utilizaban con éxito QUIC para Todo solicitudes, mentres que o 15% das sesións utilizou unha combinación de QUIC e TCP. Supoñemos que a combinación se debe ao tempo de espera da biblioteca Cronet que regresa a TCP, xa que non pode distinguir entre fallos reais de UDP e malas condicións de rede. Actualmente estamos a buscar unha solución a este problema mentres traballamos para a posterior implementación de QUIC.
Optimización QUIC
O tráfico das aplicacións móbiles é sensible á latencia, pero non ao ancho de banda. Ademais, as nosas aplicacións úsanse principalmente en redes móbiles. Segundo os experimentos, as latencias de cola seguen sendo altas aínda que se utiliza un proxy para finalizar TCP e QUIC preto dos usuarios. Buscamos activamente formas de mellorar a xestión da conxestión e mellorar a eficiencia dos algoritmos de recuperación de perdas QUIC.
Con estas e outras varias melloras, pensamos mellorar a experiencia do usuario independentemente da rede e rexión, facendo que o transporte de paquetes cómodo e fluido sexa máis accesible en todo o mundo.
Fonte: www.habr.com