DSP器件原理与应用期末复习总结。
more >>本项目实现的是基于ZYNQ的LeNet-5手写数字识别的CNN硬件结构。
学习本教程需要先掌握卷积神经网络的基本概念。
本网络有三层卷积层,卷积核大小为5x5
完成一个卷积核对image的卷积运算,输出feature map。
一个卷积层包含多个filter,也可称为卷积核。image输入到不同的Filter,得到包含不同特征的feature map。filterSet通过选择不同的卷积核并行完成两个特征图的运算。
image是32x32的,filter是5x5的。
第一层卷积层C1,有filters长度为2400。第一层有6个卷积核,每个卷积核是5x5的,位宽是FP16,故线宽为6x5x5x16=2400。
image线宽为32x32x16=16384。
输出的feature map线宽为6x28x28x16=75264。
执行单个filter对image的卷积,输出对应的feature map(总结果)。
filter为单个卷积核线宽为5x5x16=400。
输出的feature map为28x28x16=12544
实现一次单个卷积核和image的卷积,输出对应的feature map(单次窗口卷积运算结果)
输出的feature map线宽为1x16,一次卷积是乘加,只得到一个FP16的结果。
实现一次FP16的乘加,加法器是累加器。
$$
number=(-1)^s\times(1.M)\times2^{E-15}
$$
s:符号位;E:指数位;M:尾数位
本部分内容属于计算机组成原理,可参考网上资料得到算法。
1 | `timescale 100 ns / 10 ps |
本部分内容属于计算机组成原理,可参考网上资料得到算法。
1 | `timescale 100 ns / 10 ps |
FP16转hex的在线转换器:https://evanw.github.io/float-toy/
完成FP16和FP16的乘加。代码使用串行的方式累加,而非加法树形式。因此只需每次计算出一个乘法结果,就自动累加。
1 | `timescale 100 ns / 10 ps |
完成5x5的FP16和5x5的FP16的乘加,即一个窗口的卷积。
根据上一个模块的分析,本模块只需要完成连续的5x5个FP16的乘加,输出的和即总的卷积结果。代码中使用循环变量i来依次切割相对应的image和filter做乘加。只有reset能让i置0,因此本模块的reset其实是开始信号。所花费的时钟周期为:5x5个乘加+1个输出=26(或者认为加法在乘法的下一个周期)。
要注意,image和filter都是每FP16为一个独立数据。
1 | `timescale 100 ns / 10 ps |
本模块十分重要,也比较难理解。
1、将一幅图像分成左右两部分
2、给定一个rowNumber和column(这个column就是左边部分0或者右边部分1),输出这个rowNumber的所有卷积所需的image部分(即FxFxD的大小,一个四方体) ,这个image部分是先按行排,再按depth排,再按列排。
3、输出即一个column的一行中包含的所有卷积所需的image部分。
每个column需要有(H-F+1)个rowNumber,每一个row有(W-F+1)/2个列。因此在convLayerSingle模块里
要例化(W-F+1)/2次卷积单元(第一层需14个),也即给定某行,其每一列的卷积是并行的通过截取receptiveField的部分来取出每个并行卷积所需要的image部分。
要循环rowNumber (H-F+1)次,即遍历每行,每行之间的运算是串行的。
在convLayerSingle模块,先算完一行中的两个column,再换到下一行计算。即column之间的卷积是串行的。
convLayerSingle模块完成一个filter对整幅图像的卷积
1 | `timescale 100 ns / 10 ps |
1 | `timescale 100 ns / 10 ps |
这个模块例化了2个convLayerSingle模块,实现了对两个filter核的并行卷积。
1 | `timescale 100 ns / 10 ps |
至此,一个卷积层所需的实现单元就完成了。剩下的问题就是怎么让卷积的image和filter数据对应输入并计算。
第三个卷积层后接FC层,每个核卷积只输出一个值(因为H=W=F),因此只需convLayerSingle即可(输出降了一维)。
理论可参考:
https://arxiv.org/ftp/arxiv/papers/2008/2008.02078.pdf
https://thedatabus.io/activation-function
计算一个FP32的tanh值。
1 |
|
计算一堆数的tanh值,计算是串行的。
1 | module UsingTheTanh(x,clk,Output,resetExternal,FinishedTanh); |
1 |
|
1 | module UsingTheTanh16(x,clk,Output,resetExternal,FinishedTanh); |
即out=(a+b+c+d)*0.25
1 | `timescale 1 ns / 10 ps |
例化W/2*H/2个池化单元即可。比如28x28的图像做平均池化,需要14x14个平均池化单元。
1 | `timescale 1 ns / 10 ps |
对单层平均池化打拍和输出数据的重排(并转串),从而获得正确输出。
1 | `timescale 1 ns / 10 ps |
自学计算机网络,资料来自网络。
原文出处:https://www.jianshu.com/c/f627e74e6ff3
本章做了一些内容删除。
我们在浏览器的地址中输入某个网站的域名后,就可以访问该网站的内容,这个就是万维网WWW应用,其相关的应用层协议为超文本传送协议HTTP
用户在浏览器地址栏中输入的是“见名知意”的域名,而TCP/IP的网际层使用IP地址来表示目的主机,从域名到IP地址的装转换,由属于应用层范畴的域名系统DNS,在后台帮用户完成
互联网广泛使用的动态主机配置协议 DHCP (Dynamic Host Configuration Protocol) 提供了即插即用连网 (plug-and-play networking) 的机制。
这种机制允许一台计算机加入新的网络和获取 IP 地址,而不用手工配置。
在之前,如果要正常访问Web服务器,需要该主机手动配置网络的相关配置信息
如果主机数很多,工作量就大,容易出错
如果我们给网络中添加一台DHCP服务器
DHCP 使用客户-服务器方式,采用请求/应答方式工作。
DHCP 基于 UDP 工作(DHCP报文在运输层会被封装成为UDP用户数据报),DHCP 服务器运行在 67 号端口, DHCP客户运行在 68 号端口。
DHCP客户端将广播发送DHCP发现报文(DHCP DISCOVER)
事务ID
DHCP客户端的MAC地址
封装该报文的IP数据报的源IP地址为0.0.0.0,这是因为主机目前还未分配到IP地址,因此使用该地址代替
目的IP地址为广播地址255.255.255.255,之所以广播发送,是因为主机现在并不知道网络中有哪几个DHCP服务器。它们的IP地址各是什么
DHCP服务器收到DHCP发现报文后,根据其中封装的DHCP客户端的MAC地址来查找自己的数据库,如果查到匹配信息,则使用这些配置信息来构建并发送DHCP提供报文,如果没有则采用默认配置信息来构建报文并发送
DHCP服务端将广播发送DHCP提供报文(DHCP OFFER)
事务ID:DHCP客户端会与之前DHCP发现报文的事务ID做对比,来判断该DHCP提供报文是否是自己的
配置信息:
IP地址:DHCP服务器从自己的IP地址池中挑选待租用给主机的IP地址(使用ARP来确保所选IP地址未被网络中其他主机占用)
子网掩码
地址租期
默认网关
DNS服务器
源IP地址:发送DHCP提供报文的DHCP服务器的IP
目的地址:因为目的主机还没分配到IP,所以使用广播地址
在本例中,DHCP客户会收到两个DHCP服务器发来的DHCP提供报文,DHCP客户从中选择一个,一般选择先到的,并向所选择的DHCP服务器发送DHCP请求报文
DHCP客户端将广播发送DHCP请求报文(DHCP REQUEST)
事务ID
DHCP客户端的MAC地址
接收的租约中的IP地址
提供此租约的DHCP服务器端的IP地址
源地址:0.0.0.0,因为此时DHCP客户才从多个DHCP服务器中挑选一个作为自己的DHCP服务器。它首先要征得该服务器的同意,之后才能正式使用向该DHCP服务器租用的IP地址
目的地址:广播地址,这样可以一次性向所有DHCP服务器发送DHCP请求报文,来告知它们是否请求它们作为自己的DHCP服务器
在本例中,假设DHCP客户端选择DHCP服务器1作为自己的DHCP服务器,DHCP服务器1接受该请求,于是DHCP服务器1给DHCP客户端发送DHCP确认报文
源地址:DHCP服务器1的IP地址
目的地址:广播地址
DHCP客户收到该报文后就可以使用租用的IP地址
在使用前还会进行ARP检测
![]()
剩下流程图示
下图的网络拓扑中的各主机是否可以通过DHCP来自动获取到网络配置?
使用DHCP中继代理是因为我们不用给每一个网络上都设置一个DHCP服务器,这样会使DHCP服务器的数量太多
域名相比IP地址更容易记忆
因特网是否可以只使用一台DNS服务器?
不行
名称相同的域名其等级未必相同
FTP采用C/S方式(客户/服务器方式)
FTP客户计算机可将各种类型的文件上传到FTP服务器计算机
FTP客户计算机也可以从FTP服务器计算机下载文件
根据应用需求的不同,FTP服务器可能需要一台高性能和高可靠性的服务器计算机,也可能只需要一台普通的个人计算机即可。
FTP的常见用途是在计算机之间传输文件,尤其是用于批量传输文件。
FTP的另一个常见用途是让网站设计者将构成网站内容的大量文件批量上传到他们的Web服务器。
FTP服务器监听熟知端口(端口号为 21),使客户进程能够连接上。
FTP客户随机选择一个临时端口号与其建立TCP连接,这条TCP连接用于FTP客户与服务器之间传送FTP的相关控制命令(这条连接是FTP客户与服务器之间的命令通道)
下图为建立数据通道的TCP连接
FTP服务器使用自己的熟知端口号20与其建立TCP连接,这条TCP连接用于FTP客户与服务器之间传送文件
上面例子是主动模式:建立数据通道时,FTP服务器主动连接FTP客户
下图实例为被动模式
两种模式对比
注意两种模式都是
控制连接在整个会话期间保持打开状态
数据连接传输完毕后就关闭
访问网页
怎样标志分布在整个互联网上的万维网文档?
每个万维网网点都有一个服务器进程,它不断地监听 TCP 的端口 80,以便发现是否有浏览器向它发出连接建立请求。
一旦监听到连接建立请求并建立了 TCP 连接之后,浏览器就向万维网服务器发出浏览某个页面的请求,服务器接着就返回所请求的页面作为响应。
最后,TCP 连接就被释放了。
如果该请求有缓存
如果该请求没有缓存
若Web缓存的命中率比较高
则会大大减小了该链路上的通信量,因而减少了访问因特网的时延
假设原始服务器的文档被更改,这样代理服务器的文档就不是最新的
所以原始服务器通常会为每个响应的对象设定一个修改时间字段和一个有效日期字段
若未过期
若过期并且代理服务器的文档和原始服务器的文档一致,原始服务器则给代理服务器发送不包含实体主体的响应
若过期并且代理服务器的文档和原始服务器的文档不一致,原始服务器则给代理服务器发送封装有该文档的响应报文
自学计算机网络,资料来自网络。
原文出处:https://www.jianshu.com/c/f627e74e6ff3
本章做了一些内容删除。
从通信和信息处理的角度看,运输层向它上面的应用层提供通信服务,它属于面向通信部分的最高层,同时也是用户功能中的最低层。
当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时,只有位于网络边缘部分的主机的协议栈才有运输层,而网络核心部分中的路由器在转发分组时都只用到三层(到网络层)的功能。
“逻辑通信”是指运输层之间的通信好像是沿水平方向传送数据,但事实上,这两条数据并没有一条水平方向的物理连接,要传送的数据是沿着图中上下多次的虚线方向传送的
进程Ap1与Ap4之间进行基于网络的通信,进程Ap2与Ap3之间进行基于网络的通信
在运输层使用不同的端口,来对应不同的应用进程
然后通过网络层及其下层来传输应用层报文
接收方的运输层通过不同的端口,将收到的应用层报文,交付给应用层中相应的应用进程
这里端口并不是指看得见、摸得着的物理端口,而是指用来区分不同应用进程的标识符
运输层向高层用户屏蔽了下面网络核心的细节(如网络拓扑、所采用的路由选择协议等),它使应用进程看见的就好像是在两个运输层实体之间有一条端到端的逻辑通信信道。
根据应用需求的不同,因特网的运输层为应用层提供了两种不同的运输协议,即面向连接的TCP和无连接的UDP,这两种协议就是本章要讨论的主要内容。
之前课程所介绍的计算机网络体系结构中的物理层、数据链路层以及网络层它们共同解决了将主机通过异构网络互联起来所面临的问题,实现了主机到主机的通信。但实际上在计算机网络中进行通信的真正实体是位于通信两端主机中的进程。
如何为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务,运输层协议又称为端到端协议。
运输层向高层用户屏蔽了下面网络核心的细节(如网络拓扑、所采用的路由选择协议等),它使应用进程看见的就好像是在两个运输层实体之间有一条端到端的逻辑通信信道。
根据应用需求的不同,因特网的运输层为应用层提供了两种不同的运输协议,即面向连接的TCP和无连接的UDP,这两种协议就是本章要讨论的主要内容。
端系统之间通信的含义:
运行在计算机上的进程使用进程标识符PID来标志。
因特网上的计算机并不是使用统一的操作系统,不同的操作系统(windows,Linux,Mac OS)又使用不同格式的进程标识符。
为了使运行不同操作系统的计算机的应用进程之间能够进行网络通信,就必须使用统一的方法对TCP/IP体系的应用进程进行标识。
TCP/IP体系的运输层使用端口号来区分应用层的不同应用进程。端口号使用16比特表示,取值范围0~65535;
端口号只具有本地意义,即端口号只是为了标识本计算机应用层中的各进程,在因特网中,不同计算机中的相同端口号是没有联系的。
多个进程(这里一个端口表示一个进程) 利用一个运输层协议(或者称为运输层接口)发送数据称为 复用
多个进程(这里一个端口表示一个进程) 利用一个运输层协议(或者称为运输层接口)接收时叫做 分用。
在浏览器输入域名,回车浏览
然后用户PC中的DNS客户端进程会发送一个DNS查询请求报文
DNS查询请求报文需要使用运输层的UDP协议
首部中的源端口字段的值,在短暂端口号49151~65535中挑选一个未被占用的,用来表示DNS客户端进程
首部中的目的端口字段的值:53,是DNS服务器端进程所使用的熟知端口号
之后,将UDP用户数据报封装在IP数据报中,通过以太网发送给DNS服务器
DNS服务器收到该IP数据报后,从中解封出UDP用户数据报
UDP首部中的目的端口号为53,这表明应将该UDP用户数据报的数据载荷部分,也就是DNS查询请求报文,交付给本服务器中的DNS服务器端进程
DNS服务器端进程解析DNS查询请求报文的内容,然后按其要求查找对应的IP地址
之后,会给用户PC发送DNS响应报文,DNS响应报文需要使用运输层的UDP协议封装成UDP用户数据报
其首部中的源端口字段的值设置为熟知端口号53,表明这是DNS服务器端进程所发送的UDP用户数据报,目的端口的值设置为49152,这是之前用户PC中发送DNS查询请求报文的DNS客户端进程所使用的短暂端口号
将UDP用户数据报封装在IP数据报中,通过以太网发送给用户PC
用户PC收到该数据报后,从中解封出UDP用户数据报
UDP首部中的目的端口号为49152,这表明应将该UDP用户数据报的数据载荷部分,也就是DNS响应报文,交付给用户PC中的DNS客户端进程
DNS客户端进程解析DNS响应报文的内容,就可知道自己之前所请求的Web服务器的域名对应的IP地址
现在用户PC中的HTTP客户端进程可以向Web服务器发送HTTP请求报文(和DNS发送和接收流程差不多)
UDP的通信是无连接的,不需要套接字(Socket)
TCP是面向连接的,TCP之间的通信必须要在两个套接字(Socket)之间建立连接
UDP 支持单播、多播以及广播
换句话说,UDP支持一对一,一对多,以及一对全的通信
UDP对应用进程交下来的报文既不合并也不拆分,而是保留这些报文的边界
换句话说,UDP是面向应用报文的
UDP向上层提供无连接不可靠传输服务
使用TCP协议的通信双方,在进行数据传输之前,必须使用“三报文握手”建立TCP连接
TCP连接建立成功后,通信双方之间就好像有一条可靠的通信信道,通信双方使用这条基于TCP连接的可靠信道进行通信
很显然,TCP仅支持单播,也就是一对一的通信
发送方
TCP会把应用进程交付下来的数据块看作是一连串无结构的字节流,TCP并不知道这些待传送的字节流的含义
并将他们编号,并存储在自己发送缓存中
TCP会根据发送策略,提取一定量的字节构建TCP报文并发送
接收方
一方面从所接受到的TCP报文段中,取出数据载荷部分并存储在接收缓存中;一方面将接收缓存中的一些字节交付给应用进程
TCP不保证接收方应用进程所收到的数据块与发送方发送的数据块,具有对应大小的关系(例如,发送方应用进程交给发送方的TCP共10个数据块,但接收方的TCP可能只用了4个数据块,就把收到的字节流交付给了上层的应用进程,但接收方收到的字节流必须和发送方应用进程发出的字节流完全一样)
接收方的应用进程必须有能力识别收到的字节流,把它还原成有意义的应用层数据
TCP是面向字节流的,这正是TCP实现可靠传输、流量控制、以及拥塞控制的基础
本图只画了一个方向的数据流,在实际网络中,基于TCP连接的两端,可以同时进行TCP报文段的发送和接收
TCP向上层提供面向连接的可靠传输服务
举例:https://www.bilibili.com/video/BV1c4411d7jb/?p=60
网络拥塞往往是由许多因素引起的。例如:
开环控制和闭环控制
主要指标有:
上述这些指标的上升都标志着拥塞的增长。
真正的发送窗口值 = Min (接收方窗口值,拥塞窗口值)
下图的实例横纵坐标的意思
传输轮次:
拥塞窗口:
目的:用来确定网络的负载能力或拥塞程度。
算法的思路:由小到大逐渐增大拥塞窗口数值。
两个变量:
图中swnd是发送窗口
每经过一个传输轮次,拥塞窗口就加倍
窗口大小按指数增加,2的n-1次方
思路:让拥塞窗口 cwnd 缓慢地增大,避免出现拥塞。
每经过一个传输轮次,拥塞窗口 cwnd = cwnd + 1。
使拥塞窗口 cwnd 按线性规律缓慢增长。
在拥塞避免阶段,具有 “加法增大” (Additive Increase) 的特点。
如果超时重传时间RTO的值设置得比RTT0的值小很多,这会引起报文段不必要的重传,使网络负荷增大
如果超时重传时间RTO的值设置得远大于RTT0的值,这会使重传时间推迟的太长,使网络的空闲时间增大,降低传输效率
具体过程参考视频:https://www.bilibili.com/video/BV1c4411d7jb/?p=63
“握手”需要在TCP客户端和服务器之间交换三个TCP报文段
过程
最初两端的TCP进程都处于关闭状态
一开始,TCP服务器进程首先创建传输控制块,用来存储TCP连接中的一些重要信息。例如TCP连接表、指向发送和接收缓存的指针、指向重传队列的指针,当前的发送和接收序号等
之后,就准备接受TCP客户端进程的连接请求
此时,TCP服务器进程就进入监听状态,等待TCP客户端进程的连接请求
TCP服务器进程是被动等待来自TCP客户端进程的连接请求,因此成为被动打开连接
TCP客户进程也是首先创建传输控制块
由于TCP连接建立是由TCP客户端主动发起的,因此称为主动打开连接
然后,在打算建立TCP连接时,向TCP服务器进程发送TCP连接请求报文段,并进入同步已发送状态
TCP连接请求报文段首部中
同步位SYN被设置为1,表明这是一个TCP连接请求报文段
序号字段seq被设置了一个初始值x,作为TCP客户端进程所选择的初始序号
请注意:TCP规定SYN被设置为1的报文段不能携带数据,但要消耗掉一个序号
TCP服务器进程收到TCP连接请求报文段后,如果同意建立连接,则向TCP客户进程发送TCP连接请求确认报文段,并进入同步已接收状态
TCP连接请求确认报文段首部中
同步位SYN和确认为ACK都设置为1,表明这是一个TCP连接请求确认报文段
序号字段seq被设置了一个初始值y,作为TCP服务器进程所选择的初始序号,
确认号字段ack的值被设置成了x+1,这是对TCP客户进程所选择的初始序号(seq)的确认
请注意:这个报文段也不能携带数据,因为它是SYN被设置为1的报文段,但同样要消耗掉一个序号。
TCP客户进程收到TCP连接请求确认报文段后,还要向TCP服务器进程发送一个普通的TCP确认报文段,并进入连接已连接状态
普通的TCP确认报文段首部中
确认位ACK被设置为1,表明这是一个普通的TCP确认报文段
序号字段seq被设置为x+1,这是因为TCP客户进程发送的第一个TCP报文段的序号为x,所以TCP客户进程发送的第二个报文段的序号为x+1
确认号字段ack被设置为y+1,这是对TCP服务器进程所选择的初始序号的确认
请注意:TCP规定普通的TCP确认报文段可以携带数据,但如果不携带数据,则不消耗序号
TCP服务器进程收到该确认报文段后也进入连接已建立状态
现在,TCP双方都进入了连接已建立状态,它们可以基于已建立好的TCP连接,进行可靠的数据传输
为什么TCP客户进程最后还要发送一个普通的TCP确认报文段?能否使用“两报文握手”建立连接?
下图实例是“两报文握手”
为了防止已经失效的连接请求报文段突然又传到服务端,因而产生错误”,这种情况是:一端(client)A发出去的第一个连接请求报文并没有丢失,而是因为某些未知的原因在某个网络节点上发生滞留,导致延迟到连接释放以后的某个时间才到达另一端(server)B。本来这是一个早已失效的报文段,但是B收到此失效的报文之后,会误认为是A再次发出的一个新的连接请求,于是B端就向A又发出确认报文,表示同意建立连接。如果不采用“三次握手”,那么只要B端发出确认报文就会认为新的连接已经建立了,但是A端并没有发出建立连接的请求,因此不会去向B端发送数据,B端没有收到数据就会一直等待,这样B端就会白白浪费掉很多资源。
所以并不多余,这是为了防止已失效的连接请求报文段突然又传送到了TCP服务器,因而导致错误
现在TCP客户进程和TCP服务器进程都处于连接已建立状态
TCP客户进程的应用进程通知其主动关闭TCP连接
TCP客户进程会发送TCP连接释放报文段,并进入终止等待1状态
TCP连接释放报文段首部中
终止位FIN和确认为ACK的值都被设置为1,表明这是一个TCP连接释放报文段,同时也对之前收到的报文段进行确认
序号seq字段的值设置为u,它等于TCP客户进程之前已传送过的数据的最后一个字节的序号加1
确认号ack字段的值设置为v,它等于TCP客户进程之前已收到的、数据的最后一个字节的序号加1
请注意:TCP规定终止位FIN等于1的报文段即使不携带数据,也要消耗掉一个序号
TCP服务器进程收到TCP连接释放报文段后,会发送一个普通的TCP确认报文段并进入关闭等待状态
普通的TCP确认报文段首部中
确认位ACK的值被设置为1,表明这是一个普通的TCP确认报文段
序号seq字段的值设置为v,它等于TCP服务器进程之前已传送过的数据的最后一个字节的序号加1,这也与之前收到的TCP连接释放报文段中的确认号匹配
确认号ack字段的值设置为u+1,这是对TCP连接释放报文段的确认
TCP服务器进程应该通知高层应用进程,TCP客户进程要断开与自己的TCP连接
此时,从TCP客户进程到TCP服务器进程这个方向的连接就释放了
这时的TCP连接属于半关闭状态,也就是TCP客户进程已经没有数据要发送了
但如果TCP服务器进程还有数据要发送,TCP客户进程仍要接收,也就是说从TCP服务器进程到TCP客户进程这个方向的连接并未关闭
TCP客户进程收到TCP确认报文段后就进入终止等待2状态,等待TCP服务器进程发出的TCP连接释放报文段
若使用TCP服务器进程的应用进程已经没有数据要发送了,应用进程就通知其TCP服务器进程释放连接
由于TCP连接释放是由TCP客户进程主动发起的,因此TCP服务器进程对TCP连接的释放称为被动关闭连接
TCP服务器进程发送TCP连接释放报文段并进入最后确认状态
该报文段首部中
终止位FIN和确认位ACK的值都被设置为1,表明这是一个TCP连接释放报文段,同时也对之前收到的报文段进行确认
序号seq字段的值为w,这是因为在半关闭状态下,TCP服务器进程可能又发送
确认号ack字段的值为u+1,这是对之前收到的TCP连接释放报文段的重复确认
TCP客户进程收到TCP连接释放报文段后,必须针对该报文段发送普通的TCP确认报文段,之后进入时间等待状态
该报文段首部中
确认为ACK的值被设置为1,表明这是一个普通的TCP确认报文段
序号seq字段的值设置为u+1,这是因为TCP客户进程之前发送的TCP连接释放报文段虽然不携带数据,但要消耗掉一个序号
确认号ack字段的值设置为w+1,这是对所收到的TCP连接释放报文段的确认
TCP服务器进程收到该报文段后就进入关闭状态,而TCP客户进程还要进过2MSL后才能进入关闭状态
TCP客户进程在发送完最后一个确认报文后,为什么不直接进入关闭状态?而是要进入时间等待状态?
因为时间等待状态以及处于该状态2MSL时长,可以确保TCP服务器进程可以收到最后一个TCP确认报文段而进入关闭状态
另外,TCP客户进程在发送完最后一个TCP确认报文段后,在经过2MSL时长,就可以使本次连接持续时间内所产生的所有报文段都从网络中消失,这样就可以使下一个新的TCP连接中,不会出现旧连接中的报文段
TCP双方已经建立了连接,后来,TCP客户进程所在的主机突然出现了故障
TCP服务器进程以后就不能再收到TCP客户进程发来的数据
因此,应当有措施使TCP服务器进程不要再白白等待下去
数字图像处理期末复习总结。
参考教材:冈萨雷斯第三版《数字图像处理》
参考课程:【数字图像处理【杜克大学】(冈萨雷斯第三版)-Image and Video Processing】 https://www.bilibili.com/video/BV1j7411i78H
参考资料:https://www.cnblogs.com/Fish0403/p/16888369.html(这个博客很无敌)
more >>自学计算机网络,资料来自网络。
原文出处:https://www.jianshu.com/c/f627e74e6ff3
本章做了一些内容删除:CSMA/CD协议,点对点通信,以太网交换机自学习和转发帧的流程(含生成树协议)。
more >>自学计算机网络,资料来自网络。
原文出处:https://www.jianshu.com/c/f627e74e6ff3
做了一些内容删除,适合非计算机专业的入门学习。
本章内容多为通信原理、信号与系统、信息论、电磁场与电磁波等,皆为电子信息的专业课,故不再过多涉及。本文仅讨论一些与先修课程有所区别和深入的地方。
more >>tag:
缺失模块。
1、请确保node版本大于6.2
2、在博客根目录(注意不是yilia-plus根目录)执行以下命令:
npm i hexo-generator-json-content --save
3、在根目录_config.yml里添加配置:
jsonContent: meta: false pages: false posts: title: true date: true path: true text: false raw: false content: false slug: false updated: false comments: false link: false permalink: false excerpt: false categories: false tags: true