用了TCP协议，就一定不会丢包吗？( 二 ) _TCP协议

文章插图

TCP三次握手
在服务端，第一次握手之后，会先建立个半连接，然后再发出第二次握手。这时候需要有个地方可以暂存这些半连接。这个地方就叫半连接队列。
如果之后第三次握手来了，半连接就会升级为全连接，然后暂存到另外一个叫全连接队列的地方，坐等程序执行accept()方法将其取走使用。

文章插图

半连接队列和全连接队列
是队列就有长度，有长度就有可能会满，如果它们满了，那新来的包就会被丢弃。
【用了TCP协议，就一定不会丢包吗？】可以通过下面的方式查看是否存在这种丢包行为。

# 全连接队列溢出次数#.NETstat -s | grep overflowed4343 times the listen queue of a socket overflowed# 半连接队列溢出次数# netstat -s | grep -i "SYNs to LISTEN sockets dropped"109 times the listen queue of a socket overflowed

从现象来看就是连接建立失败。

文章插图

这个话题在之前写的《没有accept ，能建立TCP连接吗？》有更详细的聊过，感兴趣的可以回去看下。

流量控制丢包应用层能发网络数据包的软件有那么多，如果所有数据不加控制一股脑冲入到网卡，网卡会吃不消，那怎么办？让数据按一定的规则排个队依次处理，也就是所谓的qdisc(Queueing Disciplines ，排队规则) ，这也是我们常说的流量控制机制。
排队，得先有个队列，而队列有个长度。
我们可以通过下面的ifconfig命令查看到，里面涉及到的txqueuelen后面的数字1000 ，其实就是流控队列的长度。
当发送数据过快，流控队列长度txqueuelen又不够大时，就容易出现丢包现象。

文章插图

qdisc丢包
可以通过下面的ifconfig命令，查看TX下的dropped字段，当它大于0时，则有可能是发生了流控丢包。

# ifconfig eth0eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>mtu 1500inet 172.21.66.69netmask 255.255.240.0broadcast 172.21.79.255inet6 fe80::216:3eff:fe25:269fprefixlen 64scopeid 0x20<link>ether 00:16:3e:25:26:9ftxqueuelen 1000(Ethernet)RX packets 6962682bytes 1119047079 (1.0 GiB)RX errors 0dropped 0overruns 0frame 0TX packets 9688919bytes 2072511384 (1.9 GiB)TX errors 0dropped 0 overruns 0carrier 0collisions 0

当遇到这种情况时，我们可以尝试修改下流控队列的长度。比如像下面这样将eth0网卡的流控队列长度从1000提升为1500.
# ifconfig eth0 txqueuelen 1500
网卡丢包网卡和它的驱动导致丢包的场景也比较常见，原因很多，比如网线质量差，接触不良。除此之外，我们来聊几个常见的场景。

RingBuffer过小导致丢包上面提到，在接收数据时，会将数据暂存到RingBuffer接收缓冲区中，然后等着内核触发软中断慢慢收走。如果这个缓冲区过小，而这时候发送的数据又过快，就有可能发生溢出，此时也会产生丢包。

文章插图

RingBuffer满了导致丢包
我们可以通过下面的命令去查看是否发生过这样的事情。
# ifconfigeth0:RX errors 0dropped 0overruns 0frame 0查看上面的overruns指标，它记录了由于RingBuffer长度不足导致的溢出次数。

当然，用ethtool命令也能查看。