fix: 将错误命名的 .svg 文件重命名为 .png

- 8 个文件扩展名错误（.svg 但内容是 PNG）
- 已重命名为正确的 .png 扩展名
- 更新所有 README.md 中的图片引用

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

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

README.md

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

ch13/README.md

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