This commit is contained in:
estomm
2019-11-19 12:26:13 +08:00
parent 0f5ac425ac
commit 04e4d07f5c
4 changed files with 98 additions and 7 deletions

View File

@@ -0,0 +1,25 @@
状态转移方程
$$
f[n][m]=max\{f[n-1][m-k]+pmf[n][k],0<k<m\}
$$
$$
f[n][m]=\begin{cases}
pmf[1][m] & n=1 \\
max\{f[n-1][m-k]+pmf[n][k]\} & n>1,0<k<m
\end{cases}
$$
$$
f[i][j]=\begin{cases}
f[i][j]=0 & i=j \\
D[i][j]+min{f[i][k]+f[k][j]}&i\leq k<j
\end{cases}
$$
$$
\sum_{k=2}^n\sum_{i=2}^{n-k}\sum_{j=i+1}^{i-1}n*i*j=O(n^3)
$$

View File

@@ -0,0 +1,25 @@
# 方差分析
## 概述
### 定义
因素:影响实验结果的原因
水平:实验中因素所处的不同状态。
### 假设检验
$$
H_0:\mu_1=\mu_2=\mu_3
H_1:\mu不全相等
$$
多正太总体假设检验。
###
重点(考)
193 表5.1.4
201 表5.2.3
210 表5.2.8

View File

@@ -0,0 +1,6 @@
多个因素之间存在交互作用。
方差分析(最后)
正交实验(例题)

View File

@@ -122,8 +122,7 @@ $$
在TCP中连接双都为该连接设置了接收缓存当报文段被连接的一端接收时它会进入该接收缓存被接收的数据并不一定立即被提交给应用程序。因为应用可能由于各种而没能及时读取缓存中的数据。如果发送方发送的数据太快而应用没有及时读取被缓存的数据缓存就会变满此时为了防止缓存溢出就要丢弃报文段显然丢弃已经正确接收的报文段是对网络资源的浪费。为了解决该问题TCP需要提供一种机制来防止接收缓存溢出。
### 流量控制的方法
### 流量控制的机制
TCP提供了流量控制功能来防止发送方发送过快而导致接收方缓存溢出的情形出现。TCP采用**大小可变的滑动窗口**进行流量控制:
* 接受端根据自己的接受缓存大小随时动态调整发送端的发送窗口的上限值。接收端窗口rwnd被放在TCP报文段首部的窗口字段当中。
@@ -136,12 +135,48 @@ $$
![](image/TCP流量控制.png)
* 窗口边沿移动规律如下:
* 当窗口的左边沿向右移动时,称为窗口合拢。此时,数据被发送并被确认。
* 当左边沿与右边沿重合时,称为零窗口,发送端不发送任何有效数据。
* 当窗口右边沿向右移动时将允许发送更多数据称为窗口张开此时接收端已经确认了数据并释放了TCP的接受缓存。
* 当右边沿向左移动时,称为窗口收缩,一半不会发生,但应该能够处理这种情况。
* 但TCP连接的一端可能通告一个大小为0的窗口这时候接收到对端通告大小为0的窗口的一端并不会停止发送而是会启动一个定时器来发送窗口探测报文段该报文段只包含一个字节该报文段会被接收方确认该定时器会一直重启自身来发送窗口探测包直到对端通告了一个大小不为0的窗口为止。定时器的超时值会逐渐增大到一个最大值然后固定以该值重发窗口探测包。
### 窗口边沿移动规律
* 窗口合拢:
当窗口的左边沿向右移动时,称为窗口合拢。此时,数据被发送并被确认。
* 零窗口:
当左边沿与右边沿重合时,称为零窗口,发送端不发送任何有效数据。
* 窗口张开:
当窗口右边沿向右移动时将允许发送更多数据称为窗口张开。此时接收端已经确认了数据并释放了TCP的接受缓存。
* 窗口收缩:
当右边沿向左移动时,称为窗口收缩,一半不会发生,但应该能够处理这种情况。
### 窗口大小协商(报文交互)
为了获得最优的连接速率使用TCP窗口来控制流速率flow control滑动窗口就是一种主要的机制。这个窗口允许源端在给定连接传送数据分段而不用等待目标端返回ACK一句话描述窗口的大小决定在不需要对端响应acknowledgement情况下传送数据的数量。
TCP header中有一个Window Size字段它其实是指接收端的窗口即接收窗口用来告知发送端自己所能接收的数据量从而达到一部分流控的目的。其实TCP在整个发送过程中也在度量当前的网络状态目的是为了维持一个健康稳定的发送过程比如拥塞控制。因此数据是在某些机制的控制下进行传输的就是窗口机制。发送端的发送窗口是基于接收端的接收窗口来计算的。
最早TCP协议涉及用来大范围网络传输时候其实是没有超过56Kb/s的连接速度的。因此TCP包头中只保留了16bit用来标识窗口大小允许的最大缓存大小不超过64KB。为了打破这一限制RFC1323规定了TCP窗口尺寸选择是在TCP连接开始的时候三步握手的时候协商的SYN, SYN-ACK,ACK会协商一个 Window size scaling factor之后交互数据中的是Window size value所以最终的窗口大小是二者的乘积。
在相互发送的报文中,窗口大小字段,是指各自接受缓冲区窗口的大小,与发送窗口的具体大小没有关系(不需要在报文中。
### 窗口大小优化设置
TCP在传输数据时和windows size 关系密切本身窗口用来控制流量在传输数据时发送方数据超过接收方就会丢包流量控制流量控制要求数据传输双方在每次交互时声明各自的接收窗口「rwnd」大小用来表示自己最大能保存多少数据这主要是针对接收方而言的通俗点儿说就是让发送方知道接收方能吃几碗饭如果窗口衰减到零也就是发送方不能再发了那么就说明吃饱了必须消化消化如果硬撑胀漏了那就是丢包了。
TCP窗口既然那么重要那要怎么设置一个简单的原则是2倍的BDP.这里的BDP的意思是bandwidth-delay product也就是带宽和时延的乘积带宽对于网络取最差连接的带宽。为什么是2倍因为可以这么想如果滑动窗口是bandwidth*delay当发送一次数据最后一个字节刚到时对端要回ACK才能继续发送就需要等待一次单向时延的时间所以当是2倍时刚好就能在等ACK的时间继续发送数据等收到ACK时数据刚好发送完成这样就提高了效率。
### 慢启动过程窗口变化
虽然流量控制可以避免发送方过载接收方但是却无法避免过载网络这是因为接收窗口「rwnd」只反映了服务器个体的情况却无法反映网络整体的情况。
为了避免网络过载慢启动引入了拥塞窗口「cwnd」的概念用来表示发送方在得到接收方确认前最大允许传输的未经确认的数据。「cwnd」同「rwnd」相比不同的是它只是发送方的一个内部参数无需通知给接收方其初始值往往比较小然后随着数据包被接收方确认窗口成倍扩大有点类似于拳击比赛开始时不了解敌情往往是次拳试探慢慢心里有底了开始逐渐加大重拳进攻的力度。
拥塞窗口的大小以MSS最大报文段长度为单位是MSS的整数倍。
在慢启动的过程中随着「cwnd」的增加可能会出现网络过载其外在表现就是丢包一旦出现此类问题「cwnd」的大小会迅速衰减以便网络能够缓过来。
### 拥塞避免过程窗口变化
从慢启动的介绍中我们能看到发送方通过对「cwnd」大小的控制能够避免网络过载在此过程中丢包与其说是一个网络问题倒不如说是一种反馈机制通过它我们可以感知到发生了网络拥塞进而调整数据传输策略实际上这里还有一个慢启动阈值「ssthresh」的概念如果「cwnd」小于「ssthresh」那么表示在慢启动阶段如果「cwnd」大于「ssthresh」那么表示在拥塞避免阶段此时「cwnd」不再像慢启动阶段那样呈指数级整整而是趋向于线性增长以期避免网络拥塞此阶段有多种算法实现通常保持缺省即可这里就不一一说明了。
### 丢包后窗口变化
在慢启动的过程中随着「cwnd」的增加可能会出现网络过载其外在表现就是丢包一旦出现此类问题「cwnd」的大小会迅速衰减以便网络能够缓过来。
## 5 SWS(糊涂窗口综合症)