QQ傳輸文件原理參考

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

2、議并不提供數據傳送的驗證機制-在整個文件傳輸過 程中如果出現數據報的丟失，協議本身并不能作出任何的檢測或提示。因此， 通常人們把UDPB議稱為不可靠的傳輸協議。UDP議適用于無須應答、要求 時效的軟件使用，這樣的設計正好與 QQ1求的目標相符，所以QQffi先使用了 此協議進行一切功能應用。但是，由于 UDPft、議具有不可靠性，常會因種種原 因導致消息或數據的發(fā)送失?。ê芏鄷r候會發(fā)現發(fā)送文件給對方接收時，對方根 本收不到要求接收文件的消息?；蚴前l(fā)送聊天消息時，對方根本沒有收到過消 息）。顯然，UDP議由于排除了信息可靠傳遞機制，將安全和排序等功能移交 給上層應用來完成，極大降低了執(zhí)行時間，使

3、速度得到了保證。QQS數據傳輸上更注重實際性能，為了獲得更好的使用效果，往往可以犧牲一定的可靠性。 因此，使用QQ來傳輸數據，在很多時候就成了一個“不錯”的選擇。一般內網傳輸首選QQ速度最快，QQ的文件傳輸是直接個人對個人，采用 P2P的傳輸方式，具有不需中轉的優(yōu)勢。外網速度傳輸比較強的有網易泡泡、QQ建議網友們在需要傳輸文件時選用這兩款軟件，畢竟它們的服務器都在國內，傳輸性能要高于外國IM軟件。網易泡泡的傳輸模式為 P2s2P以個人至U服務器，再由服務器轉發(fā)到個人 ）這種傳輸方式雖然需要中轉，但是其出色的表現還是不得不讓我們用戶另眼相 看。MSN在在文件傳輸方面還是趕不上國產 QQ UC等軟

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

5、”才能建立起來，其中的過程非常復雜，我們這里只做簡單、 形象的介紹，你只要做到能夠理解這個過程即可。我們來看看這三次對話的簡 單過程：主機A向主機B發(fā)出連接請求數據包：我想給你發(fā)數據，可以嗎？， 這是第一次對話；主機B向主機A發(fā)送同意連接和要求同步（同步就是兩臺主機 一個在發(fā)送，一個在接收，協調工作）的數據包：可以，你什么時候發(fā)？，這 是第二次對話；主機A再發(fā)出一個數據包確認主機 B的要求同步：我現在就發(fā), 你接著吧！ ;這是第三次對話。三次對話”的目的是使數據包的發(fā)送和接收同 步，經過三次對話之后，主機A才向主機B正式發(fā)送數據。UDP（User Data Protocol ,用戶數據報協議）

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

7、連接 的過程。正因為UDP議沒有連接的過程，所以它的通信效果高；但也正因為 如此，它的可靠性不如TCPB議高。QQft使用UDRg消息，因此有時會出現收 不到消息的情況。tcp協議和udp協議的差別TCP UDP是否連接面向連接面向非連接傳輸可靠性可靠不可靠應用場合傳輸大量數據少量數據速度慢快QQ專輸文件原理參考（來自互聯網）QQ勺文件發(fā)送是怎樣的過程呢？通常，發(fā)送文件的計算機首先要通過消息 服務器將其IP地址發(fā)送給接收計算機，當接收計算機同意接收的確認消息反饋 到消息服務器后，消息服務器將據此設置好文件傳輸對話。隨即，發(fā)送計算機 與接收計算機就會在確定好的端口范圍內，建立起TCP或UD唯接開

8、始文件的檢索與傳輸。在默認狀態(tài)下，QQ優(yōu)先采用了 UDP（User Data Protocol ,用戶數據報協議） 協議傳送數據，而對可靠性要求高的數據通訊系統往往使用TCP協議傳輸數據。與TCPB議不同，UDP議并不提供數據傳送的驗證機制-在整個文件傳輸過 程中如果出現數據報的丟失，協議本身并不能作出任何的檢測或提示。因此， 通常人們把UDPB議稱為不可靠的傳輸協議。UDP議適用于無須應答、要求 時效的軟件使用，這樣的設計正好與 QQ1求的目標相符，所以QQK先使用了 此協議進行一切功能應用。但是，由于 UDPft、議具有不可靠性，常會因種種原 因導致消息或數據的發(fā)送失?。ê芏鄷r候會發(fā)現發(fā)送

9、文件給對方接收時，對方根本收不到要求接收文件的消息?；蚴前l(fā)送聊天消息時，對方根本沒有收到過消 息）。顯然，UDF議由于排除了信息可靠傳遞機制，將安全和排序等功能移交 給上層應用來完成，極大降低了執(zhí)行時間，使速度得到了保證。QQ&數據傳輸上更注重實際性能，為了獲得更好的使用效果，往往可以犧牲一定的可靠性。因此，使用QQ來傳輸數據，在很多時候就成了一個“不錯”的選擇。一般內網傳輸首選QQ速度最快，QQ的文件傳輸是直接個人對個人，采用 P2P的傳輸方式，具有不需中轉的優(yōu)勢。外網速度傳輸比較強的有網易泡泡、QQ建議網友們在需要傳輸文件時選用這兩款軟件，畢竟它們的服務器都在國內，傳輸性能要高于外國IM軟

10、件。網易泡泡的傳輸模式為 P2s2P以個人至U服務器，再由服務器轉發(fā)到個人 ） 這種傳輸方式雖然需要中轉，但是其出色的表現還是不得不讓我們用戶另眼相 看。MSN在在文件傳輸方面還是趕不上國產 QQ UC等軟件。另外，雙方在互傳文件時，會受到不同外網的限制 （比如電信跟網通），即 使在同一局域網內，也會因防火墻設置不同而影響速度，不過 QQ自稱能穿透一 切防火墻，從實際來看，這方面的能力確實不錯。筆者一般傳文件，首選 QQ總的來說，不管什么軟件來傳輸，都要受到時段的限制。至于雙方傳送速度不同，原因很多，我由于不太清楚也無法準確回答。你 可以根據實際情況分析一下，估計應該和雙方各自的防火墻設置及其

11、他環(huán)境有 關吧。TCP（Transmission Control Protocol ,傳輸控制協議）是基于連接的協議， 也就是說，在正式收發(fā)數據前，必須和對方建立可靠的連接。一個TCP1接必須要經過三次對話”才能建立起來，其中的過程非常復雜，我們這里只做簡單、 形象的介紹，你只要做到能夠理解這個過程即可。我們來看看這三次對話的簡 單過程：主機A向主機B發(fā)出連接請求數據包：我想給你發(fā)數據，可以嗎？， 這是第一次對話；主機B向主機A發(fā)送同意連接和要求同步（同步就是兩臺主機 一個在發(fā)送，一個在接收，協調工作）的數據包：可以，你什么時候發(fā)？，這 是第二次對話；主機A再發(fā)出一個數據包確認主機 B的要求同

12、步：我現在就發(fā), 你接著吧！ ;這是第三次對話。三次對話”的目的是使數據包的發(fā)送和接收同 步，經過三次對話之后，主機A才向主機B正式發(fā)送數據。UDP（User Data Protocol ,用戶數據報協議）是與TCP相對應的協議。它是 面向非連接的協議，它不與對方建立連接，而是直接就把數據包發(fā)送過去！UDF用于一次只傳送少量數據、對可靠性要求不高的應用環(huán)境。比如， 我們經常使用ping命令來測試兩臺主機之間TCP/IP通信是否正常，其實 ping命令的原理就是向對方主機發(fā)送 UDPt據包，然后對方主機確認收到數 據包，如果數據包是否到達的消息及時反饋回來，那么網絡就是通的。例如， 在默認狀態(tài)下

13、，一次ping操作發(fā)送4個數據包（如圖2所示）。大家可以看到, 發(fā)送的數據包數量是4包，收到的也是4包（因為對方主機收到后會發(fā)回一個確 認收到的數據包）。這充分說明了 UDPft、議是面向非連接的協議，沒有建立連接 的過程。正因為UDPft、議沒有連接的過程，所以它的通信效果高；但也正因為 如此，它的可靠性不如TCPB議高。QQft使用UDPg消息，因此有時會出現收 不到消息的情況。tcp協議和udp協議的差別TCP UDP是否連接面向連接面向非連接傳輸可靠性可靠不可靠應用場合傳輸大量數據少量數據速度慢快主題：信p2P者，得永生（一）開篇此文章的題目來自于當下的兩哥之爭，本意有調侃之意，但是用

14、在本文， 卻無此意，我以十分真誠并且后知后覺的態(tài)度認定，p2p是未來的主要計算模型。尤其是在視頻音頻領域，但是將來，p2p 一定會拓展到普通的計算上。要解釋清楚這個問題，我們得從當下最流行的音頻視頻p2P軟件聊起。先來說說較為簡單的一個音頻p2P軟件，酷狗?？峁返脑蛻撌莵碜杂谝粋€國外的公司，名字我已忘記，那家公司也是 通過mp3的p2P下載作為主要業(yè)務，不過可惜的是在美國 mp3因為版權問題非 常嚴重，所以那家公司的最終結局只有一個，就是關門。但是在中國就不一樣了，版權問題沒有這么嚴重，或者說相當的不嚴重， 所以酷狗活得很好。這就是國情?。ɡ碚撋蟻碇v，酷狗應該也有一些版權問題， 可能跟版權

15、商有合作關系，不過大多數的音頻應該沒有版權問題，這種情況和 視頻網站是類似的）。下面讓我們來看看酷狗的技術實現。以下都是 ahuaxuan的猜測，供大家討 論，未必完全正確，也未必完全錯誤，拿出來和大家探討?？峁窇撌遣捎弥行牡哪夸浄掌鹘Y構來實現 p2P的功能，也就是說，所 有的音頻文件的基本信息都會注冊到酷狗的中心目錄服務器上，那么酷狗的客 戶端需要下載某個視頻的時候，則從中心目錄服務器上查找，找到相信的音頻 信息，每個音頻信息都會對應一堆地址，這些地址是其他的擁有該音頻的客戶 端ip。讓我們用一張圖來描述一下這個問題：這樣我們就可以虛擬一個流程出來：號客戶端請求中心目錄下載服務器，要求下

16、載 0.中心目錄服務器通過搜索引擎分詞，查詢之后，得到一堆id。.中心目錄服務器根據id查找id對應的ip。顯然一個id擁有多個ip ,是1: n的關系（很不巧，這首歌2, 3號客戶機上都有，當然這里并不是應該返回所有的 ip地址，而是應選擇最短路徑的地址返回。讓我們來懷念一下dijikstra 。.中心目錄服務器返回音頻文件的ip列表。5.1號客戶機得到兩個ip地址，然后分別2號機請求音頻的第一段，從3 號機請求音頻的第二段。即多地址多線程分段下載。6.1號機下載完成之后通知中心目錄服務器，這樣中心目錄服務器關于這 個視頻又多了一個ip地址供其他客戶端下載。這個應該是最概要的流程，接著可以在

17、這個流程上細化。從上圖我們可以看到，任何一個客戶機既是client ,又是server 0作為client ,它從其他server上下載數據，作為server ,它提供數據給其他 client 下載。所以當我們開著酷狗聽歌的時候，其實你的機器就變成了下載服務器了， 同樣，如果你用的是迅雷，而且一直不把迅雷關掉，那么你的機器就成為專職 的下載服務器了?？吹竭@里，我們有理由相信，如果掌握了下列技術，做一個酷狗不是什么 難事，括號后面是ahuaxuan的選型。.搜索技術（lucene）-服務器端.音頻管理系統（java ,同時涉及到緩存和數據庫系統）-服務器端.客戶端ui編程（最好是mfc之流）-客

18、戶端.下載服務器（c ,對windows的io比較熟悉）-客戶端正如前面所說，這個只是非常高層次的設計，而且對于有過大型網站系統 經驗的人來說，1, 2點是沒有問題的。然后3, 4點需要對c/c+比較熟悉的人 來做，當然btcomet據說是python寫的。所以我也在思考python+c實現客戶 端的可行性。上面講到的是基本的整個軟件的結構體系，或者稱為 架構，在high level層面還有一個問題，就是協議的問題，客戶端之間相互下載應該使用說 明協議，以及客戶端和服務器端的交互應該使用什么協議，目前 ahuaxuan選擇 的是bt協議。利用成熟的協議可以減少很多的工作量?；蛘唠婓H的協議應該也

19、 不錯，不過沒有深入研究過。tcp udp的區(qū)別文章分類：JavaEye TCP-傳輸控制協議，提供的是面向連接、可靠的字節(jié) 流服務。當客戶和服務器彼此交換數據前，必須先在雙方之間建立一個TCP連接，之后才能傳輸數據。TCPI供超時重發(fā)，丟棄重復數據，檢驗數據，流量 控制等功能，保證數據能從一端傳到另一端。UDP-用戶數據報協議，是一個簡單的面向數據報的運輸層協議。UD杯提供可靠性，它只是把應用程序傳給IP層的數據報發(fā)送出去，但是并不能保證 它們能到達目的地。由于UDPft傳輸數據報前不用在客戶和服務器之間建立一 個連接，且沒有超時重發(fā)等機制，故而傳輸速度很快。UDPW TCP的主要區(qū)別在于U

20、DP一定提供可靠的數據傳輸。事實上，該 協議不能保證數據準確無誤地到達目的地。UDP&許多方面非常有效。當某個程序的目標是盡快地傳輸盡可能多的信息時（其中任意給定數據的重要性相對較 低），可使用UDP ICQ短消息使用UDPB議發(fā)送消息。許多程序將使用單獨的TCP連接和單獨的UDR!接。重要的狀態(tài)信息隨可 靠的TCP連接發(fā)送，而主數據流通過 UD磔送。TCP的目的是提供可靠的數據傳輸,并在相互進行通信的設備或服務之間 保持一個虛擬連接。TCPft數據包接收無序、丟失或在交付期間被破壞時，負 責數據恢復。它通過為其發(fā)送的每個數據包提供一個序號來完成此恢復。記住， 較低的網絡層會將每個數據包視為一

21、個獨立的單元，因此，數據包可以沿完全 不同的路徑發(fā)送，即使它們都是同一消息的組成部分。這種路由與網絡層處理 分段和重新組裝數據包的方式非常相似，只是級別更高而已。為確保正確地接收數據，TCP要求在目標計算機成功收到數據時發(fā)回一個 確認（即ACK如果在某個時限內未收到相應的 ACK將重新傳送數據包。如果 網絡擁塞，這種重新傳送將導致發(fā)送的數據包重復。但是，接收計算機可使用 數據包的序號來確定它是否為重復數據包，并在必要時丟棄它。TCP與UDP勺選擇如果比較UDPfe和TCP包的結構，很明顯UDPfe不具備TCP包復雜的可靠 性與控制機制。與TCPB議相同，UDP勺源端口數和目的端口數也都支持一臺

22、 主機上的多個應用。一個16位的UDP&包含了一個字節(jié)長的頭部和數據的長度， 校驗碼域使其可以進行整體校驗。（許多應用只支持UDP如：多媒體數據流， 不產生任何額外的數據，即使知道有破壞的包也不進行重發(fā)。）很明顯，當數據傳輸的性能必須讓位于數據傳輸的完整性、可控制性和可 靠性時，TCP協議是當然的選擇。當強調傳輸性能而不是傳輸的完整性時，如： 音頻和多媒體應用，UDP1最好的選擇。在數據傳輸時間很短，以至于此前的 連接過程成為整個流量主體的情況下，UDP&是一個好的選擇，如：DN皎換。把SNMPI立在UDPJjq部分原因是設計者認為當發(fā)生網絡阻塞時，UDPR低的開銷使其有更好的機會去傳送管理數

23、據。TC葉富的功能有時會導致不可預料 的性能低下，但是我們相信在不遠的將來，TCP可靠的點對點連接將會用于絕大多數的網絡應用。QQ!信原理-我研究的是QQ2007beta4版本的通信原理，相信之后的版本暫時也不會有 改動。1、登陸。不管UDP是TCP最終登陸成功之后，QQ會有一個TCP1接 來保持在線狀態(tài)。這個TCP1接的遠程端口一般是80,采用UD叨式登陸的時 候，端口是80000因此，假如你所在的網絡開放了 80端口（80端口是最常用端 口。就是通常訪問 Web勺端口，禁掉它的話，你的網絡對你來說價值已經不大 了），但沒有屏蔽騰訊的服務器IP,恭喜你，你是可以登陸成功 QQ勺。2、聊天消息通信。采用UDP議，通過服務器中轉方式。因此，現在的 IP偵探在你僅僅跟對方發(fā)送聊天消息的時候是無法獲取到IP的。大家都知道，UDPft、議是不可靠協議，它只管發(fā)送，不管對方是否收到的，但它的傳輸很高 效。但是，作為聊天軟件，怎么可以采用這樣的不可靠方式來傳輸消息呢？于是,騰訊采用了上層協議來保證可靠傳輸：如果客戶端使用UDPft、議發(fā)出消息后，服務器收到該包，需要使用 UDPB議發(fā)回一個應答包。如此來保證消息可以無 遺漏傳輸。之所以會發(fā)生在客