windows遠(yuǎn)程桌面：

　　使用遠(yuǎn)程桌面可以遠(yuǎn)程控制另一臺windows機(jī)器，可以在遠(yuǎn)程桌面里做任何本地桌面上的操作，比如刪除，復(fù)制文件，可以把本地文件復(fù)制到遠(yuǎn)程機(jī)器里，在復(fù)制的同時還能執(zhí)行其他操作，遠(yuǎn)程機(jī)器的桌面變化實(shí)時更新到本地，等等。

　　但是仔細(xì)研究會發(fā)現(xiàn)，遠(yuǎn)程桌面只使用了一條 TCP連接，連接到被控制機(jī)器的 3389 端口。也就是在一條TCP通訊連接里，傳輸各種請求數(shù)據(jù)和接收各種應(yīng)答數(shù)據(jù)。遠(yuǎn)程桌面使用的是 RDP協(xié)議，我們這里不討論RDP的細(xì)節(jié)，只討論如何在一條TCP連接中，如何做到遠(yuǎn)程桌面的各種操作。如果我們還是按照請求-應(yīng)答的模式來解釋遠(yuǎn)程桌面的通訊協(xié)議，顯然會有很多無法處理的問題。

　　比如舉個簡單例子：

　　我們在遠(yuǎn)程桌面客戶端點(diǎn)擊鼠標(biāo)操作，這個操作會通過3389的TCP連接發(fā)送到被控制端，如果按照請求-應(yīng)答模式來工作，則必須在被控制端接收到這個鼠標(biāo)操作，執(zhí)行這個動作，然后回答給客戶端已經(jīng)執(zhí)行了這個操作。如果這期間，被控制機(jī)器的桌面界面內(nèi)容發(fā)生變化，則無法通知給客戶端，因?yàn)橐磺型ㄓ嵍际前凑湛蛻舳税l(fā)起請求，然后服務(wù)端應(yīng)答的方式通訊的。即使我們使用請求-應(yīng)答的方式，通過輪詢定時查詢被控制機(jī)器的界面內(nèi)容變化情況，也無法做到實(shí)時，而且輪詢慢了會嚴(yán)重影響視覺效果，輪詢快了會嚴(yán)重浪費(fèi)資源。

　　于是，我們改換一種解決問題的辦法，從 UDP 通訊的特點(diǎn)：（按照包模式通訊）入手去解決上邊的問題。假定我們在遠(yuǎn)程桌面的TCP通訊中，一切通訊的數(shù)據(jù)都定義成一個一個的單獨(dú)的數(shù)據(jù)包在同一條TCP連接中傳輸，數(shù)據(jù)包的接收和發(fā)送分開進(jìn)行，就是在同一個TCP連接中，一個線程專門接收數(shù)據(jù)包，一個線程專門發(fā)送數(shù)據(jù)包。這是可以的，因?yàn)楝F(xiàn)在的網(wǎng)卡都是工作在全雙工狀態(tài)下。所謂全雙工，就是接收和發(fā)送使用各自的通道，能獨(dú)立進(jìn)行數(shù)據(jù)傳輸。

　　大致偽代碼如下：

　　int tcp_socket = 客戶端連接到服務(wù)端的socket或者服務(wù)端接收到客戶端連接的socket。

　　receive_thread（） //負(fù)責(zé)接收數(shù)據(jù)包的線程

　　{

　　tcp_packet = recv_packet （tcp_socket ）;

　　////TCP 是流協(xié)議，因此，我們必須至少定義一個表示包大小的頭+包內(nèi)容，才能保證TCP數(shù)據(jù)傳輸?shù)耐健?/p>

　　//處理 tcp_packet 包，為了不阻塞讀線程，一般是把tcp_packet交給別的線程處理。

　　}

　　send_thread（）//負(fù)責(zé)發(fā)送數(shù)據(jù)包的線程

　　{

　　while（loop）{

　　從發(fā)送隊(duì)列取出一個包 tcp_packet，（發(fā)送隊(duì)列，是別的線程生成的需要發(fā)送的數(shù)據(jù)包。）

　　send_packet（ tcp_socket， tcp_packet ）; //發(fā)送這個數(shù)據(jù)包。

　　}

　　}

　　再回到上邊的問題，

　　遠(yuǎn)程桌面控制端（客戶端）和被控制端（服務(wù)端），分別開啟兩個線程，一個負(fù)責(zé)接收數(shù)據(jù)包，一個負(fù)責(zé)發(fā)送數(shù)據(jù)包。當(dāng)我們在遠(yuǎn)程桌面客戶端點(diǎn)擊鼠標(biāo)等操作，生成一個鼠標(biāo)的數(shù)據(jù)包投遞到發(fā)送線程，發(fā)送線程再把它傳輸?shù)奖豢刂贫耍豢刂贫私邮盏竭@個數(shù)據(jù)包，然后執(zhí)行，他如果要回復(fù)這個鼠標(biāo)的執(zhí)行結(jié)果，則再生成一個結(jié)果包投遞到發(fā)送線程，發(fā)送線程再把這個包傳輸給客戶端。

　　同時如果被控制端的界面發(fā)生改變，則生成一個界面內(nèi)容改變的數(shù)據(jù)包，投遞到發(fā)送線程，發(fā)送線程再傳輸給客戶端。客戶端的接收線程接收到界面內(nèi)容改變的數(shù)據(jù)包，顯示新的被控制端的界面內(nèi)容。客戶端接收到鼠標(biāo)執(zhí)行結(jié)果的包，知道鼠標(biāo)操作是失敗還是成功。

　　按照包的方式通訊，就能在遠(yuǎn)程桌面中傳遞各種復(fù)雜的動作，每個動作都封裝成一個一個的數(shù)據(jù)包進(jìn)行傳輸。接收包和發(fā)送包分開獨(dú)立進(jìn)行，互相不干擾，每個包是否需要應(yīng)答包，根據(jù)每個包的需求決定，不是必須的。這又回到了 UDP通訊方式。那為何不干脆使用UDP代替呢？ 還是上邊提到的原因，TCP保證穩(wěn)定和順序，這點(diǎn)在遠(yuǎn)程桌面等這類要求數(shù)據(jù)必須準(zhǔn)確的地方，是十分必要的。

　　TCP如何保證傳輸?shù)氖菃为?dú)數(shù)據(jù)包？

　　每個數(shù)據(jù)包定義成 ”包大小+包內(nèi)容“，比如4個字節(jié)表示包的大小，然后是包數(shù)據(jù)。

　　發(fā)送的時候，“包大小+包內(nèi)容”組合到一起發(fā)送，接收的時候，先接收固定的4個字節(jié)，獲取到包的size，

　　然后再接收size字節(jié)的數(shù)據(jù)，這樣一個包就接收完成。大致偽代碼如下：

　　send_packet（tcp_socket， packet， packet_size） //發(fā)送數(shù)據(jù)包

　　{

　　int32 size = pakcet_size; ///應(yīng)該采用網(wǎng)絡(luò)序

　　send（tcp_socket， &size， 4.。）;

　　send（tcp_socket， packet， packet_size）;

　　}

　　recv_packet（tcp_socket）

　　{

　　int32 size;

　　recv（tcp_socket， &size， 4，。。.）;

　　char* packet = malloc（size）;

　　recv（ tcp_socket， packet， size， 。。.）;

　　return packet;

　　}