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的内存都是有一个最大值的。那么下面就是一个很严肃的话题了，就是发送缓冲区，滑动窗口都是什么关系