1、TCP/IP协议栈无法将连接的丢失立即通知应用程序.
TCP为什么不提供这种通知机制，不这么做的优点和缺点，应用程序怎么检测链接的丢失。
2、TCP为什么不提供连接丢失即时通知的功能？
a、其他通信协议，比如SNA和X.25，在连接丢失的时候会通知应用程序。他们是如何做到的？
他们的策略是轮询发送显示报文"有东西要发给我吗？" 或者采用后台静态帧的形式，不断地监视虚电路的状况，
这意味着要消耗一定的网络带宽。这是原因之一。
b、还有哲学方面的考虑，上层协议不应该对下层协议做任何假设，TCP只是负责发送数据报.
应用程序根据需求，来决定是否检测连接的丢失。
c、还有一个重要的原因，和TCP/IP的主要设计目标有关：出现网络故障时维护通信的能力。
TCP/IP的起源是美国国防部要求，出现战争或者自然灾害等严重网络故障，也能维护可靠通信的网络协议。
也就是说，网络故障往往是暂时的，路由器会重新找到一条路径，可以认为具备自动修复的功能.
这种暂时的连接丢失，再应用程序还没有意识到的时候就已经恢复好了。如果连接丢失立即通知应用程序，反而不是所期望的。
3、如何检测连接的丢失呢？
4、TCP的保活机制，是为了检测长时间没有交互的死连接，并且丢弃这些连接。
TCP/IP协议栈运行在系统内核，独立于应用程序。如果对等应用程序终止或者崩溃，内核中的TCP/IP协议栈会发送fin包，
表明我不再向对端发送数据了。
如果对等应用程序所在的主机崩溃，运行在内核中的TCP/IP协议栈也立即退出了，来不及发送fin包。
如果到达对等主机，但是应用程序没有运行，内核中的TCP/IP协议栈发送rst包。
5、TCP的保活机制涉及到时间间隔，要求是至少2个小时的默认空闲时间，然后发送9次探测信号，每次间隔75秒。
这就意味着TCP的保活机制要2个多小时以后才能检测到连接丢失。
这两个时间间隔可以修改，但是这种修改是全局的，会影响到所有的TCP连接。
如何时间间隔设置太短，就违背了它清除长时间死连接的最初目标。
另外，TCP保活机制不仅检测死连接，还丢弃这些连接，这往往不是应用程序所期望的。
6、那么问题来了，应用程序如何检测连接的丢失呢？
在应用程序添加心跳，设置心跳的频率，已经多久收不到心跳信号，认为连接丢失了。
7、还有另外一种办法，思路是使用一条新的连接来发送心跳信号，也就是一条连接来检测另一条连接，看起来很奇怪，但是非常合理。 因为，对于网络故障或者系统崩溃，这两条连接要么都受到影响，要么都不会。具体实现往往是：启动一个新的线程用于心跳控制。
8、TCP没有提供连接丢失即时通知应用程序的功能，但是在应用程序可以很方便地构建这种机制。