TCP可靠性保证和tcpdump命令使用

作者: 李亚林1990 | 来源:发表于2019-01-21 20:44 被阅读40次

TCP可靠性保证和tcpdump命令使用
TCP 如何保证可靠性
网络抓包
Tcpdump抓包命令使用
tcpdump的基本命令和使用
TCP 除了三次握手你还需要知道的东西
tcpdump抓取指定报文
tcpdump命令学习
TCP协议
TCP 可靠性保证

上篇分析了LengthFieldBasedFrameDecoder，只需要简单灵活的指定几个参数就能满足多种情况下的拆包处理，将服务端接收到的二进制流基于长度前缀法解析为一个个的ByteBuf消息体。
但是请设想一下异常的情况：如果网络传输过程中出现丢帧或者长度域中某个位在模数转换时出现了意外没有得到正确转换，是否意味着所有的消息体都无法再得到正确的解析了呢？本篇我们就来聊聊TCP协议的可靠性保证。

温故知新，首先我们回忆一下TCP报文结构：

image.png

16 位源端口号和 16 位目的端口号：端口号通常也称为进程地址。网络中的两个终端通信，说到底其实是两个终端上的各自的进程在通信，通过端口号才能区分响应的数据包来自远端的哪一个，以及需要发送到本机的哪个进程来处理。
32 位序号：序号用来标识从 TCP 发送端向 TCP 接收端发送的数据字节流。
32 位确认序列号：表示一个准备接收包的序列号。
4 位首部长度：首部长度指出了首部中 32 bit 字的数目，正常的 TCP 首部长度是 20 字节。
6 个标志字段：URG 紧急指针；ACK 确认序号；PSH 推标志；RST 重建连接；SYN 同步序号；
FIN 结束标志。
16 位窗口：TCP 的流量控制由连接的每一端通过声明的滑动窗口大小来提供，窗口大小为字节数。
16 位检验和：检验和字段覆盖了 TCP 首部和 TCP 数据。TCP 检验和的计算方法和 UDP 检验和的
计算方法一样，计算时需要考虑伪报头。
16 位紧急指针：URG 标志置 1 时紧急指针才有效。

可以看出TCP通过多种方式来保证消息的可靠性：
1、检验和：保证接收到字节流未出现模数转换异常
2、序号和确认序列号：发送方对每个字节进行编号，接收方对接收的数据包进行序号确认，超时后发送方会重发。
3、滑动窗口大小：通过设置滑动窗口大小表示自身socket缓冲区的大小，防止缓冲区满后发送方仍然不停发数据导致的丢包。

tcpdump是一款强大的命令，通过tcpdump可以很方便的排查出网络连接中的一些故障问题。下面是我在本机和es服务通信的一段抓包信息：

[root@localhost ~]# tcpdump -i any -c 100 host 192.168.1.77 and tcp and port 5601
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
20:13:30.311360 IP 192.168.1.77.50316 > 192.168.1.99.esmagent: Flags [P.], seq 2903948008:2903948424, ack 1028358340, win 255, length 416
20:13:30.321104 IP 192.168.1.99.esmagent > 192.168.1.77.50316: Flags [P.], seq 1:274, ack 416, win 190, length 273
20:13:30.321383 IP 192.168.1.99.esmagent > 192.168.1.77.50316: Flags [.], seq 274:3194, ack 416, win 190, length 2920
20:13:30.321395 IP 192.168.1.99.esmagent > 192.168.1.77.50316: Flags [.], seq 3194:6114, ack 416, win 190, length 2920
20:13:30.321399 IP 192.168.1.99.esmagent > 192.168.1.77.50316: Flags [.], seq 6114:9034, ack 416, win 190, length 2920
20:13:30.321404 IP 192.168.1.99.esmagent > 192.168.1.77.50316: Flags [.], seq 9034:11954, ack 416, win 190, length 2920
20:13:30.322488 IP 192.168.1.77.50316 > 192.168.1.99.esmagent: Flags [.], ack 3194, win 256, length 0
20:13:30.322502 IP 192.168.1.99.esmagent > 192.168.1.77.50316: Flags [.], seq 11954:13414, ack 416, win 190, length 1460
20:13:30.322508 IP 192.168.1.99.esmagent > 192.168.1.77.50316: Flags [P.], seq 13414:13528, ack 416, win 190, length 114
20:13:30.322561 IP 192.168.1.77.50316 > 192.168.1.99.esmagent: Flags [.], ack 6114, win 256, length 0
20:13:30.323577 IP 192.168.1.77.50316 > 192.168.1.99.esmagent: Flags [.], ack 9034, win 256, length 0
20:13:30.323654 IP 192.168.1.77.50316 > 192.168.1.99.esmagent: Flags [.], ack 11954, win 256, length 0
20:13:30.323658 IP 192.168.1.77.50316 > 192.168.1.99.esmagent: Flags [.], ack 13528, win 256, length 0
20:13:30.338768 IP 192.168.1.77.50316 > 192.168.1.99.esmagent: Flags [P.], seq 416:921, ack 13528, win 256, length 505
20:13:30.339477 IP 192.168.1.99.esmagent > 192.168.1.77.50316: Flags [P.], seq 13528:13838, ack 921, win 198, length 310
20:13:30.346640 IP 192.168.1.77.50316 > 192.168.1.99.esmagent: Flags [P.], seq 921:1397, ack 13838, win 255, length 476

本次tcpdump抓包过滤规则：
ip为192.168.1.77，tcp协议，端口为5601的前100个数据包。

可以清晰的看到，es服务在接收到请求数据包后，连续发送了5个数据包，分别为：
seq 1:274, ack 416, win 190, length 273
seq 274:3194, ack 416, win 190, length 2920
seq 3194:6114, ack 416, win 190, length 2920
seq 6114:9034, ack 416, win 190, length 2920
seq 9034:11954, ack 416, win 190, length 2920
而接收方在接收到数据包后依次发送了确认包：
ack 3194, win 256, length 0
ack 6114, win 256, length 0
ack 9034, win 256, length 0
ack 11954, win 256, length 0
可以看到接收方并不需要对每一个数据包进行确认，ack 3194代表接收方对3194之前的数据包都进行了确认。
嗯，至此算是对本篇开头的疑问进行了解答。

图片来自参考资料：
《网络协议分析及应用实验教程》