Hola.
A ver si alguien puede resolverme esta duda que hace días que tengo.
Pongamos por caso que tengo un dedicado en Alemania. Si hago un traceroute desde mi conexión hacia el dedicado, la ruta va por DTAG. Si hago un traceroute desde el dedicado hasta mi conexión, la ruta pasa por Cogent.
Entonces, cuando cargo una página web de un sitio alojado en el servidor, ¿Los paquetes de ida pasan por DTAG y los de vuelta por Cogent? ¿O todo va por DTAG?
Saludos y gracias ?
Eso dependerá de los contratos que tenga cada proveedor. Tus rutas serán diferentes a la de cualquier usuario que no sea de tu ISP.
La respuesta más corta y la mejor explicada, el protocolo de enrutamiento dinámico más usado es BGP; BGP siempre se rige por la ruta más corta, tu puedes tener X proveedores en tu AS, y llegaras al destino por la ruta más corta disponible entre tus X operadores, pero alomejor el destino tiene otros carriers que tienen mejores o peores rutas, o sencillamente aplican prepends o weights para sancionar el trafico y pagar menos (practica poco usada y poco elegante). BGP siempre elige la mejor ruta, y eso no siempre es sincrono ya que un carrier tiene X saltos y otro carrier puede tener X diferentes saltos.
Cuando cargas una página, tu ordenador abre una conexión con tu servidor, la cual pasará por DTAG. A través de esa conexión (que queda abierta) el servidor manda de vuelta la información.
Sólo en caso de que fuese tu servidor el que abriese la conexión, los datos pasarían por Cogent, pero como en el protocolo HTTP el servidor nunca abre las conexiones, nunca vas a ver los datos pasar por Cogent.
No, lo que explicas no es necesariamente correcto a nivel de carrier. Es una conexión TCP/IP y en ella solo se fijan origen y destino, no el camino.
Cuando un equipo cliente realiza una consulta al servidor (supongamos que es un web que contesta en el 80), a su vez habilita un puerto para que el servidor le conteste. El servidor verá que no es de su red local, y le entregará la respuesta a su propia puerta de enlace, la definida por el hosting alemán donde esté situada.
Desde ese mismo momento, el camino de vuelta dependerá de los contratos de peering que su proveedor de hosting tenga con otros carriers, y ese camino puede ser completamente diferente al de la conexión de ida con la solicitud de conexión. La respuesta le llegará al cliente original, por el puerto que había dejado habilitado para ello (ya que de otra forma el cortafuegos lo pararía probablemente) y no va a evaluar en ningún momento el camino que haya podido seguir.
¿Cómo exactamente es que abre el cliente un puerto para recibir la respuesta? No entiendo esa parte. ¿No se supone que en HTTP el cliente nunca abre puertos y los datos son enviados a través de las conexiones que él mismo establece?
Por ejemplo, si conozco el protocolo HTTP y hago una petición HTTP usando un cliente de telnet, veo los datos de vuelta en la misma conexión, ¿cómo es posible que haya cambiado de camino la conexión?
Porque tienes un par de conceptos básicos de TCP/IP bastante confundidos ...
Una conexión TCP/IP se identifica por los pares IP:PUERTO origen he IP:PUERTO destino ... en ningún caso, una conexión TCP/IP lleva información sobre por donde ha pasado o por donde va a pasar ... eso es responsabilidad de otros dispositivos y de otras capas de la pila de protocolos, el emisor A solo sabe la IP y puerto a la que quiere dirigir su comunicación contra el receptor B y viceversa. Por simplificación estamos obviando la parte de los cambios de dirección/puerto que sufren las conexiones que atraviesan un NAT.
Incorrecto, eso solo es cierto en casos de solo existir una ruta entre A y B ... o en caso de que por algún motivo, se establezcan políticas de strict-routing (cosa que no hace ningún carrier de este planeta, salvo contrato firmado de muchos €€)
Las rutas que tome un paquete, ya sea de ida o de vuelta, dependen exclusivamente de la configuración de los routers intermedios.
La 'magia' y la 'gracia' de el TCP/IP está en que 'te garantizan' la comunicación entre A y B ... pero no por donde van a pasar cada paquete de esa comunicación.
Te puedes encontrar que al hacer un tracert, va por un sitio ... y que al usar http, va por otro ... porque el enrutado no solo se fija en función de origen y destino, se pueden tomar decisiones de routing basadan en la carga instantánea de un enlace, en los protocolos usados, en los puertos, en la fecha/hora o en combinaciones de varios de los anteriores. En resumen ... NO PUEDES de ninguna manera y a ciencia cierta, por donde ha pasado el tráfico que va de A a B ... 'lo puedes presuponer' y se 'puede estimar' ... pero a ciencia cierta, no hay manera (salvo teniendo acceso a todos los routers intermedios ... XDD )
Se han dicho muchas incoherencias en este hilo. Si en la traza observas que la ida es por DTAG y la vuelta por Cogent, esa es la ruta que están siguiendo tus paquetes; no tiene mayor complicación. ;)
¿Sabes como funciona el tracert verdad? ... cambiando el ttl de cada paquete que manda, para recibir el 'error' de cada salto y así 'averiguar' por donde pasa ...
¿pero sabías que en cada paquete que se manda, la ruta no tiene porqué respetarse? ... si usas mtr desde windows o desde linux ... te llevarás alguna que otra sorpresa ... cuando veas que para un mismo salto ... (digamos el 10-12 en una 'supuesta ruta' de 20 saltos) de repente te devuelve una ip diferente ... ¡ups! ... ¿que ha pasado? ... pues simplemente que ESE paquete tomó otra ruta.
Así que la cosa no es 'no tiene mayor complicación' ... podemos 'presuponer' las rutas ... nunca saberlas a ciencia cierta sin tener acceso a los nodos intermedios, es así de simple.
Cuando observas dos caminos es porque hay ECMP en algún salto. Puedes evitarlo usando ICMP en lugar de UDP en la traza, o simplemente forzando un puerto fijo si prefieres UDP/TCP. Así el hash será siempre el mismo y la traza será más sencilla de interpretar.
En cualquier caso, nunca se hace balanceo de ningún tipo para paquetes de un mismo flujo porque causaría jitter, cosa que tratamos de evitar a toda costa, especialmente por lo sensible que son algunos tráficos como VoIP.
Y lo que tampoco se hace nunca es balancear entre dos operadores diferentes para una misma ruta. Y el motivo es más o menos el mismo, evitar que las latencias sean diferentes.
La teoría es muy bonita ... pero la práctica es otra.
Si se hace balanceo a nivel de paquetes , no todo el mundo, no en todos los enlaces ... pero si hay muchos operadores que lo hacen. Los Carriers si que no suelen hacerlo ... o si lo hacen es por rutas que tienen los mismos niveles en los valores de enlace, intentando no afectar al jitter.
¿Que no se balancea entre dos operadores? ... ¡juas! ... tu no has visto las tablas de routing por horas y protocolos que tiene un proveedor de hosting que yo conozco ...
Los operadores buscan la forma de reducir costes, los carriers también ... y si eso supone meter un equipo de DPI en algún punto de la red para que 'desvie flujos costosos' ... se hace y punto.
El ejemplo más chorra, es la interceptación de las consultas DNS, que puede parecer una simplonada ... pero que pueden ser varios cientos de Gigas al día para un operador grande y que si las rediriges a tus servidores caché ... te ahorras tranquilamente el 80-95% de ese tráfico.
Qué magnífico hilo: informativo, sin insultos y sin apenas ínfulas de superioridad. Voy a ponerme a dar positivos a todo el mundo, a ver qué pasa con mi cuenta.
Gracias.
