阅读须知：笔记为阅读《TCP IP 详解卷1：协议》后摘抄的一些知识点，其间也有加入一些根据英文原版的自己翻译和结合网上知识后的理解，所以有些段落之间并不能够串联上或者知识点与书上略有差别(基本差别不大，参考的资料属RFC官方文档)。
第十七章：TCP保活机制
TCP协议中不存在轮询机制，这意味着加入启动一个客户端进程，与服务器建立连接后，然后离开几小时、几天、甚至几个月，连接依然会保持着。理论上，中间路由器可以崩溃和重启，数据线可以断开再连接，只要连接两端的主机没有被重新启动(或者更改IP地址)，那么它们仍会保持连接状态。
TCP保活机制
TCP保活机制是一种在不影响数据流内容的情况下探测对方的方式。它由一个保活计时器实现，当计时器被激发，连接一端将发送一个保活探测(简称保活)报文，另一端接收报文的同时会发送一个ACK作为响应。
保活机制并不是TCP规范中的一部分，对此[RFC1122]给出三个理由：
1. 在出现短暂的网络错误的时候，保活机制会使一个好的连接断开
2. 保活机制会占用不必要的带宽
3. 在按流量计费的情况下会产生更多经济开销
并且保活机制仍存在争议，许多人认为这一功能不应该在TCP协议中提供，而应在应用程序中实现；反之也有人认为大多数应用程序需要该功能，应该在TCP协议中实现。然后...现在所有主流TCP版本都实现了保活功能，只是该功能在默认情况下是关闭的，是一个可选择激活的功能。
TCP连接的任何一端都可以请求打开这一功能，且可以设置在连接的一端、两端或者两端都没有。
保活功能的操作如下：如果在一段时间(保活时间)内连接处于非活动状态，开启保活功能的一端将向对方发送一个保活探测报文。如果发送端没有收到响应报文，那么经过一个已经提前配置好的保活时间间隔后继续发送一个保活探测报文，直到发送探测报文的次数达到保活探测数，这时对方主机将被确认为不可到达，连接也将被中断。
TCP保活功能的规则过程中，开启该功能的一端会发现对方处于以下四种状态之一：
1. 对方主机仍在工作，并且可以到达。请求端将保活计时器重置(重新设定为保活时间值)。如果在计时器超时前有应用程序通过该连接传输数据，那么计时器将再次被设定为保活时间值。
2. 对方主机已经奔溃，包括已经关闭或者正在重新启动。请求端接收不到响应报文，并在经过保活时间间隔指定的时间后超时。超时前，请求端会持续发送探测报文，一共发送保活探测数指定次数为止，如果请求端没收到任何探测报文响应，那么它将认为对方主机已经关闭，连接也将被断开。
3. 客户主机奔溃并且已重启。请求端会受到一个对其保活探测报文的响应，但这个响应是一个重置报文段，请求端将会断开连接。
4. 对方主机仍在工作，但是由于某些原因不能到达请求端。这种情况与状态2相同，因为TCP不能区分状态2和状态4，结果都是没有受到探测报文的响应。
变量保活时间、保活时间间隔和保活探测数的设置是可以变更的。有些系统允许用户在每次建立连接时设置这些变量，有些系统规定只有在系统启动时才能设置。比如在linux中，这些变量分别对应net.ipv4.tcp_keepalive_time、net.ipv4.tcp_keepalive_intvl、net.ipv4.tcp_keepalive_probes，默认设置是7200秒、75秒和9次探测。
保活探测报文为一个空报文段(只包含1字节)。它的序列号等于对方主机发送的ACK报文的最大序列号减1，因为这一序列号的数据段已经被成功接收，所以不会对到达的报文段造成影响，但探测报文返回的响应可以确定连接是否仍在工作。需要注意的是，探测及其响应报文丢失时不会进行重传。
书中的三个案例：
(案例一：正常连接 -> 另一端突然奔溃，本例中将保活时间设置为7000ms/7s，保活时间间隔设置为1s，在确认连接断开之前(62.120s)，客户端会发送10个间隔为1秒的保活探测报文，最后连接断开)
(案例二：另一端奔溃后重启，本例中将保活时间设置为12000ms/2min，最后是另一端重启后响应一个RST报文段，连接断开)
(案例三：另一端不可达，本例中将保活时间设置为12000ms/2min，到达保活探测数后仍未收到响应，连接断开)
