Introducción
Willow Games tiene dos enlaces de red y dos tipos de trabajo: pequeñas actualizaciones del marcador y grandes archivos de sonido para los ensayos. Ambos servicios ya funcionan, pero el enlace que responde antes puede no ser el que entrega antes un archivo grande.
Probarás entregas normales, compararás el retardo y el rendimiento de subida al mismo destino por ambas rutas y restaurarás la ruta original después de cada experimento. Necesitas manejo básico del terminal y saber leer un destino, un siguiente salto y una ruta de alcance limitado, como se enseña en el proyecto de enrutamiento anterior o mediante práctica equivalente. No se presupone experiencia en programación, codificación multimedia, regulación de tráfico ni iperf.
Usa Event Client para todos los comandos y Event Receipts para leer los registros de los receptores. Cada laboratorio prepara su propia red aislada y no necesita nada de una VM anterior. Los 45 minutos son una estimación del autor que incluye lectura y errores habituales, no un tiempo de finalización medido con principiantes.
Prueba una actualización pequeña y una entrega grande
En este paso usarás una mesa de resultados que ya funciona y después realizarás dos entregas reales de demostración. Empieza en Event Client. Este terminal es el shell de administrador dentro de un espacio de nombres de red Linux aislado, situado ya en /home/labex/project/event-links. El receptor está en otro espacio de nombres; ambos comparten el núcleo de una VM. No uses un shell de la plataforma para estos comandos. Abrir la pestaña no reconstruye la red.
Willow Games necesita interacciones rápidas con el marcador y archivos de sonido de ensayo completos. Una petición pequeña dedica gran parte del tiempo a esperar el viaje de los paquetes; una subida grande también necesita capacidad suficiente para transportar sus bytes. La latencia es el retardo del recorrido y el rendimiento es la cantidad de datos útiles entregados por segundo. Ninguna de las dos magnitudes describe por sí sola todos los trabajos.
pwd muestra el directorio de trabajo. cat muestra un archivo. Si un comando indica que falta un archivo, comprueba la escritura y usa el comando cd completo siguiente para volver al espacio de trabajo; un error al escribir no requiere reiniciar la VM.
pwd
cd /home/labex/project/event-links
cat links.tsv
Las dos filas identifican lane1 y lane2, sus siguientes saltos y las direcciones de origen de este cliente. Un siguiente salto es el vecino que recibe un paquete de camino al destino. El destino de los resultados es 10.205.10.10; el de los archivos multimedia es otra dirección, 10.205.10.20. Ambos escuchan en el puerto 8080. La preparación establece el retardo y la capacidad de los enlaces; deja intactos la regulación del tráfico, las direcciones y los servicios.
Empieza con un resultado existente que funciona. curl transfiere un recurso HTTP. --noproxy '*' evita la configuración de proxy del entorno para todas las direcciones; las comillas impiden que el shell expanda el comodín. -f hace que los errores HTTP provoquen un fallo, -s oculta el indicador de progreso y -S sigue mostrando los errores. Estas opciones combinadas se escriben -fsS. --max-time 35 limita toda la transferencia a 35 segundos. La URL elige el destino real, el puerto y el recurso.
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.10:8080/reference
Espera ver warmup, un resultado 1–1 y preserved. Este ejemplo normal debe seguir disponible. No es tu nueva entrega.
Lee el resultado de demostración, representado en JSON: las llaves encierran campos con nombre, las cadenas usan comillas dobles y los dos resultados son enteros.
cat source/demo.json
Espera el partido demo, local 1, visitante 0. -H establece el tipo de contenido HTTP. --data-binary @source/demo.json lee exactamente ese archivo y lo envía mediante HTTP POST; @ indica un cuerpo de archivo. -w muestra un pequeño resultado de tiempo tras la respuesta. En su cadena entre comillas simples, \n significa un salto de línea y %{time_total} los segundos transcurridos. Copia todo el comando en una sola línea:
curl --noproxy '*' -fsS --max-time 35 -H 'Content-Type: application/json' --data-binary @source/demo.json -w '\nseconds=%{time_total}\n' http://10.205.10.10:8080/scores
Lee match, los resultados, peer_ip y local_ip del recibo. Identifican lo que aceptó el receptor y el origen y destino reales de la conexión. Repetir un POST para el mismo partido reemplaza el recibo de ese partido; no crea partidos duplicados.
El archivo preparado demo.wav es un tono original de prueba de sonido de dos segundos, con audio PCM WAV válido. No necesitas crear ni codificar archivos multimedia. -T sube el cuerpo del archivo mediante HTTP PUT. Repetir un PUT con el mismo nombre reemplaza esa tarea multimedia.
curl --noproxy '*' -fsS --max-time 35 -T source/demo.wav -w '\nseconds=%{time_total}\n' http://10.205.10.20:8080/media/demo.wav
El recibo incluye el número de bytes y el resumen SHA-256 del contenido. Un resumen representa los bytes; resúmenes coincidentes respaldan la identidad del contenido, mientras que el nombre por sí solo no la demuestra. Para comparar el archivo realmente recibido, descárgalo de nuevo. -o guarda la respuesta en la ruta indicada. cmp compara cada byte y no muestra nada si coinciden:
curl --noproxy '*' -fsS --max-time 35 -o received/demo.wav http://10.205.10.20:8080/media/demo.wav
cmp source/demo.wav received/demo.wav
Cambia a Event Receipts y selecciona Refresh receipts. Abre Existing demonstration receipts y busca tu resultado demo y demo.wav. La página lee los receptores reales a través de Event Client; nunca completa los registros ausentes desde la carpeta de origen. Las tarjetas principales esperan las tareas nuevas del próximo laboratorio.
La sección de demostración desplegada a continuación muestra el resultado demo aceptado y la identidad de demo.wav, el resumen de contenido y los orígenes reales de conexión. En este momento es normal que las tarjetas principales sigan esperando.
Si curl termina con 7, no pudo conectarse: vuelve a Event Client y comprueba la dirección, el puerto y el comando ip route get que se enseña a continuación. El código 28 indica que venció el plazo, no un rechazo HTTP. El código 22 indica un error HTTP. Con -f, curl informa del estado HTTP pero omite el cuerpo de la respuesta de error; compara la ruta exacta del endpoint y el archivo JSON o cuerpo proporcionado. Lee el origen indicado con cat y corrige el comando conservando los archivos entregados. Una conexión correcta con la tarea equivocada sigue siendo un resultado de negocio incorrecto.
Mide el retardo de cada ruta
En este paso compararás una muestra limitada de retardo al mismo destino por cada enlace. Empieza en Event Client. Todos los comandos se ejecutan en este mismo cliente; solo cambia la ruta del destino multimedia. Conserva las rutas del marcador y de referencia, la ruta predeterminada, las interfaces, los archivos de origen y la regulación del tráfico.
ip route show enumera las rutas actuales. /32 selecciona exactamente un destino IPv4. ip route get consulta qué ruta y origen usaría el núcleo; no envía paquetes. Lee la ruta multimedia actual antes de modificarla:
ip route show
ip route get 10.205.10.20
Espera via 10.205.1.1 dev lane1 src 10.205.1.2. Recuerda esta ruta original: la restaurarás después de cada experimento. Este curso usa una ruta predeterminada preparada dentro de la red aislada; no proporciona acceso a Internet.
ip route replace añade o reemplaza solo la ruta del destino indicado. via selecciona el siguiente salto y dev la interfaz de salida. Reemplazar un /32 no reemplaza la ruta predeterminada. Primero establece explícitamente la prueba por lane1:
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
ping envía peticiones de eco ICMP. -n muestra direcciones numéricas, -c 4 se detiene tras cuatro peticiones y -W 2 espera como máximo dos segundos por una respuesta. El tiempo de ida y vuelta (RTT) incluye el trayecto de ida y la respuesta; no es un retardo de un solo sentido ni una respuesta de marcador de la aplicación.
ping -n -c 4 -W 2 10.205.10.20
Lee las cuatro respuestas y la línea final min/avg/max/mdev, en milisegundos (ms). Compara el promedio y la dispersión, no solo la muestra más baja. Este enlace suele rondar los 11 ms de RTT en el escenario preparado. El descubrimiento inicial de vecinos o la planificación de la VM pueden ralentizar una muestra.
Ahora cambia únicamente ese mismo destino a lane2:
ip route replace 10.205.10.20/32 via 10.205.2.1 dev lane2
ip route get 10.205.10.20
Espera via 10.205.2.1 dev lane2 src 10.205.2.2 antes de medir:
ping -n -c 4 -W 2 10.205.10.20
Esta ruta suele rondar los 180 ms de RTT. La diferencia debería ser grande; no constituye una promesa sobre un proveedor real o Internet. No recibir respuestas no significa automáticamente que el servicio HTTP esté averiado: ICMP y HTTP son protocolos distintos. Comprueba primero este destino, siguiente salto e interfaz. Si los valores parecen próximos, repite esta misma muestra limitada por una ruta cada vez; no inicies pruebas en paralelo.
Restaura la ruta original de un único destino y confírmala:
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
Has observado dos tiempos de recorrido sin cambiar las propiedades de los enlaces. A continuación comprueba si la respuesta más rápida también transporta más deprisa los datos voluminosos.
Mide el rendimiento en la dirección necesaria
En este paso compararás el rendimiento TCP de subida por las mismas dos rutas. Empieza en Event Client, con la ruta multimedia restaurada a lane1. El receptor preparado ejecuta un servidor iperf3 en el puerto 5201. El cliente inicia la prueba; el servidor recibe los datos de prueba e informa de lo que llegó. Estos bytes de prueba no son tu entrega multimedia.
iperf3 -c selecciona la dirección del servidor y -t 5 limita la prueba de datos a cinco segundos. La prueba TCP predeterminada envía del cliente al servidor, en el mismo sentido que la subida multimedia del evento. No usamos -R, que invierte la dirección. Los breves intercambios de establecimiento y resultados pueden hacer que el comando completo tarde algo más de cinco segundos.
Confirma la ruta antes de la primera prueba:
ip route get 10.205.10.20
iperf3 -c 10.205.10.20 -t 5
Lee la fila final receiver. La columna Bitrate puede usar Mbits/sec (Mbps): millones de bits por segundo. Un byte tiene ocho bits, así que divide los Mbps entre ocho para aproximar los MB/s. Por ejemplo, 2 Mbps equivalen como máximo a unos 0,25 MB/s antes de la sobrecarga del protocolo. MBytes en la columna de transferencia es una cantidad de datos, no una velocidad. La tasa del receptor por lane1 suele estar cerca de 1,9 Mbps.
Espera a que termine el comando antes de cambiar la ruta. Mide el mismo destino por lane2:
ip route replace 10.205.10.20/32 via 10.205.2.1 dev lane2
ip route get 10.205.10.20
iperf3 -c 10.205.10.20 -t 5
Lane2 suele entregar decenas de Mbps pese a su RTT mayor. El arranque de TCP, las confirmaciones, la sobrecarga del protocolo, la planificación y la breve ventana de observación afectan a la tasa. La velocidad nominal de una interfaz virtual no es rendimiento medido. Si el servidor indica que hay una prueba en curso, espera a que termine la prueba limitada actual y vuelve a intentarlo una vez; no inicies otro servidor ni superpongas más pruebas.
Restaura la ruta multimedia original y confírmala:
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
El enlace de RTT bajo es adecuado para pequeñas interacciones; el de alto rendimiento, para esta subida voluminosa. Esta conclusión se limita a las rutas preparadas y al sentido medido. No has medido Wi-Fi, capacidad de Internet público ni fiabilidad en producción. El siguiente laboratorio independiente te pide aplicar estas observaciones para entregar contenido de negocio nuevo.
Resumen
Enviaste un resultado real y audio reproducible, comparaste el mismo destino por dos rutas, interpretaste el RTT y el rendimiento del receptor TCP y restauraste la ruta limitada. Las mediciones describen una ruta y una dirección; la siguiente tarea convierte esas observaciones en rutas separadas para el trabajo del evento.
