پرش به محتوا

پروتکل انتقال فایل

از ویکی‌پدیا، دانشنامهٔ آزاد
(تغییرمسیر از انتقال فایل)
پروتکل انتقال فایل ( File Transfer Protocol )

اف‌تی‌پی (به انگلیسی: ‎FTP[۱]) یا قاپ[۲] (قرارداد انتقال پرونده)، قرارداد (پروتکلی) است که در شبکه‌های رایانه‌ای برای جابه‌جایی پرونده از مبدأ به مقصد مورد استفاده قرار می‌گیرد.

درمیان رایانه‌های میزبان، اف‌تی‌پی به‌طور ویژه یک قراردادِ متداول برای دادوستد فرمان‌ها و پرونده‌ها در هر شبکه پشتیبان از قرارداد اینترنت و قرارداد هدایت انتقال (TCP/IP) (مانند اینترنت و اینترانت) است. درگاه (پورت) پیش‌فرض برای خدمات قاپ، درگاه 21/TCP و برای انتقال داده از درگاه 20/TCP استفاده می‌کند.

در یک انتقال اف‌تی‌پی دو رایانه دخیل است، یک کارساز و یک کاربر. کارساز (سرور) قاپ، برنامه‌های کارساز اف‌تی‌پی را اجرا می‌کند، و درخواست پذیرش در شبکه را رایانهٔ دیگر (یعنی کاربر) مطرح می‌کند. رایانهٔ کاربر برنامه‌های کاربری اف‌تی‌پی را اجرا و یک ارتباط با کارساز بر قرار می‌کند.

هنگامی که یک ارتباط برقرار می‌شود کاربر می‌تواند تعدادی از برنامه‌ها را تغییر دهد (دستکاری محدود)، مانند بارگذاری پرونده در کارساز و بارگیری پرونده از آن، یا بازنامیدن یا حذف پرونده‌ها در کارساز و مانند این‌ها.

هر شخص یا شرکت برنامه‌ساز می‌تواند یک کارساز قاپ یا برنامه‌های کاربری ایجاد کند، چرا که این قراردادی آزاد است.

در واقع همهٔ بسترهای رایانه‌ای از اف‌تی‌پی پشتیبانی می‌کنند و به هر ارتباط رایانه‌ای که بر اساس قرارداد هدایت انتقال/قرارداد اینترنت باشد صرف‌نظر از این که از چه سامانهٔ عاملی استفاده می‌شود، اگر رایانه‌ها اجازهٔ دسترسی به قاپ را داشته باشند، این اجازه را می‌دهد که در پرونده‌های رایانهٔ دیگر در این شبکه تغییراتی ایجاد کند.

خدمات پروتکل انتقال فایل (FTP)

[ویرایش]
  • تهیهٔ لیستی از فایل‌های موجود از سیستم فایل کامپیوتر راه دور
  • حذف، تغییرنام و جابجا کردن فایل‌های کامپیوتر راه دور
  • جستجو در شاخه‌های کامپیوتر راه دور
  • ایجاد یا حذف شاخه روی کامپیوتر راه دور
  • انتقال (بارگذاری) فایل از کامپیوتر راه دور به کامپیوتر میزبان (download)
  • انتقال فایل و ذخیرهٔ آن از کامپیوتر میزبان به کامپیوتر راه دور (upload)

قابلیت‌هایی که پروتکل FTP عرضه می‌کند همانند Telnet می‌تواند برای سیستم سرویس دهنده بسیار خطرناک باشد زیرا به سادگی می‌توان فایل‌های یک کامپیوتر راه دور را آلوده یا نابود کرد. پس در این پروتکل کاربران باید قبل از تقاضای هر سرویسی شناسه و کلمهٔ عبور خود را وارد کنند و سرویس دهنده پس از احراز هویت کاربر، سطح دسترسی و عملیات مجاز برای کاربر را تعیین می‌کند و یک نشست FTP آغاز می‌شود.[۳]

روش‌های برقراری یک نشست FTP

[ویرایش]

ایجاد نشست بین سرویس دهنده و مشتری FTP با دو روش امکان‌پذیر است:

  • روش معمولی یا Normal Mode
  • روش غیرفعال یا Passive Mode

روش معمولی برقراری نشست:

برای برقراری یک نشست FTP به روش معمولی مراحل زیر انجام می‌شود:

الف) در برنامهٔ سمت مشتری ابتدا دو سوکت نوع TCP با شماره پورت تصادفی بالای ۱۰۲۴ ایجاد می‌شود.

ب) در مرحلهٔ دوم برنامهٔ سمت مشتری سعی می‌کند با استفاده از دستور ()connect اتصال یکی از سوکت‌های ایجاد شده را با پورت شماره ۲۱ از سرویس دهنده برقرار نماید. اگر این اتصال برقرار شود در حقیقت کانال فرمان باز شده و پروسه PIآماده تفسیر فرامین صادره از سمت مشتری است.

ج) برنامهٔ سمت مشتری با فرمان "PORT x" به برنامهٔ سمت سرویس دهنده شمارهٔ پورت سوکت دوم را اعلام می‌نماید و منتظر می‌ماند. (در حقیقت برنامه مشتری روی سوکت دوم عمل ()listen انجام می‌دهد)

د) در ادامه برنامهٔ سرویس دهنده سعی می‌کند یک اتصال TCP با شماره پورت اعلام شده از مشتری برقرار نماید. یکی از نتایج عجیب در این پروتکل آن است که سرویس دهنده FTP موظف است اقدام به برقراری یک اتصال TCP از طریق دستور ()connect با برنامه مشتری نماید در صورتی که معمولاً سرویس دهنده‌ها پذیرندهٔ اتصال هستند نه شروع کننده!. البته باید توجه کرد که به هرحال اتصال اول را مشتری ایجاد کرده‌است.

ه) برنامه سمت مشتری اتصال TCP شروع شده از سرویس دهنده را تصدیق کرده و یک نشست FTP آغاز می‌شود. ابتدا برنامهٔ سمت مشتری دو سوکت مجزا باز کرده و شماره پورت‌های دلخواه و تصادفی (مثل ۵۱۵۰ و ۵۱۵۱) را به آن‌ها مقید می‌کند. سپس از طریق سوکت اول یک اتصال TCP با پورت ۲۱ از سرویس دهنده برقرار کرده و پس از برقراری اتصال، با ارسال فرمان "PORT 5151" شماره پورت سوکت دوم خود را اعلام می‌کند. برنامهٔ سمت سرویس دهنده ضمن تصدیق پذیرش درخواست نشست، بلافاصله اقدام به برقراری یک اتصال TCP بین پورا ۲۰ خودش و پورت دوم (شماره ۵۱۵۱) از مشتری می‌نماید. با تصدیق این اتصال توسط مشتری نشست FTP آغاز می‌شود.

روش غیرفعال برقراری نشست

[ویرایش]

برای برقراری یک نشست FTP به روش غیرفعال تعاملات زیر لازم است:

الف) در برنامه سمت مشتری ابتدا دو سوکت نوع TCP با شماره پورت تصادفی بالای ۱۰۲۴ ایجاد می‌شود.

ب) برنامهٔ سمت مشتری سعی می‌کند اتصال TCP یکی از سوکت‌های ایجاد شده را با پورت شمارهٔ ۲۱ از سرویس دهنده برقرار نماید. با برقراری این ارتباط کانال فرمان باز شده و پروسهٔ PI آمادهٔ تفسیر فرامین صادره از سمت مشتری خواهد بود.

ج) برنامهٔ سمت مشتری با فرمان PASV به برنامهٔ سمت سرویس دهنده اعلام می‌کند که خواستار یک نشست از نوع غیرفعال است.

د) برنامهٔ سمت سرویس دهنده یک سوکت با شماره پورت تصادفی بالای ۱۰۲۴ ایجاد کرده و شمارهٔ آن را به برنامهٔ مشتری اعلام می‌نماید.

ه) برنامهٔ سمت مشتری اتصال سوکت دوم خود را با شماره پورت اعلام شده برقرار کرده پس از تصدیق اتصال، نشست FTP آغاز می‌شود.[۳]

تاریخچه

[ویرایش]

FTP یا قرارداد انتقال فایل اولین بار در سال ۱۹۷۱ توسط "آبهای بوشان" و تحت عنوان RFC114 (مخفف "درخواست برای توضیحات"۱) منتشر شد که به منظور قرارداد برای انتقال فایل بین شبکه آرپانت (ARPANET)؛ شبکه ای از کامپیوترها که شامل چند مرکز نظامی و دانشگاهی و عده کمی از افراد می‌شد استفاده می‌شد. سپس اصلاحاتی در این قرار داد صورت گرفت و765 RFC و RFC 959. چون در ابتدای ایجاد شبکه کامپیوتری تعداد کامپیوترها و کاربران کم و شناخته شده بودند مسائل امنیتی مهم نبود و به همین دلیل قرارداد انتقال فایل شامل نکات امنیتی نمی‌شد با گسترش شبکه کامپیوتر و افزایش ناگهانی کاربران آن نیاز به پر کردن این خلاء امنیتی احساس شد و RFC 2228 و RFC 2428 ارائه شدند

جستارهای وابسته

[ویرایش]

منابع

[ویرایش]
  1. File Transfer Protocol
  2. واژهٔ مصوب فرهنگستان زبان و ادب فارسی، دفتر نخست تا چهارم بایگانی‌شده در ۳ اوت ۲۰۰۹ توسط Wayback Machine، ۱۳۷۶ تا ۸۵
  3. ۳٫۰ ۳٫۱ اصول مهندسی اینترنت دکتر احسان ملکیان، ویراست دوم، چاپ سی و نهم
  • دانشنامهٔ آزاد ویکی‌پدیا، نسخه انگلیسی#
  1. Request for Comments: 114 ;
    1. http://tools.ietf.org/html/rfc114
    2. Request for Comments 765 ; tools.ietf.org/html/rfc765
    3. Request for Comments: 995 ; tools.ietf.org/html/rfc959
    4. Request for Comments: 995 ; tools.ietf.org/html/rfc2228
    5. Request for Comments: 995 ; tools.ietf.org/html/rfc2428