Apakah gRPC (HTTP / 2) lebih cepat daripada REST dengan HTTP / 2?

96

Tujuannya adalah untuk memperkenalkan protokol lapisan transport dan aplikasi yang lebih baik dalam latensi dan throughput jaringannya . Saat ini, aplikasi menggunakan REST dengan HTTP / 1.1 dan kami mengalami latensi tinggi. Saya perlu menyelesaikan masalah latensi ini dan saya terbuka untuk menggunakan gRPC (HTTP / 2) atau REST / HTTP2 .

HTTP / 2:

  1. Multiplexing
  2. Koneksi TCP Tunggal
  3. Biner, bukan tekstual
  4. Kompresi header
  5. Server Push

Saya menyadari semua keuntungan di atas. Pertanyaan No. 1: Jika saya menggunakan REST dengan HTTP / 2 , saya yakin, saya akan mendapatkan peningkatan kinerja yang signifikan jika dibandingkan dengan REST dengan HTTP / 1.1 , tetapi bagaimana ini dibandingkan dengan gRPC (HTTP / 2) ?

Saya juga mengetahui bahwa gRPC menggunakan buffer proto, yang merupakan teknik serialisasi biner terbaik untuk transmisi data terstruktur pada kabel. Buffer proto juga membantu dalam mengembangkan pendekatan agnostik bahasa. Saya setuju dengan itu dan saya dapat menerapkan fitur yang sama di REST menggunakan graphQL. Tetapi kekhawatiran saya adalah tentang serialisasi: Pertanyaan No. 2: Ketika HTTP / 2 mengimplementasikan fitur biner ini , apakah menggunakan buffer proto memberikan keuntungan tambahan di atas HTTP / 2?

Pertanyaan No. 3: Dalam hal streaming, kasus penggunaan dua arah , bagaimana gRPC (HTTP / 2) dibandingkan dengan (REST dan HTTP / 2)?

Ada begitu banyak blog / video di internet yang membandingkan gRPC (HTTP / 2) dengan (REST dan HTTP / 1.1) seperti ini . Seperti yang dinyatakan sebelumnya, saya ingin mengetahui perbedaan, manfaat membandingkan GRPC (HTTP / 2) dan (REST dengan HTTP / 2).

rest  http  google-cloud-platform  http2  grpc 
— Lakshman Diwaakar
sumber
apa yang akhirnya kamu gunakan? apakah ada kerangka kerja untuk HTTP2 + REST?
— knocte
@knocte Saya akhirnya menggunakan gPRC. Ini mengurangi latensi dengan cukup baik. Mengenai HTTP / 2 + REST, tidak ada kerangka kerja khusus, itu adalah pengaturan yang perlu Anda ubah di server yang Anda gunakan. Katakanlah, Anda menggunakan nginx, lihat dokumen untuk melihat langkah-langkah untuk menyiapkan HTTP / 2.
— Lakshman Diwaakar
dan Anda harus memastikan bahwa HTTP / 1.1 menggunakan kembali koneksi. Jika tidak, cari "tcp cold start". gRPC menggunakan kembali koneksi secara default.
— bohdan_trotsenko

Jawaban:

93

gRPC tidak lebih cepat dari REST melalui HTTP / 2 secara default, tetapi ini memberi Anda alat untuk membuatnya lebih cepat. Ada beberapa hal yang akan sulit atau tidak mungkin dilakukan dengan REST.

  • Kompresi pesan selektif. Di gRPC, RPC streaming dapat memutuskan untuk mengompresi atau tidak mengompresi pesan. Misalnya, jika Anda mengalirkan teks dan gambar campuran melalui satu aliran (atau konten campuran yang dapat dikompres), Anda dapat mematikan kompresi untuk gambar. Ini menyelamatkan Anda dari mengompresi data yang sudah dikompresi yang tidak akan menjadi lebih kecil, tetapi akan membakar CPU Anda.
  • Teknik load balancing kelas satu. Meskipun bukan peningkatan dalam koneksi titik ke titik, gRPC dapat dengan cerdas memilih backend mana yang akan dikirimi lalu lintas. (ini adalah fitur perpustakaan, bukan fitur protokol kabel). Ini berarti Anda dapat mengirim permintaan Anda ke server backend yang paling sedikit memuat tanpa menggunakan proxy. Ini adalah kemenangan latensi.
  • Sangat dioptimalkan. gRPC (pustaka) berada di bawah tolok ukur berkelanjutan untuk memastikan bahwa tidak ada regresi kecepatan. Tolok ukur tersebut terus meningkat. Sekali lagi, ini tidak ada hubungannya dengan gRPC sebagai protokol, tetapi program Anda akan lebih cepat karena telah menggunakan gRPC.

Seperti yang dikatakan nfirvine, Anda akan melihat sebagian besar peningkatan kinerja Anda hanya dengan menggunakan Protobuf. Meskipun Anda dapat menggunakan proto dengan REST, proto terintegrasi dengan sangat baik dengan gRPC. Secara teknis, Anda dapat menggunakan JSON dengan gRPC, tetapi kebanyakan orang tidak ingin membayar biaya kinerja setelah terbiasa dengan foto.

— Carl Mastrangelo
sumber
Terima kasih @Carl atas jawabannya. Dapatkah Anda membagikan kepada kami beberapa tautan / dokumen yang menjelaskan semua hal di atas dan tautan untuk tolok ukur?
— Lakshman Diwaakar
3
Saya memperbarui tanggapan untuk menautkan ke dasbor. Saya tidak memiliki dokumen yang menjelaskan secara langsung hal ini, tetapi saya adalah kontributor inti.
— Carl Mastrangelo
harap memberikan load balancing libraryLink
— BozoJoe
15

Saya bukan ahli dalam hal ini dengan cara apa pun dan saya tidak memiliki data untuk mendukung semua ini.

"Fitur biner" yang Anda bicarakan adalah representasi biner dari frame HTTP / 2. Konten itu sendiri (payload JSON) akan tetap UTF-8. Anda dapat mengompres JSON itu dan mengaturnya Content-Encoding: gzip, seperti HTTP / 1.

Namun gRPC juga melakukan kompresi gzip. Jadi sungguh, kita berbicara tentang perbedaan antara JSON yang dikompresi dengan gzip vs protobuf yang dikompresi dengan gzip.

Seperti yang bisa Anda bayangkan, protobuf terkompresi harus mengalahkan JSON terkompresi dalam segala hal, atau protobuf gagal mencapai tujuannya.

Selain JSON vs protobufs di mana-mana, satu-satunya downside yang dapat saya lihat untuk menggunakan protobuf adalah Anda memerlukan .proto untuk mendekodekannya, katakanlah dalam situasi tcpdump.

— nfirvine.dll
sumber
1
Terima kasih @nfirvine atas opini Anda atas pertanyaan ini. Fitur serialisasi agak masuk akal. Bisakah Anda menambahkan beberapa detail / penjelasan lebih lanjut tentang bagaimana serialisasi terjadi di REST dan gRPC. Akan sangat bagus, Jika Anda bisa berbagi beberapa tautan yang sama.
— Lakshman Diwaakar
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.