Beiträge von mainziman

aRaphael Ja

hier gibts Anregungen: https://www.digitalocean.com/community/tuto…on-ubuntu-18-04

aRaphael was spricht dagegen, das Modul mod_dav von Apache hier einfach zu verwenden?

KB19 ok so haste es gemeint;

die Frage müsste man anders herum stellen, welcher Client veranstaltet "nur" HTTP/1.0 innerhalb einer TLS "Verpackung";

ich würd mir hier keine Gedanken machen, und es lassen, der Zeitpunkt, wo das mal aus den Quellcodes fliegt kommt früh genug,

oder traut sich keiner darüber weil dann HTTP/2 auch nicht mehr geht

Zitat von KB19

Würde das (aus Serversicht) wirklich noch irgendjemand benötigen?

im Prinzip nicht, aber per mod_rewrite auf HTTPS 'weiterleiten' macht durchaus Sinn;

letzte Woche hatte meine USV gemeldet, dass die Batterie getauscht werden soll;

ich hab mal bei meinem Händler ums Eck nachgesehen, er hat sie nicht lagernd;

dann hab ich sie einfach im nächstbesten Shop der Suchmaschine meines Vertrauens bestellt,

und war schon überrascht, dass die 24 Stunden nachdem ich des Mail erhalten habe, dass

sie versendet wurde bei mir angekommen ist, und des quer durch Dtl. bis nach Österreich;

5,5 kg hatte des Packerl

die A1 Telekom ist nun im 3ten Jahrtausend angekommen ...

https://futurezone.at/digital-life/e…ckout/401777049

Zitat von aRaphael

Dabei habe ich festgestellt:

Client -> Server: So gut wie keine Retransmissions

Server -> Client (-R): Haufenweise!

ja das habe ich auch festgestellt;

und auch, dass die Bandbreite durch den Tunnel auch von vServer zu vServer deutlich nach unten einbricht;

nur warum?

aRaphael ich habe hier jeweils die Ausgabe auf der iperf3-Serverseite ausgegeben; am Client zeigt er mir z.B. sowas an:

[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   592 MBytes   496 Mbits/sec  1883             sender
[  4]   0.00-10.00  sec   591 MBytes   496 Mbits/sec                  receiver

Fehler auf der iperf3-Serverseite?

wo hackt es, dass zu Hause vom Tunnel nur noch 1/6-1/5 von der eigentlichen Bandbreite durchkommen?

und auch weiter oben, beim Tunnel von vServer zu vServer?

(irgendwie bin total ratlos, zumal sich ja am Router und am 6in4-Server nix geändert hat,

und es im April nach meinem Bandbreiten-Upgrade funktioniert hat)

Zitat von aRaphael

Hmmm....

Deinen Screenshots zufolge kommt da doch eigentlich überhaupt nix an. (Letzte Zeile 'receiver')

das stimmt schon so, je nach Parameter -R od nicht beim iperf3-Client, ist dann der iperf3-Server einmal nur sender und einmal nur receiver;

Zitat von frank_m

Ich fürchte bei den Retransmissions suchen wir an der falschen Stelle. Bei den Tunnelversuchen weiter oben treten sie nicht in signifikanter Anzahl auf, und bei den direkten vServer Verbindnungen schränken sie die Bandbreite nicht dramatisch ein.

Ja von vServer zu vServer nativ ist kaum ein Unterschied zwischen IPv4 und IPv6, wieso aber wie weiter oben gezeigt, ist sie bei einem 6in4-Tunnel von vServer zu vServer so rund 150-200 MBit/sec niedriger?

und es ist nur logisch, wenn die Gesamtbandbreite überhaupt nur 200 MBit/sec ist - ist diese nur noch 30-50 MBit/sec, obwohl, wie ganz oben gezeigt, klappte das ja mal ...

und seither hat sich nichts verändert - zumindest was ich beeinflussen kann;

Zitat von tab

Aha. Probieren werde ich das, wäre allerdings ein ziemlicher Skandal, wenn das Zertifikat jeder Seite, die mit Edge aufgerufen wird, dadurch vertrauenswürdig wird.

da kann ich dich beruhigen, es werden ausschließlich die Stammzertifikate nachgeladen, welche MS nach strengen Kriterien ausgesiebt hat - ähnlich Mozilla, nur noch etwas strenger; ABER: Google Chrome baut zwar auf den Zertstore vom Windows auf, aber Garantie, dass es auch jedes Stammzert. im Store akzeptiert hat man nicht; sprich: Google hat nochmal eine Liste, welche hardcoded im Browser ist;

wenn man eine eigene CA betreibt, hat man kein Problem, das erkennt er dass es kein offizielles Stammzert. ist, und akzeptiert es;

Zitat von aRaphael

Ist das denn ohne den Tunnel tatsächlich genauso schlecht?

ja kurioserweise, starte ich auf einem der vServer iperf3 -s

bzw. am anderen iperf3 -c IPADDR -R od. iperf3 -c IPADDR

und die Variante mit -R ist auch ohne Tunnel mit IP so schlecht ...
(auch bei deaktivierter IPtables-Firewall)

H6G da werd ich aber kaum was ändern können - das war zwischen 2 vServern;

ich stelle hier die Frage in den Raum: kündigt sich hier der Ausfall einer Netzwerkkomponente - z.B. Switch - an?

ich hatte soeben einen 6in4-Tunnel zwischen 2 vServern hier gemacht,

habe zu Testzwecken einen VPS auf Lager (Serverhording) und besagtem RS

Zitat von frank_m

Der Upload vom Router ist langsam, sobald Protokoll 41 in IPv4 Paketen verschickt wird (weil das macht HE ja auch so). Da würde ich als erstes suchen.

ne dieser ist deswegen nur 20 MBit/sec weil meine Internetbandbreite im Upload auch nur 20 MBit/sec hat ...

Zitat von frank_m

Du hast auch nie mit tc herumgespielt oder mit DiffServ?

nein keine Ahnung was das ist;

Um Dir zu folgen, wenn ich einen 2ten 6in4 Tunnel zu einem anderen meiner vServer mache, ich hier auch nur die magere Bandbreite haben werde;

wo müsste ich denn zu suchen beginnen? es hat sich ja eigentlich nichts an meinem Router geändert und am RS eigentlich auch nicht; dieser hatte

bevor ich ihn dieser Tage neu startete eine Uptime von mehr als 180 Tagen;

Zitat von H6G

Evtl. bekommen wir sie auch dazu ' und " als arcmin und arcsec zu benutzen, statt für Zoll und Fuß.

lieber nicht, arcsec ist die Umkehrfkt. des Secans

wobei weil wir schon bei den Einheiten sind, der eine od. andere ist doch sicher in einem Arbeitsverhältnis wo es eine "Stempelkarte"¹ gibt

¹ ob das jetzt eine Scheckkarte, Chipkarte od. sonstwas ist, ist hier nicht von Bedeutung, interessant ist wie gerechnet wird;

bei mir wird in der Arbeit in Industriezeit gerechnet;

wenn ich z.B. um 06:51 Uhr einstemple und um 11:36 Uhr f. die Mittagspause wieder ausstemple,

dann habe ich 4 h 45 min sondern 4,75 h gearbeitet;

stemple ich nach der Mittagspause z.B. um 12:15 Uhr wieder ein und am Abend um 16:15 Uhr wieder aus,

dann sind das genau 4 h; das wäre ja noch logisch;

aber unlängst auf einem Gebührenparkplatz hatte ich das vernommen

Beginn: 13:20 Uhr

Ende: 14:20 Uhr

Parkdauer: 01:01 h

es waren damit 2 Stunden fällig, weil die 2te Stunde ja angefangen wurde;

sprich: es scheint nicht genormt/geregelt zu sein, ob die Grenzen inklusiv od. exklusiv zu berechnen sind;

bevor die Negativzinsen die Runde machten, wurde durch die EU festgelegt,

dass das Geld am Konto ab dem Tag der Einzahlung/Gutbuchung zu verzinsen ist;

wer hat hier gesagt, ob auch der Tag der Abhebung/Lastschrift noch verzinst wird?

(ich hab hier den seltsamen Verdacht, dass sich die Zinsperiode nur verschoben hat)

auch stolpern manche bei dem darüber; wenn z.B. am 6. Okt. eine Periode f. ein ganzes Jahr beginn,

dann gilt diese klarerweise bis zum 5. Okt. des Folgejahres

und nicht bis zum 6. Okt. und erst recht nicht bis zum 7. Okt. des Folgejahres;

die Maßeinheiten sind ma schon immer suspekt gewesen, demnach wär ich 6 Fuß hoch,

also keine 3 Käse hoch

es sei denn 1 Käse ist 2 Fuß hoch

Zitat von frank_m

Hast du mal die CPU Auslastung der beteiligten Geräte im Auge behalten?

CPU ist nicht das Problem, der RS hat 2 Cores und macht eigentlich nebenbei so gut wie nichts anderes;

der Router - eine ZBOX - hat 4 Cores, ist auch nicht das Problem; (sonst hätt es ja nie gehen dürfen)

Zitat von frank_m

Hast du irgendwelche iptables oder traffic Shaper Regeln auf deinem Router aktiv?

die einzigen - welche im entferntesten darunter fallen könnten

am vServer:

bei IPv6:

-A INPUT -i eth0 #vSrver-IPv6-Prefix# -p icmpv6 -m limit --limit 2/sec --limit-burst 4 -j ACCEPT

bei IPv4:

-A INPUT -i eth0 -p icmp -m limit --limit 2/sec --limit-burst 4 -j ACCEPT

ein traceroute6  von irgendwo nach Hause endet am vServer, das hatte ich aber bereits im Januar schon so; sprich mein Netz zu Hause ist abgeschottet;

ich hab am vServer folgende beiden ip6tables-Rules

1. -I FORWARD -i eth0 -o sit1 -d #LAN-IPv6-prefix# -m state --state ESTABLISHED,RELATED -j ACCEPT
2. -I FORWARD -i sit1 -o eth0 -s #LAN-IPv6-prefix# -j ACCEPT

Zitat von frank_m

Es fällt ja auf, dass auch die HE Tunnel Ergebnisse mäßig sind.

das ist zwar richtig, aber hier gehört die Infrastuktur am Tunnelaustrittspunkt auch nicht mir alleine;

Nur mal etwas laut gedacht, wäre es möglich, dass einer der Router, die auf dem Weg zwischen netcup und mir zu Hause

die IPv4-Pakete mit dem 6in4-Protokoll (proto 41) im Header etwas drosseln - niedriger priorisieren?

(soetwas wäre f. mich nach bisherigem Wissenstand die einzige Möglichkeit, weil als echtes IPv4 habe ich die Bandbreite)

ich erwarte mir jetzt nicht unbedingt die vollen 200 MBit/sec aber nicht mal ¼ davon finde ich zuwenig;

etwa die Hälfte (rund 100 MBit/sec) würde ich gerne haben;

aRaphael leider nein; ich hab sie von default 1480 mal auf 1472 gesetzt - klar auf beiden Seiten; ändert nichts;

Steini

der umgekehrte MTR vom vServer nach Hause sieht so aus