Difference between revisions of "FAQ network-es"

From AMule Project FAQ
Jump to: navigation, search
m (Corrected Spelling of Español in language selection)
 
(20 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
<center>
 +
[[FAQ network|English]] |
 +
'''Espa&ntilde;ol'''
 +
</center>
 +
 
= Velocidad de la red: Lo que debes saber antes de preguntar =
 
= Velocidad de la red: Lo que debes saber antes de preguntar =
−
por Froenchenko Leonid, lfroen@gmail.com
 
−
 
−
 
 
== Prefacio ==
 
== Prefacio ==
 +
El propósito de este documento es clarificar algunos temas relacionados con la velocidad de la red que aparecen cada cierto tiempo en el [[aMule]] [[forum|foro]]. Las causas por las que se realizan preguntas sobre "[[FAQ eD2k-Kademlia| la red aMule]]" son varias:
  
−
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 "[[FAQ_ed2k| la red aMule]]" son varias:
+
* La velocidad que indica [[aMule]] no coincide con la de el ISP,
−
 
+
−
* La velocidad que indica el [[aMule]] no coincide con la de tu ISP.
+
−
* the speed reported by [[aMule]] doesn't match your provider's given rate;
+
 
* Bajo rendimiento del [[aMule]] o de otras aplicaciones que utilizan la red en la misma computadora, o,  
 
* 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.
 
* 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]].
+
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 que las mismas tienen en el funcionamiento del [[aMule]].
  
−
En cualquier caso esta página no tiene un propósito explícito "[[FAQ_ed2k|Network FAQ]]". Si estas buscando algo mas concreto quizás deberías ir a la páguina [[aMule is slow-es|aMule va lento FAQ]].
+
En cualquier caso esta página no tiene un propósito explícito "[[FAQ eD2k-Kademlia|Network FAQ]]". Si estas buscando algo mas concreto quizás deberías ir a la página [[aMule is slow-es|aMule va lento FAQ]].
 
   
 
   
 
== Velocidad de la red - Como es de rápida? ==
 
== 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 por la que se utiliza "bit" en lugar de "byte" es básicamente histórica, pero también 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".
  
−
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, 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 por organizaciones como la  
−
 
+
−
Hay un convenio por el que si usamos la B mayúscula "B" 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  
+
 
  [http://www.ietf.org/ IETF] y la [http://www.ieee.org/ IEEE] que utilizan "bps".
 
  [http://www.ietf.org/ IETF] y la [http://www.ieee.org/ IEEE] que utilizan "bps".
  
 
== Prefijos ==
 
== 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"''.  
 
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"''.  
  
Line 56: Line 54:
 
|}
 
|}
  
−
As you can see from the table above, the error in calculation is about 5% when the prefix is incorrectly interpreted. Please note that the speed your provider quotes you is the "speed in network units"; i.e., calculated on a decimal basis. For example when your provider tells you that your link is "ADSL 256/128", they mean 256000/128000 bps (bits per second). This means that the speed of your connection is 32000/16000 bps (bytes per second), since there are eight bits to a byte.
+
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 "ADSL 256/128", 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.  
  
−
== Protocol overhead - what is it about? ==
+
== Encabezamiento del Protocolo - Que sabemos sobre el? ==
−
When [[aMule]] is running, it constantly "talks" with other [[client]]s and [[server]]s.  
+
Cuando [[aMule]] esta funcionando, este "habla" constantemente con otros [[client-es|clientes]] y [[Server-es|servidores]].  
−
This data exchange is needed to perform such tasks as identifying itself, requesting information about
+
Este intercambio de información es necesario para realizar algunas tareas como identificarse el mismo, pedir información sobre las 
−
available [[FAQ_eD2k-Kademlia#What_is_a_source?|source]]s and [[file]]s, and performing [[search]]es.  
+
[[FAQ_eD2k-Kademlia-es#¿Qué_es_una_fuente?|fuentes]] disponibles,  [[file|ficheros]], realizar [[search|búsquedas]], etc...  
  
−
Since this information has no direct use to the user itself, it is called "overhead"; i.e., a necessary addition to the data you want to [[upload]] or [[download]].  
+
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 [[upload|compartir]] o [[download|descargar]].  
  
−
[[aMule]] calls this "''connection overhead''". However the number that [[aMule]] presents includes only the size of the actual data that [[aMule]] itself sends to the network stack. Later, these data are sent out on the network with even more overhead - that of the network protocols.
+
[[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 encabezamiento, la de los protocolos de red.
−
How much is it? - let's see that in the next section.
+
  
−
== Network overhead ==
+
¿Que tamaño tienen los encabezamientos? - Veámoslo en la siguiente sección.
−
First of all - we're talking about the [[IPv4]] network. Once upon a time, there
+
−
was only one type of [[IP]] network. Now there are two - [[IPv4|IP version 4]], the old protocol that we all know; and [[IPv6|IP version 6]] - the new protocol made to fix the limitations of [[IPv4]].
+
  
−
[[FAQ ed2k|ED2K protocol]] by design, is unable to talk over [[IPv6]] network, so users who have it (in Japan and China for example) will not be able to connect "as is". Using [[IPv4]] means, that each packet ([http://www.ietf.org/rfc/rfc793.txt TCP], [http://www.ietf.org/rfc/rfc768.txt UDP], [http://www.ietf.org/rfc/rfc792.txt ICMP]) will have an [[IPv4]] header.
+
== Encabezamiento de la Red ==
 +
Lo primero de todo, estamos hablando de la red [[IP address|IPv4]]. Hace algún tiempo, existía tan solo un tipo de red [[IP address|IP]], ahora tenemos dos - [[IP address|IP versión 4]], el viejo protocolo que todos conocemos; y el [[IP address|IP versión 6]] - el nuevo protocolo creado para cubrir las carencias del [[IP address|IPv4]].
  
−
The minimum size of this header is 20 bytes. The header can have optional parts (each of 4 bytes) and that is up to your provider - for example, mine adds an optional [dword].
+
[[FAQ eD2k-Kademlia|El protocolo ED2K ]] por su diseño, no puede comunicarse a través de la red [[IP address|IPv6]], por lo que los usuarios que lo utilizan (en Japón y China por ejemplo) no podrán conectarse al mismo. Usar [[IP address|IPv4]] significa, que cada paquete  ([http://www.ietf.org/rfc/rfc793.txt TCP], [http://www.ietf.org/rfc/rfc768.txt UDP] y [http://www.ietf.org/rfc/rfc792.txt ICMP]) tendrá un encabezado [[IP address|IPv4]].
  
−
When talking to other clients and servers on [[FAQ ed2k|ed2k network]], [[aMule]] uses the widely known [http://www.ietf.org/rfc/rfc793.txt TCP] protocol. [http://www.ietf.org/rfc/rfc768.txt UDP] is also used, but on a much smaller scale. As you may already know, [http://www.ietf.org/rfc/rfc793.txt TCP] is a reliable protocol, i.e. it guarantees that data that is sent from one side will arrive on the other or an error will be reported.
+
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 proveedores, concretamente el mío añade una [dword] opcional.
  
−
To achieve this, [http://www.ietf.org/rfc/rfc793.txt TCP] sends its own data in addition to the actual "payload" data being transferred. These data include [http://www.ietf.org/rfc/rfc793.txt TCP] client initial negotiation, checksums, sequence numbers and acknowledgments. All of this is in the ''[http://www.ietf.org/rfc/rfc793.txt TCP] header'' that is added to each packet sent. The size of this header is a minimum of 20 bytes.
+
Cuando se comunica con otros clientes en la [[FAQ eD2k-Kademlia|red ed2k]], [[aMule]] utiliza el ampliamente conocido protocolo [http://www.ietf.org/rfc/rfc793.txt TCP]. El protocolo [http://www.ietf.org/rfc/rfc768.txt UDP] también es utilizado , pero en una escala mucho menor. Como seguramente ya sabes, [http://www.ietf.org/rfc/rfc793.txt TCP] es un protocolo confiable, esto quiere decir que garantiza que la información que se ha enviado desde el origen, ha llegado al destino, y no se se ha producido ningun error en la transmisión.
  
−
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 exchanged. <u>This is exactly what happens on [[FAQ_ed2k#What_is_a_source?|source]] discovery part of [[aMule]]</u>.
+
Por aclarar este punto, [http://www.ietf.org/rfc/rfc793.txt TCP] envía su propia información añadida a la "carga útil" que se está transfiriendo. Esta información incluye la negociación inicial del cliente [http://www.ietf.org/rfc/rfc793.txt TCP], sumas de comprobación y códigos de secuencia y reconocimiento. Toda esta información se encuentra en el ''encabezado [http://www.ietf.org/rfc/rfc793.txt TCP] '' y se añade a cada paquete que es enviado. El tamaño de este encabezado tiene un mínimo de 20 bytes.  
  
−
Our [[client]] is trying to establish a connection and negotiate with a large number of other [[client]]s. Doing this, [[aMule]] opens new [http://www.ietf.org/rfc/rfc793.txt TCP] connections <u>''all the time''</u>. The number of connections opened is controlled by the ''"Maximum number of connections in 5 seconds"'' setting in the preferences.  
+
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, a nivel del ancho de banda, cuando se trata de pequeños grupos de datos que se transfieren, este último, es el caso <u>que exactamente ocurre cuando se realiza la búsqueda de [[FAQ eD2k-Kademlia-es#¿Qué_es_una_fuente?|fuentes]] en el [[aMule]]</u>.
  
−
A typical number is about 100. Each [http://www.ietf.org/rfc/rfc793.txt TCP] connection results in at least three packets traveling on the net - one is a SYN packet, i.e. connection request, and one an ACK or a RST when the connection is accepted or refused, and SYN+ACK to establish the session.  
+
Nuestro [[client-es|cliente]] trata de establecer una conexión y de negociarla con una gran cantidad de [[client-es|clientes]]. Mientras realiza estas tareas, el  [[aMule]] abre nuevas conexiones [http://www.ietf.org/rfc/rfc793.txt TCP] <u>''todo el tiempo''</u>. El número de conexiones abiertas se controla fijando en las preferencias el ''"Máximo número de conexiones cada 5 segundos"''.
  
−
There's more overhead of [http://www.ietf.org/rfc/rfc1034.txt DNS] queries when an address is resolved, retries when a host doesn't reply and so on.
+
El número mas común es de 100. Cada conexión [http://www.ietf.org/rfc/rfc793.txt 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.  
−
   
+
−
=== At low level ===
+
−
After passing [http://www.ietf.org/rfc/rfc793.txt TCP] and [[IP]] layers packets go down to the network interface driver. What kind of driver this is depends on the way your computer is connected to the internet. For the sake of simplicity, we will assume that this computer is connected to the ISP directly; i.e., that you have no LAN (or switch or router) between.  
+
  
−
Common setups include:
+
Hay otro encabezamiento añadido debida a peticiones  [http://www.ietf.org/rfc/rfc1034.txt DNS] para resolver las direcciónes, reintentos cuando un host no responde, etc...
 +
 
 +
=== A mas bajo nivel ===
 +
Una vez revisadas las capas superiores
 +
[http://www.ietf.org/rfc/rfc793.txt TCP] e [[IP address|IP]]  de los paquetes, descendemos al interfase 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. En nuestro caso para simplificarlo, vamos a asumir que nuestro ordenador esta conectado al ISP directamente, eso quiere decir que no tenemos LAN (o switch o router) entre ambos.
 +
 
 +
Las configuraciones mas comunes suelen ser del tipo:
 
   
 
   
−
* an analog modem, connected to a telephone line (ISDN modem falls in this category too);
+
* un modem analógico, conectado a una línea telefónica (Los modems RDSI entran dentro de esta categoría);
−
* a cable modem, connected through ethernet, ISP gives you an [[IP]] address through [http://www.ietf.org/rfc/rfc2131.txt DHCP];
+
* un cable modem, conectado a través de ethernet, el ISP nos da una [IP address|IP]] gracias al [http://www.ietf.org/rfc/rfc2131.txt DHCP];
−
* a cable modem, connected through ethernet, ISP requires you to configure PPPoE or PPTP tunnel;
+
* un cable modem, conectado a través de ethernet, es necesario configurar un túnel PPPoE o PPTP;
−
* an ADSL modem, connected through ethernet. You must have a PPPoE or PPTP tunnel;
+
* el modem ADSL, conectado a través de ethernet. Es necesario un túnel PPPoE o PPTP;
−
* a variation on these, e.g., a modem connected to a computer via USB.
+
* variaciones sobre los casos anteriores, un modem conectado a un ordenador por USB, etc...
 
   
 
   
−
In each of the these setups there are different protocols in use, and different headers are added to transmitted packets. There's one important thing to note: <u>''ethernet frames travel between cable/ADSL modem and computer, and don't reach the ISP''</u>. Consequently, they're not counted in rate calculations. [http://www.ietf.org/rfc/rfc2516.txt PPPoE]; in constrast,
+
En cada una de estas configuraciones se utilizan distintos protocolos, y se requieren 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 son tenidos en cuenta a la hora de calcular los ratios [http://www.ietf.org/rfc/rfc2516.txt PPPoE]; pero en cambio, los encabezados
−
[http://www.ietf.org/rfc/rfc2637.txt PPTP] headers <u>''do reach the ISP''</u>. In this respect, your particular provider may or may not choose to include them in their rate calculations. For this reason, we have excluded those headers from our calculations.  
+
[http://www.ietf.org/rfc/rfc2637.txt PPTP] <u>''si llegan a nuestro ISP''</u>.  
 +
A este respecto, tu proveedor puede o no incluir los encabezados es sus ratios
 +
. Es por ello que nosotros hemos excluido estos encabezados de nuestros cálculos
  
−
If you think that your ISP includes it, add 4 bytes to the size of each packet.
+
Si piensas que tu ISP las incluye, añade 4 bytes al tamaño de cada paquete
−
+
−
=== Example ===
+
−
Let's see how much network overhead we have on a typical network. Our connection is a cable modem connected via an ethernet link to a PC directly (no router between them).
+
  
−
In this setup we have [[IPv4]] packets sent over ethernet.  
+
=== 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)
  
−
Lets say we have 10 new connections opened each second, and all are being accepted (successfully established [http://www.ietf.org/rfc/rfc793.txt TCP] session). This alone sums up to (I'm counting data going up - from my computer to the net):
+
En esta configuración tenemos paquetes [[IP address|IPv4]] enviados sobre ethernet.  
  
−
''10 connection * 2 packets * (20 bytes of TCP + 20 bytes of [[IPv4]]) = 800 bytes of overhead.''
+
Tenemos 10 nuevas conexiones abiertas cada segundo, y todas estan siendo aceptadas (conexión [http://www.ietf.org/rfc/rfc793.txt TCP] establecida). Esta parte sola suma (estoy contando la información que va desde mi ordenador a la red):
  
−
This means that we are starting with 1.16*8 Kbps of "''invisible"''
+
''10 conexiones * 2 paquetes * (20 bytes  TCP + 20 bytes  [[IP address|IPv4]]) = 800 bytes de encabezamiento.''
−
overhead caused by the very way the network works. Now, let's assume that
+
−
after each connection is established our amule sends something to the other side and waits to receive an answer.
+
  
−
''Total of 800 bytes + 800 bytes = 1600 bytes per second = 6400 bps = 6.4 Kbps''
+
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]] envía algún dato al otro lado de la red y se queda a la espera a recibir una respuesta.
  
−
What we have here is 6.4 Kbps of network overhead alone. Taking into account
+
''Total de 800 bytes + 800 bytes = 1600 bytes por segundo = 6400 bps = 6,4 Kbps''
−
that amule has other data to send (uploads) and it is not the only network
+
−
application running we will have the following picture:
+
  
−
Most likely the link to your provider is not that fast. [[aMule]] will <u>''try''</u> to open 10 connections per second and will <u>''try''</u> to upload on the specified speed.
+
Lo que tenemos ahora son 6,4 KBps de encabezamiento de Red. Teniendo en cuenta que  nuestro [[aMule] debe enviar 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: 
  
−
Your operating system will share all available bandwidth between those and between [[aMule]] and other network applications (browser for example). Actual results will vary depending on specific OS settings.
+
Muy probablemente el enlace con tu proveedor no es tan rápido como nos parece. [[aMule]] <u>''tratará''</u> de abrir 10 conexiones por segundo y también <u>''tratará''</u> de realizar las subidas a la velocidad especificada.  
  
−
== ACK bottleneck ==
+
Tu sistema operativo compartirá todo el ancho de banda disponible entre  [[aMule]] y las otras aplicaciones de red que estén ejecutándose (por ejemplo el navegador). Los resultados dependerán de las opciones específicas el sistema operativo.
−
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 [http://www.ietf.org/rfc/rfc793.txt TCP] protocol.  
+
  
−
When [http://www.ietf.org/rfc/rfc793.txt TCP] is sending data, it requires that the other side acknowledge the reception. So if client A is sending data to [[client]] B by [http://www.ietf.org/rfc/rfc793.txt 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.  
+
== Atasco del ACK ==
 +
En todos los cálculos que realizamos con anterioridad asumimos un punto "no hay descargas". Pero el aMule se hizo para descargar. Por lo que vamos a examinar como afectan los encabezamientos a la velocidad de bajada. Nuestras respuestas se encuentran en el protocolo [http://www.ietf.org/rfc/rfc793.txt TCP].  
  
−
So, without going deeply into [http://www.ietf.org/rfc/rfc793.txt TCP] specification: <u>''if B fails to send ACK to A, as a result A will transmit slower''</u>.
+
Cuando [http://www.ietf.org/rfc/rfc793.txt TCP] esta enviando datos, necesita que haya por parte del interlocutor una confirmación de la recepción. Esto quiere decir que si el [[client-es|cliente]] A esta enviando datos al [[client-es|cliente]] B por [http://www.ietf.org/rfc/rfc793.txt TCP], B debe enviar un paquete especial  ACK a A que le informa de que "todo ha ido bien, lo he recibido". Del mismo modo si A no recibe el paquete ACK a tiempo, entiende que el paquete se habrá perdido.
  
−
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 <u>''will not be sent on time''</u>.
+
En resumen y sin entrar en profundidad en las especificaciones  [http://www.ietf.org/rfc/rfc793.txt TCP] : <u>''Si B falla en enviar el ACK a A, como resultado A disminuirá la velocidad de transmisión''</u>.
  
−
The remote party will notice this and slow down. This is one more reason why the upstream should better not be too congested.
+
Ahora veamos como queda esto en relación con el [[aMule]]. Vimos en la sección anterior que el enlace de subida puede estar congestionado por las solicitudes de conexiones y por las propias subidas. Como resultado hay muchas posibilidades de que el paquete ACK de confirmación del fichero que estamos descargando <u>''no sea enviado a tiempo''</u>.
 +
 
 +
Nuestro compañero de enlace al otro lado de la línea tomará nota, y bajará la velocidad de envío hacia nosotros. Esta es una razón más por la que la conexión de subida no debe estar congestionada.
 
   
 
   
−
== Is there anything I can do? ==
+
== ¿Hay algo que yo pueda hacer? ==
−
OK, now that you understood why your network is so slow while [[aMule]] is
+
Bueno, ahora que ya entiendes porque tu conexión va  lenta cuando esta funcionando el [[aMule]] quizás te preguntes como se puede mejorar. La respuesta se encuentra en tres palabras: "tasa de transferencia".
−
running you will maybe look for a way to fix this. The answer in 2 words: "rate limit".
+
 
 +
Lo primero que deberías hacer es asignar limites de transferencia en el   
 +
[[aMule]] que se sean realistas. Si tienes una tasa de transferencia de subida de 128 Kbps no pongas en el [[aMule]] el límite de [[upload|subida]] a 16 (kilobytes por segundo) simplemente porque 128/8 = 16.
 +
 
 +
Una mejor pero también mas complicada solución puede ser utilizar el QoS y los servicios de de planificación de paquetes de tu Sistema Operativo. Por ejemplo, se puede dar una mayor prioridad a los paquetes ACK para resolver problema mencionado anteriormente de "atasco del ACK".
 +
 
 +
El tema del QoS en cualquier caso, esta más allá del objeto de este artículo.
 +
 
 +
== Router (switch, red local): ¿Hay alguna diferencia? ==
 +
Cuando el cable que llega desde tu ISP esta conectado a un switch o aun router, que a la vez esta conectado a varios PC´s, en ancho de banda se comparte entre todos ellos.
  
−
The first thing you should do is to assign realistic rate limits in [[aMule]]
+
Por lo que si tenemos N ordenadores conectados, un aparato que tuviera un funcionamiento ideal se dedicaría simplemente repartir el ancho de banda, dando a cada uno de ellos una 1/N parte del mismo. La situación es bastante diferente en la realidad, y es posible que el aparato tenga una idea muy diferente de lo que es repartir equitativamente.  
−
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.  
+
Entendemos que no vas a tener las especificaciones de tu router, la única consideración que te hacemos es que pruebes y veas tu mismo.
  
−
The QoS topic, however, is beyond the scope of this article.
+
== Múltiples links ==
 +
Hasta ahora hemos hablado de PC´s conectados a la red a través de un solo interfase. Esta situación es la más frecuente de encontrar, aunque no es la única. Un usuario puede elegir la opción de conectarse por dos enlaces a diferentes ISPs. Hay dos razones fundamentales para ello que yo conozca, redundancia del enlace y balanceo de carga.  
  
−
== Router (switch, home network): is there any difference? ==
+
=== Redundancia del enlace ===
−
When the cable coming from your ISP is connected to some switching or routing
+
En este caso el segundo enlace se inicia cuando el primero cae. Esto puede ser hecho automáticamente, mediante un comando especial. Con esta configuración, [[aMule]] y el resto de aplicaciones de red, deben ser reiniciadas cuando se produce el cambio al otro enlace. Gracias ello conseguiremos reconectarnos a un servidor, y recibir un nuevo ID. Si el  [[aMule]] se conecta vía [http://www.ietf.org/rfc/rfc3022.txt NAT], hay que activarlo en el router
−
device, which in turn is connected to several PC's, bandwidth is shared between
+
(No tiene nada que ver con que tengas [[FAQ eD2k-Kademlia-es#¿Qué es ID baja e ID alta?|ID baja o ID alta]]), los enlaces se cambian en el
−
them.  
+
<u>'' router''</u>, y no es necesario realizar un reinicio.
  
−
So, having N computers connected, an ideal device would simply provide
+
=== Balanceo de carga ===
−
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.  
+
Este caso es algo mas complicado. Ambos enlaces están activos, y el tráfico se distribuye entre ambos, el problema es que [[aMule]] tiene acceso por
 +
<u>''a todos los interfases''</u> i.e. 0.0.0.0. Pero, en la red [[FAQ eD2k-Kademlia|ed2k]] tu ID se asocia a tu dirección [[IP address|IP]], <u>''y es imposible que tengas dos''</u>.<br>
  
−
Since you're not going to have the hardware specs of your router chipset the only advice here is "try and see yourself".
+
El problema en resumen es que [[aMule]] no elige explícitamente el interfase de  ''<u>salida</u>'' de las conexiones [http://www.ietf.org/rfc/rfc793.txt TCP] .
 +
Debes tener en consideración que
 +
<u>''da igual''</u> en cual de los dos interfases este "escuchando".
 +
Este funcionamiento es justo el <u>''opuesto''</u> al de otras aplicaciones
 +
<u>''servidoras''</u> como por ejemplo FTP o HTTP. Cuando un cliente intenta conectarse a un servidor este descubre su dirección IP resolviendo los DNS.
 +
La contestación del DNS contiene todas las direcciones IP del host y el cliente entonces las puede utilizar todas. El servidor sin embargo, puede elegir no escuchar alguna de ellas y para ello previene al cliente de que no debe utilizar ese interfase.
 +
En nuestro caso el [[aMule]] <u>''es un [[client-es|cliente]]''</u>, y el  [[server-es|servidor ed2k ]] descubre la dirección gracias a la
 +
[[FAQ eD2k-Kademlia-es#¿Qué_es_una_fuente?|fuente]] [[IP address|IP]] al solicitar la conexión. Es allí donde el [[server-es|servidor ed2k ]] tratará de conectarse.
  
−
== Multiple links ==
+
Si la conexión se produce el cliente es un [[client-es|cliente]] asignado a una [[FAQ eD2k-Kademlia-es#¿Qué es ID baja e ID alta?|ID alta]], de lo contrario el cliente tiene una ID baja.  
−
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 ===
+
La única solución en esta situación (hasta que [[aMule]] tenga la capacidad de gestionar diferentes direcciones) es utilizar el [[aMule]] en el enlace primario.<br>
−
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 &nbsp;[http://www.ietf.org/rfc/rfc3022.txt NAT]]
+
−
enabled router (it doesn't matter if you have [[FAQ_ed2k#What_is_LowID_and_HighID?|low or high ID]]), and links
+
−
are switched <u>''on the router''</u>, restart not needed.
+
  
−
=== Load balancing ===
+
Esto se puede hacer ya que [http://www.kernel.org Linux] permite enviar paquetes específicos hacia uno de los interfases.
−
This is a far more complicated case. Both (all) links are simultaneously active,
+
Pero lo mas probable es que se quedarán colgados por que la dirección [[IP address|IP]] de las fuentes no concuerdan con la dirección IP asignada al interfase.
−
and traffic is being distributed between them. The problem is that [[aMule]]
+
−
binds to <u>''all interfaces on the system''</u> i.e. 0.0.0.0. But, on [[FAQ ed2k|ed2k]]
+
−
your ID is your [[IP]] address, <u>''and you can not have two''</u>.<br>
+
−
So the problem is that [[aMule]] does not explicitly choose the source
+
−
address for ''<u>outgoing</u>'' [http://www.ietf.org/rfc/rfc793.txt TCP] connections. Note, that it <u>''doesn't
+
−
matter''</u> on which interface it listens. This is exactly <u>''opposite''</u>
+
−
to <u>''server''</u> 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]] <u>''is a [[client]]''</u>, and the [[server|ed2k server]] discovers its address from the
+
−
[[FAQ_ed2k#What_is_a_source?|source]] [[IP]] in the connection request. That's where the [[server|ed2k server]] will try to connect.
+
−
If the connection succeeds the client is [[client]] assigned a [[FAQ_ed2k#What_is_LowID_and_HighID?|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.<br>
+
−
You can, however, cause [http://www.kernel.org 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.
+

Latest revision as of 13:54, 24 September 2008

English | Español

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

Prefacio

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

  • La velocidad que indica aMule no coincide con la de el 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 que las mismas tienen en 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ágina 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 por la que se utiliza "bit" en lugar de "byte" es básicamente histórica, pero también 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, 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 por 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 "ADSL 256/128", 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, realizar búsquedas, etc...

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 encabezamiento, la de los protocolos de red.

¿Que tamaño tienen los encabezamientos? - Veámoslo en la siguiente sección.

Encabezamiento de la Red

Lo primero de todo, estamos hablando de la red IPv4. Hace algún tiempo, existía tan solo un tipo de red IP, ahora tenemos dos - IP versión 4, el viejo protocolo que todos conocemos; y el IP versión 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 conectarse al mismo. Usar IPv4 significa, que cada paquete (TCP, UDP y 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 proveedores, 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 una escala mucho menor. Como seguramente ya sabes, TCP es un protocolo confiable, esto quiere decir que garantiza que la información que se ha enviado desde el origen, ha llegado al destino, y no se se ha producido ningun error en la transmisión.

Por aclarar este punto, TCP envía su propia información añadida a la "carga útil" que se está transfiriendo. Esta información incluye la negociación inicial del cliente TCP, sumas de comprobación y códigos de secuencia 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, a nivel del ancho de banda, cuando se trata de pequeños grupos de datos que se transfieren, este último, es el caso que exactamente ocurre 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 el "Máximo 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 otro encabezamiento añadido debida a peticiones DNS para resolver las direcciónes, reintentos cuando un host no responde, etc...

A mas bajo nivel

Una vez revisadas las capas superiores TCP e IP de los paquetes, descendemos al interfase 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. En nuestro caso para simplificarlo, vamos a asumir que nuestro ordenador esta conectado al ISP directamente, eso quiere decir que no tenemos LAN (o switch o router) entre ambos.

Las configuraciones mas comunes suelen ser del tipo:

  • 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 través de ethernet, el ISP nos da una [IP address|IP]] gracias al DHCP;
  • un cable modem, conectado a través de ethernet, es necesario configurar un túnel PPPoE o PPTP;
  • el modem ADSL, conectado a través de ethernet. Es necesario un túnel 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 requieren 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 son tenidos en cuenta a la hora de calcular los ratios PPPoE; pero en cambio, los encabezados 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 estos encabezados de nuestros cálculos

Si piensas que tu ISP las 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 envía 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

Lo que tenemos ahora son 6,4 KBps de encabezamiento de Red. Teniendo en cuenta que nuestro [[aMule] debe enviar 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 nos parece. aMule tratará de abrir 10 conexiones por segundo y también tratará de realizar las subidas a la velocidad especificada.

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

Atasco del ACK

En todos los cálculos que realizamos con anterioridad asumimos un punto "no hay descargas". Pero el aMule se hizo para descargar. Por lo que vamos a examinar como afectan los encabezamientos a la velocidad de bajada. Nuestras respuestas se encuentran en el protocolo TCP.

Cuando TCP esta enviando datos, necesita que haya por parte del interlocutor una confirmación de la recepción. Esto quiere decir que si el cliente A esta enviando datos al cliente B por TCP, B debe enviar un paquete especial ACK a A que le informa de que "todo ha ido bien, lo he recibido". Del mismo modo si A no recibe el paquete ACK a tiempo, entiende que el paquete se habrá perdido.

En resumen y sin entrar en profundidad en las especificaciones TCP : Si B falla en enviar el ACK a A, como resultado A disminuirá la velocidad de transmisión.

Ahora veamos como queda esto en relación con el aMule. Vimos en la sección anterior que el enlace de subida puede estar congestionado por las solicitudes de conexiones y por las propias subidas. Como resultado hay muchas posibilidades de que el paquete ACK de confirmación del fichero que estamos descargando no sea enviado a tiempo.

Nuestro compañero de enlace al otro lado de la línea tomará nota, y bajará la velocidad de envío hacia nosotros. Esta es una razón más por la que la conexión de subida no debe estar congestionada.

¿Hay algo que yo pueda hacer?

Bueno, ahora que ya entiendes porque tu conexión va lenta cuando esta funcionando el aMule quizás te preguntes como se puede mejorar. La respuesta se encuentra en tres palabras: "tasa de transferencia".

Lo primero que deberías hacer es asignar limites de transferencia en el aMule que se sean realistas. Si tienes una tasa de transferencia de subida de 128 Kbps no pongas en el aMule el límite de subida a 16 (kilobytes por segundo) simplemente porque 128/8 = 16.

Una mejor pero también mas complicada solución puede ser utilizar el QoS y los servicios de de planificación de paquetes de tu Sistema Operativo. Por ejemplo, se puede dar una mayor prioridad a los paquetes ACK para resolver problema mencionado anteriormente de "atasco del ACK".

El tema del QoS en cualquier caso, esta más allá del objeto de este artículo.

Router (switch, red local): ¿Hay alguna diferencia?

Cuando el cable que llega desde tu ISP esta conectado a un switch o aun router, que a la vez esta conectado a varios PC´s, en ancho de banda se comparte entre todos ellos.

Por lo que si tenemos N ordenadores conectados, un aparato que tuviera un funcionamiento ideal se dedicaría simplemente repartir el ancho de banda, dando a cada uno de ellos una 1/N parte del mismo. La situación es bastante diferente en la realidad, y es posible que el aparato tenga una idea muy diferente de lo que es repartir equitativamente.

Entendemos que no vas a tener las especificaciones de tu router, la única consideración que te hacemos es que pruebes y veas tu mismo.

Múltiples links

Hasta ahora hemos hablado de PC´s conectados a la red a través de un solo interfase. Esta situación es la más frecuente de encontrar, aunque no es la única. Un usuario puede elegir la opción de conectarse por dos enlaces a diferentes ISPs. Hay dos razones fundamentales para ello que yo conozca, redundancia del enlace y balanceo de carga.

Redundancia del enlace

En este caso el segundo enlace se inicia cuando el primero cae. Esto puede ser hecho automáticamente, mediante un comando especial. Con esta configuración, aMule y el resto de aplicaciones de red, deben ser reiniciadas cuando se produce el cambio al otro enlace. Gracias ello conseguiremos reconectarnos a un servidor, y recibir un nuevo ID. Si el aMule se conecta vía NAT, hay que activarlo en el router (No tiene nada que ver con que tengas ID baja o ID alta), los enlaces se cambian en el router, y no es necesario realizar un reinicio.

Balanceo de carga

Este caso es algo mas complicado. Ambos enlaces están activos, y el tráfico se distribuye entre ambos, el problema es que aMule tiene acceso por a todos los interfases i.e. 0.0.0.0. Pero, en la red ed2k tu ID se asocia a tu dirección IP, y es imposible que tengas dos.

El problema en resumen es que aMule no elige explícitamente el interfase de salida de las conexiones TCP . Debes tener en consideración que da igual en cual de los dos interfases este "escuchando". Este funcionamiento es justo el opuesto al de otras aplicaciones servidoras como por ejemplo FTP o HTTP. Cuando un cliente intenta conectarse a un servidor este descubre su dirección IP resolviendo los DNS. La contestación del DNS contiene todas las direcciones IP del host y el cliente entonces las puede utilizar todas. El servidor sin embargo, puede elegir no escuchar alguna de ellas y para ello previene al cliente de que no debe utilizar ese interfase. En nuestro caso el aMule es un cliente, y el servidor ed2k descubre la dirección gracias a la fuente IP al solicitar la conexión. Es allí donde el servidor ed2k tratará de conectarse.

Si la conexión se produce el cliente es un cliente asignado a una ID alta, de lo contrario el cliente tiene una ID baja.

La única solución en esta situación (hasta que aMule tenga la capacidad de gestionar diferentes direcciones) es utilizar el aMule en el enlace primario.

Esto se puede hacer ya que Linux permite enviar paquetes específicos hacia uno de los interfases. Pero lo mas probable es que se quedarán colgados por que la dirección IP de las fuentes no concuerdan con la dirección IP asignada al interfase.

Retrieved from "http://wiki.amule.org/w/index.php?title=FAQ_network-es&oldid=23587"