Các gói TCP và UDP có thể được chia thành từng mảnh không?

Các gói TCP có thể đến máy thu theo từng mảnh không?

Ví dụ: nếu tôi gửi 20 byte bằng giao thức TCP, tôi có thể chắc chắn 100% rằng tôi sẽ nhận được chính xác 20 byte cùng một lúc, không phải 10 byte sau đó thêm 10 byte nữa không?

Và câu hỏi tương tự cho giao thức UDP.
Tôi biết rằng UDP không đáng tin cậy và các gói không thể đến được hoặc đến theo thứ tự khác nhau, nhưng còn một gói thì sao? Nếu nó đến, tôi có thể chắc chắn rằng đó là một gói hoàn chỉnh, không phải là một mảnh?

các gói TCP có thể đến máy thu theo từng mảnh không?

Đúng. IP hỗ trợ phân mảnh, mặc dù TCP thường cố gắng xác định MTU đường dẫn và giữ các gói của nó nhỏ hơn so với lý do hiệu suất. Sự phân mảnh làm tăng tỷ lệ mất datagram một cách thảm khốc. Nếu một đường dẫn có tỷ lệ mất gói 10%, việc phân chia một datagram thành hai gói làm cho tỷ lệ mất datagram gần như 20%. (Nếu một trong hai gói bị mất, datagram sẽ bị mất.)

Bạn không phải lo lắng về điều này mặc dù và lớp TCP cũng không. Lớp IP tập hợp lại các gói thành toàn bộ datagram.

Ví dụ: nếu tôi gửi 20 byte bằng giao thức TCP, tôi có thể chắc chắn 100% rằng tôi sẽ nhận được chính xác 20 byte cùng một lúc, không phải 10 byte sau đó thêm 10 byte nữa không?

Không, nhưng điều đó không liên quan gì đến các gói. Về cơ bản, TCP là một giao thức luồng byte không bảo toàn ranh giới thông điệp ứng dụng.

Và câu hỏi tương tự cho giao thức UDP. Tôi biết rằng UDP không đáng tin cậy và các gói không thể đến được hoặc đến theo thứ tự khác nhau,

Điều này cũng đúng với TCP. Các gói là các gói. Sự khác biệt là TCP đã thử lại và sắp xếp lại được tích hợp vào giao thức trong khi UDP thì không.

Nhưng còn 1 gói thì sao? Nếu nó đến, tôi có thể chắc chắn rằng đó là một gói hoàn chỉnh, không phải là một mảnh?

Không, nhưng đó không phải là vấn đề của bạn. Giao thức UDP xử lý việc cài đặt lại datagram. Đó là một phần công việc của nó. . sẽ thấy dữ liệu đầy đủ.

Bạn không thể chắc chắn rằng họ thực sự đến một lúc. Các lớp liên kết dữ liệu bên dưới TCP / UDP có thể chia gói của bạn lên nếu chúng muốn. Đặc biệt nếu bạn gửi dữ liệu qua internet hoặc bất kỳ mạng nào ngoài tầm kiểm soát của bạn, thật khó để dự đoán điều đó.

Nhưng không có vấn đề nếu dữ liệu đến trong một gói hoặc nhiều gói tại máy thu. Hệ điều hành nên trừu tượng hóa việc ghép các gói này, vì vậy đối với ứng dụng của bạn, nó vẫn giống như mọi thứ xuất hiện cùng một lúc. Vì vậy, trừ khi bạn là một hacker hạt nhân, trong hầu hết các trường hợp, bạn không cần phải lo lắng nếu dữ liệu này được truyền trong một hoặc nhiều gói.

Đối với UDP, HĐH cũng sẽ thực hiện một số trừu tượng, do đó, ứng dụng nhận dữ liệu không cần phải biết có bao nhiêu gói dữ liệu được truyền đi. Nhưng sự khác biệt đối với TCP là không có gì đảm bảo dữ liệu thực sự đến. Cũng có thể dữ liệu được chia thành nhiều gói và một số trong số chúng đến và một số thì không. Đối với ứng dụng nhận, dù sao nó cũng giống như một luồng dữ liệu, bất kể nó đã hoàn thành hay chưa.

Ví dụ. Các khối ký tự liền kề tương ứng với các lệnh gọi ():

TCP:

Send: AA BBBB CCC DDDDDD E         Recv: A ABB B BCC CDDD DDDE

Tất cả dữ liệu gửi được nhận theo thứ tự, nhưng không nhất thiết phải trong cùng một khối.

UDP:

Send: AA BBBB CCC DDDDDD E         Recv: CCC AA E

Dữ liệu không nhất thiết phải theo cùng một thứ tự và hoàn toàn không nhất thiết phải nhận, nhưng các thông điệp được lưu giữ toàn bộ.

Ví dụ: nếu tôi gửi 20 byte bằng giao thức TCP, tôi có thể chắc chắn 100% rằng tôi sẽ nhận được chính xác 20 byte cùng một lúc, không phải 10 byte sau đó thêm 10 byte nữa không?

Không, TCP là một giao thức truyền phát, nó giữ dữ liệu theo thứ tự nhưng nó không nhóm nó theo tin nhắn. Mặt khác, UDP được định hướng theo thông điệp, nhưng không đáng tin cậy. SCTP có thế giới tốt nhất nhưng không thể sử dụng được vì NAT phá vỡ Internet.

Có một số đảm bảo rằng nếu bạn gửi 20 byte ở đầu luồng TCP, nó sẽ không đến dưới dạng hai mảnh 10 byte. Điều này là do ngăn xếp TCP sẽ không gửi các phân đoạn nhỏ như vậy: có kích thước MTU tối thiểu. Tuy nhiên, nếu việc gửi ở bất cứ đâu ở giữa luồng, tất cả các cược sẽ bị tắt. Có thể là ngăn xếp giao thức của bạn mất 10 byte dữ liệu để điền vào một phân đoạn và gửi nó ra, và sau đó mười byte tiếp theo chuyển sang phân đoạn khác.

Ngăn xếp giao thức của bạn chia dữ liệu thành các khối và đặt chúng vào hàng đợi. Các kích thước khối được dựa trên đường dẫn MTU. Nếu bạn thực hiện thao tác gửi và vẫn còn dữ liệu xếp hàng chờ xử lý, ngăn xếp giao thức thường sẽ nhìn trộm phân đoạn nằm ở đuôi hàng đợi và xem liệu có chỗ trong phân đoạn đó để thêm dữ liệu không. Căn phòng có thể nhỏ như một byte, do đó, ngay cả một lần gửi hai byte cũng có thể được chia thành hai.

Mặt khác, phân đoạn dữ liệu có nghĩa là có thể có một phần đọc. Một hoạt động nhận có khả năng có thể thức dậy và có được dữ liệu khi có ít nhất một phân đoạn đến. Trong API ổ cắm được triển khai rộng rãi, một cuộc gọi nhận có thể yêu cầu 20 byte, nhưng nó có thể trả về bằng 10. Tất nhiên, một lớp đệm có thể được xây dựng trên đó sẽ chặn cho đến khi nhận được 20 byte hoặc ngắt kết nối. Trong thế giới POSIX, API đó có thể là luồng I / O tiêu chuẩn: bạn có thể fdopenmô tả ổ cắm để có được FILE *luồng và bạn có thể sử dụng freadnó để điền vào bộ đệm sao cho yêu cầu đầy đủ được đáp ứng với nhiều readcuộc gọi như vậy .

Các datagram UDP đóng khung dữ liệu. Mỗi cuộc gọi gửi sẽ tạo ra một datagram (nhưng xem bên dưới về nút chai). Phía bên kia nhận được một datagram đầy đủ (và, trong API socket, nó phải chỉ định một bộ đệm đủ lớn để chứa nó, nếu không thì datagram sẽ bị cắt ngắn). Các datagram lớn bị phân mảnh bởi phân mảnh IP và được lắp ráp lại trong suốt cho các ứng dụng. Nếu bất kỳ đoạn nào bị thiếu, toàn bộ datagram sẽ bị mất; không có cách nào để đọc một phần dữ liệu trong tình huống đó.

Có các phần mở rộng cho giao diện cho phép nhiều thao tác chỉ định một datagram duy nhất. Trong Linux, một ổ cắm có thể bị "đóng nút" (không thể gửi). Trong khi nó được đóng nút, dữ liệu bằng văn bản được tập hợp thành một đơn vị. Sau đó, khi ổ cắm được "mở khóa", một datagram duy nhất có thể được gửi.