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没有提供连接丢失即时通知应用程序的功能，但是在应用程序可以很方便地构建这种机制。

【T10】记住，TCP__IP不是轮询的