可靠的数据流传输服务 -TCP:传输控制协议
可靠的数据流传输服务 ——TCP：传输控制协议
TCP的服务 *端到端的面向连接的服务 *可靠的连接建立和较好的连接释放 *完全可靠性 *全双工通信 *流接口 应用程序将数据流发送给tcp 在TCP流中,毎个数据字节都被编号(序号) Tcp层将数据流分成数据段并以序号来标识
TCP的服务 端到端的面向连接的服务 可靠的连接建立和较好的连接释放 完全可靠性 全双工通信 流接口 ➢应用程序将数据流发送给tcp ➢在TCP流中，每个数据字节都被编号（序号） ➢Tcp层将数据流分成数据段并以序号来标识
可靠的建立连接:三次握手协议 建立连接听起来容易,但实际上却意想不到的棘手。初看起来,一个传输实体似乎只 需向目的机器发送一个连接请求( CONNECT REQUEST)TPDU,并等待对方接受连接(CON NECT ACCEPTED)的应答就足够了,但当网络可能丢失、存储和出现重复分组时,问题便 出现了。 设想一个子网十分拥塞以至于确认根本不能及时返呵时,每个分组由于在规定时鞭 内得不到确认而需要重发二次或三次的情形。假设该子网内部使用数据报,并且每个分 组拥有不同的路由。一些分组可能会因为子网内部的线路拥塞,需要很长一段时间才能 到达,即它们被存储到子网中,并在很久以后突然出现。 最坏的可能性是当下面情况发生时,一个用户与银行之间建立了一条连接,并发送报 文让银行将一笔巨款转至一个不能完全信任的人的账户下,然后便释放连接。不幸的是 此时每个分组均被复制并存放于子网中。当连接已经断开后,所有的复制分组又会从子 网中发出并顺序到达目的端,请求与银行建立个新的连接并再次转账,然后释放连接。 而银行则无法辨别这些分组是重复的,便假定这是第二次独立的转账业务,于是将巨款再 次转移
可靠的建立连接：三次握手协议
Tomlinson建议为每台主机增 设一个计时(tme-of-day)时钟。不同主机的时钟不需同步。假定每个时钟都采用进制 计数器形式,在统…的时间间隔内累加计数。而且,计数器内的位数必须等于或大于序列 号内的位数。最后,也是更重要的,是假定时钟一直在运转,即使主机停机亦如此。 基本思想是确保在同一时刻永远不会出现两个编号相同的TPDU。当一个连接建立 后,时钟的低k位作为初始序号(也是k位)。这样便不同于滑动窗口协议,每个 连接均以不同的序号开始对其TPυU进行编号。序号空间应该很大,以便当序号再次(循 环了一周)出现时,具有相同序号的旧的TDU早已传送完毕 旦建立连接的两个传输实体接受了初始序号,便可以使用任何滑动窗口协议来实 现数据流量控制
滑动窗口
tomlinson(975)引入了三次握手( hree way hand shake)的方法。 该建立连接的协议并不要求连接的双方以相同的序号开始发送数据,所以它可以在同步 方式下使用,而不必非要采用全局计时时钟的方式。当主机1发出连接请求时,连接建立 的一般过程如图6-11(a)所示。主机1选择个序号x并向主机2发送一包含了该序号 的连接请求TPDU;接着,主机2回应一个接受连接TPDU,确认x并声明自己所选用的初 始序号y;最后,主机1在其发送的第个数据TPDU中确认主机2所选择的初始序号
现在来看看当出现延迟的重复控制TPDU时,次握手方法是如何工作的。在图 6-11(b)中,第一个TPDU是来自于一个已经释放的连接的延迟重复的连接请求,该TPDU 在主机1毫不知晓的情况下到达主机2。主机2通过向主机1发送一个接受连接TPD 来响应该TPDU,而该接受连接TPDU的真正目的是要证实主机1确实试图建立一个新的 连接。当主机1拒绝接受主机2建立连接的意图时,主机2便意识到自已受到了延时的 重复TPDU的欺骗并放弃该连接。这样,延时的重复数据便不会产生不良后果。 Host t Host 2 Host 1 Host 2 CR(seq= x) Old duplicate OA O47 (b
释放连接:改进的三次握手协议 连接的释放要比建立更容易些。尽管如此,仍有很多不引人注意的细节问题。前面 曾提到过,终止连接有两种方式:非对称秤放和对称释放。非对称释放是电话系统动作方 式:当一方挂机后,连接即告中断。对称释放将连接按照两个独立的单向连接来处理,要 求每一方分别释放连接。 非对称释放很突然,因而可能会导致丢失数据。请看图612中所示的秤放连接(DR) 情形。当连接建立后,主机1发送了一个数据TPDU并正确抵达主机2,接着,主机1发送 了另一个数据TPDU,这次很不幸,主机2在收到第二个TDU之前先发出了 DISCONNECT (释放连接请求),结果是连接被释放,数据被丢失 Host 1 lost 2 CR CK ATA DATA No data are delivered after a disconnect request
释放连接：改进的三次握手协议
显然,我们需要采用更为完善的连接释放协议来防止数据丢失。一种方法是采用对 称释放方式,每个方向独立释放本方的连接。这种方式中,即使主机已经发出了释放连接 TPDU,仍然能够继续接收数据。 对称释放方式适用于每个用户进程有固定数量的数据需要发送,而且清楚地知道何 时发送完毕的情况。其他情况下,决定所有工作是否已经完成和连接是否应该释放是没 有把握的。可以预想一种协议,在该协议中,机1说:“我发送完了。你呢?如果主机2 响应:“我也发送完了。再见。”那么,连接便可以被安全释放。 不幸的是,这种协议并非总是有效的。对此有一个著名的问题,称为两军问题(to army problen)。设想一支白军被围困在个山谷中,如图613所示。山谷两侧是蓝军。 白军在人数上比山谷两侧的任何一支蓝军都多,但少于两支蓝军合在一起的人数。如果 单独一支蓝军对白军发动进玫则必败无疑;但如果两支蓝军同时进攻,便可取胜
Blue Blue B army #1 #2 White army 两支蓝军欲同时发动进攻。然而,他们唯的通信方法是派遗信使步行奔过山谷去 传递信息。在山谷中,信使有可能被俘虏而丢失信件(即两支蓝军只能使用一种不可靠的 通信方法)。问题是:存在使蓝军获胜的协议吗?
假设蓝军1号的指挥官发出消息:“我建议在3月29日拂晓发起攻击。怎么样?现 在假设信息送到了,蓝军2号的指挥官同意这建议,并且他的回信安全送同到蓝军|号 处。那么能否发动进攻呢?很可能不会,因为蓝军2号的指挥官不知道他的回信是否安 全送到了。如果未送到,蓝军1号将不会适时发起攻击,那么他贸然进攻就是愚靈的。 现在我们采用三次握手的方法来改进这·协议。最初提出建议的指挥官必须确认对 该建议的应答信息。假如信息没有丢大,蓝军2号将收到该确认信息,但现在蓝军1号指 挥官开始犹豫起来。因为他毕竞不知道他的确认信息是否被安全收到了,如果未被收到, 他清楚蓝军2号不会按时发动进攻。那么我们现在釆用四次握手协议会如何呢?结果仍 是于事无补。 为了看清两军问题与释放连接之间的相关性,只需用“释放连接”代替“攻击”…词就 行了。如果连接的双方在确信对方也准备释放连接之前都不准备断开连接,那么连接将 永远也得不到释放。 在实际应用时,人们在解决释放连接问题时往往准备冒比进攻白军问题更大的风险, 所以问题并非完全没有希望解决。图6-14表明了采用三次握手方法进行连接释放的四 种情况。这一协议并非绝对无误,但它已令人满意了
