12

The command shows the tcp receive buffer size in bytes.

$ cat /proc/sys/net/ipv4/tcp_rmem 
4096    87380   4001344

where the three values signifies the min, default and max values respectively.

Then I tried to find the tcp window size using tcpdump command.

 $ sudo tcpdump -n -i eth0 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and port 80 and host google.com' 
 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
 listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
 16:15:41.465037 IP 172.16.31.141.51614 > 74.125.236.73.80: Flags [S], seq 3661804272,  win  14600, options [mss 1460,sackOK,TS val 4452053 ecr 0,nop,wscale 6], length 0

I got the window size to be 14600 which is 10 times the size of MSS.

Can anyone please tell me the relationship between the two.

pradeepchhetri
  • 2,698
  • 6
  • 37
  • 47

2 Answers2

11

The TCP window size is how much data can be "in flight" on the network. The TCP receive buffer is how much data can be buffered on the recipient's end.

Normally, a TCP stack will not allow data to be sent if it has no room for it in its receive buffer. Otherwise, if the data is received before the receiving application consumes some of the data in the buffer, the data would have to be throw away by the receiving TCP stack.

But the receive buffer can be much larger than the window.

With the settings you've shown (14,600 / 87,380), this end will allow the other end to send 14,600 bytes. As it receives data, it will update the window to allow to other end to send the lesser of 14,600 bytes or 87,380 bytes less the number of bytes waiting in its receive buffer.

David Schwartz
  • 31,449
  • 2
  • 55
  • 84
  • I still don't get why we need these two parameters "data in flight" and recipient buffer as two separate quantities. The aim of "data in flight" (advertised window) is to avoid the overfilling the buffer. Why is the buffer size needed as a separate parameter – David Apr 11 '15 at 16:06
  • 2
    @David The aim of data in flight is not to avoid overfilling the buffer, it's to handle the delay introduced by the communications channel. Adapting to the bandwidth and latency of the communications channel is one issue, adapting to the application's read behavior is another. – David Schwartz Apr 12 '15 at 01:25
-3

It is recommended in the rfc https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-initcwnd-00 that the sender window of tcp should be 10 segments, which also results in the initrwnd of the receiver to be 10*MSS to accommodate the that first ten packets.If you look further, you will see that the recwnd in the packet increases as the receiver get new packets.

The number of tcp_rmem represent min default max buffer size each. As it takes more space in Linux to store TCP scoket structure, only 3/4 or 1/2 of the num is respond to the advertised window size.

You can go and look at the blog http://sandilands.info/sgordon/impact-of-bandwidth-delay-product-on-tcp-throughput and its comments for further information.

Community
  • 1
juejiang
  • 101