Skip to main content

> grpc_i̇letişim_modelleri:_unary,_çift_yönlü_akış_(streaming)_ve_http/2_akış_kontrolü_geri_basıncı

gRPC İletişim Modelleri: Unary, Çift Yönlü Akış (Streaming) ve HTTP/2 Akış Kontrolü Geri Basıncı

gRPC akış modelleri (Unary, İstemci/Sunucu Akışı, Çift Yönlü) verim ve bellek kullanımında nasıl ayrışır; HTTP/2 pencere tabanlı akış kontrolü hızlı üreticilerin yavaş tüketicileri çökertmesini nasıl önler?

Staff/Principal (L6+)

ÖZET VE TEKNİK CEVAP

gRPC **HTTP/2** protokolü üzerinde çalışarak 4 farklı uzak prosedür çağrısı (RPC) modeli sunar: (1) **Unary RPC**: Klasik istek/yanıt (istemci 1 mesaj atar, sunucu 1 mesaj döner). (2) **Sunucu Akışı (Server Streaming)**: İstemci 1 istek atar, sunucu sürekli bir veri akışı döner (canlı log takibi, borsa fiyat akışı). (3) **İstemci Akışı (Client Streaming)**: İstemci parçalı veri akışı yükler, sunucu tek bir özet yanıt döner (büyük dosya yükleme). (4) **Çift Yönlü Akış (Bidirectional Streaming)**: İstemci ve sunucu tek bir TCP bağlantısı üzerinde birbirine eşzamanlı ve bağımsız mesaj akışı gönderir (gerçek zamanlı oyunlar, canlı AI çıkarımı). Hızlı bir üretici yavaş bir tüketiciye işleyebileceğinden hızlı veri gönderirse, bellek dolar ve **OOM Çökmesi** yaşanır. gRPC bunu **HTTP/2 Kredi Tabanlı Akış Kontrolü (Flow Control Backpressure)** ile çözer: Alıcı `WINDOW_UPDATE` çerçeveleriyle bayt kredisi verir; kredi bittiğinde gönderici soketi alıcı belleği boşaltana kadar gönderimi otomatik olarak durdurur.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

gRPC Geri Basıncı (Backpressure) HTTP/2 Akış Kontrol Pencereleriyle çalışır: (1) Başlangıç Pencere Boyutu: İstemci ve sunucu varsayılan 65.535 baytlık bir akış kontrol penceresi açar. (2) Pencere Azalması: Gönderici veri gönderdikçe mevcut pencere boyutu bayt bayt azalır. (3) Pencere Tükenmesi (Geri Basınç): Pencere 0'a ulaştığında gRPC gönderimi otomatik olarak durdurur. (4) Pencere Güncellemesi: Tüketici uygulama belleğindeki mesajları okuyup işledikçe, alıcı `WINDOW_UPDATE` çerçevesi göndererek pencereyi genişletir ve veri akışı tek bir paket kaybolmadan devam eder.

2. Doğru Kullanım Senaryosu

Yüksek verimli mikroservisler arası iletişim, gerçek zamanlı AI ses akışları, telemetri log aktarımı ve canlı finansal fiyat akışları.

3. Prodüksiyon Arıza Modları

İstemci kodunda sınırsız bellek kuyrukları oluşturup HTTP/2 geri basıncını baypas ederek OOM ile çökmek; aradaki yük dengeleyicilerin gRPC Keepalive sinyalleri olmadığı için 60 saniye sonra TCP bağlantısını sessizce kapatması.

4. Teşhis ve Telemetri Sinyalleri

İstemci loglarında `RESOURCE_EXHAUSTED` hataları; ağ paketlerinde sıfır pencere `WINDOW_UPDATE` duraklamaları; gRPC akışı dinleyen pod'larda bellek kullanımının tavan yapması.

5. Önleme ve Mimari Bariyerler

gRPC Keepalive sinyallerini yapılandırın (`keepalive_time_ms: 10000`); geri basıncı dinleyen reaktif akışlar (Node.js AsyncIterator) kullanın; yüksek bant genişlikli hatlar için HTTP/2 pencere boyutlarını optimize edin.

6. Mimari Ödünleşimler (Trade-offs)

gRPC akışı JSON/REST'e kıyasla 10 kat daha yüksek verim ve düşük CPU maliyeti sağlar; ancak HTTP/2 destekleyen altyapı, özel yük dengeleme ve akış kontrolü yönetimi gerektirir.

Vaka İncelemesi (TinyCTO Örneği)

Bir yapay zeka ses platformu, LLM modelinden çıkan 24kHz ses parçalarını 10.000 mobil kullanıcıya WebSocket üzerinden JSON ile iletiyordu. JSON kodlaması ve geri basınç (backpressure) olmaması zayıf 4G bağlantılarında mobil belleğin şişmesine ve oturumların %18'inin çökmesine yol açıyordu. Ekip WebSocket yerine Protocol Buffers tabanlı gRPC Sunucu Akışına (Server Streaming) geçti. Mobil kullanıcı tünele girip interneti yavaşladığında, istemcinin HTTP/2 penceresi doldu ve arka uçtaki gRPC sunucusu veri göndermeyi otomatik olarak bekletti. Mobil çökmeler %0,01'e geriledi ve sunucu bant genişliği tüketimi %62 azaldı.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

gRPC tarafından desteklenen 4 iletişim modeli hangileridir?

Unary RPC (1:1), Sunucu Akışı (1:N), İstemci Akışı (N:1) ve Çift Yönlü Akış (N:N).
Q2

HTTP/2 pencere akış kontrolü gRPC akışında geri basıncı (backpressure) nasıl sağlar?

Göndericiyi sınırlı bir bayt kredisi penceresiyle sınırlandırarak; alıcının belleği dolduğunda yeni kredi verilmez ve alıcı belleği boşaltana kadar göndericinin veri yazması otomatik durdurulur.

gRPC İletişim Modelleri: Unary, Çift Yönlü Akış (Streaming) ve HTTP/2 Akış Kontrolü Geri Basıncı — Sıkça Sorulan Sorular

Standart L4 TCP yük dengeleme gRPC akışları için neden yetersizdir?

Çünkü gRPC tüm istekleri tek bir uzun ömürlü TCP bağlantısı üzerinde çoklar; L4 yük dengeleyici tüm TCP bağlantısını tek bir sunucuya verir ve L7 proxy (Envoy) kullanılmazsa sunucular arasında aşırı dengesiz yük oluşur.

gRPC Keepalive sinyallerinin amacı nedir?

Uzun ömürlü akışlarda periyodik HTTP/2 PING paketleri göndererek bulut NAT ağ geçitlerinin ve güvenlik duvarlarının bağlantıyı sessizce kapatmasını engellemek.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸gRPC 4 etkileşim modeli sunar: Unary, İstemci Akışı, Sunucu Akışı, Çift Yönlü Akış.
  • ▸HTTP/2 akış kontrol pencereleri otomatik kredi tabanlı geri basınç (backpressure) sağlar.
  • ▸Hızlı üreticilerin yavaş tüketicileri aşırı yükleyip OOM ile çökertmesini engeller.
  • ▸Çoklanmış gRPC akışlarını sunuculara dengeli dağıtmak için Envoy gibi L7 proxy'ler kullanın.

Yaygın Yanılgılar

  • ✗Yanılgı: gRPC her çağrı için yeni bir TCP bağlantısı açar (Gerçek: gRPC yüzlerce eşzamanlı çağrıyı tek bir kalıcı TCP bağlantısı üzerinden çoklar).
  • ✗Yanılgı: Akış mesajlarını sınırsız bir bellek kuyruğunda toplamak hızı artırır (Gerçek: Sınırsız kuyruklar geri basıncı yok eder ve uygulamanın bellek yetersizliğinden çökmesine yol açar).

Karar Kılavuzu & Önceliklendirme

Yüksek verimli, düşük gecikmeli servisler arası iletişim ve gerçek zamanlı veri hatlarında yerel HTTP/2 geri basıncına sahip gRPC Akış modellerini tercih edin.

Doğrulanmış Kaynaklar & Referanslar