一、TCP三次握手
这方面的理论介绍非常多，本文再引用进来的目的是方便下文如何分析的。
TCP三次握手.png
说明：引用来自CSDN文章： https://blog.csdn.net/wz947324/article/details/79917486
建立连接--传输数据--关闭连接.png
这里有几个相关的问题：
1、TCP与UDP的区别？
TCP，提供面向连接的服务，在传送数据之前必须先建立连接，数据传送完成后要释放连接。因此TCP是一种可靠的的运输服务，但是正因为这样，不可避免的增加了许多的开销，比如确认，流量控制等。
UDP，在传送数据前不需要先建立连接，远地的主机在收到UDP报文后也不需要给出任何确认。虽然UDP不提供可靠交付，但是正是因为这样，省去和很多的开销，使得它的速度比较快，比如一些对实时性要求较高的服务，就常常使用的是UDP。
2、在TCP/IP网络模型中，TCP为传输层，IP为网络层，HTTP为应用层。如果出现了通信超时的问题，应该分析哪个？
真正进行通信的实体是在主机中的进程，是一个主机中的一个进程与另外一个主机中的一个进程在交换数据。IP协议虽然能把数据报文送到目的主机，但是并没有交付给主机的具体应用进程。而端到端的通信才应该是应用进程之间的通信，所以传输层也作端到端通信(IP+port)，也作套接字（socket）。
客户端调用服务端的http接口超时的情况，我们应该分析的是TCP层。
3、TCP序列号（Sequence Number）和确认号（Acknowledgment Number）
序列号（Sequence Number）：数据包本身的序列号，这是为了连接以后传送数据用的，确认号（Acknowledgment Number）是对收到的数据包的确认，值是等待接收的数据包的序列号。
在第一次消息发送中，A随机选取一个序列号作为自己的初始序号发送给B；
第二次消息B使用ack对A的数据包进行确认，因为已经收到了序列号为x的数据包，准备接收序列号为x+1的包，所以ack=x+1，同时B告诉A自己的初始序列号，就是seq=y；
第三次消息A告诉B收到了B的确认消息并准备建立连接，A自己此条消息的序列号是x+1，所以seq=x+1，而ack=y+1是表示A正准备接收B序列号为y+1的数据包。
4、为什么TCP客户端最后还要发送一次确认呢？
一句话，主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。
如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。
如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。
5、TCP的几个状态标识
（在Transmission Control Protocol可以看到Flags: ）
Flags.png
在TCP层，有个FLAGS字段，这个字段有以下几个标识：SYN, FIN, ACK, PSH, RST, URG。
SYN表示建立连接；
FIN表示关闭连接；
ACK表示响应；
PSH表示有 DATA数据传输；
RST表示连接重置；
6、SYN flood攻击
image.png
攻击方的客户端只发送SYN分节给服务器，然后对服务器发回来的SYN+ACK什么也不做，直接忽略掉，
不发送ACK给服务器；这样就可以占据着服务器的半连接队列的资源，导致正常的客户端连接无法连接上服务器。
(SYN flood攻击的方式其实也分两种，第一种，攻击方的客户端一直发送SYN，对于服务器回应的SYN+ACK什么也不做，不回应ACK, 第二种，攻击方的客户端发送SYN时，将源IP改为一个虚假的IP, 然后服务器将SYN+ACK发送到虚假的IP, 这样当然永远也得不到ACK的回应。)
二、使用工具wireshark的分析过程
1、准备工作
设置时间显示格式,"视图"--》“时间显示格式”
image.png
查看TCP流
image.png
设置TCP的Seq和Ack的序号是相对还是实际的数字，“编辑”--》“首选项”
首选项.png
protocols里选择tcp
protocols_tcp.png
常用的过滤条件：
ip.addr eq 10.213.64.20 and ip.addr eq 47.110.181.229 and tcp
tcp.stream eq 101（在Transmission Control Protocol可以看到[Stream index: 101]）
2、准备分析
image.png
选中http记录，右键“追踪流”，选择“tcp流”
追踪流_tcp流.png
image.png
3、开始分析
（1）客户端--》服务端， 发送SYN建立连接请求
Flags: 0x002 (SYN)
Sequence number: 2698090139
Acknowledgment number: 0
.... ...0 .... = Acknowledgment: Not set （说明只发送了一个Syn请求）
.... .... ..1. = Syn: Set
image.png
（2）服务端--》客户端，发送SYN和ACK请求
Flags: 0x012 (SYN, ACK)
Sequence number: 3320903889
Acknowledgment number: 2698090140 （第一步的Seq + 1）
.... ...1 .... = Acknowledgment: Set
.... .... ..1. = Syn: Set
image.png
（3）客户端--》服务端，发送ACK请求
Flags: 0x010 (ACK)
Sequence number: 2698090140
Acknowledgment number: 3320903890 （第二步的Seq + 1）
.... ...1 .... = Acknowledgment: Set （其他的都是0）
image.png
四、统计--》流量图
tcp流量图.png
PS：能看到三次握手并不能实际对应问题，我们还需要使用wireshark分析网络拥塞，接口访问慢，TCP重复确认
https://www.cnblogs.com/nlskyfree/p/9773852.html
https://blog.csdn.net/wuxing26jiayou/article/details/79855306
网友评论