თამაშის სერვერის ტრაფიკი თითო მოთამაშეზე

თამაშის სერვერზე ერთი მოთამაშე სერვერის upload-იდან დაახლოებით 5-დან 250 KB/s-მდე ჯდება, თამაშის მიხედვით: რამდენიმე კილობაიტი წამში Minecraft-ისთვის ან Terraria-სთვის, 30-60 KB/s Source შუტერისთვის 64 tick-ზე, 50-150 KB/s Valheim-ისთვის და 250 KB/s-მდე დატვირთული Arma 3-ის მისიისთვის. რასაც თითოეული მოთამაშე უკან აგზავნის, ბევრად ნაკლებია, ჩვეულებრივ რამდენიმე კილობაიტი წამში. სტაბილური ტრაფიკი იშვიათად არის პრობლემა; პრობლემა ნახტომებია - მოთამაშე, რომელიც შედის და სამყაროს ჩამოტვირთავს, რუკის შეცვლა, მოდიფიცირებული სერვერი, რომელიც ასეტებს აგზავნის. ეს სტატია გაძლევს ციფრებს თამაშების მიხედვით, პარამეტრებს, რომლებიც მათ ცვლის, და იმას, როგორ გაზომო, რეალურად რას აგზავნის შენი სერვერი.

ყოველთვიური ჯამებისთვის და იმისთვის, თუ რას ნიშნავს "unmetered", იხილე bandwidth და სამართლიანი გამოყენება. ეს სტატია თითო მოთამაშის ხედვაზე რჩება.

ტრაფიკი თითო მოთამაშეზე, თამაშების მიხედვით#

ეს ტიპური ციფრებია სერვერის გამავალი ტრაფიკისთვის ერთ დაკავშირებულ მოთამაშემდე, სტაბილური თამაშის დროს. ისინი დიაპაზონებია, რადგან ციფრი დამოკიდებულია იმაზე, რა არის მოთამაშის ახლოს, რამდენად სწრაფად მოძრაობს და როგორაა სერვერი მორგებული. გაზომე შენი; ესენი გამოიყენე იმის გასაგებად, დამაჯერებელია თუ არა შენი გაზომვა.

ორი სქემა გამოირჩევა. თამაშები, რომლებიც სამყაროს მდგომარეობას ცვლილებისთანავე აგზავნიან (Valheim, Arma, survival sandbox-ები), თითო მოთამაშეზე მეტი ჯდება, ვიდრე თამაშები, რომლებიც კომპაქტურ, პროგნოზირებად განახლებებს აგზავნიან (Minecraft, Terraria). ხოლო Factorio გამონაკლისია: ის ყოველი კლიენტის სიმულაციას lockstep-ში აწარმოებს და მხოლოდ მოთამაშეების input-ებს აგზავნის, ასე რომ უზარმაზარი ქარხანა პატარაზე მეტ ტრაფიკს არ ხარჯავს - სანამ ვინმე არ შემოვა და მთელი რუკა არ დასჭირდება.

გამავალი ის ციფრია, რომელსაც მნიშვნელობა აქვს#

ტრაფიკი სიმეტრიული არ არის. ყოველი მოთამაშე სერვერს თავის input-ებს უგზავნის - მოძრაობა, დამიზნება, მოქმედებები - რაც მცირე და დაახლოებით მუდმივია, ჩვეულებრივ 2-10 KB/s. სერვერი ყოველ მოთამაშეს მის ირგვლივ არსებული ყველაფრის მდგომარეობას უგზავნის, რაც იზრდება იმის მიხედვით, რა ხდება. გაამრავლე ეს მოთამაშეების რაოდენობაზე, და სერვერის upload ყოველთვის ის მხარეა, რომელიც პირველი ივსება.

სწორედ ამიტომ აწყდება სახლში ჰოსტინგი პრობლემებს კავშირებზე, რომლებიც სწრაფად გამოიყურება. 250/25 ხაზს ბევრი download აქვს და 25 Mbit/s upload, დაახლოებით 3 MB/s, სახლში ყველაფერ დანარჩენთან გაზიარებული. ათი Valheim-ის მოთამაშე 100 KB/s-ით 1 MB/s-ია, სანამ ზედა სართულზე ვინმე ვიდეოზარს დაიწყებს. თამაშის სერვერი სახლში თუ ქირით ამ მხარეს განიხილავს. დატა-ცენტრში uplink ჩვეულებრივი თამაშის სერვერისთვის შემზღუდველი არ არის; იქ თითო მოთამაშის ციფრები ძირითადად ნახტომების გასაგებად და რაიმე არასწორის შესამჩნევად არის მნიშვნელოვანი.

ნახტომები: შესვლები, რუკის შეცვლა და ჩამოტვირთვები#

სტაბილური ტრაფიკი მცირეა. ტრაფიკთან დაკავშირებული საჩივრების უმეტესობა იმ მომენტებს ეხება, როცა ასე არ არის.

შესვლა. ახალ მოთამაშეს მის ირგვლივ სამყარო სჭირდება. Minecraft-ის კლიენტი, რომელიც ახალ არეალში ჩადის, chunk-ების მონაცემებს იმდენად სწრაფად ითხოვს, რამდენადაც კავშირი უშვებს, რამდენიმე მეგაბაიტს რამდენიმე წამში. Factorio-ს კლიენტი თამაშამდე მთელ save-ს ჩამოტვირთავს - ათეულობით მეგაბაიტს დიდი ბაზისთვის, მეტს მეგაბაზისთვის. ოცი მოთამაშე, რომლებიც გადატვირთვის შემდეგ ხელახლა უკავშირდებიან, ამას ერთდროულად აკეთებს, და სწორედ ამიტომ არის გადატვირთვის შემდგომი წუთი დღის ყველაზე დატვირთული წუთი.

რუკის შეცვლა. Source-engine სერვერები ყოველ დაკავშირებულ კლიენტს ერთდროულად ჩატვირთვის ეკრანზე გზავნიან. თუ რუკა ან მისი ასეტები კლიენტებზე უკვე არ არის, ისინი უნდა ჩამოიტვირთოს.

კონტენტის ჩამოტვირთვები. აქ ცხოვრობს დიდი ციფრები, და აქ წყვეტს კონფიგურაციის არჩევანი, შენი სერვერი ზიდავს თუ არა დატვირთვას:

• Garry's Mod-ს და სხვა Source თამაშებს შეუძლიათ საკუთარი კონტენტის მიწოდება პირდაპირ თამაშის სერვერიდან, რაც ნელია და გეიმპლეის ეჯიბრება, ან FastDL ვებ-სერვერიდან, რომელიც sv_downloadurl-ით დგება, ან Steam Workshop-იდან resource.AddWorkshop-ით Lua ფაილში, რაც კლიენტებს შენ ნაცვლად Steam-იდან ჩამოტვირთვას აიძულებს. Garry's Mod-ის workshop და FastDL დაყენებას განიხილავს.
• Minecraft-ის resource pack-ები, რომლებიც server.properties-ში resource-pack=-ით დგება, შენ მიერ მითითებული URL-იდან ჩამოიტვირთება და არა სერვერიდან. ფაილი სადმე ისე დაჰოსტე, რომ დატვირთვა გაუძლოს, და დააყენე resource-pack-sha1, რომ კლიენტებმა cache-ში შეინახონ.
• FiveM შესვლისას ყოველ მოთამაშეს სერვერიდან საკუთარ ტრანსპორტს, რუკებს და ტანსაცმელს stream-ით აწვდის. სერვერი რამდენიმე ასეული მეგაბაიტი stream-ირებული ასეტით ყოველ ახალ მოთამაშეს რამდენიმე ასეულ მეგაბაიტს უგზავნის, ხოლო ერთად შემოსული მოთამაშეები uplink-ს იყოფენ. შეამცირე, რასაც stream-ავ; FiveM-ის MLO რუკები და stream-ირებული ასეტები ხსნის, როგორ.
• Factorio-ს რუკის ჩამოტვირთვებისთვის საკუთარი ლიმიტი აქვს server-settings.json-ში: max_upload_in_kilobytes_per_second (0 შეუზღუდავს ნიშნავს) და max_upload_slots, რომელიც ზღუდავს, რამდენ მოთამაშეს შეუძლია რუკის ერთდროულად ჩამოტვირთვა. სახლის კავშირზე მათი დაყენება ხელს უშლის, რომ ერთმა შესვლამ ყველა დანარჩენის თამაში გაყინოს.

პარამეტრები, რომლებიც ციფრს ცვლის#

თამაშების უმეტესობა რამდენიმე ბერკეტს გაძლევს. მათი გამოყენება ხედვის მანძილს ან განახლების სიხშირეს ტრაფიკზე ცვლის, ამიტომ გამოიყენე ისინი რეალური პრობლემის გამოსასწორებლად და არა ნაგულისხმევად.

Minecraft

view-distance (ნაგულისხმევად 10) server.properties-ში მთავარია: თითოეული მოთამაშის ირგვლივ გაგზავნილი chunk-ების რაოდენობა მისი კვადრატის პროპორციულად იზრდება, ასე რომ 10-დან 8-მდე დაწევა chunk-ების მონაცემების დაახლოებით მესამედს აცლის. simulation-distance CPU-ზე მოქმედებს და არა ტრაფიკზე. network-compression-threshold (ნაგულისხმევად 256) ამ ბაიტებზე დიდ ყოველ პაკეტს კუმშავს; მისი დაწევა ცოტა ტრაფიკს ზოგავს CPU-ს ფასად, ხოლო -1 შეკუმშვას თიშავს, რასაც აზრი მხოლოდ იმავე მანქანაზე მდგარი proxy-ის უკან აქვს. Paper paper-global.yml-ში chunk-ების გაგზავნის სიჩქარის ლიმიტებს ამატებს თითო მოთამაშეზე; გასაღებების სახელები ვერსიებს შორის შეიცვალა, ამიტომ შეამოწმე ფაილი, რომელიც შენმა build-მა შექმნა. Paper-ის ოპტიმიზაცია დანარჩენს განიხილავს.

Source-engine თამაშები

ტრაფიკი თითოეულ კლიენტამდე კლიენტის rate პარამეტრით (ბაიტი წამში) არის შეზღუდული და სერვერის sv_minrate-ითა და sv_maxrate-ით ჩარჩოში მოქცეული. Source 1 თამაშებში, როგორიცაა TF2 და Garry's Mod, sv_maxupdaterate ზღუდავს, რამდენ განახლებას იღებს თითოეული კლიენტი წამში. CS2-მა ქსელური მოდელი შეცვალა და ძველი თითო კლიენტის განახლების რამდენიმე cvar წაშალა, ასე რომ CS:GO-ს ეპოქის კონფიგი ხაზ-ხაზ არ გადადის - შეამოწმე, რომელ პარამეტრებს ითვალისწინებს შენი თამაში ჯერ კიდევ. Tick rate-ის აწევა თამაშებში, რომლებიც ამას უშვებენ, ტრაფიკს დაახლოებით პროპორციულად ზრდის: წამში 128 განახლება დაახლოებით ორჯერ მეტი ჯდება, ვიდრე 64. რას ნიშნავს სინამდვილეში tick rate ამ კომპრომისს ხსნის.

Arma 3

Arma აშკარად რეგულირდება basic.cfg-ით. გასაღებებია MaxMsgSend, MaxSizeGuaranteed, MaxSizeNonguaranteed, MinBandwidth, MaxBandwidth, MinErrorToSend და MinErrorToSendNear. MinBandwidth და MaxBandwidth სერვერს ეუბნება, რა შეუძლია ივარაუდოს საკუთარ კავშირზე, ხოლო MaxBandwidth-ის რეალურ შესაძლებლობაზე ბევრად დაბლა დაყენება desync-ის კლასიკური მიზეზია სერვერზე, რომელსაც მარაგი ჭარბად აქვს. MinErrorToSend აკონტროლებს, რამდენად შეიძლება ობიექტი გადაიხაროს განახლების გაგზავნამდე; მცირე მნიშვნელობები ნიშნავს შორეული მოძრაობის უფრო გლუვს ასახვას და მეტ ტრაფიკს. ერთდროულად ერთი შეცვალე და სრული მისიით შეამოწმე.

Valheim

Vanilla Valheim-ს ტრაფიკის პარამეტრი არ აქვს. მისი ჩაშენებული გაგზავნის სიჩქარე კონსერვატიულია, რაც ერთ-ერთი მიზეზია, რის გამოც დიდი ჯგუფები დატვირთულ ბაზებთან rubber-banding-ს ხედავენ. არსებობს საზოგადოების მოდები, რომლებიც ლიმიტს ზრდიან და ტრაფიკს კუმშავენ, და ისინი სერვერზე და ჩვეულებრივ ყოველ კლიენტზე უნდა დაყენდეს. Valheim-ის წარმადობა და lag ხსნის, სად დგას ტრაფიკი სხვა მიზეზებს შორის.

მაყურებლები, proxy-ები და relay-ები#

მოთამაშეები ერთადერთი არ არიან, ვისაც სერვერი უგზავნის. ტრაფიკის დათვლისას სამი სხვა მომხმარებლის დავიწყება ადვილია.

მაყურებლების relay-ები. Source-engine სერვერებს შეუძლიათ SourceTV-ის გაშვება (Counter-Strike-ში GOTV), რაც ფაქტობრივად დამატებითი კლიენტია, რომელიც თამაშის სრულ მდგომარეობას იღებს და მაყურებლებს გადასცემს. თამაშის სერვერი relay-ს ერთ ნაკადს უგზავნის; relay კი ყოველ მაყურებელს ნაკადს უგზავნის. ერთ მანქანაზე, სადაც ორივე მუშაობს, ყოველი მაყურებელი დაახლოებით იმდენი ჯდება, რამდენიც მოთამაშე. tv_maxclients ზღუდავს, რამდენს შეუძლია პირდაპირ ყურება, ხოლო ტურნირმა დიდი აუდიტორიით მაყურებლები ცალკე relay-ებზე უნდა გადაიყვანოს და არა მატჩის სერვერზე. CS2-ის GOTV და demo-ები პარამეტრებს განიხილავს.

Proxy-ები სერვერის წინ. Minecraft-ის ქსელი Velocity-ის ან BungeeCord-ის უკან proxy მანქანაზე ყოველ ბაიტს ორჯერ ატარებს: შემოსულს backend-იდან, გასულს მოთამაშემდე. თუ proxy და backend-ები ერთ ჰოსტზეა, backend-იდან proxy-მდე მონაკვეთი ლოკალური რჩება და uplink-ზე არაფერი ჯდება; თუ ცალკე მანქანებზეა, ჯდება. იგივე ეხება ნებისმიერ tunnel-ს ან relay-ს, რომელსაც სახლის სერვერის წინ დგამ - relay-ის ტრაფიკი სერვერის ტრაფიკია პლუს იგივე მეორე მიმართულებით. Tunnel-ები და proxy-ები თამაშის სერვერებისთვის ხსნის, კიდევ რა ჯდება relay.

სტატუსის query-ები და მონიტორინგი. ყოველი სერვერების სიის საიტი, სტატუსის ბოტი და სკანერი, რომელიც შენს სერვერს ეკითხება, მცირე, მუდმივ ნაკადს ამატებს. ჩვეულებრივ დღეს ეს უმნიშვნელოა. Query flood-ის დროს ასე არ არის, და ის ჩანს როგორც გამავალი ტრაფიკი ონლაინ მოთამაშეების გარეშე. Query პორტები და A2S ხსნის, რას ეკითხებიან და რას პასუხობენ.

Upload-ის შერჩევა მოთამაშეების რაოდენობისთვის#

არითმეტიკა მარტივია: მოთამაშეები გამრავლებული თითო მოთამაშის ციფრზე, პლუს მარაგი შესვლებისა და ნახტომებისთვის. 1.5-ის კოეფიციენტი სტაბილური თამაშისთვის გონივრული მარაგია; მეტი, თუ შენი სერვერი კონტენტს თამაშის პორტიდან აწვდის.

გახსოვდეს გადაყვანა: 1 MB/s არის 8 Mbit/s. კავშირის სიჩქარე ბიტებში იწერება, თამაშის ტრაფიკი ჩვეულებრივ ბაიტებში იზომება, და მათი არევა რვაჯერ არასწორ პასუხებს იძლევა.

სახლის სერვერისთვის ბოლო სვეტი შეადარე შენს დატვირთვისას გაზომილ upload-ს და არა ხელშეკრულებაში მითითებულ ციფრს. ჰოსტინგზე მყოფი სერვერისთვის ეს ციფრები ნებისმიერი ჩვეულებრივი uplink-ის ფარგლებშია. RE:NODE-ზე ტრაფიკი unmetered-ია - გიგაბაიტობით არ ითვლება - რაც ჩვეულებრივად გამოყენებულ ნებისმიერ თამაშის სერვერს ფარავს; ეს არ არის ნებართვა იმისთვის, რომ გაუშვა რაიმე, რაც საერთო uplink-ს გაავსებს, და bandwidth და სამართლიანი გამოყენება პირდაპირ ამბობს, სად გადის ეს ზღვარი.

როგორ გაზომო, რას აგზავნის სინამდვილეში შენი სერვერი#

შეფასებები დაგეგმვისთვის კარგია. როცა რაღაც არასწორადაა, გაზომე.

Linux მანქანაზე ან VDS-ზე, რომელსაც აკონტროლებ:

# Live totals per interface, refreshed every second$ vnstat -l -i eth0# Live traffic per remote address - who is the server talking to?$ sudo iftop -i eth0 -P# Live traffic per process$ sudo nethogs eth0

გაყავი გამავალი სიჩქარე დაკავშირებული მოთამაშეების რაოდენობაზე და შეადარე ზემოთ მოცემულ ცხრილს. სერვერი, რომელიც თითო მოთამაშეზე მოსალოდნელზე ათჯერ მეტს აგზავნის, რაღაცას აკეთებს: თამაშის პორტიდან ჩამოტვირთვებს აწვდის, plugin ზედმეტად ბევრ განახლებას აგზავნის, ან query პაკეტების flood-ს პასუხობს. iftop აჩვენებს, რომელი; თუ ტრაფიკის უმეტესობა მისამართებზე მიდის, რომლებიც მოთამაშეები არ არიან, ეს გეიმპლეი არ არის. რას ვაკეთებთ შეტევებთან აღწერს, როგორ გამოიყურება query flood.

თავად თამაშში Source 1 თამაშებს კლიენტზე აქვთ net_graph 1, რომელიც შემომავალ და გამავალ სიჩქარეებს და დანაკარგს აჩვენებს. სთხოვე მოთამაშეს, დატვირთულ მომენტში ციფრები წაგიკითხოს; ის გეუბნება, რეალურად რას იღებს ერთი კლიენტი.

როცა პრობლემა ტრაფიკი არ არის#

ჰოსტინგზე მყოფ სერვერზე "lag"-ის უმეტესობა ტრაფიკი არ არის. მიახლოებითი გზა გასარჩევად:

• ყველა ერთდროულად ლაგავს, და სერვერის CPU მაღალია. სერვერი tick-ებს ტოვებს. ეს CPU-ს პრობლემაა; იხილე CPU თუ RAM თამაშის სერვერებისთვის.
• ერთი მოთამაშე ლაგავს, დანარჩენები კი რიგზე არიან. მისი კავშირი: wifi, გადატვირთული სახლის uplink, პაკეტების დაკარგვა მის მარშრუტზე.
• Lag-ის ნახტომები, როცა ვინმე შედის. სახლის სერვერზე შეიძლება ტრაფიკი იყოს; ჰოსტინგზე მყოფზე უფრო ხშირად ახალი მოთამაშისთვის chunk-ების ან არეალების ჩატვირთვის CPU-ს ხარჯია.
• Rubber-banding მხოლოდ დატვირთულ არეალებთან. Entity-ების დატვირთვა ან, Valheim-ში, ცუდი კავშირის მქონე მოთამაშე, რომელიც ზონას ფლობს.

Latency, jitter და პაკეტების დაკარგვა ხსნის, როგორ გაარკვიო დაახლოებით ერთ წუთში, რომელს უყურებ.

FAQ#

რამდენი upload მჭირდება Minecraft სერვერის დასაჰოსტად?

პატარა ჯგუფისთვის ძალიან ცოტა: 10 მოთამაშეს სტაბილურად დაახლოებით 1.2 Mbit/s სჭირდება და რამდენჯერმე მეტი, სანამ ახალი chunk-ები stream-დება. 10 Mbit/s upload მეგობრების ჯგუფების უმეტესობისთვის საკმარისია, იმ პირობით, რომ ოჯახი მას იმავე დროს ინტენსიურად არ იყენებს.

უფრო დიდი სამყარო მეტ ტრაფიკს ხარჯავს?

თავისთავად არა. ტრაფიკი დამოკიდებულია იმაზე, რა არის თითოეული მოთამაშის ახლოს, და არა სამყაროს ზომაზე. უფრო დიდი სამყარო მეტ დისკს და, თუ მოთამაშეები იფანტებიან, მეტ CPU-ს და მეხსიერებას ხარჯავს. Factorio შესვლებისთვის გამონაკლისია, სადაც მთელი save ჩამოიტვირთება.

რატომ ხტება ტრაფიკი გადატვირთვის შემდეგ?

ყოველი მოთამაშე ერთდროულად ხელახლა უკავშირდება და მის ირგვლივ არეალს ჩამოტვირთავს, ან ზოგ თამაშში მთელ რუკას. ეს ნახტომი ნორმალური და მოკლეა. თუ სახლში პრობლემებს იწვევს, ხელახალი დაკავშირებები დროში გაანაწილე ან ჩამოტვირთვის სიჩქარე შეზღუდე, სადაც თამაში ამას უშვებს.

მოდები ტრაფიკს ზრდიან?

მოდები, რომლებიც entity-ებს, ეფექტებს ან ხშირ განახლებებს ამატებენ, სტაბილურ ტრაფიკს ზრდიან. მოდები, რომლებიც კონტენტს ამატებენ, შესვლის ტრაფიკს ზრდიან, როცა კლიენტებს მისი ჩამოტვირთვა სჭირდებათ. მოდები, რომლებიც მხოლოდ სერვერის ლოგიკას ცვლიან, ჩვეულებრივ არაფერს ამატებენ.

100 Mbit/s საკმარისია თამაშის სერვერისთვის?

ერთი ჩვეულებრივი თამაშის სერვერისთვის - თავისუფლად. დატვირთულ Arma 3-ის სერვერსაც კი იშვიათად სჭირდება პიკზე რამდენიმე ათეულ მეგაბიტზე მეტი. რასაც ჰოსტის ქსელი ამის მიღმა გაძლევს, ეს მარაგია ნახტომებისთვის და იმ ტრაფიკის შთანთქმისთვის, რომელიც არ გითხოვია.