Re: [問題] GGC開遊戲問題

[sitos (麥子)]

※ 引述《magicayu (magicayu)》之銘言：
: 請問一下
: 固定IP 浮動IP 實體IP 虛擬IP
: 這4種哪些可以當主機開遊戲給別人家 哪些不行
: 用CABLE 網路 防火牆有關
: 開遊戲都沒人可以加 只可以加別人的遊戲
: 請大家幫忙解答一下 謝

首先，在 TCP/IP 的世界裡面並沒有分固定 IP 和浮動 IP ，所以這兩種可以不用想了，
不管是固定的還是浮動的，對它在網路裡面的功能沒有任何影響。

因此實際上要考慮的只有實體 IP 和虛擬 IP 。
基本上實體 IP (public IP) 一定可以開遊戲，只要設定正確就可以了。

虛擬 IP (private IP) 則由於 port mapping 的關係，不一定可以開遊戲。
因此，要了解虛擬 IP 與開遊戲之間的關聯，需要了解 port mapping 的原理。

首先，什麼是 port mapping 呢?

簡單講就是把 private IP 的某個 port map 到 public IP 的某個 port 。
舉例而言，我有兩台電腦 A, B 都有 private IP ，共用的 public IP 是 C 。
A 跟 B 同時想要用 port 1234 向外連線，此時就要像 NAT 就要作轉換，
可能的轉會是 A:1234 -> C:2345, B:1234 -> C:3456
此時，所有 A:1234 出去的封包，外面的人看會是由 C:2345 發出的
        而 B:3456 出去的封包，外面的人則會認為是 C:3456 發出的
因此回應這兩個 port 送出的封包，也會送回給 C 的兩個不同 port
C 再依據不同 port 轉送給 A 或者 B ，因此不會搞混。

那麼依照 port mapping 的建立方式， NAT (network address translation)
又可以分為 static NAT 和 dynamic NAT 。

所謂的 static NAT 靜態網路位址轉換，就是 port mapping 是事先定義好的，
哪個 private IP port 對應到哪個 public IP port ，都是先規劃好的。
但是這種的缺點是，如果無法事先知道 private IP 要用哪些 port 就沒辦法建。

而 dynamic NAT 動態網路位址轉換，則是 port mapping 有需要才建立。
簡單講就是當 private IP 發出一個需求的時候，再建立 port 。
假設 A:1234 要往外送一個封包，建立一個連線， C 看到了，
就找一個空的 port (目前沒有 mapping 的 port) 如 2345 ，
分給 A:1234 用，因此就得到 A:1234 -> C:2345 ，
接著如果 A:1235 也要一個 mapping 則可能對到 A:1235 -> C:2346 etc.

接下來是重點

但是，事實上在網路上的「聯絡關係」不是只有 A 和 C ，
還有 A 的溝通對象，假設是 A' 好了。
今天 A:1234 原本想要傳送的對象假設是 A':1234 ，
所建立起來的 mapping 到底是 A:1234 -> C:2345 而已，
還是 A:1234 -> C:2345 -> A':1234?

如果是前者，那代表 C:2345 已經完全被佔用了，其它人絕對不能用。
這樣在大型一點的 NAT ，可能 port 很快就用完了。
反過來，如果是後者，則當 A:1235 想要連到 B':1234 時，
可以建立另外一個 mapping A:1235 -> C:2345 -> B':1234
兩個 mapping 是不一樣的，可以共用同一個 port 。

這個問題又可以反過來從另一個角度來看，
也就是 NAT C 在轉送封包給 private 時需不需要考慮是從外面的誰送來的?

一般常見的 NAT 可以分為四種

1) full cone NAT
2) address-restricted cone NAT
3) port-restricted cone NAT
4) symmetric NAT

1) full cone NAT
只紀錄 A:1234 -> C:2345 完全不考慮外面是誰送過來的

2) address-restricted cone NAT
紀錄 A:1234 -> C:2345 -> A' ，只要是同一個人送來的，
不管 port 是哪一個，都會正確轉送，但不是建立過連線的人送的就不行。
如果 A:1234 也送給別人，還是會繼續用 C:2345 ，只是最後對應的人不同。

3) port-restricted cone NAT
紀錄 A:1234 -> C:2345 -> A':2345 ，只有同一個人的同一個 port 送來的，
才會正確轉送，所以不是建立過連線的 address + port 就不行。
但如果 A:1234 送給別人或別的 port ，還是會繼續使用 C:2345 。

4) symmetric NAT
每一次送出去，都只能送到對方特定的 port ，如 A:1234 -> C:2345 -> A':1234
而且當同一個 port 要再建立別的連線， C 會指派另一個 port ，
如 A:1234 -> C:3456 -> A':1235

基本上 1 ~ 3 有一個共通的特性，就是只要我曾經送給你，你就一定可以送回來。
那麼，穿透 NAT 有什麼樣的方法，我們一一來看，就拿 GGC 當例子吧。

1) full cone NAT
在 GGC 一連上 server 後，就從 client 的 1513 送 udp 封包給 server ，
server 就可以觀察到 client 的外部 port 。
例如該 mapping 是 A:1513 -> C:3456 -> A':1513 ，則 server 會看到 3456 。
接著 server 再將 3456 這個值透過原本的 tcp 連線傳給 client 。
此後在進入房間時， client 會告訴房間自己的外部 port 是 3456 ，
房間再告訴所有的人，新加入的這個 port 是 3456 ，
任何人都可以透過 C:3456 把資料傳給 A:1513 。 done

2) address-restricted cone NAT
前面的步驟都一樣，但是一進房間以後 GGC 就開始鬼吼鬼叫亂送封包給所有的人，
讓 C 認得說在這個房間裡面的所有人，都是我曾經送過封包的。
接著這些人看到進房的訊息以後，房間告訴大家這個新來的是 3456 ，
所以所有的人都可以透過 C:3456 傳給 A:1234 。
重點在於一進房間就要對所有的人鬼吼鬼叫。

3) port-restricted cone NAT
除了要鬼吼鬼叫以外，還要叫對 port ，但基本上房間給的 port 應該是對的。
所以沒有問題，只要對方會聽，就跟 2) 做的事差不多。
但!! 如果兩邊都是 3) 也就是在一開始都會忽略對方送的封包，
因為一開始兩邊都"未曾"送給對方正確的 port 過。
此時連線可能會建立不起來。

4) symmetric NAT
GG! 這種 NAT 沒有辦法偷工減料偷傳資料。

summary 一下，基本上能建立通訊只要有一邊夠隨便就可以。
1) 所以只要有任一方是 public IP 一定可以建立連線。
2) 只要有任一方是 full cone NAT 也一定可以建立連線。
3) 只要有任何一方是 address-restricted cone 應該也可以建立連線。
4) 當兩方都是 port-restricted cone NAT 只要同時叫對 port 應該可以建立連線。
   (只要都從 server 得到正確的 port ，然後同時對叫，就可以把 mapping 建起來)
5) 當有一方是 symmetric NAT 時，就無法建立連線。
   因為一登入連給 server 的外部 port ，不會被重覆使用，
   所以就算告訴其它人這件事，其它人對 C 鬼吼鬼叫， C 也不會理它。
   而且 A 也沒辦法從內部對外鬼吼鬼叫，因為再怎麼叫都會是另外一個 port ，
   找不到外部的 port 連線就建不起來。

以上... 很有可能有錯，重點只有一個，那就是虛擬 IP 不能一概而論，
每一個 NAT 的實作方式有可能不一樣。但只要不要註死遇到高級的 NAT ，
通常大概都是 full cone NAT (對一個家庭用而言，很夠用了)，開房大概沒啥問題，
GGC 會幫你鬼吼鬼叫建立連線。

穿透 symmetric NAT 我知道唯一的辦法是 turn server ，
白話講就是找一個可以讓兩邊建立連線的第三者來代替轉傳。
在 GGC 裡面... 這個就是開通，把你從 X 變成 | 。
然後吃掉第三者的頻寬，第三者真是有夠衰。
只要你能夠搞到開通，應該還是可以開 game ，
只是頂多慢一點頓一點，但兩邊的通訊應該是沒有問題的。

有需要的話，可以自己參考這個。
http://en.wikipedia.org/wiki/Network_address_translation (英文的)

另外，如果你的網路不錯，開著 GGC 掛網，很可能會被吃掉頻寬。
因為 GGC 裡面似乎沒有設定選項可以要求不要透過自己被 tunnel 。

--

我實實在在的告訴你們，一粒麥子不落在地裡死了，

              仍舊是一粒，若是死了，就結出許多子粒來。

                                約翰福音 12:24

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 60.248.178.71
※ 編輯: sitos           來自: 60.248.178.71        (02/07 04:48)
→ silveriii:看了這篇我忽然想把網路學好(痛哭
→ sitos:這個說實話不查資料我也記不起來，考試通常也不會考那麼細
推 terry1020:我直接end了-.-
推 Kendai:為什麼你要把你網路概論的上課筆記放到魔獸爭霸版上面呢
還好還好，我學到這個東西的時候不是在計網學的。
這是在 internet telephony 學的 (又俗稱 voice over IP, VoIP) 。

最有名穿 NAT 的例子大概是 skype 吧，能做的幾乎都做了。
開著 skype 也是一樣會被吃頻寬的。

推 allencyl:      哼哼! 不推你還以為我看不懂...
→ ica:不是學網路的 看了好痛苦
推 Attui:你們這些人都不睡的啊  我都睡醒了...@@
推 Attui:不過最後的另外  是不是要跟retty說啊  ?
跟 Retty 說也沒用阿
第一、他不是 programmer 不會直接去碰觸程式的修改
第二、要是真的搞了選項出來，依照 user selfish ，大家都不希望被偷吃頻寬，
      到時候大家都說不要幫忙轉送， tunnel 的成功機率會小很多。
GGC 應該不會做這種事砸自己腳

推 Kendai:這篇其實可以收到精華區GGC專區裡面,對於網路入門者也好用
推 Attui:老實說...我看不懂
推 KanoLoa:大推!不過這樣看來誰開通誰是沒有差異的?跟GGC說明不同?
這點我也很好奇，照理來講 tunnel 的時候是要讓雙方可以互相看到對方的訊息，
總不該是 A tunnel B 只要 A 可以跟 B 講，但 B 不能跟 A 講。
現在一般建立連線的機制，多半都是雙向的，照著一般網路的特性，
tunnel 以後，應該也會是一個雙向的 tunnel 不是單向的 tunnel 。
但我不曉得 GGC 裡面的實作方法是不是很特別，以致於 A tunnel B =/= B tunnel A 。
畢竟我沒看過 GGC 的程式碼，這件事我不能斷言。

但透過 tunnel 能把 X 變成 | 應該是透過第三者沒錯，
在螢幕上顯示找到線路 1, 2, 3 的時候其實也會收到那三個「第三者」的 UID

推 Attui:這要問ptt的正姐sighter了..
推 aa771010:推一個  把術語跟實例並用 好文
推 tnav:麥大你..認真了
推 tactical:感謝提供小知識，已收錄信長閒聊、心得文區^^~
推 sa23palipali:你是教linux的老師嗎...
完全不是，事實上穿透 NAT 和 linux 沒有直接的關係。
這個問題對所有的 OS 和 application 都一樣棘手 (如果它有需要穿的話)

推 black75:讀資工還看不懂 好痛苦~"~
推 erictku:資管推~~原po專業
推 ted80204:非資工資管的資訊科系推...只看懂一半 Q_Q
推 realG:(爆汗...)這是魔獸板?!
推 wix3000:看到一半就忍不住END了 玩個GGC何必那麼累XD
→ iftheone:大推 我董
推 TaiwanFlight:所以就是打三國前10分鐘很順，被殺後開始LAG可能是
→ TaiwanFlight:GGC再作怪，而且這種作怪方式只有了解內情的人才知道
→ TaiwanFlight:。
我沒有證據，但如果上傳頻寬不夠又被 tunnel ，理論上的確有可能突然不順。
但 GGC 可以透過觀察掉封包的情況，避免上傳頻寬不夠的人被 tunnel ，
這方面的實作並不容易，但應該是可以漸漸改善的。

→ TaiwanFlight:這篇文章只要有學過函數的定義域跟對應域就能看懂
→ TaiwanFlight:6成了吧。 (ps:文中的 mapping 即是 function)
推 wulouise:所以這段跟GXC一房限制255人有關嗎?
推 TaiwanFlight:如果GGC願意，完全可以讓房間有255*255*255*255人。
一房限制 225 個人 (不是 255 喔)，比較有可能是受限於 broadcast scalability ，
這個另外在寫一篇文章來講解好了。

推 capedoz:是麥大的話 可以哦
推 taia:推!!
推 kyo7695:快推，不然人家以為我們看不懂
※ 編輯: sitos           來自: 60.248.178.71        (02/07 11:24)
推 pureblue:這個要讀過data comm的才會吧
→ myson:快推  不然人家以為我看的懂   ~"~?
推 TaiwanFlight:印象中你以前就有說過ggc的人數限制是怎麼一回事
推 cckd754t:快推  不然人家以為我看的懂        我真的看不懂 orz
推 SeanCEO:很有邏輯的解釋，可是我看到一半還是end了Q_Q
→ sitos:其實到後面累了就開始胡說八道了
推 qaws68:問個實際點的問題  GGC開通和設定反延遲是真的有效嗎?
→ qaws68:原理是什麼
推 swinds24:推麥大XD
→ leepeter121:小聲..ggc可以鎖上傳 有的時候載圖不一定是從主機傳出
推 cawayigainax:原來如此啊  了解了
推 IamPity:推~   受教了!!!!!
→ onelife:快推  不然人家以為我看的懂 orz
推 Kcoselda:講的很清楚，可以開課了@@