problem z pobieraniem plikow

[Raffuss 4]

Witam, zapytam tutaj bo rozmowa z technikami doprowadzi mnie zaraz do białej gorączki.Posiadam konto shared w 1and1.com i od 2ch tygodni mam problem z pobieraniem plików z tego konta, za pośrednictwem przeglądarki. Z początku myślałem iż to wina mojego ISP ale nie.. znajomi z różnych części Europy również zaczeli się uskarżać na ten problem. Najczęściej pobiera paręnaście-parędziesiąt procent i pobieranie się zatrzymuje.Z kolei z konta znajomego w tym samym DC, problem nie występuje. Pisałem już do techników, ale oni odpisują takie bzdury że już mi ręce opadają.. a najgorsze że idą w zaparte iż to wina mojego ISP właśnie.. skąd w takim razie problem u reszty ludzi w Europie i dlaczego tylko na moim koncie? Na to mi już nie potrafią odpowiedzieć. Może się ktoś już spotkał z podobnym problemem na serwerze?

[patryk 451]

1&1 uprawia poważny outsourcing supportu (Indie), więc mogą być poważne problemy z naprawą czegokolwiek jeśli już sie uprą, że działa i to Twoja wina..

[Raffuss 4]

A czym może byc taki błąd spowodowany? 

[Raffuss 4]

Dobra przeniosłem pliki do neteasy i co..? i dalej to samo.. jakaś zupełna wypadkowa od tego samego ISP. Jednym pobiera, a innym nie.. Proszę, czy ktoś ma pojęcie czemu tak się może dziać..? Bo ja już zgłupiałem do reszty..

[kafi 2425]

Badziewny dostawca internetu, któremu "przypadkiem" rwą się w trakcie połączenia?

Zapuść traceroute/mtr do swojej strony od tych problematycznych osób, którym pliki nie są ściągane poprawnie i wynik umieść na forum.

 

 

PS: Nie robisz przypadkiem downloadu plików via PHP?

[Raffuss 4]

PS: Nie robisz przypadkiem downloadu plików via PHP?

Miałem przez PHP, ale wymieniłem na adresy bezpośrednie do plików.. nie idzie.. Ciężko też namówić tyle osób (aktualnie mam już ponad 200 zgłoszeń) z Polski i Europy żeby tracert zrobiły, skoro większości nawet nie mam jak wytłumaczyć i nie mam do nich kontaktu.. :/

Neo: u jednych działa u innych nie..

upc: j/w

 

O tych wiem z terenu PL.

Kto jest dostawcą internetu osób z Niemiec, Holandii czy UK nie mam pojęcia..

 

A tak ładnie wszystko działało przez pół roku i nagle z dnia na dzień się posypało.. :/ 

[kafi 2425]

Podaj adres strony i rozmiar plików, które serwujesz.

 

A przyczyn może być kilka. Główne to - uaktywniona kompresja GZip dla zawartości, przez co niepoprawnie obsługiwane jest przez niektóre przeglądarki Content-Length;

Może być po prostu restart Apache;

I może być też kilka innych, mniejszych problemików.

[Raffuss 4]

http://play.losiowisko.com/LOS_2009_04_08.mp3 prosze taki np adres bezpośredni, który wyskakuje również w kanale RSS.. Opera sobie radzi.. mozilla już nie.. (stan z moich komputerów w domu)

 

Pliki mają po 20-40mb a docelowo miały być jeszcze większe .flv

[p 3]

http://play.losiowisko.com/LOS_2009_04_08.mp3 prosze taki np adres bezpośredni, który wyskakuje również w kanale RSS.. Opera sobie radzi.. mozilla już nie.. (stan z moich komputerów w domu)

 

Pliki mają po 20-40mb a docelowo miały być jeszcze większe .flv

To raczej kwestia przypadku. Tak jak napisał Fiercio, możliwe, że wina leży po stronie serwera www, który gzip'uje Twoje pliki (a co za tym idzie, nie wysyła w nagłówkach ich rozmiaru). Dołożysz do tego częste reloady / restarty serwera www w hostingu współdzielonym i przeglądarce "wydaje się", że wszystko ściągnęła...

Z drugiej strony gdyby to faktycznie było przyczyną to skarżyłoby się więcej osób

[Raffuss 4]

Aktualnie jak pisałem strona i pliki leżą w neteasy.. w UK.

Co się tyczy ilości osób to tej strony nie odwiedza więcej niż 300-400 w miesiącu..

 

Pytanie teraz co z tym fantem zrobić, ażeby tak się nie działo.. 

[p 3]

Pytanie teraz co z tym fantem zrobić, ażeby tak się nie działo.. 

Zastanowiłem się chwilkę nad tym problemem i o ile nie chciałbym krytykować konfiguracji patryka (i być może nie tylko jego), to niestesty muszę napisać, że gzip'owanie wszystkiego jak leci to głupota.

 

Kompresowanie już skompresowanych danych oznacza:

1) Brak nagłówka Content-Length:,

2) Niepotrzebne obciążanie procesora,

3) Praktyczny brak zysków (skompresowane dane nie lubią się kompresować ).

 

$ ls -l test*
-rw-------  1 p users	 76713 12 kwi 18:28 test.html
-rw-------  1 p users   2809000 12 kwi 18:28 test.jpg
-rw-------  1 p users  12955817 12 kwi 18:09 test.mp3
-rw-------  1 p users  22650899 12 kwi 18:09 test.wmv

$ time gzip test*
real	0m8.236s
user	0m6.444s
sys	 0m0.558s

$ ls -l test*
-rw-------  1 p users	 11751 12 kwi 18:28 test.html.gz
-rw-------  1 p users   2808058 12 kwi 18:28 test.jpg.gz
-rw-------  1 p users  12918996 12 kwi 18:09 test.mp3.gz
-rw-------  1 p users  22273973 12 kwi 18:09 test.wmv.gz

Czy wyłączenie gzip'owania .mp3 pomoże w Twoim przypadku? Nie mam pojęcia

[patryk 451]

p: jak mogłeś mnie o coś takiego podejrzewać.. Dzięki za zwrócenie uwagi - wygląda na to, ze na tym serwerze z regułki anty-deflate w której sa oczywiscie zipy, rary itd wyleciało chyba przy okazji jakiś update'ów mp3.

 

Poprawiłem już to i może to rozwiąże problem, ale generalnie spotkałem się pierwszy raz z takimi cudami i w żaden sposób nie mogłem ich "powtórzyć" bo mimo użycia najgorszych możliwych łącz w typie iPlusa zawsze pliki szły i jedyne co przyszło mi na myśl to to, że wina leży po stronie Chello, które ruch do tego serwera w UK pcha przez Nowy Jork jak ma gorszy dzień..

[p 3]

Poprawiłem już to i może to rozwiąże problem, ale generalnie spotkałem się pierwszy raz z takimi cudami i w żaden sposób nie mogłem ich "powtórzyć"

Zobaczymy, sam jestem ciekawy Chociaż podobnie jak Tobie, nie udało mi się doprowadzić do opisywanej przez Raffuss'a sytuacji...

[Raffuss 4]

jedyne co przyszło mi na myśl to to, że wina leży po stronie Chello, które ruch do tego serwera w UK pcha przez Nowy Jork jak ma gorszy dzień..

Chello to chello ale co np z neo..? Koleżanka w Gdańsku mieszkająca np nie mogła żadnego z plików pobrać przez swoją neostradę i ff, gdzie kolega ze starogardu gdańskiego, także mającego neo problemów nie miał. W TP także mają ruch przez NY? tak już troszkę żartem, ponieważ w tym wypadku mam tyle różnych zgłoszeń, iż nie mogę nawet gdybym chciał winić jednego ISP.

 

 

Swoją drogą poprzednio owe pliki siedziały w Pensylvanii i jak już wspominałem wszystko działało wręcz perfecyjnie do połowy lutego tego roku. Wtedy zaczęły się problemy dosłownie z dnia na dzień..

 

btw Patryk własnie sprawdziłem pobieranie przez FF, z czym był wcześniej duży problem u mnie. Jak na razie przynajmniej, problemów nie dostrzegam. Zobaczymy co u innych w okolicach środy - czwartku. W razie czego dam znać. Dziękuję za pomoc.. 

[kafi 2425]

Pytałem wcześniej o przesyłanie plików przez PHP.

Zarówno ono, jak i kompresowanie GZip ma dwie zasadnicze cechy

1) Nie jest odsyłany Content-Length

2) Kompresja robiona jest w locie

 

W związku z tym serwer nie ma dostępu bezpośredniego do całego pliku.

Jakikolwiek refuse (problem jakiegoś routera gubiącego pakiety, lub chociażby reload/restart Apache) powoduje zerwanie połączenia.

Klient HTTP próbuje wtedy wysłać requesta o partial-content, gdzie (i tu już zależy od konfiguracji httpd):

1) jeśli to jest parsowane przez PHP, to serwer odpowiada kodem 200 (bo czemu nie) i odpala skrypt php, który głupieje

2) jeśli to standardowa zawartość z nałożonym deflate to:

2.1) może zaserwować po prostu nie-gzipowany partial-content

2.2) może zaserwować 200-OK, po czym zacząć kompresować gzipa i wysyłać na wyjście całość - wtedy browser się buntuje, albo (jak jest głupi) to dokleja całość na koniec

2.3) może zaserwować 200, kompresować, a wypluwać dopiero jak dojdzie do danego offsetu - i tu jest przykład lekkiej "zawieszki" - a jeśli dojdzie kolejny refuse to tak w kółko

2.4) może odmówić kodem 400-Bad Request albo informacją, że serwer nie wspiera partial-contentów (wtedy klient zasysa całość od nowa)

 

A inni się nie skarżą pewnie dlatego, że patryk napisał, że rary, zipy itp. są wykluczone z deflate... więc narażone były na ten efekt tylko "media".

A poza tym widać to raczej przy dużych (>1MB) plikach.