Protocolo FTP

Protocolo FTP (Protocolo de transferencia de archivos)

DEUSESFRITBR

Junio 2013

Introducción al protocolo FTP

El protocolo FTP (Protocolo de transferencia de archivos) es, como su nombre lo indica,

un protocolo para transferir archivos.

La implementación del FTP se remonta a 1971 cuando se desarrolló un sistema de

transferencia de archivos (descrito en RFC141) entre equipos del Instituto Tecnológico de

Massachusetts (MIT, Massachusetts Institute of Technology). Desde entonces, diversos

documentos de RFC (petición de comentarios) han mejorado el protocolo básico, pero las

innovaciones más importantes se llevaron a cabo en julio de 1973.

Actualmente, el protocolo FTP está definido por RFC 959 (Protocolo de transferencia de

archivos (FTP) - Especificaciones).

La función del protocolo FTP

El protocolo FTP define la manera en que los datos deben ser transferidos a través de una

red TCP/IP.

El objetivo del protocolo FTP es:

permitir que equipos remotos puedan compartir archivos

permitir la independencia entre los sistemas de archivo del equipo del cliente y del equipo

del servidor

permitir una transferencia de datos eficaz

El modelo FTP

El protocolo FTP está incluido dentro del modelo cliente-servidor, es decir, un equipo envía

órdenes (el cliente) y el otro espera solicitudes para llevar a cabo acciones (el servidor).

Durante una conexión FTP, se encuentran abiertos dos canales de transmisión:

Un canal de comandos (canal de control)

Un canal de datos

http://de.kioskea.net/contents/25-das-ftp-protokoll-file-transfer-protocol

http://en.kioskea.net/contents/272-ftp-protocol-file-transfer-protocol

http://es.kioskea.net/contents/263-protocolo-ftp-protocolo-de-transferencia-de-archivos

http://www.commentcamarche.net/contents/519-le-protocole-ftp-file-transfer-protocol

http://it.kioskea.net/contents/25-il-protocollo-ftp-file-transfer-protocol

http://pt.kioskea.net/contents/265-o-protocolo-ftp-file-transfer-protocol

Por lo tanto, el cliente y el servidor cuentan con dos procesos que permiten la administración de

estos dos tipos de información:

DTP (Proceso de transferencia de datos) es el proceso encargado de establecer la conexión

y de administrar el canal de datos. El DTP del lado del servidor se denomina SERVIDOR

DE DTP y el DTP del lado del cliente se denomina USUARIO DE DTP.

PI (Intérprete de protocolo) interpreta el protocolo y permite que el DTP pueda ser

controlado mediante los comandos recibidos a través del canal de control. Esto es diferente

en el cliente y el servidor:

El SERVIDOR PI es responsable de escuchar los comandos que provienen de un

USUARIO PI a través del canal de control en unpuerto de datos, de establecer la

conexión para el canal de control, de recibir los comandos FTP del USUARIO PI a

través de éste, de responderles y de ejecutar el SERVIDOR DE DTP.

El USUARIO PI es responsable de establecer la conexión con el servidor FTP, de

enviar los comandos FTP, de recibir respuestas del SERVIDOR PI y de controlar al

USUARIO DE DTP, si fuera necesario.

Cuando un cliente FTP se conecta con un servidor FTP, el USUARIO PI inicia la conexión con

el servidor de acuerdo con el protocolo Telnet. El cliente envía comandos FTP al servidor, el

servidor los interpreta, ejecuta su DTP y después envía una respuesta estándar. Una vez que

se establece la conexión, el servidor PI proporciona el puerto por el cual se enviarán los datos

al Cliente DTP. El cliente DTP escucha el puerto especificado para los datos provenientes del

servidor.

Es importante tener en cuenta que, debido a que los puertos de control y de datos son canales

separados, es posible enviar comandos desde un equipo y recibir datos en otro. Entonces, por

ejemplo, es posible transferir datos entre dos servidores FTP mediante el paso indirecto por un

cliente para enviar instrucciones de control y la transferencia de información entre dos procesos

del servidor conectados en el puerto correcto.

En esta configuración, el protocolo indica que los canales de control deben permanecer

abiertos durante la transferencia de datos. De este modo, un servidor puede detener una

transmisión si el canal de control es interrumpido durante la transmisión.

Los comandos FTP

Toda comunicación que se realice en el canal de control sigue las recomendaciones del

protocolo Telnet. Por lo tanto, los comandos FTP son cadenas de caracteres Telnet (en código

NVT-ASCII) que finalizan con el código de final de línea Telnet (es decir, la secuencia

<CR>+<LF>, Retorno de carro seguido del carácter Avance de línea indicado como

<CRLF>).

Si el comando FTP tiene un parámetro, éste se separa del comando con un espacio (<SP>).

Los comandos FTP hacen posible especificar:

El puerto utilizado

El método de transferencia de datos

La estructura de datos

La naturaleza de la acción que se va a realizar (Recuperar, Enumerar, Almacenar, etc.)

Existen tres tipos de comandos FTP diferentes:

Comandos de control de acceso

Comandos de parámetros de transferencia

Comandos de servicio FTP

Comandos de control de acceso

Comando Descripción

USERCadena de caracteres que permite identificar al usuario. La identificación del usuario es necesaria para establecer la comunicación a través del canal de datos.

PASS

Cadena de caracteres que especifica la contraseña del usuario. Este comando debe ser inmediatamente precedida por el comando USER. El cliente debe decidir si esconder la visualización de este comando por razones de seguridad.

ACCT

Cadena de caracteres que especifica la cuenta del usuario. El comando generalmente no es necesario. Durante la respuesta que acepta la contraseña, si la respuesta es 230, esta etapa no es necesaria; Si la respuesta es 332, sí lo es.

CWDChange Working Directory (Cambiar el directorio de trabajo): este comando permite cambiar el directorio actual. Este comando requiere la ruta de acceso al directorio para que se complete como un argumento.

CDUP

Change to Parent Directory (Cambiar al directorio principal): este comando permite regresar al directorio principal. Se introdujo para resolver los problemas de denominación del directorio principal según el sistema (generalmente "..").

SMNT Structure Mount (Montar estructura):

REIN Reinitialize (Reinicializar):

QUITComando que permite abandonar la sesión actual. Si es necesario, el servidor espera a que finalice la transferencia en progreso y después proporciona una respuesta antes de cerrar la conexión.

Comandos de parámetros de transferencia


PORTCadena de caracteres que permite especificar el número de puerto utilizado.

PASV

Comando que permite indicar al servidor de DTP que permanezca a la espera de una conexión en un puerto específico elegido aleatoriamente entre los puertos disponibles. La respuesta a este comando es la dirección IP del equipo y el puerto.

TYPEEste comando permite especificar el tipo de formato en el cual se enviarán los datos.

STRUCarácter Telnet que especifica la estructura de archivos (F de File [Archivo], R de Record [Registro], P de Page [Página]).

MODECarácter Telnet que especifica el método de transferencia de datos (S deStream [Flujo], B de Block [Bloque], C de Compressed [Comprimido]).

Comandos de servicio FTP


RETREste comando (RETRIEVE [RECUPERAR]) le pide al servidor de DTP una copia del archivo cuya ruta de acceso se da en los parámetros.

STOR

Este comando (store [almacenar]) le pide al servidor de DTP que acepte los datos enviados por el canal de datos y que los almacene en un archivo que lleve el nombre que se da en los parámetros. Si el archivo no existe, el servidor lo crea; de lo contrario, lo sobrescribe.

STOUEste comando es idéntico al anterior, sólo le pide al servidor que cree un archivo cuyo nombre sea único. El nombre del archivo se envía en la respuesta.

APPEGracias a este comando (append [adjuntar]) los datos enviados se concatenan en el archivo que lleva el nombre dado en el parámetro si ya existe; si no es así, se crea.

ALLOEste comando (allocate [reservar]) le pide al servidor que reserve un espacio de almacenamiento lo suficientemente grande como para recibir el archivo cuyo nombre se da en el argumento.

REST

Este comando (restart [reiniciar]) permite que se reinicie una transferencia desde donde se detuvo. Para hacer esto, el comando envía en el parámetro el marcador que representa la posición en el archivo donde la transferencia se había interrumpido. Después de este comando se debe enviar inmediatamente un comando de transferencia.

RNFR

Este comando (rename from [renombrar desde]) permite volver a nombrar un archivo. En los parámetros indica el nombre del archivo que se va a renombrar y debe estar inmediatamente seguido por el comando RNTO.

RNTOEste comando (rename from [renombrar a]) permite volver a nombrar un archivo. En los parámetros indica el nombre del archivo que se va a renombrar y debe estar inmediatamente seguido por el comando RNFR.

ABOR

Este comando (abort [cancelar]) le indica al servidor de DTP que abandone todas las transferencias asociadas con el comando previo. Si no hay conexión de datos abierta, el servidor de DTP no realiza ninguna acción; de lo contrario, cierra la conexión. Sin embargo, el canal de control permanece abierto.

DELEEste comando (delete [borrar]) permite que se borre un archivo, cuyo nombre se da en los parámetros. Este comando es irreversible y la confirmación sólo puede darse a nivel cliente.

RMDEste comando (remove directory [eliminar directorio]) permite borrar un directorio. El nombre del directorio que se va a borrar se indica en los parámetros.

MKDEste comando (make directory [crear directorio]) permite crear un directorio. El nombre del directorio que se va a crear se indica en los parámetros.

PWDEste comando (print working directory [mostrar el directorio actual]) hace posible volver a enviar la ruta del directorio actual completa.

LIST

Este comando permite que se vuelva a enviar la lista de archivos y directorios presentes en el directorio actual. Esto se envía a través del DTP pasivo. Es posible indicar un nombre de directorio en el parámetro de este comando. El servidor de DTP enviará la lista de archivos del directorio ubicado en el parámetro.

NLSTEste comando (name list [lista de nombres]) permite enviar la lista de archivos y directorios presentes en el directorio actual.

SITEEste comando (site parameters [parámetros del sistema]) hace que el servidor proporcione servicios específicos no definidos en el protocolo FTP.

SYSTEste comando (system [sistema]) permite el envío de información acerca del servidor remoto.

STAT

Este comando (Estado: [estado]) permite transmitir el estado del servidor; por ejemplo, permite conocer el progreso de una transferencia actual. Este comando acepta una ruta de acceso en el argumento y después devuelve la misma información que LISTA pero a través del canal de control.

HELPEste comando permite conocer todos los comandos que el servidor comprende. La información se devuelve por el canal de control.

NOOPEste comando (no operations [no operación]) sólo se utiliza para recibir un comando OK del servidor. Sólo se puede utilizar para no desconectarse después de un período de inactividad prolongado.

Las respuestas FTP

Las respuestas FTP garantizan la sincronización entre el cliente y el servidor FTP. Por lo tanto,

por cada comando enviado por el cliente, el servidor eventualmente llevará a cabo una acción y

sistemáticamente enviará una respuesta.

Las respuestas están compuestas por un código de 3 dígitos que indica la manera en la que el

comando enviado por el cliente ha sido procesado. Sin embargo, debido a que el código de 3

dígitos resulta difícil de leer para las personas, está acompañado de texto (cadena de

caracteres Telnet separada del código numérico por un espacio).

Los códigos de respuesta están compuestos por 3 números, cuyos significados son los

siguientes:

El primer número indica el estatuto de la respuesta (exitosa o fallida)

El segundo número indica a qué se refiere la respuesta.

El tercer número brinda un significado más específico (relacionado con cada segundo

dígito).

Primer número

Dígito Significado Descripción

1yzRespuesta positiva preliminar

La acción solicitada está en progreso. Se debe obtener una segunda respuesta antes de enviar un segundo comando.

2yzRespuesta de finalización positiva

La acción solicitada se ha completado y puede enviarse un nuevo comando.

3yzRespuesta intermedia positiva

La acción solicita está temporalmente suspendida. Se espera información adicional del cliente.

4yzRespuesta de finalización negativa

La acción solicitada no se ha realizado debido a que el comando no se ha aceptado temporalmente. Se le solicita al cliente que intente más tarde.

5yzRespuesta negativa permanente

La acción solicitada no se ha realizado debido a que el comando no ha sido aceptado. Se le solicita al cliente que formule una solicitud diferente.

Segundo número

Dígito Significado Descripción

x0z SintaxisLa acción tiene un error de sintaxis o sino, es un comando que el servidor no comprende.

x1z InformaciónÉsta es una respuesta que envía información (por ejemplo, una respuesta a un comando STAT).

x2z Conexiones La respuesta se refiere al canal de datos.

x3zAutenticación y cuentas

La respuesta se refiere al inicio de sesión (USUARIO/CONTRASEÑA) o a la solicitud para cambiar la cuenta (CPT).

x4zNo utilizado por el protocolo FTP.

x5zSistema de archivos

La respuesta se relaciona con el sistema de archivos remoto.

Más información

Red Grupo de Trabajo J. PostelPetición de Comentarios: 959 J. Reynolds ISIObsoletes RFC: 765 (IEN 149) octubre 1985

File Transfer Protocol (FTP)

Condición de este Memo

Esta nota es la especificación oficial de la transferencia de archivos Protocol (FTP). La distribución de este memo es ilimitada.

Los nuevos comandos opcionales siguientes se incluyen en esta edición de pliego de condiciones:

CDUP (Cambie al directorio principal), SMNT (Estructura Mount), STOU (Tienda Unique), RMD (Remove Directory), MKD (Agrega Directory), PWD (Imprimir directorio), y SYST (System).

Tenga en cuenta que esta especificación es compatible con la edición anterior.

1. INTRODUCCIÓN

Los objetivos del FTP son 1) promover el intercambio de archivos (ordenador programas y / o datos), 2) fomentar la indirecta o implícita (a través de programas), el uso de equipos remotos, 3) para proteger a un usuario variaciones en los sistemas de almacenamiento de archivos entre ordenadores, y 4) para transferir datos fiable y eficiente. FTP, aunque utilizable directamente por un usuario en un terminal, está diseñado principalmente para su uso por los programas.

El intento de esta especificación es satisfacer las diversas necesidades de los usuarios de maxi-hosts, mini-hosts, estaciones de trabajo personales y TAC, con un protocolo de diseño simple, y fácil de implementar.

En este trabajo se asume el conocimiento del Protocolo de Control de Transmisión (TCP) [2] y el Protocolo Telnet [3]. Estos documentos se encuentran en el protocolo del manual de ARPA-Internet [1].

2. PANORAMA

En esta sección, la historia, la terminología y el modelo FTP son discutido. Los términos definidos en esta sección son únicamente los que tienen un significado especial en FTP. Parte de la terminología es muy

específico para el modelo FTP, algunos lectores tal vez deseen recurrir a la sección sobre el modelo FTP al revisar la terminología.

Postel & Reynolds [Página 1]

RFC 959 10 1985Protocolo de transferencia de archivos

2.1. HISTORIA

FTP ha tenido una larga evolución a lo largo de los años. Apéndice III es un compilación cronológica de Solicitud de documentos Comentarios relativa a FTP. Estos incluyen la primera propuesta de transferencia de archivos mecanismos en 1971 que fueron desarrolladas para la implementación de los ejércitos en el MIT (RFC 114), además de comentarios y discusión en el RFC 141.

RFC 172 proporciona un protocolo orientado a nivel de usuario para la transferencia de archivos entre equipos host (PIM incluyendo terminales). Una revisión de la esto como RFC 265 de FTP actualizados para la revisión adicional, mientras RFC 281 sugieren nuevos cambios. El uso de un "conjunto de tipos de datos" transacción fue propuesto en el RFC 294 en enero de 1982.

RFC 354 RFC obsoletos 264 y 265. El Protocolo de transferencia de archivos ahora se define como un protocolo de transferencia de archivos entre los hosts de la ARPANET, con la función principal de FTP define como transferir archivos de manera eficiente y confiable entre los hosts y permitiendo el uso práctico de las capacidades de almacenamiento de archivos remotos. RFC 385 observaciones respecto a los errores, puntos de énfasis y adiciones al protocolo, mientras RFC 414 presentó un informe de situación en el servidor de trabajo y FTPs usuario. RFC 430, publicado en 1973, (Entre otras RFCs demasiado numerosos para mencionarlos) presentaron mayor comentarios sobre FTP. Por último, un documento FTP "oficial" fue publicada como RFC 454.

Para julio de 1973 considerables cambios de las últimas versiones de FTP se hicieron, pero la estructura general sigue siendo la misma. RFC 542 fue publicado como una nueva especificación "oficial" para reflejar estos cambios. Sin embargo, muchas implementaciones basadas en la mayor especificación no se han actualizado.

En 1974, RFC 607 y 614 continuos comentarios sobre FTP. RFC 624 propone más cambios de diseño y modificaciones de menor importancia. En el año 1975, RFC 686, titulado "Dejando las cosas como estaban", habló sobre la las diferencias entre todas las versiones anteriores y posteriores de FTP. RFC 691 presenta una revisión menor del RFC 686, en relación con la tema de archivos de impresión.

Motivados por la transición del NCP al TCP como subyacentes del protocolo, un fénix nació de todo lo anterior esfuerzos en RFC 765 como la especificación de FTP para su uso en TCP.

La presente edición de la especificación FTP pretende corregir algunos errores leves de documentación, para mejorar la explicación de algunas de las características del protocolo, y para añadir algo nuevo comandos opcionales.



En particular, los siguientes nuevos comandos opcionales se incluyen en esta edición de la especificación:

CDUP - Cambiar al directorio superior

SMNT - Montaje de Estructura

STOU - tienda Unique

RMD - Soltar el Directorio

MKD - Haga Directory

PWD - Directorio Imprimir

SYST - Sistema

Esta especificación es compatible con la edición anterior. La

programa implementado en conformidad con la especificación anterior debería ser automática en conformidad con esta especificación.

2.2. TERMINOLOGÍA

ASCII

El juego de caracteres ASCII es como se define en el ARPA-Internet Manual de Protocolo. En FTP, caracteres ASCII se definen como la mitad inferior de un conjunto de códigos de ocho bits (es decir, el más bit más significativo es cero).

controles de acceso

Los controles de acceso definen los privilegios de acceso de los usuarios a la utilización de un sistema, y para los archivos en ese sistema. Los controles de acceso son necesarias para impedir el uso no autorizado o accidental de archivos. Es prerrogativa de un proceso de servidor FTP para invocar acceso controles.

tamaño en bytes

Hay dos tamaños de byte de interés en FTP: el byte lógico tamaño del archivo y el tamaño en bytes de transferencia usada para la transmisión de los datos. El tamaño en bytes de transferencia es siempre 8 los bits. El tamaño en bytes de transferencia no es necesariamente el tamaño en bytes en el que los datos se va a almacenar en un sistema, ni el byte lógico tamaño de interpretación de la estructura de los datos.



conexión de control

La ruta de comunicación entre el usuario y el servidor-PI-PI para el intercambio de comandos y respuestas. Esta conexión sigue el Protocolo Telnet.

conexión de datos

Una conexión dúplex total sobre la que los datos se transfieren, en un

el modo y tipo especificados. Los datos transferidos pueden ser una parte de un archivo, un archivo o una serie de archivos. La ruta puede ser entre un servidor-DTP y un usuario-DTP, o entre dos servidor DTPs.

puerto de datos

El proceso de transferencia de datos pasiva "escucha" en el puerto de datos para una conexión desde el proceso de transferencia activo con el fin de abrir la conexión de datos.

DTP

El proceso de transferencia de datos establece y gestiona los datos conexión. La DTP puede ser pasiva o activa.

Fin de Línea

La secuencia de fin de línea define la separación de la impresión líneas. La secuencia es el retorno de carro seguido por salto de línea.

EOF

La condición de final de archivo que define el final de un archivo que se está transferido.

EOR

La condición de fin-de-registro que define el final de un registro que se transfiere.

recuperación de errores

Un procedimiento que permite a un usuario recuperar a partir de ciertos errores tales como la falta de cualquiera de los sistemas de acogida o el proceso de transferencia. En FTP, recuperación de errores puede implicar reiniciar una transferencia de archivos en una dado puesto de control.



Comandos FTP

Un conjunto de comandos que componen la información de control de flujo del usuario FTP para el proceso del servidor FTP.

expediente

Un conjunto ordenado de datos informáticos (incluidos los programas), de longitud arbitraria, identificada de forma única por un nombre de ruta.

modo

El modo en que los datos se va a transferir a través de los datos conexión. El modo define el formato de los datos durante la transferencia de incluyendo EOR y EOF. Los modos de transferencia son definidos en el FTP se describe en la sección sobre Modos de transmisión.

NVT

La Terminal Virtual de la Red tal como se define en el Protocolo Telnet.

NVFS

El sistema de archivos de red virtual. Un concepto que define una sistema de archivos de red estándar con los comandos estándar y convenciones pathname.

página

Un archivo puede estar estructurado como un conjunto de partes independientes llamado páginas. FTP es compatible con la transmisión de archivos discontinuos como indexado páginas independientes.

ruta

Nombre de ruta se define como la cadena de caracteres que deben ser de entrada a un sistema de archivo por un usuario con el fin de identificar un archivo. Pathname normalmente contiene el dispositivo y / o nombres de directorio y especificación de nombre de archivo. FTP no ha especificado todavía un estándar convención ruta. Cada usuario debe seguir la nomenclatura de archivos convenciones de los sistemas de archivos que intervienen en la transferencia.

PI

El intérprete de protocolo. El usuario y el servidor de los lados de la protocolo tiene distintas funciones implementadas en un usuario-PI y servidor-PI.



registro

Un archivo secuencial puede ser estructurado como una serie de contiguos partes llamados registros. Estructuras de registro son compatibles con FTP pero un archivo no tiene que tener una estructura de registros.

responder

Una respuesta es un acuse de recibo (positivo o negativo) enviada desde servidor al usuario a través de la conexión de control en respuesta a FTP comandos. La forma general de una respuesta es un código de terminación (Incluyendo códigos de error) seguido de una cadena de texto. Los códigos son para uso de los programas y el texto se administra generalmente por los usuarios humanos.

servidor DTP

El proceso de transferencia de datos, en su estado normal "activo", establece la conexión de datos con el puerto de datos "escuchar". En él se establecen los parámetros para la transferencia y el almacenamiento y las transferencias datos sobre el comando de su PI. La DTP se puede colocar en un Estado "pasivo" para escuchar, en lugar de iniciar un conexión en el puerto de datos.

proceso del servidor FTP

Un proceso o conjunto de procesos que realizan la función de transferencia de archivos en cooperación con un proceso de usuario-FTP y, posiblemente, otro servidor. Las funciones consisten en un protocolo intérprete (PI) y un proceso de transferencia de datos (DTP).

servidor-PI

El intérprete de protocolo del servidor "escucha" en el puerto de L conexión de un usuario-PI y establece un control conexión de comunicación. Recibe comandos FTP estándar por parte del usuario-PI, envía respuestas y rige el servidor-DTP.

tipo

El tipo de representación de datos utilizado para la transferencia de datos y almacenamiento. Tipo implica ciertas transformaciones entre el momento de transferencia de datos y almacenamiento de datos. Los tipos de representación definido en FTP se describen en la sección sobre el establecimiento de Conexiones de datos.



usuario

Una persona o un proceso en nombre de una persona que desee obtener servicios de archivos de transferencia. El usuario humano puede interactuar directamente con un proceso de servidor FTP-, pero el uso de un proceso de usuario-FTP es preferido ya que el diseño del protocolo se pondera hacia autómatas.

user-DTP

El proceso de transferencia de datos "escucha" en el puerto de datos para una Conexión de un proceso de servidor FTP. Si dos servidores son la transferencia de datos entre ellos, el usuario-DTP está inactivo.

proceso de usuario-FTP

Un conjunto de funciones que incluyen un intérprete de protocolo, los datos la transferencia de procesos y una interfaz de usuario que en conjunto realizan la función de transferencia de archivos en cooperación con uno o más procesos del servidor FTP. La interfaz de usuario permite que un local de

idioma que se utilizará en el diálogo de comandos-respuesta con el usuario.

user-PI

El intérprete de protocolo de usuario inicia la conexión de control de su U puerto al proceso del servidor FTP, FTP inicia comandos, y gobierna el usuario-DTP si ese proceso es parte de la transferencia de archivos.



2.3. EL MODELO FTP

Con las definiciones anteriores en mente, el modelo siguiente (se muestra en la Figura 1) puede ser diagramado para un servicio FTP.

------------- | / --------- \ | | | Usuario | | -------- | | Interfaz | <---> | Usuario | | \ ---- ^ ---- / | -------- ---------- | | | | / \ | ------ Comandos FTP | / ---- V ---- \ | | | Servidor | <----------------> | Usuario | | | | PI | | FTP Respuestas | | PI | | | \ - ^ --- / | | \ ---- ^ ---- / | | | | | | | -------- | / - V --- \ | Datos | / ---- V ---- \ | --------

| Archivo | <---> | Servidor | <----------------> | Usuario | <---> | Archivo | | Sistema | | | DTP | | conexión | | DTP | | | Sistema | -------- | \ ------ / | | \ --------- / | -------- -----------------------

Servidor FTP USUARIO FTP

NOTAS: 1. La conexión de datos puede ser utilizado en cualquier dirección. 2. La conexión de datos no tiene por qué existir todo el tiempo.

Figura 1 Modelo para FTP Uso

En el modelo descrito en la figura 1, el intérprete de protocolo de usuario inicia la conexión de control. La conexión de control sigue el protocolo Telnet. En el inicio del usuario, de los FTP comandos son generados por el usuario-PI y se transmiten a la proceso de servidor a través de la conexión de control. (El usuario puede establecer una conexión de control directa con el servidor de FTP-, a partir de una Terminal de TAC por ejemplo, y generar comandos estándar de FTP independiente, sin pasar por el proceso de usuario FTP.) respuestas estándar se envían desde el servidor-PI para el usuario-PI sobre el control conexión en respuesta a los comandos.

Los comandos FTP especifican los parámetros para la conexión de datos (Puerto de datos, modo de transferencia, tipo de representación y estructura) y la naturaleza de la operación del sistema de archivos (almacenar, recuperar, añadir, borrar, etc.) El usuario-DTP o designada debe "escuchar" en la el puerto de datos especificado, y el servidor inicien los datos la conexión y la transferencia de datos de acuerdo con la especificada parámetros. Cabe señalar que el puerto de datos no necesita ser en



el mismo host que inicia los comandos FTP a través del control conexión, pero el usuario o el proceso de usuario-FTP deben garantizar un "Escuchar" en el puerto de datos especificado. Debería también tenerse en cuenta que la conexión de datos puede ser utilizado para envío simultáneo y receptora.

En otra situación, un usuario podría desear transferir archivos entre dos ejércitos, ninguno de los cuales es un anfitrión local. El usuario configura controlar las conexiones a los dos servidores y arreglos para una conexión de datos entre ellos. De esta manera, controlar la información se pasa al usuario-PI, pero los datos se transfieren entre el procesos de transferencia de datos del servidor. A continuación se presenta un modelo de este interacción servidor-servidor.

Control ------------ control ----------> | Usuarios FTP | <----------- | | Usuario-PI | | | | "C" | | V ------------ V ---------------------------- | Servidor FTP | Conexión de datos | servidor FTP | | "A" | <----------------------> | "B" | -------------- Puerto (A) Puerto (B) --------------

La figura 2

El protocolo requiere que las conexiones de control se abren mientras la transferencia de datos está en curso. Es la responsabilidad del usuario solicitar el cierre de las conexiones de control cuando terminado de utilizar el servicio FTP, mientras que es el servidor que toma la acción. La transferencia de datos puede abortar si el control de servidor conexiones se cierran sin comando.

La relación entre FTP y Telnet:

El FTP utiliza el protocolo Telnet de la conexión de control. Esto se puede lograr de dos maneras: primero, el usuario-PI o la servidor-PI puede aplicar las normas del Protocolo Telnet directamente en sus propios procedimientos, o, en segundo lugar, el usuario-PI o el servidor-PI puede hacer uso del módulo de Telnet existente en el sistema.

Facilidad de implementaion, códigos compartidos, y la programación modular argumentar a favor de la segunda opción. La eficiencia y la independencia



argumentar a favor de la primera aproximación. En la práctica, FTP se basa en muy poco del protocolo Telnet, por lo que el primer enfoque no necesariamente implicar una gran cantidad de código.

3. FUNCIONES DE TRANSFERENCIA DE DATOS

Los archivos se transfieren únicamente a través de la conexión de datos. El control conexión se utiliza para la transferencia de comandos, que describen el funciones que se deben realizar, y las respuestas a estos comandos (ver la Sección de Respuestas FTP). Varios comandos se refieren a la la transferencia de datos entre hosts. Estos comandos de transferencia de datos incluyen el comando MODE, que especifican cómo los bits de los datos han de ser transmitida, y los comandos de tipo de estructura y que se utilizan para definir la forma en que los datos van a ser representado. La la transmisión y la representación son básicamente independientes pero el "Corriente" modo de transmisión depende de la estructura de archivos atributo y si se utiliza el modo de transmisión "comprimido", la naturaleza del byte de relleno depende del tipo de representación.

3.1. REPRESENTACIÓN DE DATOS Y ALMACENAMIENTO

Los datos se transfieren desde un dispositivo de almacenamiento en el envío de acogida a un dispositivo de almacenamiento en el host receptor. A menudo es necesario realizar ciertas transformaciones en los datos, ya que el almacenamiento de datos representaciones en los dos sistemas son diferentes. Por ejemplo, NVT-ASCII tiene diferentes representaciones de almacenamiento de datos en los diferentes sistemas. Diciembre TOPS-20 es generalmente almacenar NVT-ASCII como cinco de 7 bits Caracteres ASCII, justificado a la izquierda en una palabra de 36 bits. IBM Mainframe de tienda NVT-ASCII como códigos EBCDIC de 8 bits. Multics tiendas NVT-ASCII como cuatro caracteres 9 bits en una palabra de 36 bits. Es deseable convertir los caracteres en la representación NVT-ASCII estándar cuando la transmisión de texto entre sistemas diferentes. El envío y la los sitios de recepción tendría que llevar a cabo la necesaria transformaciones entre la representación y su nivel representaciones internas.

Un problema diferente en representación surge cuando se transmite datos binarios (códigos de carácter no) entre los sistemas host con diferentes longitudes de palabra. No siempre está claro cómo el emisor deberán enviar los datos, y el receptor almacena. Por ejemplo, cuando transmisión de bytes de 32 bits de un sistema de longitud de palabra de 32 bits a una Sistema de longitud de palabra de 36 bits, puede ser deseable (por razones de eficiencia y utilidad) para almacenar los bytes de 32 bits justificado a la derecha en una palabra de 36 bits en el segundo sistema. En cualquier caso, el usuario debe tener la opción de especificar los datos representación y funciones de transformación. Cabe señalar



que la FTP establece representaciones de tipos de datos muy limitados. Transformaciones deseados más allá de esta capacidad limitada deben ser realizada por el usuario directamente.

3.1.1. TIPOS DE DATOS

Representaciones de datos se manejan de FTP por un usuario especificando un Tipos de representación. Este tipo puede implícitamente (como en ASCII o EBCDIC) o explícitamente (como en el byte local) definen un tamaño de bytes de interpretación que se conoce como el "tamaño de byte lógico." Tenga en cuenta que esto no tiene nada que ver con el tamaño en bytes utilizado para transmisión a través de la conexión de datos, llamado el "transferencia tamaño en bytes ", y los dos no deben confundirse. Por ejemplo, NVT-ASCII tiene un tamaño de byte lógico de 8 bits. Si el tipo es Byte local, entonces el comando TYPE tiene una segunda condición para parámetro que especifica el tamaño de byte lógico. El byte de transferencia tamaño es siempre de 8 bits.

3.1.1.1. TIPO ASCII

Este es el tipo por defecto y debe ser aceptado por todos FTP

implementaciones. Se piensa sobre todo para la transferencia de archivos de texto, excepto cuando ambos hosts encontrarían el EBCDIC escribir más conveniente.

El remitente convierte los datos de carácter interno representación con el estándar de 8 bits NVT-ASCII representación (ver la especificación Telnet). El receptor convertirá los datos de la forma estándar a su propio forma interna.

De acuerdo con el estándar NVT, la secuencia <CRLF> debe ser utilizado cuando sea necesario para indicar el final de una línea de texto. (Véase el análisis de la estructura del archivo al final de la Sección de representación de datos y de almacenamiento.)

Con la representación NVT-ASCII estándar significa que los datos debe interpretarse en bytes de 8 bits.

El parámetro de formato para los tipos ASCII y EBCDIC se discute a continuación.



3.1.1.2. TIPO EBCDIC

Este tipo está destinado para una transferencia eficaz entre los hosts que el uso EBCDIC por su carácter interno representación.

Para la transmisión, los datos se representan como EBCDIC de 8 bits personajes. El código de carácter es la única diferencia entre las especificaciones funcionales de EBCDIC y ASCII tipos.

End-of-line (en lugar de al final de su registro - ver la discusión de la estructura), probablemente se utiliza raramente con el tipo EBCDIC

para los propósitos de que denota la estructura, pero donde está necesario el carácter <NL> se debe utilizar.

3.1.1.3. TIPO DE IMAGEN

Los datos se envían en forma de bits contiguos que, para la transferencia, se empaquetan en los bytes de transferencia de 8 bits. La recepción de sitio debe almacenar los datos como bits contiguos. La estructura del sistema de almacenamiento podría requerir el relleno de la archivo (o de cada registro, para un archivo de registros estructurados) para algún límite práctico (byte, palabra o bloque). Este acolchado, que deben ser todos ceros, puede producirse sólo en el extremo del archivo (o al final de cada registro) y debe haber una forma de identificar los bits de relleno de modo que puedan ser despojado de si se recupera el archivo. El relleno transformación debe ser bien publicitado para permitir a un usuario procesar un archivo en el lugar de almacenamiento.

Tipo de imagen está destinado para el almacenamiento eficiente y la recuperación de archivos y para la transferencia de datos binarios. Lo Se recomienda que este tipo de ser aceptada por todos FTP implementaciones.

3.1.1.4. TIPO DE LOCAL

Los datos se transfieren en bytes lógicos del tamaño especificado por el segundo parámetro obligatorio, tamaño Byte. El valor de tamaño de byte debe ser un entero decimal, hay ningún valor predeterminado. El tamaño de byte lógico no es necesariamente el mismo que el tamaño en bytes de transferencia. Si hay una diferencia en tamaños de byte, a continuación, los bytes lógicos debe ser embalado contigua, sin tener en cuenta los límites de bytes de transferencia y con cualquier relleno necesario, al final.



Cuando los datos llegan al host receptor, será

transformado en una forma dependiente del tamaño de byte lógico y el anfitrión particular. Esta transformación debe ser invertible (es decir, un archivo idéntico se puede recuperar si el se utilizan los mismos parámetros) y deberían estar bien publicitados por los ejecutores FTP.

Por ejemplo, un usuario el envío de números de punto flotante de 36 bits a un host con una palabra de 32 bits podría enviar esos datos como byte local con un tamaño en bytes de la lógica 36. El host receptor haría a continuación, esperar para almacenar los bytes lógicos para que podría ser fácilmente manipulado; en este ejemplo poniendo el 36-bit bytes lógicos en palabras dobles de 64 bits deben suficiente.

En otro ejemplo, un par de ordenadores con un tamaño de palabra de 36 bits puede enviar datos a otros en palabras usando TIPO L 36. Los datos se enviarán en los bytes de transmisión de 8 bits embalarse 9 bytes de transmisión llevan a dos palabras de acogida.

3.1.1.5. CONTROL DE FORMATO

Los tipos ASCII y EBCDIC también toman un segundo (opcional) parámetro, esto es para indicar qué tipo de formato vertical de control, en su caso, se asocia con un archivo. El siguiente tipos de representación de datos se definen en el FTP:

Un archivo de caracteres puede ser transferido a un huésped para uno de tres propósitos: para la impresión, para el almacenamiento y más tarde recuperación o para su procesamiento. Si se envía un archivo de la impresión, el host receptor debe saber cómo la vertical control de formato se representa. En el segundo caso, debe ser posible almacenar un archivo en un host y luego recuperarla más adelante en exactamente la misma forma. Por último, debe ser posible mover un archivo desde un host a otro y el proceso de el archivo en el segundo host sin problemas indebidos. Un único Formato ASCII o EBCDIC no satisface todos estos condiciones. Por lo tanto, estos tipos tienen un segundo parámetro especificando uno de los siguientes tres formatos:

3.1.1.5.1. PRINT NO

Este es el formato por defecto que se utilizará si la segunda (Formato) se omite el parámetro. Formato de impresión no debe ser aceptado por todas las implementaciones de FTP.



El archivo necesita contener ninguna información de formato vertical. Si que se pasa a un proceso de impresora, este proceso puede asumir valores estándar de espaciado y márgenes.

Normalmente, este formato se puede utilizar con archivos destinados para procesar o simplemente de almacenamiento.

3.1.1.5.2. CONTROLES DE FORMATO TELNET

El archivo contiene los controles de formato vertical ASCII / EBCDIC (Es decir, <CR>, <LF>, <NL>, <VT>, <FF>) que la impresora proceso interpretar adecuadamente. <CRLF>, Exactamente esta secuencia, también denota al final de la línea.

3.1.1.5.2. CONTROL DE TRANSPORTE (ASA)

El archivo contiene ASA (FORTRAN) de control de formato vertical personajes. (Véase el RFC 740 Apéndice C, y Comunicaciones de la ACM, vol. 7, N º 10, p. 606, octubre de 1964.) En un línea o de un registro con formato según la norma ASA, ¿no se va a imprimir el primer carácter. En su lugar, se se debe utilizar para determinar el movimiento vertical de la papel que debería tener lugar antes de que el resto de la se imprime registro.

El estándar ASA especifica el siguiente control personajes:

Carácter Separación Vertical

Mover papel en blanco una línea hacia arriba

0 Move papel de hasta dos líneas 1 Mover el papel al principio de la página siguiente + No hay movimiento, es decir, la impresión,

Es evidente que debe haber alguna manera para que un proceso de impresora distinguir el final de la entidad estructural. Si un archivo tiene estructura de registro (véase más adelante), este no es un problema; registros se marcarán de forma explícita durante la transferencia y almacenamiento. Si el archivo no tiene estructura de registro, el <CRLF> secuencia final de la línea se utiliza para la impresión de líneas separadas, pero estos determinantes de formato prevalezca la ASA controles.



3.1.2. ESTRUCTURAS DE DATOS

Además de los diferentes tipos de representación, FTP permite la estructura de un archivo que se especifique. Tres estructuras de archivos son se define en el FTP:

archivo-estructura, donde no hay una estructura interna y el archivo se considera que es un secuencia continua de bytes de datos,

record-estructura, donde el archivo se compone de secuencia registros,

y la página-estructura, donde el archivo se compone de independiente páginas indexadas.

File-estructura es el valor por defecto de suponer si la estructura comando no se ha utilizado, pero las estructuras de ambos archivos y registros que deberán ser aceptadas por los archivos "text" (es decir, archivos con TIPO ASCII o EBCDIC) por todas las implementaciones de FTP. La estructura de un archivo

afectará tanto el modo de transferencia de archivos (consulte la sección en los modos de transmisión) y la interpretación y almacenamiento de el archivo.

La estructura "natural" de un archivo dependerá del anfitrión almacena el archivo. Un archivo de código fuente por lo general se almacena en un Mainframe IBM en los registros de longitud fija, pero en un diciembre TOPS-20 como una secuencia de caracteres divide en líneas, por ejemplo por <CRLF>. Si la transferencia de archivos entre tal dispares sitios es para ser útil, debe haber algún camino para un sitio a reconocer suposiciones del otro sobre el archivo.

En algunos sitios es naturalmente orientada a archivos y otros naturalmente orientado a registro puede haber problemas si un archivo con una estructura se envía a un host orientado a la otra. Si un archivo de texto que se envía con el expediente de la estructura a un host que es el archivo orientado, entonces ese host debe aplicar un interno transformación en el fichero de base a la estructura de registro. Obviamente, esta transformación debe ser útil, pero debe también ser invertible de manera que un archivo idéntico puede ser recuperada con estructura de registro.

En el caso de un archivo que se envía con el archivo-estructura a una acogida orientado a registro, existe la cuestión de qué criterios del anfitrión deben usar para dividir el archivo en registros que pueden ser procesados localmente. Si esta división es necesario, la aplicación FTP debe utilizar la secuencia final de la línea,



<CRLF> Para ASCII o <NL> para archivos de texto EBCDIC, ya que el delimitador. Si una aplicación FTP adopta esta técnica, se deben estar preparados para revertir la transformación si el archivo es recuperado con archivo-estructura.

3.1.2.1. Estructura de los archivos

Estructura de los archivos es el predeterminado que asumir si la estructura comando no se ha utilizado.

En el archivo de estructura-no hay una estructura interna y el archivo se considera que es una secuencia continua de datos bytes.

3.1.2.2. ESTRUCTURA DE REGISTRO

Estructuras de registro deben ser aceptados para los archivos "text" (es decir, Los archivos del tipo ASCII o EBCDIC) por todas las implementaciones de FTP.

En el registro de la estructura del archivo se compone de secuencia registros.

3.1.2.3. ESTRUCTURA DE PÁGINA

Para transmitir archivos que son discontinuos, FTP define una página estructura. Los archivos de este tipo se conocen como "Archivos de acceso aleatorio" o incluso como "archivos holey". En estos presenta a veces hay otra información asociada con el archivo como un todo (por ejemplo, un descriptor de archivo), o con un sección del archivo (por ejemplo, controles de acceso de página), o ambos. En FTP, las secciones del archivo se denominan páginas.

Para proporcionar varios tamaños de página y asociados información, cada página se envía con un encabezado de página. La página cabecera tiene los siguientes campos definidos:

Longitud de cabecera

El número de bytes lógicos en el encabezado de la página incluyendo este byte. La longitud de la cabecera mínima es de 4.

Página índice

El número de página lógica de esta sección del archivo. Este no es el número de secuencia de transmisión de esta página, pero el índice utilizado para identificar esta página del archivo.



Longitud de los datos

El número de bytes lógicos en los datos de la página. La longitud de datos mínima es 0.

Tipo de página

El tipo de página se trata. Los siguientes tipos de página se definen:

0 = Última página

Esto se utiliza para indicar el final de un bloque paginado transmisión estructurada. La longitud de la cabecera debe sea 4, y la longitud de los datos debe ser 0.

1 = Simple Página

Este es el tipo normal que simples archivos paginados sin ningún nivel de la página de control asociado información. La longitud de la cabecera debe ser 4.

2 = descriptor de páginas

Este tipo se utiliza para transmitir la descriptiva información para el archivo como un todo.

3 = acceso controlado página

Este tipo incluye un campo de encabezado adicional para archivos paginados con la página de control de acceso de nivel información. La longitud de la cabecera debe ser 5.

Campos opcionales

Otros campos de cabecera pueden ser utilizados para suministrar por página información de control, por ejemplo, por acceso de página controlar.

Todos los campos son un byte lógico de longitud. El byte de lógica

tamaño se especifica por el comando TYPE. Véase el Apéndice I para más detalles y un caso específico en la estructura de la página.

Una nota de advertencia acerca de los parámetros: un archivo debe almacenarse y recuperado con los mismos parámetros si la versión recuperada es a



ser idéntica a la versión transmitida originalmente. Por el contrario, Implementaciones de FTP deben devolver un archivo idéntico al original si los parámetros que se utilizan para almacenar y recuperar un archivo son los mismos.

3.2. ESTABLECER CONEXIONES DE DATOS

La mecánica de la transferencia de datos consiste en la creación de los datos conexión a los puertos correspondientes y la elección de los parámetros de para la transferencia. Tanto el usuario como el servidor-PRM tienen un defecto puerto de datos. El puerto de datos predeterminado por el usuario proceso es el mismo que el puerto de conexión de control (es decir, U). El valor predeterminado del servidor de procesos puerto de datos es el puerto adyacente al puerto de conexión de control (Es decir, L-1).

El tamaño en bytes de transferencia es bytes de 8 bits. El tamaño en bytes es relevante sólo para la transferencia efectiva de los datos, no tiene que ver con la representación de los datos dentro del sistema de archivos de un host.

El proceso de transferencia pasiva de datos (esto puede ser un usuario-DTP o un segundo servidor DTP) será "escuchar" en el puerto de datos antes de el envío de un comando de solicitud de transferencia. El orden de petición FTP determina la dirección de la transferencia de datos. El servidor, a la recepción de la solicitud de transferencia, se iniciará la conexión de datos

al puerto. Cuando se establece la conexión, los datos transferencia comienza entre DTP de, y el servidor envía un PI- confirmando respuesta para el usuario-PI.

Cada aplicación FTP debe ser compatible con el uso de los datos por defecto puertos, y sólo el user-PI puede iniciar un cambio a la no-default puertos.

Es posible que el usuario especifique un puerto de datos alternativa por el uso del comando PORT. El usuario puede querer un archivo descargado en un TAC impresora de línea o se recupera de una tercera anfitrión de la fiesta. En este último caso, el usuario-PI establece conexiones de control con los dos servidor-PI es. Se dijo entonces un servidor (por un comando FTP) para "Escuchar" para una conexión que el otro iniciará. La user-PI envía un servidor-PI un comando PORT indicando los datos puerto de la otra. Finalmente, ambos se envió la correspondiente transferir los comandos. La secuencia exacta de comandos y respuestas enviados entre el controlador de usuario y los servidores se define en el Sección de Respuestas FTP.

En general, es responsabilidad del servidor para mantener los datos conexión - para iniciar y para cerrarla. La excepción a esta



es cuando el usuario-DTP está enviando los datos en un modo de transferencia que requiere que la conexión se cierra para indicar EOF. El servidor Debe cerrar la conexión de datos en las siguientes condiciones:

1. El servidor ha completado el envío de datos en un modo de transferencia que requiere una estrecha para indicar EOF.

2. El servidor recibe un comando ABORTAR por parte del usuario.

3. La especificación de puerto se cambia por un comando desde el usuario.

4. La conexión de control está cerrado legalmente o de otro modo.

5. Se produce una condición de error irrecuperable.

De lo contrario el cierre es una opción de servidor, cuyo ejercicio la servidor debe indicar al proceso de usuario, ya sea un 250 o 226 responder sólo.

3.3. GESTIÓN DE CONEXIÓN DE DATOS

Puertos de conexión de datos por defecto: Todas las implementaciones de FTP debe apoyar el uso de los puertos de conexión de datos por defecto, y sólo el Usuario-PI puede iniciar el uso de puertos no predeterminados.

Negociación Data port no predeterminado: El-PI usuario puede especificar un puerto de datos del lado del usuario no predeterminado con el comando PORT. La Usuario-PI puede solicitar al servidor para identificar una no predeterminado puerto de datos del lado del servidor con el comando PASV. Desde una conexión se define por el par de direcciones, cualquiera de estas acciones es suficiente para obtener una conexión de datos diferente, todavía se permite hacer las dos comandos a utilizar nuevos puertos en ambos extremos de los datos conexión.

La reutilización de la conexión de datos: Cuando se utiliza el modo de flujo de datos transferir el final del archivo debe ser indicado por el cierre de la conexión. Esto causa un problema si hay varios archivos que transferido en la sesión, debido a la necesidad de TCP para mantener la registro de conexión para un período de tiempo de espera para garantizar la fiabilidad la comunicación. Por lo tanto la conexión no puede volver a abrirse a la vez.

Hay dos soluciones a este problema. El primero es a negociar un puerto no predeterminado. La segunda es utilizar otro modo de transferencia.

Un comentario sobre los modos de transferencia. El modo de transferencia de corriente es



inherentemente poco fiables, ya que no es posible determinar si el conexión cerrada prematuramente o no. Los otros modos de transferencia (Block, comprimido) no cierran la conexión para indicar el final del archivo. Ellos tienen suficiente FTP codificación que los datos conexión se puede analizar para determinar el final del archivo. Por lo tanto el uso de estos modos se puede dejar la conexión de datos abierta para múltiples transferencias de archivos.

3.4. MODOS DE TRANSMISIÓN

La siguiente consideración en la transferencia de datos es la elección de la modo de transmisión apropiado. Existen tres modos: uno que formatos de los datos y permite procedimientos de reinicio, uno que también comprime los datos para la transferencia eficiente, y uno que pasa a los datos con poco o ningún procesamiento. En este último caso, el modo de interactúa con el atributo de estructura para determinar el tipo de procesamiento. En el modo comprimido, el tipo de representación determina el byte de relleno.

Todas las transferencias de datos deben ser completados con un de fin de archivo (EOF) que pueden ser declarados o implícitos explícitamente por el cierre de la conexión de datos. Para ficheros con estructura de registro, todos los marcadores de fin de registro (EOR) son explícitos, incluyendo la final. Para los archivos de transmisión en la estructura de la página de "última página" tipo de página es utilizado.

NOTA: En el resto de esta sección, byte significa "byte de transferencia" salvo que se indique expresamente lo contrario.

Para el propósito de la transferencia estandarizada, el envío de acogida se traducir su extremo interno de la línea o al final de la denotación registro en la representación prescrito por el modo de transferencia y archivo estructura y el host receptor realizará la inversa traducción a su denotación interna. Un registro Mainframe IBM campo de recuento no se reconozca en otro host, por lo que el la información al final de su registro puede ser transferida como un control de dos bytes código en modo de corriente o como un poco marcado en un bloque o comprimido descriptor de modo. Al final de la línea en un archivo ASCII o EBCDIC sin estructura de registro debe ser indicado por <CRLF> o <NL>,

respectivamente. Dado que estas transformaciones implican trabajo extra para algunos sistemas, sistemas idénticos transferencia desestructurada archivos de texto pueden desear utilizar una representación binaria y corriente modo de la transferencia.



Los siguientes modos de transmisión se definen en el FTP:

3.4.1. MODO DE CORRIENTE

Los datos se transmiten como una secuencia de bytes. No hay restricción en el tipo de representación utilizado, estructuras de registro se admiten.

En un registro de archivo estructurado EOR y EOF serán cada indicarse por un código de control de dos bytes. El primer byte del código de control serán todos unos, el carácter de escape. El segundo byte se tienen el bit de orden dentro y ceros en el resto de EOR y el segundo bit de orden bajo para el EOF, es decir, el byte tendrá valor 1 para EOR y el valor 2 para EOF. EOR y EOF pueden estar indicado juntos en el último byte transmitido girando tanto bits de orden bajo en (es decir, el valor 3). Si un byte de todos los estaba destinado a ser enviado como datos, se debe repetir en el segundo byte del código de control.

Si la estructura es una estructura de archivos, el EOF es indicado por el envío de acogida de cerrar la conexión de datos y todos los bytes son bytes de datos.

3.4.2. MODO BLOQUE

El archivo se transmite como una serie de bloques de datos precedidos por uno o más bytes de cabecera. Los bytes de cabecera contienen un recuento campo, y el código de descriptor. El campo de cuenta indica el

longitud total del bloque de datos en bytes, marcando así el a partir del siguiente bloque de datos (no hay bits de relleno). El código descriptor define: último bloque del archivo (EOF) última bloquear en el registro (EOR), marcador de reinicio (véase la sección sobre Los datos de recuperación y reiniciar) o sospecha de error (es decir, los datos siendo transferido es sospechoso de errores y no es confiable). Este último código no está destinado para el control de errores en FTP. Está motivada por el deseo de los sitios de intercambio de determinados tipos de datos (por ejemplo, los datos sísmicos o el clima) para enviar y recibir todo los datos a pesar de los errores locales (como "cinta magnética leído errores "), sino indicar en la transmisión que ciertas porciones son sospechosos). Estructuras de registro están permitidos en esta modo, y cualquier tipo de representación se pueden utilizar.

La cabecera se compone de los tres bytes. De los 24 bits de información de la cabecera, los 16 bits de menor orden representará byte cuentan, y los 8 bits de alto orden representarán descriptor códigos que se muestran a continuación.



Block Header

+ ---------------- + ---------------- + --------------- - + | Descriptor | Cuenta de bytes | | 8 Bits | 16 bits | + ---------------- + ---------------- + --------------- - +

Los códigos de descriptor se indican mediante indicadores de bits en el byte de descriptor. Cuatro códigos se han asignado, en donde cada uno número de código es el valor decimal del bit correspondiente en el byte.

Código Significado 128 Fin del bloque de datos es EOR

64 Fin del bloque de datos es EOF 32 errores sospechosos en el bloque de datos 16 bloque de datos es un marcador de reinicio

Con esta codificación, más de un descriptor codificado condición puede existir para un determinado bloque. Como tantos bits como sea necesario puede ser marcado.

El marcador de reinicio está incrustado en el flujo de datos como una número entero de bytes de 8 bits que representan imprimible caracteres en el idioma que se utilizan en el control de conexión (por ejemplo, por defecto - NVT-ASCII). <SP> (Espacio, en el lenguaje apropiado) no se debe utilizar dentro de un marcador de reinicio.

Por ejemplo, para transmitir un marcador de seis caracteres, la siguiente sería enviado:

+ -------- + -------- + -------- + | Descrptr | Recuento de bytes | | Código = 16 | = 6 | + -------- + -------- + -------- +

+ -------- + -------- + -------- + | Marcador | Marcador | Marcador | | 8 bits | 8 bits | 8 bits | + -------- + -------- + -------- +

+ -------- + -------- + -------- + | Marcador | Marcador | Marcador | | 8 bits | 8 bits | 8 bits | + -------- + -------- + -------- +



3.4.3. MODO COMPRIMIDO

Hay tres tipos de información que se envían: datos regulares, enviado en una cadena de bytes; datos comprimidos, que consiste en repeticiones o de relleno, y la información de control, enviados en un secuencia de escape de dos bytes. Si n> 0 bytes (hasta 127) de normal los datos son enviados, estos n bytes son precedidos por un byte con el más a la izquierda bit a 0 y más a la derecha 7 bits que contiene el número n.

Cadena de bytes:

1 7 8 8 + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + | 0 | N | | d (1) | ... | D (n) | + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + ^ ^ | --- N bytes --- | de los datos

Cadena de n bytes de datos d (1), ..., d (n) Conde n debe ser positivo.

Para comprimir una cadena de n repeticiones del byte de datos d, la siguiendo 2 bytes que desea enviar:

Byte replicado:

2 6 8 + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + | 1 0 | N | | d | + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - +

Una cadena de n bytes de relleno se puede comprimir en una sola byte, donde el byte de relleno varía con la representación tipo. Si el tipo es ASCII o EBCDIC el byte de relleno es <SP> (Espacio, código ASCII 32, código EBCDIC 64). Si el tipo es de imagen o byte local el relleno es un byte cero.

Filler cuerdas:

2 6 + - + - + - + - + - + - + - + - + | 1 1 | n | + - + - + - + - + - + - + - + - +

La secuencia de escape es un byte doble, la primera de las cuales es la



byte (todos ceros) y el segundo de los cuales contiene escapar códigos descriptor como se definen en el modo de bloqueo. El descriptor

los códigos tienen el mismo significado que en el modo de Bloque y se aplican a la sucesiva cadena de bytes.

El modo comprimido es útil para la obtención de mayor ancho de banda en transmisiones de red de gran tamaño a cambio de un suplemento CPU. Se puede utilizar más eficazmente para reducir el tamaño de la impresora archivos, como los generados por los anfitriones RJE.

3.5. RECUPERACIÓN DE ERROR Y LA REANUDACIÓN

No hay ninguna disposición para la detección de los bits perdidos o revueltos en datos transferencia; este nivel de control de errores es manejado por el protocolo TCP. Sin embargo, se proporciona un procedimiento de reinicio para proteger a los usuarios de fallos del sistema brutos (incluidos los fallos de un anfitrión, un FTP-proceso, o la red subyacente).

El procedimiento de reinicio sólo se define para el bloque y se comprime modos de transferencia de datos. Se requiere que el remitente de los datos para insertar un código de marcador especial en el flujo de datos con algún marcador información. La información de marcadores sólo tiene sentido a la emisor, sino que debe contener caracteres imprimibles en el incumplimiento o lenguaje negociado de la conexión de control (ASCII o EBCDIC). El marcador podría representar un poco de recuento, un registro de conteo, o cualquier otra información por el cual un sistema puede identificar un conjunto de datos puesto de control. El receptor de los datos, si se implementa el reiniciar procedimiento, entonces marque la posición correspondiente de este marcador en el sistema de recepción y devolver esta información a la usuario.

En el caso de un fallo del sistema, el usuario puede reiniciar los datos transferencia mediante la identificación del punto de marcador con el FTP reinicio procedimiento. El siguiente ejemplo ilustra el uso de la procedimiento de reinicio.

El remitente de los insertos de datos un bloque de marcador adecuado en la flujo de datos en un punto conveniente. El anfitrión de la recepción marca la datos correspondientes señalan en su sistema de archivos y transmite el último

remitente conocido y la información de marcador de receptor para el usuario, ya sea directamente o a través de la conexión de control en una respuesta 110 (dependiendo de quién es el remitente). En el caso de un fallo del sistema, el usuario o procesos controlador reinicia el servidor en el último servidor marcador mediante el envío de un comando de reinicio con el código del marcador del servidor como su argumento. El comando restart es transmitida por el control



conexión y es seguida inmediatamente por el comando (por ejemplo, RETR, STOR o LIST) que se está ejecutando en el sistema producido un fallo.

4. FUNCIONES DE TRANSFERENCIA DE ARCHIVOS

El canal de comunicación desde el usuario-PI al servidor-PI es establecido como una conexión TCP desde el usuario hasta el servidor estándar puerto. El intérprete de protocolo de usuario es responsable del envío de FTP comandos e interpretar las respuestas recibidas, el servidor-PI interpreta los comandos, envía respuestas y dirige su DTP para establecer el conexión de datos y transferir los datos. Si la segunda parte en el la transferencia de datos (el proceso de transferencia pasiva) es el usuario-DTP, entonces se se rige por el protocolo interno de la máquina por el usuario FTP, y si es un segundo servidor-DTP, entonces se rige por su PI en el comando de el usuario-PI. Las respuestas FTP se discuten en la siguiente sección. En la descripción de algunos de los comandos en esta sección, es útil ser explícito acerca de las respuestas posibles.

4.1. Comandos FTP

4.1.1. ACCESO COMANDOS DE CONTROL

Los siguientes comandos especifican identificadores de control de acceso (Códigos de comando se muestran entre paréntesis).

NOMBRE DE USUARIO (USER)

El campo argumento es una cadena Telnet que identifica al usuario. La identificación del usuario es la que se requiere por el servidor para el acceso a su sistema de archivos. Este comando se normalmente ser el primer comando transmitido por el usuario después de las conexiones de control se hacen (algunos servidores pueden requerir este). Información adicional de identificación en la forma de a un comando de contraseña de la cuenta y / o pueden también ser requeridos por algunos servidores. Los servidores pueden permitir un nuevo comando de usuario que se entrado en cualquier punto con el fin de cambiar el control de acceso y / o información contable. Esto tiene el efecto de enrojecimiento cualquier información del usuario, la contraseña y cuenta ya suministrado e iniciar la secuencia de inicio de sesión de nuevo. Todo parámetros de transferencia son sin cambios y cualquier transferencia de archivos en se ha completado el progreso bajo el control de acceso de edad parámetros.



CONTRASEÑA (PASS)

El campo argumento es una cadena Telnet que especifica el usuario de contraseña. Este comando debe ir precedido inmediatamente por el comando de nombre de usuario y, para algunos sitios, completa del usuario identificación para el control de acceso. Desde contraseña información es muy sensible, es deseable en general a "enmascarar" o suprimir typeout. Parece que la servidor no tiene forma infalible para lograr esto. Es por lo tanto, la responsabilidad del proceso de usuario FTP para ocultar la información de contraseña y minúsculas.

CUENTA (ACCT)

El campo argumento es una cadena Telnet que identifica al usuario de

cuenta. El comando no está necesariamente relacionada con el usuario comando, ya que algunos sitios puede requerir una cuenta de inicio de sesión y otros sólo para el acceso específico, como por ejemplo el almacenamiento de archivos. En el último caso, el comando puede llegar en cualquier momento.

Hay códigos de respuesta para diferenciar estos casos para el Automatización: cuando se requiere información de la cuenta de inicio de sesión, la respuesta a un comando exitosa contraseña es código de respuesta 332. Por otro lado, si la información de cuenta no es requerido para inicio de sesión, la respuesta a una contraseña con éxito comando es 230, y si se necesita la información de cuenta para una orden emitida posteriormente en el diálogo, el servidor debe devolver una respuesta 332 o 532 dependiendo de si se almacena (En espera de la recepción de la orden de la cuenta) o los descartes comando, respectivamente.

El directorio de trabajo (CWD)

Este comando permite al usuario trabajar con una diferente directorio o base de datos para el almacenamiento de archivos o recuperación sin alterando su usuario o información contable. Transferir parámetros son igualmente sin cambios. El argumento es un ruta de acceso que especifica un directorio u otro sistema depende designador de grupo de archivos.

CAMBIO DE DIRECTORIO DE PADRES (CDUP)

Este comando es un caso especial de la caquexia crónica, y se incluye para simplificar la implementación de programas para la transferencia de árboles de directorios entre sistemas operativos tienen diferentes



sintaxis para nombrar el directorio padre. Los códigos de respuesta

serán idénticos a los códigos de respuesta de CWD. Ver Apéndice II para más detalles.

ESTRUCTURA DE MONTAJE (SMNT)

Este comando permite al usuario montar un archivo diferente estructura de datos del sistema sin alterar su usuario o información contable. Parámetros de transferencia son de manera similar sin cambios. El argumento es un nombre de ruta especificando un directorio u otro sistema depende designador grupo de archivos.

REINITIALIZE (REIN)

Este comando termina un usuario, el lavado de E / S y de la cuenta información, salvo para permitir que cualquier transferencia en curso de ser completado. Todos los parámetros se restablecen a los valores predeterminados y la conexión de control se deja abierta. Esto es idéntico al estado en el que un usuario se encuentra inmediatamente después de se abre la conexión de control. Un comando de usuario puede ser espera que siga.

SALIR (SALIR)

Este comando termina un usuario y si la transferencia de archivos no es en curso, el servidor cierra la conexión de control. Si transferencia de archivos en curso, la conexión permanecerá abierto a la respuesta de resultado y el servidor se ciérrelo. Si el proceso de usuario es la transferencia de archivos para varios usuarios pero no desea cerrar y volver a abrir las conexiones de cada uno, entonces se debe utilizar el comando REIN en lugar de dejar de fumar.

Un cierre inesperado en la conexión de control hará que el servidor para llevar la acción efectiva de un aborto (ABOR) y un Desconexión (QUIT).

4.1.2. TRANSFERENCIA COMANDOS PARÁMETROS

Todos los parámetros de transferencia de datos tienen valores por defecto, y la comandos que especifican los parámetros de transferencia de datos sólo son necesarios si los valores de los parámetros por defecto son para ser cambiado. El valor por defecto valor es el último valor especificado, o si carece de valor ha sido

especifica, el valor por defecto estándar es como se indica aquí. Este implica que el servidor debe "recordar" el valor por defecto aplicable valores. Los comandos pueden estar en cualquier orden excepto que deben preceder a la solicitud del servicio FTP. Los siguientes comandos especificar los parámetros de transferencia de datos:



DATOS (puerto)

El argumento es una especificación HOST-puerto para el puerto de datos para ser utilizado en la conexión de datos. Hay valores predeterminados para ambos el usuario y el puerto de datos del servidor, y en condiciones normales circunstancias que no se necesitan este comando y su respuesta. Si Se utiliza este comando, el argumento es la concatenación de un Dirección de Internet de 32 bits y una dirección de puerto TCP 16 bits. Esta información de la dirección se divide en campos de 8 bits y el valor de cada campo se transmite como un número decimal (en representación de cadena de caracteres). Los campos están separados por comas. Un comando de puerto sería:

PUERTO h1, h2, h3, h4, p1, p2

donde h1 es los 8 bits de alto orden del host de Internet Dirección.

Pasivo (PASV)

Este comando solicita al servidor de DTP que "escuche" en una base de datos puerto (que no es su puerto de datos predeterminado) y esperar a que un conexión en lugar de iniciar una tras la recepción de un comando de transferencia. La respuesta a este comando incluye la host y la dirección del puerto este servidor está escuchando.

Representación Tipo (TYPE)

El argumento especifica el tipo de representación como se describe en la sección sobre representación de datos y almacenamiento. Varios tipos toman un segundo parámetro. El primer parámetro es denota por un único carácter Telnet, como es el segundo Parámetro Formato para ASCII y EBCDIC, y el segundo parámetro de byte local es un entero decimal para indicar ByteSize. Los parámetros están separados por una <SP> (espacio, código ASCII 32).

Los siguientes códigos se asignan para el tipo:

\ / A - ASCII | | N - Non-print | -> <- | T - determinantes de formato Telnet E - EBCDIC | | C - Control de Transporte (ASA) / \ I - Imagen L <byte size> - Local tamaño Byte byte



El tipo de representación predeterminado es ASCII no impresos. Si el Se cambia el parámetro formato, y más tarde sólo el primer se cambia el argumento, formato y luego regresa a la no-print predeterminado.

Estructura de archivos (STRU)

El argumento es un código de caracteres Telnet especificando estructura de archivos se describe en la Sección de Datos Representación y almacenamiento.

Los siguientes códigos se asignan a la estructura:

F - Archivo (sin estructura de registro) R - Estructura de los registros P - Estructura de la página

La estructura por defecto del archivo es.

MODO DE TRANSFERENCIA (MODE)

El argumento es un código de caracteres Telnet especificando los modos de transferencia de datos que se describen en la sección sobre

Modos de transmisión.

Los siguientes códigos se asignan a los modos de transferencia:

S - Corriente B - Bloquear C - Comprimido

El modo de transferencia por defecto es Stream.

4.1.3. FTP Comandos de servicio

Los comandos de servicio FTP definen la transferencia de archivos o el archivo la función del sistema solicitada por el usuario. El argumento de un FTP comando de servicio será normalmente un nombre de ruta. La sintaxis de rutas de acceso deben ajustarse a las convenciones de Site Server (con predeterminados estándar aplicables) y las convenciones lingüísticas de la conexión de control. El control predeterminado que se sugiere es utilizar el último dispositivo, el directorio o nombre de archivo especificado, o el estándar por defecto definido para los usuarios locales. Los comandos pueden ser en cualquier orden, excepto que un "cambio de nombre de" comando debe ser seguido de un "cambio de nombre a" comando y el comando restart debe ser seguido por el comando de interrupción del servicio (por ejemplo, STOR o RETR). Los datos, cuando se transfieren en respuesta al servicio FTP



comandos, siempre se envían a través de la conexión de datos, excepto para ciertas respuestas informativas. Los siguientes comandos especificar las solicitudes de servicio de FTP:

RECUPERAR (RETR)

Este comando hace que el servidor-DTP para transferir una copia de la archivo, especificado en la ruta de acceso, el servidor o usuario-DTP en el otro extremo de la conexión de datos. La situación y contenido del archivo en el sitio del servidor no se verán afectadas.

TIENDA (STOR)

Este comando hace que el servidor-DTP para aceptar los datos transferido a través de la conexión de datos y para almacenar los datos como un archivo en el sitio del servidor. Si el archivo especificado en el existe ruta de acceso en el sitio del servidor, a continuación, su contenido deberá se sustituyen por los datos que están siendo transferidos. Un nuevo archivo es creado en el sitio del servidor si el archivo especificado en el ruta de acceso no existe.

TIENDA UNIQUE (STOU)

Este comando se comporta como STOR excepto que la resultante archivo se creará en el directorio actual bajo un nombre única para ese directorio. El 250 Transferencia Iniciado respuesta debe incluir el nombre generado.

APPEND (a crear) (APPE)

Este comando hace que el servidor-DTP para aceptar los datos transferido a través de la conexión de datos y para almacenar los datos en un archivo en el sitio del servidor. Si el archivo especificado en el existe ruta de acceso en el sitio del servidor, los datos serán anexa a dicho archivo, de lo contrario el archivo especificado en el ruta se crea en el sitio del servidor.

ALLOCATE (ALLO)

Este comando puede ser requerido por algunos servidores para reservar almacenamiento suficiente para acomodar el nuevo archivo sea transferido. El argumento debe ser un entero decimal que representa el número de bytes (utilizando el byte lógico tamaño) de almacenamiento a ser reservado para el archivo. Para los archivos enviado con la estructura de registro o en la página de registro o página como máximo También podría ser necesario tamaño (en bytes lógicos); esto es indicado por un número entero decimal en un segundo campo de argumento



el comando. Este segundo argumento es opcional, pero cuando presente debe ser separada de la primera por los tres Caracteres Telnet <SP> R <SP>. Este comando será seguido de un comando APPEND tienda o. El comando ALLO debe ser tratado como un NOOP (sin operación) por los servidores que no requieren que el tamaño máximo del archivo sea declaran de antemano, y los servidores interesados en sólo el registro máximo o tamaño de página debe aceptar un valor ficticio en el primer argumento y lo ignoran.

RESTART (REST)

El campo argumento representa el marcador de servidor en el que transferencia de archivos se reiniciará. Este comando no provocar la transferencia de archivos, pero se salta el archivo a la especificada punto de control de datos. Este comando debe ser seguida inmediatamente por la orden de servicio FTP adecuado que hará que transferencia de archivos a reanudar.

Cambiar nombre (RNFR)

Este comando especifica la vieja ruta del archivo que se para cambiar el nombre. Este comando debe ser seguido inmediatamente por a "cambiar el nombre a" comando especificando la nueva ruta de acceso de archivo.

CAMBIAR EL NOMBRE A (RNTO)

Este comando especifica el nuevo nombre de ruta del archivo especificado en el precedente "Cambiar nombre" comando. Juntos, los dos comandos hacen que un archivo sea cambiado de nombre.

ABORTO (ABOR)

Este comando le dice al servidor FTP para abortar la anterior comando de servicio y cualquier transferencia de datos asociada. La orden de interrupción puede requerir "acción especial", como se explica en la Sección de comandos FTP, para forzar el reconocimiento de la servidor. Ninguna acción debe tomarse si el comando anterior se ha completado (incluyendo la transferencia de datos). El control

conexión no debe ser cerrada por el servidor, pero los datos conexión debe estar cerrada.

Existen dos casos para el servidor tras la recepción de esta comando: (1) la orden de servicio FTP ya se terminó, o (2) la orden de servicio FTP está todavía en curso.



En el primer caso, el servidor cierra la conexión de datos (Si está abierta) y responde con una respuesta 226, lo que indica que la orden de interrupción se ha procesado correctamente.

En el segundo caso, el servidor cancela el servicio FTP en progreso y se cierra la conexión de datos, devolviendo un 426 responder a indicar que la solicitud de servicio termina anormalmente. El servidor envía una respuesta 226, lo que indica que el comando abortar era éxito procesada.

DELETE (DELE)

Este comando hace que el archivo especificado en la ruta de ser eliminado en el sitio del servidor. Si un nivel adicional de protección se desea (por ejemplo, la consulta: "¿Realmente desea eliminar? "), que debe ser proporcionada por el proceso de usuario-FTP.

Eliminar el directorio (RMD)

Este comando hace que el directorio especificado en la ruta de acceso que ser eliminado como un directorio (si la ruta es absoluta) o como un subdirectorio del directorio de trabajo actual (si la ruta es relativa). Véase el Apéndice II.

HACER DIRECTORIO (MKD)

Este comando hace que el directorio especificado en la ruta de acceso que se creará como un directorio (si la ruta es absoluta)

o como un subdirectorio del directorio de trabajo actual (si la ruta es relativa). Véase el Apéndice II.

Print working directory (PWD)

Este comando hace que el nombre del trabajo actual directorio para ser devuelto en la respuesta. Véase el Apéndice II.

LIST (LISTA)

Este comando hace que la lista que se envía desde el servidor a la pasiva DTP. Si la ruta especifica un directorio u otro grupo de archivos, el servidor debe transferir una lista de archivos en el directorio especificado. Si la ruta de acceso especifica un presentar entonces el servidor debe enviar la información actual sobre el archivo. Un argumento nulo implica trabajo o actual del usuario directorio predeterminado. La transferencia de datos es a través de los datos conexión de tipo ASCII o EBCDIC de tipo. (El usuario debe



asegúrese de que el tipo es apropiado ASCII o EBCDIC). Dado que la información en un archivo puede variar ampliamente de un sistema de al sistema, esta información puede ser difícil de usar de forma automática en un programa, pero puede ser muy útil para un usuario humano.

LISTA DE NOMBRE (NLST)

Este comando hace una lista de directorios que se enviará a servidor de sitio del usuario. La ruta debe especificar un directorio u otro descriptor específico del sistema de grupo de archivos, un argumento nulo implica el directorio actual. El servidor devolverá una secuencia de nombres de archivos y no hay otra información. Los datos se transfieren en ASCII o Tipo EBCDIC través de la conexión de datos como nombre de ruta válido cuerdas separadas por <CRLF> o <NL>. (Una vez que el usuario debe asegúrese de que el tipo es correcto). Este comando tiene la intención

para devolver información que puede ser utilizado por un programa para procesar aún más los archivos de forma automática. Por ejemplo, en la aplicación de un "múltiple conseguir" función.

PARÁMETROS DEL SITIO (SITE)

Este comando es utilizado por el servidor para proporcionar servicios específico para su sistema que son esenciales para la transferencia de archivos pero no suficientemente universales para ser incluidos como comandos en el protocolo. La naturaleza de estos servicios y el la especificación de su sintaxis se hará constar en respuesta a el comando SITE HELP.

SISTEMA (SYST)

Este comando se utiliza para determinar el tipo de operación sistema en el servidor. La respuesta tendrá por primera palabra uno de los nombres del sistema que figuran en la versión actual del documento Números Asignados [4].

STATUS (STAT)

Este comando hará que una respuesta de estado se envían a través de la conexión de control en la forma de una respuesta. El comando pueden ser enviados durante una transferencia de archivos (junto con el IP Telnet y señales Synch - véase la sección sobre comandos FTP) en el que caso de que el servidor responderá con el estado de la operación en curso, o puede ser enviado entre el archivo transferencias. En este último caso, el comando puede tener un campo de discusión. Si el argumento es un nombre de ruta, el comando es análoga a la orden de "lista", excepto que los datos serán



transferidos a través de la conexión de control. Si un parcial se da nombre de ruta, el servidor puede responder con una lista de los

los nombres de archivo o los atributos asociados a dicha especificación. Si no se da ningún argumento, el servidor debe devolver en general información de estado acerca del proceso del servidor FTP. Este debe incluir los valores actuales de todos los parámetros de transferencia y el estado de las conexiones.

HELP (AYUDA)

Este comando hará que el servidor envíe útil información sobre su estado de aplicación en el El control de conexión al usuario. El comando puede tardar un argumento (por ejemplo, un nombre de comando) y volver más específica información como respuesta. La respuesta es del tipo 211 o 214. Se sugiere que HELP se permitirá antes de entrar a un USUARIO comando. El servidor puede utilizar esta respuesta para especificar Parámetros dependientes del sitio, por ejemplo, en respuesta a la ayuda del sitio.

NOOP (NOOP)

Este comando no afecta a los parámetros o previamente entrado comandos. En él se especifica ninguna acción aparte de que el servidor envíe una respuesta Aceptar.

El Protocolo de transferencia de archivos se ajusta a las especificaciones del Telnet protocolo para todas las comunicaciones a través de la conexión de control. Desde el lenguaje utilizado para la comunicación Telnet puede ser una solución negociada opción, todas las referencias en las dos secciones siguientes se destinen a la "Lenguaje Telnet" y el correspondiente "código de fin de línea Telnet". En la actualidad, se puede tomar esto en el sentido de NVT-ASCII y <CRLF>. Ningún otro especificaciones del protocolo Telnet se citarán.

Comandos FTP son cadenas "Telnet" terminadas por el "fin de Telnet línea de código. "Los propios códigos de comando son los caracteres alfabéticos terminado por el <SP> carácter (espacio) Si los parámetros siguen y Telnet-EOL lo contrario. Los códigos de comando y la semántica de comandos se describen en esta sección, la sintaxis detallada de comandos se especifica en la sección relativa a los comandos, las secuencias de respuesta se discuten en la Sección de secuenciación de comandos y respuestas, y escenarios que ilustran el uso de comandos se proporcionan en el Sección sobre escenarios de FTP típicas.

Comandos FTP se pueden dividir como las que especifican de control de acceso identificadores, los parámetros de transferencia de datos, o solicitudes de servicio FTP. Ciertos comandos (como ABOR, STAT, QUIT) pueden ser enviados a través del conexión de control, mientras que una transferencia de datos está en curso. Algunos



servidores pueden no ser capaces de controlar las conexiones de control y de datos al mismo tiempo, en cuyo caso será necesario algún tipo de acción especial para conseguir la atención del servidor. El formato siguiente es ordenado tentativamente recomienda:

1. Sistema inserta usuario del Telnet "Alarma de proceso" (IP) de señal en la corriente de Telnet.

2. Sistema del usuario envía la señal de Telnet "sincronización".

3. Sistema inserta usuario escribe el comando (por ejemplo, ABOR) en el Telnet arroyo.

4. Servidor PI, tras recibir "IP", analiza el flujo de Telnet para EXACTAMENTE UNA comando FTP.

(Para otros servidores esto puede no ser necesario, pero las acciones enumeradas anterior debería tener ningún efecto inusual.)

4.2. RESPUESTAS FTP

Respuestas a los comandos del protocolo de transferencia de archivos están concebidos para garantizar la sincronización de las solicitudes y acciones en el proceso de archivo transferir, y para garantizar que el proceso de usuario siempre conoce la estado del servidor. Cada comando debe generar por lo menos un responder, aunque puede haber más de uno, en el segundo caso, las múltiples respuestas deben distinguirse fácilmente. Además, algunos comandos se presentan en grupos secuenciales, como USER, PASS y ACCT o RNFR y RNTO. Las respuestas muestran la existencia de un estado intermedio si todos los comandos anteriores han sido un éxito.

Un fallo en cualquier punto de la secuencia requiere la repetición de toda la secuencia desde el principio.

Los detalles de la secuencia de comandos de respuesta se hacen explícitas en un conjunto de diagramas de estado a continuación.

Una respuesta FTP consiste en un número de tres dígitos (transmitida como tres caracteres alfanuméricos) seguido de un texto. El número está destinado a ser utilizado por los autómatas para determinar en qué estado para entrar siguiente, el texto está destinado para el usuario humano. Se pretende que los tres dígitos contienen suficiente información codificada que el fácil de proceso (el usuario-PI), no tendrá que examinar el texto y puede o bien descartarlo o pasarlo al usuario, según el caso. En particular, el texto puede ser dependiente del servidor, por lo que hay probabilidades de ser diferentes textos para cada código de respuesta.

La respuesta está definido para contener el código de 3 dígitos, seguido de espacio



<SP>, Seguido de una línea de texto (donde algunos longitud máxima de línea se ha especificado), y terminó a finales de línea Telnet código. Habrá casos, sin embargo, que el texto es más largo que una sola línea. En estos casos, el texto completo debe ir precedida por lo que el proceso de Usuario sabe cuándo puede dejar de leer la respuesta (es decir, detener el procesamiento de entrada en la conexión de control) y ir a hacer otra cosas. Esto requiere un formato especial en la primera línea de indican que más de una línea que viene, y otro en el última línea para designarlo como el último. Al menos uno de ellos debe contener el código de respuesta apropiado para indicar el estado de la transacción. Para satisfacer todas las facciones, se decidió que tanto el primer y último códigos de línea deben ser el mismo.

Por lo tanto el formato de respuestas múltiples líneas es que la primera línea comenzará con el código de respuesta exacta requerida, seguida

inmediatamente por un guión, "-" (también conocido como Minus), seguido por texto. La última línea se iniciará con el mismo código, seguido inmediatamente por <SP> espacio, algo de texto opcional y el Telnet código de fin de línea.

Por ejemplo: 123-Primera línea Segunda línea 234 Una línea que comienza con los números 123 La última línea

El proceso de usuario a continuación, simplemente tiene que buscar la segunda ocurrencia del mismo código de respuesta, seguida de <SP> (espacio), en el comienzo de una línea, y no hacer caso todas las líneas intermedias. Si una línea intermedia comienza con un número de 3 dígitos, el servidor debe rellenar la parte delantera para evitar confusiones.

Este esquema permite a las rutinas estándar del sistema para ser usado para los información de respuesta (tales como para la respuesta STAT), con "Artificial" primera y la última línea insertan en. En casos poco frecuentes donde estas rutinas son capaces de generar tres dígitos y un Espacio al principio de cualquier línea, al principio de cada línea de texto debe ser compensado por un texto neutral, como el espacio.

Este esquema asume que las respuestas de varias líneas no pueden anidarse.

Los tres dígitos de la respuesta de cada uno tiene un significado especial. Este está destinado a permitir una gama de muy simples a muy respuestas muy elaboradas por el proceso de usuario. El primer dígito indica si la respuesta es buena, mala o incompleta. (Refiriéndose al diagrama de estado), un proceso de usuario poco sofisticado será capaz de determinar su siguiente acción (proceder según lo previsto,



rehacer, retrench, etc) con sólo examinar este primer dígito. La fácil de proceso que quiere saber aproximadamente qué tipo de error producido (por ejemplo, un error del sistema de archivos, error de sintaxis de comandos) puede examinar el segundo dígito, reservando el tercer dígito de la mejor gradación de la información (por ejemplo, el comando RNTO sin precedente RNFR).

Hay cinco valores para el primer dígito del código de respuesta:

1yz positiva respuesta preliminar

Se ha iniciado la acción solicitada, se espera otro responder antes de proceder a un nuevo comando. (La el usuario proceso de envío antes de que el otro comando respuesta conclusión estaría en violación del protocolo, pero procesos de servidor FTP debe cola todos los comandos que mientras que llega un comando anterior está en curso.) Esta tipo de respuesta se puede utilizar para indicar que el comando fue aceptada y el proceso de usuario puede ahora prestar atención a las conexiones de datos, para las implementaciones en donde monitorización simultánea es difícil. El servidor FTP proceso puede enviar como máximo, una 1yz respuesta al comando.

2yz respuesta positiva de Terminación

La acción solicitada se ha completado con éxito. La nueva petición puede ser iniciada.

3yz respuesta positiva Intermedio

El comando ha sido aceptado, pero la acción solicitada se está en suspenso, a la espera de recibir más información. El usuario debe enviar otro comando especificar esta información. Esta respuesta se utiliza en grupos de secuencias de comandos.

4yz Transitoria respuesta negativa de Terminación

El comando no fue aceptado y la acción solicitada hizo no se llevará a cabo, pero la condición de error es temporal y el recurso podrá ser solicitada de nuevo. El usuario debe volver al principio de la secuencia de comandos, en su caso. Es difícil asignar un significado a "transitorio", particularmente cuando dos sitios distintos (Servidor-y

-Los procesos de usuario) tienen que ponerse de acuerdo sobre la interpretación. Cada respuesta en la categoría 4yz podría tener un poco diferente valor en el tiempo, pero la intención es que el



se recomienda al usuario-proceso para volver a intentarlo. Una regla de oro en la determinación de si una respuesta encaja en el 4yz o la 5yz (Permanent Negative) categoría es que las respuestas son 4yz si los comandos se pueden repetir sin ningún cambio en forma de comandos o en propiedades del usuario o del servidor (Por ejemplo, el comando se escribe lo mismo con la misma argumentos utilizados, el usuario no cambia su acceso a los archivos o nombre de usuario, el servidor no pone un nuevo aplicación.)

5yz Permanente respuesta negativa de Terminación

El comando no fue aceptado y la acción solicitada hizo No tome su lugar. El proceso de usuario no se le aconseja repetir la solicitud exacta (en la misma secuencia). Incluso algunas condiciones de error "permanentes" pueden corregirse, por lo el usuario humano lo desea, puede dirigir su proceso de Usuario reiniciar la secuencia de comandos de acción directa en algún momento en el futuro (por ejemplo, después de la ortografía ha sido cambiado, o si el usuario ha cambiado su estado de directorio.)

Los siguientes grupos de función están codificados en el segundo dígitos:

x0z Sintaxis - Estas respuestas se refieren a los errores de sintaxis, comandos sintácticamente correctos que no encajan en ninguna categoría funcional, sin aplicarse o superfluos comandos.

x1z información - Estas son las respuestas a las solicitudes de información, tal como el estado o ayuda.

Conexiones x2z - respuestas se hace referencia al control y conexiones de datos.

x3z autenticación y contabilidad - Respuestas para el inicio de sesión procedimientos de proceso y de contabilidad.

x4z especificado por el momento.

Sistema de archivos x5z - Estas respuestas indican el estado de la Servidor de archivos del sistema vis-a-vis la transferencia o solicitado otra acción del sistema de archivos.

El tercer dígito da una gradación más fina de significado en cada uno de las categorías de funciones, especificadas por el segundo dígito. La lista de respuestas inferiores a ilustrar esto. Tenga en cuenta que el texto



asociado con cada respuesta se recomienda, en lugar de obligatoria, e incluso puede cambiar de acuerdo con el mandato con el que está asociado. Los códigos de respuesta, por otra parte, deben seguir estrictamente las especificaciones en la sección anterior; es decir, las implementaciones del servidor no deberían inventar nuevos códigos para situaciones que son sólo ligeramente diferentes de los se describe aquí, sino que debe adaptarse códigos ya definidos.

Un comando como el tipo o ALLO cuya ejecución exitosa no ofrece el proceso del usuario toda la información nueva se provocar una respuesta 200 a devolver. Si el comando no está ejecutado por un proceso de servidor FTP en particular porque no tiene relevancia a ese sistema informático, por ejemplo ALLO en un sitio TOPS20, una respuesta positiva de Terminación todavía

deseada para que el simple proceso de usuario sabe que puede proceder con su curso de acción. Una respuesta 202 se utiliza en este caso con, por ejemplo, el texto de la respuesta: "No la asignación de almacenamiento necesario. "Si, por el contrario, el comando solicita una la acción no específica del sitio y no está implementada, la respuesta es 502. Un refinamiento de ello es la respuesta 504 para un comando que se aplican, pero que las solicitudes de un sin aplicarse parámetro.

4.2.1 Códigos de respuesta por grupos de función

200 Comando bien. 500 Error de sintaxis, comando no reconocido. Esto puede incluir errores como línea de comandos demasiado larga. 501 Error de sintaxis en los parámetros o argumentos. 202 Comando no implementado, superflua en este sitio. 502 Comando no implementado. 503 Secuencia de comandos. 504 Comando no implementado para ese parámetro.



110 Reinicie respuesta marcador. En este caso, el texto es exacta y no deja a la particular, la aplicación, sino que debe leer: MARK yyyy = mmmm Donde aaaa es marcador de flujo de datos en proceso de usuario y mmmm marcador equivalente del servidor (tenga en cuenta los espacios entre los marcadores y "="). 211 Estado del sistema o respuesta de ayuda del sistema. Directorio de estado 212.

213 Estado del archivo. 214 Mensaje de ayuda. Sobre la forma de utilizar el servidor o el significado de una determinada comando no estándar. Esta respuesta es útil sólo para la usuario humano. 215 NOMBRE tipo de sistema. Donde nombre es el nombre de un sistema oficial de la lista en el Números Asignados documento. 120 Servicio listo en minutos nnn. 220 Servicio preparado para nuevo usuario. 221 conexión de control de cierre de servicio. Conectados a su caso. 421 Servicio no disponible, conexión de control de cierre. Esto puede ser una respuesta a cualquier comando si el servicio sabe que debe cerrar. 125 conexión de datos ya abierto, la transferencia de partida. 225 conexión de datos abierta, sin transferencia en curso. 425 No se puede abrir la conexión de datos. 226 conexión de datos de cierre. Pidió el archivo de acción con éxito (por ejemplo, un archivo transferencia o archivo abortar). 426 Conexión cerrada; transferir abortado. 227 Entering Passive Mode (h1, h2, h3, h4, p1, p2). 230 Usuario conectado, proceda. 530 No conectado 331 Nombre de usuario ¿de acuerdo, se necesita contraseña. 332 Necesita cuenta para iniciar sesión. 532 Necesita cuenta para almacenar archivos.



150 Estado del archivo bien; a punto de abrir la conexión de datos. 250 acción de archivo solicitada bien, completó. 257 "ruta" creado. 350 acción de archivo solicitada en espera de más información. 450 Pidió el archivo de acción no se toma.

El archivo no está disponible (por ejemplo, archivos ocupado). No se toma 550 La acción solicitada. El archivo no está disponible (por ejemplo, archivo no encontrado, sin acceso). 451 Acción interrumpida. Error local en el procesamiento. 551 Acción interrumpida. Página tipo desconocido. No se toma 452 La acción solicitada. Espacio de almacenamiento insuficiente en el sistema. 552 acción de archivo solicitada abortada. Asignación de almacenamiento superado (para el directorio actual o conjunto de datos). No se toma 553 La acción solicitada. Nombre de archivo no permitido.

4.2.2 Orden numérico Lista de códigos de respuesta

110 Reinicie respuesta marcador. En este caso, el texto es exacta y no deja a la particular, la aplicación, sino que debe leer: MARK yyyy = mmmm Donde aaaa es marcador de flujo de datos en proceso de usuario y mmmm marcador equivalente del servidor (tenga en cuenta los espacios entre los marcadores y "="). 120 Servicio listo en minutos nnn. 125 conexión de datos ya abierto, la transferencia de partida. 150 Estado del archivo bien; a punto de abrir la conexión de datos.



200 Comando bien. 202 Comando no implementado, superflua en este sitio.

211 Estado del sistema o respuesta de ayuda del sistema. Directorio de estado 212. 213 Estado del archivo. 214 Mensaje de ayuda. Sobre la forma de utilizar el servidor o el significado de una determinada comando no estándar. Esta respuesta es útil sólo para la usuario humano. 215 NOMBRE tipo de sistema. Donde nombre es el nombre de un sistema oficial de la lista en el Números Asignados documento. 220 Servicio preparado para nuevo usuario. 221 conexión de control de cierre de servicio. Conectados a su caso. 225 conexión de datos abierta, sin transferencia en curso. 226 conexión de datos de cierre. Pidió el archivo de acción con éxito (por ejemplo, un archivo transferencia o archivo abortar). 227 Entering Passive Mode (h1, h2, h3, h4, p1, p2). 230 Usuario conectado, proceda. 250 acción de archivo solicitada bien, completó. 257 "ruta" creado. 331 Nombre de usuario ¿de acuerdo, se necesita contraseña. 332 Necesita cuenta para iniciar sesión. 350 acción de archivo solicitada en espera de más información. 421 Servicio no disponible, conexión de control de cierre. Esto puede ser una respuesta a cualquier comando si el servicio sabe que debe cerrar. 425 No se puede abrir la conexión de datos. 426 Conexión cerrada; transferir abortado. 450 Pidió el archivo de acción no se toma. El archivo no está disponible (por ejemplo, archivos ocupado). 451 Pidió acción abortada: error local en el procesamiento. No se toma 452 La acción solicitada. Espacio de almacenamiento insuficiente en el sistema.



500 Error de sintaxis, comando no reconocido. Esto puede incluir errores como línea de comandos demasiado larga. 501 Error de sintaxis en los parámetros o argumentos. 502 Comando no implementado. 503 Secuencia de comandos. 504 Comando no implementado para ese parámetro. 530 No conectado 532 Necesita cuenta para almacenar archivos. No se toma 550 La acción solicitada. El archivo no está disponible (por ejemplo, archivo no encontrado, sin acceso). 551 Pidió acción abortada: página de tipo desconocido. 552 acción de archivo solicitada abortada. Asignación de almacenamiento superado (para el directorio actual o conjunto de datos). No se toma 553 La acción solicitada. Nombre de archivo no permitido.

5. ESPECIFICACIONES declarativa

5.1. APLICACIÓN MÍNIMO

Con el fin de hacer FTP viable sin mensajes de error innecesarias, la se requiere después de la implementación mínima para todos los servidores:

TYPE - No impresión ASCII MODE - Corriente ESTRUCTURA - Archivo, Informe - COMANDOS DEL USUARIO, dejar de fumar, Puerto, TYPE, MODE STRU, para los valores por defecto RETR, STOR, NOOP.

Los valores predeterminados de los parámetros de transferencia son:

TYPE - No impresión ASCII MODE - Corriente STRU - Archivo

Todos los hosts deben aceptar lo anterior como los valores predeterminados estándar.


RFC 959 10 1985

Protocolo de transferencia de archivos

5.2. CONEXIONES

El intérprete de protocolo del servidor debe "escuchar" en el puerto L. La usuario o intérprete de protocolo de usuario iniciarán el full-duplex controlar la conexión. Servidor y el usuario los procesos deben seguir el convenciones del protocolo Telnet como se especifica en el ARPA-Internet Manual del Protocolo [1]. Servidores tienen ninguna obligación de velar por la edición de líneas de comandos y puede requerir que se haga en el huésped usuario. La conexión de control será cerrada por el servidor a petición del usuario después de que todas las transferencias y respuestas se han completado.

El usuario-DTP debe "escuchar" en el puerto de datos especificado, lo que puede ser el puerto de usuario por defecto (U) o un puerto especificado en el comando PORT. El servidor se iniciará la conexión de datos de su propio incumplimiento puerto de datos (L-1) a través del puerto de datos de usuario especificado. La dirección de la transferencia y el puerto utilizado será determinado por el FTP comando de servicio.

Tenga en cuenta que toda la aplicación FTP debe ser compatible con la transferencia de datos utilizando el puerto por defecto, y que sólo el usuario-PI puede iniciar el uso de los puertos no predeterminados.

Cuando los datos a ser transferidos entre dos servidores, A y B (se refieren la Figura 2), el usuario-PI, C, establece conexiones de control con tanto del servidor-PI. Uno de los servidores, digamos A, entonces se envía un PASV comando le dice a "escuchar" en su puerto de datos en lugar de iniciar una conexión cuando se recibe una orden de servicio de transporte. Cuando el usuario-PI recibe un acuse de recibo para el comando PASV, que incluye la identidad del host y el puerto está escuchando , el usuario-PI envía del puerto A, a, a B en un comando PORT, un se devuelve respuesta. El usuario-PI puede entonces enviar la correspondiente comandos de servicio a A y B. El servidor B inicia la conexión y los ingresos de transferencia. La secuencia de comandos de respuesta está en la lista por debajo de donde los mensajes son verticalmente sincrónica pero horizontal asincrónica:



Usuario-PI - Servidor Un usuario-PI - Servidor B ------------------------------------ C-> A: Connect-C> B: Conectar C-> A: PASV A-> C: 227 Entering Passive Mode. A1, A2, A3, A4, A1, A2 C-> B: PUERTO A1, A2, A3, A4, A1, A2 B-> C: 200 Okay C-> A: STOR C-> B: RETR B-> A: Conectar a HOST-A, Port-A

Figura 3

La conexión de datos se cierra por el servidor bajo el condiciones que se describen en la sección sobre el establecimiento de datos Conexiones. Si la conexión de datos se va a cerrar después de un la transferencia de datos, donde el cierre de la conexión no está obligado a indicar el final del archivo, el servidor debe hacerlo de inmediato. Esperar hasta después de que no se permite una nueva orden de transferencia debido a que el proceso de usuario ya habrá comprobado los datos conexión para ver si es necesario hacer un "escuchar", (recordar que el usuario debe "escuchar" en un puerto de datos cerrada antes de enviar el solicitud de transferencia). Para evitar una condición de carrera aquí, el servidor envía una respuesta (226) después de cerrar la conexión de datos (o si el conexión se deja abierta, una "transferencia completa" respuesta (250) y el usuario-PI debe esperar a que una de estas respuestas antes la emisión de una nueva orden de transferencia).

En cualquier momento el usuario o servidor de ver que la conexión está

está cerrada por el otro lado, hay que leer rápidamente cualquier datos que quedan en la cola de la conexión y emitir el cierre de su propio bando.

5.3. COMANDOS

Los comandos son cadenas de caracteres Telnet transmitidos a través de la Conexiones de control como se describe en la Sección de comandos FTP. Las funciones de comando y la semántica se describen en la Sección de comandos de control del acceso, la transferencia Comandos de parámetros, FTP Comandos de servicio y Comandos Misceláneos. La sintaxis del comando se especifica aquí.

Los comandos comienzan con un código de comando seguido de un argumento campo. Los códigos de comando son cuatro o menos caracteres alfabéticos. Caracteres alfabéticos superior e inferior de casos deben ser tratados idénticamente. Por lo tanto, cualquiera de los siguientes puede representar la recuperación de comandos:



RETR Retr retr retr retr

Esto también se aplica a los símbolos que representan los valores de los parámetros, tales como A o una de TIPO ASCII. Los códigos de comando y el argumento campos están separados por uno o más espacios.

El campo argumento consiste en una cadena de caracteres de longitud variable terminando con la secuencia de caracteres <CRLF> (retorno de carro, Línea Alimentar) para la representación NVT-ASCII, para otros idiomas negociados un final diferente carácter de línea puede ser utilizado. Debe ser señaló que el servidor es no tomar ninguna acción hasta el final de la línea se recibe un código.

La sintaxis se especifica a continuación en NVT-ASCII. Todos los personajes de la

campo argumento son caracteres ASCII, incluyendo cualquier ASCII representado enteros decimales. Los corchetes indican un opcional campo de discusión. Si la opción no se toma, la adecuada por defecto está implícito.



5.3.1. Comandos FTP

Los siguientes son los comandos FTP:

USUARIO <SP> <username> <CRLF> PASS <SP> <contraseña> <CRLF> ACCT <SP> <account-information> <CRLF> CWD <SP> <rutaDeAcceso> <CRLF> CDUP <CRLF> SMNT <SP> <rutaDeAcceso> <CRLF> SALIR <CRLF> REIN <CRLF> PUERTO <SP> <host-port> <CRLF> PASV <CRLF> TIPO <SP> <type-code> <CRLF> STRU <SP> <structure-code> <CRLF> MODO <SP> <mode-code> <CRLF>

RETR <SP> <rutaDeAcceso> <CRLF> STOR <SP> <rutaDeAcceso> <CRLF> STOU <CRLF> APPE <SP> <rutaDeAcceso> <CRLF> ALLO <SP> <decimal-integer> [<SP> R <SP> <decimal-integer>] <CRLF> DESCANSAR <SP> <marker> <CRLF> RNFR <SP> <rutaDeAcceso> <CRLF> RNTO <SP> <rutaDeAcceso> <CRLF> ABOR <CRLF> DELE <SP> <rutaDeAcceso> <CRLF> RMD <SP> <rutaDeAcceso> <CRLF> MKD <SP> <rutaDeAcceso> <CRLF> PWD <CRLF> LISTA [<SP> <rutaDeAcceso>] <CRLF> NLST [<SP> <rutaDeAcceso>] <CRLF> SITIO <SP> <cadena> <CRLF> SYST <CRLF> STAT [<SP> <rutaDeAcceso>] <CRLF> Ayuda [<SP> <cadena>] <CRLF> NOOP <CRLF>



5.3.2. Argumentos del comando FTP

La sintaxis de los campos de argumento arriba (usando la notación BNF en su caso) es:

<username> :: = <cadena> <contraseña> :: = <cadena> <account-information> :: = <cadena> <cadena> :: = <char> | <char> <cadena> <char> :: = cualquiera de los 128 caracteres ASCII excepto <CR> y <LF> <marker> :: = <pr-string> <pr-string> :: = <pr-char> | <pr-char> <pr-string> <pr-char> :: = caracteres imprimibles, cualquier Código ASCII 33 a 126 <byte-size> :: = <número> <host-port> :: = <host-number>, <número-puerto> <host-number> :: = <número>, <número>, <número>, <número> <número-puerto> :: = <número>, <número>

<número> :: = cualquier número entero decimal de 1 a 255 <form-code> :: = N | T | C <type-code> :: = A [<sp> <form-code>] | E [<sp> <form-code>] | I | L <sp> <byte-size> <structure-code> :: = F | R | P <mode-code> :: = S | B | C <rutaDeAcceso> :: = <cadena> <decimal-integer> :: = cualquier entero decimal



5.4. SECUENCIA DE COMANDOS Y RESPUESTAS

La comunicación entre el usuario y el servidor está destinado a ser una diálogo alterna. Como tal, el usuario emite un comando FTP y el servidor responde con una respuesta primaria del sistema. El usuario debe esperar a que este éxito primario inicial o falta de respuesta ante enviar más comandos.

Algunos comandos requieren una segunda respuesta para que el usuario debe También espera. Estas respuestas pueden ser, por ejemplo, el informe sobre los progresos o la finalización de la transferencia de archivos o el cierre de los datos conexión. Son respuestas secundarias para presentar comandos de transferencia.

Un grupo importante de respuestas informativas es la conexión saludos. En circunstancias normales, el servidor enviará un 220

responder, "en espera de entrada", cuando se completa la conexión. La usuario debe esperar a que este mensaje de saludo antes de enviar cualquier comandos. Si el servidor no puede aceptar la entrada de inmediato, una 120 "retraso esperado" respuesta debe ser enviada inmediatamente y 220 responder cuando esté listo. El usuario sabrá entonces que no cuelgue si hay es un retraso.

Respuestas espontáneas

A veces "el sistema" espontáneamente tiene un mensaje para ser enviado a un usuario (por lo general todos los usuarios). Por ejemplo, "Sistema de bajar en 15 minutos. "No hay ninguna disposición en el FTP para tal espontánea de información que se envía desde el servidor al usuario. Se recomienda que dicha información se pone en cola en el servidor-PI y entregado al usuario-PI en la siguiente respuesta (Posiblemente por lo que es una respuesta multi-línea).

La siguiente tabla muestra el éxito alternativas y respuestas de emergencia durante cada comando. Estos deben cumplirse estrictamente, un servidor puede Sustitúyase el texto en las respuestas, pero el significado y la acción implícita por los números de código y por la secuencia específica de la contestación de comandos no puede ser alterado.

Secuencias de comandos Responder

En esta sección, se presenta la secuencia de comandos de respuesta. Cada comando aparece con sus posibles respuestas, grupos de comandos son listado juntos. Respuestas preliminares aparecen en primer lugar (con sus respuestas posteriores sangría y debajo de ellos), entonces finalización positivo y negativo, y, por último intermediario



respuestas con el resto de los comandos de la secuencia de siguiente. Este listado constituye la base para el estado

diagramas, los cuales serán presentados por separado.

Establecimiento de conexión 120 220 220 421 Login USUARIO 230 530 500, 501, 421 331, 332 PASS 230 202 530 500, 501, 503, 421 332 ACCT 230 202 530 500, 501, 503, 421 CWD 250 500, 501, 502, 421, 530, 550 CDUP 200 500, 501, 502, 421, 530, 550 SMNT 202, 250 500, 501, 502, 421, 530, 550 Salir REIN 120 220 220 421 500, 502 SALIR 221 500



Parámetros de transferencia PUERTO 200 500, 501, 421, 530 PASV 227

500, 501, 502, 421, 530 MODO 200 500, 501, 504, 421, 530 TIPO 200 500, 501, 504, 421, 530 STRU 200 500, 501, 504, 421, 530 Comandos de acción de archivos ALLO 200 202 500, 501, 504, 421, 530 RESTO 500, 501, 502, 421, 530 350 STOR 125, 150 (110) 226, 250 425, 426, 451, 551, 552 532, 450, 452, 553 500, 501, 421, 530 STOU 125, 150 (110) 226, 250 425, 426, 451, 551, 552 532, 450, 452, 553 500, 501, 421, 530 RETR 125, 150 (110) 226, 250 425, 426, 451 450, 550 500, 501, 421, 530



LISTA 125, 150 226, 250 425, 426, 451 450 500, 501, 502, 421, 530 NLST 125, 150 226, 250 425, 426, 451

450 500, 501, 502, 421, 530 APPE 125, 150 (110) 226, 250 425, 426, 451, 551, 552 532, 450, 550, 452, 553 500, 501, 502, 421, 530 RNFR 450, 550 500, 501, 502, 421, 530 350 RNTO 250 532, 553 500, 501, 502, 503, 421, 530 DELE 250 450, 550 500, 501, 502, 421, 530 RMD 250 500, 501, 502, 421, 530, 550 MKD 257 500, 501, 502, 421, 530, 550 PWD 257 500, 501, 502, 421, 550 ABOR 225, 226 500, 501, 502, 421



Comandos informativos SYST 215 500, 501, 502, 421 STAT 211, 212, 213 450 500, 501, 502, 421, 530 AYUDA 211, 214 500, 501, 502, 421 Varios comandos SITIO 200

202 500, 501, 530 NOOP 200 500 421



6. Diagramas de estado

Aquí presentamos los diagramas de estado de una manera muy sencilla FTP mente aplicación. Sólo se utiliza el primer dígito de los códigos de respuesta. Hay un diagrama de estados para cada grupo de comandos FTP o el comando secuencias.

Las agrupaciones de comando se determinaron mediante la construcción de un modelo para cada comando a continuación, recogida de los comandos junto con estructuralmente modelos idénticos.

Para cada secuencia de comandos o el comando que hay tres posibles resultados: el éxito (S), el fracaso (F) y error (E). En el estado

siguientes diagramas se utiliza el símbolo B para "comenzar", y el símbolo W para "Esperar respuesta".

En primer lugar, presentamos el diagrama que representa el mayor grupo de FTP comandos:

1,3 + --- + -----------> | E | | + --- + | + --- + Cmd + --- + 2 + --- + | B | ----------> | W | ----------> | S | + --- + + --- + + --- + | | 4,5 + --- + -----------> | F | + --- +

Modelos de este diagrama los comandos:

ABOR, ALLO, DELE, CWD, CDUP, SMNT, HELP, MODE, NOOP, PASV, SALIR, LUGAR PORT, SYST, STAT, RMD, MKD, PWD, STRU y TYPE.



El otro gran grupo de comandos se representa por una muy similar diagrama:

3 + --- + -----------> | E | | + --- + | + --- + Cmd + --- + 2 + --- + | B | ----------> | W | ----------> | S | + --- + ---> + --- + + --- + | | | | | | 4,5 + --- + | 1 | -----------> | F | ----- + --- +

Modelos de este diagrama los comandos:

APPE, LIST, NLST, REIN, RETR, STOR, y STOU.

Tenga en cuenta que este segundo modelo también podría ser usado para representar la primera grupo de comandos, la única diferencia es que en el primer grupo de las respuestas de la serie 100 son inesperados y por lo tanto tratados como error, mientras que el segundo grupo espera (algunos pueden requerir) 100 respuestas series. Recuerde que a lo sumo, una respuesta serie 100 se permite por comando.

Los otros diagramas secuencias de comandos de modelo, tal vez la más simple de ellas es la secuencia de cambio de nombre:

+ --- + RNFR + --- + 1,2 + --- + | B | ----------> | W | ----------> | E | + --- + + --- + -> + --- + | | | 3 | | 4,5 | -------------------- | | | | + --- + | -------------> | S | | | 1,3 | | + --- + | 2 | -------- | | | | V | | | + --- + + --- + RNTO 4,5 -----> + --- + | | ----------> | W | ----------> | F | + --- + + --- + + --- +



El siguiente diagrama es un modelo simple del comando de reinicio:

+ --- + REST + --- + 1,2 + --- + | B | ----------> | W | ----------> | E | + --- + + --- + -> + --- + | | | 3 | | 4,5 | -------------------- | | | | + --- + | -------------> | S | | | 3 | | + --- + | 2 | -------- | | | |

V | | | + --- + Cmd + --- + 4,5 -----> + --- + | | ----------> | W | ----------> | F | + --- + -> + --- + + --- + | | | 1 | ------

Donde "cmd" es APPE, STOR o RETR.

Tomamos nota de que los tres modelos anteriores son similares. El reinicio se diferencia Del Renombrar dos sólo en el tratamiento de 100 respuestas en serie la segunda etapa, mientras que el segundo grupo espera (algunos pueden requerir) 100 respuestas series. Recuerde que a lo sumo, una respuesta serie 100 es permitido por comandos.



El esquema más complicado es que la secuencia de ingreso:

1 + --- + Usuarios + --- + -------------> + --- + | B | ----------> | W | 2 ----> | E | + --- + --- + ------ + | -> + --- + | | | | | 3 | | 4,5 | | | ------------------- | | | | | | | | | | | | | | --------- | | 1 | | | | V | | | |

+ --- + PASS + --- + 2 | ------> + --- + | | ----------> | W | -------------> | S | + --- + + --- + ----------> + --- + | | | | | 3 | | 4,5 | | | ---------------------- | | | | | | | | | | | | ----------- | 1,3 | | | | V | 2 | | | + --- + + --- + ACCT - | -----> + --- + | | ----------> | W | 4,5 --------> | F | + --- + + --- + -------------> + --- +



Por último, se presenta un diagrama generalizado que podría ser utilizado para modelar el comando y la respuesta de intercambio:

------------------------------------ | | Empiece | | | V | | + --- + Cmd + --- + 2 + --- + | -> | | -------> | | ----------> | | | | | | W | | S | ----- | -> | | -> | | ----- | | | | + --- + | + --- + 4,5 | + --- + | | | | | | | | | | | 1 | | 3 | + --- + | | | | | | | | | | | | ---- | ----> | F | ----- | | | | |

| | | + --- + ------------------- | | V Final



7. ESCENARIO FTP TIPICA

Usuario en el host U querer transferir archivos a / desde acogida S:

En general, el usuario se comunicará con el servidor a través de un mediador proceso de usuario-FTP. El siguiente puede ser un caso típico. La el usuario FTP solicita se muestran entre paréntesis, "---->" representa comandos del host U para alojar S, y "<----" representa las respuestas de los S anfitrión para acoger U.

COMANDOS DE LOCALES DE ACCIÓN DEL USUARIO QUE INTERVIENEN

ftp (host) Multics <CR> conectar al servidor S, puerto de L, el establecimiento de conexiones de control. <---- 220 Servicio <CRLF> listo. nombre de usuario Pérez <CR> USUARIO Pérez <CRLF> ---->

<---- 331 Nombre de usuario correcto, necesitará <CRLF> contraseña. contraseña murmurar <CR> PASS murmurar <CRLF> ----> <---- 230 Usuario conectado <CRLF>. recuperar (tipo local) ASCII <CR> (Ruta de acceso local) prueba 1 <CR> usuario FTP abre el archivo local en ASCII. (Para. ruta) test.pl1 <CR> RETR test.pl1 <CRLF> ----> <---- 150 Estado del archivo bien; a punto de abrir datos <CRLF> conexión. Servidor permite la conexión de datos al puerto de U. <---- 226 conexión de datos de cierre, transferencia de archivos <CRLF> éxito. Tipo de imagen <CR> TIPO I <CRLF> ----> <---- 200 Comando Aceptar <CRLF> almacén (tipo local) imagen <CR> (Ruta de acceso local) archivo de volcado <CR> usuario FTP abre el archivo local en Imagen. (For.pathname)> UDD> cn> fd <CR> STOR> UDD> cn> fd <CRLF> ----> <---- 550 Acceso denegado <CRLF> terminar SALIR <CRLF> ----> Server cierra todas conexiones.

8. Establecimiento de la conexión

La conexión de control FTP se establece a través de TCP entre el usuario proceso de conexión U y el puerto L. proceso del servidor Este protocolo es asignada al puerto de servicio 21 (25 octal), que es L = 21.



ANEXO I - ESTRUCTURA DE PÁGINA

La necesidad de FTP para apoyar la estructura de la página se deriva principalmente de la necesidad de apoyar la transmisión eficiente de archivos entre TOPS-20 sistemas, en particular los archivos utilizados por NLS.

El sistema de archivos de TOPS-20 se basa en el concepto de páginas. La sistema operativo es más eficaz en la manipulación de archivos como páginas. El sistema operativo proporciona una interfaz para el sistema de archivos para que muchas aplicaciones ver archivos como flujos secuenciales de caracteres. Sin embargo, algunas aplicaciones utilizan las estructuras subyacentes de página directamente, y algunos de estos archivos create holey.

Un archivo de TOPS-20 de disco consiste en cuatro cosas: una ruta, una página tabla, un conjunto (posiblemente vacío) de páginas, y un conjunto de atributos.

La ruta se ha especificado en el comando RETR o STOR. Incluye el nombre del directorio, nombre de archivo, la extensión de nombre de archivo, y la generación de número.

La tabla de la página contiene hasta 2 ** 18 entradas. Cada entrada puede tener VACÍO, o puede apuntar a una página. Si no está vacío, hay también algunos bits de acceso específicos de la página, no todas las páginas de un archivo necesita tener el misma protección de acceso.

Una página es un conjunto contiguo de 5 12 palabras de 36 bits cada uno.

Los atributos del archivo, en el Bloque de Descripción del Archivo (FDB), contener cosas tales como la hora de creación, escriba el tiempo, el tiempo de lectura, escritor puntero de bytes de tamaño, al final de su archivo, conde de lecturas y escrituras, copia de seguridad números de cinta del sistema, etc

Tenga en cuenta que no hay ningún requisito de que las entradas de la tabla de páginas sean contigua. Puede haber espacios vacíos entre la tabla de páginas ocupadas queridos. Además, el extremo de puntero de archivo es simplemente un número. No hay requisito de que los puntos de hecho, en el dato "último" en el archivo. Llamadas de E / S secuenciales ordinarias en TOPS-20 hará que al final del archivo puntero a la izquierda después del último dato escrito, pero otras operaciones puede hacer que no sea así, si un sistema de programación en particular por lo requiere.

De hecho, en ambos de estos casos especiales, archivos y "holey" indicadores de fin de archivo no al final del archivo, se producen con NLS datos archivos.



Los TOPS-20 ficheros paginados se pueden enviar con los parámetros de transferencia FTP: TIPO L 36, STRU P, S y MODE (de hecho, cualquier modo podría ser utilizado).

Cada página de la información tiene una cabecera. Cada campo de encabezado, que es una byte lógico, es una palabra TOPS-20, ya que el tipo es L 36.

Los campos de cabecera son:

Palabra 0: Longitud de cabecera.

La longitud de la cabecera es 5.

Palabra 1: Página índice.

Si los datos es una página de archivo de disco, esto es el número de esa página en página mapa del archivo. Páginas vacíos (huecos) en el archivo simplemente no son enviados. Tenga en cuenta que un agujero no es lo mismo que un Página de ceros.

Palabra 2: Longitud de los datos.

El número de palabras de datos en esta página, después de la cabecera. Por lo tanto, la longitud total de la unidad de transmisión es la Cabecera Longitud más la longitud de datos.

Palabra 3: Tipo de página.

Un código para el tipo de fragmento que es esto. Una página de datos es de tipo 3, la página FDB es tipo 2.

Palabra 4: Página de control de acceso.

Los bits de acceso asociadas a la página en la ficha de archivo mapa. (Esta cantidad palabra completa se pone en AC2 de un CAPS de el programa de lectura de la red al disco.)

Después de la cabecera son las palabras de datos de datos de longitud. Longitud de los datos es

Actualmente ya sea 512 para una página de datos o 31 para una FDB. Trailing ceros en una página de archivo de disco pueden ser descartados, por lo menos datos Longitud a 512 en ese caso.



ANEXO II - COMANDOS DE DIRECTORIO

Desde UNIX tiene una estructura de directorios en forma de árbol en el que los directorios son tan fáciles de manipular como ficheros ordinarios, es útil para ampliar los servidores FTP en estas máquinas incluyen comandos que se ocupan de la creación de directorios. Puesto que hay otros hosts de la ARPA-Internet que tienen directorios arborescentes (incluyendo TOPS-20 y Multics), estos comandos son lo más general posible.

Cuatro comandos de directorio se han agregado a FTP:

Ruta MKD

Cree un directorio con el nombre de "ruta".

RMD ruta

Elimine el directorio con el nombre de "ruta".

PWD

Imprima el nombre del directorio de trabajo actual.

CDUP

Cambie al padre del directorio de trabajo actual.

El argumento de la "ruta" se debe crear (retirado) como subdirectorio del directorio de trabajo actual, a menos que la "ruta" cadena contiene información suficiente para especificar de otro modo a la servidor, por ejemplo, "ruta" es una ruta absoluta (en UNIX y Multics), o ruta de acceso es algo así como "<abso.lute.path>" para TOPS-20.

Códigos de respuesta

El comando CDUP es un caso especial de la caquexia crónica, y se incluye para simplificar la implementación de programas para la transferencia de directorio árboles entre los sistemas operativos que tienen diferentes sintaxis para nombrar el directorio padre. Los códigos de respuesta para CDUP ser idénticos a los códigos de respuesta de CWD.

Los códigos de respuesta para RMD ser idénticos a los códigos de respuesta para su analógico archivo, DELE.

Los códigos de respuesta para MKD, sin embargo, son un poco más complicadas. La directorio recién creado será probablemente objeto de un futuro



Comando CWD. Por desgracia, el argumento para MKD puede no ser siempre un argumento adecuado para CWD. Este es el caso, por ejemplo, cuando un TOPS-20 subdirectorio se crea dando simplemente el subdirectorio nombre. Es decir, con un servidor FTP TOPS-20, la secuencia de comandos

MKD MYDIR CWD MYDIR

fallará. El nuevo directorio sólo puede hacer referencia a su Nombre de "absoluto", por ejemplo, si se ejecuta el comando MKD arriba mientras conectado a la <DFRANKLIN> directorio, el nuevo subdirectorio sólo podría ser contemplada por el nombre <DFRANKLIN.MYDIR>.

Incluso en UNIX y Multics, sin embargo, el argumento dado para MKD puede no ser adecuado. Si se trata de una ruta "relativa" (es decir, una ruta que se interpreta relativo al directorio actual), el usuario tendría que estar en el mismo directorio actual con el fin de alcanzar el subdirectorio. Dependiendo de la aplicación, esto puede ser inconveniente. No es muy robusto en cualquier caso.

Para resolver estos problemas, al término de un MKD comando, el servidor debe devolver una línea de la forma:

257 <espacio> "<directory-name>" <espacio> <commentary>

Es decir, el servidor le dirá al usuario lo va a utilizar al se hace referencia al directorio creado. El nombre del directorio puede contener cualquier carácter; comillas incrustadas deberán escaparon comillas dobles (la convención "quote-duplicación").

Por ejemplo, un usuario se conecta al directorio / usr / dm, y crea un subdirectorio, llamado ruta:

CWD / usr / dm 200 directorio cambiado a / usr / dm Ruta MKD 257 directorio "ruta / usr / dm /" creados

Un ejemplo con una cita doble incorporado:

MKD foo "bar 257 "/ usr / dm / foo" "bar" directorio creado Bar CWD / usr / dm / foo " 200 directorio cambiado a bar / usr / dm / foo "



La existencia previa de un subdirectorio con el mismo nombre es una error y el servidor debe devolver un "acceso denegado" respuesta de error en ese caso.

CWD / usr / dm 200 directorio cambiado a / usr / dm Ruta MKD Ya existe "/ usr / dm / nombre de ruta" de la guía - 521; 521 no tomar ninguna medida.

Las respuestas de fracaso para MKD son análogos a la creación de su archivo primo, STOR. Asimismo, un "acceso denegado" se da vuelta si un archivo nombre con el mismo nombre que el subdirectorio entrará en conflicto con la creación del subdirectorio (este es un problema en UNIX, pero no debe ser uno de TOPS-20).

Esencialmente porque el comando PWD devuelve el mismo tipo de información que el comando MKD éxito, el éxito PWD comando utiliza el código de respuesta 257 también.

SUTILEZAS

Debido a que estos comandos serán más útiles en la transferencia de subárboles de una máquina a otra, observar cuidadosamente que el argumento para MKD debe interpretarse como un subdirectorio del directorio de trabajo actual, a menos que contenga información suficiente para el host de destino a decir lo contrario. Una hipotética ejemplo de su uso en el mundo TOPS-20:

CWD <some.where> 200 Directorio de trabajo ha cambiado MKD overrainbow 257 directorio "<some.where.overrainbow>" creado CWD overrainbow 431 No existe el directorio CWD <some.where.overrainbow> 200 Directorio de trabajo ha cambiado

CWD <some.where> Directorio de trabajo 200 cambió a <some.where> MKD <unambiguous> 257 directorio "<unambiguous>" creado CWD <unambiguous>

Tenga en cuenta que el primer ejemplo resulta en un subdirectorio del directorio conectado. En contraste, el argumento en el segundo ejemplo, contiene información suficiente para TOPS-20 para decirle que la



directorio <unambiguous> es un directorio de más alto nivel. Tenga en cuenta también que en el primer ejemplo, el usuario "violó" el protocolo de intentar acceder al directorio recién creado con un nombre distinto del devuelto por TOPS-20. Los problemas pueden tener resultado en este caso no había sido un directorio <overrainbow>; se trata de una ambigüedad inherente en algunos TOPS-20 implementaciones. Consideraciones similares se aplican a la orden RMD. El punto es siguiente: salvo que de hacerlo violaría las convenciones de una serie de denota rutas relativas en comparación absoluta, el anfitrión debe tratar los operandos de los comandos MKD y RMD como subdirectorios. La 257 respuesta al comando MKD siempre debe contener el absoluto ruta de acceso del directorio creado.



ANEXO III - RFC en FTP

Bhushan, Abhay, "Protocolo de Transferencia de Archivos", RFC 114 (NIC 5823), MIT-Project MAC, 16 de abril de 1971.

Harslem, Eric y John Heafner ", Comentarios sobre el RFC 114 (un archivo Transfer Protocol) ", RFC 141 (NIC 6726), RAND, 29 de abril de 1971.

Bhushan, Abhay, et al, "El Protocolo de transferencia de archivos", RFC 172 (NIC 6794), MIT-Project MAC, 23 de junio de 1971.

Braden, Bob, "Comentarios sobre DTP y Propuestas de FTP", RFC 238 (NIC 7663), UCLA / CCN, 29 de septiembre de 1971.

Bhushan, Abhay, et al, "El Protocolo de transferencia de archivos", RFC 265 (NIC 7813), MIT-Project MAC, 17 de noviembre de 1971.

McKenzie, Alex, "Una adición propuesta a File Transfer Protocol", RFC 281 (NIC 8163), BBN, 8 de diciembre de 1971.

Bhushan, Abhay, "El uso de" Ajuste de tipo de datos "en la transacción del archivo Transfer Protocol ", RFC 294 (NIC 8304), MIT-Project MAC, 25 de enero 1972.

Bhushan, Abhay, "El protocolo de transferencia de archivos", RFC 354 (NIC 10596), MIT-Project MAC, 8 de julio de 1972.

Bhushan, Abhay, "Comentarios sobre el Protocolo de transferencia de archivos (RFC 354)", RFC 385 (NIC 11357), MIT-Project MAC, 18 de agosto de 1972.

Hicks, Greg, "Documentación del usuario FTP", RFC 412 (NIC 12404), Utah, 27 de noviembre 1972.

Bhushan, Abhay, "Protocolo de transferencia de estado y más de archivos (FTP) Comentarios ", RFC 414 (NIC 12406), MIT-Project MAC, 20 de noviembre de 1972.

Braden, Bob, "Comentarios sobre el Protocolo de transferencia de archivos", RFC 430 (NIC 13299), UCLA / CCN, 7 de febrero de 1973.

Thomas, Bob y Bob Clements, "Interacción Servidor FTP-Server", RFC 438 (NIC 13770), BBN, 15 de enero de 1973.

Braden, Bob, "Imprimir archivos en FTP", RFC 448 (NIC 13299), UCLA / CCN, 27 de febrero 1973.

McKenzie, Alex, "File Transfer Protocol", RFC 454 (NIC 14333), BBN, 16 de febrero 1973.



Bressler, Bob y Bob Thomas, "Recuperación de correo a través de FTP", RFC 458 (NIC 14378), BBN-NET y BBN-TENEX, 20 de febrero de 1973.

Neigus, Nancy, "File Transfer Protocol", RFC 542 (NIC 17759), BBN, 12 de julio 1973.

Krilanovich, Marcos y George Gregg, "Comentarios sobre la transferencia de archivos Protocolo ", RFC 607 (NIC 21255), UCSB, 7 de enero de 1974.

Pogran, Ken y Nancy Neigus, "Respuesta a RFC 607 - Comentarios sobre el File Transfer Protocol ", RFC 614 (NIC 21530), BBN, 28 de enero de 1974.

Krilanovich, Mark, George Gregg, Wayne Hathaway y Jim White, "Los comentarios sobre el protocolo de transferencia de archivos", RFC 624 (NIC 22054), UCSB, Centro de Investigación Ames, SRI-ARC, 28 de febrero de 1974.

Bhushan, Abhay, "FTP Comentarios y Respuesta a RFC 430", RFC 463 (NIC 14573), MIT-GCGD, 21 de febrero de 1973.

Braden, Bob, "Compresión de datos FTP", RFC 468 (NIC 14742), UCLA / CCN, 08 de marzo 1973.

Bhushan, Abhay, "FTP y el sistema de correo de Red", RFC 475 (NIC 14919), MIT-GCGD, 6 de marzo de 1973.

Bressler, Bob y Bob Thomas "Interacción Servidor FTP-Server - II", RFC 478 (NIC 14947), BBN-NET y BBN-TENEX, 26 de marzo de 1973.

Blanco, Jim, "Uso de FTP por la NIC Journal", RFC 479 (NIC 14948), SRI-ARC, 8 de marzo de 1973.

Blanco, Jim, "Parámetros FTP Host-dependientes", RFC 480 (NIC 14949), SRI-ARC, 8 de marzo de 1973.

Padlipsky, Mike, "Un problema de comandos FTP Naming", RFC 506 (NIC 16157), MIT-Multics, 26 de junio de 1973.

Día, John, "Memo al grupo FTP (Propuesta de protocolo de acceso a archivos)", RFC 520 (NIC 16819), Illinois, 25 de junio de 1973.

Merryman, Robert, "El UCSD-CC servidor FTP Fondo", RFC 532 (NIC 17451), UCSD-CC, 22 de junio de 1973.

Braden, Bob, "TENEX FTP problema", RFC 571 (NIC 18974), UCLA / CCN, 15 de noviembre 1973.



McKenzie, Alex, y Jon Postel ", Telnet y FTP Implementación - Programe el Cambio ", RFC 593 (NIC 20615), BBN y MITRE,

29 de noviembre 1973.

Sussman, Julie, "Uso de FTP Error Código para el correo más confiable Servicios ", RFC 630 (NIC 30237), BBN, 10 de abril de 1974.

Postel, Jon, "Revised Responder Códigos FTP", RFC 640 (NIC 30843), UCLA / NMC, 5 de junio de 1974.

Harvey, Brian, "Dejar las cosas como están", RFC 686 (NIC 32481), SU-AI, 10 de mayo de 1975.

Harvey, Brian, "One More Try en el FTP", RFC 691 (NIC 32700), SU-AI, 28 de mayo 1975.

Lieb, J., "CWD comando de FTP", RFC 697 (NIC 32963), 14 de julio de 1975.

Harrenstien, Ken, "FTP Extensión: XSEN", RFC 737 (NIC 42217), SRI-KL, 31 de octubre 1977.

Harrenstien, Ken, "FTP Extensión: XRSQ / XRCP", RFC 743 (NIC 42758), SRI-KL, 30 de diciembre de 1977.

Lebling, P. David, "Estudio de FTP y correo MLFL", RFC 751, MIT, 10 de diciembre 1978.

Postel, Jon, "Protocolo de transferencia de archivos Especificaciones", RFC 765, ISI, Junio de 1980.

Mankins, David, Dan Franklin, y Buzz Owen, "Directorio Oriented FTP Comandos ", RFC 776, BBN, diciembre de 1980.

Padlipsky, Michael, "FTP Único-Named Comando Store", RFC 949, MITRE, Julio de 1985.



REFERENCIAS

[1] Feinler, Elizabeth, "Protocolo de Internet Transition Workbook", Network Information Center, SRI International, marzo de 1982.

[2] Postel, Jon, "Protocolo de Control de Transmisión - DARPA Internet Program Protocolo de Especificaciones ", RFC 793, DARPA, septiembre de 1981.

[3] Postel, Jon, y Joyce Reynolds, "Protocolo Telnet Specification ", RFC 854, ISI, mayo de 1983.

[4] Reynolds, Joyce, y Jon Postel, "Assigned Numbers", RFC 943, ISI, abril de 1985.


FTPEl Protocolo de transferencia de archivos (FTP) es uno de los protocolos más viejos y populares que se encuentran en la Internet hoy día. Su objetivo es el de transmitir archivos exitósamente entre máquinas en una red sin que el usuario tenga que iniciar una sesión en el host remoto o que requiera tener conocimientos sobre cómo utilizar el sistema remoto. FTP permite a los usuarios acceder a archivos en sistemas remotos usando un conjunto de comandos estándar muy simples.

Este capítulo describe los elementos básicos de este protocolo, así como también las opciones de configuración para el servidor FTP primario que se entrega con Red Hat Enterprise Linux, vsftpd.

15.1. El Protocolo de Transferencia de ArchivosFTP utiliza una arquitectura cliente/servidor para transferir archivos usando el protocolo de red TCP. Puesto que FTP es un protocolo más antiguo, no utiliza una autenticación de usuarios y contraseña encriptada. Por esta razón, se considera un protocolo inseguro y no se debería utilizar a menos que sea absolutamente necesario. sftp, del conjunto de herramientas OpenSSH, es un buen sustituto para FTP. Para información sobre la configuración de OpenSSH, consulte el capítulo OpenSSH en el Manual de administración del sistema de Red Hat Enterprise Linux. Para más información sobre el protocolo SSH, consulte el Capítulo 20.

Sin embargo, puesto que FTP está tan extendido en la Internet, se requiere a menudo para compartir archivos con el público. Por lo tanto, los administradores de sistemas deberían estar conscientes de las características únicas del protocolo FTP.

15.1.1. Puertos múltiples, modos múltiples

A diferencia de la mayoría de los protocolos utilizados en Internet, FTP requiere de múltiples puertos de red para funcionar correctamente. Cuando una aplicación cliente FTP inicia una conexión a un servidor FTP, abre el puerto 21 en el servidor — conocido como el puerto de comandos. Se utiliza este puerto para arrojar todos los comandos al servidor. Cualquier petición de datos desde el servidor se devuelve al cliente a través del puerto de datos. El número de puerto para las conexiones de datos y la forma en la que las conexiones son inicializadas varía dependiendo de si el cliente solicita los datos en modo activo o en modo pasivo.

A continuación se describen estos modos:

modo activo

El modo activo es el método original utilizado por el protocolo FTP para la transferencia de datos a la aplicación cliente. Cuando el cliente FTP inicia una transferencia de datos, el servidor abre una conexión desde el

http://www.gb.nrao.edu/pubcomputing/redhatELWS4/RH-DOCS/rhel-rg-es-4/ch-ssh.html

puerto 20 en el servidor para la dirección IP y un puerto aleatorio sin privilegios (mayor que 1024) especificado por el cliente. Este arreglo implica que la máquina cliente debe poder aceptar conexiones en cualquier puerto superior al 1024. Con el crecimiento de las redes inseguras, tales como Internet, es muy común el uso de cortafuegos para proteger las máquinas cliente. Debido a que estos cortafuegos en el lado del cliente normalmente rechazan las conexiones entrantes desde servidores FTP en modo activo, se creó el modo pasivo.

modo pasivo

La aplicación FTP cliente es la que inicia el modo pasivo, de la misma forma que el modo activo. El cliente FTP indica que desea acceder a los datos en modo pasivo y el servidor proporciona la dirección IP y el puerto aleatorio, sin privilegios (mayor que 1024) en el servidor. Luego, el cliente se conecta al puerto en el servidor y descarga la información requerida.

Mientras que el modo pasivo resuelve el problema de la interferencia del cortafuegos en el lado del cliente con las conexiones de datos, también puede complicar la administración del cortafuegos del lado del servidor. Una de las formas de limitar el número de puertos abiertos en el servidor y de simplificar la tarea de crear reglas para el cortafuegos del lado del servidor, es limitando el rango de puertos sin privilegios ofrecidos para las conexiones pasivas. Consulte la Sección 15.5.8 para más detalles sobre cómo limitar puertos pasivos.

15.2. Servidores FTPRed Hat Enterprise Linux se entrega con dos servidores FTP diferentes:

Acelerador de Contenidos Red Hat — Un servidor Web basado en el kernel que ofrece un servidor web y servicios FTP de alto rendimiento. Puesto que la velocidad es su objetivo principal de diseño, su funcionalidad es limitada y solamente se ejecuta como FTP anónimo. Para más información sobre la configuración y administración delAcelerador de Contenidos Red Hat, consulte la documentación disponible en línea en http://www.redhat.com/docs/manuals/tux/.

vsftpd — un demonio FTP rápido y seguro, preferido para Red Hat Enterprise Linux. El resto de este capítulo se enfoca en vsftpd.

15.2.1. vsftpd

El demonio FTP vsftpd (o Very Secure FTP Daemon) está diseñado desde la base para ser rápido, estable y lo más importante, seguro. Su habilidad para manejar grandes números de conexiones de forma eficiente y segura es lo que hace que vsftpd sea el único FTP independiente distribuido con Red Hat Enterprise Linux.

El modelo de seguridad utilizado por vsftpd tiene tres aspectos principales:

http://www.redhat.com/docs/manuals/tux/

http://www.gb.nrao.edu/pubcomputing/redhatELWS4/RH-DOCS/rhel-rg-es-4/s1-ftp-vsftpd-conf.html#S2-FTP-VSFTPD-CONF-OPT-NET

Clara separación de procesos privilegiados y sin privilegios — Procesos separados manejan tareas diferentes y cada uno de estos procesos se ejecuta con los privilegios mínimos requeridos para la tarea.

Las tareas que requieren altos privilegios son manejadas por procesos con los mínimos privilegios necesarios — Influenciando las compatibilidades encontradas en la biblioteca libcap, las tareas que usualmente requieren privilegios de superusuario se pueden ejecutar de forma más segura desde un proceso menos privilegiado.

La mayoría de los procesos se ejecutan enjaulados en un ambiente chroot — Siempre que sea posible, se cambia la raíz de los procesos al directorio compartido; este directorio se considera luego como la jaula chroot. Por ejemplo, si el directorio /var/ftp/ es el directorio compartido principal, vsftpd reasigna /var/ftp/al nuevo directorio raíz, conocido como /. Esto previene actividades maliciosas de cualquier hacker potencial en algún directorio que no estén por debajo del nuevo directorio root.

El uso de estas prácticas de seguridad tiene el efecto siguiente en cómo vsftpd trata con las peticiones:

El proceso padre se ejecuta con el mínimo de privilegios requerido — El proceso padre calcula dinámicamente el nivel de privilegios requerido para minimizar el nivel de riesgos. Los procesos hijo manejan la interacción directa con los clientes FTP y se ejecutan casi sin ningún privilegio.

Todas las operaciones que requieren altos privilegios son manejadas por un pequeño proceso padre — Similar a Servidor Apache HTTP, vsftpd lanza procesos hijos sin privilegios para manejar las conexiones entrantes. Esto permite al proceso padre privilegiado, ser tan pequeño como sea posible y manejar relativamente pocas tareas.

El proceso padre no confia en ninguna de las peticiones desde procesos hijos sin privilegios — Las comunicaciones con procesos hijos se reciben sobre un socket y la validez de cualquier información desde un proceso hijo es verificada antes de proceder.

La mayor parte de la interacción con clientes FTP la manejan procesos hijo sin privilegios en una jaula chroot. — Debido a que estos procesos hijo no tienen privilegios y solamente tienen acceso al directorio que está siendo compartido, cualquier proceso fallido solamente permitirá al atacante acceder a los archivos compartidos.

15.3. Archivos instalados con vsftpdEl RPM vsftpd instala el demonio (/usr/sbin/vsftpd), su archivo de configuración y otros archivos relacionados, así como también directorios FTP en el sistema. La siguiente es una lista de los archivos y directorios considerados más a menudo cuando se configura vsftpd:

/etc/rc.d/init.d/vsftpd — El script de inicialización (initscript) utilizado por el comando /sbin/service para iniciar, detener o volver a cargar vsftpd. Consulte la Sección 15.4 para más información sobre el uso de este script.

/etc/pam.d/vsftpd — El archivo de configuración de los Pluggable Authentication Modules (PAM) para vsftpd. Este archivo define los requerimientos que debe cumplir un usuario para conectarse a un servidor FTP. Para más información, consulte el Capítulo 16.

/etc/vsftpd/vsftpd.conf — El archivo de configuración para vsftpd. Consulte el Sección 15.5 para una lista de las opciones importantes que se encuentran en este archivo.

/etc/vsftpd.ftpusers — Una lista de los usuarios que no tienen permitido conectarse a vsftpd. Por defecto esta lista incluye a los usuarios root, bin y daemon, entre otros.

/etc/vsftpd.user_list — Este archivo se puede configurar para negar o permitir el acceso a los usuarios listados, dependiendo de si la directriz userlist_denyestá configurada a YES (por defecto) o a NO en /etc/vsftpd/vsftpd.conf. Si se utiliza /etc/vsftpd.user_list para permitir acceso a los usuarios, los nombres de usuarios listados no deben aparecer en /etc/vsftpd.ftpusers.

El directorio /var/ftp/ — El directorio que contiene los archivos servidos por vsftpd. También contiene el directorio /var/ftp/pub/ para los usuarios anónimos. Ambos directorios están disponibles para la lectura de todos, pero sólo el superusuario o root puede escribir en el.

http://www.gb.nrao.edu/pubcomputing/redhatELWS4/RH-DOCS/rhel-rg-es-4/s1-ftp-vsftpd-conf.html

http://www.gb.nrao.edu/pubcomputing/redhatELWS4/RH-DOCS/rhel-rg-es-4/ch-pam.html

http://www.gb.nrao.edu/pubcomputing/redhatELWS4/RH-DOCS/rhel-rg-es-4/s1-ftp-vsftpd-start.html

Documents

Protocolo FTP