QQ傳輸文件原理參考

1、QQ傳輸文件原理參考QQ傳輸文件原理參考2010-11-02 14：31QQ傳輸文件原理參考(來自互聯(lián)網(wǎng))QQ的文件發(fā)送是怎樣的過程呢?通常，發(fā)送文件的計(jì)算機(jī)首先要通過消息服務(wù)器將其IP地址發(fā)送給接收計(jì)算機(jī)，當(dāng)接收計(jì)算機(jī)同意接收的確認(rèn)消息反饋到消息服務(wù)器后，消息服務(wù)器將據(jù)此設(shè)置好文件傳輸對(duì)話。隨即，發(fā)送計(jì)算機(jī)與接收計(jì)算機(jī)就會(huì)在確定好的端口范圍內(nèi)，建立起TCP或UDP連接開始文件的檢索與傳輸。在默認(rèn)狀態(tài)下，QQ優(yōu)先采用了UDP(User Data Protocol，用戶數(shù)據(jù)報(bào)協(xié)議)協(xié)議傳送數(shù)據(jù)，而對(duì)可靠性要求高的數(shù)據(jù)通訊系統(tǒng)往往使用TCP協(xié)議傳輸數(shù)據(jù)。與TCP協(xié)議不同，UDP協(xié)議并不提供數(shù)據(jù)傳送

2、的驗(yàn)證機(jī)制-在整個(gè)文件傳輸過程中如果出現(xiàn)數(shù)據(jù)報(bào)的丟失，協(xié)議本身并不能作出任何的檢測(cè)或提示。因此，通常人們把UDP協(xié)議稱為不可靠的傳輸協(xié)議。UDP協(xié)議適用于無須應(yīng)答、要求時(shí)效的軟件使用，這樣的設(shè)計(jì)正好與QQ追求的目標(biāo)相符，所以QQ優(yōu)先使用了此協(xié)議進(jìn)行一切功能應(yīng)用。但是，由于UDP協(xié)議具有不可靠性，常會(huì)因種種原因?qū)е孪⒒驍?shù)據(jù)的發(fā)送失敗(很多時(shí)候會(huì)發(fā)現(xiàn)發(fā)送文件給對(duì)方接收時(shí)，對(duì)方根本收不到要求接收文件的消息?；蚴前l(fā)送聊天消息時(shí)，對(duì)方根本沒有收到過消息)。顯然，UDP協(xié)議由于排除了信息可靠傳遞機(jī)制，將安全和排序等功能移交給上層應(yīng)用來完成，極大降低了執(zhí)行時(shí)間，使速度得到了保證。QQ在數(shù)據(jù)傳輸上更注重實(shí)際

3、性能，為了獲得更好的使用效果，往往可以犧牲一定的可靠性。因此，使用QQ來傳輸數(shù)據(jù)，在很多時(shí)候就成了一個(gè)不錯(cuò)的選擇。一般內(nèi)網(wǎng)傳輸首選QQ,速度最快，QQ的文件傳輸是直接個(gè)人對(duì)個(gè)人，采用P2P的傳輸方式，具有不需中轉(zhuǎn)的優(yōu)勢(shì)。外網(wǎng)速度傳輸比較強(qiáng)的有網(wǎng)易泡泡、QQ，建議網(wǎng)友們?cè)谛枰獋鬏斘募r(shí)選用這兩款軟件，畢竟它們的服務(wù)器都在國內(nèi)，傳輸性能要高于外國IM軟件。網(wǎng)易泡泡的傳輸模式為P2S2P(從個(gè)人到服務(wù)器，再由服務(wù)器轉(zhuǎn)發(fā)到個(gè)人)。這種傳輸方式雖然需要中轉(zhuǎn)，但是其出色的表現(xiàn)還是不得不讓我們用戶另眼相看。MSN現(xiàn)在在文件傳輸方面還是趕不上國產(chǎn)QQ，UC等軟件。另外，雙方在互傳文件時(shí)，會(huì)受到不同外網(wǎng)的限制(

4、比如電信跟網(wǎng)通)，即使在同一局域網(wǎng)內(nèi)，也會(huì)因防火墻設(shè)置不同而影響速度，不過QQ自稱能穿透一切防火墻，從實(shí)際來看，這方面的能力確實(shí)不錯(cuò)。筆者一般傳文件，首選QQ?？偟膩碚f，不管什么軟件來傳輸，都要受到時(shí)段的限制。至于雙方傳送速度不同，原因很多，我由于不太清楚也無法準(zhǔn)確回答。你可以根據(jù)實(shí)際情況分析一下，估計(jì)應(yīng)該和雙方各自的防火墻設(shè)置及其他環(huán)境有關(guān)吧。TCP(Transmission Control Protocol，傳輸控制協(xié)議)是基于連接的協(xié)議，也就是說，在正式收發(fā)數(shù)據(jù)前，必須和對(duì)方建立可靠的連接。一個(gè)TCP連接必須要經(jīng)過三次對(duì)話才能建立起來，其中的過程非常復(fù)雜，我們這里只做簡單、形象的介紹，你

5、只要做到能夠理解這個(gè)過程即可。我們來看看這三次對(duì)話的簡單過程：主機(jī)A向主機(jī)B發(fā)出連接請(qǐng)求數(shù)據(jù)包：我想給你發(fā)數(shù)據(jù)，可以嗎?，這是第一次對(duì)話；主機(jī)B向主機(jī)A發(fā)送同意連接和要求同步(同步就是兩臺(tái)主機(jī)一個(gè)在發(fā)送，一個(gè)在接收，協(xié)調(diào)工作)的數(shù)據(jù)包：可以，你什么時(shí)候發(fā)?，這是第二次對(duì)話；主機(jī)A再發(fā)出一個(gè)數(shù)據(jù)包確認(rèn)主機(jī)B的要求同步：我現(xiàn)在就發(fā)，你接著吧！，這是第三次對(duì)話。三次對(duì)話的目的是使數(shù)據(jù)包的發(fā)送和接收同步，經(jīng)過三次對(duì)話之后，主機(jī)A才向主機(jī)B正式發(fā)送數(shù)據(jù)。UDP(User Data Protocol，用戶數(shù)據(jù)報(bào)協(xié)議)是與TCP相對(duì)應(yīng)的協(xié)議。它是面向非連接的協(xié)議，它不與對(duì)方建立連接，而是直接就把數(shù)據(jù)包發(fā)送過

6、去！UDP適用于一次只傳送少量數(shù)據(jù)、對(duì)可靠性要求不高的應(yīng)用環(huán)境。比如，我們經(jīng)常使用ping命令來測(cè)試兩臺(tái)主機(jī)之間TCP/IP通信是否正常，其實(shí)ping命令的原理就是向?qū)Ψ街鳈C(jī)發(fā)送UDP數(shù)據(jù)包，然后對(duì)方主機(jī)確認(rèn)收到數(shù)據(jù)包，如果數(shù)據(jù)包是否到達(dá)的消息及時(shí)反饋回來，那么網(wǎng)絡(luò)就是通的。例如，在默認(rèn)狀態(tài)下，一次ping操作發(fā)送4個(gè)數(shù)據(jù)包(如圖2所示)。大家可以看到，發(fā)送的數(shù)據(jù)包數(shù)量是4包，收到的也是4包(因?yàn)閷?duì)方主機(jī)收到后會(huì)發(fā)回一個(gè)確認(rèn)收到的數(shù)據(jù)包)。這充分說明了UDP協(xié)議是面向非連接的協(xié)議，沒有建立連接的過程。正因?yàn)閁DP協(xié)議沒有連接的過程，所以它的通信效果高；但也正因?yàn)槿绱?，它的可靠性不如TCP協(xié)議高

7、。QQ就使用UDP發(fā)消息，因此有時(shí)會(huì)出現(xiàn)收不到消息的情況。tcp協(xié)議和udp協(xié)議的差別TCP UDP是否連接面向連接面向非連接傳輸可靠性可靠不可靠應(yīng)用場(chǎng)合傳輸大量數(shù)據(jù)少量數(shù)據(jù)速度慢快QQ傳輸文件原理參考(來自互聯(lián)網(wǎng))QQ的文件發(fā)送是怎樣的過程呢?通常，發(fā)送文件的計(jì)算機(jī)首先要通過消息服務(wù)器將其IP地址發(fā)送給接收計(jì)算機(jī)，當(dāng)接收計(jì)算機(jī)同意接收的確認(rèn)消息反饋到消息服務(wù)器后，消息服務(wù)器將據(jù)此設(shè)置好文件傳輸對(duì)話。隨即，發(fā)送計(jì)算機(jī)與接收計(jì)算機(jī)就會(huì)在確定好的端口范圍內(nèi)，建立起TCP或UDP連接開始文件的檢索與傳輸。在默認(rèn)狀態(tài)下，QQ優(yōu)先采用了UDP(User Data Protocol，用戶數(shù)據(jù)報(bào)協(xié)議)協(xié)議傳

8、送數(shù)據(jù)，而對(duì)可靠性要求高的數(shù)據(jù)通訊系統(tǒng)往往使用TCP協(xié)議傳輸數(shù)據(jù)。與TCP協(xié)議不同，UDP協(xié)議并不提供數(shù)據(jù)傳送的驗(yàn)證機(jī)制-在整個(gè)文件傳輸過程中如果出現(xiàn)數(shù)據(jù)報(bào)的丟失，協(xié)議本身并不能作出任何的檢測(cè)或提示。因此，通常人們把UDP協(xié)議稱為不可靠的傳輸協(xié)議。UDP協(xié)議適用于無須應(yīng)答、要求時(shí)效的軟件使用，這樣的設(shè)計(jì)正好與QQ追求的目標(biāo)相符，所以QQ優(yōu)先使用了此協(xié)議進(jìn)行一切功能應(yīng)用。但是，由于UDP協(xié)議具有不可靠性，常會(huì)因種種原因?qū)е孪⒒驍?shù)據(jù)的發(fā)送失敗(很多時(shí)候會(huì)發(fā)現(xiàn)發(fā)送文件給對(duì)方接收時(shí)，對(duì)方根本收不到要求接收文件的消息?；蚴前l(fā)送聊天消息時(shí)，對(duì)方根本沒有收到過消息)。顯然，UDP協(xié)議由于排除了信息可靠傳遞

9、機(jī)制，將安全和排序等功能移交給上層應(yīng)用來完成，極大降低了執(zhí)行時(shí)間，使速度得到了保證。QQ在數(shù)據(jù)傳輸上更注重實(shí)際性能，為了獲得更好的使用效果，往往可以犧牲一定的可靠性。因此，使用QQ來傳輸數(shù)據(jù)，在很多時(shí)候就成了一個(gè)不錯(cuò)的選擇。一般內(nèi)網(wǎng)傳輸首選QQ,速度最快，QQ的文件傳輸是直接個(gè)人對(duì)個(gè)人，采用P2P的傳輸方式，具有不需中轉(zhuǎn)的優(yōu)勢(shì)。外網(wǎng)速度傳輸比較強(qiáng)的有網(wǎng)易泡泡、QQ，建議網(wǎng)友們?cè)谛枰獋鬏斘募r(shí)選用這兩款軟件，畢竟它們的服務(wù)器都在國內(nèi)，傳輸性能要高于外國IM軟件。網(wǎng)易泡泡的傳輸模式為P2S2P(從個(gè)人到服務(wù)器，再由服務(wù)器轉(zhuǎn)發(fā)到個(gè)人)。這種傳輸方式雖然需要中轉(zhuǎn)，但是其出色的表現(xiàn)還是不得不讓我們用戶另

10、眼相看。MSN現(xiàn)在在文件傳輸方面還是趕不上國產(chǎn)QQ，UC等軟件。另外，雙方在互傳文件時(shí)，會(huì)受到不同外網(wǎng)的限制(比如電信跟網(wǎng)通)，即使在同一局域網(wǎng)內(nèi)，也會(huì)因防火墻設(shè)置不同而影響速度，不過QQ自稱能穿透一切防火墻，從實(shí)際來看，這方面的能力確實(shí)不錯(cuò)。筆者一般傳文件，首選QQ?？偟膩碚f，不管什么軟件來傳輸，都要受到時(shí)段的限制。至于雙方傳送速度不同，原因很多，我由于不太清楚也無法準(zhǔn)確回答。你可以根據(jù)實(shí)際情況分析一下，估計(jì)應(yīng)該和雙方各自的防火墻設(shè)置及其他環(huán)境有關(guān)吧。TCP(Transmission Control Protocol，傳輸控制協(xié)議)是基于連接的協(xié)議，也就是說，在正式收發(fā)數(shù)據(jù)前，必須和對(duì)方建立

11、可靠的連接。一個(gè)TCP連接必須要經(jīng)過三次對(duì)話才能建立起來，其中的過程非常復(fù)雜，我們這里只做簡單、形象的介紹，你只要做到能夠理解這個(gè)過程即可。我們來看看這三次對(duì)話的簡單過程：主機(jī)A向主機(jī)B發(fā)出連接請(qǐng)求數(shù)據(jù)包：我想給你發(fā)數(shù)據(jù)，可以嗎?，這是第一次對(duì)話；主機(jī)B向主機(jī)A發(fā)送同意連接和要求同步(同步就是兩臺(tái)主機(jī)一個(gè)在發(fā)送，一個(gè)在接收，協(xié)調(diào)工作)的數(shù)據(jù)包：可以，你什么時(shí)候發(fā)?，這是第二次對(duì)話；主機(jī)A再發(fā)出一個(gè)數(shù)據(jù)包確認(rèn)主機(jī)B的要求同步：我現(xiàn)在就發(fā)，你接著吧！，這是第三次對(duì)話。三次對(duì)話的目的是使數(shù)據(jù)包的發(fā)送和接收同步，經(jīng)過三次對(duì)話之后，主機(jī)A才向主機(jī)B正式發(fā)送數(shù)據(jù)。UDP(User Data Protoco

12、l，用戶數(shù)據(jù)報(bào)協(xié)議)是與TCP相對(duì)應(yīng)的協(xié)議。它是面向非連接的協(xié)議，它不與對(duì)方建立連接，而是直接就把數(shù)據(jù)包發(fā)送過去！UDP適用于一次只傳送少量數(shù)據(jù)、對(duì)可靠性要求不高的應(yīng)用環(huán)境。比如，我們經(jīng)常使用ping命令來測(cè)試兩臺(tái)主機(jī)之間TCP/IP通信是否正常，其實(shí)ping命令的原理就是向?qū)Ψ街鳈C(jī)發(fā)送UDP數(shù)據(jù)包，然后對(duì)方主機(jī)確認(rèn)收到數(shù)據(jù)包，如果數(shù)據(jù)包是否到達(dá)的消息及時(shí)反饋回來，那么網(wǎng)絡(luò)就是通的。例如，在默認(rèn)狀態(tài)下，一次ping操作發(fā)送4個(gè)數(shù)據(jù)包(如圖2所示)。大家可以看到，發(fā)送的數(shù)據(jù)包數(shù)量是4包，收到的也是4包(因?yàn)閷?duì)方主機(jī)收到后會(huì)發(fā)回一個(gè)確認(rèn)收到的數(shù)據(jù)包)。這充分說明了UDP協(xié)議是面向非連接的協(xié)議，沒有

13、建立連接的過程。正因?yàn)閁DP協(xié)議沒有連接的過程，所以它的通信效果高；但也正因?yàn)槿绱?，它的可靠性不如TCP協(xié)議高。QQ就使用UDP發(fā)消息，因此有時(shí)會(huì)出現(xiàn)收不到消息的情況。tcp協(xié)議和udp協(xié)議的差別TCP UDP是否連接面向連接面向非連接傳輸可靠性可靠不可靠應(yīng)用場(chǎng)合傳輸大量數(shù)據(jù)少量數(shù)據(jù)速度慢快主題：信p2p者，得永生(一)開篇此文章的題目來自于當(dāng)下的兩哥之爭，本意有調(diào)侃之意，但是用在本文，卻無此意，我以十分真誠并且后知后覺的態(tài)度認(rèn)定，p2p是未來的主要計(jì)算模型。尤其是在視頻音頻領(lǐng)域，但是將來，p2p一定會(huì)拓展到普通的計(jì)算上。要解釋清楚這個(gè)問題，我們得從當(dāng)下最流行的音頻視頻p2p軟件聊起。先來說說

14、較為簡單的一個(gè)音頻p2p軟件，酷狗?？峁返脑蛻?yīng)該是來自于一個(gè)國外的公司，名字我已忘記，那家公司也是通過mp3的p2p下載作為主要業(yè)務(wù)，不過可惜的是在美國mp3因?yàn)榘鏅?quán)問題非常嚴(yán)重，所以那家公司的最終結(jié)局只有一個(gè)，就是關(guān)門。但是在中國就不一樣了，版權(quán)問題沒有這么嚴(yán)重，或者說相當(dāng)?shù)牟粐?yán)重，所以酷狗活得很好。這就是國情啊(理論上來講，酷狗應(yīng)該也有一些版權(quán)問題，可能跟版權(quán)商有合作關(guān)系，不過大多數(shù)的音頻應(yīng)該沒有版權(quán)問題，這種情況和視頻網(wǎng)站是類似的)。下面讓我們來看看酷狗的技術(shù)實(shí)現(xiàn)。以下都是ahuaxuan的猜測(cè)，供大家討論，未必完全正確，也未必完全錯(cuò)誤，拿出來和大家探討?？峁窇?yīng)該是采用中心的目錄服務(wù)器

15、結(jié)構(gòu)來實(shí)現(xiàn)p2p的功能，也就是說，所有的音頻文件的基本信息都會(huì)注冊(cè)到酷狗的中心目錄服務(wù)器上，那么酷狗的客戶端需要下載某個(gè)視頻的時(shí)候，則從中心目錄服務(wù)器上查找，找到相信的音頻信息，每個(gè)音頻信息都會(huì)對(duì)應(yīng)一堆地址，這些地址是其他的擁有該音頻的客戶端ip。讓我們用一張圖來描述一下這個(gè)問題：這樣我們就可以虛擬一個(gè)流程出來：1.1號(hào)客戶端請(qǐng)求中心目錄下載服務(wù)器，要求下載。2.中心目錄服務(wù)器通過搜索引擎分詞，查詢之后，得到一堆id。3.中心目錄服務(wù)器根據(jù)id查找id對(duì)應(yīng)的ip。顯然一個(gè)id擁有多個(gè)ip，是1：n的關(guān)系。(很不巧，這首歌2，3號(hào)客戶機(jī)上都有，當(dāng)然這里并不是應(yīng)該返回所有的ip地址，而是應(yīng)選擇最短

16、路徑的地址返回。讓我們來懷念一下dijikstra。4.中心目錄服務(wù)器返回音頻文件的ip列表。5.1號(hào)客戶機(jī)得到兩個(gè)ip地址，然后分別2號(hào)機(jī)請(qǐng)求音頻的第一段，從3號(hào)機(jī)請(qǐng)求音頻的第二段。即多地址多線程分段下載。6.1號(hào)機(jī)下載完成之后通知中心目錄服務(wù)器，這樣中心目錄服務(wù)器關(guān)于這個(gè)視頻又多了一個(gè)ip地址供其他客戶端下載。這個(gè)應(yīng)該是最概要的流程，接著可以在這個(gè)流程上細(xì)化。從上圖我們可以看到，任何一個(gè)客戶機(jī)既是client，又是server。作為client，它從其他server上下載數(shù)據(jù)，作為server，它提供數(shù)據(jù)給其他client下載。所以當(dāng)我們開著酷狗聽歌的時(shí)候，其實(shí)你的機(jī)器就變成了下載服務(wù)器了

17、，同樣，如果你用的是迅雷，而且一直不把迅雷關(guān)掉，那么你的機(jī)器就成為專職的下載服務(wù)器了?？吹竭@里，我們有理由相信，如果掌握了下列技術(shù)，做一個(gè)酷狗不是什么難事，括號(hào)后面是ahuaxuan的選型。1.搜索技術(shù)(lucene)-服務(wù)器端2.音頻管理系統(tǒng)(java，同時(shí)涉及到緩存和數(shù)據(jù)庫系統(tǒng))-服務(wù)器端3.客戶端ui編程(最好是mfc之流)-客戶端4.下載服務(wù)器(c，對(duì)windows的io比較熟悉)-客戶端正如前面所說，這個(gè)只是非常高層次的設(shè)計(jì)，而且對(duì)于有過大型網(wǎng)站系統(tǒng)經(jīng)驗(yàn)的人來說，1，2點(diǎn)是沒有問題的。然后3，4點(diǎn)需要對(duì)c/c+比較熟悉的人來做，當(dāng)然btcomet據(jù)說是python寫的。所以我也在思考

18、python+c實(shí)現(xiàn)客戶端的可行性。上面講到的是基本的整個(gè)軟件的結(jié)構(gòu)體系，或者稱為架構(gòu)，在high level層面還有一個(gè)問題，就是協(xié)議的問題，客戶端之間相互下載應(yīng)該使用說明協(xié)議，以及客戶端和服務(wù)器端的交互應(yīng)該使用什么協(xié)議，目前ahuaxuan選擇的是bt協(xié)議。利用成熟的協(xié)議可以減少很多的工作量。或者電驢的協(xié)議應(yīng)該也不錯(cuò)，不過沒有深入研究過。tcp udp的區(qū)別文章分類：JavaEye TCP-傳輸控制協(xié)議,提供的是面向連接、可靠的字節(jié)流服務(wù)。當(dāng)客戶和服務(wù)器彼此交換數(shù)據(jù)前，必須先在雙方之間建立一個(gè)TCP連接，之后才能傳輸數(shù)據(jù)。TCP提供超時(shí)重發(fā)，丟棄重復(fù)數(shù)據(jù)，檢驗(yàn)數(shù)據(jù)，流量控制等功能，保證數(shù)據(jù)

19、能從一端傳到另一端。UDP-用戶數(shù)據(jù)報(bào)協(xié)議，是一個(gè)簡單的面向數(shù)據(jù)報(bào)的運(yùn)輸層協(xié)議。UDP不提供可靠性，它只是把應(yīng)用程序傳給IP層的數(shù)據(jù)報(bào)發(fā)送出去，但是并不能保證它們能到達(dá)目的地。由于UDP在傳輸數(shù)據(jù)報(bào)前不用在客戶和服務(wù)器之間建立一個(gè)連接，且沒有超時(shí)重發(fā)等機(jī)制，故而傳輸速度很快。UDP與TCP的主要區(qū)別在于UDP不一定提供可靠的數(shù)據(jù)傳輸。事實(shí)上，該協(xié)議不能保證數(shù)據(jù)準(zhǔn)確無誤地到達(dá)目的地。UDP在許多方面非常有效。當(dāng)某個(gè)程序的目標(biāo)是盡快地傳輸盡可能多的信息時(shí)(其中任意給定數(shù)據(jù)的重要性相對(duì)較低)，可使用UDP。ICQ短消息使用UDP協(xié)議發(fā)送消息。許多程序?qū)⑹褂脝为?dú)的TCP連接和單獨(dú)的UDP連接。重要的狀

20、態(tài)信息隨可靠的TCP連接發(fā)送，而主數(shù)據(jù)流通過UDP發(fā)送。TCP的目的是提供可靠的數(shù)據(jù)傳輸，并在相互進(jìn)行通信的設(shè)備或服務(wù)之間保持一個(gè)虛擬連接。TCP在數(shù)據(jù)包接收無序、丟失或在交付期間被破壞時(shí)，負(fù)責(zé)數(shù)據(jù)恢復(fù)。它通過為其發(fā)送的每個(gè)數(shù)據(jù)包提供一個(gè)序號(hào)來完成此恢復(fù)。記住，較低的網(wǎng)絡(luò)層會(huì)將每個(gè)數(shù)據(jù)包視為一個(gè)獨(dú)立的單元，因此，數(shù)據(jù)包可以沿完全不同的路徑發(fā)送，即使它們都是同一消息的組成部分。這種路由與網(wǎng)絡(luò)層處理分段和重新組裝數(shù)據(jù)包的方式非常相似，只是級(jí)別更高而已。為確保正確地接收數(shù)據(jù)，TCP要求在目標(biāo)計(jì)算機(jī)成功收到數(shù)據(jù)時(shí)發(fā)回一個(gè)確認(rèn)(即ACK)。如果在某個(gè)時(shí)限內(nèi)未收到相應(yīng)的ACK，將重新傳送數(shù)據(jù)包。如果網(wǎng)絡(luò)擁

21、塞，這種重新傳送將導(dǎo)致發(fā)送的數(shù)據(jù)包重復(fù)。但是，接收計(jì)算機(jī)可使用數(shù)據(jù)包的序號(hào)來確定它是否為重復(fù)數(shù)據(jù)包，并在必要時(shí)丟棄它。TCP與UDP的選擇如果比較UDP包和TCP包的結(jié)構(gòu)，很明顯UDP包不具備TCP包復(fù)雜的可靠性與控制機(jī)制。與TCP協(xié)議相同，UDP的源端口數(shù)和目的端口數(shù)也都支持一臺(tái)主機(jī)上的多個(gè)應(yīng)用。一個(gè)16位的UDP包包含了一個(gè)字節(jié)長的頭部和數(shù)據(jù)的長度，校驗(yàn)碼域使其可以進(jìn)行整體校驗(yàn)。(許多應(yīng)用只支持UDP，如：多媒體數(shù)據(jù)流，不產(chǎn)生任何額外的數(shù)據(jù)，即使知道有破壞的包也不進(jìn)行重發(fā)。)很明顯，當(dāng)數(shù)據(jù)傳輸?shù)男阅鼙仨氉屛挥跀?shù)據(jù)傳輸?shù)耐暾?、可控制性和可靠性時(shí)，TCP協(xié)議是當(dāng)然的選擇。當(dāng)強(qiáng)調(diào)傳輸性能而不是

22、傳輸?shù)耐暾詴r(shí)，如：音頻和多媒體應(yīng)用，UDP是最好的選擇。在數(shù)據(jù)傳輸時(shí)間很短，以至于此前的連接過程成為整個(gè)流量主體的情況下，UDP也是一個(gè)好的選擇，如：DNS交換。把SNMP建立在UDP上的部分原因是設(shè)計(jì)者認(rèn)為當(dāng)發(fā)生網(wǎng)絡(luò)阻塞時(shí)，UDP較低的開銷使其有更好的機(jī)會(huì)去傳送管理數(shù)據(jù)。TCP豐富的功能有時(shí)會(huì)導(dǎo)致不可預(yù)料的性能低下，但是我們相信在不遠(yuǎn)的將來，TCP可靠的點(diǎn)對(duì)點(diǎn)連接將會(huì)用于絕大多數(shù)的網(wǎng)絡(luò)應(yīng)用。QQ通信原理-我研究的是QQ2007beta4版本的通信原理，相信之后的版本暫時(shí)也不會(huì)有改動(dòng)。1、登陸。不管UDP還是TCP，最終登陸成功之后，QQ都會(huì)有一個(gè)TCP連接來保持在線狀態(tài)。這個(gè)TCP連接的遠(yuǎn)

23、程端口一般是80，采用UDP方式登陸的時(shí)候，端口是8000。因此，假如你所在的網(wǎng)絡(luò)開放了80端口(80端口是最常用端口。就是通常訪問Web的端口，禁掉它的話，你的網(wǎng)絡(luò)對(duì)你來說價(jià)值已經(jīng)不大了)，但沒有屏蔽騰訊的服務(wù)器IP，恭喜你，你是可以登陸成功QQ的。2、聊天消息通信。采用UDP協(xié)議，通過服務(wù)器中轉(zhuǎn)方式。因此，現(xiàn)在的IP偵探在你僅僅跟對(duì)方發(fā)送聊天消息的時(shí)候是無法獲取到IP的。大家都知道，UDP協(xié)議是不可靠協(xié)議，它只管發(fā)送，不管對(duì)方是否收到的，但它的傳輸很高效。但是，作為聊天軟件，怎么可以采用這樣的不可靠方式來傳輸消息呢?于是，騰訊采用了上層協(xié)議來保證可靠傳輸：如果客戶端使用UDP協(xié)議發(fā)出消息后，服務(wù)器收到該包，需要使用UDP協(xié)議發(fā)回一個(gè)應(yīng)答包。如此來保證消息可以無遺漏傳輸。之所