რატომ არ ავსებს CONNECT ტრაფიკი Squid-ის ობიექტების ქეშს
რატომ შეუძლია ჩვეულებრივ HTTPS გვირაბს ბევრი ბაიტის გადაცემა ისე, რომ პირდაპირ პროქსის ხელახლა გამოსაყენებელი HTTP პასუხის ობიექტები არ მიაწოდოს.
ჩვეულებრივი CONNECT გვირაბი Squid-ს აწვდის დაშიფრულ ბაიტებს და არა ვებსაიტის პასუხს, რომლის ქეშირებაც შესაძლებელია. ამიტომ დიდმა HTTPS ჩამოტვირთვამ შეიძლება ბევრი ტრაფიკი წარმოქმნას ისე, რომ ობიექტების ქეშს არცერთი ხელახლა გამოსაყენებელი ჩანაწერი არ დაამატოს.
Squid-ს შეუძლია გვირაბის დანიშნულების ადგილის, ხანგრძლივობისა და ბაიტების რაოდენობის ჩაწერა. იგი არ იღებს შიდა URL-ის გზას, ქეშის დირექტივებს, წარმოდგენასა და ვალიდატორებს ჩვეულებრივი HTTP შეტყობინებების სახით, რომელთა შენახვა და ხელახლა გამოყენებაც შეეძლება. მეტი დისკური სივრცე ან ობიექტის ზომის უფრო მაღალი ზღვარი მათ ვერ გამოაჩენს.
სანამ ქეშირებას გაუმართავად მიიჩნევთ, შეამოწმეთ მოთხოვნის მეთოდები და გვირაბების ჩანაწერები. დატვირთვაში, სადაც CONNECT ჭარბობს, დიდი მოცულობის გადაცემა და ობიექტების მცირე ხელახალი გამოყენება ერთმანეთს არ ეწინააღმდეგება. ქეშის რეალური შემოწმებისთვის გამოიყენეთ თქვენი კონტროლის ქვეშ მყოფი HTTP რესურსი, ქეშის მკაფიო სათაურებითა და ცნობილი შიგთავსით; დარწმუნდით, რომ ამოწმებთ Squid-ის ობიექტების დამუშავების გზას და არა გვირაბს, ბრაუზერის ქეშს ან დანიშნულების CDN-ს.
პროქსიმდე TLS არის ცალკე შრე. საკუთარ მსმენელზე TLS კავშირის დასრულების შემდეგ Squid-ს შეუძლია HTTP დანიშნულების ჩვეულებრივი მოთხოვნის დამუშავება. თუ იმავე კავშირით სანაცვლოდ HTTPS-ზე CONNECT მოითხოვება, დანიშნულების შიდა TLS ცალკე და გაუმჭვირვალე რჩება.
HTTPS-ის ჩაჭერა ცვლის სერტიფიკატებისადმი ნდობის, ავტორიზაციისა და კონფიდენციალურობის მოთხოვნებს. ეს ქეშის სივრცის ჩვეულებრივი რეგულირება არ არის და ჩვეულებრივ პირდაპირ პროქსის მუშაობისთვის ჩაჭერა არ სჭირდება.