Pues dame el enlace.
Porque precisamente eso es el throttling. Se viene explicación rollazo sobre como funcionan las redes con un ejemplo muy manido. Pedir cervezas en un bar en una terraza.
En este ejemplo, hay dos actores implicados:
- El cliente, es decir, tú que te pides cervezas, por medio de una solicitud.
- El servidor, es decir, el bar que es quien almacena las cervezas y te las tiene que hacer llegar.
¿Pero como llegan las cervezas? ¡Por medio de un camarero!
Nuestro camarero es nuestro canal por el que nos llegan las cervezas desde el bar hasta nuestra mesa en la terraza. Y así podemos asumir que:
- La velocidad de descarga es como la rapidez en la que un camarero puede llevar bebidas a la terraza de un bar.
- El tamaño de la bandeja es lo que denominamos ancho de banda, es decir, cuanto más grande sea la bandeja, más potenciales cervezas podrá nuestro camarero llevar “al mismo tiempo”.
- La cantidad de bebidas pedidas determinará el tamaño del archivo a descargar.
La distancia entre la barra donde se tiran las cervezas y la mesa donde la bebemos determina la latencia o también mal llamado ping.
Pero esa distancia, tiene muchas partes distintas, es decir, puntos por los que tiene que pasar el camarero:
- El trayecto desde la cocina hasta la puerta del bar, que es responsabilidad del propio bar.
- El trayecto desde la puerta de bar hasta nuestra mesa en la terraza, que no es responsabilidad del bar.
- Nuestra mesa, que nos la proporciona el bar, pero nosotros la usamos.
Así, podemos resumir que pedir una gran cantidad de cervezas desde nuestra mesa en la terraza implica:
- Ocupar una mesa de la terraza.
- Hacer el pedido al bar por medio del camarero.
- El bar preparar las cervezas y dárselas al camarero.
- El camarero transportar las cervezas.
- Tomarnos las cervezas.
En uno de esos puntos, puede ser donde esté el error que haga que no estemos disfrutando de la cerveza lo suficientemente rápido:
- Puede ser que la mesa esté coja y muchas de las cervezas que lleguen se caigan, derramandose y no pudiendo tomarlas. Esto sería que el cliente de juego tiene bugs.
- Puede ser que el camarero no se entere de nuestro pedido, y por tanto no nos lleguen las cervezas. Esto sería un problema de conexión.
- Puede ser que el bar esté cerrado y no pueda servir cervezas, es decir, tenga los servidores cerrados. O puede que no tenga suficientes grifos para tirar todas las cervezas que le están solicitando, es decir, que está sobrecargado. En estos casos, el problema es del bar.
- Puede ser problema del camarero al transportar las cervezas hasta nuestra mesa, que no pueda ir lo suficientemente rápido.
- Puede ser que no seamos capaces de beber tanta cerveza como nos traen, y por eso el camarero no nos trae más, porque aún tenemos muchas cervezas sin empezar encima de la mesa.
Si fallase el cliente de juego, es decir, la mesa fallaría para todos, porque todas las mesas del bar son iguales. Si fuese problema de que el camarero no se entera, no recibiríamos ninguna cerveza. Si fuese problema del bar, todos tendría el mismo problema ya que todas las cervezas salen de los distintos grifos del bar, y si hay un grifo “roto” o atascado, se sirve de los otros que si funcionan.
¿Qué nos queda? El recorrido del camarero.
Pero claro, no estamos solos en el mundo. Hay muchas otras mesas que el camarero tiene que atender. Y se pueden pedir otras muchas cosas a parte de cerveza, como coca-colos. Y hay muchos camareros. Y más bares. Y otros negocios. Y todos utilizan las mismas “calles” para llegar desde sus negocios hasta las terrazas. Podemos asumir que tenemos “muchos” camareros compitiendo por ir por el mismo sitio.
Además, el recorrido no es recto, sino que se hace entre puntos de enrutamiento. Es decir, el camarero tiene que pasar un camino desde el bar hasta el dispositivo, eligiendo las intersecciones que tenga disponible.
Si una de estas intersecciones está muy ocupada los datos pueden retrasarse (el camarero tarda más en llegar) o perderse (al camarero le tiran la cerveza).
Esto puede hacer, que la red se congestione. Pero para evitar eso, las ISP se encargan de poner orden a los camareros, orquestándolos:
Para ello, ponen en cada intersección unos “agentes de tráfico” que permiten controlar a los camareros que entran y cervezas llevan.
Igual no te dejo salir a 50 camareros del bar, solo te dejo a 20. Y no dejo que entres con 20 cervezas, solo con 5. Además, como es dinámico, puede ser que haya momentos en el que la intersección esté congestionada, porque haya otros camareros o repartidores de otros sitios, pero que tienen que pasar por el mismo punto. Así que puede haber momento en los que te permita pasar con 10 cervezas y otras con 20 cervezas.
A esta limitación impuesta por los puntos de intersección se le denomina throttling. Es decir, cuando tu ISP reduce intencionalmente el tráfico que permite pasar por una determinada intersección.
Además, tenemos las políticas QoS de calidad de servicio, que hacen que ciertos camareros tengan prioridad a la hora de pasar por una determinada intersección. ¿A qué camareros le dan prioridad? ¡Pues a los suyos propios!
Porque hay muchos ISP que además de poner el camino, también tienen bares. ¿Quién creeis que tiene prioridad?
Claro, si yo soy el dueño del Bar X, pues haré que mis camareros den menos vuelta y tengan prioridad. Y el que Bar Y se fastidie, que es la competencia.
Y claro, Y no puede hacer nada, porque conozco a sus camareros por donde salen, que es mi parte. Y yo puedo determinar por donde los mando para que lleguen a su destino, aunque le imponga restricciones.
¿Y qué pasa cuando se usa una VPN?
Pues que le estamos pidiendo las cervezas al bar, pero usando un camarero que oculta su identidad. ¡Así el ISP no saben de donde viene! Aunque sigue usando las mismas calles, puede tomar otro camino, que no esté influenciado por las políticas.
¿Y esto es legal? Aquí es donde se habla de parte de la neutralidad de la red. ¿Es lícito que un ISP priorice el tráfico de sus propias plataformas en su encaminado y en sus políticas de QoS? En Europa se garantiza que debe existir la neutralidad de la red, bajo el Reglamento UE 2015/2120.
Este reglamento prohíbe explícitamente bloquear, ralentizar o priorizar tráfico específico, pero deja un “posible” abierto, que es en caso de gestión de la red para evitar la congestión temporal.
Por tanto, ¿por qué a unos le llegan más cervezas que a otros si el bar es el mismo? No es problema del bar, porque entonces nadie recibiría cervezas. Tampoco es problema de los vasos ni de las mesas, porque son del bar y da los mismos a todos.
Pues porque hay caminos que están frenando o controlando la cantidad de camareros y lo que llevan en sus bandejas, porque están “gestionando” la congestión priorizando un tráfico frente a otro.
¿Y qué tráfico priorizan? Aquel que requiere tiempo real, como el streaming o la VoIP. Y cuales son las que perjudican… pues las descargas, que hacen un uso masivo de los canales y que además es competencia “directa” de su “bar”.
Además, el tráfico de Blizzard es muy fácil de identificar, ya que ya que utiliza protocolos y puertos específicos para su sistema de descargas, lo que hace que sea muy fácil de identificar por los “agentes”.
Así que si tu descarga va lenta usando un camino, pero si usas otro camino como una red móvil o una VPN, el problema está en el camino. Y más cuando estás usando el camino en las horas “calientes” de la competencia que compiten por el recurso.
Así que si, si el bar está haciendo llegar cervezas a otros clientes pero a tu mesa no llegan, no te quejes del bar, sino quéjate al camarero y del camino que esté siguiendo.
Un saludote ^_ ^