传输层自学

news2025/3/17 5:41:33

  • 传输实体：完成传输层任务的硬件或软件

    • 可能位于：
      • 操作系统内核
      • 独立的用户进程
      • 绑定在网络应用中的链接库
      • 网络接口卡

1.功能：

网络层与传输层作用范围比较？

  • 网络层负责把数据从源机送达到目的机

  • 传输层负责把数据送达到具体的应用进程

 

（1）数据链路相邻节点之间的逻辑通信，网络层提供主机之间的逻辑通信。

传输层运行不同主机的进程之间提供逻辑通信，两台主机实际上是应用进程之间（端到端）

（2）复用：不同的应用进程 使用同一个协议

（3）差错检测：TCP：重发，即使下面不可靠，仍然传输全双工可靠信道（面向连接的，向上提供全双工可靠）

UDP：丢弃（不可靠）

网络层：IP数据报首部中只检验首部是否出错

2.端口作用（IP地址在网络层，IP标识主机，端口标识主机中的应用进程）：各种进程将数据向下传输层，报文段中的数据交给应用层

（1）端口号：通过端口号标识，长度16，只标识本地应用层的各种进程

分类：熟知端口号

各户端使用的端口号

  • 通信 5 元组
    • 源端点：源IP、源端口
    • 目的端点：目的IP、目的端口
    • 协议：UDP、TCP
  • 知名端口

（2）套接字

IP区分主机，端口号区分应用进程

IP地址：端口号=唯一地标识一台主机上一个应用

3.服务访问点

数据链路：帧的”类型“

网络层：IP数据报”协议“

传输层:端口号

应用层：“用户界面”

4.软件端口：应用层的各种协议进程与传输层进行层交互的一种地址

5.TCP面向连接提供可靠传输，先建立连接，进行可靠传输，释放连接

不提供广播或多播

（1）实现可靠传输

措施：确认，流量控制，计时器，连接管理

UDP提供两个服务：多路复用，对数据的错误检查

IP层：知道如何把分层投递给一台主机，但不知道投到哪个具体应用

IP区分主机，端口号区分应用进程

IP地址：端口号=唯一地标识一台主机上一个应用

（2）IP数据报，在网络层经过路由器的存储转发

UDP数据报：在传输层的端到端的逻辑通信，封装成IP数据报在网络层传输，对路由器不可见的

TCp 在传输层逻辑通信中传输，对路由器不可见

虚电路：经过交换节点保存虚电路

6.UDP

  1. 功能：仅仅在IP数据报上加了复用和分用，差错检测

2.报文段格式

在这里插入图片描述

UDP数据段包括头部和数据两个部分，其中头部有4部分，每部分2字节，共 8 字节


第一部分和第二部分分别为源端口和目的端口

第三部分的长度包括头部和数据总共的长度

校验和可选，如果不计算校验和，则该域置为 0。

UDP比IP好的地方在于它可以使用源端口和目的端口。

3.端口

  • 端口共16位，共有 2 16 2^{16}2 

  • 端口范围：0~65535

  • 端口分为三部分

  • ① ≤ 1023 \leq 1023≤1023，用于公共应用 (保留，全局分配，用于标准服务器)，由 IANA 分配

  • ② 1024~49151，非特权用户端口，注册端口

  • ③ ≥ 49152 \geq 49152≥49152，动态端口，私人端口

  • 自由端口

  • 本地分配、动态的随机端口

  • 访问网站时，网站的端口通常是一些知名端口 (比如80)，而本地主机端口是系统自动分配的一个自由端口

4.校验


伪首部：（校验能力不强，好处：简单处理速度快）

作用：

检察源端口号，目的端口号，UDP数据报的数据部分，检查IP数据报的源IP地址和目的地址

流程：

在计算校验和时,要在UDP数据报之前增加 12B的伪首部,伪首部并不是UDP的真正首部。只是在计算校验和时，临时添加在UDP数据报的前面，得到一个临时的UDP数据报。校验和就是按照这个临时的UDP数据报来计算的。伪首部既不向下传送又不向上递交，而只是为了计算校验和。

UDP检验和：首部和数据部分一起检验

IP数据报：IP数据报的首部

首部开销：TCP  20B   UDP：8B

由四个字段组成，每个字段的长度2B

支持一对一，一对多，多对一，多对多

校验流程：
发送方首先把全零放入校验和字段并添加伪首部，然后把UDP数据报视为许多16位的字串接起来。若UDP数据报的数据部分不是偶数个字节，则要在数据部分末尾填入一个全零字节(但此字节不发送)。然后按二进制反码计算出这些16位字的和，将此和的二进制反码写入校验和字段，并发送。接收方把收到的UDP数据报加上伪首部(如果不为偶数个字节，那么还需要补上全零字节)后，按二进制反码求这些16位字的和。当无差错时其结果应为全1，否则就表明有差错出现，接收方就应该丢弃这个UDP数据报。

若出错，可丢弃可交付给上层，需要附上错误报告

5.校验和
将IP伪头部、UDP段头、数据三个部分，按照16位一行，然后按列进行补码相加求和，再将相加结果拿来取反码，作为最后的校验和。

如果收方的校验和为全 1，则传输无错

二进制反码求和

  1. 从低位到高位逐列计算
  2. 0和0相加是0，0和1相加是1，1和1相加是0，但产生进位
  3. 最高位相加产生进位，该位为 1

检错能力较弱，但简单快速
                  
原文链接：https://blog.csdn.net/qq_41552508/article/details/108017257

3.维护可靠性的工作：

应用层

4.UDP的首部长度

长度：最小为8

检验和，不想算直接为0

5.TCP协议

  • TCP 是专门为了在不可靠的互联网络上提供可靠的端到端字节流而设计的。
  • TCP 必须动态地适应不同的拓扑、带宽、延迟、分组大小和其它的参数，并且当有错误的时候，能够足够健壮。

支持 TCP 的机器都有一个 TCP 实体，或者是用户进程或者是操作系统内核，都可以管理 TCP 流和跟 IP层的接口。
发：封装
TCP实体接收本地进程的用户数据流，将其分割成不超过64KB的分片 (实践中，通常分割成1460字节，以通过以太网传输)
收：解封装
当包含TCP数据段的报文到达某台机器的时候，被提交给传输实体，传输实体将其重构出原始的字节流。

TCP协议特点

  1. TCP连接上的每个字节都有它自己独有的32位序列号
  2. 收发双方的TCP实体以数据段的形式交换数据
  3. 一个数据段包括20字节的头部 (不包括可选项) 和数据域 (0或更多字节)
  4. TCP软件决定数据段的大小，有两个因素限制了数据段的长度
  5. TCP数据段必须适合IP的 65515 = 65535 − 20 65515 = 65535-2065515=65535−20 的载荷限制
  6. 每个TCP数据段必须适合于下层网络的MTU (如，1500字节 - 以太网载荷大小)
  7. TCP使用的基本协议具有动态窗口大小的滑动窗口协议

在不可靠的IP协议上实现可靠的数据传输协议

（1） 面向连接

（2）只有两个端口，一对一

（3）提供可靠交付，保证无差错、不重复、不丢失

（4）全双工：设置接收缓存和发送缓存，临时存放双向通信

发送方暂时存：送给TCP准备发送的，已发送但尚未收到确认

接收方：按需到达但未被接收，不按顺序到达

（5）面向字节流，TCP把应用程序交下来的数据视为一连串的无结构的

总长度：UDP 发送应用进程决定

TCP 接收方的窗口和拥塞程度
原文链接：https://blog.csdn.net/m0_63742310/article/details/137385674

传送的数据单元：报文段，既可以运载数据，又可以建立连接、释放连接、应答

报文段格式

在这里插入图片描述

TCP的全部功能体现在其首部的各个字段中，各字段意义如下:
1)源端口和目的端口。各占2B。端口是传输层与应用层的服务接口。

2)序号。占4B，范围为0~232-1，共232个序号。TCP是面向字节流的，传送的字节流中的每个字节都按顺序编号。序号字段的值指的是本报文段所发送的数据的第一个字节的序号。

3)确认号。占4B，是期望收到对方下一个报文段的第一个数据字节的序号。

4)数据偏移(即首部长度)。占4位，这里不是IP数据报分片的那个数据偏移，而是表示首部长度(首部中还有长度不确定的选项字段)，它指出TCP报文段的数据起始处距离TCP报文段的起始处有多远。

5)保留。占6位，保留为今后使用，但目前应置为0。

6)紧急位URG。当URG=1时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送。

7)确认位ACK。仅当ACK=1时确认号字段才有效。当ACK=0时，确认号无效。TCP 规定，在连接建立后所有传送的报文段都必须把ACK置1。

8)推送位PSH(Push)。接收方TCP收到PSH=1的报文段，就尽快地交付给接收应用进程，而不再等到整个缓存都填满了后再向上交付。

9)复位位RST(Reset)。当RST=1时，表明TCP连接中出现严重差错(如主机崩溃或其他原因)，必须释放连接，然后再重新建立运输连接。

10)同步位SYN。当SYN=1时表示这是一个连接请求或连接接受报文。当SYN=1，ACK=0时，表明这是一个连接请求报文，对方若同意建立连接，则应在响应报文中使用 SYN=1，ACK=1。

11)终止位FIN(Finish)。用来释放一个连接。当FIN=1时，表明此报文段的发送方的数据已发送完毕，并要求释放运输连接。

12)窗口。占2B，范围为0~26-1。它指出现在允许对方发送的数据量，接收方的数据缓存空间是有限的，因此用窗口值作为接收方让发送方设置其发送窗口的依据。

13)校验和。占2B。校验和字段检验的范围包括首部和数据两部分。在计算校验和时，和UDP一样，要在TCP报文段的前面加上12B的伪首部(只需将UDP伪首部的协议字段的 17改成6，UDP长度字段改成TCP 长度，其他的和UDP一样)。

14)紧急指针。占 2B。紧急指针仅在URG=1时才有意义，它指出在本报文段中紧急数据共有多少字节。

15)选项。长度可变。

16)填充。这是为了使整个首部长度是 4B 的整数倍。

连接管理

TCP 连接建立图示

  • 第一步:客户机的TCP 首先向服务器的TCP发送连接请求报文段。这个特殊报文段的首部中的同步位 SYN 置1，同时选择一个初始序号 seq=x。TCP规定，SYN 报文段不能携带数据，但要消耗掉一个序号（当SYN=1时表示这是一个连接请求或连接接受报文。当SYN=1，ACK=0时，表明这是一个连接请求报文）。这时，TCP 客户进程进入SYN-SENT(同步已发送)状态。
  • 第二步:服务器的TCP收到连接请求报文段后，如同意建立连接，则向客户机发回确认，并为该TCP连接分配缓存和变量。在确认报文段中,把SYN 位和ACK位都置1（对方若同意建立连接，则应在响应报文中使用 SYN=1，ACK=1。）,确认号是ack=x+1,同时也为自己选择一个初始序号 seq=y。注意，确认报文段不能携带数据，但也要消耗掉一个序号。这时，TCP服务器进程进入SYNRCVD(同步收到)状态。
  • 第三步:当客户机收到确认报文段后，还要向服务器给出确认，并为该TCP 连接分配缓存和变量。确认报文段的ACK位置1，确认号 ack=y+1，序号 seq=x+1。该报文段可以携带数据，若不携带数据则不消耗序号。这时，TCP 客户进程进入ESTABLISHED(已建立连接)状态。成功进行以上三步后，就建立了TCP 连接，
  • 接下来就可以传送应用层数据。TCP提供的是全双工通信，因此通信双方的应用进程在任何时候都能发送数据。另外，值得注意的是，服务器端的资源是在完成第二次握手时分配的，而客户端的资源是在完成第三次握手时分配的，这就使得服务器易于受到SYN 洪泛攻击（？？）。

  • 三次握手建立TCP连接，也称为同步。这个过程中，双方交换了一个最重要的参数 —— 初始序列号，这个可以用来跟踪后续交换的每一个字节。即后续的字节的编号就是以这个初始序列号作为基础的。建立TCP连接的双方没有主从之分，它们可以相互收发数据，因此TCP数据段的传输是全双工的。

    为什么是三次握手？

    为了实现可靠数据传输， TCP 协议的通信双方， 都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。

  • 可能的问题在于网络中的延迟或旧的SYN包。比如，假设客户端之前发送了一个SYN包，由于网络延迟，这个包在某个地方滞留了。客户端可能已经重新发送了新的SYN，并完成了通信。但这时旧的SYN到达了服务器，服务器会认为这是一个新的连接请求，于是发送SYN-ACK。如果是两次握手的话，此时服务器已经建立连接，但客户端并没有发送第三次ACK，所以实际上客户端可能不会理会这个SYN-ACK，导致服务器一直等待，浪费资源。

  • 或者，另一种情况是，两次握手无法确保客户端确认服务器的SYN-ACK。三次握手中，客户端的ACK不仅确认了服务器的SYN，也携带了数据。如果只有两次握手，服务器无法确定客户端已经收到了SYN-ACK，这样可能导致连接的不确定性，比如在客户端没有正确收到SYN-ACK的情况下，服务器已经认为连接建立，但客户端并没有，导致数据发送失败。

  • 另外，三次握手还能交换初始序列号，这对后续的数据传输和确认至关重要。两次握手的话，可能只能保证一方的序列号被正确同步，另一方可能没有机会确认自己的序列号，导致数据不一致。

  • 还有可能涉及资源分配的问题。服务器在收到SYN后会分配资源，如果两次握手就建立连接，可能会因为客户端的ACK未到达而导致服务器资源被占用，而客户端可能根本不会继续通信，从而引发资源浪费的问题。

  • 三次握手的过程即是通信双方相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤。

  • 如果只是两8 次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认。

  • DoS 攻击
  • SYN泛洪导致DoS攻击 (伪造源IP)

  • 大量 Agent 向被攻击方发送TCP请求连接数据段，但源IP伪造成一个不存在的IP

  • 由于不会有主机回发确认数据段，被攻击方会挂起大量进程，最终资源耗竭而崩溃。

  • 数据传输开始后可能有两个原因导致阻塞
    快的机器向慢的机器发送数据
    多台机器同时向一台机器发送数据

  • 第一步:客户机打算关闭连接时，向其TCP发送连接释放报文段，并停止发送数据，主动关闭TCP 连接，该报文段的终止位FIN 置1（当FIN=1时，表明此报文段的发送方的数据已发送完毕，并要求释放运输连接），序号 seq=u，它等于前面已传送过的数据的最后一个字节的序号加1，FIN 报文段即使不携带数据，也消耗掉一个序号。
  • 这时，TCP客户进程进入FIN-WAIT1(终止等待1)状态。TCP是全双工的，即可以想象为一条TCP连接上有两条数据通路，发送FIN 的一端不能再发送数据，即关闭了其中一条数据通路，但对方还可以发送数据。
  • 第二步:服务器收到连接释放报文段后即发出确认，确认号ack=u+1，序号seq=v，等于它前面已传送过的数据的最后一个字节的序号加1。然后服务器进入CLOSE-WAIT(关闭等待)状态。此时，从客户机到服务器这个方向的连接就释放了，TCP连接处于半关闭状态。但服务器若发送数据，客户机仍要接收，即从服务器到客户机这个方向的连接并未关闭。
  • 第三步:若服务器已经没有要向客户机发送的数据，就通知TCP释放连接，此时，其发出FIN=1的连接释放报文段。设该报文段的序号为w(在半关闭状态服务器可能又发送了一些数据)，还须重复上次已发送的确认号 ack=u+1。这时服务器进入LASTACK(最后确认)状态。
  • 第四步:客户机收到连接释放报文段后，必须发出确认。把确认报文段中的确认位ACK置1，确认号ack=w+1，序号 seq=u+1。此时TCP连接还未释放，必须经过时间等待计时器设置的时间2MSL(最长报文段寿命)后，客户机才进入CLOSED(连接关闭)状态。

  • 当 FIN 被确认之后，该方向的连接关闭
  • 当双向连接都关闭了的时候，连接释放
  • 连接释放的问题
  • 连接释放取决于另一方，这导致连接释放要求连接的两端都释放，但是决定什么时候两边释放非常困难
  • 最后信息的发送者，永远无法知道这个信息是否到达
  • 解决方案 1
  • 将释放连接的决定权交给请求者独立裁定，而不是对方。
  • 比如，一方发送连接释放请求DR (Disconnect Request)，且期待对方的确认ACK
  • 当DR到达接收端，它回发ACK，并且也发送一个DR
  • ACK到达发送端的时候，连接释放；同时，它回发确认ACK，当这个ACK到达接收端，反方向的连接也释放了。
  • 解决方案 2：使用定时器
  • 如果一方发送了FIN数据段出去，却在一个设定的时间没有收到应答，释放连接
  • 另一方最终会注意到连接的对方已经不在了，超时后连接释放。

半开放连接
定义
理论上讲，如果初始DR和重传都丢了，发送者将因超时放弃发送且释放连接。但是，另外一端却不知道这些情况，仍然处于活跃的状态。
这种情况导致半开放连接。(half-open)
杀死半开放连接的方式
如果在一定的时间内，没有TPDUs到达的话，连接自动释放
因此传输实体在发送一个TPDU的时候必须启动定时器，定时器超期，将发送一个哑TPDU，以免连接断开。

三次握手正常释放连接


正常释放连接过程


如果确认ACK丢失

 

 TCP 4步终止会话


 

3.可靠传输
TCP 使用了校验、序号、确认和重传等机制来达到这一可靠传输的目的。

序号
  TCP首部的序号字段用来保证数据能有序提交给应用层,TCP把数据视为一个无结构但有序的字节流，序号建立在传送的字节流之上，而不建立在报文段之上。
如给每个第一个报文段的数据、第二个、第三个 都编上一个序号。

确认
  TCP首部的确认号是期望收到对方的下一个报文段的数据的第一个字节的序号。发送方缓存区会继续存储那些已发送但未收到确认的报文段，以便在需要时重传
TCP默认使用累积确认，即TCP只确认数据流中至第一个丢失字节为止的字节。

重传
  有两种事件会导致TCP对报文段进行重传:超时和冗余ACK。

  (1)超时
  TCP 每发送一个报文段，就对这个报文段设置一次计时器。计时器设置的重传时间到期但还未收到确认时，就要重传这一报文段。

  (2)冗余ACK(冗余确认)
  超时触发重传存在的一个问题是超时周期往往太长。所幸的是，发送方通常可在超时事件发生之前通过注意所谓的冗余ACK来较好地检测丢包情况。冗余ACK就是再次确认某个报文段的ACK，而发送方先前已经收到过该报文段的确认。

 TCP拥塞概述


1.分组守恒：当有一个老的分组离开之后才允许新的分组注入网络
TCP 希望通过动态维护窗口大小来实现这个目标
2.拥塞检测
所有的互联网TCP算法都假定超时是由拥塞引起的，并且通过监视超时的情况来判断是否出现问题。
3.拥塞控制
接受者容量 (维护接收者窗口 —— 容易控制)
当一个连接建立的时候，双方选择一个合适的窗口大小，接收方根据自己的缓冲区大小来指定窗口的大小。
如果发送者遵守此窗口大小的限制，则接收端不会出现缓冲区溢出的问题，但可能由于网络内部的拥塞而发生问题。
网络容量 (维护拥塞窗口 —— 难于控制)

慢启动算法 (Slow Start)

慢启动算法过程

当连接建立的时候，发送者用当前使用的最大数据段长度初始化用塞窗口，然后发送一个最大的数据段。
如果在定时器超期之前收到确认，则将拥塞窗口翻倍，然后发送两个数据段……直至超时 (或达到接收方窗口的大小)
确定出拥塞窗口的大小
例如，一开始发4096字节没有问题，下一次就发8192字节，如果发生超时，则拥塞窗口设为4096字节。
慢启动算法图示

在这里插入图片描述

 阈值


除了使用接受者窗口和拥塞窗口，TCP拥塞控制还是用了第三个参数，阈值 (threshold)，初始化为 64K。

当一个超时发生的时候，阈值降为当前拥塞窗口的一半，同时将拥塞窗口设为一个最大数据段的长度。
使用慢启动算法来决定网络的容量，拥塞窗口增长到阈值时停止指数增长。从这个点开始，每次成功的传输都会让拥塞窗口线性增长 (每次仅增长一个最大的数据段长度)
慢启动算法+阈值图示

  • 一开始2倍倍增增长，到达阈值后变为线性增长。
  • 线性增长到超时之后，阈值降为一半，拥塞窗口回到初始值。重复步骤。
  • 线性增长，可以将越来越粗放的窗口尝试粒度变小，以获得更准确的拥塞窗口值。
  • TCP慢启动算法就是这样不断超时、不断重启，尝试出的拥塞窗口值也随着网络状况的变化而发生变化，达到拥塞控制的目的。

快速恢复

重新慢启动时，拥塞窗口值不用重置为一个数据段大小，而是可以设置为阈值大小，从这里直接开始线性增长，即快速恢复。此时，反复的慢启动过程呈现出一个锯齿形状。

 TCP 定时器


重传定时器
为了解决数据段丢失的问题，每发一个数据段都会启动一个定时器 (重传定时器)。
该定时器的时间长短设置需要仔细的考量。
持续定时器
避免如下的死锁发生：
接收方发送了一个窗口数为0的确认 (窗口更新)，告诉发送方等待。
稍后，接收方空出了缓存，发送更新窗口的数据段，但是该分组丢失了。
现在，收发双方都在等待对方发送数据段过来，但大家都等不到，由此死锁产生！

解决死锁的方法：
发送方在收到 win = 0时，启动一个持续定时器，如果定时器超期没有收到更新窗口，则发送一个探测数据段，引发对方重新发出更新窗口！

保活定时器
保活定时器 (keep-alive timer)
用来检查连接是否存活，当一个连接空闲的时间超过保活定时器的时间，该连接将被杀掉。
在关闭时刻处于timed wait状态中使用的定时器：运行两倍的最大分组生存时间，以确保连接关闭之后，该连接上的所有分组都完全消失。

课程总结
TCP与UDP的比较
可靠性：TCP可靠，UDP不可靠
传播延迟：TCP不确定，UDP为网络延迟
拥塞控制：TCP有拥塞控制，UDP没有拥塞控制


选择TCP的情况


需要可靠传输方式
需要让应用程序简单化，程序员不必进行错误检查、修正等工作

选择UDP的情况


为了降低对计算机资源的需求 (DNS)
应用程序本身已提供数据完整性的检查机制，勿须依赖传输层的而协议来保证。
应用程序传输的并非关键性的数据。
一对多方式，必须使用UDP (视频传播) (TCP仅限于一对一的传送)
 


原文链接：https://blog.csdn.net/qq_41552508/article/details/108017257

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/2316429.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

微服务架构下前端如何配置 OpenAPI 接口

微服务架构下前端如何配置 OpenAPI 接口

在微服务架构中，后端通常由多个独立的服务组成，每个服务可能提供自己的 API 接口。为了在前端项目中高效地调用这些 API，可以使用 OpenAPI 规范生成客户端代码。以下是详细的配置步骤和最佳实践： 1. 理解 OpenAPI 规范 OpenAPI 是…
阅读更多...
FreeRTOS源码概述

FreeRTOS源码概述

FreeRTOS源码概述 1 FreeRTOS目录结构 使用 STM32CubeMX 创建的 FreeRTOS 工程中，FreeRTOS 相关的源码如下： 主要涉及2个目录： Core Inc 目录下的 FreeRTOSConfig.h 是配置文件Src 目录下的 freertos.c 是 STM32CubeMX 创建的默认任务 Mi…
阅读更多...
日志统计(C++,模拟，双指针)

日志统计(C++,模拟，双指针)

题目要我们求在某个时间段中，帖子点赞数达到K的帖子数 遍历方式一 我们可以先对所有帖子根据时间，升序排序 枚举每一条帖子，枚举后续每一条帖子，如果id相同且时间差小于d，那么就记录起来，如果记录数量cn…
阅读更多...
加固脱壳技术：DEX动态加载对抗

加固脱壳技术：DEX动态加载对抗

1. 加固技术原理剖析 1.1 DEX保护演进路线 加固方案发展历程： graph LR A[2015 代码混淆] --> B[2017 DEX动态加载] B --> C[2019 VMP指令虚拟化] C --> D[2022 全链路加密] 1.1.1 主流加固方案对比 厂商核心防护技术弱点分析梆梆加固DEX文件分片…
阅读更多...
C++之list类（超详细）

C++之list类（超详细）

在上一节中我们学习了STL中的vector这个容器，这节我们来学习一下另外一个常用的容器——list。 文章目录 前言 一、list的介绍 二、list的使用及相关接口 1.list的使用 2.list的迭代器使用 3.list的相关接口 3.1 list capacity 3.2 list element access 3.3…
阅读更多...
强化学习的一些概念

强化学习的一些概念

目录 强化学习 打个比方 核心要素 State Action Reward 几个代码demo 学习目标 强化学习 强化学习（Reinforcement Learning, RL）是机器学习的一个分支，旨在让智能体（Agent）通过与环境的交互学习最优策略，以…
阅读更多...
MambaTab：表格数据处理的新利器

MambaTab：表格数据处理的新利器

——基于结构化状态空间模型的特征增量学习框架 摘要 本文提出MambaTab，一种基于结构化状态空间模型（SSM）的表格数据处理框架。通过创新的嵌入稳定化设计与轻量化SSM架构，MambaTab在普通监督学习和特征增量学习场景中均表现优异&…
阅读更多...
Kafka的流量控制机制

Kafka的流量控制机制

Kafka的流量控制机制 Kafka 作为一款高吞吐量的消息队列系统，能够在海量数据场景下提供稳定的消息生产和消费能力，其背后的流量控制机制功不可没。我们需要认识到，Kafka 的流量控制并非仅仅是为了防止系统过载或崩溃，它的目标是实…
阅读更多...
CSSHTML新特性

CSSHTML新特性

HTML5 新特性探秘 在 Web 开发的不断演进中，HTML5 带来了一系列令人振奋的新特性，极大地提升了网页的功能和用户体验。今天，我们就来深入探究一下这些新特性。 语义化标签：让网页结构更清晰 语义化标签是 HTML5 的一大亮点。在…
阅读更多...
51单片机的工作方式

51单片机的工作方式

目录 一、51 单片机的时钟电路及时钟信号 （一）时钟电路 （二）时钟信号 二、51 单片机的CPU 时序 （一）时钟周期​ （二）机器周期​ （三）指令周期​ 三、…
阅读更多...
Java算法OJ（12）

Java算法OJ（12）

目录 1.前言 2.正文 2.1Fib数列 2.2单词搜索 2.3杨辉三角 3.小结 1.前言 哈喽大家好吖，今天来分享几道的练习题，欢迎大家在评论区多多交流，废话不多说让我们直接开始吧。 2.正文 2.1Fib数列 题目：斐波那契数列_牛客题霸…
阅读更多...
MrRobot靶机详细解答

MrRobot靶机详细解答

一、主机发现 arp-scan -l二、端口扫描、目录枚举、指纹识别 2.1端口扫描 nmap -p- 192.168.55.147发现22端口关闭，且无其它特殊端口，只能去网页中寻找信息 2.2目录枚举 dirb http://192.168.55.1472.3指纹识别 nmap 192.168.55.147 -sV -sC -O --…
阅读更多...
java线性表（单向链表）

java线性表（单向链表）

对于链表我们有很多种，有带头和不带头，双向和单项，循环和不循环。 我们实现的单向链表是不带头单向不循环链表。 链表不比顺序表，它可以连续也可以不连续，是链子型的每条链子两边都有节点（除首尾)。 单向…
阅读更多...
QT：动态属性和对象树

QT：动态属性和对象树

动态对象 1.添加Q_PROPERTY对象 #ifndef MYPROPERTYCLASS_H #define MYPROPERTYCLASS_H#include <QObject>class MyPropertyClass : public QObject {Q_OBJECTQ_PROPERTY(QString mask READ mask WRITE setMask NOTIFY maskChanged) public:explicit MyPropertyClass(Q…
阅读更多...
PH热榜 | 2025-03-16

PH热榜 | 2025-03-16

1. BrowserAgent 标语&#xff1a;基于浏览器的人工智能代理 - 无限使用&#xff0c;固定费用 介绍&#xff1a;在您的浏览器中直接创建和运行AI工作流程&#xff0c;无需支付API费用。我们的可视化编辑器不需要编写代码&#xff0c;同时我们的浏览器本地技术支持以固定价格进…
阅读更多...
关于进程的实验（子进程和父进程相关的）

关于进程的实验（子进程和父进程相关的）

文章目录 1.第一个问题2.第二个问题3.第三个问题 1.第一个问题 编写一段程序&#xff0c;利用系统调用fork( )创建两个进程。当此程序运行时&#xff0c;在系统中有一个父进程和两个子进程活动。让每一个进程在屏幕上显示一个字符&#xff1a;父进程显示字符“a”;子进程分别显…
阅读更多...
《基于视频监控的智能跌倒检测系统》开题报告

《基于视频监控的智能跌倒检测系统》开题报告

一、本课题研究目标 本课题旨在研究并实现一个基于视频监控的智能跌倒检测系统&#xff0c;以有效识别老年人或需特殊照顾人群的跌倒事件&#xff0c;并实现自动报警功能。具体而言&#xff0c;该系统将通过机器学习和深度学习技术&#xff0c;对视频数据中的行为模式进行分析&…
阅读更多...
SonarQube安装及结合IDEA使用详细教程（2025适配版）

SonarQube安装及结合IDEA使用详细教程（2025适配版）

一、环境验证与准备 JDK版本确认 PS C:\> java -version openjdk version "17.0.14" 2025-01-21 LTS OpenJDK Runtime Environment Zulu17.5615-CA (build 17.0.147-LTS) OpenJDK 64-Bit Server VM Zulu17.5615-CA (build 17.0.147-LTS)安装路径说明 主程序路径&a…
阅读更多...
2018年全国职业院校技能大赛高职组-计算机网络应用竞赛竞赛样题E卷

2018年全国职业院校技能大赛高职组-计算机网络应用竞赛竞赛样题E卷

目录 总体规划 模块二：设备基础信息配置 模块三：网络搭建与网络冗余备份方案部署 模块四：移动互联网搭建与网优 模块五：出口安全防护与远程接入 总体规划 医院在进行网络部分信息化建设方案设计过程中，需要保证医院、血液中心通过社保网进行互连互通，同时满足献血中心与医…
阅读更多...
vue echarts封装使用

vue echarts封装使用

echarts 尺寸自动调节 resize.js 柱状图 components/dashboard/lineChart.vue <template><div :class"className" :style"{height:height,width:width}" /> </template><script> import echarts from echarts require(echarts/…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023