Tại sao tải trọng ethernet cố định trong khoảng từ 46 đến 1500 byte?


8

Bất cứ ai cũng có thể giải thích tại sao kích thước tải trọng ethernet được cố định trong khoảng từ 46 đến 1500 byte?

Tôi đọc rất nhiều bài viết không bao giờ có được làm rõ?


4
Tôi nghĩ rằng kích thước tối thiểu được đặt để có thời gian phát hiện va chạm, không liên quan lắm trong mạng hiện đại khi một nửa song công gần như biến mất. Kích thước tối đa có thể được đặt vì vậy, để cho phép một số đảm bảo từ kiểm tra FCB 4B, khung lớn hơn và bạn sẽ mất một số đảm bảo về FCS hoặc bạn cần nhiều byte hơn trong FCS.
ytti

@ytti, hoạt động bán song công chính thức được bao gồm trong thông số 1000BaseT và IEEE đã rất kiên quyết về khả năng tương thích ngược. Nói rằng nó không liên quan lắm bên cạnh vấn đề. Half-duplex được bao gồm trong mỗi 1000BaseT PHY tuân thủ theo chuẩn 802.3 được sản xuất.
Mike Pennington

Có câu trả lời nào giúp bạn không? nếu vậy, bạn nên chấp nhận câu trả lời để câu hỏi không xuất hiện mãi mãi, tìm kiếm câu trả lời. Ngoài ra, bạn có thể cung cấp và chấp nhận câu trả lời của riêng bạn.
Ron Maupin

Câu trả lời:


10

Lý do cho tải trọng 46 byte:

Theo đoạn 6.3.2.3 của Thông số Ethernet V2 , khung ethernet tối thiểu dựa trên Thời gian khe Ethernet , có độ dài 512 bit (64 byte) cho ethernet 10M. Thời gian khe chi phối cả chiều dài cáp tối đa và kích thước khung tối thiểu.

Sau khi trừ 18 byte cho tiêu đề ethernet và CRC, bạn nhận được 46 byte tải trọng Ethernet dưới dạng kích thước tải tối thiểu.

Thời gian khe (và do đó kích thước khung tối thiểu) cũng liên quan chặt chẽ đến phát hiện va chạm Ethernet. Trích dẫn Giới thiệu về Mạng máy tính , đoạn 2.1.2:

... về nguyên tắc, một sự va chạm có thể được nhận, tại bất kỳ thời điểm nào cho đến khi kết thúc thời gian. Kết quả là, Ethernet có kích thước gói tối thiểu, bằng với thời gian của khe, tức là 64 byte (hoặc 46 byte trong phần dữ liệu). Một trạm truyền gói tin có kích thước này được đảm bảo rằng nếu xảy ra xung đột, người gửi sẽ phát hiện ra nó (và có thể áp dụng thuật toán truyền lại, bên dưới). Các gói nhỏ hơn có thể va chạm và người gửi không biết điều đó, cuối cùng dẫn đến thông lượng giảm đáng kể

Thời gian khe Ethernet được chỉ định để CSMA / CD hoạt động chính xác. Kích thước tối thiểu của khung được xác định để đảm bảo rằng việc truyền của nó mất đủ thời gian để ngay cả với khung hợp lệ ngắn nhất, có thể phát hiện được một xung đột đáng tin cậy; nếu kích thước khung hình quá nhỏ (đối với chiều dài cáp tối đa), việc phát hiện va chạm xác định là không thể .

Tải trọng 1500 byte:

Chúng tôi đã thảo luận về lý do cho MTU 1500 byte ; vui lòng tham khảo câu hỏi đó để biết chi tiết.

Lưu ý: nhận xét của ytti về giới hạn FCS của ethernet không phải là lý do khiến 1500 byte được chọn. Nó được chọn do các vấn đề với việc diễn giải trường Độ dài trong khung mã hóa 802.3 so với trường Loại trong khung Ethernet II.


1
Bạn viết "kích thước khung tối thiểu không vượt quá chiều dài cáp dài nhất có thể" mà tôi diễn giải ngược lại với những gì là đúng. Thời gian truyền của khung tối thiểu phải vượt quá thời gian lan truyền trong thời gian dài nhất có thể của cáp để phát hiện va chạm để hoạt động đúng.
kll

Tôi đề nghị "cần có kích thước khung tối thiểu để cho phép phát hiện và báo hiệu va chạm trên toàn mạng trong khi người gửi vẫn đang truyền".
Zac67

@kll, nếu bạn khăng khăng đối diện với khung tối thiểu, thì dĩ nhiên nhiều khung kích thước tối thiểu có thể tồn tại trên dây trước khi phát hiện va chạm hợp lệ. Đó rõ ràng là không mong muốn.
Mike Pennington

@MikePennington bốn năm sau ..;) Tôi đồng ý rằng không có nhiều khung trên dây ... nhưng bạn nói rằng kích thước khung tối thiểu không được vượt quá chiều dài dài nhất của cáp, điều này có vẻ sai. Nếu chiều dài cáp vượt quá kích thước khung hình, thì nó cho phép nhiều khung hình mà chúng tôi vừa thỏa thuận là không mong muốn, do đó kích thước khung phải vượt quá chiều dài cáp. Bạn bằng cách nào đó sử dụng vượt quá có nghĩa là ngược lại với cách tôi diễn giải nó? Hướng nào là vượt quá bạn? Ngắn hơn / ít byte hơn của khung?
kll

@MikePennington bằng cách nào đó chúng ta phải nói chuyện với nhau. Chúng tôi đồng ý kích thước khung tối thiểu là 64 byte. Điều đó bao gồm một RTT đường kính mạng tối đa để chúng tôi có thể phát hiện xung đột một cách đáng tin cậy. Nếu kích thước khung là 10 byte, chúng tôi không thể phát hiện xung đột vì chiều dài cáp vượt quá kích thước khung. Ngược lại, nếu gói từ 64 byte trở lên thì kích thước khung vượt quá chiều dài cáp và chúng ta có thể phát hiện xung đột. Tôi nghĩ rằng khung có độ dài kể từ khi được nối tiếp trên cáp, nó lan truyền với một tốc độ nhất định và do đó có được độ dài trong môi trường.
kll

-1

Giới hạn trên không được cố định ở mức 1500, khung jumbo có thể lên tới 9000 byte, nhưng nó phụ thuộc vào mạng / ứng dụng

https://en.wikipedia.org/wiki/Jumbo_frame

Danh sách các MTU phổ biến https://en.wikipedia.org/wiki/Maximum_transmission_unit#IP_MTUs_for_common_media


5
MTU ethernet được cố định ở mức 1500 trên mỗi tiêu chuẩn. Khung Jumbo là không chuẩn, và mỗi nhà cung cấp làm điều đó khác nhau (hoặc có thể không hoàn toàn). Một số nhà cung cấp làm điều đó khác nhau trên các mô hình chuyển đổi khác nhau, hoặc thậm chí trên các giao diện khác nhau trên cùng một công tắc. Trên thực tế, liên kết thứ hai của bạn nói: " Khung Jumbo thường chỉ được nhìn thấy trong các mạng có mục đích đặc biệt. "
Ron Maupin

OK, nhưng câu hỏi không nói kích thước khung ethernet "được chỉ định" tiêu chuẩn
vaaz

Câu hỏi là, " Có ai có thể giải thích tại sao kích thước tải trọng ethernet được cố định trong khoảng từ 46 đến 1500 byte không? " Câu trả lời của bạn cho biết, " Giới hạn trên không được cố định ở 1500. " nhưng tiêu chuẩn ethernet, IEEE 802.3, đã sửa nó đường. Có rất nhiều tiêu chuẩn mạng, và, vâng, nhiều nhà cung cấp vi phạm các tiêu chuẩn đó theo những cách khác nhau. Cách duy nhất bạn có thể chắc chắn rằng các thiết bị ethernet không đồng nhất của bạn hoạt động là tuân theo tiêu chuẩn trong đó MTU ethernet là 1500.
Ron Maupin

ok hiểu rồi, cảm ơn
vaaz
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.