網路遊戲程式設計師須知 udp vs tcp
這篇教程讓我們就從最基本的網路資料收發開始談起吧。其實這部分才是網路程式設計師應該做的最基礎最簡單的部分，但是這部分如果想要做好相對來說還是很有技巧和困難的。而且如果這部分你沒做好，在多人對戰類遊戲中它帶來的影響是極其惡劣的。
你可能聽說過埠這個概念，也可能知道tcp和udp這兩個概念。在做網路開發的的時候，我們首先要做的就是選擇合適的協議。到底是tcp，還是udp，或者是兩者混合來用呢？這是乙個問題。
其實來說，你的選擇應該和你需要做的遊戲型別相關。所以首先如果你是做網路遊戲開發的，從現在起，我預設你對一些知名的網路遊戲，比如cod,quake, unreal, cs已經很熟悉了。
既然我們要談網路遊戲的協議選擇，我們就先得對各種協議來個深入的了解，這樣到底應該選擇那種協議也就不言而喻了。
tpc/ip
tcptcp解釋為傳輸控制協議，ip解釋為網路協議。他們合起來就完成了你日常網路的大部分工作，比如寫email，看網頁等。
假如你曾經使用過tcp，那麼你肯定知道tcp是可靠協議。即你先在兩台機器間建立連線，然後你再在兩台機器上開始傳輸資料，傳輸的過程和檔案讀寫很像。你在一頭寫，在另外一頭讀而已。
tcp協議是可靠而且有序的，這個意味著tcp負責保證你的資料可以完整而且有序的傳輸到另外一端。tcp是通過流的方式來傳輸資料的，這就意味這tcp會負責把你的資料切分，打包，然後具體傳輸。
最後記住，tcp傳輸其實就和讀寫檔案一樣簡單。 by rellikt
ipip協議的抽象簡單概念與ip協議底層傳輸的複雜真實實現形成鮮明對比。
這裡不需要任何連線的概念，資料報從乙個電腦傳輸到另外乙個電腦，就像你在上課的教室裡面傳紙條一樣。你只要給出乙個最終的目的地，包自然會傳到那個終端，當然中間還會經過好多層的路由遞送。
你完全不能確定自己的包最終會不會到達目的地，只能希望它到達。如果你想知道包最終是否到達，那你就必須讓接收者收到以後做出回覆。
事實上，整個過程可能還要更複雜一些，由於沒有一台機器能夠預知包可以最快到達的完整路由途徑，所以有時候ip協議會將包複製多份發出，這些包會走不同的路由，因此他們一般也會在不同的時刻到達。
你必須了解網際網路絡由問題的設計原則是自主組織路徑，自主修復路徑。所以當你思考問題的底層是如何實現時那是相當帶勁的，當然你可以在相關的教科書上找到你想要的內容或者wiki。
udp我們已經有一種可以像寫檔案一樣穩定傳輸資料的方法了，如果我們還想要一種可以自由的收發包的方法，我們可以怎麼做呢？
這裡我們可以用到udp。udp解釋為「user datagram protocol」（使用者自定義資料協議）。它和tcp類似也是建立在ip協議上的，不過他相比起tcp來在ip協議上只做了薄薄的一層協議。
我們可以使用udp協議直接對指定的ip和埠發包，比如 1.0.0.127:21（本機的ftp埠）。這個包會從傳送者自己路由到接收者手中，當然也有可能半路丟失掉。
在接收端，我們只要偵聽相關埠就可以了，當有包從任何電腦發來的時候（這裡沒有連線的概念），我們在得到包的資料的同時，也得到了包的傳送者的ip和埠資料，傳送包的大小。
udp是不穩定可靠的傳輸協議，事實上大部分的包是會被送達的，但是你一般會有1%到5%的丟包率。甚至你會發現有段時間，你連乙個包都收不到。路由路徑上的那些機器出了點啥問題，誰知道呢？
有時候收包的順序和發包的順序也是不同的，可能你發包的時候是1,2,3,4,5的順序發。收到的包就變成1,3,4,5,2的順序了。當然大部分時候這個順序是不會亂的。但是這個誰都不敢打保票。
udp只能保證你一件事，那就是包的完整性。你如果發乙個256bytes的包，那麼對方收到的肯定也是乙個256bytes的包。他不會只收到半個包之類的。當然這其實也是udp唯一能保證你的事情。其他事情都要靠你自己去訂製。 by rellikt
tcp vs udp
我們現在要做乙個選擇了。開發遊戲到底是用udp好呢？還是用tcp好呢？
首先我們連列一下他們的有缺點：
tcp：
1. 基於連線的協議。
2. 可靠性和資料報的序列性是***的。
3. 自動為你的資料封包。
4. 確保包的流量不會超出你的網路鏈結的負載上限。
5. 簡單易用，你只需要像寫檔案一樣去讀寫就萬事大吉了。
udp：
1. 沒有連線的概念，如果你想要，自己去實現去。
2. 沒有關於可靠性和包序列性的保證，包可能會丟失，重複，亂序。
3. 你必須自己去封包。
4. 你必須自己確保自己的資料報不會流量過大從而導致超過鏈結負載上限。
5. 你必須自己處理包的丟失，重複，亂序的情況，如果你不想他們對你的程式造成麻煩，必須要自己實現**來做出應對。
這樣一比，我們顯然應該用那個tcp協議了。它完成了所有我們想要的特性，實在是太完美了，不是嗎？by rellikt
tcp的真實工作情況
tcp和udp都是基於ip協議的，但是他們的本質確實截然不同的。udp和它底層的ip協議類似，tcp卻將很多東西進行了抽象，它使你在使用它的時候感覺就像讀寫乙個檔案一樣，事實上他對你隱藏了很多複雜功能的實現細節。
它到底是如何實現這些細節的呢？
首先，tcp是流性質的協議，你將資料乙個位元乙個位元的寫入流，然後tcp來確保他們會最終到底目的地。我們必須明確：tcp協議是基於ip協議的，ip協議是基於資料報的。這裡tcp其實是把我們的資料流在底層進行了打包。事實上有一些tcp協議中的**就是把我們的資料流進行排隊，然後依次寫入包中，當包寫入了足夠多的資料以後，它就會把包發走。
這裡就會導致一些問題，因為你不能控制底層的打包和傳輸，所以當很小的使用者輸入資料寫入資料流的時候，tcp可能會湊滿一定量的資料（比如100bytes），然後再打包傳送。這樣的話，在實時性上面就會很差，因為也許你會需要這些包越快到達越好。這些小延遲也許就會大大的影響你的遊戲性。
tcp中其實有乙個tcp_nodelay的選項，使用這個選項以後，你的資料就會跳過tcp的佇列打包過程，直接傳送。
但是即使你使用的這個技術，你在多人網路遊戲中還是會遇到不小的問題。
這些問題源自於tcp實現可靠傳輸的機制。by rellikt
tcp是如何實現可靠傳輸的
基本上來說，tcp將資料流中的資料做成封包，然後將他們通過不可靠的ip協議傳送，然後在接收端重組這些包成為資料流。
但是當乙個包丟失的時候tcp會做些什麼呢？當包重複和亂序的時候tcp又做了些什麼呢？
這裡我不想做太深入的介紹，有興趣的讀者可以在wiki上找到他們需要的細節。大致來說，tcp發現丟包的時候，會要求傳送者重發，重複的包會被丟棄，亂序包會被排序，事實上他就是這麼保證傳輸的可靠性的。
這裡的丟包處理對遊戲來說就很糟糕了。tcp中，如果你發現丟包了，必須等待傳送者進行重發，在重發的包到來以前，即使有新包來，你也只能讓他們在佇列裡等著，不能讀取，這個等待的時間大概是ping值的1.5倍，如果重發的包再次丟失的話那就是3倍的時間。假設你的ping值是125ms，丟包一次就會延遲200ms左右，如果連續丟包就是400ms，這樣的情況在大多數即時類遊戲中是不能忍受的。
為何你不能選用tcp作為遊戲開發的網路協議
通過上面的論述，其實已經很明白了。在注重即時性的遊戲中，對於延遲的要求是很苛刻的，我們可以丟包，但是如果我們收到了比丟掉的包更新的包的話，我們完全可以不管丟掉的包。我們只關注當前資料。
這裡我們來假設乙個最簡單的多人遊戲的模型。比如乙個fps遊戲，你在客戶段每次將輸入的資料（比如前進，跳躍，**）傳送到伺服器端，然後伺服器端將玩家當前的位置和情況發回給客戶端來做顯示。
在這個最簡單的模型中，只要有乙個包丟失了，所有的東西都必須停下來等包的重發，任何操作都得停掉，你不能移動也不能射擊。等到這個包到達的時候，你總算能繼續操作了。但是可能你會發現還有一堆等等待重發的包在排隊，於是你只好繼續等，而且可能你收到的這個重發包對遊戲來說已經失去時效性，完全沒意義了。這樣的遊戲你能忍嗎？
不幸的是你對tcp協議的這個行為完全無能為力。這是tcp協議的本性，就是它保證了tcp協議的可靠性的。
我們不需要這樣無法訂製的可靠性協議。我們需要自己進行訂製丟包時的處理原則。這也是我們在開發遊戲時，避免使用tcp協議的原因。
是否可以混合使用tcp和udp協議呢？
上面的結論中，我們可以明確知道，一些類似玩家操作，玩家位置的時效性相關資料，我們必須不能使用tcp協議。但是有些資料確是必須保證可靠性的，那我們是否可以使用tcp協議來做同步呢？
這個想法是很好的，我們可以在玩家操作等即時性很強的資料上使用udp協議，在玩家ai，資料載入，玩家對話等序列性很強的資料上使用tcp。如果你願意的話，甚至可以為不同的ai建立不同的tcp連線，以免乙個ai的丟包會影響的另外乙個ai的即時性。
結論我的建議是在遊戲中僅僅使用udp作為網路協議，即使要使用tcp也是自己在udp的基礎上實現一種類tcp的協議。這也是現代遊戲中流行的網路架構。
寫了老半天，總算翻譯完了，大家如果喜歡的話，下週有空我再翻譯一章吧。就這樣了。
網路遊戲程式設計師須知 收包與發包
platform detection define platform windows 1 define platform mac 2 define platform unix 3 include elif platform platform mac platform platform unix in...
程式設計師和網路遊戲
我發現程式設計師生涯和網遊非常像。網遊中的級別高低，完全取決於其經驗值的多少。程式設計師也是一樣。程式設計師的水平高低，不在於會用多少框架，不在於學過多少教程。為什麼程式設計師這行對學歷特別的不看重？程式設計師到底看重什麼？經驗。但是這個經驗不是按時間計算的。同樣幹了幾年的程式設計師，水平為什麼有高...
程式設計師須知
重要的不是你用什麼開發，而是你在開發什麼。程式 演算法 資料結構 過程 物件 屬性 方法 事件 程式設計師的秘訣是 程式設計 程式設計 再程式設計。程式設計的秘訣是 思索 思索 再思索。自由固不是錢所能買到的，但能夠為程式設計而賣掉。程式設計為了生活，生活為了程式設計。不要認為程式設計是一項任務，其...