|
|
总的来说,每个应用系统都有能力实现其自身的协议以适应IP网络在分组传送时发生的
异常变化,并从中进行恢复。然而,在Internet发展的初期,人们认识到这种实现会导致大量
的冗余设计和实现的复杂性。许多早期的应用,像电子邮件、文件传输协议(FTP)和Telnet
(远端登录服务)等,对分组的丢失都十分敏感(要保证发送的每一条信息都被接收到),但
对实时性不特别敏感(可以忍受的延迟从数十毫秒到几秒钟)。应用系统之间需要共享使用相
同的端到端的传输要求,以便实现字节在终端之间按顺序可靠地传输。因此,一种明智的方
法就是让这些应用系统共享一个共同的协议,该协议可以在不可靠的IP网络服务之上提供一
种可靠的传输服务。最终,这种技术导致了现在人人皆知的传输控制协议(TCP)的发展。
TCP位于应用系统和IP网络之间(见图1-2),它把应用系统的数据分成特定分组长度的单
元,采用应答的IP分组传输方式检测分组的丢失,如果出现分组丢失,就重新发送该IP分组。
TCP采用窗口流量控制机制,以便用网络友好的方式来适应在IP网络中可能出现的拥塞。在
任何两个终端点之间基于端口号的复用方式,支持数千个独立的应用系统数据流。TCP对应
用系统隐藏了IP网络的不可靠性,可以使开发者把注意力集中在其应用系统的实现目标上—
例如其数据库更新、交换邮件、文件传输服务、远端登录服务、Web页面的下载等等。最重
要的是,IP网络通常并不知道TCP实体正在为其他的应用系统产生和交换IP包。一个很好的比
方就是,一组经理有一个共同的管理秘书。经理们只关心与他通信的其他经理,而让秘书去
利用电话、语音邮件、邮政服务等具体的通信手段来传输其实际的信息。
图1-2传输控制协议跨越IP网络透明运行
并不是所有的应用都需要TCP所提供的可靠服务或流量控制,也并不是所有的应用都能
容忍TCP的初始启动延迟。对于这些应用,用户数据报协议(UserDatagramProtocol,UDP)
第1章今天的Internet使用3
下载
IP分组
内容
IP内容
内容
ICP层ICP层
ICP帧
ICP帧
ICP帧
IP网络
内容
内容
IP层IP分组IP层
提供了一种无连接的、面向数据包的传输服务。尽管从原则上讲,原始的IP访问能够满足使
用的需要,但UDP还是有必要的,它可以在每个终端点的操作系统中提供一个访问IP层的、
通用的应用级的接口。与TCP一样,UDP也支持基于端口号的复用,允许在任意两个IP终端
之间支持数千个独立的、不可靠的应用到应用的数据报流。与TCP不同的是,UDP没有采用
窗口流量控制,因此不会影响其传输速度,也没有同步确认机制来检测和恢复丢失的分组。
如果需要这些功能,那么应用程序只能自己来完成。
应用流(applicationflow)或者流(flow)这个术语常常用于表示在两个相同的终端上、
相同的TCP或UDP端口之间进行交换的分组的序列。对于网络QoS的各种建议都涉及到网络能
够识别IP分组的内容,并根据源端/目的端的IP地址以及TCP或UDP的端口号对分组流进行区
分。(许多应用都使用某些熟知的缺省端口号,因此有时候我们能够从应用流所使用的端口号
推断出应用程序的标识。) |
|