TCP თუ UDP გეიმ სერვერებისთვის: რატომ იყენებენ თამაშები UDP-ს

ინტერნეტში თითქმის ყველა action თამაში გეიმფლეის UDP-ით აგზავნის და მიზეზი ერთი წინადადებით ეტევა: თამაშში დაგვიანებული პაკეტი უარესია, ვიდრე პაკეტი, რომელიც საერთოდ არ მოსულა. TCP-ს ამ აზრის გამოხატვა არ შეუძლია. ის გარანტიას იძლევა, რომ ყველაფერი, რაც გაგზავნე, მივა და თანმიმდევრობით, რაც ნიშნავს, რომ როცა ერთი პაკეტი იკარგება, მის უკან ყველაფერი ხელახალი გადაცემის მოლოდინშია - და სანამ ხელახლა გაგზავნილი პოზიციის განახლება მოვა, მოთამაშემ სამჯერ უკვე გადაინაცვლა. UDP-ს არც ასეთი გარანტია აქვს და არც ასეთი დაყოვნება, ამიტომ თამაშები დაუმუშავებელ datagram-ს იღებენ და მასზე ზუსტად იმ საიმედოობას აგებენ, რაც სჭირდებათ. ეს ერთი არჩევანი ხსნის უმეტეს პრაქტიკულ რამეს, რასაც შეხვდები: რატომ არ იმუშავა შენმა firewall-ის წესმა, რატომ ვერ დამალავ გეიმ სერვერს იმავე proxy-ის უკან, რის უკანაც შენი ვებსაიტია, და რატომ არაფერს გეუბნება telnet თამაშის პორტზე.

განსხვავება, რომელსაც მნიშვნელობა აქვს: head-of-line blocking#

სახელმძღვანელოებში შედარება ხუთ განსხვავებას ჩამოთვლის. მხოლოდ ერთი წყვეტს რამეს.

TCP ნაკადია. ის ყოველ ბაიტს ნომრავს, აღიარებს იმას, რაც მივიდა, ხელახლა აგზავნის იმას, რაც არ მივიდა, და აპლიკაციას მიაწვდის სრულყოფილად დალაგებულ თანმიმდევრობას. ამისთვის მან უნდა შეაჩეროს მონაცემები, რომლებიც არეულად მოვიდა, სანამ დაკარგული ნაწილი არ გამოჩნდება. ეს არის head-of-line blocking და დანაკარგიან კავშირზე ის 1%-იან პაკეტის დანაკარგს ხილულ გაჭედვად აქცევს, რადგან მიმღებ აპლიკაციას პაკეტების 5, 6 და 7 დანახვის უფლება არ აქვს, სანამ პაკეტი 4 არ აღდგება. Linux-ზე ხელახალი გადაცემის მინიმალური timeout 200 ms-ია, ამიტომ ერთი დანაკარგი არასწორ მომენტში სულ მცირე იმდენს ჯდება.

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

დანარჩენი განსხვავებები აქედან გამომდინარეობს:

ყალბი წყაროს რიგი ის არის, რომელსაც წარმადობის მიღმა შედეგები აქვს: რადგან UDP-ს handshake არ აქვს, თავდამსხმელს შეუძლია პაკეტზე შენი მისამართი მიაწეროს და მესამე მხარეს შენთვის პასუხი გააგზავნინოს. ეს არის reflection შეტევების მთელი საფუძველი, რაც აღწერილია DDoS შეტევები გეიმ სერვერებზე ახსნილში.

რატომ ვერ გამოიყენებს shooter-ი TCP-ს#

გაიარე დროის გათვლა და არგუმენტი თავისით ჩამოყალიბდება.

სერვერი, რომელიც წამში 64 tick-ზე მუშაობს, სამყაროს ახალ snapshot-ს ყოველ 15,6 ms-ში ქმნის. ყოველი snapshot აღწერს, სად არის ახლა ყველა. დავუშვათ, snapshot 100 მოთამაშემდე მისვლისას დაიკარგა.

UDP-ით: არაფერი ხდება. Snapshot 101 15,6 ms-ის შემდეგ მოდის უფრო ახალი პოზიციებით, კლიენტი ხარვეზზე interpolate-ს აკეთებს და ვერავინ ამჩნევს. დაკარგული snapshot მოძველებული იყო, სანამ ვინმე მის ხელახლა მოთხოვნას მოასწრებდა.

TCP-ით: კლიენტის kernel-ს snapshot-ები 101, 102 და 103 ბუფერში უდევს და არცერთს არ აძლევს თამაშს, რადგან snapshot 100 აკლია და თანმიმდევრობა უნდა შენარჩუნდეს. ის ხელახლა გაგზავნას ელოდება, რასაც სულ მცირე ერთი round trip სჭირდება და შესაძლოა 200 ms timeout. შემდეგ თამაში ერთდროულად ოთხ snapshot-ს იღებს, რომელთაგან სამი წარსულს აღწერს. მოთამაშე ხედავს გაჭედვას, რასაც მოსდევს ყველას teleport-ი. ზუსტად ასე გამოიყურება "rubber-banding".

არ არსებობს კონფიგურაცია, რომელიც ამას შეასწორებს. TCP_NODELAY თიშავს Nagle-ის ალგორითმს და სხვა დაყოვნებას ხსნის - იმას, როცა პატარა ჩაწერები დასაჯგუფებლად ინახება - და ღირს, ნებისმიერ TCP გეიმ სერვერზე დააყენო, მაგრამ head-of-line blocking-ს ვერ ეხება, რადგან ეს თავად გარანტიის თვისებაა.

ამიტომ თამაშები მდგომარეობას UDP-ით აგზავნიან და დანაკარგს ნორმად იღებენ. რასაც საიმედოობაში კარგავენ, ტექნიკით ანაზღაურებენ: სრული snapshot-ები, რომ ნებისმიერი ერთი პაკეტი ხელახალი სინქრონიზაციისთვის საკმარისი იყოს, delta შეკუმშვა ბოლო დადასტურებულ მდგომარეობასთან, client-side prediction, რომ შენი საკუთარი მოძრაობა მყისიერი იყოს, და interpolation, რომ სხვა მოთამაშეები ხარვეზებზე გლუვად მოძრაობდნენ. Latency, jitter და packet loss აღწერს, რით განსხვავდება ეს სამი პრობლემა მოთამაშის შეგრძნებაში, ხოლო რას ნიშნავს tick rate სინამდვილეში გაგზავნის მხარეს ფარავს.

რომელი თამაში რას იყენებს#

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

Minecraft ამის ყველაზე დამრიგებელი გამონაკლისია. ეს twitch თამაში არ არის: ბლოკის განთავსება, ინვენტარის გადაადგილება ან ჩატის ხაზი ცალკეული მოვლენაა, რომელიც ზუსტად ერთხელ და თანმიმდევრობით უნდა მივიდეს, და დაკარგულის interpolate-ის გამოსადეგი გზა არ არსებობს. TCP ამისთვის სწორი ინსტრუმენტია და ფასი ისაა, რომ ცუდი კავშირის მოთამაშე rubber-band-ის ნაცვლად გაჭედვას იღებს. Bedrock-ის კოდის ბაზა განსხვავებული პროგრამაა, რომელიც UDP-ს იყენებს 19132-ზე, რის გამოც ამ ორს პორტი არასოდეს გაუყვიათ.

რაც ორივე პროტოკოლითაა ჩამოთვლილი, ჩვეულებრივ ნიშნავს გეიმფლეის UDP-ზე პლუს რაღაც ადმინისტრაციულს ან HTTP-ის მსგავსს TCP-ზე, იმავე ნომერზე. ამიტომ ეს თამაშები ითხოვენ ერთ გამოყოფას, რომელიც ორივე პროტოკოლს მოიცავს და არა ორს.

საიმედოობა, ხელახლა აგებული UDP-ის თავზე#

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

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

ბიბლიოთეკები, რომლებიც ამას აკეთებენ, ლოგსა და კონფიგურაციის ფაილში ღირს ამოცნობად: ENet, RakNet, Steam Networking Sockets და მისი Datagram Relay, და სულ უფრო მეტად QUIC, რომელიც UDP-ზე აგებული საიმედო, დაშიფრული, მულტიპლექსირებული ტრანსპორტია და რაზეც HTTP/3 მუშაობს. QUIC არგუმენტის ყველაზე ნათელი დამტკიცებაა: როცა ადამიანებს, რომლებიც TCP-ს ინახავენ, ვებისთვის head-of-line blocking-ის გასწორება უნდოდათ, TCP არ გაასწორეს, UDP-ზე თავიდან ააგეს.

ზომის გათვალისწინებით პრაქტიკული შედეგი: რადგან თამაშები საკუთარ ხელახალ გაგზავნას თავად მართავენ, დანაკარგიანი მარშრუტი სუსტდება და არა ინგრევა, მაგრამ მაინც სუსტდება. გეიმ სერვერზე 2% დანაკარგი ხილული პრობლემაა, მაშინ როცა ფაილის ჩამოტვირთვისას 2% დანაკარგი უხილავია. როცა ვინმე ამბობს, რომ სერვერი ლაგავს, დანაკარგი სამიდან ერთია, რაც უნდა გამორიცხო, და traceroute-სა და mtr-ის კითხვა არის გზა იმის საპოვნელად, რომელი hop აკეთებს ამას.

რას ნიშნავს ეს firewall-ის წესებისთვის#

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

$ ufw allow 25565/tcp            # Minecraft Java$ ufw allow 2456:2457/udp        # Valheim game and query$ ufw allow 27015/udp            # a Source game$ ufw allow 27015/tcp            # the same game's RCON$ ufw allow 30814                # both protocols, for BeamMP$ ufw status numbered

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

ორი UDP-სპეციფიკური ქცევა, რომელიც დაბნეულობას იწვევს:

UDP კავშირი არ არსებობს, მაგრამ შენი firewall ისე იქცევა, თითქოს არსებობდეს. Connection tracking ფსევდო-ჩანაწერს ქმნის, როცა ნაკადის პირველ პაკეტს ხედავს, და timeout-ის შემდეგ მას ასრულებს - Linux-ზე nf_conntrack_udp_timeout ნაგულისხმევად 30 წამია, ხოლო nf_conntrack_udp_timeout_stream - 120 წამი, როცა ტრაფიკი ორივე მიმართულებით მოძრაობს. თამაში, რომელიც ამაზე დიდხანს არაფერს აგზავნის, ჩანაწერს კარგავს და შემდეგი შემომავალი პაკეტი ახლად ითვლება. თამაშები keepalive-ებს ნაწილობრივ ამის გამოც აგზავნიან.

სახლის როუტერები იგივეს აკეთებენ, უარესად. UDP-ის NAT binding სწრაფად ამოიწურება, რის გამოც მოთამაშე, რომელიც გარკვეული როუტერის უკან დგას, მშვიდ lobby-დან ვარდება. სერვერის მხარეს, თუ სახლიდან ჰოსტავ, UDP-ის port forward TCP-ის port forward-ისგან ცალკე წესია, და CGNAT-ის გამო შესაძლოა საერთოდ ვერაფერი გადამისამართო. სახლში ჰოსტინგი თუ ქირაობა პატიოსანი შედარებაა.

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

რატომ ვერ დააყენებ თამაშს ჩვეულებრივი reverse proxy-ის უკან#

ეს კითხვა კვირაში დაახლოებით ერთხელ მოდის, ჩვეულებრივ ასეთი ფორმულირებით: "შემიძლია ჩემი Minecraft სერვერი Cloudflare-ის უკან დავაყენო".

HTTP reverse proxy - nginx ჩვეულებრივ რეჟიმში, Caddy, Traefik, ან ნარინჯისფერი ღრუბელი ვებსაიტის წინ - წყვეტს TCP კავშირს, კითხულობს HTTP მოთხოვნას და შენს backend-ს საკუთარ მოთხოვნას უგზავნის. ამ წინადადების ყოველი ნაწილი TCP-ს და HTTP-ს გულისხმობს. თამაში, რომელიც UDP datagram-ებს საკუთარი ბინარული პროტოკოლით აგზავნის, არც ერთს გვთავაზობს, ამიტომ HTTP proxy-ს გასაკეთებელი არაფერი აქვს. რას აკეთებს reverse proxy ზოგადი ახსნაა, ხოლო Cloudflare ვებსაიტებისა და გეიმ სერვერებისთვის კონკრეტულია იმაში, სად გადის ხაზი.

რაც არსებობს:

• Layer 4 TCP proxy. nginx-ის stream მოდული, HAProxy TCP რეჟიმში, ან თამაშისთვის სპეციფიკური proxy, როგორიცაა Velocity Minecraft-ისთვის. ეს TCP თამაშებისთვის მუშაობს და ნამდვილად გამოსადეგია: Velocity ქსელი რამდენიმე backend-ს ერთი საჯარო პორტის უკან სვამს.
• UDP proxy. nginx-ის stream მოდულს შეუძლია UDP-ის გადაგზავნა listen 25565 udp;-ით და proxy_pass-ით და მარტივ შემთხვევებში მუშაობს. საქმე წყაროს მისამართშია: გამჭვირვალე proxy-ს გარეშე გეიმ სერვერი ყველა მოთამაშისთვის proxy-ის მისამართს ხედავს, რაც ტეხს ბანებს, ლოგებს და ყველაფერს, რაც მოთამაშეზეა მიბმული.
• მომწოდებლის relay ქსელები. Steam Datagram Relay და მსგავსი სერვისები UDP-ს ოპერატორის საკუთარ backbone-ზე ატარებენ და სერვერის მისამართს მალავენ. ისინი თამაშის პლატფორმის ნაწილია და არა რაღაც, რასაც გვერდიდან მიამაგრებ.

პრაქტიკული შეჯამება: ვებ front end proxy-ის უკან შეიძლება დაიმალოს, UDP-ზე მყოფი გეიმ სერვერი - ვერა, და თუ ორივეს უშვებ, ისინი ერთ მისამართს არ უნდა იზიარებდნენ. RE:NODE-ზე აპლიკაციებისა და ვებ გეგმების proxy-ის სლოტი ზუსტად ეს HTTP-ის მსგავსი რამაა - მიუთითე A ჩანაწერი ნაჩვენებ მისამართზე და სერტიფიკატი ავტომატურად გაიცემა და განახლდება, ხოლო კლიენტის რეალური მისამართი X-Forwarded-For-ში მოდის. ის შენი ვებსაიტისა და API-სთვისაა და არა თამაშის პორტისთვის.

Query პორტები, RCON და შერეული შემთხვევა#

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

თამაშის პორტი გეიმფლეის ატარებს და ისეთია, როგორიც თამაშმა აირჩია. Query პორტი სერვერების ბრაუზერებსა და სიის საიტებს მოთამაშეების რაოდენობით, რუკითა და სახელით პასუხობს. Source ოჯახში ეს A2S პროტოკოლია UDP-ზე, ჩვეულებრივ იმავე ნომერზე, რაც თამაშს. Minecraft-ში ორია: TCP status ping თამაშის პორტზე, რომელსაც თამაშის შიგნით სერვერების სია იყენებს, და არჩევითი UDP query პროტოკოლი, რომელიც enable-query=true-ით და query.port-ით ირთვება server.properties-ში და რომელსაც გარე status საიტები იყენებენ.

RCON დისტანციური ადმინისტრირებაა და თითქმის ყოველთვის TCP-ა, რადგან ბრძანება ზუსტად ერთხელ და თანმიმდევრობით უნდა მივიდეს. Minecraft-ის არის 25575, Source თამაშები თამაშის პორტის ნომერს იყენებენ TCP-ზე, Project Zomboid-ი და რამდენიმე სხვა ნაგულისხმევად 27015-ს. ეს ერთადერთი პორტია, რომელიც მგრძნობიარედ უნდა მიიჩნიო - იხილე RCON-ის უსაფრთხოდ გამოყენება.

DNS-საც იცის ეს განსხვავება. A ჩანაწერი პროტოკოლისგან დამოუკიდებელია: ის სახელს მისამართზე ასახავს და პორტებზე ან პროტოკოლებზე არაფერს ამბობს. SRV ჩანაწერი ორივეს შეიცავს, რის გამოც Minecraft-ის SRV ჩანაწერი იწერება როგორც _minecraft._tcp.example.com და რის გამოც UDP თამაშის ექვივალენტი _udp-ს დაასახელებდა. SRV ჩანაწერები Minecraft-ისთვის ფარავს ერთ შემთხვევას, სადაც ეს რეგულარულად გამოიყენება.

UDP პორტის სწორად შემოწმება#

აქ ხდება დიაგნოსტიკის უმეტესი შეცდომა. UDP პორტს telnet-ით ვერ შეამოწმებ და nc -z -u თითქმის უსარგებლოა, რადგან სიჩუმე წარმატებით მიწოდებულ UDP პაკეტზე ნორმალური პასუხია. პასუხის არარსებობა არაფერს ამტკიცებს.

დაიწყე სერვერზე, სადაც პასუხი ერთმნიშვნელოვანია:

$ ss -lunp | grep 27015        # is anything listening on UDP?$ ss -ltnp | grep 25575        # and the TCP side$ ss -lunp

ss -lunp ჩამოთვლის მოსმენად UDP socket-ებს პროცესთან ერთად, რომელიც მათ ფლობს. თუ შენი თამაში ამ სიაში არ არის, პრობლემა თამაშის კონფიგურაციაშია და არა ქსელში და არცერთი firewall-ის ცვლილება არ დაგეხმარება. ეს ერთი ბრძანება "პორტი არ მუშაობს" ბილეთების უმეტესობას წყვეტს.

თუ socket ადგილზეა, უყურე, საერთოდ ჩამოდის თუ არა პაკეტები:

$ tcpdump -n -i any udp port 27015$ tcpdump -n -i any udp port 27015 -c 20 -w /tmp/capture.pcap

ტრაფიკი მოდის და პასუხი არ არის - ნიშნავს, რომ თამაში არ პასუხობს, და ეს თამაშის პრობლემაა. ტრაფიკი არ მოდის - ნიშნავს, რომ ის შენამდე იკარგება, და ეს firewall-ის ან upstream-ის პრობლემაა.

გარედან პატიოსანი ვარიანტები შეზღუდულია:

$ nmap -sU -p 27015 203.0.113.10        # needs root, and is slow

nmap open|filtered-ს აბრუნებს, როცა არაფერი ბრუნდება, და ის ზუსტად იმას ნიშნავს, რასაც ამბობს: ან პორტი ღიაა და სერვისმა პასუხი არ ისურვა, ან რაღაცამ საცდელი პაკეტი გადააგდო. ერთადერთი გარეშე გადამწყვეტი ტესტი კლიენტია, რომელიც თამაშის საკუთარ პროტოკოლს ლაპარაკობს - თავად თამაში, სერვერის query ხელსაწყო ან ამ თამაშის საჯარო status checker-ი. თუ query პორტი მისაწვდომია, სიის საიტს სერვერის დანახვა შეუძლია, და ეს არის პასუხი, რომელიც რეალურად გინდოდა.

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

FAQ#

რატომ იყენებენ თამაშები UDP-ს TCP-ის ნაცვლად?

იმიტომ, რომ დაგვიანებული პაკეტი უარესია, ვიდრე დაკარგული. TCP თანმიმდევრულ მიწოდებას გარანტირებს, ამიტომ ერთი დაკარგული პაკეტი მის უკან ყველაფერს სულ მცირე ერთი round trip-ით აჩერებს, სანამ ხელახლა იგზავნება, და მაშინ ინფორმაცია უკვე მოძველებულია. UDP აწვდის იმას, რაც მოვიდა, როცა მოვიდა, და თამაში ხარვეზებს prediction-ითა და interpolation-ით ავსებს.

ნაკლებად საიმედოა UDP, ვიდრე TCP?

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

უნდა გავხსნა თუ არა ორივე, TCP და UDP?

ეს თამაშზეა დამოკიდებული და ღირს შემოწმება და არა გამოცნობა. უმეტეს თამაშს UDP სჭირდება გეიმფლეისთვის და TCP მხოლოდ RCON-ისთვის ან ვებ ინტერფეისისთვის. რამდენიმე, მათ შორის 7 Days to Die, FiveM, Satisfactory და BeamMP, ნამდვილად იყენებს ორივეს ერთსა და იმავე ნომერზე. UDP თამაშისთვის მხოლოდ TCP-ს გახსნა იძლევა სერვერს, რომელიც მუშაობს და რომელსაც ვერავინ უკავშირდება.

შემიძლია გეიმ სერვერი Cloudflare-ის უკან დავაყენო?

სტანდარტულ proxy-ს ვერა, რომელიც HTTP-სა და HTTPS-ს TCP-ზე ამუშავებს. UDP-ის გამგზავნ თამაშს მას დასასრულებელი არაფერი აქვს. გამოიყენე ის შენი ვებსაიტისთვის და ვებსაიტი თამაშისგან სხვა მისამართზე გქონდეს, რადგან ვებსაიტი ჩვეულებრივ ის გზაა, რომლითაც ხალხი თამაშის მისამართს პოულობს.

რატომ ამბობს telnet, რომ პორტი დახურულია, როცა სერვერი მუშაობს?

იმიტომ, რომ telnet TCP-ს ლაპარაკობს და თამაშის პორტი UDP-ა. ტესტი უაზროა. სერვერზე შეამოწმე ss -lunp, რომ ნახო, რაიმე ისმენს თუ არა, შემდეგ გარედან გამოსცადე ხელსაწყოთი, რომელიც თამაშის საკუთარ query პროტოკოლს ლაპარაკობს.

იყენებს თუ არა UDP ნაკლებ გამტარუნარიანობას, ვიდრე TCP?

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