Files
webmin/squid/help/edit_icp.da.auto.html
2020-04-23 18:10:56 +03:00

1 line
1.9 KiB
HTML

<header> Andre cacher </header> <b>Andre proxy-cache-servere</b> : Dette viser alle aktuelt konfigurerede søskende, overordnede og multicast-cacher. Klik på værtsnavnet eller adressen for at redigere eller se den komplette konfiguration. <p> <b>Hent direkte URL&#39;er, der indeholder</b> : Standarder til &quot;.cgi&quot; og &quot;?&quot;. Lader dig tvinge Squid til altid at hente bestemte indholdstyper direkte fra originalserveren. Normalt behøver dette ingen ændringer, da de fleste ting håndteres automatisk af Squid uden hjælp. <p> <b>ICP-forespørgsel timeout</b> : Standard er til en &#39;optimal&#39; værdi. Hvis du vil tilsidesætte den værdi, der er bestemt af Squid, skal du indstille denne til en ikke-nul værdi. Standard i gamle versioner af Squid var 2000. <p> <b>Multicast ICP-timeout</b> : Standard er til 2000 ms eller 2 sekunder. For multicast-peers sender Squid regelmæssigt ICP-&quot;sonder&quot; for at tælle, hvor mange andre peers, der lytter til den givne multicast-adresse. Denne værdi angiver, hvor længe Blæksprutter skal vente med at tælle alle svarene. <p> <b>Død peer-timeout</b> : Standard er 10 sekunder. Dette styrer, hvor længe blæksprutte venter på at erklære en peer-cache som &quot;død&quot;. Hvis der ikke er modtaget ICP-svar inden for dette tidsrum, vil Squid erklære peer-døren og ikke forvente at modtage yderligere ICP-svar. Imidlertid fortsætter det med at sende ICP-forespørgsler og vil markere peeren som levende efter modtagelse af det første efterfølgende ICP-svar. <p> Denne timeout påvirker også, når Squid forventer at modtage ICP-svar fra peers. Hvis der er gået mere end &#39;dead_peer&#39; sekunder siden det sidste ICP-svar blev modtaget, forventer Squid ikke at modtage et ICP-svar på den næste forespørgsel. Så hvis din tid mellem anmodninger er større end denne timeout, vil du se en masse anmodninger sendt DIRECT til originalservere i stedet for til dine forældre. <p><hr>