QQ傳輸文件原理參考

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

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

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

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

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

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

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

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

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

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

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

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

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

14、較為簡單的一個音頻p2p軟件，酷狗?？峁返脑蛻撌莵碜杂谝粋€國外的公司，名字我已忘記，那家公司也是通過mp3的p2p下載作為主要業(yè)務，不過可惜的是在美國mp3因為版權問題非常嚴重，所以那家公司的最終結局只有一個，就是關門。但是在中國就不一樣了，版權問題沒有這么嚴重，或者說相當?shù)牟粐乐兀钥峁坊畹煤芎?。這就是國情啊(理論上來講，酷狗應該也有一些版權問題，可能跟版權商有合作關系，不過大多數(shù)的音頻應該沒有版權問題，這種情況和視頻網(wǎng)站是類似的)。下面讓我們來看看酷狗的技術實現(xiàn)。以下都是ahuaxuan的猜測，供大家討論，未必完全正確，也未必完全錯誤，拿出來和大家探討?？峁窇撌遣捎弥行牡哪夸浄掌?/p>

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

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

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

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

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

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

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

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

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