Soy consciente de que esta es una pregunta inusual, pero parece que es muy probable que las personas aquí sean las que puedan ayudar. Estoy intentando depurar con mi ISP por qué tengo retrasos extremos durante el juego.
Pregunta:¿Cuál es una buena manera de analizar el tiempo de ejecución y la pérdida de paquetes que me brinde información más detallada sobre dónde está el cuello de botella en la conexión? ¿Existe una manera fácil de reproducir el tráfico artificialmente hasta cierto punto sin tener que jugar?
Aquí está mi situación:
- Mi ISP proporciona mi conexión a través de una gran red inalámbrica con varios puntos de acceso a lo largo de unos 10 km antes de llegar al cable principal. Siempre ha sido así y en el pasado demostró ser extremadamente fiable. Debido a cambios en el hardware u otros cambios en la configuración de mi ISP, la calidad del juego disminuyó hace varios meses. Mi ISP es muy útil e intenta encontrar y solucionar el origen de los problemas.
- En general tengo un ping muy bueno y cuando juego, la información del juego siempre muestra un buen ping de 20-30ms.
- Una característica de Battlefield es que muestra símbolos de advertencia cuando la velocidad de fotogramas cae, el tiempo de respuesta de la conexión es malo o se pierden paquetes. La situación que se repite es que puedo jugar entre 10 y 60 segundos sin ningún símbolo de advertencia y luego experimento una pérdida severa de paquetes donde tengo retrasos y BF me muestra todo tipo de advertencias de conexión. Después de eso, puedo volver a jugar durante unos segundos antes de volver a ver este comportamiento.
Trabajo exclusivamente en Linux y me siento algo cómodo con ping, traceroute, nmapy otras herramientas de red. Conozco los puertos altos que utiliza BF, puedo averiguar los tamaños de paquetes utilizados y, por supuesto, puedo extraer IP de los servidores de juegos. ¿Cuál es una buena manera de comenzar a rastrear este problema para poder provocar la pérdida de paquetes artificialmente mientras mi ISP depura lo que sucede en su red?
Análisis
Instalé WireShark como amablemente me sugirió Moonpoint y capturé algunos minutos de juego lento. En un primer análisis, me concentré en los paquetes que provienen del servidor del juego. Filtré todos los paquetes UDP que provienen del servidor a mi IP y ajusté el tiempo para ver el tiempo relativo entre esos paquetes. Después de clasificar, hubo alrededor de 20 paquetes que tardaron entre 650 ms y 1300 ms, y sospecho que son aquellos en los que salto la mitad del mapa. Entre la mayoría de los otros paquetes tienen casi exactamente el tiempo de ejecución que veo como "Ping" dentro del juego de unos 30 ms.
Después de marcar todos los paquetes críticos, limpié el filtro y miré todo el tráfico para ver si puedo encontrar algún patrón de lo que sucede con todos los paquetes alrededor de los críticos. Lo que encontré es que hay dos situaciones. Tenga en cuenta que 94.250.208.153 es el servidor del juego y el resaltado azul es el paquete de juego UDP crítico:
Primero, alrededor de 10 a 15 paquetes antes del crítico hay un paquete místico SSDP M-Search proveniente de una dirección MAC:
La segunda situación es que el paquete crítico está precedido (o a veces rodeado) por una retransmisión TCP principalmente a un servidor de Google:
¿Existen otras medidas que pueda tomar por mi parte? ¿Alguien puede decirme cómo puedo investigar en el paquete místico SSDP?
Respuesta1
MTR, que combina la funcionalidad que se encuentra en ping y traceroute, también puede ser una herramienta útil para determinar el punto o puntos a lo largo de una ruta de red donde se produce la pérdida de paquetes o dondeestar nerviosoes alto (ejemplo).
También puedes utilizar el código abierto y gratuito.Wiresharkanalizador de paquetes para solucionar el problema, pero ser capaz de comprender la información que proporciona requiere estar familiarizado con cómo funcionan las funciones subyacentes.protocolos de internet, como TCP/IP, funcionan. Hay cursos y tutoriales sobre su uso en línea. Aunque aprender a utilizarlo de forma eficaz puede llevar bastante tiempo, una vez que aprenda a utilizar una herramienta como Wireshark, podrá solucionar más fácilmente todo tipo de problemas relacionados con la conectividad de red.
Si no está familiarizado con Wireshark, en YouTube hayTutorial de WireShark para principiantesyWireshark 101: Cómo usar Wireshark, Haktip 115; Se pueden encontrar muchos otros buscando los términos "tutorial de Wireshark". Los sitios web con tutoriales incluyenTutorial rápido y sucio de Wireshark,Cómo utilizar Wireshark para capturar, filtrar e inspeccionar paquetes, yTutorial de Wireshark, que es un archivo PDF creado porProfesor Angelos Stavrouen el Departamento de Ciencias de la Computación de la Universidad George Mason. También hay cursos en línea disponibles sobre cómo utilizar Wireshark.
Con Wireshark, otcpdump, una herramienta de captura de paquetes de línea de comandos disponible para Linux, OS X y Microsoft Windows (WinDump), puede capturar los paquetes que fluyen desde y hacia su sistema cuando ocurre el problema para que pueda analizar los datos usted mismo más tarde o en tiempo real, o, dado que ambas herramientas pueden guardar los datos que ha capturado como unpcaparchivo, puede proporcionar los datos al personal de soporte de red de su ISP, ya que su personal puede estar familiarizado con la interpretación de dichos datos, ya que los archivos pcap son un método común para intercambiar datos sobre un problema de red entre ingenieros de red al depurar un problema.
Wireshark capturará todos los datos en una interfaz de red, pero como conoce los números de puerto de red y las direcciones IP asociadas con los servidores del juego Battlefield, puedeutilice un filtro Wireshark para filtrar por número(s) de puerto y/o dirección IP.
Actualizar:
ElhexadecimalLos dígitos que vio asociados con el "paquete SSDP M-Search" no son uncontrol de acceso a medios (MAC)DIRECCIÓN. Las direcciones MAC son similares a 50-c5-8d-26-c2-06, es decir, las direcciones MAC de Ethernet y Wi-Fi generalmente se muestran con guiones o dos puntos entre cada dos dígitos hexadecimales con un total de 12 dígitos, es decir, son 48. direcciones de bits. Lo que estás viendo es, en cambio, unaIPv6dirección: hay dos versiones del Protocolo de Internet que se utilizan hoy en día en Internet, la utilizada desde hace mucho tiempoProtocolo de Internet versión 4 (IPv4)y la más reciente versión 6 del Protocolo de Internet (IPv6).
SSDP significaProtocolo simple de descubrimiento de servicios, que es un protocolo utilizado paraPlug and Play universal (UPnP). Algún sistema en su red local, el que tiene dirección IPv6 fe80::50e7:d4f0:db:c4dc, está enviando un paquete a unmultidifusión IPdirección, ff02::c. Para IPv4, la dirección de multidifusión es 239.255.255.250 mientras que SSDP sobre IPv6 usa la dirección establecida ff0X::c para todos los rangos de alcance indicados por X ("X" en el paquete que vio es "2").
No sé por qué su sistema se comunica con elServicios web de Amazon (AWS)Dirección IP ni la dirección de Google.
C:\>nslookup 52.203.205.255 8.8.8.8
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Name: ec2-52-203-205-255.compute-1.amazonaws.com
Address: 52.203.205.255
C:\>nslookup 216.58.212.78 8.8.8.8
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Name: lhr35s05-in-f78.1e100.net
Address: 216.58.212.78
Veo que la conexión es al puerto 443, elpuerto conocidopara el tráfico HTTPS, pero cuando realicé un52.203.205.255 Búsqueda inversa de IPusando herramientas de dominioBúsqueda inversa de IPcapacidad, informó "No encontramos ningún resultado para su búsqueda". A menudo, ingresar una dirección IP en esa herramienta de búsqueda le mostrará lanombres de dominio completos (FQDN)para sitios web alojados en la dirección IP (se pueden alojar varios sitios web en la misma dirección IP), pero no en este caso.
A216.58.212.78 Búsqueda inversa de IPdevolvió el mismo mensaje. Si ve un 1e100.net, es un sistema de Google. Google usa "1e100" en el nombre porque es una forma de representar un "1" seguido de cien ceros, lo cual es unagoogol.
Es posible que ambos paquetes no estén relacionados con las comunicaciones con el servidor de Battlefield. El hecho de que sean retransmisiones, que se envían cuando un sistema envía un paquete, pero no recibe un paquete de confirmación del otro lado que indique que fue recibido, puede indicar que el tráfico a otros sitios también está experimentando pérdida de paquetes en el Al mismo tiempo que tienes problemas con el servidor de Battlefield. Puede filtrar esas dos direcciones IP para ver otros paquetes hacia/desde ellas y tener una mejor idea de por qué pueden aparecer en la captura de paquetes, si estuviera interesado en saber por qué su sistema se comunica con esas dos direcciones IP.