网络编程

阻塞 / 非阻塞 VS 同步 / 异步 阻塞 I/O 阻塞 I/O 发起 read 请求，线程会被挂起，一直等到内核数据准备好，并把数据从内核区域拷贝到应用程序的缓冲区中，当拷贝过程完成，read 请

上一讲引入了 reactor 反应堆模式，并让 reactor 反应堆同时分发 Acceptor 上的连接建立事件和已建立连接的 I/O 事件。 这种模式在发起连接请求的客户端非常多的情况下，有一个地

重温事件驱动 基于事件的程序设计: GUI、Web 事件驱动的好处是占用资源少，效率高，可扩展性强，是支持高性能高并发的不二之选。 GUI 设定了一系列的控件，如 Button、Label、文本框等，

线程（thread）是运行在进程中的一个“逻辑流”，现代操作系统都允许在单进程中运行多个线程。线程由内核管理。每个线程都有自己的上下文（context），包括一个可以唯一标识线程的 ID、栈、程序计数

父进程和子进程 进程是程序执行的最小单位，一个进程有完整的地址空间、程序计数器等，如果想创建一个新的进程，使用函数 fork 程序调用 fork 一次，却在父、子进程里各返回一次。在调用该函数的进程（

epoll 的用法 epoll 可以说是和 poll 非常相似的一种 I/O 多路复用技术，有些朋友将 epoll 归为异步 I/O，我觉得这是不正确的。本质上 epoll 还是一种 I/O 多路复用

非阻塞 I/O 读操作 如果套接字对应的接收缓冲区没有数据可读，在非阻塞情况下 read 调用会立即返回，一般返回 EWOULDBLOCK 或 EAGAIN 出错信息。在这种情况下，出错信息是需要小心

select 有一个缺点：它所支持的文件描述符的个数是有限的。在 Linux 系统中，select 的默认最大值为 1024。 那么有没有别的 I/O 多路复用技术可以突破文件描述符个数限制呢？ po

我们先在源码中看看fd_set的定义 __FD_SETSIZE是一个宏定义，为1024，NFDBITS之前求过是64，所以我们的fds_bits数组的个数为16个 我们做个实验： 结果为 这意味着，实

什么是 I/O 多路复用 我们可以使用 fgets 方法等待标准输入，但这样做就没有办法在套接字有数据时读出数据；或者使用 read 方法等待套接字有数据返回，但就没有办法在标准输入有数据的情况下，读

如何理解 TCP 四次握手？ TCP 建立一个连接需 3 次握手，而终止一个连接则需要四次挥手。四次挥手的整个过程是这样的： 首先，一方应用程序调用 close，我们称该方为主动关闭方，该端的 TCP

对端的异常状况 前面我们已经初步接触过一些防范对端异常的方法，比如，通过 read 等调用时，可以通过对 EOF 的判断，随时防范对方程序崩溃。 read 函数返回 0 字节时，实际上就是内核返回 E

TCP 是可靠的？ 你可能会认为 TCP 是一种可靠的协议。发送端程序调用 send 函数发送的数据流总能可靠地到达接收端；而接收端总是可以把对端发送的数据流完整无损地传递给应用程序来处理。 事实上，

TCP 是一种流式协议 在前面的章节中，我们讲的都是单个客户端 - 服务器的例子，可能会给你造成一种错觉，好像 TCP 是一种应答形式的数据传输过程，比如发送端一次发送 network 和 progr

网络编程中，服务器程序需要绑定本地地址和一个端口，监听在这个地址和端口，等待客户端连接的到来。在实战中，你可能经常碰到一个问题，当服务器程序重启后，总是碰到Address in use的报错信息，程序

从一个例子开始 在这个例子中，客户端在 UDP 套接字上调用 connect 函数，之后将标准输入的字符串发送到服务器，并从服务器接收处理后的报文。当然，和服务器发送和接收报文是通过调用函数 send

调用数据发送接口以后…… 在前面的内容中，我们已经熟悉如何通过套接字发送数据，比如使用 write 或 send 方法进行数据流的发送。 我们已经知道，调用这些接口并不意味着数据被真正发送到网络上而只

TCP Keep-Alive 选项 很多刚接触 TCP 编程的人会惊讶地发现，在没有数据读写的连接上，没有办法发现 TCP 连接是否有效。比如客户端突然崩溃，服务器端可能在几天内都维护着一个无用的 T

在使用套接字开发和测试过程中，总会碰到各种问题。学会对这些问题进行诊断和分析，其实需要不断地积累经验。而 Linux 平台下提供的各种网络工具，则为我们进行诊断分析提供了很好的帮助。 ping 在上面

上一讲我们讲到了 TCP 的四次挥手，其中发起连接关闭的一方会有一段时间处于 TIME_WAIT 状态。那么究竟如何来发起连接关闭呢？这一讲我们就来讨论一下。 TCP 连接需要经过三次握手进入数据传输