Chính xác thì vấn đề MTU / MRU là gì, nguyên nhân gây ra và cách khắc phục?

Trong các trường hợp kết nối internet bị treo, đóng băng, chậm, không phản hồi, nguyên nhân thường được xác định một cách vô lý là "vấn đề MTU / MRU" với một số "phương pháp chữa bệnh" được đề xuất vội vàng (thường không hợp lệ hoặc không thể áp dụng cho tình huống) như các lệnh liên quan iptableshoặc ifconfig, và " kẹp MTU vào TSS "phép thuật.

Điều tôi muốn biết chính xác là vấn đề MTU / MRU là gì, tại sao nó ảnh hưởng đến tốc độ và độ trễ kết nối và cách khắc phục (phương pháp đã biết và hiện đại), vì tôi muốn hiểu rõ cách giải quyết vấn đề này, không kỳ diệu

Đây là một câu hỏi phức tạp, vì vậy tôi sẽ bắt đầu với những điều cơ bản. Hãy tha thứ cho tôi nếu bạn biết tất cả những điều này rồi.

MTU là Đơn vị truyền tối đa, gói dữ liệu lớn nhất mà giao diện máy tính sẽ gửi. Đối với Ethernet, mặc định là 1500 byte. Các khung Ethernet thường được phép lên tới 1522-1542 (tùy thuộc vào số lượng bạn đếm) và không gian thêm được 'dành riêng' cho thông tin tiêu đề.

Các kết nối khác nhau có thể có khả năng khác nhau. Khá phổ biến khi chạy trên một liên kết trên Internet có MTU nhỏ hơn 1500. Điều này thường là do liên kết sử dụng thông tin tiêu đề bổ sung hoặc sử dụng phương tiện khác ngoài Ethernet 'tiêu chuẩn' (hầu hết Internet thực sự chạy trên Kết nối ATM / SoNet). Thông thường lưu lượng truy cập gặp một liên kết như vậy chỉ đơn giản được chia thành nhiều phần và gửi cùng.

Bởi vì điều này là phổ biến và vào thời điểm IP được phát minh, một phần trách nhiệm của giao thức ICMP là liên lạc với bất kỳ vấn đề nào với MTU. Nếu một gói vì bất kỳ lý do nào không thể bị phá vỡ và chuyển tiếp, ICMP được sử dụng để liên lạc vấn đề trở lại máy tính gửi. Máy tính gửi có hành động thích hợp, chia thông tin thành các phần nhỏ hơn và mọi người đều vui vẻ. Toàn bộ quá trình này được xử lý đằng sau hậu trường. Trong một mạng hoạt động đúng , không bao giờ cần thiết phải cài đặt MTU .

Vòng loại trên câu cuối cùng là kicker. Có ba lý do phổ biến khiến quy trình tự động bị hỏng:

1. Thực hiện bị hỏng - Phần mềm tại một số điểm chỉ đơn giản là không hoạt động như bình thường. Không có luật nào nói rằng mọi người phải tuân theo các tiêu chuẩn có liên quan của Internet và có những công ty phá vỡ các tiêu chuẩn, thường là rẻ.
2. Việc triển khai bị vô hiệu hóa về mặt hành chính - Điều xảy ra là những người có ý định tốt sẽ phá vỡ phần mềm vì họ thực sự không biết họ đang làm gì. Cá nhân tôi đã thấy mọi người chặn ICMP vì họ nghĩ rằng nó chỉ được sử dụng cho các gói ICMP.0.0 (echo, hầu hết mọi người đều biết điều này bởi pingtiện ích).
3. Những lý do khác hoàn toàn nằm ngoài quy trình 'bình thường' này. Thông thường, điều này có nghĩa là kết nối bị mất đến mức chỉ các gói ngắn hơn mới thực hiện được thông qua kết nối (hoặc không có số lượng lớn các lần thử lại). Một số DSL và CableModems ban đầu có vấn đề như thế này. Và trước đó, quay số thường gặp vấn đề như thế này khi sử dụng các đường dây điện thoại chất lượng rất kém và mã hóa đường dây mạnh mẽ.

Vì vậy, tại sao là phổ biến: Kỹ thuật viên / công ty lười biếng. Hầu như toàn cầu 'dễ dàng hơn' để kết nối kết nối với một MTU nhỏ hơn là khắc phục một trong những vấn đề được nêu ở trên. Như đã nói ở trên, không ai phải gặp rắc rối với MTU những ngày này (một ngoại lệ tôi có thể nghĩ là kích hoạt khung Jumbo, nhưng đó thực sự không phải là điều chúng ta đang thảo luận ở đây). Cách chữa đúng trong mọi trường hợp là tìm ra vấn đề tiềm ẩn và khắc phục điều đó; trường hợp kinh điển của điều trị bệnh không phải là triệu chứng.

MTU ảnh hưởng đến kết nối như thế nào? Cắt dữ liệu thành các mảnh nhỏ có nghĩa là mỗi mảnh sẽ có cơ hội tốt hơn để đến đích, đặc biệt là qua các kết nối không đáng tin cậy. Là những mảnh nhỏ hơn, tuy nhiên, có nhiều chi phí hơn cho mỗi dữ liệu được truyền. Điều này có nghĩa là tốc độ kết nối hiệu quả bị giảm; đáng kể nếu MTU thực sự nhỏ. Độ trễ có thể bị ảnh hưởng, mặc dù tôi cho rằng nó là nhỏ, do quá trình xử lý bổ sung và chi phí chung của tiêu đề và quá trình phân mảnh / lắp lại.

Cập nhật: - Về --clamp-mss-to-pmtu
cá nhân tôi chưa bao giờ bị mắc kẹt với MTU; Tôi thừa nhận tôi là một người cầu toàn và khi bị đưa ra những bản hack xấu xí như thế này, tôi luôn tìm ra gốc rễ của vấn đề và đã có thể sửa nó. Cuối cùng, iptablestùy chọn --clamp-mss-to-pmtunày không quen thuộc với tôi. Rõ ràng nó là cực kỳ phổ biến, và có khả năng rất không chính đáng trong hầu hết các tình huống, để sử dụng hack này. Nó vẫn là một hack để bù đắp cho một trong những vấn đề trên. Tôi trích dẫn từ trang web Linux cho iptables (8):

Mục tiêu này được sử dụng để khắc phục các ISP hoặc máy chủ bị tấn công hình sự, chặn các gói 'ICMP Fragment Needed' hoặc 'ICMPv6 Packet Too Big'.

Ngôn ngữ tương đối gay gắt của trang chủ phải là một dấu hiệu cho thấy mức độ khinh miệt của các ISP và Mạng không tuân theo RFC (và không nỗ lực để cố gắng hoặc bù đắp).

Nói về việc sử dụng UDP trong VPN, điều này được sử dụng phổ biến nhất để giảm thiểu chi phí hoạt động của VPN và cho phép các điểm cuối hiện tại quản lý thông tin phiên. VPN không có cách nào để biết cách xử lý phiên này, vì vậy nhiệm vụ đó thực sự là tốt nhất cho các ứng dụng biết.

Nhiều giao thức đường hầm VPN hiện đại được xây dựng ở các cấp thấp hơn (thậm chí ít chi phí hơn), chẳng hạn như GRE và L2TP; hoặc được tạo đường hầm ở các cấp cao hơn (thường để tương thích với tường lửa hạn chế hoặc các lý do khác), chẳng hạn như SSTP hoặc SSH. Chúng sẽ dần thay thế UDP như một cơ chế vận chuyển.

Cập nhật 2: - Chẩn đoán sự cố MTU / ICMP
Vì vậy, bạn nghĩ rằng bạn đã gặp sự cố MTU / ICMP và muốn chắc chắn. Có hai bước cơ bản cho quá trình này. Các hướng dẫn dành cho hộp Linux hoặc BSD, nhưng có thể được điều chỉnh phù hợp với mọi hệ điều hành.

1. Chọn mục tiêu Ping ICMP (ví dụ: Google.com, Yahoo.com, Facebook.com, v.v.). Hãy thử ping chúng bằng lệnh sau : ping -c 2 -s 1472 -D google.com.
   • Điều này sẽ thành công. Nếu nó không thành công, nó sẽ trả về "gói cần được phân mảnh". Nếu một trong hai điều này là đúng, dừng lại, kết nối của bạn sẽ hoạt động tốt.
   • Nếu điều này không trả về bất cứ điều gì, hoặc đưa ra một thông báo "hết thời gian" thì bạn có vấn đề.
2. Chỉ dành cho kết nối bị hỏng: chạy traceroute -F google.com 1472. Điều này sẽ cho bạn biết hop nào bị hỏng. Lưu ý: CPE khá phổ biến khi không đáp ứng với các yêu cầu theo dõi, vì vậy đừng hoảng hốt nếu bước nhảy đầu tiên không phản hồi.
   • Bất cứ điều gì là bước nhảy cuối cùng để trả lời là lần cuối cùng hoạt động chính xác với bạn.
   • Nếu không ai trong số họ trả lời thì đó là đường CPE hoặc DSL của bạn (tìm ra điều này có thể hơi rắc rối, nhưng gần như không bao giờ CPE nếu nó hiện đại). Lưu ý: Nếu kết nối của bạn hoạt động tốt, traceroute sẽ hoàn thành thành công.

Một lưu ý phụ: ISP nào sử dụng PPTP những ngày này?! Đó là một vụ nổ từ quá khứ xa xưa và vô dụng. Họ ít nhất nên sử dụng PPPoE; nhưng chỉ cần ủy quyền cho modem bằng MAC và Phân đoạn sẽ dễ dàng hơn nhiều (dễ dàng hơn cho cả ISP và Khách hàng).