杂记 02

1 WSL安装

WSL的安装遇到了问题，睡醒起来发现电脑蓝屏了，linux系统没装好，但是好像大部分开发环境都是linux下需要的，先这样用一下吧，到时候再说。可以问下前辈开发细节，主要是网络代理问题，保存不了。

WSL 安装过程中电脑出现蓝屏，可能和虚拟化资源配置冲突、驱动冲突或内存不足等有关。至于网络代理无法保存，通常是 NAT 模式 WSL 不支持 localhost 代理所致。下面是具体的解决建议：

处理 WSL 安装致蓝屏的问题

• 调整虚拟化参数配置：WSL2 基于 Hyper-V 实现，可调整分配资源缓解冲突。在 PowerShell 执行以下命令编辑其全局配置文件：

plaintext

wsl --shutdown
notepad $env:USERPROFILE\.wslconfig

在打开的文件中按需添加类似如下内容后保存：

plaintext

memory=4GB  
processors=2  
swap=2GB  

• 更新系统及驱动：确保 Windows 系统已更新到最新服务包，其包含 WSL 功能增强补丁或兼容修复。同时，更新显卡等硬件驱动，避免因驱动老旧与 WSL2 产生冲突。

解决 WSL 网络代理无法保存的问题

可通过修改 .wslconfig 文件，把网络模式设为 mirrored 并启用 autoProxy 来处理。步骤如下：

• 创建或编辑 .wslconfig 文件：打开文件资源管理器进入 C:\Users\你的用户名\ 目录，创建或找到 .wslconfig 文件，右键用记事本打开。
• 添加网络与代理配置内容：写入以下内容：

plaintext

[experimental]
autoMemoryReclaim=gradual
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true

• 保存配置并重启 WSL：保存 .wslconfig 文件关闭编辑器，再于 PowerShell 运行 wsl --shutdown，等待片刻后重新启动 WSL 使配置生效。

上述 networkingMode=mirrored 能让 WSL 与 Windows 宿主机共享网络接口，autoProxy=true 可让代理配置自动同步至 WSL 环境。不过 mirrored 等属实验性配置，可能存在罕见兼容问题。

------------------------------------------------

也许好像现阶段还没有需求要用这个wsl，也可以选择双系统或者vmware（这个已经可以用了），据说这个本来就比较麻烦新手容易踩坑，可以后续自己学一点linux操作系统的课，总之自己要多学不要期望学校里可以教会什么。计算机就是自学的在实践中的工科。

2 Git 克隆速度慢与缓存设置

今天拉取仓库的代码的时候出现了错误，clone 的速度也很慢

error: RPC failed; curl 56 Recv failure: Connection was reset
error: 4307 bytes of body are still expected
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output

但是输入了这个增加git缓存就好了（该命令将缓存大小设置为 500MB，足够应对大多数仓库）

git config --global http.postBuffer 524288000

------------------------------------------------

Git 克隆速度慢或出现类似 RPC failed; curl 56 Recv failure 的错误，确实可能与缓存设置有关，但也可能涉及其他因素。下面详细解释相关原因和原理：

1. Git 缓存（buffer）的作用

Git 在克隆或拉取代码时，会通过 HTTP/HTTPS 协议传输数据，此时需要一个缓冲区（buffer）临时存储传输的数据。默认情况下，Git 的 HTTP 缓存大小（http.postBuffer）设置相对较小（通常约 1MB）。

当克隆大型仓库（包含大量文件、大文件或历史提交记录）时，传输的数据量可能超过默认缓存大小，导致：

• 传输中断（如 Recv failure: Connection was reset）
• 速度变慢（频繁的缓存读写和数据分片传输）

2. 为什么缓存不足会导致克隆慢或失败？

• 数据分片传输：缓存不足时，Git 会将数据分成多个小块传输，每块传输完成后需要重新建立连接或确认，增加了网络交互开销，拖慢整体速度。
• 网络稳定性敏感：小块数据传输对网络波动更敏感，一旦中间某块传输失败，可能导致整个克隆过程中断（出现类似 early EOF 错误）。
• 服务器限制：部分服务器对单次请求的数据包大小有限制，缓存不足可能触发服务器的流量控制或超时机制。

3. 其他导致克隆慢的常见原因

除了缓存，这些因素也可能影响克隆速度：

• 网络环境：
  • 本地网络不稳定、带宽不足。
  • 与 GitHub 服务器的连接质量（跨国网络可能存在延迟或丢包）。
• 仓库本身特性：
  • 仓库体积过大（包含大文件、历史提交多）。
  • 分支数量多、标签多（需要同步额外的元数据）。
• Git 配置或工具限制：
  • 未启用压缩传输（core.compression 配置过低）。
  • 代理代理或代理配置不当。

4. 优化建议

除了增大缓存（git config --global http.postBuffer 524288000，即 500MB），还可以尝试：

• 启用压缩：

  bash

  git config --global core.compression 6  # 压缩级别 0-9，6 是平衡值
  

• 浅克隆（适合仅需最新代码）：

  bash

  git clone --depth 1 <仓库地址>  # 只克隆最近1次提交，体积更小
  

• 使用 SSH 协议：
  相比 HTTPS，SSH 协议在部分网络环境下更稳定，克隆前需配置 SSH 密钥：

  bash

  git clone [e-mail]:weblab-workshops/catbook-react.git  # SSH 地址
  

• 检查网络代理：
  若使用代理，确保 Git 正确配置：

  bash

  git config --global http.proxy http://代理地址:端口
  git config --global https.proxy https://代理地址:端口
  

总结：缓存不足是导致大型仓库克隆失败或变慢的常见原因之一，通过调大缓存可以缓解；但克隆速度还受网络质量、仓库大小等因素影响，需结合具体情况优化。

3 SSH 协议是什么？远程连接服务器？

SSH（Secure Shell，安全外壳协议）是一种网络协议，主要用于在不安全的网络环境中建立加密的远程连接，实现对远程服务器或设备的安全管理。它的核心作用是提供加密的远程登录、命令执行、文件传输等功能，替代了传统的明文传输协议（如 Telnet、FTP），大幅提升了远程操作的安全性。

SSH 的核心用途：

1. 远程服务器管理
   最常见的用途是通过命令行远程登录服务器（如 Linux 服务器、云服务器等），执行命令、配置系统、部署应用等。例如，开发者常用 SSH 连接云服务器进行代码部署或运维操作。

2. 加密数据传输
   SSH 通过非对称加密（如 RSA、ED25519）建立连接，所有传输传输的数据（包括用户名、密码、命令、文件等）都会被加密，防止被窃听或篡改。

3. 文件传输
   基于 SSH 协议的工具（如scp、sftp）可安全传输文件，替代不安全的 FTP 协议。

4. 端口转发 / 隧道
   可通过 SSH 建立加密隧道，转发其他协议的流量（如 HTTP、数据库连接），实现安全访问内网服务。

与 Git 的关系：

在代码管理中，SSH 常被用于 Git 仓库的远程连接（如 GitHub、GitLab），替代 HTTPS 协议克隆 / 推送代码：

• 优势：无需每次输入用户名密码（通过 SSH 密钥认证），且在部分网络环境下更稳定。
• 示例：用 SSH 地址克隆仓库

  bash

  git clone [e-mail]:用户名/仓库名.git
  

总结：

SSH 本质是一种安全的远程通信协议，核心是通过加密保护远程操作的安全性，不仅用于服务器远程管理，也广泛应用于代码仓库访问、文件传输等场景。

【在多人协作开发的时候我好像用过这个ssh通道】

在多人协作开发中，SSH 协议确实是非常常用的工具，主要用于安全地访问远程代码仓库（如 GitHub、GitLab、企业自建 Git 服务器等）和协作管理代码，核心优势体现在以下几个场景：

1. 免密访问远程仓库，提升协作效率

多人协作时，团队成员需要频繁地从远程仓库拉取（git pull）、推送（git push）代码。

• 如果用 HTTPS 协议，每次操作可能需要输入用户名和密码（或个人访问令牌），频繁输入会降低效率。
• 而通过 SSH 密钥认证后，只需在本地配置一次 SSH 密钥并添加到远程仓库（如 GitHub 的「SSH keys」设置），后续所有操作都无需重复验证，直接通过加密通道完成，大幅提升协作流畅度。

2. 安全共享代码，保护敏感信息

SSH 采用非对称加密（公钥 + 私钥），所有数据传输全程加密，能有效防止代码传输过程中被窃听或篡改。

• 团队成员只需将自己的公钥添加到共享仓库的权限列表中，即可获得访问权限，无需共享账号密码，避免了密码泄露风险。
• 对于企业内部私有仓库，SSH 还可以配合服务器的 SSH 配置（如 authorized_keys）精细控制谁能访问仓库，方便团队权限管理。

3. 远程协作调试（通过 SSH 隧道）

在复杂协作场景中（如联调服务器环境），还可以通过 SSH 隧道（端口转发）安全访问团队共享的开发服务器或数据库：

bash

# 示例：将远程服务器的 3000 端口映射到本地 8080 端口，方便本地访问远程服务
ssh -L 8080:localhost:3000 用户名@远程服务器地址

这样团队成员无需直接暴露服务器公网地址，就能安全地协作调试。

总结

SSH 在多人协作中最核心的作用是简化远程仓库的访问流程和保障数据传输安全，尤其适合团队高频次的代码同步操作。配置一次 SSH 密钥后，团队成员可以专注于代码开发，而不必在认证环节浪费时间，是协作开发中的基础工具之一。