Heute haben wir uns mit den Prinzipien der Internetarchitektur auf Basis des RFC 1958 auseinandergesetzt.
| Anfang | 1-msc-ain-internet-arch-fundamentals-20160420 – Seite 30 |
|---|---|
| Ende | 1-msc-ain-internet-arch-fundamentals-20160420 – Seite 38 |
Prinzipien der Internetarchitektur
Wie sollte das Systemdesign aussehen?
- Das Systemdesign sollte unabhängig von Anzahl der Knoten sein und beliebig viele erlauben
- In der Praxis limitieren IP-Adressen und die Werte des TTL-Felds die Kommunikation
- Diese Einschränkungen liegen nicht am Design, sondern der Implementierung
Warum sollte man das Senden beschränken?
- Aus Gründen der Staukontrolle, um die Bandbreite der anderen Teilnehmer nicht übermäßig negativ zu beeinflussen
Warum sollte man beim Empfangen tolerant sein?
- Aufgrund von falschen Werten in reservierten (d. h. nicht genutzten) Feldern sollten die Nachrichten nicht verworfen werden
Warum sollte man keine Adressinformationen im Quellcode von Programmen festlegen?
- Damit Änderungen nicht nur durch Entwickler vorgenommen werden können
- Damit Anwendungen modular und portabel sind
Welche Protokolle und Technologien sind zu präferieren?
- Unpatentierte Technologien sind immer zu bevorzugen, auch wenn sie unter Umständen schlechter sind
Wie gewährleistet man eine maximale Kompatibilität bei der Protokollentwicklung?
- Verwende stets alle Teile eines Protokolls und nicht nur Teile davon
Warum ist es wichtig, Internationalization zu berücksichtigen?
- Bei der Eingabe von Zeichenketten können Sonderzeichen vorkommen
- Es muss klar sein, wie mit diesen umzugehen ist
Wie sieht es mit Vertraulichkeit aus?
- Man sollte immer davon ausgehen, dass alle Daten vertraulich sind
- Daher sollte am Besten immer verschlüsselt und authentifiziert werden
Was ist crypto-agility?
- Die Fähigkeit, dass von einem IT-System alternative kryptographische Verfahren genutzt werden können
- Es sollte immer ein Verfahren geben, das alle machen können müssen (mandatory support)