გამტარი პროქსის ნაკადი სრული პასუხის ბუფერიზაციის წინააღმდეგ

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

ნაკადის ჩვეულებრივი ეტაპები შეიძლება გადაფარდეს:

origin produces a chunk → proxy forwards bytes → client consumes them

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

უკუწნეხა შეიძლება დროებით შეაჩეროს ზედა დინების კითხვა, როცა ნელი კლიენტი ავსებს გამომავალ რიგებს. Content-Length ასევე გვაძლევს სიგრძეს სრული ბუფერიზაციის გარეშე. HTTP/1.1 chunked კოდირება იძლევა ეტაპობრივ მიწოდებას, მაგრამ ვერ გარანტირებს დაბალ შეყოვნებას, თუ წინა კომპონენტი ინახავს მონაცემებს.

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

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