26.4.5 半雙工、一次一字元、一次一行或行方式

    對於大多數Te l n e t的伺服器程序和客戶程序，共有4種操作方式。

    1. 半雙工

----------------------- Page 13-----------------------

    這是Te l n e t的預設方式，但現在卻很少使用。N V T預設是一個半雙工裝置，在接收使用者輸

入之前，它必須從伺服器程序獲得GO AHEAD                （G A）命令。使用者的輸入在本地回顯，方向是

從N V T鍵盤到N V T印表機，所以客戶程序到伺服器程序只能傳送整行的資料。

    雖然該方式適用於所有型別的終端裝置，但是它不能充分發揮目前大量使用的支援全雙

工通訊的終端功能。RFC 857 [Postel       和Reynolds 1983c] 定義了E C H O選項，RFC 858 [Postel

和Reynolds 1983d]定義了SUPPRESS GO AHEAD      （抑制繼續進行）選項。如果聯合使用這兩

個選項，就可以支援下面將討論的方式：帶遠端回顯的一次一個字元的方式。

    2. 一次一個字元方式

    這和前面的R l o g i n工作方式類似。我們所鍵入的每個字元都單獨傳送到伺服器程序。服務

器程序回顯大多數的字元，除非伺服器程序端的應用程式去掉了回顯功能。

    該方式的缺點也是顯而易見的。當網路速度很慢，而且網路流量比較大的時候，那麼回

顯的速度也會很慢。雖然如此，但目前大多數Te l n e t實現都把這種方式作為預設方式。

    我們將看到，如果要進入這種方式，只要啟用伺服器程序的 SUPPRESS GO AHEAD選項

即可。這可以通過由客戶程序傳送DO SUPPRESS GO AHEAD                 （請求啟用伺服器程序的選項）

請求完成，也可以通過伺服器程序給客戶程序傳送 WILL SUPPRESS GO AHEAD                       （伺服器進

程啟用選項）請求來完成。伺服器程序通常還會跟著傳送 WILL ECHO ，以使回顯功能有效。

    3. 一次一行方式

    該方式通常叫做準行方式（kludge line mode ），該方式的實現是遵照RFC 858 的。該R F C

規定：如果要實現帶遠端回顯的一次一個字元方式， E C H O選項和SUPPRESS GO AHEAD選

項必須同時有效。準行方式採用這種方式來表示當兩個選項的其中之一無效時， Te l n e t就是工

作在一次一行方式。在下節中我們將介紹一個例子，可以看到如何協商進入該方式，並且當

程式需要接收每個擊鍵時如何使該方式失效。

    4. 行方式

    我們用這個術語代表實行方式選項，這是在RFC 1184[Borman 1990] 中定義的。這個選項

也是通過客戶程序和伺服器程序進行協商而確定的，它糾正了準行方式的所有缺陷。目前比

較新的Te l n e t實現支援這種方式。

    圖2 6 - 11是不同的Te l n e t客戶程序和伺服器程序之間預設的操作方式。“c h a r ”表示一次一

個字元方式，“k l u d g e ”表示準行方式，“l i n e m o d e ”表示如RFC 11 8 4定義的實行方式。

               圖26-11 不同的Telnet客戶程序和伺服器程序之間預設的操作方式

    從圖中可以看出，只有當客戶程序和伺服器程序都是 B S D / 3 8 6或4 . 4 B S D 的時候才支援實

行方式。當伺服器程序的作業系統是這兩者之一時，如果客戶程序不支援實行方式，才會協

商進入準行方式。從圖中還可以看出，其實任何型別的客戶程序和伺服器程序都支援準行方

式，但是一般都不把它作為預設方式，除非伺服器程序指定。

----------------------- Page 14-----------------------

26.4.6 同步訊號

    Te l n e t 以Data Mark命令（即圖2 6 - 8 中的D M ）作為同步訊號，該同步訊號是以T C P緊急數

據形式傳送的。D M命令是隨資料流傳輸的同步標誌，它告訴收端回到正常的處理過程上來。

Te l n e t的雙方都可以傳送該命令。

    當一端收到對方已經進入了緊急方式的通知後，它將開始讀資料流，一邊讀一邊丟棄所讀

的資料，直到讀到Te l n e t命令為止。緊急資料的最後一個位元組就是D M位元組。採用T C P緊急方式

的原因就是：即使T C P資料流已經被T C P流量控制所終止，Te l n e t命令也可以在連線上傳輸。

    在下節中我們將看到Te l n e t同步訊號的使用情況。

26.4.7 客戶的轉義符

    和R l o g i n 的客戶程序一樣，Te l n e t客戶程序也可以使使用者直接和客戶程序進行互動，而不

是被髮送到伺服器程序。通常客戶的轉義字元是 C o n t r o l _ ]          （c o n t r o l鍵和右中括號鍵，通常以

“^ ] ”表示）。這使得客戶程序顯示它的提示符，通常是“t e l n e t >”。這時候有很多命令可供

使用者選擇，以改變連線的特性或列印某些資訊。大多數的 U n i x客戶程序提供“h e l p ”命令，

該命令將顯示所有可用的命令。

    在下節中我們將看到客戶程序轉義的例子，以及此時可以輸入的命令。

26.5  Telnet舉例

    在這裡我們將介紹在三種不同的操作方式下 Te l n e t選項協商的情況。這些方式包括：單字

符方式、實行方式和準行方式。同樣我們還將討論當用戶在伺服器端按了中斷鍵退出了一個

正在執行的程序後，系統的執行情況。

26.5.1 單字元方式

    首先介紹基本的單字元方式，該方式類似於R l o g i n 。使用者在終端輸入的每個字元都將由終

端傳送到伺服器程序，伺服器程序的響應也將以字元方式回顯到終端上。在這裡執行的是一

個新的客戶程序B S D / 3 8 6 ，它試圖啟用很多新的選項，伺服器程序還是執行老的 S V R 4，我們

將看到很多選項被伺服器拒絕。

    為了看到伺服器和客戶機之間選項協商的內容，我們將啟用客戶程序的一個選項來顯示

所有的選項協商。同樣我們執行t c p d u m p來獲得資料報交換的時間次序。圖2 6 - 1 2顯示了這個

互動會話。

    在圖中，我們已經對由 S E N T或R C V D開頭的選項協商的每一步都進行了標註。關於每一

步的解釋如下：

    1) 客戶發起SUPPRESS GO AHEAD選項協商。由於GO AHEAD命令通常是由伺服器傳送

給客戶的，而且客戶希望伺服器啟用該選項，因此該選項的請求方式是 D O                            （由於啟用這一選

項將會禁止G A命令的傳送，上述過程很容易讓人混淆）。在第1 0行可以看到伺服器程序同意

該選項。

    2)  客戶程序要按照在RFC 1091[VanBokkelen 1989] 中的定義傳送終端型別。這對U n i x型別的

客戶程序來講是很普通的。因為客戶程序要啟用本地的選項，所以該選項的請求方式是W I L L。

----------------------- Page 15-----------------------

                       圖26-12 Telnet雙方選項協商的初始化過程

    3) NAW S 的意思是“協商視窗大小”，它在RFC 1073 [Wa i t z m a n ] 中有定義。如果伺服器

程序同意該選項（實際上不同意，見 11行），客戶程序就要傳送終端視窗的行、列大小的子選

項。而且只要視窗大小發生變化，客戶程序隨時都將向伺服器程序傳送這一子選項（這和圖

2 6 - 4 中R l o g i n的0 x 8 0命令類似）。

    4) TSPEED 選項允許傳送方（通常是客戶程序）傳送它的終端速率，這在                           RFC 1079

[Hedrick 1988b] 中有定義。如果伺服器程序同意（實際上不同意，見 1 2行），客戶程序將傳送

其傳送速率和接收速率的子選項。

    5) LFLOW代表“本地流量控制”，這在RFC1371 [Hedrick  和Borman 1992] 中定義。客戶

程序給伺服器程序傳送該選項，表示客戶程序希望用命令方式啟用或禁止流量控制。如果服

務器程序同意（實際上不同意，見 1 3行），只要C o n t r o l _ S和C o n t r o l _ Q程序需要在客戶程序和

伺服器程序進行切換，客戶程序都要向伺服器程序傳送子選項（這類似於圖  2 6 - 4 中R l o g i n 的

0 x 1 0和0 x 2 0命令）。正如在關於R l o g i n 的討論中我們所提到的那樣，由客戶程序進行流量控制

的效果比由伺服器程序來完成要好。

    6) LINEMODE代表在2 6 . 4 中所說的實行方式。所有終端字元的處理由Te l n e t客戶程序完成

（例如回格，刪除行等），然後整行傳送給伺服器程序。在本節後面，我們將介紹一個例子。

該選項同樣被伺服器程序拒絕，如 1 4行所示。

    7) ENVIRON選項允許客戶程序把環境變數傳送給伺服器程序，這在 RFC 1408 [Borman

----------------------- Page 16-----------------------

1 9 9 3 a ]中有定義。這樣就可以把客戶程序的使用者環境變數自動傳播到伺服器程序。在 1 5行，

伺服器程序拒絕該選項（U n i x 中的環境變數通常是大寫字母，緊跟一個等號，然後是一個字

符串值，當然這只是一個慣例而已）。預設情況下，BSD/386 Te l n e t客戶程序傳送兩個環境變

量：D I S P L AY和P R I N T E R ，前提是這兩個變數已經定義並且有效。 Te l n e t使用者可以定義其他

一些要傳送的環境變數。

    8) STAT U S選項（RFC 859 [Postel 和Reynolds 1983e] 中定義）允許連線的一方詢問對方

對Te l n e t選專案前狀態的理解。在這個例子中，客戶程序要求對方啟用選項（ D O ）。如果服務

器程序同意（實際上不同意，見 1 6行），客戶程序就可以要求伺服器程序以子選項的形式傳送

它的狀態值。

    9)  這是伺服器程序的第一個響應。伺服器程序同意啟用終端型別選項（幾乎所有的 U n i x

型別的伺服器程序都支援該選項）。但現在客戶程序還不能立即傳送它的終端型別。它必須要

等到伺服器程序用子選項的形式詢問終端型別的時候才能夠傳送（ 1 7行）。

    10) 伺服器程序同意抑制傳送GO AHEAD命令。

    11) 伺服器程序不同意客戶程序傳送它的視窗大小。

    12) 伺服器程序不同意客戶程序傳送它的終端速率。

    13) 伺服器程序不同意客戶程序實施流量控制。

    14) 伺服器程序不同意客戶程序啟用行方式選項。

    15) 伺服器程序不同意客戶程序傳送環境變數。

    16) 伺服器程序不傳送狀態資訊。

    17) 這是伺服器程序要求客戶程序傳送終端型別的子選項。

    18) 客戶程序把終端型別“I B M P C 3 ”以6位元組的字串形式傳送給伺服器程序。

    19)  伺服器程序要求客戶程序發起請求，要求伺服器程序啟用回顯選項。這是本例中服務

器程序第一次主動發起選項協商。

    20) 客戶程序同意由伺服器程序實現回顯功能。

    21)  伺服器程序要求客戶程序實現回顯功能。這個命令是多餘的，它只是將前兩行進行了

交換。這是目前大多數U n i x 的Te l n e t伺服器程序判斷客戶程序是否執行 4 . 2 B S D或更新的B S D

版本時的一個方法。如果客戶程序回送 WILL ECHO ，就表明客戶程序執行的是老版本的

4 . 2 B S D ，不支援T C P的緊急方式（在這種情況下就不能採用T C P緊急方式）。

    22)  客戶程序回送WONT ECHO ，表示它不是一臺4 . 2 B S D主機。

    23) 對於客戶程序回送的WONT ECHO ，伺服器程序以DONT ECHO作為響應。

    圖2 6 - 1 3顯示的是本例中伺服器程序和客戶程序互動的時間系列（去掉了連線建立部分）。

    報文段1包含了圖2 6 - 1 2 中的1 ~ 8行。該報文段中包含2 4個位元組資料，每個選項佔3個位元組。

這是客戶程序發起的選項協商。該報文段顯示多個 Te l n e t選項可以打在一個T C P段中傳送。

    報文段3是圖2 6 - 1 2 中的第9行，即DO TERMINAL TYPE命令。報文段5包含下面的8個選

項協商中伺服器程序的響應，即圖 2 6 - 1 2 中的1 0 ~ 1 7行。該報文段的長度是 2 7個位元組，因為

1 0 ~ 1 6行是常規選項，每個佔3個位元組，而1 7行的子選項部分佔6個位元組。報文段6包含1 2個字

節，和1 8行對應，這是客戶傳送它的終端型別的子選項。

    報文段8   （5 3個位元組）包含兩個Te l n e t命令和4 7位元組的輸出資料。前面的兩個伺服器程序

傳送Te l n e t命令佔6位元組，：WILL ECHO和DO ECHO       （1 9和2 1行）。後4 7個位元組的資料是：

----------------------- Page 17-----------------------

    \r\n\r\nUNIX(r) System V Release 4.0 (svr4) \r\n\r\0\r\n\r\0

    前面4個位元組資料在字串輸出之前產生兩個空行。兩位元組的字元序列“ \ r \ n ”在Te l n e t中

被認為是換行命令，而兩位元組的字元序列“ \ r \ 0 ”則被認為是回車命令。這表明資料和命令可

以在一個數據段中傳輸。Te l n e t伺服器程序和客戶程序必須掃描接收到的每個字元，尋找 I A C

位元組並執行它後續的命令。

                圖26-13 Telnet伺服器程序和客戶程序選項協商初始化過程

    報文段9包含客戶程序傳送的最後兩個選項： 2 0和2 2行。2 3行是報文段1 0的響應，也是服

務器程序傳送的最後一個選項資料。

    從現在開始，雙方就可以互動資料了。當然在互動資料的過程中還可以進行選項協商，

我們在該例子中就不多介紹了。報文段 1 2是伺服器程序傳送的提示符“ l o g i n : ”。報文段1 4是

使用者輸入的登入使用者名稱的第一個字元，它的回顯在報文段 1 5中。這和我們在1 9 . 2節中介紹的

R l o g i n互動類似：客戶程序每次傳送一個字元，伺服器程序完成回顯工作。

       圖2 6 - 1 2 中的選項協商由客戶程序初始化的，但是在本書中我們已經介紹了用

    Te l n e t客戶程序連線某些標準伺服器程序如：日間（d a y t i m e）伺服器、回顯( e c h o )服務

    器等情況。當然我們介紹這些的目的是為了描述 T C P的各種特性。但考察這些例子中

----------------------- Page 18-----------------------

    的分組交換，如圖1 8 - 1，我們並沒有看到客戶程序發起的選項協商。為什麼？這是因

    為在U n i x系統中，除非使用標準的Te l n e t埠號2 3，否則客戶程序不進行選項協商。這

    個特性使得Te l n e t客戶程序可以使用標準的N V T 同其他一些非Te l n e t伺服器程序交換數

    據。我們已經在日間伺服器、回顯伺服器和丟棄( d i s c a r d )伺服器中使用了這個特性，在

    後面章節介紹FTP和SMTP伺服器的時候我們還將使用該特性。

26.5.2 行方式

    為了描述Te l n e t 的行方式選項協商過程，我們在主機 b s d i執行客戶程序，伺服器是位於

v a n g o g h . v s . b e r k e l e y . e d u節點執行4 . 4 B S D作業系統的一臺主機。B S D / 3 8 6和4 . 4 B S D都

支援這個選項。

    我們不詳細討論所有的報文、選項和子選項協商過程，因為這個過程和前面的例子類似，

而且對於行方式選項我們已經論述得比較清楚。下面我們僅僅討論在選項協商中的一些區別。

    1) 對於B S D / 3 8 6希望協商的選項例如：視窗大小、本地流量控制、狀態、環境變數和終

      端速率等，4 . 4 B S D伺服器程序都支援。

    2) 4 . 4 B S D伺服器程序將協商一個B S D / 3 8 6客戶程序不支援的新選項：鑑別（為避免以明

      文形式在網路上傳輸使用者口令）。

    3) 和上個例子一樣，客戶程序傳送WILL LINEMODE選項，由於伺服器程序支援該選項，

      所以伺服器程序傳送DO LINEMODE。此時客戶程序以子選項形式給伺服器程序傳送1 6個

      特定字元。這些字元是能影響客戶程序的特定終端字元值：如中斷字元，檔案結束符等。

      伺服器程序給客戶程序傳送一個子選項，讓客戶程序處理所有的輸入，執行所有的編

      輯功能（刪除字元，刪除行等）。客戶程序把除控制字元以外的字元以行的形式傳送給

      伺服器程序。伺服器程序還要求客戶程序把所有中斷鍵和訊號鍵轉換為相應的 Te l n e t字

      符。例如中斷鍵是C o n t r o l _ C，我們可以按C o n t r o l _ C來中斷伺服器端的某個程序。客戶

      程序必須把C o n t r o l _ C轉換為Te l n e t的I P命令（<IAC, IP> ）傳輸給伺服器程序。

    4)  當用戶輸入口令時情況也有所不同。在R l o g i n和一次一字元方式的Te l n e t中，都是由服

      務器程序負責回顯，所以當伺服器程序讀到口令時，它並不回顯這些字元。但在行方

      式中由客戶程序負責回顯。下面這些互動過程將處理這種情況：

      (a) 伺服器程序傳送WILL ECHO ，以告訴客戶程序：伺服器程序將處理回顯。

      (b) 客戶程序回送DO ECHO 。

      (c) 伺服器程序向客戶程序傳送字串 P a s s w o r d:，客戶程序把它傳送到終端上。

      (d) 然後使用者輸入口令，當用戶按下R E T U R N鍵的時候，客戶程序把口令傳送給伺服器

         程序。此時口令不回顯，因為客戶程序認為伺服器程序將回顯它。

      (e)  由於口令的結束符R E T U R N沒有回顯，伺服器程序傳送兩位元組字元序列 C R和L F 以

        移動游標。

      (f) 伺服器程序傳送WONT ECHO 。

      (g)  客戶程序回送DONT ECHO 。然後繼續由客戶程序負責回顯。

    一旦登入完成，客戶程序將把資料以整行的方式傳送給伺服器程序。這就是行方式選項

的目的。行方式大大地減少了客戶程序和伺服器程序之間的資料互動數量，而且對於使用者的

----------------------- Page 19-----------------------

擊鍵（也就是回顯和編輯）提供更快的響應。圖 2 6 - 1 4顯示的是當我們輸入命令時，在行方式

連線下分組交換的情況。

    Vangogh %d a t e

    （去掉了業務種類資訊和視窗通告資訊）。

                圖26-14 Telnet行方式下客戶程序向伺服器程序傳送命令的情況

    把它和在R l o g i n 中輸入同樣命令（圖1 9 - 2）時的情況進行一下比較。我們看到在 Te l n e t行

方式下只需要2個報文段（一個包含資料，另一個用於 A C K ，連同I P和T C P首部共8 6位元組），

而在R l o g i n 中要傳送1 5個報文段（5個有鍵入的資料，5個有回顯的資料，5個是A C K ，共6 11

位元組）。可見節省的資料量是非常可觀的。

    如果在伺服器端執行一個需要進入單個字元方式的應用程式（例如  v i編輯器）會怎麼樣

呢？實際上將發生如下的一些互動：

    1)  當伺服器的應用程式啟動了，並改變其偽終端方式時， Te l n e t伺服器程序被通告需要進

入單個字元方式。然後伺服器傳送WILL ECHO命令和行方式子選項，以告知客戶不要再以行

方式工作，轉而進入單個字元方式。

    2) 客戶響應以DO ECHO ，並確認行方式子選項。

    3)  應用程式在伺服器上執行。我們鍵入的每個字元將傳送到伺服器（當然要強制使用

N a g l e演算法），此時伺服器將處理必要的回顯工作。

    4) 當應用程式終止時，就恢復其偽終端方式，並通告Te l n e t伺服器。伺服器將向客戶傳送

WONT ECHO命令，同時傳送行方式子選項，告訴客戶恢復進入行方式。

    5) 客戶響應DONT ECHO ，確認進入行方式。

    上述情況同我們鍵入口令之間的區別表明：回顯功能和單個字元方式與一次一行方式沒

有依賴關係。當我們鍵入口令時，回顯功能必須失效，但一次一行方式有效。對於一個全屏

應用來講，例如編輯器，回顯必須失效而單個字元方式必須有效。

    圖2 6 - 1 5概括了R l o g i n和Te l n e t不同方式之間的差異。

                                     圖26-15   Rlogin和不同方式的Telnet之間的比較