TCP丢包浅析
前言
在管理后台的监控丢包页面上，你是否经常会看到有TCP丢包发生，虽不是很频繁，但很让人讨厌。你是否很想知道是什么原因导致TCP丢包的出现，并且很想把它解决掉。TCP丢包的原因可以有很多中，就好像人生病的原因各式各样一样，本人不才，本文只针对其中一些情况做些浅显之说明，如有不对的地方，还望指出。
丢包情况说明
假设有A B 2台机器相互通信，你可以类比想象平时我们一直在使用的dubbo调用，如果A机器有问题（比如网卡有些什么问题）、或者B机器有问题（比如操作系统有些什么问题）、或者A B之间的网路有问题的时候，都有可能发生TCP丢包现象。众所周知，TCP是一个可靠的协议，所以在发生丢包时它会通过自身的机制重传以避免出现错误。但毕竟是发生了重传，多少会影响到性能，带来一些抖动。
如果这个抖动发生在业务低谷期，或者发生在不太重要的服务上，对业务也许没有多少影响，但如果这个抖动发生在高峰期，或出现在一些重要的服务上，那么对业务的影响就会比较大了，所以当发生这种情况时，技术人员需要尽可能得去排查问题，解决问题。
那这种问题怎么排查呢，本文使用的是tcpdump工具，它是一款在Linux上及其强大的抓包工具，网上已经有很多相关的tcpdump使用方面的文章，在此不多做介绍，只说一说本次我们将要用到的功能，如果对它感兴趣，读者可以自行百度或google。
丢包现象
平时的你是否有过如下的一些经历？
- 一进入电梯时，手机似乎就卡住了，总是发不出去信息或者接受不到新信息
- 在同一个内网里，有同学在下高清电影，你的电脑的网络此时变得卡了起来，经常鼠标转圈圈
上面这些一般我们统称为网络卡了，专业一点说就是TCP丢包严重，一直在重传
tcpdump工具
tcpdump -i eth0 tcp port 10900
上面是一条tcpdump的使用举例，它的意思是在网卡eth0上监听tcp报文，且只监听端口号是10900的报文。
排查过程探究
刚才我们说了，由于发生TCP丢包的位置有3个，A机器、B机器、AB之间的网路，所以第一步就是要排查到底是哪一个位置发生了丢包，也就是先要找到丢包的机器位置。
我们假设A机器是客户端，B机器是服务端。我们的方法是，在A机器上启用tcpdump监听数据包，在B机器上也启用tcpdump监听数据包，那么可能的情况会有以下几种。
第一种，A机器上数据包发出去了，但很慢才发出去的. 第二种，A机器上数据包很快发出起了，但B机器上迟迟没有收到数据包. 第三种，A机器上数据包很快发出去了，B机器上也很快收到了数据包,但是TCP重传了.
上面的三种分别说明了完全不同的三种情况
第一种，由于A机器上的数据包发出去很慢，那表明是A机器有问题，比如A机器的发送缓冲区太小但发送数据太多、A机器上的程序设计有问题等等，于是作为技术人员的你下一步的重点就是研究A机器到底出了什么问题。
第三种，A机器发包快，B机器收包快，但依旧发生TCP重传，这是一种极其罕见的现象，想要说明白其中的细节，需要花费大量时间，本文不对此做太多细节性描述，仅做简单说明，这种情况的原因是内核的TCP参数配置不合理，导致内核不得不丢弃已经在缓冲区中的数据，而tcpdump原理是备份了一份缓冲区数据，所以会出现tcpdump显示B已经收到数据包，但应用程序没有收到的诡异现象。此时作为技术人员的你需要做的是去排查为什么B机器会丢弃已经收到的报文。
第二种，A机器发包快，说明A机器没有问题，但B机器迟迟没有收到，这个原因是AB之间的网路出现了问题，一般来说在内部网络中的2台可以通信的且处于相同网段的机器，至少有1台交换机相连，如果链接它们的交换机有问题的话，就会出现客户端发出了包但服务端迟迟没有收到的情况。此时作为技术人员的你就需要将排查重心放在AB之间的各种网络设备上。
