TCP/IP网络上，有两种应用提供远程登录功能：
1.Telnet：几乎每个TCP/IP的实现都提供这个功能，它能够运行在不同操作系统的主机之间。Telnet通过客户进程和服务器进程之间的选项协商机制，从而确定通信双方可以提供的功能特性。
2.Rlogin：起源于伯克利Unix，开始它只能运行在Unix系统之间，现在它已经可以在其他操作系统上运行。
Telnet是最老的一种Internet应用，起源于1969年的ARPANET（高级研究计划局网络，Advanced Research Projects Agency Network，通常称其为阿帕网，是美国国防高级研究计划局开发的世界上第一个运营的数据包交换网络，是全球互联网的鼻祖），Telnet的名字是电信网络协议telecommunication network protocol的缩写词。
上图需要注意以下几点：
1.Telnet使用的是TCP连接。
2.Telnet服务器进程需要和伪终端设备交互（至少在Unix下是这样的），这使得对于登录shell进程来说，它是被Telnet服务器进程直接调用的，且任何运行在登录shell处的程序都感觉是在直接和一个终端进行交互。
3.由于只用了一条TCP连接，且客户进程和服务器进程都会互相多次发送消息，因此需要某些方式来区分发送的是命令还是数据。
4.上图用虚线框把终端驱动进程、伪终端驱动进程、TCP/IP实现框了起来，虚线框中的内容一般是操作系统内核的一部分。而Telnet客户进程和服务器进程属于用户程序。
5.上图中，我们在服务器主机上显示登录shell来重申我们需要登录到服务器，我们必须在服务器所在系统中有账户来登录，不管是Telnet还是Rlogin都是这样。
通过比较Telnet和Rlogin的客户进程和服务器进程源代码的行数，就可以知道这两者的复杂程度：
现在仍然不断有新的Telnet选项被添加到Telnet中，这使得Telnet的源码数量不断增加；而Rlogin依然变化不大，还是比较简单。
远程登录不是那种有大量数据报传输的应用，客户进程和服务器进程交互的分组大多比较小。[Paxson 1993]发现，由客户发送的字节数（用户在终端上的输入）与服务器返回的字节数之比大概是1:20，这是因为终端上键入的一条短命令往往令服务器进程端产生许多输出。
Rlogin第一次发布是在4.2 BSD中，当时它仅能实现Unix主机间的远程登录，这使得Rlogin比Telnet简单。由于客户进程和服务器进程的操作系统都能预知对方的操作系统类型（都是Unix），因此不需要选项协商机制。Rlogin协议后来也派生出了几种非Unix版本。
当Rlogin的客户进程和服务器进程的TCP连接建立完毕后，会发生以下动作：
1.客户进程给服务器进程发送4个字符串：
（1）1个字节0。
（2）用户登录进客户进程主机的登录名，以字节0结束。
（3）要登录进的服务器端主机的登录名，以字节0结束。
（4）用户进程终端类型+/+用户进程终端速率，以字节0结束。
发用户进程的终端类型是由于大多满屏应用程序需要知道终端类型；发终端速率是由于有些应用随着终端速率的改变，它的操作也有所变化，如vi编辑器，当速率比较小时，它的窗口也变小，这样就不会花费很长时间重新绘制窗口。
2.服务器进程返回1个字节0。
3.服务器进程可选择要求用户输入口令，这个步骤的交互没有特别的协议，被当作是普通的数据传输，服务器进程通常发送一个字符串显示在客户进程的屏幕上，通常是password:，如果在一定的限定时间内（通常60秒）客户进程没有输入口令，服务器进程将关闭该连接。通常可以在远程用户的$HOME目录下生成一个文件.rhosts，其中每行记录包含一个主机名和一个客户用户名，如果我们从指定的主机以对应的客户用户名登录，此时服务器进程不提示客户输入口令，但这样做有安全漏洞，强烈建议不使用这个特性。如果输入口令，则口令会以明文形式发送到服务器进程，如果有人能截取网络上的原始传输的分组，他就可以截获用户口令，为避免这个问题，新版的Rlogin客户程序采用了Kerberos安全模型，可避免口令在网络上以明文传播，这要求服务器进程也支持Kerberos。
4.服务器进程通常要向客户进程发送请求询问其窗口大小。
Rlogin客户进程每次给服务器发送一个字节的内容，并且接收服务器进程的所有返回信息，这里使用了Nagle算法，从而可以保证在速率较低的网络上，若干输入字节以单个TCP报文段传输。
默认，Rlogin的流量控制是由客户进程完成的。客户进程能识别用户键入的STOP和START的ASCII字符（Control_S和Control_Q），并且终止或启动客户自己的终端输出，如果客户进程不能识别这两个字符，每次我们为终止终端输出而键入的Control_S字符向服务器进程传递时，服务器进程还在向客户进程发送数据，在输出停止之前，可能有很多字节还会在屏幕上显示：
有时服务器上运行的程序需要自己解释输入的每个字节，而不想让客户对它的输入内容进行处理，如上例中对Control_S和Control_Q的特殊处理（emacs编辑器将这两个字符当作自己的命令），为此，服务器有了告诉客户是否要进行流量控制的能力。
当我们在客户端键入一个中断字符时（DELETE或Control_C，两者都产生SIGINT），也会发生上例这种服务器还继续发送数据直到收到中断字符的情况，而我们的本意是要中断字符尽快终止某进程，使得屏幕上不再有任何响应输出。
对于从客户到服务器之间的数据传送，这个方向上只包含我们键入的字符，因此这些特殊输入字符（Control-S等）不需要TCP紧急方式来传递。
如果是窗口式的显示方式，在客户的应用程序运行时，我们可以动态地改变窗口的大小，一些应用需要知道窗口大小的变化，Rlogin客户需要采用某种方法通知服务器有关窗口大小变化的情况。
Rlogin的服务器进程也可给客户发命令，但只有一条TCP连接可用，所以服务器进程需要给命令字节做标记，使得客户进程可以从数据流中识别出命令，而不是显示在终端上。服务器要给客户发命令时，服务器就进入紧急方式，且把命令放在紧急数据的最后一个字节中，当客户接收到紧急方式通知时，它从连接上读取数据并保存起来，直到读到命令字节（即紧急数据的最后一个字节），此时客户根据读到的命令，再决定对于所读到数据是显示在终端上还是丢弃它。
采用TCP紧急方式发送Rlogin从服务器到客户的命令的原因在于，清仓输出命令需要立即发送给客户，即使服务器到客户的数据流被TCP的窗口流量控制所终止（这是常发生的，因为服务器的输出速率通常大于客户终端的显示速率）。
其他三个命令的实时性并不特别强，但为了简单起见，也采用了和第一个命令相同的技术。
Rlogin中客户到服务器的命令只有一条，就是将当前窗口大小发送给服务器。当客户的窗口大小发生变化时，客户并不立即向服务器报告，除非收到了服务器发来的0x80命令。
客户同样需要对命令字节进行标注，使服务器可以在数据流中识别出命令，而不是把它发送到上层的应用中，处理方法是在两个字节的0xff后跟两个特殊的标志字节。对于窗口大小命令，两个标志字节都是ASCII码的s，之后是4个16bit长的数据（网络字节序），分别是行数、列数、X方向的像素数、Y方向的像素数，通常，后两个16bit是0，因为Rlogin服务器进程调用的应用程序通常以字符为单位来度量屏幕，而非像素点。
从客户到服务器的命令采用的是带内信令，即命令字节和其他的普通数据一起传输，选择0xff字节表示这个带内信令的原因是一般用户操作不会产生0xff这个字节，因此Rlogin是不完备的，如果我们采用某种办法通过键盘产生两个连续的0xff字节+两个连续的ASCII的s字符，则后面字节会被认为是窗口大小。
对于服务器到客户的Rlogin命令，大多数API采用的技术叫做带外数据，所以将其称为带外命令。
由于从客户到服务器的命令使用的是带内信令，因此服务器进程必须检查从客户进程收到的每个字节，看是否有两个0xff字节。对于从服务器到客户的带外信令，客户进程不需要检查收到的每个字节，除非服务器进入了紧急方式，即使在紧急方式下，客户进程也仅仅需要留意紧急指针所指向的字节。由于从服务器到客户的数据量远大于从客户到服务器的数据量，因此带内信令比较适合从客户到服务器这种较少数据量的情况，而带外信令适合于从服务器到客户传输数据这种数据量比较大的情况。
有时，Rlogin客户不需要把键入的信息传输到服务器，而是要和Rlogin客户进程直接通信，方法是在一行的开头键入代字符，即~，后跟以下4个字符之一：
1..：结束客户进程。
2.文件结束符Control_D：结束客户进程。
3.任务控制挂起符Control_Z：挂起客户进程。
4.任务控制延迟挂起符Control_Y：仅挂起客户进程的输入。此时不管客户运行什么程序，键入的信息将由当前运行在客户主机上的程序解释，但从服务器发送到客户的信息还是输出到终端上，这适合当我们需要在服务器上运行一个长时间程序且想知道服务端会输出什么，同时还想在客户端与其他正在其上运行的程序进行交互的场合。
只有当客户的Unix支持任务控制时，以上命令3、4才会生效。
从主机bsdi到服务器svr4的Rlogin建立一个连接时的时间序列，图中去掉了TCP的建立过程、窗口通告、服务类型等信息）：
客户首先发送一个字符0，在收到服务器的ACK后，发送了三个字符串给服务器，分别是客户的登录名rstevens、要登录的服务器用户名rstevens、终端类型和速率ibmpc3/9600，服务器的TCP收到这些信息后，发送了一个ACK，之后服务器进程确认了这些信息后，发送了一个字节0。
随后服务器在报文段7中发送窗口请求命令，这是采用TCP紧急方式发送的，这里是采用了较老的解释，即紧急指针指明的序号是紧急数据的最后一个字节加1。之后客户回送12字节的数据：2字节的0xff、2字节的s、4个16bit长度的窗口数据。
随后服务器发送的4个报文段（10、12、14、16）是服务器操作系统的问候，之后的报文段18是一个7字节长度的shell进程提示符" svr4% "。
随后客户每键入一个字节，就发送一个字节。
客户和服务器都可以主动中断该连接，如果在服务器端输入命令让服务器的shell终止运行，则服务器会中断该连接；如果我们给Rlogin客户键入一个转移符~，紧跟一个句点或一个文件结束符，则客户将主动关闭该链接。
Rlogin的客户进程端口号是1023，这是IANA分配的。Rlogin协议要求客户进程使用小于1024的端口号，这类端口的术语叫保留端口。Unix中，客户进程一般不能使用保留端口号，除非客户进程有root权限，这是客户进程和服务器进程相互鉴别的一部分，这种鉴别可以使得用户可以不需要口令直接登录。
在主机上sun上运行Rlogin客户进程，登录到主机bsdi，向终端输出一个大文本文件，然后键入Control_S中断输出，当输出停止时，键入中断键（DELETE）以异常方式终止该进程：
描述上图过程：
1.键入Control_S以停止终端的输出。
2.用户终端的输出缓存很快被填满，所以Rlogin客户进程向终端的写操作被阻塞。
3.此时客户进程也不能从网络连接上读取数据，所以客户的TCP接收缓存也将被填满。
4.客户的接收缓存已满时，客户进程的TCP会向服务器的TCP通告现在的接收窗口是0。
5.当服务器收到客户的窗口为0的通告时，停止向客户发送数据，这样，服务器的发送缓存也将被填满。
6.由于服务器发送缓存已满，Rlogin服务器进程不能从服务器运行的应用程序cat处读取数据。
7.当cat程序的输出缓存也被填满时，cat将停止。
8.用中断键终止服务器上的cat程序，这个命令从客户的TCP传输到服务器的TCP，该方向上的数据传输没有被流量控制所终止。
9.cat收到终端命令后终止，使得它的输出缓存被清空，这将唤醒Rlogin服务器进程，然后Rlogin服务器进程进入紧急方式，向客户进程发出清仓输出命令。
上图中的阴影部分是服务器的发送缓存中没有被使用的部分。上图中的序号seq#来自下图时间序列中：
报文段1~3是服务器向客户发送的满长度的TCP报文段，此时客户进程不能向终端写信息，所以在报文段4中，客户进程向服务器发送ACK确认时，告诉服务器进程此时接收窗口是1024字节。报文段5中，服务器向客户发送的报文段就不是满长度的了，此时报文段6中客户进程的确认信号所带的接收窗口大小是此时接收缓存的空余字节长度349，但根据糊涂窗口避免技术，应发送0，但如果发送的是0，窗口指针的右边界会向左移动，这是不能发生的。当服务器接收到报文段6的ACK后，它不能再发送全长的报文段，此时它采用糊涂窗口避免技术，不发送任何东西，同时置一个5秒的坚持计时器，当计时器超时，服务器进程才会发送349字节大小的数据，5秒后，服务器发送了报文段7，报文段7中含349字节数据，客户接收到报文段7后，客户进程的接收缓存就满了，于是客户在报文段8的ACK中通告窗口大小此时为0。
我们键入的中断键在报文段9中被传输到服务器进程，服务器进程接收到中断键后，服务器进程把它发送给应用程序cat，cat就终止，由于cat被终端中断键终止，应用就清空它的输出缓存，服务器进程发现后，通过TCP紧急方式向客户进程发送清仓输出命令（报文段10），报文段10告诉客户进程在命令字节前还有3419个字节（从26727到30145）在服务器进程的发送缓存中等待发送。
报文段10采用紧急通知方式发送，包含了服务器进程向客户进程要发送的下一个字节26727，这个字节并不是清仓输出命令字节，它只是服务器进程发送1个字节的数据来试探客户的接收窗口是否关闭，然后客户进程TCP就发送了报文段11通知服务器当前接收窗口还是0，但客户进程内部已经知道了对方有紧急通知。
服务器发送报文段12的原因是，如果连接的一端处于TCP紧急模式，则每收到一个报文段，就会发送一个报文段，这个报文段中没有告诉客户任何新信息，只是重申进入了紧急模式。
当客户进程开始读取已经在TCP输入缓存中等待被读取的数据时，接收窗口会重新打开（报文段13），然后服务器进程就开始正常发送数据（报文段14、15、17、18），报文段18中包含紧急数据的最后一个字节的数据，客户收到该命令后，它就丢弃报文段14、15、17、18所收到的数据，且清空终端的输出缓存。报文段19中的2个字节是中断键的回显^?，最后一个报文段21包含了服务器的shell提示符。
Telnet可工作在任何操作系统之间。
RFC 854定义了Telnet的规范，其中还定义了一种通用字符终端，叫做网络虚拟终端（NVT，Network Virtual Terminal）。NVT是虚拟设备，连接的双方都必须把它们的物理终端转换为NVT格式，同时，不管服务器进程的终端是什么类型，操作系统必须能把NVT格式转换为终端能支持的格式。
NVT是带有键盘和打印机的字符设备，用户击键产生的数据被发送到服务器进程，服务器进程回送的响应输出到打印机上。
术语NVT ASCII指在整个互联网协议套件中使用的ascii字符集的7位美国变体，每个7比特的字符都以8比特格式发送，最高位比特为0。行结束符以回车（CR）+换行（LF）表示，用\r\n表示。单独的一个CR也是以两个字符序列（\r\0）表示。FTP、SMTP、Finger、Whois协议都以NVT ASCII描述客户命令和服务器的响应。
Telnet通信的两个方向都是用带内信令方式。字节0xff叫做IAC（Interpret As Command，作为命令解释），该字节后面的一个字节才是命令字节。如果要发送的数据是0xff，则发送两个连续的0xff（由于Telnet的数据流是NVT ASCII，是7bit的格式，因此255不能在Telnet上传输，但Telnet中有一个选项，可以允许数据以8bit传输）。
Telnet连接双方首先进行交互的信息是选项协商数据，选项协商是对称的，每一方都可以主动发送选项协商请求。
对于任何给定选项，连接的任何一方都能发送以下4种请求之一：
1.WILL：发送方本身想激活该选项。
2.DO：发送方想让接收方激活该选项。
3.WONT：发送方本身想禁止该选项。
4.DONT：发送方想让接收方禁止该选项。
根据Telnet规定，对于激活请求（上述请求1、2），接收方有权同意或不同意，对于使选项失效的请求（上述请求3、4），必须同意，这样4种请求会组合出6种情况：
选项协商需要3个字节：一个IAC字节、一个WILL或DO或WONT或DONT字节、一个指明选项的ID字节。Assigned Number RFC文档中指明选项ID的字节值，以下是部分选项ID：
虽然Telnet的选项协商机制是对称的，但客户进程和服务器进程的任务是不同的，因此有些Telnet选项仅仅适合客户进程，而某些选项仅适合于服务器进程。
有些选项不是仅仅用激活和禁用就能表达的，如指定终端类型，客户进程必须发送一个ASCII字符串表示终端类型，为此，定义了子选项协商机制：
1.首先，连接的某方（通常是客户进程）发送3个字节的字符序列来请求激活自身的该选项，如终端类型选项：
2.之后服务器进程发送如下字符串：
该字符串询问客户进程的终端类型，SB是子选项协商的起始命令标志；24表示子选项是终端类型；下一字节1表示发送你的终端类型；子选项协商的结束命令标志是IAC+SE。
3.如果客户的终端类型是ibmpc，则客户的响应为：
响应中的第四个字节0表示后面内容是我的终端类型，上图中0后面应该有一个逗号与I隔开；之后的字节表示终端类型，用大写字母表示，服务器收到该字符串后会自动转换为小写字符；IAC+SE表示子选项结束标志。
Telnet的服务器进程和客户进程，有4种操作模式：
1.半双工：Telnet以前的默认方式，但现在很少使用了。NVT默认是一个半双工设备，在接收用户输入前，它必须从服务器进程获得GO AHEAD（GA）命令。用户的输入会在本地回显，方向是从NVT键盘到NVT打印机，所以客户进程到服务器进程只能发送整行数据。虽然该方式适用于所有类型的终端设备，但它不能充分发挥目前大量使用的支持全双工通信的终端功能。如果联合使用ECHO和SUPPRESS GO AHEAD（抑制继续前行）选项，就能使用方式2。SUPPRESS GO AHEAD是一种TELNET选项，它用于取消GO AHEAD信号的发送。GO AHEAD信号是一种用于指示数据传输方向的信号，原始的TELNET实现默认为半双工模式，即数据只能在一个方向上传输，需要特定的动作来结束一个方向上的传输，并允许另一个方向上的传输开始。当SUPPRESS GO AHEAD选项生效时，数据发送者不需要发送GO AHEAD信号，而可以直接进行双工模式的通信。SUPPRESS GO AHEAD选项可以由客户端或服务器端发起请求，并由对方回复确认。
2.一次一个字符方式：我们键入的每个字符都单独发送到服务器进程，服务器进程回显字符，除非服务器进程的应用程序去掉了回显功能。当网络速度很慢，且网络流量很大时，回显的速度也会很慢。目前大多Telnet实现把这种方式作为默认方式。如果要进入这种方式，只要激活服务器进程的SUPPRESS GO AHEAD选项即可，可通过客户进程发送DO SUPPRESS GO AHEAD给服务器进程或服务器进程发送WILL SUPPRESS GO AHEAD给客户进程来完成，服务器进程通常还会跟着发送WILL ECHO请求给客户进程，以使回显功能有效。
3.一次一行方式：这种方式通常叫做准行方式。方式2需要ECHO和SUPPRESS GO AHEAD选项同时有效，如果任一选项失效，就是方式3。
4.行方式：这种方式也称为实行方式，它也是通过客户进程和服务器进程进行协商而确定的，它纠正了准行方式的所有缺陷。比较新的Telnet实现支持这种方式。
Telnet以Data Mark（DM）命令作为同步信号，该同步信号是以TCP紧急数据形式发送的，它告诉接收端回到正常的处理过程上来，DM就是最后一个TCP紧急数据字节，Telnet的双方都能发送该命令。当一端收到对方已经进入了紧急方式的通知后，它开始读数据流，一边读一边丢弃读的数据，直到读到Telnet命令为止，采用TCP紧急方式的原因是，即使TCP数据流已经被TCP流量控制所终止，该命令也可以在连接上传输。
Telnet客户进程也可以使用户直接和客户进程进行交互，通常客户的转义字符是Control_]，这会使客户进程显示它的提示符，通常是telnet>，此时可输入命令与客户进程交互。
单字符方式下，用户在终端输入的每个字符都将发送到服务器进程，服务器进程的响应也将以字符方式回显到终端上。这种方式下与服务器连接时的选项协商过程：
对上图中协商选项的说明，以上图中标注序号顺序描述：
1.客户发起SUPPRESS GO AHEAD选项协商。此命令以DO开头，这是因为一般GO AHEAD命令是由服务器发送给客户的，而客户不希望自己激活GA选项，因此发送了这一选项使服务器激活此选项，激活服务器的此选项会禁止服务器发送GA激活请求。
2.客户进程按RFC 1091中的定义想发送自己的终端类型。
3.客户发送NAWS选项（Negotiate About Window Size，协商窗口大小）请求，如果服务器进程同意该选项，客户进程就要发送终端窗口的行、列大小的子选项，之后只要窗口大小发生变化，客户进程会向服务器进程发送这一子选项，实际上服务器在第11行拒绝了此请求。
4.TSPEED选项允许发送方（通常是客户端）发送它的终端速率，如果服务器进程同意，客户进程就发送它的发送速率和接收速率子选项，实际上服务器在第12行拒绝了此请求。
5.客户发送LFLOW（local flow control，本地流量控制）选项请求，表示客户进程希望可以用命令激活或禁止流量控制，如果服务器进程同意（实际上在第13行服务器拒绝了），使用Control_S和Control_Q时服务器会发送一个子选项来切换客户进程或服务器进程。它类似于Rlogin的0x10和0x20命令。由客户进程进行流量控制的效果比由服务器进行的效果要好。
6.客户发送LINEMODE（实行方式）选项请求，表示所有终端字符的处理由Telnet客户进程完成（如删除行等），然后发送整行给服务器。
7.客户发送ENVIRON选项请求，表示客户想把环境变量发送给服务器进程。默认，BSD/386 Telnet客户进程发送两个环境变量值DISPLAY和PRINTER，前提是这两个变量已经定义且有效，Telnet用户可定义其他要发送的环境变量。
8.客户发送请求令服务器激活STATUS选项，此选项允许一方询问对方Telnet的一些状态，上例中，客户进程要求对方激活此选项，如果服务器进程同意，客户进程就可以要求服务器进程以子选项形式发送它的状态值。
9.服务器进程同意激活终端类型选项，但此时客户进程还不能立即发送它的终端类型，它要等到服务器进程用子选项的形式询问终端类型时才发送。
10.服务器同意抑制发送GA命令。
11.服务器不同意客户发送它的窗口大小。
12.服务器不同意客户发送它的终端速率。
13.服务器不同意客户实施流量控制。
14.服务器不同意客户激活行方式选项。
15.服务器不同意客户发送环境变量。
16.服务器不发送状态信息。
17.服务器询问客户进程的终端类型的子选项。
18.客户把终端类型发送给服务器。
19.服务器询问客户是否让服务器执行回显。这是服务器进程首次发出一个选项协商。
20.客户同意服务器的回显功能。
21.服务器要求客户实现回显功能，这是目前大多Unix的Telnet服务器进程判断客户进程运行的是4.2 BSD还是更新的版本的一个不一定准确的方法，如果客户回送WILL ECHO，就表明客户运行的是比较老的4.2 BSD版本，此版本的TCP紧急方式的实现是不对的，就不会再使用TCP紧急方式。
22.客户进程回送WONT ECHO，表示客户运行的不是4.2 BSD，而是更新的版本。
23.对于客户回送的WONT ECHO，服务器以DONT ECHO作为响应。
以下是以上过程的时间序列（去掉了连接建立部分）：
第一个报文段包含了标注1~8的内容，该报文段中包含24个字节，每个选项占3字节，这是客户进程发起的协商。这说明多个Telnet选项可以在一个TCP段中发送。
报文段3是标注9的内容，即DO TERMINAL TYPE命令。
报文段5中是标注10~17的内容，长27字节，其中10~16是常规选项，每个占3字节，17是子选项，占6个字节。
报文段6中包含12字节，对应标注18，是客户发送它的终端类型子选项。
报文段8中包含53字节，其中含两个Telnet命令和47字节的输出数据，两个命令是服务器的WILL ECHO和DO ECHO，输出数据为：
输出数据的前4字节产生两个空行（\r\n在Telnet中表示换行命令）。\r\0表示回车。报文段8表明数据和命令可以在一个数据段中传输，Telnet服务器进程和客户进程必须扫描接收到的每个字符，寻找IAC字节并执行它的后续命令。
报文段9包含客户发送的标注20和22两个选项SENT DO ECHO和SENT WONT ECHO。
报文段10中含标注23表示的客户接收到的选项DONT ECHO。之后双方就可以交互数据了，交互过程中还可进行选项协商。报文段12是服务器发送的提示符login:。报文段14是用户输入的登陆用户名的第一个字符，它的回显是在报文段15中。
上例中，客户端发起选项协商，而在18章中，telnet命令的tcpdump并没有看到客户发起选项协商，这是由于在Unix系统中，除非使用标准的Telnet端口号23，否则客户进程不进行选项协商，这一特性使得Telnet客户进程可以使用标准的NVT同其他一些非Telnet服务器进程交换数据。
为描述Telnet行方式选项协商过程，使用主机BSD/386和4.4 BSD，它们都支持这个选项，以下是此次行方式选项协商与上例单字符方式的区别：
1.对于BSD/386希望协商的选项，如窗口大小、本地流量控制、状态、环境变量、终端速率等，4.4 BSD服务器都支持。
2.4.4 BSD将协商一个BSD/386客户不支持的新选项：authentication（为避免以明文形式在网络上传输用户口令）。
3.客户进程发送WILL LINEMODE，由于服务器进程支持该选项，所以服务器进程发送DO LINEMODE，此时客户进程以子选项方式给服务器发送16个特定字符，这些字符是客户进程的特殊字符的当前值，如中断字符、文件结束符等。
服务器进程给客户进程发送一个子选项，让客户进程处理所有输入、执行所有编辑功能（删除字符、删除行等），客户只会把完成编辑的行发送到服务器。服务器进程要求客户进程把所有中断键和信号键转换为相应的Telnet字符，如客户按中断键Control_C，客户必须把其转换为Telnet的命令<IAC, IP>传输给服务器进程。
4.用户输入口令时，在Rlogin和单字符方式的Telnet中，都是由服务器进程负责回显，所以服务器读到口令时，它并不回显这些字符，但在行方式中由客户进程负责回显，以下交互过程处理这种情况：
（1）服务器进程发送WILL ECHO，告诉客户服务器将处理回显。
（2）客户回送DO ECHO。
（3）服务器向客户发送字符串password:，客户进程将该串发送到终端上。
（4）用户输入口令，按RETURN键（回车键）时，客户进程把口令发送给服务器，此时口令不回显，因为此时由服务器控制回显。
（5）由于口令的结束符RETURN没有回显，服务器发送两字节序列CR、LF给客户以移动光标。
（6）服务器发送WONT ECHO。
（7）客户回送DONT ECHO，然后继续由客户负责回显。
一旦登录完成，客户进程将把数据以整行方式发送给服务器，这种行方式大大减少了客户和服务器之间的数据交互量，且对于用户的击键（回显和编辑）提供更快的响应。
在行方式下，我们输入以下命令：
以下是该命令发送的分组的时间序列：
可见在Telnet行方式下只需要2个报文段（一个包含命令，另一个用于ACK，连同IP和TCP首部共86字节），而在Rlogin中要发送15个报文段（5个有键入的数据，5个有回显的数据，5个ACK，共611字节），节省的数据量很可观。
如果在服务器端运行一个需要进入单个字符方式的应用（如vi编辑器），会发生如下交互：
1.当服务器的应用程序启动了，并改变其伪终端方式时，Telnet服务器进程被通告需要进入单个字符方式，然后服务器发送WILL ECHO命令和行方式子选项，以告知客户要进入单个字符方式。
2.客户响应DO ECHO，并确认行方式子选项。
3.客户键入的每个字符将发送到服务器（使用Nagle算法），服务器将处理必要的回显工作。
4.服务器的应用终止时，会恢复其伪终端方式，并通告Telnet服务器进程，服务器会向客户发送WONT ECHO命令，同时发送行方式子选项，以告知客户进入行方式。
5.客户响应DONT ECHO，确认进入行方式。
以上过程和键入口令的过程说明：客户直接回显与单个字符方式或一次一行方式没有依赖关系。当我们在Telnet行方式下键入口令时，客户直接回显必须关闭，但一次一行方式仍然会开启；在Telnet行方式下，对于一个编辑器，客户直接回显失效且单个字符方式有效。
如果客户不支持行方式，而服务器支持行方式，则可使用准行方式，以下是客户与服务器协商进入准行方式的过程：
1.当客户不同意服务器的行方式请求时，服务器会发送DO TIMING MARK选项，这个选项的原作用是让收发双方同步（即希望对端发送WILL TIMING MARK选项，对端这么发送就说明之前的数据已经处理完毕），但此处的该选项只是用来判断客户是否支持准行方式。
2.客户响应WILL TIMING MARK表示其支持准行方式。原因是，在准行方式下，WILL TIMEING MARK表示客户端已经处理完了之前发送的所有数据，且准备好接收新的数据，这样服务器就可以知道客户端的缓冲区状态，从而实现行模式的效果。如服务器要发送一个命令提示符给客户端时，它会先发送IAC DO TIMING-MARK来请求一个时序标记，当客户端回复WILL TIMING-MARK时，服务器就知道客户端已经显示完了之前的输出，且空闲了，然后服务器就发送命令提示符给客户端，并等待客户端输入一行数据。
3.服务器发送WONT SUPPRESS GO AHEAD和WONT ECHO选项，由于单个字符方式下是假定SUPPRESS GO AHEAD和ECHO同时有效的，禁止这两个选项之一就进入了准行方式。
4.客户响应DONT SUPPRESS GO AHEAD和DONT ECHO命令。
5.服务器发送登录提示符，然后用户键入用户名，用户名是以整行方式发送给服务器的，回显由客户进程在本地处理。
6.服务器发送密码提示符和WILL ECHO命令，这将使客户的回显失效，客户响应DO ECHO命令，因此客户键入的口令就不回显到屏幕上。
7.客户键入口令，口令以整行方式发送到服务器。
8.服务器发送WONT ECHO命令，客户响应DONT ECHO，使得客户重新激活回显功能。
以上过程后，普通命令处理过程就和行方式类似了，即客户处理所有的编辑和回显，并以整行的方式发送给服务器。
以下是进入准行方式客户端的过程：
经过以上过程，SUPPRESS GO AHEAD和ECHO选项都是失效的，Telnet会话就进入了准行方式。
准行方式下，如果在服务器运行如vi这样一次一字符的应用，服务器必须告诉客户从准行方式切换到单字符方式，当应用结束时，服务器还要告诉客户返回准行方式，以下是协商要点：
1.当应用改变其伪终端方式并通知服务器进程时，服务器进程将进入单字符方式，服务器进程向客户进程发送WILL SUPPRESS GO AHEAD和WILL ECHO，这会使客户进程进入单字符方式。
2.客户回送DO SUPPRESS GO AHEAD和WILLL ECHO。
3.应用开始在服务器端运行。
4.应用结束并改变其伪终端方式，服务器进程发送WONT SUPPRESS GO AHEAD和WONT ECHO命令，使客户返回准行方式。
5.客户回送DONT SUPPRESS GO AHEAD和DONT ECHO命令，告诉服务器它已经回到了准行方式。
在行方式下，当用户键入中断键时的时间序列：
报文段1中包含的是中断键（Control_C或DELETE）转换而成的Telnet的IP命令（中断命令）<IAC,IP>，之后的3个字节<IAC,DO,TM>组成了Telnet的DO TIMING MARK选项，这个标志由客户发送，服务器必须使用WILL或WONT响应，所有在服务器响应前收到的数据都要丢弃（除了Telnet的命令），这是服务器和客户的同步过程，报文段1没有采用TCP紧急方式，Host Requirements RFC叙述了IP命令不能使用Telnet的同步信号（即DM命令，作为TCP紧急数据发送）来发送，如果可以，那么<IAC, IP>的后面将跟随<IAC, DM>，同时紧急指针指向DM字节。大多Unix Telnet客户有一个选项来使用同步信号发送IP命令，但这个选项默认是关闭的。
报文段2是服务器对DO TIMING MARK选项的响应。
报文段3、4是Telnet的同步信号<IAC, DM>，报文段3中的紧急指针指向将在报文段4中发送的DM字节。如果客户的缓冲区已满，那么客户发送了报文段1中的IP命令后就丢弃收到的所有数据。即使服务器被TCP的流量控制所终止而不能发送报文段2、3、4中的数据，紧急指针仍可发送。
Rlogin和Telnet服务器都设置了TCP的保活选项以检测客户主机是否崩溃。
Rlogin和Telnet都采用了TCP紧急方式，以便从服务器到客户的数据传输被流量控制终止时，服务器仍然可以向客户发送命令。
Rlogin客户进程必须使用保留端口号，通常使用的是512~1023之间的保留端口，这限制了一个主机只能有512个远程登录的客户，实际上，这个限制一般小于512，因为这个范围内的一些端口被其他服务器用作了知名端口。Rlogin客户不支持端口重用，如果它支持，对于一个TCP连接，TCP的限制是4元组必须唯一，由于Rlogin服务器总是使用了知名端口513，因此一台单接口主机上多个Rlogin客户只有在它们和不同的服务器主机（假设此主机上只有一个接口）相连接时才可以使用相同的保留端口，且最多有512个Rlogin本地客户可以和同一个服务器主机相连。
