파일 전송 프로토콜

File Transfer Protocol
「FTP」는 여기서 리다이렉트 됩니다.그 외의 용도는, FTP(구체적인 설명)를 참조해 주세요.
파일 전송 프로토콜
통신 프로토콜
목적파일 전송
개발자RFC 959용 Abhay Bushan
서론1971년 4월 16일, 51년 전(1971-04-16)
포트컨트롤의 경우 21, 데이터 전송의 경우 20
RFCRFC 959
인터넷 프로토콜 스위트
응용 프로그램레이어
트랜스포트 레이어
인터넷 레이어
링크 레이어

File Transfer Protocol(FTP)은 컴퓨터 네트워크상의 서버에서 클라이언트로 컴퓨터 파일을 전송하는 데 사용되는 표준 통신 프로토콜입니다.FTP는 클라이언트와 [1]서버 간의 개별 제어 및 데이터 연결을 사용하여 클라이언트-서버 모델 아키텍처를 기반으로 구축됩니다.FTP 사용자는 보통 사용자 이름과 비밀번호 형식으로 클리어 텍스트사인인 프로토콜을 사용하여 자신을 인증할 수 있지만 서버가 이를 허용하도록 구성된 경우 익명으로 연결할 수 있습니다.유저명과 패스워드를 보호하고 컨텐츠를 암호화하는 시큐어 전송을 위해서, FTP 는 SSL/TLS(FTPS)로 보호되거나 SSH File Transfer Protocol(SFTP)로 대체되는 경우가 많습니다.

최초의 FTP 클라이언트애플리케이션은, operating system이 그래피컬 유저 인터페이스를 갖추기 전에 개발된 커맨드 라인 프로그램으로, 대부분의 Windows, Unix, 및 Linux operating [2][3]system에 부속되어 있습니다.이후 많은 전용 FTP 클라이언트와 자동화 유틸리티가 데스크톱, 서버, 모바일 장치 및 하드웨어용으로 개발되었으며 FTP는 HTML 편집기 및 파일 관리자 등의 생산성 애플리케이션에 통합되었습니다.

FTP 클라이언트는 일반적으로 웹 브라우저에 통합되어 파일서버는 URI 프리픽스 "로 브라우즈 됩니다.ftp://2021년 내내 양대 웹 브라우저 벤더는 이 기능을 삭제했습니다.FTP 프로토콜 지원은 2021년 [4]1월에 구글 크롬 88에서 처음 비활성화되었고,[5] 2021년 4월에 파이어폭스 88.0이 뒤를 이었다.2021년 7월, 파이어폭스 90은 [6]FTP를 완전히 폐기했고, 구글은 2021년 10월에 따라 구글 크롬 [7]95에서 FTP를 완전히 제거했다.

FTP 서버 이력

File Transfer Protocol의 원래 사양은 Abhay Bushan에 의해 작성되어 다음과 같이 발행되었습니다. 1971년 4월 16일 RFC114.1980년까지 FTP는 TCP/[2]IP의 전신인 NCP에서 실행되었습니다.이 프로토콜은 나중에 TCP/IP 버전, RFC765(1980년 6월) 및 현재 사양인 RFC959(1985년 10월)로 대체되었습니다.RFC1579(1994년2월)에는 방화벽 친화적인 FTP(패시브모드), RFC2228(1997년6월)에는 보안 확장을, RFC2428(1998년9월)에는 IPv6 의 서포트가 추가되어 새로운 [8]타입의 패시브모드가 정의되는 등, 제안된 몇개의 표준이 RFC959 를 개정하고 있습니다.

프로토콜 개요

통신 및 데이터 전송

포트 21을 사용한 패시브 접속 시작 그림

FTP는 액티브모드 또는 패시브모드로 실행할 수 있습니다.이것은 데이터 접속의 [9]확립 방법을 결정합니다.(이 「모드」의 의미는 FTP 프로토콜의 MODE 명령의 의미와는 다릅니다.

  • 액티브 모드에서는, 클라이언트는 포토 M 의 서버로부터의 착신 데이터 접속의 수신을 개시합니다.FTP 명령어 PORT M 을 송신해, 어느 포토를 수신하고 있는지를 서버에 통지합니다.다음으로 서버는 포트 20(FTP 서버 데이터 포트)에서 클라이언트에 대한 데이터 채널을 시작합니다.
  • 클라이언트가 방화벽의 배후에 있어 착신 TCP 접속을 받아들일 수 없는 상황에서는 패시브모드를 사용할 수 있습니다.이 모드에서는, 클라이언트는 제어 접속을 사용해 서버에 PASV 커맨드를 송신해,[9] 서버로부터 서버의 IP 주소와 서버 포토 번호를 수신합니다.이것에 의해, 클라이언트는 임의의 클라이언트 포토로부터 수신한 [10]서버의 IP 주소와 서버 포토 번호에의 데이터 접속을 오픈합니다.

양쪽 모드는, 1998년 9월에 IPv6 를 서포트하도록 갱신되었습니다.그 시점에서 패시브모드가 추가 변경되어 확장 패시브모드로 [11]갱신되었습니다.

서버는 제어 연결을 통해 ASCII의 3자리 상태 코드와 옵션 텍스트메시지를 사용하여 응답합니다.예를 들어 "200"(또는 "200 OK")는 마지막 명령이 성공했음을 의미합니다.숫자는 응답 코드를 나타내고 옵션 텍스트는 사람이 읽을 수 있는 설명 또는 요청을 나타냅니다(예: <파일 저장을 위한 계정 필요>).[1]제어 연결을 통해 전송되는 인터럽트 메시지를 사용하여 데이터 연결을 통한 파일 데이터의 지속적인 전송을 중단할 수 있습니다.

FTP는 원래 NCP(Network Control Protocol) 상에서 동작하도록 설계되었기 때문에 2개의 포트(송신용과 수신용)가 필요합니다.NCP는 2개의 포트 주소를 사용하여 양방향 통신을 위해 2개의 연결을 확립하는 심플렉스 프로토콜입니다.홀수 포트와 짝수 포트가 각 애플리케이션 계층 애플리케이션 또는 프로토콜용으로 예약되었습니다.TCP 와 UDP 의 표준화에 의해, 애플리케이션 마다 2 개의 심플렉스 포토를 1 개의 듀플렉스 [12]: 15 포토로 사용할 필요는 감소했습니다만, FTP 프로토콜은 1 개의 포토만을 사용하도록 변경되지 않고, 하위 호환성을 위해서 2 개의 포토를 계속 사용하고 있습니다.

NAT 및 방화벽 통과

FTP 는, 통상은, PORT 커맨드가 클라이언트에 송신된 후에, 서버에 클라이언트에의 접속에 의해서 데이터를 전송 합니다.이것은, 인터넷에서 내부 호스트로의 [13]접속을 허가하지 않는 NAT 와 방화벽의 양쪽 모두에 문제가 있습니다.NAT 의 경우는, PORT 커맨드로 IP 주소와 포토 번호를 나타내는 것이, NAT 의 퍼블릭 IP 주소와 포토가 아니고, 내부 호스트의 IP 주소와 포토를 참조하는 것도 복잡합니다.

이 문제를 해결하기 위한 두 가지 방법이 있습니다.하나는 FTP 클라이언트와 FTP 서버가 PASV 명령을 사용하는 것입니다.이것에 의해,[13] FTP 클라이언트에서 서버로의 데이터 접속이 확립됩니다.이것은 현대의 FTP 클라이언트에서 널리 사용되고 있습니다.또 하나의 접근방식은 NAT이 애플리케이션레벨 게이트웨이를 [13]사용하여 PORT 명령어 값을 변경하는 것입니다.

데이터형

네트워크를 통해 데이터를 전송할 때는 다음 4가지 데이터 유형이 [2][3][8]정의됩니다.

  • ASCII(TYPE A): 텍스트에 사용됩니다.데이터는, 필요에 따라서 송신전의 송신 호스트의 문자 표현으로부터 「8비트 ASCII」로 변환해, 필요에 따라서 수신 호스트의 문자 표현으로 변환합니다.따라서 이 모드는 일반 텍스트 이외의 데이터를 포함하는 파일에는 적합하지 않습니다.
  • 이미지(TYPE I, 일반적으로 이진 모드라고 함):송신 머신은, 각 파일의 바이트 단위로 송신해, 수신자는 수신시에 바이 테스트 스트림을 보존합니다(FTP 의 모든 실장에 대해서 이미지 모드 서포트가 권장되고 있습니다).
  • EBCDIC(TYPE E): EBCD를 사용하는 호스트 간의 일반 텍스트에 사용됩니다.IC 문자 세트
  • 로컬(TYPE L n):DEC PDP-10 등의 36비트 시스템 등 8비트 바이트를 사용하지 않는 머신 간의 파일 전송을 지원하도록 설계되어 있습니다.예를 들어 "TYPE L 9"는 9비트 바이트로 데이터를 전송하기 위해, "TYPE L 36"은 36비트 단어를 전송하기 위해 사용됩니다.현대의 대부분의 FTP 클라이언트/서버는 I에 해당하는 L8만을 지원합니다.

만료된 인터넷 초안에서는 UTF-8을 [14]사용하여 Unicode 텍스트파일을 전송하기 위한 TYPE U가 정의되어 있습니다.초안이 RFC가 된 적은 없지만 여러 FTP 클라이언트/서버에 의해 구현되어 있습니다.

이러한 데이터 유형은 일반적으로 "모드"라고 불리지만, 이 단어는 active-vs-passive 통신 모드(위 참조) 및 FTP 프로토콜 MODE 명령(아래 참조)에 의해 설정된 모드를 나타낼 때도 모호하게 사용됩니다.

텍스트 파일(TYPE A 및 TYPE E)의 경우 파일 인쇄 방법을 제어하는 세 가지 형식 제어 옵션이 제공됩니다.

  • 비인쇄(TYPE A N 및 TYPE E N)– 파일에는 프린터용 캐리지 컨트롤 문자가 포함되어 있지 않습니다.
  • Telnet(TYPE A T 및 TYPE E T): 파일에는 Telnet(ASCII C0) 캐리지 제어 문자(CR, LF 등)가 포함되어 있습니다.
  • ASA(TYPE A 및 TYPE E A): 파일에는 ASA 캐리지 제어 문자가 포함되어 있습니다.

이러한 형식은 주로 라인 프린터와 관련되어 있습니다.현대의 FTP 클라이언트/서버는 대부분 N의 기본 형식 제어만 지원합니다.

파일 구조

파일 구성은 STRU 명령을 사용하여 지정합니다.다음 파일 구조는 RFC959 섹션 3.1.1에 정의되어 있습니다.

  • F 또는 FILE 구조(스트림 지향).파일은 바이트, 문자 또는 단어의 임의 시퀀스로 표시됩니다.이것은 Unix 시스템 및 CP/M, MS-DOS, Microsoft Windows 등의 다른 시스템에서 일반적인 파일 구조입니다.(제3.1.1절)
  • R 또는 RECORD 구조(레코드 지향).파일은 고정 길이 또는 가변 길이일 수 있는 레코드로 분할되어 표시됩니다.이 파일 구성은 MVS, VM/CMS, OS/400 및 VMS와 같은 레코드 지향 파일 시스템을 지원하는 메인프레임 및 미드레인지 시스템에서 일반적입니다.
  • P 또는 PAGE 구조(페이지 지향).파일은 데이터 또는 메타데이터를 포함할 수 있는 페이지로 분할됩니다.또, 각 페이지에는, 다양한 속성을 가지는 헤더가 있는 경우도 있습니다.이 파일 구조는 TENEX 시스템용으로 특별히 설계되었으며 일반적으로 다른 플랫폼에서는 지원되지 않습니다.RFC1123 섹션 4.1.2.3에서는 이 구조를 실장하지 않을 것을 권장합니다.

현대의 대부분의 FTP 클라이언트와 서버는 STRU F만 지원합니다. STRU R은 여전히 메인프레임 및 미니 컴퓨터 파일 전송 애플리케이션에서 사용되고 있습니다.

데이터 전송 모드

데이터 전송은 다음 3가지 모드 [1][2]중 하나로 실행할 수 있습니다.

  • 스트림 모드(MODE S): 데이터가 연속 스트림으로 전송되므로 FTP가 처리하지 않습니다.모든 처리는 TCP에 맡겨집니다.데이터가 레코드로 분할되지 않는 한 파일 종료 표시기는 필요하지 않습니다.
  • 블록 모드(MODE B):주로 레코드 지향 파일(STR R) 전송용으로 설계되었으며 스트림 지향(STR F) 텍스트 파일 전송에도 사용할 수 있습니다.FTP는 데이터의 각 레코드(또는 행)를 여러 블록(블록 헤더, 바이트 수 및 데이터 필드)으로 나누어 TCP에 [8]전달합니다.
  • 압축 모드(MODE C): MODE B를 실행 길이 부호화를 사용한 데이터 압축으로 확장합니다.

현대의 대부분의 FTP 클라이언트 및 서버는 MODE B 또는 MODE C를 구현하지 않습니다.메인프레임 및 미니컴퓨터 운영체제용 FTP 클라이언트 및 서버는 예외입니다.

일부 FTP 소프트웨어에서는 DEFLATE 기반 압축 모드(이 모드를 활성화하는 명령어 뒤에 "모드 Z"라고도 함)도 구현됩니다.이 모드는 인터넷 초안에서는 설명되었지만 [15]표준화되지는 않았습니다.

GridFTP는 MODE B의 확장으로 MODE[16] E와 MODE [17]X라는 추가 모드를 정의합니다.

기타 명령어

보다 최근의 FTP 실장에서는 Modify Fact: Modification Time(MFMT) 명령어가 지원됩니다.이것에 의해, 클라이언트는 그 파일 속성을 리모트로 조정할 수 있기 때문에,[18][19] 파일을 업 로드할 때에 그 어트리뷰트를 유지할 수 있습니다.

리모트 파일의 타임스탬프를 취득하려면 , MDTM 커맨드가 있습니다.일부 서버(및 클라이언트)는 MFMT와[20] 동일한 방식으로 동작하는2개의 인수를 사용하여 MDTM 명령어의 비표준 구문을 지원합니다.

로그 인.

FTP 로그인은 [2]액세스를 허용하기 위해 일반 사용자 이름과 비밀번호 방식을 사용합니다.사용자 이름은 USER 명령을 사용하여 서버로 전송되고 비밀번호는 PASS [2]명령을 사용하여 전송됩니다.이 시퀀스는 암호화되지 않은 "온더 와이어"이므로 네트워크 스니핑 [21]공격에 취약할 수 있습니다.클라이언트가 제공한 정보가 서버에 의해 받아들여지면 서버는 클라이언트에 그리팅을 전송하고 세션이 [2]시작됩니다.서버가 지원하는 경우 사용자는 로그인 credential을 제공하지 않고 로그인할 수 있지만 동일한 서버에서 이러한 [2]세션에 대해 제한된 액세스만 허용할 수 있습니다.

익명 FTP

FTP 서비스를 제공하는 호스트는 익명 FTP [2]액세스를 제공할 수 있습니다.일반적으로 사용자는 사용자 이름을 입력하라는 메시지가 표시되면 '익명'(일부 FTP 서버에서는 대소문자가 구분됨) 계정으로 서비스에 로그인합니다.사용자는 일반적으로 비밀번호 [3]대신 이메일 주소를 보내도록 요구받지만 제공된 [22]데이터에 대한 확인은 실제로 수행되지 않습니다.소프트웨어 업데이트를 제공하는 것을 목적으로 하는 FTP 호스트의 대부분은 익명 [3]로그인을 허용합니다.

HTTP와의 차이점

HTTP 는, Web 페이지의 일반적인 것과 같이, 많은 작은 에페메랄 전송에 불편하게 하는 FTP 의 버그를 근본적으로 수정합니다.

FTP에는 현재 작업 디렉토리 및 기타 플래그를 유지하는 스테이트 풀 제어 연결이 있으며, 각 전송에는 데이터가 전송되는 세컨더리 연결이 필요합니다."passive" 모드에서는 이 세컨더리 접속은 클라이언트에서 서버로, 기본 "active" 모드에서는 이 접속은 서버에서 클라이언트로 이루어집니다.액티브 모드에서의 역할 역전 및 모든 전송에 대한 랜덤 포트 번호에 의해 방화벽과 NAT 게이트웨이가 FTP에 대해 매우 어려움을 겪고 있습니다.HTTP는 스테이트리스이며 클라이언트로부터 서버로의 단일 접속을 통해 제어와 데이터를 다중화합니다.이러한 포트 번호는 NAT 게이트웨이를 경유하여1개씩 간단하게 이루어집니다.관리해야 할 수 있습니다.

FTP 제어 접속의 셋업은 필요한 명령어를 모두 송신하고 응답을 대기하는 라운드 트립 지연으로 인해 매우 느립니다.따라서 세션을 드롭하고 새로 확립하는 것이 아니라 제어 접속을 확립하여 여러 파일 전송에 대해 오픈 상태로 유지하는 것이 일반적입니다.이와는 대조적으로 HTTP는 원래 전송 후 비용이 너무 적게 들기 때문에 연결을 끊었습니다.그 후 HTTP는 TCP 접속을 여러 전송에 재사용할 수 있게 되었습니다만, 개념 모델은 세션이 아닌 독립된 요구입니다.

FTP가 데이터 연결을 통해 전송 중일 때 제어 연결이 유휴 상태입니다.전송에 시간이 너무 오래 걸리면 방화벽 또는 NAT은 제어 연결이 비활성 상태라고 판단하고 추적을 중지하여 사실상 연결이 끊어지고 다운로드가 혼란스러울 수 있습니다.단일 HTTP 접속은 요청 간에만 아이돌 상태가 되며 타임아웃 후 이러한 접속이 드롭되는 것은 정상입니다.

소프트웨어 지원

웹 브라우저

대부분의 일반적인 웹 브라우저는 FTP 서버에 호스트된 파일을 검색할 수 있지만 FTPS와 [3][23]같은 프로토콜 확장자를 지원하지 않을 수도 있습니다.HTTP 가 아닌 FTP 가 지정되면, 리모트서버상의 액세스 가능한 컨텐츠는, 다른 Web 컨텐츠에 사용되는 것과 같은 방법으로 표시됩니다.FireFTP는 완전한 기능을 갖춘 FTP 클라이언트로 설계된 브라우저 확장 기능으로 과거에는 Firefox 내에서 실행될 수 있었지만 지금은 Waterfox를 사용하는 것이 좋습니다.

Google Chrome은 Chrome [24]88에서 FTP 지원을 완전히 제거했습니다.2019년 현재,[25][7] 모질라는 코드를 단순화하기 위해 더 이상 사용되지 않는 오래된 FTP 구현에 대한 지원만 삭제하는 것을 포함한 제안을 논의하고 있다.2021년 4월 Mozilla는 기본적으로 [26]FTP 지원을 사용하지 않도록 설정한 Firefox 88.0을 출시했습니다.2021년 7월 Firefox 90은 FTP 지원을 완전히 [6]중단했습니다.

구문

FTP URL 구문은 RFC 1738에서 다음 형식으로 설명되어 있습니다.ftp://[user[:password]@]host[:port]/url-path(괄호 안의 부품은 옵션입니다).

예를 들어 URL ftp://public.ftp-servers.example.com/mydirectory/myfile.txt은 myfile 파일을 나타냅니다.txt 를 FTP 리소스로서 서버 public.ftp-servers.example.com 의 디렉토리 mydirectory 에서 가져옵니다.URL ftp://user001:secretpassword@private.ftp-servers.example.com/mydirectory/myfile.txt 에는 이 리소스에 액세스하기 위해 사용해야 하는 사용자 이름과 비밀번호 지정이 추가됩니다.

사용자 이름과 비밀번호 지정에 대한 자세한 내용은 브라우저 설명서(예: Firefox[27] 및 Internet[28] Explorer)를 참조하십시오.디폴트로는 대부분의 웹 브라우저는 패시브(PASV) 모드를 사용하여 최종 사용자 방화벽을 보다 쉽게 통과합니다.

사용자의 [29]루트 이외의 홈디렉토리가 있는 경우 브라우저에 따라 경로 해결 방법이 다릅니다.

다운로드 매니저

대부분의 일반적인 다운로드 매니저는 FTP 서버에 호스트된 파일을 수신할 수 있지만, 일부 다운로드 매니저는 FTP 서버에 호스트된 파일을 취득할 수 있는 인터페이스도 제공합니다.Download Studio를 사용하면 FTP 서버에서 파일을 다운로드할 수 있을 뿐만 아니라 FTP [30]서버 상의 파일 목록도 볼 수 있습니다.

보안.

FTP는 보안 프로토콜로 설계되지 않았으며 많은 보안 [31]취약점이 있습니다.1999년 5월에 RFC 2577의 저자들은 다음 문제에 대한 취약성을 열거했습니다.

FTP 는 트래픽을 암호화하지 않습니다.모든 전송은 클리어 텍스트로 되어 [2][31]있어 네트워크상에서 패킷캡처(스니핑)를 실행할 수 있는 모든 사용자가 사용자 이름, 패스워드, 명령어 및 데이터를 읽을 수 있습니다.이 문제는 TLS나 [8]SSL 등의 암호화 메커니즘이 작성되기 전에 설계된 많은 인터넷 프로토콜 사양(SMTP, Telnet, POP 및 IMAP 등)에서 공통적으로 발생합니다.

이 문제에 대한 일반적인 해결책은 다음과 같습니다.

  1. FTP 대신 FTPS, Telnet 대신 TelnetS 등 안전하지 않은 프로토콜의 보안 버전을 사용합니다.
  2. SSH File Transfer Protocol 또는 Secure Copy Protocol과 같이 작업을 처리할 수 있는 보다 안전한 다른 프로토콜을 사용합니다.
  3. Secure Shell(SSH; 시큐어 셸)이나 Virtual Private Network(VPN; 가상 프라이빗 네트워크)등의 시큐어 터널을 사용합니다.

SSH를 통한 FTP

FTP over SSH 는, 시큐어 셸 [31]접속을 개입시켜 통상의 FTP 세션을 터널링 하는 방법입니다.FTP는 복수의 TCP 접속을 사용하기 때문에(아직 사용되고 있는TCP/IP 프로토콜에서는 통상적으로) SSH를 통한 터널링이 특히 어렵습니다.SSH 클라이언트가 많은 경우 컨트롤 채널(포트 21의 초기 클라이언트와 서버 연결)의 터널 설정을 시도하면 해당 채널만 보호됩니다.데이터가 리드로 전송되면 FTP 소프트웨어에서 보호됩니다.양쪽 끝에서 새로운 TCP 접속(데이터 채널)을 셋업하기 때문에 기밀성이나 무결성 보호가 없습니다.

그렇지 않으면 SSH 클라이언트소프트웨어가 FTP 프로토콜에 대한 특정 지식을 갖추고 FTP 제어 채널메시지를 감시 및 고쳐 쓰고 FTP 데이터 채널의 새로운 패킷 전송을 자율적으로 오픈해야 합니다.이 모드를 지원하는 소프트웨어 패키지는 다음과 같습니다.

파생상품

FTPS

주요 기사: FTPS

명시적 FTPS는 FTP 표준의 확장 기능으로 클라이언트는 FTP 세션을 암호화하도록 요구할 수 있습니다.이를 수행하려면 "AUTH TLS" 명령을 전송합니다.서버에는 TLS를 요청하지 않는 연결을 허용하거나 거부할 수 있는 옵션이 있습니다.이 프로토콜 확장은 RFC 4217에 정의되어 있습니다.암묵적 FTPS는 SSL 또는 TLS 연결을 사용해야 하는 FTP의 오래된 표준입니다.일반 FTP와는 다른 포트를 사용하도록 지정되었습니다.

SSH 파일 전송 프로토콜

주요 문서: SSH File Transfer Protocol(SSH 파일 전송 프로토콜)

SSH 파일 전송 프로토콜(연혁적으로 두 번째인 SFTP)은 파일을 전송하고 사용자를 위한 유사한 명령 집합을 갖지만 Secure Shell Protocol(SSH)을 사용하여 파일을 전송합니다.FTP와는 달리 명령어와 데이터를 모두 암호화하여 패스워드 및 기밀 정보가 네트워크를 통해 개방적으로 전송되는 것을 방지합니다.일부 FTP 클라이언트 소프트웨어는 SSH 파일 전송 프로토콜도 지원하지만 FTP 소프트웨어와 상호 운용할 수 없습니다.

Trivial 파일 전송 프로토콜

주요 기사:Trivial 파일 전송 프로토콜

TFTP(Trivial File Transfer Protocol)는 클라이언트가 리모트호스트로부터 파일을 취득하거나 리모트호스트에 파일을 배치할 수 있는 심플한 록스텝 FTP 입니다.TFTP의 주요 용도 중 하나는 로컬에리어 네트워크에서 부팅하는 초기 단계입니다.이는 TFTP의 구현이 매우 간단하기 때문입니다.TFTP에는 보안이 결여되어 있으며 File Transfer Protocol과 같은 보다 강력한 파일 전송 프로토콜이 제공하는 대부분의 고급 기능이 없습니다.TFTP는 1981년에 처음 표준화되었으며 프로토콜의 현재 사양은 RFC 1350에서 확인할 수 있습니다.

단순 파일 전송 프로토콜

RFC 913에서 정의된 Simple File Transfer Protocol(SFTP로 약칭된 최초의 프로토콜)은 TFTP와 FTP 사이의 복잡성 수준을 가진 (보안되지 않은) 파일 전송 프로토콜로 제안되었습니다.인터넷에서 널리 받아들여진 적이 없고, 현재는 IETF에 의해 Historic status가 할당되어 있습니다.포트 115를 통해 실행되며 SFTP의 이니셜리즘을 수신하는 경우가 많습니다.11개의 명령어세트가 있으며 ASCII, 바이너리 및 연속의 3종류의 데이터 전송을 지원합니다.워드 사이즈가 8비트의 배수인 시스템의 경우 바이너리와 연속의 실장은 동일합니다.또한 프로토콜은 사용자 ID 및 암호를 사용한 로그인, 계층 폴더 및 파일 관리(이름 변경, 삭제, 업로드, 다운로드, 덮어쓰기 포함, 추가 포함)를 지원합니다.

FTP 명령어

주요 기사:FTP 명령어 목록

FTP 응답 코드

주요 기사:FTP 서버 반환 코드 목록

FTP 서버가 반환할 가능성이 있는FTP 응답 코드의 개요를 다음에 나타냅니다.이들 코드는 IETF에 의해 RFC 959로 표준화되어 있습니다.응답 코드는 3자리 값입니다.첫 번째 숫자는 성공, 실패 또는 오류 또는 불완전한 응답을 나타내는 세 가지 결과 중 하나를 나타내기 위해 사용됩니다.

  • 2yz –성공 응답
  • 4yz 또는 5yz – 응답 실패
  • 1yz 또는 3yz –오류 또는 불완전한 응답

두 번째 숫자는 오류의 종류를 정의합니다.

  • x0z : 구문.이러한 응답은 구문 오류를 나타냅니다.
  • x1z – 정보정보 요청에 대한 응답입니다.
  • x2z – 연결.컨트롤과 데이터 접속에 관한 응답.
  • x3z – 인증 및 계정.로그인 프로세스 및 계정 절차에 대한 응답입니다.
  • x4z – 정의되어 있지 않습니다.
  • x5z – 파일 시스템이러한 응답은 서버 파일 시스템에서 상태 코드를 릴레이합니다.

응답 코드의 세 번째 숫자는 두 번째 숫자로 정의된 각 카테고리에 대한 추가 세부 정보를 제공하기 위해 사용됩니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b c Forouzan, B.A. (2000). TCP/IP: Protocol Suite (1st ed.). New Delhi, India: Tata McGraw-Hill Publishing Company Limited.
  2. ^ a b c d e f g h i j Kozierok, Charles M. (2005). "The TCP/IP Guide v3.0". Tcpipguide.com.
  3. ^ a b c d e Dean, Tamara (2010). Network+ Guide to Networks. Delmar. pp. 168–171.
  4. ^ "Deprecations and removals in Chrome 87". Retrieved 18 November 2020.
  5. ^ "Firefox 88.0, See All New Features, Updates and Fixes". Retrieved 23 April 2021.
  6. ^ a b Vonau, Manuel (7 July 2021). "Firefox follows in Chrome's footsteps and drops FTP support (APK Download)". Android Police. Retrieved 12 July 2021.{{cite web}}: CS1 maint :url-status (링크)
  7. ^ a b "Remove FTP support - Chrome Platform Status". www.chromestatus.com. Retrieved 2 September 2021.
  8. ^ a b c d Clark, M.P. (2003). Data Networks IP and the Internet (1st ed.). West Sussex, England: John Wiley & Sons Ltd.
  9. ^ a b "Active FTP vs. Passive FTP, a Definitive Explanation". Slacksite.com.
  10. ^ RFC 959 (표준) File Transfer Protocol (FTP)포스텔, J. & 레이놀즈, J.(1985년 10월)
  11. ^ RFC 2428(제안된 표준) IPv6, NAT 및 확장 패시브모드 확장Allman, M. & Metz, C. & Ostermann, S. (1998년 9월)
  12. ^ Stevens, W. Richard (1994). TCP/IP Illustrated Volume I. Vol. 1. Reading, Massachusetts, USA: Addison-Wesley Publishing Company. ISBN 0-201-63346-9.
  13. ^ a b c Gleason, Mike (2005). "The File Transfer Protocol and Your Firewall/NAT". Ncftp.com.
  14. ^ Klensin, John. FTP TYPE Extension for Internationalized Text. I-D draft-klensin-ftpext-typeu-00. Retrieved 9 June 2020.
  15. ^ Preston, J. (January 2005). Deflate transmission mode for FTP. IETF. I-D draft-preston-ftpext-deflate-03. Retrieved 27 January 2016.
  16. ^ Allcock, W. (April 2003). "GridFTP: Protocol Extensions to FTP for the Grid" (PDF).
  17. ^ Mandrichenko, I. (4 May 2005). "GridFTP v2 Protocol Description" (PDF).
  18. ^ "MFMT FTP command". support.solarwinds.com. 11 October 2018.
  19. ^ "FTP Commands: DSIZ, MFCT, MFMT, AVBL, PASS, XPWD, XMKD Serv-U". www.serv-u.com.
  20. ^ "MDTM FTP command". support.solarwinds.com. 11 October 2018.
  21. ^ Prince, Brian. "Should Organizations Retire FTP for Security?". Security Week. Security Week. Retrieved 14 September 2017.
  22. ^ RFC 1635 (정보)익명 FTP 사용방법.P. & Emage, A. & Marine, A. (1994년 5월)
  23. ^ Matthews, J. (2005). Computer Networking: Internet Protocols in Action (1st ed.). Danvers, MA: John Wiley & Sons Inc.
  24. ^ Sneddon, Joey (26 January 2021). "Linux Release Roundup: GParted, Lightworks, Google Chrome + More". omgubuntu.co.uk. Retrieved 30 January 2021.
  25. ^ "1574475 - Remove FTP support".
  26. ^ "See what's new in Firefox: 88.0 Firefox Release". mozilla.org. 19 April 2021. Retrieved 20 April 2021.
  27. ^ "Accessing FTP servers How to Firefox Help". Support.mozilla.com. 5 September 2012. Retrieved 16 January 2013.
  28. ^ : CS1 maint: bot: 원래 URL 상태를 알 수 없음(링크) IE 버전 6 이전용으로 작성되었습니다"How to Enter FTP Site Password in Internet Explorer". Archived from the original on 2 July 2015. Retrieved 13 February 2020.{{cite web}}.새로운 버전에서는 동작할 수 있습니다.
  29. ^ Jukka “Yucca” Korpela (18 September 1997). "FTP URLs". "IT and communication" (jkorpela.fi). Retrieved 26 January 2020.
  30. ^ "DownloadStudio - Internet Download Manager And Download Accelerator - Features". Conceiva. Retrieved 19 October 2021.
  31. ^ a b c "Securing FTP using SSH". Nurdletech.com.
  32. ^ "Components of the Information Assurance Platform (section Tectia ConnectSecure)". ssh.com. Archived from the original on 31 July 2020.

추가 정보

  • RFC 697 – FTP의 CWD 명령어1975년 7월
  • RFC 959 – (표준) File Transfer Protocol (FTP)J. 포스텔, J. 레이놀즈1985년 10월
  • RFC 1579 – (정보) 방화벽에 적합한 FTP.1994년 2월
  • RFC 1635 – (정보)익명 FTP 사용 방법1994년 5월
  • RFC 1639 - FTP Operation Over Big Address Records(FOOBAR)1994년 6월
  • RFC 1738 – Uniform Resource Locator(URL; 통일 자원 로케이터)1994년 12월
  • RFC 2228 – (제안된 표준) FTP 보안 확장.1997년 10월
  • RFC 2389 – (제안된 표준) File Transfer Protocol의 기능 네고시에이션 메커니즘.1998년 8월
  • RFC 2428 – (제안된 표준) IPv6, NAT 및 확장 패시브모드용 확장.1998년 9월
  • RFC 2577 – (정보) FTP 보안 고려사항1999년 5월
  • RFC 2640 – (제안된 표준) 파일 전송 프로토콜의 국제화.1999년 7월
  • RFC 3659 – (제안된 표준) FTP로의 확장.P. Hethmon.2007년 3월
  • RFC 5797 – (제안된 표준) FTP 명령 및 확장 레지스트리.2010년 3월
  • RFC 7151 – (제안된 표준) 가상 호스트용 File Transfer Protocol HOST 명령어.2014년 3월
  • IANA FTP 명령 및 확장 레지스트리– FTP 명령 및 확장의 공식 레지스트리

외부 링크