مقاله درباره پروتکل مسیریابی DSR

لینک دانلود و خرید پایین توضیحات

فرمت فایل word  و قابل ویرایش و پرینت

تعداد صفحات: 19

Dynamic Source Routing (DSR )

پروتکل مسیریابی DSR در شبکه های Adhoc مورد استفاده قرارمی گیرد . این پروتکل در دسته پروتکلهای مسیریابی On-Dmand قرار می گیرد وعملکرد این پروتکل بر اساس مسیریابی از مبدأ می باشد .

همانگونه که قبلاً هم ذکر گردید ،‌ Source Routing یک تکنیک مسیریابی است که در آن فرستنده بسته ،‌ ترتیبی کامل از نودهایی که باید بسته مذکور را forward‌ کنند مشخص می نماید وآن را در header‌ آن بسته قرارمی دهد . لازم به ذکر است که در این لیست ،‌ هرنود forward کننده با آدرس hop بعدی اش مشخص می شود .

Source Routing‌ در بسیاری از مفاهیم موجود در شبکه های سیم دار نیز استفاده می شود و به صورت استاتیک و یا داینامیک مسیر مورد نظر را مشخص می نماید .

در پروتکل DSR‌ اعلان مسیرها به صورت دوره ای انجام نمی گیرد . در این پروتکل نیز همانند سایر پروتکلهای On-Demand دیگر ،‌ مسیرها فقط در مواقع نیاز و از طریق پروسه کشف مسیر شکل می گیرند .

عملکرد کلی پروتکل DSR

هنگامیکه یک نود می خواهد بسته ای را به نود دیگری ارسال نماید ،‌ در صورتی که مسیری را به سمت آن مقصد نداشته باشد پروسه کشف مسیر انجام می گیرد تا مسیر مورد نظر بدست آید . سپس مسیر مذکور را در header بسته قرار داده و آن را در شبکه forward می کند . هر نودی که این بسته را دریافت می کند در صورتی که به عنوان مقصد آن بسته نباشد ‌،‌ به سادگی بر طبق آدرسهایی که در header اش قرار دارد آن را به سمت نود بعدی forward می کند . زمانی که بسته به مقصد نهایی اش می رسد توسط نرم افزار لایه شبکه آن نود دریافت می گردد .

هرنود متحرک در شبکه Adhoc دارای یک Route Cache می باشد که در آن مسیرهایی را که بدست آمده است cache می کند . هنگامیکه یک نود می خواهد بسته ای را به نود دیگری بفرستد ابتدا مسیرهای موجود در Route cache خود را بررسی می کند و در صورت عدم وجود یک مسیر معتبر به سمت آن مقصد پروسه کشف مسیر را راه اندازی خواهد کرد .

درطول مدت زمانی که آن نود منتظر است تا عملیات کشف مسیر انجام شود ،‌ می تواند پروسسهای طبیعی خود را ادامه دهد و بسته هایی را به نودهای دیگر بفرستد و یا از آنها دریافت نماید .

هر مدخل در Route cache‌ دارای یک زمان انقضا خواهد بود که بعد از اتمام این زمان ‌،‌ مدخل مربوطه ازcache پاک خواهد شد .

پروسه کشف مسیر

پروسه کشف مسیر به هر نودی در شبکه Adhoc‌ اجازه می دهد تا به صورت داینامیک مسیری را به سمت نود دیگری دراین شبکه پیدا نماید . این پروسه به صورت زیر انجام می گیرد .

ابتدا نود مبدأ یک بسته درخواست مسیر (RREQ) را به همسایگانش می فرستد . در این بسته آدرس مقصد ذکر گردیده است . هر یک از نودهای واسط با توجه به آدرس مذکور اقدام به ارسال این بسته به نودهای دیگر می نمایند تا در نهایت بسته RREQ‌ به مقصد برسد .

در صورتی که پروسه کشف مسیر موفقیت آمیز باشد نود فرستنده یک بسته پاسخ مسیر (RREP) را دریافت خواهد کرد که در آن ترتیبی از آدرس های مربوط به نودهایی که از طریق آنها بسته RREQ به مقصد رسیده است وجود دارد .

علاوه بر آدرس نود فرستنده ونود مقصد نهایی ،‌ یک Route Record نیز در هر RREQ قرار دارد. در Route Record ترتیبی از hop هایی که بسته برای رسیدن به مقصد نهایی از طریق آنها forward می شود قرار می گیرد . هر RREQ شامل یک شماره درخواست نیز می باشد که توسط نود فرستنده به صورت محلی تولید می شود .

زمانیکه یک نود ،‌ بسته RREQ را دریافت می کند با توجه به شرایط زیر اقدامات مختلفی را انجام خواهد داد .

در صورتی که (‌آدرس نود مبدأ ،‌ شماره درخواست ) در لیست درخواستهایی که اخیراً دیده است وجود داشته

مقاله درباره پروتکل OLSR

لینک دانلود و خرید پایین توضیحات

فرمت فایل word  و قابل ویرایش و پرینت

تعداد صفحات: 15

Optimized link State Routing Protocol (OLSR)

پروتکل OLSR نیز از جمله پروتکلهای مسیریابی درشبکه های Adhoc می‎باشد ،‌ این پروتکل در دسته پروتکلهای ProActive قرار می‎گیرد .

OLSR پروتکل Link State را با فشرده سازی سایز اطلاعات ارسالی ونیز کاهش ارسال مجدد اطلاعات در کل شبکه بهینه کرده است . برای رسیدن به این هدف ،‌ OLSR از تکنیک ارسال مجدد بصورت چندگانه استفاده می‎کند . این پروتکل ،‌ برای مسیریابی در شبکه های بی سیم Adhoc‌ متراکم وبزرگ کارا می‎باشد .

عملکرد پروتکل OLSR

این پروتکل ذاتاً بر مبنای الگوریتم Link State است و به علت طبیعت ProActive اش ، مسیرها هر زمان که مورد نیاز باشند فوراً در دسترس قرار می گیرند . در پروتکل LinkState اصلی هزینه تمام لینکها بین نودهای همسایه اعلان می‎شود ودر کل شبکه منتشر می گردد. پروتکل OLSR حالت بهینه شده پروتکل LS است که در شبکه های Adhoc متحرک استفاده می‎شود .

این پروتکل سایز بسته های کنترلی را کاهش می‎دهد ، و به جای اینکه بسته های کنترلی به تمام نودها در شبکه منتشر شوند ، فقط به یک زیر مجموعه‎ای از نودها ارسال می گردند . این پروتکل به صورت قابل توجهی تعداد ارسالهای مجدد را در یک پرویسجرbroadcast کاهش می‎دهد .

لازم بذکر است که این پروتکل مسیرها را برای تمام مقصدها در شبکه نگهداری می‎کند ، ازاین رو برای نمونه های ترافیکی که یک زیر مجموعه بزرگی از نودها با یکدیگر ارتباط برقرار می کنند و جفتهای مبدأ ومقصد مرتباً تغییر می کنند مفید می باشند . در این پروتکل هر نود بصورت دوره‎ای پیامهای کنترلی خود را در شبکه ارسال می‎کند ، بنابراین از گم شدن بعضی از بسته ها که در شبکه های رادیویی به دلیل تصادم و بسیاری از مشکلات دیگر انتقال بسیار معمول می‎باشد رنج می‎برد . در این پروتکل هرپیام دارای یک SeqNo است ، بنابراین در طرف گیرنده دریافت نامرتب پیامها نمی تواند سبب بروز مشکل گردد .

پروتکل OLSR یک پروتکل مسیریابی hop-by-hop است . هر نود از آخرین اطلاعاتش برای مسیریابی یک بسته استفاده می‎کند .

-ارسال مجدد چند نقطه ای (Multipoint Relay)

ایده اصلی ارسال مجدد چند نقطه ای ، می نیمم کردن سیلی از بسته های کنترلی است که در شبکه ارسال می‎شوند . این کار توسط کاهش ارسال های مجدد تکراری ، در یک ناحیه یکسان انجام می پذیرد .

هرنود در شبکه مجموعه ای از نودهای همسایه اش را انتخاب می‎کند . این نودها وظیفه ارسال مجدد بسته های آن نود را دارند وبه مجموعه آن ها مجموعه ارسال مجدد چند نقطه ای (multipoint relay) گفته می‎شود .

هر یک از نودهای موجود در این مجموعه multipoint relay های آن نود نامیده می‎شود .

همسایگانی از نود مفروض N که در مجموعه multipoint relay آن نود نیستند بسته های ارسال شده توسط نود N را دریافت و پروسس می کنند ولی مجدداً آن را ارسال نمی کنند .

دراین راستا می‎توان مفهوم دیگری را به نام انتخاب کننده های ارسال مجدد چند نقطه ای (multipoint relay selectors ) برای هر نود تعریف نمود .

هر پیامی که توسط MPR selector های نود مفروض Q ارسال شده باشد و به آن نود برسد فرض می‎شود که به وسیله نود Q‌ نیز ارسال مجدد خواهد شد .

پس هر نود می‎تواند دارای یک مجموعه multipoint relay و یک مجموعه multipoint relay selector باشد .

بسته های ارسال شده توسط آن نود از طریق تمام نودهایی که در مجموعه multipoint relay اش قرار گرفته اند مجدداً ارسال می‎شوند وبسته هایی که از طرف یکی از نودهای موجود در مجموعه multipoint selector های نود مذکور دریافت شوند باید توسط آن نود نیز ارسال گردند .

هرنود مجموعه multipoint relay اش را از بین همسایگانی انتخاب می‎کند که دارای 3 شرط زیر باشند .

فاصله شان از نود اصلی به اندازه یک hop‌ باشد .

لینکشان دوطرفه باشد .

پروتکل ها و DNS

لینک دانلود و خرید پایین توضیحات

فرمت فایل word  و قابل ویرایش و پرینت

تعداد صفحات: 32

آموزش DNS 1

تاریخچه DNS 2

پروتکل DNS 2

پروتکل DNS و مدل مرجع OSI 2

DNS 3

Flat NetBios NameSpace 4

اینترفیس های NetBIOS و WinSock 5

اینترفیس Winsock 5

استفاده از نام یکسان دامنه برای منابع اینترنت و اینترانت 8

استفاده از اسامی متفاوت برای دامنه ها ی اینترنت و اینترانت 9

Reverse Lookup Zones 11

آشنائی با پروتکل HTTP 12

پروتکل HTTP چیست ؟ 12

توضیحات  : 13

پروتکل HTTP  : یک معماری سرویس گیرنده و سرویس دهنده 15

پاسخ سرویس دهنده 15

توضیحات  : 16

آشنائی با پروتکل های  SLIP و PPP 17

PPP نسبت به SLIP دارای مزایای متعددی است : 17

وجه اشتراک پروتکل های PPP و SLIP 18

نحوه عملکرد یک اتصال SLIP و یا PPP 18

آشنائی با پروتکل FTP ( بخش اول ) 19

پروتکل FTP چیست ؟ 19

ویژگی های پروتکل FTP 19

اموزش FTP 23

Passive Mode 25

ملاحضات امنیتی 25

Passive Mode  و یا Active Mode ؟ 25

پیکربندی فایروال 26

و اما یک نکته دیگر در رابطه با پروتکل FTP ! 26

پروتکل TCP/IP 26

پروتکل های موجود در لایه Network پروتکل TCP/IP 27

پروتکل های موجود در لایه Application پروتکل TCP/IP 27

سیستم پست الکترونیکی واقعی 28

سرویس دهنده SMTP 29

سرویس دهنده POP3 31

ضمائم 32

منابع: 32

آموزش DNS

DNS از کلمات Domain Name System اقتباس و یک پروتکل شناخته شده در عرصه شبکه‌های کامپیوتری خصوصا اینترنت است . از پروتکل فوق به منظور ترجمه اسامی‌کامپیوترهای میزبان و Domain به آدرس‌های IP استفاده می‌گردد. زمانی که شما آدرس www.srco.ir را در مرورگر خود تایپ می‌نمائید ، نام فوق به یک آدرس IP و بر اساس یک درخواست خاص ( query ) که از جانب کامپیوتر شما صادر می‌شود، ترجمه می‌گردد .

تاریخچه DNS

DNS ، زمانی که اینترنت تا به این اندازه گسترش پیدا نکرده بود و صرفا در حد و اندازه یک شبکه کوچک بود، استفاده می‌گردید. در آن زمان ، اسامی‌کامپیوترهای میزبان به صورت دستی در فایلی با نام HOSTS درج می‌گردید . فایل فوق بر روی یک سرویس دهنده مرکزی قرار می‌گرفت . هر سایت و یا کامپیوتر که نیازمند ترجمه اسامی‌کامپیوترهای میزبان بود ، می‌بایست از فایل فوق استفاده می‌نمود. همزمان با گسترش اینترنت و افزایش تعداد کامپیوترهای میزبان ، حجم فایل فوق نیز افزایش و امکان استفاده از آن با مشکل مواجه گردید ( افزایش ترافیک شبکه ). با توجه به مسائل فوق، در سال 1984 تکنولوژی DNS معرفی گردید .

پروتکل DNS

DNS ، یک بانک اطلاعاتی توزیع شده است که بر روی ماشین‌های متعددی مستقر می‌شود ( مشابه ریشه‌های یک درخت که از ریشه اصلی انشعاب می‌شوند) . امروزه اکثر شرکت‌ها و موسسات دارای یک سرویس دهنده DNS کوچک در سازمان خود می‌باشند تا این اطمینان ایجاد گردد که کامپیوترها بدون بروز هیچگونه مشکلی، یکدیگر را پیدا می‌نمایند . در صورتی که از ویندوز 2000 و اکتیو دایرکتوری استفاده می‌نمائید، قطعا از DNS به منظور ترجمه اسامی‌کامپیوترها به آدرس‌های IP ، استفاده می‌شود . شرکت مایکروسافت در ابتدا نسخه اختصاصی سرویس دهنده DNS خود را با نام ( WINS ( Windows Internet Name Service طراحی و پیاده سازی نمود . سرویس دهنده فوق مبتنی بر تکنولوژی‌های قدیمی‌بود و از پروتکل‌هایی استفاده می‌گردید که هرگز دارای کارایی مشابه DNS نبودند. بنابراین طبیعی بود که شرکت مایکروسافت از WINS فاصله گرفته و به سمت DNS حرکت کند .

از پروتکل DNS در مواردی که کامپیوتر شما اقدام به ارسال یک درخواست مبتنی بر DNS برای یک سرویس دهنده نام به منظور یافتن آدرس Domain می‌نماید ، استفاده می‌شود .مثلا در صورتی که در مرورگر خود آدرس www.srco.ir را تایپ نمائید ، یک درخواست مبتنی بر DNS از کامپیوتر شما و به مقصد یک سرویس دهنده DNS صادر می‌شود . ماموریت درخواست ارسالی ، یافتن آدرس IP وب سایت سخاروش است.

پروتکل DNS و مدل مرجع OSI

پروتکل DNS معمولا از پروتکل UDP به منظور حمل داده استفاده می‌نماید . پروتکل UDP نسبت به TCP دارای overhead کمتری می‌باشد. هر اندازه overhead یک پروتکل کمتر باشد ، سرعت آن بیشتر خواهد بود. در مواردی که حمل داده با استفاده از پروتکل UDP با مشکل و یا بهتر بگوئیم خطاء مواجه گردد ، پروتکل DNS از پروتکل TCP به منظور حمل داده استفاده نموده تا این اطمینان ایجاد گردد که داده بدرستی و بدون بروز خطاء به مقصد خواهد رسید .

فرآیند ارسال یک درخواست DNS و دریافت پاسخ آن ، متناسب با نوع سیستم عامل نصب شده بر روی یک کامپیوتر است .برخی از سیستم‌های عامل اجازه استفاده از پروتکل TCP برای DNS را نداده و صرفا می‌بایست از پروتکل UDP به منظور حمل داده استفاده شود . بدیهی است در چنین مواردی همواره این احتمال وجود خواهد داشت که با خطاهایی مواجه شده و عملا امکان ترجمه نام یک کامپیوتر و یا Domain به آدرس IP وجود نداشته باشد. پروتکل DNS از پورت 53 به منظور ارائه خدمات خود استفاده می‌نماید. بنابراین یک سرویس دهنده DNS به پورت 53 گوش داده و این انتظار را خواهد داشت که هر سرویس گیرنده‌ای که تمایل به استفاده از سرویس فوق را دارد از پورت مشابه استفاده نماید . در برخی موارد ممکن است مجبور شویم از پورت دیگری استفاده نمائیم . وضعیت فوق به سیستم عامل و سرویس دهنده DNS نصب شده بر روی یک کامپیوتر بستگی دارد.

DNS

DNS مسئولیت حل مشکل اسامی کامپیوترها ( ترجمه نام به آدرس ) در یک شبکه و مسائل مرتبط با برنامه های Winsock را بر عهده دارد. به منظور شناخت برخی از مفاهیم کلیدی و اساسی DNS ، لازم است که سیستم فوق را با سیستم دیگر نامگذاری در شبکه های مایکروسافت(NetBIOS ) مقایسه نمائیم . قبل از عرضه ویندوز 2000 تمامی شبکه های مایکروسافت از مدل NetBIOS برای نامگذاری ماشین ها و سرویس ها ی موجود بر روی شبکه استفاده می کردند. NetBIOS در سال 1983 به سفارش شرکت IBM طراحی گردید. پروتکل فوق در ابتدا بعنوان پروتکلی در سطح لایه " حمل " ایفای وظیفه می کرد.در ادامه مجموعه دستورات NetBIOS بعنوان یک اینترفیس مربوط به لایه Session نیز مطرح تا از این طریق امکان ارتباط با سایر پروتکل ها نیز فراهم گردد. NetBEUI مهمترین و رایج ترین نسخه پیاده سازی شده در این زمینه است . NetBIOS برای شیکه های کوچک محلی با یک سگمنت طراحی شده است . پروتکل فوق بصورت Broadcast Base است . سرویس گیرندگان NetBIOS می توانند سایر سرویس گیرندگان موجود در شبکه را از طریق ارسال پیامهای Broadcast به منظور شناخت و آگاهی از آدرس سخت افزاری کامپیوترهای مقصد پیدا نمایند. شکل زیر نحوه عملکرد پروتکل فوق در یک شبکه و آگاهی از آدرس سخت افزاری یک کامپیوتر را نشان می دهد. کامپیوتر ds2000 قصد ارسال اطلاعات به کامپیوتری با نام Exeter را  دارد. یک پیام Broadcast برای تمامی کامپیوترهای موجود در سگمنت ارسال خواهد شد. تمامی کامپیوترهای موجود در سگمنت مکلف به بررسی پیام می باشند. کامپیوتر Exeter پس از دریافت پیام ،آدرس MAC خود را برای کامپیوتر ds2000 ارسال می نماید.

همانگونه که اشاره گردید استفاده از پروتکل فوق برای برطرف مشکل اسامی ( ترجمه نام یک کامپیوتر به آدرس فیزیکی و سخت افزاری ) صرفا" برای شبکه های محلی با ابعاد کوچک توصیه شده و در شبکه های بزرگ نظیر شبکه های اترنت با ماهیت Broadcast Based با مشکلات عدیده ای مواجه خواهیم شد.در ادامه به برخی از این مشکلات اشاره شده است .

بموازات افزایش تعداد کامپیوترهای موجود در شبکه ترافیک انتشار بسته های اطلاعاتی بشدت افزایش خواهد یافت .

پروتکل های مبتنی بر NetBIOS ( نظیر NetBEUI) دارای مکانیزمهای لازم برای روتینگ نبوده و دستورالعمل های مربوط به روتینگ در مشخصه فریم بسته های اطلاعاتی NetBIOS تعریف نشده است .

 در صورتی که امکانی فراهم گردد که قابلیت روتینگ به پیامهای NetBIOS داده شود ( نظیر Overlay نمودن NetBIOS بر روی پروتکل دیگر با قابلیت روتینگ ، روترها بصورت پیش فرض بسته های NetBIOS را منتشر نخواهند کرد. ماهیت BroadCast بودن پروتکل NetBIOS یکی از دو فاکتور مهم در رابطه با محدودیت های پروتکل فوق خصوصا" در شبکه های بزرگ است . فاکتور دوم ، ساختار در نظر گرفته شده برای نحوه نامگذاری است . ساختار نامگذاری در پروتکل فوق بصورت مسطح (Flat) است .

Flat NetBios NameSpace به منظور شناخت و درک ملموس مشکل نامگذاری مسطح در NetBIOS لازم است که در ابتدا مثال هائی در این زمینه ذکر گردد. فرض کنید هر شخص در دنیا دارای یک نام بوده و صرفا" از طریق همان نام شناخته گردد. در چنین وضعیتی اداره راهنمائی و رانندگی اقدام به صدور گواهینمامه رانندگی می نماید. هر راننده دارای یک شماره سریال خواهد شد. در صورتی که از اداره فوق سوالاتی نظیر سوالات ذیل مطرح گردد قطعا" پاسخگوئی به آنها بسادگی میسر نخواهد شد.

چند نفر با نام احمد دارای گواهینامه هستند؟

چند نفر با نام رضا دارای گواهینامه هستند؟

در چنین حالی اگر افسر اداره راهنمائی و رانندگی راننده ای را بخاطر تخلف متوقف نموده و از مرکز و بر اساس نام وی استعلام نماید که آیا " راننده ای با نام احمد قبلا" نیز مرتکب تخلف شده است یا خیر ؟" در صورتی که از طرف مرکز به وی پاسخ مثبت داده شود افسر مربوطه هیچگونه اطمینانی نخواهد داشت که راننده در مقابل آن همان احمد متخلف است که قبلا" نیز تخلف داشته است . یکی از روش های حل مشکل فوق، ایجاد سیستمی است که مسئولیت آن ارائه نام بصورت انحصاری و غیرتکراری برای تمامی افراد در سطح دنیا باشد. در چنین وضعیتی افسر اداره راهنمائی و رانندگی در برخورد با افراد متخلف دچار مشکل نشده و همواره این اطمینان وجود خواهد داشت که اسامی بصورت منحصر بفرد استفاده شده است . در چنین سیستمی چه افراد و یا سازمانهائی مسئله عدم تکرار اسامی را کنترل و این اطمینان را بوجود خواهند آورند که اسامی بصورت تکراری در سطح دنیا وجود نخواهد داشت؟. بهرحال ساختار سیستم نامگذاری می بایست بگونه ای باشد که این اطمینان را بوجود آورد که نام انتخاب شده قبلا" در اختیار دیگری قرار داده نشده است . در عمل پیاده سازی اینچنین سیستم هائی غیر ممکن است.مثال فوق محدودیت نامگذاری بصورت مسطح را نشان می دهد. سیستم نامگذاری بر اساس NetBIOS بصورت مسطح بوده و این بدان معنی است که هر کامپیوتر بر روی شبکه می

پروتکل انتقال فایل FTP 12 ص

لینک دانلود و خرید پایین توضیحات

فرمت فایل word  و قابل ویرایش و پرینت

تعداد صفحات: 13

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

پروتکل انتقال فایل که آن را ftp می نامیم ابزاریست مطمئن برای انتقال فایل بین کامپیوتر ها یی که به شبکه اینترنت متصل هستند. خدماتی که این پروتکل ارائه می کند عبارتند از :

تهیه لیستی از فایلهای موجود ازسیستیم فایل کامپوتر راه دور

حذف، تغییر نام و جابجا کردن فایلهای کامپیوتر راه دور

جستجو در شاخه های ( دایر کتوریهای) کامپیوتر راه دور

ایجاد یا حذف شاخه روی کامپیوتر راه دور

انتقال فایل ازکامپیوتر میزبان

انتقال فایل و ذخیره ی آن از کامپیوتر میزبان به کامپیوتر راه دور

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

در پروتکل FTP برای شروع یک نشست بین برنامه سرو.یس دهنده و برنامه ی سرویس گیرنده باید دو ارتباط همزمان ازنوع TCP بر قرار شود. به هر یک از این ارتباطات در ادبیات پروتکل FTP ،کانال گفته می شود. این دو کانال عبارتند از :

کانال داده : یک ارتباط TCP با پورت شمارهی 20 از سرویس دهنده که روی آن داده ها ( مثلا بلوکهای یک فایل ) مبادله می شوند .

کانال فرمان: یک ارتباط TCP با پورت شمارهی 21 که روی آن فرامین لازم برای مدیریت فایلها رد و بدل می شود.

دلیل لزوم برقراری دو کانال مجزا بین سروس دهنده و سرویس گپیرنده ان است که بتوان بدون قطع جریان داده ها فرامین را بطور همزمان مبادله کرد. بعنوان مثال در حین اتقاال یک فایل می توان روی کانال فرمان دستور لغو عمل انتقال یا تغییر مود انتقال را صادر کرد. ذکر این نکته ضروری است که در پروکتل FTP ازسیستم spooler یا صف برای انتقال فایلها استفاده نمی کند بلکه عملیات انتقال به صورت بلادر نگ انجام می گیرد . ( سیستمهایی مثل مدیریت چاپ در پس زمینه عمل می کند یعنی وقتی پروسه ای تقاضای چاپ یک سند را می دهد سیستم عامل آن را به صف میکند تادر موقع مناسب آنرا چاپ نماید فلذا مشخص نیست از زمان صدور فرمان چاپ چه مدت طول بکشد تا سند چاپ شود چرا که اولویت با پروسه هایی است که در پیش زمینه اجرا می شوند .)

به گونه ای که اشاره شد سرویس دهنده FTP بایستی دو پروسه همزمان ایجاد نماید که یکی وظیفه مدیریت ارتباط روی کانال فرمان را به عهده داشته و اصطلاحاً مفسر پروتکل یا پروسه PI نامیده می شود . وظیفه پروسه دیگر مدیریت انتقال داده است وبه DTP یا پروسه انتقال داده معروف است . پروسه PI همیشه به پورت شماره 21 گوش میدهد و پروسه DPT به پورت شماه 20 مقید شده است.

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

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

روش معمولی یا NORMAL MODE

روش غیر فعال یا PASSIVE MODE

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

1) در برنامه سمت سرویس گیرنده ( برنامه سمت مشتری ) ابتدا دو سوکت نوع TCP با شماره پورت تصادفی بالای 1024 ایجاد می شود .

2) در مرحله دوم برنامه سمت مشتری سعی می کند با استفاده ازدستور () CONNECT ارتباط یکی از سوکتهای ایجاد شده را با پورت شماره 21 ازسرویس دهنده برقرار نماید. اگر این ارتباط برقرار شود در حقیقت کانال فرمان باز شده و پروسه PI آماده تفسیر فرامین صادره ازسمت مشتری می باشد .

3) برنامه سمت مشتری با فرمان PORT به برنامه سمت سرویس دهنده شماره پورت سوکت دوم را اعلام می ماند . ( در حقیقت برنامه مشتری روی سوکت دوم عمل () Iisten انجام می دهد )

4) در ادامه برنامه سرویس دهنده سعی می کند یک ارتباط با tcp با شماره پورت اعلام شده برقرار نماید . یکی ازنکات عجیب در این پروتکل آنست که سرویس دهنده FTP موظف است اقدام به برقراری یک ارتباط TCP ازطریق دستور ()CONNECT با برنامه مشتری نماید در صورتی که معمولا سرویس دهنده پذیرنده ارتباط است نه شروع کننده ارتباط.

5) برنامه سمت مشتری ارتباط TCP شروع شده ازسرویس دهنده را تصدیق کرده و یک نشست FTP آغاز می شود.

مثالی از یک نشست FTP به روش معمولی

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

1) در برنامه ی سمت مشتری ابتدا دو سوکت نوع TCP با شماره پورت های تصادفی بالای 1024 ایجاد می شود.

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

پروتکل 12 ص

لینک دانلود و خرید پایین توضیحات

فرمت فایل word  و قابل ویرایش و پرینت

تعداد صفحات: 12

در این مقاله برای شما بطور  مختصر از پروتکل هایی خواهیم گفت که امکانFT

یا (File Transfer) یا انتقال فایل را فراهم می آورند یا از بلوکهای سازنده پروتکل

های ذکر شده در مقاله رمزنگاری در پروتکل های انتقال استفاده می کنند تا امکان

FT  امن را ایجاد کنند. درحالیکه پروتکلهای ذکر شده در مقاله مذکور سیستمهای

امنیتی عمومی هستند که قابل کاربرد برای FT  نیز هستند، آنچه در اینجا اشاره می شود، مشخصاً برای FT  ایجاد شده اند:

AS2

AS2 (Applicability Statement 2) گونه ای EDI (Electronic Date Exchange) یا تبادل دیتای الکترونیکی (اگرچه به قالبهای EDI محدود نشده) برای استفاده های تجاری با استفاده از HTTP است. AS2 در حقیقت بسط یافته نسخه قبلی یعنی AS1 است. AS2 چگونگی تبادل دیتای تجاری را بصورت امن و مطمئن با استفاده از HTTP بعنوان پروتکل انتقال توصیف می کند. دیتا با استفاده از انواع محتوایی MIME استاندارد که XML، EDI ، دیتای باینری و هر گونه دیتایی را که قابل توصیف در MIME باشد، پشتیبانی می کند، بسته بندی می شود. امنیت پیام (تایید هویت و محرمانگی) با استفاده از S/MIME پیاده سازی می شود. AS1 در عوض از SMTP استفاده می کند. با AS2 و استفاده از HTTP یا HTTP/S ( HTTP با SSL) برای انتقال، ارتباط بصورت زمان حقیقی ممکن می شود تا اینکه از طریق ایمیل انجام گیرد. امنیت، تایید هویت، جامعیت پیام، و خصوصی بودن با استفاده از رمزنگاری و امضاهای دیجیتال تضمین می شود، که برپایه S/MIME هستند و نه SSL. استفاده از HTTP/S بجای HTTP استاندارد بدلیل امنیت ایجادشده توسط S/MIME کاملاً انتخابی است. استفاده از S/MIME اساس ویژگی دیگری یعنی انکارناپذیری را شکل می دهد، که امکان انکار پیام های ایجادشده یا فرستاده شده توسط کاربران را مشکل می سازد، یعنی یک شخص نمی تواند منکر پیامی شود که خود فرستاده است.

*برای FT :)File Transfer  انتقال فایل یا( AS2 مشخصاً برای درکنارهم قراردادن  ویژگیهای امنیتی با انتقال فایل یعنی تایید هویت، رمزنگاری، انکارناپذیری توسط S/MIME و SSL  انتخابی، طراحی شده است. از آنجا که AS2 یک پروتکل در حال ظهور است، سازمانها باید تولید کنندگان را به پشتیبانی سریع از آن تشویق کنند. قابلیت وجود انکارناپذیری در تراکنش های برپایه AS2 از اهمیت خاصی برای سازمانهایی برخوردار است که می خواهند پروسه های تجاری بسیار مهم را به سمت اینترنت سوق دهند. وجود قابلیت برای ثبت تراکنش پایدار و قابل اجراء برای پشتبانی از عملکردهای بسیار مهم مورد نیاز است. AS2 از MDN (Message Disposition Notification) بر پایه RFC 2298 استفاده می کند. MDN (که می تواند در اتصال به سایر پروتکل ها نیز استفاده شود) بر اساس محتوای MIME است که قابل خواندن توسط ماشین است و قابلیت آگاه سازی و اعلام وصول پیام را بوجود می آورد، که به این ترتیب اساس یک ردگیری نظارتی پایدار را فراهم می سازد.

(File Transfer Protocol) FTP

FTP  یا پروتکل انتقال فایل به منظور انتقال فایل از طریق شبکه ایجاد گشته است، اما هیچ نوع رمزنگاری را پشتیبانی نمی کند. FTP حتی کلمات عبور را نیز بصورت رمزنشده انتقال می دهد، و به این ترتیب اجازه سوءاستفاده آسان از سیستم را می دهد. بسیاری سرویس ها FTP بی نام را اجراء می کنند که حتی نیاز به کلمه عبور را نیز مرتفع می سازد (اگرچه در این صورت کلمات عبور نمی توانند شنیده یا دزدیده شوند)

*برای FT: FTP بعنوان یک روش امن مورد توجه نیست، مگر اینکه درون یک کانال امن مانند SSL یا IPSec قرار گیرد.گرایش زیادی به FTP امن یا FTP بر اساس SSL وجود دارد.(می‌توانید به SFTP و SSL مراجعه کنید)

FTPS و SFTP

SFTP به استفاده از FT بر روی یک کانال که با SSH امن شده، اشاره دارد، در حالیکه منظور از FTPS استفاده از FT بر روی SSL است. اگرچه SFTP دارای استفاده محدودی است، FTPS (که هر دو شکل FTP روی SSL و FTP روی TLS را بخود می گیرد) نوید کارایی بیشتری را می دهد. RFC 2228 (FTPS)  رمزنگاری کانالهای دیتا را که برای ارسال تمام دیتا و کلمات عبور استفاده شده اند، ممکن می سازد اما کانالهای فرمان را بدون رمزنگاری باقی می گذارد (بعنوان کانال فرمان شفاف شناخته می شود). مزیتی که دارد این است که به