Aziatische websites/downloads traag

[Verwijderd]

Thanks mensen!

[ Voor 109% gewijzigd door Verwijderd op 28-10-2010 22:54 ]

[leuk_he]

Dus je wil weten hoe snel diverse internationale verbindingen zijn en hoe bepaald servers daar op aangesloten zijn?

Hier heb je een link om je in te lezen.

http://navigators.com/isp.html

Zoek dan eens door, vertel wat je gevonden hebt, en stel je vraag dan eens opnieuw.

Ook ligt het eraan wat je provider aan internationale verbindngen geregeld heeft. Dat vertellen ISP niet.

[ Voor 16% gewijzigd door leuk_he op 09-09-2008 17:13 ]

[Verwijderd]

Nee, ik wil weten waarom intercontinentale downloads vaak zo ontzettend traag gaan, terwijl de server in Hong Kong gewoon in een DC staat, en hun de file op volle kracht binnen kunnen halen, terwijl wij het met 200kb/sec moeten doen.

Andersom misschien ook, dat ik de file met mijn volle 25mbits binnen kan halen, en dat hun (aan de andere kant van de aarde) het met 200-300kb/sec moeten doen. Alsof het ergens gecapt word ofzo... Iniedergeval wil ik weten hoe dat nou zit met die snelheidsbeperking, waarom je files die aan de andere kans van de wereld staan niet met je volle 25mbits kan binnenhalen.

Zo ook met websites... Ik ga naar een Amerikaanse website, en het laden van zo'n website duurt wel minstens een seconde of 5-6, terwijl een andere Amerikaanse website hem vrijwel direct heeft geladen, terwijl ze geografisch op het zelfde plek bevinden. (ook zelfde content) Terwijl ik bij bewijs van spreken die file met 100 kb/sec binnen haal, en het gevoel krijg dat er iets mis is met die verbinding/ server, hebben die anderen helemaal geen problemen met die website, en kunnen ze fullspeed files daarvan downloaden.

[ Voor 30% gewijzigd door Verwijderd op 09-09-2008 19:10 ]

[krvabo]

Zo lastig is het toch niet?

Pinging bandai.co.jp [202.95.216.44] with 32 bytes of data:

Reply from 202.95.216.44: bytes=32 time=321ms TTL=47
Reply from 202.95.216.44: bytes=32 time=323ms TTL=47
Reply from 202.95.216.44: bytes=32 time=323ms TTL=47
Reply from 202.95.216.44: bytes=32 time=323ms TTL=47

(concepts-ict)
300ms heen, 300ms terug. Tegen de tijd dat de server "ja ik heb het ontvangen" ("ack") heeft gezien en het volgende packet verstuurd ben je dus al 0.6s verder.
Elke server heeft een max aantal connecties / requests tegelijk (zeg bijv 10) en een bestand heeft al snel heel wat meer packets dan de server aan requests toestaat.
Zo moet dus de server wachten tot de client aangeeft dat het volgende packet mag worden verstuurd, en de client moet wachten tot de server daadwerkelijk gaat sturen.

[Vunzz]

Jouw ISP is met een gigabitverbinding of wellicht nog sneller direct op de verschillende datacenters is Amsterdam aangesloten. Om data uit Hong Kong te downloaden moet die data eerst door een paarduizend kilometer aan kabel over de bodem van de oceaan. Daar is allicht wat minder bandbreedte.

@krvabo: dat heeft echt helemaal nergens mee te maken. Dan kan je beter een tracert doen, dan zie je dat het eerst nog via de VS gaat.

[ Voor 19% gewijzigd door Vunzz op 09-09-2008 19:06 ]

[krvabo]

Vunzz schreef op dinsdag 09 september 2008 @ 19:03:
@krvabo: dat heeft echt helemaal nergens mee te maken. Dan kan je beter een tracert doen, dan zie je dat het eerst nog via de VS gaat.

Natuurlijk heeft dat wel ergens mee te maken. Die zeekabels hebben echt niet "weinig" bandbreedte, het duurt gewoon lang voordat het pakketje aankomt (door zoals je zegt: de lengte (en aantal hops)).
De nieuwe onderzeekabel met India krijgt bijna 4Tb aan throughput per seconde.

Hoe je erbij komt dat de ping niets te maken heeft met de doorvoersnelheid..

[Vunzz]

Omdat de server niet pas het volgende pakketje gaat versturen als hij weet dat het vorige is aangekomen.

[AndriesLouw]

Dat zou inderdaad absurd zijn, volgens mij is het downloaden van een file net zoiets als streamen, ze verzenden de data in 1 keer. Ik zou gek worden als een download server continu pakketjes ontvangt met "zend de volgende maar".

Edit: Daarbij, als je download op een gedeelte failt (internet klappert) met bijvoorbeeld een host zoals Rapidshare, dan kun je de download niet hervatten op een punt, je moet hem helemaal opnieuw starten. Dit kun je op andere servers wel, je browser / downloadmanager verzend gewoon vanaf welk punt hij de data wil ontvangen in zijn Request-Header. Zo kan ik een file pauzeren, en dan weer starten. Dat gaat dus volgens mij niet op packet-level.

[ Voor 49% gewijzigd door AndriesLouw op 09-09-2008 19:24 ]

[Verwijderd]

Maar zo gaat het al jaren _{een andere techniek stuurt gewoon domweg alles door.}

Je hebt gewoon een lange afstand te overbruggen door tig hopjes, en niet elk hopje is evensnel.

[DukeBox]

AndriesLouw schreef op dinsdag 09 september 2008 @ 19:21:
Dat zou inderdaad absurd zijn, volgens mij is het downloaden van een file net zoiets als streamen, ze verzenden de data in 1 keer. Ik zou gek worden als een download server continu pakketjes ontvangt met "zend de volgende maar".

Dat hangt natuurlijk van het protocol af, alleen al het verschil tussen udp en tcp heb je al... het is net wat voor waardje je geeft aan de betrouwbaarheid en of je al wat hebt aan patiële data.

Overigens kun je met een mpls netwerk garanties krijgen over latency e.d. maar meestal kun je al meer winnen met waas/riverbed e.d. oplossingen.

[ Voor 12% gewijzigd door DukeBox op 09-09-2008 19:26 ]

[leuk_he]

Vunzz schreef op dinsdag 09 september 2008 @ 19:17:
Omdat de server niet pas het volgende pakketje gaat versturen als hij weet dat het vorige is aangekomen.

Download gaan via tcp. tcp stuurt eerst een buffer door totdat hij dat er een ack komt.

wellicht kun je hier starten: Wikipedia: TCP window scale option

helaas zijn de windowoptions packets niet goed beschikbaar in windows, dus je kunt er niet goed aan optimaliseren. (ja er zijn vista api's, maar dan wordt je eer incompatible met xp )

[Verwijderd]

http://www.jal.co.jp Ik vroeg me altijd af of dat nou aan die server daar ligt, of aan hier. Want dit is één van die sites die hier totaal ruk lopen.

[ Voor 40% gewijzigd door Verwijderd op 15-02-2010 21:42 ]

[Vunzz]

Doe maar eens

tracert www.jal.co.jp

en dan

tracert tweakers.net

[Verwijderd]

Vunzz schreef op dinsdag 09 september 2008 @ 22:51:
Doe maar eens

[...]

en dan

[...]

Dat ken ik wel, maar die link mag wel veel meer hops hebben dan tw, en geografisch ver weg liggen, wat overigens logisch is voor het aantal hops, maar waarom is die snelheid dan zo beperkt, en hoe word dat dan bepaald? Want ik ken zelf ook websites die behoorlijke hops hebben, maar wel behoorlijk hoog scoren als het gaat om downloadsnelheid. Toen ik zelf voor enkele weken aan de andere kant van de wereld verbleef heb ik gewoon perfect en behoorlijk snel wat files van mijn server kunnen downloaden.

Als een bedrijf zijn servers bijvoorbeeld in China staat, en wil ook dat klanten in usa hun website optimaal kunnen bereiken, files, drivers downloaden etc. Wat kan een website/hoster dan doen om zo optimaal mogelijk bereikbaar te zijn voor internationale connecties? Natuurlijk is CDN een mogelijkheid maar dat kost dan weer een hoop poen.

[ Voor 20% gewijzigd door Verwijderd op 09-09-2008 23:18 ]

[Vunzz]

Het gaat er in dit geval met name om dat er in Japan een stuk of wat hele trage hops na elkaar zitten.

[alienfruit]

Je kan overwegen om een VPN op te zetten met die server -- dan kan het sneller gaan. Als ik namelijk zonder VPN verbinding maak met mijn server in Auckland dan haal ik maar max. 30-90kb/s. Terwijl het als ik verbonden via en Cisco VPN verbinding toch 4-5x sneller gaat. Blijkbaar is dan de routing beter

[ Voor 27% gewijzigd door alienfruit op 10-09-2008 10:53 ]

[Verwijderd]

Wat is het voordeel van VPN dan, behalve dat het een beveiligde verbinding is? Want wat maakt VPN dan sneller op het gebied van uploads en downloads?

[ Voor 60% gewijzigd door Verwijderd op 13-09-2008 10:44 ]