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節中的建議生成時間戳。