tcp的複雜機制

懂socket編程的人不一定理解tcp協議，實際上很多電腦編程高手都不一定懂tcp協議，編程高手很多都是對api很理解，對於api下面的機制就不一定理解了，我是一個學網路出身的人，在我會用java或者c寫hello world之前我就知道了tcp的原理，記得當時為tcp的滑動視窗，慢啟動等著迷過，成夜成夜的研究路由協議和交換器原理，僅為理解mss，mtu等等概念，然後白天申請到機房去做實驗...後來看了linux源碼，看了linux中對tcp/ip協議棧的實現，突然發現竟然是如此複雜，tcp的三向交握在socket編程時是看不到的，但是在核心中卻能看到，必須在核心中看到，如果核心都不實現協議棧，那麼靠誰實現呢？三向交握在linux中是通過一個狀態機器來實現的，三向交握完畢後跳出核心的狀態機器，進入使用者空間的socket進程。

典型的tcp協議要求每一個資料區段發送之後都要有一個ack回複，然後才能發送下一個資料區段，雖然這樣能保證資料的可靠傳輸，但是效率呢？由於tcp是全雙工系統通訊，在等待一個資料區段的ack恢複之前網路將會閑置，因此效率將會受到極大影響，因此協議提出了滑動視窗子協議，專門負責資料的傳輸，滑動視窗子協議分為簡單的停-等協議，後退N協議，以及選擇重傳協議三個子子協議，其實三個子子協議可以由一個常式表示，只是一個常式的三個不同情況，比如發送和接收視窗都為1時就是簡單的停等協議。三個子子協議都很複雜，只有靠這種複雜的機制才換取了網路鏈路的高效利用。