Tại sao SNMP thường chạy trên UDP chứ không phải TCP/IP?

Question

Sáng nay, đã có những vấn đề lớn trong công việc vì bẫy SNMP không "đi qua" vì SNMP được chạy trên UDP. Tôi nhớ từ lớp mạng ở trường đại học rằng UDP không được đảm bảo phân phối như TCP/IP. Và Wikipedia nói rằng SNMP có thể chạy trên TCP/IP, nhưng UDP là phổ biến hơn.

Tôi nhận thấy rằng một số ưu điểm của UDP trên TCP/IP là tốc độ, phát sóng và đa hướng. Nhưng có vẻ như với tôi rằng việc phân phối được đảm bảo quan trọng hơn đối với việc giám sát mạng hơn khả năng phát sóng. Đặc biệt khi có nhu cầu bảo mật cao nghiêm trọng. Một trong những đồng nghiệp của tôi nói với tôi rằng các gói UDP là gói đầu tiên bị loại bỏ khi lưu lượng truy cập bị nặng. Đó là một lý do khác để thích TCP/IP hơn UDP cho giám sát mạng (IMO).

Vậy tại sao SNMP sử dụng UDP? Tôi không thể tìm ra và cũng không thể tìm được lý do chính đáng trên Google.

Answer 1

UDP thực sự được mong đợi hoạt động tốt hơn TCP trong các mạng bị mất (hoặc mạng bị tắc nghẽn). TCP là tốt hơn nhiều trong việc chuyển số lượng lớn dữ liệu, nhưng khi mạng bị lỗi thì có nhiều khả năng UDP sẽ vượt qua được. (trên thực tế, gần đây tôi đã thực hiện một nghiên cứu thử nghiệm điều này và nó thấy rằng SNMP trên UDP đã thành công tốt hơn SNMP trên TCP trong các mạng bị mất khi thời gian chờ UDP được đặt đúng). Nói chung, TCP bắt đầu hoạt động kém với khoảng 5% mất gói và trở nên hoàn toàn vô dụng ở mức 33% (ish) và UDP vẫn sẽ thành công (cuối cùng).

Vì vậy, điều phải làm, như mọi khi, là chọn đúng công cụ cho đúng công việc. Nếu bạn đang theo dõi thường xuyên nhiều dữ liệu, bạn có thể xem xét TCP. Nhưng hãy sẵn sàng để quay trở lại UDP để khắc phục vấn đề. Hầu hết các ngăn xếp những ngày này thực sự có thể sử dụng cả TCP và UDP.

Đối với việc gửi TRAP, có TRAP không đáng tin cậy vì chúng không được xác nhận. Tuy nhiên, SNMP INFORMs là một phiên bản được thừa nhận của SNMP TRAP. Vì vậy, nếu bạn muốn biết rằng người nhận thông báo đã nhận được tin nhắn, vui lòng sử dụng INFORM. Lưu ý rằng TCP không không phải giải quyết vấn đề này vì nó chỉ cung cấp thông báo mức 3 lớp mà thông báo đã được nhận. Không có đảm bảo rằng người nhận thông báo thực sự đã nhận được nó. SNMP INFORMs thực hiện xác nhận mức ứng dụng và đáng tin cậy hơn nhiều so với giả định một TCP ack cho biết họ đã nhận được nó.

Answer 2

Việc sử dụng bẫy với SNMP được coi là không đáng tin cậy. Bạn thực sự không nên dựa vào bẫy.

SNMP được thiết kế để sử dụng làm giao thức yêu cầu/phản hồi. Các chi tiết giao thức rất đơn giản (do đó tên, "giao thức quản lý mạng đơn giản"). Và UDP là một phương tiện vận chuyển rất đơn giản. Hãy thử triển khai TCP trên tác nhân cơ bản của bạn - nó phức tạp hơn nhiều so với một tác nhân đơn giản được mã hóa bằng UDP.

Hoạt động SNMP get/getnext có cơ chế thử lại - nếu không nhận được phản hồi trong thời gian chờ thì yêu cầu tương tự sẽ được gửi tới số lần thử tối đa.

Answer 3

Kiểm tra các tác phẩm của O'Reilly trên SNMP: https://library.oreilly.com/book/9780596008406/essential-snmp/18.xhtml

Một lợi thế của việc sử dụng UDP để bẫy SNMP là bạn có thể trực tiếp UDP tới một địa chỉ quảng bá, và sau đó trường chúng với nhiều trạm quản lý trên subnet đó.

Answer 4

Nếu hệ thống đã gửi bẫy SNMP qua TCP, chúng có thể chặn chờ các gói được ACKed nếu có sự cố khi nhận lưu lượng truy cập đến người nhận. Nếu có rất nhiều bẫy được tạo ra, nó có thể sử dụng hết các ổ cắm sẵn có trên hệ thống và hệ thống sẽ khóa lại. Với UDP không phải là một vấn đề vì nó là không trạng thái.Một vấn đề tương tự đã xảy ra với BitBucket vào tháng 1 mặc dù giao thức syslog thay vì SNMP - về cơ bản, họ vô tình sử dụng syslog qua TCP do lỗi cấu hình, máy chủ syslog bị hỏng và tất cả các máy chủ bị khóa chờ syslog máy chủ để ACK gói của họ. Nếu bẫy SNMP được gửi qua TCP, một vấn đề tương tự có thể xảy ra.

http://blog.bitbucket.org/2012/01/12/follow-up-on-our-downtime-last-week/