天天看点

Telnet Protocol

Telnet Protocol

远程登录 (Remote Login) 是 Internet 上最广泛的应用之一。我们可以先登录 ( 即 ) 注册到一台主机然后再通过网络远程登录到任何其他一台网络主机上去,而不需要为每一台主机连接一个硬件终端 ( 当然必须有登录账号 ) 。

在 TCP/IP 网络上,有两种应用提供远程登录功能。

Telnet 是标准的提供远程登录功能的应用,几乎每个 TCP/IP 的实现都提供这个功能。它能够运行在不同操作系统的主机之间。 Telnet 通过客户进程和服务器进程之间的选项协商机制,从而确定通信双方可以提供的功能特性。

Rlogin 起源于伯克利 Unix ,开始它只能工作在 Unix 系统之间,现在已经可以在其他操作系统上运行。

Telnet 是一种最老的 Internet 应用,起源于 1969 年的 ARPNRT ,它的名字是“电信网络协议 (telecommunication network protocol) ”的缩写词。

远程登录采用客户 - 服务器模式。

在这张图中,有以下要点需要注意:

◆      Telnet 客户进程同时和终端用户和 TCP/IP 协议模块进行交互。通常我们所键入的任何信息的传输是通过 TCP 连接,连接的任何返回信息都输出到终端上。

◆      Telnet 服务器进程经常要和一种叫做“伪终端设备” (pseudo-terminal device) 打交道,至少在 Unix 系同下是这样的。这就使得对于登录外壳 (shell) 进程来讲,它是被 Telnet 服务器进程直接调用的,而且任何运行在登录外壳进程出的程序都感觉是直接和一个终端进行交互。对于像满屏编辑器这样的应用来讲,就像直接在和终端打交道一样。实际上,如何对服务器进程的登录外壳进程进行处理,使得它好像在直接和终端交互,往往是编写远程登录服务器进程程序中最困难的方面之一。

◆      仅仅使用了一条 TCP 连接。由于客户进程必须多次和服务器进行通信 ( 反之亦然 ) ,这就必然需要某些方法,来描绘在连接上传输的命令和用户数据。

◆      在 TCP/IP 实现中,虚线框的内容一般是操作系统内核的一部分。 Telnet 客户进程和服务器进程只是属于用户应用程序。

◆      把服务器进程的登录外壳进程画出来的目的是为了说明:当我们想登录到系统的时候必须要有一个账户, Telnet 和 Rlogin 都是如此。

◆      远程登录不是那种有大量数据报传输的应用。 [Paxson 1993] 发现客户进程发出的字节数 ( 用户在终端上键入的信息 ) 和服务器进程端发出的字节数的数量之比是 1 : 20. 这是因此我们在终端上键入的一条短命令往往令服务器进程端产生很多输出。

Rlogin 的第一此发布时在 4.2BSD 中,当时它仅能实现 Unix 主机之间的远程登录。这就使得 Rlogin 比 Telnet 简单。由于客户进程和服务器进程的操作系统预先都知道对方的操作系统类型,所以就不需要选项协商机制。在过去的几年中, Rlogin 协议也派生出几种非 Unix 环境的版本。

RFC1282 详细说明了 Rlogin 协议。类似于选路信息协议 (RIP) 的 RFC ,它是 Rlogin 用了多年后才发布的。

Telnet 客户的转义符:

和 Rlogin 的客户进程一样, Telnet 客户进程也可以使用户直接和客户进程客户进程进行交互,而不是被发送到服务器进程。通常客户的转义字符是 Control-](control 键和右括号键,通常以“ ^] ”表示 ) 。这使得客户进程显示它的提示符,通常是“ telnet> ”。这时候有很多命令可供用户选择,以改变连接的特性或打印某些信息。大多数的 Unix 客户进程提供 ”help” 命令,该命令将显示所有可用的命令。

选项协商:

虽然我们可以认为 Telnet 连接的双方都 NVT, 但是实际上 Telnet 连接双方首先进行交互的信息时选项协商数据。选项协商时对称的,也就是说任何一方可以主动发送选项协商请求给对方。

对于任何给定的选项,连接的任何一方都可以发送下面 4 种请求的饿任意一个请求。

发送方 接收方 描述
WILL   -> 发送方想激活选项
<-   DO 接收方说同意
WILL   -> 发送方想激活选项
<-   DONT 接收方说不同意
DO     -> 发送方想让接收方激活选项
<-     WILL 接收方同意
DO    -> 发送方想让接收方激活选项
WONT  <- 接收方说不同意
WONT  -> 发送方想禁止选项
<-   DON’T 接收方必须说同意
DON’T  -> 发送方想让接收方禁止选项
<-    WONT 接收方必须说同意

Telnet 在有三种不同的操作方式下选项协商的情况。这些方式包括:单字符方式、实行方式和准行方式。

单字符方式,该方式类似于 Rlogin 。用户在终端输入的每个字符都由终端发送到服务器进程,服务器进程的相应也以字符方式回显到终端上。

Rlogin 服务器和 Telnet 服务器通常都将设置 TCP 的保活选项以检测客户主机是否崩溃。这两种应用都采用了 TCP 紧急方式,以便即使从服务器到客户的数据传输被流量控制所终止,服务器仍然可以向客户发送命令。

rfc854: Telnet 协议规范

这个 RFC 详细说明了 ARPA 互联网社区的一个标准。在 ARPA 因特网的上的主机应该采用和实现这个标准。

简介:

TELNET 协议的目的在于提供一个通用性良好的,双向的,面向八字节通讯机制。它的主要目标是允许终端设备和面向终端的过程能通过一个标准过程进行互相交互。另外,可以预想,该协议可以应用到终端到终端通信 (“ 连接 ”) 和过程到过程通信 ( 分布计算 ) 中。

总则

一个 TELNET 连接是一个传输带有 TELNET 控制信息的数据传输的 TCP 连接。

TELNET 协议是基于三个主要观点构建的:首先,网络虚假终端的概念;第二,协商选项原则;第三,终端和过程对称的观点。

1.     当一个 TELNET 连接开始被建立时,每个终端是产生了,终端在一个网络虚假终端上,一个网络虚拟终端是一个想象的设备,它提供规范终端的一个标准的,网络的,中间层的表示。这个消除了对服务器和客户器需要保持各个终端特有的特性和终端处理协议信息的需要。所有的主机包括用户机和服务器,都映射到它们本地设备特性和约定,这就好像用虚拟终端通过网络通讯。而且每一方都可以假设对方也有一个类似的映射。 NVT 有意地使过度受限 ( 没有提供给主机足够的词汇来映射到他们的本地字符集 ) 和过度包含 ( 使用适当的终止来处罚用户 ) 达到了平衡。

注意 :” 用户 ” 机通常指那些进行连接的物理终端, ” 服务器 ” 提出指的是那些能够提供一些服务的机器。从终端到终端或过程到过程的可应用的平等性来看, ” 用户 ” 指的是初始化通信连接的机器。

2 .可谈判的选项的观点基于这样一个事实 : 许多主机都希望能够在 NVT 之上提供更多的服务,而许多用户将会拥有一个更复杂的终端,并且希望能够得到一流的,而不是极少的一点服务。尽管相互独立,但建立在 TELNET 协议中的是许许多多的 ” 选项 ” ,这些选项将被用来认可及同 ”DO,DON’T,WILL,WON’T” 结构 ( 下面将会讨论 ) 一起使用去允许用户和服务器同意在他们的 TELNET 连接上使用更精致的 ( 或者可能是完全不同的 ) 协议集合。这些选项包括改变字符集,回显,等等。

建立选项使用的基本策略,是让每一方 ( 或双方 ) 初始化一个使一些选项有效的请求,另一方可以接受或拒绝该请求。如果该请求被接受了,选项立即生效 ; 如果该请求被拒绝,连接的另一端仍然保留 NVT 的特性。很显然,一方经常可以通过拒绝来使能,而从来不能通过拒绝来取消一些选项,因为这些选项是双方为了支持 NVT 而准备的。

我们已经建立了一套谈判选项的规则,使得双方在同时请求一个相同选项的时候,每一方都可以把对方的请求当作对自己的请求的肯定回应。

3 .谈判句法的对称性可能会导致无穷尽的应答循环 -- 每一方都把对方发送过来的命令当作必须回答的请求而不是对方的应答。为防止这种循环,可以应用下面这些规则 :

1.     a .一方只能请求改变选项的状态。也就是一方不能只发送宣布它所使用的模式的请求。

2.     b .如果一方所接收到的请求是要求它进入当前它所在的状态,那么该请求将不会被应

答。这种不应答对防止无穷尽的循环是非常重要的。对于那些改变模式的请求,都需要一个

应答 -- 尽管该模式不一定改变。

3.     c .无论何时,只要一方向第二方发送一个选项命令,不管该命令是请求还是应答,而

且使用该选项将会对从第一方发送到第二方的数据进行处理时生产影响,那么必须把该命令

插到数据流中它希望开始起作用的点上。 ( 要注意到在传送请求和接收到可能是否定的应答

的过程需要一些时间。因此,一台主机可能在发出请求一个选项的请求后希望缓冲要发送的

数据,直到它知道该请求是被接受还是被拒绝,来隐藏这段对用户来说是 " 不确定 " 的时间。 )

网络虚拟终端:

网络虚拟终端是一个双向的字符设备,这个终端有一个打印机和一个键盘。打印机对收到的数据响应,键盘产生发出的数据,它是通过 TELNET 连接发送出去,并且在需要“回显”时,同时在 NVT 的打印机上回显这些数据。“回显”并不要求数据一定要经过网络(尽管有一个选项可以控制该操作的“远程”模式,但并不要求主机实现该选项)。

除了在这里说明的外,所有的编码集合都是有八位的,但只使用其中的七位的 USASCII 码。所有的代码转换和时区方面的问题都是本地的事情,而不影响 NVT 。

数据的传输:

尽管一个通过网络连接的 TELNET 连接本质上时全双工的,但通常把 NVT 看作在线性缓冲模式下的半双工设备。也就是说,除非已经和对方谈判好,以下情形,对应于通过 TELNET 连接进行数据的传输。

1)         在本地缓冲空间允许的可用范围内,可以在产生数据的机器上汇集数据,直到完整的一行数据已经准备好,或者某些在局部定义的信号明确地要求传输数据。这些信号即可以有进程产生,也可以有用户发出。

定义这个规则的动机是,处理网络输入中断的代价是很高的,另外,缺省的 NVT 规范指定“回显”操作的数据部经过网络的传输。因此,有理由在产生数据的源上缓冲一些数据。许多系统都会在输入一行结束后进行一些动作(行式打印机或者卡片打印机经常都是这样子的),因此数据传输可以在一个数据结束时触发。另外,有时候一个用户或者进程会发现有必要或者应该提供一些不在一行的结尾结束的数据,因此实现者要注意,提供的局部信号机制要确保所有的缓冲数据都能够被立即发送出去。

2)         当一个过程已完成向一个 NVT 打印机发送数据,并且输入队列中也没有来自 NVT 键盘,需要进一步进行处理的数据 ( 就是说,当一个在 TELNET 连接的一端的过程无法再另一端没有数据输入的情况下进行处理 ) ,该过程必须传输 TELNET 的继续 (Go Ahead, GA) 命令。

注意:由于 TELNET 模型的对称性,从理论上来说,在一个 TELNET 连接的每一端,都必须有一个 NVT

连接的建立:

TELNET TCP 连接是在用户端口 U 和服务器端口 L 之间建立的。服务器在用于这种类型的连接的一个总所周知的端口 L 上监听客户的请求。由于一个 TCP 连接是全双工的,并且通过双方的端口来标示,服务器可以对不同的用户端口 U 和端口 L 的之间的许多并发连接进行应答。

端口分配:

当用户来给远程用户提供访问服务主机的服务(也就是远程终端访问),这个协议分配了服务端口 23 (八进制 27 )。也就是 L=23 。