Protocolo FTP

Protocolo FTP (Protocolo de transferencia de archivos)
DEUSESFRITBR
Junio 2013
Introduccin al protocolo FTP

El protocolo FTP (Protocolo de transferencia de archivos) es, como su nombre lo indica, un protocolo para transferir archivos. La implementacin del FTP se remonta a 1971 cuando se desarroll un sistema de transferencia de archivos (descrito en RFC141) entre equipos del Instituto Tecnolgico de Massachusetts (MIT, Massachusetts Institute of Technology ). Desde entonces, diversos documentos de RFC (peticin de comentarios) han mejorado el protocolo bsico, pero las innovaciones ms 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 funcin del protocolo FTP

El protocolo FTP define la manera en que los datos deben ser transferidos a travs 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 enva rdenes (el cliente) y el otro espera solicitudes para llevar a cabo acciones (el servidor). Durante una conexin FTP, se encuentran abiertos dos canales de transmisin: Un canal de comandos (canal de control) Un canal de datos
Por lo tanto, el cliente y el servidor cuentan con dos procesos que permiten la administracin de estos dos tipos de informacin: DTP (Proceso de transferencia de datos) es el proceso encargado de establecer la conexin 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 (Intrprete de protocolo) interpreta el protocolo y permite que el DTP pueda ser controlado mediante los comandos recibidos a travs 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 travs del canal de control en unpuerto de datos, de establecer la conexin para el canal de control, de recibir los comandos FTP del USUARIO PI a travs de ste, de responderles y de ejecutar el SERVIDOR DE DTP. El USUARIO PI es responsable de establecer la conexin 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 conexin con el servidor de acuerdo con el protocolo Telnet. El cliente enva comandos FTP al servidor, el servidor los interpreta, ejecuta su DTP y despus enva una respuesta estndar. Una vez que se establece la conexin, el servidor PI proporciona el puerto por el cual se enviarn 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 informacin entre dos procesos del servidor conectados en el puerto correcto.
En esta configuracin, el protocolo indica que los canales de control deben permanecer abiertos durante la transferencia de datos. De este modo, un servidor puede detener una transmisin si el canal de control es interrumpido durante la transmisin.
Los comandos FTP

Toda comunicacin 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 cdigo NVT-ASCII) que finalizan con el cdigo de final de lnea Telnet (es decir, la secuencia <CR>+<LF>, Retorno de carro seguido del carcter Avance de lnea indicado como <CRLF>). Si el comando FTP tiene un parmetro, ste se separa del comando con un espacio (<SP>). Los comandos FTP hacen posible especificar: El puerto utilizado El mtodo de transferencia de datos La estructura de datos
La naturaleza de la accin que se va a realizar (Recuperar, Enumerar, Almacenar, etc.) Existen tres tipos de comandos FTP diferentes: Comandos de control de acceso Comandos de parmetros de transferencia Comandos de servicio FTP
Comandos de control de acceso
Comando Descripcin USER Cadena de caracteres que permite identificar al usuario. La identificacin del usuario es necesaria para establecer la comunicacin a travs del canal de datos. Cadena de caracteres que especifica la contrasea del usuario. Este comando debe ser inmediatamente precedida por el comando USER. El cliente debe decidir si esconder la visualizacin de este comando por razones de seguridad. Cadena de caracteres que especifica la cuenta del usuario. El comando generalmente no es necesario. Durante la respuesta que acepta la contrasea, si la respuesta es 230, esta etapa no es necesaria; Si la respuesta es 332, s lo es. Change 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. Change to Parent Directory (Cambiar al directorio principal): este comando permite regresar al directorio principal. Se introdujo para resolver los problemas de denominacin del directorio principal segn el sistema (generalmente ".."). Structure Mount (Montar estructura): Reinitialize (Reinicializar): Comando que permite abandonar la sesin actual. Si es necesario, el servidor espera a que finalice la transferencia en progreso y despus proporciona una respuesta antes de cerrar la conexin.
PASS
ACCT
CWD
CDUP
SMNT REIN QUIT
Comandos de parmetros de transferencia Comando Descripcin PORT Cadena de caracteres que permite especificar el nmero de puerto utilizado. Comando que permite indicar al servidor de DTP que permanezca a la espera de una conexin en un puerto especfico elegido aleatoriamente entre los puertos disponibles. La respuesta a este comando es la direccin IP del equipo y el puerto. Este comando permite especificar el tipo de formato en el cual se enviarn los datos. Carcter Telnet que especifica la estructura de archivos (F de File [Archivo] , R de Record [Registro] , P de Page [Pgina] ). Carcter Telnet que especifica el mtodo de transferencia de datos (S deStream [Flujo] , B de Block [Bloque] , C de Compressed [Comprimido] ).
PASV
TYPE STRU
MODE
Comandos de servicio FTP
Comando Descripcin RETR Este comando (RETRIEVE [RECUPERAR] ) le pide al servidor de DTP una copia del archivo cuya ruta de acceso se da en los parmetros. 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 parmetros. Si el archivo no existe, el servidor lo crea; de lo contrario, lo sobrescribe. Este comando es idntico al anterior, slo le pide al servidor que cree un archivo cuyo nombre sea nico. El nombre del archivo se enva en la respuesta. Gracias a este comando (append [adjuntar] ) los datos enviados se concatenan en el archivo que lleva el nombre dado en el parmetro si ya existe; si no es as, se crea. Este 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. Este comando (restart [reiniciar] ) permite que se reinicie una transferencia desde donde se detuvo. Para hacer esto, el comando enva en el parmetro el marcador que representa la posicin en el archivo donde la transferencia se haba interrumpido. Despus de este comando se debe enviar inmediatamente un comando de transferencia. Este comando (rename from [renombrar desde] ) permite volver a nombrar un archivo. En los parmetros indica el nombre del archivo que se va a renombrar y debe estar inmediatamente seguido por el comando RNTO. Este comando (rename from [renombrar a] ) permite volver a nombrar un archivo. En los parmetros indica el nombre del archivo que se va a renombrar y debe estar inmediatamente seguido por el comando RNFR. Este comando (abort [cancelar] ) le indica al servidor de DTP que abandone todas las transferencias asociadas con el comando previo. Si no hay conexin de datos abierta, el servidor de DTP no realiza ninguna accin; de lo contrario, cierra la conexin. Sin embargo, el canal de control permanece abierto. Este comando (delete [borrar] ) permite que se borre un archivo, cuyo nombre se da en los parmetros. Este comando es irreversible y la confirmacin slo puede darse a nivel cliente. Este comando (remove directory [eliminar directorio] ) permite borrar un directorio. El nombre del directorio que se va a borrar se indica en los parmetros. Este comando (make directory [crear directorio] ) permite crear un directorio. El nombre del directorio que se va a crear se indica en los parmetros.
STOR
STOU
APPE
ALLO
REST
RNFR
RNTO
ABOR
DELE
RMD
MKD
PWD
Este comando (print working directory [mostrar el directorio actual] ) hace posible volver a enviar la ruta del directorio actual completa. Este comando permite que se vuelva a enviar la lista de archivos y directorios presentes en el directorio actual. Esto se enva a travs del DTP pasivo. Es posible indicar un nombre de directorio en el parmetro de este comando. El servidor de DTP enviar la lista de archivos del directorio ubicado en el parmetro. Este comando (name list [lista de nombres] ) permite enviar la lista de archivos y directorios presentes en el directorio actual. Este comando (site parameters [parmetros del sistema] ) hace que el servidor proporcione servicios especficos no definidos en el protocolo FTP. Este comando (system [sistema] ) permite el envo de informacin acerca del servidor remoto. 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 despus devuelve la misma informacin que LISTA pero a travs del canal de control. Este comando permite conocer todos los comandos que el servidor comprende. La informacin se devuelve por el canal de control. Este comando (no operations [no operacin] ) slo se utiliza para recibir un comando OK del servidor. Slo se puede utilizar para no desconectarse despus de un perodo de inactividad prolongado.
LIST
NLST
SITE
SYST
STAT
HELP
NOOP
Las respuestas FTP

Las respuestas FTP garantizan la sincronizacin entre el cliente y el servidor FTP. Por lo tanto, por cada comando enviado por el cliente, el servidor eventualmente llevar a cabo una accin y sistemticamente enviar una respuesta. Las respuestas estn compuestas por un cdigo de 3 dgitos que indica la manera en la que el comando enviado por el cliente ha sido procesado. Sin embargo, debido a que el cdigo de 3 dgitos resulta difcil de leer para las personas, est acompaado de texto (cadena de caracteres Telnet separada del cdigo numrico por un espacio). Los cdigos de respuesta estn compuestos por 3 nmeros, cuyos significados son los siguientes: El primer nmero indica el estatuto de la respuesta (exitosa o fallida) El segundo nmero indica a qu se refiere la respuesta. El tercer nmero brinda un significado ms especfico (relacionado con cada segundo dgito).
Primer nmero
Dgito Significado 1yz
Descripcin
La accin solicitada est en progreso. Se debe obtener Respuesta positiva una segunda respuesta antes de enviar un segundo preliminar comando. Respuesta de finalizacin positiva Respuesta intermedia positiva Respuesta de finalizacin negativa Respuesta negativa permanente La accin solicitada se ha completado y puede enviarse un nuevo comando. La accin solicita est temporalmente suspendida. Se espera informacin adicional del cliente. La accin solicitada no se ha realizado debido a que el comando no se ha aceptado temporalmente. Se le solicita al cliente que intente ms tarde. La accin solicitada no se ha realizado debido a que el comando no ha sido aceptado. Se le solicita al cliente que formule una solicitud diferente.
2yz
3yz
4yz
5yz
Segundo nmero Dgito Significado x0z x1z x2z x3z Sintaxis Informacin Conexiones Autenticacin y cuentas No utilizado por el protocolo FTP. Sistema de archivos La respuesta se relaciona con el sistema de archivos remoto. Descripcin La accin tiene un error de sintaxis o sino, es un comando que el servidor no comprende. sta es una respuesta que enva informacin (por ejemplo, una respuesta a un comando STAT). La respuesta se refiere al canal de datos. La respuesta se refiere al inicio de sesin (USUARIO/CONTRASEA) o a la solicitud para cambiar la cuenta (CPT).
x4z x5z
Ms informacin
Red Grupo de Trabajo J. Postel Peticin de Comentarios: 959 J. Reynolds ISI Obsoletes RFC: 765 (IEN 149) octubre 1985 File Transfer Protocol (FTP) Condicin de este Memo Esta nota es la especificacin oficial de la transferencia de archivos Protocol (FTP). La distribucin de este memo es ilimitada. Los nuevos comandos opcionales siguientes se incluyen en esta edicin 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 especificacin es compatible con la edicin anterior. 1. INTRODUCCIN Los objetivos del FTP son 1) promover el intercambio de archivos (ordenador programas y / o datos), 2) fomentar la indirecta o implcita (a travs 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 diseado principalmente para su uso por los programas. El intento de esta especificacin es satisfacer las diversas necesidades de los usuarios de maxi-hosts, mini-hosts, estaciones de trabajo personales y TAC, con un protocolo de diseo simple, y fcil de implementar. En este trabajo se asume el conocimiento del Protocolo de Control de Transmisin (TCP) [2] y el Protocolo Telnet [3]. Estos documentos se encuentran en el protocolo del manual de ARPA-Internet [1]. 2. PANORAMA En esta seccin, la historia, la terminologa y el modelo FTP son discutido. Los trminos definidos en esta seccin son nicamente los que tienen un significado especial en FTP. Parte de la terminologa es muy
especfico para el modelo FTP, algunos lectores tal vez deseen recurrir a la seccin sobre el modelo FTP al revisar la terminologa.
Postel & Reynolds [Pgina 1]
RFC 959 10 1985 Protocolo de transferencia de archivos 2.1. HISTORIA FTP ha tenido una larga evolucin a lo largo de los aos. Apndice III es un compilacin cronolgica 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 implementacin de los ejrcitos en el MIT (RFC 114), adems de comentarios y discusin 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 revisin de la esto como RFC 265 de FTP actualizados para la revisin adicional, mientras RFC 281 sugieren nuevos cambios. El uso de un "conjunto de tipos de datos" transaccin 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 funcin principal de FTP define como transferir archivos de manera eficiente y confiable entre los hosts y permitiendo el uso prctico 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 situacin 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 especificacin "oficial" para reflejar estos cambios. Sin embargo, muchas implementaciones basadas en la mayor especificacin no se han actualizado. En 1974, RFC 607 y 614 continuos comentarios sobre FTP. RFC 624 propone ms cambios de diseo y modificaciones de menor importancia. En el ao 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 revisin menor del RFC 686, en relacin con la tema de archivos de impresin. Motivados por la transicin del NCP al TCP como subyacentes del protocolo, un fnix naci de todo lo anterior esfuerzos en RFC 765 como la especificacin de FTP para su uso en TCP. La presente edicin de la especificacin FTP pretende corregir algunos errores leves de documentacin, para mejorar la explicacin de algunas de las caractersticas del protocolo, y para aadir algo nuevo comandos opcionales. Postel & Reynolds [Pgina 2]
RFC 959 10 1985 Protocolo de transferencia de archivos En particular, los siguientes nuevos comandos opcionales se incluyen en esta edicin de la especificacin: 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 especificacin es compatible con la edicin anterior. La
programa implementado en conformidad con la especificacin anterior debera ser automtica en conformidad con esta especificacin. 2.2. TERMINOLOGA ASCII El juego de caracteres ASCII es como se define en el ARPAInternet Manual de Protocolo. En FTP, caracteres ASCII se definen como la mitad inferior de un conjunto de cdigos de ocho bits (es decir, el ms bit ms significativo es cero). controles de acceso Los controles de acceso definen los privilegios de acceso de los usuarios a la utilizacin 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. tamao en bytes Hay dos tamaos de byte de inters en FTP: el byte lgico tamao del archivo y el tamao en bytes de transferencia usada para la transmisin de los datos. El tamao en bytes de transferencia es siempre 8 los bits. El tamao en bytes de transferencia no es necesariamente el tamao en bytes en el que los datos se va a almacenar en un sistema, ni el byte lgico tamao de interpretacin de la estructura de los datos.
RFC 959 10 1985 Protocolo de transferencia de archivos conexin de control La ruta de comunicacin entre el usuario y el servidor-PI-PI para el intercambio de comandos y respuestas. Esta conexin sigue el Protocolo Telnet. conexin de datos Una conexin dplex 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 conexin desde el proceso de transferencia activo con el fin de abrir la conexin de datos. DTP El proceso de transferencia de datos establece y gestiona los datos conexin. La DTP puede ser pasiva o activa. Fin de Lnea La secuencia de fin de lnea define la separacin de la impresin lneas. La secuencia es el retorno de carro seguido por salto de lnea. EOF La condicin de final de archivo que define el final de un archivo que se est transferido. EOR La condicin de fin-de-registro que define el final de un registro que se transfiere. recuperacin 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, recuperacin de errores puede implicar reiniciar una transferencia de archivos en una dado puesto de control.
RFC 959 10 1985 Protocolo de transferencia de archivos Comandos FTP
Un conjunto de comandos que componen la informacin de control de flujo del usuario FTP para el proceso del servidor FTP. expediente Un conjunto ordenado de datos informticos (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 travs de los datos conexin. 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 seccin sobre Modos de transmisin. 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 estndar con los comandos estndar y convenciones pathname. pgina Un archivo puede estar estructurado como un conjunto de partes independientes llamado pginas. FTP es compatible con la transmisin de archivos discontinuos como indexado pginas 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 especificacin de nombre de archivo. FTP no ha especificado todava un estndar convencin ruta. Cada usuario debe seguir la nomenclatura de archivos convenciones de los sistemas de archivos que intervienen en la transferencia. PI
El intrprete de protocolo. El usuario y el servidor de los lados de la protocolo tiene distintas funciones implementadas en un usuario-PI y servidor-PI. Postel & Reynolds [Pgina 5]
RFC 959 10 1985 Protocolo de transferencia de archivos 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 travs de la conexin de control en respuesta a FTP comandos. La forma general de una respuesta es un cdigo de terminacin (Incluyendo cdigos de error) seguido de una cadena de texto. Los cdigos 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 conexin de datos con el puerto de datos "escuchar". En l se establecen los parmetros 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 conexin en el puerto de datos. proceso del servidor FTP Un proceso o conjunto de procesos que realizan la funcin de transferencia de archivos en cooperacin con un proceso de usuario-FTP y, posiblemente, otro servidor. Las funciones consisten en un protocolo intrprete (PI) y un proceso de transferencia de datos (DTP). servidor-PI
El intrprete de protocolo del servidor "escucha" en el puerto de L conexin de un usuario-PI y establece un control conexin de comunicacin. Recibe comandos FTP estndar por parte del usuario-PI, enva respuestas y rige el servidor-DTP. tipo El tipo de representacin 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 representacin definido en FTP se describen en la seccin sobre el establecimiento de Conexiones de datos.
RFC 959 10 1985 Protocolo de transferencia de archivos 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 diseo del protocolo se pondera hacia autmatas. user-DTP El proceso de transferencia de datos "escucha" en el puerto de datos para una Conexin 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 intrprete de protocolo, los datos la transferencia de procesos y una interfaz de usuario que en conjunto realizan la funcin de transferencia de archivos en cooperacin con uno o ms procesos del servidor FTP. La interfaz de usuario permite que un local de
idioma que se utilizar en el dilogo de comandos-respuesta con el usuario. user-PI El intrprete de protocolo de usuario inicia la conexin 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.
RFC 959 10 1985 Protocolo de 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 | | conexin | | DTP | | | Sistema | -------- | \ ------ / | | \ --------- / | -----------------------------Servidor FTP USUARIO FTP NOTAS: 1. La conexin de datos puede ser utilizado en cualquier direccin. 2. La conexin 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 intrprete de protocolo de usuario inicia la conexin de control. La conexin 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 travs de la conexin de control. (El usuario puede establecer una conexin de control directa con el servidor de FTP-, a partir de una Terminal de TAC por ejemplo, y generar comandos estndar de FTP independiente, sin pasar por el proceso de usuario FTP.) respuestas estndar se envan desde el servidor-PI para el usuario-PI sobre el control conexin en respuesta a los comandos. Los comandos FTP especifican los parmetros para la conexin de datos (Puerto de datos, modo de transferencia, tipo de representacin y estructura) y la naturaleza de la operacin del sistema de archivos (almacenar, recuperar, aadir, borrar, etc.) El usuario-DTP o designada debe "escuchar" en la el puerto de datos especificado, y el servidor inicien los datos la conexin y la transferencia de datos de acuerdo con la especificada parmetros. Cabe sealar que el puerto de datos no necesita ser en Postel & Reynolds [Pgina 8]
RFC 959 10 1985 Protocolo de transferencia de archivos el mismo host que inicia los comandos FTP a travs del control conexin, pero el usuario o el proceso de usuario-FTP deben garantizar un "Escuchar" en el puerto de datos especificado. Debera tambin tenerse en cuenta que la conexin de datos puede ser utilizado para envo simultneo y receptora.
En otra situacin, un usuario podra desear transferir archivos entre dos ejrcitos, ninguno de los cuales es un anfitrin local. El usuario configura controlar las conexiones a los dos servidores y arreglos para una conexin de datos entre ellos. De esta manera, controlar la informacin se pasa al usuario-PI, pero los datos se transfieren entre el procesos de transferencia de datos del servidor. A continuacin se presenta un modelo de este interaccin servidor-servidor. Control ------------ control ----------> | Usuarios FTP | <----------| | Usuario-PI | | | | "C" | | V ------------ V ---------------------------| Servidor FTP | Conexin 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 accin. La transferencia de datos puede abortar si el control de servidor conexiones se cierran sin comando. La relacin entre FTP y Telnet: El FTP utiliza el protocolo Telnet de la conexin 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 mdulo de Telnet existente en el sistema. Facilidad de implementaion, cdigos compartidos, y la programacin modular argumentar a favor de la segunda opcin. La eficiencia y la independencia
RFC 959 10 1985 Protocolo de transferencia de archivos argumentar a favor de la primera aproximacin. En la prctica, FTP se basa en muy poco del protocolo Telnet, por lo que el primer enfoque no necesariamente implicar una gran cantidad de cdigo. 3. FUNCIONES DE TRANSFERENCIA DE DATOS Los archivos se transfieren nicamente a travs de la conexin de datos. El control conexin se utiliza para la transferencia de comandos, que describen el funciones que se deben realizar, y las respuestas a estos comandos (ver la Seccin 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 cmo 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 transmisin y la representacin son bsicamente independientes pero el "Corriente" modo de transmisin depende de la estructura de archivos atributo y si se utiliza el modo de transmisin "comprimido", la naturaleza del byte de relleno depende del tipo de representacin. 3.1. REPRESENTACIN DE DATOS Y ALMACENAMIENTO Los datos se transfieren desde un dispositivo de almacenamiento en el envo 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 cdigos 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 representacin NVT-ASCII estndar cuando la transmisin de texto entre sistemas diferentes. El envo y la los sitios de recepcin tendra que llevar a cabo la necesaria transformaciones entre la representacin y su nivel representaciones internas.
Un problema diferente en representacin surge cuando se transmite datos binarios (cdigos de carcter no) entre los sistemas host con diferentes longitudes de palabra. No siempre est claro cmo el emisor debern enviar los datos, y el receptor almacena. Por ejemplo, cuando transmisin 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 opcin de especificar los datos representacin y funciones de transformacin. Cabe sealar
RFC 959 10 1985 Protocolo de transferencia de archivos que la FTP establece representaciones de tipos de datos muy limitados. Transformaciones deseados ms 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 representacin. Este tipo puede implcitamente (como en ASCII o EBCDIC) o explcitamente (como en el byte local) definen un tamao de bytes de interpretacin que se conoce como el "tamao de byte lgico." Tenga en cuenta que esto no tiene nada que ver con el tamao en bytes utilizado para transmisin a travs de la conexin de datos, llamado el "transferencia tamao en bytes ", y los dos no deben confundirse. Por ejemplo, NVT-ASCII tiene un tamao de byte lgico de 8 bits. Si el tipo es Byte local, entonces el comando TYPE tiene una segunda condicin para parmetro que especifica el tamao de byte lgico. El byte de transferencia tamao 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 encontraran el EBCDIC escribir ms conveniente. El remitente convierte los datos de carcter interno representacin con el estndar de 8 bits NVT-ASCII representacin (ver la especificacin Telnet). El receptor convertir los datos de la forma estndar a su propio forma interna. De acuerdo con el estndar NVT, la secuencia <CRLF> debe ser utilizado cuando sea necesario para indicar el final de una lnea de texto. (Vase el anlisis de la estructura del archivo al final de la Seccin de representacin de datos y de almacenamiento.) Con la representacin NVT-ASCII estndar significa que los datos debe interpretarse en bytes de 8 bits. El parmetro de formato para los tipos ASCII y EBCDIC se discute a continuacin.
RFC 959 10 1985 Protocolo de transferencia de archivos 3.1.1.2. TIPO EBCDIC Este tipo est destinado para una transferencia eficaz entre los hosts que el uso EBCDIC por su carcter interno representacin. Para la transmisin, los datos se representan como EBCDIC de 8 bits personajes. El cdigo de carcter 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 discusin de la estructura), probablemente se utiliza raramente con el tipo EBCDIC
para los propsitos de que denota la estructura, pero donde est necesario el carcter <NL> se debe utilizar. 3.1.1.3. TIPO DE IMAGEN Los datos se envan en forma de bits contiguos que, para la transferencia, se empaquetan en los bytes de transferencia de 8 bits. La recepcin de sitio debe almacenar los datos como bits contiguos. La estructura del sistema de almacenamiento podra requerir el relleno de la archivo (o de cada registro, para un archivo de registros estructurados) para algn lmite prctico (byte, palabra o bloque). Este acolchado, que deben ser todos ceros, puede producirse slo 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 transformacin 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 recuperacin 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 lgicos del tamao especificado por el segundo parmetro obligatorio, tamao Byte. El valor de tamao de byte debe ser un entero decimal, hay ningn valor predeterminado. El tamao de byte lgico no es necesariamente el mismo que el tamao en bytes de transferencia. Si hay una diferencia en tamaos de byte, a continuacin, los bytes lgicos debe ser embalado contigua, sin tener en cuenta los lmites de bytes de transferencia y con cualquier relleno necesario, al final.
RFC 959 10 1985 Protocolo de transferencia de archivos Cuando los datos llegan al host receptor, ser
transformado en una forma dependiente del tamao de byte lgico y el anfitrin particular. Esta transformacin debe ser invertible (es decir, un archivo idntico se puede recuperar si el se utilizan los mismos parmetros) y deberan estar bien publicitados por los ejecutores FTP. Por ejemplo, un usuario el envo de nmeros de punto flotante de 36 bits a un host con una palabra de 32 bits podra enviar esos datos como byte local con un tamao en bytes de la lgica 36. El host receptor hara a continuacin, esperar para almacenar los bytes lgicos para que podra ser fcilmente manipulado; en este ejemplo poniendo el 36-bit bytes lgicos en palabras dobles de 64 bits deben suficiente. En otro ejemplo, un par de ordenadores con un tamao de palabra de 36 bits puede enviar datos a otros en palabras usando TIPO L 36. Los datos se enviarn en los bytes de transmisin de 8 bits embalarse 9 bytes de transmisin llevan a dos palabras de acogida. 3.1.1.5. CONTROL DE FORMATO Los tipos ASCII y EBCDIC tambin toman un segundo (opcional) parmetro, esto es para indicar qu tipo de formato vertical de control, en su caso, se asocia con un archivo. El siguiente tipos de representacin de datos se definen en el FTP: Un archivo de caracteres puede ser transferido a un husped para uno de tres propsitos: para la impresin, para el almacenamiento y ms tarde recuperacin o para su procesamiento. Si se enva un archivo de la impresin, el host receptor debe saber cmo la vertical control de formato se representa. En el segundo caso, debe ser posible almacenar un archivo en un host y luego recuperarla ms 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 parmetro 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 parmetro. Formato de impresin no debe ser aceptado por todas las implementaciones de FTP.
RFC 959 10 1985 Protocolo de transferencia de archivos El archivo necesita contener ninguna informacin de formato vertical. Si que se pasa a un proceso de impresora, este proceso puede asumir valores estndar de espaciado y mrgenes. 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, tambin denota al final de la lnea. 3.1.1.5.2. CONTROL DE TRANSPORTE (ASA) El archivo contiene ASA (FORTRAN) de control de formato vertical personajes. (Vase el RFC 740 Apndice C, y Comunicaciones de la ACM, vol. 7, N 10, p. 606, octubre de 1964.) En un lnea o de un registro con formato segn la norma ASA, no se va a imprimir el primer carcter. En su lugar, se se debe utilizar para determinar el movimiento vertical de la papel que debera tener lugar antes de que el resto de la se imprime registro. El estndar ASA especifica el siguiente control personajes: Carcter Separacin Vertical Mover papel en blanco una lnea hacia arriba
0 Move papel de hasta dos lneas 1 Mover el papel al principio de la pgina siguiente + No hay movimiento, es decir, la impresin, 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 (vase ms adelante), este no es un problema; registros se marcarn de forma explcita durante la transferencia y almacenamiento. Si el archivo no tiene estructura de registro, el <CRLF> secuencia final de la lnea se utiliza para la impresin de lneas separadas, pero estos determinantes de formato prevalezca la ASA controles.
RFC 959 10 1985 Protocolo de transferencia de archivos 3.1.2. ESTRUCTURAS DE DATOS Adems de los diferentes tipos de representacin, 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 pgina-estructura, donde el archivo se compone de independiente pginas 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 debern 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 seccin en los modos de transmisin) y la interpretacin y almacenamiento de el archivo. La estructura "natural" de un archivo depender del anfitrin almacena el archivo. Un archivo de cdigo 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 lneas, por ejemplo por <CRLF>. Si la transferencia de archivos entre tal dispares sitios es para ser til, debe haber algn 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 enva a un host orientado a la otra. Si un archivo de texto que se enva con el expediente de la estructura a un host que es el archivo orientado, entonces ese host debe aplicar un interno transformacin en el fichero de base a la estructura de registro. Obviamente, esta transformacin debe ser til, pero debe tambin ser invertible de manera que un archivo idntico puede ser recuperada con estructura de registro. En el caso de un archivo que se enva con el archivoestructura a una acogida orientado a registro, existe la cuestin de qu criterios del anfitrin deben usar para dividir el archivo en registros que pueden ser procesados localmente. Si esta divisin es necesario, la aplicacin FTP debe utilizar la secuencia final de la lnea, Postel & Reynolds [Pgina 15]
RFC 959 10 1985 Protocolo de transferencia de archivos <CRLF> Para ASCII o <NL> para archivos de texto EBCDIC, ya que el delimitador. Si una aplicacin FTP adopta esta tcnica, se deben estar preparados para revertir la transformacin 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 PGINA Para transmitir archivos que son discontinuos, FTP define una pgina 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 informacin asociada con el archivo como un todo (por ejemplo, un descriptor de archivo), o con un seccin del archivo (por ejemplo, controles de acceso de pgina), o ambos. En FTP, las secciones del archivo se denominan pginas. Para proporcionar varios tamaos de pgina y asociados informacin, cada pgina se enva con un encabezado de pgina. La pgina cabecera tiene los siguientes campos definidos: Longitud de cabecera El nmero de bytes lgicos en el encabezado de la pgina incluyendo este byte. La longitud de la cabecera mnima es de 4. Pgina ndice El nmero de pgina lgica de esta seccin del archivo. Este no es el nmero de secuencia de transmisin de esta pgina, pero el ndice utilizado para identificar esta pgina del archivo. Postel & Reynolds [Pgina 16]
RFC 959 10 1985 Protocolo de transferencia de archivos Longitud de los datos El nmero de bytes lgicos en los datos de la pgina. La longitud de datos mnima es 0. Tipo de pgina El tipo de pgina se trata. Los siguientes tipos de pgina se definen: 0 = ltima pgina Esto se utiliza para indicar el final de un bloque paginado transmisin estructurada. La longitud de la cabecera debe sea 4, y la longitud de los datos debe ser 0. 1 = Simple Pgina Este es el tipo normal que simples archivos paginados sin ningn nivel de la pgina de control asociado informacin. La longitud de la cabecera debe ser 4. 2 = descriptor de pginas Este tipo se utiliza para transmitir la descriptiva informacin para el archivo como un todo. 3 = acceso controlado pgina Este tipo incluye un campo de encabezado adicional para archivos paginados con la pgina de control de acceso de nivel informacin. La longitud de la cabecera debe ser 5. Campos opcionales Otros campos de cabecera pueden ser utilizados para suministrar por pgina informacin de control, por ejemplo, por acceso de pgina controlar. Todos los campos son un byte lgico de longitud. El byte de lgica
tamao se especifica por el comando TYPE. Vase el Apndice I para ms detalles y un caso especfico en la estructura de la pgina. Una nota de advertencia acerca de los parmetros: un archivo debe almacenarse y recuperado con los mismos parmetros si la versin recuperada es a
RFC 959 10 1985 Protocolo de transferencia de archivos ser idntica a la versin transmitida originalmente. Por el contrario, Implementaciones de FTP deben devolver un archivo idntico al original si los parmetros que se utilizan para almacenar y recuperar un archivo son los mismos. 3.2. ESTABLECER CONEXIONES DE DATOS La mecnica de la transferencia de datos consiste en la creacin de los datos conexin a los puertos correspondientes y la eleccin de los parmetros 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 conexin de control (es decir, U). El valor predeterminado del servidor de procesos puerto de datos es el puerto adyacente al puerto de conexin de control (Es decir, L-1). El tamao en bytes de transferencia es bytes de 8 bits. El tamao en bytes es relevante slo para la transferencia efectiva de los datos, no tiene que ver con la representacin 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 envo de un comando de solicitud de transferencia. El orden de peticin FTP determina la direccin de la transferencia de datos. El servidor, a la recepcin de la solicitud de transferencia, se iniciar la conexin de datos
al puerto. Cuando se establece la conexin, los datos transferencia comienza entre DTP de, y el servidor enva un PIconfirmando respuesta para el usuario-PI. Cada aplicacin FTP debe ser compatible con el uso de los datos por defecto puertos, y slo el user-PI puede iniciar un cambio a la nodefault 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 lnea o se recupera de una tercera anfitrin 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 conexin que el otro iniciar. La user-PI enva 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 Seccin de Respuestas FTP. En general, es responsabilidad del servidor para mantener los datos conexin - para iniciar y para cerrarla. La excepcin a esta
RFC 959 10 1985 Protocolo de transferencia de archivos es cuando el usuario-DTP est enviando los datos en un modo de transferencia que requiere que la conexin se cierra para indicar EOF. El servidor Debe cerrar la conexin de datos en las siguientes condiciones: 1. El servidor ha completado el envo 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 especificacin de puerto se cambia por un comando desde el usuario. 4. La conexin de control est cerrado legalmente o de otro modo.
5. Se produce una condicin de error irrecuperable. De lo contrario el cierre es una opcin de servidor, cuyo ejercicio la servidor debe indicar al proceso de usuario, ya sea un 250 o 226 responder slo. 3.3. GESTIN DE CONEXIN DE DATOS Puertos de conexin de datos por defecto: Todas las implementaciones de FTP debe apoyar el uso de los puertos de conexin de datos por defecto, y slo el Usuario-PI puede iniciar el uso de puertos no predeterminados. Negociacin 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 conexin se define por el par de direcciones, cualquiera de estas acciones es suficiente para obtener una conexin de datos diferente, todava se permite hacer las dos comandos a utilizar nuevos puertos en ambos extremos de los datos conexin. La reutilizacin de la conexin de datos: Cuando se utiliza el modo de flujo de datos transferir el final del archivo debe ser indicado por el cierre de la conexin. Esto causa un problema si hay varios archivos que transferido en la sesin, debido a la necesidad de TCP para mantener la registro de conexin para un perodo de tiempo de espera para garantizar la fiabilidad la comunicacin. Por lo tanto la conexin 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 Postel & Reynolds [Pgina 19]
RFC 959 10 1985 Protocolo de transferencia de archivos
inherentemente poco fiables, ya que no es posible determinar si el conexin cerrada prematuramente o no. Los otros modos de transferencia (Block, comprimido) no cierran la conexin para indicar el final del archivo. Ellos tienen suficiente FTP codificacin que los datos conexin se puede analizar para determinar el final del archivo. Por lo tanto el uso de estos modos se puede dejar la conexin de datos abierta para mltiples transferencias de archivos. 3.4. MODOS DE TRANSMISIN La siguiente consideracin en la transferencia de datos es la eleccin de la modo de transmisin apropiado. Existen tres modos: uno que formatos de los datos y permite procedimientos de reinicio, uno que tambin comprime los datos para la transferencia eficiente, y uno que pasa a los datos con poco o ningn procesamiento. En este ltimo caso, el modo de interacta con el atributo de estructura para determinar el tipo de procesamiento. En el modo comprimido, el tipo de representacin 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 implcitos explcitamente por el cierre de la conexin de datos. Para ficheros con estructura de registro, todos los marcadores de fin de registro (EOR) son explcitos, incluyendo la final. Para los archivos de transmisin en la estructura de la pgina de "ltima pgina" tipo de pgina es utilizado. NOTA: En el resto de esta seccin, byte significa "byte de transferencia" salvo que se indique expresamente lo contrario. Para el propsito de la transferencia estandarizada, el envo de acogida se traducir su extremo interno de la lnea o al final de la denotacin registro en la representacin prescrito por el modo de transferencia y archivo estructura y el host receptor realizar la inversa traduccin a su denotacin interna. Un registro Mainframe IBM campo de recuento no se reconozca en otro host, por lo que el la informacin al final de su registro puede ser transferida como un control de dos bytes cdigo en modo de corriente o como un poco marcado en un bloque o comprimido descriptor de modo. Al final de la lnea 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 idnticos transferencia desestructurada archivos de texto pueden desear utilizar una representacin binaria y corriente modo de la transferencia.
RFC 959 10 1985 Protocolo de transferencia de archivos Los siguientes modos de transmisin se definen en el FTP: 3.4.1. MODO DE CORRIENTE Los datos se transmiten como una secuencia de bytes. No hay restriccin en el tipo de representacin utilizado, estructuras de registro se admiten. En un registro de archivo estructurado EOR y EOF sern cada indicarse por un cdigo de control de dos bytes. El primer byte del cdigo de control sern todos unos, el carcter 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 cdigo de control. Si la estructura es una estructura de archivos, el EOF es indicado por el envo de acogida de cerrar la conexin 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 ms bytes de cabecera. Los bytes de cabecera contienen un recuento campo, y el cdigo 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 cdigo descriptor define: ltimo bloque del archivo (EOF) ltima bloquear en el registro (EOR), marcador de reinicio (vase la seccin sobre Los datos de recuperacin y reiniciar) o sospecha de error (es decir, los datos siendo transferido es sospechoso de errores y no es confiable). Este ltimo cdigo 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 ssmicos o el clima) para enviar y recibir todo los datos a pesar de los errores locales (como "cinta magntica ledo errores "), sino indicar en la transmisin que ciertas porciones son sospechosos). Estructuras de registro estn permitidos en esta modo, y cualquier tipo de representacin se pueden utilizar. La cabecera se informacin de representar byte cuentan, y los cdigos que se compone de los tres bytes. De los 24 bits de la cabecera, los 16 bits de menor orden 8 bits de alto orden representarn descriptor muestran a continuacin.
RFC 959 10 1985 Protocolo de transferencia de archivos Block Header + ---------------- + ---------------- + --------------- + | Descriptor | Cuenta de bytes | | 8 Bits | 16 bits | + ---------------- + ---------------- + --------------- + Los cdigos de descriptor se indican mediante indicadores de bits en el byte de descriptor. Cuatro cdigos se han asignado, en donde cada uno nmero de cdigo es el valor decimal del bit correspondiente en el byte. Cdigo 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 codificacin, ms de un descriptor codificado condicin 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 nmero entero de bytes de 8 bits que representan imprimible caracteres en el idioma que se utilizan en el control de conexin (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 sera enviado: + | | + + | | + + | | + -------Descrptr Cdigo = --------------Marcador 8 bits | --------------Marcador 8 bits | -------+ -------- + -------- + | Recuento de bytes | 16 | = 6 | + -------- + -------- + + | 8 + + | 8 + -------Marcador bits | 8 --------------Marcador bits | 8 -------+ -------- + | Marcador | bits | + -------- + + -------- + | Marcador | bits | + -------- +
RFC 959 10 1985 Protocolo de transferencia de archivos 3.4.3. MODO COMPRIMIDO Hay tres tipos de informacin que se envan: datos regulares, enviado en una cadena de bytes; datos comprimidos, que consiste en repeticiones o de relleno, y la informacin 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 ms a la izquierda bit a 0 y ms a la derecha 7 bits que contiene el nmero 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 vara con la representacin tipo. Si el tipo es ASCII o EBCDIC el byte de relleno es <SP> (Espacio, cdigo ASCII 32, cdigo 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 Postel & Reynolds [Pgina 23]
RFC 959 10 1985 Protocolo de transferencia de archivos byte (todos ceros) y el segundo de los cuales contiene escapar cdigos descriptor como se definen en el modo de bloqueo. El descriptor
los cdigos 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 obtencin de mayor ancho de banda en transmisiones de red de gran tamao a cambio de un suplemento CPU. Se puede utilizar ms eficazmente para reducir el tamao de la impresora archivos, como los generados por los anfitriones RJE. 3.5. RECUPERACIN DE ERROR Y LA REANUDACIN No hay ninguna disposicin para la deteccin de perdidos o revueltos en datos transferencia; este nivel de control de errores el protocolo TCP. Sin embargo, se proporciona un procedimiento de proteger a los usuarios de fallos del sistema brutos (incluidos los fallos un FTP-proceso, o la red subyacente). los bits es manejado por reinicio para de un anfitrin,
El procedimiento de reinicio slo se define para el bloque y se comprime modos de transferencia de datos. Se requiere que el remitente de los datos para insertar un cdigo de marcador especial en el flujo de datos con algn marcador informacin. La informacin de marcadores slo tiene sentido a la emisor, sino que debe contener caracteres imprimibles en el incumplimiento o lenguaje negociado de la conexin de control (ASCII o EBCDIC). El marcador podra representar un poco de recuento, un registro de conteo, o cualquier otra informacin 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 posicin correspondiente de este marcador en el sistema de recepcin y devolver esta informacin a la usuario. En el caso de un fallo del sistema, el usuario puede reiniciar los datos transferencia mediante la identificacin 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 anfitrin de la recepcin marca la datos correspondientes sealan en su sistema de archivos y transmite el ltimo
remitente conocido y la informacin de marcador de receptor para el usuario, ya sea directamente o a travs de la conexin de control en una respuesta 110 (dependiendo de quin 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 envo de un comando de reinicio con el cdigo del marcador del servidor como su argumento. El comando restart es transmitida por el control
RFC 959 10 1985 Protocolo de transferencia de archivos conexin 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 comunicacin desde el usuario-PI al servidor-PI es establecido como una conexin TCP desde el usuario hasta el servidor estndar puerto. El intrprete de protocolo de usuario es responsable del envo de FTP comandos e interpretar las respuestas recibidas, el servidor-PI interpreta los comandos, enva respuestas y dirige su DTP para establecer el conexin 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 mquina 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 seccin. En la descripcin de algunos de los comandos en esta seccin, es til ser explcito 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 (Cdigos de comando se muestran entre parntesis). NOMBRE DE USUARIO (USER)
El campo argumento es una cadena Telnet que identifica al usuario. La identificacin 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 despus de las conexiones de control se hacen (algunos servidores pueden requerir este). Informacin adicional de identificacin en la forma de a un comando de contrasea de la cuenta y / o pueden tambin 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 informacin contable. Esto tiene el efecto de enrojecimiento cualquier informacin del usuario, la contrasea y cuenta ya suministrado e iniciar la secuencia de inicio de sesin de nuevo. Todo parmetros de transferencia son sin cambios y cualquier transferencia de archivos en se ha completado el progreso bajo el control de acceso de edad parmetros.
RFC 959 10 1985 Protocolo de transferencia de archivos CONTRASEA (PASS) El campo argumento es una cadena Telnet que especifica el usuario de contrasea. Este comando debe ir precedido inmediatamente por el comando de nombre de usuario y, para algunos sitios, completa del usuario identificacin para el control de acceso. Desde contrasea informacin 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 informacin de contrasea y minsculas. 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 de inicio de sesin y otros slo para almacenamiento de archivos. el ltimo caso, momento. el Automatizacin: cuando se requiere informacin de la cuenta de inicio de sesin, la respuesta a un comando exitosa contrasea es cdigo de respuesta 332. Por otro lado, si la informacin de cuenta no es requerido para inicio de sesin, la respuesta a una contrasea con xito comando es 230, y si se necesita la informacin de cuenta para una orden emitida posteriormente en el dilogo, el servidor debe devolver una respuesta 332 o 532 dependiendo de si se almacena (En espera de la recepcin 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 recuperacin sin alterando su usuario o informacin contable. Transferir parmetros 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 crnica, y se incluye para simplificar la implementacin de programas para la transferencia de rboles de directorios entre sistemas operativos tienen diferentes algunos sitios puede requerir una cuenta el acceso especfico, como por ejemplo el En el comando puede llegar en cualquier
Hay cdigos de respuesta para diferenciar estos casos para
RFC 959 10 1985 Protocolo de transferencia de archivos sintaxis para nombrar el directorio padre. Los cdigos de respuesta
sern idnticos a los cdigos de respuesta de CWD. Ver Apndice II para ms detalles. ESTRUCTURA DE MONTAJE (SMNT) Este comando permite al usuario montar un archivo diferente estructura de datos del sistema sin alterar su usuario o informacin contable. Parmetros 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 informacin, salvo para permitir que cualquier transferencia en curso de ser completado. Todos los parmetros se restablecen a los valores predeterminados y la conexin de control se deja abierta. Esto es idntico al estado en el que un usuario se encuentra inmediatamente despus de se abre la conexin 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 conexin de control. Si transferencia de archivos en curso, la conexin permanecer abierto a la respuesta de resultado y el servidor se cirrelo. 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 conexin de control har que el servidor para llevar la accin efectiva de un aborto (ABOR) y un Desconexin (QUIT). 4.1.2. TRANSFERENCIA COMANDOS PARMETROS Todos los parmetros de transferencia de datos tienen valores por defecto, y la comandos que especifican los parmetros de transferencia de datos slo son necesarios si los valores de los parmetros 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 estndar 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 parmetros de transferencia de datos: Postel & Reynolds [Pgina 27]
RFC 959 10 1985 Protocolo de transferencia de archivos DATOS (puerto) El argumento es una especificacin HOST-puerto para el puerto de datos para ser utilizado en la conexin 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 concatenacin de un Direccin de Internet de 32 bits y una direccin de puerto TCP 16 bits. Esta informacin de la direccin se divide en campos de 8 bits y el valor de cada campo se transmite como un nmero decimal (en representacin de cadena de caracteres). Los campos estn separados por comas. Un comando de puerto sera: PUERTO h1, h2, h3, h4, p1, p2 donde h1 es los 8 bits de alto orden del host de Internet Direccin. 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 conexin en lugar de iniciar una tras la recepcin de un comando de transferencia. La respuesta a este comando incluye la host y la direccin del puerto este servidor est escuchando. Representacin Tipo (TYPE)
El argumento especifica el tipo de representacin como se describe en la seccin sobre representacin de datos y almacenamiento. Varios tipos toman un segundo parmetro. El primer parmetro es denota por un nico carcter Telnet, como es el segundo Parmetro Formato para ASCII y EBCDIC, y el segundo parmetro de byte local es un entero decimal para indicar ByteSize. Los parmetros estn separados por una <SP> (espacio, cdigo ASCII 32). Los siguientes cdigos 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 tamao Byte byte Postel & Reynolds [Pgina 28]
RFC 959 10 1985 Protocolo de transferencia de archivos El tipo de representacin predeterminado es ASCII no impresos. Si el Se cambia el parmetro formato, y ms tarde slo el primer se cambia el argumento, formato y luego regresa a la noprint predeterminado. Estructura de archivos (STRU) El argumento es un cdigo de caracteres Telnet especificando estructura de archivos se describe en la Seccin de Datos Representacin y almacenamiento. Los siguientes cdigos se asignan a la estructura: F - Archivo (sin estructura de registro) R - Estructura de los registros P - Estructura de la pgina La estructura por defecto del archivo es. MODO DE TRANSFERENCIA (MODE) El argumento es un cdigo de caracteres Telnet especificando los modos de transferencia de datos que se describen en la seccin sobre
Modos de transmisin. Los siguientes cdigos 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 funcin 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 estndar aplicables) y las convenciones lingsticas de la conexin de control. El control predeterminado que se sugiere es utilizar el ltimo dispositivo, el directorio o nombre de archivo especificado, o el estndar 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 interrupcin del servicio (por ejemplo, STOR o RETR). Los datos, cuando se transfieren en respuesta al servicio FTP Postel & Reynolds [Pgina 29]
RFC 959 10 1985 Protocolo de transferencia de archivos comandos, siempre se envan a travs de la conexin 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 conexin de datos. La situacin y contenido del archivo en el sitio del servidor no se vern afectadas.
TIENDA (STOR) Este comando hace que el servidor-DTP para aceptar los datos transferido a travs de la conexin 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 continuacin, su contenido deber se sustituyen por los datos que estn 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 travs de la conexin 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 sern 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 nmero de bytes (utilizando el byte lgico tamao) de almacenamiento a ser reservado para el archivo. Para los archivos enviado con la estructura de registro o en la pgina de registro o pgina como mximo Tambin podra ser necesario tamao (en bytes lgicos); esto es indicado por un nmero entero decimal en un segundo campo de argumento Postel & Reynolds [Pgina 30]
RFC 959 10 1985 Protocolo de transferencia de archivos 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 operacin) por los servidores que no requieren que el tamao mximo del archivo sea declaran de antemano, y los servidores interesados en slo el registro mximo o tamao de pgina 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 interrupcin puede requerir "accin especial", como se explica en la Seccin de comandos FTP, para forzar el reconocimiento de la servidor. Ninguna accin debe tomarse si el comando anterior se ha completado (incluyendo la transferencia de datos). El control
conexin no debe ser cerrada por el servidor, pero los datos conexin debe estar cerrada. Existen dos casos para el servidor tras la recepcin de esta comando: (1) la orden de servicio FTP ya se termin, o (2) la orden de servicio FTP est todava en curso.
RFC 959 10 1985 Protocolo de transferencia de archivos En el primer caso, el servidor cierra la conexin de datos (Si est abierta) y responde con una respuesta 226, lo que indica que la orden de interrupcin se ha procesado correctamente. En el segundo caso, el servidor cancela el servicio FTP en progreso y se cierra la conexin de datos, devolviendo un 426 responder a indicar que la solicitud de servicio termina anormalmente. El servidor enva 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 proteccin 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). Vase el Apndice 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). Vase el Apndice II. Print working directory (PWD) Este comando hace que el nombre del trabajo actual directorio para ser devuelto en la respuesta. Vase el Apndice II. LIST (LISTA) Este comando hace que la lista que se enva 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 informacin actual sobre el archivo. Un argumento nulo implica trabajo o actual del usuario directorio predeterminado. La transferencia de datos es a travs de los datos conexin de tipo ASCII o EBCDIC de tipo. (El usuario debe Postel & Reynolds [Pgina 32]
RFC 959 10 1985 Protocolo de transferencia de archivos asegrese de que el tipo es apropiado ASCII o EBCDIC). Dado que la informacin en un archivo puede variar ampliamente de un sistema de al sistema, esta informacin puede ser difcil de usar de forma automtica 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 especfico 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 informacin. Los datos se transfieren en ASCII o Tipo EBCDIC travs de la conexin de datos como nombre de ruta vlido cuerdas separadas por <CRLF> o <NL>. (Una vez que el usuario debe asegrese de que el tipo es correcto). Este comando tiene la intencin
para devolver informacin que puede ser utilizado por un programa para procesar an ms los archivos de forma automtica. Por ejemplo, en la aplicacin de un "mltiple conseguir" funcin. PARMETROS DEL SITIO (SITE) Este comando es utilizado por el servidor para proporcionar servicios especfico 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 especificacin de su sintaxis se har constar en respuesta a el comando SITE HELP. SISTEMA (SYST) Este comando se utiliza para determinar el tipo de operacin sistema en el servidor. La respuesta tendr por primera palabra uno de los nombres del sistema que figuran en la versin actual del documento Nmeros Asignados [4]. STATUS (STAT) Este comando har que una respuesta de estado se envan a travs de la conexin de control en la forma de una respuesta. El comando pueden ser enviados durante una transferencia de archivos (junto con el IP Telnet y seales Synch - vase la seccin sobre comandos FTP) en el que caso de que el servidor responder con el estado de la operacin en curso, o puede ser enviado entre el archivo transferencias. En este ltimo caso, el comando puede tener un campo de discusin. Si el argumento es un nombre de ruta, el comando es anloga a la orden de "lista", excepto que los datos sern Postel & Reynolds [Pgina 33]
RFC 959 10 1985 Protocolo de transferencia de archivos transferidos a travs de la conexin 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 especificacin. Si no se da ningn argumento, el servidor debe devolver en general informacin de estado acerca del proceso del servidor FTP. Este debe incluir los valores actuales de todos los parmetros de transferencia y el estado de las conexiones. HELP (AYUDA) Este comando har que el servidor enve til informacin sobre su estado de aplicacin en el El control de conexin al usuario. El comando puede tardar un argumento (por ejemplo, un nombre de comando) y volver ms especfica informacin 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 Parmetros dependientes del sitio, por ejemplo, en respuesta a la ayuda del sitio. NOOP (NOOP) Este comando no afecta a los parmetros o previamente entrado comandos. En l se especifica ninguna accin aparte de que el servidor enve una respuesta Aceptar. El Protocolo de transferencia de archivos se ajusta a las especificaciones del Telnet protocolo para todas las comunicaciones a travs de la conexin de control. Desde el lenguaje utilizado para la comunicacin Telnet puede ser una solucin negociada opcin, todas las referencias en las dos secciones siguientes se destinen a la "Lenguaje Telnet" y el correspondiente "cdigo de fin de lnea Telnet". En la actualidad, se puede tomar esto en el sentido de NVT-ASCII y <CRLF>. Ningn otro especificaciones del protocolo Telnet se citarn. Comandos FTP son cadenas "Telnet" terminadas por el "fin de Telnet lnea de cdigo. "Los propios cdigos de comando son los caracteres alfabticos terminado por el <SP> carcter (espacio) Si los parmetros siguen y Telnet-EOL lo contrario. Los cdigos de comando y la semntica de comandos se describen en esta seccin, la sintaxis detallada de comandos se especifica en la seccin relativa a los comandos, las secuencias de respuesta se discuten en la Seccin de secuenciacin de comandos y respuestas, y escenarios que ilustran el uso de comandos se proporcionan en el Seccin sobre escenarios de FTP tpicas.
Comandos FTP se pueden dividir como las que especifican de control de acceso identificadores, los parmetros de transferencia de datos, o solicitudes de servicio FTP. Ciertos comandos (como ABOR, STAT, QUIT) pueden ser enviados a travs del conexin de control, mientras que una transferencia de datos est en curso. Algunos Postel & Reynolds [Pgina 34]
RFC 959 10 1985 Protocolo de transferencia de archivos servidores pueden no ser capaces de controlar las conexiones de control y de datos al mismo tiempo, en cuyo caso ser necesario algn tipo de accin especial para conseguir la atencin del servidor. El formato siguiente es ordenado tentativamente recomienda: 1. Sistema inserta usuario del Telnet "Alarma de proceso" (IP) de seal en la corriente de Telnet. 2. Sistema del usuario enva la seal de Telnet "sincronizacin". 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 debera tener ningn efecto inusual.) 4.2. RESPUESTAS FTP Respuestas a los comandos del protocolo de transferencia de archivos estn concebidos para garantizar la sincronizacin 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 ms de uno, en el segundo caso, las mltiples respuestas deben distinguirse fcilmente. Adems, 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 repeticin de toda la secuencia desde el principio. Los detalles de la secuencia de comandos de respuesta se hacen explcitas en un conjunto de diagramas de estado a continuacin. Una respuesta FTP consiste en un nmero de tres dgitos (transmitida como tres caracteres alfanumricos) seguido de un texto. El nmero est destinado a ser utilizado por los autmatas para determinar en qu estado para entrar siguiente, el texto est destinado para el usuario humano. Se pretende que los tres dgitos contienen suficiente informacin codificada que el fcil de proceso (el usuario-PI), no tendr que examinar el texto y puede o bien descartarlo o pasarlo al usuario, segn el caso. En particular, el texto puede ser dependiente del servidor, por lo que hay probabilidades de ser diferentes textos para cada cdigo de respuesta. La respuesta est definido para contener el cdigo de 3 dgitos, seguido de espacio Postel & Reynolds [Pgina 35]
RFC 959 10 1985 Protocolo de transferencia de archivos <SP>, Seguido de una lnea de texto (donde algunos longitud mxima de lnea se ha especificado), y termin a finales de lnea Telnet cdigo. Habr casos, sin embargo, que el texto es ms largo que una sola lnea. En estos casos, el texto completo debe ir precedida por lo que el proceso de Usuario sabe cundo puede dejar de leer la respuesta (es decir, detener el procesamiento de entrada en la conexin de control) y ir a hacer otra cosas. Esto requiere un formato especial en la primera lnea de indican que ms de una lnea que viene, y otro en el ltima lnea para designarlo como el ltimo. Al menos uno de ellos debe contener el cdigo de respuesta apropiado para indicar el estado de la transaccin. Para satisfacer todas las facciones, se decidi que tanto el primer y ltimo cdigos de lnea deben ser el mismo. Por lo tanto el formato de respuestas mltiples lneas es que la primera lnea comenzar con el cdigo de respuesta exacta requerida, seguida
inmediatamente por un guin, "-" (tambin conocido como Minus), seguido por texto. La ltima lnea se iniciar con el mismo cdigo, seguido inmediatamente por <SP> espacio, algo de texto opcional y el Telnet cdigo de fin de lnea. Por ejemplo: 123-Primera lnea Segunda lnea 234 Una lnea que comienza con los nmeros 123 La ltima lnea El proceso de usuario a continuacin, simplemente tiene que buscar la segunda ocurrencia del mismo cdigo de respuesta, seguida de <SP> (espacio), en el comienzo de una lnea, y no hacer caso todas las lneas intermedias. Si una lnea intermedia comienza con un nmero de 3 dgitos, el servidor debe rellenar la parte delantera para evitar confusiones. Este esquema permite a las rutinas estndar del sistema para ser usado para los informacin de respuesta (tales como para la respuesta STAT), con "Artificial" primera y la ltima lnea insertan en. En casos poco frecuentes donde estas rutinas son capaces de generar tres dgitos y un Espacio al principio de cualquier lnea, al principio de cada lnea de texto debe ser compensado por un texto neutral, como el espacio. Este esquema asume que las respuestas de varias lneas no pueden anidarse. Los tres dgitos 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 dgito indica si la respuesta es buena, mala o incompleta. (Refirindose al diagrama de estado), un proceso de usuario poco sofisticado ser capaz de determinar su siguiente accin (proceder segn lo previsto, Postel & Reynolds [Pgina 36]
rehacer, retrench, etc) con slo examinar este primer dgito. La fcil 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 dgito, reservando el tercer dgito de la mejor gradacin de la informacin (por ejemplo, el comando RNTO sin precedente RNFR). Hay cinco valores para el primer dgito del cdigo de respuesta: 1yz positiva respuesta preliminar Se ha iniciado la accin solicitada, se espera otro responder antes de proceder a un nuevo comando. (La el usuario proceso de envo antes de que el otro comando respuesta conclusin estara en violacin 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 atencin a las conexiones de datos, para las implementaciones en donde monitorizacin simultnea es difcil. El servidor FTP proceso puede enviar como mximo, una 1yz respuesta al comando. 2yz respuesta positiva de Terminacin La accin solicitada se ha completado con xito. La nueva peticin puede ser iniciada. 3yz respuesta positiva Intermedio El comando ha sido aceptado, pero la accin solicitada se est en suspenso, a la espera de recibir ms informacin. El usuario debe enviar otro comando especificar esta informacin. Esta respuesta se utiliza en grupos de secuencias de comandos. 4yz Transitoria respuesta negativa de Terminacin El comando no fue aceptado y la accin solicitada hizo no se llevar a cabo, pero la condicin 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 difcil asignar un significado a "transitorio", particularmente cuando dos sitios distintos (Servidor-y
-Los procesos de usuario) tienen que ponerse de acuerdo sobre la interpretacin. Cada respuesta en la categora 4yz podra tener un poco diferente valor en el tiempo, pero la intencin es que el Postel & Reynolds [Pgina 37]
RFC 959 10 1985 Protocolo de transferencia de archivos se recomienda al usuario-proceso para volver a intentarlo. Una regla de oro en la determinacin de si una respuesta encaja en el 4yz o la 5yz (Permanent Negative) categora es que las respuestas son 4yz si los comandos se pueden repetir sin ningn 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 aplicacin.) 5yz Permanente respuesta negativa de Terminacin El comando no fue aceptado y la accin 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 accin directa en algn momento en el futuro (por ejemplo, despus de la ortografa ha sido cambiado, o si el usuario ha cambiado su estado de directorio.) Los siguientes grupos de funcin estn codificados en el segundo dgitos: x0z Sintaxis - Estas respuestas se refieren a los errores de sintaxis, comandos sintcticamente correctos que no encajan en ninguna categora funcional, sin aplicarse o superfluos comandos.
x1z informacin - Estas son las respuestas a las solicitudes de informacin, tal como el estado o ayuda. Conexiones x2z - respuestas se hace referencia al control y conexiones de datos. x3z autenticacin y contabilidad - Respuestas para el inicio de sesin 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 accin del sistema de archivos. El tercer dgito da una gradacin ms fina de significado en cada uno de las categoras de funciones, especificadas por el segundo dgito. La lista de respuestas inferiores a ilustrar esto. Tenga en cuenta que el texto Postel & Reynolds [Pgina 38]
RFC 959 10 1985 Protocolo de transferencia de archivos 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 cdigos de respuesta, por otra parte, deben seguir estrictamente las especificaciones en la seccin anterior; es decir, las implementaciones del servidor no deberan inventar nuevos cdigos para situaciones que son slo ligeramente diferentes de los se describe aqu, sino que debe adaptarse cdigos ya definidos. Un comando como el tipo o ALLO cuya ejecucin exitosa no ofrece el proceso del usuario toda la informacin 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 informtico, por ejemplo ALLO en un sitio TOPS20, una respuesta positiva de Terminacin todava
deseada para que el simple proceso de usuario sabe que puede proceder con su curso de accin. Una respuesta 202 se utiliza en este caso con, por ejemplo, el texto de la respuesta: "No la asignacin de almacenamiento necesario. "Si, por el contrario, el comando solicita una la accin no especfica 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 parmetro. 4.2.1 Cdigos de respuesta por grupos de funcin 200 Comando bien. 500 Error de sintaxis, comando no reconocido. Esto puede incluir errores como lnea de comandos demasiado larga. 501 Error de sintaxis en los parmetros o argumentos. 202 Comando no implementado, superflua en este sitio. 502 Comando no implementado. 503 Secuencia de comandos. 504 Comando no implementado para ese parmetro.
RFC 959 10 1985 Protocolo de transferencia de archivos 110 Reinicie respuesta marcador. En este caso, el texto es exacta y no deja a la particular, la aplicacin, 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 estndar. Esta respuesta es til slo para la usuario humano. 215 NOMBRE tipo de sistema. Donde nombre es el nombre de un sistema oficial de la lista en el Nmeros Asignados documento. 120 Servicio listo en minutos nnn. 220 Servicio preparado para nuevo usuario. 221 conexin de control de cierre de servicio. Conectados a su caso. 421 Servicio no disponible, conexin de control de cierre. Esto puede ser una respuesta a cualquier comando si el servicio sabe que debe cerrar. 125 conexin de datos ya abierto, la transferencia de partida. 225 conexin de datos abierta, sin transferencia en curso. 425 No se puede abrir la conexin de datos. 226 conexin de datos de cierre. Pidi el archivo de accin con xito (por ejemplo, un archivo transferencia o archivo abortar). 426 Conexin cerrada; transferir abortado. 227 Entering Passive Mode (h1, h2, h3, h4, p1, p2). 230 530 331 332 532 Usuario conectado, proceda. No conectado Nombre de usuario de acuerdo, se necesita contrasea. Necesita cuenta para iniciar sesin. Necesita cuenta para almacenar archivos.
RFC 959 10 1985 Protocolo de transferencia de archivos 150 Estado del archivo bien; a punto de abrir la conexin de datos. 250 257 350 informacin. 450 accin de archivo solicitada bien, complet. "ruta" creado. accin de archivo solicitada en espera de ms Pidi el archivo de accin no se toma.
El archivo no est disponible (por ejemplo, archivos ocupado). No se toma 550 La accin solicitada. El archivo no est disponible (por ejemplo, archivo no encontrado, sin acceso). 451 Accin interrumpida. Error local en el procesamiento. 551 Accin interrumpida. Pgina tipo desconocido. No se toma 452 La accin solicitada. Espacio de almacenamiento insuficiente en el sistema. 552 accin de archivo solicitada abortada. Asignacin de almacenamiento superado (para el directorio actual o conjunto de datos). No se toma 553 La accin solicitada. Nombre de archivo no permitido. 4.2.2 Orden numrico Lista de cdigos de respuesta 110 Reinicie respuesta marcador. En este caso, el texto es exacta y no deja a la particular, la aplicacin, 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 conexin de datos ya abierto, la transferencia de partida. 150 Estado del archivo bien; a punto de abrir la conexin de datos.
RFC 959 10 1985 Protocolo de transferencia de archivos 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 estndar. Esta respuesta es til slo para la usuario humano. 215 NOMBRE tipo de sistema. Donde nombre es el nombre de un sistema oficial de la lista en el Nmeros Asignados documento. 220 Servicio preparado para nuevo usuario. 221 conexin de control de cierre de servicio. Conectados a su caso. 225 conexin de datos abierta, sin transferencia en curso. 226 conexin de datos de cierre. Pidi el archivo de accin 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 accin de archivo solicitada bien, complet. 257 "ruta" creado. 331 Nombre de usuario de acuerdo, se necesita contrasea. 332 Necesita cuenta para iniciar sesin. 350 accin de archivo solicitada en espera de ms informacin. 421 Servicio no disponible, conexin 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 conexin de datos. 426 Conexin cerrada; transferir abortado. 450 Pidi el archivo de accin no se toma. El archivo no est disponible (por ejemplo, archivos ocupado). 451 Pidi accin abortada: error local en el procesamiento. No se toma 452 La accin solicitada. Espacio de almacenamiento insuficiente en el sistema.
500 Error de sintaxis, comando no reconocido. Esto puede incluir errores como lnea de comandos demasiado larga. 501 Error de sintaxis en los parmetros o argumentos. 502 Comando no implementado. 503 Secuencia de comandos. 504 Comando no implementado para ese parmetro. 530 No conectado 532 Necesita cuenta para almacenar archivos. No se toma 550 La accin solicitada. El archivo no est disponible (por ejemplo, archivo no encontrado, sin acceso). 551 Pidi accin abortada: pgina de tipo desconocido. 552 accin de archivo solicitada abortada. Asignacin de almacenamiento superado (para el directorio actual o conjunto de datos). No se toma 553 La accin solicitada. Nombre de archivo no permitido. 5. ESPECIFICACIONES declarativa 5.1. APLICACIN MNIMO Con el fin de hacer FTP viable sin mensajes de error innecesarias, la se requiere despus de la implementacin mnima para todos los servidores: TYPE - No impresin 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 parmetros de transferencia son: TYPE - No impresin ASCII MODE - Corriente STRU - Archivo Todos los hosts deben aceptar lo anterior como los valores predeterminados estndar.
RFC 959 10 1985
Protocolo de transferencia de archivos 5.2. CONEXIONES El intrprete de protocolo del servidor debe "escuchar" en el puerto L. La usuario o intrprete de protocolo de usuario iniciarn el fullduplex controlar la conexin. 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 obligacin de velar por la edicin de lneas de comandos y puede requerir que se haga en el husped usuario. La conexin de control ser cerrada por el servidor a peticin del usuario despus 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 conexin de datos de su propio incumplimiento puerto de datos (L-1) a travs del puerto de datos de usuario especificado. La direccin de la transferencia y el puerto utilizado ser determinado por el FTP comando de servicio. Tenga en cuenta que toda la aplicacin FTP debe ser compatible con la transferencia de datos utilizando el puerto por defecto, y que slo 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 enva un PASV comando le dice a "escuchar" en su puerto de datos en lugar de iniciar una conexin 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 enva 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 conexin y los ingresos de transferencia. La secuencia de comandos de respuesta est en la lista por debajo de donde los mensajes son verticalmente sincrnica pero horizontal asincrnica:
RFC 959 10 1985 Protocolo de transferencia de archivos 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 conexin de datos se cierra por el servidor bajo el condiciones que se describen en la seccin sobre el establecimiento de datos Conexiones. Si la conexin de datos se va a cerrar despus de un la transferencia de datos, donde el cierre de la conexin no est obligado a indicar el final del archivo, el servidor debe hacerlo de inmediato. Esperar hasta despus de que no se permite una nueva orden de transferencia debido a que el proceso de usuario ya habr comprobado los datos conexin 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 condicin de carrera aqu, el servidor enva una respuesta (226) despus de cerrar la conexin de datos (o si el conexin se deja abierta, una "transferencia completa" respuesta (250) y el usuario-PI debe esperar a que una de estas respuestas antes la emisin de una nueva orden de transferencia). En cualquier momento el usuario o servidor de ver que la conexin est
est cerrada por el otro lado, hay que leer rpidamente cualquier datos que quedan en la cola de la conexin y emitir el cierre de su propio bando. 5.3. COMANDOS Los comandos son cadenas de caracteres Telnet transmitidos a travs de la Conexiones de control como se describe en la Seccin de comandos FTP. Las funciones de comando y la semntica se describen en la Seccin de comandos de control del acceso, la transferencia Comandos de parmetros, FTP Comandos de servicio y Comandos Miscelneos. La sintaxis del comando se especifica aqu. Los comandos comienzan con un cdigo de comando seguido de un argumento campo. Los cdigos de comando son cuatro o menos caracteres alfabticos. Caracteres alfabticos superior e inferior de casos deben ser tratados idnticamente. Por lo tanto, cualquiera de los siguientes puede representar la recuperacin de comandos: Postel & Reynolds [Pgina 45]
RFC 959 10 1985 Protocolo de transferencia de archivos RETR Retr retr retr retr Esto tambin se aplica a los smbolos que representan los valores de los parmetros, tales como A o una de TIPO ASCII. Los cdigos de comando y el argumento campos estn separados por uno o ms espacios. El campo argumento consiste en una cadena de caracteres de longitud variable terminando con la secuencia de caracteres <CRLF> (retorno de carro, Lnea Alimentar) para la representacin NVT-ASCII, para otros idiomas negociados un final diferente carcter de lnea puede ser utilizado. Debe ser seal que el servidor es no tomar ninguna accin hasta el final de la lnea se recibe un cdigo. La sintaxis se especifica a continuacin 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 discusin. Si la opcin no se toma, la adecuada por defecto est implcito.
RFC 959 10 1985 Protocolo de transferencia de archivos 5.3.1. Comandos FTP Los siguientes son los comandos FTP: USUARIO <SP> <username> <CRLF> PASS <SP> <contrasea> <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 STOR STOU APPE ALLO
<SP> <rutaDeAcceso> <CRLF> <SP> <rutaDeAcceso> <CRLF> <CRLF> <SP> <rutaDeAcceso> <CRLF> <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>
RFC 959 10 1985 Protocolo de transferencia de archivos 5.3.2. Argumentos del comando FTP La sintaxis de los campos de argumento arriba (usando la notacin BNF en su caso) es: <username> :: = <cadena> <contrasea> :: = <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 Cdigo ASCII 33 a 126 <byte-size> :: = <nmero> <host-port> :: = <host-number>, <nmero-puerto> <host-number> :: = <nmero>, <nmero>, <nmero>, <nmero> <nmero-puerto> :: = <nmero>, <nmero>
<nmero> :: = cualquier nmero 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
RFC 959 10 1985 Protocolo de transferencia de archivos 5.4. SECUENCIA DE COMANDOS Y RESPUESTAS La comunicacin entre el usuario y el servidor est destinado a ser una dilogo 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 ms comandos. Algunos comandos requieren una segunda respuesta para que el usuario debe Tambin espera. Estas respuestas pueden ser, por ejemplo, el informe sobre los progresos o la finalizacin de la transferencia de archivos o el cierre de los datos conexin. Son respuestas secundarias para presentar comandos de transferencia. Un grupo importante de respuestas informativas es la conexin saludos. En circunstancias normales, el servidor enviar un 220
responder, "en espera de entrada", cuando se completa la conexin. 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 espontneas A veces "el sistema" espontneamente 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 disposicin en el FTP para tal espontnea de informacin que se enva desde el servidor al usuario. Se recomienda que dicha informacin 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-lnea). La siguiente tabla muestra el xito alternativas y respuestas de emergencia durante cada comando. Estos deben cumplirse estrictamente, un servidor puede Sustityase el texto en las respuestas, pero el significado y la accin implcita por los nmeros de cdigo y por la secuencia especfica de la contestacin de comandos no puede ser alterado. Secuencias de comandos Responder En esta seccin, 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 sangra y debajo de ellos), entonces finalizacin positivo y negativo, y, por ltimo intermediario
RFC 959 10 1985 Protocolo de transferencia de archivos respuestas con el resto de los comandos de la secuencia de siguiente. Este listado constituye la base para el estado
diagramas, los cuales sern presentados por separado. Establecimiento 120 220 220 421 Login USUARIO 230 530 500, 501, 331, 332 PASS 230 202 530 500, 501, 332 ACCT 230 202 530 500, 501, CWD 250 500, 501, CDUP 200 500, 501, SMNT 202, 250 500, 501, Salir REIN 120 220 220 421 500, 502 SALIR 221 500 de conexin
421
503, 421
503, 421 502, 421, 530, 550 502, 421, 530, 550 502, 421, 530, 550
RFC 959 10 1985 Protocolo de transferencia de archivos Parmetros 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 accin 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
RFC 959 10 1985 Protocolo de transferencia de archivos 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
RFC 959 10 1985 Protocolo de transferencia de archivos 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
RFC 959 10 1985 Protocolo de transferencia de archivos 6. Diagramas de estado Aqu presentamos los diagramas de estado de una manera muy sencilla FTP mente aplicacin. Slo se utiliza el primer dgito de los cdigos 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 construccin de un modelo para cada comando a continuacin, recogida de los comandos junto con estructuralmente modelos idnticos. 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 smbolo B para "comenzar", y el smbolo 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.
RFC 959 10 1985 Protocolo de transferencia de archivos 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 tambin podra 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 ms 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 | + --- + + --- + + --- +
RFC 959 10 1985 Protocolo de transferencia de archivos 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 slo 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.
RFC 959 10 1985 Protocolo de transferencia de archivos El esquema ms 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 | + --- + + --- + -------------> + --- +
RFC 959 10 1985 Protocolo de transferencia de archivos Por ltimo, se presenta un diagrama generalizado que podra ser utilizado para modelar el comando y la respuesta de intercambio: -----------------------------------| | Empiece | | | V | | + --- + Cmd + --- + 2 + --- + | -> | | -------> | | ----------> | | | | | | W | | S | ----- | -> | | -> | | ----- | | | | + --- + | + --- + 4,5 | + --- + | | | | | | | | | | | 1 | | 3 | + --- + | | | | | | | | | | | | ---- | ----> | F | ----| | | | |
| | | + --- + ------------------| | V Final
RFC 959 10 1985 Protocolo de transferencia de archivos 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 travs de un mediador proceso de usuario-FTP. El siguiente puede ser un caso tpico. La el usuario FTP solicita se muestran entre parntesis, "---->" representa comandos del host U para alojar S, y "<----" representa las respuestas de los S anfitrin para acoger U. COMANDOS DE LOCALES DE ACCIN 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 Prez <CR> USUARIO Prez <CRLF> ---->
<---- 331 Nombre de usuario correcto, necesitar <CRLF> contrasea. contrasea 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> conexin. Servidor permite la conexin de datos al puerto de U. <---- 226 conexin de datos de cierre, transferencia de archivos <CRLF> xito. Tipo de imagen <CR> TIPO I <CRLF> ----> <---- 200 Comando Aceptar <CRLF> almacn (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 conexin La conexin de control FTP se establece a travs de TCP entre el usuario proceso de conexin U y el puerto L. proceso del servidor Este protocolo es asignada al puerto de servicio 21 (25 octal), que es L = 21.
RFC 959 10 1985 Protocolo de transferencia de archivos ANEXO I - ESTRUCTURA DE PGINA La necesidad de FTP para apoyar la estructura de la pgina se deriva principalmente de la necesidad de apoyar la transmisin 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 pginas. La sistema operativo es ms eficaz en la manipulacin de archivos como pginas. 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 pgina directamente, y algunos de estos archivos create holey. Un archivo de TOPS-20 de disco consiste en cuatro cosas: una ruta, una pgina tabla, un conjunto (posiblemente vaco) de pginas, 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 extensin de nombre de archivo, y la generacin de nmero. La tabla de la pgina contiene hasta 2 ** 18 entradas. Cada entrada puede tener VACO, o puede apuntar a una pgina. Si no est vaco, hay tambin algunos bits de acceso especficos de la pgina, no todas las pginas de un archivo necesita tener el misma proteccin de acceso. Una pgina es un conjunto contiguo de 5 12 palabras de 36 bits cada uno. Los atributos del archivo, en el Bloque de Descripcin del Archivo (FDB), contener cosas tales como la hora de creacin, escriba el tiempo, el tiempo de lectura, escritor puntero de bytes de tamao, al final de su archivo, conde de lecturas y escrituras, copia de seguridad nmeros de cinta del sistema, etc Tenga en cuenta que no hay ningn requisito de que las entradas de la tabla de pginas sean contigua. Puede haber espacios vacos entre la tabla de pginas ocupadas queridos. Adems, el extremo de puntero de archivo es simplemente un nmero. 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 despus del ltimo dato escrito, pero otras operaciones puede hacer que no sea as, si un sistema de programacin 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.
RFC 959 10 1985 Protocolo de transferencia de archivos Los TOPS-20 ficheros paginados se pueden enviar con los parmetros de transferencia FTP: TIPO L 36, STRU P, S y MODE (de hecho, cualquier modo podra ser utilizado). Cada pgina de la informacin tiene una cabecera. Cada campo de encabezado, que es una byte lgico, 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: Pgina ndice. Si los datos es una pgina de archivo de disco, esto es el nmero de esa pgina en pgina mapa del archivo. Pginas vacos (huecos) en el archivo simplemente no son enviados. Tenga en cuenta que un agujero no es lo mismo que un Pgina de ceros. Palabra 2: Longitud de los datos. El nmero de palabras de datos en esta pgina, despus de la cabecera. Por lo tanto, la longitud total de la unidad de transmisin es la Cabecera Longitud ms la longitud de datos. Palabra 3: Tipo de pgina. Un cdigo para el tipo de fragmento que es esto. Una pgina de datos es de tipo 3, la pgina FDB es tipo 2. Palabra 4: Pgina de control de acceso. Los bits de acceso asociadas a la pgina 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.) Despus de la cabecera son las palabras de datos de datos de longitud. Longitud de los datos es
Actualmente ya sea 512 para una pgina de datos o 31 para una FDB. Trailing ceros en una pgina de archivo de disco pueden ser descartados, por lo menos datos Longitud a 512 en ese caso.
RFC 959 10 1985 Protocolo de transferencia de archivos ANEXO II - COMANDOS DE DIRECTORIO Desde UNIX tiene una estructura de directorios en forma de rbol en el que los directorios son tan fciles de manipular como ficheros ordinarios, es til para ampliar los servidores FTP en estas mquinas incluyen comandos que se ocupan de la creacin de directorios. Puesto que hay otros hosts de la ARPA-Internet que tienen directorios arborescentes (incluyendo TOPS-20 y Multics), estos comandos son lo ms 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 informacin 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.
Cdigos de respuesta El comando CDUP es un caso especial de la caquexia crnica, y se incluye para simplificar la implementacin de programas para la transferencia de directorio rboles entre los sistemas operativos que tienen diferentes sintaxis para nombrar el directorio padre. Los cdigos de respuesta para CDUP ser idnticos a los cdigos de respuesta de CWD. Los cdigos de respuesta para RMD ser idnticos a los cdigos de respuesta para su analgico archivo, DELE. Los cdigos de respuesta para MKD, sin embargo, son un poco ms complicadas. La directorio recin creado ser probablemente objeto de un futuro Postel & Reynolds [Pgina 62]
RFC 959 10 1985 Protocolo de transferencia de archivos 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 slo 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 slo podra 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 tendra que estar en el mismo directorio actual con el fin de alcanzar el subdirectorio. Dependiendo de la aplicacin, esto puede ser inconveniente. No es muy robusto en cualquier caso. Para resolver estos problemas, al trmino de un MKD comando, el servidor debe devolver una lnea 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 carcter; comillas incrustadas debern escaparon comillas dobles (la convencin "quote-duplicacin"). 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 257 Bar 200 foo "bar "/ usr / dm / foo" "bar" directorio creado CWD / usr / dm / foo " directorio cambiado a bar / usr / dm / foo "
RFC 959 10 1985 Protocolo de transferencia de archivos 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 gua - 521; 521 no tomar ninguna medida. Las respuestas de fracaso para MKD son anlogos a la creacin 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 creacin 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 informacin que el comando MKD xito, el xito PWD comando utiliza el cdigo de respuesta 257 tambin.
SUTILEZAS Debido a que estos comandos sern ms tiles en la transferencia de subrboles de una mquina a otra, observar cuidadosamente que el argumento para MKD debe interpretarse como un subdirectorio del directorio de trabajo actual, a menos que contenga informacin suficiente para el host de destino a decir lo contrario. Una hipottica ejemplo de su uso en el mundo TOPS-20: CWD 200 MKD 257 CWD 431 CWD 200 <some.where> Directorio de trabajo ha cambiado overrainbow directorio "<some.where.overrainbow>" creado overrainbow No existe el directorio <some.where.overrainbow> 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 informacin suficiente para TOPS-20 para decirle que la Postel & Reynolds [Pgina 64]
RFC 959 10 1985 Protocolo de transferencia de archivos directorio <unambiguous> es un directorio de ms alto nivel. Tenga en cuenta tambin que en el primer ejemplo, el usuario "viol" el protocolo de intentar acceder al directorio recin creado con un nombre distinto del devuelto por TOPS-20. Los problemas pueden tener resultado en este caso no haba sido un directorio <overrainbow>; se trata de una ambigedad inherente en algunos TOPS-20 implementaciones. Consideraciones similares se aplican a la orden RMD. El punto es siguiente: salvo que de hacerlo violara las convenciones de una serie de denota rutas relativas en comparacin absoluta, el anfitrin 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.
RFC 959 10 1985 Protocolo de transferencia de archivos 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 adicin 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 transaccin 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, "Documentacin del usuario FTP", RFC 412 (NIC 12404), Utah, 27 de noviembre 1972. Bhushan, Abhay, "Protocolo de transferencia de estado y ms 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, "Interaccin 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. Postel & Reynolds [Pgina 66]
RFC 959 10 1985 Protocolo de transferencia de archivos Bressler, Bob y Bob Thomas, "Recuperacin de correo a travs 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 Investigacin 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, "Compresin 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 "Interaccin 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, "Parmetros 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. Da, 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.
RFC 959 10 1985 Protocolo de transferencia de archivos McKenzie, Alex, y Jon Postel ", Telnet y FTP Implementacin Programe el Cambio ", RFC 593 (NIC 20615), BBN y MITRE,
29 de noviembre 1973. Sussman, Julie, "Uso de FTP Error Cdigo para el correo ms confiable Servicios ", RFC 630 (NIC 30237), BBN, 10 de abril de 1974. Postel, Jon, "Revised Responder Cdigos FTP", RFC 640 (NIC 30843), UCLA / NMC, 5 de junio de 1974. Harvey, Brian, "Dejar las cosas como estn", RFC 686 (NIC 32481), SU-AI, 10 de mayo de 1975. Harvey, Brian, "One More Try en el FTP", RFC 691 (NIC 32700), SUAI, 28 de mayo 1975. Lieb, J., "CWD comando de FTP", RFC 697 (NIC 32963), 14 de julio de 1975. Harrenstien, Ken, "FTP Extensin: XSEN", RFC 737 (NIC 42217), SRIKL, 31 de octubre 1977. Harrenstien, Ken, "FTP Extensin: 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 Transmisin - 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.
FTP
El Protocolo de transferencia de archivos (FTP) es uno de los protocolos ms viejos y populares que se encuentran en la Internet hoy da. Su objetivo es el de transmitir archivos exitsamente entre mquinas en una red sin que el usuario tenga que iniciar una sesin en el host remoto o que requiera tener conocimientos sobre cmo utilizar el sistema remoto. FTP permite a los usuarios acceder a archivos en sistemas remotos usando un conjunto de comandos estndar muy simples. Este captulo describe los elementos bsicos de este protocolo, as como tambin las opciones de configuracin para el servidor FTP primario que se entrega con Red Hat Enterprise Linux, vsftpd.
15.1. El Protocolo de Transferencia de Archivos

FTP utiliza una arquitectura cliente/servidor para transferir archivos usando el protocolo de red TCP. Puesto que FTP es un protocolo ms antiguo, no utiliza una autenticacin de usuarios y contrasea encriptada. Por esta razn, se considera un protocolo inseguro y no se debera utilizar a menos que sea absolutamente necesario. sftp, del conjunto de herramientas OpenSSH, es un buen sustituto para FTP. Para informacin sobre la configuracin de OpenSSH, consulte el captulo OpenSSH en el Manual de administracin del sistema de Red Hat Enterprise Linux. Para ms informacin sobre el protocolo SSH, consulte el Captulo 20. Sin embargo, puesto que FTP est tan extendido en la Internet, se requiere a menudo para compartir archivos con el pblico. Por lo tanto, los administradores de sistemas deberan estar conscientes de las caractersticas nicas del protocolo FTP.
15.1.1. Puertos mltiples, modos mltiples

A diferencia de la mayora de los protocolos utilizados en Internet, FTP requiere de mltiples puertos de red para funcionar correctamente. Cuando una aplicacin cliente FTP inicia una conexin 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 peticin de datos desde el servidor se devuelve al cliente a travs del puerto de datos. El nmero de puerto para las conexiones de datos y la forma en la que las conexiones son inicializadas vara dependiendo de si el cliente solicita los datos en modo activo o en modo pasivo. A continuacin se describen estos modos:
modo activo
El modo activo es el mtodo original utilizado por el protocolo FTP para la transferencia de datos a la aplicacin cliente. Cuando el cliente FTP inicia una transferencia de datos, el servidor abre una conexin desde el
puerto 20 en el servidor para la direccin IP y un puerto aleatorio sin privilegios (mayor que 1024) especificado por el cliente. Este arreglo implica que la mquina cliente debe poder aceptar conexiones en cualquier puerto superior al 1024. Con el crecimiento de las redes inseguras, tales como Internet, es muy comn el uso de cortafuegos para proteger las mquinas 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 aplicacin 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 direccin 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 informacin requerida. Mientras que el modo pasivo resuelve el problema de la interferencia del cortafuegos en el lado del cliente con las conexiones de datos, tambin puede complicar la administracin del cortafuegos del lado del servidor. Una de las formas de limitar el nmero 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 Seccin 15.5.8 para ms detalles sobre cmo limitar puertos pasivos.
15.2. Servidores FTP

Red 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 diseo, su funcionalidad es limitada y solamente se ejecuta como FTP annimo. Para ms informacin sobre la configuracin y administracin delAcelerador de Contenidos Red Hat, consulte la documentacin disponible en lnea en http://www.redhat.com/docs/manuals/tux/. un demonio FTP rpido y seguro, preferido para Red Hat Enterprise Linux. El resto de este captulo se enfoca en vsftpd.
vsftpd
15.2.1. vsftpd
El demonio FTP vsftpd (o Very Secure FTP Daemon) est diseado desde la base para ser rpido, estable y lo ms importante, seguro. Su habilidad para manejar grandes nmeros 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:
Clara separacin de procesos privilegiados y sin privilegios Procesos separados manejan tareas diferentes y cada uno de estos procesos se ejecuta con los privilegios mnimos requeridos para la tarea. Las tareas que requieren altos privilegios son manejadas por procesos con los mnimos privilegios necesarios Influenciando las compatibilidades encontradas en la biblioteca libcap, las tareas que usualmente requieren privilegios de superusuario se pueden ejecutar de forma ms segura desde un proceso menos privilegiado. La mayora de los procesos se ejecutan enjaulados en un ambiente chroot Siempre que sea posible, se cambia la raz 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 raz, conocido como /. Esto previene actividades maliciosas de cualquier hacker potencial en algn directorio que no estn por debajo del nuevo directorio root.
El uso de estas prcticas de seguridad tiene el efecto siguiente en cmo vsftpd trata con las peticiones:
El proceso padre se ejecuta con el mnimo de privilegios requerido El proceso padre calcula dinmicamente el nivel de privilegios requerido para minimizar el nivel de riesgos. Los procesos hijo manejan la interaccin directa con los clientes FTP y se ejecutan casi sin ningn privilegio. Todas las operaciones que requieren altos privilegios son manejadas por un pequeo 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 pequeo 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 informacin desde un proceso hijo es verificada antes de proceder. La mayor parte de la interaccin 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. vsftpd
15.3. Archivos instalados con
El RPM vsftpd instala el demonio (/usr/sbin/vsftpd), su archivo de configuracin y otros archivos relacionados, as como tambin directorios FTP en el sistema. La siguiente es una lista de los archivos y directorios considerados ms a menudo cuando se configura vsftpd:
El script de inicializacin (initscript) utilizado por el comando /sbin/service para iniciar, detener o volver a cargar vsftpd. Consulte la Seccin 15.4 para ms informacin sobre el uso de este script.
/etc/rc.d/init.d/vsftpd
El archivo de configuracin 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 ms informacin, consulte el Captulo 16.
/etc/pam.d/vsftpd
El archivo de configuracin para vsftpd. Consulte el Seccin 15.5 para una lista de las opciones importantes que se encuentran en este archivo.
/etc/vsftpd/vsftpd.conf
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.ftpusers
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.
/etc/vsftpd.user_list
El directorio /var/ftp/ El directorio que contiene los archivos servidos por vsftpd. Tambin contiene el directorio /var/ftp/pub/ para los usuarios annimos. Ambos directorios estn disponibles para la lectura de todos, pero slo el superusuario o root puede escribir en el.

Protocolo FTP

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Protocolo FTP

Uploaded by

Copyright:

Available Formats

Protocolo FTP (Protocolo de transferencia de archivos)

Introduccin al protocolo FTP

La funcin del protocolo FTP

Los comandos FTP

Comandos de control de acceso

SMNT REIN QUIT

Comandos de servicio FTP

Las respuestas FTP

Dgito Significado 1yz

Postel & Reynolds [Pgina 1]

Postel & Reynolds [Pgina 3]

Postel & Reynolds [Pgina 4]

RFC 959 10 1985 Protocolo de transferencia de archivos Comandos FTP

Postel & Reynolds [Pgina 6]

Postel & Reynolds [Pgina 7]

Postel & Reynolds [Pgina 9]

Postel & Reynolds [Pgina 10]

Postel & Reynolds [Pgina 11]

Postel & Reynolds [Pgina 12]

Postel & Reynolds [Pgina 13]

Postel & Reynolds [Pgina 14]

Postel & Reynolds [Pgina 17]

Postel & Reynolds [Pgina 18]

RFC 959 10 1985 Protocolo de transferencia de archivos

Postel & Reynolds [Pgina 20]

Postel & Reynolds [Pgina 21]

Postel & Reynolds [Pgina 22]

Postel & Reynolds [Pgina 24]

Postel & Reynolds [Pgina 25]

Hay cdigos de respuesta para diferenciar estos casos para

Postel & Reynolds [Pgina 26]

Postel & Reynolds [Pgina 31]

RFC 959 10 1985 Protocolo de transferencia de archivos

Postel & Reynolds [Pgina 39]

Postel & Reynolds [Pgina 40]

Postel & Reynolds [Pgina 41]

Postel & Reynolds [Pgina 42]

RFC 959 10 1985 Protocolo de transferencia de archivos

Postel & Reynolds [Pgina 43]

RFC 959 10 1985

Postel & Reynolds [Pgina 44]

Postel & Reynolds [Pgina 46]

RETR STOR STOU APPE ALLO

Postel & Reynolds [Pgina 47]

Postel & Reynolds [Pgina 48]

Postel & Reynolds [Pgina 49]

Postel & Reynolds [Pgina 50]

Postel & Reynolds [Pgina 51]

Postel & Reynolds [Pgina 52]

202 500, 501, 530 NOOP 200 500 421

Postel & Reynolds [Pgina 53]

Postel & Reynolds [Pgina 54]

Postel & Reynolds [Pgina 55]

Postel & Reynolds [Pgina 56]

Postel & Reynolds [Pgina 57]

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

Postel & Reynolds [Pgina 58]

Postel & Reynolds [Pgina 59]

Postel & Reynolds [Pgina 60]

Postel & Reynolds [Pgina 61]

Postel & Reynolds [Pgina 63]

Postel & Reynolds [Pgina 65]

Postel & Reynolds [Pgina 67]

Postel & Reynolds [Pgina 68]