network.tcp.tcp_fastopen_enable
Moderator: trava90
Forum rules
This board is for technical/general usage questions and troubleshooting for the Pale Moon browser only.
Technical issues and questions not related to the Pale Moon browser should be posted in other boards!
Please keep off-topic and general discussion out of this board, thank you!
This board is for technical/general usage questions and troubleshooting for the Pale Moon browser only.
Technical issues and questions not related to the Pale Moon browser should be posted in other boards!
Please keep off-topic and general discussion out of this board, thank you!
network.tcp.tcp_fastopen_enable
Why is there no option to set this parameter ?
Significantly accelerates the loading of sites on which the server supports TCP Fast Open (TFO)
Significantly accelerates the loading of sites on which the server supports TCP Fast Open (TFO)
-
- Board Warrior
- Posts: 1651
- Joined: 2018-06-08, 17:02
Re: network.tcp.tcp_fastopen_enable
I'll note that while it has been in FF for a while now, it is not defaulted to 'on'.
Wiki: TCP Fast Open
Wiki: TCP Fast Open
Examples?sites on which the server supports TCP Fast Open
-
- Pale Moon guru
- Posts: 35649
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
Re: network.tcp.tcp_fastopen_enable
I'm very much apprehensive about TFO. It falls in the same kind of risk category as TLS 1.3 0-RTT in that it will send data before a handshake has been completed. It can apparently also lead to stalls (the opposite of the intended effect) and I'd rather stick with completing a proper handshake before switching to the data transfer phase of a connection. Saving 1 round trip between server and client really isn't worth trying to push outside of safe, well-established protocols.
In addition, there is apparently a security concern (that I don't have access to, by the way) with it that has had Mozilla switch it off before Firefox 57 landed, and has not re-enabled it since in the almost 2 years that have passed.
Also, I don't see how it would "significantly accelerate the loading of sites". At most you'd be looking at a slightly decreased first data time per connection -- but since browsers use connection pools, potentially http pipelining and http2 multiplexing of requests, as well as having much more latency in the protocols on top of TCP than TCP itself, the practical win for TFO is very underwhelming and IMHO should be reserved for specialized applications that use raw TCP in a timing-critical environment.
In addition, there is apparently a security concern (that I don't have access to, by the way) with it that has had Mozilla switch it off before Firefox 57 landed, and has not re-enabled it since in the almost 2 years that have passed.
Also, I don't see how it would "significantly accelerate the loading of sites". At most you'd be looking at a slightly decreased first data time per connection -- but since browsers use connection pools, potentially http pipelining and http2 multiplexing of requests, as well as having much more latency in the protocols on top of TCP than TCP itself, the practical win for TFO is very underwhelming and IMHO should be reserved for specialized applications that use raw TCP in a timing-critical environment.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: network.tcp.tcp_fastopen_enable
https://www.babai.ru/articles/kak-my-zaveli-minipiga.html
support TFO, support TLS 1.3 0-RTT, support http/2, support server push etc.
There is really one caveat. This is my website.
-
- Pale Moon guru
- Posts: 35649
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
Re: network.tcp.tcp_fastopen_enable
That doesn't count then, does it?
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: network.tcp.tcp_fastopen_enable
Of course you're right.
It’s just that I myself want my site to be the fastest and most convenient for visitors. My site is completely non-profit, I’m not selling anything. There is no advertising on the site. I just want as many people as possible to see friends in piglets and not food!
-
- Pale Moon guru
- Posts: 35649
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
Re: network.tcp.tcp_fastopen_enable
Once more, compared to the rest of the protocol and data transfer, TFO will be insignificant.
Proof: The indicated rows are the full 3-way handshake. The TCP connection is established in 51 ms without TFO from my location to yours. TLS Client Hello on its way after 54 ms and first encrypted data being sent by the browser after 109 ms.
Of note, Ping to your server is 49 ms, so we're looking at a single round trip to establish the TCP connection, and another single round trip to have TLS completely ready. All this confirmed inside the browser with timings: 51 ms to establish connection, another 58 ms for establishing TLS, after which the browser waits 71 ms to be served your page's initial html.
This is then followed by being shoved 80 kB of CSS and 87 kB of JavaScript, which takes approx. 250 ms to parse before the rest of the content is loaded in parallel through a connection pool, which takes a total of 1.18 s before DOM content is loaded. Page load completes after 1.66 s. Effectively, TFO could maybe shave off half a round trip, i.e. ~ 25 ms, if you take the necessary processing and added complexity into account. If you don't have any stalls or async hangups because of this, that would mean at most saving 1.5% on the page load time with TFO. Is that worth the added risk, and potential loss if you have any hangups because data is sent prematurely? I think not.
1.5% is also not "significantly accelerating" anything. Even in the theoretical ideal situation of 3%, it's still not significant.
Proof: The indicated rows are the full 3-way handshake. The TCP connection is established in 51 ms without TFO from my location to yours. TLS Client Hello on its way after 54 ms and first encrypted data being sent by the browser after 109 ms.
Of note, Ping to your server is 49 ms, so we're looking at a single round trip to establish the TCP connection, and another single round trip to have TLS completely ready. All this confirmed inside the browser with timings: 51 ms to establish connection, another 58 ms for establishing TLS, after which the browser waits 71 ms to be served your page's initial html.
This is then followed by being shoved 80 kB of CSS and 87 kB of JavaScript, which takes approx. 250 ms to parse before the rest of the content is loaded in parallel through a connection pool, which takes a total of 1.18 s before DOM content is loaded. Page load completes after 1.66 s. Effectively, TFO could maybe shave off half a round trip, i.e. ~ 25 ms, if you take the necessary processing and added complexity into account. If you don't have any stalls or async hangups because of this, that would mean at most saving 1.5% on the page load time with TFO. Is that worth the added risk, and potential loss if you have any hangups because data is sent prematurely? I think not.
1.5% is also not "significantly accelerating" anything. Even in the theoretical ideal situation of 3%, it's still not significant.
Off-topic:
P.S.: While there I noticed that you are implementing a P3P header. Don't bother with that, it's a dead, unfinished spec not used by anyone, even the spec itself states: "The Technical Architecture Group (TAG) has discontinued work on this document. The specification should not be referenced in this form or implemented as-is."
P.S.: While there I noticed that you are implementing a P3P header. Don't bother with that, it's a dead, unfinished spec not used by anyone, even the spec itself states: "The Technical Architecture Group (TAG) has discontinued work on this document. The specification should not be referenced in this form or implemented as-is."
You do not have the required permissions to view the files attached to this post.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: network.tcp.tcp_fastopen_enable
I understand everything and I repeat that you are right. But I'm a perfectionist - it's a disease
This is what the connection to my site looks like in a browser that supports TFO and TLS 1.3 0-RTT :
P.S.
P3P header installs Bitrix CMS. I can’t do anything here
You do not have the required permissions to view the files attached to this post.
-
- Moon Magic practitioner
- Posts: 2194
- Joined: 2018-05-05, 13:29
Re: network.tcp.tcp_fastopen_enable
There's something I miss: if data is sent before the last ack is sent, what happens if a delayed ack from a previous connection arrives?
Is the protocol able to differentiate it? Given that data was sent already, I mean.
The wiki doesn't say anything and maybe that's the cause of the reported hangings?
Is the protocol able to differentiate it? Given that data was sent already, I mean.
The wiki doesn't say anything and maybe that's the cause of the reported hangings?
-
- Fanatic
- Posts: 108
- Joined: 2016-12-04, 22:01
Re: network.tcp.tcp_fastopen_enable
Off-topic:
I don't understand how people who can't think about eating dogs and cats, can eat pigs. They're about the same level of intelligence and self-conciousness as dogs.
Disclaimer: I'm not vegetarian. But dogs, cats, pigs, apes, dolphins, etc. are not food for me.
I don't understand how people who can't think about eating dogs and cats, can eat pigs. They're about the same level of intelligence and self-conciousness as dogs.
Disclaimer: I'm not vegetarian. But dogs, cats, pigs, apes, dolphins, etc. are not food for me.