【网络】TCP协议——TCP连接相关、TCP连接状态相关、TCP数据传输与控制相关、TCP数据处理和异常、基于TCP应用层协议

news2024/11/15 1:30:56

文章目录

  • Linux网络
    • 1. TCP协议
      • 1.1 TCP连接相关
        • 1.1.1 TCP协议段格式
        • 1.1.2 确定应答(ACK)机制
        • 1.1.3 超时重传机制
      • 1.2 TCP连接状态相关
        • 1.2.1 TIME_WAIT状态
        • 1.2.2 CLOSE_WAIT 状态
      • 1.3 TCP数据传输与控制相关
        • 1.3.1 滑动窗口
        • 1.3.2 流量控制
        • 1.3.3 拥塞控制
        • 1.3.4 延迟应答
        • 1.3.5 捎带应答
        • 1.3.6 面向字节流
      • 1.4 TCP数据处理和异常
        • 1.4.1 粘包问题
        • 1.4.1 TCP异常情况
      • 1.5 基于TCP应用层协议

Linux网络

1. TCP协议

  TCP(Transmission Control Protocol,传输控制协议) 是为了在不可靠的互联网络上提供可靠的端到端字节流而专门设计的一个传输协议。

  

在这里插入图片描述

  

1.1 TCP连接相关

1.1.1 TCP协议段格式

在这里插入图片描述

  
  源/目的端口号:表示数据是从哪个进程来,到哪个进程去。

  
  序列号:32 位,标识本报文段所发送数据的第一个字节的序号。

  
  确认号:32 位,期望接收对方下一个报文段的第一个数据字节的序号。

  
  数据偏移:4 位,指出 TCP 报文段的数据起始处距离 TCP 报文段起始处有多远。

  
  保留:6 位,保留为今后使用。

  
  6位标志位

  URG: 紧急指针是否有效

  ACK: 确认号是否有效

  PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走

  RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段

  SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段

  FIN: 通知对方, 本端要关闭了 , 我们称携带FIN标识的为结束报文段

  
  窗口大小:16位,用于流量控制,表示接收方愿意接收的字节数。

  
  校验和:16位,发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部, 也包含TCP数据部分。用于检验 TCP 报文段的完整性。

  
  紧急指针:16位,标识哪部分数据是紧急数据。

  

1.1.2 确定应答(ACK)机制

  在 TCP 通信中,接收方通过发送 ACK 确认报文来告知发送方已成功接收的数据。例如,当发送方发送了一段数据,接收方成功接收后,会返回一个 ACK 报文,其中的确认号是发送方下一个应该发送的数据的序号。这样发送方就知道哪些数据已经被接收方确认,哪些还需要重传。

  

  TCP将每个字节的数据都进行了编号,即为序列号

  每一个ACK都带有对应的确认序列号,意思是告诉发送者,我已经收到了哪些数据,下一次你从哪里开始发。

  例如,发送方发送了序列号为 1 的 1000 字节数据,接收方成功接收后,会返回一个 ACK 报文,确认号为 1001,表示它已经成功接收了序列号为 1 到 1000 的 1000 字节数据,期望接收序列号为 1001 的下一个数据段。

  

在这里插入图片描述

  

1.1.3 超时重传机制

  在 TCP 通信中,当发送方发送一个数据段后,会启动一个计时器。如果在计时器超时之前,发送方没有收到接收方针对该数据段的确认(ACK),就会认为这个数据段丢失了,然后重新发送该数据段。

  主机A发送数据给B之后,可能因为网络拥堵等原因,数据无法到达主机B,如果主机A在一个特定时间间隔内没有收到B发来的确认应答,就会进行重发。

  
在这里插入图片描述
  

  但是,主机A未收到B发来的确认应答, 也可能是因为ACK丢失了。

  因此主机B会收到很多重复数据. 那么TCP协议需要能够识别出那些包是重复的包, 并且把重复的丢弃掉, 就可以很容易做到去重的效果. 这时候我们可以利用前面提到的序列号

  

在这里插入图片描述

  

  那么, 如果超时的时间如何确定?

  最理想的情况下, 找到一个最小的时间, 保证 “确认应答一定能在这个时间内返回”。

  但是这个时间的长短,随着网络环境的不同,是有差异的。

  如果超时时间设的太长,会影响整体的重传效率。

  如果超时时间设的太短,有可能会频繁发送重复的包。

  

  TCP为了保证无论在任何环境下都能比较高性能的通信,因此会动态计算这个最大超时时间。Linux中(BSD Unix和Windows也是如此),超时以500ms为一个单位进行控制,每次判定超时重发的超时时间都是500ms的整数倍。

  如果重发一次之后,仍然得不到应答,等待 2500ms 后再进行重传。如果仍然得不到应答, 等待 4500ms 进行重传。依次类推,以指数形式递增,累计到一定的重传次数, TCP认为网络或者对端主机出现异常,强制关闭连接。

  

1.2 TCP连接状态相关

  在正常情况下,TCP要经过三次握手建立连接,四次挥手断开连接。

  

  服务端状态转化:

  [CLOSED -> LISTEN] 服务器端调用listen后进入LISTEN状态, 等待客户端连接;(同步报文段), 就将该连接放入内核等待队列中 [LISTEN -> SYN_RCVD] 一旦监听到连接请求 , 并向客户端发送SYN确认报文。
  
  [SYN_RCVD -> ESTABLISHED] 服务端一旦收到客户端的确认报文, 就进入ESTABLISHED状态, 可以进行读写数据了。
  
  [ESTABLISHED -> CLOSE_WAIT] 当客户端主动关闭连接(调用close), 服务器会收到结束报文段, 服务器返回确认报文段并进入CLOSE_WAIT。
  
  [CLOSE_WAIT -> LAST_ACK] 进入CLOSE_WAIT后说明服务器准备关闭连接(需要处理完之前的数据); 当服务器真正调用close关闭连接时, 会向客户端发送FIN, 此时服务器进入LAST_ACK状态, 等待最后一个ACK到来(这个ACK是客户端确认收到了FIN)。
  
  [LAST_ACK -> CLOSED] 服务器收到了对FIN的ACK, 彻底关闭连接。

  

  客户端状态转化:

  [CLOSED -> SYN_SENT] 客户端调用connect, 发送同步报文段。
  
  [SYN_SENT -> ESTABLISHED] connect调用成功, 则进入ESTABLISHED状态, 开始读写数据。
  
  [ESTABLISHED -> FIN_WAIT_1] 客户端主动调用close时, 向服务器发送结束报文段, 同时进入FIN_WAIT_1。
  
  [FIN_WAIT_1 -> FIN_WAIT_2] 客户端收到服务器对结束报文段的确认, 则进FIN_WAIT_2, 开始等待服务器的结束报文段。
  
  [FIN_WAIT_2 -> TIME_WAIT] 客户端收到服务器发来的结束报文段, 进入TIME_WAIT, 并发出LAST_ACK。
  
  [TIME_WAIT -> CLOSED] 客户端要等待一个2MSL(Max Segment Life, 报文最大生存时间)的时间, 才会进入CLOSED状态。

  

在这里插入图片描述

  

  以下是TCP状态转换

  较粗的虚线表示服务端的状态变化情况。

  较粗的实线表示客户端的状态变化情况。

  CLOSED是一个假想的起始点, 不是真实状态。

  

在这里插入图片描述

  

1.2.1 TIME_WAIT状态

  TIME_WAIT 状态是 TCP 协议中的一种连接状态。

  

  特点:

  持续时间通常为 2 倍的最大段生存期(MSL,Maximum Segment Lifetime),在大多数实现中,MSL 的值约为 30 秒到 2 分钟,因此 TIME_WAIT 状态的持续时间一般在 1 到 4 分钟。

  

  作用:

  可靠地实现 TCP 全双工连接的终止:在主动关闭连接的一方发送最后一个 ACK 后,进入 TIME_WAIT 状态。如果这个 ACK 丢失,被动关闭方会重传 FIN 报文。由于主动关闭方仍处于 TIME_WAIT 状态,能够重新发送 ACK 来完成连接的关闭。

  允许老的重复分节在网络中消逝:即使连接已经关闭,之前传输的数据可能还在网络中传输。处于 TIME_WAIT 状态可以确保这些延迟的数据在其可能对新连接造成干扰之前被丢弃。

  

  举例说明:

  假设客户端和服务器端进行通信,客户端主动关闭连接。客户端发送完最后的 ACK 后进入 TIME_WAIT 状态。如果这个 ACK 在网络中丢失,服务器端由于没有收到 ACK 会重传 FIN 报文。由于客户端还在 TIME_WAIT 状态,能够接收到重传的 FIN 报文并重新发送 ACK,从而确保连接正常关闭。

  另外,如果客户端在关闭连接后立即建立新的连接,并且新连接使用了与之前相同的源端口和目的端口,且网络中仍存在之前连接的延迟数据包。如果没有 TIME_WAIT 状态来缓冲,这些延迟数据包可能会被错误地认为是新连接的数据,从而导致数据混乱。

  

在这里插入图片描述

  

1.2.2 CLOSE_WAIT 状态

  CLOSE_WAIT 状态是 TCP 连接中的一种中间状态。

  当对方主动关闭连接(即对方发送了 FIN 报文),而本地还没有调用 close 函数关闭连接时,就会处于 CLOSE_WAIT 状态。

  处于 CLOSE_WAIT 状态可能会带来一些问题。例如,如果程序没有正确处理这种状态,长时间不调用 close 关闭连接,可能会导致资源泄漏,比如文件描述符没有被释放,内存占用无法回收等。

  

  以下是一个可能导致进入 CLOSE_WAIT 状态的示例场景

  假设服务器端和客户端建立了 TCP 连接进行通信,客户端完成任务后主动关闭连接,向服务器端发送了 FIN 报文。服务器端收到 FIN 报文后,正常情况下应该处理完剩余数据,并调用 close 函数关闭连接。但如果服务器端的程序存在逻辑漏洞,没有及时调用 close 函数,那么服务器端就会一直处于 CLOSE_WAIT 状态。

  为了避免出现 CLOSE_WAIT 状态,程序在接收到对方的 FIN 报文后,应尽快完成必要的清理工作,并调用 close 函数关闭连接,以释放相关资源并使连接正常关闭。

  

1.3 TCP数据传输与控制相关

1.3.1 滑动窗口

  滑动窗口是TCP协议中的一个重要机制,用于控制、管理发送方和接收方之间的数据传输。是TCP实现流量控制和拥塞控制的基础。

  

  特点:

  动态调整:窗口大小不是固定不变的,而是根据网络状况、接收方的处理能力和缓冲区空间等因素动态调整。

  基于字节:窗口是以字节为单位进行计量和操作的,而非数据包的数量。

  

  作用:

  提高传输效率:允许发送方在等待确认的同时发送多个数据包,而不必逐个数据包进行确认,从而充分利用网络带宽,减少等待时间。

  流量控制:接收方通过通告其可用的接收窗口大小,来控制发送方的发送速率,防止接收方缓冲区溢出。

  

  工作原理示例:

  假设发送方的窗口大小为 1000 字节,初始时已发送但未确认的字节范围是 1 - 500。当接收方成功确认了 1 - 300 字节,发送方的窗口就会向右滑动 300 字节,此时可以发送 301 - 800 字节的数据。

  如果接收方的缓冲区已满,它可能通知发送方窗口大小为 0。发送方会停止发送数据,直到接收方重新通知有可用的窗口空间。

  

  优点:适应网络变化:能够根据网络的拥塞程度和接收方的处理能力自动调整数据发送量。减少开销:减少了频繁的确认和等待,降低了通信开销。

  缺点:实现复杂:需要双方精确地维护窗口状态和相关的控制信息。对内存要求较高:需要为未确认的数据保留缓冲空间。

在这里插入图片描述

  

1.3.2 流量控制

  接收端处理数据的速度是有限的。如果发送端发的太快,导致接收端的缓冲区被打满,这个时候如果发送端继续发送,就会造成丢包,继而引起丢包重传等等一系列连锁反应。

  因此TCP支持根据接收端的处理能力,来决定发送端的发送速度,这个机制就叫做流量控制(Flow Control)。

  

  流量控制特点:

  接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段,通过ACK端通知发送端。

  窗口大小字段越大,说明网络的吞吐量越高。

  接收端一旦发现自己的缓冲区快满了,就会将窗口大小设置成一个更小的值通知给发送端。

  发送端接受到这个窗口之后,就会减慢自己的发送速度。

  如果接收端缓冲区满了,就会将窗口置为0;这时发送方不再发送数据,但是需要定期发送一个窗口探测数据段,使接收端把窗口大小告诉发送端。

  接收端如何把窗口大小告诉发送端呢? 回忆我们的TCP首部中,有一个16位窗口字段,就是存放了窗口大小信息。

  

  那么问题来了,16位数字最大表示65535,那么TCP窗口最大就是65535字节么?

  实际上,TCP首部40字节选项中还包含了一个窗口扩大因子M,实际窗口大小是 窗口字段的值左移 M 位;

  

在这里插入图片描述

  

1.3.3 拥塞控制

  虽然TCP有了滑动窗口这个大杀器,能够高效可靠的发送大量的数据,但是如果在刚开始阶段就发送大量的数据,仍然可能引发问题。

  因为网络上有很多的计算机,可能当前的网络状态就已经比较拥堵,在不清楚当前网络状态下,贸然发送大量的数据,是很有可能引起雪上加霜的。

  TCP引入 慢启动 机制,先发少量的数据,探探路,摸清当前的网络拥堵状态,再决定按照多大的速度传输数据此处引入一个概念程为拥塞窗口。

  

  发送开始的时候,定义拥塞窗口大小为1。

  每次收到一个ACK应答,拥塞窗口加1。

  每次发送数据包的时候,将拥塞窗口和接收端主机反馈的窗口大小做比较,取较小的值作为实际发送的窗口。

  
在这里插入图片描述
  

  像上面这样的拥塞窗口增长速度,是指数级别的。“慢启动” 只是指初使时慢,但是增长速度非常快。

  为了不增长的那么快,因此不能使拥塞窗口单纯的加倍。

  此处引入一个叫做慢启动的阈值。

  当拥塞窗口超过这个阈值的时候,不再按照指数方式增长,而是按照线性方式增长。

  
在这里插入图片描述
  

  当TCP开始启动的时候,慢启动阈值等于窗口最大值。

  在每次超时重发的时候,慢启动阈值会变成原来的一半, 同时拥塞窗口置回1。

  少量的丢包,我们仅仅是触发超时重传,大量的丢包,我们就认为网络拥塞;当TCP通信开始后,网络吞吐量会逐渐上升。随着网络发生拥堵,吞吐量会立刻下降。

  拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案.

  

1.3.4 延迟应答

  其核心思想是:接收方在收到数据后,不立即发送确认应答(ACK),而是等待一段时间再回复。

  延迟应答带来的好处主要有以下几点:

  增加窗口大小:在等待的这段时间内,接收方可能有更多的数据被处理,从而使得接收缓冲区腾出更多空间。这样在回复 ACK 时,可以告知发送方一个更大的接收窗口,允许发送方发送更多的数据,提高了传输效率。

  减少应答次数:如果每次收到数据都立即应答,可能会导致频繁的小数据包交互。通过适当延迟应答,可以将多个数据的确认合并在一个应答中,减少网络中的数据包数量。

  

  一定要记得,窗口越大,网络吞吐量就越大,传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率。

  那么所有的包都可以延迟应答么? 肯定也不是:

  数量限制:每隔N个包就应答一次。

  时间限制:超过最大延迟时间就应答一次。

  具体的数量和超时时间,依操作系统不同也有差异: 一般N取2,超时时间取200ms。

  

在这里插入图片描述

  

1.3.5 捎带应答

  捎带应答是 TCP 协议中一种提高通信效率的机制。

  当一个主机在向另一个主机发送数据的同时,正好有对对方数据的确认信息要返回,就可以把确认信息搭载在正在发送的数据上,一起发送给对方,而不必单独发送一个确认数据包。

  例如,A 向 B 发送数据,此时 B 正好要向 A 发送数据,并且 B 已经成功接收了 A 之前发送的数据,那么 B 就可以在要发送给 A 的数据包中捎带上对 A 之前数据的确认信息。

  

  这样做的好处是减少了网络中数据包的数量,节省了网络资源,提高了数据传输的效率。

  假设在一个客户端与服务器进行频繁交互的场景中,客户端向服务器发送请求,服务器处理请求后返回响应,同时确认收到了客户端之前的某些数据。如果每次确认都单独发送一个数据包,会增加网络开销。而通过捎带应答,服务器可以在返回响应时一并完成确认,减少了不必要的数据包传输。

  
在这里插入图片描述

  

1.3.6 面向字节流

  TCP 并不关心应用层交给它的数据的具体含义和结构,它只是把这些数据看作一连串无结构的字节序列进行传输。

  具体来说,TCP 把应用层交下来的数据仅仅看成是一连串的字节流,它不保留应用层交下来数据的边界。 例如,应用层程序一次性向 TCP 写入了 100 个字节,然后又写入了 200 个字节。TCP 可能并不会把这两次写入的数据分别发送,它可能会根据当时的网络状况和自身的策略,将这 300 个字节拆分成几个部分进行发送,也可能会把它们和后续写入的数据一起组合发送。

  

  在接收端,TCP 接收到的数据也只是一系列的字节,接收方的应用程序需要根据自己的需求和数据的特点来确定数据的边界和含义。

  举例来说,假设一个即时通讯应用通过 TCP 发送了两条消息“Hello”和“World”。在传输过程中,TCP 可能将它们作为一个连续的字节流发送,比如“HelloWorld”。接收方的应用程序需要根据事先约定的规则(比如特定的分隔符或者消息长度)来将这个字节流解析为两条独立的消息。

  

1.4 TCP数据处理和异常

1.4.1 粘包问题

  粘包问题是在基于 TCP 协议进行数据传输时可能出现的一种现象。

  由于 TCP 是面向字节流的协议,且其具有优化机制(如 Nagle 算法),数据在传输过程中可能不会按照发送方发送的边界进行接收,导致多个数据包粘连在一起。

  例如,发送方先后发送了两个小数据包,一个包含“Hello”,另一个包含“World”。在接收方,可能会一次性接收到“HelloWorld”,而不是分别接收到两个独立的数据包。

  

  粘包问题产生的原因主要有以下几点:

  应用程序写入数据的字节大小较小,TCP 为了提高传输效率,会将多次写入的数据合并发送。

  接收方的缓冲区大小和接收时机,可能导致多个数据包一次性被读取。

  

  那么如何避免粘包问题呢? 就是明确两个包之间的边界。常见的方法有:

  定长消息:规定每个数据包的固定长度,接收方按照固定长度读取。

  特殊分隔符:在数据包之间添加特定的分隔符,接收方根据分隔符来拆分数据包。

  消息头+消息体:在数据包开头添加描述消息长度等信息的消息头,接收方根据消息头来解析消息体。

  假设一个聊天应用中,客户端发送了多条短消息,如果不处理粘包问题,服务端可能会将多条消息混淆。通过添加消息头指示消息长度,服务端就能准确地拆分和处理每条消息。

  

1.4.1 TCP异常情况

  TCP异常情况:

  进程终止:进程终止会释放文件描述符,仍然可以发送FIN。和正常关闭没有什么区别。

  机器重启:和进程终止的情况相同。

  机器掉电/网线断开:接收端认为连接还在,一旦接收端有写入操作,接收端发现连接已经不在了,就会进行reset。即使没有写入操作,TCP会定期询问对方是否还在自己也内置了一个保活定时器,如果对方不在,也会把连接释放。

  另外,应用层的某些协议,也有一些这样的检测机制。例如HTTP长连接中,也会定期检测对方的状态。例如QQ,在QQ断线之后,也会定期尝试重新连接。

  

  以上TCP机制是按照功能分类的,也可以按照实现的性质分类:

  可靠性: 校验和、序列号(按序到达)、确认应答、超时重发、连接管理、流量控制、拥塞控制。

  提高性能: 滑动窗口、快速重传、延迟应答、捎带应答。

  

1.5 基于TCP应用层协议

  HTTP、HTTPS、SSH、Telnet、FTP、SMTP、我们自己写TCP程序时自定义的应用层协议。

            

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

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

相关文章

草的渲染理论

Unity引擎提供了基础的terrain工具,可以制作地形,在上面刷树刷草。对于树,Unity是支持带LOD的Prefab,不同距离显示不同细节的模型,效果还不错。对于草,Unity支持两种方式来刷草,一种是Add Grass…

汇凯金业:解读区块链概念、类型与独特优势

区块链作为一种具有革命性的创新技术,正在逐渐改变我们的生活和商业模式。它的去中心化、安全可靠、不可篡改等特性,为解决许多传统领域中的问题提供了新的思路和方法。 一、区块链的基本概念 区块链是一种具有创新性的计算机技术应用模式,…

C#复习之类和对象

知识点一:什么是类 基本概念: 具有相同特征 具有相同行为 一类事物的抽象 类是对象的模板 可以通过类创建出对象 类的关键字 Class 知识点二:类声明在哪里 类一般声明在namespace语句块中 知识点三:类声明的语法 知识点四&#xf…

html+css 实现文字滚动的按钮

前言:哈喽,大家好,今天给大家分享htmlcss 绚丽效果!并提供具体代码帮助大家深入理解,彻底掌握!创作不易,如果能帮助到大家或者给大家一些灵感和启发,欢迎收藏关注哦 💕 文…

2024年前端趋势:全栈或许是不容错过的选择!

近年来,前端开发的技术不断推陈出新,2024年也不例外。在这个变化迅速的领域,全栈开发逐渐成为一股不容忽视的趋势。无论你是经验丰富的开发者,还是刚刚入门的新手,掌握全栈技术都能让你在竞争中脱颖而出。而在这个过程…

Spring -- 拦截器

T04BF 👋专栏: 算法|JAVA|MySQL|C语言 🫵 今天你敲代码了吗 文章目录 1. 自定义拦截器2. 注册配置拦截器3. 拦截器详解3.1 拦截路径3.2 拦截器执行流程 3.3 DispatcherServlet源码分析3.3.1 初始化:3.3.2 处理请求3.3.3 适配器 拦截器是Spring框架提供的…

vue项目删除无用的依赖

1.安装依赖检查工具 npm i depcheck 2.查看无用的依赖 npx depcheck 3.手动删除pageage.json中的无用的依赖(如果有sass和sass-loader不要删,会引起项目报错) 4.全部删除完成之后,删除package-lock.json和yarn.lock文件&#x…

【文件解析漏洞复现】

一.IIS解析漏洞复现 1.IIS6.X 方式一:目录解析 搭建IIS环境 在网站下建立文件夹的名字为.asp/.asa 的文件夹,其目录内的任何扩展名的文件都被IIS当作asp文件来解析并执行。 访问成功被解析 方式一:目录解析 在IIS 6处理文件解…

图纸加密与零信任沙箱:构建企业数据安全的双重保障

在这个信息爆炸的时代,数据安全如同一场没有硝烟的战争。深信达SDC沙盒防泄密系统,以其零信任沙盒技术,为企业提供了一个坚不可摧的“金钟罩铁布衫”,确保企业图纸安全“坚如磐石”。 一、数据安全的“冰与火之歌” 数据安全是一…

如何简便改文件名

在出OI题的时候,有时候想要方便地把输入输出文件的文件名都改掉,类似于将a1.in,a2.in,…,a50.in都改成b1.in,b2.in,…,b50.in 我用gpt写了一个python代码 import osdef rename_files(base_name, new_name, num_files):for i in range(1, num_files 1)…

函数实例讲解 (一)

文章目录 函数中的引用、运算符、通配符1、引用2、运算符3、通配符 函数的类别、输入方式、结果检查1、函数类别2、输入方式3、结果检查 数组的基本概念1、数组极其元素的概念2、数组的书写3、数组的类型4、内存数组的存储位置5、数组公式与普通公式的区别 逻辑判断函数之IF1、…

【工具】-gdb-学习笔记

准备工作 程序的发布方式有两种,debug模式和release模式 Linux gcc/g出来的二进制程序,默认是release模式 要使用gdb调试,必须在源代码生成二进制程序的时候, 加上 -g 选项,发布成debug模式 如下源代码经过编译: #…

VS Code C/C++ MSVC编译器

官方教程 通过快捷方式打开VS Code是编译不了的,需要对tasks.json修改(Tasks: Configure default build task) 先创建tasks.json 复制这段配置到tasks.json,记得修改VsDevCmd.bat的路径 {"version": "2.0.0","windows": {"options"…

深度学习中卷积算子和dropout算子的作用

笔者在调网络的时候,有时调细一些在想不同卷积核尺寸的卷积操作有啥区别,在哪些算子后用dropout会比较好呢?于是有了下面一段总结。 文章目录 一、卷积核尺寸1X1和3X3的区别1x1卷积核3x3卷积核 二、dropout的作用使用情况算子组合注意事项 一…

[读论文]-FreeU: Free Lunch in Diffusion U-Net 提高生成质量

摘要 In this paper, we uncover the untapped potential of diffusion U-Net, which serves as a “free lunch” that substantially improves the generation quality on the fly. We initially investigate the key contributions of the U-Net architecture to the denois…

《计算机网络》(第8版)第9章 无线网络和移动网络 复习笔记

第 9 章 无线网络和移动网络 一、无线局域网 WLAN 1 无线局域网的组成 无线局域网提供移动接入的功能,可分为两大类:有固定基础设施的和无固定基础设 施的。 (1)IEEE 802.11 IEEE 802.11 是无线以太网的标准,是有固定…

SQL数据库备份

转载:数据库备份与还原 1. 以下过程为记录客户单位备份过程。 一般有E盘选择E盘备份,否则选择D盘备份。选中备份文件需要重命名,以防原文件被覆盖。切换选项,选中压缩备份。

IoTDB 入门教程 问题篇④——外网攻击导致OOM内存溢出,服务崩溃

文章目录 一、前文二、思考问题三、验证问题五、深入思考六、总结 一、前文 IoTDB入门教程——导读 二、思考问题 从上一篇博客得知,因为内存大小设置的不合理,容易导致OOM内存溢出,最终导致服务崩溃。 事后转念一想,又在思考&…

【ADC】欠采样的基本理论及其应用中的抗混叠滤波器设计原则

概述 之前的两篇文章:信号采样中的频谱混叠现象、频谱混叠的MATLAB仿真与抗混叠滤波器设计 介绍了关于 ADC 采样时,有关奈奎斯特采样定律的基本理论、频谱混叠现象的由来,以及抗混叠滤波器的设计与仿真。但这都是基于过采样的情况&#xff0…