linux關於tcp協議ack的實現–總結和公平性問題

tcp是一個可靠串連的協議，但不要指望它是什麼理論的實現，它是實踐的東西，任何實踐的東西背後都不是一個理論，而是一大堆理論，tcp正是單一停等，GBN(回退N)以及SR(選擇重傳)的結合體，單一停等是最原始的理論，但是頻寬利用率太低了，後面的GBN實現了流水線式的資料發送和確認，可靠串連的根本就在於確認-ack，而GBN的ack完全是基於接收方的，接收方很簡單的只發送最後一個按序到達的報文的序號最為確認號，而發送端收到以後將重傳該確認號之後的所有報文，這樣實現很簡單，要考慮的事情也不多，但是可能會導致大量不必要的重傳動作，因此SR就報上了名來，只要接收端收到一個報文就給予確認，發送方將已經被確認的分組從重傳鏈表刪除，然後如果被確認的分組在視窗的最左邊，那麼向前移動發送視窗，這就解決了GBN中的一系列問題，可是新的問題就是實現起來可能更複雜了，收發雙方對於ack的處理都很複雜。
     linux的tcp實現實質上是以GBN為根本，但是內建了SR演算法的支援，正和RFC的建議一致，SR在RFC2018中被描述，而它是作為一個tcp選項被加入協議的，也就是說tcp的實現的骨架還是gbn，但是如果你想使用sr的特性，那麼需要通過tcp頭的選項來支援，linux實現了這一點，並且將發送ack，接收ack，處理sr，以及重傳等動作完全分離，發送ack完全按照gbn的方式，如果需要sack的話，那麼另外填寫選項，對於接收ack並處理，也是按照GBN的方式，但是其間需要檢查是否冗餘ack積累到了一定量，接收ack是tcp_ack處理的，雖然它基於，但它絲毫不必擔心gbn的大量重傳問題，因為重傳動作完全是tcp_ack以外的，它將根據sack相關的資訊處理重傳，而不是根據gbn的原則重傳分組。
     正是ack保證了串連的可靠性，同時ack也左右了tcp的擁塞控制以及流量控制動作，進而使得tcp實現頻寬的公平性(加增乘減)，但是公平性只是針對tcp內部而言的，如果大量瘋狂的udp視頻傳輸於骨幹網，由於udp沒有擁塞控制，它會佔去大量資源而不後退，而tcp由於丟包或者延遲已經感覺到了擁塞，於是tcp們紛紛減緩發送，於是就讓給udp更大的頻寬，雖然這種綏靖不是有意的，但是這個問題卻是亟待解決的，目前無法在協議本身找到完美的解決方案，而只能通過諸如路由器的流控或者在linux上使用iptables配置相關策略來實現。
     因此tcp是一個諸多理論的混合體，而linux實現的tcp又是諸多實現建議的混合體。