Networking

有读者在《X-Forwarded-For 取首段的陷阱》那篇下面留了一条评论，大意是： 搞太复杂了。就一点——这个 HTTP header 的内容是不是来自可信来源？比如自己信任的 proxy。如果不是，直接忽略掉。或者用更好的办法：直接在 proxy 上 strip 掉非可信来源的 header 内容，把复杂性丢到 proxy 上，简化后端业务代码。 这条评论我盯了两天才想清楚该怎么回。原因是它有一半是对的，而且是那种你说不出"不对"的对；另一半听起来更简洁，但那个简洁是错觉。 先说结论：**它描述的不是"更简单的实现"，而是"把同一条约束换个地方执行"。**换个地方本身没问题——问题在于换过去之后，那条约束落进了一层基本没人测的配置里，而它本来是一段可测的代码。 一、评论其实说了两件事 # 评论的主张 它是什么 我的判定 A header 是否来自可信来源，不是就直接忽略 解析逻辑的第一步 原文已经这么写了 B 在 proxy 上 strip 掉非可信来源的 header，把复杂性丢给 proxy ...

一、从角色模糊到分工明确：RSTP 端口角色的革命在上一篇文章中，我们提到 STP 只有两种端口角色：根端口（Root Port）和指定端口（Designated Port）。这种二分法在面对复杂拓扑时显得力不从心——一个端口如果既不是根端口也不是指定端口，就只是一个"被阻塞的端口"，交换机不知道这个阻塞端口在拓扑变化时能起到什么作用。 RSTP 将端口角色扩展为四种： 12345RSTP 端口角色├── Root Port（根端口） — 非根桥上离根最近的端口├── Designated Port（指定端口） — 每条链路上离根最近的端口├── Alternate Port（替代端口） — 根端口的"备胎"└── Backup Port（备份端口） — 指定端口的"备胎" 1.1 Alternate 端口：根端口的快速后备Alternate 端口是 RSTP 最重要的新增角色。它的定义是：收到了来自其他交换机的更优 BPDU，但不如当前根端口优的端口。 用一个通俗的类比： 根端口是你...

一、网络冗余的"双刃剑"在一个可靠的网络中，冗余链路是必不可少的。想象一个企业园区网：核心交换机与汇聚交换机之间通常会有两条甚至多条物理链路相连，目的是当其中一条链路发生故障时，流量可以自动切换到备用链路，保证业务不中断。 然而，冗余链路带来了一个致命的问题——二层环路。 1234 [SW1] / \ / \[SW2]---[SW3] 在以太网帧的头部，没有 TTL（Time To Live）字段。IP 数据包有 TTL 来防止无限循环，但二层以太网帧一旦进入环路，就会永无止境地被转发。这就是广播风暴的根源。 环路带来的三大危害： 问题 描述 后果 广播风暴 广播帧在环路中无限复制转发 带宽被耗尽，网络瘫痪 MAC 地址表震荡 同一 MAC 地址在交换机不同端口间反复翻转 交换机无法正确转发单播帧 重复帧 同一数据帧通过不同路径多次到达目的地 上层协议可能出错 正是为了解决这个矛盾——在保留冗余链路的同时消除环路，**生成树协议（Spanning Tree Protocol, STP）**应运而生。 二、传统 S...

一、JWT概念JWT（JSON Web Token）是一种用于在网络上安全传输信息的紧凑、自包含的方式。它由三部分组成：头部（Header）、载荷（Payload）和签名（Signature），通过点分隔的字符串形式呈现。在身份验证和信息交换场景中应用广泛，因为它可以验证信息的完整性和真实性。 1.1 准备工作在开始之前，我们需要确保系统中安装了libjwt库，这是一个轻量级的 JWT 实现库。在 Ubuntu/Debian 系统上，可以使用以下命令安装： 1sudo apt-get install libjwt-dev 1.2 jwt.cc1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889#include <jwt.h>#include <stdio.h>#i...

要将双栈 TCP 回声服务器从线程池模式改造为Reactor 模式，核心是基于I/O 多路复用（epoll） 实现 “事件驱动” 的高效 I/O 处理 —— 通过单线程（或主线程）监听多个 Socket 的 I/O 事件，事件触发时再分发到对应处理器，避免线程上下文切换开销，更适合高并发场景。 一、Reactor 模式核心原理与组件Reactor 模式（反应器模式）是一种事件驱动架构，核心思想是 “将 I/O 事件从业务逻辑中分离”，通过以下组件实现： 组件 作用 Reactor（反应器） 核心调度器：运行事件循环，通过 I/O 多路复用（epoll）等待事件，分发事件到处理器 EventDemultiplexer 事件多路分离器：封装 epoll，负责注册 / 删除事件、等待事件触发（本文用 epoll） EventHandler（处理器） 事件处理接口：定义handleRead/handleWrite/handleError等统一接口，子类实现具体逻辑（如 “新连接处理”“回声...

在原有双栈兼容基础上，新增线程池替代进程、文件日志、超时处理、自定义协议四大核心优化，解决进程开销高、排查难、资源占用、粘包等问题，适用于高并发场景。 一、核心优化方案设计 优化功能 实现思路 线程池优化 设计固定大小线程池（基于pthread），复用线程处理客户端连接，避免频繁创建销毁进程的开销 文件日志系统 实现线程安全的日志类，记录时间戳、日志级别、事件详情，写入本地文件（如echo_server.log） 超时处理 通过setsockopt设置SO_RCVTIMEO/SO_SNDTIMEO，为recv/send设置超时（默认 5 秒） 自定义协议 定义 “4 字节长度头 + 数据” 格式，解决 TCP 粘包问题（长度头用网络字节序传输） 二、通用工具类实现（日志 + 线程池）1. 线程安全的文件日志类（Logger）负责将日志写入文件，支持INFO/ERROR级别，包含时间戳，多线程下通过互斥锁保证安全。 12345678910111213141516171819202122232425262728293031323...

一、核心技术：IPv4/IPv6 双栈兼容的关键设置要实现双栈兼容，需理解四个核心概念：hints.ai_family=AF_UNSPEC、hints.ai_flags=AI_PASSIVE、getaddrinfo函数、INET6_ADDRSTRLEN宏。它们共同解决了 IPv4 与 IPv6 协议差异带来的适配问题。 1. hints.ai_family = AF_UNSPEC：协议无关的地址解析hints是getaddrinfo的查询条件结构体，ai_family指定地址族（协议类型）： AF_INET：仅解析 IPv4 地址（对应struct sockaddr_in）； AF_INET6：仅解析 IPv6 地址（对应struct sockaddr_in6）； AF_UNSPEC：不限制协议，同时解析 IPv4 和 IPv6 地址。 为什么选AF_UNSPEC 现代服务器需同时响应 IPv4 和 IPv6 客户端的连接（例如用户可能通过192.168.100或fe80::1访问）。AF_UNSPEC让getaddrinfo返回...

1. 代理技术基础概念1.1 代理服务器定义代理服务器（Proxy Server）是位于客户端（Client）和目标服务器（Target Server）之间的网络中间节点，负责接收客户端的网络请求、转发至目标服务器，并将目标服务器的响应回传至客户端。其核心价值在于隐藏真实通信端点、控制网络流量、优化访问性能及增强网络安全。 1.2 代理技术的核心作用 通信中转：实现客户端与目标服务器的间接通信，解决直接连接受限问题 流量控制：基于规则过滤、转发或拦截网络请求（如企业内网访问策略） 性能优化：通过缓存常用资源、压缩数据减少网络传输量 安全防护：隐藏真实 IP 地址，隔离内外网，抵御部分网络攻击 2. 正向代理（Forward Proxy）技术原理2.1 正向代理定义正向代理是代理服务器为客户端提供服务的代理模式，客户端明确知道目标服务器地址，通过正向代理间接访问目标服务器。此时，代理服务器代表客户端与目标服务器通信，目标服务器无法直接获取客户端的真实 IP 地址。 2.2 正向代理工作流程 客户端配置正向代理服务器的地址及端口，明确目标服务器地址 客户端向正向代理发送请...

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146#include <sys/socket.h>#include <sys/types.h>#include <netdb.h>#include <cstring>#include <unistd.h>#include <cerrno>#include <c...

一、网络地址解析的必要性在网络通信中，应用程序通常需要通过域名（如www.example.com）而非直接使用 IP 地址（如93.184.216.34）来定位目标主机，同时需要通过服务名（如http）而非直接使用端口号（如80）来指定通信端口。这种抽象带来了以下核心需求： 用户友好性：人类更容易记忆域名而非数字 IP 协议兼容性：需同时支持 IPv4 与 IPv6，避免硬编码地址类型 服务灵活性：服务端口可能动态分配，通过服务名解析更可靠 网络拓扑适应：同一域名可能对应多个 IP（负载均衡场景），需支持多地址选择 传统地址解析方法（如gethostbyname、getservbyname）存在明显局限性：仅支持 IPv4、无法统一处理主机名与服务名、线程安全性差。getaddrinfo作为 POSIX 标准接口，完美解决了这些问题，是现代 C++ 网络编程的首选地址解析方案。 二、getaddrinfo 函数getaddrinfo是一个统一的地址解析接口，可同时处理主机名→IP 地址、服务名→端口号的解析，并返回可直接用于socket调用的地址结构。 2.1 函数原...

一、事务与并发控制基础1.1 事务ACID特性在分布式系统中，事务需要满足以下核心特性： 原子性：事务操作不可分割，全部完成或全部失败 一致性：事务执行前后数据库状态保持一致 隔离性：事务之间相互隔离，避免并发执行的干扰 持久性：事务提交后永久生效，即使系统崩溃也不会丢失 对于InnoDB存储引擎，ACID特性通过日志系统（Redo Log）和多版本并发控制（MVCC）实现，MySQL 8.0版本后已完全支持事务性存储引擎。 1.2 并发问题分类体系四个经典的并发问题及其表现形式： 问题类型 定义说明 典型场景 脏写 事务A写入数据后未提交，事务B又覆盖该数据，导致A的写入被B无效 两个事务对同一行数据进行并发修改，典型例子为数据库主从复制中的write-ahead log问题 脏读 事务A写入未提交数据，事务B读取该数据导致读取到无效数据 高并发读取场景，如统计报表生成时读取未提交的业务数据 不可重复读 事务A读取数据后，事务B修改该数据并提交，导致A再次读取时结果不同 需要保证数据一致性的金融交易场景 幻读 事务A读取数据集后，事务B插入新数据...

CD\LS命令12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152#include "Server.h"// CD命令实现int CmdCd(char *path, const int depth, FileBuf_t *msg, Node_t *p){ DIR *dir =opendir(path); if(dir == NULL){ sprintf(msg->buf, "(error: %s)", strerror(errno)); return -1; }else{ p->depth = depth; char *help; char *pathblock = strtok_r(path, " /", &help); f...

服务端信息处理123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111#include "Server.h"// 接收并处理命令int RecvCommand(Node_t *p){ int netfd = p->netfd; //接收指令 SignalSend_t *cmd = (SignalSend_t *)calloc(1, sizeof(SignalSend_t)); if (cmd == NULL){ printf("Error calloc\n"); syslog(...

服务端登录验证123456789101112131415161718192021222324252627282930313233343536373839#include "Server.h"//#include <shadow.h>//#include <crypt.h>//#include <syslog.h>int IsLoading(int netfd){ if(send(netfd, "请输入用户名和密码", sizeof("请输入用户名和密码"), 0) <= 0){ printf("error recv loadmsg\n"); return -1; } char load[2][PATHLEN]; char *username = load[0]; if(recv(netfd, load, 2 * PATHLEN, 0) <= 0){ ...

服务端头文件123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384#ifndef SERVER_H#define SERVER_H#include "my_header.h"#include <arpa/inet.h>#include <fcntl.h>#include <dirent.h>#include <sys/mman.h>#include <unistd.h>#include <pthread.h>#include <netinet/in.h>#include <sys/epoll.h>#include <sys/types.h>#include <sys/socket.h>...

收发文件循环接收12345678910#include "Client.h"int recvn(int sockfd, void *buf, int size){ int total = 0; char *p = (char *)buf; while(total < size){ ssize_t sret = recv(sockfd, p+total, size-total, 0); total += sret; } return total;} 收文件根据对方发送的文件名，在当下实现文件的接收 123456789101112131415161718192021222324252627282930313233343536int RecvFile(int sockfd){ FileBuf train; char filename[128] = {0}; recv(sockfd, &train.size, ...

导言最近学习完成了数据库和多人聊天室，想基于这些东西，设计一个老掉牙的网盘项目（才不是收到齐哥刺激）。目前是只有空闲时间能做，大概还是跟之前更新一样，大概一周一更慢慢写。 头文件1234567891011121314151617181920212223242526272829303132333435/* Usage: 实现收发功能，收消息没有限制，发消息需要信号，Switch判断发送，结构体发送指令，接收消息，接收文件*/#ifndef CLIENT_H#define CLIENT_H#include "my_header.h"#include <arpa/inet.h>#include <fcntl.h>#include <unistd.h>#include <pthread.h>#include <netinet/in.h>#include <sys/epoll.h>#include <sys/types.h>#include <sys/socket.h>#in...

一、引言在网络通信领域，TCP 协议凭借其强大的可靠性与稳定性，成为文件传输系统的首选。本教程聚焦于基于 TCP 的多线程文件传输系统，深入剖析事件驱动与线程池协同工作的架构设计。支持双向消息交互与文件传输，由九个核心文件构成，全面覆盖网络连接建立、事件监听、线程管理以及数据传输等关键环节。 二、代码结构分析1. 文件概览 文件名 主要功能 核心函数列表 head.h 全局结构体定义与函数声明 结构体：Train（封装消息与文件传输数据）、Queue_t（定义客户端连接队列结构）、Res_t（线程池资源相关结构体）；函数声明：Ready（服务器套接字初始化）、EpollAdd（将文件描述符添加到 epoll 监听列表）等 client.c 客户端主逻辑实现 main函数包含事件驱动循环，集成消息处理、连接状态管理及用户输入响应等模块，负责客户端的连接管理与数据通信。 Server.c 服务器核心逻辑 main函数基于 epoll 事件驱动机制，整合信号处理模块，实现客户端连接接收、消息转发及线程池任务调度，是服务器的核心控制中枢。 Ready.c 服务器套接...

一、pipe 机制详解1.1 管道的基本概念管道 (pipe) 是 Unix 系统中最古老的 IPC 机制之一，它通过一对文件描述符实现进程间的单向通信： 一个文件描述符用于读取数据 (fd[0]) 另一个文件描述符用于写入数据 (fd[1]) 数据在管道中以先进先出 (FIFO) 的方式传输 管道本质上是内核维护的一个缓冲区，其大小因系统而异 (通常为 64KB)，当缓冲区满时，写入操作会阻塞；当缓冲区空时，读取操作会阻塞。 1.2 pipe () 系统调用12#include <unistd.h>int pipe(int pipefd[2]); 成功时返回 0，失败时返回 -1 并设置 errno pipefd[0]：读取端文件描述符 pipefd[1]：写入端文件描述符 1.3 父子进程通信实现使用 pipe 进行父子进程通信的典型流程： 创建管道 调用 fork() 创建子进程 关闭不需要的文件描述符 进行数据读写操作 关闭所有文件描述符 1234567891011121314151617181920212223242526...

引言本文将详细解析一个基于多进程模型的文件传输系统，该系统包含服务器端和客户端两部分。服务器端采用进程池设计模式，通过预先创建多个工作进程来处理客户端的文件请求，提高系统的并发处理能力。客户端则负责接收服务器传输的文件并显示传输进度。 一、系统整体架构该系统主要由以下几个部分组成： 服务器端： 主进程：负责监听客户端连接、管理工作进程池 工作进程：实际处理文件传输任务 进程间通信：通过 UNIX 域套接字传递文件描述符 客户端： 连接服务器 接收文件数据 显示传输进度 二、核心数据结构1. Train 结构体1234typedef struct Train{ int size; char data[1024];}Train; 功能描述：用于文件数据的传输封装 结构说明： size：表示data数组中有效数据的长度 data：存储实际的文件数据，最大为 1024 字节 2. WorkerData 结构体12345typedef struct WorkerData{ pid_t pid; int st...

一、sendfile 系统调用解析1.1 技术要点sendfile 作为基于 Unix/Linux 操作系统的高效文件传输系统调用，其函数原型定义为： 1ssize\_t sendfile (int out\_fd, int in\_fd, off\_t \*offset, size\_t count); 各参数语义阐释如下： out_fd：数据输出目标文件描述符，常用于指向网络编程中的套接字描述符。 in_fd：数据输入源文件描述符，需支持内存映射（mmap）操作。 offset：文件读取偏移指针，设为 NULL 时启用系统默认偏移并自动更新。 count：指定待传输数据字节长度。 sendfile 的核心优势在于零拷贝技术，数据传输在内核空间完成，避免用户与内核空间的数据拷贝开销。传统 I/O 需四次上下文切换与四次数据拷贝，而 sendfile 仅需两次上下文切换和两次数据拷贝，大幅提升传输效率。 1.2 应用场景sendfile 系统调用适用于静态资源服务器文件传输、视频流媒体分发、大规模文件传输及高性能计算等对传输性能要求高的场景。 1...

一、早期搭建原因与后续放弃原因1.1 早期搭建原因 硬件适配与稳定性保障：早期服务器开发受限于单核 CPU 与有限内存，进程池架构通过预创建固定进程，规避频繁进程操作开销，利用进程资源隔离特性，防止单业务异常拖垮整个系统。 技术成熟与高效处理：多进程编程结合epoll事件驱动模型已趋成熟，凭借epoll对活跃事件的精准处理，服务器在高并发场景下实现资源高效利用。 性能优化策略：无锁化调度与动态负载均衡，有效化解多进程资源竞争，均衡任务分配，提升服务整体处理性能。 1.2 后续放弃原因 资源管理局限：业务扩张与用户增长时，固定进程池难以适配动态负载。高并发下请求排队导致响应延迟，且进程独占内存，数量过多易造成资源浪费，灵活性不足。 切换开销较大：进程池虽减少创建销毁频率，但上下文切换仍有开销。多核时代，线程作为轻量级单元，切换开销远低于进程，更适合高并发短周期任务，削弱多进程架构优势。 新技术的冲击：Node.js、Golang 等语言框架自带高效异步 I/O 与协程模型，开发效率和性能俱佳；Nginx 事件驱动架构成行业标杆，传统多进程服务器逐渐被替代。 二、主函数...

导言在 Linux 系统编程中，进程间通信（IPC）是核心课题。传统 IPC 机制如管道、消息队列和共享内存各有优势，但在高性能服务器、分布式系统等场景下存在局限，亟需更灵活的通信方式。 一、文件描述符传输的原理文件描述符作为进程私有资源标识，无法直接跨进程传递。因为不同进程的文件描述符表相互独立，同一数值在不同进程中可能指向不同资源。例如父进程中文件描述符 3 指向网络套接字，直接传递数值 3 给子进程，子进程的 3 可能指向标准输入。因此，需借助 Unix 域套接字等专门 IPC 机制传递。 在 Linux 中，文件描述符是进程访问 I/O 资源的抽象句柄，默认具有进程私有性。而在高并发服务器、分布式文件系统等场景下，传递文件描述符能提升资源复用与协作效率。其实现核心是利用 Linux 辅助数据机制，常通过 socketpair 创建 UNIX 域套接字，配合 sendmsg 和 recvmsg 系统调用完成。 二、代码实现分析伪代码部分扩展 为了更清晰地展示文件描述符传输的核心逻辑，以下通过伪代码对关键函数SendFd和RecvFd进行流程拆解，并补充更直观的主程...

一、核心逻辑的伪代码解释1.1 主程序逻辑1234567891011121314151617181920212223主程序开始: 打开文件"1.txt"用于读写 如果文件打开失败: 输出错误信息并退出程序 向文件中写入"nonono"字符串 如果写入失败: 关闭文件 输出错误信息并退出程序 强制将缓冲区数据写入磁盘 分配能存储3个workerData_t结构体的内存空间 如果内存分配失败: 关闭文件 输出错误信息并退出程序 调用MakeWorker函数创建3个工作进程 如果创建失败: 释放已分配的内存 关闭文件 输出错误信息并退出程序 对于每个工作进程: 等待该进程执行结束 释放内存空间 关闭文件 正常退出程序 主程序首先尝试打开文件并写入内容，确保数据持久化。接着分配内存存储工作进程信息，调用MakeWorker函数创建子进程，最后等待...

导言今天是聊天室，改了又改版本，目前更改部分包括：放弃了好用但是实现复杂的链表，采用数组来实现信息存储；时间结构采用ctime函数；用epoll代替select；生成历史记录文件等。 本代码实现的简易多人聊天系统主要包含两个部分： 服务器端：支持多客户端连接，具备消息广播、私聊以及超时检测功能。 客户端：负责与服务器建立连接，实现消息的发送与接收。 系统采用 TCP 协议进行通信，并运用 epoll 实现 I/O 多路复用。相较于传统的 select/poll 模型，在高并发场景下，epoll 展现出更出色的性能。 一、核心技术点解析1.1 epoll I/O 多路复用epoll 是 Linux 系统下高效的 I/O 事件通知机制，本项目主要使用了以下函数： epoll_create()：用于创建 epoll 实例。 epoll_ctl()：可添加、删除或修改被监控的文件描述符。 epoll_wait()：用于等待事件发生。 服务器和客户端均通过 epoll 同时监控 socket 和标准输入，实现了非阻塞的 I/...