Einführung in Protokolltests
Nun ..., Sie haben sicherlich schon häufig irgendwelche Internet-Dienste genutzt (z.B. um sich diese Seite in Ihrem Browser anzeigen zu lassen). Normalerweise macht man sich keine Gedanken darüber wie die angeforderten Informationen (Webseiten, Mails, News, ...) auf den eigenen Rechner gelangen. Man tippt z.B. eine Adresse in die entsprechende Zeile des Browsers und erhält daraufhin die gewünschte Seite. Was macht aber nun der Browser um diesen "Arbeitsauftrag" zu erfüllen?
Er "tuschelt" im Hintergrund, unbemerkt von Ihnen, mit dem zugehörigen Webserver. Damit sich der Webserver und Ihr Browser (er ist der Webclient) auch verstehen verwenden sie für diesen "Plausch" eine vorher festgelegte Sprache. Zusätzlich wurde aber auch genau festgelegt wer von den Beiden mit dem "Plauschen" beginnt und welche Wörter (Kommandos) die Sprache beinhaltet. Man kann sich das auch so vorstellen:
Zwei Diplomaten aus fremden Ländern wollen sich unterhalten. Sie einigen sich zuerst auf ein von beiden beherrschte Sprache. Da sie aber evtl. auch aus anderen Kulturkreisen stammen, gibt es auch ein diplomatisches Protokoll in dem das Benehmen der beiden geregelt ist.
In der System- und Rechnerverwaltung kommt es nun durchaus häufig vor, dass eine Software wie der Browser oder der E-Mail-Client nicht funktionieren. Trotz korrekter Konfiguration funktioniert in dem komplexen Gebilde aus Server, Netzwerk und Client aber trotzdem etwas nicht. Nachdem Sie die generelle Funktion des Netzwerks getestet haben (ping, traceroute bzw. tracert, ...) bleibt nur noch ein Fehler auf Protokollebene eines Dienstes übrig. Mit etwas Wissen über das Protokoll zwischen Server und Client können Sie nun die Clientsoftware umgehen und sich direkt mit dem Server unterhalten. Auf dieser Ebene erhalten Sie dann üblicherweise eine klarere Fehlermeldung und können evtl. das Problem beseitigen.
Beispiele für Protokolle:
- http: Hypertext Transfer Protocol
- ftp: File Transfer Protocol
- smtp: Simple Mail Transfer Protocol
- nntp: Netnews Transfer Protocol
- pop3: Post Office Protocol (Version 3)
Nachfolgend wird nun beschrieben wie Sie mit Hilfe eines telnet-Clients derartige Protokolltests durchführen können.
Vom Regen in die Traufe :) - Was ist denn telnet?
telnet ist eigentlich ein Server-Dienst wie beispielsweise ein E-Mail-Server (smtp), ein Webserver(http) oder Netnews (nntp). Er dient dazu eine Verbindung vom lokalen Rechner zu einem Server-Rechner im Netzwerk (oder Internet) herzustellen. Klappt das so erhält der Clientrechner einen Kommandozeileninterpreter zur freien Verfügung. Dieser Kommandozeileninterpreter (auf einem Microsoft-Betriebssystem wäre das ein DOS-Fenster/Shell) befindet sich aber natürlich auf dem Server-Rechner. Sie erhalten nur seine optische Oberfläche angezeigt und alle Tastenanschläge werden über das Netzwerk an den Server versandt. Langer Rede kurzer Sinn: Innerhalb des Telnetfensters ist Ihr lokaler Clientrechner nur noch ein Monitor und eine Tastatur. Die eigentliche Arbeit wird mit dem Betriebssystem und dem Prozessor des Server-Rechners erledigt. Da Sie hier auf einem anderen Rechner arbeiten müssen Sie sich für die Benutzung dieses Dienstes üblicherweise auch anmelden (mit einem Benutzernamen und einem dazu passenden Passwort) um damit den Nachweis zu führen, dass Sie dies auch dürfen.
Jetzt geht's aber los. Einstellungen am telnet-Client
Bei einer telnet-Sitzung werden Tastaturanschläge des Clients an den telnet-Server gesendet. Der Client selbst stellt die gesendeten Zeichen erst einmal nicht auf dem Bildschirm dar - also kein lokales "Echo" des Tastenanschlags. Vielmehr schickt der telnet-Server nach Erhalt des/der Zeichen diese wieder an den Client zurück der sie erst dann auf dem Bildschirm darstellt. Damit wird sichergestellt, dass der Anwender erst dann Zeichen in seiner Sitzung sieht wenn sie auch tatsächlich beim telnet-Server angekommen und wieder "ge-echo-t" wurden.
Die meisten anderen Protokolle haben diesen gerade beschriebenen echo-Mechanismus nicht! Damit würden wir bei Tests mit anderen Protokollen gar nicht sehen was wir tippen. Unter anderem zur Entdeckung von Tippfehlern ist dies aber sehr wichtig. Um demnach einen telnet-Client für Testzwecke bei anderen Protokollen zu verwenden, muss dieser erst einmal dazu veranlasst werden die Zeichen sofort lokal darzustellen ohne auf das "Echo" des Servers zu warten.Ein Freeware-telnet-Client der u.a. dies ermöglicht ist die eigentlich als SSH-Client berühmte Software "PuTTY" von Simon Tatham.
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
Die Software ist extrem klein, besteht aus einer einzigen Datei die notfalls einfach auf das Desktop gelegt werden kann und verursacht somit keinerlei Installationsprobleme. Nachfolgend nun eine Beschreibung welche Einstellungen Sie vornehmen müssen wenn Sie Protokolltests mit diesem Client durchführen wollen. Der Beschreibung liegt die Version 0.60 von PuTTY zugrunde.
Nach dem Start von PuTTY erscheint zuerst das Konfigurationsfenster. Sie können hier Sitzungseinstellungen für die Verbindung zu verschiedenen Servern vornehmen und abspeichern. Zukünftig reicht dann ein Doppelklick auf den entsprechenden Eintrag um sofort wieder eine Verbindung auf Basis der einmal erstellten Konfiguration herstellen.
Die nun vorgestellten Einstellungen funktionieren z.B. für einen http-Protokoll-Test:
PuTTY stellt selbst fest ob ein lokales Echo notwendig ist. Sie müssen also nicht wie in früheren Versionen das lokale Echo aktivieren. Unsere erste Einstellung ist damit erst einmal die Vergrösserung des Scrollback-Puffers und der Fenstergrösse. Gehen Sie dazu im "PuTTY Configuration"-Fenster auf die "Category" "Window"
Stellen Sie (siehe oben) die Einstellungen für"Columns", "Rows" und "Lines of scrollback" auf größere Werte ein (obige Werte sind ok). Unter der Kategorie "Terminal" können Sie sicherheitshalber noch kontrollieren ob das lokale Echo wirklich auf "Auto" eingestellt ist. Anschließend gehen Sie zurück in die erste Kategorie "Session".
In diesem Konfigurationsdialog nehmen Sie folgende Einstellungen vor:
- Geben Sie in der obersten Zeile den Webservername und den Port 80 ein.
- Stellen Sie bei "Protocol" auf "Raw". Die Einstellung "Telnet" sendet außer den eigentlichen Tastenanschlägen noch Steuerzeichen des Telnet-Protokolls.
- Wählen Sie für zukünftige Verbindungsaufnahmen einen Sessionnamen Ihrer Wahl und tragen Sie diesen unter "Saved Sessions" ein.
- Damit Sie nach einem Test in aller Ruhe nachverfolgen können was denn vom Server zurückam, müssen Sie unter "Close window on exit" noch die Einstellung "Never" vornehmen.
Speichern Sie die Einstellungen als "Session-Profil" durch Anklicken von "Save". Dieses Session-Profil steht Ihnen nun bei jedem Start von PuTTY zur Verfügung und kann z.B. mit einem Doppelklick ausgeführt werden.
Im Anschluss können Sie, entsprechende theoretische Kenntnisse zum jeweiligen Protokoll vorausgesetzt, die Kommunikation mit dem zugehörigen Server ausprobieren und dessen Reaktionen sehen. Im Schulungsbereich eignen sich hier - wegen der "Einfachheit" des Protokolls - insbesondere die Protokolle http, smtp und pop3.
Der eigentliche Protokolltest - hier am Beispiel http
Nachfolgend der Screenshot eines http-Protokolltests. Dabei wurde die Startseite von Google per http angefordert. Die ersten beiden Zeilen sind der dafür minimal erforderliche http-Request (http-Anfrage). Dieser Request muss von Ihnen als Anwender/in manuell eingegeben werden und mit einer Leerzeile abgeschlossen wird.
Direkt an Ihre Leerzeile anschließend müsste nun die Antwort des Google-Webservers kommen. Es kommt zuerst der http-Header der Antwort und dann der HTML-Code der Google-Startseite.
