Phát hiện các khung Ethernet khác nhau


12

Làm thế nào ai đó có thể phân biệt giữa các gói khác nhau trong giao thức Ethernet? Nó không có trường / chiều "khu vực" như các giao thức cấp cao hơn sử dụng để làm như vậy.

Bởi vì giao thức này có xử lý trong cả phạm vi vật lý và phạm vi logic, tôi cho rằng sự khác biệt cũng được tách biệt.

Là sự phân tách logic được thực hiện bằng cách sử dụng trường giao thức "EtherType"? (tức là có được độ dài gói bằng cách sử dụng loại giao thức cấp cao hơn, có trường độ dài trong các tiêu đề của nó).

Là sự phân biệt vật lý chỉ đơn giản là không truyền tín hiệu điện? (Theo hiểu biết của tôi, tín hiệu điện cao / thấp đại diện cho 0/1 bit).

Câu trả lời:


14

Mặc dù ytti đã trả lời, có một số chi tiết có liên quan mà bạn có thể quan tâm ...

Làm thế nào ai đó có thể phân biệt giữa các gói khác nhau trong giao thức Ethernet? Nó không có trường / chiều "khu vực" như các giao thức cấp cao hơn sử dụng để làm như vậy.

Trên thực tế ethernet có nhiều đóng gói:

  • Ethernet II (Thường được sử dụng cho IP, như được chỉ định trong [RFC 894], là đóng gói phổ biến nhất): Không có trường độ dài , thay vào đó, trường loại được sử dụng ...
       +----+----+------+------+-----+
       | DA | SA | Type | Data | FCS |
       +----+----+------+------+-----+
                 ^^^^^^^^

       DA      Destination MAC Address (6 bytes)
       SA      Source MAC Address      (6 bytes)
       Type    Protocol Type           (2 bytes: >= 0x0600 or 1536 decimal)  <---
       Data    Protocol Data           (46 - 1500 bytes)
       FCS     Frame Checksum          (4 bytes)
  • Ethernet 802.2 LLC: có trường độ dài
       +----+----+------+------+------+------+-----+
       | DA | SA | Len  | LLC  | SNAP | Data | FCS |
       +----+----+------+------+------+------+-----+
                 ^^^^^^^^

       DA      Destination MAC Address (6 bytes)
       SA      Source MAC Address      (6 bytes)
       Len     Length of Data field    (2 bytes: <= 0x05DC or 1500 decimal)  <---
       LLC     802.2 LLC Header        (3 bytes)
       SNAP                            (5 bytes)
       Data    Protocol Data           (46 - 1492 bytes)
       FCS     Frame Checksum          (4 bytes)

Bất kể sự tồn tại của trường độ dài của 802.2, bạn luôn có thể phát hiện phần cuối của khung ethernet trên dây bằng cách tìm Khoảng cách liên khung 96 bit .

Là sự phân tách logic được thực hiện bằng cách sử dụng trường giao thức "EtherType"? (tức là có được độ dài gói bằng cách sử dụng loại giao thức cấp cao hơn, có trường độ dài trong các tiêu đề của nó).

Bằng cách phân tách logic, tôi giả sử bạn có nghĩa là phân tách giữa các giao thức khác nhau được mang bên trong ethernet, chẳng hạn như phân biệt giữa IPv4, IPv6 hoặc có lẽ là Spanning-Tree Frames.

  • Ethernet II thường sử dụng trường Loại
  • Ethernet 802.2 LLC thường sử dụng phần mở rộng SNAP Ethernet 802.2 . Các giao thức chỉ được giải mã với phần mở rộng SNAP khi các byte DSAP / SSAP 802.2 là 0xAAAA.

Là sự phân biệt vật lý chỉ đơn giản là không truyền tín hiệu điện? (Theo hiểu biết của tôi, tín hiệu điện cao / thấp đại diện cho 0/1 bit)

Nói một cách đơn giản, có khoảng cách 96 bit giữa các khung Ethernet; tuy nhiên, lưu ý rằng ethernet sử dụng mã hóa 8b / 10b (FastEthernet) và mã hóa 64b / 66b (GigabitEthernet), do đó không đúng về mặt kỹ thuật để nói "không truyền tín hiệu điện", vì 8b / 10b không có " im lặng "nhà nước.


Đối với người tò mò, tôi cũng đang liên kết với thông số kỹ thuật Ethernet phiên bản 2 gốc .


7

Ethernet có phần mở đầu và phân định khung bắt đầu khi bắt đầu và ở cuối, nó có 'IFG' hoặc khoảng cách giữa các khung. Chúng được sử dụng để xác định bắt đầu và kết thúc khung.


Đó là một sự tách biệt trong phạm vi vật lý hoặc logic? Tuy nhiên, nếu trường dữ liệu của giao thức sẽ bao gồm thông tin / ký tự / tín hiệu giống với dấu phân cách bắt đầu / kết thúc thì sao?
Phản ánh

1
Gap hoàn toàn theo nghĩa đen, không có rủi ro tìm thấy nó trong tải trọng. Tuy nhiên, trong một số bối cảnh khác, không phải ethernet, đây là một vấn đề đáng lo ngại và có thể được khắc phục bằng cách đảm bảo rằng một số ký hiệu không bao giờ được sử dụng để mã hóa dữ liệu, nhưng chỉ để báo hiệu, tuy nhiên sẽ làm giảm hiệu quả để lãng phí một số ký hiệu vì 'không hữu ích' dữ liệu.
ytti
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.