TCP Vs. Chỉ số Benchmark

Question

Tôi đang có một ứng dụng web đang ngồi trên IIS, và nói chuyện với [Remote] Service-Machine. Tôi không chắc chắn nên chọn TCP hay Http, làm giao thức chính. hơn

chi tiết:

2. tôi sẽ có nhiều hơn một dịch vụ \ endpoint
3. một số trong số họ sẽ là một chiều
4. sự khác sẽ được hai cách
5. các trang web sẽ làm việc trước mặt của dịch vụ
6. chúng ta đang nói về hi quy mô trang web

Tôi biết sự khác biệt khá tốt, nhưng tôi đang tìm kiếm một điểm chuẩn tốt, cho thấy TCP nhanh hơn bao nhiêu?

Answer 1

HTTP là lớp được xây dựng ontop của lớp TCP với một số tiêu chuẩn hóa việc truyền dữ liệu. Vì vậy, tự nhiên bằng cách sử dụng TCP socket sẽ ít nặng hơn so với sử dụng HTTP. Nếu hiệu suất là điều duy nhất bạn quan tâm về sau đó đồng bằng TCP là giải pháp tốt nhất cho bạn.

Bạn có thể muốn xem xét HTTP vì tính dễ sử dụng và tính đơn giản giúp giảm thời gian phát triển. Nếu bạn đang làm một cái gì đó có thể được tiêu thụ trực tiếp bởi một trình duyệt (thông qua một cuộc gọi AJAX) thì bạn nên sử dụng HTTP. Đối với một trình duyệt không hiện đại để trực tiếp tiêu thụ các kết nối TCP mà không cần HTTP, bạn sẽ phải sử dụng Flash hoặc Silverlight và điều này thường xảy ra đối với nội dung phong phú như video và/hoặc âm thanh. Tuy nhiên, nhiều trình duyệt hiện đại hiện nay (tính đến năm 2013) hỗ trợ API để truy cập tài nguyên mạng, âm thanh và video trực tiếp thông qua JavaScript. Điều duy nhất cần xem xét là tỷ lệ sử dụng của các trình duyệt web hiện đại trong số người dùng của bạn; xem caniuse.com để biết thông tin mới nhất về khả năng tương thích của trình duyệt.

Đối với điểm chuẩn, this là điều duy nhất tôi tìm thấy. Xem trang 5, nó có biểu đồ hiệu suất. Lưu ý rằng nó không thực sự so sánh táo với táo vì nó so sánh tùy chọn dữ liệu TCP/Binary với tùy chọn dữ liệu HTTP/XML. Điều gì đặt ra câu hỏi: loại dữ liệu nào là dịch vụ của bạn xuất ra? nhị phân (video, âm thanh, tệp) hoặc văn bản (JSON, XML, HTML)?

Trong hệ thống định hướng chung về hiệu suất như trong các lĩnh vực quân sự hoặc tài chính, có thể sẽ sử dụng các kết nối TCP thuần túy. Khi các công ty tập trung vào web nói chung sẽ chọn sử dụng HTTP và sử dụng IIS hoặc Apache để lưu trữ các dịch vụ của họ.

Answer 2

Bạn luôn có thể đo điểm chuẩn. Nói chung, nếu những gì bạn muốn thực hiện có thể dễ dàng thực hiện qua HTTP (nghĩa là lý do duy nhất bạn nghĩ về việc sử dụng TCP thô là để tăng hiệu suất có thể), bạn nên sử dụng HTTP. Chắc chắn, bạn có thể lập trình socket, nhưng tại sao lại bận tâm? Rất nhiều người đã dành rất nhiều thời gian và công sức để xây dựng thư viện máy khách HTTP và máy chủ, và họ đã dành nhiều thời gian hơn để tối ưu hóa và thử nghiệm mã đó hơn bạn sẽ có thể chi tiêu trên các cổng TCP của bạn. Có rất nhiều lỗi có thể xảy ra mà bạn sẽ phải xử lý, các trường hợp cạnh và tối ưu hóa có thể được thực hiện, thường dễ dàng hơn và an toàn hơn khi sử dụng chức năng thư viện cho HTTP.

Ngoài ra, thông số HTTP xác định tất cả các loại đối tượng địa lý (và khách hàng/máy chủ triển khai, mà bạn sử dụng "miễn phí", nghĩa là không có công việc triển khai bổ sung) làm cho khả năng tương tác của bên thứ ba dễ dàng hơn nhiều. "Đây là URL của tôi, dưới đây là các quy tắc cho những gì bạn gửi, dưới đây là các quy tắc cho những gì tôi trả lại ..."

Answer 3

Câu hỏi mà bạn thực sự cần câu trả lời là "sẽ TCP hoặc HTTP nhanh hơn cho của tôi ứng dụng ". Câu trả lời là nó phụ thuộc vào bản chất của ứng dụng của bạn, và trên cách bạn sử dụng TCP và/hoặc HTTP trong ứng dụng của bạn. Điểm chuẩn chung HTTP vs TCP sẽ không trả lời câu hỏi của bạn, bởi vì cơ hội là điểm chuẩn sẽ không phù hợp với hành vi ứng dụng của bạn.

Về lý thuyết, một giải pháp được thiết kế/triển khai tối ưu bằng TCP sẽ nhanh hơn giải pháp sử dụng HTTP. Nhưng nó cũng có thể được nhiều công việc để thực hiện ... tùy thuộc vào các chi tiết của ứng dụng của bạn.

Có các vấn đề khác có thể ảnh hưởng đến lựa chọn của bạn. Ví dụ, bạn ít có khả năng chạy vào các vấn đề tường lửa nếu bạn sử dụng HTTP hơn nếu bạn sử dụng TCP trên một số cổng ngẫu nhiên. Một điều nữa là HTTP sẽ làm cho việc cân bằng tải giữa máy chủ IIS và các hệ thống phụ trợ dễ dàng hơn.

Cuối cùng, vào cuối ngày, có lẽ điều quan trọng hơn là hệ thống của bạn là đáng tin cậy, có thể duy trì và (có thể) có khả năng mở rộng nhanh hơn. Một chiến lược hợp lý là để thực hiện phiên bản đơn giản trước, nhưng có kế hoạch trong đầu của bạn để làm thế nào để làm cho nó nhanh hơn ... nếu giải pháp đơn giản là quá chậm.