El auto-DDoS de Twitter

• Mientras el feed de inicio de Twitter estuvo caído durante gran parte de esa mañana, se observó una situación en la que el cliente web seguía repitiendo solicitudes de contenido y parecía provocarse un DDoS a sí mismo
• Incluso en una pantalla que no cargaba, los reintentos no se detenían; en el primer video aparecían un error de rate limited y una barra de desplazamiento temblorosa
• En el segundo video se confirma que, en el proceso de intentar obtener contenido que no llegaba, Twitter se enviaba a sí mismo aproximadamente 10 solicitudes por segundo
• Se señala como posible causa que la reciente restricción de lectura para usuarios no logueados pudo haber creado condiciones inesperadas
• En la consola de red de Firefox de un video posterior también se veían solicitudes que seguían llegando en cascada, lo que se interpretó como una situación de auto-DDoS en la que el navegador del usuario repetía solicitudes a Twitter

---

Solicitudes repetidas observadas en el cliente web de Twitter

• El feed de inicio de Twitter estuvo caído durante gran parte de esa mañana y, aunque no se cargaba nada, el sitio web no dejaba de reintentar solicitudes
• El primer video muestra un mensaje de error que indica que el usuario está en estado rate limited y una escena con la barra de desplazamiento de la derecha temblando
• El segundo video muestra por qué temblaba la barra de desplazamiento: Twitter intentaba obtener contenido enviándose a sí mismo aproximadamente 10 solicitudes por segundo
• Como trasfondo de que el contenido no llegara, se señala el cambio que impidió a los usuarios no logueados leer Twitter

Verificación posterior y material adjunto

• Una publicación posterior muestra adicionalmente, mediante la consola de red de Firefox, que las solicitudes de red seguían ocurriendo
• Se añadió la interpretación de que el código desplegado provocó una condición de carrera (race condition) y, como resultado, los usuarios terminaron ejecutando solicitudes con características de DDoS contra Twitter
• El autor de la publicación indicó que al principio cerró la conexión, pero que después Twitter mantuvo durante un tiempo la situación en la que seguía induciendo solicitudes
• Material adjunto:
  • Video 4: error de rate limited y barra de desplazamiento temblorosa
  • Video 5: escena en la que Twitter se envía solicitudes repetidas a sí mismo
  • Video 6: escena en la que las solicitudes siguen ocurriendo en la consola de red de Firefox

[xguru]

Twitter cambia temporalmente a un modo de velocidad limitada

[GN⁺]

Comentarios en Hacker News

• Desde una experiencia personal muy dolorosa, pocas cosas sacuden tanto a una persona como que la obliguen a ejecutar algo que claramente sabe que es una idea terrible
  Más aún cuando intentaste explicarle ese hecho a la persona que te presiona para ir en contra de tu mejor criterio y fracasaste, y peor todavía si después esa persona grita que nunca hizo esa petición aunque haya pruebas por escrito
  No sé si la gente que hoy trabaja en Twitter advirtió que las medidas recientes podían causar efectos secundarios tan grandes, pero viendo cómo opera el liderazgo no sorprendería en absoluto
  He odiado mucho en lo que se ha convertido Twitter en los últimos meses, y ni antes de la compra me gustaba por cómo el formato corto elimina los matices y unos pocos tuits fáciles de incrustar terminan siendo la base de artículos, pero de verdad da pena la gente que tiene que trabajar bajo esa directiva

  • Lo más probable es que toda la gente de Twitter que entendía el sistema y podía prever efectos secundarios ya haya sido despedida o se haya ido
    Si tuviera que adivinar, Elon dijo que “el sitio está demasiado lento”, los ingenieros vieron que las solicitudes del feed principal eran lentas, pero no entendían la estructura, no tenían herramientas de profiling, y los presionaron para arreglarlo con plazos irreales
    Así que probablemente lo único que podían hacer era lanzar múltiples solicitudes en paralelo y esperar que alguna saliera rápido
    Habiendo trabajado en la industria de los videojuegos, entendí por qué salen juegos que, después de gastar cantidades enormes de tiempo y dinero, ni siquiera tienen bien resueltas las funciones básicas
    Este tipo de presión extrema de calendario termina creando, paradójicamente, un enorme lodazal donde cambias una cosa y se rompen diez, y al final el progreso se detiene
  • Haciendo de abogado del diablo, los desarrolladores frontend también deberían ser un poco más inteligentes
    Esto es manejo básico de errores que debió estar implementado desde hace años
    Un 403 o cualquier otra respuesta que bloquee tuits jamás debería disparar reintentos infinitos en intervalos cortos
  • Cuando me pidieron hacer algo realmente estúpido, una vez solté una bomba de CC por si acaso
  • Justo ahora estoy pasando por algo así en el trabajo
    Hice una herramienta para gestionar los tickets de vulnerabilidades del equipo, y el primer caso de uso fue borrar todos los tickets de vulnerabilidades, pese a mi oposición
    A quien lo ejecuta le importa más que en el papel se vea bien que mejorar realmente la seguridad
  • Mucho peor que la dinámica de criticar entre todos algo que todos usan y les importa es la situación en la que sabes la solución, pero te da miedo siquiera intentar actuar
    Es cuando lo sabes desde hace mucho, lo has propuesto repetidamente, ni siquiera te permiten intentarlo y, peor aún, te apartan y te tratan como “ese tipo”
    Lo he vivido con enfoques técnicos y de negocio que “la manera de siempre” todavía logra sostener de algún modo, pero que van matando lentamente a la empresa
    Dicho eso, si un superior asume con claridad la responsabilidad por algo que considera riesgoso pero necesario, incluso cuando surgen problemas hay mucho más margen para responder bien y el desarrollador tiene que aguantar menos sarcasmo a toro pasado
    Claro, igual es más fácil ponerse a criticar

• Hay que ver que esto pasó en fin de semana feriado
  Elon empujó un gran lanzamiento y básicamente hizo que los ingenieros fueran a trabajar y se pasaran las últimas 12 horas aplicando parche tras parche

  • Su arrogancia es tan grande que la palabra arrogancia se queda corta
    Me preocupan los programadores
    Lo aún más sorprendente es lo improvisada que se ve hoy la ingeniería de Twitter
    Se meten en problemas porque, en vez de invertir esfuerzo en entender a fondo la base de código, eligen siempre el arreglo más simple y más corto
  • Los ingenieros de Twitter han tenido más de un año para buscar otro trabajo
    A estas alturas, tanto las condiciones de empleo como las expectativas del jefe son completamente claras
    Cuesta sentir mucha empatía por quienes siguen ahí, sea por la razón que sea
  • Al menos sí podían desplegar directamente en producción

• Es muy poco probable que este bug haya sido la causa
  El rate limiter del lado del servidor tiene un costo pequeño, y el bug del frontend solo se activa cuando el rate limit ya está en funcionamiento
  En sistemas que administro también he visto bugs parecidos, porque a las librerías de red les encanta reintentar solicitudes por defecto sin límites razonables
  Pero esos reintentos nunca pusieron en aprietos al rate limiter
  Si golpeas una API que hace algo realmente costoso antes de devolver el error, sí se vuelve un poco más molesto, pero por eso todos los endpoints públicos tienen rate limit
  La web app probablemente sea la porción más pequeña del tráfico de Twitter, y supongo que la app nativa no tiene este problema

  • No creo que necesariamente signifique que un DDoS autoinfligido causó problemas técnicos que bloquearon el acceso
    Puede que bloquear el acceso anónimo haya provocado un DDoS, que eso generara un pico gigantesco en alguna métrica y que, como resultado, Elon concluyera que había más scraping y luego castigara a los scrapers con el límite de 600 tuits por día
    Parece que mi cuota ya se reinició o cambió la política, porque puedo volver a entrar al sitio
  • Cuando tienes un liderazgo conocido por mentir si cree que eso le da algún beneficio personal, el concepto mismo de verdad queda destruido
    Coincido en que es poco probable que este bug sea la causa raíz de todo
    Pero tampoco me creo la historia que Musk vende como motivo para prácticamente cerrar el sitio
    Puede que ambas cosas sean ciertas, y uno sigue pensando en otras posibles razones, lo cual es una pérdida total de tiempo, pero se siente como una especie de carnada mental extraña
    El libro "Nothing is true and everything is possible" trata sobre cómo Putin usa la desinformación para controlar al público y eliminar la política democrática, y se siente aplicable también aquí
    Los fans de Musk repetirán exactamente lo que él les diga que repitan, pero la mayoría sabrá que solo es palabrería interesada
    Y quien intenta encontrar la causa raíz termina desviándose fácilmente hacia narrativas como este bug, que suenan correctas pero no tienen absolutamente ningún dato que las respalde
    Si quieres ver una posible trayectoria futura de Estados Unidos, recomiendo mucho este libro
    https://en.wikipedia.org/wiki/Nothing_Is_True_and_Everything...
  • Depende de la escala total del sistema
    Yo mismo he visto e intentado mitigar casos degenerados donde este tipo de reintentos saturaba tanto el backend que el servidor ya ni siquiera podía rechazar solicitudes a tiempo
    Por los reintentos en varias capas de llamadores aguas arriba, la situación se volvió tan mala que las solicitudes básicamente expiraban en los buffers/colas de TCP antes siquiera de ser procesadas por la aplicación
    No sé si el backend de la página principal de Twitter tenga una escala parecida

• Es una situación interesante.
  Si ves la captura, se genera una cantidad enorme de GET /TweetDetail, y como aparece un 429, parece estar activando algún límite de velocidad.
  Si esto se debe a la decisión reciente de exigir autenticación para todas las llamadas a la API, el culpable en realidad podría ser el API gateway o algún componente similar por debajo.
  Además, este comportamiento no parece detenerse, lo cual no es lo que se esperaría de reintentos con backoff exponencial.
  No digo que yo sea mejor ingeniero que la gente que trabaja en Twitter, pero incluso dejando de lado todo lo relacionado con Musk, es interesante ver algo así en producción.

  • En teoría, el backoff exponencial es lo óptimo, pero no creo que en la práctica se use tan seguido.
    He visto demasiados casos donde se considera tan importante responder a las solicitudes del usuario con baja latencia que se prefiere un backoff aleatorio constante en lugar de backoff exponencial.
    He visto en varias reuniones de diseño y documentos que se toma explícitamente la decisión de no usar backoff exponencial, entendiendo el compromiso entre sobrecarga y recuperación del sistema.
  • Parece probable que el frontend se haya escrito bajo la suposición de que el backend seguiría funcionando incluso sin autenticación.
    Es posible que un cambio en el backend, es decir, autenticación obligatoria + rate limiting, se haya desplegado sin probar suficientemente juntos el frontend y el backend.
  • ¿Elon habrá pagado la factura de AWS?
    Eso parece un culpable bastante plausible.
    También podría ser que las instancias de Twitter estén siendo apagadas a la fuerza.

• Platformer reportó el 10 de junio que “Twitter se estaba negando a pagar los costos de los servicios en la nube de Google antes de la fecha de renovación del contrato del 30 de junio”.
  También decía que “el contrato de Twitter con Google Cloud existía desde 2018”.
  https://www.engadget.com/twitter-has-supposedly-started-payi...
  Ah, esto parece explicar todo este desastre.

  • Según ese artículo y reportes de Bloomberg, Twitter al final hizo las paces con Google y el problema se resolvió.
    Probablemente estén tratando de salirse de GCP, pero no parece que esto haya pasado porque de pronto perdieran acceso a GCP por negarse a pagar.
  • https://www.reuters.com/technology/twitter-resumes-paying-go...
    Este artículo es de hace una semana.
  • Twitter no usa Google Cloud como servicio principal de backend.
    Todo está self-hosted.
    Gcloud solo soporta trabajos por lotes y análisis de datos.
  • Los servicios centrales de Twitter están en centros de datos on-premises.

• Es una teoría interesante, pero el DDoS empezó antes de la decisión de desactivar el acceso anónimo.
  De hecho, esa decisión se tomó para mitigar un DDoS que ya estaba en curso[0][1].
  Así que una lógica sospechosa de reintentos en el frontend web pudo haber empeorado la situación, pero no sería la causa raíz.
  [0] https://twitter.com/elonmusk/status/1674865731136020505
  “Es una medida temporal de emergencia. El saqueo de datos fue tan intenso que estaba degradando la calidad del servicio para los usuarios normales”.
  [1] https://twitter.com/elonmusk/status/1674942336583757825
  “Se levantará pronto. Como en la publicación anterior, niveles extremos de scraping de datos hicieron necesarias medidas drásticas e inmediatas”.
  “Casi todas las empresas que hacen IA, desde startups hasta algunas de las compañías más grandes del planeta, estaban haciendo scraping de enormes cantidades de datos”.
  “Es bastante irritante tener que poner de emergencia una enorme cantidad de servidores solo para ayudar con la absurda valuación de alguna startup de IA”.

  • Sinceramente, más que con startups de IA y todo eso, parece estar más relacionado con la decisión de básicamente cerrar el acceso a la API salvo que pagues tarifas absurdas.
    Seguro que por ahí andan circulando enormes archivos con todos los tuits anteriores a cierta fecha que esas startups usan.
  • Esa es una afirmación que Elon Musk hizo después de la reacción negativa, así que hay que tomarla con mucha cautela.

• ¿Alguien sabe si ya existían solicitudes así antes del cambio a solo con login?
  Sería realmente gracioso si esa enorme operación de scraping en realidad fuera un bug de su JavaScript.

  • En las últimas semanas he visto que el frontend le pega al backend con bastante frecuencia.
    No me sorprendería en absoluto que gran parte del “tráfico de scraping” fuera culpa de Twitter mismo.
  • Parte del scraping ocurrió porque Twitter arruinó la API y los bots se pasaron al scraping.
    Es un resultado obvio, aunque estúpido.
  • En ciertos flujos, como la pantalla de perfil, al presionar “atrás” definitivamente se producía un bucle infinito de redirecciones en Firefox para Android.
    Antes de que entrara el rate limit, seguramente se iban decenas de solicitudes en unos pocos segundos.
    Muchos bugs pequeños como ese, juntos, pudieron haber parecido algún DDoS o scraping.

• No parece imposible que no sea un bug.
  Elon dijo que limitó a 600 los tuits vistos por día, lo cual es una locura.
  La mayoría de la gente seguramente supera eso con solo 5 minutos de scroll.

  • Quizá sea momento de reflexionar sobre cuánta información inútil consumimos.
  • Puede que 5 minutos sea una exageración.
    Recuerdo que cuando Tweetbot mostraba más de 500 elementos en mi feed, alcanzaba de sobra para leer tonterías durante varios trayectos de 20 minutos en tranvía.
  • Como en las últimas semanas he visto que el frontend le pega al backend, sospecho que este nuevo rate limit es una respuesta a eso, aunque Musk no lo reconozca públicamente.
    No dudo que Twitter haya visto un enorme aumento reciente en el tráfico, pero estoy bastante convencido de que gran parte de eso fue un problema que Twitter se creó solo.

• Elon simplemente tenía que dejarlo en paz, pero claro, estaban los 44 mil millones de dólares
  Parag Agrawal y su equipo sabían exactamente lo que estaban haciendo
  Es literalmente el dicho de que un tonto y su dinero pronto se separan

  • ¿Así que jugaron ajedrez en 5 dimensiones con esa cláusula venenosa?
  • También hay una teoría que lo ve de otra manera
    Después de que un tribunal de Delaware obligó a Elon a comprar Twitter, fue con dictadores adinerados, recibió 44 mil millones de dólares y dijo que incendiaría Twitter por ellos
    Sin Twitter no hay Primavera Árabe, no hay actualizaciones en tiempo real durante desastres, y ya no hace falta cortar internet para impedir que se difundan voces disidentes

• No significa mucho, pero el límite de velocidad se está relajando otra vez
  6k/600/300 → 8k/800/400 (cerca del mediodía) → 10k/1k/500 (cerca de las 3 p. m.)
  https://twitter.com/elonmusk/status/1675214274627530754 y según sus propias respuestas

  • No se puede leer
    Sale “Something went wrong”
    Bajo las nuevas reglas de solo iniciar sesión, aunque el sitio estuviera vivo, igual no se habría podido leer
    Ahora los enlaces de Twitter se volvieron enlaces contaminados, así que en la práctica ya no sirven
  • Solo toqué ese enlace y me topé con un límite de velocidad que parecía recién aumentado
    Es un circo total
  • Volvió a ser accesible, y luego probablemente me volvió a aplicar el límite de velocidad en 5 o 6 minutos bajo este nuevo límite