原文地址:https://blog.csdn.net/erlib/article/details/24430493
在編寫網(wǎng)絡(luò)游戲的時候欢揖，到底使用UDP還是TCP的問題遲早都要面對。
一般來說你會聽到人們這樣說：“除非你正在寫一個動作類游戲，否則你就用TCP吧” 或者是 “你能夠在MMO游戲中用TCP,因為魔獸世界就用的TCP屑柔！”
遺憾的是，這些觀點(diǎn)都沒有反映這個問題的復(fù)雜性珍剑。
背景
首先掸宛，說明一下，我之前主要是用TCP進(jìn)行網(wǎng)絡(luò)編程招拙。我曾為一個流行的在線紙牌游戲編寫服務(wù)器了好幾年唧瘾，在高峰期我們的每臺服務(wù)器能夠承受4000到10000個連接（同一臺物理機(jī)器上有多個服務(wù)器進(jìn)程在跑）都沒有問題。在我來看别凤，TCP是一種安全而且常見的選擇饰序。
盡管如此，我們最新的項目卻是使用UDP協(xié)議闻妓，而且我們的項目無法通過任何方式在TCP下工作。事實上掠械，項目一開始使用的TCP由缆，但是后來發(fā)現(xiàn)我們使用TCP無法達(dá)到我們需求的連接數(shù)量時注祖，我們只能換成UDP了。
在使用中TCP表現(xiàn)怎么樣呢
從原理上均唉，TCP的優(yōu)勢有：
- 簡單直接的長連接
- 可靠的信息傳輸
- 數(shù)據(jù)包的大小沒有限制
任何一個和TCP打過交道的人都知道是晨，要實現(xiàn)一個穩(wěn)定的TCP網(wǎng)絡(luò)連接，需要處理各種隱藏的坑舔箭，比如斷線檢測罩缴、慢速客戶端響應(yīng)阻塞數(shù)據(jù)包，對開放連接的各種dos攻擊层扶，阻塞和非阻塞IO模型等等箫章。
除了上面列出的這些問題外，一個好的TCP模塊確實不好編碼實現(xiàn)镜会。
但是檬寂，TCP最糟糕的特性是它對阻塞的控制。一般來說戳表，TCP假定丟包是由于網(wǎng)絡(luò)帶寬不夠造成的桶至，所以發(fā)生這種情況的時候，TCP就會減少發(fā)包速度匾旭。
在3G或WiFi下镣屹，一個數(shù)據(jù)包丟失了，你希望的是立馬重發(fā)這個數(shù)據(jù)包价涝，然而TCP的阻塞機(jī)制卻完全是采用相反的方式來處理女蜈！
而且沒有任何辦法能夠繞過這個機(jī)制，因為這是TCP協(xié)議構(gòu)建的基礎(chǔ)飒泻。這就是為什么在3G或者WiFi環(huán)境下鞭光，ping值能夠上升到1000多毫秒的原因。
為什么不用UDP
UDP相對TCP來說既簡單又困難泞遗。
舉個例子來說惰许，UDP是基于數(shù)據(jù)包構(gòu)建，這意味著在某些方面需要你完全顛覆在TCP下的觀念史辙。UDP只使用一個socket進(jìn)行通信汹买，不像TCP需要為每一個客戶端建立一個socket連接。這些都是UDP非常不錯的地方聊倔。
但是晦毙，大多數(shù)情況下你需要的僅僅是一些連接的概念罷了，一些基本的包序功能耙蔑，以及所謂的連接可靠性见妒。可惜的是甸陌，這些功能UDP都沒有辦法簡單的提供給你须揣，而你使用TCP卻都可以免費(fèi)得到盐股。
這也是人們?yōu)槭裁唇?jīng)常推薦TCP的原因。在用TCP的時候你可以不考慮這些問題耻卡，直到你需要同步連接的數(shù)量級達(dá)到500以上的時候疯汁。
所以，是的卵酪，UDP沒有提供所有的解決方法幌蚊，但是就像你看到的那樣，這也正是UDP好用的地方溃卡。在某種意義上來說溢豆，TCP對UDP就好比是Hibernate和手寫SQL的區(qū)別。
使用TCP失敗的地方
人們經(jīng)常給你建議塑煎，讓你去使用TCP沫换，比如“TCP跟UDP一樣快”或者“游戲X用TCP如此成功，所以TCP當(dāng)然是首選”最铁，然而讯赏，他們完全沒有理解為什么在那個特定的游戲中TCP是有效的，為什么UDP不按照順序發(fā)送數(shù)據(jù)包呢冷尉？
那么為什么魔獸世界采用TCP呢漱挎？首先我們需要解釋這個問題。這個問題其實是“為什么魔獸世界有的時候1000毫秒以上的延遲還能夠運(yùn)行雀哨？”這是TCP的性質(zhì)決定的磕谅，在發(fā)生丟包的時候，會產(chǎn)生巨大的延遲雾棺，因為TCP首先會去檢測哪些包發(fā)生了丟失膊夹，然后重發(fā)所有丟失的包，直到他們都被接收到捌浩。
可靠的UDP也是有延遲的放刨，但是由于它是在UDP的基礎(chǔ)之上建立的通信協(xié)議，所以可以通過多種方式來減少延遲尸饺，不像TCP进统，所有的東西都要依賴于TCP協(xié)議本身而無法被更改。
就這一點(diǎn)來講浪听，一些人要開始提到Nagle算法了螟碎，實際上它是你在實現(xiàn)任意一個對延遲敏感的TCP模型時首先需要禁止使用的。
那么魔獸世界以及其他的一些游戲是怎么處理延遲問題的呢迹栓？
方法也很簡單掉分，他們能夠隱藏掉延遲帶來的影響。
在魔獸世界中，玩家和玩家是無法碰撞的：因為這類碰撞是無法通過一些預(yù)測來處理的酥郭，但是玩家和環(huán)境之間的碰撞卻是可以通過預(yù)測來處理的尔崔，所以這里使用TCP是沒有問題的。
我們來看一下魔獸世界的戰(zhàn)斗就會發(fā)現(xiàn)褥民，玩家的攻擊指令發(fā)送給服務(wù)器的操作是放在比如“attack_entity(entity_id)”或者”cast_spell(entity_id, spell_id)“的接口中來做的，換句話說洗搂，瞄準(zhǔn)操作是獨(dú)立于進(jìn)行的消返。如此一來，一些類似發(fā)起攻擊動作和釋放技能特效就能夠在沒有收到服務(wù)器確認(rèn)的情況下就直接執(zhí)行耘拇，比如展現(xiàn)冰凍技能的效果就可以在服務(wù)器沒有返回數(shù)據(jù)前在客戶端就做出來撵颊。
客戶端直接開始進(jìn)行計算而不等待服務(wù)端確認(rèn)是一種典型的隱藏延遲的技術(shù)。
幾年前惫叛，我為一個叫“Five Card Jazz”的紙牌游戲編寫過客戶端倡勇。它使用的是http協(xié)議，它比直接的TCP協(xié)議連接的延遲更加嚴(yán)重嘉涌。
我們用簡單的紙牌繪制和抽牌的動畫來掩蓋延遲的問題妻熊，所以延遲的問題只在非常糟糕的連接下才會被看出來。這種方法也非常的典型：發(fā)送請求的同時開始播放牌桌的動畫仑最，一直播放翻動最后一張牌直到接收到了服務(wù)端傳回來的數(shù)據(jù)為止扔役。魔獸世界的戰(zhàn)斗特效就是使用類似的原理。
這也意味著警医，我們到底是使用TCP還是UDP取決于我們能否隱藏延遲亿胸。
