前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >速读原著-TCP/IP(长肥管道)

速读原著-TCP/IP(长肥管道)

作者头像
cwl_java
发布2020-03-13 09:39:08
6480
发布2020-03-13 09:39:08
举报
文章被收录于专栏:cwl_Javacwl_Java

第24章 TCP的未来和性能

24.3 长肥管道

在2 0 . 7节,我们把一个连接的容量表示为

代码语言:javascript
复制
c a p a c i t y (b) = b a n d w i d t h (b/s) × ro u n d-t r i p t i m e ( s )

并称之为带宽时延乘积。也可称它为两端的管道大小。当这个乘积变得越来越大时, T C P的某些局限性就会暴露出来。图 2 4 - 5显示了多种类型的网络的某些数值。

在这里插入图片描述
在这里插入图片描述

可以看到带宽时延乘积的单位是字节,这是因为我们用这个单位来测量每一端的缓存大小和窗口大小。

具有大的带宽时延乘积的网络被称为长肥网络( Long Fat Network,即L F N,发音为“e l e f a n ( t ) s”),而一个运行在 L F N上的T C P连接被称为长肥管道。回顾图 2 0 - 11和图2 0 - 1 2,管道可以被水平拉长(一个长的 RT T),或被垂直拉高(较高的带宽),或向两个方向拉伸。使用长肥管道会遇到多种问题。

  1. T C P首部中窗口大小为 16 bit,从而将窗口限制在 6 5 5 3 5个字节内。但是从图 2 4 - 5的最后一列可以看到,现有的网络需要一个更大的窗口来提供最大的吞吐量。在 2 4 . 4节介绍的窗口扩大选项可以解决这个问题。
  2. 在一个长肥网络 L F N内的分组丢失会使吞吐量急剧减少。如果只有一个报文段丢失,我们需要利用 2 1 . 7节介绍的快速重传和快速恢复算法来使管道避免耗尽。但是即使使用这些算法,在一个窗口内发生的多个分组丢失也会典型地使管道耗尽(如果管道耗尽了,慢启动会使它渐渐填满,但这个过程将需要经过多个 RT T)。 在RFC 1072 [Jacobson and Braden 1988]中建议使用有选择的确认( S A C K)来处理在一个窗口发生的多个分组丢失。但是这个功能在 RFC 1323中被忽略了,因为作者觉得在把它们纳入T C P之前需要先解决一些技术上的问题。
  3. 我们在第2 1 . 4节看到许多T C P实现对每个窗口的RT T仅进行一次测量。它们并不对每个报文段进行RT T测量。在一个长肥网络 L F N上需要更好的RT T测量机制。我们将在 2 4 . 5节介绍时间戳选项,它允许更多的报文段被计时,包括重传。
  4. T C P对每个字节数据使用一个32 bit无符号的序号来进行标识。如果在网络中有一个被延迟一段时间的报文段,它所在的连接已被释放,而一个新的连接在这两个主机之间又建立了,怎样才能防止这样的报文段再次出现呢?首先回想起I P首部中的T T L为每个I P段规定了一个生存时间的上限—2 5 5跳或2 5 5秒,看哪一个上限先达到。在1 8 . 6节我们定义了最大的报文段生存时间(M S L)作为一个实现的参数来阻止这种情况的发生。推荐的M S L的值为2分钟(给出一个2 4 0秒的2 M S L),但是我们在1 8 . 6节看到许多实现使用的M S L为3 0秒。

在长肥网络 L F N上,T C P的序号会碰到一个不同的问题。由于序号空间是有限的,在已经传输了4 294 967 296个字节以后序号会被重用。如果一个包含序号 N字节数据的报文段在网络上被迟延并在连接仍然有效时又出现,会发生什么情况呢?这仅仅是一个相同序号N在M S L期间是否被重用的问题,也就是说,网络是否足够快以至于在不到一个M S L的时候序号就发生了回绕。在一个以太网上要发送如此多的数据通常需要 6 0分钟左右,因此不会发生这种情况。但是在带宽增加时,这个时间将会减少:一个 T 3的电话线(45 Mb/s)在1 2分钟内会发生回绕,F D D I(100 Mb/s)为5分钟,而一个千兆比网络(1000 Mb/s)则为3 4秒。这时问题不再是带宽时延乘积,而在于带宽本身。在2 4 . 6节,我们将介绍一种对付这种情况的办法:使用 T C P的时间戳选项的 PAW S(Protection Against Wrapped Sequence numbers)算法(保护回绕的序号)。

4 . 4 B S D包含了我们将要在下面介绍的所有选项和算法:窗口扩大选项、时间戳选项和保护回绕的序号。许多供应商也正在开始支持这些选项。

千兆比网络 当网络的速率达到千兆比的时候,情况就会发生变化。 [Partridge 1994]详细介绍了千兆比网络。在这里我们看一下在时延和带宽之间的差别 [Kleinrock 1992]。

考虑通过美国发送一个 1 0 0万字节的文件的情况,假定时延为 30 ms。图2 4 - 6显示了两种情况:上图显示了使用一个 T 1电话线(1 544 000 b/s)的情况,而下图则是使用一个 1 Gb/s网络的情况。x轴显示的是时间,发送方在图的左侧,而接收方则在图的右侧, y轴为网络容量。

两幅图中的阴影区域表示发送的 1 0 0万字节。

在这里插入图片描述
在这里插入图片描述

图2 4 - 6显示了30 ms后这两个网络的状态。经过 30 ms(延时)以后数据的第1个比特都已到达对端。但对T 1网络而言,由于管道容量仅为 5 790字节,因此发送方仍然有 994 210个字节等待发送。而千兆比网络的容量则为 3 750 000字节,因此,整个文件仅使用了 2 5%左右的带宽,此时文件的最后一个比特已经到达第 1个字节后8 ms处。

经过T 1网络传输文件的总时间为5 . 2 11秒。如果增加更多的带宽,使用一个T 3网络(45 000 000 b/s),则总时间减少到0 . 2 0 8秒。增加约2 9倍的带宽可以将总时间减小到约2 5分之一。

使用千兆比网络传输文件的总时间为0 . 0 3 8秒:30 ms的时延加上8 ms的真正传输文件的时间。假定能够将带宽增加为 2000 Mb/s,我们只能够将总时间减小为 0.304 ms:同样30 ms的时延和4 m s的真正传输时间。现在使带宽加倍仅能够将时间减少约 1 0%。在千兆比速率下,时延限制占据了主要地位,而带宽不再成为限制。

时延主要是由光速引起的,而且不能够被减小(除非爱因斯坦是错误的)。当我们考虑到分组需要建立和终止一个连接时,这个固定时延起的作用就更糟糕了。千兆比网络会引起一些需要不同看待的连网观点。

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2020-03-12 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 第24章 TCP的未来和性能
    • 24.3 长肥管道
    领券
    问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档