✨ 完成从旧站的搬运

2025-08-27 11:19:39 +08:00
parent f667c37701
commit 565aff4a59
11 changed files with 517 additions and 4 deletions
@@ -0,0 +1,59 @@
+---
+{
+  title: "ApiFox / Postman 使用WebSocket连接SignalR需要注意的小问题",
+  description: "使用ApiFox测试SignalR时发现消息发送无响应，原因为未在消息末尾添加结束符0x1e。正确格式为消息体后加0x1e字符，如`{\"protocol\":\"json\",\"version\":1}`。调用方法需按指定JSON结构，并注意不同类型消息的含义。",
+  draft: false,
+  type: "article",
+  created_at: "2024-09-11T15:00:00+08:00",
+  published_at: "2024-09-11T15:08:00+08:00",
+  updated_at: [ "2024-09-11T15:08:00+08:00"],
+  category: '个人',
+  tags: [ "WebSocket" ],
+  tech_stack: [ "WebSocket" ],
+  tech_stack_percent: [ 1 ],
+  tech_stack_icon_names: [ "simple-icons:socketdotio" ],
+  tech_stack_theme_colors: [ "#fdfdfd" ],
+}
+---
+!!!warning  Legacy Article 过时的文章
+此文章从旧博客迁移而来，编写时技术水平有限，仅供参考
+!!!
+
+省流：忘加0x1e
+最近刚接触SignalR，发现用ApiFox怎么都没法测试，可以正常连接，但是发消息没有任何反应。我一度怀疑是自己的环境出了问题。
+![image.png](https://typecho.lichx.top/usr/uploads/2024/09/1251616581.png)
+后来直接使用大佬的代码（带前端）进行测试，发现是正常的。说明这只是操作上的问题。又去搜postman调试SignalR。才找到了这个简单的隐蔽的问题。
+SignalR的交流以0x1e作为结束符。之前没有注意到这一点，走了一些弯路。
+`{"protocol":"json","version":1}`
+这段代码末尾加了个0x1e。可以直接整段复制用于SignalR连接。
+![image.png](https://typecho.lichx.top/usr/uploads/2024/09/2409001684.png)
+TakeAway message:
+如果想要上传消息，格式是：
+
+    {
+      "type": 1,
+      "target": "方法名",
+      "arguments": ["方法参数1", "方法参数2..."]
+    }
+SignalR type 数字含义：（From Copilot）
+1.	Invocation (1)：
+      •	表示客户端或服务器调用一个方法。
+      •	例如，客户端调用服务器上的一个Hub方法。
+2.	StreamItem (2)：
+      •	表示流中的一项数据。
+      •	用于流式传输数据时，每个数据项都会使用这个消息类型。
+3.	Completion (3)：
+      •	表示一个调用或流的完成。
+      •	包含调用的结果或错误信息。
+4.	StreamInvocation (4)：
+      •	表示客户端请求从服务器流式传输数据。
+      •	服务器会返回多个StreamItem消息。
+5.	CancelInvocation (5)：
+      •	表示取消一个流式传输的请求。
+      •	客户端可以发送这个消息来取消一个正在进行的流。
+6.	Ping (6)：
+      •	表示一个心跳消息，用于保持连接活跃。
+      •	没有负载，只是为了确保连接没有超时。
+7.	Close (7)：
+      •	表示连接关闭。
+      •	包含可选的错误信息。
@@ -0,0 +1,60 @@
+---
+{
+  title: "Docker内部网络连接错误的一种检查手段 nmap container",
+  description: "文章讲述了排查容器内应用连接问题的方法。作者创建了一个nmap容器来检查`host.docker.internal`，发现该域名已不可用，实际应使用IP`172.17.0.1`。同时分享了在服务器无法拉取镜像时，通过`docker save`和`docker load`迁移本地镜像的解决方案。最后提到可直接在容器内启动Ubuntu并exec进入操作。",
+  draft: false,
+  type: "article",
+  created_at: "2024-09-23T20:50:00+08:00",
+  published_at: "2024-09-23T21:01:00+08:00",
+  updated_at: [ "2024-09-23T21:01:00+08:00"],
+  category: '个人',
+  tags: [ "Docker" ],
+  tech_stack: [ "Docker" ],
+  tech_stack_percent: [ 1 ],
+  tech_stack_icon_names: [ "mdi:docker" ],
+  tech_stack_theme_colors: [ "#1c90ed" ],
+}
+---
+!!!warning  Legacy Article 过时的文章
+此文章从旧博客迁移而来，编写时技术水平有限，仅供参考
+!!!
+
+最近被一个容器无法内应用无法连接的问题折磨住了，我想看看内部的host.docker.internal到底怎么回事，于是想到建立一个nmap container进去检查
+Dockerfile:
+```
+# 使用官方的 Ubuntu 镜像作为基础镜像
+FROM ubuntu:latest
+
+# 更新包列表并安装 nmap
+RUN apt-get update && apt-get install -y nmap
+
+# 创建一个目录来存储 nmap 结果
+RUN mkdir /nmap_results
+
+# 运行 nmap 并将结果保存到文件中，同时打印到控制台
+CMD ["sh", "-c", "nmap host.docker.internal > /nmap_results/nmap_results.log && cat /nmap_results/nmap_results.log"]
+```
+docker-compose.yml:
+```
+version: '3.4'
+
+services:
+  nmap_service:
+    image: nmap_image:latest
+    build:
+      context: .
+      dockerfile: Dockerfile
+    volumes:
+      - ./nmap_results:/nmap_results
+```
+nmap结果发现不存在host.docker.internal，可能是docker更新的原因。之前是可用的，但现在变成了 `172.17.0.1`
+另附服务器无法pull image时，使用其他机器本地image的方法
+```
+# 机器一
+docker save [imgID] > imagefile
+#机器二
+docker load < imagefile
+docker tag [new_imgID] [随便什么名字]:[随便什么版本]
+```
+最后改掉Dockerfile中的FROM就好了
+写文章时我才想起来，可以直接docker内起ubuntu虚拟机，exec进去操作，忘了。