قرارداد داده‌نگار کاربر

از ویکی‌پدیا، دانشنامهٔ آزاد
پرش به: ناوبری، جستجو

قرارداد بسته دادۀ کاربر یا پروتکل بسته دادۀ کاربر (به انگلیسی: UDP یا User Datagram Protocol) یکی از اجزاء اصلی مجموعه پروتکل اینترنت، مجموعه‌ای از پروتکل‌های شبکه که در اینترنت مورد استفاده قرار می‌گیرند، می‌باشد. رایانه‌ها با استفاده از UDP قادر به ارسال پیغام، که در این مورد آن را بسته داده یا Datagram می‌نامیم، به دیگر میزبان‌های موجود در پروتکل اینترنت (IP) می‌باشند. این پروتکل توانایی این را دارد که این کار را بدون برقراری ارتباط قبلی و یا ایجاد کانالها یا مسیرهای انتقال داده ویژه انجام دهد. پروتکل مزبور در سال 1980 توسط دیوید پی. رید ابداع گردیده و به طور رسمی در استاندارد RFC 768 تعریف شد.

UDP از مدل انتقال ساده بدون استفاده از تکنیک دست تکانی صریح که برای ایجاد قابلیت اطمینان (Reliability)، مرتب سازی و یکپارچه سازی داده‌ها بکار می‌رود، بهره می‌جوید. بنابراین، UDP سرویس غیرمطمئنی را ارائه می‌دهد و ممکن است بسته داده ها نامرتب، تکراری بوده و یا بدون اطلاع قبلی از دست بروند. UDP تشخیص می‌دهد که بررسی خطا و تصحیح آن با توجه به نوع کاربردی که دارد لازم نبوده و یا نباید اجرا شود، بنابراین چنین بار اضافی پردازشی را بر شبکه تحمیل نمی‌کند. برنامه‌های که نسبت به زمان حساس هستند از UDP استفاده می‌کنند، زیرا از دست دادن بسته‌ها بهتر از منتظر ماندن برای بسته هاست. بنابراین پروتکل UDP بهترین گزینه برای سیستم‌های بلادرنگ به حساب می‌آید. اگر برنامه‌ای نیاز به امکانات تصحیح خطا در سطح واسط شبکه داشته باشد، می‌تواند از قرارداد کنترل انتقال (به انگلیسی: TCP یا Transmission Control Protocol) و یا پروتکل انتقال کنترل جریان (به انگلیسی: SCTP یا Stream Control Transmission Protocol) استفاده کند که به طور خاص برای این منظور طراحی شده‌اند.

طبیعت [[پروتکل‌های بدون حالت|بدون حالت}} UDP می‌تواند برای سرورهایی که به پرس و جوهای کوچک حجم زیادی از کلاینت‌ها پاسخ می‌دهند نیز مفید واقع شود. UDP بر خلاف TCP، با شبکه‌های پخشی (انتشار بسته در کل شبکه محلی) و شبکه‌های چندپخشی (ارسال بسته به بخشی از شبکه) سازگاری کامل دارد.

برنامه‌های معمول شبکه که از UDP استفاده می‌کنند عبارتند از: سامانه نام دامنه (به انگلیسی: DNS یا Domain Name System)، برنامه‌هایی که از پخش زنده یا رسانه جویباری (Streaming Media) استفاده می‌کنند نظیر تلویزیون پروتکل اینترنت یا IPTV، صدا روی پروتکل اینترنت یا VoIP، پروتکل ساده انتقال فایل (به انگلیسی: TFTP یا Trivial File Transfer Protocol) و بسیاری از بازی‌های برخط.

پورت‌های مورد استفاده[ویرایش]

نوشتار اصلی: پورت UDP و TCP


برنامه‌های UDP از سوکت بسته داده برای برقراری ارتباطات میزبان-به-میزبان استفاده می‌کنند. برنامه یک سوکت را در انتهای بسته انتقال داده اش می‌چسباند، که ترکیبی از آدرس آی‌پی و شماره پورت سرویس است. پورت یک ساختار نرم‌افزاری است که با یک عدد 16 بیتی به نام شماره پورت شناسایی می‌شود. شماره پورت عددی بین 0 تا 65,535 است. پورت 0 رزرو شده‌است، اما اگر پردازش ارسال کننده انتظار دریافت پیام را نداشته باشید مجاز است که از این پورت استفاده کند.

آیانا یا انجمن شماره‌های تخصیص یافته اینترنتی شماره پورتها را به سه دسته تقسیم کرده‌است. پورت‌های بین 0 تا 1023 برای سرویس‌های شناخته شده و عمومی آزادند. پورتهای بین 1024 و 49,151 پورت‌های ثبت شده هستند و برای سرویس‌های مخصوص IANA در نظر گرفته شده‌اند. پورتهای بین 49,152 تا 65,535 پورت‌های داینامیکی هستند که به طور رسمی برای سرویس خاصی در نظر گرفته نشده‌اند و می توان برای هر منظوری استفاده کرد.

ساختار بسته UDP[ویرایش]

UDP کمینه ترین پروتکل مبتنی بر پیغام لایه انتقال است که جزئیات آن در RFC 768 آورده شده‌است.

UDP هیچگونه تضمینی برای تحویل پیام به پروتکل لایه بالاتر را نمی‌دهد و پروتکل‌هایی هم که از UDP استفاده می‌کنند هیچ حالتی از پیغامی را می‌فرستند نگه نمی‌دارند. به همین دلیل، UDP را پروتکل بسته-داده غیر مطمئن می‌نامند.

UDP تسهیم‌سازی برنامه (از طریق شماره پورت) و بررسی یکپارچگی (با استفاده از چک‌سام) سرایند و بخش داده‌ای را فراهم می‌آورد. اگر مطمئن بودن انتقال موردنظر باشد، بایستی این امکان در برنامه کاربر تعبیه شود.

افست (بیت) 0 – 15 16 – 31
0 شماره پورت مبدأ شماره پورت مقصد
32 طول چک‌سام
64  
داده
 

UDP داده ها را در قالب قطعاتی (Segment) ارسال می کند، که در ابتدای آنها 8 بایت سرآیند و سپس داده های لایه کاربرد قرار می گیرد. این سرآیند در جدول بالا نشان داده شده است. دو فیلد شماره پورت به منظور شناسایی نقاط پایانی (پروسه‌های نهایی) در ماشینهای مبدأ و مقصد به کار می آیند. وقتی یک بسته UDP از راه می رسد، محتوای آن به پروسه متصل به شماره پورت مقصد، تحویل داده می شود. عمل اتصال پروسه به یک پورت از طریق تابع اولیه BIND انجام می شود. (فرایند مقیدسازی پروسه به یک پورت در TCP و UDP تفاوتی ندارد) در حقیقت، آنچه که UDP در مقایسه با IP معمولی اضافه‌تر دارد پورتهای مبدأ و مقصد هستند. بدون فیلدهای مربوط به پورت، لایه انتقال نمی‌داند که با یک بسته چه کار کند. با این فیلدها، داده به درستی تحویل پروسه مربوطه خواهد شد.

برای آنکه بتوان برای پروسه مبدأ پاسخی برگرداند، به شماره پورت مبدأ نیاز است. بدین منظور محتوای فیلد پورت مبدأ از بسته ورودی، در فیلد پورت مقصد از بسته خروجی، کپی و ارسال می شود. بدین ترتیب فرستنده پاسخ، پروسه تحویل گیرنده بسته را مشخص می نماید. [۱]

سرایند UDP دارای 4 ستون، طول هر کدام 2 بایت (16 بیت) و استفاده از دو تای آنها در IPv4 اختیاری است. (فیلدهایی که با رنگ صورتی مشخص شده‌اند). در IPv6 تنها استفاده از شماره پورت مبداً اختیاری می باشد. (جدول پایین)

شماره پورت مبدأ
این فیلد شماره پورت فرستنده را مشخص می‌کند و زمانی معنا پیدا می‌کند که برای پاسخ دادن احتیاج به شماره پورت فرستنده داشته باشیم. اگر از آن استفاده نشود، عدد صفر در آن قرار می‌گیرد. اگر میزبان مبدأ یک کلاینت باشد، شماره پورت به احتمال زیاد یک شماره پورت موقتی (دسته سوم) خواهد بود. اگر میزبان مبدأ یک سرور باشد، احتمالاً شماره پورت جزو پورت‌های عمومی (دسته اول) خواهد بود.
شماره پورت مقصد
این فیلد شماره پورت مقصد را نشان می‌دهد و وجود آن الزامیست. همانند شماره پورت مبدأ، اگر کلاینت، میزبان مقصد باشد، شماره پورت به احتمال زیاد جزو پورت‌های موقتی خواهد بود و اگر میزبان مقصد یک سرور باشد شماره پورت جزو دسته اول خواهد بود.
طول
فیلدی که طول کل بسته داده را بر حسب بایت نشان می‌دهد. حداقل طول 8 بایت است که متعلق به طول سرآیند می‌باشد. اندازه فیلد به طور تئوریک 65,535 بایت (8 بایت برای سرآیند + 65,527 بایت برای داده) برای بسته دادۀ UDP است. اما حداکثر اندازه عملی برای IPv4 عبارت است از 65,507 بایت. (65,535 - 8 بایت برای سرآیند یو دی پی - 20 بایت برای سرآیند IP). عدم استفاده از این فیلد نوعی سهل انگاری است مگر اینکه کیفیت داده ها چندان مهم نباشد. (مثلاً در مورد صدای دیجیتال)
چک‌سام
فیلد چک‌سام برای بررسی خطای سرایند و داده استفاده می‌شود. اگر هیچ چک‌سامی توسط فرستنده تولید نشود، این فیلد با صفر پر می‌شود. فیلد مزبور در IPv6 اختیاری نیست.

محاسبه چک‌سام[ویرایش]

روشی که برای محاسبه چک‌سام مورد استفاده قرار می گیرد در RFC 768 تعریف شده است:

این کد حاصل جمع سرآیند، داده‌ها و یک «شبه فرایند فرضی» (Pseudoheader) است. قالب شبه سرآیند فرضی در جدول پایین آمده است. برای محاسبه این کد ابتدا فید چک‌سام صفر فرض می شود و در صورت فرد بودن تعداد بایتها، تعدادی صفر زائد به انتهای داده‌ها اضافه می گردد تا تعداد بایتها زوج شود. الگوریتم محاسبه چک‌سام بسیار ساده است: مجموعه بایتها به صورت کلمات 16 بیتی (یعنی دو بایت دو بایت) با هم جمع شده و حاصل جمع به صورت «متمم 1» (One's Complement) منفی می شود و درون فید چک‌سام قرار می گیرد. نتیجتاً وقتی در گیرنده این محاسبه بر روی کل قطعه (شامل فیلد چک‌سام) انجام می شود نتیجه آن باید صفر باشد. در غیر اینصورت داده‌ها قابل اطمینان و سالم نیستند.[۲]

تفاوت IPv4 و IPv6 در محاسبه چک‌سام در میزان داده های محاسباتی آنها می باشد.

شبه سرآیند فرضی در IPv4[ویرایش]

چک سام در قالب UDP IPv4 با استفاده از یک شبه سرآیند فرضی محاسبه می شود و شباهت زیادی به سرآیند واقعی یک IP دارد. این سرآیند فرضی یک سرآیند واقعی IP نمی‌باشد که در ارسال بسته IP دخالت دارد. جدول زیر ساختار کامل شبه سرآیند فرضی که تنها برای محاسبه چک‌سام مورد استفاده قرار می گیرد را مشخص می نماید.

bits 0 – 7 8 – 15 16 – 23 24 – 31
0 آدرس مبدأ
32 آدرس مقصد
64 تعدادی صفر پروتکل طول UDP
96 شماره پورت مبدأ شماره پورت مقصد
128 طول چک‌سام
160  
داده
 

محاسبه چک‌سام در IPv4 اختیاری است. اگر این کار انجام نشود، مقدار آن فیلد با صفر پر می شود.

شبه سرآیند فرضی در IPv6[ویرایش]

زمانیکه پروتکل UDP در سیستم IPv6 مورد استفاده قرار میگیرد، محاسبه آن اجباری است. روشی که برای محاسبه چک‌سام در IPv6 انجام می شود در RFC 2460 تعریف شده است. همانند IPv4 شبه سرآیند فرضی در محاسبه چک سام استفاده می شود.

bits 0 – 7 8 – 15 16 – 23 24 – 31
0 آدرس مبدأ
32
64
96
128 آدرس مقصد
160
192
224
256 طول UDP
288 تعدادی صفر سرآیند بعدی
320 شماره پورت مبدأ شماره پورت مقصد
352 طول چک‌سام
384  
داده
 

قابلیت اطمینان و راه‌حل‌هایی برای کنترل ازدحام[ویرایش]

فقدان قابلیت اطمینان بدین معناست که برنامه‌هایی که از UDP استفاده می‌کنند کلاً می‌توانند مقداری خطا یا افزونگی را بپذیرند. برخی پروتکلها نظیر TFTP می‌توانند مکانیزم‌های ابتدایی برای برقراری قابلیت اطمینان را در لایه کاربرد به کار گیرند. در اغلب اوقات برنامه‌هایی که از UDP استفاده می‌کنند از مکانیزم‌های برقراری قابلیت اطمینان استفاده نمی‌کنند و حتی مانع از اجرای آنها می‌شوند. رسانه‌های جویباری، بازی‌های چندبازیکنه بلادرنگ و VoIP مثالهایی از برنامه‌هایی هستند که از UDP بهره می‌برند. در این برنامه‌های خاص از دست دادن بسته‌ها معمولاً مشکل حادی نیست. اگر برنامه‌ای احتیاج به برقراری قابلیت اطمینان بالا داشته باشد، باید از پروتکلی نظیر TCP استفاده کند.

در مورد UDP بر خلاف TCP مورد مهم و قابل توجهی وجود دارد که برنامه‌های مبتنی بر این پروتکل قابلیت جلوگیری از ازدحام و مکانیزم کنترلی خوبی نیستند. برنامه‌های UDP ای که به مسأله ازدحام توجهی نمی‌کنند و میزان قابل توجهی از پهنای باند را نیز اشغال می‌کنند، می‌توانند ثبات اینترنت را به مخاطره بیندازند. مکانیزم‌های مبتنی بر شبکه‌ای وجود دارد که برای به حداقل رساندن تأثیرات مخرب، ترافیک‌های کنترل نشده UDP ارائه شده‌اند. اجزاء مبتنی بر شبکه نظیر روترها که از تکنیک‌های صف بندی و حذف بسته‌ها استفاده می‌کنند، تنها ابزار موجود برای کاهش دادن ترافیک حجیم برنامه‌های مبتنی بر UDP می‌باشند. پروتکل کنترل ازدحام بسته داده (به انگلیسی: DCCP یا Datagram Congestion Control Protocol) راه حلی نسبی برای حل این مشکل بالقوه‌است. این پروتکل با افزودن رفتار کنترلی مشابه TCP در سیستم میزبان، جریان‌های شدید UDP را کنترل می‌کند.

کاربردها[ویرایش]

برنامه‌های اینترنتی متعددی از UDP بهره می‌برند:

انتقال صدا و تصویر معمولاً از طریق UDP صورت می‌گیرد. پروتکل‌های پخش زنده صدا و تصویر برای مدیریت از دست رفتن بسته‌ها طراحی شده‌اند تا تنها افت کیفیت ناچیزی رخ دهد، تا اینکه زمان زیادی برای ارسال دوباره بسته‌های از دست رفته صرف شود. به این دلیل که TCP و UDP هر دو در یک شبکه کار می‌کنند، بسیاری از کسب و کارها به این نتیجه رسیده‌اند که افزایش اخیر در ترافیک UDP از این برنامه‌های بلادرنگ بر کارایی برنامه‌هایی نظیر پایانه‌های فروش (POS)، سیستم‌های حسابداری و پایگاه داده که از TCP استفاده می‌کنند، آسیب می‌رسانند. زمانیکه TCP متوجه از دست رفتن بسته‌ای می‌شود، نرخ انتقال داده‌هایش را کاهش می‌دهد. از آنجاییکه، برنامه‌های تجاری و بلادرنگ برای کسب و کارها مهم می‌باشند، بر اهمیت توسعه راه حل‌های کیفیت خدمات (QoS) روز به روز افزوده می‌شود.

مقایسه UDP و TCP[ویرایش]

نوشتار اصلی: لایه کاربرد


پروتکل کنترل انتقال یک پروتکل اتصال گرا (Connection-Oriented) می‌باشد، بدین معنا که برای برقراری ارتباط بین دو میزبان احتیاج به تکنیک «دست تکانی» یا Handshaking دارد. به محض اینکه ارتباط برقرار شد داده‌های کاربر می‌تواند به صورت دوطرفه ارسال و دریافت شود. از جمله خصوصیات این پروتکل می‌توان به موارد زیر اشاره کرد:

  • قابل اطمینان - TCP تصدیق پیغام، ارسال دوباره و زمان انقضاء را مدیریت می‌کند. اگر پیغامی به مقصد نرسید این امکان را دارد که برای چندین بار این کار را انجام دهد. اگر بسته‌ای در وسط راه از دست رفت، سرور می‌تواند درخواست ارسال دوباره بسته مفقوده را اعلام کند. در TCP، از دست رفتن داده معنایی ندارد و در مواردی که زمان انقضاء (Timeout) افزایش یابد، ارتباط قطع خواهد شد.
  • دارای ترتیب - اگر دو پیغام بر روی یک خط ارتباطی به ترتیب فرستاده شوند، پیغام اول، اول خواهد رسید. زمانیکه قطعات داده‌ای در ترتیب اشتباه دریافت شوند، TCP تمام بسته‌های خارج از ترتیب را بافر می‌کند تا اینکه تمام بسته‌ها به طور کامل دریافت شوند، سپس تمام آنها را مرتب کرده و تحویل برنامه کاربردی می‌دهد.
  • سنگین - TCP برای برقراری ارتباط سوکت و پیش از شروع ارسال اطلاعات کاربر، احتیاج به سه بسته دارد. TCP با استفاده از کنترل ازدحام قابلیت اطمینان را فراهم می‌آورد.
  • جریانی - داده‌ها به صورت جریانی از بایت‌ها خوانده می‌شوند.

UDP یک پروتکل بی اتصال (Connectionless) مبتنی بر پیغام ساده‌است. پروتکل‌های بی اتصال نیازی به برقراری ارتباط اختصاصی ندارند. ارتباط به صورت یکطرفه و در یک مسیر ار مبدأ به مقصد و بدون در نظر گرفتن حالت یا وضعیت گیرنده برقرار می‌شود. از جمله خصوصیات این پروتکل می‌توان به موارد زیر اشاره کرد:

  • غیر مطمئن - زمانیکه پیغامی ارسال می‌شود، نمی‌توان فهمید که آیا این پیغام به مقصد رسیده‌است یا خیر؛ ممکن است پیغام مورد نظر در میانه راه از دست رفته باشد. در این نوع پروتکل مفهومی به نام «تصدیق» یا Acknowledgement، ارسال دوباره یا زمان انقضاء وجود ندارد.
  • بدون ترتیب - اگر دو پیغام به یک گیرنده فرستاده شود، ترتیب دریافت پیغام‌ها به هیچوجه مشخص نخواهد بود.
  • سبک - در این پروتکل هیچگونه ترتیب پیغام، ردگیری ارتباط و غیره وجود ندارد. بنابراین بار پردازشی خاصی نیز بر شبکه تحمیل نمی‌کند.
  • بسته داده - بسته‌ها به صورت تکی ارسال شده و تنها زمانیکه به مقصد برسند از نظر یکپارچگی مورد بررسی قرار می‌گیرند. بسته‌ها دارای حد صریح و روشنی هستند که برای گیرنده کاملاً مشخص است.
  • عدم وجود کنترل ازدحام - UDP به خودی خود از ازدحام جلوگیری نمی‌کند و این احتمال وجود دارد برنامه‌هایی که پهنای باند زیادی مصرف می‌کنند باعث بروز ازدحام شوند، مگر اینکه در لایه کاربردی تمهیداتی برای کنترل ازدحام در نظر گرفته شده باشد.

جستارهای وابسته[ویرایش]

منابع[ویرایش]

مشارکت‌کنندگان ویکی‌پدیا، «User Datagram Protocol»، ویکی‌پدیای انگلیسی، دانشنامهٔ آزاد (بازیابی در ۲۹ ژوئیه ۲۰۱۱).

پانویس[ویرایش]

  1. اندرو تنن‌بام. «فصل ششم، لایه انتقال». در شبکه‌های کامپیوتری. ترجمهٔ حسین پدرام، احسان ملکیان، علیرضا زارع پور. ویرایش چهارم. تهران: نص، 1382. 523-522. 
  2. همان، ص 537.