როდის ეხმარება საერთო პროქსი ქეში კროლერს

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

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

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

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

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

ჩვეულებრივი HTTPS CONNECT ტრაფიკისთვის forward პროქსი დაშიფრულ გვირაბს ატარებს და მასში ქეშირებადი HTTP ობიექტები არ არის. TLS-შემოწმებიან განლაგებას სხვა ნდობისა და დამუშავების ქცევა აქვს. ობიექტების ქეშირების ხელმისაწვდომობის შეფასებისას ჩართეთ რეალური რეჟიმი.

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