欢迎一起交流问题！

上面这种方法有一个缺点，就是假如 server_job 的任务执行时间太长的话，需要等待 server_job 执行完后才能继续 accept 下一个连接请求，这样效率十分低，所以可以采用多线程的方式来解决，每个进程或线程处理一个连接请求。udp 会出现丢包的问题，TTL生存周期（路由跳转个数） ，丢包是由阻塞造成的，当等待队列快满的时候会发生丢包（网络太拥塞），可以使用流量控制解决（限制发送端的速率）。多点通信（广播、多播、组播）只能用报式套接字实现，因为流式套接字是一对一的，点对点的。

阻塞io会等待操作的完成或期待事情的到来。会被信号打断（信号会打断阻塞中的系统调用），若被打断则错误码为EINTR（假错）。操作的完成和期待事件的到来会通知阻塞的进程。

信号是软件层面的中断。信号的响应依赖于中断。信号分为标准信号和实时信号。kill -l 可以查看系统中的信号：core 文件是程序出错的现场，可以使用 gdb 对 core 文件进行调试。

系统调用会复制调用进程来创建一个子进程，在父进程中 fork 返回子进程的 pid，在子进程中返回 0。fork 后子进程不继承未决信号和文件锁，资源利用量清 0。由于进程文件描述符表也继承下来的，所以可以看到父子进程的输入输出指向都是一样的，这个特性可以用于实现基本的父子进程通信。

可以通过打开的文件描述符获取文件的属性。lstat() 和 stat() 功能相同，有一点区别就是当 pathname 是一个链接文件的时候，lstat() 返回的是链接文件本身的属性，而不是链接文件指向的文件的属性。下面是 stat 结构体中的部分成员：但 st_size 仅仅是文件的属性，实际占用磁盘的块大小和个数是 st_blksize 和 st_blocks。

不同系统上的系统调用 IO 的使用方式可能不一样，为了隐藏不同系统上的细节，提出了标准 IO 给程序员调用，标准 IO 的实现是依赖于系统调用 IO 的，但是标准 IO 的可移植性更好。系统调用 IO 都是不带缓冲的 IO，而标准 IO 是带缓冲的 IO。

不同系统上的系统调用 IO 的使用方式可能不一样，为了隐藏不同系统上的细节，提出了标准 IO 给程序员调用，标准 IO 底层其实还是调用了系统调用 IO，但是标准 IO 的可移植性更好