diff --git a/README.md b/README.md index f5705a72..05caa00e 100644 --- a/README.md +++ b/README.md @@ -4,6 +4,7 @@ > 关于笔记记录的说明：我觉得笔记记录的内容过于细节。所有的知识应该以书上为准。整理笔记的目的应该是作为一种快速参考或者索引，而不是详细的记录所有的细节。说实话，我觉得你的笔记废话太多，自己都不一定会看。 > 我觉得是时间放弃你愚蠢的笔记策略了。 +> 从今以后，必须跟上自己的笔记进度和作业进度。不能就学两科还跟不上进度，太傻逼了。 ## 1 分类标题（用来描述主题的各个方面或者分类） diff --git a/概率论与数理统计/第16节 一元线性回归.md b/概率论与数理统计/第16节 一元线性回归.md index e69de29b..67dd5d0a 100644 --- a/概率论与数理统计/第16节 一元线性回归.md +++ b/概率论与数理统计/第16节 一元线性回归.md @@ -0,0 +1,55 @@ +# 一元线性回归 + +## 回归分析理解 + +### 变量关系 + +* 确定性关系：可用函数来描述。 +* 非确定性关系：不能用函数来描述。 + + +### 回归分析 + +* 回归模型：变量间相关关系无法用完全确定的函数关系描述，但在平均意义下，有一定的函数表示式。通过大量数据，估计函数表示式，称为回归分析。回归分析中根据观测数据建立的反映变量间相关关系的统计模型称为回归模型。 + +* 回归分析分类 + * 随机变量间的相关关系。 + * 随机变量与普通变量间的相关关系。 + +> 随机变量与普通变量的相关关系的回归分析：普通变量更像一个参数，能够决定随机分布的参数。建立的函数关系式是参数$E(Y)=\mu$与普通变量之间的关系。 + + +### 相关定义 + +响应变量和解释变量 +* 响应变量+解释变量：在随机变量与普通变量的回复分析中，随机变量是因变量，或响应变量。普通变量为自变量，或解释变量。 + +回归分析的元 +* 一元回归分析：一个响应变量+一个解释变量 +* 多元回归分析：一个响应变量+多个解释变量 +* 多元多重回复分析：多个响应变量+多个解释变量 + +回归分析的方法 +* 线性回归：线性统计模型 +* 多项式回归： +* 神经网络（常数回归？）： +* 支持箱梁节（不知道诶）： + +## 一元线性回归的数学描述 + +$E(y)=\mu(x)$的理解。 + +随机变量 +* E(y):随机变量的数据特征。是随机变量的在某一个性质上投影。 +* $\mu(x)$:这个性质投影，能够消除随机变量的随机性，反映一种基本性质。这个性质投影，与某个普通变量存在一定的关系。 + +* 这与之前的随机变量的参数估计相似。一个随机变量有一个未知参数——数学期望。利用样本数据求出这种关系。 + +回归分析 +* 求函数表达式$E(y)=\mu(x)$的估计是回归分析的基本内容。$\mu(x)$为y对x的理论回归函数，而基于数据对$\mu(x)$估计称为y对x的经验回归函数。 + + +## 未知参数的估计及其统计性质 + + +## 回归的显著性检验与回归系数的置信区间 diff --git a/概率论与数理统计/第17节 多元线性回归.md b/概率论与数理统计/第17节 多元线性回归.md new file mode 100644 index 00000000..e69de29b diff --git a/计算机网络/3.5 传输层-TCP可靠数据传输.md b/计算机网络/3.5 传输层-TCP可靠数据传输.md index bda84845..7fc7bb1a 100644 --- a/计算机网络/3.5 传输层-TCP可靠数据传输.md +++ b/计算机网络/3.5 传输层-TCP可靠数据传输.md @@ -1,34 +1,57 @@ -# TCP可靠数据传输 +# TCP数据传输 ## 1 概述 -TCP提供了可靠的传输服务，这是通过下列方式提供的： -* 应用数据被分割成TCP认为最适合发送的数据块。由TCP传递给IP的信息单位称为报文段或段（segment） -* 当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。 -* 当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒 -* TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）。 -* 由于IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。如果必要，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。 -* IP数据报会发生重复，TCP的接收端必须丢弃重复的数据。 -* TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。 +### 主要内容 + +tcp数据传输主要包括以下几个方面 +* 可靠数据传输（保证数据传输的正确性） + * 面向连接 + * 序号机制（保证数据顺序） + * 校验和（防止数据出错） + * 确认机制（应对丢包） + * 超时重传（应对丢包、丢失确认） + * 累计确认（发送方动作，发送方认为之前全被正确接收） + * 选择重传（接受方动作，接收方维持滑动串口，只要求重传丢失的分组） +* 流量控制（提高传输效率的流水线方法，考虑接收端的接受能力，发送方的发送速率不应该超过接收端的接受能力） + * 滑动窗口（对应缓冲区大小，双向缓冲窗口流水线技术） +* 拥塞控制（通过流量控制实现，考虑断点之间的网络情况，目的使负载不超过网络的传输能力。） + * 慢启动 + * 拥塞避免 + * 快重传 + * 快恢复 + +> * 在接收方实现了流量控制 +> * 在发送方实现了拥塞控制 -## 2 TCP主要任务 +### TCP主要任务 当TCP连接建立之后，应用程序即可使用该连接进行数据收发。应用程序将数据提交给TCP，TCP将数据放入自己的缓存，并且在其认为合适的时候将数据发送出去。在TCP中，数据会被当做字节流并按照MSS的大小进行分段，然后加上TCP头部并提交给网络层。之后数据就会被网络层提交给目地主机，目地主机的IP层会将分组提交给TCP，TCP根据报文段的头部信息找到相应的socket，并将报文段提交给该socket，socket是和应用关联的，也就提交给了应用。 -## 3 TCP可靠传输 -IP提供的服务是尽力交付的服务，也是不可靠的服务。但是TCP在IP之上提供了可靠度传输服务。TCP采用了流水线下的可靠数据传输协议，但是在差错恢复时，并没有简单的采取GBN协议或者选择重传协议，而是将二者结合了起来。 +### 相关概念 -TCP采用了累积确认的方式，这类似于GBN，即如果TCP发送了对某个序号N的确认，则表明在N之前的所有字节流都已经被正确接收。但是另一方面，TCP又不会像GBN协议那样简单丢弃失序到达的报文段，而是会将它们缓存起来，但是这些被缓存的报文段不会逐个被确认。当发生超时时，TCP只会重传发生超时的那一个报文段。 +* 字节流：编了序号的字节串 -TCP还允许接收方选择性的确认失序到达的分组，而不是累积的对最后一个确认最后一个正确到达的分组，将它与TCP所采取的选择重传结合起来看就很想选择重传协议的工作机制。因此说TCP的差错恢复结合了GBN和选择重传。 +## 2 TCP可靠传输 -选择重传中每个报文段都有自己的超时值，TCP采用了RFC2988建议的机制用一个单一定时器来完成该功能。RFC2988定义的原则： -* 发送TCP分段时，如果还没有重传定时器开启，那么开启它。 -* 发送TCP分段时，如果已经有重传定时器开启，不再开启它。 -* 收到一个非冗余ACK时，如果有数据在传输中，重新开启重传定时器。 -* 收到一个非冗余ACK时，如果没有数据在传输中，则关闭重传定时器。 +> 这一部分主要介绍了TCP实现可靠数据传输的基本原理。包括校验和、序号机制、确认机制、超时重传、流水线技术（滑动窗口）、累计确认、选择重传等。 +### 可靠保证 +TCP提供了可靠的传输服务，这是通过下列方式提供的： + +* **校验和**TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）。 +* **序号机制**由于IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。如果必要，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。IP数据报会发生重复，TCP的接收端必须丢弃重复的数据。 +* **确认机制和超时重传**：应用数据被分割成TCP认为最适合发送的数据块。由TCP传递给IP的信息单位称为报文段或段（segment）当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。 + +### GBN协议与选择重传结合——流水线技术 +* **流水线技术**IP提供的服务是尽力交付的服务，也是不可靠的服务。但是TCP在IP之上提供了可靠度传输服务。TCP采用了流水线下的可靠数据传输协议，但是在差错恢复时，并没有简单的采取GBN协议或者选择重传协议，而是将二者结合了起来。 + + TCP采用了累积确认-选择重传的方式 + +* **累计确认**：这类似于GBN，即如果TCP发送了对某个序号N的确认，则表明在N之前的所有字节流都已经被正确接收。但是另一方面，TCP又不会像GBN协议那样简单丢弃失序到达的报文段，而是会将它们缓存起来，但是这些被缓存的报文段不会逐个被确认。 + +* **选择重传**TCP还允许接收方选择性的确认失序到达的分组，当发生超时时，TCP只会重传发生超时的那一个报文段。而不是所有的没有确认的报文段。 ### 基本工作过程 @@ -54,7 +77,19 @@ TCP还允许接收方选择性的确认失序到达的分组，而不是累积 如果收到的报文段的序号等于rcv_base，并且有延迟的ACK待发送，则更新rcv_base，并发送累积的ACK以确认这两个按序报文段 如果收到的报文段的序号大于rcv_base，则发送冗余的ACK，即重传对已经确认过的最后一个按序到达的报文段的ACK + +## 3 超时重传机制 +### 发送端超时重传机制 + +选择重传中每个报文段都有自己的超时值，TCP采用了RFC2988建议的机制用一个单一定时器来完成该功能。RFC2988定义的原则： +* 发送TCP分段时，如果还没有重传定时器开启，那么开启它。 +* 发送TCP分段时，如果已经有重传定时器开启，不再开启它。 +* 收到一个非冗余ACK时，如果有数据在传输中，重新开启重传定时器。 +* 收到一个非冗余ACK时，如果没有数据在传输中，则关闭重传定时器。 + + ### 往返时延的估算与超时 + TCP协议定义了RTT来代表一个TCP分段的往返时间。然而由于IP网络是尽力而为的，并且路由是动态的，且路由器可能缓存或者丢弃IP数据报，因此一个TCP连接的RTT是动态变化的，因而也需要动态测量。样本RTT(SampleRTT)是报文段被发出到报文段的确认被收到的时间间隔。TCP不会为每一个发动的报文段测量一个SampleRTT，而是仅为已发送但是未被确认的分组测量SampleRTT。这样做是为了产生一个近似于RTT的SampleRTT。TCP不会为重传的报文段测量SampleRTT。 得到多个SampleRTT后，TCP会尝试使用这些信息来尽可能得到一个较为准确的RTT，为此TCP采用了经常被采用的收到即使用一个滤波器来对多个SampleRTT进行计算。TCP使用如下的滤波器来计算一个EstimateRTT： @@ -75,38 +110,55 @@ $$ ### 倍数增加的重传间隔 -在发生超时重传时，TCP不是以固定的时间间隔来重传的，而是会再每次重传时都将下一次重传的间隔设置为上次重传间隔的2倍，因此重传间隔是倍数增加的。直到收到确认或者彻底失败。由于正常发送报文段时，重传定时器的超时值为EstimateRTT + 4 * DevRTT，因此第一重传时会将下一次的超时时间设置为2倍的该值，依次类推。 +在发生超时重传时，TCP不是以固定的时间间隔来重传的，而是每次重传时都将下一次重传的间隔设置为上次重传间隔的2倍，因此重传间隔是倍数增加的。直到收到确认或者彻底失败。由于正常发送报文段时，重传定时器的超时值为EstimateRTT + 4 * DevRTT，因此第一重传时会将下一次的超时时间设置为2倍的该值，依次类推。 ### 快速重传 倍数增加的重传间隔会增大端到端的时延，使得发送端可能不得不等待很长时间才能重传报文段。冗余ACK使得TCP可以得到分组丢失的线索。TCP基于冗余ACK提供了一种快速重传机制。其原理是：如果收到了对相同数据的三个冗余的ACK，发送端就认为跟在这个被确认了三次的报文段之后的报文段丢失了，因此重传它，而不是等待它的超时定时器到期。这就是快速重传。 -### 流量控制 +## 4 流量控制 + +### 流量控制的原因 在TCP中，连接双都为该连接设置了接收缓存，当报文段被连接的一端接收时，它会进入该接收缓存，被接收的数据并不一定立即被提交给应用程序。因为应用可能由于各种而没能及时读取缓存中的数据。如果发送方发送的数据太快，而应用没有及时读取被缓存的数据，缓存就会变满，此时为了防止缓存溢出，就要丢弃报文段，显然丢弃已经正确接收的报文段是对网络资源的浪费。为了解决该问题，TCP需要提供一种机制来防止接收缓存溢出。 -TCP提供了流量控制功能，来防止发送方发送过快而导致接收方缓存溢出的情形出现。这是通过让接收方通告一个接收窗口大小来实现的。接收窗口的大小包含在TCP头部的窗口大小字段中。其工作原理为： +### 流量控制的方法 -接收方通过窗口大小通告本地可以接收的报文段的总大小。发送方将根据该信息来判断自己可以发送多少数据。发送方保证自己发送的未被确认的报文段的总大小不超过接收方通告的窗口大小。对应到我们所描述的GBN和选择重传协议中，就是发送方会用接收方通告的窗口大小更新本地的窗口大小N的值。一个可视化的描述如下图： +TCP提供了流量控制功能，来防止发送方发送过快而导致接收方缓存溢出的情形出现。TCP采用**大小可变的滑动窗口**进行流量控制： + +* 接受端根据自己的接受缓存大小，随时动态调整发送端的发送窗口的上限值。接收端窗口rwnd，被放在TCP报文段首部的窗口字段当中。 +* 发送端根据其对网络拥塞程度的估计确定窗口值，叫做拥塞窗口cwnd。 +$$ +发送窗口的上限值=Min[cwnd,rwnd] +$$ + +* 发送端的窗口大小通告的可视化的描述如下图： ![](image/TCP流量控制.png) -但是TCP连接的一端可能通告一个大小为0的窗口，这时候接收到对端通告大小为0的窗口的一端并不会停止发送，而是会启动一个定时器来发送窗口探测报文段，该报文段只包含一个字节，该报文段会被接收方确认，该定时器会一直重启自身来发送窗口探测包直到对端通告了一个大小不为0的窗口为止。定时器的超时值会逐渐增大到一个最大值，然后固定以该值重发窗口探测包。 +* 窗口边沿移动规律如下： + * 当窗口的左边沿向右移动时，称为窗口合拢。此时，数据被发送并被确认。 + * 当左边沿与右边沿重合时，称为零窗口，发送端不发送任何有效数据。 + * 当窗口右边沿向右移动时将允许发送更多数据，称为窗口张开，此时接收端已经确认了数据，并释放了TCP的接受缓存。 + * 当右边沿向左移动时，称为窗口收缩，一半不会发生，但应该能够处理这种情况。 +* 但TCP连接的一端可能通告一个大小为0的窗口，这时候接收到对端通告大小为0的窗口的一端并不会停止发送，而是会启动一个定时器来发送窗口探测报文段，该报文段只包含一个字节，该报文段会被接收方确认，该定时器会一直重启自身来发送窗口探测包直到对端通告了一个大小不为0的窗口为止。定时器的超时值会逐渐增大到一个最大值，然后固定以该值重发窗口探测包。 -## 4 SWS(糊涂窗口综合症) +## 5 SWS(糊涂窗口综合症) 糊涂窗口综合症是指在发送端应用进程产生数据很慢、或接收端应用进程处理接收缓冲区数据很慢，或二者都存在时，通过TCP连接传输的报文段会很小，这会导致有效载荷很小。极端情况下，有效载荷可能只有1个字节；而传输开销有40字节(20字节的IP头+20字节的TCP头) 这种现象就叫糊涂窗口综合症。 ### 发送端引起的SWS -如果TCP发送端的应用是产生数据很慢的应用程序(比如telnet)，它可能一次只产生一个字节。这种应用程序一次只往TCP提交一个字节的数据，如果没有特殊的处理，这就会导致TCP每次都产生一个只有一个有效载荷的报文段。最终导致网络的有效利用率非常低。解决办法是防止TCP发送过小的报文段，如果应用提交的数据较短，就等待足够的数据来组成一个较大的报文段再发送，为了防止长时间等待导致时延过大，可以加入一个等待时间限制，如果时间到期还没等到足够的数据就直接发送不再等待。Nagle算法就是这样的一种算法。 +如果TCP发送端的应用是产生数据很慢的应用程序(比如telnet)，它可能一次只产生一个字节。这种应用程序一次只往TCP提交一个字节的数据，如果没有特殊的处理，这就会导致TCP每次都产生一个只有一个有效载荷的报文段。最终导致网络的有效利用率非常低。解决办法是防止TCP发送过小的报文段，如果应用提交的数据较短，就等待足够的数据来组成一个较大的报文段再发送，为了防止长时间等待导致时延过大，可以加入一个等待时间限制，如果时间到期还没等到足够的数据就直接发送不再等待。 +* Nagle算法就是这样的一种算法。 +* CORK选项是为了提高利用率。 ### 接收端引起的SWS 如果TCP接收端的应用处理数据的速度很慢，一次只从TCP缓存取走很小数量的数据，比如一个字节，而发送方发送的速度较快，这就会导致接收方的缓存被填满，然后接收方每次在应用取走一个字节的数据后都通告一个大小为1的窗口，这就限制发送方每次只能发送包含一个字节的有效载荷的报文段。 对于这种糊涂窗口综合症，即应用程序消耗数据比到达的慢，有两种建议的解决方法： -Clark解决方法 Clark解决方法是只要有数据到达就发送确认，但通告的窗口大小为零，这个过程持续到缓存空间已能放入具有最大长度的报文段或者缓存空间的一半已经空了。 -延迟确认 第二个解决方法是延迟一段时间后再发送确认。这时接收方不立即确认收到的报文段。接收方在确认收到的报文段之前一直等待，直到入缓存有足够的空间为止。该方法阻止了发送端滑动其窗口，当发送端发送完其数据后，它就停下来了。这样就防止了这种症状。延迟的确认还减少了通信量。接收端不需要确认每一个报文段。但它有可能使发送端重传其未被确认的报文段。可以给延迟的确认加一个时间限制来降低该方法缺点的影响。 +* Clark解决方法 Clark解决方法是只要有数据到达就发送确认，但通告的窗口大小为零，这个过程持续到缓存空间已能放入具有最大长度的报文段或者缓存空间的一半已经空了。 +* 延迟确认 第二个解决方法是延迟一段时间后再发送确认。这时接收方不立即确认收到的报文段。接收方在确认收到的报文段之前一直等待，直到入缓存有足够的空间为止。该方法阻止了发送端滑动其窗口，当发送端发送完其数据后，它就停下来了。这样就防止了这种症状。延迟的确认还减少了通信量。接收端不需要确认每一个报文段。但它有可能使发送端重传其未被确认的报文段。可以给延迟的确认加一个时间限制来降低该方法缺点的影响。 ### Nagle算法 @@ -115,7 +167,7 @@ Nagle算法的核心思想是任意时刻，最多只能有一个未被确认的 * 如果该包含有FIN，则允许发送； * 设置了TCP_NODELAY选项，则允许发送； * 未设置TCP_CORK选项时，若所有发出去的小数据包（包长度小于MSS）均被确认，则允许发送； -上述条件都未满足，但发生了超时（一般为200ms），则立即发送。 +* 上述条件都未满足，但发生了超时（一般为200ms），则立即发送。 Nagle算法在任意时刻只允许存在一个未被确认的报文段，但他它并不关心报文段的大小，因此它事实上就是一个扩展的停止等待协议，只不过它是基于报文段的而不是基于字节的。Nagle算法完全由TCP协议的ACK机制决定，因此也有一些缺点，比如如果对端ACK回复很快的话，Nagle事实上不会拼接太多的数据包，虽然避免了网络拥塞，网络总体的利用率依然很低。 @@ -132,9 +184,9 @@ Nagle算法和CORK算法非常类似，但是它们也有区别： 用户通过TCP_NODELAY来启用或禁用Nagle算法而通过TCP_CORK来启用或禁用CORK算法。 -Nagle算法关心的是网络拥塞问题，只要有ACK回来则发包，而CORK算法关心的是报文段大小，在前后数据发送间隔很短的前提下，即使你是分散发送多个小数据包，你也可以通过使能CORK算法将这些内容拼接在一个包内，如果此时用Nagle算法的话，则可能做不到这一点。 +Nagle算法关心的是网络拥塞问题，只要有ACK回来则发包；而CORK算法关心的是报文段大小，在前后数据发送间隔很短的前提下，即使你是分散发送多个小数据包，你也可以通过使能CORK算法将这些内容拼接在一个包内，如果此时用Nagle算法的话，则可能做不到这一点。 -## 5 紧急方式 +## 6 紧急方式 TCP提供了“紧急方式(urgentmode)”，它使连接的一端可以告诉另连接的一端有些 “紧急数据”已经被放置在数据流中。紧急数据的处理方式由接收方决定。 diff --git a/计算机网络/3.6 传输层-TCP拥塞控制.md b/计算机网络/3.6 传输层-TCP拥塞控制.md index 957a0521..478831f4 100644 --- a/计算机网络/3.6 传输层-TCP拥塞控制.md +++ b/计算机网络/3.6 传输层-TCP拥塞控制.md @@ -17,6 +17,13 @@ TCP让连接双方根据自己所判断的网络拥塞的程度来限制其发 TCP通过ACK到达的情况（即是否到达，到达的速率）来调整拥塞窗口的大小。 +### 主要技术 + +* 慢启动 +* 拥塞避免 +* 快重传 +* 快恢复 + ## 2 慢启动 在建立TCP连接时，拥塞窗口被初始化为 min (4*SMSS, max (2*SMSS, 4380 bytes)) 。但是TCP不是以线性的方式增大拥塞窗口，而是以指数的方式增加的，即： * 初始设置cwnd=1个 min (4*SMSS, max (2*SMSS, 4380 bytes)) ，发送一个报文，在RFC5861中有更新，但是总体就是一个较小的值（SMSS：SENDER MAXIMUM SEGMENT SIZE : The SMSS is the size of the largest segment that the sender can transmit）。(对于SCTP，cwnd初始值为min(4*MTU)。 @@ -43,7 +50,7 @@ TCP通过ACK到达的情况（即是否到达，到达的速率）来调整拥 因此TCP的拥塞控制方式又称为加性增，乘性减。拥塞窗口的增加受惠的只是自己，而拥塞窗口减少受益的是大家，当出现拥塞时，通过乘性减虽然损害了自己，但是可以让更多的其它网络参与者受益，这也证实TCP拥塞控制中的公平性的核心所在。 -## 4 对超时事件的处理 +## 4 快重传（超时处理） 虽然超时和收到三个冗余ACK（SCTP中不存在三个冗余ACK，对应的事件是三个SACK都不包含都某个报文段的确认，则认为该报文段丢失需要重传）都被认为是丢包事件，但是TCP在二者的处理上并不全相同。当收到三个冗余ACK时，TCP的处理就是“加性增，乘性减”。但是如果是超时事件，则TCP会更新ssthresh的值为max (FlightSize / 2, 2*SMSS)（对于SCTP，max(cwnd/2, 4*MTU)），然后进入“慢启动”过程，即将拥塞窗口设置为一个MSS，然后指数增加拥塞窗口大小。此时“慢启动”会持续到遇到一个丢包事件或者拥塞窗口被增大到了ssthresh，如果是增大到了ssthresh则进入“拥塞避免”的模式，即开始加性增。 diff --git a/计算机网络实验/4 传输层实验.md b/计算机网络实验/4 传输层实验.md new file mode 100644 index 00000000..e69de29b diff --git a/计算机网络实验/802.11无线网络.md b/计算机网络实验/802.11无线网络.md index 0ca45011..050ebc55 100644 --- a/计算机网络实验/802.11无线网络.md +++ b/计算机网络实验/802.11无线网络.md @@ -128,23 +128,40 @@ CSMA/CA 访问控制机制 虚拟载波监听功能与网络分配矢量 帧间隔 -RTS（Request To Send）请求发送 -RA：RTS用于为要传送的数据帧、管理帧或者控制帧预约信道，RA就是后续这些帧的目的地址； -TA：发送RTS的无线终端的地址； -Duration：持续时间，单位为微秒。值为传送一个管理帧或者数据帧时间加上一个CTS时间、一个ACK再加上3个SIFS。 +* 控制帧的类型 + +|Subtype Value|Subtype Description| +|-|-| +|0000-0110 |Reseved| +|1000 |Block Ack Reques| +|1001 |Block Ack| +|1010 |PS-Poll| +|1011 |RTS| +|1100 |CTS| +|1101 |ACK| -CTS（Clear To Send）允许发送 -RA：直接拷贝自对应RTS中的TA； -Duration：拷贝自对应的RTS中的Duration值，但要减去传输此CTS帧的时间，并再减去一个SIFS。 +* RTS（Request To Send）请求发送 + + * RA：RTS用于为要传送的数据帧、管理帧或者控制帧预约信道，RA就是后续这些帧的目的地址； + * TA：发送RTS的无线终端的地址； + * Duration：持续时间，单位为微秒。值为传送一个管理帧或者数据帧时间加上一个CTS时间、一个ACK再加上3个SIFS。 -ACK -RA：拷贝自所要确认的帧的Address 2字段； -Duration： -如果Frame Control中More Fragment为0，那么Duration为0； -否则将拷贝自所要确认的帧中的Duration值，并减去传输此ACK所需时间，再减去一个SIFS。 +* CTS（Clear To Send）允许发送 + * RA：直接拷贝自对应RTS中的TA； + * Duration：拷贝自对应的RTS中的Duration值，但要减去传输此CTS帧的时间，并再减去一个SIFS。 + +* ACK + * RA：拷贝自所要确认的帧的Address 2字段； + * Duration：如果Frame Control中More Fragment为0，那么Duration为0；否则将拷贝自所要确认的帧中的Duration值，并减去传输此ACK所需时间，再减去一个SIFS。 + +* PS-Poll(Power Save模式) + * 无线接入点为处于PS模式的无线终端缓存数据帧。无线终端唤醒后，通过PS-Poll帧来通知无线接入点把缓存帧发送过来。 + * BSSID：包含连接无线终端的无线接入点所在的服务集标识 + * TA：传输该帧的无线终端地址 + * AID：该无线终端和无线服务器端关联时指定的关联代码。 ## 3 802.11与以太网帧转换 ### 802.11帧封装 diff --git a/计算机网络实验/image/无线网ipv6.png b/计算机网络实验/image/无线网ipv6.png new file mode 100644 index 00000000..6f0f892e Binary files /dev/null and b/计算机网络实验/image/无线网ipv6.png differ