UNIX下可用的I/O模型：
阻塞式I/O；
非阻塞式I/O；
I/O复用（select，poll，epoll...）；
信号驱动式I/O（SIGIO）；
异步I/O（POSIX的aio_系列函数）；
再看POSIX对这两个术语的定义：
同步I/O操作：导致请求进程阻塞，直到I/O操作完成；
异步I/O操作：不导致请求进程阻塞。
好，下面我用我的语言来总结一下阻塞，非阻塞，同步，异步
阻塞，非阻塞：进程/线程要访问的数据是否就绪，进程/线程是否需要等待；
同步，异步：访问数据的方式，同步需要主动读写数据，在读写数据的过程中还是会阻塞；异步只需要I/O操作完成的通知，并不主动读写数据，由操作系统内核完成数据的读写。
更多阅读：http://blog.51cto.com/yaocoder/1308899
并发TCP连接数
文件句柄限制
端口号范围限制
更多阅读：http://blog.51cto.com/yaocoder/1312821
TCP半开连接的处理
什么是半开连接？
当客户端与服务器建立起正常的TCP连接后，如果客户主机掉线（网线断开）、电源掉电、或系统崩溃，服务器进程将永远不会知道（通过我们常用的select，epoll监测不到断开或错误事件），如果不主动处理或重启系统的话对于服务端来说会一直维持着这个连接，任凭服务端进程如何望穿秋水，也永远再等不到客户端的任何回应。这种情况就是半开连接，浪费了服务器端可用的文件描述符。
如何处理？
熟悉套接字通用选项的朋友一定已经有了想法。TCP套接字不是有个保持存活选项SO_KEEPALIVE嘛，如果在两个小时之内在该套接字的任何一个方向上都没数据交换，TCP就自动给对端发送一个保持存活探测分节，如果此TCP探测分节的响应为RST，说明对端已经崩溃且已经重新启动，该套接字的待处理错误被置为ECONNRESET，套接字本身则被关闭。如果没有对此TCP探测分节的任何响应，该套接字的处理错误就被置为ETIMEOUT，套接字本身则被关闭。
确实，这个选项确实可以处理我们前面遇到的TCP半开连接的问题，但是默认两小时间隔探测的实时性是不是差了些呢？当然，我们可以通过修改内核参数改小时间间隔，完美了吧？但是必须注意的是大多数内核是基于整个内核维护这些时间参数的，而不是基于每个套接字维护的，因此如果把无活动周期从两小时改为（比如）2分钟，那将影响到该主机上所有开启了此选项的套接字。我想大家都不会愿意承担服务器端的这种不确定性吧。另外，心跳除了说明应用程序还活着（进程存在，网络畅通），更重要的是表明应用程序能正常工作。而SO_KEEPALIVE由操作系统负责探查，即便是进程死锁或有其他异常，操作系统也会正常收发TCP keepalive消息，而对方无法得知这一异常。
没关系，其实我们可以在应用层模拟SO_KEEPALIVE的方式，用心跳包来模拟保活探测分节。由于服务器通常要承担成千上万的并发连接，所以肯定是由客户端在应用层进行心跳来模拟保活探测分节，客户端多次收不到服务器的响应时可终止此TCP连接，而服务端可监测客户端的心跳包，若在一定时间间隔内未收到任何来自客户端的心跳包则可以终止此TCP连接，这样就有效避免了TCP半开连接的情况。
参考书籍：
《UNIX网络编程：卷1》
《Linux多线程服务端编程》
转自：http://blog.51cto.com/yaocoder/1309358
TCP的TIME_WAIT状态在服务器开发中的影响？
在进行TCP高并发服务器开发时，有些规则仿佛是约定俗成的，很多朋友会依据这些规则去做，比如高并发TCP服务器中进行主动关闭的一方最好是客户端、服务器端程序最好启用SO_REUSEADDR选项，但是很多人却不知所以然，我们为什么要这么做呢？
TIME_WAIT状态有两个存在的理由
可靠地实现TCP全双工连接的终止；
允许老的重复分节在网络中消逝；
更多阅读：http://blog.51cto.com/yaocoder/1338567
TCP协议的“流”特性
更多阅读：http://blog.51cto.com/yaocoder/1339958
TCP连接拔掉网线后会发生什么
背景：前些天团队在进行终端设备和服务器端长连接业务的测试时，发现了这么一个情况：在拔掉设备端的网线后，再插上网线，有时可以继续正常的进行长接连请求，而且用的还是拔掉网线之前的那个长连接。但是有时却不能继续正常的长连接请求，需要重新建立一个新的长连接。让我尤感诧异的是第一种网线断开再插上后长连接可以恢复的情况，彻底颠覆了我一直抱有的一个所谓的“物理连接”的观念。究竟怎么回事，我们来探个究竟。
更多阅读：http://blog.51cto.com/yaocoder/1589919
https://www.ibm.com/developerworks/cn/aix/library/0808_zhengyong_tcp/index.html
