Permintaan Komentar: 959 J. Reynolds
ISI
Obsoletes RFC: 765 (IEN 149) Oktober 1985
FILE TRANSFER PROTOCOL (FTP)
Status Memo ini
memo ini adalah spesifikasi resmi dari File Transfer
Protocol (FTP). Distribusi memo ini tidak terbatas.
mengikuti perintah opsional baru termasuk dalam edisi ini
spesifikasi:
CDUP (Ubah ke direktori Parent), SMNT (Struktur Mount), Stou
(Toko Unik), RMD (Hapus Direktori), MKD (Membuat Directory), PWD
(Direktori Cetak), dan SYST (System).
Perhatikan bahwa spesifikasi ini kompatibel dengan edisi sebelumnya.
1. PERKENALAN
Tujuan dari FTP adalah 1) untuk mempromosikan berbagi file (komputer
program dan / atau data), 2) untuk mendorong langsung atau implisit (via
program) penggunaan komputer remote, 3) untuk melindungi pengguna dari
variasi dalam sistem penyimpanan file antara host, dan 4) untuk mentransfer
Data andal dan efisien. FTP, meskipun dapat digunakan langsung oleh pengguna
di terminal, dirancang terutama untuk digunakan oleh program.
Upaya dalam spesifikasi ini adalah untuk memenuhi beragam kebutuhan
pengguna maxi-host, mini-host, workstation personal, dan TAC,
dengan sederhana, dan mudah diimplementasikan desain protokol.
Makalah ini mengasumsikan pengetahuan tentang Transmission Control Protocol
(TCP) [2] dan Protokol Telnet [3]. Dokumen-dokumen ini terkandung
dalam buku pegangan protokol ARPA-Internet [1].
2. GAMBARAN
Pada bagian ini, sejarah, terminologi, dan model FTP yang
dibahas. Ketentuan yang ditetapkan dalam bagian ini hanya orang-orang yang
memiliki arti khusus di FTP. Beberapa terminologi sangat
khusus untuk model FTP; beberapa pembaca mungkin ingin beralih ke
Bagian pada model FTP saat meninjau terminologi.
Postel & Reynolds [Halaman 1]
RFC 959 Oktober 1985
File Transfer Protocol
2.1. SEJARAH
FTP telah memiliki evolusi yang panjang selama bertahun-tahun. Lampiran III adalah
kompilasi kronologis Permintaan Komentar dokumen
berkaitan dengan FTP. Ini termasuk transfer file pertama kali diusulkan
mekanisme pada tahun 1971 yang dikembangkan untuk implementasi pada host
di M.I.T. (RFC 114), ditambah komentar dan diskusi dalam RFC 141.
RFC 172 tersedia protokol berorientasi user-level untuk transfer file
antara komputer host (termasuk terminal IMPS). Sebuah revisi
ini sebagai RFC 265, disajikan kembali FTP untuk ditinjau tambahan, sementara RFC 281
menyarankan perubahan lebih lanjut. Penggunaan "Set Data Type"
transaksi diusulkan pada RFC 294 pada Januari 1982.
RFC 354 RFC sudah usang 264 dan 265. File Transfer Protocol
sekarang didefinisikan sebagai protokol untuk transfer file antara host pada
ARPANET, dengan fungsi utama dari FTP didefinisikan sebagai
mentransfer file secara efisien dan andal antara host dan
memungkinkan penggunaan yang mudah dari kemampuan penyimpanan file jarak jauh.
RFC 385 lebih lanjut berkomentar pada kesalahan, poin penekanan, dan
penambahan protokol, sementara RFC 414 memberikan laporan status
pada server dan pengguna FTPs bekerja. RFC 430, yang diterbitkan pada tahun 1973,
(Antara RFC lain terlalu banyak untuk disebutkan) disajikan lebih lanjut
komentar di FTP. Akhirnya, "resmi" dokumen FTP adalah
diterbitkan sebagai RFC 454.
Pada bulan Juli 1973, perubahan besar dari versi terakhir dari FTP
yang dibuat, namun struktur umum tetap sama. RFC 542
diterbitkan sebagai "resmi" spesifikasi baru untuk mencerminkan ini
perubahan. Namun, banyak implementasi berdasarkan tua
spesifikasi tidak diperbarui.
Pada tahun 1974, RFC 607 dan 614 terus komentar pada FTP. RFC 624
diusulkan perubahan desain lebih lanjut dan modifikasi kecil. Pada tahun 1975,
RFC 686 yang berjudul, "Meninggalkan Nah Cukup Alone", membahas
perbedaan antara semua versi awal dan kemudian FTP.
RFC 691 disajikan revisi minor dari RFC 686, mengenai
subjek mencetak file.
Termotivasi oleh transisi dari NCP ke TCP sebagai
protokol yang mendasari, phoenix lahir dari semua di atas
upaya dalam RFC 765 sebagai spesifikasi FTP untuk digunakan pada TCP.
Edisi saat ini spesifikasi FTP dimaksudkan untuk
memperbaiki beberapa kesalahan dokumentasi kecil, untuk meningkatkan
penjelasan beberapa fitur protokol, dan menambahkan beberapa baru
perintah opsional.
Postel & Reynolds [Halaman 2]
RFC 959 Oktober 1985
File Transfer Protocol
Secara khusus, mengikuti perintah opsional baru termasuk dalam
edisi ini spesifikasi:
CDUP - Ubah ke direktori Parent
SMNT - Struktur Mount
Stou - Toko Unik
RMD - Hapus Direktori
MKD - Membuat Direktori
PWD - Direktori Cetak
SYST - Sistem
spesifikasi ini kompatibel dengan edisi sebelumnya. SEBUAH
Program dilaksanakan di kesesuaian dengan spesifikasi sebelumnya
secara otomatis berada dalam kesesuaian dengan spesifikasi ini.
2.2. TERMINOLOGI
ASCII
Set karakter ASCII sebagaimana didefinisikan dalam ARPA-Internet
Protokol Handbook. Dalam FTP, karakter ASCII didefinisikan sebagai
bagian bawah kode set delapan-bit (yaitu, paling
bit signifikan adalah nol).
kontrol akses
kontrol akses menentukan hak akses pengguna ke penggunaan
sistem, dan file dalam sistem itu. Akses kontrol yang
diperlukan untuk mencegah penggunaan yang tidak sah atau file tanpa disengaja.
Ini adalah hak prerogatif dari proses server-FTP untuk memohon akses
kontrol.
ukuran byte
Ada dua ukuran byte yang menarik di FTP: byte logis
ukuran file, dan ukuran transfer byte digunakan untuk
transmisi data. Ukuran Transfer byte selalu 8
bit. Ukuran Transfer byte belum tentu ukuran byte
di mana data akan disimpan dalam sistem, maupun byte logis
ukuran untuk interpretasi struktur data.
Postel & Reynolds [Halaman 3]
RFC 959 Oktober 1985
File Transfer Protocol
koneksi kontrol
Jalur komunikasi antara PENGGUNA-PI dan SERVER-PI untuk
pertukaran perintah dan balasan. Koneksi ini berikut
Telnet Protocol.
koneksi data
Sambungan duplex penuh atas data yang ditransfer, dalam
Modus yang ditentukan dan jenis. Data yang ditransfer dapat menjadi bagian dari
file, seluruh file atau beberapa file. path mungkin
antara server-DTP dan user-DTP, atau antara dua
server DTPS.
port data
Proses transfer data pasif "mendengarkan" pada port data
untuk koneksi dari proses transfer aktif untuk
membuka koneksi data.
DTP
Proses transfer data menetapkan dan mengelola data
koneksi. DTP dapat pasif atau aktif.
Akhir-of-Line
Akhir-of-line urutan mendefinisikan pemisahan pencetakan
baris. Urutannya adalah Carriage Return, diikuti oleh Line Feed.
EOF
Akhir-of-file kondisi yang mendefinisikan akhir file menjadi
ditransfer.
EOR
Akhir-of-record kondisi yang mendefinisikan akhir rekor
dipindahkan.
pemulihan kesalahan
Sebuah prosedur yang memungkinkan pengguna untuk pulih dari kesalahan tertentu
seperti kegagalan baik sistem host atau proses transfer. Di
FTP, pemulihan kesalahan mungkin melibatkan restart transfer file pada sebuah
diberikan pos pemeriksaan.
Postel & Reynolds [Halaman 4]
RFC 959 Oktober 1985
File Transfer Protocol
perintah FTP
Satu set perintah yang terdiri dari informasi kontrol yang mengalir
dari user-FTP untuk proses server-FTP.
mengajukan
Sebuah memerintahkan set data komputer (termasuk program), dari
panjang sewenang-wenang, unik diidentifikasi oleh pathname a.
mode
Modus di mana data yang akan ditransfer melalui data
koneksi. Modus yang mendefinisikan format data selama transfer
termasuk EOR dan EOF. Modus Transfer didefinisikan dalam FTP adalah
dijelaskan dalam Bagian pada Mode Transmisi.
NVT
Jaringan Virtual Terminal sebagaimana didefinisikan dalam Telnet Protocol.
NVFS
Jaringan Virtual File System. Sebuah konsep yang mendefinisikan
sistem file jaringan standar dengan perintah standar dan
konvensi pathname.
halaman
Sebuah file dapat disusun sebagai seperangkat bagian independen yang disebut
halaman. FTP mendukung pengiriman file terputus-putus sebagai
diindeks halaman independen.
pathname
Path didefinisikan sebagai string karakter yang harus
input ke sistem file oleh pengguna untuk mengidentifikasi file.
Pathname biasanya berisi nama perangkat dan / atau direktori, dan
mengajukan spesifikasi nama. FTP belum menentukan standar
konvensi pathname. Setiap pengguna harus mengikuti penamaan file
konvensi sistem file yang terlibat dalam transfer.
PI
Protokol interpreter. Pengguna dan server sisi
protokol telah peran yang berbeda diterapkan dalam user-PI dan
Server-PI.
Postel & Reynolds [Halaman 5]
RFC 959 Oktober 1985
File Transfer Protocol
merekam
Sebuah file sekuensial dapat disusun sebagai jumlah bersebelahan
bagian yang disebut catatan. struktur record yang didukung oleh FTP
tapi file tidak perlu memiliki struktur record.
balasan
Sebuah balasan adalah pengakuan (positif atau negatif) yang dikirim dari
server untuk pengguna melalui koneksi kontrol dalam menanggapi FTP
perintah. Bentuk umum dari balasan adalah kode selesai
(Termasuk kode kesalahan) diikuti dengan string teks. kode
adalah untuk digunakan oleh program dan teks biasanya ditujukan untuk
pengguna manusia.
Server-DTP
Proses transfer data, di "aktif" nya normal,
menetapkan koneksi data dengan "mendengarkan" data port.
Ini set up parameter untuk transfer dan penyimpanan, dan transfer
Data pada perintah dari PI-nya. DTP dapat ditempatkan dalam
"Pasif" negara untuk mendengarkan, daripada memulai
koneksi pada port data.
server FTP proses
Sebuah proses atau serangkaian proses yang melakukan fungsi
Transfer bekerjasama file dengan proses dan user-FTP,
mungkin, server lain. Fungsi terdiri dari protokol
interpreter (PI) dan proses transfer data (DTP).
Server-PI
Protokol ini interpreter "mendengarkan" di Pelabuhan L untuk
koneksi dari user-PI dan menetapkan kontrol
koneksi komunikasi. Ini menerima perintah FTP standar
dari user-PI, mengirimkan balasan, dan mengatur server-DTP.
mengetik
Jenis representasi data yang digunakan untuk transfer data dan
penyimpanan. Jenis menyiratkan transformasi tertentu antara waktu
penyimpanan data dan transfer data. Jenis representasi
didefinisikan dalam FTP dijelaskan dalam Bagian pada Membangun
Koneksi data.
Postel & Reynolds [Halaman 6]
RFC 959 Oktober 1985
File Transfer Protocol
pemakai
Seseorang atau suatu proses atas nama orang yang ingin mendapatkan
mengajukan layanan transfer. Pengguna manusia dapat berinteraksi secara langsung
dengan proses server-FTP, tetapi penggunaan proses user-FTP adalah
disukai karena desain protokol tertimbang terhadap
automata.
user-DTP
Proses transfer data "mendengarkan" pada port data untuk
sambungan dari proses server-FTP. Jika dua server
mentransfer data antara mereka, pengguna-DTP tidak aktif.
user-FTP proses
Satu set fungsi termasuk juru protokol, data
proses transfer dan user interface yang bersama-sama melakukan
fungsi transfer file bekerja sama dengan satu atau lebih
proses server-FTP. Antarmuka pengguna memungkinkan lokal
bahasa yang akan digunakan dalam perintah-balasan dialog dengan
pengguna.
user-PI
Protokol pengguna juru memulai koneksi kontrol
dari pelabuhan U untuk proses server-FTP, memulai FTP
perintah, dan mengatur user-DTP jika proses yang merupakan bagian dari
transfer file.
Postel & Reynolds [Halaman 7]
RFC 959 Oktober 1985
File Transfer Protocol
2.3. MODEL FTP
Dengan definisi di atas dalam pikiran, model berikut (ditampilkan di
Gambar 1) dapat digambarkan untuk layanan FTP.
-------------
| / --------- \ |
|| pengguna || --------
|| Antarmuka | <---> | pengguna |
| \ ---- ^ ---- / | --------
---------- | | |
| / ------ \ | FTP Perintah | / ---- V ---- \ |
|| Server | <----------------> | pengguna ||
|| PI || FTP Balasan || PI ||
| \ - ^ --- / | | \ ---- ^ ---- / |
| | | | | |
-------- | / - V --- \ | Data | / ---- V ---- \ | --------
| Berkas | <---> | Server | <----------------> | Pengguna | <---> | Berkas |
| Sistem | || DTP || koneksi || DTP || | Sistem |
-------- | \ ------ / | | \ --------- / | --------
---------- -------------
Server-FTP PENGGUNA-FTP
CATATAN: 1. sambungan data dapat digunakan di kedua arah.
2. sambungan data tidak perlu ada sepanjang waktu.
Gambar 1 Model untuk FTP Gunakan
Dalam model yang digambarkan pada Gambar 1, penafsir user-protokol
memulai koneksi kontrol. Koneksi kontrol berikut
protokol Telnet. Pada inisiasi pengguna, FTP standar
perintah dihasilkan oleh user-PI dan dikirim ke
proses server melalui koneksi kontrol. (Pengguna dapat
membuat sambungan kontrol langsung ke server-FTP, dari
terminal TAC misalnya, dan menghasilkan perintah FTP standar
independen, melewati proses user-FTP.) balasan Standar
dikirim dari server-PI ke user-PI alih kontrol
koneksi dalam menanggapi perintah.
Perintah FTP menentukan parameter untuk koneksi data
(Port data, modus transfer, jenis representasi, dan struktur) dan
sifat operasi sistem file (menyimpan, mengambil, menambahkan,
menghapus, dll). Pengguna-DTP atau menunjuk yang harus "mendengarkan" di
port data tertentu, dan server melakukan data
koneksi dan transfer data sesuai dengan yang ditentukan
parameter. Perlu dicatat bahwa port data tidak perlu di
Postel & Reynolds [Halaman 8]
RFC 959 Oktober 1985
File Transfer Protocol
host yang sama yang memulai perintah FTP melalui kontrol
koneksi, namun pengguna atau proses user-FTP harus memastikan
"Mendengarkan" pada port data tertentu. Seharusnya juga dicatat
bahwa koneksi data dapat digunakan untuk simultan mengirim dan
menerima.
Dalam situasi lain pengguna mungkin ingin mentransfer file antara
dua host, baik yang merupakan host lokal. pengguna set up
koneksi kontrol ke dua server dan kemudian mengatur untuk
koneksi data di antara mereka. Dengan cara ini, kontrol informasi
diteruskan ke user-PI tetapi data yang ditransfer antara
Server proses transfer data. Berikut ini adalah model ini
interaksi server-server.
------------ Kontrol kontrol
----------> | User-FTP | <-----------
| | User-PI | |
| | "C" | |
V ------------ V
-------------- --------------
| Server-FTP | Data Connection | Server-FTP |
| "A" | <----------------------> | "B" |
-------------- Pelabuhan (A) Pelabuhan (B) --------------
Gambar 2
Protokol mensyaratkan bahwa koneksi kontrol terbuka sementara
transfer data berlangsung. Ini adalah tanggung jawab
pengguna untuk meminta penutupan koneksi kontrol saat
selesai menggunakan layanan FTP, sementara itu adalah server yang mengambil
tindakan. server dapat membatalkan transfer data jika kontrol
koneksi ditutup tanpa perintah.
Hubungan antara FTP dan Telnet:
FTP menggunakan protokol Telnet pada koneksi kontrol.
Hal ini dapat dicapai dengan dua cara: pertama, user-PI atau
Server-PI mungkin menerapkan aturan Telnet Protocol
langsung dalam prosedur mereka sendiri; atau, kedua, user-PI atau
server-PI dapat menggunakan modul Telnet yang ada di
sistem.
Kemudahan implementaion, kode berbagi, dan pemrograman modular
berdebat untuk pendekatan kedua. Efisiensi dan kemandirian
Postel & Reynolds [Page 9]
RFC 959 Oktober 1985
File Transfer Protocol
berdebat untuk pendekatan pertama. Dalam prakteknya, FTP mengandalkan sangat
sedikit dari Telnet Protocol, sehingga pendekatan pertama tidak
perlu melibatkan sejumlah besar kode.
3. FUNGSI TRANSFER DATA
File yang ditransfer hanya melalui koneksi data. Kontrol
koneksi digunakan untuk transfer perintah, yang menggambarkan
fungsi yang harus dilakukan, dan balasan perintah tersebut (lihat
Bagian atas Balasan FTP). Beberapa perintah prihatin dengan
transfer data antara host. perintah transfer data ini meliputi
perintah MODE yang menentukan bagaimana bit data yang menjadi
ditransmisikan, dan struktur dan TYPE perintah, yang digunakan untuk
menentukan cara di mana data yang akan diwakili. Itu
transmisi dan representasi pada dasarnya independen tetapi
"Stream" mode transmisi tergantung pada struktur file
atribut dan jika mode transmisi "Compressed" digunakan, sifat
dari byte filler tergantung pada jenis representasi.
3.1. PERNYATAAN DATA DAN PENYIMPANAN
Data ditransfer dari perangkat penyimpanan di tuan rumah pengiriman ke
perangkat penyimpanan di host penerima. Sering perlu untuk
melakukan transformasi tertentu pada data karena penyimpanan data
representasi dalam dua sistem yang berbeda. Sebagai contoh,
NVT-ASCII memiliki representasi penyimpanan data yang berbeda di berbagai
sistem. Desember TOPS-20-an umumnya menyimpan NVT-ASCII lima 7-bit
karakter ASCII, kiri-dibenarkan dalam kata 36-bit. IBM Mainframe ini
toko NVT-ASCII sebagai 8-bit kode EBCDIC. toko Multics NVT-ASCII
empat karakter 9-bit dalam satu kata 36-bit. Hal ini diinginkan untuk
mengkonversi karakter ke dalam standar NVT-ASCII representasi ketika
transmisi teks antara sistem yang berbeda. Pengiriman dan
menerima situs harus melakukan yang diperlukan
transformasi antara representasi standar dan mereka
representasi internal.
Sebuah masalah yang berbeda dalam representasi muncul ketika transmisi
data biner (tidak kode karakter) antara sistem host dengan
panjang kata yang berbeda. Hal ini tidak selalu jelas bagaimana pengirim
harus mengirim data, dan penerima menyimpannya. Misalnya, ketika
transmisi byte 32-bit dari 32-bit kata-panjang sistem ke
36-bit sistem kata-panjang, mungkin diinginkan (untuk alasan
efisiensi dan kegunaan) untuk menyimpan byte 32-bit
benar-benar dalam kata 36-bit dalam sistem yang terakhir. dalam setiap
kasus, pengguna harus memiliki pilihan untuk menentukan data
representasi dan transformasi fungsi. Perlu dicatat
Postel & Reynolds [Halaman 10]
RFC 959 Oktober 1985
File Transfer Protocol
yang FTP menyediakan sangat terbatas tipe data representasi.
Transformasi yang diinginkan di luar kemampuan terbatas ini harus
dilakukan oleh pengguna secara langsung.
3.1.1. JENIS DATA
representasi data ditangani dalam FTP oleh pengguna menentukan
Jenis representasi. Jenis ini dapat secara implisit (seperti dalam ASCII atau
EBCDIC) atau secara eksplisit (seperti dalam byte lokal) mendefinisikan ukuran byte untuk
interpretasi yang disebut sebagai "ukuran byte logis."
Catatan bahwa ini tidak ada hubungannya dengan ukuran byte yang digunakan untuk
pengiriman melalui sambungan data, yang disebut "Transfer
ukuran byte ", dan dua tidak harus bingung. Misalnya,
NVT-ASCII memiliki ukuran byte logis dari 8 bit. Jika jenisnya adalah
byte lokal, maka perintah TYPE memiliki kedua wajib
parameter menentukan ukuran byte logis. Transfer byte
Ukuran selalu 8 bit.
3.1.1.1. ASCII TYPE
Ini adalah jenis default dan harus diterima oleh semua FTP
implementasi. Hal ini dimaksudkan terutama untuk transfer
file teks, kecuali jika kedua host akan menemukan EBCDIC
mengetik lebih nyaman.
Pengirim mengkonversi data dari karakter internal yang
representasi dengan standar 8-bit NVT-ASCII
representasi (lihat spesifikasi Telnet). Penerima
akan mengkonversi data dari bentuk standar untuk sendiri
bentuk internal.
Sesuai dengan standar NVT, yang <CRLF> urut
harus digunakan bila perlu untuk menunjukkan akhir baris
teks. (Lihat pembahasan struktur file di akhir
Seksi pada Perwakilan Data dan Storage.)
Menggunakan standar representasi NVT-ASCII berarti data yang
harus ditafsirkan sebagai 8-bit byte.
Format parameter untuk ASCII dan EBCDIC jenis dibahas
di bawah.
Postel & Reynolds [Halaman 11]
RFC 959 Oktober 1985
File Transfer Protocol
3.1.1.2. TYPE EBCDIC
Jenis ini dimaksudkan untuk transfer efisien antara host
yang menggunakan EBCDIC untuk karakter internal mereka
perwakilan.
Untuk transmisi, data direpresentasikan sebagai 8-bit EBCDIC
karakter. Kode karakter adalah satu-satunya perbedaan
antara spesifikasi fungsional dari EBCDIC dan ASCII
jenis.
End-of-line (sebagai lawan untuk mengakhiri-of-record - lihat diskusi
struktur) mungkin akan jarang digunakan dengan jenis EBCDIC
untuk tujuan struktur yang menunjukkan, tapi di mana itu adalah
diperlukan dalam <NL> karakter harus digunakan.
3.1.1.3. IMAGE TYPE
Data tersebut dikirim sebagai bit bersebelahan yang, untuk transfer,
yang dikemas dalam transfer byte 8-bit. penerima yang
situs harus menyimpan data sebagai bit bersebelahan. Struktur
dari sistem penyimpanan mungkin memerlukan padding dari
file (atau dari setiap record, untuk file rekaman-terstruktur) untuk
beberapa batas nyaman (byte, kata atau blok). Ini
padding, yang harus semua nol, dapat terjadi hanya di akhir
file (atau pada akhir setiap record) dan harus ada
cara mengidentifikasi padding bit sehingga mereka mungkin
menanggalkan jika file yang diambil. padding
transformasi harus dipublikasikan dengan baik untuk memungkinkan pengguna untuk
memproses file di situs penyimpanan.
Jenis gambar ini dimaksudkan untuk penyimpanan yang efisien dan
pengambilan file dan untuk transfer data biner. Saya t
Disarankan bahwa jenis ini dapat diterima oleh semua FTP
implementasi.
3.1.1.4. TYPE LOKAL
Data ditransfer dalam byte logis dari ukuran
ditentukan oleh wajib kedua parameter, ukuran Byte.
Nilai ukuran Byte harus bilangan bulat desimal; ada
tidak ada nilai default. Ukuran byte logis tidak selalu
sama dengan ukuran transfer byte. Jika ada
Perbedaan dalam ukuran byte, maka byte logis harus
dikemas contiguously, mengabaikan batas Transfer byte
dan dengan padding yang diperlukan di akhir.
Postel & Reynolds [Halaman 12]
RFC 959 Oktober 1985
File Transfer Protocol
Ketika data mencapai host penerima, maka akan
diubah dengan cara tergantung pada ukuran byte logis
dan host tertentu. transformasi ini harus
dibalik (yaitu, file yang sama dapat diambil jika
parameter yang sama digunakan) dan harus dipublikasikan dengan baik oleh
pelaksana FTP.
Misalnya, pengguna mengirimkan 36-bit floating-point untuk
host dengan kata 32-bit bisa mengirim data sebagai byte lokal
dengan ukuran byte logis dari 36. host penerima akan
maka diharapkan untuk menyimpan byte logis sehingga mereka
bisa dengan mudah dimanipulasi; dalam contoh ini menempatkan
36-bit byte logis ke 64-bit kata-kata ganda harus
cukup.
Dalam contoh lain, sepasang host dengan ukuran word 36-bit
dapat mengirimkan data ke satu sama lain dalam kata-kata dengan menggunakan TYPE L 36.
Data akan dikirim dalam byte transmisi 8-bit
dikemas sehingga 9 byte transmisi dilakukan dua kata tuan.
3.1.1.5. FORMAT KONTROL
Jenis ASCII dan EBCDIC juga mengambil kedua (opsional)
parameter; ini adalah untuk menunjukkan apa jenis format vertikal
kontrol, jika ada, terkait dengan file. Pengikut
jenis representasi data didefinisikan dalam FTP:
Sebuah file karakter dapat ditransfer ke host untuk salah satu
tiga tujuan: untuk pencetakan, penyimpanan dan kemudian
pengambilan, atau untuk pengolahan. Jika file yang dikirim untuk
pencetakan, host penerima harus tahu bagaimana vertikal
kontrol Format diwakili. Dalam kasus kedua, itu harus
mungkin untuk menyimpan file di host dan kemudian mengambilnya
kemudian di bentuk yang sama persis. Akhirnya, itu harus
mungkin untuk memindahkan file dari satu host ke yang lain dan proses
file di host kedua tanpa kesulitan yang tidak semestinya. Tunggal
ASCII atau EBCDIC format tidak memenuhi semua ini
kondisi. Oleh karena itu, jenis ini memiliki parameter kedua
menentukan salah satu dari tiga format berikut:
3.1.1.5.1. PRINT NON
Ini adalah format default yang akan digunakan jika kedua
(Format) parameter dihilangkan. format non-cetak harus
diterima oleh semua implementasi FTP.
Postel & Reynolds [Halaman 13]
RFC 959 Oktober 1985
File Transfer Protocol
file perlu berisi informasi format yang vertikal. Jika
itu akan diteruskan ke proses printer, proses ini mungkin
mengasumsikan nilai standar untuk jarak dan margin.
Biasanya, format ini akan digunakan dengan file ditakdirkan
untuk pengolahan atau hanya penyimpanan.
3.1.1.5.2. KONTROL TELNET FORMAT
File ini berisi ASCII / EBCDIC Format vertikal kontrol
(Yaitu, <CR>, <LF>, <NL>, <VT>, <FF>) yang printer
Proses akan menafsirkan dengan tepat. <CRLF>, persis
urutan ini, juga menunjukkan akhir-of-line.
3.1.1.5.2. PENGANGKUTAN KONTROL (ASA)
File ini berisi ASA (FORTRAN) kontrol Format vertikal
karakter. (Lihat RFC 740 Lampiran C; dan Komunikasi
dari ACM, Vol. 7, No 10, p. 606, Oktober 1964.) Dalam
line atau catatan diformat sesuai dengan Standar ASA,
karakter pertama tidak akan dicetak. Sebaliknya,
harus digunakan untuk menentukan pergerakan vertikal dari
kertas yang harus dilakukan sebelum sisa
catatan dicetak.
ASA Standard menentukan kontrol berikut
karakter:
Karakter Spasi Vertikal
kosong Pindahkan kertas sampai satu baris
0 Pindahkan kertas sampai dua baris
1 Pindahkan kertas ke atas halaman berikutnya
+ Tidak ada gerakan, yaitu, mencetak
Jelas harus ada beberapa cara untuk proses printer untuk
membedakan akhir entitas struktural. Jika file
memiliki catatan struktur (lihat di bawah) ini tidak ada masalah;
catatan akan secara eksplisit ditandai selama transfer dan
penyimpanan. Jika berkas ini tidak memiliki struktur record, yang <CRLF>
end-of-line urutan digunakan untuk memisahkan jalur pencetakan,
tapi format efektor ini diganti oleh ASA
kontrol.
Postel & Reynolds [Halaman 14]
RFC 959 Oktober 1985
File Transfer Protocol
3.1.2. STRUKTUR DATA
Selain jenis representasi yang berbeda, FTP memungkinkan
struktur file yang akan ditentukan. Tiga struktur berkas yang
didefinisikan dalam FTP:
File-struktur, di mana tidak ada struktur internal dan
file tersebut dianggap sebagai
urutan yang kontinu byte data,
record-struktur, di mana file tersebut terdiri dari berurutan
catatan,
dan halaman-struktur, di mana file tersebut terdiri dari independen
halaman diindeks.
File-struktur adalah default yang akan diasumsikan jika struktur
Perintah belum digunakan namun kedua berkas dan struktur record
harus diterima untuk "text" file (misalnya, file dengan TYPE ASCII
atau EBCDIC) oleh semua implementasi FTP. Struktur file
akan mempengaruhi baik modus transfer file (lihat Bagian yang
pada Mode Transmisi) dan interpretasi dan penyimpanan
berkas.
"Alami" struktur file akan tergantung pada tuan rumah
menyimpan file. Sebuah file source-code biasanya akan disimpan di
Mainframe IBM dalam catatan panjang tetap tetapi pada Desember TOPS-20
sebagai aliran karakter dipartisi ke baris, misalnya
oleh <CRLF>. Jika transfer file antara yang berbeda seperti
situs ini untuk menjadi berguna, harus ada beberapa cara untuk satu situs ke situs
mengenali asumsi lain tentang file.
Dengan beberapa situs yang secara alami mengajukan berorientasi dan lain-lain
alami merekam berorientasi mungkin ada masalah jika sebuah file dengan
satu struktur dikirim ke host yang berorientasi ke yang lain. Jika sebuah
file teks yang dikirim dengan catatan-struktur ke host yang berkas
berorientasi, maka host harus menerapkan internal
transformasi ke file berdasarkan struktur record.
Jelas, transformasi ini harus berguna, tapi harus
juga dapat dibalik sehingga file yang sama dapat diambil
menggunakan struktur record.
Dalam kasus file yang dikirim dengan berkas-struktur untuk
record-berorientasi tuan rumah, terdapat pertanyaan tentang apa
Kriteria tuan rumah harus digunakan untuk membagi file ke dalam catatan
yang dapat diproses secara lokal. Jika divisi ini diperlukan,
pelaksanaan FTP harus menggunakan end-of-line urutan,
Postel & Reynolds [Halaman 15]
RFC 959 Oktober 1985
File Transfer Protocol
<CRLF> untuk ASCII, atau <NL> untuk file teks EBCDIC, sebagai
pembatas. Jika implementasi FTP mengadopsi teknik ini,
harus siap untuk membalikkan transformasi jika file tersebut
diambil dengan berkas-struktur.
3.1.2.1. FILE STRUKTUR
struktur file adalah default yang akan diasumsikan jika struktur
Perintah belum digunakan.
Dalam file-struktur tidak ada struktur internal dan
File dianggap urutan data terus menerus
bytes.
3.1.2.2. REKOR STRUKTUR
struktur catatan harus diterima untuk "text" file (yaitu,
file dengan TYPE ASCII atau EBCDIC) oleh semua implementasi FTP.
Dalam catatan-struktur file terdiri dari berurutan
catatan.
3.1.2.3. HALAMAN STRUKTUR
Untuk mengirimkan file yang terputus-putus, FTP mendefinisikan halaman
struktur. File jenis ini kadang-kadang dikenal sebagai
"File akses acak" atau bahkan sebagai "file berlubang". dalam
file ada informasi kadang-kadang lain yang terkait dengan
file secara keseluruhan (misalnya, file descriptor), atau dengan
bagian dari file (misalnya, kontrol akses halaman), atau keduanya.
Dalam FTP, bagian dari file yang disebut halaman.
Untuk menyediakan berbagai ukuran halaman dan terkait
informasi, setiap halaman dikirim dengan header halaman. Halaman
Header memiliki bidang yang didefinisikan sebagai berikut:
Header panjang
Jumlah byte logis dalam header halaman
termasuk byte ini. Panjang Header minimum adalah 4.
Indeks halaman
Logis nomor halaman dari bagian file.
Ini bukan nomor urut transmisi ini
Halaman, tetapi indeks yang digunakan untuk mengidentifikasi halaman ini dari
mengajukan.
Postel & Reynolds [Halaman 16]
RFC 959 Oktober 1985
File Transfer Protocol
Data panjang
Jumlah byte logis dalam data halaman. Itu
minimum panjang data adalah 0.
halaman Type
Jenis halaman ini. Jenis halaman berikut
didefinisikan:
0 = Akhir
Ini digunakan untuk menunjukkan akhir paged sebuah
transmisi terstruktur. Panjang Header keharusan
menjadi 4, dan panjang data harus 0.
1 = Simple Halaman
Ini adalah jenis normal untuk file paged sederhana
tanpa kontrol level halaman yang terkait
informasi. Panjang Header harus 4.
2 = Descriptor Halaman
Jenis ini digunakan untuk mengirimkan deskriptif
informasi untuk file secara keseluruhan.
3 = Akses Terkendali Halaman
Jenis ini termasuk kolom header tambahan
untuk file paged dengan kontrol akses tingkat halaman
informasi. Panjang Header harus 5.
Fields opsional
field header lanjut dapat digunakan untuk memasok per halaman
mengontrol informasi, misalnya, per akses halaman
kontrol.
Semua bidang yang satu byte logis panjang. Byte logis
Ukuran ditentukan oleh perintah TYPE. Lihat Lampiran I untuk
Rincian lebih lanjut dan kasus tertentu di struktur halaman.
Sebuah catatan dari hati-hati tentang parameter: file harus disimpan dan
diambil dengan parameter yang sama jika versi diambil adalah untuk
Postel & Reynolds [Halaman 17]
RFC 959 Oktober 1985
File Transfer Protocol
identik dengan versi awalnya dikirim. Sebaliknya,
implementasi FTP harus kembali file identik dengan aslinya
jika parameter yang digunakan untuk menyimpan dan mengambil file yang sama.
3.2. MEMBANGUN KONEKSI DATA
Mekanisme mentransfer data terdiri dari menyiapkan data
koneksi ke port yang sesuai dan memilih parameter
untuk transfer. Baik pengguna dan server-DTPS memiliki default
port data. Pengguna-proses port data default adalah sama dengan
control port koneksi (yaitu, U). Server-proses standar
port data adalah port berdekatan dengan kontrol port koneksi
(Yaitu, L-1).
Ukuran Transfer byte adalah 8-bit byte. Ukuran byte ini relevan
hanya untuk transfer sebenarnya dari data; tidak memiliki bantalan pada
representasi data dalam sistem file host.
Proses transfer data pasif (ini mungkin user-DTP atau
kedua server DTP) akan "mendengarkan" pada port data sebelum
mengirimkan perintah permintaan transfer. FTP permintaan perintah
determines the direction of the data transfer.
Sumber : https: //www.ietf.org/rfc/rfc959.txt
0 Response to "FTP "
Post a Comment