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 算法并不合适。
上面说可以减少系统调用的应该是让应用自己凑到一定长度再发。 |