任何事情都需要一定的節拍來驅動，最典型的就是時鐘，它規定了什麼時間要幹什麼事。在古代沒有精確的機械時鐘時，人們使用太陽，月亮來計時，因此就像年，四季，月，日，時辰，都是時鐘的體現，另外像生肖，星座也一樣，其實，任何時鐘都是一系列的週期輪迴組成的。在農業民族看來，時鐘始終都是精確的，這也就是為什麼中國人總結出了二十四節氣的原因，古代的中國是沒有12月的，這個是古羅馬的曆法，也叫凱撒曆法，翻譯為儒略曆，中國人更近一步，一共24個節氣，這些節氣規定了x的時候要播種，y的時候要收割，z的時候要除草...
上面說的這些可能在程式設計師們看來不是很直觀反而覺得很抽象(你每天的三點一線也是時鐘驅動的)，然而這些和作業系統裡面的時鐘中斷沒有什麼本質的區別。但是，上面我們說的這些，不管是儒略曆，二十四節氣，還是作業系統的時鐘中斷，都是外部時鐘，比如太陽，地球執行軌道，主機板上的時鐘源等等，還有一種時鐘是自時鐘，也就是說不需要外部時鐘源，完全靠內部的激勵機制來推進事件的進展。
說到內部時鐘，我還是禁不住提一下海洋民族，像古代的腓尼基人，希臘人這樣的，一旦航行***(雖然只是地中海，但在那個年代就是大海了)，便丟失了太陽這個最大的時鐘源，因為海上世界變幻莫測，不像陸地上那般固定，海上沒有「太陽黃經位於...」這種，海上基本隨機地在風暴和靜謐之間切換，因此沒有外部的時鐘可以依靠，必須靠自己的判斷來決定下一步做什麼！這就是自時鐘！
下面說點程式設計師們懂的東西，tcp作為乙個端到端額協議，對中間的網路完全不知情，因此便和海洋民族一樣(海洋民族不知道風暴的規律，不曉得氣壓和熱輻射的關係，不懂副熱帶高壓，熱帶氣旋的生成規律，但是他們可以就這些現象做出恰當的反應，最終創造了現代的我們生活其中的文明！)，被動的受制於擁塞和通暢，因此它也不得不靠自時鐘來推進資料段的傳送。
tcp在設計之初就是乙個端到端的協議，後來加入的ecn我感覺是個錯誤。因此tcp的傳送基本上依靠ack，以ack來驅動傳送，然而並不是全部。即便是海洋民族靠海吃海，有時候也得看看天，不是嗎？
我們知道tcp資料的傳送時機，基本分為兩大類：
1.應用程式有資料要發(呼叫send函式)，且視窗允許的時候；
2.ack到來，傳送佇列有資料待傳送，且傳送視窗仍有空餘。
因此，要想保持tcp流的源源不斷傳送，就一定要保證有源源不斷的ack流，如果沒有ack流，上述的第1點也是無法保證的，因為總會耗盡視窗，能讓視窗滑動的只有ack！但是你能保證ack流嗎？誰都不能！因為ack流完全不受控，對端可能不發，緩發，也可能發了ack但丟失，甚至，你發的資料都丟了，無法觸發對端的ack傳送...因此僅僅靠自時鐘是不夠的，必須有乙個外部時鐘！這也就是說，要想保證tcp流被傳送，必須有乙個外部時鐘，在大多數的實現中，這就是rto定時器！這是絕對少不了的，你可以改變rto的行為，比如不讓它將視窗降低，不重啟慢啟動，但是必須有這麼乙個定時器，並且你必須在這個定時器裡面做點什麼！
以上就是tcp混合型自時鐘的概念，它靠ack自時鐘驅動資料的傳送，但是仍然需要乙個外部的超時時鐘。
關於遊戲《祖瑪》和雙邊加速
玩過《祖瑪》嗎？很簡單的乙個遊戲，很多人不屑玩它，但是卻可以在裡面找到乙個tcp雙邊加速的方案。
Winform開發框架之混合型框架的剖析
我在隨筆 winform開發框架之框架演化 和 winform開發框架之混合型框架的實現 都對winform框架的變種，混合型框架進行了比較詳細的介紹，本文繼續上篇對混合型框架進行進一步的說明。混合型框架為了支援wcf方式和傳統訪問資料庫方式兩種對資料操作的方式，有兩個地方有扇出操作，乙個是在介面上...
Winform開發框架之混合型框架的剖析
我在隨筆 winform開發框架之框架演化 和 winform開發框架之混合型框架的實現 都對winform框架的變種，混合型框架進行了比較詳細的介紹，本文繼續上篇對混合型框架進行進一步的說明。混合型框架為了支援wcf方式和傳統訪問資料庫方式兩種對資料操作的方式，有兩個地方有扇出操作，乙個是在介面上...
EIGRP吹出來的混合型路由協議
eigrp 增強型內部閘道器路由協議,他是個距離向量路由協議,被吹時叫混合型路由協議.1.閃速更新 當收到乙個新的路由條目時,會在第一時間傳遞出去.2.增量更新 跟閃速更新差不多,只要接到了乙個新的路由條目,就會立即吧這個路由條目,而且只會傳送這個新增的路由條目.3.路由更新 傳遞自己的路由表 之所...