网络传输 MTU 最大是 1500 扣除以太网 TCP IP 报文头，如果我 read 一个已经握手好的 TCP 的 fd 并设置 buffer 是 4096，操作系统是尽量快速返回还是尽量塞满我的 buffer 之后再返回？
lewis89 · 2020-12-26 08:05:30 +08:00 · 2595 次点击这是一个创建于 1465 天前的主题，其中的信息可能已经有所发展或是发生改变。
第 1 条附言 · 2020-12-26 08:53:01 +08:00
第 2 条附言 · 2020-12-26 08:53:10 +08:00
已解决
 |
1
lewis89 OP 网络传输 MTU 最大是 1500 扣除以太网 TCP IP 报文头，如果我 read 一个已经握手好的 TCP 的 fd 并设置 buffer 是 4096，操作系统是尽量快速返回还是尽量塞满我的 buffer 之后再返回？
|
 |
2
fff333 2020-12-26 08:49:37 +08:00 via Android
塞满
|
 |
3
zhs227 2020-12-26 08:50:18 +08:00
有个 NAGLE 算法，发包时会稍微等一下，凑齐一个大包。可以使用 sockopt TCP_NODELAY 来关掉。读的时候应该不会等，缓冲区里有多少就读多少，除非还没有收到，或者是头部阻塞了在等重传。
想要塞满 buffer 可以多读几次，直到大于一个 buffer 以后，把多余的那一点缓存起来，放到下一轮读取里。 |
|
4
lewis89 OP @zhs227 #3 老哥真及时，我刚在 StackOverflow 上 看到
Each send call is a kernel call. But kernel calls do not correspond to individual packets, unless you've disabled packet coalescing. I suggest you read about the Nagle algorithm. https://stackoverflow.com/questions/28785437/tcp-sockets-send-buffer-size-efficiency |
|
7
lewis89 OP @zhs227 #3 Indeed, the wikipedia article strongly recommends you buffer writes yourself and disable Nagle. Reduced cost of kernel calls is another benefit.
|
 |
9
carlclone 2020-12-26 09:14:04 +08:00
意思是你自己在 user space 做缓存,而不是发给内核,内核帮你做缓存
|
|
10
carlclone 2020-12-26 09:15:15 +08:00
缓冲..打错了
|
|
11
zhs227 2020-12-26 09:52:52 +08:00  1
nagle 算法最主要的是如果你发送连续的小包，他会等一个计时器的长度，如果计时器的长度里有可以拼到一起的数据，就会拼在一起发送。这样会以延迟换取网络上发送的包数。但对于某些时间敏感的内容，比如 ssh，telnet，Nagle 算法并不合适。
上面说可以减少系统调用的应该是让应用自己凑到一定长度再发。 |
Select Language