FAQ network-es

Velocidad de la red: Lo que debes saber antes de preguntar

por Froenchenko Leonid, lfroen@gmail.com

Prefacio

El propósito de este documento es clarificar algunos temas relacionados con la velocidad de la red que paracen cada cierto tiempo en el aMule [[forum]|foro]. Las causas por las que realizan preguntas sobre " la red aMule" son varias:

• La velocidad que indica el aMule no coincide con la de tu ISP.
• Bajo rendimiento del aMule o de otras aplicaciones que utilizan la red en la misma computadora, o,
• Los factores clave que influyen sobre el rendimiento de la red cuando el aMule esta corriendo.

Este documento va dirigido a usuarios que desean adquirir un mayor conocimiento del funcionamiento de las redes en general, y en particular, de las implicaciones de éstas sobre el funcionamiento del aMule.

En cualquier caso esta página no tiene un propósito explícito "Network FAQ". Si estas buscando algo mas concreto quizás deberías ir a la páguina aMule va lento FAQ.

Velocidad de la red - Como es de rápida?

Cuando hablamos de velocidad de red, generalmente usamos la unidad "bps", que significa bits por segundo, la razón es por la que se utiliza "bit en lugar de byte es básicamente histórica, pero tambíen viene dada por la arquitectura de los sistemas, y mas concretamente, viene del hecho de que no todas las redes en el mundo transmiten el tráfico de la red en bytes.

Hay un convenio por el que si usamos la B mayúscula en "Bps" en el caso de que hablemos de "bytes por segundo". De cualquier modo este convenio no es aceptado por todo el mundo y mas en particular en organizaciones como la

IETF y la IEEE que utilizan "bps".

Prefijos

Desde su invención, las redes han progresado enormemente. Hoy en día tenemos redes que transmiten miles de millones de bits por segundo. Para dar una medida a estas velocidades utilizamos los siguientes prefijos "kilo", "mega", "giga", "tera".

Es un error muy común pensar que los valores con estos prefijos son similares en computación. La realidad es que, por razones históricas, los prefijos en redes tienen una base decimal y no binaria

Prefijo	significado en informática	significado en redes	diferencia, %%
k (kilo)	2^10 = 1024	10^3 = 1000	2%
M (mega)	2^20 = 1,048,576	10^6 = 1,000,000	5%
G (giga)	2^30 = 1,073,741,624	10^9 = 1,000,000,000	7%
T (tera)	2^40 = 1,099,511,627,776	10^12 = 1,000,000,000,000	9%

Como puedes ver en la tabla anterior, el error en el cálculo es del 5% cuando el prefijo es incorrectamente interpretado. Date cuenta de que la velocidad contratada con tu ISP es la velocidad en "unidades de red"; (calculado en base decimal). Por ejemplo cuando tu proveedor te dice que tu conexión es de "ADSL 256/128", esto quiere decir 256000/128000 bps (bits por segundo). Esto significa que la velocidad de tu conexión es de 32000/16000 bps (bytes por segundo), teniendo en cuenta que hay 8 bits en cada byte.

Encabezamiento del Protocolo - Que sabemos sobre el?

Cuando aMule esta funcionando, este "habla" constantemente con otros clientes y servidores. Este intercambio de información es necesario para realizar algunas tareas como identificarse el mismo, pedir información sobre las fuentes disponibles, ficheros, y realizar búsquedas.

Como esta información es transparente para el usuario, se denomina "encabezamiento", es una carga añadida de información a los datos que deseas compartir o descargar.

aMule lo llama "encabezamiento de la conexión". De cualquier modo los datos de transferencia que aMule presenta, incluyen solo el tamaño de la información que el aMule mismo envía a la red. Mas tarde esa información se envía a la red con mayor sobrecarga , la de los protocolos de red.

Cuanta es esta sobrecarga? - Veámoslo en la siguiente sección.

Encabezamiento de la Red

Lo priemro de todo, nosotros estamos hablando de la red IPv4 network. Hace algún tiempo, existía tan solo un tipo de red IP. Ahora tenemos dos - IP version 4, el viejo protocolo que todos conocemos; y el IP version 6 - el nuevo protocolo creado para cubrir las carencias del IPv4.

El protocolo ED2K por su diseño, no puede comunicarse a través de la red IPv6, por lo que los usuarios que lo utilizan (en Japón y China por ejemplo) no podrán concectarse. Usar IPv4 significa, que cada paquete (TCP, UDP and ICMP) tendrá un encabezado IPv4.

El tamaño mínimo de este encabezado es de 20 bytes. El encabezado puede tener partes opcionales (cada 4 bytes) y estas partes dependen de los preocveedores, concretamente el mío añade una [dword] opcional.

Cuando se comunica con otros clientes en la red ed2k , aMule utiliza el ampliamente conocido protocolo TCP. El protocolo UDP también es utilizado , pero en menor escala. Como seguramente ya sabes, TCP es un protocolo confiable, esto quiere decir que garantiza que la información se ha enviado desde el origen ha llegado al destino y no se se ha producido ningun error en la transmisión.

Para aclarar este punto, TCP envia su propia información añadida a la "carga util" que se se está transfiriendo. Esta información incluye la negociación inicial del cliente TCP, sumas de comprobación y códigos de seguencia y reconocimiento. Toda esta información se encuentra en el encabezado TCP y se añade a cada paquete que es enviado. El tamaño de este encabezado tiene un mínimo de 20 bytes.

La importancia de este encabezado es casi despreciable cuando se trate de un pequeño encabezado que antecede a una gran cantidad de datos, pero empieza a tener relevancia en ancho de banda cuando se trata de pequeños grupos de datos que se transfieren While being only a small overhead for a large bulk transfer, it can take significant part of bandwidth when small amounts of data are being exchangedy esto es exactamente lo que pasa cuando se realiza la búsqueda de fuentes en el aMule.

Nuestro cliente trata de establecer una conexión y de negociarla con una gran cantidad de clientes. Mientras realiza estas tareas, el aMule abre nuevas conexiones TCP todo el tiempo. El número de conexiones abiertas se controla fijando en las preferencias "Maxímo número de conexiones cada 5 segundos".

El número mas común es de 100. Cada conexión TCP se convierte en al menos 3 paquetes que viajan por la red - uno es el paquete SYN, (petición de conexión), otro es el ACK o el RST dependiendo de si la conexión es aceptada o denegada, y por último el paquete SYN+ACK que se encarga de establecer la conexión.

Hay otra "sobrecarga" añadida debida a peticiones DNS para resolver las direccións, reintentos cuando un host no responde, etc...

El cuerpo de la red

Una vez revisadas las capas superiores TCP e IP de los paquetes, descendemos al intefase con la gestión de la red. Dependiendo de la manera en la que te conectas a la red la gestión de la misma se verá afectada. Simplificándolo, vamos a asumir que nuestro ordenador esta conectado al ISP directamente, eso quiere decir que no tenemos LAN (o switch o router) entre ambos.

Common setups include: Las configuraciones mas comunes incluyen:

• un modem analógico, conectado a una línea telefónica (Los modems RDSI entran dentro de esta categoría);
• un cable modem, conectado a traves de ethernet, el ISP nos da una una [IP]] gracias al DHCP;
• un cabel modem, conectado a traves de ethernet, es necesario configurar un tunel PPPoE o PPTP;
• el modem ADSL modem, conectado a traves de ethernett. Es necesario un tunel PPPoE o PPTP;
• variaciones sobre los casos anteriores, un modem conectado a un ordenador por USB, etc...

En cada una de estas configuraciones se utilizan distintos protocolos, y se diferentes encabezados para los paquetes enviados/recibidos.Hay un punto importante a reseñar: las tramas ethernet viajan entre el ordenador y el cable/ADSL, nunca llegan a nuestro ISP. Esto provoca que no sontenidos en cuanta a la hora de calcular los ratios PPPoE; pero en cambio, las cabezeras PPTP si llegan a nuestro ISP. A este respecto, tu proveedor puede o no incluir los encabezados es sus ratios . Es por ello que nosotros hemos excluido estas cabezeras de nuestros cálculos

Si piensas que tu ISP los incluye, añade 4 bytes al tamaño de cada paquete

Ejemplo

Veamos que sobrecarga tenemos en una red tipo. Nuestra conexión es mediante cable modem, conectada mediante un enlace ethernet a nuestro PC directamente( no tenemos un router entre ambos)

En esta configuración tenemos paquetes IPv4 enviados sobre ethernet.

Tenemos 10 nuevas conexiones abiertas cada segundo, y todas estan siendo aceptadas (conexión TCP establecida). Esta parte sola suma (Estoy contando la información que va desde mi ordenador a la red):

10 conexiones * 2 paquetes * (20 bytes TCP + 20 bytes IPv4) = 800 bytes de encabezamiento.

Esto quiere decir que empezamos con 1.16*8 Kbps "invisibles" de encabezamiento debidos a la manera en la que la red trabaja. Ahora vamos a asumir que después de cada conexión que se establece nuestro aMule envia algún dato al otro lado de la red y se queda a la espera a recibir una respuesta..

Total de 800 bytes + 800 bytes = 1600 bytes por segundo = 6400 bps = 6,4 Kbps

Loque tenemos aqui son 6,4 KBps de encabezamiento de Red. Teniendo en cuenta que nuestro [[aMule] debe eviar otro tipo de datos (Subidas) y que es posible que no sea la unica aplicación de red que este funcionando, llegamos a lo siguiente:

Muy probablemente el enlace con tu proveedor no es tan rápido como parece. aMule tratará de abrir 10 conexiones por segundo y tratará de realizar las subidas a la velocidad especificada.

Tu sistema operativo compartirá todo el ancho de banda disponible entre aMule las otras aplicaciones de red que esten ejecutándose (por ejemplo el navegador). Los resultados pueden depender de las opciones específicas el sistema operativo.

ACK bottleneck

In all calculations above there was one assumption - zero download. But downloading is what amule was built for. So let's examine how the overhead above affects your downloading speed. The answer is in TCP protocol.

When TCP is sending data, it requires that the other side acknowledge the reception. So if client A is sending data to client B by TCP, B has to send a special ACK packets to A which tells B "ok, I got it". If, however, A doesn't receive the ACK packets in time, he will assume that either packet is lost.

So, without going deeply into TCP specification: if B fails to send ACK to A, as a result A will transmit slower.

Now let's see the situation in aMule. We saw in the previous chapter, that the uplink stream is congested by connection requests and uploads. As a result, there's a good chance that ACK packets for a file we are downloading will not be sent on time.

The remote party will notice this and slow down. This is one more reason why the upstream should better not be too congested.

Is there anything I can do?

OK, now that you understood why your network is so slow while aMule is running you will maybe look for a way to fix this. The answer in 2 words: "rate limit".

The first thing you should do is to assign realistic rate limits in aMule itself. If you have a uplink rate of 128 Kbps don't set aMule's upload limit to 16 (kilobytes per second) just because 128/8 = 16.

A better, but far more complicated solution is to use the QoS and packet scheduling services of your OS. For example, you can give a higher priority to ACK packets to solve the above mentioned "ACK bottleneck" problem.

The QoS topic, however, is beyond the scope of this article.

Router (switch, home network): is there any difference?

When the cable coming from your ISP is connected to some switching or routing device, which in turn is connected to several PC's, bandwidth is shared between them.

So, having N computers connected, an ideal device would simply provide each one of them with 1/N of the total bandwidth. The situation may vary in real life, and your particular device may have different idea about fairness.

Since you're not going to have the hardware specs of your router chipset the only advice here is "try and see yourself".

Multiple links

Until now, we talked about computers that are connected to the network through single interface. While being most frequent, this is not mandatory. A user may choose to connect via 2 (or more links) provided by different ISP's. There're 2 reasons for this decision that I know about: link redundancy and load balancing.

Link redundancy

In a case of link redundancy second link becomes operational when primary link fails. This can be done automatically, or by explicit user command. When this setup used, aMule along with other network applications must be restarted when links are being switched. This will allow to bind new address, reconnect to server and receive new ID. If aMule is connected via  NAT] enabled router (it doesn't matter if you have low or high ID), and links are switched on the router, restart not needed.

Load balancing

This is a far more complicated case. Both (all) links are simultaneously active, and traffic is being distributed between them. The problem is that aMule binds to all interfaces on the system i.e. 0.0.0.0. But, on ed2k your ID is your IP address, and you can not have two.
So the problem is that aMule does not explicitly choose the source address for outgoing TCP connections. Note, that it doesn't matter on which interface it listens. This is exactly opposite to server applications like FTP or HTTP. When a client tries to connect to a server it discovers its IP address by resolving DNS. Resolver replies will contain all IP addresses of the specified host and a client should try them all. The server, in turn, may choose not to listen on one of them and thus prevent the client from using this interface. In our case aMule is a client, and the ed2k server discovers its address from the source IP in the connection request. That's where the ed2k server will try to connect. If the connection succeeds the client is client assigned a high ID, if it doesn't the client gets a Low ID. The only solution in this situation (until aMule will have an ability to bind to specific address) is to use aMule on your "primary" link.
You can, however, cause Linux to send packet through interface of your choice. But, most probably they will be dropped by your ISP's router as "spoofed" because the source IP address doesn't match the address the ISP assigned to that interface.