Wie geht es weiter mit SPDY und HTTP/2?

remote_mind said:
Das wird sich zeigen. Vorraussetzung für SPDY war die verschlüsselte Übertragung (und damit ein passendes SSL-Zertifikat). Bei HTTP/2 wird es wohl Browser geben, die das nur verschlüsselt mitmachen[1]
Click to expand...
Das ist IMHO eins der stärksten Argumente für das Protokoll.

Was die Einführung angeht, irgendwann wird Google sagen 'oh by the way, our next search engine update will score sites with HTTP/2 slightly higher'
Click to expand...
Das ist das bereits jetzt der Fall. [1]
Edit: Das bezieht sich natürlich auf HTTPS - aber wenn man das eh schon macht, ist die Hürde HTTP/2 einzuführen, ja auch nicht mehr so hoch. Hoffentlich hilft das Hochranken dann auch besser als Anreiz als bei flächendeckendem Einsatz von HTTPS, der leider immer noch auf sich warten lässt.

[1] http://googlewebmastercentral.blogspot.com/2014/08/https-as-ranking-signal.html
 
Last edited by a moderator:
elias5000 said:
So schnell wie HTML5, TLS1.x und IPv6?
(SCNR)
Click to expand...

Schneller :D
Wobei HTML5 schon genutzt worden ist, bevor der Standard überhaupt fertig gewesen ist. Bei IPv6 treten eher die Provider auf die Bremse.
 
ich denke das mit dem tls overhead wird sich fast relativieren da das ständige neuanfragen wegfällt.

warum prinzipiell https höher gerankt werden verstehe ich auch nicht. bei ecommerce macht es sinn.

aber websites mit keinerlei bezug zu einem login oder geldtransaktion werden dagegen bestraft.

brauche ich wirklich ssl um einen artikel auf wikipedia zu lessen oder eine übersetzung auf dict?
ich denke wikipedia denkt in dem fall genau so, zumindest bis dato gibt es keine ssl pflicht beim lesen dort.
 
Semi-OT:
Ich bin ja schon gespannt welche esoterischen Blüten das im Bereich SEO wieder verursachen wird.
"Wir haben herausgefunden, dass Zertifikate welche bei Vollmond erstellt wurden zu einem um 30% besseren Ranking führen."
 
wenn google dafür gesorgt hätte das class1 zertifikate generell kostenfrei werden wärs mir auch relativ schnuppe. nicht jeder kennt startssl oder will sich mit deren authentifizierungsmechanismuss auseinandersetzen, welche sehr nervig wird sollte man seinen key mal verlieren.

die einzigen die derzeit von googles politik profitieren sind die schon onehin gut bezahlten zertifizierungsstellen.

vielleicht hätte sich das web mal darum kümmern sollen anstatt 300+ irrsinnig bescheuerte gtlds einzuführen.

alle reden von sicherheit (bzw. privatssphäre) aber keiner beseitigt eine der größten anfangshürden bis auf zwei dienstleister wovon einer auch nur chinesisch spricht.
 
Last edited by a moderator:
Ja, echt cool. Hab auch noch so zwei Seiten, die ich mit SSL absichern könnte.
 
remote_mind said:
eine Seite mit viel Traffic auf _nur_ TLS umzustellen kostet auch CPU...
Click to expand...
Natürlich tut es das, aber dieser Faktor ist unseren eigenen Webhosting-Erfahrungswerten nach bei etwas Optimierung und "moderner" Implementierung im Grunde zu vernachlässigen.

MadMakz said:
warum prinzipiell https höher gerankt werden verstehe ich auch nicht. bei ecommerce macht es sinn. aber websites mit keinerlei bezug zu einem login oder geldtransaktion werden dagegen bestraft.
Click to expand...
Möchtest du denn, dass jemand mitliest, was du liest?

maltris said:
Mit dem Angriff Lets encrypts [1] wird das in Ordnung kommen.
Click to expand...
:D Schöne Anspielung.
 
Da immer mehr Seiten verschlüsselt sind, wird es für Betreiber eines Proxy-Servers immer ruhiger. Wie macht ihr das im Unternehmen, wenn eure Leitung ziemlich lahm ist? Eigentlich könnte man die private Nutzung ausschließen und den Proxy intern die SSL-Zertifikate auszutauschen, damit er den entschlüsselten Content cachen kann. Wer setzt das ein und welche Bedenken gibt es da?

PS: Ich bin glaube ich im falschen Thread. Ich finde den Tab nicht mehr wieder :-(
 
Ohne Jurist zu sein, stelle ich mir das dann schwierig vor, wenn die private Nutzung prinzipiell erlaubt ist (je nach Betrieb ist das ja manchmal so).
Wenn sowieso nur geschäftlicher Internetverkehr erlaubt ist, könnte ich mir schon vorstellen, dass man das darf.

Then again: das dürfte eher eine Frage für Juristen sein, bzw. den/die Datenschutzbeauftragten des Betriebes.
 
DeaD_EyE said:
Wie macht ihr das im Unternehmen, wenn eure Leitung ziemlich lahm ist?
Click to expand...
Man könnte eine dickere Leitung anschaffen.
In Zeiten von CDN und Web2.0 dürften auch die Websites ordentlich auf Cachability getrimmt sein und dank Viewer-Cache somit auch nicht schlimm auffallen auf einem Proxy.

In unserem Unternehmen wurde der (Zwangs-)Proxy zum Glück vor einer Weile entfernt.

Wenn die (Web-)Entwickler stöhnen, weil sie bei Starbucks um die Ecke besser testen können (dort können sie nämlich den Viewer-Cache leeren, der Proxy liefert trotzdem weiterhin für die Cachedauer eine kaputte Datei), dann ist das schon sehr grenzwertig.

IMHO ist Proxy zu Cache-Zwecken mittlerweile anachronistisch.
 
marce said:
Ein paar "nette" Gedanken zu der Gesamt-Thematik:

http://blog.fefe.de/?ts=aa031bbb
Click to expand...

Praktisch alles davon ist überflüssig. Sowohl auf Client-, als auch auf Serverseite. Ein Teil davon ist dem Standard geschuldet (wieso muss der Server bitte das Datum mitschicken?!),
Click to expand...
Wenn du die Benutzergenerierten "x-" Einträge weg lässt eigentlich nur Date, sofern man sich denn auf max-age verlassen will welches wiederum selbst ein optionaler Parameter ist.
Wenn du kein Maxage, Expire oder Datum schickst hat der Browser keinerlei Refrenz für einen Cache als sich selbst und die Seite erscheint im schlimmsten Fall niemals als geändert nachdem der Browser die Daten im Cache hat.
D.h. der Browser muss sich selbst ein Expire setzen. Damit wäre z.B. AJAX nicht vernünftig durchfürbar.

Connection: * ist, wie der Artikel besagt, HTTP/1.0 zu schulden. Hätte man es aber in 1.1 weg gelassen wäre 1.1 in der übergangszeit nicht Rückwärtskompatibel gewesen. Da es fester bestandteil von HTTP/1.1 ist hätte man es nur mit einem neuen Draft (HTTP1.2) wegstandatisieren könnenund wiederum die Rückwärtskompatibilität gebrochen.

Bisher zeichnen sich alle HTTP Standarts durch ihre Rückwärtskompatibilität aus (so weit es geht).

wget (bis einschließlich v1.12) ist z.B. ein Tool welches den HTTP/1.1 Standart nicht 100%ig interstützt sowie vermutlich manch andere Clientapplikationen die die Kommunikation nur auf das nötigste beschränken.
Wir könnten auch einfach HTTP/1.1 nehmen, Pipelining und TLS 1.2 vorschreiben, und wir hätten so gut wie alle Vorteile von HTTP/2
Click to expand...
Und wenn man das in einem Standart zusammenfassen will nennt man es HTTP/2 (nur halt mit Multiplex)

Pipe vs. Multiplex: http://stackoverflow.com/questions/...http-pipeling-and-http-multiplexing-with-spdy
 
Last edited by a moderator:
MadMakz said:
wget (bis einschließlich v1.12) ist z.B. ein Tool welches den HTTP/1.1 Standart nicht 100%ig interstützt sowie vermutlich manch andere Clientapplikationen die die Kommunikation nur auf das nötigste beschränken.
Click to expand...
Einer der Punkte aus Fefes Rant war, dass wir diese Art von Clients nur haben, _weil_ der Standard das zulässt.
Würde der Standard sowas nicht durchgehen lassen, wären diese Clients in 0,nichts gefixt.

Manchmal muss man Leidensdruck erzeugen um eine Änderung zu forcieren oder es wird sich nie ändern. Man muss auch mal alte Zöpfe abschneiden.
Schau doch z.B. mal IPv6 an - da hat es auch erst das Ausschöpfen des Adressraumes von IPv4 gebraucht um das mal zu beschleunigen. (Mal davon abgesehen, dass IPv6 auch nicht gerade ein Paradebeispiel für exzellentes Protokolldesign ist).

Connection: * ist, wie der Artikel besagt, HTTP/1.0 zu schulden. Hätte man es aber in 1.1 weg gelassen wäre 1.1 in der übergangszeit nicht Rückwärtskompatibel gewesen.
Click to expand...
Wieso sagt der Client im Request wohl an, welche HTTP-Version er spricht? In 1.1 hätte man ganz klar mit den Defaults aus 1.0 brechen können.
 
Last edited by a moderator:
Danke für den d-Hinweis ;)

elias5000 said:
Wieso sagt der Client im Request wohl an, welche HTTP-Version er spricht? In 1.1 hätte man ganz klar mit den Defaults aus 1.0 brechen können.
Click to expand...



Ich denke weil es auch noch close als Connection status gibt.

Nun ist die Frage ob man prinzipiell Connection: senden muss sofern es kein close darstellt und andernfalls von keep-alive ausgehen soll wenn sich der Client als 1.1 ausweist.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top