Switchport ở chế độ song công - Tải xuống tốc độ nhưng tải lên vẫn ổn

Một người dùng đã gặp vấn đề với tốc độ tải xuống từ Internet. Kết nối với Internet là 100 Mbit / s. Người dùng có khoảng 7 Mbit / s xuôi dòng và khoảng 80 Mbit / s ngược dòng.

Tôi đã thử nghiệm từ máy tính của mình và nó nhận được khoảng 70 Mbit / s xuôi dòng và 80 Mbit / s ngược dòng. Rõ ràng là người dùng PC đã đổ lỗi.

Tôi đã kiểm tra công tắc là Catalyst 3560 và ở đó đúng như tôi dự đoán, cổng ở chế độ song công. Người dùng đã mã hóa cứng PC của mình thành 100 / đầy và cổng đang sử dụng tự động. Tốc độ được phát hiện bởi các xung liên kết nhanh (FLP) nhưng song công phải được giả định là một nửa để cổng được sử dụng 100 / một nửa. Với bộ điều khiển hiển thị, tôi có thể thấy các va chạm và va chạm muộn như mong đợi.

Băng thông đã được kiểm tra thông qua trang web Thụy Điển www.bredbandkollen.se. Nó sử dụng TCP để kiểm tra độ trễ lúc đầu. Sau đó, nó sẽ mở một ổ cắm thông qua Flash và thực hiện một số HTTP GET (TCP) và đo băng thông xuôi dòng trong khoảng 10 giây. Sau đó, nó thực hiện bốn bài viết HTTP đến máy chủ và gửi lưu lượng trong 10 giây và tính toán băng thông ngược dòng.

Tôi biết rằng các loại trang web này không chính xác 100% nhưng thường thì ít nhất chúng có thể đưa ra một số loại dấu hiệu nếu bạn gần nhận được loại băng thông mà bạn nên và đó là một thử nghiệm dễ dàng để đảm bảo rằng đó là người dùng và không phải là lỗi mạng ở đây.

1. Tại sao chỉ hạ lưu bị ảnh hưởng và không ngược dòng?

2. Là những va chạm thực sự? Vì cáp có cặp truyền và nhận riêng biệt.

Đây là hành vi hoàn toàn bình thường với sự không phù hợp song công.

Tại sao chỉ hạ lưu bị ảnh hưởng và không ngược dòng?

Vì máy tính đang hoạt động ở chế độ song công hoàn toàn, nên nó không sử dụng CSMA-CD. Điều này có nghĩa là nó không kiểm tra xem phương tiện có ở chế độ chờ trước khi truyền hay không và cũng không nhận thấy bất kỳ dữ liệu nào nó nhận được trong khi truyền dưới dạng va chạm. Do đó, việc tải lên từ máy tính sẽ vẫn không bị ảnh hưởng nhiều.

Ngược lại, công tắc đang sử dụng CSMA-CD và sẽ đợi phương tiện ở chế độ chờ trước khi truyền. Ngoài ra, khi công tắc phát hiện va chạm, nó ngay lập tức dừng truyền khung và làm theo quy trình phát hiện va chạm CSMA-CD. Điều này có tác động đáng kể đến hiệu suất đối với lưu lượng được gửi đến máy tính.

Khi lưu lượng truy cập là TCP, hiệu ứng tiêu cực sẽ được nhân lên vì bất kỳ TCP ACK nào bị mất vào máy tính sẽ gây ra truyền lại TCP.

Là những va chạm thực sự? Vì cáp có cặp truyền và nhận riêng biệt.

Vâng, họ là những va chạm thực sự; ngay cả trong một môi trường song công hoàn toàn (tức là các hub) có các cặp truyền và nhận riêng biệt. Lý do là trong môi trường song công một nửa, các hub sẽ lặp lại tín hiệu nhận được trên một cổng ra tất cả các cổng khác. Nếu hai trạm cố gắng truyền phát cùng một lúc, tín hiệu được lặp lại sẽ không thể sử dụng được.

Vì công tắc đang hoạt động ở chế độ song công, nó hoạt động giống như trong môi trường như vậy và chỉ có thể truyền hoặc nhận tại bất kỳ thời điểm nào. Bất cứ khi nào công tắc gửi khung và phát hiện lưu lượng khác trên phương tiện (tức là máy tính không kiểm tra phương tiện nhàn rỗi), điều này được coi là va chạm và công tắc sẽ tuân theo quy trình phát hiện va chạm (bao gồm một chờ đợi hoặc lùi lại trong khoảng thời gian).

Vì máy tính không hoạt động theo cách này (tức là nó bắt đầu truyền tự động khi có dữ liệu để gửi), bạn kết thúc với nhiều va chạm hơn so với trong môi trường hoàn toàn được tạo thành từ một nửa thiết bị song công.

Chỉnh sửa: Tôi đã bắt gặp một tài liệu tham khảo vào cuối tuần này trong khi tìm kiếm một vấn đề không liên quan, nơi chúng được gọi là va chạm sai . Tôi sẽ không đồng ý với quan điểm này vì công tắc rõ ràng xem chúng là một vụ va chạm và xử lý chúng như vậy. Thay vào đó, tôi sẽ nghĩ về chúng như những va chạm không cần thiết ở chỗ chúng không nên tồn tại trong một mạng chuyển mạch.

Bên cạnh đó, đây là loại không phù hợp được báo cáo thường xuyên nhất (trong đó công tắc được đặt thành tự động và máy tính thành song công hoàn toàn). Hầu hết mọi người tải xuống nhiều hơn họ tải lên, họ có xu hướng nhận thấy tình trạng này dễ dàng hơn để báo cáo nó.

Nếu TCP đã được thử nghiệm, có rất nhiều thứ bạn không thể kiểm soát hoặc thậm chí không thể tưởng tượng được. Sự khác biệt về hạ lưu / ngược dòng có thể dễ dàng gây ra bởi các cài đặt ưu tiên nội bộ của NIC, bộ đệm cho RX / TX và về cơ bản là các cài đặt cấp thấp chỉ ra cách xử lý lưu lượng RX và TX.

'Bộ điều khiển sh' sẽ báo cáo mọi tình trạng RX và TX đồng thời là xung đột nếu làm việc ở chế độ bán song công.