Dự án chuyển tệp udp - có cần kiểm tra lỗi không?

Question

Tôi đã được giao nhiệm vụ cổ điển để truyền tệp bằng UDP. Trên các tài nguyên khác nhau, tôi đã đọc cả kiểm tra lỗi trên gói (thêm CRC cùng với dữ liệu vào gói) là cần thiết VÀ UDP đã kiểm tra các gói bị hỏng và loại bỏ chúng, vì vậy tôi chỉ cần lo lắng về việc gửi lại các gói đã bị hủy.

Điều nào trong số đó là chính xác? Tôi có cần phải tự thực hiện kiểm tra tính toàn vẹn trên các gói dữ liệu đến hoặc các gói không chính xác đã bị loại bỏ không?

Ngôn ngữ cho dự án là Java bằng cách này.

CHỈNH SỬA: Một số nguồn (sách giáo khoa, internet) cho biết tổng kiểm tra chỉ bao gồm tiêu đề, do đó đảm bảo IP của người gửi và người nhận là chính xác vv .. Một số nguồn nói là checksum cũng bao gồm phân đoạn dữ liệu. Một số nguồn cho biết checksum có thể phân đoạn dữ liệu bìa NHƯNG tùy chọn và quyết định bởi hệ điều hành.

EDIT 2: Đã hỏi giáo sư của tôi và họ nói kiểm tra lỗi UDP trên phân đoạn dữ liệu là tùy chọn trong IPv4, defauld trong IPv6. Nhưng tôi vẫn không biết liệu nó có thuộc quyền kiểm soát của lập trình viên hay hệ điều hành hay một lớp khác ...

Answer 1

Thực tế đầu tiên:

UDP có trường kiểm tra 16 bit bắt đầu từ bit 40 của tiêu đề gói.Đây bị (ít nhất) 2 điểm yếu:

• Checksum là không bắt buộc, tất cả các bit đặt thành 0 được định nghĩa là "Không checksum"
• nó là một 16 bit Trả phòng tổng theo nghĩa hẹp của từ, vì vậy nó dễ bị hư hỏng không bị phát hiện.

Điều này đồng nghĩa với việc tổng kiểm tra tích hợp của UDP có thể hoặc không đủ tin cậy, tùy thuộc vào môi trường của bạn.

thực tế thứ hai:

Một mối đe dọa thậm chí thực tế hơn courruption dữ liệu dọc theo giao thông là mất gói sắp xếp lại: USP không đảm bảo về

• tất cả các gói đến (cuối cùng) đến tất cả
• các gói để đến cùng một chuỗi như được gửi

thực sự UDP không có cơ chế tích hợp để xử lý tải trọng lớn hơn gói duy nhất, xuất phát từ thực tế, rằng nó không được xây dựng cho điều đó.

Kết luận:

Phụ thêm gói sau khi gói như nhận được mà không cần các biện pháp bổ sung là bị ràng buộc để tạo ra một nhận dòng khác nhau từ send suối trong tất cả các môi trường rất favourablest, làm cho nó một ít hơn giao thức tối ưu cho tập tin trực tiếp. chuyển khoản.

Nếu bạn làm muốn hoặc phải sử dụng UDP để chuyển tệp, bạn cần phải xây dựng các phần đó, không thể thiếu trong TCP mà không phải UDP vào ứng dụng. Có một câu nói mặc dù, rằng điều này rất có thể sẽ dẫn đến một reimplementation inefrior của TCP.

Triển khai thành công bao gồm nhiều giao thức chia sẻ tệp ngang hàng, nơi bảo vệ chống gián đoạn kết nối và mất gói hoặc sắp xếp lại cần phải là một phần của chức năng apllication để đánh bại hoặc giảm thiểu bộ lọc.

khuyến nghị thực hiện:

gì đã làm việc cho chúng ta là một thực hiện cửa sổ chunked: Tải trọng được tách ra thành những phần có chiều dài cố định và thuận tiện, (chúng tôi sử dụng 1023 byte) một mảng tình trạng của N khối như được giữ vào cuối gửi và nhận.

Về phía gửi:

• Một UDP thông điệp được inititated, có chứa một đoạn như vậy, số thứ tự của nó (nhiều hơn một lần) trong dòng và một checksum hoặc băm.
• Các vết mảng tình trạng đoạn này là "gửi/chờ" với timestamp
• Gửi điểm dừng, nếu mảng tình trạng đầy đủ (gửi cửa sổ) được tiêu thụ

Về phía nhận:

• các gói đã nhận được kiểm tra với tổng kiểm tra của họ,
• gói bị hỏng được negativly thừa nhận nếu tất cả các bản sao của số thứ tự đồng ý, bỏ khác
• Các gói OK được đánh dấu trong mảng trạng thái là "đã nhận/đang chờ xử lý" với dấu thời gian
• Lời cảm ơn hoạt động bằng cách gửi gói ack nếu đủ khối nhận được để điền vào gói ack hoặc dấu thời gian của dấu "nhận/đang chờ xử lý "phát triển quá cũ (một số ms đến khoảng 100ms).
• Gói Ack cần kiểm tra, nhưng không cần giải trình tự.
• Chunks, mà một ack đã được gửi đi, được đánh dấu là "ack/chờ" với timestamp trong mảng tình trạng

Về phía gửi:

• gói Ack được tiếp nhận và kiểm tra , các gói bị hỏng bị loại bỏ
• Các khối, đã nhận được ack, được đánh dấu là "ack/done" trong mảng trạng thái
• Nếu đoạn đầu tiên trong mảng trạng thái được đánh dấu "ack/done", trạng thái mảng trượt lên, cho đến khi đoạn đầu tiên của nó một lần nữa không được thực hiện.
• Điều này có thể phát hành một hoặc nhiều đoạn chưa gửi được gửi đi.
• cho các phần trong trạng thái "đã gửi/đang chờ xử lý", thời gian chờ trên dấu thời gian kích hoạt gửi mới cho đoạn này, vì đoạn gốc có thể đã bị mất.

Về phía nhận:

• Tiếp nhận đoạn i + N (N là chiều rộng cửa sổ) đánh dấu đoạn i như ack thực hiện, trượt lên cửa sổ/nhận. Nếu không phải tất cả các khối trượt ra khỏi cửa sổ nhận được được làm thành "ack/pending", đây là lỗi không thể khôi phục.
• cho các đoạn trong trạng thái "ack/pending", một thời gian chờ trên dấu thời gian kích hoạt mã mới cho đoạn này, vì thư ack gốc có thể đã bị mất.

Rõ ràng là cần có một loại thông báo đặc biệt từ phía gửi, nếu cửa sổ gửi trượt ra cuối tệp, để nhận tín hiệu ACK mà không gửi đoạn N + i, chúng tôi đã triển khai chỉ đơn giản là gửi N khối hơn tồn tại, nhưng không có trọng tải.

Answer 2

UDP sẽ thả các gói không đáp ứng kiểm tra nội bộ cho mỗi gói; Kiểm tra CRC rất hữu ích để xác định ở lớp ứng dụng nếu một khi tải trọng xuất hiện hoàn thành, thì những gì đã nhận được thực sự hoàn thành (không có gói bị loại bỏ) và khớp với những gì được gửi (không có kẻ tấn công trung gian hoặc tấn công khác) .

Answer 3

Bạn có thể chắc chắn các gói bạn nhận được giống như những gì được gửi (tức là nếu bạn gửi gói A và nhận gói A, bạn có thể chắc chắn rằng chúng giống nhau). Lớp vận chuyển CRC kiểm tra trên các gói đảm bảo điều này. Vì UDP không có đảm bảo giao hàng tuy nhiên, bạn cần phải chắc chắn rằng bạn nhận được tất cả mọi thứ đã được gửi và bạn cần phải chắc chắn rằng bạn đặt nó một cách chính xác.

Nói cách khác, nếu gói A, B và C được gửi theo thứ tự đó, bạn có thể thực sự chỉ nhận được A và B (hoặc không có). Vì vậy, kiểm tra của bạn cần phải quan tâm đến khía cạnh phân phối được đảm bảo mà TCP cung cấp (xác minh thứ tự, đảm bảo tất cả dữ liệu ở đó và thông báo cho máy chủ gửi lại bất cứ thứ gì bạn đã làm ” t nhận được) đến bất kỳ mức độ nào bạn yêu cầu.

Lý do muốn sử dụng UDP trên TCP là đối với một số ứng dụng không phải là thứ tự dữ liệu hoặc dữ liệu hoàn chỉnh. Ví dụ: khi phát trực tuyến gói âm thanh AAC, các khung âm thanh riêng lẻ quá nhỏ đến nỗi một lượng nhỏ chúng có thể bị loại bỏ hoặc phát ra một cách an toàn mà không làm gián đoạn trải nghiệm nghe ở bất kỳ mức độ quan trọng nào. Nếu 99,9% các gói tin được nhận và đặt hàng chính xác, bạn có thể phát luồng tốt và không ai chú ý. Điều này hoạt động tốt đối với một số ứng dụng di động/di động và bạn thậm chí không phải lo lắng về việc gửi lại các khung bị bỏ lỡ (lưu ý rằng Shoutcast và một số máy chủ khác sử dụng TCP để phát trực tuyến trong một số trường hợp [để tạo điều kiện siêu dữ liệu trong băng], nhưng chúng không không phải).

Nếu bạn cần đảm bảo tất cả dữ liệu ở đó và được sắp xếp đúng, thì bạn nên sử dụng TCP, sẽ kiểm tra dữ liệu đó ở đó, đặt hàng đúng và gửi lại nếu cần.

Answer 4

Giao thức UDP sử dụng cùng một chiến lược để kiểm tra các gói có lỗi mà giao thức TCP sử dụng - kiểm tra 16 bit trong tiêu đề gói.

Cấu trúc gói UDP nổi tiếng (cũng như TCP) để gói có thể dễ dàng bị sửa đổi nếu không được mã hóa, thêm một kiểm tra khác (ví dụ CRC-32) cũng sẽ làm cho nó mạnh mẽ hơn. Nếu mục đích là mã hóa dữ liệu (theo cách thủ công hoặc qua kênh SSL), tôi sẽ không làm phiền thêm một kiểm tra khác.

Vui lòng cân nhắc xem gói có thể được gửi hai lần hay không. Hãy chắc chắn rằng bạn đối phó với điều đó cho phù hợp.

Bạn có thể kiểm tra cả hai cấu trúc gói tin trên Wikipedia, cả hai đều có checksums:

• Transmission Control Protocol
• User Datagram Protocol

Bạn có thể kiểm tra cấu trúc gói tin TCP với chi tiết hơn để có được lời khuyên về cách đối phó với các gói bị loại bỏ. Giao thức TCP sử dụng "Số thứ tự" và "Số xác nhận" cho mục đích đó.

Tôi hy vọng điều này sẽ hữu ích và chúc bạn may mắn.