Family of Chipmunk' s blogs! - 网络
type: channel
link: https://jyjswk.online/category/net.html
items: API接口（2）
items: API接口（1）
items: 内网穿透
items: 侧载
items: 计算机通信协议栈
items: 邮件传输协议
items: Linux防火墙三层架构
items: HTTPS
items: MkDocs静态网站+Nginx反向代理

API接口（2）
type: item
date: 2026-06-13T13:56:00+08:00
description: 应用层协议半双工在C/S架构中典型代表是http，这种一问一答会出现逻辑阻塞，早期常使用轮询来处理有实时响应的任务场景全双工主流的长连接方式使用websocket，类似的还有MQTT等协议，解决了轮询在处理实时响应任务时出现的通信延迟问题API类型不同风格API的适用场景不同（由请求的数据决定），没有协议的规定严格，与后端服务返回的数据格式（XML、JSON）配合使用，但核心功能还是：基于某种应用层协议的请求报文解析与响应报文封装。RESTful API最常见的Web API类型，基于 HTTP/HTTPS 协议，配合JSON数据格式轻量、简单且高度可扩展。GraphQL API用于针对数据库中特定数据结构的精确查找，效率高。gRPC API常用于微服务架构中的系统间快速通信。后端异步处理架构与传统的请求驱动模型不同，让后端不同服务之间解耦合，系统扩展性更好。事件/消息驱动本质没有太大差别：事件驱动使用状态机模型，事件处理完成返回一条状态，开始执行下一个任务；消息驱动使用订阅模型，事件处理每一步通过消息来管理是否进入下一个服务，过程更细化。import threading import time # 事件生成器 class EventGenerator(threading.Thread): def __init__(self, event_total): super(EventGenerator, self).__init__() self.event_total = event_total def run(self): for i in range(self.event_total): event = {'type': 'event', 'timestamp': time.time(), 'data': i} event_bus.put(event) time.sleep(1) # 事件处理器 class EventHandler(threading.Thread): def __init__(self, event_total): super(EventHandler, self).__init__() self.event_total = event_total def run(self): for i in range(self.event_total): event = event_bus.get() print(f'处理事件：{event}') time.sleep(1) # 事件总线 from queue import Queue event_bus = Queue() # 启动事件生成器和事件处理器 event_generator = EventGenerator(10) event_handler = EventHandler(10) event_generator.start() event_handler.start() # 等待事件处理完成 event_generator.join() event_handler.join()任务队列异步处理、存储、调度任务的全生命周期import threading import time # 生产者 class Producer(threading.Thread): def __init__(self, message_total): super(Producer, self).__init__() self.message_total = message_total def run(self): for i in range(self.message_total): message = {'type': 'message', 'timestamp': time.time(), 'data': i} message_queue.put(message) time.sleep(1) # 消费者 class Consumer(threading.Thread): def __init__(self, message_total): super(Consumer, self).__init__() self.message_total = message_total def run(self): for i in range(self.message_total): message = message_queue.get() print(f'处理消息：{message}') time.sleep(1) # 消息队列 from queue import Queue message_queue = Queue() # 启动生产者和消费者 producer = Producer…

API接口（1）
type: item
date: 2026-05-26T00:18:00+08:00
description: HTTP通信过程这是一条绝对URI（统一资源标识符）的标准格式：http://user:pass@www.example.com:80/dir/index.htm?uid=1#ch1user:pass：用户认证信息；/dir/index.htm:文件路径；uid=1:查询字符串；ch1:片段标识符URL（统一资源定位器）是其中的一部分，它定义了重要的请求类型和资源路径，下面以GET类型请求和响应为例：# 请求 GET /dir/index.htm HTTP/1.1 Host: www.example.com Connection: keep-alive Content-Type: application/x-www-form-urlencoded Content-Length: 16# 响应 HTTP/1.1 200 OK Date: Tue, 10 Jul 2012 06:50:15 GMT Content-Length: 362 Content-Type: text/html ...HTTP/1.1支持的请求方法请求动词描述操作类型应用场景举例GET获取资源SELECTGET /users 获取所有用户POST创建资源CREATEPOST /users 创建一个新用户PUT全局更新UPDATEPUT /users/123 替换该用户的所有信息PATCH局部更新UPDATEPATCH /users/123 仅更新用户的密码DELETE删除资源DELETEDELETE /users/123 删除该用户............HTTP状态码JSON、DictJSON与字典都是键值对组成，JSON中键只能是字符或字符串，字典的键必须是可哈希（不可变，即对应的内存地址唯一）的对象，如：字符串、数字、元组，目的是为了高效查询，时间复杂度O(1)router_table = { ("GET", "/api/users"): get_all_users_function, ("POST", "/api/users"): create_user_function, ("GET", "/api/articles"): get_articles_function }FastAPI成熟的API框架内部都是先通过正则表达式解析HTTP的请求报文，根据请求类型和资源路径调用后端函数，常见与数据库交互；然后将函数返回值以JSON格式返回，回填进响应报文发送给客户端。以FastAPI为例：app = FastAPI() @app.get("/api/users") def get_all_users(): ... result = [{"id": row[0], "name": row[1], "role": row[2]} for row in rows] return result

内网穿透
type: item
date: 2026-05-16T21:59:00+08:00
description: 技术原理NAT 技术负责实现内网与公网ip转换，同时也起到了隔离保护的作用。中转服务器与内网设备的某个端口建立隧道，等效于将该内网设备的端口服务暴露在公网上，所以可以由其他设备进行连接。frp桌面端服务器部署frps，控制端和被控制端部署frpc，建立连接后可以用Windows任务计划程序库让端口服务在后端运行，还可以升级为系统服务来守护进程。常见的端口服务有：远程桌面服务，可以选择Windows官方的 RDP 连接，也可以选择 VNC 连接；数据库连接；ssh连接；移动端常见的软件有：Windows App Mobile、RVNC Viewer

侧载
type: item
date: 2026-05-16T04:03:00+08:00
description: 问题描述通过侧载为 iOS 安装第三方应用，本质就是要解决 apple 的沙盒机制对软件的签名证书发放及续签申请，但是侧载安装的开发者应用的签名证书有效期只有7天。部署经过由于身边缺少 Mac，只能通过云电脑模拟开发环境，这里用的是 Codemagic，它的 CI/CD 流水线非常丝滑，打包很快，你可以得到一个 Runner.app.zip 压缩包。在本地修改一下压缩结构，然后将.zip改为.ipa，就得到了iOS上运行的软件格式。接下来就进入了侧载环节，常用的侧载工具有：sideloadly、altstore(非欧盟成员国及日本，不支持PAL版)、sidestore(altstore进阶版)，他们在下载时都有一个共性：需要下载iTunes登录apple id验证身份，sideloadly还需要iCloud验证。sideloadly是可以走通的，但是缺少客户端，过期了只能手动重新安装。续签自动化altstore在开发者电脑上可以安装一个服务端，在移动端上安装的就是客户端，服务端通过客户端的真机身份向apple伪装申请一个签证申请，然后交给客户端appsidestore延续这种 C/S 交互模式，并将服务端与客户端一起封装到移动端 app 中，它们之间的通信还需要一个 VPN 提供本地回环隧道，欺骗 iOS 平台的 installd 监管（默认只安装具有apple签名证书的应用）最后的问题sidestore服务端需要连接anisette服务器才能向apple申请证书，官方服务器大多在海外，但是移动端如果打开 VPN 通常与原有的代理冲突，这里我用搭建了一个rust版本的anisette服务器：https://jyjswk.online/anisette.json（需要自取）现在还需要在sidesotre内登录你的apple id就可以正常使用了，但是当前接收apple发来的验证码，sidestore软件无法解析，后面贴出了anisette服务器请求结果、VPN配置、sidestore软件报错信息。

计算机通信协议栈
type: item
date: 2026-05-14T16:32:00+08:00
description: 通信原理外部通信注：图片来自网络内部通信注：图片来自 AI 生成

邮件传输协议
type: item
date: 2026-05-10T23:12:00+08:00
description: SMTP（发送）/IMAP（接收）SMTP: 传输和中继邮件IMAP: 取邮件，更早时候使用 POP3 协议场景案例：用户A使用不同方式给用户B发送类型不同的邮件移动端用户A -[SMTP]-> 邮件服务器A -[SMTP]-> 邮件服务器B <-[IMAP]- 用户Bweb端用户A -[HTTPS]-> Web服务器 -[SMTP]-> 邮件服务器A -[SMTP]-> 邮件服务器B <-[IMAP]- Web服务器 <-[HTTPS]- 用户B总结发/取邮件的过程中，客户端都是主动方IMAP协议本身是短/按需连接，但它有一个扩展叫IDLE（常用于桌面端环境），属于长连接，用于邮件通知SMTP面向的是一个分布式、跨信任域的异步传输，IMAP面向的是一个集中式、个人化的本地在线管理邮件属于跨服务异步通信，与即时通信（IM）存在本质不同

Linux防火墙三层架构
type: item
date: 2026-05-08T20:20:00+08:00
description: 内核级——框架Netfilter基于网络层对数据包进行深度检查，允许或拒绝数据包通过用户态——规则iptables/nftables基于网络层和传输层（跟踪tcp连接状态），根据连接状态来允许或拒绝数据包iptables -L iptables -A INPUT -p tcp --dport [端口号] -j ACCEPT 前端——工具管理ufw/firewalld基于应用层工作，常用于http、ftp等代理服务ufw status ufw allow [端口号]/tcp

HTTPS
type: item
date: 2026-03-21T04:31:00+08:00
description: TLS/SSL证书1、SSL，主要使用MD5加密算法，迭代版本有1.0、2.0、3.02、TLS，主要使用AES加密算法，迭代版本有1.0、1.1、1.2Public/Private key1、公钥常用于加密，明文记录在CA机构颁发的证书里2、私钥除了用于服务端解密，还对证书的明文信息哈希后加签，客户端得到<证书明文信息>和<证书数字签名>，查找本地证书根目录并用公钥解签通信过程1、客户端对服务端发起请求，服务端向客户端发送证书，对比本地受信任的根证书路径判断证书是否有效2、客户端<数据和密钥K>经过<公钥A>加密发送给服务端，用<私钥A>解密获得用户请求与对称加密密钥K3、服务端发送经过<密钥K>加密的响应数据，并由客户端使用<密钥K>进行解密全网最透彻HTTPS加解密原理，看完不懂你来打我（面试常问） - Java汤姆的文章 - 知乎

MkDocs静态网站+Nginx反向代理
type: item
date: 2026-03-16T01:44:00+08:00
description: 用户请求过程nginx配置中，先监听主站的80端口（http）然后重定向到443端口（https），然后又代理到mkdocs服务的8000端口（http），用户访问https://jyjswk.online/mkdocs过程是不是可以描述成下面这样的：1、用户请求服务器ip（这里用的是域名），浏览器默认使用443，用户请求经过ssl加密，到这里是先解密再转发还是未解密继续转发呢，假设先解密再转发。2、从443转发到8000端口，然后本地的8000端口服务返回/mkdocs目录下的主页文件，这时服务端内容再经过对称加密发送给用户服务器端测试链接curl https://jyjswk.online/mkdocs/css/theme.css，返回状态码404curl http://127.0.0.1/mkdocs/css/them.css，返回状态码301curl http://127.0.0.1:8000/mkdocs/css/theme.css，返回状态码200nginx、mkdocs配置文件（部分）location /mkdocs { proxy_pass http://127.0.0.1:8000/mkdocs/; ...} site_url: http://127.0.0.1:8000/mkdocs