B站湖科大《计算机网络》超详细重点笔记
  XFFtHPXbStbF 18天前 36 0

湖科大 《计算机网络》 超详细重点笔记 适合没时间看课想快速掌握知识点 或者 课后梳理复习

基础概念

路由器

是实现分组交换的关键构建 是最重要的分组交换机
任务是将网络互联起来，并对接收到的分组进行转发
不称其为主机

报文

表示一条消息的整个01串

三种交换方式

电路交换
报文交换

分组交换(分组的长度固定 ----->>> 缓冲区的大小便于控制)
image-20240823074335643

过程

先把报文分成小的数据段 在每一个数据段前面 加上一些由必要的控制信息组成的首部以后 就构成了一个分组 简称为包 首部称为 包头

分组交换机收到这个包以后 先暂时存储下来 再检查首部 根据首部中的目的地址进行查表转发 找到合适的转发接口 通过这个接口将分组转发给下一个分组交换机。。。。。一次次转发就到了目的主机 再去掉首部 将各数据段连接还原

衡量网络性能的一些指标

先记一下数据量的单位
image-20240823075959515

再记一下速率的单位

image-20240823090351999

这两者直接有一一对应的约等于关系
比如: 2^10 = 10^3 2^20 = 10^6 2^30 = 10^9

标250GB实际是多少呢？

image-20240823090108457

厂家给的GB是10^9 bit 但是操作系统中的是 2^30 bit
所以image-20240823090214254

速率的计算

image-20240823090722417

带宽

单位时间内能传输的数据量

image-20240823090813536

吞吐量

image-20240823090924871

时延

处理时延 知道有就行了

发送时延
计算公式: 分组长度 / 发送速率
image-20240823091601359
发送速率由上面的部分共同决定

计算

image-20240823092258492

传播时延

image-20240823091931916

时延带宽积

image-20240823094826304

往返时间 RTT

网络利用率

image-20240823095346427

丢包率

OSI体系结构

image-20240823095904806

TCP/IP体系结构

image-20240823100004714

image-20240823100853325

五层体系结构

重新把网络接口层划分为物理层和数据链路层

image-20240823100922034

每层解决的问题

image-20240823101026799

image-20240823101154539

如果在多个网络中 该如何标识各个网络和各个网络的主机呢 这就引入了网络层

image-20240823101306328

​ 当主机收到了来自服务器的分组 那么这些分组应该交给主机中的哪个进程来处理呢？ 运输出现错误该怎么解决呢？
image-20240823101413919

在此基础上 制定相应的协议 并且按照协议编写相应的应用程序 通过应用进程间的交互来完成相应的网络应用 这些就是应用层来解决的问题
image-20240823101450067

基于网络的进程间通讯的具体流程描述

​ 应用层按照http协议， 构建一个http请求报文， 把它交给运输层处理， 运输层给http报文添加一个tcp首部，让他成为一个tcp报文段， 之后交给网络层， 网络层给它添加一个ip首部， 让他成为一个ip数据报， 之后交给数据链路层处理， 数据链路层给他添加一个首部和尾部， 让他成为帧， 之后交给物理层， 物理层把帧看成bit流， 如果是以太网， 物理层就还会给比特流前面添加前导码， 为了让目的主机做好接收帧的准备， 之后物理层把这个比特流变换成相应的信号发送到传输媒体。

​ 信号通过传输媒体到达路由器， 路由器的物理层将信号再变回比特流， 去掉前导码后交给数据链路层， 去掉帧的首部和尾部， 交给网络层， 是IP数据报， 网络层解析首部， 从中提取出目的网络的地址， 查找自身的路由表， 确定转发的端口再一步步重新给到自己的物理层发送出去。

。。。。。。。 之后就是后半部分一样的处理了

image-20240823102019547

实体

image-20240823102310550

协议

image-20240823102548615

注意:
逻辑通讯并不存在
是为了让我们在研究某一层的时候不用考虑其它层 方便研究的一种手段

协议的三要素

image-20240823103019932

每层之间协议的关系

image-20240823103351181

image-20240823105011754

数据链路层

是什么
image-20240823105907378

封装成帧

把上层交付的协议数据单元封装成帧
image-20240823111416865

image-20240823112226439

image-20240823111427446

  • 帧头和帧尾中包含有重要的控制信息
  • 帧头和帧尾的作用之一就是帧定界 (比如ppp帧前后的那一个字节) 方便接收方的数据链路层从物理层的Bit流中把一个个的帧提取出来(mac帧是物理层添加了前导码,所以没有帧定界标识)

**透明传输: **
image-20240823113831612

会产生的问题:
帧定界标志是一个特殊的字符,如果在上层交付的协议数据单元中,恰好也包含了这个字符,就会出现问题。影响接收方的接收，这种情况下,数据链路层就会采取一些措施,保证接收方能正常接收。

问题的解决：
image-20240823114032942

字节填充就是发送之前先扫描一遍,遇到了帧定界符,就在前面加一个转义字符,和真正的帧定界符进行去区分

比特填充法就是发送之前扫描一遍,遇到了和帧定界的这个字节的比特完全一样的,就在这个字节里面某个固定的位置填充上0

image-20240823114446187

差错检测

是什么:image-20240823134142067

发送方将检错码封装在帧尾， 接收方主机收到帧后， 通过检错码和检错算法， 判断帧在传输过程中是否出现了误码 这就是差错检测

上面图中帧尾那四个字节的 FCS就是检错码

奇偶校验(很容易出错)image-20240823140651260

循环冗余校验CRC
image-20240823140918039

具体计算:
image-20240823141030132
image-20240823141233679
image-20240823141301299

image-20240823142103747

注意 : 进行的是异或运算

image-20240823142412320

总结：

image-20240823142516609

可靠传输

概念: 误码是不能避免的,但是 只要能实现发送方发送什么，接收方就接收到什么,就称为可靠传输
image-20240823142632070

提供的两种类型：
image-20240823142655943

image-20240823142757840
另外 : 每一层都可以选择实现可靠传输

举例一些协议 的要求(要求可靠还是不可靠)
image-20240823142920744

实现可靠传输的具体协议(协议是数据链路层的协议，但是这三种协议的基本原理并不局限于数据链路层,可以用到计算机网络体系的各层协议)

停止等待协议SW
image-20240823145006207但是如果接收方发送的确认分组也丢失了怎么办呢？？？
那么发送方就会超时重传一个重复的分组， 这个时候接收方就得判断这是不是一个重复的分组
image-20240823145237847带个序号就可以了
如果接收方发现重复了
就丢弃掉
再给发送方发送一个确认分组

既然数据分组需要编号

那么确认分组也需要编号 这样就可以解决重复确认的问题(数据链路层一般不会出现丢失的问题,所以一般不用编号)

image-20240823145353951

信道利用率
image-20240823145835388

具体计算
image-20240823150051152

回退N帧协议GBN

image-20240824081553010

好处: 采用累计确认的方法 即使确认分组丢失 也有可能是不必重传的 比如一开始的ack1丢失了 但是ack4传过去了， 这就说明前五个分组都是正确接收的 所以ack1也就没必要重传了

有差错时: 比如发送窗口这次发送来的是56701 但是5就丢失了,那么后续就会依次丢弃6701,每丢弃一个,就发送一个ack4的确认信息给发送方(上一次接收到的信息 因为上一次发送过来的是01234 所以最后一个接收到的是4) 发送方接收到重复的确认,就知道之前发送的数据分组出现了差错,不用等到超时计时器超时就立刻重传 (这也就是回退N帧)

为什么发送窗口的尺寸不能超过上线？
在上面图中的例子中,假设发送窗口是8，正好超过上限，第一次发送八个分组，接收方正确接收了，发送ACK7给发送方，但是这个确认分组丢失了，发送分组再重发前八个分组，因为序号还是0 ~ 7 ， 所以没有办法分辨是新的分组还是旧的分组。

总结:

image-20240824095638581

image-20240824100001841

image-20240824100137660

当通讯线路质量不好的时候，他的信道利用率不比停等协议高

选择重传协议

image-20240824101852599必须对每个收到的分组逐一确认 不能再多个分组才确认一次
遇到序号不匹配的， 接收方的滑动窗口就不能向前滑动

举个例子:
image-20240824102003354

​ 比如这个例子 2是错误的，所以2被丢弃了， 3进来，但是序号不匹配了，窗口就只会移动两个位置，并且发送两个确认信号，发送方收到01两个确认分组后，向前移动两个位置 发送45。发送方没收到2号确认分组 直接收到了3号确认分组 2号超时重传 接收方的滑动窗口收到这个2号以后 才会继续向前滑动

image-20240824102742175

image-20240824103117246

点对点ppp协议

image-20240824103703432

​ image-20240824103846536

帧格式
image-20240824103950691

如何解决透明传输问题？

image-20240824143213645

方法一: 字节填充法
image-20240824143957132
方法二: 比特填充法
image-20240824144350340

差错检测

计算范围如下
image-20240824144455563

循环冗余校验CRC
image-20240824144536807

工作状态

ppp链路的开始和结束都是静止状态 不存在物理层连接
当检测到调制解调器的载波信号 并建立物理层连接之后 ppp进入链路的建立状态
现在链路控制协议LCP 开始协商一些配置选项
协商成功 则进入鉴别状态
协商失败 则退回到静止状态
若无需鉴别 或 鉴别成功 则进入网络状态
若鉴别失败 则 进入终止状态
NCP配置后 进入打开状态

image-20240824145608686

MAC地址 IP地址 ARP协议

image-20240824152725978

但是因为三者关系紧密 所以放在一起了

image-20240824152805024

MAC地址

使用点对点信道的数据链路层不需要使用地址 因为整条线路上就他们两个
使用广播信道的数据链路层必须使用地址来区分各主机

image-20240824161801522
image-20240824161816704
image-20240824161904442
image-20240824161955988

MAC地址格式
image-20240824163916536

第一字节的b0位取0 代表是单播地址 取1代表是多播地址
第一字节的b1位取0 代表全球管理 取1代表本地管理
image-20240824164726902

MAC地址的发送顺序
image-20240824165114340

单播MAC地址作用 ： 发送的主机在源地址填上自己的mac地址,在目的地址填上要发送给的那个主机的mac地址 再加上帧首部的其它字段 数据载荷以及 帧尾部等 构成了单播帧 。 之后发送出去，收到这个帧的主机,去目的地址检查一下，和自己的地址是不是匹配，不匹配就直接丢弃

广播mac地址作用 ： 目的地址字段直接写广播地址就行了FF-FF-FF-FF-FF-FF 其它不变 所有主机都会接收并处理

多播mac地址作用 :
image-20240824165727280
先判断一下这个地址是不是多播地址 直接换成二级制 完后看看最后一位是0还是1

image-20240824165838794

发现有两个主机都包含了这个多播地址

发送的时候在目的地址的位置填上这个多播地址 这两台主机就都能收到这个多播帧了

IP地址 (属于网络层) 在这里只介绍ip地址的作用 详细的还是在网络层

image-20240824171145525
image-20240824171151942

从网络体系结构看ip地址和mac地址
image-20240824171311943

数据包转发过程中IP地址和MAC地址的变化情况 本例只关注网络层和数据链路层
(路由器的最高层为网络层 没有运输层和应用层)

H1想发送数据给H2
image-20240824172855950

image-20240824172916765

这种转发需要通过IP地址找到MAC地址

由此引出了ARP协议

地址解析协议ARP

每台主机都会有一个ARP高速缓存表
image-20240824174531701

image-20240824173705427
本图中 他之前获取到的A的IP和MAC的关系就被存在了高速缓存表里面

当主机B要给主机C发送数据包的时候
先在缓存表中查询有没有主机C的IP MAC(他只知道C的IP 并不知道MAC 所以需要知道MAC才能发送)
这个时候主机B发送一个ARP请求报文 获得主机C的MAC地址
image-20240824174116774
其它主机接收到后 将帧交付上层处理 上层的ARP进程解析ARP请求报文
如果发现询问的IP地址不是自己的IP 就不予理会
如果发现是自己的IP地址 就进行响应

响应步骤如下
image-20240824174342366
image-20240824174358463
image-20240824174420984
image-20240824174427735

之后B就可以正常给C发送数据包了
结束

注意:

image-20240824174552683

ARP只能逐段链路使用
不能跨好几个链路使用

集线器与交换机的区别

集线器
image-20240825094816913

使用集线器HUB在物理层扩展以太网

下面是三个使用集线器连接的相互独立的以太网 一二三系 ，是三个独立的碰撞域， 也就是说 如果一系中的某台主机发送了数据帧，信号会传给一系中的全部主机。
为了使各系的以太网能相互通信，可以再使用一个集线器把他们互联起来，这样三个以太网就互联成了一个更大的以太网，三个碰撞域就合并成了一个更大的碰撞域， 形成了一个更大的总线型以太网，
image-20240825100722610

以太网交换机

image-20240825100817311

假如都发送了一个单播帧，集线器会发给总线上的全部主机，但是交换机会根据自身的帧交换表直接转发给目的主机

假设都发送了一个广播帧 没啥区别

假设都同时给一个主机发送单播帧 集线器会碰撞 交换机会先缓存起来再逐个发给这个主机 不会产生碰撞

详细对比如下

image-20240825102532450
image-20240825102626771

交换机

全双工： 发送帧和接收帧可以同时进行

概念

image-20240825101234418

直通交换是 不必把整个帧先缓存再进行处理 在接收帧的同时，就立即按照帧的目的MAC地址 决定该帧的转发接口 但是他不检查帧是否有差错就直接转发

以太网交换机自学习和转发帧的流程

image-20240825102906289

详细流程(假设各主机知道网络中其它各主机的MAC地址 也就是无需进行ARP):

image-20240825105731471
假设主机A给主机B发送帧 ， 从交换机1的接口1进入交换机1，交换机1首先进行登记工作，将MAC地址A记录到自己的帧交换表中，将进入的接口1这个接口号也相应的记录到自己的帧交换表中，这个登记工作就是交换机的自学习。之后进行转发，在帧交换表中查找B，发现找不到，于是对该帧进行盲目转发，也称为泛洪，也就是向除了这个接口外的所有接口转发该帧，主机B的网卡收到这个帧后，根据帧的目的MAC地址知道这个是发送给自己的帧，接收。该帧从交换机2的接口2进入交换机2，交换机2也进行自学习，进行相同步骤的转发。。。
之后主机B给主机A发送上述帧，先自学习B，之后查找A，发现能找到，直接转发到接口1.

大致意思就是这样，剩下的看下面的图片就行了
image-20240825110553367

另外还有丢弃的情况，就是多加了一个G的这种，不会转发到进入的接口，所以就丢弃该帧了
image-20240825110737080

image-20240825110758649

image-20240825111024355

以太网交换机的生成树协议STP

广播风暴: 广播帧会在这个环路中不停的循环转发。。

现在的以太网的问题，如果某条线路断了，如果某个交换机只依赖这一条线路，就会直接在以太网中断联了，安全性很低
image-20240825114221687

解决办法：

image-20240825114334025

虽然有环路，但是会根据STP来阻塞自己的一些接口，避免出现网络环路
image-20240825114511082

虚拟局域网VLAN

先说路由器
路由器工作在网络层
路由器默认情况下不对广播数据包进行转发
所以它可以隔离广播域

image-20240825115557044

但是成本高
所以就需要VLAN了

概念
image-20240825115705454
原本三个网段中的所有主机属于一个广播域，但是分割成VLAN1和VLAN2后，广播将只在内部进行，也就是VLAN1中某主机发送的广播，VLAN2中的主机不会收到

实现机制
是在交换机上实现的。交换机需要有两个功能 ， 一个是能处理带有VLAN标记的帧，一个是交换机的各端口可以支持不同的端口类型（不同类型的端口对帧的处理方式有所不同）
image-20240825120034187

特殊帧

image-20240825121106351

交换机的端口类型

交换机的缺省VLAN ID（PVID）是交换机端口在没有特定配置时的默认VLAN标识
例如，当一个数据帧进入交换机端口时，如果该端口配置了特定的PVID，且数据帧的VLAN信息与端口的PVID匹配，那么该数据帧将不带VLAN标签直接发送出去；如果不匹配，则数据帧将被打上端口的PVID标签后发送。这种机制确保了数据帧在交换机内部的正确路由和传输‌

image-20240825122120283
交换机的每个端口有且只有一个PVID
思科交换机在未配置VLAN时，所有端口都默认属于VLAN1
华为交换机上称为PVID
下面都采用PVID来描述

类型

image-20240825122320856

Access端口

下图中的交换机初始化时，各接口默认PVID=1，端口类型默认是A，也就是Access接口
一般用于连接用户交换机

image-20240825122551213
一个广播帧从端口1进来，因为PVID = 1,所以给他打标签,VID = 1，之后去检查其它端口的PVID，一样就去标签转发

下面，我们想让主机AB划分为VLAN2 CD划分为VLAN3 可以如图所示进行改变
image-20240825122841195

假如一个广播帧从端口1进入交换机，VID=2，就只会转发给端口2了，也就实现了VLAN的划分

Trunk端口

一般用于交换机之间 或者 交换机与路由器之间互联

image-20240825123342597
image-20240825123353492

想如图把两个交换机互联的网络划分为VLAN1和VLAN2
可以如图配置
记得把交换端口 也就是端口5的端口类型改为T

转发流程:
image-20240825123617729
从端口1进来的广播帧，因为VID=1,和端口5的PVID相等 所以可以转发到交换机2
image-20240825123704210

image-20240825124038178
如果VID != PVID那么就会直接转发 不会进行去标签
接收的时候也是直接接收

image-20240825124318325

网络层

概述
各个网络之间由路由器互联
image-20240825132313150

路由选择: 路由器收到数据包后怎么知道应该转发到哪个路由器呢？

image-20240825132909441

所以这边介绍的是网际层

两种服务

面向连接的虚电路服务

是逻辑连接 并不是真的有一条线路
image-20240825145738009

无连接的数据报服务(因特网)

image-20240825145939371

image-20240825150022433

IPV4地址

概述

image-20240825151928066

表示方法

image-20240825152036852

计算方法

image-20240825152210152

到商0的时候结束,将从下到上组合比特串就行了

但是一般就是背住了凑就行了
image-20240825152639811

分类编址的IPV4地址

一共有五类 红色数字是最高位固定的数字
image-20240825152914312

注意事项
image-20240825153703589

image-20240825161754623

image-20240825161829310

A类地址(最高位固定为0)

image-20240825155921552

B类地址(最高位固定为10)
image-20240825161020327

C类地址(最高位固定为110)
image-20240825161240104

分配网络号

image-20240825162020765

划分子网的IPV4地址

image-20240825164502636

现在想把一个网络划分为几个子网 借用原来网络的主机号的一些位，来充当网络号，用来标识不同的子网

由此就有了下面的问题

image-20240825164637259

所以就引出了一个划分子网的工具 ------>>>>> 子网掩码
image-20240825165528727

看完例子再回去看上图就明白了

image-20240825170250636

子网掩码中的255.255.255 对应网络号部分
128对应的是有多少位被借用

image-20240825170348177

将128转化为二进制,发现只有一个1，所以只有1位是从主机号部分借用来充当子网号

image-20240825170454178

现在的主机号还剩七位 也就是只有七位来标识主机了 所以可分配的地址数量是2^7,但是还要去掉主机号为全0的网络地址和全1的广播地址

分析一下

这是没有划分子网时候 该网络地址的细节
image-20240825170841843

划分子网后就是下面这样了

image-20240825171025939

可以再看个例题
image-20240825171232515

默认子网掩码
image-20240825171328915

无分类编址的IPV4地址

概念image-20240825171852211

就是采用了全新的一套 不用ABC分类了 也没子网的概念了

image-20240825172105082

看一下例子:
image-20240825190811751

地址掩码是 255.255.240.0

路由聚合(构造超网)
一个路由器想把自己的路由信息告诉另一个路由器时，可以采用这种方式将很多条记录合并为一条，以此来节约空间。
找到共同前缀 下面例子中，他们的前两个字节都一样，从第三个字节开始不一样，所以把第三个字节转化为二进制形式，其它的不变。这样就可以找到共同前缀。
聚合地址块格式为 共同前缀(保持不变) + 剩下的bit全部取0 / 共同前缀的长度

image-20240825192104947

看个例题:
image-20240825192348856
目的地址是4.3 也就是是一个广播地址，所有主机都能收到 一共就两个可以分配的IP 也就是只有两个主机

IPV4地址的应用规划

给定一个IPV4的地址块，如何将其划分为几个更小的地址块，并将这些地址块分配给互联网中的不同网络，进而可以给各网络中的主机和路由器接口分配IPV4地址。 一般有下面的两种方法

image-20240825194116330

定长子网掩码划分举例:
先分析每个网络的IP地址需求
image-20240825194759196

由此，需要划分为五个子网 ， 每个子网可分配的IP都不能少于自身的需求

image-20240825195334907
分析一下，借用三个比特正好可以满足要求。在子网掩码中，所有对应网络号的都是1，对应主机号的都是0

把后面的八个比特改写成10进制
image-20240825195616959

具体划分情况如下图
image-20240825195742298

最后随便选五个子网分给N1到N5就可以了

总结 ： 采用定长的子网划分 只能划分出2^n个子网 n 是借用的用来作为子网号的比特数量

采用变长的子网掩码划分
和上面的划分需求相同

可以每个子网单独分析需要的网络前缀和标识的主机的位数
image-20240825200718310

总结一下需求:
image-20240825200840164

现在就要给这5个子网来分配子块
image-20240825201026541
image-20240825201328682

IP数据包的发送和转发过程

注意
image-20240826064255145

包括下面两个部分
image-20240826064322798

直接交付和间接交付
image-20240826064433030

那么源主机如何知道自己和目的主机是否在同一个网络中？
image-20240826064617397

假设主机C要给主机F发送IP数据报
C先用自己的IP和自己的子网掩码相与 得到自己的网络地址
再用F的IP地址和自己的子网掩码相与 得到目的主机的网络地址
发现不一样 --->>> 不在同一网络中
通讯属于间接交付

那么主机C如何知道应该把数据交给哪个路由器来转发呢？

用户指定一个默认的路由器 也就是默认网关

image-20240826064924022

路由器如何转发？
image-20240826065015136

image-20240826065413029

将目的地址和地址掩码相与 如果发现和目的网络不匹配 这条就不满足

广播
image-20240826065558380

如果发送的地址是本网络中的广播地址 就只能在本网络中传播 路由器不会转发

image-20240826065701465

如果发送地址是对面的广播地址 也不会转发

image-20240826065908334

静态路由配置及其可能产生的环路问题

是什么image-20240826070150161

image-20240826070416945

当想转发的时候 ， 查一下路由表 ， 路由表没有的话自己配置一下，就是静态路由配置

默认路由:
对于具有相同下一跳的不同目的网络的路由条目，可以用一条默认路由条目来替代
默认路由条目中的目的网络地址为 0.0.0.0 地址掩码也是0.0.0.0 CIDR形式 0.0.0.0/0
image-20240826070837451

特定主机路由: 地址掩码全1才能确定一个特定的主机
image-20240826071120833

路由环路:
解决方法1

image-20240826071254100

解决方法2(解决聚合了不存在网络的问题) 添加黑洞路由

image-20240826071603245

路由选择协议

image-20240826071900534

因特网采用的路由选择协议的主要特点:
image-20240826072251718

自治系统内部和自治系统外部可以采用不同类别的协议

image-20240826072347276
EGP和IGP只是路由选择协议的分类名称 不是具体的路由选择协议

常见的路由选择协议
image-20240826072617039

路由器的基本结构
image-20240826072731549

流程: 信号从某个端口进入 物理层将信号转换成比特流 数据链路层从比特流中识别出帧 去掉帧头和帧尾后送交网络层处理
如果送交网络层的是普通的数据分组 就去查表转发 查不到就丢弃
转发后再一步步封装 发送出去
如果送交网络层的是交换路由信息的路由报文 就把这个分组送交路由选择处理机
处理机根据分组的内容更新自己的路由表

image-20240826073252790
还有缓冲区

**路由表和转发表 ** 后续课程不严格区分
image-20240826073158842

路由信息协议RIP

基本概念

image-20240826073639594

image-20240826073837520

**基本工作流程: ** 看 下面图右边 的 1 2 3 就是流程
image-20240826074105091

路由条目更新规则 两个路由器之间通过封装有路由信息的RIP更新报文来交换

D收到C的路由表后 先进行改造
image-20240826074332693
举例都增加1 下一跳全部改成C

下面通过改造好的路由表对自己的路由表进行更新 有不同的更新理由
image-20240826074547557

要注意16就是不可达了

image-20240826074726651
image-20240826074732852

问题
R1到N1的线路故障了 但是还没来得及把新的路由信息发送给R2 就接收到了R2原来的信息 导致R1被误导了
image-20240826074945483
image-20240826075014660

开放最短路径优先OSPF

一些基本概念
image-20240826082125419

image-20240826082155704

image-20240826082257205

image-20240826082840628
image-20240826082925368

image-20240826083017637

分组类型
image-20240826083329166

工作过程

R1收到R2发来的数据库描述分组后,如果发现自己的数据库中缺少了信息,就会发送LSR分组 ，R2会回应LSU分组image-20240826084012563

当链路状态发生改变或者到了指定的时间 就会发送链路状态更新分组 收到该分组的路由器会洪泛转发该分组
image-20240826084141168

在多点接入网络中建立邻居关系后，如何减少问候分组发送的数量?
image-20240826084636482

划分区域 --->>> 把利用洪泛法交换链路状态信息的范围 局限于每一个区域 而不是 整个自治系统

image-20240826084938091

边界网关协议BGP

不能以 代价来作为标准寻找最佳路由
image-20240826090408312

具体情况比较复杂 尽量选择一条能到的比较好的就可以了
image-20240826090918651

基本工作原理
image-20240826091047010
image-20240826091157620
image-20240826091233109

BGP报文类型
image-20240826091329642

封装关系

image-20240826091925487

IPV4数据报的首部格式

为了简单起见，将IPV4数据报简称为IP数据报

某些IP数据报的首部 除了包含20字节外 还包含一些可选的字段 来 增加IP数据报的功能
每一行32Bit 也就是4个字节

image-20240826092812549

image-20240826092820357
image-20240826092927250
image-20240826092950673

IP数据报的首部长度一定是四字节的整数倍
由于首部中可选字段的长度从1字节到40字节不等
所以当长度不是四字节的整数倍的时候
就要用到填充字段了
image-20240826093122899

image-20240826093148581

image-20240826093218436

总长度字段和首部长度字段的关系
image-20240826093431223

首部长度是以4字节为单位的
总长度直接以字节为单位
二者相减就得到了数据载荷的长度

标识 标志 片偏移字段
这三个字段共同用于IP数据报分片

为什么要分片？

image-20240826093649709

image-20240826093802844

举例说明IP数据报如何进行分片

image-20240826094006062

将3800字节的数据载荷部分分片为三个单独的IP数据报 给每个数据报都添加上首部

分片1数据载荷部分的第一个字节就是原数据报数据载荷部分的第一个字节
所以片偏移为 0 / 8 (因为片偏移字段以8为单位)

填表如下
image-20240826094424272

若还需再次分片
image-20240826094447676
image-20240826094509153

生存时间

image-20240826094609653

image-20240826094727577

可以防止IP数据报在网络中永久兜圈

协议字段
image-20240826094857972

image-20240826094943833

image-20240826095009428

注意: 片偏移量必须为整数 如果计算出来不是整数 就得换一种分片方式了

网际控制报文协议ICMP

image-20240826100035867

分类
image-20240826100214902

终点不可达
image-20240826103044393

源点抑制(让源点发的慢点)
image-20240826103249661

时间超过
image-20240826103611819
image-20240826103634929

参数问题
image-20240826103705184

改变路由
image-20240826103823879

在什么情况下不发送差错报告报文
image-20240826104231888

ICMP询问报文
image-20240826104428546

应用

image-20240826104557721

Ping命令就是第一个应用 用来测试主机或路由器间的连通性

image-20240826104657467

tracert命令的原理:
image-20240826104905476H1给H2发送TTL=1的回送请求报文
到达R1的时候超时
R1丢弃该数据报 并给源主机发送ICMP差错报告

之后H1给H2发送TTL=2的回送请求报文
。。。。。。
以此类推
image-20240826105237615

虚拟专用网VPN与网络地址转换NAT

虚拟专用网VPN

image-20240826105957945
image-20240826110003708

这三个是无需分配的专用地址
image-20240826110031598

专用地址 只能用于一个机构的内部通讯

内部使用专用网络的两个通过因特网相互通讯的部门
具体通讯流程如下
image-20240826110329346

虽然要要经过多个网络和路由器
但是从逻辑上看
好像是点对点的一样
所以也称为IP隧道技术

内联网VPN和外联网VPN

image-20240826110723416

网络地址转换NAT

用来缓解IPV4地址即将被耗尽的问题
image-20240826110913881

NAT路由器

假如使用私有地址的主机要给因特网上使用全球IP地址的另一台主机发送IP数据报
该主机先将ip数据报发送给NAT路由器
首部中源地址字段的值为该主机的私有地址
目的地址为另一台主机的全球地址
NAT路由器从自己的全球IP地址池中
给这个私有地址分配一个临时的全球IP地址
image-20240826111418678

交换期间使用的全都是全球IP地址
当这台主机给源主机发回数据报后
NAT路由器会检查NAT转换表image-20240826111539364

之后把目的地址再修改为私有地址 并进行转发

产生的问题

image-20240826111634540

解决

image-20240826111737632

其实就是多加了个端口号

注意: 外网主机不能主动发起通信
image-20240826111825009

运输层

概述

之前的几层实现了主机到主机的通讯
但是通讯的实体是位于通信两端主机中的进程
image-20240826131926442
应用进程 到 应用进程

通信过程如下
image-20240826132040233

image-20240826132134908

端口号

运输层使用端口号来区分不同的应用进程

端口号的基本概念
image-20240826133101248

发送方的复用和接收方的分用

在运输层使用UDP协议封装 称为UDP复用
在运输层使用TCP协议封装 称为TCP复用

在网络层使用IP协议封装成IP数据报 称为IP复用
IP数据报首部中协议字段的值 用来表明IP数据报的数据载荷部分封装的是何种数据单元
取值为6 TCP
取值为17 UDP

接受方的网络层接收到IP数据报后进行IP分用
如果协议字段17 把数据载荷上交运输层的UDP
运输层进行分用
也就是根据端口号
将他们交付给上层相应的用户进程

如下图所示流程
image-20240826134010672

TCP/IP体系的 应用层常用协议 所使用的 运输层熟知端口号

image-20240826134212897

DNS服务器端进程所使用的熟知端口号是53

举例:
通过域名访问WEB服务器时候, 先向DNS服务器发送一个DNS查询请求
在运输层采用UDP协议 封装成UDP用户数据报
之后将UDP用户数据报 封装在IP数据报中
通过以太网发送给DNS服务器
DNS服务器接收到这个报文后
从中解封出UDP用户数据报
UDP首部中的目的端口号为53
所以把数据载荷部分交给DNS服务器

源端口是 用户PC中的DNS服务(DNS客户端)进程端口号

image-20240826134757794

image-20240826135040370

TCP和UDP的对比

image-20240826140654996

UDP支持 一对一 一对多 一对全部的通讯
TCP仅支持 一对一通讯

image-20240826145829843

这两个协议对应用报文的处理

UDP对应用进程交下来的报文既不合并也不拆分 而是 保留这些报文的边界 UDP是面向应用报文的

TCP把应用进程交下来的数据块 仅仅看作一连串的 无结构的字节流
TCP把他们放到发送缓存中，根据发送策略， 从发送缓存中提取一定数量的字节，构建TCP报文段并发送
接收方的TCP一方面从所接收到的TCP报文段中 取出数据载荷部分存储在接收缓存中 一方面将接收缓存中的一些字节交付给应用进程 而且假如发送方发了10个数据块 接收方可能只用了4个数据块就把这些字节交付给应用进程了 所以应用进程要自己能还原出来这些信息 TCP是全双工通讯
TCP是面向字节流的 image-20240826150543594

可靠不可靠的对比

虽然网际层使用的是IP数据报 向上层提供不可靠的传输服务 但只要运输层使用TCP协议 就可向上层提供面向连接的可靠的传输服务
image-20240826151028930

首部对比

image-20240826151116919

TCP的流量控制

让发送方别发的太快，要让接收方来得及接收
image-20240826152012676

举例:
A给B发送数据 B对A进行流量控制
假设A的TCP报文段一次可以发送100字节数据
建立连接时
B告知A 窗口的大小是400
A也将发送窗口设置为400
大写ACK是TCP报文段首部中的标志位
小写ack是TCP报文段首部中的确认号字段 取值201说明序号201之前的数据全部正确接收了
rwnd是窗口字段

具体流程如下:
image-20240826152917530

就是通过调整自己的接收窗口来对主机A进行流量控制

出现的问题
如果主机B又想让主机A发送数据了
重新调整接收窗口大小为300
但是调整报文在途中丢失了
就会产生死锁

image-20240826153123736

解决 启用计时器 + 发送零窗口探测报文
image-20240826153255072

TCP规定 即使接收窗口为0 也必须接收零窗口探测报文

TCP的拥塞控制

基本概念

image-20240826155105469

四种拥塞控制算法

image-20240826155257742

拥塞窗口 / 慢开始门限

image-20240826155501513

慢开始算法

一个传输轮次 就是一个 往返时间
往返时间并不是恒定的数值
使用传输轮次作为横坐标是为了强调
已经把拥塞窗口所允许发送的报文段都连续发送出去 并收到了对已发送的最后一个报文段的确认
开始时拥塞窗口的值为1 慢开始门限的初始值为16

在执行慢开始算法的时候
发送方每收到一个对新报文段的确认时
就把拥塞窗口 大小翻倍
然后开始下一轮的传输
当拥塞窗口的值增长到慢开始门限值的时候
就改为执行拥塞避免算法
拥塞窗口是几 就能发送几个数据报文段

改为执行拥塞避免算法后
收到了一批确认报文后
只能给 拥塞窗口的大小 +1

如果有部分报文段在传输过程中丢失了一部分
image-20240826161359387
这样就会使发送方超时重传
发送方以此判断网络很可能出现了拥塞
需要进行下图工作:

image-20240826161535493

整体传输过程如下图:
image-20240826161650140

注意:
image-20240826161708238

但是这两种算法有些问题

image-20240826161902094

另外两种算法：

image-20240826161930855

快重传算法

image-20240826162353404

过程如下:

image-20240826162559861

确认M6 代表前6个报文段都被正确接收了

快恢复算法
image-20240826162952637

包含全部四种算法的整个控制拥塞的流程如下图:

发生了超时重传的话 就进行前两种算法的拥塞控制办法
当发送方收到三个重复确认的时候
就进行快重传和快恢复

image-20240826163123740

来个例题:
image-20240826163732882

TCP超时重传时间选择

纵坐标是时间

超时重传时间RTO 应略大于 往返时间RTT

因为TCP下层是很复杂的网络环境
数据报的转发路由也有可能不同
所以每次的往返时间也有很大差别
所以这个超时重传时间RTO还是很难选择

image-20240826165322001

如上图 可能RTT1 > RTT0 那我们一开始设置的略大于往返时间的RTO就不在合适了

所以选择的规则如下
image-20240826165642535

RFC6298给出的计算RTO的公式如下:

当测量到第一个RTT1的时候 RTTD1的值取为该样本的一半
image-20240826170355686

往返时间RTT的测量
image-20240826170453931

image-20240826170543516

会出现上图的情况

针对出现超时重传时无法准确测量RTT的情况
解决方法如下:

image-20240826192035732

计算举例:
没出现超时重传就按公式算就可以了
出现了超时重传就不看公式了 直接变成之前的两倍

image-20240826192256312

TCP可靠传输的实现

TCP基于以字节为单位的滑动窗口来实现可靠传输

ack=31 说明接收方希望收到的下一个数据的序号是31 且 30号及以前的数据都被正确的接收了

image-20240826193750584

本例中发送窗口的尺寸大小是20
image-20240826194223439

发送窗口的情况 包括前沿 后沿的情况

image-20240826194307084

现在31~41已经发送 但是还没收到确认 42~50是可以发送但是没发送的状态
如何描述发送窗口的状态呢？
image-20240826194418030

接收方只能对按序收到的数据中的最高序号给出确认
如果收到了 32 33 但是没收到31 那么会把32 33 放在缓存中 同时发送一个确认信息 仍然是ack=31
发送方收到三个重复确认后就会进行快重传

补充说明image-20240826195000120

来个例题:
image-20240826195831763

TCP连接的建立

概述
image-20240826200838030

连接的建立要解决下面三个问题
image-20240826201641179

三报文握手建立连接的过程

一台主机中的某个进程主动发起TCP连接建立，称为TCP客户，另一台主机中被动等待TCP连接建立的应用进程称为TCP服务器。 将TCP连接建立的过程比喻为握手

一开始，TCP服务器进程首先创建传输控制块， 用来存储TCP连接中的一些重要信息。之后，TCP服务器进程进入监听状态，等待TCP客户进程的连接请求，称为被动打开连接。
TCP客户进程也是首先创建传输控制块，在打算建立连接的时候，向TCP服务器进程发送TCP连接请求报文段，并进入同步已发送状态。 称为主动打开连接。 SYN=1 说明是连接请求报文段 SYN=1的报文段不能携带数据
服务端发送连接请求确认报文段 ， 并进入同步已接收状态。报文段也不能携带数据
客户请求收到后 ， 再发送一个普通的TCP确认报文段，并进入连接已建立状态 可以携带数据 但是不携带数据就可以不消耗序号
服务器进程收到这个确认后 也进入连接已建立状态image-20240826202913767

为什么最后还要再发送一个普通的确认报文段呢？

下面举例说明:
TCP客户进程发送了一个TCP连接请求报文段，但是该报文在某些网络结点长时间滞留了，这会导致该报文段的超时重传，如果重传的报文段被TCP服务正确接收，TCP服务器给TCP客户进程发送一个TCP连接请求的确认报文段，并进入连接已建立状态(现在已经改成了两报文握手，所以直接进入了连接已建立状态，而不是像三报文握手那样进入同步已接收状态)，现在TCP连接的双方都进入了连接已建立状态。
但是，一段时间过后，刚才滞留的请求报文又到达了TCP服务器进程，就会被误认为是又发起了一个新的TCP连接请求。这样会浪费主机很多资源。image-20240826204745254

TCP连接的释放

通过四报文挥手来释放连接

下面来举例说明:
FIN是该报文段首部的终止位

TCP连接释放报文段(同时对之前收到的报文段进行确认,序号seq字段的值设置为u,等于客户进程之前已经传送过的最后一个字节的序号 + 1,FIN=1的报文段即使不携带数据，也要消耗掉一个序号.ack等于之前客户进程之前已收到的，数据的最后一个字节的序号 + 1)
服务器收到后，发送一个普通的TCP确认报文段并进入关闭等待状态。通知高层应用进程客户端进程要断开连接了。 TCP客户进程到服务进程这个连接就释放了 ， 现在的TCP连接属于半关闭状态(如果服务器进程仍有数据要发送，客户进程依然要接收)
客户端进程收到普通确认报文段后，进入终止等待2状态，等待TCP服务端进程发出的TCP连接释放报文段
服务端发送连接释放报文段 进入最后确认状态
客户端收到后发送确认报文段 进入时间等待状态
服务端收到后 进入关闭状态
客户端经过2MSL后进入关闭状态(确保TCP服务器进程收到最后一个TCP确认报文段并进入关闭状态)

image-20240826211252087

保活计时器
image-20240826211820957

TCP报文段的首部格式

image-20240826213752347

首部格式如图
image-20240826213954797

image-20240826214024736

image-20240826214409001

image-20240826214452861

image-20240826214501483

image-20240826214516468

image-20240826214712707
该字段以4字节为单位
0101的话 十进制是5 以4字节为单位 所以首部的长度就是 20字节
1111的话 十进制是15 以4字节为单位 所以首部长度就是 60字节
image-20240826215111086

image-20240826215149598

发送窗口大小应该选择 拥塞窗口和接收窗口中的较小者
image-20240826215323036

image-20240826215354900

image-20240826215450242

image-20240826215501514

image-20240826215529702

扩展首部
image-20240826215618381

image-20240826215632691

应用层

常见的应用
image-20240827074606185

客户/服务器(C/S)方式 和 对等(P2P)方式

CS方式

image-20240827074804394
image-20240827074920321
image-20240827075001996

对等方式
image-20240827075217498
image-20240827075243123

动态主机配置协议DHCP(TCP/IP体系应用层的协议)

DHCP报文在运输层被封装成UDP用户数据报

需要给主机手动配置 IP地址 子网掩码 默认网关 DNS服务器等 才能使用户主机正确访问Web服务器
但是手工配置的工作量较大
所以可以在网络中设置一台DHCP服务器，网络开机后自动启动DHCP程序，向DHCP服务器请求自己的网络配置信息，这样就可以自动获取网络配置信息了，不需要手动设置了

DHCP的工作过程

现在网络中有两台DHCP服务器和一台主机
DHCP服务器使用CS方式，在DHCP服务器上运行DHCP服务器进程 ，简称为DHCP服务器(使用的UDP端口是67)
用户主机上运行DHCP客户端进行，简称为客户(使用的UDP端口是68)

先发送一个DHCP发现报文
封装有 事务ID DHCP客户端的MAC地址 等
源IP地址是 0.0.0.0
目的IP地址是: 255.255.255.255
服务器根据MAC地址查找自己的数据库 查找有无这个MAC地址对应的配置信息(也要用ARP确保IP地址没被占用)
有的话就用这个配置信息构建并发送DHCP提供报文
没有的话就用默认配置信息来构建并发送DHCP提供报文(目的地址也是广播地址)
DHCP客户根据事务ID来判断是不是自己请求的发现报文(和自己封装的事务ID相等就是自己请求的报文)
两台服务器各会发送一个，客户选择先到的那个就可以了(现在就挑选好了DHCP服务器)
下面发送请求报文,也就是要征得DHCP服务器的同意
请求报文包含以下内容
image-20240827092845923

服务器同意，给客户发送确认报文
客户收到这个确认报文后，就可以开始使用所租用的IP地址了
不过在使用前还会先看看是不是被网络中的其它主机占用了
image-20240827093041547

当租期已经过去一半时，客户会给服务器发送更新请求报文
同意 则发回确认报文
不同意 则发回否认报文 客户收到后必须立即停止使用的IP地址并重新发送DHCP发现报文 重新开始申请IP地址
无响应 则当租期过去87.5%时，必须重新发送更新请求报文
。。。

另外服务器可以随时提前终止DHCP服务器所提供的租用期
发送释放报文段即可

完整流程图如下:

image-20240827093552720

DHCP中继代理

image-20240827094003015

路由器不会转发DHCP发现报文 因为是广播

解决方法:
给该服务器配置DHCP服务器的IP地址
并使之称为DHCP中继代理
image-20240827094132475

域名系统DNS

工作流程:
在浏览器输入域名后，用户主机会现在自己的DNS高速缓存中查找该域名对应的IP地址，没有找到的话，就会向网络中的某台DNS服务器查询(DNS服务器中有域名和IP地址映射关系的数据库)，DNS服务器收到DNS查询报文后，在其数据库中进行查询，之后将查询结果发送给用户主机。 用户主机的浏览器通过IP地址对这个服务器进行访问。

层次树状结构的域名结构

image-20240827095740989

image-20240827100013837

形成了下面这种树形结构
image-20240827100245691

DNS是分布式系统
image-20240827100652191

域名解析的过程

递归查询
image-20240827103617149

迭代查询
image-20240827103743822

image-20240827103923048

在查询时就可以利用上高速缓存了
image-20240827103958719

image-20240827104014101

不光在本地域名服务器中需要高速缓存
在用户主机中也很需要
image-20240827104224435

文件传送协议FTP

image-20240827133121917

FTP客户计算机可以将各种文件上传到FTP服务器
也可以从FTP服务器下载文件
image-20240827133235874

image-20240827133339314

创建FTP服务器后 会有一个IP地址
客户在浏览器中可以通过这个地址访问FTP服务器

image-20240827133458207

工作原理
一开始建立的连接 是来传送命令的 是命令通道
后面建立的才是数据通道

主动模式
image-20240827133711735

被动模式
image-20240827133750654

端口号不一样 服务器是被动等待客户连接的

image-20240827133902392

电子邮件

image-20240827140245272

邮件服务器中有很多邮箱
有用来转发待发送邮件的缓存

用户代理 其实就是电子邮件的客户端软件 比如Gmail 之类的
image-20240827140725454

邮件发送和接收过程
image-20240827140837594

SMTP的基本工作原理

发现有待转发的邮件 就建立TCP连接
基于命令和应答

具体流程如下图

220是应答代码 可能跟有描述信息
image-20240827142710652

image-20240827142904392

注意:
image-20240827142931191

电子邮件的信息格式

image-20240827144234084

传送

如果有非ASCII码数据 要转化为MIME进行传送
image-20240827144853703

为了实现这种转换
image-20240827144929925

下面介绍有关邮件读取的相关内容

常用的邮件读取协议
image-20240827151042028

基于万维网的电子邮件

用的都是HTTP协议
image-20240827151246798

很方便

万维网

是运行在因特网上的一个分布式应用
image-20240827151557559

浏览器
image-20240827151737046

image-20240827151826983

万维网的文档
image-20240827151950733

这些文档都部署在服务器端
需要从服务器传送给浏览器进行解析和渲染

TCP/IP体系中应用层非常重要的协议
HTTP超文本传输协议
image-20240827153156432

举例:
image-20240827153257364

HTTP/1.0

在第三次握手，也就是最后一个报文的数据载荷部分携带了HTTP请求
image-20240827153847547

HTTP/1.1

image-20240827153942922

HTTP的报文格式

image-20240827154353636

HTTP请求报文的格式
image-20240827154524305

url 统一资源定位符 /index.htm：服务器上资源的路径（例如一个网页）

这个HTTP报文没有主体实体

image-20240827154709055

支持以下方法
image-20240827154946731

HTTP响应报文的格式

短语是对状态码的简单描述

image-20240827155035110

常见的状态码image-20240827155049532

image-20240827155153929

Cookieimage-20240827155316017

后续每次客户端请求服务器的时候，都会把cookie放在首部行中
具体流程如下:
image-20240827155455413

万维网缓存与代理服务器
image-20240827155703351

代理服务器没有请求的数据才会向因特网上的原始服务器发送请求
image-20240827155733405

image-20240827155829234

如果Web缓存的命中率高，就可以大大减少该链路上的通讯量 降低网络时延

image-20240827161025212

【版权声明】本文内容来自摩杜云社区用户原创、第三方投稿、转载，内容版权归原作者所有。本网站的目的在于传递更多信息，不拥有版权，亦不承担相应法律责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱： cloudbbs@moduyun.com
  1. 分享：
最后一次编辑于 18天前 0

暂无评论

推荐阅读
  cO5bqZfFaDhk   2天前   10   0   0 Java
  vqyNVbtzBw9E   2天前   18   0   0 Java
  ZTo294hNoDcA   2天前   26   0   0 Java
  3dygdw7fVgD7   2天前   21   0   0 Java
  dUmYBvMWvsMI   2天前   9   0   0 Java
  ZTo294hNoDcA   2天前   12   0   0 Java
  cO5bqZfFaDhk   2天前   7   0   0 Java
  ZTo294hNoDcA   16小时前   11   0   0 Java
  6DQJUnBMpiUt   16小时前   12   0   0 Java
  u8s65Xl4dX8N   2天前   22   0   0 Java
  cO5bqZfFaDhk   3天前   30   0   0 Java
  C5asRf6NCP9F   3天前   30   0   0 Java
  u8s65Xl4dX8N   3天前   31   0   0 Java
  Ohj9nz73OSYY   3天前   27   0   0 Java
  6vi5cDFX2Me8   16小时前   12   0   0 Java
  d62ENPHvIsHf   3天前   34   0   0 Java
  u8s65Xl4dX8N   16小时前   13   0   0 Java
  028qt9vJ8T8H   3天前   32   0   0 Java
  028qt9vJ8T8H   3天前   37   0   0 Java
  028qt9vJ8T8H   3天前   32   0   0 Java
XFFtHPXbStbF
XFFtHPXbStbF
作者其他文章 更多
B站湖科大《计算机网络》超详细重点笔记

2024-08-27

对四种限流算法的思考和总结

2024-08-21

最新推荐 更多
【Python学习笔记】 第7章 字符串基础

2024-09-13

manim边学边做--通用多边形

2024-09-13

CTF/5/利用python自动请求网页

2024-09-13

WPF 什么时候 VisualTreeHelper.GetDescendantBounds 将返回无穷大

2024-09-13

C# 开源教程带你轻松掌握数据结构与算法

2024-09-13

第22篇 生成proto文件bat脚本

2024-09-13

LinkedHashMap原理详解—从LRU缓存机制说起

2024-09-13

Vert.x HttpClient调用后端服务时使用Idle Timeout和KeepAlive Timeout的行为分析

2024-09-13

Java常见报错

2024-09-13

字符串-面试题

2024-09-13

哈尔滨的珍同学

2024-09-12

Qml 实现仿前端的 Notification (悬浮出现页面上的通知消息)

2024-09-12

最新PHP在线客服系统I聊天源码网页端在线客服系统 带教程

2024-09-12

【Python学习笔记】 第6章 动态类型

2024-09-12

全网最适合入门的面向对象编程教程：47 Python函数方法与接口-回调函数Callback

2024-09-12

dotnet 记在 Linux 上某些文件的文件长度为 0 但是存在内容

2024-09-12

WPF 解决 SelectionTextBrush 设置无效问题

2024-09-12

dotnet C# 警惕可空结构体的方法内部赋值无效

2024-09-12

VisualStudio 通过配置 DefaultXamlRuntime 属性 让控制台项目里的 XAML 应用上智能提示

2024-09-12

UWP WinUI3 传入 AddHandler 的 RoutedEventHandler 类型与事件所需不匹配将抛出参数异常

2024-09-12

常用标签
数据数据数据数据linuxlinuxjavapythonredisJavapythonCentOS区块链技术信息系统区块链项目管理字符串MySQL资讯mysql教程MySQL