Query პორტები და A2S: სერვერის სტატუსის მოთხოვნა

Query პორტი ის პორტია, რომელსაც თამაშის სერვერი კითხვაზე "ვინ ხარ და რამდენად ხარ სავსე?" საპასუხოდ იყენებს - სერვერების სიებისთვის, სტატუსის საიტებისთვის, Discord-ის ბოტებისთვის და მონიტორინგისთვის. Steam-ის თამაშებზე პასუხი A2S-ით მოდის, Valve-ის პატარა UDP პროტოკოლით: კლიენტი ფიქსირებულ მოთხოვნას აგზავნის, სერვერი კი თავისი სახელით, რუკით, მოთამაშეების რაოდენობით, მაქსიმალური მოთამაშეებით და რამდენიმე ნიშნით პასუხობს. ის გეიმპლეისგან განცალკევებულია, ხშირად ცალკე პორტზე, და ჩანაფიქრით ავთენტიფიკაციის გარეშეა. მისი მუშაობის ცოდნა საშუალებას გაძლევს, სერვერის ხილვადობა ერთი ბრძანებით შეამოწმო, პორტის პრობლემა სიის პრობლემისგან გაარჩიო და გაიგო, რატომ არის ერთი და იგივე პორტი ის, რითაც მოთამაშეები გპოულობენ, და ის, რითაც თავდამსხმელები გიყენებენ.

რისთვის არის query პორტი#

გეიმპლეის ტრაფიკი მხოლოდ მაშინ მიდის, როცა მოთამაშემ შესვლა უკვე გადაწყვიტა. ყველაფერი მანამდე - სერვერების სია, მოთამაშეების რაოდენობა ვებსაიტზე, შეტყობინება "server is online" Discord-ში - query პროტოკოლიდან მოდის. მას სამი მნიშვნელოვანი თვისება აქვს:

• უცნობებს პასუხობს. ყველა, ვინც სწორად აწყობილ პაკეტს გაგზავნის, პასუხს იღებს. ასეც უნდა იყოს, რადგან სერვერების სია უცნობია.
• UDP-ია. ერთი მოთხოვნა, ერთი პასუხი (ან რამდენიმე დიდი პასუხისთვის), კავშირის გარეშე.
• ხშირად საკუთარ პორტზეა. Source-engine თამაშები თავად თამაშის პორტზე პასუხობენ. Steam-ის ბევრი სხვა თამაში ცალკე query პორტზე პასუხობს, ჩვეულებრივ თამაშის პორტიდან ფიქსირებული წანაცვლებით ან ფიქსირებულ ნომერზე, როგორიცაა 27015.

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

A2S ერთ ცხრილში#

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

A2S_INFO შეიცავს სტრიქონს Source Engine Query, რომელსაც ნულოვანი ბაიტი მოსდევს. პასუხი ფიქსირებული რიგით დალაგებული ველების მწკრივია:

ნიშნის შემდეგ არასავალდებულო ველებში შედის თამაშის პორტი (ნიშანი 0x80), სერვერის Steam ID (0x10), SourceTV-ის პორტი და სახელი (0x40), საკვანძო სიტყვები ან tag-ები (0x20) და სრული 64-ბიტიანი game id (0x01). თამაშის პორტის ველის წყალობით შეიძლება Steam-ის სია query პორტზე მიმართო და მოთამაშეები მაინც სწორ თამაშის პორტს დაუკავშირდნენ.

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

ორი ძველი მოთხოვნა, A2S_PING და დამოუკიდებელი challenge-ის მოთხოვნა, მოძველებულია და ბევრი სერვერი მათ აღარ პასუხობს. მათზე ხელსაწყოებს ნუ ააშენებ.

Challenge, და რატომ დაემატა#

A2S ისეთ ეპოქაში შეიქმნა, როცა reflection-ზე არავინ ნერვიულობდა. დაახლოებით 25-ბაიტიანი მოთხოვნა გაყალბებული წყაროს მისამართიდან რამდენიმე ასეულბაიტიან პასუხს იწვევდა, რომელიც გაყალბებულ მისამართზე იგზავნებოდა - გამაძლიერებელი, რომლის დამიზნებაც ნებისმიერს შეეძლო. თამაშის სერვერები reflection შეტევების გავრცელებულ ინგრედიენტად იქცა, რასაც DDoS შეტევები თამაშის სერვერებზე დეტალურად განიხილავს.

გამოსავალი challenge-ია. A2S_PLAYER და A2S_RULES მას დიდი ხანია მოითხოვს, ხოლო 2020 წლის ბოლოდან Valve-ის იმპლემენტაცია A2S_INFO-საც challenge-ს უგზავნის. გაცვლა ასე გამოიყურება:

1. კლიენტი მოთხოვნას აგზავნის.
2. სერვერი პასუხობს 0x41 (A) ტიპის მოკლე პაკეტით, რომელიც 4-ბაიტიან challenge-ის ნომერს შეიცავს.
3. კლიენტი იმავე მოთხოვნას ხელახლა აგზავნის, ამ 4 ბაიტის მიმატებით.
4. სერვერი ნამდვილ პასუხს აგზავნის.

გაყალბებული წყაროს მისამართი მე-2 ნაბიჯს ვერასოდეს ხედავს, ამიტომ მე-4-ს ვერასოდეს იღებს, და გაძლიერება ქრება. შენთვის პრაქტიკული შედეგი: ძველი სტატუსის სკრიპტი, რომელიც ერთ A2S_INFO-ს აგზავნის და I პასუხს ელის, ახლა A პასუხს იღებს, წყვეტს, რომ სერვერი გაფუჭებულია, და offline-ად აცხადებს. თუ მონიტორინგის ხელსაწყო ბოლო რამდენიმე წელიწადში გაჩუმდა და სხვა არაფერი შეცვლილა, დიდი ალბათობით მიზეზი ეს არის. ძველ ძრავებზე ან საკუთარ იმპლემენტაციებზე მომუშავე სერვერები შეიძლება ისევ challenge-ის გარეშე პასუხობდნენ, ამიტომ ხელსაწყოებმა ორივე უნდა დაამუშაონ.

A2S_PLAYER-ისა და A2S_RULES-ისთვის პირველი მოთხოვნა challenge-ის პოზიციაზე FF FF FF FF-ს შეიცავს, რაც challenge-ის მოთხოვნას ნიშნავს.

სერვერისთვის query-ის თავად გაგზავნა#

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

python-a2s-ით

ყველაზე სწრაფი საიმედო ხელსაწყო python-a2s პაკეტია, რომელიც challenge-ებსა და დაყოფილ პაკეტებს ამუშავებს:

$ pip install python-a2s$ python3

import a2saddress = ("203.0.113.10", 27015)  # the QUERY port, not always the game portinfo = a2s.info(address, timeout=3.0)print(info.server_name, info.map_name, info.player_count, info.max_players)for player in a2s.players(address):    print(player.name, player.score, round(player.duration))print(a2s.rules(address))

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

ბიბლიოთეკის გარეშე

თუ ვერაფერს აყენებ, პროტოკოლი იმდენად პატარაა, რომ ხელით ლაპარაკიც შეიძლება. ეს A2S_INFO-ს challenge-ით აკეთებს და პირველ რამდენიმე ველს კითხულობს; დაყოფილ პაკეტებს უგულებელყოფს, რაც info პასუხს თითქმის არასოდეს სჭირდება.

import socket, struct, sysdef read_str(buf, i):    end = buf.index(b"\x00", i)    return buf[i:end].decode("utf-8", "replace"), end + 1host, port = sys.argv[1], int(sys.argv[2])req = b"\xFF\xFF\xFF\xFFTSource Engine Query\x00"s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)s.settimeout(3.0)s.sendto(req, (host, port))data, _ = s.recvfrom(4096)if data[4] == 0x41:  # challenge: resend with it appended    s.sendto(req + data[5:9], (host, port))    data, _ = s.recvfrom(4096)i = 6  # skip the 4-byte header, the 0x49 type and the protocol bytename, i = read_str(data, i)map_name, i = read_str(data, i)folder, i = read_str(data, i)game, i = read_str(data, i)app_id, players, max_players, bots = struct.unpack_from("<HBBB", data, i)print(f"{name} | {map_name} | {players}/{max_players} ({bots} bots)")

გაუშვი ასე: python3 a2s_info.py 203.0.113.10 27015.

GameDig-ით

GameDig არის Node.js ბიბლიოთეკა და ბრძანების ხაზის ხელსაწყო, რომელმაც ასობით თამაში იცის, მათ შორის ისეთებიც, რომლებიც A2S-ზე არ ლაპარაკობენ. სწორედ მას იყენებს ქვემოთ ბევრი სტატუსის ბოტი და ვებსაიტი.

$ npm install -g gamedig$ gamedig --type valheim 203.0.113.10:2456

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

Query პორტები თამაშების მიხედვით#

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

დასამახსოვრებელი სქემა: Source თამაშები თამაშის პორტზე პასუხობენ, ხოლო თამაშები, რომლებმაც Steam-ის სერვერის API სხვა ძრავს მიაბეს, ჩვეულებრივ მეორე პორტზე პასუხობენ. როცა თამაშის პორტს ცვლი, შეამოწმე, query პორტი მასთან ერთად მოძრაობს (წანაცვლება) თუ ადგილზე რჩება (ფიქსირებული პარამეტრი). ერთის შეცვლა და მეორის დავიწყება გაძლევს სერვერს, რომელზეც შესვლა შეიძლება და რომელიც უხილავია. პანელზე ორივე ნომერი უნდა იყოს გამოყოფილი - RE:NODE-ზე ისინი გეგმის პორტების რაოდენობის ნაწილია, დამატებითი კი Network ჩანართზე ემატება - და თამაშის საკუთარი პარამეტრი გამოყოფილს უნდა ემთხვეოდეს. თამაშის სერვერის პორტების ახსნაში უფრო გრძელი ცხრილია, RCON-ისა და დამხმარე პორტების ჩათვლით.

Minecraft ამას სხვანაირად აკეთებს#

Minecraft Java A2S-ს არ იყენებს. მას ორი მექანიზმი აქვს, და მათი არევა ადვილია.

Server List Ping არის ის, რასაც multiplayer ეკრანი იყენებს. ის TCP-ზე, თამაშის პორტზე მუშაობს: კლიენტი აგზავნის handshake-ს სტატუსის მოთხოვნით, შემდეგ სტატუსის მოთხოვნას, ხოლო სერვერი JSON-ით პასუხობს - ვერსია, ონლაინ და მაქსიმალური მოთამაშეები, მოთამაშეების სახელების ნიმუში, MOTD და სერვერის ხატულა. მას server.properties-ში enable-status აკონტროლებს, რომელიც ნაგულისხმევად ჩართულია. მისი გამორთვა სერვერს სიაში offline-ად აჩვენებს, თუმცა ის მაინც იღებს მოთამაშეებს, რომლებმაც მისამართი იციან.

Query ძველი UDP პროტოკოლია, რომელსაც წარმოშობის მიხედვით ხშირად GameSpy4 query-ს უწოდებენ. ის ნაგულისხმევად გამორთულია და მას enable-query და query.port აკონტროლებს. ჩართულ მდგომარეობაში სტატუსის ping-ზე მეტ დეტალს აბრუნებს, ზოგიერთ სერვერულ პროგრამაზე plugin-ების სიის ჩათვლით. მესამე მხარის სტატუსის საიტები ზოგჯერ მას ითხოვენ; თითქმის არაფერს სხვას არ სჭირდება.

from mcstatus import JavaServer  # pip install mcstatusserver = JavaServer.lookup("play.example.com:25565")status = server.status()print(status.players.online, status.players.max, round(status.latency))

lookup SRV ჩანაწერსაც მიჰყვება, ასე რომ მისამართს ისე ამოწმებს, როგორც მოთამაშეები წერენ. SRV ჩანაწერები Minecraft-ისთვის ამ ნაწილს ხსნის.

რას აკეთებენ მასთან სტატუსის საიტები, ბოტები და სიები#

ყოველი სერვერების სიის ვებსაიტი, ყოველი "players online" ვიჯეტი და თითქმის ყოველი Discord-ის სტატუსის ბოტი ტაიმერზე მომუშავე query კლიენტია. ისინი A2S-ს (ან თამაშის ეკვივალენტს) დაახლოებით ყოველ წუთში აგზავნიან და პასუხს ინახავენ. ამას სამი შედეგი აქვს.

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

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

Rate limit-ები და რას გასცემს query#

რადგან query პორტი ყველას პასუხობს, ის სერვერის ყველაზე იაფად დასატვირთი ნაწილია. Source-engine სერვერებს ჩაშენებული ლიმიტები აქვთ, ნაგულისხმევი მნიშვნელობებით, რომლებიც ჩვეულებრივ გამოყენებას ერგება:

sv_max_queries_sec 3          // queries per second from one addresssv_max_queries_window 30      // window over which that rate is averagedsv_max_queries_sec_global 60  // total queries per second answered

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

Query იმაზე მეტსაც გასცემს, ვიდრე ხალხი ელის. A2S_RULES Source სერვერზე აბრუნებს ყოველ cvar-ს, რომელიც საჯაროდაა მონიშნული, რაც მოდიფიცირებულ სერვერზე ხშირად plugin-ების სახელებსა და ვერსიებს მოიცავს - უფასო ინვენტარი ყველასთვის, ვინც ცნობილ მოწყვლად plugin-ს ეძებს. ზოგი თამაში და ადმინისტრირების framework წესების ან მოთამაშეების სიის დამალვის საშუალებას იძლევა; სადაც ასეა, კერძო სერვერისთვის ეს განიხილე. რას ვაკეთებთ შეტევებთან query პორტს თავდაცვის მხრიდან განიხილავს.

Query-ის ჯანმრთელობის შემოწმებად გადაქცევა#

Query ყველაზე კარგი იაფი ჯანმრთელობის შემოწმებაა, რაც თამაშის სერვერს აქვს, ICMP ping-ზე ან უბრალო TCP connect-ზე უკეთესი, რადგან მას მხოლოდ მომუშავე თამაშის პროცესი პასუხობს. მანქანა, რომელიც ჩართულია, მაგრამ სერვერი ჩავარდნილი ან გაყინული აქვს, ping-ებს მაინც პასუხობს; A2S-ს კი არა. სწორად გამოყენებისას ის იჭერს იმ ჩავარდნებს, რომლებიც მოთამაშეებისთვის მნიშვნელოვანია.

რამდენიმე წესი მას სანდოს ხდის:

• შეამოწმე გარედან. იმავე მანქანაზე გაშვებული შემოწმება პროცესზე გეუბნება და არა იმ გზაზე, რომელსაც მოთამაშეები იყენებენ. გაუშვი სხვაგან, იდეალურად სხვა ქსელიდან.
• გაითვალისწინე ერთი დაკარგული პაკეტი. UDP პასუხები იკარგება. ჩავარდნის დათვლამდე ერთხელ სცადე ხელახლა უფრო გრძელი timeout-ით, ხოლო გაფრთხილება სამი ზედიზედ ჩავარდნის შემდეგ გაგზავნე და არა ერთის.
• შეამოწმე შინაარსი და არა მხოლოდ პასუხი. შეადარე სერვერის სახელი და მაქსიმალური მოთამაშეები მოსალოდნელს. პასუხი არასწორი სერვერიდან - ან სერვერიდან, რომელიც ნაგულისხმევი კონფიგით გადაიტვირთა მას შემდეგ, რაც განახლებამ შენი წაშალა - ჩავარდნაა, რომელსაც მარტივი "უპასუხა თუ არა" შემოწმება ვერ ხედავს.
• უყურე ტენდენციას და არა მომენტს. მოთამაშეების რაოდენობა, რომელიც ყოველ ღამე ერთსა და იმავე დროს ნულამდე ეცემა, დაგეგმილი გადატვირთვაა. ის, რომელიც შემთხვევით ეცემა ნულამდე და ორ წუთში ბრუნდება, crash loop-ია, და შემდეგი წასაკითხი არის რატომ გადაიტვირთება შენი თამაშის სერვერი გამუდმებით.
• ინტერვალი გონივრული დატოვე. წუთში ერთხელ სავსებით საკმარისია. შენი საკუთარი მონიტორი, რომელიც ყოველ წამს ეკითხება, პატარა flood-ისგან არ განსხვავდება და შეიძლება სერვერის rate limit-ს გადააჭარბოს.

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

როცა query ფუჭდება, თამაში კი მუშაობს#

იმოქმედე გარედან: ჰკითხე პორტს, რომელიც query პორტი გგონია, შემდეგ თამაშის პორტს, შემდეგ წაიკითხე სერვერის log-ის პირველი ხაზები, რომ ნახო, რომელ პორტზე მიება სინამდვილეში. ყოველ კამათში log იგებს.

FAQ#

Query პორტი იგივეა, რაც RCON-ის პორტი?

არა. Query პორტი ანონიმურ სტატუსის მოთხოვნებს UDP-ით პასუხობს. RCON ავთენტიფიცირებული დისტანციური კონსოლია, Source თამაშებზე TCP-ით, და ის იმაზე ფართოდ არ უნდა გახსნა, ვიდრე გჭირდება. RCON უსაფრთხოდ ამას განიხილავს.

მჭირდება query პორტის გახსნა, თუ სერვერი კერძოა?

მოთამაშეებს კერძო სერვერზე პირდაპირი მისამართით მის გარეშეც შეუძლიათ შესვლა. მაგრამ Steam-ის favourites, სტატუსის ბოტები და თამაშის შიდა სია query პორტს იყენებენ, ამიტომ მისი დახურვა სერვერს ყველგან offline-ად აჩვენებს. უმეტესობა ღიად ტოვებს და პაროლს ეყრდნობა.

რატომ აჩვენებს ჩემი query ხელსაწყო მოთამაშეების სხვა რაოდენობას, ვიდრე თამაში?

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

შემიძლია A2S uptime-ის მონიტორინგისთვის გამოვიყენო?

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

ყველა Steam თამაში უჭერს მხარს A2S-ს?

Steam-ის game server API-ზე აგებული გამოყოფილი სერვერების უმეტესობა A2S-ს პასუხობს, მაგრამ არა ყველა, და ზოგი მხოლოდ ნაწილს პასუხობს. თამაშები, რომლებიც სიას Epic-ის, PlayFab-ის ან საკუთარი სერვისის მეშვეობით აწყობენ, ხშირად A2S-ს საერთოდ არ პასუხობენ. ეჭვის შემთხვევაში ჰკითხე და ნახე.