没有合适的资源?快使用搜索试试~ 我知道了~
TCPIP协议详解卷三:事务.pdf
需积分: 13 9 下载量 186 浏览量
2007-08-27
11:13:01
上传
评论
收藏 9.18MB PDF 举报
温馨提示
试读
239页
TCPIP协议详解卷三:事务.pdf------不用说也知介绍什么哈:P
资源推荐
资源详情
资源评论
下载
第1章 T/TCP 概 述
1.1 概述
本章首先介绍客户-服务器事务概念。我们从使用 U D P 的客户-服务器应用开始,这是最
简单的情形。接着我们编写使用 T C P的客户和服务器程序,并由此考察两台主机间交互的
T C P / I P 分组。然后我们使用 T / T C P,证明利用T / T C P可以减少分组数,并给出为利用 T / T C P需
要对两端的源代码所做的最少改动。
接下来介绍了运行书中示例程序的测试网络,并对分别使用 U D P、T C P 和T / T C P 的客户-
服务器应用程序进行了简单的时间耗费比较。我们考察了一些使用 T C P 的典型I n t e r n e t 应用程
序,看看如果两端都支持 T / T C P ,将需要做哪些修改。紧接着,简要介绍了 I n t e r n e t协议族中
事务协议的发展历史,概略叙述了现有的 T / T C P实现。
本书全文以及有关 T / T C P 的文献中,事务一词的含义都是指客户向服务器发出一个请求,
然后服务器对该请求作出应答。 I n t e r n e t 中最常见的一个例子是,客户向域名服务器 ( D N S ) 发
出请求,查询域名对应的 I P 地址,然后域名服务器给出响应。本书中的事务这个术语并没有
数据库中的事务那样的含义:加锁、两步提交、回退,等等。
1.2 UDP上的客户-服务器
我们先来看一个简单的 U D P客户-服务器应用程序的例子,其客户程序源代码如图 1 - 1 所
示。在这个例子中,客户向服务器发出一个请求,服务器处理该请求,然后发回一个应答。
图1-1 UDP上的简单客户程序
第一部分 TCP事务协议
图1-1 (续)
本书中所有源代码的格式都是这样。每一非空行前面都标有行号。正文中叙述
某段源代码时,这段源代码的起始和结束行号标记于正文段落的左边,如下面的正
文所示。有时这些段落前面会有一小段说明,对所描述的源代码进行概要说明。源
代码段开头和结尾处的水平线标明源代码段所在的文件名。这些文件名通常都是指
我们在1 . 9 节中将介绍的4 . 4 版B S D - L i t e中发布的文件。
我们来讨论这个程序的一些有关特性,但不详细描述插口函数,因为我们假设读者对这
些函数有一些基本的认识。关于插口函数的细节在参考书 [Stevens 1990]的第6章中可以找到。
图1 - 2给出了头文件c l i s e r v . h 。
1. 创建U D P 插口
1 0 - 1 1 s o c k e t 函数用于创建一个U D P 插口,并将一个非负的插口描述符返回给调用进程。
出错处理函数e r r _ s y s 参见参考书[Stevens 1992]的附录B . 2。这个函数可以接受任意数目的
参数,但要用 v s p r i n t f 函数对它们格式化,然后这个函数会打印出系统调用所返回的
e r r n o 值所对应的U n i x出错信息,然后终止进程。
2. 填写服务器地址
1 2 - 1 5 首先用m e m s e t 函数将I n t e r n e t 插口地址结构清零,然后填入服务器的I P地址和端口号。
为简明起见,我们要求用户在程序运行中通过命令行输入一个点分十进制数形式的 I P地址
(a r g v [ 1 ] )。服务器端口号 (U D P _ S E R V _ P O R T )在头文件c l i s e r v . h 中用# d e f i n e定义,在
本章的所有程序首部中都包含了该头文件。这样做是为了使程序简洁,并避免使调用
g e t h o s t b y n a m e 和g e t s e r v b y n a m e函数的源代码复杂化。
3. 构造并向服务器发送请求
1 6 - 1 9 客户程序构造一个请求 (只用一行注释来表示),并用s e n d t o 函数将其发出,这样就
有一个 U D P 数据报发往服务器。同样是为了简明起见,我们假设请求 (R E Q U E S T )和应答
(R E P L Y )的报文长度为固定值。实用的程序应当按照请求和应答的最大长度来分配缓存空间,
但实际的请求和应答报文长度是变化的,而且一般都比较小。
4. 读取和处理服务器的应答
2 0 - 2 3 调用r e c v f r o m 函数将使进程阻塞(即置为睡眠状态),直至收到一个数据报。接着客
户进程处理应答(用一行注释来表示),然后进程终止。
由于r e c v f r o m函数中没有超时机制,请求报文或应答报文中任何一个丢失都将
造成该进程永久挂起。事实上, U D P 客户-服务器应用的一个基本问题就是对现实世
界中的此类错误缺少健壮性。在本节的末尾将对这个问题做更详细的讨论。
2计计第一部分 TCP事务协议
下载
在头文件c l i s e r v . h中,我们将S A定义为struct sockaddr*,即指向一般
的插口地址结构的指针。每当有一个插口函数需要一个指向插口地址结构的指针时,
该指针必须被置为指向一个一般性插口地址结构的指针。这是由于插口函数先于
ANSI C标准出现,在8 0 年代早期开发插口函数的时候, v o i d *(空类型)指针类型尚
不可用。问题是,“struct sockaddr*”总共有1 7个字符,这经常使这一行源代
码超出屏幕(或书本页面 )的右边界,因此我们将其缩写成为 S A 。这个缩写是从 B S D
内核源代码中借用过来的。
图1 - 2给出了在本章所有程序中都包含的头文件 c l i s e r v . h 。
图1-2 本章各程序中均包含的头文件 c l i s e r v . h
图1 - 3 给出了相应的U D P 服务器程序。
图1-3 与图1 - 1的U D P客户程序对应的U D P服务器程序
第1章 T / T C P概述计计3
下载
图1-3 (续)
5. 创建U D P 插口和绑定本机地址
8 - 1 5 调用s o c k e t 函数创建一个U D P插口,并在其I n t e r n e t插口地址结构中填入服务器的本
机地址。这里本机地址设置为通配符 (I N A D D R _ A N Y ),这意味着服务器可以从任何一个本机
接口接收数据报(假设服务器是多宿主的,即可以有多个网络接口 )。端口号设为服务器的知名
端口(U D P _ S E R V _ P O R T ),该常量也在前面讲过的头文件 c l i s e r v . h 中定义。本机I P地址和
知名端口用b i n d函数绑定到插口上。
6. 处理客户请求
1 6 - 2 5 接下来,服务器程序就进入一个无限循环:等待客户程序的请求到达 (r e c v f r o m ),
处理该请求(我们只用一行注释来表示处理动作 ),然后发出应答(s e n d t o)。
这只是最简单的U D P 客户-服务器应用。实际中常见的例子是域名服务系统 ( D N S )。D N S
客户(称作解析器)通常是一般客户应用程序 (例如,Te l n e t 客户、F T P 客户或W W W浏览器)的一
个部分。解析器向 D N S 服务器发出一个U D P数据报,查询某一域名对应的 I P地址。服务器发
回的应答通常也是一个U D P 数据报。
如果观察客户向服务器发送请求时双方交换的分组,我们就会得到图 1 - 4这样的时间系列,
页面上时间自上而下递增。服务器程序先启动,其行为过程给在图 1 - 4 的右半部,客户程序稍
后启动。
我们分别来看客户和服务器程序中调用的函数及其相应内核执行的动作。在对 s o c k e t函
数的两次调用中,上下紧挨着的两个箭头表示内核执行请求的动作并立即返回。在调用
s e n d t o 函数时,尽管内核也立即返回,但实际上已经发出了一个 U D P 数据报。为简明起见,
我们假设客户程序的请求和服务器程序的应答所生成的 I P 数据报的长度都小于网络的最大传
输单元( M T U ),I P数据报不必分段。
在这个图中,有两次调用 r e c v f r o m 函数使进程睡眠,直到有数据报到达才被唤醒。我
们把内核中相应的例程记为 s l e e p和w a k e u p 。
最后,我们还在图中标出了事务所耗费的时间。图 1 - 4 的左侧标示的是客户端测得的事务
时间:从客户发出请求到收到服务器的应答所经历的时间。组成这段事务时间的数值标在图
的右侧:RTT + SPT,其中RT T是网络往返时间,S P T是服务器处理客户请求的时间。 U D P 客
户-服务器事务的最短时间就是 RTT + SPT。
4计计第一部分 TCP事务协议
下载
图1-4 UDP客户-服务器事务的时序图
尽管没有明确说明,但我们已经假设从客户到服务器的路径需要
1
/2 RT T 时间,返
回的路径又需
1
/2 RT T时间。但实际情况并非总是如此。据对大约 6 0 0 条I n t e r n e t 路径的
研究[Paxson 1995b]发现:3 0 % 的路径呈现明显的不对称性,说明两个方向上的路由
经过了不同的站点。
我们的U D P 客户-服务器看起来非常简捷 (每个程序只有大约3 0 行有关网络的源代码 ),但
在实际环境中应用还不够健壮。由于 U D P 是不保证可靠的协议,数据报可能会丢失、失序或
重复,因此实用的应用程序必须处理这些问题。这通常是在客户程序调用 r e c v f r o m 时设置
一个超时定时器,用以检测数据报的丢失,并重传请求。如果要使用超时定时器,客户程序
就要测量RT T并动态更新,这是因为互连网上的 RT T 会在很大范围内变化,并且变化很快。但
如果是服务器的应答丢失,而不是请求,那么服务器就要再次处理同一个请求,这可能会给
某些服务带来问题。解决这个问题的办法之一是让服务器将每个客户最近一次请求的响应暂
存起来,必要时重传这个应答即可,而不需要再次处理这个请求。最后,典型的情况是,客
户向服务器发送的每个请求中都有一个不同的标识,服务器把这个标识在响应中传回来,使
客户能把请求和响应匹配起来。在参考书 [Stevens 1990]的 8 . 4节中给出了U D P 上的客户-服务
器处理这些问题的源代码细节,但这将在程序中增加大约 5 0 0 行源代码。
一方面,许多U D P应用程序都通过执行所有这些额外步骤 (超时机制、RT T值测量、请求
标识,等等)来增加可靠性;另一方面,随着新的 U D P 应用程序不断出现,这些步骤也在不断
地推陈出新。参考书 [Patridge 1990b]中指出,“为了开发‘可靠的 U D P 应用程序’,你要有状
态信息(序列号、重传计数器和往返时间估计器 ),原则上你要用到当前T C P 连接块中的全部信
第1章 T / T C P概述计计5
下载
客户端
函数 内核 网络 内核
服务器端
函数
返回
进程请求
返回
剩余238页未读,继续阅读
资源评论
Z1Z1Z1Z12
- 粉丝: 0
- 资源: 3
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功