当前位置: 首页 > news >正文

CNI 网络分析(九)Calico IPIP

文章目录

  • 环境
  • 流量分析
    • Pod 间
    • Node 到 Pod
    • Pod 到 service
    • Node 到 service
    • NetworkPolicy

理清和观测网络流量

环境

在这里插入图片描述
在这里插入图片描述
可以看到,在宿主机上有到每个 pod IP 的路由指向 veth 设备
到对端节点网段的路由 指向 tunl0 下一跳 ens10 的 ip
有到本节点网段 第一个 ip 即 tunl0 的流量 指向 blackhole,丢弃

流量分析

Pod 间

  • 同 node 不同 pod 之间
    pod1 <-> pod2
  1. 在 pod1 eth0 抓包:
00:37:59.442570 32:21:45:c4:c5:d5 > ee:ee:ee:ee:ee:ee, ethertype IPv4 (0x0800), length 98: 10.244.153.204 > 10.244.153.201: ICMP echo request, id 56616, seq 1, length 64
00:37:59.442707 ee:ee:ee:ee:ee:ee > 32:21:45:c4:c5:d5, ethertype IPv4 (0x0800), length 98: 10.244.153.201 > 10.244.153.204: ICMP echo reply, id 56616, seq 1, length 64

pod1 中下一跳都是 169.254.1.1,且目的 mac 是 ee:ee:ee:ee:ee:ee
2. 在 host 端 calice0906292e2 抓包不变
3. 匹配主机路由 10.244.153.201 dev cali118af4ccd16 scope link 和 neighbor 10.244.153.201 dev calibd2348b4f67 lladdr f2:d4:17:63:9d:3d REACHABLE, 在 cali118af4ccd16 抓包

00:41:07.879975 ee:ee:ee:ee:ee:ee > f2:d4:17:63:9d:3d, ethertype IPv4 (0x0800), length 98: 10.244.153.204 > 10.244.153.201: ICMP echo request, id 56616, seq 185, length 64
00:41:07.879998 f2:d4:17:63:9d:3d > ee:ee:ee:ee:ee:ee, ethertype IPv4 (0x0800), length 98: 10.244.153.201 > 10.244.153.204: ICMP echo reply, id 56616, seq 185, length 64
  1. 在 pod2 内 eth0 抓包:
00:43:59.911019 ee:ee:ee:ee:ee:ee > f2:d4:17:63:9d:3d, ethertype IPv4 (0x0800), length 98: 10.244.153.204 > 10.244.153.201: ICMP echo request, id 56616, seq 353, length 64
00:43:59.911056 f2:d4:17:63:9d:3d > ee:ee:ee:ee:ee:ee, ethertype IPv4 (0x0800), length 98: 10.244.153.201 > 10.244.153.204: ICMP echo reply, id 56616, seq 353, length 64
  • 不同 node 上 pod 之间
    pod1 访问 pod3
    在 veth host 端抓包
20:22:47.858674 32:21:45:c4:c5:d5 > ee:ee:ee:ee:ee:ee, ethertype IPv4 (0x0800), length 98: 10.244.153.204 > 10.244.146.205: ICMP echo request, id 17555, seq 106, length 64
20:22:47.860043 ee:ee:ee:ee:ee:ee > 32:21:45:c4:c5:d5, ethertype IPv4 (0x0800), length 98: 10.244.146.205 > 10.244.153.204: ICMP echo reply, id 17555, seq 106, length 64

看 主机路由 10.244.146.192/26 via 192.168.100.112 dev tunl0 proto bird onlink 下一跳是 tunl0
在 tunl0 上抓包,没有 二层信息。

20:24:42.016898 ip: 10.244.153.204 > 10.244.146.205: ICMP echo request, id 17555, seq 220, length 64
20:24:42.022282 ip: 10.244.146.205 > 10.244.153.204: ICMP echo reply, id 17555, seq 220, length 64

在 业务网卡抓包,可以看到 mac 地址是业务网卡两个端点的 mac。外层 IP 是 业务网卡两个端点的 IP,内层是 icmp 报文。

20:25:41.151109 52:54:00:dc:c7:b4 > 52:54:00:d3:bf:21, ethertype IPv4 (0x0800), length 118: 192.168.100.111 > 192.168.100.112: 10.244.153.204 > 10.244.146.205: ICMP echo request, id 17555, seq 279, length 64
20:25:41.152198 52:54:00:d3:bf:21 > 52:54:00:dc:c7:b4, ethertype IPv4 (0x0800), length 118: 192.168.100.112 > 192.168.100.111: 10.244.146.205 > 10.244.153.204: ICMP echo reply, id 17555, seq 279, length 64

在 对面机器上的报文路径与之对称

Node 到 Pod

  • Node 到本 node 上的 pod
    在 node111 ping pod1
    在 veth host 端抓包,根据路由 10.244.153.204 dev calice0906292e2 scope link,生成报文时拿默认路由网卡的 ip 做源地址
20:15:23.174963 ee:ee:ee:ee:ee:ee > 32:21:45:c4:c5:d5, ethertype IPv4 (0x0800), length 98: 172.18.22.111 > 10.244.153.204: ICMP echo request, id 6, seq 9, length 64
20:15:23.175025 32:21:45:c4:c5:d5 > ee:ee:ee:ee:ee:ee, ethertype IPv4 (0x0800), length 98: 10.244.153.204 > 172.18.22.111: ICMP echo reply, id 6, seq 9, length 64

在 veth 内 eth0 抓包

20:18:23.399015 ee:ee:ee:ee:ee:ee > 32:21:45:c4:c5:d5, ethertype IPv4 (0x0800), length 98: 172.18.22.111 > 10.244.153.204: ICMP echo request, id 6, seq 185, length 64
20:18:23.399049 32:21:45:c4:c5:d5 > ee:ee:ee:ee:ee:ee, ethertype IPv4 (0x0800), length 98: 10.244.153.204 > 172.18.22.111: ICMP echo reply, id 6, seq 185, length 64
  • Node 到其他 node 上的 pod
    node111 到 pod3
    在 node111 tunl0 抓包,根据路由 10.244.146.192/26 via 192.168.100.112 dev tunl0 proto bird onlink,源 IP 为 tunl0 ip
21:10:02.099557 ip: 10.244.153.192 > 10.244.146.205: ICMP echo request, id 11, seq 46, length 64
21:10:02.100595 ip: 10.244.146.205 > 10.244.153.192: ICMP echo reply, id 11, seq 46, length 64

在 ens10 抓包

21:10:18.124555 52:54:00:dc:c7:b4 > 52:54:00:d3:bf:21, ethertype IPv4 (0x0800), length 118: 192.168.100.111 > 192.168.100.112: 10.244.153.192 > 10.244.146.205: ICMP echo request, id 11, seq 62, length 64
21:10:18.129910 52:54:00:d3:bf:21 > 52:54:00:dc:c7:b4, ethertype IPv4 (0x0800), length 118: 192.168.100.112 > 192.168.100.111: 10.244.146.205 > 10.244.153.192: ICMP echo reply, id 11, seq 62, length 64

Pod 到 service

# kubectl get svc
NAME            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
nginx-service   ClusterIP   10.107.161.255   <none>        8080/TCP   2s
# kubectl get endpoints
NAME            ENDPOINTS                             AGE
nginx-service   10.244.146.205:80,10.244.153.201:80   5s
  • Pod 访问 service clusterIP
    在 pod1 veth 对抓包,目的地之为 svcIP
21:27:42.690221 32:21:45:c4:c5:d5 > ee:ee:ee:ee:ee:ee, ethertype IPv4 (0x0800), length 74: 10.244.153.204.38610 > 10.107.161.255.8080: Flags [S], seq 4133783852, win 64800, options [mss 1440,sackOK,TS val 3911662959 ecr 0,nop,wscale 7], length 0
21:27:42.690427 ee:ee:ee:ee:ee:ee > 32:21:45:c4:c5:d5, ethertype IPv4 (0x0800), length 74: 10.107.161.255.8080 > 10.244.153.204.38610: Flags [S.], seq 86025828, ack 4133783853, win 64260, options [mss 1440,sackOK,TS val 1534565294 ecr 3911662959,nop,wscale 7], length 0

在 pod2 veth 对抓包,源地址为 主机默认路由网卡 ip,目的地址为 pod2,目的端口为 80

21:27:42.690366 ee:ee:ee:ee:ee:ee > 2a:e7:de:3f:09:fb, ethertype IPv4 (0x0800), length 74: 10.244.153.204.38610 > 10.244.153.201.80: Flags [S], seq 4133783852, win 64800, options [mss 1440,sackOK,TS val 3911662959 ecr 0,nop,wscale 7], length 0
21:27:42.690404 2a:e7:de:3f:09:fb > ee:ee:ee:ee:ee:ee, ethertype IPv4 (0x0800), length 74: 10.244.153.201.80 > 10.244.153.204.38610: Flags [S.], seq 86025828, ack 4133783853, win 64260, options [mss 1440,sackOK,TS val 1534565294 ecr 3911662959,nop,wscale 7], length 0

去 service dnat 成后端 IP 转到 pod2,pod2 回复 pod1,再 snat 成 svcIP。
后端为 跨节点的 pod3 和上面相同

Node 到 service

  • Node 访问 service clusterIP
    本节点 pod 时
    Dnat 成 pod2 ip,根据默认路由网卡 IP,构造报文
22:07:10.054483 ee:ee:ee:ee:ee:ee > 2a:e7:de:3f:09:fb, ethertype IPv4 (0x0800), length 74: 172.18.22.111.13579 > 10.244.153.201.80: Flags [S], seq 948451555, win 65495, options [mss 65495,sackOK,TS val 519032124 ecr 0,nop,wscale 7], length 0
22:07:10.054534 2a:e7:de:3f:09:fb > ee:ee:ee:ee:ee:ee, ethertype IPv4 (0x0800), length 74: 10.244.153.201.80 > 172.18.22.111.13579: Flags [S.], seq 2350447822, ack 948451556, win 64260, options [mss 1440,sackOK,TS val 319012716 ecr 519032124,nop,wscale 7], length 0

跨节点 pod 时
Dnat 成 pod3 ip,根据路由用 node111 ippool 的 网关去请求

22:07:19.881187 ee:ee:ee:ee:ee:ee > 4e:11:e1:74:9d:6c, ethertype IPv4 (0x0800), length 74: 10.244.153.192.14543 > 10.244.146.205.http: Flags [S], seq 1990644142, win 65495, options [mss 65495,sackOK,TS val 519041957 ecr 0,nop,wscale 7], length 0
22:07:19.881227 4e:11:e1:74:9d:6c > ee:ee:ee:ee:ee:ee, ethertype IPv4 (0x0800), length 74: 10.244.146.205.http > 10.244.153.192.14543: Flags [S.], seq 2030705031, ack 1990644143, win 64260, options [mss 1440,sackOK,TS val 1033275778 ecr 519041957,nop,wscale 7], length 0

外部到 svc
default nginx-service NodePort 10.107.161.255 8080:30080/TCP
在主机被访问 IP 网卡抓包

22:13:00.656471 ac:7e:8a:6c:41:c4 > 52:54:00:ba:dc:62, ethertype IPv4 (0x0800), length 149: 172.20.151.77.47334 > 172.18.22.111.30080: Flags [P.], seq 1:84, ack 1, win 229, options [nop,nop,TS val 430411787 ecr 1033616455], length 83
22:13:00.657729 52:54:00:ba:dc:62 > ac:7e:8a:6c:41:c4, ethertype IPv4 (0x0800), length 66: 172.18.22.111.30080 > 172.20.151.77.47334: Flags [.], ack 84, win 502, options [nop,nop,TS val 1033616544 ecr 430411787], length 
Chain KUBE-NODE-PORT (1 references)
target     prot opt source               destination         
KUBE-MARK-MASQ  tcp  --  0.0.0.0/0            0.0.0.0/0            /* Kubernetes nodeport TCP port for masquerade purpose */ match-set KUBE-NODE-PORT-TCP dst

Masquerade 转为

22:15:32.507099 ee:ee:ee:ee:ee:ee > 2a:e7:de:3f:09:fb, ethertype IPv4 (0x0800), length 74: 172.18.22.111.10229 > 10.244.153.201.80: Flags [S], seq 450784444, win 29200, options [mss 1460,sackOK,TS val 430563700 ecr 0,nop,wscale 7], length 0
22:15:32.507198 2a:e7:de:3f:09:fb > ee:ee:ee:ee:ee:ee, ethertype IPv4 (0x0800), length 74: 10.244.153.201.80 > 172.18.22.111.10229: Flags [S.], seq 3057963543, ack 450784445, win 64260, options [mss 1440,sackOK,TS val 319515169 ecr 430563700,nop,wscale 7], length 0

如果 后端不在本节点
Masquerade 转为

22:31:15.850370 ee:ee:ee:ee:ee:ee > 4e:11:e1:74:9d:6c, ethertype IPv4 (0x0800), length 74: 10.244.153.192.50499 > 10.244.146.205.http: Flags [S], seq 1374007914, win 29200, options [mss 1460,sackOK,TS val 431507052 ecr 0,nop,wscale 7], length 0
22:31:15.850422 4e:11:e1:74:9d:6c > ee:ee:ee:ee:ee:ee, ethertype IPv4 (0x0800), length 74: 10.244.146.205.http > 10.244.153.192.50499: Flags [S.], seq 3861438831, ack 1374007915, win 64260, options [mss 1440,sackOK,TS val 1034711747 ecr 431507052,nop,wscale 7], length 0

NetworkPolicy

为 pod1 打上 role == pod1
为 pod2,pod3 打上 app == nginx

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:name: allow-tcp-80namespace: default
spec:selector: app == 'nginx'ingress:- action: Allowprotocol: TCPsource:selector: role == 'pod1'destination:ports:- 80

应用后查看 iptables 流程

# iptables -nL
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
cali-OUTPUT  all  --  0.0.0.0/0            0.0.0.0/0            /* cali:tVnHkvAo15HuiPy0 */
// 下的是 ingress,则在宿主机上看到的是 Output chain,发给 pod 时的规则Chain cali-OUTPUT (1 references)
target     prot opt source               destination         
cali-forward-endpoint-mark  all  --  0.0.0.0/0            0.0.0.0/0           [goto]  /* cali:5Z67OUUpTOM7Xa1a */ mark match ! 0x0/0xfff00000Chain cali-forward-endpoint-mark (1 references)
target     prot opt source               destination         
cali-to-wl-dispatch  all  --  0.0.0.0/0            0.0.0.0/0            /* cali:aFl0WFKRxDqj8oA6 */Chain cali-to-wl-dispatch (2 references)
target     prot opt source               destination         
cali-tw-calibd2348b4f67  all  --  0.0.0.0/0            0.0.0.0/0           [goto]  /* cali:m9Fd7J2kx1zys3Gw */Chain cali-tw-calibd2348b4f67 (1 references)
target     prot opt source               destination         
MARK       all  --  0.0.0.0/0            0.0.0.0/0            /* cali:GqobtmvaGkGX_I6Q */ /* Start of policies */ MARK and 0xfffdffff
cali-pi-_w6c3i7lsXCdtfGqcxq5  all  --  0.0.0.0/0            0.0.0.0/0            /* cali:Ew7qVfwras3_yV_L */ mark match 0x0/0x20000Chain cali-pi-_w6c3i7lsXCdtfGqcxq5 (1 references)
target     prot opt source               destination         
MARK       tcp  --  0.0.0.0/0            0.0.0.0/0            /* cali:O4FzgAjAMQ8CsxAM */ /* Policy default/default.allow-tcp-80 ingress */ match-set cali40s:SPeglQlTBmfidv00S2cBaDC src multiport dports 80 MARK or 0x10000
// 匹配策略的打 mark 0x10000 accept

相关文章:

CNI 网络分析(九)Calico IPIP

文章目录环境流量分析Pod 间Node 到 PodPod 到 serviceNode 到 serviceNetworkPolicy理清和观测网络流量环境 可以看到&#xff0c;在宿主机上有到每个 pod IP 的路由指向 veth 设备 到对端节点网段的路由 指向 tunl0 下一跳 ens10 的 ip 有到本节点网段 第一个 ip 即 tunl0 的…...

分布式任务调度(XXL-JOB)

什么是分布式任务调度&#xff1f; 任务调度顾名思义&#xff0c;就是对任务的调度&#xff0c;它是指系统为了完成特定业务&#xff0c;基于给定时间点&#xff0c;给定时间间隔或者给定执行次数自动执行任务。通常任务调度的程序是集成在应用中的&#xff0c;比如&#xff1a…...

Django框架之模型视图--Session

Session 1 启用Session Django项目默认启用Session。 可以在settings.py文件中查看&#xff0c;如图所示 如需禁用session&#xff0c;将上图中的session中间件注释掉即可。 2 存储方式 在settings.py文件中&#xff0c;可以设置session数据的存储方式&#xff0c;可以保存…...

二极管的“几种”应用

不知大家平时有没有留意&#xff0c;二极管的应用范围是非常广的&#xff0c;下面我们来看看我想到几种应用&#xff0c;也可以加深对电路设计的认识&#xff1a; A&#xff0c;特性应用&#xff1a; 由于二极管的种类非常之多&#xff0c;这里这个大类简单罗列下&#xff1a…...

github上传本地文件详细过程

repository 也就是俗称的仓库 声明&#xff1a;后续操作基于win10系统 前提&#xff1a;有一个github账号、电脑安装了git(官方安装地址) 目的&#xff1a; 把图中pdf文件上传到github上的个人仓库中 效果&#xff1a; 温馨提示&#xff1a; git中复制: ctrl insert&#xf…...

常用聚类算法分析

1. 什么是聚类 1.1. 聚类的定义 聚类(Clustering)是按照某个特定标准(如距离)把一个数据集分割成不同的类或簇&#xff0c;使得同一个簇内的数据对象的相似性尽可能大&#xff0c;同时不在同一个簇中的数据对象的差异性也尽可能地大。也即聚类后同一类的数据尽可能聚集到一起…...

OSG三维渲染引擎编程学习之五十八:“第五章:OSG场景渲染” 之 “5.16 简单光源”

目录 第五章 OSG场景渲染 5.16 简单光源 5.16.1 场景中使用光源 5.16.2 简单光源示例 第五章 OSG场景渲染 OSG存在场景树和渲染树,“场景数”的构建在第三章“OSG场景组...

80211无线网络架构

无线网络架构物理组件BSS&#xff08;Basic Service Set&#xff09;基本服务集BSSID&#xff08;BSS Identification&#xff09;ssid&#xff08;Service Set Identification&#xff09;ESS&#xff08;Extended Service Set&#xff09;扩展服务集物理组件 无线网络包含四…...

基于springboot+vue的便利店库存管理系统

基于springbootvue的便利店库存管理系统 ✌全网粉丝20W,csdn特邀作者、博客专家、CSDN新星计划导师、java领域优质创作者,博客之星、掘金/华为云/阿里云/InfoQ等平台优质作者、专注于Java技术领域和毕业项目实战✌ &#x1f345;文末获取项目下载方式&#x1f345; 一、项目背景…...

3|物联网控制|计算机控制-刘川来胡乃平版|第1章:绪论|青岛科技大学课堂笔记|U1 ppt

目录绪论&#xff08;2学时&#xff09;常用仪表设备&#xff08;3学时&#xff09;计算机总线技术&#xff08;4学时&#xff09;过程通道与人机接口&#xff08;6学时&#xff09;数据处理与控制策略&#xff08;6学时&#xff09;网络与通讯技术&#xff08;3学时&#xff0…...

js打印本地pdf(使用HttpPrinter打印插件)

js打印本地pdf&#xff08;使用HttpPrinter打印插件&#xff09;第一步&#xff1a;启动HttpPrinter打印插件第二步&#xff1a;用浏览器打开示例文件\调用示例\websocket协议示例\html\打印pdf.html输入pdf地址 点击 “下载并打印pdf文件”按钮&#xff0c;就可以静默打印了。…...

华为OD机试 - 双十一(Python) | 机试题算法思路 【2023】

最近更新的博客 【新解法】华为OD机试 - 关联子串 | 备考思路,刷题要点,答疑,od Base 提供【新解法】华为OD机试 - 停车场最大距离 | 备考思路,刷题要点,答疑,od Base 提供【新解法】华为OD机试 - 任务调度 | 备考思路,刷题要点,答疑,od Base 提供【新解法】华为OD机试…...

2020年UML 秋季期末测试题

1.UML的全称是&#xff08;B &#xff09;。A.Unified Making LanguageB.Unified Modeling LanguageC.Unified Meodem languageD.Unify Modeling Language2.UML主要应用于&#xff08; C&#xff09;。A.基于螺旋模型的结构化开发方法B.基于数据的数据流开发方法C.基于对象的面…...

SpringCloud - Ribbon负载均衡

目录 负载均衡流程 负载均衡策略 Ribbon加载策略 负载均衡流程 Ribbon将http://userservice/user/1请求拦截下来&#xff0c;帮忙找到真实地址http://localhost:8081LoadBalancerInterceptor类对RestTemplate的请求进行拦截&#xff0c;然后从Eureka根据服务id获取服务列表&…...

Spring Boot + Redis 实现分布式锁

一、业务背景有些业务请求&#xff0c;属于耗时操作&#xff0c;需要加锁&#xff0c;防止后续的并发操作&#xff0c;同时对数据库的数据进行操作&#xff0c;需要避免对之前的业务造成影响。二、分析流程使用 Redis 作为分布式锁&#xff0c;将锁的状态放到 Redis 统一维护&a…...

CAD二次开发 插件初始化接口IExtensionApplication

前言&#xff1a;在实际项目开发中&#xff0c;我们总会遇到一些问题。比如说在CAD打开之前&#xff0c;修改注册表的内容&#xff0c;或者解决CAD在没有完全加载想要的dll情况下&#xff0c;功能运行报错的bug。因此&#xff0c;下面和大家介绍一下IExtensionApplication接口 …...

kafka-11-kafka的监控工具和常用配置参数

kafka官方文档 参考Kafka三款监控工具比较 1 查看kafka的版本 进入kafka所在目录&#xff0c;通过查看libs目录下的jar包。 2.11是scala的版本&#xff0c;2.0.0是kafka的版本。 测试环境 #systemctl start zookeeper #systemctl start kafkka 2 kafka的常用配置 Kafka使用…...

前端PWA渐进式加载技术

1.什么是PWA&#xff1f; 渐进式网络应用&#xff08;PWA&#xff09;是谷歌在2015年底提出的概念。基本上算是web应用程序&#xff0c;但在外观和感觉上与原生app类似。支持PWA的网站可以提供脱机工作、推送通知和设备硬件访问等功能。 2.PWA有那些优点&#xff1f; 更小更…...

【ubuntu 22.04不识别ch340串口】

这个真是挺无语的&#xff0c;发现国内厂商普遍对开源环境不感兴趣&#xff0c;ch340官方linux驱动好像被厂家忘了&#xff0c;现在放出来的驱动还是上古内核版本&#xff1a; 于是&#xff0c;驱动居然要用户自己编译安装。。还好网上有不少大神&#xff1a;链接&#xff0c;…...

解决:eclipse绿化版Resource注解报Resource cannot be resolved to a type问题

如图&#xff1a; 网上解决教程很多&#xff0c;我的eclipse是绿化版的&#xff0c;不需要安装 解决办法如下&#xff1a; 1、在eclipse中&#xff0c;进入到Window->Preferences->Java->Installed JREs中 默认显示如下&#xff1a; 2、点击Add-->Standard VM--…...

RK3576开发板PCIE NVMe SSD扩展实战:从硬件连接到性能优化

1. 项目概述&#xff1a;当开发板遇上高性能存储 最近在折腾一块基于瑞芯微RK3576的开发板&#xff0c;这玩意儿性能确实不错&#xff0c;四核A55加上一个独立的NPU&#xff0c;跑一些边缘计算和轻量级AI推理任务绰绰有余。但玩着玩着就发现一个问题&#xff1a;板载的eMMC存储…...

面向高校的基于算法的发明专利申请写作方法

发明专利作为国家和高校认可的成果形式之一&#xff0c;其申请和授权一直受到教师和学生们的高度重视&#xff1b;基于算法的发明专利作为发明专利的重要分支&#xff0c;每年都有大量的算法专利被授权或者拒绝。虽然高校的教师对论文写作非常熟悉&#xff0c;但是发明专利的写…...

初创团队如何利用Taotoken的多模型聚合能力低成本验证产品创意

&#x1f680; 告别海外账号与网络限制&#xff01;稳定直连全球优质大模型&#xff0c;限时半价接入中。 &#x1f449; 点击领取海量免费额度 初创团队如何利用Taotoken的多模型聚合能力低成本验证产品创意 对于资源有限的初创团队而言&#xff0c;在产品早期验证阶段&#…...

OpenCV 4.x/5.x 在Ubuntu 22.04上安装后,CMake项目死活找不到库?一个环境变量就搞定

OpenCV 4.x/5.x 在Ubuntu 22.04上安装后CMake项目找不到库的终极解决方案 当你满怀期待地在Ubuntu 22.04上安装了最新版的OpenCV&#xff0c;准备开始你的计算机视觉项目时&#xff0c;却遭遇了CMake无法找到OpenCV库的尴尬局面。这种"明明安装了却找不到"的情况&…...

嵌入式开发中的模拟信号处理:ADC、DAC与PWM核心原理与CircuitPython实战

1. 项目概述&#xff1a;从数字世界到物理世界的桥梁在嵌入式开发的世界里&#xff0c;我们写的代码最终是要和物理世界打交道的。物理世界是连续的、模拟的——光线强弱、温度高低、声音大小&#xff0c;这些都不是简单的“开”或“关”&#xff0c;而是平滑变化的连续量。而我…...

基于Claude API的视频转录技能开发:从语音识别到AI集成实战

1. 项目概述&#xff1a;一个为Claude设计的视频转录技能最近在折腾AI应用开发&#xff0c;特别是围绕Claude API构建一些实用工具。我发现一个挺有意思的项目&#xff0c;叫Johncli7941/claude-skill-video-transcribe。从名字就能看出来&#xff0c;这是一个为Claude设计的“…...

基于MCP协议构建Python文档智能查询服务器,提升AI编程助手准确性

1. 项目概述&#xff1a;一个为Python开发者量身定制的文档智能助手如果你和我一样&#xff0c;每天大部分时间都在和Python代码打交道&#xff0c;那你肯定也经历过这样的场景&#xff1a;为了查一个函数的参数顺序&#xff0c;或者确认某个库的版本兼容性&#xff0c;不得不频…...

Perplexity搜索响应延迟超800ms?紧急修复手册:从LLM路由策略到本地缓存穿透的5层优化路径

更多请点击&#xff1a; https://intelliparadigm.com 第一章&#xff1a;Perplexity搜索响应延迟超800ms&#xff1f;紧急修复手册&#xff1a;从LLM路由策略到本地缓存穿透的5层优化路径 当Perplexity风格的语义搜索接口P95延迟持续突破800ms&#xff0c;用户会感知明显卡顿…...

Python 代码优化:核心技巧与模式

Python 代码优化&#xff1a;核心技巧与模式 1. 技术分析 1.1 代码优化原则 代码优化需要遵循以下原则&#xff1a; 优化原则先测量后优化: 避免盲目优化保持可读性: 不要为了性能牺牲代码质量优先算法优化: 算法层面的优化效果最显著考虑空间换时间: 合理使用缓存1.2 常见性能…...

TimerBlox:基于电流基准的硬件定时新方案,替代555与MCU

1. 项目概述&#xff1a;重新认识定时电路的设计范式在嵌入式系统、电源管理、电机控制乃至各类信号发生器的设计中&#xff0c;定时功能几乎无处不在。无论是生成一个精确的PWM波去调节LED亮度&#xff0c;还是产生一个可调的时钟信号驱动VCO&#xff0c;亦或是需要一个精准的…...