Proxy Timeout Ayarları: Bağlantı ve Okuma Zaman Aşımı

Proxy’de zaman aşımı iki bağlantıya bölünür

Doğrudan bir HTTPS isteğinde iki aşama vardır: hedefe TCP bağlantısı ve TLS el sıkışması, sonra yanıtın gelmesi. Proxy araya girince aşama sayısı artar. İstemci önce proxy sunucusuna TCP bağlantısı açar; sonra proxy’ye hedefe tünel açmasını söyler (CONNECT isteği); proxy hedefe kendi TCP bağlantısını kurar ve tünelin hazır olduğunu bildirir; istemci tünelin içinden hedefle TLS el sıkışması yapar; son olarak isteği gönderir ve ilk baytı bekler.

Kütüphanelerin çoğunda bağlantı zaman aşımı yalnız birinci aşamayı, yani istemciden proxy’ye TCP bağlantısını kapsar. Proxy’nin hedefe bağlanmak için harcadığı süre, istemci açısından “CONNECT yanıtını bekleme” süresidir ve okuma zaman aşımının içine düşer. Bu ayrım pratikte şu anlama gelir: proxy sunucusu yakın ve hızlıysa bağlantı zaman aşımı kısa tutulabilir, ama okuma zaman aşımı proxy’nin hedefe ulaşma süresini de karşılamak zorundadır. Hedef uzak bir ülkedeyse okuma süresi hedefe göre, bağlantı süresi proxy’ye göre seçilir.

Okuma zaman aşımının tanımı da kütüphaneye göre değişir. Çoğunda bu süre iki bayt arasındaki en uzun bekleme süresidir; yanıt akmaya devam ettiği sürece toplam süre sınırsız olabilir. Bazı kütüphaneler ayrıca bir toplam süre sınırı sunar; bu sınır bağlantıdan son bayta kadar her şeyi kapsar. Üç süre (bağlantı, okuma, toplam) ayrı ayrı anlaşılmadan seçilen değer ya çok gevşek ya da yanlış aşamada sıkı olur.

Varsayılan “sonsuz bekleme” neden tehlikelidir?

Bazı kütüphanelerde zaman aşımı verilmezse istek sonsuza kadar bekler. Python’un yaygın kullanılan requests kütüphanesi bunun en bilinen örneğidir: timeout parametresi geçilmezse ne bağlantı ne okuma için bir sınır vardır. curl’de toplam süre için varsayılan bir sınır yoktur; bağlantı aşaması için uzun bir varsayılan vardır ama toplamı o da sınırlamaz. Diğer kütüphanelerde varsayılanlar dakikalarla ölçülür; yüksek hacimli bir iş için dakika bile uzundur.

Sonsuz beklemenin bedeli hata sayısında görünmez, işçi sayısında görünür. Elli işçiyle çalışan bir scraper düşünün; hedefin bazı adreslerinde yanıt hiç gelmiyor ama bağlantı da kapanmıyor. Her bu tür adrese denk gelen işçi süresiz bekler. Birkaç saat sonra elli işçinin kırk beşi beklemededir, kuyruk neredeyse durmuştur ve hata günlüğü boştur, çünkü hiçbir istek başarısız olmamıştır. Bu, yüksek hacimli işlerde teşhisi en zor arızadır: sistem ne hata verir ne iş yapar.

Kısa sınır bu arızayı gürültülü bir arızaya çevirir: süresiz bekleyecek istek birkaç saniyede zaman aşımı hatasıyla düşer, işçi serbest kalır, hata günlüğünde hangi hedefin ve hangi aşamanın sorun çıkardığı görünür. Zaman aşımı hatası bu düzende bir ölçüm aracıdır.

Değer seçimi: kendi gecikme ölçümünüzden yola çıkın

Zaman aşımı değeri hedefe, proxy lokasyonuna ve ürüne bağlı olduğu için evrensel bir doğru değer yoktur. Doğru yöntem, gecikme ölçümü rehberinde anlatılan dört bekleme noktasını (istemciden proxy’ye TCP, tünel kurulumu, tünel içi TLS, ilk bayt) aynı proxy ve hedefle birkaç yüz istekte ölçüp her aşamanın yüzde 95’lik değerini almaktır. Zaman aşımı bu değerin birkaç katı olarak seçilir; kat sayısı, geçici yavaşlamaların hata sayılmaması için pay bırakır.

Bir örnek, varsayımları açık olsun: ölçümde proxy’ye TCP bağlantısının yüzde 95’i 300 milisaniyenin altında, tünel kurulumu ve TLS dahil ilk bayt süresinin yüzde 95’i 1,8 saniyenin altında, yanıt gövdesinin tamamı yüzde 95 olasılıkla 4 saniye içinde geliyor olsun. Buradan türeyen değerler bağlantı için 2 saniye, okuma için 6 saniye, toplam için 15 saniyedir. Bağlantı sınırı ölçümün altı katı görünse de mutlak olarak küçüktür; proxy sunucusuna 2 saniyede bağlanılamıyorsa o anda proxy’ye ulaşılamıyordur ve beklemeye devam etmenin faydası yoktur.

Scraping araçlarının dokümanlarında ve sağlayıcı yardım sayfalarında sık rastlanan başlangıç değerleri bağlantı için birkaç saniye, okuma için on saniyeden bir dakikaya kadardır. Bunlar yalnız ölçüm yapılana kadar kullanılacak başlangıç değerleridir. Hedef başına ölçüm yapıldığında çoğu zaman bu aralığın altına inilebildiği görülür; iki hedef arasındaki fark bile büyük olabilir, bu yüzden ağır hedefler ayrı bir zaman aşımı sınıfına alınır.

Proxy lokasyonu okuma süresini doğrudan etkiler: proxy hedefe yakınsa tünel kurulumu ve ilk bayt kısalır, uzaksa uzar. Lokasyon seçimi rehberinde pazar ve gecikme ayrımı anlatılıyor; zaman aşımı değerleri lokasyon değiştiğinde yeniden ölçülür, taşınmaz.

Kütüphane başına ayar: curl, Python, Node ve Go

curl’de iki bayrak yeterlidir: --connect-timeout bağlantı aşamasını saniye cinsinden sınırlar, --max-time toplam süreyi sınırlar. Proxy ile kullanıldığında --connect-timeout yalnız proxy’ye bağlanmayı kapsar; proxy’nin hedefe bağlanma süresi --max-time içinde kalır. Bir hedefi elle test ederken --connect-timeout 5 --max-time 30 ile başlayıp ölçüm sonucuna göre daraltmak pratik bir yoldur.

Python requests kütüphanesinde timeout parametresine iki elemanlı bir demet verilir: ilki bağlantı, ikincisi okuma zaman aşımıdır; timeout=(3, 10) biçiminde yazılır. Tek sayı verilirse ikisine de aynı değer uygulanır. Burada okuma zaman aşımı iki bayt arasındaki bekleme süresidir; toplam süre sınırı yoktur ve uzun bir yanıt sınırsız sürebilir. Toplam sınır gerekiyorsa istek bir iş parçacığı ya da zamanlayıcı ile sarılır. httpx kütüphanesinde zaman aşımı nesnesi bağlantı, okuma, yazma ve havuz bekleme sürelerini ayrı ayrı alır; proxy’li kullanımda havuz bekleme süresi, eşzamanlı istek sayısı havuz boyutunu aştığında devreye girer ve ayrı bir hata üretir.

Node’da yerleşik fetch ve undici tarafında bağlantı zaman aşımı ProxyAgent’a bağlantı seçenekleriyle verilir; başlıkların gelmesi ve gövdenin akması için ayrı süreler vardır. Toplam süre için isteğe bir AbortSignal.timeout değeri bağlanır; süre dolunca istek iptal edilir ve işçi serbest kalır. Bu üçü birlikte kurulmazsa yalnız biri sınırlanır ve diğer aşamalar varsayılanda kalır.

Go’da http.Client üzerindeki Timeout alanı toplam süreyi kapsar: bağlantıdan gövdenin okunup bitmesine kadar. Aşama bazlı sınırlar Transport üzerindedir: DialContext içindeki bağlantı süresi proxy’ye TCP bağlantısını, TLSHandshakeTimeout tünel içindeki el sıkışmayı, ResponseHeaderTimeout ise isteğin gönderilmesinden yanıt başlıklarının gelmesine kadar geçen süreyi sınırlar. Proxy’nin hedefe bağlanma süresi burada da bağlantı süresinin dışında, başlık bekleme süresinin içinde kalır. Dört değerin dördünü de yazmak, Go’da varsayılanların bir kısmının sınırsız olması nedeniyle gereklidir.

Çok kısa ve çok uzun zaman aşımının bedeli

Çok kısa zaman aşımı sağlıklı istekleri hata sayar. Hedefin geçici bir yavaşlamasında yüzlerce istek aynı anda düşer, hepsi yeniden denenir ve yeniden denemeler hem hedefin yükünü hem GB bazlı ürünlerde kotayı artırır; yarım inen gövde de sayılmıştır. İkinci etki ölçümün bozulmasıdır: hata oranı yükselir, hangi proxy adresinin gerçekten sorunlu olduğu görünmez olur, çünkü her adres eşit oranda “zaman aşımı” üretir.

Çok uzun zaman aşımı işçileri kilitler ve kuyruğun kuyruk ucunu uzatır. Bir isteğin bedeline geçen sürenin yanında o süre boyunca meşgul tutulan işçi de girer: 30 saniyelik okuma sınırıyla elli işçiden onu takıldığında kapasitenin beşte biri yarım dakika boyunca iş üretmez. Thread sayısı rehberinde anlatılan eşzamanlılık planı, zaman aşımı değeriyle birlikte okunmalıdır; aynı işçi sayısı 6 saniyelik ve 30 saniyelik sınırlarla çok farklı verim üretir.

Hedefleri sınıflara ayırmak iki ucu da dengeler. Küçük ve hızlı sayfalar (ürün listesi, fiyat alanı) kısa sınıf; büyük raporlar, arama sonuçları ve ağır sayfalar uzun sınıf. Sınıf başına ölçüm yapılır ve sınıf başına değer tutulur. Tek bir küresel değer, en ağır hedefe göre seçilmek zorunda kaldığı için hafif hedeflerde gereksiz uzundur.

Zaman aşımını izlemek: hangi süre hangi sorunu gösterir?

Zaman aşımı hataları aşamasıyla birlikte kaydedildiğinde teşhis aracına dönüşür. Her hata satırında en az şu alanlar bulunmalıdır: proxy adresi ya da portu, hedef sunucu, hangi aşamada düştüğü (bağlantı, tünel, TLS, başlık, gövde), geçen süre ve saat. Bu alanlar olmadan “zaman aşımı” tek bir sayıdır ve hiçbir karara yol açmaz.

Dört örüntü sık görülür. Bağlantı zaman aşımı yalnız belirli bir proxy adresinde ya da portta yoğunlaşıyorsa sorun proxy uç noktasında ya da istemciyle proxy arasındaki ağdadır; hedefle ilgisi yoktur. Başlık ya da ilk bayt zaman aşımı belirli bir hedefte yoğunlaşıyorsa hedef yavaştır ya da sessizce sınır koyuyordur; bağlantı hataları rehberindeki sessiz engelin görünümleri bu durumu ayırmaya yarar. Okuma zaman aşımı bütün hedeflerde ve bütün proxy adreslerinde aynı anda başlıyorsa sorun proxy çıkışı ya da üst ağdadır. TLS el sıkışması zaman aşımı ise çoğunlukla yanlış port ya da protokol, nadiren tünel içinde bir ara kutudur.

İzlenecek ölçü, hedef ve aşama başına saatlik zaman aşımı oranıdır. Oran sıfır değildir ve sıfır olması hedeflenmez; ölçüm yapılan taban değere göre yükselmesi izlenir. Taban değer bir haftalık normal çalışmadan alınır. Oran belirli bir hedefte tabanın birkaç katına çıkarsa o hedefin sınıfı ya da sınırı gözden geçirilir; bütün hedeflerde çıkarsa proxy ya da istemci tarafı incelenir.

Headless tarayıcıda zaman aşımı farklı çalışır

Tarayıcı tabanlı araçlarda tek bir sayfa onlarca istek üretir ve zaman aşımı sayfa bazında düşünülür. Playwright ve Puppeteer’da gezinme zaman aşımı, sayfanın belirli bir yükleme olayına (DOM hazır, yük tamamlandı, ağ boşta) ulaşmasını bekler. Proxy üzerinden yavaş gelen tek bir görsel ya da üçüncü taraf betiği “yük tamamlandı” olayını geciktirir ve sayfa, veri çoktan gelmiş olsa bile zaman aşımına düşer.

Bu yüzden tarayıcı düzeninde iki ayar birlikte yapılır: gezinme beklemesi DOM hazır olayına çekilir ve asıl veri için belirli bir ögenin görünmesi ayrı, kısa bir süreyle beklenir. Gereksiz kaynakların engellenmesi de zaman aşımı sayısını düşürür, çünkü geciktiren isteklerin çoğu verinin kendisi değildir. Tarayıcının kendi bağlantı aşaması için ayrı bir sınır yoktur; proxy’ye bağlanamama tarayıcıda gezinme hatası olarak görünür ve ayrı bir hata metni taşır, günlükte bu metin aşama alanına yazılır.