diff options
author | cinap_lenrek <cinap_lenrek@felloff.net> | 2015-05-14 21:09:12 +0200 |
---|---|---|
committer | cinap_lenrek <cinap_lenrek@felloff.net> | 2015-05-14 21:09:12 +0200 |
commit | 21f97338f86b9aa4a2995ddc7bbe539efadfab70 (patch) | |
tree | 0fc40c8f03bec27723371ebd4d48aa69c476badb /rc/bin/rc-httpd | |
parent | e611879eab9ad99ea6fa1f51529c4c85e679dad2 (diff) | |
download | plan9front-21f97338f86b9aa4a2995ddc7bbe539efadfab70.tar.xz |
tcp: fix loopback slowness issue / set tcb->mss for incoming connections (thanks David du Colombier)
David du Colombier wrote:
> The slowness issue only appears on the loopback, because
> it provides a 16384 MTU.
>
> There is an old bug in the Plan 9 TCP stack, were the TCP
> MSS doesn't take account the MTU for incoming connections.
>
> I originally fixed this issue in January 2015 for the Plan 9
> port on Google Compute Engine. On GCE, there is an unusual
> 1460 MTU.
>
> The Plan 9 TCP stack defines a default 1460 MSS corresponding
> to a 1500 MTU. Then, the MSS is fixed according to the MTU
> for outgoing connections, but not incoming connections.
>
> On GCE, this issue leads to IP fragmentation, but GCE didn't
> handle IP fragmentation properly, so the connections
> were dropped.
>
> On the loopback medium, I suppose this is the opposite issue.
> Since the TCP stack didn't fix the MSS in the incoming
> connection, the programs sent multiple small 1500 bytes
> IP packets instead of large 16384 IP packets, but I don't
> know why it leads to such a slowdown.
Diffstat (limited to 'rc/bin/rc-httpd')
0 files changed, 0 insertions, 0 deletions