Irgendeine Möglichkeit zu erkennen, ob eine Remote-Website SPDY unterstützt und welche Version es ist?Wie erkennt man, wenn ein Server SPDY verwendet
Etwas, das ich von der Befehlszeile wie ein Bash-Skript verwenden kann.
Versuchte Senden benutzerdefinierter User-Agent-Header mit curl, kann aber keine Antwort-Header erhalten, die mir helfen würden.
Die Idee ist, SPDY zu erhalten: true/false Version: 3.1/3.0 ... für jede Domain.
openssl s_client -connect google.com:443 -nextprotoneg ''
CONNECTED(00000003)
Protocols advertised by server: spdy/3.1, spdy/3, http/1.1
Dieser Befehl funktioniert nicht, wenn Sie openssl 0.9.8 verwenden. Wenn Sie auf einem Mac sind, können Sie openssl mit brew aktualisieren: http://apple.stackexchange.com/a/126832/78754 – jdorfman
Die SPDY-Protokollaushandlung findet während des ersten TLS-Handshakes statt.
Es gibt derzeit zwei Möglichkeiten, das Protokoll zu verhandeln: Das ältere Protokoll heißt NPN (http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-04). In der ClientHello TLS-Nachricht sendet der Client die NPN-Erweiterung mit der ID 0x3374. Der Server antwortet mit einer ServerHello-TLS-Nachricht, die auch die Liste der vom Server unterstützten Protokolle auch in einer NPN-Erweiterung enthält. Der Client wählt dann das Protokoll und sendet seine Wahl verschlüsselt an den Server. Die neue Methode wurde für HTTP 2.0 entwickelt und heißt ALPN(). Die ClientHello TLS-Nachricht enthält die ALPN-Erweiterung mit der ID 0x10. Der Client sendet diesmal die Liste der unterstützten Protokolle und der Server antwortet mit einer ServerHello-TLS-Nachricht, die das vom Server ausgewählte Protokoll enthält, ebenfalls in einer ALPN-Erweiterung.
Sowohl in der NPN- als auch in der ALPN-Erweiterung wird die Liste der Protokolle als Zeichenfolgen wie http/1.1 oder spdy/3 gesendet.
Sobald das Protokoll ausgewählt wurde, wird der TLS-Handshake fortgesetzt und dann beginnen beide Parteien sofort das Protokoll zu sprechen, das sie gewählt haben.
Die einzige Möglichkeit, sich über die Aushandlung des Protokolls bewusst zu sein, besteht daher darin, TLS zu verwenden und einen Client zu verwenden, der die Protokollaushandlungserweiterungen verfügbar macht. Jeder Client macht das auf eine bestimmte Art und Weise, aber soweit ich weiß, gibt es noch keine Unterstützung für Bash-Skripte.
HAProxy zum Beispiel unterstützt sowohl NPN als auch ALPN (http://cbonte.github.io/haproxy-dconv/configuration-1.5.html) und Jetty 9.2 hat auch Unterstützung für NPN und ALPN (sowohl für Clients als auch für Server).
Andere Server wie Nginx oder Apache unterstützen NPN mit Patches für ALPN (da es sowieso von HTTP 2.0 benötigt wird).
NPN wird irgendwann verblassen; Google Adam Langley has stated, dass NPN zugunsten von ALPN veraltet ist.
Sie empfehlen daher, mit wireshark nach SPDY zu suchen? Irgendeine Möglichkeit, diesen Prozess zu automatisieren? – Jim
Wireshark ist sicherlich eine Option. Die programmierbare Option besteht darin, eine API zu finden, mit der Sie TLS-Erweiterungen festlegen/prüfen können. Ich weiß, dass Java (noch) keins bietet, aber andere Sprachen/Plattformen können. Das Jetty-Projekt hat eine API für NPN und ALPN in Java, aber sie können nicht zusammen verwendet werden. Mit den Jetty-APIs wäre es ziemlich einfach, die SPDY-Unterstützung zu erkennen (das ist der Jetty-SPDY-Client). – sbordet
Ich denke, diese falsch falsch getippte Antwort ist besser als die akzeptierte.+1 – cnicutar
Sie werden ein Programm schreiben, um dies zu tun, oder möchten Sie, dass dieses Programm für Sie geschrieben wird? –
Ich hatte gehofft, dass da draußen etwas bereit wäre, das ich in einem Bash-Skript verwenden könnte. – Jim