11.1.2、SYN标志
RFC793中第3.9节指出了如果一个接收到的SYN报文有一个有效的序列号（即在窗口内），应当回送一个RST报文作为响应，而且应终止这个连接。
IETF正在编写一个文档”提高TCP对一个窗内致盲攻击的抗性“[Ramaiahet al,2008],它对基于TCP的各种连接复位攻击进行寻址。本节描述了由IETF提出的对策，从实现的解决方案中可以提出一个问题，并围绕它进行研究。
为了减轻这种攻击，[Ramaiahet al,2008]中提出了按如下方式改变TCP对SYN报文的响应：当在任何同步状态接收到一个SYN报文时，将发送一个ACK报文作为回应。
正如[Ramaiahet al, 2008]中描述的那样：存在一个不能被该机制处理的特例情况，如果主机（TCPA）与远端(TCPB)建立了一个TCP连接,然后崩溃、重启并试图在同一个连接上建立一个新的连接（即：与钱一个连接有相同的四元组），并且在远端（TCPB）它的初始序列号为RCV.NXT，那么由远端（TCPB）回应的SYN报文就爱那个包含一个TCPA认为是有效的确认号，因而TCPA并不会发送一个RST报文来响应这个ACK报文。由于这个ACK没有设置SYN位，TCPA(正处于SYN-SENT状态)将丢弃该报文。在超过有hi个重传超时时间后，TCPA将重传它的SYN报文，这将产生与前述相同的结果。结果是，TCPA将超时，连接将终止。这是引入新机制后产生的不期望的特殊情况。然而，我们认为这种情况极其罕见，就算出现，连接在重试了一个周期的用户超时描述后扔不会被终止。
然而，当完全按照[Ramaiahet al, 2008]中描述的实现了这种修改后，由于在很多TCP的实现中禁用了全面结合一个启发式算法，将引入新的内部操作问题。
在很多方案中，在TCP远端，当一个四元组处于TIME-WAIT状态时，需要重新使用该对套接字。比如，客户端访问在主机上的一些服务时，当前一个连接在服务器端处于TIME-WAIT状态时，可能会试着创建对先前连接的一个新副本。如果临时端口号被重用的速度过快，或由于一个不合理的选择端口规则，或由于该服务连接速率极快时，都会出现这种情况。在这些情况下，重用处于TIME-WAIT状态的四元组建立新连接将失败。为了避免出现这种情况，RFC1122指出：当接收到的连接请求是一个处于TIME-WAIT状态的四元组是，如果新到达的SYN报文的序列号大于先前连接的最大报文号，那么这个连接请求将被接受。
这种规定的目的是避免新旧连接实例的序列号空间冲突，这样就避免了先前实例的旧报文被新连接作为有效报文而接收。
在[Ramaiah et al,2008]中对任何处于同步状态的连接中接收的SYN报文的忽略要求将禁止实现上述的启发式算法。结果是，我们讨论的[Ramaiahet al, 2008]中处理SYN报文的方法应只作用于处于同步状态的连接而不是处于TIME-WAIT状态的连接。
如下段落总结了SYN报文子啊同步状态中饿处理过程。当内部草错不被影响时，它将缓和连接复位攻击。此外为了允许建立连接的高速率，对到达的SYN报文将在启发式算法执行中包含时间戳选项（如果存在），因而提高了TCP的鲁棒性。
在同步状态下处理一个接收到的SYN报文段时，应按如方式发生：
-
如果一个连接的SYN报文在任何同步态而不是在TIME-WAIT状态中被接收到，回应一个ACK，执行速率节流。
-
如果相对应的连接处于TIME-WAIT状态，那么：
-
如果先前连接的实例使用了时间戳，那么：
-
如果新连接也将使能时间戳，而且包含在新到来的SYN报文中的时间戳大于包含在先前连接实例中的最近时间戳（针对数据传输方向），那么按连接请求执行操作（在SYN-RECEIVED状态创建连接）。
-
如果新连接也将使能时间戳，而且包含在新到来的SYN报文中的时间戳等于包含在先前连接实例中的最近时间戳（针对数据传输方向），而且新到来的SYN报文的序列号大于旧连接实例的序列号（针对数据传输方向），那么按连接请求执行操作（在SYN-RECEIVED状态创建连接）。
-
如果新建立的连接实例未使能TCP时间戳，但新到来SYN报文的序列号大于先前连接实例的序列号（对于数据传输的相同方向），那么按连接请求执行操作（在SYN-RECEIVED状态创建连接）。
-
否则，丢弃新到来的SYN报文，因而使先前连接实例离开TIME-WAIT状态。
-
如果连接的先前实例没有使用时间戳，那么：
-
如果在新连接实例中使能了TCP时间戳，按新到来连接的请求执行操作。
-
如果在新连接实例中没有使能TCP时间戳，但新到来SYN报文的序列号比旧连接的序列号大（在同一数据传输方向），那么按新到来连接的请求执行操作（不管新连接的SYN报文的序列号是否落入先前连接实例的接收窗口中，都执行操作）。
-
除此之外，丢弃新到来的SYN报文，从而是先前的连接实例离开TIME-WAIT状态。
在上述中的”TCP时间戳将被新连接实例使能“是指新到来的SYN报文包含了一个TCP时间戳选项（即：客户端使能了TCP时间戳），也意味着SYN/ACK报文将在发送的回应中包含时间戳选项（即服务器端使能了TCP时间戳）。在这种场景下，TCP时间戳将对新连接的实例使能。
”在先前连接实例中的最新序列号（在同一个数据传输方向上）“是指被先前连接实例使用的最新序列号（在同一数据传输方向上）。而不是在相应报文上最后看到的序列号。即：该序列号是先前连接实例在对应数据传输方向上的FIN标志相关的序列号。
在本接种提出的处理规则并不遵从即将出台的新RFC”提高TCP对窗内致盲攻击的鲁棒性”，它要求实现对在任何同步状态（包含TIME-WAIT状态）下接收到的连接发送一个ACK报文来响应窗内SYN报文。
当执行上述启发式算法时，很多实现不包含TCP时间戳选项，因而在生成初始序列号时、在连接的数据传输率上、在数据的传输数量上，对他们应进行强制严格限制。RFC793建议ISN应每隔4微秒旧必须增加一次（即美妙更新250000次），结果是，任何以大于250KB/s来传输数据量大于250000字节的传输将导致在一个连接上的最后几个序列号将进入TIME-WAIT状态后仍将大于新到来的用于创建该四元组新连接实例的SYN报文的序列号。在这些情况下，4.4BSD启发式算法将失效，因此连接请求将超时，通过在上述启发式算法中包含TCP时间戳选项，所有这些限制将被极大的缓和。
很明显，对上述启发式算法使用TCP时间戳将在两个相同的TCP端点间线性增加连接数。因此，微妙强力建议按4.7.1节中的建议生成时间戳。