sk_wmem_queued是目前发送缓冲区的量
tcp_trim_head 把这快内存给去掉,
什么时候会加入到内存里呢?__tcp_add_write_queue_tail,
skb里的内存是啥?
是如何确认发送缓冲区的,发送缓冲区 sk_wmem_free_skb 当接收到了ack之后,整个skb就可以被释放掉了,所以在整个内存被发送出去之前,这些都是有可能的。所以为了
[<ffffffff816f21d2>] tcp_ack+0x1742/0x18b0
[<ffffffff816f3d04>] tcp_rcv_established+0x224/0x6d0
[<ffffffff816fd089>] tcp_v4_do_rcv+0x129/0x210
[<ffffffff8166fb9a>] __release_sock+0x5a/0x100
[<ffffffff8166fc70>] release_sock+0x30/0x90
[<ffffffff816e9f1f>] tcp_sendmsg+0x11f/0xea0
[<ffffffff8187a6de>] ? _raw_spin_unlock_irqrestore+0xe/0x10
[<ffffffff81713cd5>] inet_sendmsg+0x65/0xa0
[<ffffffff8166bde5>] sock_sendmsg+0x35/0x40
[<ffffffff8166be6b>] sock_write_iter+0x7b/0xd0
[<ffffffff8118af94>] __vfs_write+0xc4/0x120
[<ffffffff8118bb18>] vfs_write+0xb8/0x1b0
[<ffffffff8118ca66>] SyS_write+0x46/0xb0
[<ffffffff8187a760>] entry_SYSCALL_64_fastpath+0x13/0x94
End write
所以基本可以确认,所谓的发送缓冲区,其实就是一系列的skb!!!!udp协议应该发送出去就结束了。
所以,说白了,发送缓冲区就说明了,我这个sock能用到内存的最大的数量。
不对啊,收到了ack还是不能说明我这个缓冲。。。oh, my gosh,这里是发送缓存,是可以放弃的,刚才误以为是接收缓存了,ok,所以一个sock的内存都是有一个最大值的。那么下面就是一个很严肃的话题了,就是发送缓冲区,滑动窗口都是什么关系