Video在线视频

类似数据链路层

TCP数据传输

采用了基本的肯定确认

重传机制

TCP是以数据段的形式

传输数据的

一个数据段

包含很多个字节

相当于批量传输

为避免大量数据淹没接收方

采用流控技术

利用的是段头中的一个字段

叫窗口尺寸

window size

下面我们用这个例子来看一下

怎么采用window size这个字段

来进行流控的

左边是sender发送方

右边是receiver接收方

现在接收方

它有一个4K大小的缓存

是空的

sender发送了一个2K的数据

过来

在这个2K的数据里边

它的Sequence Number

是等于0的

所以我们知道

这个2K的字节

它的编号是从0 1 2 3

一直到2047

那么这个数据

到达receiver之后呢

receiver的内存

就被占据了一半

还剩下2K

所以这个接收方

它会回发一个确认

在这个确认里边

它的ACK number等于2048

就表明说2047 2046等等

之前的那些字节

它已经收到了

下一次呢

发送方可以从2048

编号的那个字节开始发送

同时注意看

它的window size值

是等于2048

等于2K的

这个值就是告诉发送方说

我现在只有2K的空间

你只能发2K

或者小于2K的数据过来

当sender收到这个确认之后

他果然就发了2K的数据过来

在这2K的数据里边

Sequence Number

是等于2048的

这个2K的数据

一旦到达接收方

接收方的缓存

全部被充满

也就是说

它没有更多的空间

来接收新的数据了

所以这个时候

接收方发出去的确认

它的window size等于0

其实就是告诉对方说

对不起

我不能收新数据了

请你稍等

在这个window size等于0的

确认里面

它的ACK等于4096

表明说4095 4094等等之前

那些编号的字节

已经正确的收到了

过一段时间

接收方

它对缓存里面的数据

进行了处理

空出了2K的空间

这个时候

它可以接收2K的数据了

所以它马上发送了一个

更新窗口

在这个更新窗口数据段里面

window size等于2048

也就是说等于2K

告诉对方说

你现在可以发数据了

发数据呢

可以发2K

2K之内都可以发

同时你也会观察到

在这个更新窗口

这个数据段里面

ACK number是等于4096的

跟刚才window size等于0的

那个数据段里面的ACK number

是一样的

就是说它其实没有收到新的数据

当这个更新窗口

到达发送方的时候

发送方就发送了一个数据

这个数据我们看到

是1K

1K是小于2K的

所以这是允许的

它的Sequence Number

等于4096

正是对方要求我发过去的

那个字节的编号

这个过程呢

就是采用window size这个字段

来进行流控的过程

在这个图解里边

我们看到明确的sender

receiver

实际上呢

TCP传输是双工的

sender receiver是可以交换的

它们可以互为收发方

当窗口数位于0的时候

发送方

不能够正常的发送数据段

除非有紧急数据

比如说用户想杀掉远端

机器上的进程的时候

就可以发送紧急数据

发送者

可以发送一个字节的数据段

以便让接收者

再次发送期待接收的字节号

和窗口数

避免死锁

这种情形呢

我们稍候再讲一个例子

实际上呢

发送者

不需要马上发送应用程序

产生的数据

接收者

也不需要马上发送应答

为什么呢

你可能使用过Telnet

它是一个远程交互式工具

远程编辑器对用户的

每一次击键

都会做出响应

我们来看一下最坏的情况

当用户敲入一个字符的时候

被送到传输实体

创建一个21字节的数据段

再传到网络层

变成了41个字节的IP分组

接收方收到这个信息之后

会立刻发回一个

40个字节长的确认分组

它包括20个字节的TCP段头

和20个字节的IP头

随后当编辑器读取出这个字节

TCP实体

发回一个窗口更新

这个分组也是40个字节

最后当编辑器

处理完了这个字符

它发送一个41字节的分组

作为该字符的回显

可见

对于每个敲入的字符

需要至少162个字节

还没有考虑数据链路层的开销

总共发出了四个数据段

我们其实是可以优化接收端的

比如说接收端

不要那么着急发送确认分组

和窗口更新

而是延迟一个时间

以便可以免费搭载到一个

处理后的回显分组之中

也就是说

搭一个便车

也可以优化发送端

采用Nagle的算法

当数据以一次一字节的速度

到达传输实体的时候

只发送第一个字节

然后将后续的字节缓存起来

直到发出的字节

得到确认

将缓存起来的字节

在一个数据段中发出

再继续缓存

直到发出的数据得到确认

Nagle的算法

在很多TCP上都有实现

但是有些时候最好禁用

比如当一个X—window的应用

通过互联网远程运行的时候

鼠标的移动事件

必须发送给远程计算机

把这些移动事件累积起来

一批一批地发送出去

将使得鼠标的移动极不连贯

另一个使TCP性能退化的问题

是傻瓜窗口综合症

当有大块数据被传递给发送端

TCP实体

但接收端的交互式应用

每次只读取一个字节的时候

问题就来了

在这个图中

左边是发方

右边是收方

我们注意观察收方

它的缓存现在已经满了

所以它不得不发一个window size

等于0的确认分组给对方

告诉它停止发送 等待

当它处理一个字节的时候

就缓存里面空出了一个字节

这个时候它非常着急地

就把这个更新窗口

window size等于1发出去了

window size等于1到达发送者

发送者也急急忙忙的

发送了一个字节过来

很快就把它的一个字节的缓存

再次充满

充满了之后

接收方

现在只能够发window size

等于0的确认回去了

那么发送方

又只有继续等待

当它处理好了一个字节的空间

出来之后

它又发了一个更新窗口

window size等于1

那么发送方

再发一个字节来

又把它的缓存充满了

那么这个状况

一直这样

让接收方的缓存

一个字节 一个字节的

充满 释放 充满 释放

那么要解决

这个傻瓜窗口综合症的问题

可以用Clark的解决方案

Clark的解决方案是这样的

它主旨接收方

发送只有一个字节的窗口更新

相反

它必须等待一段时间

当有了一定数量的空间之后

也就是说它处理完了

把这个缓存的空间

累积到一定的量之后

再向发送方

去发出这个窗口更新

接收方可以维护一个内部缓存

并且主旨上层应用的read请求

直到它有大块的数据提供

Clark的解决方案

治愈了傻瓜窗口综合症

它的工作情形是这样的

左边是发送方

右边是接收方

我们先看右边

它的缓存

现在是满掉的

红色的是满掉的

所以它只能发一个

window size等于0

告诉对方说请稍等

接着下来

它就开始处理这些数据

把缓存弹了一个单位出来

再弹一个单位出来

它不着急发更新窗口

一直到它累积到了一定的量

比如说等于6个单位的时候

它才发更新窗口过去

那么发送方

这个时候就可以批量地发数据

过来了

就把刚才描述的那种

一个字节 一个字节地

填满 空闲 填满 空闲的这个症状

完全地解决掉了

所以其实发方和收方

都要做优化

发方我们做的优化

就采用Nagle的算法

尽量不发送数据含量小的数据段

还有缓存

应用层的数据

到达一定量之后再发

而接收方呢

采用Clark的解决方案

他不请求对方发送短数据段

也就是说

它的window size的值

尽量地不要太小

它延迟窗口更新的信息

直到缓冲区

变得足够的大

小结一下今天的内容

TCP数据段的传输

是全双工的

而且它传输的是字节流

TCP适配

收发双方的数据流量的方法是

采用window size这个字段

TCP还需要效率

它的发方

可以用Nagle的算法

来进行优化

而收方呢

可以用Clark的解决方案

来进行优化