Wie du sagst:
- FastCGI ist ein Protokoll
- Rack ist eine API
Also handelt es sich tatsächlich um zwei ziemlich unterschiedliche Dinge, obwohl sie zusammen genutzt werden könnten.
FastCGI legt fest, wie zwei verschiedene Prozesse miteinander kommunizieren sollen
FastCGI legt als Protokoll fest, wie zwei verschiedene Prozesse (üblicherweise ein Webserver und ein Anwendungsserver oder "FastCGI-Server") über eine Netzwerkverbindung miteinander kommunizieren sollen. Die Spezifikation definiert Datensätze in einem bestimmten Format, die von den beiden Prozessen gesendet und empfangen werden.
Es wird nicht explizit festgelegt, wie die Programme aussehen, die diese Nachrichten senden und empfangen, und sie könnten beliebig sein. Auf der einen Seite könnte man ein C-Programm haben, das Daten im Speicher zusammenstellt und dann Systemaufrufe tätigt, um das Betriebssystem die Daten senden zu lassen, und auf der anderen Seite könnte man ein Ruby-Programm haben, das einen Socket öffnet, Daten in Arrays einließt, diese Daten analysiert und ein neues Objekt erstellt, das die Anfrage verkapselt.
Rack legt fest, welche Ruby-Objekte und -Methoden für höherwertige Software verfügbar sein müssen
Andererseits spezifiziert Rack als Ruby API-Spezifikation genau, welche Ruby-Objekte und -Methoden für höherwertige Software, die eine Art von Webanwendung implementiert, verfügbar sein müssen, und wie sich diese Objekte und Methoden aus der Sicht der Anwendung verhalten müssen. (Lassen Sie sich nicht durch die Verwendung des Wortes "Protokoll" in dem obigen verlinkten Dokument verwirren. Hier wird es nicht im Sinne von Datenformaten verwendet, die über eine Kommunikationsverbindung gesendet werden, sondern im objektorientierten Sinn der konzeptionellen "Nachrichten", die zwischen Objekten ausgetauscht werden, um Programmverhalten auszudrücken, obwohl dies tatsächlich zu verschiedenen Zeiten und in verschiedenen Ebenen als Funktionsaufrufe implementiert wird.)
Als API-Spezifikation sollte der Benutzer der Rack-API zumindest so handeln, als hätte er keine Ahnung, was unter der Motorhaube passiert, wenn er Methoden auf den verschiedenen Objekten aufruft, die eine Implementierung von Rack bereitstellt. Es könnte sein, dass die Bibliothek tatsächlich eine Kommunikation mit einem separaten Prozess eingerichtet hat, der als Webserver fungiert, über FastCGI oder ein anderes Protokoll Daten von dem anderen Prozess empfängt und zurücksendet, basierend auf dem, was die Anwendung tut, die die API-Implementierung verwendet. Andererseits könnten Sie genauso gut (zumindest in der Theorie) eine völlig andere Implementierung der API einfügen, die selbst Ruby-Code hat, um einen Webserver zu betreiben, und derselbe Prozess, der Ruby-Code für die Webanwendung ausgeführt hat, würde zusätzlichen Ruby-Code ausführen, um direkt mit einem Client-Webbrowser oder ähnlichem das HTTP-Protokoll zu sprechen.
Man kann nicht sagen, dass Unicorn (oder jede andere Implementierung der Rack-API) eine "Ruby-Implementierung von FastCGI" ist
Die Frage gilt nicht so, wie Sie sie gestellt haben, denn der ganze Sinn der Rack-API-Spezifikation besteht darin, dass man explizit vermeidet, über die tatsächliche Implementierung der über diese API bereitgestellten Dienste nachzudenken. Es könnte gut sein, dass einige Implementierungen FastCGI verwenden, aber Ihre Anwendung sollte genauso gut mit einer funktionieren, die das nicht tut, und Sie möchten wirklich nicht darüber nachdenken, was unter der Motorhaube passiert.
