科技: 人物 企业 技术 IT业 TMT
科普: 自然 科学 科幻 宇宙 科学家
通信: 历史 技术 手机 词典 3G馆
索引: 分类 推荐 专题 热点 排行榜
互联网: 广告 营销 政务 游戏 google
新媒体: 社交 博客 学者 人物 传播学
新思想: 网站 新书 新知 新词 思想家
图书馆: 文化 商业 管理 经济 期刊
网络文化: 社会 红人 黑客 治理 亚文化
创业百科: VC 词典 指南 案例 创业史
前沿科技: 清洁 绿色 纳米 生物 环保
知识产权: 盗版 共享 学人 法规 著作
用户名: 密码: 注册 忘记密码?
    创建新词条
科技百科
  • 人气指数: 6712 次
  • 编辑次数: 2 次 历史版本
  • 更新时间: 2009-07-09
方兴东
方兴东
发短消息
方兴东
方兴东
发短消息
相关词条
刘韵洁
刘韵洁
钱华林
钱华林
张树新
张树新
Charles Hedrick
Charles Hedrick
杰·西·亚·利克里德
杰·西·亚·利克里德
拉里·罗伯茨
拉里·罗伯茨
文顿·瑟夫
文顿·瑟夫
保尔·贝恩
保尔·贝恩
Einar Stefferud
Einar Stefferud
推荐词条
希拉里二度竞选
希拉里二度竞选
《互联网百科系列》
《互联网百科系列》
《黑客百科》
《黑客百科》
《网络舆情百科》
《网络舆情百科》
《网络治理百科》
《网络治理百科》
《硅谷百科》
《硅谷百科》
2017年特斯拉
2017年特斯拉
MIT黑客全纪录
MIT黑客全纪录
桑达尔·皮查伊
桑达尔·皮查伊
阿里双十一成交额
阿里双十一成交额
最新词条

热门标签

微博侠 数字营销2011年度总结 政务微博元年 2011微博十大事件 美国十大创业孵化器 盘点美国导师型创业孵化器 盘点导师型创业孵化器 TechStars 智能电视大战前夜 竞争型国企 公益型国企 2011央视经济年度人物 Rhianna Pratchett 莱恩娜·普莱契 Zynga与Facebook关系 Zynga盈利危机 2010年手机社交游戏行业分析报告 游戏奖励 主流手机游戏公司运营表现 主流手机游戏公司运营对比数据 创建游戏原型 正反馈现象 易用性设计增强游戏体验 易用性设计 《The Sims Social》社交亮 心理生理学与游戏 Kixeye Storm8 Storm8公司 女性玩家营销策略 休闲游戏的创新性 游戏运营的数据分析 社交游戏分析学常见术语 游戏运营数据解析 iPad风行美国校园 iPad终结传统教科书 游戏平衡性 成长类型及情感元素 鸿蒙国际 云骗钱 2011年政务微博报告 《2011年政务微博报告》 方正产业图谱 方正改制考 通信企业属公益型国企 善用玩家作弊行为 手机游戏传播 每用户平均收入 ARPU值 ARPU 游戏授权三面观 游戏设计所运用的化学原理 iOS应用人性化界面设计原则 硬核游戏 硬核社交游戏 生物测量法研究玩家 全球移动用户 用户研究三部曲 Tagged转型故事 Tagged Instagram火爆的3大原因 全球第四大社交网络Badoo Badoo 2011年最迅猛的20大创业公司 病毒式传播功能支持的游戏设计 病毒式传播功能 美国社交游戏虚拟商品收益 Flipboard改变阅读 盘点10大最难iPhone游戏 移动应用设计7大主流趋势 成功的设计文件十个要点 游戏设计文件 应用内置付费功能 内置付费功能 IAP功能 IAP IAP模式 游戏易用性测试 生理心理游戏评估 游戏化游戏 全美社交游戏规模 美国社交游戏市场 全球平板电脑出货量 Facebook虚拟商品收益 Facebook全球广告营收 Facebook广告营收 失败游戏设计的数宗罪名 休闲游戏设计要点 玩游戏可提高认知能力 玩游戏与认知能力 全球游戏广告 独立开发者提高工作效率的100个要点 Facebook亚洲用户 免费游戏的10种创收模式 人类大脑可下载 2012年最值得期待的20位硅谷企业家 做空中概股的幕后黑手 做空中概股幕后黑手 苹果2013营收 Playfish社交游戏架构

Charles Hedrick 发表评论(0) 编辑词条

路由信息协议(RIP)——1988

发明人:Charles Hedrick

发明故事:Hedrick负责开发了RIP协议,这种协议可以让路由器确定它们要和哪些网络通信,这些网络距离它们有多远。ARPANET(互联网的始祖)就使用RIP作为其初期的路由算法。

User Name: hedrick@rutgers.edu
Full Name: Charles;Charles L. Hedrick
Email: hedrick at rutgers dot edu

目录

RIP路由协议简介 编辑本段回目录

RIP 的历史影响

RIP 是最早的距离矢量路由协议。尽管 RIP 缺少许多更为高级的路由协议所具备的复杂功能,但其简单性和使用的广泛性使其具有很强的生命力。RIP 不是“即将被淘汰”的协议。实际上,现在已经出现了一种支持 IPv6 的 RIP,称为 RIPng(ng 是 next generation 的缩写,意为“下一代”)。

RIP 从 Xerox 开发的早期协议 - 网关信息协议 (GWINFO) 演变而来。随着 Xerox 网络系统 (XNS) 的发展,GWINFO 逐渐演变成 RIP。此后,由于 Berkeley 软件分发 (BSD) 的 routed(读作“route-dee”,而不是“rout-ed”)守护程序中采用了 RIP,RIP 因而得以广泛流行。其它厂商也相继开发出了大同小异的自有 RIP 版本。由于意识到需要对该协议进行标准化,所以 Charles Hedrick 在 1988 年编写了 RFC 1058,他在该文档中记录了现有协议并进行了一些改进。自那时起,RIP 不断完善,1994 年出现 RIPv2,1997 年出现 RIPng。
 
ripv1的特征和消息格式
 
RIP 的特征
 
RIP 主要有以下特征:
.RIP 是一种距离矢量路由协议。
.RIP 使用跳数作为路径选择的唯一度量。
.将跳数超过 15 的路由通告为不可达。
.每 30 秒广播一次消息。
 
RIP 消息的数据部分封装在 UDP 数据段内,其源端口号和目的端口号都被设为 520。在消息从所有配置了 RIP 的接口发送出去之前,IP 报头和数据链路报头会加入广播地址作为目的地址。
 


RIP 消息格式:RIP 报头
RIP 报头长度为四个字节,这四个字节被划分为三个字段,如图中橙色区域所示。命令字段指定了消息类型。版本字段设置为 1,表示为 RIPv1。第三个字段被标记为必须为零。“必须为零”字段用于为协议将来的扩展预留空间。
 
RIP 消息格式:路由条目
消息的路由条目部分包含三个字段,其内容分别是:地址类型标识符(设置为 2 代表 IP 地址,但在路由器请求完整的路由表时设置为 0)、IP 地址以及度量。路由条目部分代表一个目的路由及与其关联的度量。一个 RIP 更新最多可包含 25 个路由条目。数据报最大可以是 512 个字节,不包括 IP 或 UDP 报头。
 
为什么很多字段都设置为零?
RIP 开发得比 IP 更早,以前是用于其它网络协议(如 XNS)。BSD 也对其产生一定影响。最初添加额外的空间是为了今后支持更大的地址空间。RIPv2 目前已经使用了这些空字段的绝大部分。
 
IP 地址类和有类路由
RIP 是有类路由协议。我们知道 RIPv1 不会在更新中发送子网掩码信息。因此,路由器将使用本地接口配置的子网掩码,或者根据地址类应用默认子网掩码。受此限制,RIPv1 网络不能为不连续网络,也不能使用 VLSM。
 
network 命令的作用如下:

在属于某个指定网络的所有接口上启用 RIP。相关接口将开始发送和接收 RIP 更新。
在每 30 秒一次的 RIP 路由更新中向其它路由器通告该指定网络。
注: 如果您输入子网地址,IOS 会自动将其转换到有类网络地址。例如,如果您输入命令 network 192.168.1.32,路由器将把它转换为 network 192.168.1.0。
 
强大的故障排除命令
要检验路由和排除路由故障,请首先使用 show ip route 和 show ip protocols。如果使用这两条命令不能找出问题,那么请使用 debug ip rip 命令查看详细情况。我们将按照检验路由和排除路由故障时这三条命令的建议使用顺序来分别讨论它们。请记住,在配置任何路由(无论静态或动态)时,请使用 show ip interface brief 命令确保所有必需的接口都处于“up”和“up”状态。


解读 show ip route 输出
现在我们以 R1 获知的一条 RIP 路由为例来解读路由表中显示的输出。
R 192.168.5.0/24 [120/2] via 192.168.2.2, 00:00:23, Serial0/0/0
通过检查路由列表中是否存在带 R 代码的路由,我们可快速得知路由器上是否确实运行着 RIP。如果没有配置 RIP,您将不会看到任何 RIP 路由。
紧跟在 R 代码后的是远程网络地址和子网掩码 (192.168.5.0/24)。
AD 值(RIP 为 120)和到该网络的距离(2 跳)显示在括号中。
此外,输出中还列出了通告路由器的下一跳 IP 地址(地址为 192.168.2.2 的 R2)和自上次更新以来已经过了多少秒(本例中为 00:00:23)。
最后列出的是路由器用来向该远程网络转发数据的送出接口 (Serial 0/0/0)。
 
解读 show ip protocols 输出
如果路由表中缺少某个网络,可以使用 show ip protocols 命令来检查路由配置。show ip protocols 命令会显示路由器当前配置的路由协议。其输出可用于检验大多数 RIP 参数,从而确认:
.是否已配置 RIP 路由
.发送和接收 RIP 更新的接口是否正确
.路由器通告的网络是否正确
.RIP 邻居是否发送了更新
此命令对于检验其它路由协议的工作情况也非常有用
 
解读 debug ip rip 输出
大多数 RIP 配置错误都涉及 network 语句配置错误、缺少 network 语句配置,或在有类环境中配置了不连续的子网。对于这种情况,可使用一个很有效的命令 debug ip rip 找出 RIP 更新中存在的问题,如图所示。该命令将在发送和接收 RIP 路由更新时显示这些更新信息。因为更新是定期发送的,所以您需要等到下一轮更新开始才能看到命令输出
 
不必要的 RIP 更新会影响网络性能
 
在 LAN 上发送不需要的更新会在以下三个方面对网络造成影响:
1. 带宽浪费在传输不必要的更新上。因为 RIP 更新是广播,所以交换机将向所有端口转发更新。
2. LAN 上的所有设备都必须逐层处理更新,直到传输层后接收设备才会丢弃更新。
3. 在广播网络上通告更新会带来严重的风险。RIP 更新可能会被数据包嗅探软件中途截取。路由更新可能会被修改并重新发回该路由器,从而导致路由表根据错误度量误导流量。
 
停止不需要的 RIP 更新
您可能会想到使用 no network 192.168.3.0 命令从配置中删除 192.168.3.0 网络,从而停止该更新,但这样做的后果是 R2 将不会在发往 R1 和 R3 的更新中通告该 LAN。正确的解决方法是使用 passive-interface 命令,该命令可以阻止路由更新通过某个路由器接口传输,但仍然允许向其它路由器通告该网络。在路由器配置模式下输入 passive-interface 命令。
Router(config-router)#passive-interface interface-type interface-number

TCP/IP 协议概貌编辑本段回目录

作者:Charles L. Hedrick

翻译:waterbird[AKA]

Copyright (C) 1987, Charles L. Hedrick. Anyone may reproduce this document, in whole or in part, provided that: (1) any copy or republication of the entire document must show Rutgers University as the source, and must include this notice; and (2) any other use of this material must reference this manual and Rutgers University, and the fact that the material is copyright by Charles Hedrick and is used by permission.

  TCP/IP 是一个协议的分层集合。为理解此含义,让我们看一个例子,MAIL。首先,有一个MAIL的协议。它定义了一个从一台机器向另一台机器发送的命令集合,即那些指定谁是信息的发送者、谁是接受者以及信息的内容。该协议假定已经存在一条在两台计算机之间通讯的可靠通道。和其他应用协议一样,MAIL简单定义了一个命令集以及要发送的内容。它被设计为和TCP、IP一起使用。TCP保证命令被发送到另外一端,它跟踪要发送的东西,并在发送失败时重发信息。如果信息的内容(邮件长度)太长了,大于一个数据报的长度,TCP会把他们拆成几个数据报分别发送,并保证它们能够正确到达。因为这些函数在许多应用中都能用到,它们被打包成一个单独的协议,而不是作为MAIL协议的一部分。从编程的角度看,你可以认为TCP协议是一个函数库,调用它们可以和另一台计算机进行可靠的网络通讯。与此类似,TCP又要调用IP提供的服务。尽管很多应用都使用TCP提供的服务,也有一些应用不需要它。可是,存在一些每个应用都需要的服务。它们就被一起放进IP协议之中。象TCP一样,你可以认为IP是一个TCP要调用的函数库,当然,其他未用到TCP的协议也可以直接调用它。这种构造几个不同层次的协议的策略被成为“分层”。 我们把MAIL、TCP、 IP这样的应用程序看作是各个相互独立的“层”,它们都调用位于自己“下面”的那个层提供的服务。通常,TCP/IP应用使用4个层:

* 应用协议如MAIL

* 一个为其他应用提供服务的协议,如TCP

* IP, 提供最基本的服务,把数据报送到目的地

* 一个需要处理特定物理传输介质的协议,如以太网或点到点连接

  TCP/IP是基于“catenet”模型的。(详见IEN 48) 该模型假设许多个相互独立的网络通过网关连接在一起。用户可以从网络的任何地方访问其上的计算机和资源。数据报在到达目的地之前通常要经过许多不同的网络。完成此任务的路由工作对用户应该是完全不可见的。对用户而言,所有他需要知道的只是另一个系统的“Internet 地址”。这是一个类似 128.6.4.194 这样的地址。它实际上是一个32位数字。但是,它经常被写为4个10进制数字,每个数字代表地址的8 位。(Internet 文档 用"octet"一词表示这样的8位数据块,而不用"字节",因为TCP/IP也被其他一些非8位字节的计算机所支持。注:指在那些计算机中,1个字节并非是通常的8位)通常,该地址本身就向你透漏了些如何到达它们的信息。例如, 128.6 是由有关负责机构分配给 Rutgers 大学的网络号。Rutgers 大学使用下一个octet 来表示哪个校园的以太网。 128.6.4刚好是计算机系所使的以太网。最后那个octet可以用来表示该以太网上254个不同的系统。(因为0和255被禁用,原因稍后详述。) 注意 128.6.4.194和128.6.5.194将分属不同的系统。稍后我们再详细讨论Internet地址的结构。

  通常我们用名称而不是Internet地址来表示一个系统。当我们指定一个名称,网络软件就去查找数据库,返回它对应的Internet地址。 (见RFC 882)

  TCP/IP基于无连接技术。信息作为一个“数据报”序列传递。“数据报”是数据集,它作为一个单独的信息发送。这些“数据报”各自独立通过网络。有一些关于建立连接的条文。(即开始一个可持续的会话)然而在某些层,这些连接下的信息被拆分成数据报,这些数据报被网络单独传送。例如,设想你要传一个15000字节的文件。很多网络无法处理这么大的数据报。因此,协议会把它分成30个500字节大小的数据报,分别传送到另一端,然后再重新组装回一个15000字节大小的文件。网络在传输这些数据报时,并不知道它们之间的联系。包14很可能先于包13到达目的地。也可能由于网络的故障,某个数据报没能通过网络,这时它将被重发。

  注意,数据报和“包”一词常常可以互换。技术上,数据报是正确用语。数据报是协议处理的数据单元。包是在以太网或网线上出现的一个物理实体。多数情况下,一个包仅仅包含一个数据报,因此二者差别甚微。但他们仍有不同。当在X.25协议上使用TCP/IP时,X.25接口把数据报拆分成128字节的包。这对IP是不可见的,因为在另一端TCP/IP处理它之前各个包又被重新组装回原来的数据报格式了。这里,一个IP数据报有多个包来负载。但是对于绝大多数介质,采取一个包一个数据报的方式最为有效,因此它们之间就没什么差别了。

  ---- TCP层

  处理TCP/IP数据报用到两个协议。 其中 TCP(传输控制协议)负责把信息分割成一个个数据报、在另一端将他们重组、丢失时重新发送以及保证他们的正确顺序。 IP(Internet协议)则负责各个数据报的路由、寻径(routing) 。看起来好象TCP作了所有工作。而事实上对小型网络也正是如此。可是在Internet中,单单传一个数据报到目的地就是件非常复杂的工作。连接可能要求数据报经过Rutgers的几个网络、再经过通往冯.诺依曼超级计算中心的一根串行线、再经过那里的以太网、再经过到另一个NSFnet的一根56K电话线,以及另一个校园的以太网。实际表明,跟踪到所有这些地方的路由,以及处理不同传输介质之间的兼容性,是一件很复杂的工作。请注意TCP和IP之间的接口非常之简单。 TCP只是传给IP一个带目的地址的数据报。IP并不知道此数据报同它之前或之后的数据报有什么关系。

  你会觉得这里少了点什么。我们已经谈到了Internet地址,但并无涉及你怎样追踪到一个系统的多条连接。很明显它不足以使一个数据报到达正确的目的地。TCP必须知道该数据报属于哪个连接。这个任务被称为“解析(?)”。事实上,在TCP/IP中存在多个层次的"解析"。解析所需的信息位于一系列“包头”中。包头是协议加在数据报头部的一些附加8位字节,用来对该数据报进行追踪。这很象是你把一封信装入信封,再在外面写上地址。在现代网络中,该过程发生多次。类似以下过程:你把信件放入一个小信封,你的秘书再把它放进一个大信封,学校邮局又把它放入一个更大的信封。 下面是一个典型的TCP/IP网络如何给一个要传输的信息添加包头的:

  以一个简单数据流为例,如你要传递如下文件到其他计算机去:

   ......................................................

   TCP先把它分割成若干个可处理的数据块。(为此,TCP必须知道你的网络的最大可传输数据报的大小。实际上,两端的TCP先交流一下它们各自的最大可传输数据报大小,然后选择最小的那个。)

   .... .... .... .... .... .... .... ....

   TCP给每个数据报都添加一个“报头(header)”。此报头至少包含20个8位字节,其中最为重要的部分是源端口号、目的数据端口和序列号。端口号被用来追踪不同的对话。假设有3个不同的人要传送文件。你的TCP应该为他们分别分配3个端口:1000,1001和1002,这就是源端口号,因为你是该数据报的发送源。当然另一端的TCP也为会话分配了一个它自己的端口号。你的TCP必须知道另一端的那个端口号。(它用来判断何时开始连接。)它将其写入目的端口地址域。显然,如果是另一端向你发数据,源端口和目的端口应该倒过来,它是源而你却成了目的所在。每个数据报都有一个序列号。目的端据此来判断它以正确的顺序接受数据报,以及是否丢失数据报。TCP并不以数据报为单位计数,而是以8位字节数来计数。因此如果在每个数据报中有500个8位字节,那么第一个数据报的序号为0,第二个就为500,下一个就为1000,如此类推。 最后来谈谈校验和(Checksum)。它是将数据报中所有的字节相加所得之和。结果被放入报头中。另一端的TCP接受到数据报后,重新再算一遍校验和。如果二者不一致,该包就被认为有错而被抛弃。现在,数据报的格式就是这样子了:

   
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     
   Source Port          |       Destination Port        |
   
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     
                 Sequence Number                        |
   
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     
             Acknowledgment Number                      |
   
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Data
|           |U|A|P|R|S|F|                               |
     | Offset|
Reserved  |R|C|S|S|Y|I|            Window             |
     |       |       
  |G|K|H|T|N|N|                               |
   
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     
    Checksum            |         Urgent Pointer        |
   
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | 
your data ... next 500 octets                               |
     |   ......
                                                    |
 

  如果我们将TCP“报头”缩写为"T",则整个文件现在就是这样子了:

   T....   T....   T....   T....   T....   T....   T....

  你会注意到报头中有些东西我还未描述到。通常它们是用来管理连接的。为了确保数据报已经到达了目的地,接收方必须送回一个“确认”。这是一个填充了“确认号码”的数据报。例如,送回一个确认号为1500的数据报表明你已经收到了所有1500号以前的数据报。如果发送方在一段合理长的时间内未收到确认,它将再次发送数据。窗口是用来控制一次可以发送多少数据。如果每次都等到收到前一个数据报的确认后才发送下一个数据报,传输效率就太低了。 另一方面,你也不能马不停蹄地只管发送。因为那样一个快速的计算机的发送速度会超过一个慢速接收方的接受能力而导致溢出。 因此每个接收端在自己的“窗口域”中显示一个数字来表示自己当前准备接收的新的数据量。当计算机接收数据时,窗口中的数据逐步减少,减到0时,发送方将停止发送数据。当接收方处理数据时,窗口中的数据逐步增加,表明它可以接受更多的数据了。通常,负责发确认信号的哪个数据报也负责通知发送方可以继续发送新的数据了。(通过一个更新了的窗口) “紧急域”(Urgent)允许一端通知另一端跳过一个特定的字节而不加处理。这常常用于处理异步事件,例如在你敲入一个控制字符或其他命令中断输出时。其它域超出了本文档的讨论范围。

  3 IP层

  TCP把每个数据报都送给IP。当然它必须告诉IP另一端计算机的Internet地址。注意这才是IP要关心的。它并不在乎数据报的内容,甚至也不在乎TCP头的内容。IP只是为数据报找到路由,将其送到另一端。为了让网关及其他中间系统传送数据报,IP为数据报加上自己的报头。报头中主要包含源端IP地址(32位地址,如128.6.4.194)、目的端IP地址、协议号和一个校验和。源端IP地址就是你的机器的地址。(必须,另一端靠它获知数据报的来源)目的端IP地址是另一台机器的地址。(必须,中间的网关靠它获知数据报的目的地)协议号告诉另一端的IP将数据报送给TCP协议进行处理而非其它。尽管很多IP传输都使用TCP,但也能使用IP的其它协议,因此你必须告诉IP究竟把数据报送给哪个协议。最后,校验和允许另一端的IP验证数据报头是否在传输中被损坏。注意,TCP和IP都有各自的校验和。IP需要验证数据报头是否在传输中被损坏,否则就会将消息送到错误的目的地。但是,使用TCP协议对TCP的报头和数据单独计算一个校验和更加有效、也更加安全(原因篇幅所限,恕不在此详述)。一旦IP准备好了报头,格式将如下所示:


    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Version|  IHL  |Type of Service|          Total Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Identification        |Flags|      Fragment Offset    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Time to Live |    Protocol   |         Header Checksum       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Source Address                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Destination Address                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  TCP header, then your data ......                            |
    |                                                               |

  如果我们将IP的报头用"I"来表示,我们要传输的数据将如下所示, 其中T代表TCP的报头:


   IT....   IT....   IT....   IT....   IT....   IT....   IT....

  同样,报头中也有一些未被讨论的域。它们大多超出了本文档的范围。标志位(flags)和段偏移量 (fragmentoffset)被用于当一个数据报不得不被拆分时追踪数据碎片。对于某些最大传输数据包尺寸较小的网络,当大数 据 报经过时,就需要将它拆开成合适大小的数据报。存活时间(time to live)是一个随着数据报的传输而不断变小的数字。当它减为零时,这个数据报就被丢弃。这可以防止系统中传输环路的 影响。当然这应当是很少发生的,但是设计良好的网络必须也能够处理这些“意外”情况。

  到现在,我们不再需要报头了。如果你的计算机跟目的计算机刚好有一个直接的电话线连接,或通过网关相连,它可以简单地把数据发送出去。(尽管可能还会用到一个同步协议如HDLC,但它只是在开始和结束加上几个8进制数)

   4 以太网(Ethernet)层

  然而今天多数网络都使用以太网。所以我们现在必须描述一下以太网的报头。不幸的是,以太网有自己的地址。设计以太网的人希望确保世界上所有计算机都有一个唯一的以太网地址。而且,它们不想让用户去担心如何分配以太网地址的问题,因而每个以太网控制器(网卡)出厂时就自带了一个唯一的地址。为确保不会重复,设计者为以太网地址留出了48位空间。制造以太网设备的厂家必须到一个权威机构进行登记,以确保他们使用的以太网地址不会跟其他厂家的重复。以太网是以“广播方式”工作的。它象是那种老式的会议电话。当你往以太网上发送一个数据报后,网络上所有的计算机都能看到它。因此必须有种机制来保证正确的机器才能接收它。如你所猜,这涉及到以太网报头。每个以太网数据包都有一14个八进制数长的报头,它包括源以太网地址、目的以太网地址和一个类型码。每台机器都被假定只对发给自己的数据报 ----目的以太网地址和自己地址相等的数据报----即感兴趣。(当然,进行欺骗是绝对可行的,这就是以太网通讯是绝对不安全的一个原因)注意,在以太网地址和因特网地址(即IP地址)之间并无必然联系。每台机器都有一个以太网地址和IP地址的对照表。 (稍后我们将对此进行进一步讨论)除了地址,报头还包含一个类型码。这个类型码允许多种不同的协议族在同一个网络上运行。 因此你可以同时使用TCP/IP, DECnet, Xerox NS,等等,它们每个都往报头的类型域中填入不同的数值。最后,也有一个校验和。由以太网控制器负责计算所有数据包的校验和。当另一端收到数据报后,它重新计算校验和,扔掉与原先校验和不一致的数据包。 这个校验和被放在数据包的尾部,而非头部。最后,你的数据变成了下面这个样子:


   
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     
Ethernet destination address (first 32 bits)            |
   
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |
Ethernet dest (last 16 bits)  |Ethernet source (first 16 bits)|
   
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     
Ethernet source address (last 32 bits)                  |
   
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     
 Type code              |
   
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  IP
header, then TCP header, then your data                   |
     |           
                                                  |
         ...
     |      
                                                       |
     |   end of your
data                                            |
   
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     
                Ethernet Checksum                       |
   
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
  如果我们用"E"来代替以太网数据报头,用"C"来代替以太网校验和,你的文件看起来将是这个样子:

   EIT....C   EIT....C   EIT....C   EIT....C   EIT....C

  当这些数据包被另一端收到后,所有的报头都会被移走: 以太网接口会移走以太网数据报头和以太网校验和。它看一看类型码。因为这里类型码是IP,所以以太网设备驱动器将数据包向上送给IP; IP移走IP报头。它看一看IP的协议域,发现协议类型是TCP,于是将包送给TCP; TCP检查一下序列号,它使用序列号以及其他信息将各个数据包合起来形成原来的文件。

  TCP/IP 协议概貌介绍到此结束。当然还有很多重要的概念没有得到详细的论述。接下来我们将回过头来在各个地方添加一些细节。(详细描述请参考RFC 793 for TCP, RFC 791 for IP, and RFC's 894 and 826 for sending IP over Ethernet.)

数据包分离和重新组装编辑本段回目录

翻译:Liu Zehua
    版权所有,1987,Charles L. Hedrick. 任何人在符合下列条件下可以复制这份文档的一部分或者全部:(1) 任何对本文档的完整复制或再版必须注明 Rutgers University是该文档的来源,同时附上本布告;(2)任何其它对本文档的使用必须提及本文档以及Rutgers University,以及说明本文档为Charles Hedrick版权所有,而且是在许可之下使用。

    TCP/IP是设计来使用于不同种类的网络。不幸的是,对大的信息包应该是怎样,不同网络的设计者有不同的看法。以太网信息包可以长达1500字节(八位字节)。ARPA网的却最多只有大约1000字节。一些非常快的网络有大更多的信息包大小。首先,你可能以为IP只需要尽可能小的大小。可是,这会导致严重的性能问题。当传送大文件时,大的信息包比小的要有效率得多。所以我们需要能够使用尽可能大的信息包大小。但是我们也需要可以处理有信息包大小限制的网络。对于这一点,有两种方法。第一,TCP能够协商数据包的大小。当打开一个TCP连接时,连接的两端可以传送他们能够处理的最大数据包大小。比较小的一个就被采用。这种方法允许两个可以处理大数据包的网络使用大的数据包,同时允许他们和不能处理大数据包的网络通讯。可是,这并没有彻底解决问题。最严重的问题是连接的两端不需要知道这其中所有的步骤。例如,当在Rutgers()和Berkeley(柏克利大学)之间传送数据时,两端的计算机都在以太网上的可能性很高。因此两端都可以处理1500字节的数据包。但是,建立起来的连接同时需要经过ARPA网。ARPA网不可以处理那么大的数据包。因为这一点,很多方法可以用来把数据包分成几部分。(这个叫做“分段”(fragmentation)) IP头信息包含了该数据包是否可以分离以及怎样可以把分离的个部分重新合并的完整信息。如果一个网关连接一个以太网到ARPA网,它必须接收1500字节的以太数据包,把它分离成几部分,再把这些转换成可以在ARPA网上用的包。此外,每一个应用TCP/IP的主机都必须可以接收这种已经分离的部分并把他们重新组合。这个叫做“重新组装”(reassembly)。

    不同的TCP/IP应用在怎样确定使用什么数据包大小这一方面并不一致。很多 TCP/IP应用使用576字节的数据包,当它们不能确认整个传输路径都可以处理大数据包。使用这个相当保守的策略是因为有很多TCP/IP应用的重新组装的程序有问题。应用者通常要避免分段的出现。不同的应用者有不同的途径去决定什么时候可以使用大数据包。有一些人只在局域网使用大数据包。其他人会在同一个校园内的网络之间使用。576字节是一个“安全”的大小,这是每一个TCP/IP应用所必须支持的.

参考文献编辑本段回目录

→如果您认为本词条还有待完善,请 编辑词条

词条内容仅供参考,如果您需要解决具体问题
(尤其在法律、医学等领域),建议您咨询相关领域专业人士。
0

标签: Charles L. Hedrick

收藏到: Favorites  

同义词: Charles L. Hedrick

关于本词条的评论 (共0条)发表评论>>

对词条发表评论

评论长度最大为200个字符。