RFC 791 - Internet Protocol - Summary

همچنین قابل دسترس از:

RFC 791 در سال 1981 برای DARPA (اداره پروژه های تحقیقاتی پیشرفته) توسط دانشگاه علوم اطلاعات کالیفرنیای جنوبی نوشته شده است. این سند به سه بخش، مقدمه، بررسی و مشخصات تقسیم می شود. اگرچه مقدمه و بررسی اطلاعات بسیار خوبی دارند، این خلاصه بر مشخصات تمرکز می کند اما بخش های afew را از مرور کلی برجسته می کند.

Header

همانطور که در مقاله فریم ها و بسته ها در این سایت دیده می شود، هدر IP به نظر می رسد:

IPv4 Header (32 bits)
Starting Byte	Byte								Byte								Byte								Byte
	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	Version				IHL (header Len)				Type Of Server (TOS)								Total Length
4	Identification																IP Flag			Fragment Offset
8	Time To Line (TTL)								Protocol								Header Checksum
12	Source Address
16	Destination Address
20	IP Option (Variable Length, Optional, not common)

جزئیات Header

همانطور که می توانید ببینید، Datagram شامل چندین عنصر است. عملکرد هر عنصر:

نسخه RFC 791 به طور خاص به نسخه 4 اشاره دارد
طول سرسر اینترنت (IHL) - سیستم های بازیابی طول هدر و زمانی که داده ها شروع می شود
نوع خدمات (TOS) - این مقدار 8 بیتی برای کیفیت خدمات استفاده می شود.
- 0-2 مخفف Precedence
  - 000 - Routine
  - 001 - اولویت
  - 010 فوری -
  - 011 - Flash
  - 100 - فلش Override
  - 101 - CRITIC/ECP
  - 110 - کنترل اینترنت
  - ۱۱- کنترل شبکه
- کمی 3 برای تاخیر طبیعی (0) یا تاخیر پایین (1)
- کمی 4 برای خروجی طبیعی (0) یا High Byput (1)
- کمی 5 برای قابلیت اطمینان طبیعی (0) یا قابلیت اطمینان بالا (1)
- هنگامی که RFC 791 نوشته شد، حدود 6 و 7 که در آن ذخیره شده برای استفاده در آینده
مجموع طول - آیا کل طول Datagram در بایت ها تا 6535 octets است. با این حال، یک سیستم باید بتواند حداقل 567 octets را بپذیرد.
شناسایی - استفاده در re-assembling داده های تقسیم شده
پرچم ها - استفاده شده با قطعه داده
- 0 کمی رزرو شده و باید 0
- کمی 1 اگر تنظیم به 0 اجازه می دهد تا یک Datagram به حاشیه رانده شود. اگر تا 1 تنظیم شده باشد، نمی تواند تقسیم شود
- 2 اگر تنظیم به 0 نشان دهنده آخرین حاشیه است. اگر به 1 قطعه دیگر برسد
بخش قطعه – افست به سیستم هایی که حاشیه داده را اجرا می کنند، می گوید که در آن می تواند تقسیم شود
زمان برای زنده ماندن – مشخص کرد که چه مدت می تواند در شبکه باقی بماند. اگر آن را به 0 صفحه داده باید دور انداخته شود
پروتکل - پروتکل سطح بعدی مورد استفاده در Datagram
Header Checksum - اعتبار داده ها را در هر نقطه از طریق شبکه
آدرس منبع - 32 بیت
آدرس مقصد - 32 بیت
گزینه ها - بسیاری از گزینه های IPv4 وجود دارد که ممکن است یا ممکن است اعمال نشود. برای جزئیات اضافی لطفاً تمام RFC را به طور خاص صفحه 15 - 22 بخوانید
در پایان هدر، نمودار داده ها با 0 به پایان می رسد تا زمانی که آن را در 32 کمی محدود به پایان می رسد

RFC خلاصه

همانطور که با تمام RFC این RFC نیاز دارد که هر گونه indivdual که IPdatagram را پیاده سازی می کند، با استاندارد سازگار است، به طوری که هر حزب ممکن است با داده های سیستم های مختلف ارتباط برقرار کند. در بخش 3، طرح آدرس IPv4 به طور طولانی مورد بحث قرار می گیرد زیرا توابع خلاصه شده در بالا هستند. در ارتباط با IPv4 این RFC کلاس A، B و اندازه شبکه C را تعریف می کند. کلاس A 7 بیت را برای شبکه و 24 بیت برای میزبان اختصاص می دهد. کلاس B 14 بیت را برای شبکه و 16 بیت برای میزبان اختصاص می دهد. کلاس C 21 بیت را برای شبکه و 8 بیت برای میزبان اختصاص می دهد. علاوه بر پرداختن به طرح ها، توابع خاص تقسیم بندی داده ها و جمع آوری مجدد در جزئیات عالی در RFC مورد بحث قرار می گیرد. مشخص کنید که برخی از گزینه ها ممکن است یا ممکن است زمانی که یک بسته تقسیم می شود، گنجانده نشود.

ارجاع به یک ارزیابی قبلی در مورد پیاده سازی IP Datagram RFC همچنین مثال هایی در مورد آنچه که باید به پروتکل های لایه بالا برای عناصر پیکربندی ارائه شود ارائه می دهد تا ارتباط و پیکربندی آسان تر بین سیستم ها را تقویت کند. این elemenets همان عناصری هستند که برای ساخت Datagram استفاده می شوند.