3 ms·
On Linux (at least recent kernels), there are a number of variables that can determine whether or not DF is set on outgoing packets. I ran a few tests with (Ub
by aminuit 17y ago
On Linux (at least recent kernels), there are a number of variables that can determine whether or not DF is set on outgoing packets. I ran a few tests with (Ubuntu Hardy) firefox and it seems largely to vary based on the value of /proc/sys/net/ipv4/ip_no_pmtu_disc. If 1, no DF. If 0, DF set. But it has this behavior regardless of whether I'm using HTTPS or HTTP.
I understand your objection: standards do not often reflect the real world. But the title of your post is misleading. Saying that routers treat https differently than http is just incorrect. When I read it, I thought you were trying to imply that routers were doing some sort of deep inspection, or at least looking at the TCP port numbers.
What is true is that you can't expect PMTU discovery to work reliably over the Internet (another case of standards not reflecting the real world). I work at an ISP and it's a constant source of frustration. In general though, it's something that needs to be fixed on the client side (or at least on the client's ISP side), rather than on the server side.
- mmaunder 17y agoSo you're saying that with ip_no_pmtu_disc set to off (the default value), your HTTPS server does not set the DF flag on packets? What I've seen is that all HTTPS servers (that I've observed) set DF on their data packets. No HTTP servers (that I've observed) set DF for their data packets. What I would like to know is why SSL servers set DF on their data packets. As you've observed there's nothing in the FAQ and I've googled the socket options and couldn't find any recommendations. I'm curious if an underlying API like openssl is simply so widely used that it's a de facto standard.
- aminuit 17y agoDid you try tweaking ip_no_pmtu_disc and run your tests? I played a bit with the openssl test client/server and it seems to respect ip_no_pmtu_disc. Test goes something like this: 1) In one window run openssl s_server 2) In another window run openssl s_client -connect localhost:4433 3) In another window run tcpdump -nvi lo port 4433 Try twiddling the ip_no_pmtu_disc sysctl and see what happens.
- aminuit 17y agoAlso, when you say "HTTPS servers set DF," are you observing from the server or from the client? Over the Internet, it's likely that you'd see different values for DF on opposite sides of the connection. Any router can set or clear the DF bit on your packets for any reason.