So sánh các ứng dụng TCP / IP với các ứng dụng HTTP [đã đóng]


13

Tôi quan tâm đến việc phát triển một trang web hướng tới người dùng quy mô lớn được viết bằng Java.

Về thiết kế, tôi đang nghĩ đến việc phát triển các dịch vụ mô-đun độc lập có thể đóng vai trò là nhà cung cấp dữ liệu cho ứng dụng web chính của mình.

Đối với việc viết các dịch vụ mô-đun này (nhà cung cấp dữ liệu), tôi có thể tận dụng một khung công tác hiện có như Spring và phát triển các dịch vụ này theo mẫu thiết kế RESTful và hiển thị tài nguyên qua HTTP với định dạng thông báo như JSON ... hoặc tôi có thể tận dụng mạng hiện có khung như Netty ( http://netty.io/ ) và định dạng tuần tự hóa như Protobufs ( https://developers.google.com/protatio-buffers/docs/overview ) và phát triển máy chủ TCP gửi qua lại protobuf được tuần tự hóa khối hàng.

Khi nào bạn nên chọn cái này hơn cái kia? Sẽ có bất kỳ lợi ích của việc sử dụng một định dạng tuần tự hóa như Protobuf và gửi luồng byte qua dây không? Sẽ có chi phí sử dụng JSON không? Có bao nhiêu chi phí giữa việc sử dụng TCP / IP và sử dụng HTTP? Khi nào bạn nên sử dụng Spring over Netty và ngược lại để xây dựng một dịch vụ như vậy?


Có vẻ như bạn đang nghĩ nhiều hơn về ngăn xếp công nghệ hơn là về các yêu cầu thực tế. Làm thế nào bất cứ ai trong chúng ta có thể trả lời câu hỏi này mà không biết bạn cần phải làm gì ? Bạn có đang tạo một trò chơi nhiều người chơi có độ trễ gần như bằng không? Hoặc một ứng dụng đánh dấu trang xã hội nơi hầu hết quyền truy cập đã qua HTTP và bạn có thể lưu trữ dữ liệu trong nhiều giờ liền và thậm chí không quan tâm đến độ mới, chứ đừng nói đến độ trễ?
Aaronaught

3
Tôi không nghĩ OP đang yêu cầu chúng tôi đưa ra lựa chọn cho anh ấy. Anh ta chỉ đơn giản là hỏi một câu hỏi cấp cao về cách lựa chọn như vậy được thực hiện và những yếu tố được xem xét. Đừng nghĩ có gì sai khi đưa ra câu trả lời cấp cao cho điều đó .... và tôi đã làm.
DXM

Tôi thường phản đối việc sử dụng các định dạng nhị phân trừ khi bạn thực sự phải làm. Không có định dạng tệp nhị phân, không có tuần tự hóa nhị phân, v.v. Ví dụ, trong Java, tuần tự hóa nhị phân gây ra sự không tương thích giữa các phiên bản Java và các phiên bản phần mềm của riêng bạn, nhưng tôi tin rằng XML không nhiều như vậy. Tôi nghĩ rằng TCP / IP> HTTP> XML sau đây Tất nhiên, nó sẽ phụ thuộc vào những gì bạn đang làm. Tôi nghĩ rằng JSON là một thay thế cho XML. Tôi không biết nhiều về Spring hay Netty, mặc dù tôi đọc rằng mọi người đang sử dụng Spring.
Kaydell

+1 DXM, tôi đang đặt câu hỏi cấp cao làm thức ăn cho suy nghĩ khi nghĩ về việc đưa ra quyết định như vậy.
HiChews123

Câu trả lời:


21

Chắc chắn có những ưu / nhược điểm về việc sử dụng JSON so với REST so với TCP / IP ngay lập tức với giao thức nhị phân và tôi nghĩ rằng bạn đã nghi ngờ rằng giao thức nhị phân sẽ nhanh hơn. Tôi không thể cho bạn biết chính xác tốc độ của nó nhanh hơn bao nhiêu (và điều này phụ thuộc vào rất nhiều yếu tố), nhưng tôi đoán có thể là 1-2 đơn hàng chênh lệch cường độ.

Thoạt nhìn nếu một thứ gì đó chậm hơn 10 - 100 lần so với thứ khác, bạn có thể có phản ứng giật đầu gối và đi tìm "điều nhanh". Tuy nhiên, sự khác biệt tốc độ này chỉ có trong chính giao thức. Nếu có quyền truy cập cơ sở dữ liệu / tệp ở phía máy chủ, điều đó sẽ không bị ảnh hưởng bởi sự lựa chọn của bạn về lớp chuyển. Trong một số trường hợp, nó có thể làm cho tốc độ lớp chuyển của bạn giảm đi đáng kể.

HTTP REST và JSON tốt cho một số lý do:

  • chúng dễ dàng được tiêu thụ bởi bất cứ ai. Bạn có thể viết Ứng dụng web của mình, sau đó quay lại và xuất bản API của mình cho phần còn lại của thế giới sử dụng. Bây giờ bất cứ ai cũng có thể đạt được điểm cuối tương tự và nhận được dịch vụ của bạn
  • chúng có thể dễ dàng gỡ lỗi, bạn có thể mở gói sniffer hoặc đơn giản là đổ các yêu cầu đến vào tệp văn bản và xem điều gì đang xảy ra. Bạn không thể làm điều đó với các giao thức nhị phân
  • chúng có thể dễ dàng mở rộng. Bạn có thể thêm nhiều thuộc tính và dữ liệu sau đó và không phá vỡ tính tương thích với các máy khách cũ.
  • có thể sử dụng bởi các ứng dụng khách javascript (chưa chắc họ đã có trình phân tích cú pháp JS protobuf chưa, không tin là có)

Protobufs qua TCP / IP:

  • chúng nhanh hơn

Nếu đó là lựa chọn của tôi, tôi sẽ thực hiện với HTTP REST và JSON. Có một lý do mà rất nhiều công ty và trang web khác đã đi theo con đường đó. Ngoài ra, hãy nhớ rằng trong tương lai bạn luôn có thể hỗ trợ 2 điểm cuối. Nếu thiết kế của bạn là chính xác, lựa chọn điểm cuối của bạn sẽ được tách rời hoàn toàn khỏi logic nghiệp vụ phía máy chủ hoặc cơ sở dữ liệu. Vì vậy, nếu sau này bạn nhận ra rằng bạn cần nhiều tốc độ hơn cho tất cả / một số yêu cầu, bạn sẽ có thể thêm protobuf với sự phiền phức tối thiểu. Tuy nhiên, ngay lập tức, REST / JSON sẽ đưa bạn lên mặt đất nhanh hơn và đưa bạn đi xa hơn.

Theo như Netty vs Spring đi. Tôi đã không sử dụng Netty trực tiếp, nhưng tôi tin rằng đây chỉ là một máy chủ web nhẹ trong khi Spring là một khung cung cấp nhiều thứ cho bạn hơn thế. Nó có các lớp truy cập dữ liệu, lập lịch công việc nền và (tôi nghĩ) một mô hình MVC, vì vậy nó nặng hơn nhiều. Chọn cái nào? Nếu bạn quyết định đi theo con đường HTTP, thì câu hỏi tiếp theo có lẽ là ứng dụng của bạn chuẩn như thế nào? Nếu bạn chuẩn bị viết một số logic tùy chỉnh điên rồ không phù hợp với khuôn chuẩn và tất cả những gì bạn cần chỉ là một lớp máy chủ HTTP, hãy đi với Netty.

Tuy nhiên, tôi nghi ngờ ứng dụng của bạn không có gì đặc biệt và nó có thể có lợi từ rất nhiều thứ mà Spring phải cung cấp. Nhưng điều đó có nghĩa là bạn nên cấu trúc ứng dụng của mình xung quanh khuôn khổ của Spring và làm mọi thứ theo cách họ mong đợi bạn làm, điều đó có nghĩa là tìm hiểu thêm về Spring trước khi đi sâu vào sản phẩm của bạn. Các khung nói chung là tuyệt vời vì một lần nữa chúng đưa bạn lên mặt đất nhanh hơn, nhưng nhược điểm là bạn phải phù hợp với khuôn của chúng thay vì thiết kế của riêng bạn và sau đó mong đợi khung chỉ hoạt động.

(*) - trước đây người ta chỉ ra rằng các bài đăng của tôi không phản ánh ý kiến ​​của toàn thế giới, vì vậy tôi sẽ ghi lại và chỉ nói thêm rằng tôi có kinh nghiệm hạn chế với Netty (Tôi đã sử dụng Play framework trước đây dựa trên Netty) hoặc Spring (Tôi chỉ đọc về nó). Vì vậy, lấy những gì tôi nói với một hạt muối.


1
+1, đặc biệt là "sự khác biệt tốc độ này chỉ có trong chính giao thức. Nếu có quyền truy cập cơ sở dữ liệu / tệp ở phía máy chủ, điều đó sẽ không bị ảnh hưởng bởi sự lựa chọn của bạn về lớp chuyển". 99% đó chính xác là nó sẽ như thế nào và tối ưu hóa sớm (không đúng chỗ) sẽ không giúp ích gì cả.
Shivan Dragon

Cảm ơn bạn đã trả lời dài dòng và phân tích sâu về so sánh hai. Tôi hiểu những lợi ích của việc xây dựng một ứng dụng RESTful bởi vì nó dễ dàng được sử dụng bởi các khách hàng công cộng. Tuy nhiên, trong trường hợp tôi muốn giữ mọi thứ trong nhà và không muốn phơi bày dịch vụ (tôi quan tâm đến việc tuần tự hóa / giải tuần tự hóa), tôi không thể hiểu tại sao không sử dụng giao thức nhị phân tùy chỉnh sẽ không phải là lựa chọn đầu tiên. Có, bạn có thể khởi đầu nhanh hơn với các khung hiện có, nhưng với chi phí bị khóa trong API của họ và kiểm soát chi tiết kém hơn.
HiChews123

REST rất dễ tiêu thụ bởi TẤT CẢ khách hàng, không chỉ những khách hàng công cộng, mà chắc chắn chúng được bao gồm. Công ty của tôi có một sản phẩm mà chúng tôi đã xây dựng khoảng một năm nay. Chúng tôi đã có giao thức "độc quyền" đã được nghỉ ngơi. Chúng tôi chỉ mở nó cho người khác. Một điều họ dạy bạn ở trường kinh doanh là "tư duy lựa chọn", đưa ra quyết định để lại cho bạn càng nhiều lựa chọn càng tốt để bạn có thể đưa ra quyết định vào một ngày sau đó. Vì vậy, với tất cả các thiết lập bằng nhau, tôi chọn REST không phải vì tôi có máy khách JS hoặc quyền truy cập API ngày hôm nay, mà tôi có tùy chọn có nó trong tương lai nếu tôi cần. Sau đó, một lần nữa, nếu ...
DXM

... bạn đã sẵn sàng sử dụng giao thức nhị phân, hãy tiếp tục. 96% khả năng lựa chọn giao thức của bạn sẽ không ảnh hưởng gì đến ứng dụng cuối cùng của bạn, vì vậy tôi sẽ không tiết lộ quyết định đó quá nhiều. Và như tôi đã nói trong câu trả lời, với thiết kế hợp lý, bạn sẽ có thể trao đổi các giao thức vào một ngày sau đó. Một điều khác tôi muốn làm là thử cả hai trường hợp, nếu tôi quyết định đưa ra quyết định, tôi lật một đồng xu và chọn tùy chọn A. Lần sau tôi làm một dự án tương tự tôi chọn tùy chọn B để tôi có thể quay lại và so sánh / đối chiếu kinh nghiệm của tôi. Đôi khi, đó là cách duy nhất bạn tự quyết định điều đó tốt hơn
DXM

@DXM, phản hồi tuyệt vời, bravo!
HiChews123

0

Đây thực sự là một câu hỏi không. Theo bộ giao thức Internet tcp là một giao thức trong lớp vận chuyển và http là một giao thức trong lớp ứng dụng. Bạn đang so sánh những điều hoàn toàn khác nhau với nhau. (Xem thêm tại đây: http://en.wikipedia.org/wiki/INET_protatio_suite )

Trong thực tế, hầu hết http là trên tcp / ip. Vì vậy, để trả lời câu hỏi của bạn, có, bạn nên sử dụng tcp / ip. Sau đó, bạn muốn thêm một giao thức lớp ứng dụng qua đó (như http) và sau đó là định dạng dữ liệu (như json, xml, html). Netty cho phép bạn sử dụng http và protobuff bằng json, xml, html.

Tất cả phụ thuộc vào yêu cầu của bạn là gì và loại dữ liệu bạn sẽ cần vận chuyển. Bạn có cần các phiên trong protocoll của mình không, một cái bắt tay có thể cải thiện cấu hình giao thức của bạn không, bạn sẽ gửi bao nhiêu dữ liệu cùng một lúc, bạn có cần mã hóa không? Đây là những câu hỏi bạn cần trả lời khi chọn một giao thức ứng dụng.

Để chọn định dạng biểu diễn dữ liệu (json, xml, html, protobuff, v.v.), nó phụ thuộc vào băng thông, khả năng đọc, hỗ trợ ngôn ngữ / công cụ của bạn, v.v.

Bạn không thể so sánh http với tcp.

Hãy nhớ rằng tốc độ không phải là tất cả. Tốc độ là không có ích nếu bạn không thể thể hiện bản thân một cách hợp lý.


5
Không có gì trong câu hỏi của anh ấy cho thấy anh ấy không biết sự khác biệt giữa các lớp của ngăn xếp mạng. Anh ta hỏi anh ta nên sử dụng HTTP (thực tế là HTTP là một lớp trên TCP / IP được giả định) hoặc sử dụng TCP / IP với giao thức tùy chỉnh của riêng anh ta. Không có gì sai với câu hỏi của anh ấy.
Michael

Tôi không đồng ý tất nhiên. Đó không phải là cách tôi hiểu anh ấy
iveqy

1
Vâng, tôi hiểu rằng HTTP nằm ở tầng trên TCP / IP, câu hỏi của tôi thực sự là về suy nghĩ về việc đưa ra quyết định về sự đánh đổi - độ trễ, tốc độ phát triển, v.v ... Tuy nhiên, cảm ơn bạn đã đặt câu hỏi cho tôi!
HiChews123

2
@ acspd7 Tôi sẽ tránh tạo ra protocoll của riêng bạn, có rất nhiều protocoll đã được chứng minh ngoài đó và trừ khi protocoll của bạn là thứ mang lại lợi thế cho đối thủ, bạn có lẽ tốt hơn với protocoll tiêu chuẩn. Tôi đã thực hiện một protocoll tùy chỉnh, nó rất thú vị! Tuy nhiên, mã hóa, bấm lỗ, giữ bí mật, bắt tay (các mạng khác nhau đòi hỏi tốc độ khung hình khác nhau), v.v ... đó là rất nhiều công việc để làm việc tốt. Chưa kể tất cả các tài liệu bạn sẽ cần. Hãy suy nghĩ về những gì bạn thực sự cần trong các tính năng trước khi làm một cái gì đó tùy chỉnh.
iveqy

1
GPB được ghi chép tốt, được sử dụng bởi nhiều người khác vì vậy tôi thực sự không thể thấy bất kỳ vấn đề nào khi sử dụng nó. Nuôi ong ngắn gọn hơn XML và JSON sẽ rất tuyệt! (bạn có thể thiếu khả năng đọc của con người, nhưng nếu đó không phải là một yêu cầu ...). Tuy nhiên, bạn không bỏ lỡ một lớp? Thông thường bạn có một lớp giữa tcp và xml, json, protobuff. Một cái gì đó như http, ssh, v.v.
iveqy
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.