为什么 Linux 内核协议栈会丢弃 SYN 数据包

这篇具有很好参考价值的文章主要介绍了为什么 Linux 内核协议栈会丢弃 SYN 数据包。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

最近了解到 SYN 数据包丢弃的问题,网上有一些资料,这里记录分享一下。

serverfault上的重要信息

tcp - No SYN-ACK Packet from server - Server Fault

信息如下:

        My embedded system with LwIP is the client and I have server1 and server2. I connected to server1 and end the connection before connecting to server2.

Further breakdown on the flow:

  1. Client creates New Socket with server1
  2. Client sent DNS packet to obtain server1's ip address; received ACK from AP
  3. Client send TCP SYN packet;
  4. Server1 send TCP SYN-ACK and perform some data transmission
  5. Client ends connection with server1 by sending TCP RST packet; and close socket
  6. Client creates New Socket with server2
  7. Client sent DNS packet to obtain server2's ip address; received ACK from AP
  8. Client send TCP SYN packet to server2
  9. Server2 send TCP SYN-ACK and perform some data transmission
  10. Client ends connection with server2 by sending TCP RST packet; and close socket

        However, sometimes server2 did not response to client's SYN Packet which is in Step 9. Its only happens sometime. I checked several forum like:

[1] Why would a server not send a SYN/ACK packet in response to a SYN packet

[2] Server not sending a SYN/ACK packet in response to a SYN packet

主要就是关闭下面配置:

sysctl -w net.ipv4.tcp_timestamps=0
sysctl -w net.ipv4.tcp_tw_recycle=0

或设置

cat /etc/sysctl.conf 

net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_window_scaling = 0
net.ipv4.tcp_timestamps = 0

下面翻译自:Why Are Linux Kernel Protocol Stacks Dropping SYN Packets - Alibaba Cloud Community

SYN 数据包丢弃

        在排除网络问题时,经常会遇到 TCP 连接失败的情况。如果能获取到两端抓到的数据包,则数据包如下:

  • 客户端一直在以指数退避方式重新传输 TCP SYN。

这是因为第一个数据包还没有获得RTT和RTO,会在1、2、4、8秒左右重传,直到net.ipv4.tcp_syn_retries重传完成。

  • 在服务器端可以看到TCP SYN包已经到达网卡,但是没有返回TCP包。

        这个问题出现的比较频繁。本博客将重点讨论与 TCP 协议栈相关的网络问题。对于TCP协议栈来说,我们指的是相关的网络问题可能是这样的情况:TCP SYN包可能已经到达了内核的TCP处理模块,但是根据服务器端内核代码却没有给客户端返回SYNACK。客户端持续重传TCP SYN也可能是由其他原因造成的,比如服务器端多个网卡导致访问路径不一致,或者SYN报文被规则拦截iptables,但这里不讨论这些。相反,我们将关注最常见的原因。

处于监听状态时处理 TCP SYN

        在本教程中,我们将使用广泛使用的CentOS 7内核版本。在本教程中,我们首先看一下TCP处理SYN的主要逻辑,并根据案例处理经验分析可能出现问题的点。Listen状态下的socket处理第一个TCP SYN报文的逻辑如下:

tcp_v4_do_rcv() @net/ipv4/tcp_ipv4.c
        |--> tcp_rcv_state_process() @net/ipv4/tcp_input.c // This functiuon implements the processing of accept messgaes in the vast TCP state (except for ESTABLISHED and TIME-WAIT), including of course the LISTEN state we are interested in.
                |--> tcp_v4_conn_request() @@net/ipv4/tcp_ipv4.c // When the TCP socket is in the LISTEN state and the TCP SYN flag is in the received message is set, it comes to this function.

        CentOS中的内核代码可能会略有调整。如果您需要跟踪源代码中的确切行数,systemtap是一种适合此目的的方法,如下所示:

# uname -r
3.10.0-693.2.2.el7.x86_64
# stap -l 'kernel.function("tcp_v4_conn_request")'
kernel.function("tcp_v4_conn_request@net/ipv4/tcp_ipv4.c:1303")

在tcp_v4_conn_request()的代码中,前几行函数逻辑如下:

为什么 Linux 内核协议栈会丢弃 SYN 数据包,运营管理,网络编程,Linux,linux,运维,服务器

        进入该函数的前提是TCP套接字处于Listen状态,并且接收到的数据包中设置了TCP SYN标志。进入函数逻辑后,我们可以发现函数应该考虑各种可能出现的异常,但很多异常其实并不那么常见。比如前几行的两种情况:

  1. 第1482行:拒绝发送到广播和组播的数据包。
  2. 1490行:如果请求队列(存放SYN包的队列)已满,则isn为0,为want_cookiefalse,则丢弃SYN包。

        第一种情况比较容易理解,实际中还没有见过。但是,第二种情况稍微复杂一些,在实际中也有一定概率会遇到。下面我们就来看看:

        第一个条件,请求队列已满,其实很容易满足。syn 洪水攻击很容易导致这种情况发生。TCP_SKB_CB(skb)->isn 的分配与函数开头的when相同。这是用于计算 TCP 控制块结构中的 RTT 的字段。表示want_cookie是否使用syn syncookies方法。它在tcp_syn_flood_action()中的定义如下。如果ifdef前面添加CONFIG_SYN_COOKIES,并且内核参数net.ipv4.tcp_syncookies也设置为1,则摘要返回 true,因此want_cookie返回为true

为什么 Linux 内核协议栈会丢弃 SYN 数据包,运营管理,网络编程,Linux,linux,运维,服务器

        因此,在上述丢弃SYN数据包的情况下,真正的前提条件是内核参数net.ipv4.tcp_syncookies未启用。但在实际生产系统中,参数net.ipv4.tcp_syncookies是默认启用的。Syn syncookies是一种通过以时间(CPU计算)换取空间(请求队列)来防御syn Flood攻击的方法。在实际生产中,任何场景都不需要显式关闭该开关。所以一般来说,1490行的请求并不是很常见。

内核丢弃SYN数据包的主要场景

        下面介绍两种主要可能导致SYN包丢失的场景以及如何快速判断服务器不返回SYNACK的原因。

1. 每主机 PAWS(Protect Against Wrapped Sequences ) 检查导致 SYN 数据包丢失

症状

        这是实际生产环境中最常见的问题:对于同时启用了net.ipv4.tcp_tw_recycle和 的服务器net.ipv4.tcp_timestamps,当服务器有 NAT 客户端访问时,出现此问题的概率非常高。从客户端来看,这个问题的症状是新连接不稳定。有时可以连接,有时不能连接。

每主机 PAWS 原则

        有关背景信息,PAWS 是 Protect Against Wrapped Sequences 的缩写,这是一种防止序列号被包装的方法。接下来,Per-host 检查对等主机的 IP 地址,而不是 IP 端口的四元组。

        每主机PAWS检查的方式如下:对于快速回收的TIME_WAIT套接字的五元组对等主机IP,这有助于防止来自同一主机的旧数据的干扰。因此,新 SYN 数据包的 TCP Timestamps 选项需要在 60 秒内增加。当客户端处于NAT环境中时,这个条件往往不容易满足。

        理论上,只需要记住上面这句话,就可以解决很多客户端三向握手时而连通、时而断开的问题。欲了解更多信息,请参阅下面的详细解释。

为什么存在单主机 PAWS?

RFC 1323中提到了每主机 PAWS ,如下:

  • 允许旧的重复段过期。为了取代 TIME-WAIT 状态的这一功能,必须有一种跨连接操作的机制。PAWS 严格定义在单个连接内;最后一个时间戳是 TS.Recent 保存在连接控制块中,并在连接关闭时丢弃。
  • 可以向 TCP 添加一个附加机制,即从任何连接接收到的最后时间戳的每主机缓存。然后,如果可以保证时间戳时钟自旧连接打开以来至少已滴答一次,则可以在 PAWS 机制中使用该值来拒绝连接早期版本中的旧重复段。这要求 TIME-WAIT 延迟加上 RTT 必须至少是发送方时间戳时钟的一个刻度。此类扩展不属于本 RFC 提案的一部分。
  • 请注意,这是 Garlick、Rom 和 Postel [Garlick77] 提出的机制的一个变体,该机制要求每个主机维护包含每个连接上的最高序列号的连接记录。如果使用时间戳,则只需为每个远程主机保留一个数量,而不管到该主机的同时连接数是多少。

需要TIME_WAIT的原因在.的代码注释tcp_minisocks.c中也有解释。而PAWS机制,TIME_WAIT快速回收的理论基础如下:

  • TIME-WAIT 状态的主要目的是,当其中一端处于 LAST-ACK 或 CLOSING 重传 FIN(可能还有数据尾部)并且一个或多个 ACK​​ 丢失时,优雅地关闭连接。
  • 什么是TIME-WAIT超时?它与互联网中的最大数据包生存期相关,这会导致错误的结论,即它被设置为捕获偏离其路径的“旧重复段”。这并不完全正确。该超时的计算方式使其超过最大重传超时,足以允许丢失由对等方发送的一个(或多个)分段和我们的 ACK。这个时间可以根据RTO来计算。
  • 当TIME-WAIT套接字收到RST时,意味着另一端终于关闭了,我们也可以杀死TIME-WAIT。
  • TIME-WAIT 的第二个目的是捕获旧的重复段。好吧,这当然是纯粹的偏执,但如果我们用这种语义加载 TIME-WAIT,我们就不能用 RST 杀死 TIME-WAIT 状态。
  • 如果我们发明一些更聪明的方法来捕获重复项(基于 PAWS),我们可以将 TIME-WAIT 截断为多个 RTO。

        根据上面RFC的描述以及内核代码注释,我们可以看出Linux内核对状态实现了快速回收机制TIME-WAIT。Linux可以丢弃60秒的TIME-WAIT时间,直接缩短到RTO时间的3.5倍,因为Linux使用了一些“聪明”的方法来捕获旧的重复数据包(例如,基于PAWS机制)。相比之下,Linux 确实使用每主机 PAWS 来防止先前连接中的数据包被包装到新连接中。

Linux 内核实现

        在tcp_ipv4.c中,在收到 SYN 之前,如果满足以下两个条件,则检查对等体是否经过验证,即执行每主机 PAWS 检查:

  • 接收到的数据包具有 TCP 时间戳选项。
  • 计算机上启用了内核参数net.ipv4.tcp_tw_recycle。
...
else if (!isn) {
/* VJ's idea. We save last timestamp seen
 * from the destination in peer table, when entering
 * state TIME-WAIT, and check against it before
 * accepting new connection request.
 *
 * If "isn" is not zero, this request hit alive
 * timewait bucket, so that all the necessary checks
 * are made in the function processing timewait state.
 */
if (tmp_opt.saw_tstamp &&  // The report contains TCP timestamp option
    tcp_death_row.sysctl_tw_recycle &&  // The net.ipv4.tcp_tw_recyclekernel parameter is enabled.
    (dst = inet_csk_route_req(sk, &fl4, req)) != NULL &&
    fl4.daddr == saddr) {
    if (!tcp_peer_is_proven(req, dst, true)) {  // peer  (per-host PAWS)
        NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_PAWSPASSIVEREJECTED);
        goto drop_and_release;
    }
}

        在tcp_metrics.c中,Linux per-host PAWS 的实现逻辑如下。简单来说,正如本节开头提到的:新的SYN数据包的TCP Timestamps选项需要在60秒内增加。

bool tcp_peer_is_proven(struct request_sock *req, struct dst_entry *dst, bool paws_check)
{
    struct tcp_metrics_block *tm;
    bool ret;
    ...
    
    tm = __tcp_get_metrics_req(req, dst);
    if (paws_check) {
      if (tm &&
          // peer information is saved within 60 seconds (TCP_PAWS_MSL)之内
          (u32)get_seconds() - tm->tcpm_ts_stamp < TCP_PAWS_MSL &&
          // Compared with the timestamp in the current(TCP_PAWS_WINDOW)
          (s32)(tm->tcpm_ts - req->ts_recent) > TCP_PAWS_WINDOW)
        ret = false;
      else
        ret = true;
    }
}

NAT 环境中对客户端的影响

        当这种允许TIME-WAIT状态快速回收的每主机PAWS机制在Linux中实现时,它被设计为基于具有足够数量的IPv4地址池的网络环境的解决方案。然而,随着互联网的快速发展,NAT的应用越来越普遍,客户端在SNAT设备内访问同一台服务器的情况也很常见。

        Per-host PAWS 机制通过 TCP Timestamps 选项字段的增加来确定包装的数据,而时间戳是根据每个客户端的 CPU 滴答数获得的值,可以说在 NAT 设备内是完全随机的。当客户端主机1通过NAT与服务器建立TCP连接,然后服务器关闭并快速回收TIME-WAIT套接字时,其他客户端主机的新连接源IP与服务器对等表中记录的相同,但TCP Timestamps选项是完全随机的或者与主机1当时记录的时间戳相比有50%的概率是随机的。如果时间戳小于主机1的时间戳,则60秒内新连接将被拒绝,60秒后新连接将成功。如果时间戳大于主机1的时间戳,则新连接直接成功。所以,从客户端来看,这个问题的症状就是新连接不稳定。有时可以连接,有时不能连接

        这就是NAT环境下客户端使用TIME-WAIT快速回收机制带来的副作用。这种副作用在每主机 PAWS 机制设计之初就无法预料到,因为当时的网络环境与现在有很大不同。在当前的网络环境下,唯一的建议是禁用TIME-WAIT快速回收,即制作net.ipv4.tcp_tw_recycle=0. 禁用net. ipv4.tcp_timestamps删除 TCP 时间戳选项也可以解决此问题。但由于时间戳是计算RTT和RTO的基础,因此一般不建议禁用。

故障排除

        在实际生产中,排除故障并不容易。但对于同时启用了net.ipv4.tcp_tw_recycle和 的net.ipv4.tcp_timestamps服务器,当服务器有 NAT 客户端访问时,出现此问题的概率非常高,所以如果获取了这两个内核参数的设置以及客户端网络的 NAT 环境,就可以做出基本的判断。

        另外,您可以参考 中的统计数据netstat -s,该统计数据来自/proc/net/snmp/proc/net/netstat/proc/net/sctp/snmp。如下所示,该统计值表示有多少新连接因时间戳而被拒绝。这是历史统计总计,因此两个时间点之间的差异对于故障排除更有意义。

xx passive connections rejected because of time stamp

2. 接受队列已满导致 SYN 数据包丢失

症状

        不存在统一的、有规律的现象。当 TCP 接受队列已满时会发生这种情况。当用户空间应用程序出现问题时,通常会发生这种情况。一般来说,发生的概率不是很高。

原则

        接受队列翻译为全连接队列或者接收队列。新连接经过三次握手后进入接受队列。用户空间应用程序调用accept系统调用来获取连接并创建一个新的套接字,返回与该套接字关联的文件描述符(fd)。在用户空间,可以使用poll等机制,通过可读事件获知已经完成3次握手的新连接已进入accept队列,收到通知后可以立即调用accept系统调用来获取新连接。

        接受队列的长度是有限的。长度取决于 min [backlog, net.core.somaxconn],它是两个参数中较小的一个。

  • Backlog是应用程序调用Listen系统调用时的第二个参数。请参考#include 中的 int Listen(int sockfd, int backlog) 。
  • Net.core.somaxconn 是系统内核参数。默认值为128。当应用程序监听时,如果设置的backlog较大(例如NGINX默认为512),并且全局内核参数没有调整,则accept队列的长度仍然会由较小的net.core.somaxconn决定。

        即使在并发连接数较多的情况下,应用程序正常使用accept系统调用获取accept队列中的连接也不会因为效率问题而被延迟。但是,如果由于应用程序阻塞而未能及时获得连接,则可能会导致接受队列已满,从而导致新的 SYN 数据包被丢弃。

Linux 内核实现

        在tcp_ipv4中,“当接受队列已满时拒绝 SYN 数据包”的实现非常简单,如下:

/* Accept backlog is full. If we have already queued enough
 * of warm entries in syn queue, drop request. It is better than
 * clogging syn queue with openreqs with exponentially increasing
 * timeout.
 */
//If accept queueis full, and SYN queuehas a semi-join that has not been retransmitted by SYNACK, the SYN request is discarded.
if (sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_young(sk) > 1) {
  NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENOVERFLOWS);
  goto drop;
}

在sock.h中,定义了完整接受队列的内联函数:

static inline bool sk_acceptq_is_full(const struct sock *sk)
{
    return sk->sk_ack_backlog > sk->sk_max_ack_backlog;
}

inet_connection_sock.h和request_sock.h中定义了判断SYN队列中是否存在未重传SYNACK的半连接的方法:

static inline int inet_csk_reqsk_queue_young(const struct sock *sk)
{
    return reqsk_queue_len_young(&inet_csk(sk)->icsk_accept_queue);
}

static inline int reqsk_queue_len_young(const struct request_sock_queue *queue)
{
    return queue->listen_opt->qlen_young;
}

        以上是3.10中的实现。其实我们需要判断两个条件:“accept队列是否已满”和“SYN队列是否有没有SYNACK重传的半连接”。当接受队列已满时,通常会存在大量新连接,因此通常会同时满足第二个条件。如果SYN队列没有半连接,即当接受队列满时还没有重传SYNACK,Linux内核仍然接受SYN并返回SYNACK。这种情况在实际生产中很少见,除非应用程序进程完全停止,例如使用SIGSTOP信号停止进程。所以当accept队列满时,TCP内核协议栈仍然不会直接丢弃SYN数据包。

        由于接受队列已满而丢弃 SYN 的逻辑在较新的内核版本中略有变化。例如4.10中,判断条件由2个变为1个,即内核只判断accept队列是否已满。因此,在这些版本中,当接受队列已满时,内核将直接丢弃SYN数据包。

故障排除

        当用户空间应用程序出现问题时,通常会发生这种问题。一般来说,发生的概率不是很高。可以通过以下两种方法来确认该问题:

使用ss命令查看实时问题

        使用 ss 命令的选项 -l 检查监听套接字。显示 Recv-Q 和 Send-Q。Recv-Q表示当前accept队列的总连接数,Send-Q表示accept队列的最大长度。如下所示: 几个进程默认的accept队列是128,因为受到net.core.somaxconn=128系统的限制。

为什么 Linux 内核协议栈会丢弃 SYN 数据包,运营管理,网络编程,Linux,linux,运维,服务器

Netstat -s 统计

        参考netstat -s 中的统计信息。下面的统计值表示由于套接字溢出而被拒绝的新连接数。同样,这也是一个历史统计总计,两个时间点之间的差异对于故障排除更有意义。

xx times the listen queue of a socket overflowed

建议的解决方案

        如果确认SYN包被丢弃是由于accept队列的原因,那么很自然地想到解决办法就是增加accept队列的长度。同时增加backlog和net.core.somaxconn参数可以增加accept队列的长度。

        但一般来说,这种方法只能缓解问题,最有可能的情况是加长的accept队列很快又被填满。因此,解决这个问题的最好方法是检查应用程序,看看为什么它接受新连接的速度这么慢,解决根本原因。

概括

        本博客文章的主体总结了两个主要场景,主要是与云基础设施和服务软件层相关的问题,其中 SYN 由于每主机 PAWS 检查和完整接受队列而被丢弃。这两种情况涵盖了绝大多数 TCP 堆栈丢弃 SYN 的情况。如果其他协议栈出现SYN丢包,则需要结合参数配置和代码逻辑进一步具体排查。

参考

tcp - No SYN-ACK Packet from server - Server Fault

Why Are Linux Kernel Protocol Stacks Dropping SYN Packets - Alibaba Cloud Community文章来源地址https://www.toymoban.com/news/detail-605852.html

到了这里,关于为什么 Linux 内核协议栈会丢弃 SYN 数据包的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 既然有HTTP协议,为什么还要有RPC?

    我想起了我刚工作的时候,第一次接触RPC协议,当时就很懵, 我HTTP协议用得好好的,为什么还要用RPC协议?   于是就到网上去搜。   不少解释显得非常官方,我相信大家在各种平台上也都看到过,解释了又好像没解释,都在 用一个我们不认识的概念去解释另外一个我们不

    2024年02月09日
    浏览(35)
  • 为什么要使用零知识证明来开发跨链协议

    在过去的几年当中出现了各种各样的独立公链以及以太坊 Layer 2。 由于在安全性、低成本、快速交易以及开发者和用户社区差异等方面,不同链都具有各自不同的优势,用户在不同链之间切换使用的行为是很常见的。 比起以太坊链,Layer2 以及其他独立公链上的手续费会更加

    2024年01月19日
    浏览(61)
  • NFT 为什么会有差异,探索底层的铸造协议

    NFT 的流行,让许多人都对它已经不怎么陌生了。但你真正了解过它么?从表面来看,每个 NFT 之间的性质、特点以及属性和功能等都没有多大的差别,当我们深入了解时才会发现,在不同应用领域的 NFT 之间,也有一些细微的不同。是什么导致了这些差异的存在呢?这个问题

    2024年02月15日
    浏览(42)
  • 为什么 HTTPS 协议能保障数据传输的安全性?

    HTTP 协议 在谈论 HTTPS 协议之前,先来回顾一下 HTTP 协议的概念。 HTTP 协议介绍 HTTP 协议是一种基于文本的传输协议,它位于 OSI 网络模型中的应用层。 HTTP 协议是通过客户端和服务器的请求应答来进行通讯,目前协议由之前的 RFC 2616 拆分成立六个单独的协议说明(RFC 7230、

    2024年01月22日
    浏览(51)
  • TCP协议为什么要三次握手而不是两次?

    TCP(Transmission Control Protocol,传输控制协议)的历史可以追溯到1970年代初期,最初的版本是RFC 793,后来经过多次更新和改进,包括RFC 1122、RFC 1323、RFC 2018、RFC 2581、RFC 2873、RFC 3168和RFC 4614等。其中,RFC 1323(TCP Extensions for High Performance)提出了TCP的高性能扩展,RFC 2018(TCP Se

    2024年02月06日
    浏览(49)
  • 为什么客户端和服务器不支持SSL协议

    为什么客户端和服务器不支持SSL协议?这是使用 SSL证书 的用户经常会遇到了一个问题,客户端和服务器不支持SSL协议可能有以下几个原因,大家可以作个参考。 版本不匹配:SSL协议有多个版本,包括过时的SSL 2.0、SSL 3.0和较新的TLS(Transport Layer Security)版本(如TLS 1.0、TLS

    2024年04月25日
    浏览(47)
  • SSL/TLS协议详解 - https为什么比http更安全

    SSL/TLS是世界上应用最广泛的密码通信方法。比如,在网上商城输入信用卡卡号时,Web浏览器就会使用SSL/TLS进行密码通信。使用SSL/TLS可以对通信对象进行认证,还可以确保通信内容的机密性。TLS相当于SSL的后续版本。 SSL (Secure Sockets Layer)安全套接层协议 :由Netscape公司开发

    2024年02月05日
    浏览(48)
  • HTTP协议演进:为什么说HTTP/1.1的时代已经过去了

    前言   欢迎来到今天的每日一题,每日一提。昨天聊到了,HTTP 是什么。有哪些组成部分。并且最后提到了 HTTP 的一些缺点,比如:性能较低,容易导致网络拥塞和延迟,不支持服务器推送等等。设计协议的大佬们,对这样的缺点肯定是不能容忍的,所以 HTTP2 它来了。 什

    2023年04月17日
    浏览(41)
  • 为什么如此安全的https协议却仍然可以被抓包呢?(1)

    好了,阅读到了这里,说明你对https已经非常熟悉了,那么你一定知道,https协议是结合了非对称加密和对称加密一起工作,从而保证数据传输的安全性的。 非对称加密用于确保客户端可以安全地获取到服务器的真实公钥。对称加密用于确保客户端和服务器之间的数据传输不

    2024年04月26日
    浏览(40)
  • Spark重温笔记(三):Spark在企业中为什么能这么强?——持久化、Checkpoint机制、共享变量与内核调度原理全攻略“

    前言:今天是温习 Spark 的第 3 天啦!主要梳理了 Spark 核心数据结构:RDD(弹性分布式数据集),包括RDD持久化,checkpoint机制,spark两种共享变量以及spark内核调度原理,希望对大家有帮助! Tips:\\\"分享是快乐的源泉💧,在我的博客里,不仅有知识的海洋🌊,还有满满的正能量

    2024年04月09日
    浏览(46)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包