Internet协议的分析方法

张靖笙旧作

  摘要:本文介绍了Internet的标准协议和分析方法。介绍Internet协议文件RFC,并作为举例分析了FTP协议

  关键字:RFC Internet协议

   前言

     近年来,Internet正以令人眩目的速度增长，这个增长包括Internet这个网络规模和与之相关的技术，规模的增长带来Internet技术的广泛普及，使其中的如IP,TCP,HTTP,FTP,TELNET,HTML,NNTP等等毫无争议地成为事实的标准，同时又给以上技术提出新的要求和为其发展带来了直接的动力；技术的不断提高又克服了一个又一个网络相联出现的难题和障碍,技术和应用的相互促进，使人类文明能在事实上的迈入类信息社会。

    随着Internet的不断扩大，发展的无序化日益严重，Internet的标准化无疑对保证Internet及相关技术健康发展起了决定性作用。

    在这里作者对Internet标准组织，Internet标准化过程，Internet标准文件等做个简单的介绍，希望能提供给读者一个直接快速地深入了解Internet的方法，同时鼓吹一种深入核心技术和融入世界规范的思想。

 1 描述Internet协议的官方文件 RFC(Request For Comment)

    1.1 什么是RFC

     在Internet的开发和研究中，产生了一系列技术协议(protocol)，而其中一些被Internet的标准化机构采用，解析这些协议的文件被称为RFC(request forcomments),中文意思是请求评注。由于RFC包含了一系列文件，所以下文用RFCs表示这一系列的文件。这些文件是关于Internet标准的最权威的定义，是INTERNET OFFICIAL PROTOCOL STANDARDS,参见RFC-2400。

    RFCs原本是Internet研究和开发社团--"网络工作组"(Network Working Group)的工作笔记，一篇文件可能是关于计算机通讯技术的一些话题的论文，也可能是关于确定一个标准的会议的报告。虽然所有标准以RFC的形式公布，但并不是说，所有的RFC文件所描述的协议都是已经确定的Internet标准。下文会讨论到协议的不同分类。

     由于许多RFC文件本身就是技术文档，所以它们的技术参考价值非常高，而且由于用语规范，可读性也非常强。

    RFCs是按编写的时间顺序编号的，当一篇文件成为RFC后，被分配一个RFC编号后，这个编号不会被其他文件使用,即使文件修改和重新发表也不会使用同一个RFC编号,所以当一个Internet协议(如FTP)被改进后，可能因而产生RFCs中的许多不同版本的文件，所以当您研究一个协议时，注意它在RFCs中的最新版本。

    1.2 RFCs是如何产生的

     RFCs文档由Internet中的标准化机构-因特网活动委员会IAB(InternetActivities Board) 负责编辑管理和发表。这里不对IAB做详细介绍，有兴趣请参阅RFC-1160 "TheInternet Activities  Board"和RFC-1601 "Charter of theInternet Architecture Board (IAB)"。 IAB下属有因特网工程特别任务组IETF(Internet Engineering Task Force)和因特网研究特别任务组IRTF(Internet ResearchTask Force),这两个任务组各有一个领导组被称做IESG (Internet EngineeringSteering Group)和IRSG(Internet Research SteeringGroup)。大部分的Internet协议的开发和标准化活动在IETF的工作组中进行。

     一篇RFC的发表必须得到IESG的同意，对于一些记录实验工作的文章，编辑者在发表前通知了IESG,由相关的IETF工作组或IRTF研究组检讨并向作者提供评价意见。

 2 协议的分类(categorization)

     这里有两个Internet协议的分类依据,其中一个根据是协议的成熟程度(maturity level)或在标准化程序中的阶段(STATE ofstandardization),分为标准(standard),草案标准(draft standard),被提议的标准(proposed standard),实验(experimental),情报(informational),历史(historic)。另外一个根据协议的需求程度(requirement level)或协议的地位(STATUS)，分为必需(required),推荐(recommended),可选(elective)，限制使用(limited use)，不推荐(not recommanded)。

     在所有情况中，一个协议处于以下组合中的一种情况，表格中的X个数表示一种组合的可能性大小。一个新的协议一般从提议标准,可选(proposedstandard,elective)或实验,限制使用(experimental,  limited use)开始。

2.1协议STATE的定义

    1)标准协议(StandardProtocol)

     IESG同意这些协议作为Internet中正式标准协议，具体包括两组(1)IP协议和通用于整个Internet的其他协议。(2)特定网络协议(network-specific protocol),一般是如何在特定网络实现IP的说明书。

    2)草案标准协议(DraftStandard Protocol)

     IESG正积极地考虑把这些协议提升为标准协议(Standard Protocol)。这些协议还需要严格和广泛的测试和评价,评价和测试结果会被提交给IESG，协议在成为标准协议时可能需要修改。

    3)被提议标准化的协议(ProposedStandard Protocol)

      这是一些被IESG考虑纳入标准化程序的协议。

    4)实验协议(ExperimentalProtocol)

     一般地，实验协议指那些作为一个研究中项目的一部分，除了一些与该研究有关的场合，一般不提倡使用，如果后来它们被提议标准化,才进入标准化程序。

    5)情报性协议(InformationalProtocol)

     这是一些由其他标准化组织或厂商制定，或由于某种原因协议的内容超出IESG权限(purview),以RFC的形式发表只是为了Internet团体的检索方便。

    6)历史协议(HistoricProtocol)

     这是一些因为被新技术淘汰或缺乏兴趣发展而不能成为标准的协议，保留在RFC中只是作为历史的见证。

2.2  协议Status的定义

   1)必需协议(RequiredProtocol)

     一个Internet上的系统(主机或网关)必需实现的协议。

   2)推荐协议(RecommendedProtocol)

     一个Internet上的系统最好能实现推荐协议

   3)可选协议(ElectiveProtocol)

     一个Internet上的系统可以实现也可以不实现可选协议，取决于你自己是否愿意实现。这里可能有几个可选协议在同一个普通领域，如几个电子邮件协议和几个路由协议。

   4)限制使用协议(LimitedUse Protocol)

     这些协议只在一些限定的环境内应用，可能由于他们属于实验阶段，或只适用在特殊的自然环境下，或因为其功能有限，或已经被淘汰，如历史协议。

   5)不推荐使用协议(NotRecommanded Protocol)

     这些协议不被推荐使用。

 3 协议的标准化过程

         |

        +<----------------------------------------------+

         V   0                                         |    4

   +-----------+                                  +===========+

   |  enter  |-->----------------+-------------->|experiment |

   +-----------+                   |               +=====+=====+

                                   V    1                |

                             +-----------+               V

                             | proposed  |-------------->+

                       +--->+-----+-----+              |

                        |          V   2                |

                       +<---+-----+-----+              V

                             | draft std|-------------->+

                        +--->+-----+-----+               |

                        |          V   3                |

                       +<---+=====+=====+              V

                             | standard  |-------------->+

                             +=====+=====+               |

                                                        V    5

                                                  +=====+=====+

                                                  | historic  |

                                                   +===========+

     一个协议是否进入标准化程序或在标准化程序中由一个阶段(STATE)提升到另一个阶段取决于IESG的推荐。图中的单线框表示临时过渡阶段，双线框表示长期阶段，一个协议一般保留在一个临时阶段数个月时间，proposed standard最少六个月，draft standard最少四个月，如果是长期阶段则可能保持数年。

     图中从(1)proposed standard阶段到(2)draft standard阶段，这行动只能由IESG决定并且协议成为proposed standard至少六个月。

     从(2)draft standard到(3)standard也是只能由IESG决定并且协议成为draft standard至少四个月。

     如果协议不打算进行标准化就会被放置到(4)experimental阶段，该协议将脱离标准化程序，协议经过进一步完善后，需要重新提交加入标准化程序的申请。

     有时一个协议被其他协议取代，或感觉到将要被其他协议替代，于是成为(5)historic。     

 4 Internet协议的分析方法

     第一,寻找可以找到RFCs文件的地方

     有关Internet的问题当然最好在Internet中找答案,RFCs文件在Internet的许多地方可以找到，根据本人实践，我发现以下站点对此组织得不错，资料查找起来非常方便。

     https://www.cis.ohio-state.edu/hypertext/information/rfc.html

     第二,确定您所研究的协议的最新版本的RFC文件。

     如前文所述，在RFC-2400中有协议的完整清单，按照清单找到的RFC一般是协议的最新版本，如果协议的STATE是Standard就更好了。如下文所分析的FTP协议的RFC文件是RFC-959。

     第三，获取RFC文件

     根据RFC文件编号查看以上站点的RFCs文件索引

     https://www.cis.ohio-state.edu/htbin/rfc/INDEX.rfc.html

     在里面您可以很快地找到您要找的RFC文件。

     第四,阅读描述协议的RFC文件全文

     这不用说了。

     第五，实践

     实践是检验真理的唯一标准，虽然Internet协议不是什么真理，但如果能实践一下对理解和掌握都有好处，许多Internet应用层的协议可视程度非常高，协议中许多控制和参数用英文短语来表示，所传输的数据如文本也是ASCII码，如HTTP,FTP等,这类协议单纯用Telnet就可以模拟一下客户端程序的运作，当然，编程实现是最好的锻炼。

     第六,总结

     总结确实是不错的学习方法，自己的文章是一面镜子。

 5.举例:FTP协议分析

  FTP协议的定义在 RFC-959 "FILE TRANSFERPROTOCOL"(Standard, Recommended)。

 5.1介绍  

   FTP 文件传输协议 (FileTransfer Protocol)      

     FTP协议是一个应用层协议，在TCP上实现的。

     开发FTP的目的是

     1)促进文件(计算机程序和/或数据)的共享。

     2)鼓励对远程计算机间接或隐式(implicit)(通过程序)的使用。

     3)对用户屏蔽不同主机系统中的文件储存的细节。

     4)可靠和高效率地实现文件的传送。

     用户虽然可以直接通过一个终端使用FTP协议,但FTP协议的设计主要是给程序使用的。

 5.2 FTP模型图

                                            -------------

                                           |/---------\|

                                           ||   User  ||   --------

                                           ||Interface|<--->| User |

                                            |\----^----/|    --------

                  ----------                |     |    |

                  |/------\|  FTP Commands |/----V----\|

                 ||Server|<---------------->|  User  ||

                  ||  PI ||   FTP Replies  ||   PI   ||

                  |\--^---/|                |\----^----/|

                  |   |   |                |     |    |

      --------    |/--V---\|      Data     |/----V----\|    --------

      | File |<--->|Server|<---------------->|  User  |<--->| File |

      |System|    || DTP ||   Connection   ||  DTP   ||    |System|

      --------    |\------/|                |\---------/|    --------

                  ----------                -------------

                  Server-FTP                   USER-FTP

        注: 1. 图中的 data connection 可以被双向使用。

            2. data connection不需要任何时间都存在。

5.3 术语解析 

    为了描述上的准确，有关FTP术语出现的地方基本引用其英文原文，这里给出相应的中文解释，仅仅为了方便读者的理解。为了检索方便，这里的术语是按照其原英文顺序排列，一些前面没有解析的术语请在后面找。

  control connection 控制(信息)连接

    USER-PI和SERVER-PI之间交换FTP命令和回应的通信通道，连接中传送的信息符合Telnet协议(RFC-854)中的约定，在整个FTP使用过程中，控制连接是一直保持的。

  data connection 数据连接

     数据传送中使用的全双工连接，数据传送有特定模式(mode)和类型(type)。这里所说的数据可能是一个文件的一部分，或一整个文件或多个文件。连接可能是Server-DTP和User-DTP之间，或两个Server-DTPs之间，数据连接在需要传送数据时才需要建立。 

  data port 数据端口

     当有一个数据传送的要求时，DTP在数据端口监听，等待对方发来的连接请求以建立连接。

  data structures 数据结构

     除了数据类型(TYPE)外，FTP允许指定一个传送中文件的结构，以便决定Server-FTP对文件的处理方式。在FTP中定义有三种文件结构。

    file structure:文件没有内部结构，是一个连续的数据字节序列。

    record structure:文件数据按记录形式组织，文件由连续的记录组成。

    page structure:文件由独立的含索引的数据页组成。

  DTP （data transfer process) 数据传送进程

     数据传送进程建立数据连接(data connection)和进行文件数据的传送。        

  FTP commands FTP命令集

    FTP命令集是由User-FTP发给Server-FTP的请求命令组成的集合。        

  mode(传输)模式

    数据通过数据连接(data connection)传输数据的模式,模式定义了数据在传输中的格式，有以下三种。

     stream mode 流模式

      文件以字符流的形式传输，数据在表示类型上没有限制。

     block mode 块模式

      文件以数据块的模式按顺序传输，每个块的开头的含表达控制信息的字节。

     compressed mode 压缩模式

      传输的数据按照一定的格式被压缩。      

    模式用MODE命令设置，一般缺省情况是stream。

 PI (protocolinterpreter)协议解释器

    如上图所示，PI是用户端和服务器端实现和解释FTP协议的部分，具体在用户端(User-PI)实现FTP命令(FTP command)的发送和回应的解释，在服务器端实现FTP命令的解释执行和回应(reply)的返回。一般的常见FTP客户端软件(User-PI)上还有用户界面(User-Interface)，普通用户不用直接面对FTP命令和回应。实际例子中，简单的用户界面如现在各种操作系统提供的ftp程序的命令交互,复杂如诸如Bullet FTP,Cute FTP等产品的图形界面。最简单的情况可用Telnet程序来使用，但缺点是没法产生User-DTP,所以实际上无法直接实现数据的传送。

reply回应

    一个回应是一个从服务器传送到客户端的对FTP命令执行情况的反馈(肯定或否定)。回应的一般格式是一个3位数字编码后面跟着一句文字串。        

server-DTP

    服务器端的数据传送进程,User-FTP和Server-FTP之间数据连接建立过程中，Server-DTP一般充当请求连接的一方。在两个Server-FTP之间则其中一个充当被动监听，另外一个充当主动请求连接。具体由与它们相连的User-FTP发来的FTP命令决定。

server-PI

   服务端的协议解释器，在端口21监听等待User-PI请求建立控制连接(control connection)。和User-PI建立连接后，Server-PI接收user-PI发来的FTP命令,解析执行命令,发送回应,和有数据传送要求时管理server-DTP。

type类型

   由于不同类型的主机的数据表达方式不同，如IBM S390用EBCDIC码，普通PC用ASCII码，为了使不同类型的主机能实现文件的交换，在传送过程中的数据类型应该是确定的，类型的设置暗示了数据由储存中到传送的转换规则(transformation)。FTP中有以下类型。

     ASCII TYPE 

     这是比较通用的类型，表示发送的是字符文件，且在文件传送过程中数据使用ASCII码表示。发送者会把按内部字符表表示的数据转换成标准的八位NVT-ASCII码。         

    EBCDIC TYPE

     文件传送过程中使用EBCDIC码。

    IMAGE TYPE

     传送的数据按照连续的位流传送，为了传输上的方便，数据被封装为八位的字节单位，不足8位的补零。比较常见的称呼是二进制数据(binary data)。

    LOCAL TYPE

     传送的数据按照发送方所在主机的字符表示传送，在一些主机中一个字可能是大于8位的，则对齐成8的倍数,如一个36位字符转换64位，即8个字节，两个36位字符转换成72位，即9个字节。

user-DTP

   当有数据传送要求时，用户端的数据传送进程在数据端口监听，等待服务器端DTP的连接请求。

user-PI

   用户端的协议解释器,负责向Server-PI请求建立控制连接，发送FTP命令，在文件传输过程中管理user-DTP。        

5.4常用的FTP命令解释

   由于篇幅所限，这里不对以上每个FTP命令做解释，这里仅解释一下作者认为比较重要或常用的FTP命令，如果读者需要深入了解请参阅 RFC-959 "FILETRANSFER PROTOCOL"。

USER NAME(USER〈sp〉〈username〉)

    本命令的参数〈username〉标识用户名，服务器凭这个用户的权限使用文件系统。这个命令一般是在控制连接后的第一个命令。这个命令成功执行后，服务器会等待PASS命令，PASS也成功执行后，用户才算等录成功，可以存取Server-FTP中的文件。

PASSWORD(PASS〈sp〉〈password〉)

    这个命令是USER命令的补充，向Server-FTP发送由〈password〉所表示的密码，该命令执行成功，USER命令所指示的〈username〉才算成功登录。这里的〈password〉是明文传送。

CHANGE WORKING DIRECTORY(CWD〈SP〉〈pathname〉)

    令Server-FTP改变当前目录到〈pathname〉。

LOGOUT(QUIT)

    这个命令表示用户停止使用FTP, Server-FTP会关闭控制连接。

DATA PORT(PORT 〈SP〉〈host-port〉)

   User-FTP这个命令告诉Server-FTP，等待Server-DTP连接的DTP(可能是User-DTP或其他的Server-DTP）的地址,〈host-port〉所指示的就是这个地址，具体的PORT命令形式如下。

    PORT  h1,h2,h3,h4,p1,p2

     以上六个参数都是小于256的数字。

    h1,h2,h3,h4表示IP地址,如192,168,0,1 表示IP地址是192.168.0.1的主机。

    p1,p2,表示端口号，注意p1和p2都是小于256，所以1000表示为3,232(1000=3*256+232) 

RETRIEVE(RETR〈SP〉〈pathname〉)

     这个命令请求Server-FTP通过数据连接向User-DTP传送由〈pathname〉指示的文件的数据。          

STOR(RETR 〈SP〉〈pathname〉)  

     这个命令请求Server-FTP通过数据连接接收User-DTP传送的数据，数据保存在由〈pathname〉指示的文件中。注意〈pathname〉是在Server-FTP的主机上的。

PRINT WORKING DIRECTORY(PWD)

    Server-FTP收到该命令后在回应中返回当前工作目录名。

LIST(LIST [〈SP〉〈pathname〉])

    Server-FTP收到该命令后向User-DTP发送目录〈pathname〉的文件目录信息。如果没有〈pathname〉参数，则返回当前目录的文件目录信息。

STATUS(STAT [〈SP〉〈pathname〉])

   这个命令的回应有两种情况，没有〈pathname〉参数和有〈pathname〉参数。

   1)没有参数，Server-FTP会在回应中返回的一些状态信息，如以下是我Linux上的Server-FTP返回的信息:

         211-zfm.home FTP server status:

                 Versionwu-2.4.2-VR17(1) Mon Apr 19 09:21:53 EDT 1999

                 Connected to zfl_k6.home (192.168.0.1)

                 Logged in as fszfl

                 TYPE: ASCII, FORM: Nonprint; STRUcture:File; transfer MODE: Stream

                 No data connection

                 0data bytes received in 0 files

                 0 data bytes transmitted in 0 files

                 0 data bytes total in 0 files

                 145 traffic bytes received in 0 transfers

                 4306 traffic bytes transmitted in 0transfers

                 4501 traffic bytes total in 0 transfers

          211 End of status

   2)如果有〈pathname〉参数，则在回应中返回〈pathname〉的目录信息，如以下是我发送STAT . 的结果:

         213-statusof .:                                                   

              total 64                                                            

              drwxrwxr-x   2 fszfl   fszfl        1024 Nov 25 01:37.           

              drwx------  12 fszfl   fszfl        1024 Nov 29 00:35 ..          

           213 End of Status 

    这个功能好象和LIST有点相似，但LIST中的目录信息在数据连接中返回的。

HELP [〈SP〉〈string〉]

    这是帮助命令，如果没有参数则返回FTP命令列表，如果有参数则返回〈string〉表示的命令的语法。

5.5 FTP回应

 5.5.1 回应的格式

   FTP回应有3位数字编码和有关信息的文本组成,编码后一个分隔符，如果回应中返回信息的长度大于一行，则编码后跟减号(-),否则跟空格(〈sp〉)。多于一行的信息可以参考上面的例子。注意最后还有"213End of Status"表示信息的结束。FTP回应使用的编码是约定好的，信息文本可以由具体的Server-FTP设计。显然，编码为了方便程序设计，文本信息可以方便阅读。

  为了叙述方便，下文把这3位编码称为回应码。

5.5.2 回应码含义

  3位回应码的每一位都有确定的含义。第一位表示命令的执行结果，表示成功，失败，或命令没有完成。第二位表示回应的类型，第三位一般指第二位的进一步细化，预留给将来的发展。

  第1位可能的取值：

   1yz  初步确认 (Positive Preliminary reply)

     表示请求的命令已经开始，请等待进一步的回应，在此之前不要发送新的FTP命令。

   2yz  完成确认 (Positive Completion reply)

     表示请求的命令已经成功完成，可以发送新的请求。

   3yz  中间状态确认(Positive Intermediate reply)

     请求的命令已经被接受，等待下一条相关的命令提供进一步的信息。这个回应用于一些命令序列中，如USER和PASS，如果USER被接受则可以得到这个回应，表明还需要密码来完成用户的登录。

   4yz  暂时否认 (Transient Negative Completionreply)

     Server-FTP由于一些暂时的原因没有接收命令，User-FTP最好重新请求这个命令。如果是命令序列，则需要从该序列的第一条指令开始。

   5yz  命令有错 (Permanent Negative Completionreply)

     命令没有被接收，具体的拒绝原因由回应码第二位指出。

   第2位可能的取值，描述回应的分类：  

   x0z   语法(Syntax) - 命令语法不正确，或Server-FTP没有实现这个功能。                 

   x1z   信息(Information) -  描述如STAT或HELP等命令要求Server-FTP信息的返回。

   x2z   连接(Connections) - 描述有关控制和数据连接。

   x3z   帐户和认证(Authentication and accounting)- 登录过程的回应。   

   x4z   现在还没有指定。

   x5z   文件系统(File system) - 这个回应反映服务器的文件系统的状态。

   第3位的的含义需要根据第1,2位的值再细化。

5.5.3 回应举例

        3位回应码的不同组合产生了许多不同的含义，篇幅所限不一一列举，具体请查 RFC-959。下面是几个例子：

        200 Command okay.

        500 Syntax error, command unrecognized.            

        501 Syntax error in parameters or arguments

 5.6 FTP举例

      以下给出一个实际的例子，FTP客户端用随Windows98提供ftp,FTP服务器用Sco Unix 5.0.4,其中的'------〉'表示客户端发给服务器的命令，'〈--------'表示服务器的回应，〈CR〉表示回车，〈CRLF〉表示回车换行。

5.7实践

     有条件的读者可以按以上例子实践一下，在win98的user-FTP程序中有debug命令，可以打开调式模式，调式模式中会显示使用中的FTP命令和回应，读者可以很清晰地验证FTP的使用过程。

     如果还有条件可以用TCP编程技术，按FTP的原理和约定编制一个简单的User-FTP或Server-FTP程序，应该不是非常困难的事，但非常有利于理解。