ჩატის გვერდი იტვირთება, მაგრამ ცოცხალი კავშირი ვერ მყარდება: სად ვეძებოთ

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

იპოვეთ მოთხოვნა, რომელიც შეტყობინებებს გადასცემს

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

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

კონფიგურაცია, მიწოდება და სიცოცხლის ხანგრძლივობა სხვადასხვაგვარად ფუჭდება

WebSocket იხსნება HTTP განახლებით, რომელსაც 101 სტატუსით პასუხობენ, ხოლო ყველაფერი შემდეგ უკვე ჩარჩოებად დაყოფილი შეტყობინებებია და არა გვერდის ჩამოტანა; ეს ორი ეტაპი RFC 6455 ცალსახად გამოყოფს. მოვლენათა ნაკადი პასუხობს სტრიმინგის კონტენტის ტიპით და პასუხის სხეულს ღიად ინახავს. ორივემ შეიძლება ვერ გაიხსნას, გაიხსნას და ვერაფერი მიაწოდოს, ან გაიხსნას, მიაწოდოს და შემდეგ ჩუმად მოკვდეს.

wscat -c wss://chat.example.com/socket -H "Origin: https://chat.example.com"
curl -N -H "Accept: text/event-stream" https://chat.example.com/events

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

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

ცოცხალი ჰოსტი ცალკე დანიშნულებაა

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

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

გაასწორეთ დანიშნულებათა სია და არა უსაფრთხოების შემოწმებები

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

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

დატოვეთ საკმარისი ჩანაწერი გადასაცემად

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

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