-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
can add udp mtu configuration option? #1367
Comments
MTU should be changed through network interfaces. What do you expect shadowsocks as an application could do with the interfaces’ MTU size? |
my local mtu is 1400 and server mtu is 1500 will lead to data fragmentation,so hope application have function can set send packet size (mtu-ip header size-udp header size) |
This indeed would be something really nice (and important IMO) to have in shadowsocks-rust. My project shadowsocks-go was written with this in mind and has a mandatory MTU option for both client and server configurations. On top of my mind I can think of the following benefits:
|
The configured MTU value is just for hinting? |
not just a reminder hinting,it is an actual function. you can customize the size of the packet data that is forced to be sent, so that the data packet size configuration can be completed in the application part. otherwise, unnecessary fragmentation will occur in the mtu part,especially when you know that the mtu between your client and server is different and the minimum mtu is what, this may be very practical. |
So in practice, the |
yes,you are right,is it possible to add such functionality? |
Maybe. I haven’t look deep into it yet. Theoretically, the |
Don't forget to subtract the IPv4 header length (20 bytes) and UDP header length (8 bytes). On
On Unix systems, when the message does not fit in the supplied buffer, the default behavior is to truncate the message and indicate this in the flags, which is up to the application to check. The most portable way to implement the check is to always use There are also other ways on some common platforms. On Linux you can specify |
Ok. But what should application do to handle these oversized packets? Just ignore them? |
My take is to print a warning and drop the packet.
It'd be nice to have it on the server as well. When you know the exact MTU and that your applications do not rely on IP fragmentation, you can use smaller buffers for server -> client relay to reduce memory usage. |
It’s true about lowering the memory consumption, but that’s quite small comparing to the other part of the application. BTW, the |
Another reason to implement the MTU option: QUIC. Many QUIC clients use DPLPMTUD (RFC 8899) to probe the PMTU and determine the best packet size. If the proxy program allows IP fragmentation and uses a large buffer size, it might confuse the QUIC client and causes it to select a packet size that's too large for the actual path. |
It's actually quite significant in my experience, especially after I implemented |
BTW, I just double check the code, we have already set
So the problem here is: the packet was bigger than the path MTU, but system didn't reject it with |
- Setting `udp_mtu` to limits inbound, outbound MTU - Ref #1367
Linux and Windows seem to be the only platforms where socket options are properly implemented for dual-stack ( Unfortunately, on common BSD-derived platforms like FreeBSD and macOS, calling |
I am also experiencing this problem, but I don't know how I should change it, my router maximum allowed configured MTU is 1492, after I start sslocal, I use
|
specify sslocal and ssserver udp mtu option.in some network environments, not all mtu are consistent. If the intermediate route does not enable pmtud, fragmentation will occur and various questions.
The text was updated successfully, but these errors were encountered: