Протокол за пренос на податотеки

Од Википедија, слободната енциклопедија
Прејди на: содржини, барај
Петте нивоа на TCP/IP моделот
5. Апликациско ниво (Application layer)

DHCP • FTP • IMAP4 • POP3 • SIP • SMTP • SSH • BGP •

4. Транспортно ниво (Transport layer)

UDP • TCP • DCCP • SCTP • RSVP • ECN

3. Мрежно ниво (Network layer)

IP (IPv4 • IPv6) • ICMP • IGMP • RSVP • IPsec

2. Податочно ниво (Data Link Layer)

ATM • DTM • Ethernet • FDDI • Frame Relay • GPRS • PPP • ARP • RARP • L2TP • PPTP

1. Физичко ниво (Physical layer)

Етернет • ISDN • Модеми • PLC • SONET/SDH • G.709 • Wi-Fi •

Протокол за пренос на податотеки (ППП) е стандарден мрежен протокол кој се користни за копирање на податотека од еден на друг хост преку TCP базирана мрежа, како што е Интернет. ППП се заснова на клиент-сервер архитектурата. [1] ППП клиентите се индентификуваат со користење на корисничко име и лозинка, но исто така може да се поврзат и анонимно на ППП опслужувачот доколку истиот тоа го има дозволено.

Првите ППП клиентски апликации беа интерактивни алатки за командната линија, спроведувајќи стандардни команди и синтакса. Графичките кориснички интерфејс клиенти, кои беа развиени за многу популарните десктоп оперативни системи, се користат и денес.

Историја[уреди]

Оригиналните спецификации за Протоколот за пренос на податотеки напишани од Abhay Brushan и објавени како RFC 114 на 16 Април 1971 и подоцна заменети со RFC 765 (Јуни 1980) и RFC 959 (Октомври 1985), тековните спецификации. Неколку предложени измени за стандардот RFC 959, на пример RFC 2228 (Јуни 1997) предлагаат безбедносни екстензии и RFC 2428 (Септември 1998) дава подршка за IPv6 и дефинира нов тип на пасивен режим. .[2]

Преглед на протоколот[уреди]

Протоколот е наведен во RFC 959, кој е сумиран подолу. .[3]

Клиентот прави TCP врска до серверската порта 21. Оваа врска, наречена контролна врска, останува отворена за време на траењето на сесијата, со втора врска, наречена податочна врска , отворена од серверот од неговата порта 20 до клиентската порта (наведени во преговарачкиот дијалог) како што е потребно за пренос на податочна датотека. Контролната врска се користи за администрација на сесија (односно, команди, идентификација, лозинки) )[4]разменета помеѓу клиентот и серверот користејќи telnet како протокол. На пример "RETR "filename"" веднаш ке ја пренесе одредената датотека од серверот до клиентот. Поради две-портната структура, ППП се смета за out-of-band, за разлика на in-band протоколот како што е HTTP. [4]

Серверот одговара на контролната врска со статус код со три цифри во ASCII со опционална текст порака, на пример "200" (или "200 OK.") значи дека последната команда беше успешна. Бројките го претставуваат кодот број и опционалниот текст претставува објаснување (на пример ,<OK>) или се потребни параметри (на пример, <Треба корисничка сметка за зачувување на датотека>).[1]Пренос на датотека во прогрес низ податочна врска може да биде прекинат користејќи порака на прекин испратена низ контролната врска.

ППП може да биде извршен во активен или пасивен режим, којшто одредува како податочната врска е воспоставена. Во активен режим, клиентот ја испраќа на серверот IP адресата и бројот на портата на која клиентот ќе слуша, и серверот иницира TCP врска. Во ситуации кога клиентот е зад firewall и не може да ја прифати дојдовната TCP врска, пасивниот режим може да се користи. Во овој режим клиентот испраќа PASV команда на серверот и добова една IP адреса и бројот на портата за возврат. Клиентот ги користи овие податоци за отворање на врската до серверот. [3]Двете форми се ажурирани во Септември 1998 година за да подржат IPv6. Во тоа време беа направени и други промени на пасивниот режим, правејќи го продолжен пасивен режим. [5]

Додека се пренесуваат податоци низ мрежата, четири претставувања на податоци може да се користат[2]:

  • ASCII режим: секористи за текст. Податоците се конвертирани, ако е потребно, од испраќачкиот хост на претставувањето на карактерите во "8-битен ASCII" пред преносот, и (повторно, ако е потребно) до примачкиот хост на претставувањето на карактерите. Како последица на тоа, овој режим е несоодветен за датотеки кои содржат податоци, освен обичен текст.
  • Слика режим (вообичаено се нарекува Бинарен режим): испраќачката машина ја испраќа секоја датотека бајт по бајт, и примателот ги снима овие потоци од бајти како што ги прима.(Подршката за Image режим се препорашува за сите имплементации на ППП).
  • EBCDIC режим:се користи за обичен текст помеѓу хостовите користејќи го множеството со карактери EBCDIC. Овој режим инаку е како ASCII режимот.
  • Локален режим:дозволува два или повеќе компјутери со идентични поставувања да испраќаат податоци во неслободен формат, без потреба да ги претвораат во ASCII.

За текстуални датотеки, различен формат ги контролира и евидентира опциите на структурата кои се предвидени. Овие карактеристики се дизајнирани за да се олеснат датотеките кои содржат Telnet или ASA форматирање.

Преносот на податоци може да се направи на било кој од трите начини:

  • Поточен режим:Податоците се праќаат како континуиран поток, ослободувајќи го ППП од било каква обработка. Донекаде, сите обработки се оставени на TCP. Не е потребен индикатор End-of-file, доколку податоците се поделени во записи.
  • Блок режим:ППП ги разбива податоците во неколку блокови, (наслов на блокот, број на бајт, и податочно поле) и потоа ги пренесува во TCP.[2]
  • Компресиран режим:Податоците се компресирани со еден единствен алгоритам (вообичаено run-length кодирање).

Безбедност[уреди]

ППП не бил дизајниран да биде сигурен протокол-особено на денешните стандарди-и има многу безбедносни слабости. Во Мај 1999, авторите на RFC 2577 ги набројале следните недостатоци: [6]

ППП не бил дизајниран за да го шифрира својот сообраќај; сите преноси се во чист текст, и корисничките имиња, лозинки, команди и податоците може лесно да бидат прочитани од било кој кој може да фаќа пакети преку ( душкање) на мрежата. Овој проблем е заеднички за многу спецификации на Интернет протоколи (како што се SMTP, Telnet, POP и IMAP) дизајнирани пред создавањето на механизми за шифрирање како што се TLS или SSL.[2]Заедничко решение за овој проблем е користењето на “безбеден”, TLS-заштитена верзија на несигурни протоколи (на пример, FTPS за FTP, TelnetS за Telnet и други) или избор на различен, посигурен протокол кој може да се справи со работата, како што е SFTP/SCP алатки, заедно со повеќето имплементации на Secure Shell протоколот.

Анонимни ППП[уреди]

Хост којшто обезбедува услуги на ППП може дополнително да обезбедува анонимен ППП пристап. Корисниците обично се најавуваат на сервисот со ‘анонимна’ корисничка сметка кога ќе бидат известени за корисничко име. Иако корисниците најчесто треба да ги испраќаат своите email адреси наместо лозинка, без потврда всушност изведена доставата на податоци; [7] примери на анонимни ППП сервери можат да бидат најдени овде.

Далечински ППП или ПППmail[уреди]

Каде што ППП пристапот е ограничен, далечинскиот ППП (или ПППmail) сервисот може да се користи за да се избегне проблемот. E-mail кој ги содржи ППП командите за да се изврши е испратен на далечинскиот ППП сервер, кој е сервер за пошта што го парсира дојдовниот e-mail, ги извршува ППП командите, и испраќа назад e-mail со сите преземени датотеки како прилог. Очигледно ова е помалку флексибилно од ППП клиент, како што не е можно да се погледнат директориумите интерактивно или за менување на команди, и исто така може да има проблеми со големите датотечни прикачувања во одговорите што се добиваат од серверите за пошта. Услугата се користи само кога некои корисници имаат пристап до Интернет преку е-мејл портали како што е BBS или онлајн сервис.

Подршка за веб прелистувачи[уреди]

Најчестите веб прелистувачи можат да вчитат податоци хостирани на ППП сервери, иако тие можеби не подржуваат протокол екстензии како што е FTPS. ]].[8] Кога ППП-наместо HTTP- URL е добиена, достапни содржини на оддалечен сервер се претставени на начин сличен на оној што се користи за други веб содржини. Полно-опремен ППП клиент може да се движи (run) во рамките на Firefox во форма на проширување наречена FireFTP[1]

ППП URL синтаксата е опишана во RFC 1738,[9] земајќи ја формата:

ftp://[<корисник>[:<лозинка>]@]<хост>[:<порта>]/<патека_на_url>[9]

(Делот во заградите е опционален.) На пример:

ftp://public.ftp-servers.example.com/mydirectory/myfile.txt

или:

ftp://user001:secretpassword@private.ftp-servers.example.com/mydirectory/myfile.txt

Повеќе детали за впишувањена корисничкото име и лозинката може да се нјдат во документацијата на веб пребарувачите, како што се, на пример , Firefox и Internet Explorer.

Стандардно, повеќето веб прелистувачи користат пасивен (PASV) режим, кој полесно го преминува крајниот корисничи firewall.

NAT и поминувањето на огнените ѕидови[уреди]

ППП нормално пренесува податоци со тоа што серверот се поврзува назад со клиентот, откако командата PORT е испратена на од страна на клиентот. Ова е проблематично и за NAT и за огнените ѕидови, кои не дозволуваат врски од Интернетот кон внатрешните хостови. За NAT, дополнителна компликација е застапеноста на IP адреси и бројот на портата во PORT командата што се однесува на IP адресата на домашниот хост и портата, наместо јавната IP адреса и портата на NAT.

Постојат два пристапа кон овој проблем. Една од нив е дека ППП клиентот и ППП серверот ја користат PASV командата, која што предизвикува податочната врска да се утврди од ППП клиентот до серверот. Ова е широко употребувано од современите ППП клиенти. Другиот пристап е да NAT ги менува вредностите на PORT командата, користејќи апликација на ниво на портал за оваа намена.

Безбеден ППП[уреди]

Постојат неколку методи за безбедно пренесување на датотеки што се нарекуваат “Безбеден ППП” во една точка или друга.

FTPS (експлицитен)[уреди]

Експлицитниот FTPS е продолжение на ППП стандардот кој што им овозможува на клиентите да побараад да ППП сесијата биде шифрирана. Тоа се прави со праќање на командата “AUTH TLS”. Серверот има опција да дозволи или одбие врски кои не барааат TLS. Најновата дефиниција на овој протокол е RFC 4217.

FTPS (имплицитен)[уреди]

Имплицитниот FTPS е застарен стандард за ППП којшто бара употреба на SLL или TLS врска. ТОј бил определен да користи различни порти од обичниот ППП.

SFTP[уреди]

SFTP, "SSH Протокол за пренос на датотеки," не е поврзан со ППП освен тоа што и тој исто така пренесува датотеки и има слично командно множество за корисниците.

ППП преку SSH (не SFTP)[уреди]

ППП преку SSH (не БППП)” се однесува на праксата на тунелирање на нормална ППП сесија во текот на SSH врска. Бидејќи ППП користи повеќе TCP врски (невообичаено за TCT/IP протокол кој сеуште е во употреба), особено е тешко да се пробие преку SSH. Со многу SSH клиенти, кој што се обидуваат да се пробијат за “каналот за контрола” (почетна клиент-сервер врска на портата 21) ќе биде заштитен само тој канал; кога податоците се пренесени, ППП софтверот на двата краја ќе постави нови TCP врски (“податочни канали”), којшто ја заобиколуваат SSH врската, според тоа нема доверливост, интегрирана заштита итн.

Во спротивно, е неопходно за SSH клиент софтверот да има специфични знаења за ППП протоколот, и да се следи и да се поправи ППП каналот за контрола на пораки и автономно да се отвараат нови препраќања за ППП податочните канали. Верзијата 3 на [[SSH Комуникациската безбедност , GPL лиценцирано FONC, и Co:Z FTPSSH Proxy се трите софтверски пакети кои го подржувааат овој режим.

ППП преку SSH, понекогаш се нарекува “безбеден ППП”; ова не треба да се меша со другите методи за обезбедување на ППП, како на пример со SSL/TLS (FTPS). Други методи на пренос на датотеки со користење на SSH кои не се поврзани со ППП вклучуваат SFTP и БКП; во секоја од овие, целиот разговор (акредитиви и податоци) е секогаш заштитен со SSH протоколот.

Листа на ППП команди[уреди]

Подолу е Листа на ППП команди кои мошат да бидат до ППП сервер, вклучувајќи ги сите команди кои се стандардизирани во RFC 959 од страна на IETF. Сите команди подолу се RFC 959 базирани освен ако не е поинаку назначено. Имајте на ум дека повеќето командни линии на ППП клиентите на корисниците им презентираат свое множество команди. На пример, GET е заедничка корисничка команда за да ја спуштите датотеката наместо необработената (сурова) команда RETR.


Команда RFC Опис
ABOR Прекини активен пренос на датотека.
ACCT Информации за корисничката сметка.
ADAT RFC 2228 Проверка за автентичност/Безбедност на податоци.
ALLO Додели доволно простор за да се прими датотека.
APPE Додава.
AUTH RFC 2228 Проверка за автентичност/Безбедносен механизам.
CCC RFC 2228 Јасен Команден Канал
CDUP Промена на главниот директориум.
CONF RFC 2228 Доверлива заштитна команда.
CWD Промена на работниот директориум.
DELE Бришење на датотека.
ENC RFC 2228 Заштита на приватен канал.
EPRT RFC 2428 Одредува проширена адреса и портата на која што серверот треба да се поврзе.
EPSV RFC 2428 Внесете продолжен пасивен режим.
FEAT RFC 2389 Добиј листа на функции имплементирана од страна на серверот.
LANG RFC 2640 Договарање на јазик.
LIST Ако е одредено враќа информации за датотеката или директориумот, инаку враќа информации од тековниот директориум.
LPRT RFC 1639 Одредува долга адреса и порта на која што серверот треба да се поврзе.
LPSV RFC 1639 Внеси долг пасивен режим.
MDTM RFC 3659 Врати го последното изменето време на наведената датотека.
MIC RFC 2228 Интегрирана заштитена команда.
MKD Направи директориум.
MLSD RFC 3659 Листај ја содржината на директориумот ако директориумот е именуван.
MLST RFC 3659 Обезбедува податоци за точно именуван објект на командната линија, и за никој друг.
MODE Го поставува режимот на пренос (Поток, Блок, или Компресиран).
NLST Враќа листа на имињата на датотеките во одреден директориум.
NOOP Нема операција (лажен пакет;се користи главно за keepalives).
OPTS RFC 2389 Одбери опција за функција.
PASS Лозинка за автентикација.
PASV Внесете пасивен режим.
PBSZ RFC 2228 Заштита на големината на буферот.
PORT Ја одредува адресата и портата на која серверот треба да се поврзе.
PROT RFC 2228 Безбедносно ниво на податочни канали.
PWD Печати работен директориум. Го враќа тековниот директориум на хостот.
QUIT Исклучување.
REIN Ре иницијализирање на врската.
REST Рестартирај го преносот од назначена точка.
RETR Испрати копија од датотеката.
RMD Отстрани директориум.
RNFR Преименувај од.
RNTO Преименувај до.
SITE Испрати страна специфични команди до оддалечен сервер.
SIZE RFC 3659 Ја враќа големината на датотеката.
SMNT Качи датотечна структура.
STAT Го враќа тековниот статус.
STOR Прифати ги податоците и сними ги податоците како датотека на серверската страна
STOU Да се чува датотеката посебно.
STRU Постави ја структурата на пренос на датотеки.
SYST Врати го типот на системот.
TYPE Го поставува режимот (ASCII/Бинарен).
USER Автентичност на корисничкото име.

Видете исто така[уреди]

Референци[уреди]

  1. 1,0 1,1 Forouzan, B.A. (2000). TCP/IP: Protocol Suite. Прво издание, Њу Делхи, Индија: Tata McGraw-Hill Publishing Company Limited.
  2. 2,0 2,1 2,2 2,3 Clark, M.P. (2003). Data Networks IP and the Internet. Прво издание. Западен Сасекс , Англија: John Wiley & Sons Ltd.
  3. 3,0 3,1 Postel, J., & Reynolds. J. (Октомври 1985). RFC 959. In The Internet Engineering Task Force.
  4. 4,0 4,1 Kurose, J.F. & Ross, K.W. (2010). Computer Networking. Петто издание. Бостон, MA: Pearson Education, Inc.
  5. Allman, M. & Metz, C. & Ostermann, S. (Септември 1998). RFC 2428. In The Internet Engineering Task Force.
  6. Allman, M. & Ostermann, S. (Мај 1999). RFC 2577. In The Internet Engineering Task Force. Retrieved from http://www.ietf.org/rfc/rfc2577.txt
  7. Deutsch, P. & Emtage, A. & Marine, A. (May 1994). RFC 1635. In The Internet Engineering Task Force. Retrieved from http://www.ietf.org/rfc/rfc1635.txt
  8. Matthews, J. (2005). Computer Networking: Internet Protocols in Action. 1st ed. Danvers, MA: John Wiley & Sons Inc.
  9. 9,0 9,1 Berners-Lee, T. & Masinter, L. & McCahill, M. (December 1994). RFC 1738. In The Internet Engineering Task Force. Retrieved from http://www.ietf.org/rfc/rfc1738.txt

Натамошно читање[уреди]

  • RFC 959 – (Standard) File Transfer Protocol (FTP). J. Postel, J. Reynolds. October 1985.
  • RFC 1579 – (Informational) Firewall-Friendly FTP.
  • RFC 2228 – (Proposed Standard) FTP Security Extensions.
  • RFC 2389 – (Proposed Standard) Feature negotiation mechanism for the File Transfer Protocol. August 1998.
  • RFC 2428 – (Proposed Standard) Extensions for IPv6, NAT, and Extended passive mode. September 1998.
  • RFC 2640 – (Proposed Standard) Internationalization of the File Transfer Protocol.
  • RFC 3659 – (Proposed Standard) Extensions to FTP. P.Hethmon. March 2007.
  • RFC 5797 – (Proposed Standard) FTP Command and Extension Registry. March 2010.
  • RFC 697 - CWD Command of FTP
  • RFC 959 - File Transfer Protocol (FTP)
  • RFC 1639 - FTP Operation Over Big Address Records (FOOBAR)
  • RFC 2228 - FTP Security Extensions
  • RFC 2389 - Feature negotiation mechanism for the File Transfer Protocol
  • RFC 2428 - FTP Extensions for IPv6 and NATs
  • RFC 2640 - Internationalization of the File Transfer Protocol
  • RFC 3659 - Extensions to FTP
  • RFC 5797 - FTP Command and Extension Registry

Надворешни врски[уреди]

Wikibooks
Англиските Викикниги нудат повеќе материјал на тема:

Шаблон:URI scheme