gRPC

Du definierst eine .proto Datei: service Greeter { rpc SayHello (HelloRequest) returns (HelloReply) {} } Dann drückst du einen Knopf (Code Generator). Zack, hast du fertigen Code für Java, Python, Go und C++. Du rufst die Funktion client.sayHello() auf, als wäre sie lokal. Dass sie übers Netzwerk geht, merkst du im Code kaum.

1. Streaming

Das Killer-Feature. REST ist Request -> Response. gRPC kann:

• Server Streaming: Client fragt 1x, Server schickt 1000 Antworten (Aktien-Ticker).
• Client Streaming: Client schickt 1GB Daten häppchenweise.
• Bidirektional: Beide reden gleichzeitig durcheinander (Chat).

2. Browser-Support (gRPC-Web)

Browser verstehen kein pures gRPC (sie können kein rohes HTTP/2 kontrollieren). Man braucht einen Proxy (Envoy) dazwischen, der übersetzt ("gRPC-Web"). Deshalb ist gRPC im Frontend (noch) selten, im Backend aber Standard.

1. Protobuf Wire Format und Varints (LEB128)

Warum ist Protobuf (Binary) so klein? Es überträgt keine Feldnamen ("age", "name"), sondern kodiert Felder als rohe Integer-Tags (1: Max). Das Meisterstück liegt in der Varint-Kompression (Variable-Length Integers, LEB128). Während JSON für die Zahl 150 drei Bytes als ASCII-Text fordert, und ein C++ uint64 hart acht Bytes Memory alloziiert, nutzt Protobuf eine Sliding-Bitmaske. Kleine Zahlen wie 5 belegen exakt $1\text{ Byte}$. Das höchste Bit signalisiert lediglich, ob das nächste Byte noch Bestandteil der selben Zahl ist. Das drückt den Payload bei Microservices massiv zusammen und eliminiert jegliches String-Parsing-Gewicht in der Rechen-ALU.

2. HTTP/2 Framing und Head-of-Line Blocking

gRPC läuft exklusiv auf puren HTTP/2 Frames. Anstatt bei 100 parallelen Calls 100 TCP-Sockets zu verfeuern (was Limit-FD Errors provoziert), reitet gRPC über eine einzige langlebige TCP-Line. Alle Calls werden in DATA-Frames und HEADERS-Frames zerstückelt und wild gemischt (Multiplexing). Das ironische Problem: Wenn das Netzwerk ein einziges TCP-Paket verliert (z.B. Byte #500), crasht das das gesamte Stream-Gefüge (TCP Head-of-Line Blocking). Alle 100 gRPC-Calls müssen im TCP-Puffer (Wait-State) verharren, bis das Kern OS das fehlende Byte resendet. Darum migrieren High-End Systeme für externe Latenz aktuell auf gRPC-over-HTTP/3 (QUIC/UDP).

3. Load Balancing (Client-Side vs. Proxy)

Ein unsichtbarer Schmerzpunkt in gRPC. Da es eine persistente L4-Verbindung erzwingt, tunnelt es fröhlich durch reguläre L4-Loadbalancer (AWS NLB) hindurch. Wenn Client A sich verbindet, landet er bei Pod 1. Verbindet sich Pod 100, nageln alle Streams auf Pod 1 ein – Pod 2 bis 99 langweilen sich, da keine neuen TCP-Connects entstehen. Die Lösung ist exklusives L7 Load Balancing (Envoy) oder Client-Side Load Balancing (xDS). Letzteres (Thick Client) lässt den gRPC-Client direkt mit der Kubernetes API reden, die Pod-IPs pullen, und im Ram lokal über Subchannel Round-Robin verteilen. Keine Middlebox-Latenz.