????????在TCP確認機制中，無法有效處理非連續TCP片段。確認號表明所有低于該編號的sequence number已經被發送該編號的設備接收。如果我們收到的字節數落在兩個非連續的范圍內，則無法只通過一個編號來確認。這可能導致潛在嚴重的性能問題，特別是高速或可靠性較差的網絡。
????????還是以下圖為例，服務器發送了4個片段并收到1條回復，確認號為201。因此，片段1和片段2被當成已確認。它們從重傳隊列中移出，同時允許服務器發送窗口向右移動200字節，從而發送數據增加200個字節。
????????然而，再次假設片段3，從sequence number201開始，在發送過程中丟失了。由于客戶端從沒有收到這一片段，所以它也無法發送確認號高于201的確認信息，從而導致滑動窗口停滯。服務器可以繼續發送其他片段直到填滿客戶端的接收窗口，但是直到客戶端發送另一條確認信息，服務器的發送窗口都不會滑動。
????????另一個問題是如果片段3丟失了，客戶端將無法告知服務器是否收到后續的片段。在客戶端接收窗口填滿之前，很有可能客戶端已經接收到片段4以及之后的片段。但是客戶端無法發送值為501的確認信息以表明接收到片段4，因為這意味著片段3也接收到了。
????????這里我們看到了TCP單編號，累積確認機制的缺點。我們可以想象一個最差的情況，服務器被告知它有一個10，000字節窗口，20個片段每個片段500字節。第一個片段丟失了，其他19個被接收到了。但是由于第一個片段從沒有接收到，其他19個也無法確認。
未確認片段處理策略：
????????我們怎樣處理丟失片段之后的片段呢？本例中，當服務器片段3重傳超時，它必須決定怎樣處理片段4，它不知道客戶端是否已經接收到。在上述最差情況下，第一個片段丟失后，其余19個可能或可能無法被客戶端接收到。
????????處理這種情況有兩種可能的方式：
? ??????????僅重傳超時片段：這是一種更加保守的方式，僅重傳超時的片段，希望其他片段都能夠成功接收。如果該片段之后的其他片段實際上接收到了，這一方式是最佳的，如果沒接收到，就無法正常執行。后者的情況每一個片段需要單獨計時并重傳。假設上述最壞情況下，所有20個500字節片段都丟失了。我們需要等片段1超時并重傳。這一片段也許會得到確認，但之后我們需要等待片段2超時并重傳。這一過程會重復多次。
? ??????????重傳所有片段：這是一種更激進或者說更悲觀的方式。無論何時一個片段超時了，不僅重傳該片段，還有所有其他尚未確認的片段。這一方式確保了任何時間都有一個等待確認的停頓時間，在所有未確認片段丟失的情況下，會刷新全部未確認片段，以使對端設備多一次接收機會。在所有20個片段都丟失的情況下，相對于第一種方式節省了大量時間。這種方式的問題在于可能這些重傳是不必要的。如果第一個片段丟失而其他19個實際上接收到了，也得重傳那9500字節數據。
????????由于TCP不知道其他片段是否接收到，所以它也無法確認哪種方法更好，但只能選擇一種方式。上圖示例了保守的方式，而下圖顯示的是激進的方式：
????????問題的關鍵在于無法確認非連續片段。解決方式是對TCP滑動窗口算法進行擴展，添加允許設備分別確認非連續片段的功能。這一功能稱為選擇確認（selective acknowledgment, SACK）。
選擇確認：
????????通過SACK，連接的兩方設備必須同時支持這一功能，通過連接時使用的SYN片段來協商是否允許SACK。這一過程完成之后，任一設備都可以在常規TCP片段中使用SACK選項。這一選項包含一個關于已接收但未確認片段數據sequence number范圍的列表，由于它們是非連續的。
????????各設備對重傳隊列進行修改，如果該片段已被選擇確認過，則該片段中的SACK比特位置為1。該設備使用圖2中激進方式的改進版本，一個片段重傳之后，之后所有片段也會重傳，除非SACK比特位為1。
????????例如，在4個片段的情況下，如果客戶端接收到片段4而沒有接收到片段3，當它發回確認號為201（片段1和片段2）的確認信息，其中包含一個SACK選項指明：“已接收到字節361至500，但尚未確認”。如果片段4在片段1和2之后到達，上述信息也可以通過第二個確認片段來完成。服務器確認片段4的字節范圍，并為片段4打開SACK位。當片段3重傳時，服務器看到片段4的SACK位為1，就不會對其重傳。如下圖所示。
????????在片段3重傳之后，片段4的SACK位被清除。這是為了防止客戶端出于某種原因改變片段4已接收的想法。客戶端應當發送確認號為501或更高的確認信息，正式確認片段3和4接收到。如果這一情況沒有發生，服務器必須接收到片段4的另一條選擇確認信息才能將它的SACK位打開，否則，在片段3重傳時或計時器超時的情況下會對其自動重傳。
