Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1799083
  • 博文数量: 600
  • 博客积分: 10581
  • 博客等级: 上将
  • 技术积分: 6205
  • 用 户 组: 普通用户
  • 注册时间: 2008-11-06 10:13
文章分类
文章存档

2016年(2)

2015年(9)

2014年(8)

2013年(5)

2012年(8)

2011年(36)

2010年(34)

2009年(451)

2008年(47)

分类: LINUX

2009-08-22 12:58:06

必须在生成的IP首部中加入某种标识,以表明数据属于哪一层。为此,IP在首部中存入一个长度为8比特的数值,称作协议域。1表示为ICMP协议,2表示为IGMP协议,6表示为TCP协议,17表示为UDP协议。

    类似地,许多应用程序都可以使用TCPUDP来传送数据。运输层协议在生成报文首部时要存入一个应用程序的标识符。TCPUDP都用一个16 bit的端口号来表示不同的应用程序。TCPUDP把源端口号和目的端口号分别存入报文首部中。

    网络接口分别要发送和接收IPARPRARP数据,因此也必须在以太网的帧首部中加入某种形式的标识,以指明生成数据的网络层协议。为此,以太网的帧首部也有一个16 bit的帧类型域。

 

1.7 分用(Demultiplexing

    当目的主机收到一个以太网数据帧时,数据就开始从协议栈中由底向上升,同时去掉各层协议加上的报文首部。每层协议盒都要去检查报文首部中的协议标识,以确定接收数据的上层协议。这个过程称作分用,图1.8显示了该过程是如何发生的。

 

1.8  以太网数据帧的分用过程

 

(下面是原书p.11①的译文)

    为协议ICMPIGMP定位一直是一件很棘手的事情。在图1.4中,我们把它们与IP放在同一层上,那是因为事实上它们是IP的附属协议。但是在这里,我们又把它们放在IP层的上面,这是因为ICMPIGMP报文都被封装在IP数据报中。

    对于ARPRARP我们也遇到类似的难题。在这里我们把它们放在以太网设备驱动程序的上方,这是因为它们和IP数据报一样,都有各自的以太网数据帧类型。但在图2.4中,我们又把ARP作为以太网设备驱动程序的一部分,放在IP层的下面,其原因在逻辑上是合理的。

 

    当进一步描述TCP的细节时,我们将看到协议确实是通过目的端口号,源IP地址和源端口号进行解包的。

 

1.8 客户服务器模型

    大部分网络应用程序在编写时都假设一端是客户,另一端是服务器,其目的是为了让服务器为客户提供一些特定的服务。

    我们可以将这种服务分为两种类型:重复型或并发型。重复型服务器通过以下步骤进行交互:

I1. 等待一个客户请求的到来。

I2. 处理客户请求。

I3. 发送响应给发送请求的客户。

I4. 返回I1步骤。

重复型服务器主要的问题发生在I2状态。在这个时候,它不能为其他客户机提供服务。

相应地,并发型服务器采用以下步骤:

C1. 等待一个客户请求的到来

C2. 启动一个新的服务器来处理这个客户的请求。在这期间可能生成一个新的进程、任务或线程,并依赖底层操作系统的支持。这个步骤如何进行取决于操作系统。生成的新服务器对客户的全部请求进行处理。处理结束后,终止这个新服务器。

C3.返回C1步骤。

    并发服务器的优点在于它是利用生成其他服务器的方法来处理客户的请求。也就是说,每个客户都有它自己对应的服务器。如果操作系统允许多任务,那么就可以同时为多个客户同时服务。

    我们对服务器,而不是对客户进行分类的原因是因为对于一个客户来说,它通常并不能够辨别自己是与一个重复型服务器或并发型服务器进行对话。

    一般来说,TCP服务器是并发的,而UDP服务器是重复的,但也存在一些例外。我们将在11.12节对UDP对其服务器产生的影响进行详细讨论,并在18.11节对TCP对其服务器的影响进行讨论。

 

1.9 端口号

    我们前面已经指出过,TCPUDP采用16比特的端口号来识别应用程序。那么这些端口号是如何选择的呢?

    服务器一般都是通过人们所熟知的端口号来识别的。例如,对于每个TCP/IP实现来说,FTP服务器的TCP端口号都是21,每个Telnet服务器的TCP端口号都是23,每个TFTP(简单文件传输协议)服务器的UDP端口号都是69。任何TCP/IP实现所提供的服务都用众所周知的11023之间的端口号。这些人们所熟知的端口号由Internet端口号分配机构(Internet Assigned Numbers Authority, IANA)来管理。

 

(下面是原书p.13①的译文)

    1992年为止,人们所熟知的端口号介于1255之间。2561023之间的端口号通常都是由Unix系统占用,以提供一些特定的Unix服务――也就是说,提供一些只有Unix系统才有的,而其他操作系统可能不提供的服务。现在IANA管理11023之间所有的端口号。

Internet扩展服务与Unix特定服务之间的一个差别就是TelnetRlogin。它们二者都允许我们通过计算机网络登录到其他主机上。Telnet是采用端口号为23TCP/IP标准且几乎可以在所有操作系统上进行实现。相反,Rlogin最开始时只是为Unix系统设计的(尽管许多非Unix系统现在也提供该服务),因此在80年代初,它的有名端口号为513

 

    客户端通常对它所使用的端口号并不关心,只需保证该端口号在本机上是唯一的就可以了。客户端口号又称作临时端口号(即存在时间很短暂)。这是因为它通常只是在用户运行该客户程序时才存在,而服务器则只要主机开着的,其服务就运行。

    大多数TCP/IP实现给临时端口分配10245000之间的端口号。大于5000的端口号是为其他服务器预留的(Internet上并不常用的服务)。我们可以在后面看见许多这样的给临时端口分配端口号的例子。

 

(下面是原书p.13②的译文)

Solaris 2.2是一个很有名的例外。通常TCPUDP的缺省临时端口号从32768开始。在E.4节中,我们将详细描述系统管理员如何对配置选项进行修改以改变这些缺省项。

大多数Unix系统的file/etc/services都包含了人们熟知的端口号。为了找到Telnet服务器和域名系统的端口号,我们可以运行以下语句:

 

(见原书p.13的③)

 

保留端口号

    Unix系统有保留端口号的概念。只有具有超级用户特权的进程才允许给它自己分配一个保留端口号。

    这些端口号介于11023之间,一些应用程序(如有名的Rlogin26.2节)将它作为客户与服务器之间身份认证的一部分。

 

1.10 标准化过程

    究竟是谁控制着TCP/IP协议组件,又是谁在定义新的标准以及其他类似的事情?事实上,有四个小组在负责Internet技术。

    1. Internet协会(ISOC: Internet Society)是一个推动、支持和促进Internet不断增长和发展的专业组织,它把Internet作为全球研究通信的基础设施。

    2. Internet体系结构委员会(IABInternet Architecture Board)是一个技术监督和协调的机构。它由国际上来自不同专业的15个志愿者组成,其职能是负责Internet标准的最后编辑和技术审核。IAB隶属于ISOC

    3. Internet工程专门小组(IETFInternet Engineering Task Force)是一个面向近期标准的组织,它分为9个领域(应用,寻径和寻址,安全等等)。IETF开发成为Internet标准的规约。为帮助IETF主席,又成立了Internet工程指导小组(IESGInternet Engineering Steering Group)。

    4. Internet研究专门小组主要对长远的项目进行研究。

    IRTFIETF都隶属于IAB。文献[Crocker 1993]提供了关于Internet内部标准化进程更为详细的信息,同时还介绍了它的早期历史。

 

1.11 RFC

    所有关于Internet的正式标准都以RFCRequest for Comment)文档出版。另外,大量的RFC并不是正式的标准,出版的目的只是为了提供信息。RFC的篇幅从1页到200页不等。每一项都用一个数字来标识,如RFC 1122,数字越大说是RFC的内容越新。

所有的RFC都可以通过电子邮件或用FTPInternet上免费获取。如果发送下面这份电子邮件,你就会收到一份获取RFC的方法清单:

 

To: rfc-info@ISI.EDU

Subject: getting rfcs

help: ways_to_get_rfcs

 

    最新的RFC索引总是搜索信息的起点。这个索引列出了RFC被替换或局部更新的时间。

下面是一些重要的RFC文档:

    1. 赋值RFCAssigned Numbers RFC)列出了所有Internet协议中使用的数字和常数。至本书出版时为止,最新RFC的编号是1340 [Reynolds and Postel 1992]。所有著名的Internet端口号都列在这里。

    当这个RFC被更新时(通常每年至少更新一次),索引清单会列出RFC 1340被替换的时间。       

    2. Internet正式协议标准,目前是RFC 1600[Postel 1994]。这个RFC描述了各种Internet协议的标准化现状。每种协议都处于下面几种标准化状态之一:标准,草案标准,提议标准,实验标准,信息标准,和历史标准。另外,对每种协议都有一个要求的层次:必需的,建议的,可选择的,限制使用的,或者不推荐的。

    与赋值RFC一样,这个RFC也定期更新。请一定随时查看最新版本。

    3. 主机需求RFC11221123[Braden 1989a, 1989b]RFC 1122针对链路层,网络层和运输层,RFC 1123针对应用层。这两个RFC对早期重要的RFC文档作了大量的纠正和解释。如果要查看有关协议更详细的细节内容,它们通常是一个入口点。它们列出了协议中关于“必须”,“应该”,“可以”,“不应该”或者“不能”等特性及其实现细节。

    文献[Borman 1993b]提供了有关这两个RFC的实用内容。RFC 1127[Braden 1989c]对工作小组开发主机需求RFC过程中的讨论内容和结论进行了非正式的总结。

    4.路由器需求RFC,目前正式版是RFC 1009[Braden and Postel 1987],但一个新版已接近完成[Aknqyust 1993]。它与主机需求RFC类似,但是只单独描述了路由器的需求。

 

1.12 标准的简单服务

    有一些标准的简单服务几乎每种实现都要提供。在本书中我们将使用其中的一些服务程序,而客户程序通常选择Telnet。图1.9描述了这些服务。从该图我们可以看出,当使用TCPUDP提供相同的服务时,一般选择相同的端口号.

 

(下面是原书p.15①的译文)

    如果仔细检查这些标准的简单服务以及其他标准的TCP/IP服务(如Telnet, FTP, SMTP等)的端口号时,我们发现它们都是奇数。这是有历史原因的,因为这些端口号都是从NCP端口号派生出来的。(NCP,即网络控制协议,是ARPANET的运输层协议,是TCP的前身。NCP是单工的,不是全双工的,因此每个应用程序需要两个连接,需预留一对奇数和偶数端口号。当TCPUDP成为标准的运输层协议时,每个应用程序只需要一个端口号,因此就使用了NCP中的奇数。

 

(以下是原书p.161.9的译文)

名字

TCP端口号

UDP端口号

RFC

描述

echo

7

7

862

服务器返回客户发送的所有内容。

discard

9

9

863

服务器丢弃客户发送的所有内容。

daytime

13

13

867

服务器以可读形式返回时间和日期。

chargen

19

19

864

当客户发送一个数据报时,TCP服务器发送一串连续的字符流,直到客户中断连接。UDP服务器发送一个随机长度的数据报。

time

37

37

868

服务器返回一个二进制形式的32 bit数,表示从UTC时间190011日午夜至今的秒数。

 

1.9 大多数实现都提供的标准的简单服务

 

1.13 互连网

    在图1.3中,我们列举了一个由两个网络组成的互连网-一个以太网和一个令牌环网。在1.4节和1.9节中,我们讨论了世界范围内的互连网-Internet,以及集中分配IP地址的需要(InterNIC),还讨论了著名的端口号(IANA)。internet这个词第一个字母是否大写决定了它具有不同的含义。

    internet意思是用一个共同的协议族把多个网络连接在一起。而Internet指的是世界范围内通过TCP/IP互相通信的所有主机集合(超过100万台)。Internet是一个internet(互连网),但internet不等于Internet

 

1.14 实现

    既成事实标准的TCP/IP软件实现来自于位于伯克利的加利福尼亚大学的计算机系统研究小组。从历史上看,软件是随同4.x BSD系统(Berkeley Software Distribution)的网络版一起发布的。它的源代码是许多其他实现的基础。

    1.10列举了各种BSD版本发布的时间,并标注了重要的TCP/IP特性。列在左边的BSD网络版,其所有的网络源代码可以公开得到:包括协议本身以及许多应用程序和工具(如TelnetFTP)。

    在本书中,我们将使用“伯克利派生系统”来指SunOS 4.x, SVR4, 以及AIX 3.2等那些基于伯克利源代码开发的系统。这些系统有很多共同之处,经常包含相同的错误。

 

(以下是原书p.171.10的译文)

                                                      4.2BSD (1983) 第一个广泛可用的TCP/IP发布

                                 4.3BSD (1986)  TCP性能得到改善

                                 4.3BSD Tahoe (1988) 启动慢,拥塞避免措施

BSD网络软件1.0(1989)Net/1  

                                                        4.3BSD Reno(1990) TCP首部预测,SLIP首部压缩

                                                        路由表修改

BSD网络软件2.0(1991)Net/2

                                                        4.4BSD(1993)  多播,长胖管道修改

4.4BSD-Lite (1994)

又称为Net/3

阅读(641) | 评论(0) | 转发(0) |
0

上一篇:TCP/IP详解1

下一篇:TCP/IP详解3

给主人留下些什么吧!~~