Files
riba2534 5625eea472 docs: 全面校对全部章节文档与示例代码
通过多智能体工作流对 19 章笔记(README.md)与 96 个 .c 示例代码做深度
审查与对抗性验证,修复 317 处确认问题,涵盖:

技术正确性:
- 修复缓冲区溢出:echo_mpserv.c / echo_storeserv.c 等的 read(buf, BUFSIZ)
  改为 BUF_SIZE(buf 仅 30 字节,BUFSIZ 远大于此)
- 修复 open() 缺少 mode 参数:low_open.c / fd_seri.c / desto.c 等
  O_CREAT 调用补 0644(原导致 low_read 链路失败)
- 修复 feof 循环 off-by-one:news_sender.c / echo_stdserv.c 改用 fgets
  返回值判断
- 修复线程竞态:chat_server.c / webserv_linux.c 的 &clnt_sock 栈地址
  传子线程改为 malloc 分配 + free
- 修复索引混淆:char_EPLTserv.c 错用 clnt_sock 查找改为 ep_events[i].data.fd
- 修复格式化符:thread4.c 的 sizeof 用 %d 改为 %zu
- 修正习题答案:ch01 fd 序号、ch13 MSG_OOB 加粗项、ch09 Nagle 等

文档规范:
- 统一术语:IPv4/IPv6、接收(receive)/连接(connection)
- 修正错别字:occured→occurred、cooffee→coffee、Usgae→Usage、
  eerror→error、proess→process 等
- 修复病句、补全习题答案解释
- GitHub 绝对 URL 改为相对路径,统一项目引用规范
- 同步根 README.md(前言 + 19 章合并)

另:重命名 ch10/remove_zomebie.c → remove_zombie.c(修正拼写)

所有 .c 文件经 gcc 编译验证通过(ch17 epoll 文件因 macOS 无 sys/epoll.h
跳过,已人工复核)。
2026-06-28 12:47:46 +08:00
..

第 15 章 套接字和标准I/O

本章代码,在TCP-IP-NetworkNote中可以找到。

15.1 标准 I/O 的优点

15.1.1 标准 I/O 函数的两个优点

除了使用 read 和 write 函数收发数据外,还能使用标准 I/O 函数收发数据。下面是标准 I/O 函数的两个优点:

  • 标准 I/O 函数具有良好的移植性
  • 标准 I/O 函数可以利用缓冲提高性能

创建套接字时,操作系统会准备 I/O 缓冲。此缓冲在执行 TCP 协议时发挥着非常重要的作用。此时若使用标准 I/O 函数,将得到额外的缓冲支持。如下图:

假设使用 fputs 函数传输字符串「Hello」时首先将数据传递到标准 I/O 缓冲,然后将数据移动到套接字输出缓冲,最后将字符串发送到对方主机。

设置缓冲的主要目的是为了提高性能。从以下两点可以说明性能的提高:

  • 传输的数据量
  • 数据向输出缓冲移动的次数。

比较 1 个字节的数据发送 10 次的情况和 10 个字节发送 1 次的情况。发送数据时,数据包中含有头信息。头信息与数据大小无关,是按照一定的格式填入的。假设头信息占 40 个字节,需要传输的数据量也存在较大区别:

  • 1 个字节 10 次40*10=400 字节
  • 10个字节 1 次40*1=40 字节。

15.1.2 标准 I/O 函数和系统函数之间的性能对比

下面是利用系统函数的示例:

下面是使用标准 I/O 函数复制文件

对于以上两个代码进行测试,明显基于标准 I/O 函数的代码跑得更快。这是因为标准 I/O 函数通过缓冲区减少了系统调用的次数,每次系统调用都有一定的开销(用户态与内核态的切换),而缓冲机制可以将多次小数据量的 I/O 操作合并为较少次数的系统调用,从而提高性能。

15.1.3 标准 I/O 函数的几个缺点

标准 I/O 函数存在以下几个缺点:

  • 不容易进行双向通信
  • 有时可能频繁调用 fflush 函数
  • 需要将文件描述符转换为 FILE 结构体指针才能使用。

15.2 使用标准 I/O 函数

15.2.1 利用 fdopen 函数转换为 FILE 结构体指针

函数原型如下:

#include <stdio.h>
FILE *fdopen(int fildes, const char *mode);
/*
成功时返回转换的 FILE 结构体指针,失败时返回 NULL
fildes  需要转换的文件描述符
mode  将要创建的 FILE 结构体指针的模式信息
*/

以下为示例:

#include <stdio.h>
#include <fcntl.h>

int main()
{
    FILE *fp;
    int fd = open("data.dat", O_WRONLY | O_CREAT | O_TRUNC); //创建文件并返回文件描述符
    if (fd == -1)
    {
        fputs("file open error", stdout);
        return -1;
    }
    fp = fdopen(fd, "w"); //返回 写 模式的 FILE 指针
    fputs("NetWork C programming \n", fp);
    fclose(fp);
    return 0;
}

编译运行:

gcc desto.c -o desto
./desto
cat data.dat

运行结果:

文件描述符转换为 FILE 指针,并可以通过该指针调用标准 I/O 函数。

15.2.2 利用 fileno 函数转换为文件描述符

函数原型如下:

#include <stdio.h>
int fileno(FILE *stream);
/*
成功时返回文件描述符,失败时返回 -1
*/

示例:

#include <stdio.h>
#include <fcntl.h>

int main()
{
    FILE *fp;
    int fd = open("data.dat", O_WRONLY | O_CREAT | O_TRUNC);
    if (fd == -1)
    {
        fputs("file open error", stdout);
        return -1;
    }

    printf("First file descriptor : %d \n", fd);
    fp = fdopen(fd, "w"); //转成 file 指针
    fputs("TCP/IP SOCKET PROGRAMMING \n", fp);
    printf("Second file descriptor: %d \n", fileno(fp)); //转回文件描述符
    fclose(fp);
    return 0;
}

15.3 基于套接字的标准 I/O 函数使用

把第四章的回声客户端和回声服务端的内容改为基于标准 I/O 函数的数据交换形式。

代码如下:

编译运行:

gcc echo_client.c -o eclient
gcc echo_stdserv.c -o eserver

结果:

可以看出,运行结果和第四章相同,这是利用标准 I/O 实现的。

15.4 习题

以下答案仅代表本人个人观点,可能不是正确答案。

  1. 请说明标准 I/O 的 2 个优点。它为何拥有这 2 个优点?

    答:①具有很高的移植性②有良好的缓冲提高性能。

    移植性的原因:标准 I/O 函数是由 ANSI C 标准定义的,在任何符合 ANSI C 标准的平台上都能使用,适合所有编程领域。

    性能的原因:标准 I/O 函数内部维护了用户态缓冲区,数据首先在缓冲区中积累,当缓冲区填满或显式刷新时才一次性调用系统函数(如 write)进行实际 I/O。这减少了用户态与内核态之间上下文切换的次数从而显著提高了性能。

  2. 利用标准 I/O 函数传输数据时,下面的说法是错误的

    调用 fputs 函数传输数据时,调用后应立即开始发送!

    为何上述说法是错误的?为达到这种效果应该添加哪些处理过程?

    答:因为标准 I/O 函数使用缓冲机制,调用 fputs 后数据只是被写入到用户态的缓冲区中,而不是立即发送到套接字输出缓冲或对端主机。只有在缓冲区满、缓冲区方向改变(如从读切换到写)、文件关闭或显式刷新时,数据才会真正发送。

    为达到立即发送的效果,应该在调用 fputs 后添加 fflush 函数来刷新缓冲区,例如:

    fputs("Hello", fp);
    fflush(fp);  // 强制将缓冲区数据发送