[Guía básica del juego] La mega guía de Ping, lag, IP, TCP, UDP y demás

  • Guia del Juego
  • [Guía básica del juego] La mega guía de Ping, lag, IP, TCP, UDP y demás

    Introducción


    Dado el auge de los juegos con características "online" y que ademas estamos en un foro pertinente a uno de estos juegos se hace necesario explicar de forma breve como realmente funciona esto que mal denominamos internet y que caracteristicas determinan nuesta jugabilidad.

    En definitiva, lo que se va a intentar en este hilo es explicar que coño es eso de ping y porque con mis 100 megas tengo 300ms.

    Indicar que realmente lo que me motivo a escribir esta guia fue un post por parte del usuario [NICK]esteso que podeis encontrar aqui [Actualización 5.1] Live Stream

    El primero que quiero que entendais (Aparte de que Internet no es Google) es entender que lo que denominamos Internet no es mas que una mezcla hetereogenea de distintas redes donde numerosas organizaciones y entidades donde cada uno intenta seguir el estandard TCP/IP a su manera.

    En el caso que nos atañe tenemos numerosos participantes, en un principio estara nuesta red domestica (Si, tienes un router tienes una red domestica), para continuar con la red de nuestro proveedor de Internet, luego disitntos organismos gubernamentales y distintos "proveedores" de internet (En adelante ISP) que ira haciendo que nuestra conexion "salte" entre distintos nodos hasta, finalmente, alcanzar el ISP de Gameforge, su red local y sus servidores (Todo esto se puede monitorizar y os enseñare como hacerlo mas adelante).


    Historia de internet... bueno, mejor dejemonos de historias...


    Internet nace como medio para compartir hiperdocumentos cientificos usando una tecnologia militar (ARPANET). Desde ahi ha evolucionado hasta lo que manejamos hoy en dia, por el camino se han ido estableciendo ciertas "normas" de como deben hacerse las cosas, lo que al fin y al cabo se denomina estandar.

    Para entender esto ultimo debeis comprender que cuando se define algo en terminos de informatica se determina como y cuando algo debe hacerse, dando normas para que todos los sistemas tengan piezas "interoperables", porque, en Informatica, existen miles de formas de solucionar un unico problema. Un ejemplo es que para pintar un simple caracter como puede ser la letra "a" requiere una gran coordinacion entre numerosos componentes de un unico sistema. Por suerte, a dia de hoy, esto es una tarea trivial ya que trabajamos con componentes virtuales (Software) que facilitan esto en raiz a distintos estandares de comunicacion que se han establecido a nivel fisico (Hardware).

    Imaginad la dificultad de comunicar dos sistemas distintos, donde no solo dispongan de hardware distinto (Distinta arquitectura de procesador por ejemplo) si no que incluso operen con un sistema operativo distinto. Para solventar estas limitaciones nacio el estandard TCP/IP que, al final, se convirtio en la base de lo que hoy conocemos como Internet.


    TCP/IP o como hacemos que A y B hablen entre ellos


    TCP/IP es la base de Internet, todos los sistemas que utilizan esta gran red se comunican usando los conceptos básicos de este protocolo.

    TCP/IP es un sistema en capas, donde la capa mas inferior es las mas cercana al funcionamiento fisico mientras que la mas superior es la que permite trabajar de una forma abstracta. Esta división en capas permite a los programadores abstraerse de como se transmiten la informacion (Si es por ondas, por cable etc) y centrarse en como su aplicación debe gestionar la comunicacion.


    Como estan estructuradas las distintas capas de TCIP/IP y donde se asientan cada uno de los protocolos

    Empezando de abajo arriba tenemos lo siguiente:

    Physical Layer bip bip bip
    En esta capa se vana a asentar los protocolos que van a permitir que dos dispositivos se comuniquen de forma física. Esto quiere decir que si un ordenador y un router estan comunicados a través de un cable, el protocolo que usaran (Ethernet) debe indicar que voltajes deben usar, tiempos etc. Si, en cambio, lo hicieran a traves de Wifi (802.11) cuales deben ser las frecuencias, tiempos de espera etc.

    Lo importante es que en esta capa solo se permite la comunicacion directa de sistema a sistema, por lo cual, dichos sistemas deben estar situados de forma proxima.

    Data Link Layer

    Si en la capa anterior definiamos como dos dispositivos proximos pueden comunicarse a traves de un medio en esta capa crearemos la primera abtracción a fin de que "se entiendan" (En esta capa se establecen muchos mecanismos de redundancia de datos a fin de poder establecer mecanismos de comprobacion de errores):

    Mientras que en la capa anterior se definia como iva a intepretarse los distintos cambios del medio a fin de determinar su valor, en esta capa se intenta genera lo que se denomina como trama, un conjunto de cambios de estado que tendran representacion binaria "01001101".

    En esta capa se define lo que se conoce como MAC Address o direcciones fisicas. Todos los componentes de comunicacion (Ya sean Ethernet, Wifi, etc) poseen una dirección unica la cual no puede ser duplicada, esta direccioon es la que permite identificar un dispositivo en una red local como receptor de una trama especifica..


    Imagen de una etiqueta situada en un router que indica su MAC Address


    Network Layer [em]Una dirección IP para dominar el mundo...[/em]

    En la capa anterior eramos capaces de poder comunicarnos con cualquier dispositivo a nuestro alcance indicando su dirección MAC. A partir de esta capa podremos comunicarnos con el resto del mundo.

    Para ello nace el direccionamiento IP, o como algunos dirian, esos 4 numeros que dicen donde resido... Una dirección ip es un conjunto de 4 bytes (32 bits) expresados en su forma decimal sin tener en cuenta su valor negativo. Cada conjunto puede tomar un valor que oscila desde el 0 hasta el 255, de esta forma, obtenemos IPs tales como 216.58.214.163 (google.es), 79.110.83.131 (gameforge.com), etc.

    El protocolo, a fin de comunicar distintas redes entre ellas, utiliza lo que es conocido como enrutamiento, mediante el enrutamiento, los datagramas (conjuntos de tramas proporcionados por la capa anterior) viajan por dintos enrutadores hasta alcanzar el destino.


    Esquema que presenta la telaraña de Internet

    Tomando la imagen anterior, cuando un datagrama del cliente quiere alcanzar el servicio de internet se efectua aproximadamente las siguientes operaciones:

    - El ordenador cliente envia a su puerta de enlace (Su router) el datagrama espeficando la IP del servicio.
    - El primer ruter comprueba la IP del servicio, si tuviera registrado un camino para dicho rango de IP enviara directamente el datagrama, si no, enviara una peticion de "discover" al resto de ruters conocidos a su alcance.
    - Cuando el resto de ruters reciben el "discover" buscan en su registro a ver si tienen el camino, en caso negativo mandan otra peticion de "discover".
    - El proceso se continua hasta que el ruter al que esta conectado el servicio contesta indicando que el "conoce" la IP, asi que empieza a mandar señales hacia atras a fin de establecer el camino
    - Con el camino ya establecido el primer ruter envia el datagrama al ruter escogido y este lo repilca.. asi hasta alcanzar el servicio.
    Esto es una aproximación y una abreviacion de como funciona el direccionamiento IP, se que cometo algunas falacias pero explica de forma escueta mas o menos como funciona

    Es por lo que cuando hablamos de Internet hablamos de saltos ("hops") que nuestra señales deben atravesar al fin de alcanzar el destino.


    Direcciones IP de los distintos servidores
    [DE] Loki - 79.110.83.69
    [EN] Deyla - 79.110.83.66
    [EN] Antrishka - 79.110.83.68
    [EN] Hellion - 79.110.83.77
    [FR] Hyperion - 79.110.83.73
    [DE] Thor - 79.110.83.70
    [FR] Urtem - 79.110.83.72
    [PL] Barus - 79.110.83.106
    [INT] Rookie 2 - 79.110.83.101
    [INT] Union1 - 79.110.83.87
    [INT] Union2 - 79.110.83.89
    [INT] Pangea1 - 79.110.83.96


    Para concer el numero de "hops" que se realizan entre tu cliente y una dirección IP tenemos de serie la herramienta tracert en Windows (traceroute en Linux) que nos permite saber por cuantos ruters nuestros datagramas trasncurren hasta alcanzar la direccion indicada


    Traza al servidor de Hellion

    Transport Layer

    En la capa anterior ya podiamos llegar a la puerta de un sistema y entregarla un datagrama, el problema ahora radica que un sistema puede estar corriendo numerosas aplicaciones al mismo tiempo asi que deberiamos de poder indicar a que aplicacion hemos de entregar dicho datagrama. Para eso, esta capa determina que a cada segemento (basicamente un datagrama IP con información adicional) posee un identificador de aplicación denominado comunmente "puerto", de forma que el sistema operativo es capaz de otorgar a la aplicacion que es encuentra en la capa superior un segemento que le pertenece y no el de una aplicacion distinta.

    A parte de asignar puertos esta capa ordena los segmentos otorgados por la capa inferior (pueden venir en ordenes distintos a los que fueron enviados), asi como comprobacion de errores, etc.

    En esta capa se asientan dos protocolos muy importantes, conocidos como TCP y UDP.

    - TCP: establece sincronia entre emisor y receptor, es decir, una serie de pasos al fin de que la conexion se inicie, se mantenga abierto y por ultimo se cierre.
    - UDP: Es un protocolo sin sincronia, tras "abrir" una conexion se empiezan a enviar mensajes sin sincronización entre emisor y receptor y se puede cerrar de forma abrupta.

    A efectos sencillos estas son las diferencias, indicar que TCP hace que cada segmento tenga un mayor peso (mayor cantidad de bytes) que el protocolo UDP pero permite gestionar de una forma mas eficiente un recurso limitado como es el maximo de conexiones que se pueden establecer.


    Application Layer o como hacer que todo esto valga la pena

    En la parte superior tenemos la capa de aplicacion, donde realmente los programadores y desarrolladores nos movemos. En esta capa se pueden ubicar muchisimos protocolos como HTTP, FTP, P2P, etc... es donde construimos nuestras aplicaciones que usaran las capas inferiores para lograr una comunicacion que nosotros interpretaremos.

    A nivel de programacion habitualmente hablamos de sockets, que son conexiones TCP entre una aplicacion cliente y una aplicacion servidora. Cuando el socket se encuentra en la aplicacion cliente lo llamamos como un socket saliente mientras que cuando radica en la aplicacion servidora tenemos los sockets a la escucha (Realmente tendremos una fabrica de sockets como indicamos mas abajo).

    Os pondre un ejemplo de como utilizamos este "stack" los programadores a fin de crear una aplicacion simple que responda todos los mensajes que reciba.

    Aplicacion cliente
    1. Se crea un socket TCP dando como destino la direccion IP del servidor asi como el puerto en el cual estara a la escucha
    2. Se inicia la conexion del socket
    3. Se envia un mensaje a traves del socket, en este ejemplo el mensaje sera la cadena de texto plana "hola"
    4. Esperamos que el servidor conteste creando un mini bucle que estara pendiente de si recibimos datos por parte del servidor
    5. Una vez recibimos el mensaje completo del servidor, lo imprimimos por pantalla
    6. Cerramos el Socket

    Aplicacion servidor
    1. Creamos una "fabrica de sockets" a la escucha en un puerto determinado, esta fabrica lo que hara es esperar conexiones entrantes y, al recibir una, generara un socket con al conexion ya establecida (Habra hecho el Handshake o el saludo TCP).
    2. Una vez tenemos el socket abierto con el cliente, esperamos a recibir su mensaje con un minibucle.
    3. Tras recibir el mensaje escribimos en el socket la respuesta, el texto plano "ey, ¿que tal estas?"
    4. Volvemos a poner el socket a la espera de que el cliente cierre la conexion (Podria cerrarlo el servidor... pero para este ejemplo mejor lo dejamos abierto).
    5. Recibimos el cierre de socket por lo cual lo eliminamos.

    Si se ejecutara en una maquina la aplicacion cliente funcionaria exactamente igual que si se ejecuta en 1000 maquinas distintas sin importar la ubicacion donde residan las maquinas. Para esto es para lo que sirve todo el stack TCP/IP.


    Pendiente: Correciones ortograficas
  • Pero... toda esta mierda, ¿¿que tiene que ver con que tenga mucho Ping en el AION??


    Se que lo de arriba es un tochazo pero establece las bases para que ahora pueda hablar con tranquilidad de ciertos terminos tecnicos y que no parezca que este hablando en un idioma de mordor.

    ¿Que es el ping?

    Ping es una medida usada en las conexiones que nos indica la latencia de una conexión. Se mide en milisegundos (1/1000 segundos) y refleja el tiempo que un datagrama tarda entre ir y volver del servicio. Existen muchas implementaciones siendo la mas conocida la que usa el protocolo ICMP, existen otras como la de usar un servicio de echo o ping (Basicamente la aplicacion cliente manda al servicio un mensaje que debe responder lo mas rapidamente posible).

    Existe una aplicacion ampliamente conocida que permite "medir" el retraso de una conexion usando el protocolo ICMP, esta es el comando de MS-DOS conocido como ping.


    Ping efectuado desde un sistema Linux ubicado en Vigo (Galicia) al servidor Hellion

    Los resultados de latencia pueden verse afectados por inumerables factores, cito algunos:

    - Sobrecarga del sistema cliente: Existe un limite de conexiones y de capacidad de transmision / recepcion en todos los sistemas que viene determinado por el propio hardware, si se sobrepasa dicho limite el sistema operativo debe poner ciertas conexiones (las que menos prioridad tengan) en espera.

    - Sobrecarga del medio entre el cliente y ruter: Como indicaba en la capa fisica, existen muchisimas formas de transmitir informacion entre dos sistemas, las mas conocidas son Ethernet (Cable) y Wifi, pero puede realizarse a su vez a traves de conexiones bluetooth, laser, etc. Un clasico ejemplo es que el protocolo 802.11 (WiFi) tiene una carga adicional de redundancia que hace que los valores de ping sean superiores a los usados a traves de ethernet (Podemos hablar de 5 a 20ms), estos problemas son facilmente detectables (Al final de la guia pongo como hacer analisis de estas situaciones).

    - Sobrecarga de cualquier router entre el cliente y el servicio: Todos los routers deben de hacer tareas como los "discover" ademas de encaminar los datagramas a su siguiente destino. Puede darse el caso (Y de hecho se da) de que un router se encuentre sobrecargado o bien no responda. Si se encontrara sobrecargado atendera los datagramas por orden de prioridad (No usan siempre colas FIFO) y, si no respondiera, el router anterior debera empezar una tarea de "discover", (En estos casos o da lag o directamente se perderia la conexion).

    - Sobrecarga del servicio: Cuando estamos realizando una conexion a un servicio esperamos que, al menos, procese la informacion. Recordemos que la latencia o ping se mide en tiempos de ida y vuelta por lo cual todo el tiempo que el servicio precise para procesar dicha conexion seran milisegundos adicionales.

    - Bucle de enrutamiento: No es tan anomalo, simplemente que cuando un router dirige un datagrama al siguiente router, este de alguna manera acaba enviandolo a uno de los router que procesaron el mensaje anterior. Cuando sucede esta situación habitualmente el datagrama caduca y se pierde obligando a la aplicación cliente a reenviarlo o al servidor cortar la conexion. (Los datagramas tienen un TTL o un tiempo de vida que es un indicador de cuantos saltos pueden hacer, con cada "hop" los router van restando 1 a dicho valor hasta que alcanza el valor de cero, en estas situaciones el datagrama deja de redireccionarse).

    ¿Que es el lag?

    El lag es un incremento desorbitado de latencia que puede incluso cortar la conexion con el servicio. Tiene muchisimos origines como el de routers que no contestan o bien distintos bucles de enrutamiento, aunque el mas habitual es una sobrecarga en la red local del cliente. Suele ser un incremento temporal y pasajero que se disuelve cuando se descongestiona el problema.

    ¿Que es el ancho de banda?

    Mucha gente piensa que, por tener un mayor ancho de banda debe de reducirse el ping, cosa que no es del todo cierta. El ancho de banda define una caracteristica mediante la cual podemos determinar el maximo de bytes por segundo que podemos tener tanto de recepcion como de envio.Se mide en bytes por segundo (B/S) aunque suele usarse algun multiplo del Byte a fin de facilitar su lectura (KB/S, MB/S, GB/S, TB/S, PB/S).

    Este limite suele imponerlo el ISP sobre el router de un cliente de forma que cuando se alcanza dicho limite el router debe empezar a usar colas de prioridades ya que no puede sacar ni recibir todos los mensajes al mismo tiempo.

    Es la unica confluencia que existe entre el ancho de banda y el ping, en un sistema "zero" (cero conexiones en reposo) nunca se va a abarcar completamente el ancho de banda limite de un router cuando se establecen las conexiones que ejecuta en este caso el AION.

    Detectar problemas con el ancho de banda es bastante complejo ya que en este caso el sistema afectado (El router) no tiene herramientas que nos faciliten mediciones a tiempo real de su trafico. La mejor manera consiste en monitorizar con todos los sistemas desconectados y un sistema "zero" que efectua las comprobaciones. Ir encendiendo sistemas poco a poco e ir viendo como afecta a la conexion...

    ¿Que es eso de timeout?

    Timeout simplemente refleja que algo caduco por tiempo... En el caso de conexiones es un tiempo preestablecido que indica si algo responde o no.

    Si se produce un timeout en el servicio por inactividad del cliente (No enviar datos de sincronizacion) este cerrara la conexion. A su vez, los routers pueden producir timeouts al encaminar hacia el siguiente "hop" haciendo que deban optar por una via secundaria.


    A mejor procesador, mejor ping

    Este es otro error bastante comun aunque en algunas ocasiones si que es cierto, para gestionar las conexiones el sistema operativo debe usar tiempo de procesador (Si, el sistema operativo determina quien puede procesar y quien no... es complejo pero paso de explicarlo) asi que si dicho procesador esta "sobrecargado" se producira un incremento de tiempos bastante alto. Pero esto solo ocurre cuando la carga del procesador esta al 100% asi como la memoria RAM con un 100% de carga, lo que, a terminos de juego, se va a traducir en 2-3 fps que provocan que el juego no vaya para nada fluido (Y paso de meterme en como funciona un juego por dentro).


    ¿Que es una VPN/Tunelador?

    De todos es sabido que usar servicios como Battleping o WTFast mejoran la latencia de los juegos. Esto es debido a que usan VPN privadas tuneladoras.

    Para empezar, una VPN es una red privada virtual (No explique redes privadas pero basicamente son redes que no se pueden acceder a traves de internet sin mecanismos especiales), lo que permite que los ordenadores que utilicen dicha VPN puedan usar caracteristicas propias de las redes privadas como compartir recursos, etc

    Un servicio VPN tunelador a su vez codifica las conexiones en esta red para que parezcan de protocolos distintos saltando asi las colas de prioridade los enrutadores.

    Un ejemplo clasico es que la mayoria de MMROPG utilizan el protocolo UDP a fin de crear las conexiones con sus clientes (necesitan alta disponibilidad asi que la sobrecarga de TCP no es valida), pero los ISP (Proveedores de servicios y dueños de los ruters mediante los cuales haces los distintos saltos) le asignan a los datagramas UDP una prioridad muy baja en su sistema a raiz de que no precisan sincronia (Ironico no? se usa UDP para agilizar y ahcer las conexiones mas rapidas y los ISP los penalizan por no ser sincronizados).

    Al usar un tunelador estos paquetes UDP se encapsulan y enmascaran como paquetes TCP de la VPN de forma que se saltan la baja prioridad de los ISP permitiendo obtener bajas latencias


    ¿Porque no usar entonces TCP para el juego?

    Porque los efectos de usar TCP en vez de UDP serian todavia mas perjudiciales. TCP es un protocolo super redundante, por cada mensaje envia una confirmacion, y cuando se pierde un paquete el propio protocolo espera hasta haberlo recibido de vuelta desde el origen. Todas estas caracteristicas implicarian que se requeriria muchisimo mayor ancho de banda y conexiones practicamente 100% fiables para poder crear aplicaciones en tiempo real (Si, los MMROPG son aplicaciones en tiempo real).

    UDP en cambio no genera tanta redundancia y la perdida de paquetes aunque es real (1-5%) no tiene un gran impacto cuando la informacion fluye adecuadamente. Si quereis mas informacion os recomiendo este artículo gafferongames.com/networking-f…e-programmers/udp-vs-tcp/

    La culpa del ping es completamente de la ineficacia de los servidores de Gameforge

    No nos equivoquemos, tanto el uso de CPU y RAM como el ancho de banda de los servidores es muy importante pero cuando estos estan sobredimensionados (en un post que suministraron en el foro de UK indicaron que el consumo de RAM y CPU apenas llega al 10%) se pueden descartar de la ecuación. Si que es cierto que a la hora de medir la latencia se contabiliza cuanto tarda el servidor en retornar la información pero esta para ciertos jugadores apenas oscila entre los 5-10 ms, asi que, salvo periodos de carga excesivos y problemas con su red interna podriamos descartar que sea culpa de los servidores de Gameforge

    Si no soy yo y no es Gameforge, entonces ¿De quien es la culpa?

    Puede que la culpa sea tuya y todavia no entiendas las razones (Sobrecarga de tu sistema, medio o tu router), mas adelante te dare herramientas para que determines si es tu problema.

    Si descartas tu pequeña red local y descartamos a mayores los servidores de Gameforge solo nos queda que los responsables se ubican entre tu ISP y el ISP de la compañia. Como ya te he comentado es facil que uno de los routers europeos este caido o la mala praxis de bajar prioridad a ciertos paquetes UDP (afectando de forma muy sensible a la latencia)

    ¿Que podemos hacer si no es ni culpa nuestra ni de Gameforge?

    Poco, salvo usar un tunelador que dependiendo de ciertas caracteristicas puede incluso ser una peor opcion (debido a la redundancia, saturacion, etc). Quizas debas ocupar tu tiempo a jugar juegos como el buscaminas... pero vamos, principalmente da las gracias a estos grandes gobiernos europeos que permiten que Internet no sea igual para todos

    Y si ponen un servidor de replicación en España

    Lo veo una perdida de tiempo y esfuerzos por distintas razones. Para empezar, un servidor de replicacion debe estar conectado de alguna manera al servidor central para obtener y actualizar los cambios, lo que a su vez daria una redundancia mayor (y probablemente tambien sufriria de problemas de latencia). Aparte de que seguramente la nueva arquitectura precisara de cambios sustanciales tanto en el cliente como servidores a fin de que la sincronización sea viable.

    Es una medida que en aplicaciones de tiempo real centralizadas no suele optarse por los inconvenientes tecnicos que plantea y a la larga incrementaria tiempos de mantenimiento y posiblemente crearia un gran impacto en el rendimiento general del juego

    Una opcion que si que es viable y que resolveria todos los problemas de latencia de golpe residiria en que abrieran un servidor exclusivo en España (con ubicación en Madrid, Barcelona, etc), esto solventaria los problemas de latencia en una medida increible

    Pendiente: revisión y correcciones ortograficas
  • Como analizar mi red local y detectar posibles problemas de red


    Para esta sección vamos a asumir que tienes una arquitectura típica con un modem router y uno o varios sistemas conectados al mismo bien sea a traves de ethernet (cable) o bien a través de Wifi.

    A su vez consideraremos que el sistema operativo presente en el sistema principal donde se efectuaran las pruebas sera un Windows 7, 8 o 10 (Yo, en mi caso, hare las pruebas y pegare pantallazos desde un Windows 7).

    Herramientas básicas

    Antes de empezar debeis de ser capaces de controlar una serie de herramientas básicas que nos daran distintas estadisticas y valores sobre nuestro sistema

    - Consola: Facilmente accesible accediendo al dialogo de ejecutar (Tecla de windows+R) y escribiendo "cmd" (Sin comillas" en el cuadro. (Has de pulsar en el boton ejecutar, claro esta...)



    - Administrador de tareas: Boton derecho en la barra de windows y en el menu desplegable pulsar en el Administrador de tareas.



    - Monitor de recursos: Desde el propio administrador de tareas existe un boton "recursos" en la pestaña recursos.



    - Monitor de servicios: Desde el propio administrador de tareas existe un boton "servicios" en la pestaña servicios.



    Primeras comprobaciones, que mierda esta pasando en mi PC

    Lo primero que deberemos hacer es acceder al monitor de recursos y en la pestaña de red dejar que carguen poco a poco todas las conexiones de red que han abierto las distintas aplicaciones que estan corriendo en el sistema.

    El monitor de recursos es una herramienta muy practica que permite ver que ancho de banda esta consumiendo cada uno de los procesos.


    En esta imagen podemos ver el ancho de banda consumida por un video de youtube ejecutado a full HD

    Debemos ser capaces de de identificar que procesos hemos abierto y cuales estan consumiendo datos en segund plano sin que nos demos cuenta. Como norma general, con el sistema en reposo y recien arrancado no deberiamos tener ninguna carga de datos ya que todavia no se ha iniciado ninguna aplicacion. Si esta situacion no es asi depende muchisimo de que proceso es y si queremos o no que este funcionando en segundo plano.

    Una vez hemos limpiado procesos que estan chupando red porque si, hemos hecho uno de los primeros pasos para obtener un sistema "zero", simplemente cargar el juego con el monitor abierto y hacer comprobaciones de ping.


    En esta imagen podemos ver el proceso de AION ejecutandose

    Es mas que probable que cuando intentemos matar algun proceso que este haciendo carga de red (Por ejemplo el de Onedrive) el muy hijo de fruta vuelva a arrancarse. Esto es porque es un servicio y debes parar el mismo (Identificar el servicio es algo complejo y debes hacerlo viendo su PID).

    Una de las maravillas del monitor de recursos es que puedes ver las conexiones que un proceso ha efectuado y podremos incluso obtener el ping "general" que tienen dichas conexiones


    En esta imagen podemos ver las conexiones TCP iniciadas por el AION