VIP برنامه نویسی Client Side

☾♔TALAYEH_A♔☽ · 2019/01/29

کدهای وضعیت
از نسخهٔ ۱٫۰ پروتکل انتقال ابرمتن به بعد، خطِ اولِ پاسخِ سرور تحت عنوان خط وضعیت شناخته شده‌است. این خط حاوی یک کد عددی (مانند ۴۰۴) که به عنوان کد وضعیت شناخته می‌شود و یک پیام متنی (مانند "یافت نشد" یا "Not Found") که با عنوان علت وضعیت شناخته می‌شود، می‌باشد. نحوهٔ برخورد عامل کاربر با پاسخ، بستگی کامل به کد وضعیت و فیلدهای سرآیند بستهٔ پاسخ دارد. با این حال استفاده از کدهای سفارشی (که در پروتکل اصلی موجود نیستند) نیز بلامانع می‌باشد. زیرا عوامل کاربر در برخورد با کدهای تعریف نشده، از رقم اول عدد آن‌ها برای شناسایی نوع کلی کد استفاده می‌کنند.[۱][بخش ۶٫۱]

کدهای وضعیت پروتکل انتقال ابرمتن به ۵ دستهٔ کلی تقسیم می‌شوند:

کدهای 1xx یا اطلاعاتی: این کدها با عدد ۱ آغاز می‌شوند. این گروه، این پیام کلی را مشخص می‌کنند: «درخواست شما دریافت شد، ادامه دهید».
کدهای 2xx یا موفقیت: این کدها با عدد ۲ آغاز می‌شوند. یعنی «درخواستِ ارسالی دریافت شده، درک شده، پذیرفته شده و با موفقیت انجام شده‌است».
کدهای 3xx یا تغییر مسیر: این کدها با عدد ۳ آغاز می‌شوند. یعنی «کلاینت برای کامل شدن درخواست نیازمند انجام عملیات اضافی است».
کدهای 4xx یا خطای کلاینت: این کدها با عدد ۴ آغاز می‌شوند. این گروه از کدها مشخص می‌کنند که «کلاینت در درخواست خود اشتباه کرده یا باعث بروز خطا شده‌است».
کدهای 5xx یا خطای سرور: این کدها با عدد ۵ آغاز می‌شوند. با این مفهوم که «سرور در انجام عملیات مربوط به یک بستهٔ درخواستِ ظاهراً صحیح، ناموفق بوده و با خطا مواجه شده‌است».

علت وضعیتهایی که در متن تعریف پروتکل آمده‌اند پیشنهادی بوده و می‌توانند با متون دیگر، به صلاحِ دید توسعه دهنده، تغییر پیدا کنند. این عبارت می‌تواند توسط عامل کاربر به عنوان توضیحات اضافی به کاربر نمایش داده شود.

☾♔TALAYEH_A♔☽ · 2019/01/29

مثال
در زیر مثالی از یک جلسه بین یک کلاینت HTTP و یک سرور HTTP که بر روی

Please, ورود or عضویت to view URLs content!

قرار دارد، ارائه شده‌است.

درخواست کلاینت
GET /index.html HTTP/1.1
Host:

Please, ورود or عضویت to view URLs content!

☾♔TALAYEH_A♔☽ · 2019/01/29

در درخواست کلاینت، خط اول روش، نشانی و نسخهٔ پروتکل استفاده شده در درخواست را مشخص می‌کند. از خط دوم هر خط حاوی یک فیلد سرآیند (به انگلیسی: Header Field) می‌باشد و این فیلدها با یک خط خالی به پایان می‌رسند. پایان هر خط در این پروتکل با ۲ حرف Carriage Return و Line Feed پشتِ‌سرهم مشخص می‌شود. (r\n\)

پاسخ سرور
HTTP/1.1 200 OK
Date: Mon, ۲۳ مه ۲۰۰۵ ۲2:38:34 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
Last-Modified: Wed, ۰۸ ژانویه ۲۰۰۳ ۲3:11:55 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 131
Connection: close

<html>
<head>
<title>An Example Page</title>
</head>
<body>
Hello World, this is a very simple HTML document.
</body>
</html>

☾♔TALAYEH_A♔☽ · 2019/01/29

در پاسخ سرور، خط اول، که خط وضعیت نامیده می‌شود، یکی از وضعیت‌های تعریف شده در پروتکل را مشخص می‌کند. در اینجا کد وضعیت ۲۰۰ به معنای صحیح و مجاز بودن درخواست می‌باشد. از خط دوم، هر خط حاوی یک فیلد سرآیند (به انگلیسی: Header Field) پاسخ است. این فیلدها با یک خط خالی به پایان می‌رسند. پایان هر خط نیز مانند بستهٔ درخواست با ۲ حرف Carriage Return و Line Feed پشتِ‌سرِهم مشخص می‌شود. بعد از یک خط خالی (که به معنای پایان فیلدهای سرآیند است)، بدنه پاسخ آغاز می‌شود. طول بدنهٔ پاسخ معمولاً در فیلد سرآیند Content-Length توسط سرور مشخص می‌شود. در صورتی که این فیلد مشخص نشود، اطلاعات ارسالی تا بسته شدن کامل ارتباط، بدنهٔ پاسخ محسوب خواهند شد.

☾♔TALAYEH_A♔☽ · 2019/01/29

HTTP

تداوم
Compression
HTTPS

روش‌های درخواست

POST
PUT
DELETE
TRACE
CONNECT
PATCH

زمینه‌های سرآیند

Cookie
ETag
Location
HTTP referer
DNT
X-Forwarded-For

کدهای وضعیت

۳۰۱ برای همیشه منتقل شده
۳۰۲ موقتا منتقل شده
۳۰۳ موارد دیگر
خطای ۴۰۳
خطای ۴۰۴
451 به دلایل قانونی در دسترس نیست

☾♔TALAYEH_A♔☽ · 2019/01/29

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

مجموعه پروتکل اینترنت
لایه کاربرد

BGP
DHCP
DHCPv6
DNS
HTTP
IMAP
IRC
LDAP
MGCP
NNTP
NTP
POP
RPC
RTP
RTSP
RIP
SIP
SMTP
SNMP
SOCKS
SSH
Telnet
TLS/SSL
XMPP
(بیشتر)

لایه حمل

TCP
UDP
DCCP
SCTP
RSVP
(بیشتر)

لایه اینترنت

IP
- IPv4
- IPv6
ICMP
ICMPv6
ECN
IGMP
IPsec
(بیشتر)

لایه پیوند

ARP/InARP
NDP
OSPF
Tunneling
- L2TP
PPP
MAC
- Ethernet
- DSL
- ISDN
- FDDI
(بیشتر)

ن
ب
و

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

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

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

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

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

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

محتویات

۱ خدمات پروتکل انتقال فایل (FTP)
۲ روش‌های برقراری یک نشست FTP
۳ روش غیرفعال برقراری نشست
۴ تاریخچه
۵ جستارهای وابسته
۶ منابع

☾♔TALAYEH_A♔☽ · 2019/01/29

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

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

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

☾♔TALAYEH_A♔☽ · 2019/01/29

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

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

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

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

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

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

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

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

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

☾♔TALAYEH_A♔☽ · 2019/01/29

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

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

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

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

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

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

☾♔TALAYEH_A♔☽ · 2019/01/29

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

VIP برنامه نویسی Client Side

☾♔TALAYEH_A♔☽

کاربر نگاه دانلود

پیشنهادات

☾♔TALAYEH_A♔☽

کاربر نگاه دانلود

☾♔TALAYEH_A♔☽

کاربر نگاه دانلود

☾♔TALAYEH_A♔☽

کاربر نگاه دانلود

☾♔TALAYEH_A♔☽

کاربر نگاه دانلود

☾♔TALAYEH_A♔☽

کاربر نگاه دانلود

☾♔TALAYEH_A♔☽

کاربر نگاه دانلود

☾♔TALAYEH_A♔☽

کاربر نگاه دانلود

☾♔TALAYEH_A♔☽

کاربر نگاه دانلود

☾♔TALAYEH_A♔☽

کاربر نگاه دانلود

برخی موضوعات مشابه

5 روش پولساز کسب درآمد از سئو

مقالات طراحی وب/ سایت

آمار انجمن

این صفحه را به اشتراک بگذارید