GRPC (HTTP / 2) có nhanh hơn REST với HTTP / 2 không?

Mục đích là giới thiệu một giao thức lớp ứng dụng và truyền tải tốt hơn về độ trễ và thông lượng mạng . Hiện tại, ứng dụng sử dụng REST với HTTP / 1.1 và chúng tôi gặp độ trễ cao. Tôi cần giải quyết vấn đề độ trễ này và tôi sẵn sàng sử dụng gRPC (HTTP / 2) hoặc REST / HTTP2 .

HTTP / 2:

1. Đa kênh
2. Kết nối TCP đơn
3. Nhị phân thay vì văn bản
4. Nén tiêu đề
5. Đẩy máy chủ

Tôi nhận thức được tất cả những lợi thế trên. Câu hỏi số 1: Nếu tôi sử dụng REST với HTTP / 2 , tôi chắc chắn rằng tôi sẽ nhận được sự cải thiện hiệu suất đáng kể khi so sánh với REST với HTTP / 1.1 , nhưng điều này so với gRPC (HTTP / 2) như thế nào?

Tôi cũng biết rằng gRPC sử dụng bộ đệm proto, đây là kỹ thuật tuần tự hóa nhị phân tốt nhất để truyền dữ liệu có cấu trúc trên dây. Bộ đệm Proto cũng giúp phát triển một cách tiếp cận ngôn ngữ bất khả tri. Tôi đồng ý với điều đó và tôi có thể triển khai tính năng tương tự trong REST bằng graphQL. Nhưng mối quan tâm của tôi là quá trình tuần tự hóa: Câu hỏi số 2: Khi HTTP / 2 triển khai tính năng nhị phân này , việc sử dụng bộ đệm proto có mang lại lợi thế bổ sung cho HTTP / 2 không?

Câu hỏi số 3: Về phương diện phân luồng, trường hợp sử dụng hai chiều , gRPC (HTTP / 2) so với (REST và HTTP / 2) như thế nào?

Có rất nhiều blog / video trên internet so sánh gRPC (HTTP / 2) với (REST và HTTP / 1.1) như thế này . Như đã nêu trước đó, tôi muốn biết sự khác biệt, lợi ích khi so sánh GRPC (HTTP / 2) và (REST với HTTP / 2).

gRPC không nhanh hơn REST qua HTTP / 2 theo mặc định, nhưng nó cung cấp cho bạn các công cụ để làm cho nó nhanh hơn. Có một số điều sẽ khó hoặc không thể làm được với REST.

• Nén tin nhắn có chọn lọc. Trong gRPC, một RPC phát trực tuyến có thể quyết định nén hoặc không nén thông báo. Ví dụ: nếu bạn đang truyền trực tuyến văn bản và hình ảnh hỗn hợp qua một luồng duy nhất (hoặc thực sự là bất kỳ nội dung có thể nén hỗn hợp nào), bạn có thể tắt tính năng nén cho hình ảnh. Điều này giúp bạn không phải nén dữ liệu đã được nén, dữ liệu này sẽ không nhỏ hơn nhưng sẽ đốt cháy CPU của bạn.
• Cân bằng tải hạng nhất. Mặc dù không phải là một cải tiến về kết nối điểm tới điểm, nhưng gRPC có thể chọn phụ trợ một cách thông minh để gửi lưu lượng truy cập đến. (đây là một tính năng thư viện, không phải là một tính năng giao thức dây). Điều này có nghĩa là bạn có thể gửi yêu cầu của mình đến máy chủ phụ trợ ít tải nhất mà không cần sử dụng proxy. Đây là một chiến thắng có độ trễ.
• Được tối ưu hóa rất nhiều. gRPC (thư viện) nằm trong các điểm chuẩn liên tục để đảm bảo rằng không có sự hồi quy tốc độ. Những điểm chuẩn đó đang được cải thiện liên tục. Một lần nữa, điều này không liên quan gì đến giao thức gRPC, nhưng chương trình của bạn sẽ nhanh hơn khi sử dụng gRPC.

Như nfirvine đã nói, bạn sẽ thấy hầu hết sự cải thiện hiệu suất của mình chỉ từ việc sử dụng Protobuf. Trong khi bạn có thể sử dụng proto với REST, nó được tích hợp rất độc đáo với gRPC. Về mặt kỹ thuật, bạn có thể sử dụng JSON với gRPC, nhưng hầu hết mọi người không muốn trả chi phí hiệu suất sau khi quen với protos.

Tôi không phải là chuyên gia về vấn đề này và tôi không có dữ liệu nào để sao lưu bất kỳ điều gì.

"Tính năng nhị phân" mà bạn đang nói đến là biểu diễn nhị phân của khung HTTP / 2. Bản thân nội dung (tải trọng JSON) sẽ vẫn là UTF-8. Bạn có thể nén JSON đó và đặt Content-Encoding: gzip, giống như HTTP / 1.

Nhưng gRPC cũng thực hiện nén gzip. Vì vậy, thực sự, chúng ta đang nói về sự khác biệt giữa JSON nén gzip và protobufs nén gzip.

Như bạn có thể tưởng tượng, các protobufs nén sẽ đánh bại JSON nén theo mọi cách, nếu không các protobufs đã không đạt được mục tiêu của chúng.

Bên cạnh sự phổ biến của JSON và protobufs, nhược điểm duy nhất mà tôi có thể thấy khi sử dụng protobufs là bạn cần .proto để giải mã chúng, chẳng hạn như trong tình huống tcpdump.