chore: 将所有外部图片本地化到仓库

- 下载 110 张外部图片到根目录 images/ 文件夹
- 更新所有 README.md 中的图片引用为统一路径 images/xxx.png
- 55 张图片成功下载（PNG 格式）
- 55 张失效图片创建占位文件（SVG/PNG）
- 移除所有外部图片链接依赖

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

ch13/README.md

@@ -62,9 +62,9 @@ gcc oob_recv.c -o recv
 
 运行结果：
 
-![](https://i.loli.net/2019/01/26/5c4bda167ae08.png)
+![](images/5c4bda167ae08.svg)
 
-![](https://i.loli.net/2019/01/26/5c4bdb4d99823.png)
+![](images/5c4bdb4d99823.svg)
 
 从运行结果可以看出，send 是客户端，recv 是服务端，客户端给服务端发送消息，服务端接收完消息之后显示出来。可以从图中看出，每次运行的效果，并不是一样的。
 
@@ -94,7 +94,7 @@ fcntl(recv_sock, F_SETOWN, getpid());
 
 MSG_OOB 的真正意义在于督促数据接收对象尽快处理数据。这是紧急模式的全部内容，而 TCP 「保持传输顺序」的传输特性依然成立。TCP 的紧急消息无法保证及时到达，但是可以要求急救。下面是 MSG_OOB 可选项状态下的数据传输过程，如图：
 
-![](https://i.loli.net/2019/01/26/5c4be222845cc.png)
+![](images/5c4be222845cc.svg)
 
 上面是:
 
@@ -108,7 +108,7 @@ send(sock, "890", strlen("890"), MSG_OOB);
 
 也就是说，实际上只用了一个字节表示紧急消息。这一点可以通过图中用于传输数据的 TCP 数据包（段）的结构看得更清楚，如图：
 
-![](https://i.loli.net/2019/01/26/5c4beeae46b4e.png)
+![](images/5c4beeae46b4e.svg)
 
 TCP 数据包实际包含更多信息。TCP 头部包含如下两种信息：
 
@@ -137,7 +137,7 @@ gcc peek_send.c -o send
 
 结果：
 
-![](https://i.loli.net/2019/01/26/5c4c0d1dc83af.png)
+![](images/5c4c0d1dc83af.svg)
 
 可以通过结果验证，仅发送了一次的数据被读取了 2 次，因为第一次调用 recv 函数时设置了 MSG_PEEK 可选项。
 
@@ -174,7 +174,7 @@ struct iovec
 
 下图是该函数的使用方法：
 
-![](https://i.loli.net/2019/01/26/5c4c61b07d207.png)
+![](images/5c4c61b07d207.svg)
 
 writev 的第一个参数，是文件描述符，因此向控制台输出数据，ptr 是存有待发送数据信息的 iovec 数组指针。第三个参数为 2，因此，从 ptr 指向的地址开始，共浏览 2 个 iovec 结构体变量，发送这些指针指向的缓冲数据。
 
@@ -274,7 +274,7 @@ gcc readv.c -o rv
 
 运行结果：
 
-![](https://i.loli.net/2019/01/26/5c4c718555398.png)
+![](images/5c4c718555398.svg)
 
 从图上可以看出，首先截取了长度为 5 的数据输出，然后再输出剩下的。
 
@@ -284,7 +284,7 @@ gcc readv.c -o rv
 
 其意义在于减少数据包个数。假设为了提高效率在服务器端明确禁用了 Nagle 算法。其实 writev 函数在不采用 Nagle 算法时更有价值，如图：
 
-![](https://i.loli.net/2019/01/26/5c4c731323e19.png)
+![](images/5c4c731323e19.svg)
 
 ### 13.3 基于 Windows 的实现