mirror of
https://github.com/Estom/notes.git
synced 2026-04-13 18:00:27 +08:00
math
This commit is contained in:
@@ -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)
|
||||
$$
|
||||
25
概率论与数理统计/第18节 方差分析单因素.md
Normal file
25
概率论与数理统计/第18节 方差分析单因素.md
Normal 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
|
||||
|
||||
6
概率论与数理统计/第19节 正交实验设计.md
Normal file
6
概率论与数理统计/第19节 正交实验设计.md
Normal file
@@ -0,0 +1,6 @@
|
||||
|
||||
多个因素之间存在交互作用。
|
||||
|
||||
|
||||
方差分析(最后)
|
||||
正交实验(例题)
|
||||
@@ -122,8 +122,7 @@ $$
|
||||
|
||||
在TCP中,连接双都为该连接设置了接收缓存,当报文段被连接的一端接收时,它会进入该接收缓存,被接收的数据并不一定立即被提交给应用程序。因为应用可能由于各种而没能及时读取缓存中的数据。如果发送方发送的数据太快,而应用没有及时读取被缓存的数据,缓存就会变满,此时为了防止缓存溢出,就要丢弃报文段,显然丢弃已经正确接收的报文段是对网络资源的浪费。为了解决该问题,TCP需要提供一种机制来防止接收缓存溢出。
|
||||
|
||||
### 流量控制的方法
|
||||
|
||||
### 流量控制的机制
|
||||
TCP提供了流量控制功能,来防止发送方发送过快而导致接收方缓存溢出的情形出现。TCP采用**大小可变的滑动窗口**进行流量控制:
|
||||
|
||||
* 接受端根据自己的接受缓存大小,随时动态调整发送端的发送窗口的上限值。接收端窗口rwnd,被放在TCP报文段首部的窗口字段当中。
|
||||
@@ -136,12 +135,48 @@ $$
|
||||
|
||||

|
||||
|
||||
* 窗口边沿移动规律如下:
|
||||
* 当窗口的左边沿向右移动时,称为窗口合拢。此时,数据被发送并被确认。
|
||||
* 当左边沿与右边沿重合时,称为零窗口,发送端不发送任何有效数据。
|
||||
* 当窗口右边沿向右移动时将允许发送更多数据,称为窗口张开,此时接收端已经确认了数据,并释放了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(糊涂窗口综合症)
|
||||
|
||||
Reference in New Issue
Block a user