Hi,
Am Don, 27 Apr 2000 schrieb Carsten Meyer:
Gibt übrigens kaum noch Provider mit Proxy-Zwang, oder?
Doch, haufenweise, nur kriegst Du davon nichts mit, weil die transparente Proxys einsetzen.
Ist was gegen Proxys einzuwenden? Also, ich muss sagen, dass sich lokale Proxies zB WWWoffle richtig lohnen können, in vielen Fällen. Richtig lustig wirds wenn ein Proxy auf einen anderen zugreift *g* Kann man eigentlich (mit traceroute oder so) Proxywege verfolgen? Würde mich mal interessieren...
DH
ciao Stephan Beyer -- Stephan Beyer http://lightning.prohosting.com/~sbeyer/ mailto:PH-Linex@gmx.net --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Am Don, 01 Jan 1970 schrieb Stephan Beyer:
Ist was gegen Proxys einzuwenden?
Nö, hat mein posting den Anschein erweckt? Nur falsch konfigurierte Proxys können nerven. Aktualität ist ja wohl kein Thema mehr, da dynamisch erzeugte Seiten sowieso nicht gecached werden sollten. (Siehe Konfiguration)
Also, ich muss sagen, dass sich lokale Proxies zB WWWoffle richtig lohnen können, in vielen Fällen. Richtig lustig wirds wenn ein Proxy auf einen anderen zugreift *g*
Mir reicht Junkbuster.
Kann man eigentlich (mit traceroute oder so) Proxywege verfolgen? Würde mich mal interessieren...
Nein, IMHO laufen ICMP-Pakete nicht über Proxys. DH --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Stephan Beyer wrote on Sat, Apr 29, 2000 at 23:40 +0000:
Ist was gegen Proxys einzuwenden?
Wenn wir beim Thema sind, hier Auszug aus einer Mail vom Fri, 13 Aug 1999 22:39:09 +0200 (MEST) an proxyadm@bln2-tux.atm-bb.de wegen: Subject: transparent proxy for mobilcom: Proxy bremst Geschwindigkeit auf ein VIERZIGSTEL (1/40)
Leider bremst der Transparent Proxy "bln2-tux.atm-bb.de" (port 80) unheimlich. Fahre ich auf einem WWW-Server dieselben Seiten auf port 80 und einem andereren, so ist dieser andere Port != 80 sehr schnell (habe ping-zeiten um die 60 ms), der "normale" jedoch gaehnend lahm. [...] Das laden vom 2. Port dauert so z.B. einer bestimmten Seite 2 Sekunden, ueber der Zwangsproxy 1:25, also 85 Sekunden, ein Bremsfaktor von unglaublichen 4250% !!!! Das geht so nicht! (gemessen: Fri Aug 13 22:33:25 MEST 1999)
Das blieb (erstmal?) so, und ich verabschiedete mich von Mogelcom. Leider waren die auch noch bei ein paar Kunden als Dialup ISPs eingestellt (diese Kunden hatten sich über unseren langsamen WWW-Server beschwert). Dumm gelaufen. Weiß nicht, ob sich da was geändert hat... Bei T-Online habe ich auch manchmal beobachtet, daß mit Proxy weniger als 7KB/sec kamen (ISDN), ohne jedoch der B Kanal ausgelastet wurde. Dann wird ein Proxy zum Nadelöhr...
Also, ich muss sagen, dass sich lokale Proxies zB WWWoffle richtig lohnen können, in vielen Fällen.
Yepp, finde ich auch. Allerdings verwende ich ausschließlich squid. Besonders schick ist, daß ein Download weitergeht, wenn die Workstation abstürzt (da ist mal ne NT Kiste bei 99% eines 60MB Downloades über schleppende ISDN Leitung abgeklatsch. Neu gebootet, und das File mit 800KB/sec geholt :)).
Richtig lustig wirds wenn ein Proxy auf einen anderen zugreift *g*
Na, so ne Proxy-Chain kann ganz schön bremsen. Parallele, die über ICP kommunizieren gehen ganz gut. Die Addressen von diesen kann man dann für den selben Namen im DNS eintragen (Round robbing), falls man ne ganz dicke Leitung (>E3) hat. Dazu gibt's übrigens ein interessantes Projekt im Zusammenhang mit Squid. Auch das DFN hat (versucht?) in der Richtung was zu machen. Im BRAIN (Berliner Hochschulnetz) fragt z.B. auch TU Berlin die TFH Berlin usw. Bei ATM macht das Spaß :)
Kann man eigentlich (mit traceroute oder so) Proxywege verfolgen?
Na, mit traceroute selbstverständlich überhaupt nicht, da dieses auf IP Ebene ansetzt, und nur bis zur ersten Applikation Wege aufzeigen kann, d.h. bis zum ersten Proxy. Man kann mit ein paar Tricks versuchen, ein bißchen was rauszukriegen. Manche Proxy hinterlassen auch Infos im HTTP Header. Proxies (z.B. der Mobilcom Transparent Proxy) fallen auf, wenn fehlerhaft URLs angefordert werden, und generieren einen Fehler. Parenting (Caches, die Caches fragen) sollte man allerdings kaum sehen können, bei neighbors (also parallelen Caches) fällt mir auch nix ein... Nee, glaube, normalerweise sollte man vom zweiten Proxies nichts sehen. Den letzen kann man erkennen, wenn man im Serverlog eines WWW-Servers mal nachschaut, welche IP die Seite eigentlich geholt hat. Aber was dazwischen passiert? Wer mehr als zwei Proxies kaskadiert, weiß entweder, was er tun muß (z.B. Firewall etc.), oder macht was falsch ;) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Steffen Dettmer schrieb in 3,5K (84 Zeilen):
Yepp, finde ich auch. Allerdings verwende ich ausschließlich squid. Besonders schick ist, daß ein Download weitergeht, wenn die Workstation abstürzt (da ist mal ne NT Kiste bei 99% eines
Was fuer wwwoffle auch kein Problem darstellt.
Na, so ne Proxy-Chain kann ganz schön bremsen.
Oft machen Chains Sinn. PEER PEER \ / \ / Lokale -- PROXY-1 --duenne--> PROXY-0 ===teuere===> Server User Leitung | Leitung mit | Browser-Cache PEER Dann lass noch eine Arbeitsgruppe via Dial-Up an Proxy-1 haengen (sie brauchen die internen Webseiten) und spendier denen auch nochmal einen Proxy (weil's Sinn macht) ...
Dazu gibt's übrigens ein interessantes Projekt im Zusammenhang mit Squid. Auch das DFN hat (versucht?) in der Richtung was zu machen. Im BRAIN (Berliner Hochschulnetz) fragt z.B. auch TU Berlin die TFH Berlin usw. Bei ATM macht das Spaß :)
Die Uni Koeln reduziert den Traffic um ca 50% durch Proxy0 und 5-10% durch andere Unis & co (Peers), so dass die teueren Amerika-Connections seltener sind. Proxy1 waere dann die FH-Koeln.
Man kann mit ein paar Tricks versuchen, ein bißchen was rauszukriegen.
Ring! Rrring! "NetzwerkCenter XY, $NAME, Guddn Dach?" "Hallo, hier ist $NAME2. Ich haett gern ma jewusst, ob sie einen ParentProxy haben und welche Peers sie benutzen ..." -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Wolfgang Weisselberg wrote on Sun, Apr 30, 2000 at 15:16 +0200:
Steffen Dettmer schrieb in 3,5K (84 Zeilen):
Yepp, finde ich auch. Allerdings verwende ich ausschließlich squid. Besonders schick ist, daß ein Download weitergeht, wenn die Workstation abstürzt (da ist mal ne NT Kiste bei 99% eines
Was fuer wwwoffle auch kein Problem darstellt.
Ja, hab ich auch nicht behauptet ;)
Na, so ne Proxy-Chain kann ganz schön bremsen.
Oft machen Chains Sinn.
Klar. Begrenzt, z.B. nach dünner Leitung. z.B. "sichere" Seite einer Firewall. In einer DMZ. Hat man einen Firewall-Proxy, der einen Cache hinter einem Virenscanner in der DMZ fragt, was dann noch zweimal im sicheren Netz gecacht wird, dauert ein CGI Output schon ganz schön lange ;)
Dann lass noch eine Arbeitsgruppe via Dial-Up an Proxy-1 haengen
Ja, ich sagte ja, es gibt Leute, die wissen, was sie tun ;)
Die Uni Koeln reduziert den Traffic um ca 50% durch Proxy0 und 5-10% durch andere Unis & co (Peers), so dass die teueren Amerika-Connections seltener sind.
Hatte ich an der TFH auch, so bis zu 50%. Das mit den anderen Unis ist aber (zumindestens bei TFH, TU, HU AFAIK) ne Absprache zwischen den Unis, was nix dem dem DFN Projekt zu tun hat. Damals habe ich mich aber nicht weiter drum gekümmert, weil ich nicht einsah, so einen "Aufriß" zumachen, um dem DFN Kosten zu sparen, und im Berliner Cachenetz soweiso schon fast alles irgentwo rumlag ;) Und wie Du schon sagtest, haben die Peerhits einen relativ kleinen Anteil.
Man kann mit ein paar Tricks versuchen, ein bißchen was rauszukriegen.
Ring! Rrring! "NetzwerkCenter XY, $NAME, Guddn Dach?" "Hallo, hier ist $NAME2. Ich haett gern ma jewusst, ob sie einen ParentProxy haben und welche Peers sie benutzen ..."
Mag sein, daß das in Köln geht :) Habe da andere Sachen erlebt: "More than 95% are ICP_DENY, disabling sibling.", weil die IP Addresse in der ACL einfach nicht (nach vielfacher Aufforderung) ändern wollten. Namen einzutragen war nicht gewollt (dann hätte ja ein restart gereicht). Oder: Ring!! "Könnten Sie $PROXY mal bitte in Ihrer ACL wie folgt korrigieren $OLD->$NEW?" - "Nee, sorry, hat mal ein Student konfiguriert, der ist nicht mehr da, und so..." :) Schade :) Aber das ist jetzt wohl ein bissel OT ;) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Steffen Dettmer schrieb in 2,5K (72 Zeilen):
* Wolfgang Weisselberg wrote on Sun, Apr 30, 2000 at 15:16 +0200:
Hat man einen Firewall-Proxy, der einen Cache hinter einem Virenscanner in der DMZ fragt, was dann noch zweimal im sicheren Netz gecacht wird, dauert ein CGI Output schon ganz schön lange ;)
Virenscanner? Wozu? java(script) aus und gut is. :-) Und die caches sind nicht die Geschwindigkeitsbremsen. (vor allem, wo CGI oft selber langsam ist, du den 'ich fang nix'-Scanner dazwischen hast und dynamischer Content in der Regel eh ein "do not cache" hat).
Die Uni Koeln reduziert den Traffic um ca 50% durch Proxy0 und 5-10% durch andere Unis & co (Peers), so dass die teueren Amerika-Connections seltener sind.
Damals habe ich mich aber nicht weiter drum gekümmert, weil ich nicht einsah, so einen "Aufriß" zumachen, um dem DFN Kosten zu sparen,
Bei Kosten in der Groessenordnung von 0.5+ Mio DM/Jahr (der Uni Koeln) trotz Cache ist das schon mehr als nur ein paar Ueberlegungen wert. Und das DFN wird von den Nutzern (i.e. den Unis) bezahlt.
rumlag ;) Und wie Du schon sagtest, haben die Peerhits einen relativ kleinen Anteil.
50TDM/Jahr ist nicht zu verachten.
Ring!! "Könnten Sie $PROXY mal bitte in Ihrer ACL wie folgt korrigieren $OLD->$NEW?" - "Nee, sorry, hat mal ein Student konfiguriert, der ist nicht mehr da, und so..." :) Schade :)
Siehst du, deshalb sind die 50 TDM wichtig. Fuer den Studenten :-) -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Wolfgang Weisselberg wrote on Tue, May 02, 2000 at 10:39 +0200:
Steffen Dettmer schrieb in 2,5K (72 Zeilen):
* Wolfgang Weisselberg wrote on Sun, Apr 30, 2000 at 15:16 +0200:
[DMZ, Proxy Kaskade]
... dauert ein CGI Output schon ganz schön lange ;)
Virenscanner? Wozu? java(script) aus und gut is. :-)
:) Ja, es gibt auch Moorhuhn-Pattern für gängige Scanner, auch wichtig :)
Und die caches sind nicht die Geschwindigkeitsbremsen.
Bei SSL und CGI funktioniert Cacheing ja nu nicht, also etwas langsamer. Virenscanner bremsen schon richtig, klar. Aber eine lahme Leitung wird zumindestens nicht viel langsamer, schnelle jedoch IMHO schon. (Reden wir eigentlich über Proxies für zu Hause oder für "richtige" Netze?)
Regel eh ein "do not cache" hat).
Angeblich macht NetObjects auch so ein Mist, mit jeweils neuen URLs.
Damals habe ich mich aber nicht weiter drum gekümmert, weil ich nicht einsah, so einen "Aufriß" zumachen, um dem DFN Kosten zu sparen,
Bei Kosten in der Groessenordnung von 0.5+ Mio DM/Jahr (der Uni Koeln) trotz Cache ist das schon mehr als nur ein paar Ueberlegungen wert. Und das DFN wird von den Nutzern (i.e. den Unis) bezahlt.
AFIAK bezahlte ne Uni den Traffic zum/vom DFN. Egal, ob der zum Cache geht oder nicht. Dadurch spart das DFN aber Geld (und Bandbreite), sollte also versuchen, die Unis zu überzeugen, neben eigenen Caches auch die vom DFN mitzubenutzen (Neighbor-Idee, Cache Intrafstruktur), aber das passiert ja nicht (oder nicht richtig?). Außerdem möchte ich nicht wissen, wieviel Geld im DFN verbrannt wird...
rumlag ;) Und wie Du schon sagtest, haben die Peerhits einen relativ kleinen Anteil.
50TDM/Jahr ist nicht zu verachten.
Bezahlt ne Uni so aber trozdem! Das meinte ich ja. Der Traffic zum DFN Cache muß bezahlt werden. Deshalb eigenen Caches. Würde man sibling mit den DFN-Caches machen, zahlt man dann sogar für die Daten, die der DFN-Proxie vom lokalen holt (und ICP natürlich).
Siehst du, deshalb sind die 50 TDM wichtig. Fuer den Studenten :-)
Ja, bloß da kommt ja nu gar nix an. Wenn man sich nur "blöd" genug anstellt, verbrennt viel viel mehr Kohle. Über 50K kann man da nur müde ablachen. Ein Problem scheint zu sein, daß das DNF fast schon ne Behörde ist :) Nee, komisch, aber das hab ich nie verstanden, wie das laufen soll... Aber wir kommen OT :) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Steffen Dettmer schrieb in 2,6K (78 Zeilen):
Bei SSL und CGI funktioniert Cacheing ja nu nicht, also etwas langsamer.
Unsinn. Caching funktioniert schon bei CGI, es sei denn, im Header steht ein entsprechender Hinweis an die Caches. Und die Caches koennen sich dann aussuchen, wie sie die Haltbarkeit selber regeln wollen. :-) Und bei SSL kannst du auch cachen. Ob das gut ist? Andere Frage.
Virenscanner bremsen schon richtig, klar. Aber eine lahme Leitung wird zumindestens nicht viel langsamer, schnelle jedoch IMHO schon. (Reden wir eigentlich über Proxies für zu Hause oder für "richtige" Netze?)
Reden wir jetzt ueber Bandwith oder Latency? *Du* redest ueber Latency, aber du sagst es so, als waere es Bandbreite. Das ist wie ein Politiker vor der Wahl. :-/ Schliesslich wird pro $Zeiteinheit (bei vernuenftigem Ausbau der Caches) genausoviel an Bytes ruebergeschoben. Nur dauert es beim einzelnen Luser halt 0.1-0.2 sec pro Verbindung mehr bei non-cached (und 5 sec weniger bei hits).
AFIAK bezahlte ne Uni den Traffic zum/vom DFN.
Unter Anderem. Der DFN muss ja selber auch zahlen. (Ist ja ein Verein, um die Forschungsinstitute (also gerade auch Unis) zu verbinden.) Das wird dann selbst im einfachsten Fall volumenmaessig auf die Teilnehmer umgelegt. Wenn also (fast) alle weniger teuere USA-Verbindungen machen und dafuer mehr billigere inner-DFN-Verbindungen macht, sinken die Gesamtkosten des DFN, und damit auch die Kosten pro Byte.
Egal, ob der zum Cache geht oder nicht.
Preise werden erst am Ende des Jahres festgelegt.
rumlag ;) Und wie Du schon sagtest, haben die Peerhits einen relativ kleinen Anteil.
50TDM/Jahr ist nicht zu verachten.
Bezahlt ne Uni so aber trozdem!
Jain. IIRC wird nicht nur rein nach Volumen gerechtet, sondern auch wohin geroutet wird. Da sind's dann halt 30TDM statt 70TDM. -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Wolfgang Weisselberg wrote on Sat, May 06, 2000 at 01:53 +0200:
Steffen Dettmer schrieb in 2,6K (78 Zeilen):
Bei SSL und CGI funktioniert Cacheing ja nu nicht, also etwas langsamer.
Unsinn. Caching funktioniert schon bei CGI, es sei denn, im Header steht ein entsprechender Hinweis an die Caches.
Na, was ist dabei z.B. mit Cookies? Damit gäbe es dann Probleme, deshalb wird sowas i.d.R. nur vom Browser gecacht, und Paramteraufrufe sollte man laut Empfehlung auch nicht cachen.
Und bei SSL kannst du auch cachen. Ob das gut ist? Andere Frage.
Wie denn bitte?
Virenscanner bremsen schon richtig, klar. Aber eine lahme Leitung wird zumindestens nicht viel langsamer, schnelle jedoch IMHO schon. (Reden wir eigentlich über Proxies für zu Hause oder für "richtige" Netze?)
Reden wir jetzt ueber Bandwith oder Latency? *Du* redest ueber Latency, aber du sagst es so, als waere es Bandbreite.
Der Datendurchsatz wird durch einen Virenscanner herabgesetzt, es sei denn, er ist verdammt schnell, also richtig verdammt mega schnell.
Das ist wie ein Politiker vor der Wahl. :-/
Das ist irgentwie unsachlich...
Schliesslich wird pro $Zeiteinheit (bei vernuenftigem Ausbau der Caches) genausoviel an Bytes ruebergeschoben. Nur dauert es beim einzelnen Luser halt 0.1-0.2 sec pro Verbindung mehr
Womit scannst Du eigentlich?
AFIAK bezahlte ne Uni den Traffic zum/vom DFN.
Unter Anderem. Der DFN muss ja selber auch zahlen.
Nicht, wenn ein DFN Cache gefragt wird, weil der Traffic im DFN Netz bleibt. Dadurch würde das DFN (nicht die Uni) Geld sparen. Das DFN zahlt dann nur, wenn es kein Cache Hit war. Ergo etwas weniger. Damit sollte das DFN daran interessiert sein. Allerdings kann das DFN natürlich nur sehr schlecht mit einem kommerziellen Anbieter verglichen werden.
Das wird dann selbst im einfachsten Fall volumenmaessig auf die Teilnehmer umgelegt. Wenn also (fast) alle weniger teuere USA-Verbindungen machen und dafuer mehr billigere inner-DFN-Verbindungen macht, sinken die Gesamtkosten des DFN, und damit auch die Kosten pro Byte.
Sicher? Ich habe gehört, daß DFN berechnet per MB/GB unabhängig von der Zieladdresse, d.h. uni-uni in Deutschland genauso teuer für die Unis wie Transatlantik. Kann sich aber inzwischen geändert haben. Was kostet eigentlich ein Gig beim DFN in etwa?
50TDM/Jahr ist nicht zu verachten.
Bezahlt ne Uni so aber trozdem!
Jain. IIRC wird nicht nur rein nach Volumen gerechtet, sondern auch wohin geroutet wird. Da sind's dann halt 30TDM statt 70TDM.
Na, wenn das so ist (ich habs auch nur aus dritter Hand gehört), dann wäre es ok. Bleibt aber dabei, für's DFN wäre es IMHO gut, Proxy-Verwendung zu fördern. Na, DFN ist ja auch schon fast ne Behörde, da ist eh alles anders :) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Steffen Dettmer schrieb in 3,1K (89 Zeilen):
* Wolfgang Weisselberg wrote on Sat, May 06, 2000 at 01:53 +0200:
Unsinn. Caching funktioniert schon bei CGI, es sei denn, im Header steht ein entsprechender Hinweis an die Caches.
Na, was ist dabei z.B. mit Cookies?
Die werden prinzipiell abgelehnt. :-) Oder vom Sanitizer entfernt. Niemand muss sich an die Vorgaben des Webservers halten. Oft wird es gemacht. Wwwoffle, z.B., kann auf Wunsch auch das "pragma nocache" ignorieren. Ja, das macht oft Sinn.
Damit gäbe es dann Probleme, deshalb wird sowas i.d.R. nur vom Browser gecacht, und Paramteraufrufe sollte man laut Empfehlung auch nicht cachen.
i.d.R., sollte ...
Und bei SSL kannst du auch cachen. Ob das gut ist? Andere Frage.
Wie denn bitte?
Meine Guete, muss ich erklaeren, was z.B. ein "man-in-the-middle" ist? Oder was man mit Proxies anstellen kann? Nur wenn du den "man-in-the-middle" ausschalten kannst, kannst du mit SSL Probleme bekommen. Aber auch dann kannst du immer noch 'playback' machen, solange die (Session)-Keys noch stimmen.
Virenscanner bremsen schon richtig, klar. Aber eine lahme Leitung wird zumindestens nicht viel langsamer, schnelle jedoch IMHO schon. (Reden wir eigentlich über Proxies für zu Hause oder für "richtige" Netze?)
Reden wir jetzt ueber Bandwith oder Latency? *Du* redest ueber Latency, aber du sagst es so, als waere es Bandbreite.
Der Datendurchsatz wird durch einen Virenscanner herabgesetzt, es sei denn, er ist verdammt schnell, also richtig verdammt mega schnell.
Er muss nur schnell genug sein, um die tatsaechliche Bandbreite verarbeiten zu koennen. In der Regel wird der Virenscanner ja auch nur gegen Email gerichtet, nicht gegen Port 80.
Schliesslich wird pro $Zeiteinheit (bei vernuenftigem Ausbau der Caches) genausoviel an Bytes ruebergeschoben. Nur dauert es beim einzelnen Luser halt 0.1-0.2 sec pro Verbindung mehr
Womit scannst Du eigentlich?
?
AFIAK bezahlte ne Uni den Traffic zum/vom DFN.
Unter Anderem. Der DFN muss ja selber auch zahlen.
Nicht, wenn ein DFN Cache gefragt wird, weil der Traffic im DFN Netz bleibt. Dadurch würde das DFN (nicht die Uni) Geld sparen.
Das DFN mietet die Leitungen, IIRC auch per GB. Kosten tut's also, nur weniger.
Das DFN zahlt dann nur, wenn es kein Cache Hit war. Ergo etwas weniger. Damit sollte das DFN daran interessiert sein.
Klar. Da die Kosten aber 1:1 weitergegeben werden (s.u.) ...
Das wird dann selbst im einfachsten Fall volumenmaessig auf die Teilnehmer umgelegt. Wenn also (fast) alle weniger teuere USA-Verbindungen machen und dafuer mehr billigere inner-DFN-Verbindungen macht, sinken die Gesamtkosten des DFN, und damit auch die Kosten pro Byte.
Sicher? Ich habe gehört, daß DFN berechnet per MB/GB unabhängig von der Zieladdresse, d.h. uni-uni in Deutschland genauso teuer für die Unis wie Transatlantik.
Die Kosten pro GB werden *nachher* errechnet. Stell dir vor, dein (nicht-kommerzieller) Provider sagt am Ende des Jahres: "Wir hatten $BIGNUM[1] DM an Netzwerkkosten, $BIGNUM[2] GB Durchsaz, also kostete ein GB im letzten Jahr $PREIS. Bitte zahlen sie (die Differenz zu den Vorauszahlungen) jetzt!" Bei vernuenftigen Usern ist schon damit Sinn gegeben, das GB billig zu machen. Kommerzielle Provider rechnen ja selber und tragen das Risiko der Fehlkalkulation. -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Wolfgang Weisselberg wrote on Sun, May 07, 2000 at 23:43 +0200:
Steffen Dettmer schrieb in 3,1K (89 Zeilen):
* Wolfgang Weisselberg wrote on Sat, May 06, 2000 at 01:53 +0200:
Na, was ist dabei z.B. mit Cookies?
Die werden prinzipiell abgelehnt. :-) Oder vom Sanitizer entfernt.
Du hast Recht. Man kann kaputt-cachen. Aber Du gehst dann bitte auch ans Telefon und erklärst den Leuten, warum ihr Onlinebanking nicht richtig geht!
Damit gäbe es dann Probleme, deshalb wird sowas i.d.R. nur vom Browser gecacht, und Paramteraufrufe sollte man laut Empfehlung auch nicht cachen.
i.d.R., sollte ...
Klar, man _kann_ es kaputt konfigurieren!
Und bei SSL kannst du auch cachen. Ob das gut ist? Andere Frage.
Wie denn bitte?
Meine Guete, muss ich erklaeren, was z.B. ein "man-in-the-middle" ist? Oder was man mit Proxies anstellen kann?
Dann cache doch bitte mal eine Verbindung, die ein Client-Certificat verwendet, natürlich, ohne die Keys von jedem Benutzer zu kennen!
kannst du mit SSL Probleme bekommen. Aber auch dann kannst du immer noch 'playback' machen, solange die (Session)-Keys noch stimmen.
Was soll das jetzt? Klar kann man SSL kaputtrixen. Würde ich als User übrigens exakt als Man-In-The-Middle Angriff werten. Aber der Browser sollte das normalerweise merken, wenn die Namen nicht stimmen, denn er soll ja DNS Auflösen und den Namen mit den DN vergleichen.
Der Datendurchsatz wird durch einen Virenscanner herabgesetzt, es sei denn, er ist verdammt schnell, also richtig verdammt mega schnell.
Er muss nur schnell genug sein, um die tatsaechliche Bandbreite verarbeiten zu koennen.
Also im Extremfall 34 oder 100 oder 155 Mbit.
In der Regel wird der Virenscanner ja auch nur gegen Email gerichtet, nicht gegen Port 80.
Klar, man kann ihn abschalten, dann ist es schneller. Sag mal, daß ist doch hier keine Argumentation! Dann könnten sich die Sekretärinnen immernoch per HTTP (oder FTP) ihre Vieren downladen.
Schliesslich wird pro $Zeiteinheit (bei vernuenftigem Ausbau der Caches) genausoviel an Bytes ruebergeschoben. Nur dauert es beim einzelnen Luser halt 0.1-0.2 sec pro Verbindung mehr
Womit scannst Du eigentlich?
?
Also, ein Virenscanner, der einen großen FTP Strom in 0.1 sec scannt, wäre nicht schlecht. Soweit mir bekannt, gibt es keinen stabilen, sicheren Scanner, der _richtig_ "on the fly" Datenströme scannen kann, und die Verbindung richtig "abwürgt" etc.
Nicht, wenn ein DFN Cache gefragt wird, weil der Traffic im DFN Netz bleibt. Dadurch würde das DFN (nicht die Uni) Geld sparen.
Das DFN mietet die Leitungen, IIRC auch per GB. Kosten tut's also, nur weniger.
Kann schon sein. Beim DFN ist's zudem noch unwahrscheinlich, daß Preise neuverhandelt werden, wenn der Markt sich ändert, z.T., weil man nicht "mal eben" den Provider wechseln kann etc. pp.
Die Kosten pro GB werden *nachher* errechnet. [...] GB Durchsaz, also kostete ein GB im letzten Jahr $PREIS. Bitte zahlen sie (die Differenz zu den Vorauszahlungen) jetzt!"
Dann habe ich entweder was ganz ganz falsches gehört (1DM/MB), oder es werden sehr seltsame "Nebenkosten" bezahlt. Außerdem macht das keinen Sinn, wenn die selbst per GB bezahlen, denn dann sollte das kalkulierbar sein, oder? Aber bitte bitte laß uns nicht übers DFN diskutieren! Wenn Du noch was loswerden möchtest, meinetwegen per PM. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
participants (4)
-
PH-Linex＠gmx.net -
steffen＠dett.de -
stockexchange＠gmx.net -
weissel＠netcologne.de