Docker桥接网络分析

news2024/10/6 2:25:37

前言

《虚拟局域网(VLAN)》一文中描述了虚拟网卡、虚拟网桥的作用，以及通过iptables实现了vlan联网，其实学习到这里自然就会联想到目前主流的容器技术：Docker，因此接下来打算研究一下Docker的桥接网络与此有何异同。

猜测

众所周知，Docker有host、bridge、none三种网络模式，这里我们仅分析桥接(bridge)模式。有了上一篇文章的基础，bridge这个概念我们应该已经熟悉了，bridge网桥是一种基于mac地址在数据链路层进行数据交换的一个虚拟交换机。

所以我们现在可以大胆的进行猜测：Docker也是基于此模式实现了内部网络通信。

  • 猜测一：Docker引擎在创建容器的时候会自动为容器创建一对虚拟网卡(veth)并为其分配私有ip，然后将veth一端连接在docker0网桥中，另一端连接在容器的内部网络中
  • 猜测二：Docker同样利用iptables的nat能力将容器内流量转发至互联网实现通信。

求证

检查主机网卡列表

检查docker容器及网卡列表，观察是否存在docker网桥以及veth。

shell
# 查看本机正在运行的coekr容器(mysql、redis、halo、debian)
[root@VM-8-10-centos ~]# docker ps 
CONTAINER ID   IMAGE                COMMAND                  CREATED         STATUS         PORTS                                                  NAMES
56ffaf39316a   debian               "bash"                   23 hours ago    Up 7 minutes                                                          debian
c8a273ce122e   halohub/halo:1.5.3   "/bin/sh -c 'java -X…"   5 months ago    Up 47 hours    0.0.0.0:8090->8090/tcp, :::8090->8090/tcp              halo
d09fcfa7de0f   redis                "docker-entrypoint.s…"   12 months ago   Up 5 weeks     0.0.0.0:8805->6379/tcp, :::8805->6379/tcp              redis
87a2192f6db4   mysql:5.7            "docker-entrypoint.s…"   2 years ago     Up 5 weeks     0.0.0.0:3306->3306/tcp, :::3306->3306/tcp, 33060/tcp   mysql
# 检查主机网卡列表(确认docker0、veth存在)
[root@VM-12-15-centos ~]# ip link 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:b3:6f:20 brd ff:ff:ff:ff:ff:ff
    altname enp0s5
    altname ens5
3: br-67cf5bfe7a5c: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether 02:42:c5:07:22:c7 brd ff:ff:ff:ff:ff:ff
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:38:d6:1b:ea brd ff:ff:ff:ff:ff:ff
5: br-9fd151a807e7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether 02:42:35:7f:ed:76 brd ff:ff:ff:ff:ff:ff
315: vethf2afb37@if314: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-67cf5bfe7a5c state UP mode DEFAULT group default 
    link/ether 3a:06:f0:8d:06:f6 brd ff:ff:ff:ff:ff:ff link-netnsid 12
317: veth1ec30f9@if316: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-9fd151a807e7 state UP mode DEFAULT group default 
    link/ether 4a:ad:1a:b0:5a:5f brd ff:ff:ff:ff:ff:ff link-netnsid 0
319: vethc408286@if318: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-67cf5bfe7a5c state UP mode DEFAULT group default 
    link/ether 26:b0:3c:f4:c5:5b brd ff:ff:ff:ff:ff:ff link-netnsid 1
321: veth68fb8c6@if320: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-67cf5bfe7a5c state UP mode DEFAULT group default 
    link/ether 96:ca:a9:42:f8:a8 brd ff:ff:ff:ff:ff:ff link-netnsid 9
323: veth6dba394@if322: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-67cf5bfe7a5c state UP mode DEFAULT group default 
    link/ether 92:1c:5e:9c:a2:b3 brd ff:ff:ff:ff:ff:ff link-netnsid 4
325: veth1509ed0@if324: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-67cf5bfe7a5c state UP mode DEFAULT group default 
    link/ether fa:22:33:da:12:e0 brd ff:ff:ff:ff:ff:ff link-netnsid 11
329: vethef1dbac@if328: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-67cf5bfe7a5c state UP mode DEFAULT group default 
    link/ether aa:db:d2:10:36:60 brd ff:ff:ff:ff:ff:ff link-netnsid 3
331: veth69d3e7d@if330: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-67cf5bfe7a5c state UP mode DEFAULT group default 
    link/ether 86:45:d0:0e:6b:a7 brd ff:ff:ff:ff:ff:ff link-netnsid 5
335: veth98588ae@if334: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-67cf5bfe7a5c state UP mode DEFAULT group default 
    link/ether 86:59:55:39:17:ad brd ff:ff:ff:ff:ff:ff link-netnsid 7
349: vetha84d717@if348: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-67cf5bfe7a5c state UP mode DEFAULT group default 
    link/ether ee:7f:d2:27:15:83 brd ff:ff:ff:ff:ff:ff link-netnsid 6
354: veth1@if355: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-mybridge state UP mode DEFAULT group default qlen 1000
    link/ether 72:c8:9e:24:a6:a3 brd ff:ff:ff:ff:ff:ff link-netns n1
356: br-mybridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 72:c8:9e:24:a6:a3 brd ff:ff:ff:ff:ff:ff

使用ip link查看本机网卡列表，可以发现宿主机存在一个名为docker0的虚拟网桥，且虚拟网桥下有四对虚拟网卡分别对应 debian、halo、redis、mysql四个docker容器。

检查网桥ip及Docker内部容器的网络通信

shell
# docker0默认网桥的IP地址为172.17.0.1/16
[root@VM-8-10-centos ~]# ip addr show docker0
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:6f:d7:19:7e brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:6fff:fed7:197e/64 scope link 
       valid_lft forever preferred_lft forever
# 检查桥接网络内部容器的ip地址(分别为172.17.0.2/16、172.17.0.3/16、172.17.0.4/16、172.17.0.5/16)       
[root@VM-8-10-centos ~]# docker network inspect bridge
[
    {
        "Name": "bridge",
        "Id": "2dc75e446719be8cad37e1ea9ae7d1385fcc728b8177646a3c62929c2b289e94",
        "Created": "2024-04-24T09:46:14.399901891+08:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.17.0.0/16",
                    "Gateway": "172.17.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "56ffaf39316ac9f776c6b3e2a8a79e9f42dfab42aa1f7de7525bd26c686defaa": {
                "Name": "debian",
                "EndpointID": "47dd9441d4a4c8b09afea3bca23652b80ba35e6baa13d44ec21ec89522e722a6",
                "MacAddress": "02:42:ac:11:00:05",
                "IPv4Address": "172.17.0.5/16",
                "IPv6Address": ""
            },
            "87a2192f6db48c9bf2996bf25c79d4c18c3ae2975cac9d55e7fdfdcec03f896b": {
                "Name": "mysql",
                "EndpointID": "00b93de23c5abf2ed1349bac1c2ec93bf7ed516370dabf23348b980f19cfaa9c",
                "MacAddress": "02:42:ac:11:00:02",
                "IPv4Address": "172.17.0.2/16",
                "IPv6Address": ""
            },
            "c8a273ce122ef5479583908f40898141a90933a3c41c8028dc7966b9af4c465d": {
                "Name": "halo",
                "EndpointID": "ba8ef83c80f3edb6e7987c95ae6d56816a1fc00d07e8bb2bfbb0f19ef543badf",
                "MacAddress": "02:42:ac:11:00:04",
                "IPv4Address": "172.17.0.4/16",
                "IPv6Address": ""
            },
            "d09fcfa7de0f2a7b3ef7927a7e53a8a53fb93021b119b1376fe4616381c5a57c": {
                "Name": "redis",
                "EndpointID": "afbc9128f7d27becfbf64e843a92d36ce23800cd42c131e550abea7afb6a131e",
                "MacAddress": "02:42:ac:11:00:03",
                "IPv4Address": "172.17.0.3/16",
                "IPv6Address": ""
            }
        },
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    }
] 
# 进入debian容器测试内部网络通信和互联网通信
[root@VM-8-10-centos ~]# docker exec -it debian /bin/bash
root@56ffaf39316a:/# ping 172.17.0.1
PING 172.17.0.1 (172.17.0.1) 56(84) bytes of data.
64 bytes from 172.17.0.1: icmp_seq=1 ttl=64 time=0.071 ms
64 bytes from 172.17.0.1: icmp_seq=2 ttl=64 time=0.036 ms
--- 172.17.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.036/0.053/0.071/0.017 ms
root@56ffaf39316a:/# ping 172.17.0.3
PING 172.17.0.3 (172.17.0.3) 56(84) bytes of data.
64 bytes from 172.17.0.3: icmp_seq=1 ttl=64 time=0.067 ms
64 bytes from 172.17.0.3: icmp_seq=2 ttl=64 time=0.047 ms
--- 172.17.0.3 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.047/0.057/0.067/0.010 ms
root@56ffaf39316a:/# ping baidu.com
PING baidu.com (39.156.66.10) 56(84) bytes of data.
64 bytes from 39.156.66.10 (39.156.66.10): icmp_seq=1 ttl=247 time=59.0 ms
64 bytes from 39.156.66.10 (39.156.66.10): icmp_seq=2 ttl=247 time=55.4 ms
--- baidu.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 55.400/57.221/59.043/1.821 ms
小结

通过shell的结果分析：docker0网桥的ip为172.17.0.1/16，docker0各子网通信正常，并且通过ping baidu.com检查了互联网通信也正常。因此可以得出docker桥接模式与前一章中vlan模式是一致的，都是通过一个虚拟网桥实现了内部网络的通信。

docker内部通信脉络图

Docker容器与互联网进行通信

在上一章节中不小心留了个坑，因为firewalld在iptables中内置了很多的规则，所以对于流量的分析很不友好，所以我索性直接关闭了firewalld，但是紧接着就发现这样做有一个副作用：firewalld关闭后，iptables也会被清空。当时不觉得有什么影响，现在仔细回想了一下vlan之所以能够连接互联网，很大一部分原因是利用了iptables的nat功能，iptables被清空，意味着nat功能被关闭了，所以利用此功能的应用会失去网络连接。下面使用shell命令来模拟并分析此现象。

shell
# 关闭firewalld
[root@VM-8-10-centos ~]# systemctl stop firewalld
# 检查iptables
[root@VM-8-10-centos ~]# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
[root@VM-8-10-centos ~]# iptables -t nat -nvL
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination 
# 检查debian容器互联网连接情况 
[root@VM-8-10-centos ~]# docker exec -it debian /bin/bash
root@56ffaf39316a:/# ping baidu.com
PING baidu.com (110.242.68.66) 56(84) bytes of data.
--- baidu.com ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4000ms
# 检查内部网络连接情况
root@56ffaf39316a:/# ping 172.17.0.1
PING 172.17.0.1 (172.17.0.1) 56(84) bytes of data.
64 bytes from 172.17.0.1: icmp_seq=1 ttl=64 time=0.041 ms
64 bytes from 172.17.0.1: icmp_seq=2 ttl=64 time=0.046 ms
--- 172.17.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.041/0.043/0.046/0.002 ms
root@56ffaf39316a:/# ping 172.17.0.2
PING 172.17.0.2 (172.17.0.2) 56(84) bytes of data.
64 bytes from 172.17.0.2: icmp_seq=1 ttl=64 time=0.081 ms
64 bytes from 172.17.0.2: icmp_seq=2 ttl=64 time=0.055 ms
--- 172.17.0.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.055/0.068/0.081/0.013 ms

通过清空iptables发现docker容器内部确实丢失了互联网连接，但是没有影响内部网络的通信。

手动添加nat记录恢复Docker容器与互联网的通信
# 添加snat记录
[root@VM-8-10-centos ~]# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# 检查debian容器互联网连接情况 
[root@VM-8-10-centos ~]# docker exec -it debian /bin/bash
root@56ffaf39316a:/# ping baidu.com
PING baidu.com (39.156.66.10) 56(84) bytes of data.
64 bytes from 39.156.66.10 (39.156.66.10): icmp_seq=1 ttl=247 time=55.8 ms
64 bytes from 39.156.66.10 (39.156.66.10): icmp_seq=2 ttl=247 time=55.4 ms
--- baidu.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 55.386/55.610/55.834/0.224 ms

个人总结: docker容器与互联网进行通信时确实依赖iptables，且行为上与vlan几乎一致，因此我认为Docker其实是vlan+iptables一种高级应用。
docker容器互联网通信脉络图

思考

docker容器内的网络通信是否也基于二层协议进行数据交换？

基于之前对vlan的了解，明白了bridge是一种工作在"数据链路层"，根据mac地址交换数据帧的虚拟交换机，既然工作在二层，那么意味着它在进行数据交换时是没有ip概念的，仅仅是按照mac地址转发数据帧。既然如此，那么即使删除了它的ip地址和路由表，应该也可以完成数据交换。

[root@VM-8-10-centos ~]# ip addr del 172.17.0.1/16 dev docker0
[root@VM-8-10-centos ~]# ip addr show docker0
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:6f:d7:19:7e brd ff:ff:ff:ff:ff:ff
    inet6 fe80::42:6fff:fed7:197e/64 scope link 
       valid_lft forever preferred_lft forever
[root@VM-8-10-centos ~]# docker exec -it debian /bin/bash
root@56ffaf39316a:/# ping 172.17.0.3 
PING 172.17.0.3 (172.17.0.3) 56(84) bytes of data.
64 bytes from 172.17.0.3: icmp_seq=1 ttl=64 time=0.066 ms
64 bytes from 172.17.0.3: icmp_seq=2 ttl=64 time=0.049 ms
--- 172.17.0.3 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.049/0.057/0.066/0.008 ms

iptables与路由表有何联系和区别？谁决定了流量的出口网卡？

学习vlan的时候就存在一个疑惑：**虚拟网桥进行互联网通信时，将流入网桥的流量转发到出口网卡是由谁决定的？**当时做vlan的nat通信时，因为需要在iptables中配置FORWARD及NAT规则，自然而然的会认为是iptables实现的。如此的话，那么路由表存在的意义又是什么呢？**所以到底是iptables实现了流量转发，还是路由表(ip route)实现了流量转发？**或者具体点讲：是谁将流量从docker0网卡转发到eth0网卡？

具体过程需要深入分析iptables的工作原理，这里就不再赘述了，直接给出个人结论仅供参考。

个人结论：路由表不对流量做任何更改，仅仅用来确定数据包的出口网卡，iptables可以对ip数据包进行过滤、修改、转发，但最终还是由路由表确定出口网卡。

即使没有snat，数据包是不是应该也可以到达对方网络？

在互联网中基于ip协议进行通信的流量都会被标注源地址和目的地址，目的地址决定了流量应该如何发送给对方主机，源地址决定了其他主机如何区分数据包是由谁发送的。而SNAT的核心概念是通过转换源地址的方式进行工作的，这是否意味着即使不配置snat，数据包依然可以到达对方网络，只是对方网络无法回复。

# 假设我有两台具有公网ipv4地址的云服务器xxx.xxx.xxx.xx1和xxx.xxx.xxx.xx2。xx1局域网内有另一台主机x10

# xx1主机
# 使用snat将源ip由xx1转换为xx2
[root@VM-8-10-centos ~]# iptables -t nat -A POSTROUTING -s xx1 -o eth0 -j SNAT --to-source xxx.xxx.xxx.x10
# 监听eth0网卡的icmp数据包
[root@VM-8-10-centos ~]# tcpdump -i eth0 -p icmp -nv | grep x10

# xx2主机
# 监听eth0网卡的icmp数据包
[root@VM-8-10-centos ~]# tcpdump -i eth0 -p icmp -nv

根据tcpdump抓包分析xx1确实发送了源地址为x10的数据包，但是从xx2主机的监听结果看并没有收到来自xx1或来自x10发送的数据包。或许是数据包在中途路由的过程中被丢弃了，又或者是我理解错了??

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

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

相关文章

react基础学习 JSX

react基础学习 JSX

JSX的测试网站 Babel Babel 可以测试代码的效果 JSX实现map列表 注意 key不一样&#xff08;使用遍历的时候&#xff09; 简单条件渲染 复杂条件渲染 绑定事件 function App() {const colorse (e)>{console.log("测试点击",e);}const colorse1 (name)>{…
阅读更多...
月入30000的软件测试人员，简历是什么样子的？

月入30000的软件测试人员，简历是什么样子的？

我们都知道&#xff0c;简历是一个人进入职场的敲门砖。从某种层面来说&#xff0c;简历也像一个人的具象身份证&#xff0c;或者专业资格证。所以&#xff0c;一份简历的好坏&#xff0c;不仅关乎个人的“脸面”&#xff0c;更关乎你是不是一个有“含金量”的技术人员。 所以…
阅读更多...
Python爬虫协程批量下载图片

Python爬虫协程批量下载图片

import aiofiles import aiohttp import asyncio import requests from lxml import etree from aiohttp import TCPConnectorclass Spider:def __init__(self, value):# 起始urlself.start_url value# 下载单个图片staticmethodasync def download_one(url):name url[0].spl…
阅读更多...
Docker容器开启特权模式

Docker容器开启特权模式

一、问题 1、容器系统中无法使用systemctl命令 即使是开了特权模式&#xff08;--privileged&#xff09; 2、无法通过/sbin/init启动容器 要想在容器中使用systemctl命令&#xff0c;除了要指定--privileged参数外&#xff0c;还需要指定启动参数为/sbin/init&#xff0c;但…
阅读更多...
关于protobuf import 在idea中报红色错误解决

关于protobuf import 在idea中报红色错误解决

首先安装protobuf 插件 protocol 文件引入别的protocol 时报红原因在插件的设置&#xff0c;它并不知道去哪找&#xff0c;只需要配置下protobuf的所在目录即可
阅读更多...
【成品设计】基于单片机的智慧交通控制系统设计

【成品设计】基于单片机的智慧交通控制系统设计

《基于单片机的智慧交通控制系统设计》 所需器件&#xff1a; STM32最小系统板。按键模块。红黄绿LED灯柱。距离传感器。OLED屏幕。语音识别模块。 整体功能&#xff1a; 本文介绍了一种基于单片机的智慧交通控制系统设计。该系统集成了多种传感器、控制器和执行器&#xf…
阅读更多...
【成品设计】基于USB接口的指纹图像采集与处理系统设计

【成品设计】基于USB接口的指纹图像采集与处理系统设计

《基于USB接口的指纹图像采集与处理系统设计》 所需器件&#xff1a; STM32F429阿波罗开发板。ATK-AS608 模块指纹识别模块。USB转TTL模块。 整体功能&#xff1a; 实现指纹的采集录入。实现指纹的对比&#xff0c;并展示对比结果&#xff0c;用LED灯和蜂鸣器提示。指纹信息…
阅读更多...
云原生下的数据协调艺术：etcd存储系统解析

云原生下的数据协调艺术：etcd存储系统解析

目录 一、分布式存储简介 二、etcd介绍 三、etcd架构 四、etcd集成实践 一、分布式存储简介 随着云原生与容器化技术的兴起&#xff0c;分布式系统的复杂性大大增加。分布式系统面临一系列问题&#xff0c;比如部署复杂、响应时间慢、运维复杂等&#xff0c;其中最根本的问…
阅读更多...
MySQL数据库整体知识点简述

MySQL数据库整体知识点简述

目录 第一章&#xff1a;数据库系统概述 第二章&#xff1a;信息与数据模型 第3章 关系模型与关系规范化理论 第四章——数据库设计方法 第六-七章——MySQL存储引擎与数据库操作管理 第九章——索引 第10章——视图 第11章——MySQL存储过程与函数 第12章——MySQL 触…
阅读更多...
神工坊夏日知识问答｜辨“麦克斯韦妖”，赢百元好礼！

神工坊夏日知识问答｜辨“麦克斯韦妖”，赢百元好礼！

神工坊知识问答 辨“麦克斯韦妖”&#xff0c;赢百元好礼&#xff01; 科普时间到&#xff01; 中国古代传说有四大神兽 分别是青龙、白虎、朱雀和玄武 那你知道物理学中也有“四大神兽”吗&#xff1f; 它们分别是芝诺的乌龟、拉普拉斯兽 麦克斯韦妖和薛定谔的猫 芝诺的…
阅读更多...
【Vue】组件通信

【Vue】组件通信

文章目录 一、组件之间如何通信二、组件关系分类三、通信解决方案四、父子通信流程五、父向子通信代码示例六、子向父通信代码示例 组件通信&#xff0c;就是指组件与组件之间的数据传递 组件的数据是独立的&#xff0c;无法直接访问其他组件的数据。想使用其他组件的数据&…
阅读更多...
Linux C语言学习:数据类型

Linux C语言学习:数据类型

一、 为什么要引入数据类型 • 计算机中每个字节都有一个地址&#xff08;类似门牌号&#xff09; • CPU通过 地址 来访问这个字节的空间 0x20001103 1 0 0 1 0 0 1 1 0x20001102 1 1 1 0 1 1 1 0 0x20001101 1 1 1 1 0 1 0 1 0x20001100 0 …
阅读更多...
什么是it运维工单系统？有哪些应用价值？

什么是it运维工单系统？有哪些应用价值？

it运维工单系统是一个智能化的it运维服务管理系统&#xff0c;可以为企业和服务提供商提供高效的it运维服务管理&#xff0c;它可以自动分配任务、优化工作流程并跟踪工作进展&#xff0c;从而大大提高it运维工作效率和客户满意度。 一、it运维工单系统是什么&#xff1f; it…
阅读更多...
提示词工程基础：定义与重要性

提示词工程基础：定义与重要性

目录 一、引言二、提示词工程的定义1. 概念明晰2. 技术框架3. 功能作用 三、提示词工程的重要性1. 核心作用强调2. 提升效率与降低成本3. 推动技术发展与创新 四、提示词工程的组成部分1. 提示词设计2. 模型训练与调整3. 效果评估与优化 五、实际应用示例1. 虚拟助手2. 自动新闻…
阅读更多...
1790java网络学习平台Myeclipse开发mysql数据库web结构java编程计算机网页项目

1790java网络学习平台Myeclipse开发mysql数据库web结构java编程计算机网页项目

一、源码特点 java网络学习平台系统 是一套完善的web设计系统&#xff0c;对理解JSP java编程开发语言有帮助采用了java设计&#xff0c;系统具有完整的源代码和数据库&#xff0c;系统采用web模式&#xff0c;系统主要采用B/S模式开发。开发环境为TOMCAT7.0,Myeclipse8.5开发&…
阅读更多...
STM32自己从零开始实操04:显示电路原理图

STM32自己从零开始实操04:显示电路原理图

一、TFT-LCD 屏接口 1.1指路 以下是该部分的设计出来后的实物图&#xff0c;我觉得看到实物图可能更方便理解这部分的设计。 图1 实物图 这部分设计的是一个屏幕的接口&#xff0c;很简单。使用的屏幕是&#xff1a;2.8inch 16BIT Module MRB2801。 1.2数据手册 &#xff0…
阅读更多...
【Redis数据库】命令操作

【Redis数据库】命令操作

文章目录 一、连接命令二、键命令 &#x1f308;你好呀&#xff01;我是 山顶风景独好 &#x1f495;欢迎来到我的博客&#xff0c;很高兴能够在这里和您见面&#xff01; &#x1f495;希望您在这里可以感受到一份轻松愉快的氛围&#xff01; &#x1f495;这里不仅可以获得有…
阅读更多...
sqoop操作

sqoop操作

介绍 sqoop是隶属于Apache旗下的, 最早是属于cloudera公司的,是一个用户进行数据的导入导出的工具, 主要是将关系型的数据库(MySQL, oracle...)导入到hadoop生态圈(HDFS,HIVE,Hbase...) , 以及将hadoop生态圈数据导出到关系型数据库中 操作 将数据从mysql中导入到HDFS中 1.全量…
阅读更多...
贷款行业新宠：短信群发营销的高效应用

贷款行业新宠：短信群发营销的高效应用

在贷款行业的激烈竞争中&#xff0c;短信群发营销凭借其高效、精准的特性逐渐崭露头角&#xff0c;成为行业新宠。 一、个性化信息&#xff0c;直达目标客户 通过短信群发&#xff0c;贷款机构能够精准地向目标客户推送个性化的贷款产品推荐。基于客户的信用状况、贷款需求等…
阅读更多...
[Windows] 植物大战僵尸杂交版

[Windows] 植物大战僵尸杂交版

游戏包含冒险模式、挑战模式、生存模式三种不同玩法。冒险模式主打关卡闯关&#xff0c;挑战模式则挑战特殊设计的关卡&#xff0c;生存模式结合无尽模式和特殊地图&#xff0c;各具特色。玩家可根据喜好自由选择模式&#xff0c;体验不同的游戏乐趣。快来尝试这款独特的pvz游戏…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023