mboost-dp1
Flickr - flyvancity
Det var praktisk sådan bare at kunne lukke det hele et sted. Praktisk for tyraniske ledere.
Enelig meget sjovt at tænke på hvor skrøbligt noget som internettet er. Det er jo næppe noget vi ville være foruden i længere perioder. Men hvis nogle klippede forbindelsen ude på armager fx ville danmark stå i samme situation eller har det ændret sig det med at de hele udlandstrafikken samles i sverige?
Enelig meget sjovt at tænke på hvor skrøbligt noget som internettet er. Det er jo næppe noget vi ville være foruden i længere perioder. Men hvis nogle klippede forbindelsen ude på armager fx ville danmark stå i samme situation eller har det ændret sig det med at de hele udlandstrafikken samles i sverige?
erchni (1) skrev:Enelig meget sjovt at tænke på hvor skrøbligt noget som internettet er.
Især i betragtning af at det oprindeligt var designet til det modsatte.
Det blev jo designet til militær brug, og det var vigtigt ikke at have nogen single point of failure. Smuttede én forbindelse, brugte man bare en anden.
Vi ser dog stadig noget til det. Bla. kan jeg da huske flere gange at en eller anden hovedledning kommer ud af drift, hvor følgen er at nogle bemærker en langsommere forbindelse.
erchni (1) skrev:eller har det ændret sig det med at de hele udlandstrafikken samles i sverige?
Det kommer meget an på den enkelte ISP. Der er både peering gennem DIX, privat peering, transit gennem DIX og lignende, og transit ad andre kanaler både via tyskland og sverige. Større ISPer har typisk flere transitforbindelser ad forskellige veje plus en masse peering.
erchni (1) skrev:
Men hvis nogle klippede forbindelsen ude på armager fx ville danmark stå i samme situation eller har det ændret sig det med at de hele udlandstrafikken samles i sverige?
Jeg mener jeg læste det på DRs teksttv, så man skal tage forbehold for kilden.. Men dansk internet går ikke kun gennem DIX, så selvom regeringen/staten/en-eller-anden-spasser lukker for adgangen til DIX, så vil vi stadig kunne tilgå internettet.
På papiret, ja.myplacedk (3) skrev:Det blev jo designet til militær brug, og det var vigtigt ikke at have nogen single point of failure. Smuttede én forbindelse, brugte man bare en anden.
Dem som rent faktisk udførte implementationen (Universiteterne), designede det ikke på samme måde.
Det andet er en håbløs myte, som åbenbart sidder lidt for godt fast i folks hoveder
For lige at uddybe den med redundans i internettets helt unge dage:
Dengang var datalinjerne langt mere ustabile end de er i dag. Man forventede derfor langt større pakketab og større forstyrrelser end man gør nu. Det var derfor internettet (dengang "ARPANET") blev designet til at kunne modstå tekniske problemer.
En måde vi ser det på er, at endepunkterne er ligeglad med ruten. Faktisk er en router typisk ligeglad med det meste af ruten, og bekymrer sig kun om næste hop. En pakke har en afsender og en modtager, og så må routerne der imellem selv finde ud af hvordan pakken skal nå frem. Dvs. man kan ændre ruten uden at ny opsætning skal skubbes ud til alle "deltagere" på internettet og forbindelser afbrydes. Det ville i øvrigt også være et helvede i dag, med den størrelse internettet har.
En anden ting er TCP's overhead. Når man overfører via TCP (som man stort set altid gør), vil TCP helt automatisk håndtere pakketab. Men det koster lidt ekstra trafik og sådan. Den justerer selv på nogle parametre ud fra forbindelsens kvalitet. Men med nutidens hurtige og stabile forbindelser, står alle knapperne på "max", og standard TCP kan slet ikke udnytte de moderne linjer. Især ikke over LAN. Dette forsøgt man at forbedre ved at indføre mulighed for større vinduer. Ideen er fin nok, men det kan give et helvedes problem hvis ikke alle hop på routen understøtter så stort et vindue.
Hvordan det så håndteres i praksis i dag og hvor godt det går aner jeg ikke. Men hvis jeg skal overføre noget hurtigt over LAN, så går det en hel del hurtigere over UDP end TCP, og det bunder i dette problem.
Dengang var datalinjerne langt mere ustabile end de er i dag. Man forventede derfor langt større pakketab og større forstyrrelser end man gør nu. Det var derfor internettet (dengang "ARPANET") blev designet til at kunne modstå tekniske problemer.
En måde vi ser det på er, at endepunkterne er ligeglad med ruten. Faktisk er en router typisk ligeglad med det meste af ruten, og bekymrer sig kun om næste hop. En pakke har en afsender og en modtager, og så må routerne der imellem selv finde ud af hvordan pakken skal nå frem. Dvs. man kan ændre ruten uden at ny opsætning skal skubbes ud til alle "deltagere" på internettet og forbindelser afbrydes. Det ville i øvrigt også være et helvede i dag, med den størrelse internettet har.
En anden ting er TCP's overhead. Når man overfører via TCP (som man stort set altid gør), vil TCP helt automatisk håndtere pakketab. Men det koster lidt ekstra trafik og sådan. Den justerer selv på nogle parametre ud fra forbindelsens kvalitet. Men med nutidens hurtige og stabile forbindelser, står alle knapperne på "max", og standard TCP kan slet ikke udnytte de moderne linjer. Især ikke over LAN. Dette forsøgt man at forbedre ved at indføre mulighed for større vinduer. Ideen er fin nok, men det kan give et helvedes problem hvis ikke alle hop på routen understøtter så stort et vindue.
Hvordan det så håndteres i praksis i dag og hvor godt det går aner jeg ikke. Men hvis jeg skal overføre noget hurtigt over LAN, så går det en hel del hurtigere over UDP end TCP, og det bunder i dette problem.
terracide (15) skrev:er retareded
Tal for dig selv.
Jeg kan ikke se hvorfor en applikation ikke skulle lave sin egen pakkekontrol, hvis den kan gøre det bedre end TCP.
terracide (15) skrev:Og i at du nok ikke har justeret dine TCP værdier for LAN, men for WAN...
Jeg har ikke justeret min TCP overhovedet. Jeg kan ikke se hvorfor jeg skulle bruge tid på at sætte mig ind i det, når jeg ikke har et problem det kan løse.
Jeg gider ikke engang undersøge om LAN-optimering vil give dårligere internetforbindelse. Det er internetforbindelsen jeg har mest behov for at optimere.
#17
Det er da fuldstændigt irrelevant for denne diskution, hvordan man justerer TCP window scaling osv. på de maskiner jeg bruger. Jeg ved hvad det betyder, og er nok mere kvalificeret til at diskutere det end langt de fleste af dem som har fundet et eller andet GUI, og så justeret tallene indtil tests af en eller anden grund giver et bedre resultat.
Jeg synes det fremgår tydeligt nok af denne tråd at jeg ved noget om det, så jeg kan ikke se hvorfor du skulle skrive #17 hvis ikke det bare er for at være den sædvanlige troll du nu engang er.
Det er da fuldstændigt irrelevant for denne diskution, hvordan man justerer TCP window scaling osv. på de maskiner jeg bruger. Jeg ved hvad det betyder, og er nok mere kvalificeret til at diskutere det end langt de fleste af dem som har fundet et eller andet GUI, og så justeret tallene indtil tests af en eller anden grund giver et bedre resultat.
Jeg synes det fremgår tydeligt nok af denne tråd at jeg ved noget om det, så jeg kan ikke se hvorfor du skulle skrive #17 hvis ikke det bare er for at være den sædvanlige troll du nu engang er.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund