Neden bazı indirme dosyaları kendi boyutlarını bilmiyor? [çift]


82

Bu sorunun burada zaten bir cevabı var:

Bazen, bir web tarayıcısında bir dosyayı indirirken, indirme işlemi dosyanın toplam boyutunu ya da indirme işleminin ne kadar sürdüğünü "bilmez" - sadece indirme hızını gösterir. "Bilinmeyen" olarak toplam.

Tarayıcı neden bazı dosyaların son boyutunu bilmiyor? Bu bilgiyi ilk olarak nereden alıyor?


13
Dinamik olarak oluşturulan dosyaların boyutu yoktur, EOF'a ulaşılana kadar akış olarak gelirler.
Fiasco Labs

Yanıtlar:


114

Web sunucularından belge istemek için tarayıcılar HTTP protokolünü kullanır. Bu adı adres çubuğunuzdan biliyor olabilirsiniz (şimdi gizlenmiş olabilir, ancak adres çubuğunu tıklattığınızda, URL'yi kopyalayın ve bir metin düzenleyicisine yapıştırın http://, başında göreceksiniz ). HTTP basit bir metin tabanlı protokoldür. Bu gibi çalışır:

İlk olarak, tarayıcınız web sitesinin sunucusuna bağlanır ve indirmek istediği belgenin bir URL'sini (web sayfaları da belgelerdir) ve tarayıcının kendisi ile ilgili bazı ayrıntıları ( Kullanıcı Aracısı vb.) Gönderir . Örneğin, ana sayfayı SuperUser sitesine yüklemek için http://superuser.com/tarayıcım şuna benzeyen bir istek gönderir:

GET / HTTP/1.1
Host: superuser.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.0 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: pl-PL,pl;q=0.8,en-US;q=0.6,en;q=0.4
Cookie: [removed for security]
DNT: 1
If-Modified-Since: Tue, 09 Jul 2013 07:14:17 GMT

İlk satır, sunucunun hangi belgeyi döndürmesi gerektiğini belirtir. Diğer satırlara başlık denir; şöyle gözüküyorlar:

Header name: Header value

Bu satırlar, sunucunun ne yapacağına karar vermesine yardımcı olan ek bilgiler gönderir.

Her şey yolundaysa, sunucu istenen belgeyi göndererek yanıt verir. Yanıt, bir durum mesajı ile başlar, ardından bazı başlıklar (belge hakkında ayrıntılı bilgi verilir) ve son olarak, her şey yolundaysa, belgenin içeriği ile başlar. SuperUser sunucusunun isteğime olan cevabı şöyle görünüyor:

HTTP/1.1 200 OK
Cache-Control: public, max-age=60
Content-Type: text/html; charset=utf-8
Expires: Tue, 09 Jul 2013 07:27:20 GMT
Last-Modified: Tue, 09 Jul 2013 07:26:20 GMT
Vary: *
X-Frame-Options: SAMEORIGIN
Date: Tue, 09 Jul 2013 07:26:19 GMT
Content-Length: 139672

<!DOCTYPE html>
<html>
    [...snip...]
</html>

Son satırdan sonra, Süper Kullanıcı'nın sunucusu bağlantıyı kapatır.

İlk satır ( HTTP/1.1 200 OK) cevap kodunu içerir, bu durumda 200 OK. Sunucunun, istendiği gibi bir belgeyi iade edebileceğine karar verdiği ve izleyen içeriğin böyle bir belge olacağına söz verdiği anlamına gelir. Durum böyle değilse, kod başka bir şey olacaktır ve sunucunun sadece bir belgeyi yanıt olarak geri döndürmemesinin nedenini gösterecektir: örneğin, istenen belgeyi bulamazsa, geri göndermesi gerekir. 404 Not Foundve söz konusu içeriğe erişme izniniz yoksa, geri göndermesi gerekiyor 403 Forbidden.

Bu ilk durum satırından sonra, cevap başlıkları aşağıdaki gibidir; bunun gibi, iade edilen içerik hakkında daha fazla bilgi sağlarlar Content-type.

Sırada boş bir satır var. Daha fazla yanıt başlığının takip etmeyeceği gerçeğinin bir göstergesidir. Bu satırın üstündeki her şey, istediği belgenin içeriğidir. Yani yukarıdaki örnekte, <!DOCTYPE html>SuperUser ana sayfasının ilk satırı (bir HTML belgesi). İndirmek için bir belge talep ediyor olsaydım, muhtemelen bazı saçma karakterler olurdu, çünkü çoğu belge formatları önceden işlem görmeden okunamıyordu.

Başlıklara dön. Bizim için en ilginç olanı sonuncusu Content-Length. Tarayıcıya, boş satırdan sonra kaç bayt veri beklemesi gerektiğini bildirir, bu nedenle temel olarak bayt olarak ifade edilen belge boyutudur. Bu başlık zorunlu değildir ve sunucu tarafından atlanabilir. Bazen belge boyutu tahmin edilemez (örneğin belge anında oluşturulduğunda), bazen tembel programcılar bunu içermez (sürücü indirme sitelerinde oldukça yaygındır), bazen web siteleri bilmeyenler tarafından oluşturulur böyle bir başlığın.

Neyse, sebebi ne olursa olsun, başlık eksik olabilir. Bu durumda, tarayıcı sunucunun ne kadar veri göndereceğini bilmez ve bu nedenle sunucunun bağlantıyı kapatmasını bekleyen belge boyutunu bilinmeyen olarak görüntüler . Bu da bilinmeyen belge boyutlarının nedeni.


4
Çok, çok küçük bir not: Tarayıcılar HTTP dışındaki protokolleri desteklemektedir. Ancak bu günlerde diğer protokoller nadirdir ve detaylar farklı olsa da temelde aynı kavramlar diğer protokoller için de geçerlidir.
Robert Fisher

5
@RobertFisher FTP nadir bir protokoldür? : p
Thomas,

5
@Tamam Bu günlerde benim deneyimim. Tarayıcımda bir ftp URLsi gördüğümü hatırlıyorum birkaç yıl oldu. Birkaç yıl önce, doğrudan tarayıcıda değil, işte (neredeyse tamamen yüklenir) ftp kullanıyordum, ancak bu işler şimdi scp tarafından gerçekleştiriliyor. Bugün için ftp kullandığım tek şey, içeriği minimalist bir web sunucusuna yüklemek. Tabii ki, YMMV. ^ _ ^
Robert Fisher

2
Bu tam olarak bu siteyi sevmemi sağlayan bir cevap. Buna nasıl bir ödül verebilirim?
Bu Brezilyalı Adam,

1
@ ruda.almeida bu konuda hemfikir değil, meta.superuser.com'da bu konuda yayınlayabilirsiniz, tartışılacak ve belki birileri soruyu yeniden açacaktır.
gronostaj

54

HTTP Content-Lengthüstbilgisi bazı durumlarda isteğe bağlıdır ve bu nedenle dosyayla iletilmeyebilir; Soket kapatıldığında dosyanın sonuna işaret edilir.


1
Kesin olarak, HTTP 1.0 içerik uzunluğunu her belgeden sonra soketi kapatarak tanımladı. Bu hala uyumluluk için HTTP 1.1'de desteklenmektedir. Ancak, HTTP 1.1, Content-Lengthbaşlık alanı kullanılıyorsa veya belge aktarılıyorsa, birden çok belge için bağlantıların yeniden kullanılmasına izin verir Transfer-Encoding: chunked. İkincisi, dinamik olarak içerik oluşturmaya ve oluşturuldukça parçanın sonuna gönderilmesini sağlar ve belgenin sonunu işaret eder.
x4u,

3

İçerik (örneğin bir .pdfbelge veya bir Excel sayfası) anında oluşturulduğunda, boyut önceden bilinemez. Bu durumda, sunucu size indirme işleminin boyutunu gönderemez ve tarayıcı toplam boyutu gösteremez.


9
@alfo katılmıyorum ... eğer video akışı yapıyorsam, ya da sabit boyutlu olmayan herhangi bir veri akışı yapıyor olsam bile, eğer nokta kullanıcıya mümkün olan en hızlı şekilde ulaşmaksa, Transmittali başlattığım noktadaki büyüklüğü bilmeyeceğim
Foon

4
@Alfo Anında .pdfdosyalar gibi veriler oluşturabilirsiniz . Veriler uygun şekilde yazılmadığı sürece, boyutu bilmiyorsunuz ancak atayı zaten tarayıcıya gönderebilirsiniz. Bunu zaten Java'da yaptım ve anında oluşturulan tarayıcıya bir Excel dosyası gönderdim. Tarayıcılar tarafında bir indirme işlemine benziyordu, ancak sunucular tarafında bir yayın. Bu yüzden mümkündür akışı .pdf bu hayal cnnot bile dosyaları. Tarayıcıdan bilinen uzunlukta bir indirme gibi görünüyor.
Uwe Plonus

8
@Alfo - sadece son paket müşteriye gönderilmeden önce oluşturulmasının bitmesi gerekiyor.
GalacticCowboy

4
@Alfo Video buharlama hakkında değil , genel olarak akış hakkında bir şey almadım , bu da bir .pdfdosya veya bir Excel sayfasını da aktarabilir!
Uwe Plonus

2
@Alfo - Geçerli bir noktaya sahipsiniz, dinamik dosyalar tamamen ilk önce bellekte oluşturulabilir ve daha sonra HTTP yoluyla gönderilebilir ve içeriği kolayca hesaplanabilir. Bununla birlikte, sunucu birçok pakete bölünecek dinamik olarak oluşturulmuş birçok büyük dosya gönderiyorsa, sunucunun topakları hesaplandıkları gibi göndermeye başlaması mantıklı olacaktır (aksine her büyük dosyayı bellekte oluşturmak zorunda kaldıktan sonra gönder). HTTP 1.1 , bu amaç için özellikle yığın ötelemeli kodlamayı tasarladı .
dr jimbob
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.