Steffen Dettmer schrieb in 3,2K (85 Zeilen):
* Wolfgang Weisselberg wrote on Sun, Mar 19, 2000 at 19:27 +0100:
Der Forwarder hat eine gute Chance, schon .uni-koeln.de. zu kennen. Macht einen lookup weniger. Ist also schneller.
Dann brauche ich noch mail.ph...., leider liefert der Forwarder nur den Eintrag für www, also muß der Forwarder den erst holen.
Ob du ihn holen musst oder der Forwarder, ist herzlich egal. Es ist und bleibt *ein* zusaetzlicher Lookup: auf mail.ph-cip... Oder saugst du bei einem lookup auf www.example.org immer gleich auch *.example.org mit?
Sonst könnte der richtige DNS-Server sofort gefragt werden. Ist also langsamer. Aber für rastlose Surfer spielt das vermutlich weniger ne Rolle.
1. richtig ist der, der die Antwort weiss. 2. Modem oder ISDN-Leitung ist langsamer als die Leitung vom Provider zur Aussenwelt. (wenn du www und mail brauchst, brauchst du nur 2 Anfragen, nicht noch 3 zusaetzliche auf .de., uni-koeln.de., ph-cip.uni-koeln.de. --- der Forwarder des Providers braucht diese Angaben selten (cache) udn ist IMHO schneller bei ph-cip.uni-koeln.de.) 3. Wenn genuegend Leute nach www.ph-cip.uni-koeln.de. (und Co) fragen, dann werden sich nicht nur die root-server bedanken. Auch ns*.uni-koeln.de sagt dann irgendwann *tschuess*, mal ganz abgesehen von der Leitung nach draussen. Von daher verstehe ich dein "langsamer" nicht, oder meinst du: "der Forwarder muss manchmal (nicht dauernd) einen Lookup machen, und im Schnitt ist der *so* langsam, dass eine direkte Anfrage im Schnitt schneller ist"?
Oder bist du der Meinung, der Cache-Lookup des Providers + dessen in der Regel wesendlich schnellere Leitung zur Aussenwelt ist langsamer als den Root-Server selber zu fragen und sich dann durchzufragen?
Sicher, wenn ich mehrere Hosts aus einer Domain brauche, gehen die alle den Umweg über einen DNS-Server, sonst kommen sie direkt, sofort. Ist also (außer eben beim ersten Domainanfrage natürlich) schneller.
Wenn ich dich richtig verstehe, hat sich soeben u.a. der SQUID in Luft aufgeloest. Oder sagst du nicht: Caches (im allgemeinen) sind langsamer, egal ob sie die Daten schon haben"? Spielen wir den Fall durch: Wir haben www und wollen www2: Forwarder, nicht im Cache Du ---X ms--> Forwarder (F ms) ---Y ms--> NS.* (N ms) --. Du <--X ms--- Forwarder (F' ms) <--Y ms-- <-------------' Forwarder, im Cache Du ---X ms--> Forwarder (F ms) --. Du <--X ms--- <------------------' Kein Forwarder Du ---X ms--> ---Y ms--> NS.* (N ms) --. Du <--X ms--- <--Y ms--- <-------------' 2* X ms ~= Pingtime Du <-> ISP. F ms ~= Lookup-Time Forwarder[1] F' ms ~= Insertion-Time in den Cache + reply 2* Y ms ~= Pingtime ISP <-> Nameserver N ms ~= Lookup-Time Nameserver[2] C = Chance, dass der Forwarder die Daten hat (0 <= X <= 1) [1] Annahme: Hits sind nicht schneller als Misses. [2] Annahme: Der NS ist immer gleichschnell (was nicht der Fall ist, wenn Forwarders weithin nicht mehr benutzt werden) Zusaetzliche Annahme: Du bekommst keine Delegation auf einen besseren Server (dann geht das Ganze Spiel naemlich nochmal los, nur spart der Forwarder dann 2*X ...) bzw du bekommst keinen CNAME als Antwort (und das war nicht die Frage), dann muesstest du naemlich geg. einen weiteren Lookup machen (und wieder sparst du 2*X im Austausch gegen F' und F). Daraus folgt: Lookup ohne Forwarder: 2*X + 2*Y + N Lookup mit Forwarder: 2*X + F + ((1-C) * 2*Y + N + F') Daraus folgt: Forwarder abschalten nuetzt nur, wenn 2*Y + N < F + ((1-C) * 2*Y + N + F') also, wenn entweder der Forwarder im Schnitt selten cached (weil dann -- worst case -- F + F' hinzukommt) oder wenn F kaum schneller als 2*Y + N ist (also der Forwarder kaum schneller als die Leitung + der remote NS ist). Stimmts?
Ja. Angenommen, du willst auf h1, h2 und h3 von example.org zugreifen.
kein forwarder forwarder
h1 Lookup .org Lookup h1.example.org an forwarder[1] Lookup .example.org Lookup h1.example.org h2 Lookup h2.example.org Lookup h2.example.org an forwarder[2] h3 Lookup h3.example.org Lookup h3.example.org an forwarder[2]
[1] Im schlimmsten Fall macht der Forwarder 3 lookups, im Normalfall nur .example.org und h1.example.org ... einen weniger als du. Und die Chance, dass er .example.org kennt,
Aber ich muß dennoch einen machen, um das Ergebnis zu holen, also ohne forwarder insgesammt 5 Lookups, im anderen Falle 3 lookups an den Forwarder plus warten, bis dieser seine 3 lookups gemacht hat.
Der Forwarder muss *maximal* 3 Lookups fuer h1.example.org machen und *maximal* einen weiteren pro h*.example.org. Du musst praktisch immer 3 Lookups fuer h1.example.org und praktisch immer einen weiteren pro h*.example.org. Wenn 2*Y klein und F gross ist, dann klar, dann ist der Forwarder fuer dich nicht brauchbar.
Im günstigsten Falle. h4+ dauern aber alle länger, weil alle über den Forwarder laufen.
Maximal um F + F'. Wenn du ein brauchbar grosses C hast, bist du am Ende schneller. Wenn z.B. Y gross ist (nach Kanada oder .ru), faellt F und F' kaum in's Gewicht, ein einziger gecacheter Hit macht viele Misses dann schon wieder wett.
Im Falle des cachens kommt erschwerend hinzu, daß das Alter der Daten nicht mitübermittelt wird, also gelten dann TTL * DNS-Server.
Wuerdest du bitte die entsprechende Stelle in den RFCs angeben? Meine Leserei sagt naemlich genau das Gegenteil!
Im schlimmsten Falle forwarded der ISP intern auch nochmal... Und diesen kann man dann übrigens auch nicht notfalls mal neustarten, um ein Cache-Expire zu erzwingen.
Man kann natuerlich auch die 'authoritative information' verlangen ...
Es soll sogar vorzukommen, das DNS-Server die TTLs künstlich verlängern (hat jedenfalls mal ein ISP behauptet - kann mir allerdings kaum vorstellen, das die einen bind gepatcht haben; evtl. gibt's aber auch was anderes da...).
Klar. Kann man alles machen. Es gibt sogar Menschen, die falsche Daten (von aussen) in DNS-Server eintragen ...
Dann verdient so ein ISP mit forwardern nichts, also wird er in der Regel da nicht sehr in Performance investieren...
Versuch' mal ohne gute DNS-Server zu surfen ... Da kann der ISP auch auf den Webcache verzichten. :-) -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com