TCP传输¶
TCP可靠传输的实现:
% 为方便描述,假定数据传输只在一个方向上进行，即A发送数据，B给出确认
TCP的滑动窗口是以字节为单位的.
假定A收到B发来的确认报文字段，其中窗口是20字节，而确认号是31字节
表明:B期望接收到的下一个序号是31，序号30之前的数据已经收到了
A的发送窗口的位置由B发来的确认报文中的确认号和窗口大小确定
继续:
现在假定A发送了序号为31-41的数据
从上图图中可以看出要描述一个发送窗口的状态需要三个指针P1,P2,P3
小于P1的是已发送并收到确认的部分
大于P3的是不允许发送部分
B的接收窗口大小为20
在接收窗口外面，到30号为止的数据均发送过确认并交付主机使用,因此B不再保留（之前的数据）
假设B收到了32和33的数据，却没收到31的数据（并不保证按序到达）
因此B的发送的确认号仍然是31，而不能是32或33
继续:
现假定B收到序号为31的数据并把序号为31-33的数据交付给主机,并删除这些数据
接着把接收窗口向前移动3个序号，同时给A发出确认
其窗口值仍为20，但确认号为34,表明B已经接收到序号33为止的数据
而B收到的37、38和40的数据，但没按序到达，只能先暂存在接收窗口中
A收到B的确认后，将发送窗口向前滑动3个序号，但指针P2不动
A继续发送完序号42-53的数据后，指针P2向前与P3重合
发送窗内的数据以发送完，但还没收到确认，因此必须停止发送
发送缓存用来暂时存放:
发送应用程序传送给发送方TCP准备的数据,TCP已发送但尚未收到确认的数据
发送窗口通常只是发送缓存的一部分,已被确认的数据应当从发送缓存中删除,
因此发送缓存与发送窗口的后沿是重合的
发送应用程序必须控制写入缓存的速率，不能太快，否则发送缓存就会没有存放数据的空间
接收缓存用来暂时存放:
按序到达的，但尚未被接收应用程序读取的数据、未按序到达的数据
如果收到的分组检测出有差错，则要丢弃
如果接收应用程序来不及读取收到的数据，接收缓存最终就会被填满，使接收窗口减小到0
反之,接收应用程序能够及时从接收缓存中读取收到数据,接收窗口就会变大,但最大也不能超过接收缓存的大小
超时重传机制:
TCP每发送一个报文段，就对这个报文段设置一次计时器
只要达到计时器设置的重传时间还没有收到确认，就要重传这个报文段
由于数据链路层和运输层的往返实验概率分布存在很大差异，因此有必要选择合适的超时重传时间
TCP采用了一中自适应算法来确定超时重传时间
它记录一个报文段发出的时间，以及收到相应的确认的时间
这两个时间差就是报文段的往返时间RTT
TCP保留了RTT的一个加权平均往返时间RTTs
RTTs的计算方法如下，推荐的阿尔法值为1/8:
新的RTTs = (1-a) * (旧的RTTs) +a*(新的RTTs样本)
显然超时重传时间RTO应略大于RTTs:
RTO = RTTs + 4* RTTd
% RTTd是TTT的偏差的加权平均值
选择确认SACK:
若收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据
采用选择确认的方法来传送缺少的数据，而不重传已经正确接收到的数据
用一个例子来说明（Selctive ACK）工作原理
如上图所示，接收放收到了前面的字节流不连续的两个字节块
如果这些字节的序号都在接收窗口内，那么接收方就先收下这些数据
但要把这些信息准确的告诉发送放，使发送方不要在重复发送这些已经收到的数据
TCP首部没有哪个字段能够提供上述这些字节块的边界信息
如果要使用选择确认,那么在建立TCP连接时,就要在TCP首部的选项上加上“允许SACK”的选项
TCP的流量控制与拥塞控制:
1.流量控制:
所谓的流量控制就是让发送方的发送速率不要太快，让接收方来得及接受
利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制
2.拥塞控制:
某段时间,对网络中的某资源的需求超过了该资源所能提供的可用部分,网络的性能就要变化,这种情况叫做拥塞
网络拥塞往往是由许多因素引起,简单的提高节点处理机的速度或者扩大结点缓存的存储空间并不能解决拥塞问题
问题的是指往往是整个系统的各个部分不匹配，只有各个部分平衡了,问题才会得到解决
拥塞控制和流量控制的差别:
所谓拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载
拥塞控制所要做的都有一个前提，就是网络能承受现有的网络负荷
流量控制往往指的是点对点通信量的控制，是个端到端的问题
流量控制所要做的就是控制发送端发送数据的速率，以便使接收端来得及接受
拥塞控制是很难设计的，因为它是一个动态的问题
许多情况下，甚至就是拥塞控制机制本身成为引起网络性能恶化甚至死锁的原因
RFC定义了进行拥塞控制的四种算法：慢开始、拥塞避免、快重传和快恢复