RFC 791 - Internet Protocol - Summary

其他语言版本：

RFC 791是南加州大学信息科学研究所为DARPA(国防高级研究项目机构)所写的. 本文件分为导言、概述和规格三个部分。虽然《导言和概览》有很好的资料,但本摘要将侧重于规格,但将突出概述的各节.

页眉

从这个网站的"框架"和"包"文章中可以看出,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)

页眉细节

可以看到数据格图包含多个元素. 每个要素的功能是:

版本 - RFC 791特指版本4
互联网信头长度(IHL) - 将信头长度和数据何时开始告知复读系统
服务类型(TOS) - 此8位值用于服务质量.
- bit 0-2 为优先级
  - 000 - 常规
  - 001 - 优先权
  - 010 - 即时
  - 011 - 闪光
  - 100 - 闪光覆盖
  - 101 - 犯罪/经济犯罪
  - 110 - 互联网工作控制
  - 111 - 网络控制
- 位 3 用于正常延迟 (0) 或低延迟 (1)
- bit 4 表示正常吞吐量( 0) 或高吞吐量(1)
- bit 5 用于正常可靠性( 0) 或高可靠性 (1)
- 当 RFC 791 被写为第 6 和第 7 位时, 保留用于将来使用
总长度 - 以字节表示的数据图的总长度可达65535octets. 然而,一个系统必须能够接受至少567克特.
识别 -- -- 用于重新组装零散数据
旗帜 - 用于数据克分解
- 位为 0 , 必须是 0
- 如果设置为 0, 则比特 1 允许对数据格进行发酵。如果设置为 1, 数据图不能被分割
- 设置为 0 的比特 2 表示最后一个发烧。如果设定为再有1个碎片出现
分解偏移 - 告诉进行数据gram分解的系统在哪里可以分解
活命时间 - 指出数据图表在网络上可以持续多久. 如果达到0, 数据图必须被丢弃
协议 - 表示数据图中使用的下一级协议
标题校验和 - 通过网络验证每个点的数据图
源地址 - 32 位元
目标地址 - 32 位
选项 - 有很多IPv4选项可以应用,也可以不应用. 详情请参见《联邦金融公司条例》第15-22页全文
在页眉后方,数据格被加入了0's,直到结束在32位边框

RFC 概要

与所有RFC的这种RFC一样,要求任何执行IP数据gram的单行本与标准一致,使任何一方都可以与不同系统的数据gram进行交互. 第3节详细讨论了涉及计划的IPv4以及上文概述的功能。相对于IPv4,这个RFC定义了A类,B类和C类网络大小. A类为网络分配了7比特,为主机分配了24比特. B类分配14个比特用于网络,16个比特用于主机. C类为网络分配了21位,为主机分配了8位. 除了处理方案外,在区域渔业委员会内还详细讨论了数据图分解和重新组装的具体功能。指定当一个数据包被打碎时可能包含或不包含一些选项.

参考先前关于实施IP Datagram的统计,RFC还举例说明了应当向上层协议提交哪些配置元素,以方便系统之间的交流和配置。这些elemenets是用于构建数据克的同一种元素.