Está en la página 1de 13

Estado del arte:

PROTOTIPO FTP CON TCP/vegas

INTEGRANTES:

DOCENTE:

FECHA:
22 JUNIO 2016

ndice
1. Introduccin...1
2. Objetivos.2
2.1 Objetivo general...2
2.2 Objetivo Especfico..2
3. Historia de FTP..2
3.1 Definicin de FTP2
3.2 Modelo FTP..3
3.3 Servidor FTP4
3.4 Cliente FTP...4
4. Definicin de TCP..4
4.1 Funciones de TCP5
4.2
Puertos
TCP..6
4.3 Desarrollo de TCP7
5. Definicin de TCP/Vegas...8
5.1 Mtodos de control de congestin
8
5.1.1 Slow Start...9
5.2 Fast Recovery...9
5.3 TCP/VEGAS...10
6. Bibliografa...11

1. Introduccin
En el ambiente de las redes informticas la ciencia ha estado en una evolucin invariable, de la cual sea
desarrollado nuevos tipos de interconexin, de envo y recepcin de datos. Esto ha generado varios tipos
de protocolos, enrutamiento, mtodos y algoritmos.
EL protocolo FTP desde su creacin conform un estndar, en la transferencia de archivos entre quipos
remotos (ordenadores) a travs de internet TCP/IP conexiones. FTP se basa en canales de comunicacin
entre cliente y servidor.
El protocolo TCP es uno de los protocolos fundamentales de internet. Desde que se creara, a principios de
los aos 70, se ha convertido, junto al protocolo IP (TCP/IP), en el estndar mundial de comunicaciones
dentro de las redes informticas. Da soporte a muchas de las aplicaciones ms populares en Internet
(navegadores, intercambio de ficheros, clientes FTP, etc.) y los protocolos de aplicacin HTTP, SMTP,
SSH, FTP, etc. Y sobre l se han construido grandes estructuras de las que dependen econmicamente
grandes empresas y organismos de todo el mundo. TCP ha tenido una evolucin dependiendo de sus
necesidades por lo que podemos mencionar sus variantes como son RENO, TAHOE y VEGAS. Adems
de tener una relacin con varios tipos de protocolos a nivel de la capa de aplicacin como son FTP, HTTP
y TELNET.

2. Objetivos
2.1 Objetivo General

Tener un acercamiento formal, clarificando ideas respecto al tema de desarrollo PROTOTIPO


FTP con variante TCP/vegas.

2.2 Objetivo Especfico

Conocer de definiciones, conceptos del tema propuesto.


Estar al tanto de las propuestas creadas anteriormente acerca del tema.
Recopilar datos para luego ser utilizados en la implementacin de la propuesta a resolver.

3. Historia de FTP
Desde su creacin en abril de 1971, el protocolo FTP ha sido utilizado para transferir archivos entre
equipos remotos. Los desarrolladores del protocolo de transferencia de archivos (FTP) tenan que
equilibrar la necesidad de un conjunto completo de funcionalidades con el deseo de crear un protocolo
que fuera simple y fcil de implementar.
File Transfer Protocol (FTP) versin RFC 959, fue publicado en octubre de 1985 dando la posibilidad de
modificar el FTP original, aadiendo varios comandos nuevos. Desde entonces, una serie de otras normas
se han publicado para aadir funciones; pero su administracin es complicada y no permite una verdadera
automatizacin de procesos o ser utilizado para cumplir con regulaciones y leyes. (Bolo, 2011)

3.1 Definicin de FTP:


Protocolo de transferencia de archivos (FTP) es un estndar de Internet protocolo para la transmisin de
archivos entre ordenadores a travs de Internet a travs de TCP / IP conexiones.
FTP es un cliente-servidor de protocolo que se basa en dos canales de comunicacin entre el cliente y el
servidor: un canal de mando para el control de la conversacin y un canal de datos para transmitir el
contenido del archivo. Los clientes inicien conversaciones con los servidores mediante la solicitud para
descargar un archivo. El uso de FTP, un cliente puede cargar, descargar, borrar, renombrar, mover y copiar
archivos en un servidor. Un usuario normalmente tiene que iniciar sesin en el servidor FTP, aunque
algunos servidores hacen parte o la totalidad de su contenido disponible sin entrada, tambin conocido
como FTP annimo.
Sesiones FTP funcionan en los modos pasivos o activos. En el modo activo, despus de un cliente inicia
una sesin a travs de una peticin de canal de comando, el servidor inicia una conexin de datos de
vuelta al cliente y comienza la transferencia de datos. En el modo pasivo, el servidor usar el canal de
comando para enviar al cliente la informacin que necesita para abrir un canal de datos. Debido a que el
modo pasivo tiene el cliente que inicia todas las conexiones, que funciona bien a travs de cortafuegos y
de direcciones de red ( NAT puertas de enlace). (Rouse, 2015)

3.2 Modelo FTP

En el modelo, el intrprete de protocolo (IP) de usuario inicia la conexin de control en el puerto 21. Las
rdenes FTP estndar las genera el IP de usuario y se transmiten al proceso servidor a travs de la
conexin de control. Las respuestas estndar se envan desde la IP del servidor hasta la IP de usuario por
la conexin de control como respuesta a las rdenes.

Figura 1: Diagrama de un servicio FTP.

Estas rdenes FTP especifican parmetros para la conexin de datos (puerto de datos, modo de
transferencia, tipo de representacin y estructura) y la naturaleza de la operacin sobre el sistema de
archivos (almacenar, recuperar, aadir, borrar, etc.). El proceso de transferencia de datos (DTP) de usuario
u otro proceso en su lugar, debe esperar a que el servidor inicie la conexin al puerto de datos
especificado (puerto 20 en modo activo o estndar) y transferir los datos en funcin de los parmetros que
se hayan especificado.
Vemos tambin en el diagrama que la comunicacin entre cliente y servidor es independiente del sistema
de archivos utilizado en cada computadora, de manera que no importa que sus sistemas operativos sean
distintos, porque las entidades que se comunican entre s son los PI y los DTP, que usan el mismo
protocolo estandarizado: el FTP.
Tambin hay que destacar que la conexin de datos es bidireccional, es decir, se puede usar
simultneamente para enviar y para recibir, y no tiene por qu existir todo el tiempo que dura la conexin
FTP. Pero tena en sus comienzos un problema, y era la localizacin de los servidores en la red. Es decir,
el usuario que quera descargar algn archivo mediante FTP deba conocer en qu mquina estaba
ubicado. La nica herramienta de bsqueda de informacin que exista era Gopher, con todas sus
limitaciones. (Wikipedia, 2016)

3.3 Servidor FTP


Un servidor FTP es un programa especial que se ejecuta en un equipo servidor normalmente conectado a
Internet (aunque puede estar conectado a otros tipos de redes, LAN, MAN, etc.). Su funcin es permitir el
intercambio de datos entre diferentes servidores/ordenadores.
Por lo general, los programas servidores FTP no suelen encontrarse en los ordenadores personales, por lo
que un usuario normalmente utilizar el FTP para conectarse remotamente a uno y as intercambiar
informacin con l.
Las aplicaciones ms comunes de los servidores FTP suelen ser alojamiento web, en el que sus clientes
utilizan el servicio para subir sus pginas web y sus archivos correspondientes; o como servidor de
backup (copia de seguridad) de los archivos importantes que pueda tener una empresa. Para ello, existen
protocolos de comunicacin FTP para que los datos se transmitan cifrados, como el SFTP (Secure File
Transfer Protocol). (Wikipedia, 2016)

3.4 Cliente FTP


Cuando un navegador no est equipado con la funcin FTP, o si se quiere cargar archivos en un ordenador
remoto, se necesitar utilizar un programa cliente FTP. Un cliente FTP es un programa que se instala en el
ordenador del usuario, y que emplea el protocolo FTP para conectarse a un servidor FTP y transferir
archivos, ya sea para descargarlos o para subirlos. (E. Red, 2010)
Para utilizar un cliente FTP, se necesita conocer el nombre del archivo, el ordenador en que reside
(servidor, en el caso de descarga de archivos), el ordenador al que se quiere transferir el archivo (en caso
de querer subirlo nosotros al servidor), y la carpeta en la que se encuentra.
Algunos clientes de FTP bsicos en modo consola vienen integrados en los sistemas operativos,
incluyendo Microsoft Windows, DOS, GNU/Linux y Unix. Sin embargo, hay disponibles clientes con
opciones aadidas e interfaz grfica. Aunque muchos navegadores tienen ya integrado FTP, es ms
confiable a la hora de conectarse con servidores FTP no annimos utilizar un programa cliente.
(Wikipedia, 2016)

4. Definicin de TCP
TCP (que significa Protocolo de Control de Transmisin) es uno de los principales protocolos de la capa
de transporte del modelo TCP/IP. En el nivel de aplicacin, posibilita la administracin de datos que
vienen del nivel ms bajo del modelo, o van hacia l, (es decir, el protocolo IP). Cuando se proporcionan
los datos al protocolo IP, los agrupa en datagramas IP, fijando el campo del protocolo en 6 (para que sepa
con anticipacin que el protocolo es TCP). TCP es un protocolo orientado a conexin, es decir, que
permite que dos mquinas que estn comunicadas controlen el estado de la transmisin.
Las principales caractersticas del protocolo TCP son las siguientes:


TCP permite colocar los datagramas nuevamente en orden cuando vienen del
protocolo IP.

TCP permite que el monitoreo del flujo de los datos y as evitar la saturacin de
la red.

TCP permite que los datos se formen en segmentos de longitud variada para
"entregarlos" al protocolo IP.

TCP permite multiplexar los datos, es decir, que la informacin que viene de
diferentes fuentes (por ejemplo, aplicaciones) en la misma lnea pueda circular
simultneamente.

Por ltimo, TCP permite comenzar y finalizar la comunicacin amablemente.


(CCM, 2016)
Con el uso de protocolo TCP, las aplicaciones pueden comunicarse en forma segura (gracias al de acuse
de recibo -ACK- del protocolo TCP) independientemente de las capas inferiores. Esto significa que los
routers (que funcionan en la capa de Internet) slo tiene que enviar los datos en forma de datagrama, sin
preocuparse con el monitoreo de datos porque esta funcin la cumple la capa de transporte (o ms
especficamente el protocolo TCP). (SITES, s.f.)

4.1 Funciones del TCP

Figura 2: Funciones TCP cliente


Servidor

En la pila de protocolos TCP/IP, TCP es la capa intermedia entre el protocolo de internet (IP) y la
aplicacin. Muchas veces las aplicaciones necesitan que la comunicacin a travs de la red sea confiable.
Para ello se implementa el protocolo TCP que asegura que los datos que emite el cliente sean recibidos
por el servidor sin errores y en el mismo orden que fueron emitidos, a pesar de trabajar con los servicios
de la capa IP, la cual no es confiable. Es un protocolo orientado a la conexin, ya que el cliente y el
servidor deben de anunciarse y aceptar la conexin antes de comenzar a transmitir los datos a ese usuario
que debe recibirlos.
Las conexiones TCP se componen de tres etapas:

1. establecimiento de conexin.
2. transferencia de datos.
3. fin de la conexin.
Para establecer la conexin se usa el procedimiento llamado negociacin en tres pasos (3-way
handshake). Para la desconexin se usa una negociacin en cuatro pasos (4-way handshake). Durante el
establecimiento de la conexin, se configuran algunos parmetros tales como el nmero de secuencia con
el fin de asegurar la entrega ordenada de los datos y la robustez de la comunicacin. (Dallos, s.f.)

4.2 Puertos TCP


Diversos programas TCP/IP pueden ejecutarse simultneamente en Internet (por ejemplo, pueden abrirse
diferentes navegadores de manera simultnea o navegar por pginas HTML mientras se descarga un
archivo de un FTP). Cada uno de estos programas funciona con un protocolo. A veces el equipo debe
poder distinguir las diferentes fuentes de datos.
Por lo tanto, para facilitar este proceso, a cada una de estas aplicaciones puede serle asignada una
direccin nica en equipo, codificada en 16 bits: un puerto (por consiguiente, la combinacin de
direccin IP + puerto es una direccin nica en el mundo denominada socket).
De esta manera, la direccin IP sirve para identificar de manera nica un equipo en la red mientras que el
nmero de puerto especifica la aplicacin a la que se dirigen los datos. As, cuando el equipo recibe
informacin que va dirigida a un puerto, los datos se envan a la aplicacin relacionada. Si se trata de una
solicitud enviada a la aplicacin, la aplicacin se denomina aplicacin servidor. Si se trata de una
respuesta, entonces hablamos de una aplicacin cliente.
Existen miles de puertos (codificados en 16 bits, es decir que se cuenta con 65536 posibilidades). Es por
ello que la IANA (Internet Assigned Numbers Authority [Agencia de Asignacin de Nmeros de
Internet]) desarroll una aplicacin estndar para ayudar con las configuraciones de red.

Los puertos del 0 al 1023 son los "puertos conocidos" o reservados. En trminos
generales, estn reservados para procesos del sistema (daemons) o programas ejecutados por
usuarios privilegiados. Sin embargo, un administrador de red puede conectar servicios con
puertos de su eleccin.

Los puertos del 1024 al 49151 son los "puertos registrados".

Los puertos del 49152 al 65535 son los "puertos dinmicos y/o privados".
A continuacin se indican algunos de los puertos conocidos ms utilizados:

Figura 3: Puertos ms utilizados

Por lo tanto, un servidor (un equipo conectado que ofrece servicios como FTP, Telnet, etc.) cuenta con
nmeros de puerto fijos a los cuales el administrador de red conecta los servicios. Entonces, los puertos
del servidor generalmente se encuentran entre 0 y 1023 (rango de valores relacionado con servicios
conocidos).
Del lado del cliente, el sistema operativo elige el puerto entre aqullos que estn disponibles de forma
aleatoria. Por lo tanto, los puertos del cliente nunca incluirn los puertos que se encuentran entre 0 y
1023, ya que este rango de valores representa a los puertos conocidos. (CCM, 2016)

4.3 Desarrollo de TCP


TCP es un protocolo muy desarrollado y complejo. Sin embargo, mientras mejoras significativas han sido
propuestas y llevadas a cabo a lo largo de los aos, ha conservado las operaciones ms bsicas sin
cambios desde el RFC 793, publicado en 1981. El documento RFC 1122 (Host Requirements for Internet
Hosts), especifica el nmero de requisitos de una implementacin del protocolo TCP. El RFC 2581
(Control de Congestin TCP) es uno de los ms importantes documentos relativos a TCP de los ltimos
aos, describe nuevos algoritmos para evitar la congestin excesiva. En 2001, el RFC 3168 fue escrito
para describir la Notificacin de Congestin Explcita (ECN), una forma de eludir la congestin con
mecanismos de sealizacin. En los comienzos del siglo XXI, TCP es usado en el 95% de todos los
paquetes que circulan por Internet. Entre las aplicaciones ms comunes que usan TCP estn
HTTP/HTTPS (World Wide Web), SMTP/POP3/IMAP (correo electrnico) y FTP (transferencia de
ficheros). Su amplia extensin ha sido la prueba para los desarrolladores originales de que su creacin
estaba excepcionalmente bien hecha.
Recientemente, un nuevo algoritmo de control de congestin fue desarrollado y nombrado como FAST
TCP (Fast Active queue management Scalable Transmission Control Protocol) por los cientficos de
California Institute of Technology (Caltech). Es similar a TCP Vegas en cuanto a que ambos detectan la
congestin a partir de los retrasos en las colas que sufren los paquetes al ser enviados a su destino.

Todava hay un debate abierto sobre si este es un sntoma apropiado para el control de la congestin.
(Almirn, 2003)

5. Definicin de TCP/Vegas
El resultado tangible de este esfuerzo es una nueva implementacin de TCP que nos referimos como TCP
Vegas. Tenga en cuenta que Vegas no implica ningn cambio en la especificacin TCP; no es ms que una
alternativa aplicacin que es capaz de interactuar con cualquier otra aplicacin vlida de TCP. De hecho,
todos los cambios confirmados en el lado de envi.
TCP Vegas posee grandes modificaciones con respecto a las versiones anteriores de TCP. Hasta ahora la
ventana de congestin creca hasta que ocurra una prdida de paquete y cuando esto pasaba, el
throughput de la conexin se degrada. (Handley, June 2000)
La idea del TCP Vegas es controlar y mantener el tamao adecuado de la ventana de manera que no
ocurra la perdida de paquetes y se evite que se degrade el throughput. El TCP Vegas administra el tamao
de la ventana observando RTT (round-trip-times) de los paquetes que el TCP emisor envi con
anterioridad. El RTT es el tiempo desde que el emisor enva el paquete hasta que arriba el ACK
correspondiente. Si el RTT es mayor, TCP Vegas reconoce que la red comienza a estar congestionada y
achica la ventana. Por el contario, si los valores de RTT son ms pequeos, el TCP emisor determina que
la red no est en congestin e incrementa el tamao. Otra de las modificaciones importantes del TCP
Vegas es en el algoritmo de control de congestin, en la fase de slow start. (Herlin)
Vegas utiliza esta idea para medir y controlar la cantidad de datos adicionales, esta conexin tiene en
trnsito, donde por datos adicionales nos referimos a los datos que no han sido enviados si el ancho de
banda utilizado por la conexin exactamente emparejado el ancho de banda disponible de la red.
El objetivo de Vegas es mantener la cantidad "correcta" de datos adicionales en la red. Obviamente, si una
conexin est enviando demasiados datos adicionales, que har que la congestin, menos obvia, si una
conexin est enviando muy pocos datos adicionales, no puede responder con suficiente rapidez a
transitorios aumenta en el ancho de banda de red disponible. Acciones de evitacin de la congestin
Vegas se basan en los cambios de la cantidad estimada de datos adicionales en la red. (Walrand)

5.1 Mtodos de control de congestin


Desde TCP Vegas utiliza base RTT como una estimacin del retardo de propagacin de ruta, su
rendimiento es sensible a la exactitud de base RTT. Por lo tanto, si las conexiones sobreestiman la
propagacin retrasar debido a la base RTT incorrecta, puede tener un impacto sustancial en el rendimiento
de TCP Vegas.
Vamos a considerar en primer lugar un escenario donde las conexiones sobreestiman los retardos de
propagacin y posiblemente conducir el sistema a un estado persistente congestionado. (r.Jain, 1989)
Supongamos que una conexin se inicia cuando hay muchas otras conexiones existentes, la red est
congestionado y las colas son respaldadas. Entonces, debido a la demora de espera de otros atrasados
paquetes, los paquetes de la nueva conexin pueden experimentar retardos de ida y vuelta que son
considerablemente ms grande que el retardo de propagacin real de la ruta de acceso. Por lo tanto, la
nueva conexin se establecer la ventana tamao a un valor tal que se considera que su nmero esperado
de paquetes atrasados encuentra entre y , cuando en realidad tiene muchos ms paquetes atrasados
debido a la estimacin inexacta de la retardo de propagacin de la ruta. Este escenario se repite para cada
nueva conexin, y es posible que este hace que el sistema permanezca en una congestin persistente. (R,
Marzo 2004)

Esto es exactamente lo contrario de un escenario deseable. Cuando la red est congestionada, no


queremos que las nuevas conexiones para hacer el nivel de congestin peor. Esta misma situacin puede
surgir con Reno TCP o TCP Tahoe. Sin embargo, es ms probable que suceda con TCP Vegas debido a su
mecanismo de evitacin de la congestin afinado.
5.1.1 Slow Start
Cuando se inicia una nueva conexin TCP se hace necesario estimar la banda disponible en ese momento
e incrementar, en consecuencia, la CongestionWindow. Inicialmente, cuando la fuente no tiene ninguna
idea de la banda disponible, la CongestionWindow se inicializa a 1 segmento. La fase de Slow Start
incrementa, pues, tal valor exponencialmente, aumentndolo en una unidad por cada ACK recibido, es
decir, duplicndolo a cada RTT, hasta alcanzar el valor asumido por el SlowStartThreshold. Hace falta
considerar, en efecto, que poniendo la ventana de congestin igual a 1 segmento y slo incrementndola
linealmente, se corre el riesgo de bajo-utilizar la banda disponible y someterse a un largo retraso antes de
que el ritmo de envo suba a un nivel aceptable. El mecanismo AIMD slo es eficiente cuando el emisor
TCP usa valores de CongestionWindow cercanos a la banda disponible que ofrecen en ese momento la
red. (IEEE, 2008).La fase de Slow Start acaba cuando el valor de CongestionWindow supera el del
umbral SlowStartThreshold. Al principio de la conexin, este ltimo parmetro es programado a valores
muy altos, de modo que no influye en la consideracin inicial de la banda disponible. Cuando ocurre un
timeout, para poder tener conocimientos del nivel de congestin de la red, se actualiza la variable umbral,
ponindola a la mitad del valor actual del CongestionWindow (de acuerdo con el valor de la misma que
deriva del decremento multiplicativo). El nuevo SlowStartThreshold determina la dimensin de la
ventana a la que tiene que acabar la siguiente fase de Slow Start, y a la que tiene que iniciar la de
Congestin Avoidance, donde es ejecutado el algoritmo AIMD. En el diagrama temporal de la figura
4vienen representadas la evolucin de la ventana de congestin del TCP y la variable umbral. Se hacen
notar las fases de Slow Start que se suceden despus de cada acontecimiento de timeout. (H, Septiembre
2002)

Figura 4: Evolucin de la ventana de congestin de TCP

5.2 Fast Recovery


Para remediar el problema de los largos perodos de inactividad atados al timeout, se ha introducido el
mecanismo de Fast Retransmit. Con este mecanismo el TCP no tiene innecesariamente que esperar a que
venza el timeout para poder retransmitir un segmento. Est previsto que el receptor mande el ACK
relativo a un segmento, aunque no se hayan recibido an los segmentos anteriores a ste. El transmisor
deduce del nmero de ACK duplicados qu recibe, si el segmento se ha perdido o bien est sufriendo

solamente retrasos. En efecto, un ACK duplicado indica el hecho tal que el receptor no puede mandar un
ACK relativo a un segmento llegado fuera de orden, ya que est esperando recibir de uno precedente.
(C.Liu, Noviembre 2004)

5.3 TCP/VEGAS
Con la recepcin de un nuevo ACK:
Si cnwd =< ssthresh
1. cwnd ++una vez por medio
2. Enve la ventana disponible.
En cambio si cnwd > ssthresh, pase a congestin Avoidance para procesamiento del ACK
Con la recepcin de un ACK duplicado:
Si el nmero de acks consecutivos duplicados es menor que 3, no haga nada
En cambio si el nmero de acks consecutivos es igual a 3, pase al estado de FastRetransmit de Fast
Retransmission/Recovery
Como se observa, slow start en Vegas incrementa la ventana de congestionamiento ms lentamente que
Reno al incrementar cnwd una vez por medio en vez de hacerlo con el arribo de cada ack.

6. Bibliografa
Almirn, Y. (2003). Time Rime. Obtenido de
http://timerime.com/es/evento/2011289/Vint+Cerf+y+Robert+Kahn+crean+el+TCP/
Bolo, F. (2 de Agosto de 2011). M. Filetransfer. Obtenido de
https://managefiletransfer.wordpress.com/2011/08/02/mft-b2bconsulting/
C.Liu, R. J. (Noviembre 2004). Approaches of wireless TCP.

CCM. (Junio de 2016). CCM. Obtenido de http://es.ccm.net/contents/281-protocolo-tcp


Dallos, A. (s.f.). SITES. Obtenido de
https://sites.google.com/site/protocolosderedes2/protocolo-tcp
E. Red. (2010). EcuRed. Obtenido de http://www.ecured.cu/Cliente_FTP

H, E. (Septiembre 2002). Improving TCP Performance. Vol 34.


Handley, M. (June 2000). TCP congestion Windows Validation. Espaa: RFC.
Herlin, D. R. (s.f.). Explorando posiibles mejoras de protocolo TCP. Argentina: Ciencias
Exactas e Informatica.
IEEE. (2008). El Protocolo TCP. Ethernet/IEEE.

R, T. F. (Marzo 2004). TCP sobre enlaces wireless. Republica: Facultad de Republica.


r.Jain, D. (1989). Redes Informaticas. California: University of California.
Rouse, M. (Julio de 2015). S. EnterpriseWAN. Obtenido de
http://searchenterprisewan.techtarget.com/definition/File-Transfer-Protocol
SITES. (s.f.). Sites. Obtenido de
https://sites.google.com/site/aaronyabrahambh/topologias-de-red/componentes-de-unared-local/a-tarjetas-de-red/5-protocolo-tcp-ip-de-comunicacion/funcion-del-protocolo-tcp
Walrand, R. J. (s.f.). Issues and TCP/Vegas. California: University of California.

Wikipedia. (13 de mayo de 2016). Wikipedia . Obtenido de


https://es.wikipedia.org/wiki/File_Transfer_Protocol#cite_note-1