在原文基础上有所删减，保留了个人验证过的大部分内容。
下面我以server端为视角，从 连接建立、 数据包接收 和 数据包发送 这3条路径对参数进行归类梳理。
一、连接建立
简单看下连接的建立过程，客户端向server发送SYN包，server回复SYN＋ACK，同时将这个处于SYN_RECV状态的连接保存到半连接队列。客户端返回ACK包完成三次握手，server将ESTABLISHED状态的连接移入accept队列，等待应用调用accept()。
另外，为了应对SYNflooding（即客户端只发送SYN包发起握手而不回应ACK完成连接建立，填满server端的半连接队列，让它无法处理正常的握手请求），Linux实现了一种称为SYNcookie的机制，通过net.ipv4.tcp_syncookies控制，设置为1表示开启。简单说SYNcookie就是将连接信息编码在ISN(initialsequencenumber)中返回给客户端，这时server不需要将半连接保存在队列中，而是利用客户端随后发来的ACK带回的ISN还原连接信息，以完成连接的建立，避免了半连接队列被攻击SYN包填满。对于一去不复返的客户端握手，不理它就是了。
二、数据包的接收
先看看接收数据包经过的路径：
数据包的接收，从下往上经过了三层：网卡驱动、系统内核空间，最后到用户态空间的应用。Linux内核使用sk_buff(socketkernel buffers)数据结构描述一个数据包。当一个新的数据包到达，NIC（networkinterface controller）调用DMAengine，通过RingBuffer将数据包放置到内核内存区。RingBuffer的大小固定，它不包含实际的数据包，而是包含了指向sk_buff的描述符。当RingBuffer满的时候，新来的数据包将给丢弃。一旦数据包被成功接收，NIC发起中断，由内核的中断处理程序将数据包传递给IP层。经过IP层的处理，数据包被放入队列等待TCP层处理。每个数据包经过TCP层一系列复杂的步骤，更新TCP状态机，最终到达recvBuffer，等待被应用接收处理。有一点需要注意，数据包到达recvBuffer，TCP就会回ACK确认，既TCP的ACK表示数据包已经被操作系统内核收到，但并不确保应用层一定收到数据（例如这个时候系统crash），因此一般建议应用协议层也要设计自己的确认机制。
上面就是一个相当简化的数据包接收流程，让我们逐层看看队列缓冲有关的参数。
RingBuffer
Ring Buffer位于NIC和IP层之间，是一个典型的FIFO（先进先出）环形队列。RingBuffer没有包含数据本身，而是包含了指向sk_buff（socketkernel buffers）的描述符。
可以使用ethtool-g eth0查看当前RingBuffer的设置：
上面的例子接收队列为4096，传输队列为256。可以通过ifconfig观察接收和传输队列的运行状况：
RXerrors：收包总的错误数
RX dropped:表示数据包已经进入了RingBuffer，但是由于内存不够等系统原因，导致在拷贝到内存的过程中被丢弃。
RX overruns:overruns意味着数据包没到RingBuffer就被网卡物理层给丢弃了，而CPU无法及时的处理中断是造成RingBuffer满的原因之一，例如中断分配的不均匀。
当dropped数量持续增加，建议增大RingBuffer，使用ethtool-G进行设置。
InputPacket Queue(数据包接收队列)
当接收数据包的速率大于内核TCP处理包的速率，数据包将会缓冲在TCP层之前的队列中。接收队列的长度由参数net.core.netdev_max_backlog设置。 recvBuffer
recv buffer是调节TCP性能的关键参数。BDP(Bandwidth-delayproduct，带宽延迟积) 是网络的带宽和与RTT(roundtrip time)的乘积，BDP的含义是任意时刻处于在途未确认的最大数据量。RTT使用ping命令可以很容易的得到。为了达到最大的吞吐量，recvBuffer的设置应该大于BDP，即recvBuffer >= bandwidth * RTT。假设带宽是100Mbps，RTT是100ms，那么BDP的计算如下：
BDP = 100Mbps * 100ms = (100 / 8) * (100 / 1000) = 1.25MB
Linux在2.6.17以后增加了recvBuffer自动调节机制，recvbuffer的实际大小会自动在最小值和最大值之间浮动，以期找到性能和资源的平衡点，因此大多数情况下不建议将recvbuffer手工设置成固定值。
三、数据包的发送
发送数据包经过的路径：
和接收数据的路径相反，数据包的发送从上往下也经过了三层：用户态空间的应用、系统内核空间、最后到网卡驱动。应用先将数据写入TCP sendbuffer，TCP层将sendbuffer中的数据构建成数据包转交给IP层。IP层会将待发送的数据包放入队列QDisc(queueingdiscipline)。数据包成功放入QDisc后，指向数据包的描述符sk_buff被放入RingBuffer输出队列，随后网卡驱动调用DMAengine将数据发送到网络链路上。
同样我们逐层来梳理队列缓冲有关的参数。
sendBuffer
发送端缓冲的自动调节机制很早就已经实现，并且是无条件开启，没有参数去设置。
QDisc
QDisc（queueing discipline ）位于IP层和网卡的ringbuffer之间。我们已经知道，ringbuffer是一个简单的FIFO队列，这种设计使网卡的驱动层保持简单和快速。而QDisc实现了流量管理的高级功能，包括流量分类，优先级和流量整形（rate-shaping）。可以使用tc命令配置QDisc。
QDisc的队列长度由txqueuelen设置，和接收数据包的队列长度由内核参数net.core.netdev_max_backlog控制所不同，txqueuelen是和网卡关联，可以用ifconfig命令查看当前的大小：
使用ifconfig调整txqueuelen的大小：
ifconfig eth0 txqueuelen 2000
RingBuffer
和数据包的接收一样，发送数据包也要经过RingBuffer，使用ethtool-g eth0查看：
其中TX项是RingBuffer的传输队列，也就是发送队列的长度。设置也是使用命令ethtool-G。
TCPSegmentation和Checksum Offloading
操作系统可以把一些TCP/IP的功能转交给网卡去完成，特别是Segmentation(分片)和checksum的计算，这样可以节省CPU资源，并且由硬件代替OS执行这些操作会带来性能的提升。
一般以太网的MTU（MaximumTransmission Unit）为1500 bytes，假设应用要发送数据包的大小为7300bytes，MTU1500字节－ IP头部20字节 －TCP头部20字节＝有效负载为1460字节，因此7300字节需要拆分成5个segment：
Segmentation(分片)操作可以由操作系统移交给网卡完成，虽然最终线路上仍然是传输5个包，但这样节省了CPU资源并带来性能的提升：
可以使用ethtool-k eth0查看网卡当前的offloading情况：
上面这个例子checksum和tcpsegmentation的offloading都是打开的。如果想设置网卡的offloading开关，可以使用ethtool-K(注意K是大写)命令，例如下面的命令关闭了tcp segmentation offload：
sudo ethtool -K eth0 tso off