Toad的博客

动机

当使用者在X windows系统下运行的Telnet客户端，对于远程的Telnet来说，分辨客户端得X显示定位就非常有用。例如，用户可能希望从远程的服务器开启另一个X应用程序，而这个服务器使用的是与Telnet客户端相同的显示定位。这个选项的目的是通过telnet连接使得这个信息可利用。

点击下载：[PDF]RFC1096_Telnet X 显示定位选项_中文版

简介

Sun的网络文件系统(NFS)协议提供了对网络中的共享文件进行透明的远程访问。NFS协议被设计为适合于不同的机器，操作系统，网络体系和传输协议。这种广泛的适应性是通过使用建立在外部数据描述(XDR)之上的远程过程调用（RPC）原语得到的。此协议的实现已经存在于从个人电脑到超级电脑等不同种类的机器之上，。

对安装协议的支持允许服务器分发远程访问优先级给一个受限制的客户集。它执行了操作系统特定的功能，以允许把远程目录树链接在本地的文件系统上。

点击下载：[PDF]RFC1094_NFS网络文件系统协议说明书_中文版

点击下载：[PDF]RFC1091_TELNET终端类型选项_中文版

简介

在RFC821（"SIMPLE MAIL TRANSPORT PROTOCOL"，SMTP，简单邮件传输协议）的附录D中提到了直接将SMTP置于X.25虚电路（ISO第3层）上的可能性。并建议“利用一种类似于TCP可靠的端到端协议在X.25的连接上”。在1981年时，考虑到PSDNs的总体的可靠性，这毫无疑问是可行的。这一业务现在（1989年）已经非常可靠，它允许直接将其置于虚电路业务上。

在包括22个不同的国家的24个PSDN网的许多产品，证明了这种方法是成功的，结果证明，即使使用在一些花费比较昂贵的PSDN中，这种方法还是十分经济的，在X.25专网和X.25局域网中，这种方法也是成功。

每一个SMTP会话必须打开一条X.25虚电路（Virtual Circuit ，VC），SMTP会话将使用由VC提供的全双工通道。通常，VC是由发起呼叫的一方关闭的。

点击下载：[PDF]RFC1090_SMTP在X.25_中文版

序言

本文档旨在给出在NetBIOS网络上传输IP数据报的具有兼容性和互操作性的实现方法。

NetBIOS标准描述了创建虚拟电路并发送和接收点对点、多点传送和广播数据报的一种方法。本规范仅用了数据报服务。

本备忘录的前期版本使用NetBIOS 广播数据报服务代替NetBIOS组名服务实现IP广播。 现在这些版本已经作废。

点击下载：[PDF]RFC1088_IP 数据包传输通过NetBIOS网络的标准_中文版

简介

在IP网络上多播的草拟标准目前存在[2]，但没有支持网间多播的路由选择协议。本备忘录描述了实验性的路由选择协议，叫做DVMRP，它实现了网间多播。DVMRP使RIP中的许多特性和在Deering[3]中所描述的截断方向路径广播（TRPB）算法相结合。

DVMRP是一个“内部网关协议”；适合在自治系统内的使用，但不能在不同的自治系统之间使用。当前开发的DVMRP不能用于为非多播数据报选路，因此要想一个路由器既能为多播数据报又能为单播数据报选路，则它必须运行两个分离的路由选择进程。DVMRP被设计成易于扩展的，可以扩展成为单播数据报选路。

开发DVMRP是为了试验[3]中所描述的算法。RIP用作这次开发的起始点是因为有一个实现版本可用，而且距离矢量算法与连接状态类算法[4]相比较简单的。另外，为了试验穿越不支持多播的网络可行性，开发了一种叫“隧道”的机制

多播转发算法需要构建基于路由信息的树。构建这颗树需要的状态信息比RIP被设计能提供的要多。因为DVMRP在某些方面比RIP复杂的多。已经具有许多所需要的状态的连接状态算法，可能为Internet上多播选路和转发提供了更好的基础。

DVMRP在一个非常重要的方面与RIP有不同之处。RIP按照路由和转发数据报的方式思考。 DVMRP的目的是为了了解到多播数据报出发地的返回路径。为了将DVMRP解释的和RIP一致，单词“目的地”用来代替更恰当的“出发地”但读者应该记住数据报并不被转发到这些目的地，而是起源于那里。

本备忘录被组织为下列部分：

—对DVMRP进行描述。

—解释隧道。

—展示路由算法。

—展示转发算法。

—列出不同的时间值。

—说明配置信息。

本备忘录不分析距离矢量路由，也不充分解释距离矢量算法；要想获得这方面主题的更多信息，请参看[1]。在本备忘录中执行路由和转发功能的一个进程或多个进程被称作“路由器”。

点击下载：[PDF]RFC1075_远距离矢量多播选路协议_中文版

随着窗口系统的日益流行，Telnet客户端总是运行在一个可变尺寸的窗口中。Telnet服务器为了正确控制光标，需要知道窗口的尺寸。窗口可能在Telnet的会话过程中改变尺寸，更新的窗口尺寸需要传送给服务器。本备忘录就确定了一个从客户端到服务器发送用字符表示的窗口高度和宽度的选项。

Telnet选项：协商输出行宽（NAOL）和协商输出页尺寸(NAOP)在语义上并不是很恰当，他们不是公用的[见RFC-1011 "正式Internet协议",和"防卫协议手册"]。NAOL和NAOP选项是双向的（也就是说服务器可以控制客户端的行宽或者页尺寸），在每一轴中限制253个字符。

这个选项是正常窗口协商过程的一个较好的模型。客户端完全控制它的窗口尺寸，只是简单地告诉服务器当前的窗口是多大。而且，253个字符的高度和宽度的限制非常低，所以，新的选项具有65535字符的限制。最后，这个选项同时发送窗口的高度和宽度，因为窗口高度和宽度通常都是同时改变的。许多操作系统和窗口应用程序更可能认为窗口的高度和宽度是同时改变的。

点击下载：[PDF]RFC1073_Telnet窗口大小选项_中文版

传统的邮政服务可以被看作是一个简单网络的例子。其工作过程使我们都很熟悉：把信
放在信封里，写出最终收信人地址，然后投进本地的邮筒里。之后我们这些终端用户，可以
简单地相信“邮政网络”能在某个合理的时间内（通常是几天）把信送到目的地。我们承认
有时信可能会丢失。由于我们了解邮政服务的局限性，我们要采用自己的端到端策略来确保
传输的成功（例如几天后给收信人打个电话，或每隔几天邮寄原信件的拷贝，直到接收人回
复他已经收到邮件）。网络本身既不看信封中的内容来决定该做什么，也不会对信封中的内容
做任何修改。所有额外的服务（例如，若信件发往国外时信件内容的翻译、给信加上安全措
施或转发信件的多份拷贝）都是由在各自一端的人（也就是智能边缘）来完成的。
从终端用户的观点来看，尽力而为的IP网络就像是一个很简单的、功能齐全的实体，其
首要的任务就是把数据分组从一点传到另一点。终端用户通常是运行在一个与IP网络相连的
终端点上的应用程序；这些终端点都采用数字IP地址来标识。当前的Internet是基于IPv4的；
在其协议中采用32位（4个字节）的值来表示终端点的IP地址。习惯上我们用点分整数的形式
来记录这些地址，即用句点分隔的4个十进制数字分别代表了构成IP地址的每个字节。例如32
位二进制地址10000000010100001100010100000011用点分整数的形式可记为
128.80.197.3。从理论上说，最多可有232个唯一的IPv4地址，但是下面你会看到实际可以使用的地址数目要比这少的多。

终端有时被通称为主机，尽管并不完全准确。因为一个主机（一台PC机、工作站或任何
能与IP网络相连的物理实体）实际上可能支持多个IP终端（即多穴主机，其每个终端点是由
一个与主机相连的唯一的网络接口来代表的）。分配给特定终端的IPv4地址取决于它在什么地
方与IP网络相连。因此，IPv4地址同时表征了标志和位置。如果应用系统从一个主机移到另
一个主机上，或者主机改变了与IP网络的连接点，那么用于标识应用系统的IP地址也必须改
变。

一般的应用系统既不用了解也不需要关心IP网络的内部情况，应用系统所需要知道到的
仅仅是与其进行分组交换的其它终端的IP地址。（图1-1表示一个终端向另一个终端发送分组，
发送端所要了解的就是目标端的地址—w.x.y.z）。分组的内容是任何可以用数字化表示的信
息—图像、文本、声音、影片等—其内容只受应用系统复杂度的限制。IP网络本身并不关
心每个终端上应用系统发送的信息内容的具体含义。采用简单网络/智能边缘的方式，所有重
要的过程都发生在网络的终端上，而不是发生在网络的中间，这种方法也就是所说的端到端
的模型。

注：IP地址与完全限定域名（FullyQualifiedDomainNames,FQDN，即类似
www.lucent.com或whitehouse.gov这种让人易读的地址格式）有着密切的关系。尽管这
种文字化的地址有时也被认为是IP地址，但实际上它们不是。如果一个用户的应用系
统采用FQDN，一个被称为域名系统（DNS）的系统就会将这个地址解析为相应的IP地
址，而这个操作对应用的用户是透明的。应用系统是用解析出的数字IP地址与其它主
机建立分组通信。

在着手研究I n t e r n e t的服务质量（ Q o S）之前，我们首先来回顾一下现今的互连网协议
（即I P协议）网络的发展状况以及推动其进一步发展的应用需求。这一章涵盖了尽力而为
（Best Eff o r t）的I P技术的基础，以及如何影响其自身的发展道路。本章还阐述了现有的I P技
术在面临下一代应用（例如I n t e r n e t电话、IP虚拟专用网（ Virtuoll PriVate Netwark, VPN）以
及多媒体We b发布等）需求时存在的局限。
注如果你已经了解IP网络的基本知识，例如IP寻址、子网、前缀、最短通路寻路、路
由器和路由协议的作用、以及为什么现今的I n t e r n e t只提供尽力而为的服务，那么你可
以跳过这一章。我们在这一章中的主要目的是对一系列背景知识的回顾，以便于开始
讨论下一代的新技术，而这种新技术要求把Q o S加到I n t e r n e t中去。因为现在的I n t e r n e t
是基于IP协议版本4（IPv4）的，我们还是需要对其进行一下回顾。
“网络应该尽可能地简单”是I P网络互连最基本的原则之一，即网络只需要为相对“左右
缩2智能化”的边缘设备之间的通信提供最小的功能集。它代表一种与传统电信网络完全不同
的设计观点。通常电信网的设计是为了配合极端简化的终端用户设备（如用户的电话机），而
尽量提高网络智能化程度。
I n t e r n e t的发展受益于微电子系统在处理能力和精密程度方面令人惊异的快速发展，特别
是嵌入式计算机和日益普及的的个人电脑（ P C）的发展。1 9 8 0年以后，这些设备的发展已经
使简单网络/智能边缘（simple network / smart edge）的设计模型成为可能；事实上，它也的
确为成千上万的工程师和网络爱好者提供了开发I n t e r n e t应用（智能服务）的工具。而与之相
对，电信业通常受到政府或大公司的严格控制，因此电信智能网络服务的进展受到他们所控
制的专业工程试验室在这方面取得进展的限制。作为智能化终端的P C平台的快速发展无疑成
为2 0世纪9 0年代I n t e r n e t成功的一个重要原因（尽管所有传统电信行业也在努力开发和介绍它
们自己的数字网络服务）。
简单的I P网络所要求的最小功能是其连接性—即如果存在任何可能的通路，数据分组就
可以在一段合理的时间内从源端传送到目的端。对合理时间所定义的范围可以从毫秒级到秒
级，最终也许不能保证任何发送的分组都能到达其目的地。但是，我们通常都假定智能化的
边缘设备及其所支持的应用程序能够对这种情况进行某种处理。这个原理就是，而且现在仍
然是尽力而为网络的定义。
即使是一个简单的网络，也会要求有某种程度的内部智能，以便能在源端和任何要到达
的目的端之间找到合适的通路，这也就是I P路由协议完成的功能。尽管我们会很兴奋地认为
I P的选路功能能够动态地适应由战争或自然界灾难引发的网络故障，但现今的I P路由协议通
常只能处理可预见的变化（由重新配置引起）和对大规模系统造成影响的不可预见故障。
然而，人们还是强烈希望I P网络能扩展其最小功能集的功能，不仅仅是提供简单的连接
功能。需要实时信息传送和交互的终端用户程序通常要求网络能保证快速的和可预测的响应
时间。商业I P网络的客户希望得到可靠的带宽保证。这些新应用都需要一个以传输及时性和
可预测性为其首要特征的网络。

RPC模式

Sun RPC协议基于远程过程调用模式,它类似于本地过程调用模型.在本地调用方式中,调用者把参数放在公众指定地点(如注册窗口),然后发送控制到过程,最后重新获得控制.接着,从指定地点取出过程结果,调用者继续执行.

远程过程调用相类似.控制线程在两个过程中逻辑转换:调用过程和服务过程.调用过程首先发送一个调用信息到服务过程然后等待应答信息.调用信息包括过程参数,应答信息包括过程结果.一旦接收到应答信息,就取得过程结果,然后调用执行继续进行.

在服务器端,过程保持睡眠状态到调用信息的到达.当一个调用信息到达,服务器获得过程参数,计算结果,发送应答信息,然后等待下一个调用信息.

在这种模型中,任何时间里两个过程只有一个激活.但是,该模型只是作为一个例子.Sun RPC协议对并行模型执行没有限制,但是其它的有可能不一样.例如,一个应用程序可能选择RPC调用为异步的,因此客户端只有等到服务器端的应答才做有效工作.另外一个可能是使服务器端生成一个新的任务来处理进来的调用,因此最初的服务器可以处理其他请求. 远程调用和本地过程调用有几个重要区别:

1.错误处理:在远程过程调用中，网络或远程服务器的失败必须处理.

2.全局变量和副作用:因为服务器没法访问客户地址空间,隐藏的参数不能用全局变量传递或返回副作用.

3.表现:远程过程操作比本地过程调用慢一到几个数量级.

4.鉴定:因为远程过程可以在不安全的网络中传输,必须采用鉴定.

结论是即使有工具自动为给定服务产生客户或服务器库,仍然必须仔细设计协议.

点击下载：[PDF]RFC1057_RPC远程步骤呼叫协议说明书版本 2_中文版