TELNET协议规范讲解.doc

TELNET协议规范 ARPA Internet上的主机被要求采用并实现此标准。 　 　 介绍 TELNET Protocol的目的是提供一个相对通用的，双向的，面向八位字节的通信方法。它主要的目标是允许接口终端设备的标准方法和面向终端的相互作用。可以预见到，此协议也可被用于终端到终端的通信和处理到处理的通信（分布式计算）。 　 　 一般考虑 一个TELNET连接是一个用于传输控制协议的传送数据的。TELNET 协议是建立在以下三个想法上的：首先是网络虚拟终端的概念；其次是对话选项的方法；最后是终端和处理的协调。 　 当一个TELNET连接被初次建立时，每一端都被假设使用了网络虚拟终端，也就是NVT。NVT是一个想象中的标准设备通用设备的代表。这就消除了“服务器”和“用户”机要了解对方机器终端的特点，而终端可以直接处理对话。所有的主机，用户端的和服务器端的，它们自己本地的设备特点因此在网络上可以作为一种NVT处理，任何一个都可以认为对方使用的是相同特点的设备。NVT倾向于不过多地限制（提供了一个相应比较丰富的映射到本地设备的字符集），也不是包括一切的（它要求用户使用适当的终端）。注意：用户机通常是与处理终端连接的主机，服务器机通常是提供某种服务的机器。从另一点看，在终端到终端或进程到进程的通信上，用户机是发起通信的机器。 规定选项的原理将以下事实考虑在内，许多机器希望在现在的NVT上提供另外的服务，多数用户有比较复杂的终端，它们也就希望一种比较完整的而不是最小的服务。独立的，但是存在于 TELNET 协议的不同选项支持这些需求，它们使用DO, DONT, WILL, WONT 结构允许用户机和服务器建立建立一种更加精巧的TELNET会话连接。这种选项包括改变字符集，响应模式等等。设置选项的基本策略是任一方（或者两者）初始化要求一个选项生效的请求。另一方可以接受也可以拒绝这一请求。如果接受请求，此选项立刻生效；如果被拒绝，连接仍然保持基本的NVT的连接属性。很明显，一方可以拒绝另一方关于启用某一选项的请求，但是不能拒绝另一方关于使一选项失效的请求，因为双方必须准备支持NVT。对话选项语法的建立使在双方都发出请求某一选项生效的请求时，另一方可以直接认为收到对方的确认信息。 这种对称式的对话语法潜在地引起了一个不可终止的确认环--任何一方都将收到的确认信息看作是请求，而不是一个确认信息。为了防止这种循环的出现，有下面的规则： 任何一方仅可以要求对选项状态的变化：例如，一方不可以发出请求，仅仅说明它在什么样的选项状态下。 如果一方接收到好象是请求的信息，请求进入一个已经进入的状态，此信息将被看作是一个确认消息。这种非响应从本质上防止了不可终止的对话的循环。如果要求发送一个要求改变状态的请求，即使状态并未改变。 无论何时，一方发送选项命令到另一方，无论作为一个请求或者是一个确认消息，选项的使用将对发送的数据处理有影响，这样命令应该被插入到希望发生作用的数据流中的数据点之前。（应该注意，传送请求和收到确认消息之间有一定的时间间隔，这是被动方式的。因此，一个主机希望在要求一个选项后缓存数据，直到它知道它的请求是否被接受，这样就可以使这段不不确定时间对用户不可见。）选项的请求可以在建立TELNET连接时十分频繁地来往交换，因为每一方都希望从对方得到更好的服务。 除此以外，选项也可以在连接持续过程中动态改变来适应本地机器条件的变化。例如，NVT（它将以后被详细解释）对于许多“一次一行”的应用程序，如BASIC是十分适用的，而对于如NLS的“一次一字”的应用程序却不怎么好用。服务器可能被选择作为“一次一字”法则来适应在其上运行的本地进程，它将发起对话以达到合适的选项状态。然而，相对于永久地负责这种多余的处理负担；它可以通过会话，在不需要这样的选项状态下回到NVT状态。由一个进程发起的请求可以导致一个不可终止的请求循环，如果此进程对一个拒绝请求的响应是再次要求此选项。为了防止这样循环的发生，被拒绝的请求在其它事情发生变化之前不能被重复请求。这可能意味着，进程运行另外一个程序，或者用户发送另外的命令，或者用户对于环境或选项的改变。 比较好的方法是，预请求应该作为由另一端发送信息的结果而发生，或者由于人为介入而发生。选项的设计者不应该因为对于选项会话的种种限制而感觉到伸不开手脚。一般语法的目的是更容易地拥有选项--因为表示对它们的忽视也是容易的。 如果特定的选项需要除DO, DONT, WILL, WONT以外的更丰富的结构，正确的方针是使用DO, DONT, WILL, WONT来建立连接解释这种新结构，当这一解释工作完成时，就可以自由地使用这一新结构了。例如，一方可能发送请求改变（或建立）每行的长度。如果接受了这些，对于对话的不同行长度