Tôi muốn biết chi phí chung của việc tạo kết nối mới, so với UDP. Tôi biết TCP yêu cầu trao đổi ban đầu các gói (bắt tay 3 chiều). Chi phí khác là gì? Ví dụ là có một số loại ma thuật trong hạt nhân cần thiết để thiết lập bộ đệm, vv?Tổng phí tạo kết nối TCP
Lý do tôi hỏi là tôi có thể giữ kết nối hiện tại đang mở và sử dụng lại khi cần. Tuy nhiên nếu có ít chi phí kết nối lại nó sẽ làm giảm độ phức tạp.
So với độ trễ của trao đổi gói, tất cả các chi phí khác như thời gian thiết lập hạt nhân là không đáng kể.
Sau khi gói UDP được đổ vào dây, ngăn xếp giao thức UDP là hoàn toàn miễn phí để quên nó đi. Với TCP, có tối thiểu chi tiết kết nối (nguồn/cổng đích và nguồn/đích IP), số thứ tự, kích thước cửa sổ cho kết nối, v.v ... Nó không phải là một lượng dữ liệu khổng lồ, nhưng tăng lên nhanh chóng trên một máy chủ bận rộn với nhiều kết nối.
Và sau đó là bắt tay 3 chiều. Một số braindead (và/hoặc hệ thống độc hại) có thể lạm dụng quy trình (tra cứu 'syn flood'), hoặc chỉ thả kết nối vào cuối, để hệ thống của bạn chờ phản hồi hoặc thông báo gần sẽ không bao giờ đến. Bên cạnh đó là với TCP, hệ thống sẽ làm hết sức mình để đảm bảo gói tin nhận được gói dữ liệu. Với UDP, không có gì đảm bảo cả.
OPTION 1: Chi phí chung của việc tạo ra một kết nối TCP là:
Bước 1: Yêu cầu trao đổi các gói, do đó, nó bị trễ bởi & từ độ trễ mạng cộng với thời gian dịch vụ của máy chủ đích. Không có sử dụng CPU đáng kể trên một trong hai hộp có liên quan.
Bước 2: Tùy thuộc vào kích thước của thư.
Bước 3: IIRC, chỉ gửi gói 'đóng ngay bây giờ', không đợi mã ack đích, do đó không có thời gian chờ.
OPTION 2: Chi phí UDP: *
Bước 1: Yêu cầu thiết lập tối thiểu, không phải lo lắng trễ , rất nhanh.
Bước 2: HÃY CẨN THẬN SIZE, không có truyền lại trong UDP vì nó không quan tâm liệu gói có được nhận bởi bất kỳ ai hay không. Tôi đã nghe nói rằng thông điệp càng lớn thì khả năng nhận dữ liệu càng lớn và quy tắc chung là bạn sẽ mất một tỷ lệ phần trăm tin nhắn nhất định trên 20 MB.
Bước 3: Công việc tối thiểu, thời gian tối thiểu.
OPTION 3: Sử dụng ZeroMQ Thay vào đó
Bạn đang so sánh TCP để UDP với mục tiêu giảm thời gian kết nối lại. ĐÂY LÀ MỘT GỢI Ý NICE: Ổ cắm ZeroMQ.
ZMQ cho phép bạn thiết lập ổ cắm xuất bản mà bạn không quan tâm nếu có ai đang nghe (như UDP) và có nhiều người nghe trên ổ cắm đó. Đây không phải là một ổ cắm UDP - nó là một thay thế cho cả hai giao thức này.
Xem: ZeroMQ.org để biết chi tiết.
Tốc độ rất cao và khả năng chịu lỗi, và đang gia tăng sử dụng trong ngành tài chính vì những lý do đó.
Tôi không chắc chắn nơi bạn có số lượng 20MB cho UDP. Trong IPV4, kích thước tin nhắn tối đa là 65.507 byte (65.535 - 8 byte tiêu đề UDP - tiêu đề IP 20 byte), theo Wikipedia. Có lẽ bạn đang giả định IPV6? – Joe
Tôi đã không đề cập đến kích thước gói, nhưng kích thước tin nhắn. Thêm vào đó, con số này là một tin đồn phỏng đoán. Tình hình: trên một mạng trung tâm dữ liệu nội bộ tốc độ cao hợp lý thông qua UDP, trong bất kỳ bộ N tin nhắn có kích thước 20 MB, 5% N (N * 0,05) của chúng bị hỏng. Đây là một firehose w/HUGE dữ liệu một-> một số, với bộ khác nhau của hộp nghe tin nhắn gửi đến cho họ. Xin lỗi vì sự nhầm lẫn. Thông điệp của anh ấy (đồng nghiệp của tôi) với tôi là nếu anh ấy sử dụng những phần lớn hơn, tỷ lệ phần trăm cao hơn sẽ có lỗi và không có gì sẽ gửi. Anh ta có một backchannel để yêu cầu gửi lại. –
UDP không có khái niệm về thông báo lớn hơn một gói dữ liệu 64k duy nhất, bởi vì trường kích thước trong tiêu đề UDP là 16 bit (https://tools.ietf.org/html/rfc768). Điều đó thường lớn hơn MTU của tầng truyền tải cơ bản, vì vậy IP sẽ có khả năng phân mảnh và lắp ráp lại một gói 64k. Nếu bất kỳ mảnh nào bị mất, toàn bộ gói bị mất, vì vậy vượt quá MTU không được khuyến nghị. Một thông báo 20MB yêu cầu một giao thức mức cao hơn UDP hoặc một cái gì đó khác như TCP. Nếu bạn có một tham chiếu cho các tin nhắn lớn hơn, tôi quan tâm để đọc nó. – Joe
Tôi nghĩ độ trễ của cái bắt tay là chi phí đáng kể nhất. – CodesInChaos
Ahh điểm tốt. Kết nối không được coi là mở cho đến khi toàn bộ bắt tay hoàn thành. Tuy nhiên sau khi mở, bạn có thể phát trực tuyến dữ liệu mà không cần đợi mã ACK trên mỗi đoạn (vì cửa sổ trượt) – seand
không có 'ack trên mỗi đoạn'. – EJP