24/12/15

WindRunnerMax · Dec 15, 2024 · ba69a01 · ba69a01
1 parent 0b7bcfd
commit ba69a01
Show file tree

Hide file tree

Showing 6 changed files with 429 additions and 20 deletions.
diff --git a/MyLife/记一次有意思的种树比赛.md b/MyLife/记一次有意思的种树比赛.md
@@ -395,8 +395,8 @@ while(true){
 ## 最后
 虽然写这个极其上头，但是还有很多事没做，比如老师给的论文下周要做汇报，玩了一下午先不玩了，在我写下这篇文章的时候已经有大佬种到`200w`棵了，我才种了`100w`，然后排行是`82`，在此仰望大佬们哈哈。
 
-## BLOG
+## Blog
 
 ```
-https://github.com/WindrunnerMax/EveryDay/
+https://github.com/WindRunnerMax/EveryDay/
 ```
diff --git a/Plugin/从脚本管理器的角度审视Chrome扩展.md b/Plugin/从脚本管理器的角度审视Chrome扩展.md
diff --git a/Plugin/初探富文本之在线文档交付.md b/Plugin/初探富文本之在线文档交付.md
diff --git a/Plugin/基于WebRTC的局域网文件传输.md b/Plugin/基于WebRTC的局域网文件传输.md
@@ -108,7 +108,7 @@ socket.on("disconnect", () => {
 });
 ```
 
-可以看出我们管理房间是通过`IP`来实现的，因为此时需要注意一个问题，如果我们的信令服务器是部署在公网的服务器上，那么我们的房间就是全局的，也就是说所有的设备都可以连接到同一个房间，这样的话显然是不合适的，解决这个问题的方法很简单，对于服务器而言我们获取用户的`IP`地址，如果用户的`IP`地址是相同的就认为是同一个局域网的设备，所以我们需要获取当前连接的`Socket`的`IP`信息，在这里我们特殊处理了`127.0.0.1`和`192.168.0.0`两个网域的设备，以便我们在本地/路由器部署时能够正常发现设备。
+可以看出我们管理房间是通过`IP`来实现的，因为此时需要注意一个问题，如果我们的信令服务器是部署在公网的服务器上，那么我们的房间就是全局的，也就是说所有的设备都可以连接到同一个房间，这样的话显然是不合适的。解决这个问题的方法很简单，对于服务器而言我们获取用户的`IP`地址，如果用户的`IP`地址是相同的就认为是同一个局域网的设备，所以我们需要获取当前连接的`Socket`的`IP`信息，在这里我们特殊处理了`127.0.0.1`和`192.168.0.0`两个网域的设备，以便我们在本地/路由器部署时能够正常发现设备。
 
 ```js
 // packages/webrtc/server/utils.ts
@@ -417,7 +417,7 @@ ICE Candidate pair: :55305 <=> 2408:8240:e12:3c45:f1ba:c574:6328:a70:45954
 ICE Candidate pair: 101.68.35.129:25595 <=> 101.68.35.129:25596
 ```
 
-在前几天搬砖的时候，我突然想到一个问题，现在都是`IPv6`的时代了，而`STUN`服务器实际上又是支持`IPv6`的，那么如果我们的设备都有全球唯一的公网`IPv6`地址岂不是做到`P2P`互联，从而真的成为互联网，所以我找了朋友测试了一下`IPv6`的链接情况，因为手机设备通常都是真实分配`IPv6`的地址，所以就可以直接在手机上先进行一波测试，首先访问下`test-ipv6`来获取手机的公网`IPv6`地址，并且对比下手机详细信息里边的地址，而`IPv6`目前只要是看到以`2/3`开头的都可以认为是公网地址，以`fe80`开头的则是本地连接地址。在这里我们可以借助`Netcat`也就是常用的`nc`命令来测试，在手机设备上可以使用`Termux`并且使用包管理器安装`netcat-openbsd`。
+在前几天搬砖的时候，我突然想到一个问题，现在都是`IPv6`的时代了，而`STUN`服务器实际上又是支持`IPv6`的，那么如果我们的设备都有全球唯一的公网`IPv6`地址岂不是做到`P2P`互联，从而真的成为互联网。所以我找了朋友测试了一下`IPv6`的链接情况，因为手机设备通常都是真实分配`IPv6`的地址，所以就可以直接在手机上先进行一波测试，首先访问下`test-ipv6`来获取手机的公网`IPv6`地址，并且对比下手机详细信息里边的地址，而`IPv6`目前只要是看到以`2/3`开头的都可以认为是公网地址，以`fe80`开头的则是本地连接地址。在这里我们可以借助`Netcat`也就是常用的`nc`命令来测试，在手机设备上可以使用`Termux`并且使用包管理器安装`netcat-openbsd`。
 
 ```bash
 # 设备`A`监听
@@ -426,7 +426,7 @@ $ nc -vk6 9999
 $ nc -v6 ${ip} 9999 
 ```
 
-这里的测试就很有意思了，然后我屋里的路由器设备已经开启了`IPv6`，而且关闭了标准中未定义而是社区提供的`NAT6`方案，并且使用获取`IPv6`前缀的`Native`方案，然而无论我如何尝试都不能通过我的电脑连接到我的手机，实际上即使我的电脑没有公网地址而只要手机有公网地址，那么从电脑发起连接请求并且连接到手机，但是可惜还是无法建立链接，但是使用`ping6`是可以`ping`通的，所以实际上是能寻址到只是被拦截了连接的请求，后来我尝试在设备启动`HTTP`服务也无法直接建立链接，或许是有着一些限制策略例如`UDP`的报文必须先由本设备某端口发出后这个端口才能接收公网地址报文。再后来我找我朋友的手机进行连接测试，我是联通卡朋友是电信卡，我能够连接到我的朋友，但是我朋友无法直接连接到我，而我们的`IPv6`都是`2`开头的是公网地址，然后我们怀疑是运营商限制了端口所以尝试不断切换端口来建立链接，还是不能直接连接。
+这里的测试就很有意思了，然后我屋里的路由器设备已经开启了`IPv6`，而且关闭了标准中未定义而是社区提供的`NAT6`方案，并且使用获取`IPv6`前缀的`Native`方案。然而无论我如何尝试都不能通过我的电脑连接到我的手机，实际上即使我的电脑没有公网地址而只要手机有公网地址，那么从电脑发起连接请求并且连接到手机，但是可惜还是无法建立链接，但是使用`ping6`是可以`ping`通的，所以实际上是能寻址到只是被拦截了连接的请求。后来我尝试在设备启动`HTTP`服务也无法直接建立链接，或许是有着一些限制策略例如`UDP`的报文必须先由本设备某端口发出后这个端口才能接收公网地址报文。再后来我找我朋友的手机进行连接测试，我是联通卡朋友是电信卡，我能够连接到我的朋友，但是我朋友无法直接连接到我，而我们的`IPv6`都是`2`开头的是公网地址，然后我们怀疑是运营商限制了端口所以尝试不断切换端口来建立链接，还是不能直接连接。
 
 于是我最后测试了一下，我换到了我的卡`2`电信卡，此时无论是我的朋友还是我的电脑都可以直接通过电信分配的`IPv6`地址连接到我的手机了。这就很难绷，而我另一个朋友的联通又能够直接连接，所以在国内的网络环境下还是需要看地域性的。之后我找了好几个朋友测试了`P2P`的链接，因为只要设备双方只要有一方有公网的`IP`那么大概率就是能够直接`P2P`的，所以通过`WebRTC`连接的成功率还是可以的，并没有想象中那么低，但我们主要的场景还是局域网传输，只是我们会在项目中留一个输入对方`ID`用以跨网段链接的方式。
 
@@ -574,7 +574,7 @@ const onDownloadFile = (id: string, fileName: string) => {
 };
 ```
 
-在后来补充了一下多文件传输的方案，具体的思路是构造`ArrayBuffer`，其中前`12`个字节表示当前块所属的文件`ID`，再使用`4`个字节也就是`32`位表示当前块的序列号，其余的内容作为文件块的实际内容，然后就可以实现文件传输的过程中不同文件发送块，然后就可以在接收端通过存储的`ID`和序列号进行`Blob`组装，思路与后边的`WebSocket`通信部分保持一致，所以在这里只是描述一下`ArrayBuffer`的组装方法。
+在后来补充了一下多文件传输的方案，具体的思路是构造`ArrayBuffer`，其中前`12`个字节表示当前块所属的文件`ID`，再使用`4`个字节也就是`32`位表示当前块的序列号，其余的内容作为文件块的实际内容。然后就可以实现文件传输的过程中不同文件发送块，然后就可以在接收端通过存储的`ID`和序列号进行`Blob`组装，思路与后边的`WebSocket`通信部分保持一致，所以在这里只是描述一下`ArrayBuffer`的组装方法。
 
 ```js
 // packages/webrtc/client/utils/binary.ts
@@ -824,7 +824,7 @@ const onSendFile = () => {
 };
 ```
 
-在接收消息的地方，我们改变了策略，因为当前的数据是纯文本携带了很多数据，所以对于文件分块而言我们的可控性更高了，所以我们采用一种客户端请求的多文件分片策略，具体就是说在`A`向`B`发送文件的时候，我们由`B`来请求我希望拿到的下一个文件分片，`A`在收到请求的时候将这个文件进行切片然后发送给`B`，当这个文件分片传输完成之后再继续请求下一个，直到整个文件传输完成，而每个分片我们都携带了所属文件的`ID`以及序列号、总分片数量等等，这样就不会因为多文件传递的时候造成混乱，而且两端的文件传输进度是完全一致的，不会因为缓冲区的差异造成两端传输进度上的差别。
+在接收消息的地方，我们改变了策略，因为当前的数据是纯文本携带了很多数据，所以对于文件分块而言我们的可控性更高了，所以我们采用一种客户端请求的多文件分片策略。具体就是说在`A`向`B`发送文件的时候，我们由`B`来请求我希望拿到的下一个文件分片，`A`在收到请求的时候将这个文件进行切片然后发送给`B`，当这个文件分片传输完成之后再继续请求下一个，直到整个文件传输完成。而每个分片我们都携带了所属文件的`ID`以及序列号、总分片数量等等，这样就不会因为多文件传递的时候造成混乱，而且两端的文件传输进度是完全一致的，不会因为缓冲区的差异造成两端传输进度上的差别。
 
 ```js
 // packages/websocket/client/components/modal.tsx

diff --git a/_sidebar.md b/_sidebar.md
@@ -273,6 +273,7 @@
   * [初探webpack之解析器resolver](Plugin/初探webpack之解析器resolver.md)
   * [基于ServiceWorker的文件传输方案](Plugin/基于ServiceWorker的文件传输方案.md)
   * [初探富文本之搜索替换算法](Plugin/初探富文本之搜索替换算法.md)
+  * [从脚本管理器的角度审视Chrome扩展](Plugin/从脚本管理器的角度审视Chrome扩展.md)
 
 * Patterns
   * [简单工厂模式](Patterns/简单工厂模式.md)

diff --git a/index.html b/index.html
@@ -24,6 +24,8 @@
     <style type="text/css">
       aside.sidebar {
         overscroll-behavior: contain;
+        scrollbar-color: rgb(201, 205, 212) transparent;
+        scrollbar-width: thin;
       }
     </style>
     <!-- <meta name="referrer" content="no-referrer"> -->