秋深的池塘 - deepfal
type: channel
link: https://blog.deepfal.cn/index.php/author/1/
description: deepfal
items: 记一次诡异的 Tailscale 子网路由劫持：当 Ping 能通但 TCP 端口死活连不上
items: 【自动跟踪更新】Tailscale Derp docker 容器镜像 去除域名验证补丁版
items: Docker 部署 Mihomo (Clash Meta) 核心 + WebUI 指南
items: Qwen3模型YaRN长文本扩展技术深度解析
items: 自搭建 Tailscale DERP 服务器并使用客户端验证(verify-clients)
items: 一文读懂 QUIC 协议：更快、更稳、更高效的网络通信
items: MySQL经典四表查询(教师，学生，成绩，课程表)多表查询
items: SpringMVC注解式开发
items: SSM整合相关配置类 备忘
items: Snort 安装与配置(CentOS 7)

记一次诡异的 Tailscale 子网路由劫持：当 Ping 能通但 TCP 端口死活连不上
type: item
date: 2026-02-26T22:22:00+08:00
description: 📌 1. 问题背景与网络拓扑 最近在调整多节点网络，使用了 Tailscale 组网，并在一台内网的 Ubuntu 服务器上开启了 Subnet Router（子网路由），以便身在外地时能直接通过本地 IP 访问内网设备。 当前的网络拓扑： 外网设备（Windows）： Tailscale 虚拟 IP 100.116.47.82 网关节点（Ubuntu）： 局域网 IP 192.168.31.177 （开启了 Tailscale Subnet Router，开启了内核转发，装有 1Panel 面板和多个 Docker 容器） 目标服务器： 局域网 IP 192.168.31.220 （内网另一台机器，运行着 PostgreSQL 数据库，端口 5432） 核心诉求： 在 Windows 上通过 Tailscale 隧道，直连 192.168.31.220:5432。 👻 2. 诡异的半残网络现象 在配置好一切后，遇到了一个极其反直觉的现象： ICMP 畅通： 在 Windows 上 Ping 192.168.31.220，完美连通，延迟仅 5ms。说明 Tailscale 隧道和底层的三层路由毫无问题。 网关到目标畅通： 在 Ubuntu (177) 本机用 nc -zv 192.168.31.220 5432 测试，返回 open。说明 220 目标服务器的防火墙和数据库配置正常。 TCP 业务瘫痪： 在 Windows 上用客户端连接 220 的 5432 端口，死活连不上（超时）。 初步抓包诊断： 在 Ubuntu (177) 上执行 tcpdump -i any host 192.168.31.220 and port 5432 -nn，发现只有从 tailscale0 进来的包 (In)，没有任何发往物理网卡的包 (Out)。 阶段性结论： 数据包安全到达了 177 网关，但被 177 的内部网络栈“私吞”了，未能进入 FORWARD（转发）流程。 🕵️‍♂️ 3. 排查深入：内核级“天眼”追踪 既然常规的放行规则（在 FORWARD 链首部强行 ACCEPT）无效，说明包死在了更靠前的位置。为了不靠猜排错，我决定利用 iptables -j LOG 在 Linux Netfilter 的 6 个核心关卡埋下日志探头，追踪这个 TCP 包的完整生命周期。 执行部署探头命令： # 1. 刚接触到网卡，最原始的状态 (raw 表) sudo iptables -t raw -I PREROUTING 1 -p tcp -s 100.116.47.82 -j LOG --log-prefix "S1-RAW-PRE: " # 2. 准备被修改标记 (mangle 表) sudo iptables -t mangle -I PREROUTING 1 -p tcp -s 100.116.47.82 -j LOG --log-prefix "S2-MGL-PRE: " # 3. 准备被劫持或映射 (nat 表) sudo iptables -t nat -I PREROUTING 1 -p tcp -s 100.116.47.82 -j LOG --log-prefix "S3-NAT-PRE: " # 4. 意外关卡：如果包被劫持给本机，会进入 INPUT 链 sudo iptables -I INPUT 1 -p tcp -s 100.116.47.82 -j LOG --log-prefix "S-X-INPUT: " # 5. 正常进入转发通道 (FORWARD 链) sudo iptables -I FORWARD 1 -p tcp -s 100.116.47.82 -j LOG --log-prefix "S4-FORWARD: " # 6. 即将离开物理网卡发往目标 (POSTROUTING 链) sudo iptables -t nat -I POSTROUTING 1 -p tcp -s 100.116.47.82 -j LOG --log-prefix "S5-NAT-POST: " 随后在 Windows 上再次发起 5432 端口的连接请求，然后在 Ubuntu 提取过滤后的内核日志： sudo dmesg -T | grep -E "S1|S2|S3|S4|S5|S-X" | grep "DPT=5432" | tail -n 6 提取到的震撼日志： [四 2月 26 21:58:22 2026] S1-RAW-PRE: SRC=100.116.47.82 DST=192.168.31.220 DPT=5432 [四 2月 26 21:58:22 2026] S2-MGL-PRE: SRC=100.11…

【自动跟踪更新】Tailscale Derp docker 容器镜像 去除域名验证补丁版
type: item
date: 2026-02-26T17:41:00+08:00
description: 简介 最近看到 tailscale 一直在保持更新（尤其是提高网络吞吐量相关的特性），我就去问了问 ai，如果 derp 服务器一直保持在旧版是不是在中转模式下吃不到新版本的特性？AI 说确实。。 所以自己搓了个 github actions 自动检查新版本 derp 拉过来打补丁 然后发布到 dockerhub 直观效果就是 去除域名验证，国内免备案 (ip + 端口可以直接用)，安全性由客户端验证保证 所以宿主机尽量也运行 tailscale 的客户端来确保安全（被扫到就会被白嫖）！ Github 仓库 [post url="https://github.com/DeepFal/tailscale-derp" title="GitHub" intro="DeepFal/tailscale-derp" cover="https://cc.deepfal.cn/2026/02/26/69a019972b8be.png" /] 快速启动： docker run -d \ --name tailscale-derp \ --restart unless-stopped \ -p 0.0.0.0:59443:36666 \ -p 0.0.0.0:3478:3478/udp \ -v /run/tailscale:/var/run/tailscale:ro \ deepfal/tailscale-derp:latest \ ./derper \ -hostname derp.deepfal.cn \ -a :36666 \ -certmode manual \ -certdir /ssl \ --verify-clients 自搭建 derp 服务器完整教程说明： [post cid="945" cover="https://cc.deepfal.cn/2026/02/26/69a019db3f91f.png"/]

Docker 部署 Mihomo (Clash Meta) 核心 + WebUI 指南
type: item
date: 2025-12-11T14:14:00+08:00
description: 流程概览 前言 Mihomo（原名 Mihomo Meta，亦即 Clash Meta）是目前 Clash 核心最活跃、功能最强大的分支。由于原始 Clash 项目删库，Mihomo 已成为各平台客户端的首选核心。 值得注意的是，Mihomo 本身是一个纯命令行程序（Core），没有图形界面。为了方便日常管理和监控，我们需要为其搭配一个 Web UI（如 Metacubexd）。本文将详细介绍如何在 Docker 环境（包括 Linux 服务器、NAS、飞牛OS等）中优雅地部署 Mihomo + WebUI，并开启 TUN 模式实现更接管更底层的流量。 准备工作 在开始之前，请确保您的环境满足以下条件： Docker 环境：已安装 Docker 及 Docker Compose。 基础知识：熟悉基本的命令行操作（创建文件夹、编辑文件）。 网络环境：拥有可用的节点订阅链接。 第一步：编写配置文件 (config.yaml) Mihomo 的运行核心在于配置文件。我们需要先在宿主机上准备好这个文件。 新建一个文件夹，命名为 mihomo。 在其中创建一个名为 config.yaml 的文件。 参考以下模板填入内容。 ⚠️ 重点修改提示： 请务必修改下方模板中的 第 7 行（API访问密钥）、第 20、21 行（节点订阅信息）与 第 26 行（节点名称前缀）。修改时请去掉尖括号 < >。 mixed-port: 7890 allow-lan: true bind-address: '*' mode: rule log-level: info external-controller: '0.0.0.0:9090' secret: "<API访问密钥>" tun: enable: false stack: mixed dns-hijack: - "any:53" - "tcp://any:53" auto-route: true auto-redirect: true auto-detect-interface: true proxy-providers: <节点提供者名称>: url: "<节点订阅链接>" type: http interval: 86400 health-check: {enable: true,url: "https://www.gstatic.com/generate_204", interval: 300} override: additional-prefix: "<节点名称前缀>" proxies: - name: "直连" type: direct udp: true geodata-mode: true geox-url: geoip: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geoip.dat" geosite: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geosite.dat" mmdb: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/country-lite.mmdb" asn: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/GeoLite2-ASN.mmdb" dns: enable: true ipv6: true respect-rules: true enhanced-mode: fake-ip fake-ip-filter: - "*" - "+.lan" - "+.local" - "+.market.xiaomi.com" nameserver: - https://120.53.53.53/dns-query - https://223.5.5.5/dns-query proxy-server-nameserver: - https://120.53.53.53/dns-query - https://223.5.5.5/dns-query nameserver-policy: "geosite:cn,private": - https://120.53.53.53/dns-query - https://223.5.5.5/dns-query "geosite:geolocation-!cn": - "https://dns.cloudflare.com/dns-query" - "https://…

Qwen3模型YaRN长文本扩展技术深度解析
type: item
date: 2025-08-15T14:08:00+08:00
description: Qwen3 模型原生支持 32,768 个 token 的上下文长度。对于超出此限制的长文本，官方推荐使用 YaRN (Yet another RoPE-based Neural network scaling) 扩展技术。YaRN 是一种基于旋转位置编码（RoPE）的扩展方法，已验证可将上下文长度扩展至 131,072 个 token，并被 transformers、llama.cpp、vllm 和 sglang 等多个推理框架支持。 要启用 YaRN，需配置以下关键参数： rope_scaling: 一个配置 RoPE 缩放策略的字典。 rope_type: 字符串类型，指定缩放类型。启用 YaRN 时，其值为 "yarn"。 factor: 浮点数，定义上下文窗口扩展的倍数。例如，4.0 表示将原始长度扩展四倍。 original_max_position_embeddings: 整数，表示模型的原始最大上下文长度，对于 Qwen3，其值为 32768。 max_model_len: 整数，最终设置的模型最大上下文长度，应与 factor 的乘积相匹配。 解决方案：两种配置方式 根据官方文档，有以下两种主要方法来启用 YaRN。 1. 修改模型配置文件（推荐） 这是最直接且不易出错的方法，完全规避了命令行参数解析的复杂性。 定位文件: 打开 Qwen3 模型目录下的 config.json 文件。 添加配置: 在文件中添加或修改 rope_scaling 字段，并设置 max_model_len。 JSON "rope_scaling": { "rope_type": "yarn", "factor": 4.0, "original_max_position_embeddings": 32768 }, "max_model_len": 131072 这种方法配置一次即可永久生效，特别适用于生产环境部署。 2. 命令行参数传递 对于不同的推理框架，命令行参数的格式有所不同。 vLLM: Bash VLLM_USE_MODELSCOPE=true vllm serve ... --rope-scaling '{"rope_type":"yarn","factor":4.0,"original_max_position_embeddings":32768}' --max-model-len 131072 sglang: Bash SGLANG_USE_MODELSCOPE=true python -m sglang.launch_server ... --json-model-override-args '{"rope_scaling":{"rope_type":"yarn","factor":4.0,"original_max_position_embeddings":32768}}' llama.cpp: Bash llama-server ... --rope-scaling yarn --rope-scale 4 --yarn-orig-ctx 32768 命令行参数的格式因框架而异，需特别注意。 推荐模型参数与最佳实践 在启用 YaRN 长文本支持后，为了获得最佳推理效果，还需关注以下生成参数和最佳实践： 采样参数 对于思考模式（enable_thinking=True），使用 Temperature=0.6、TopP=0.95、TopK=20 和 MinP=0。不要使用贪婪解码，因为它可能导致性能下降和无尽的重复。 对于非思考模式（enable_thinking=False），我们建议使用 Temperature=0.7、TopP=0.8、TopK=20 和 MinP=0。 对于支持的框架，您可以将 presence_penalty 参数调整在 0 到 2 之间以减少无尽的重复。然而，使用较高的值偶尔会导致语言混杂和模型性能轻微下降。 其他重要提示 性能考量: 大部分开源框架都实现了静态 YaRN。我们建议仅在需要处理长上下文时才启用 YaRN，因为它可能影响处理较短文本时的性能。 factor 调整: 官方建议根据典型上下文长度调整 factor，例如，若应用场景的上下文长度通常为 65,536 个 token，则将 factor 设置为 2.0。 版本兼容性: 若遇到 Unrecognized keys in rope_scaling 警告，请升级 transformers 至 4.51.0 或更高版本。 显存需求: 扩展上下文长度会显著增加显存消耗。处理 131,072 个 token 的文本可能需要比原生长度多占用 30-40% 的显存。 输出长度: 对于大多数查询，建议设置 32,768 个 token …

自搭建 Tailscale DERP 服务器并使用客户端验证(verify-clients)
type: item
date: 2025-01-16T15:42:00+08:00
description: Tailscale DERP（Distributed, Encrypted, and Resilient Packet Relay）服务器是 Tailscale 网络中用于中继流量的组件，尤其适用于网络环境复杂或直连困难的场景，但是国内网络连接官方提供的 derp 服务器时普遍存在延迟高，速度慢，甚至几乎无法使用的情况。所以产生了自建私有 derp 流量中转服务器的需求，以便在 p2p 无法直连打洞成功的场景下能够实现和使用低延迟，高速度的 tailscale 流量中继服务。以下是使用 Docker 搭建 Tailscale DERP 服务器的详细步骤： 环境准备 操作系统：推荐使用 Linux 系统，如 Ubuntu、Debian 等，因为 Docker 在 Linux 上的性能和兼容性更佳。 Docker 环境：确保已安装 Docker。可以通过运行 docker --version 命令来检查 Docker 是否已安装。 Tailscale 客户端：在宿主机上安装并启动 Tailscale 客户端，以便 DERP 服务器能够与 Tailscale 网络通信。 网络配置：确保服务器的网络配置正确，能够正常访问外网，且对应的端口没有被防火墙阻止。 搭建步骤 1. 安装并启动 Tailscale 客户端 在宿主机上安装 Tailscale 客户端，并启动它。安装方法因操作系统而异，具体可以参考 Tailscale 官方文档。 启动 Tailscale 客户端后，它会在 /var/run/tailscale 目录下创建一个名为 tailscaled.sock 的套接字文件。 2. 拉取 Docker 镜像 从 Docker Hub 拉取 deepfal/tailscale-derp 镜像。该镜像已经包含了搭建 DERP 服务器所需的全部依赖和配置。 docker pull deepfal/tailscale-derp:latest 3. 运行 DERP 服务器容器 使用以下命令启动 DERP 服务器容器。该命令会将 DERP 服务器映射到宿主机的指定端口，并挂载必要的文件和目录。 docker run -d \ --name tailscale-derp \ --restart unless-stopped \ -p 0.0.0.0:59443:36666 \ -p 0.0.0.0:3478:3478/udp \ -v /run/tailscale:/var/run/tailscale:ro \ deepfal/tailscale-derp:latest \ ./derper \ -hostname derp.deepfal.cn \ -a :36666 \ -certmode manual \ -certdir /ssl \ --verify-clients 参数解释 -d：后台运行容器。 --name tailscale-derp：指定容器名称为 tailscale-derp。 -p 0.0.0.0:59443:36666：将容器的 36666 端口映射到宿主机的 59443 端口，允许外部访问。 -p 0.0.0.0:3478:3478/udp：将容器的 3478 端口映射到宿主机的 3478 端口，用于 UDP 通信。 -v /run/tailscale:/var/run/tailscale:ro：将宿主机的 Tailscale 套接字文件挂载到容器中，以便 DERP 服务器与 Tailscale 守护进程通信，挂载目录是为了防止客户端重启导致 socks 突然获取不到了导致 derp 工作异常，挂目录比较稳。 deepfal/tailscale-derp:latest：指定使用的 Docker 镜像。 ./derper：指定容器启动时运行的命令。 -hostname "derp.deepfal.cn"：设置 DERP 服务器的主机名。 -a ":36666"：指定 DERP 服务器监听的端口。 -certmode "manual"：指定证书模式为手动。 -certdir "/ssl"：指定证书目录。 --verify-clients：启用客户端验证。 4. 验证 DERP 服务器状态 启动容器后，可以通过以下命令查看 DERP 服务器的运行状态： docker logs tailscale-derp 如果看到类似 DERP server started 的日志信息，表示 DERP 服务器已成功启动。 5. 配置 Tailscale 客户端 在 Tailscale 后台配置中，添加自建 DERP 服务器的信息。具体配置方法如下： { "derpMap": { "OmitDefaultRegions": false, "R…

一文读懂 QUIC 协议：更快、更稳、更高效的网络通信
type: item
date: 2024-07-15T14:56:00+08:00
description: 一文读懂 QUIC 协议：更快、更稳、更高效的网络通信 ​ 你是否也有这样的困扰：打开 APP 巨耗时、刷剧一直在缓冲、追热搜打不开页面、信号稍微差点就直接加载失败…… ​ 如果有一个协议能让你的上网速度，在不需要任何修改的情况下就能提升 20%，特别是网络差的环境下能够提升 30%以上；如果有一个协议可以让你在 WiFi 和蜂窝数据切换时，网络完全不断开、直播不卡顿、视频不缓冲；你愿意去了解一下它吗？它就是 QUIC 协议。本文将从 QUIC 的背景、原理、实践部署等方面来详细介绍。 一：网络协议栈 1.1 什么叫网络协议？ ​ 类似于我们生活中签署的合同一样，比如买卖合同是为了约束买卖双方的行为按照合同的要求履行，网络协议是为了约束网络通信过程中各方（客户端、服务端及中间设备）必须按照协议的规定进行通信，它制定了数据包的格式、数据交互的过程等等，网络中的所有设备都必须严格遵守才可以全网互联。 ​ 在网络协议栈中，是有分层的，每一层负责不同的事务。我们讨论最多的有三个：应用层、传输层、网络层。应用层主要是针对应用软件进行约束，比如你访问网站需要按照 HTTP 协议格式和要求进行，你发送电子邮件需要遵守 SMTP 等邮件协议的格式和要求；传输层主要负责数据包在网络中的传输问题，比如如何保证数据传输的时候的安全性和可靠性、数据包丢了怎么处理；网络层，也叫路由转发层，主要负责数据包从出发地到目的地，应该怎样选择路径才能更快的到达。合理的网络协议能够让用户上网更快！ 1.2 HTTP/3 协议 ​ HTTP/3 是第三个主要版本的 HTTP 协议。与其前任 HTTP/1.1 和 HTTP/2 不同，在 HTTP/3 中，弃用 TCP 协议，改为使用基于 UDP 协议的 QUIC 协议实现。所以，HTTP/3 的核心在于 QUIC 协议。显然，HTTP/3 属于应用层协议，而它使用的 QUIC 协议属于传输层协议。 1.3 我们需要 HTTP/3 协议吗 ​ 很多人可能都会有这样一个疑问，为什么在 2015 年才标准化了 HTTP/2 ，这么快就需要 HTTP/3？ ​ 我们知道，HTTP/2 通过引入“流”的概念，实现了多路复用。简单来说，假设你访问某个网站需要请求 10 个资源，你使用 HTTP1.1 协议只能串行地发请求，资源 1 请求成功之后才能发送资源 2 的请求，以此类推，这个过程是非常耗时的。如果想 10 个请求并发，不需要串行等待的话，在 HTTP1.1 中，应用就需要为一个域名同时建立 10 个 TCP 连接才行（一般浏览器不允许建立这么多），这无疑是对资源的极大的浪费。HTTP/2 的多路复用解决了这一问题，能使多条请求并发。 ​ 但现实很残酷，为什么很多业务用了 HTTP/2，反倒不如 HTTP1.1 呢？ ​ 第一：多流并发带来了请求优先级的问题，因为有的请求客户端（比如浏览器）希望它能尽快返回，有的请求可以晚点返回；又或者有的请求需要依赖别的请求的资源来展示。流的优先级表示了这个请求被处理的优先级，比如客户端请求的关键的 CSS 和 JS 资源是必须高优先级返回的，图片视频等资源可以晚一点响应。流的优先级的设置是一个难以平衡或者难以做到公平合理的事情，如果设置稍微不恰当，就会导致有些请求很慢，这在用户看来，就是用了 HTTP/2 之后，怎么有的请求变慢了。 ​ 第二：HTTP/2 解决了 HTTP 协议层面的队头阻塞，但是 TCP 的队头阻塞仍然没有解决，所有的流都在一条 TCP 连接上，如果万一序号小的某个包丢了，那么 TCP 为了保证到达的有序性，必须等这个包到达后才能滑动窗口，即使后面的序号大的包已经到达了也不能被应用程序读取。这就导致了在多条流并发的时候，某条流的某个包丢了，序号在该包后面的其他流的数据都不能被应用程序读取。这种情况下如果换做 HTTP1.1，由于 HTTP1.1 是多条连接，某个连接上的请求丢包了，并不影响其他连接。所以在丢包比较严重的情况下，HTTP/2 整体效果大概率不如 HTTP1.1 ​ 事实上，我们并不是真的需要新的 HTTP 版本，而是需要对底层传输控制协议(TCP) 进行升级。 1.4 QUIC 协议栈 ​ QUIC 协议实现在用户态，建立在内核态的 UDP 的基础之上，集成了 TCP 的可靠传输特性，集成了 TLS1.3 协议，保证了用户数据传输的安全。 二：QUIC 协议的优秀特性 2.1 建连快 ​ 数据的发送和接收，要想保证安全和可靠，一定是需要连接的。TCP 需要，QUIC 也同样需要。连接到底是什么？连接是一个通道，是在一个客户端和一个服务端之间的唯一一条可信的通道，主要是为了安全考虑，建立了连接，也就是建立了可信通道，服务器对这个客户端“很放心”，对于服务…

MySQL经典四表查询(教师，学生，成绩，课程表)多表查询
type: item
date: 2023-08-18T14:14:00+08:00
description: MySQL经典四表查询(教师，学生，成绩，课程表)多表查询 1、表架构呈现 student(sid,sname,sage,ssex) 学生表 teacher(tid,tname) 教师表 course(cid,cname,tid) 课程表 sc(sid,cid,score) 成绩表 2、建表SQL语句并插入数据 -- 1.学生表 CREATE TABLE student( sid INT PRIMARY KEY AUTO_INCREMENT, sname VARCHAR(20), sage DATE, ssex ENUM ('男','女') ); -- 2.课程表中使用了外键教师编号，因而需要先建立教师表 CREATE TABLE teacher( tid INT PRIMARY KEY AUTO_INCREMENT, tname VARCHAR(20) ); -- 3.建立课程表 CREATE TABLE course( cid INT PRIMARY KEY AUTO_INCREMENT, cname VARCHAR(20), tid INT, FOREIGN KEY (tid) REFERENCES teacher (tid) ); -- 4.建立成绩表 CREATE TABLE sc( sid INT, cid INT, score INT ); -- 先给student表插入数据 INSERT INTO student VALUES (1,'赵雷','1990-01-01','男'), (2,'钱电','1990-12-21','男'), (3,'孙风','1990-05-20','男'), (4,'李云','1990-08-06','男'), (5,'周梅','1991-12-01','女'), (6,'吴兰','1992-03-01','女'), (7,'郑竹','1989-07-01','女'), (8,'王菊','1990-01-20','女'); -- 给teacher表插入数据,这里不可以先给course表插入数据,因为course表外键连接到teacher的主键 INSERT INTO teacher VALUES(1,'张三'),(2,'李四'),(3,'王五'); -- 给course表插入数据 INSERT INTO course VALUES(1,'语文',2),(2,'数学',1),(3,'英语',3); -- 最后给sc表插入数据 INSERT INTO sc VALUES(1,1,90),(1,2,80),(1,3,90),(2,1,70),(2,2,60),(2,3,80),(3,1,80), (3,2,80),(3,3,80),(4,1,50),(4,2,30),(4,3,20),(5,1,76),(5,2,87),(6,1,31),(6,3,34),(7,2,89),(7,3,98); 3、问题集锦 （1）查询 1 课程比 2 课程成绩高的学生的信息及课程分数 SELECT s.sid,s.sname,s.sage,s.ssex,sc1.score,sc2.score FROM student s ,sc sc1,sc sc2 WHERE sc1.`cid` = 1 AND sc2.`cid` = 2 AND sc1.`score` > sc2.`score` AND sc1.`sid` = s.`sid`AND sc2.`sid` = s.`sid`; （2）查询平均成绩大于等于60分的同学的学生编号和学生姓名和平均成绩 SELECT s.sid,s.sname,AVG(sc1.`score`) AS 'avg_score' FROM student s ,sc sc1 WHERE s.sid = sc1.`sid` GROUP BY s.sid HAVING avg_score >= 60 ORDER BY avg_score DESC; （3）查询名字中含有"风"字的学生信息 SELECT s.sid,s.sname,s.sage,s.ssex FROM student s WHERE sname LIKE '%风%'; （4）查询课程名称为"数学"，且分数低于60的学生姓名和分数 SELECT s.sname,sc1.score FROM student s ,sc sc1 WHERE s.sid = sc1.sid AND cid = 2 AND sc1.score < 60; （5）查询所有学生的课程及分数情况 SELECT sc1.sid,c.cname,sc1.score FROM course c,sc sc1 WHERE c.cid = sc1.cid; （6）查…

SpringMVC注解式开发
type: item
date: 2023-08-18T13:45:00+08:00
description: SpringMVC注解式开发 1.1 @Controller ​ 传统的配置式开发中的控制器Controller类必须实现Controller接口，并实现接口中的HandleRequest()方法，还需要再配置文件中配置处理器映射，且一个处理器（控制器）只能有一个方法，为了实现程序功能，不得不创建大量的处理器（控制器）类，不够方便灵活。 ​ 而，注解开发中，将一个普通的类转化为控制器类只需要在该类的声明上添加@Controller注解即可。一个基于注解的控制器可以有多个方法，能大大减少处理器（控制器）类的数量。 ​ 要使注解被扫描到，必须在springmvc.xml中配置组件扫描器，代码如下： <context:component-scan base-package="com.deepfal.controller" /> 1.2 @RequestMapping定义请求规则 ​ 基于注解的控制器无须在xml配置文件中配置处理器映射器，仅需要用@RequestMapping对应控制器类中任意一个方法进行注解即可建立“请求/响应”映射关系，将客户端请求与处理器的方法一一对应。 ​ 通过@RequestMapping 注解可以定义处理器对于请求的映射规则。该注解可以注解在方法上，也可以注解在类上，但意义是不同的。value 属性值常以“/”开始。@RequestMapping 的 value 属性用于定义所匹配请求的 URI。 1.2.1 指定模块名称 ​ 一个@Controller 所注解的类中，可以定义多个处理器方法。当然，不同的处理器方法所匹配的 URI 是不同的。这些不同的 URI 被指定在注解于方法之上的@RequestMapping 的value 属性中。但若这些请求具有相同的 URI 部分，则这些相同的 URI部分可以被抽取到注解在类之上的@RequestMapping 的 value 属性中。此时的这个 URI 表示模块（相当于包）的名称。URI 的请求是相对于 Web 的根目录。换个角度说，要访问处理器的指定方法，必须要在方法指定 URI 之前加上处理器类前定义的模块名称。 示例： 提取后 @Controller @RequestMapping("/zar") public class HelloSpringMvc { //相当于一个控制器处理的方法 @RequestMapping("/hello") public String one() { return "main"; } @RequestMapping("/two") public String two() { return "main"; } //客户端的请求： // // } 1.2.2 对请求提交方式的定义 ​ 对于@RequestMapping，其有一个属性 method，用于对被注解方法所处理请求的提交方式进行限制，即只有满足该 method 属性指定的提交方式的请求，才会执行该被注解方法。Method 属性的取值为 RequestMethod 枚举常量。常用的为 RequestMethod.GET 与RequestMethod.POST，分别表示提交方式的匹配规则为 GET 与 POST 提交。 @RequestMapping(value = "/hello",method = RequestMethod.POST) public String one() { return "main"; } 以上处理器方法只能处理 POST 方式提交的请求。 客户端浏览器常用的请求方式，及其提交方式有以下几种： 也就是说，只要指定了处理器方法匹配的请求提交方式为 POST，则相当于指定了请求发送的方式：要么使用表单请求，要么使用 AJAX 请求。其它请求方式被禁用。 当然，若不指定 method 属性，则无论是 GET 还是 POST 提交方式，均可匹配。即对于请求的提交方式无要求。 （1）post提交方式 （2）get提交方式 1.3 数据提交的方式 前四种数据注入的方式，会自动进行类型转换。但无法自动转换日期类型。 （1）单个数据（基本数据类型）注入 在方法中声明一个和表单提交的参数名称相同的参数，由框架按照名称直接注入。 （2）对象封装注入 在方法中声明一个自定义的实体类参数，框架调用实体类中相应的setter方法注入属性值，只要保证实体类中成员变量的名称与提交请求的name属性值一致即可。 实体Bean含对象属性 比如：Student对象，其中有一个Address的对象属性，在Address对象中有country和city两个基本类型的属性。 对象数据提交 姓名： 年龄： 国家： 城市： （3）动态占位符提交/路径变量（仅用于超链接） ​ 使用框架提供的…

SSM整合相关配置类 备忘
type: item
date: 2023-08-18T13:22:00+08:00
description: SSM整合相关纯注解配置类 备忘 纯注解配置类，包含Servlet,SpringMVC，Spring，MyBatis 组件名(artifactId) 版本号 javax.servlet-api 4.0.1 javax.servlet.jsp-api 2.3.3 spring-webmvc 5.2.10.RELEASE mysql-connector-java 5.1.49 spring-jdbc 5.2.10.RELEASE druid 1.2.17 mybatis 3.5.13 mybatis-spring 2.1.1 Servlet配置类 ServletConfig.java package com.deepfal.config; import org.springframework.web.filter.CharacterEncodingFilter; import org.springframework.web.servlet.support.AbstractAnnotationConfigDispatcherServletInitializer; import javax.servlet.Filter; /** * AbstractAnnotationConfigDispatcherServletInitializer是一个Spring框架中的抽象类,它用来配置使用基于Java的Spring配置(基于注解的配置) instead of the traditional web.xml file的Web应用程序。 * * 它扩展了AbstractDispatcherServletInitializer类,并重写了特定的方法来指定Java @Configuration类的位置,DispatcherServlet的映射以及DispatcherServlet的名称。 * * 关于AbstractAnnotationConfigDispatcherServletInitializer的一些关键点: * * 这是一个抽象类,需要扩展它并提供应用程序特定的配置。 * getRootConfigClasses()方法返回配置根应用程序上下文的@Configuration类数组,这个上下文由ContextLoaderListener加载。 * getServletConfigClasses()方法返回配置dispatcher servlet应用程序上下文的@Configuration类。 * getServletMappings()方法返回DispatcherServlet的servlet映射,默认映射到"/"。 * 所以总结一下,它提供了一种基于Java的方式来配置DispatcherServlet以及根应用程序上下文,作为web.xml的替代方案。扩展这个类并重写方法可以只使用Java代码而不需要web.xml就配置一个Spring MVC web应用程序。 */ public class ServletConfig extends AbstractAnnotationConfigDispatcherServletInitializer { //加载Spring容器 @Override protected Class<?>[] getRootConfigClasses() { return new Class[]{SpringConfig.class}; } //指向SpringMvc配置类，加载SpringMVC容器 @Override protected Class<?>[] getServletConfigClasses() { return new Class[]{SpringMvcConfig.class}; } //将哪些请求发给SpringMVC处理 @Override protected String[] getServletMappings() { return new String[]{"/"}; } //编码过滤器（仅对Body生效） @Override protected Filter[] getServletFilters() { CharacterEncodingFilter filter = new CharacterEncodingFilter(); filter.setEncoding("UTF-8"); return new Filter[]{filter}; } } SpringMVC配置类 SpringMvcConfig.java package com.deepfal.config; import org.springframework.context.annotation.Componen…

Snort 安装与配置(CentOS 7)
type: item
date: 2023-04-21T01:31:00+08:00
description: Snort 安装与配置(CentOS 7) ​ Snort 是免费 NIPS 以及 NIDS 软件，具有对数据流量分析和对网络数据包进行分析处理的能力，通过灵活可定制的规则库（Rules），可对处理的报文内容进行搜索和匹配，能够检测出各种攻击，并进行实时预警。 ​ Snort 支持三种工作模式：嗅探器、数据包记录器、网络入侵检测系统，支持多种操作系统，如 Fedora、CentOS、FreeBSD、Windows 等，本次实验使用 CentOS 7 系统安装 Snort 3。 前置工作 根据实际网络连接情况配置网卡信息，使能够连通互联网。 更新 Yum 源和软件包： # sudo yum clean all # sudo yum makecache # sudo yum -y update 安装Wget，准备使用网络下载所需资源： # sudo yum install -y wget 安装 EPEL 源： # sudo yum install -y epel-release 安装所需组件： # sudo yum install -y gcc flex bison zlib zlib-devel libpacp libpacp-devel pcre pcre-devel libdnet libdnet-devel tcpdump 安装 Snort&daq 使用官网预编译的 rpm 安装包安装 Snort&daq： # cd ~ # wget https://snort.org/downloads/archive/snort/daq-2.0.6-1.centos7.x86_64.rpm # wget https://snort.org/downloads/archive/snort/snort-2.9.9.0-1.centos7.x86_64.rpm # sudo yum install ./daq-2.0.6-1.centos7.x86_64.rpm -y # sudo yum install ./snort-2.9.9.0-1.centos7.x86_64.rpm -y 配置 Snort ​ Snort官方提供三种下载规则：Community rules、Registered rules、Subscriber rules，第一种是社区规则，无需注册购买即可下载使用，第二种是注册规则，需要在官方注册账户后可下载使用，第三种必须要付费订阅才可使用。这里使用第一种 Community rules。 下载解压 Community rules 规则： # cd ~ # wget https://www.snort.org/rules/community -O ~/community.tar.gz # sudo tar -xvf ~/community.tar.gz -C ~/ # sudo sudo cp ~/community-rules/* /etc/snort/rules 创建所需要的文件和目录，在前面的操作中，有些目录已经自动创建好了，所以创建目录时看到”目录已存在“的提示无须担心： # sudo mkdir /var/log/snort # sudo mkdir /usr/local/lib/snort_dynamicrules # sudo mkdir /etc/snort/rules # sudo touch /etc/snort/rules/white_list.rules # sudo touch /etc/snort/rules/black_list.rules 编辑 Snort 配置文件 # sudo vi /etc/snort/snort.conf 找到 var RULE_PATH ../rules 及相邻的四条配置信息，修改路径变量为： var RULE_PATH /etc/snort/rules var SO_RULE_PATH /etc/snort/so_rules var PREPROC_RULE_PATH /etc/snort/preproc_rules var WHITE_LIST_PATH /etc/snort/rules var BLACK_LIST_PATH /etc/snort/rules 设置日志目录：找到关键词 # config logdir: ，取消注释后将该行修改为 config logdir: /var/log/snort 配置输出插件，找到关键词 # output unified2: ，取消注释后将该行 修改为 output unified2: filename snort.log, limit 128 配置 Snort 启动时需要加载的自定义规则项：找到关键词 # include…