阻塞式 I/O：“有美人兮，见之不忘，一日不见兮，思之如狂。” select：“所用皆鹰腾，破敌过箭疾” select() 允许一个程序监听多个文件描述符，等待一个或者多个文件描述符的 I/O 操作变成“就绪”状态（比如：可读）。对 sel

select，poll，epoll 都是 IO 多路复用的机制。I/O 多路复用就是通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。但 select，poll，epoll 本质

注：本文是对众多博客的学习和总结，可能存在理解错误。请带着怀疑的眼光，同时如果有错误希望能指出。 同步 IO 和异步 IO，阻塞 IO 和非阻塞 IO 分别是什么，到底有什么区别？不同的人在不同的上下文下给出的答案是不同的。所以先限定一下本

说明 本文以 TCP 的发展历程解析容易引起混淆、误会的方方面面 本文不会贴大量的源码，大多数是以文字形式描述，我相信文字看起来是要比代码更轻松的 针对对象：对 TCP 已经有了全面了解的人。因为本文不会解析 TCP 头里面的每一个字段或者

TCP 协议作为一个可靠的面向流的传输协议，其可靠传输与流量控制由滑动窗口协议保证，而拥塞控制则由拥塞窗口结合一系列的控制算法实现。 滑动窗口协议关于这部分自己不晓得怎么叙述才好，因为理解的部分更多，下面就用自己的理解来介绍下 TCP 的精

为了实现可靠性传输，需要考虑很多事情，例如数据的破坏、丢包、重复以及分片顺序混乱等问题。如不能解决这些问题，也就无从谈起可靠传输。那么，TCP 是通过序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输的。今天，将重点介绍

问题：服务端出现大量 CLOSE_WAIT 状态，什么原因？有什么危害？应该怎么办？ CLOSE_WAIT 是什么时候出现的回答这个问题，首先需要知道 CLOSE_WAIT 状态是什么时候出现的？还是回到经典的四次挥手过程，这个过程得不断

问题：TCP 在 CLOSE_WAIT 状态还能收到报文吗？ 先说答案首先给出答案：能收到报文，而且还能正确地回复 ACK。 从四次挥手看先从四次挥手说起（不熟悉的话，可以先看《三次握手与四次挥手》），这道面试题比较简单： 我们都知道 T

今天来讲一讲 TCP 的 TIME_WAIT 的问题。这个问题尽人皆知，不过，这次遇到的是不太一样的场景，前两天也解决了，正好写篇文章，顺便把 TIME_WAIT 的那些事都说一说。对了，这个场景，跟我开源的探活小工具 EaseProbe

问题背景文首的状态机图展示了通信双方建立 TCP 连接之后的状态转换过程（图片来源：tcpipguide.com）。 通信双方中，主动发起关闭连接的一端，存在 TIME_WAIT 状态；被动接受关闭连接的一端，会进入 CLOSE_WAIT

一、问题描述（一）现象描述服务器有两个现象，第一是 TCP 连接数不多，不超过 10 个，但是 TIME_WAIT 状态的连接却有 2000。第二是按照以往的性质，在很少用户访问的情况下，服务器的资源几乎没有使用，比如 CPU 不超过 5%

如果一个服务端和一个客户端建立 TCP 连接后，服务端一直 sleep，然后客户端一直发送数据，会是什么现象？ 要回答这个问题，首先我们需要知道 socket 缓冲区和 TCP 发送数据流程。 每个 socket 在创建成功后，内核都会自