【TCP3次握手4次挥手】Wireshark抓包分析TCP建立和断开连接的过程
使用wireshark抓网口的包,然后查找特定的tcp流,wireshark命令和使用不做解释。
#tcp.stream eq 23
一.网络模型简介
常见的网络模型是大家熟知的OSI7层网络模型和TCP/IP4层网络模型,简单介绍如下。
>OSI 7层网络模型
>TCP/IP 4层模型
>5层模型
从前面的4层模型可以看到,最底层的网络接口层实际包含:物理层+数据链路层。所以实际的TCP/IP 包含5层模型。后面讲解数据包的时候也是以5层模型为基础,介绍每一层的数据如何封装的。
二、数据传输单元
我们经常说使用抓包工具进行抓包,那么抓包工具抓的包是哪一层的数据,包里面包含哪些信息?信息在网络模型中是如何层层封装的?在了解这些之前,需要先了解网络模型数据在不同层次中间传输时的数据单元。
下面是5层模型中,数据的单元。5层模型的数据格式从上到下层层封装,最后到物理层进行传输。
应用层——消息(message:报文)
传输层——数据段(segment)
网络层——分组、数据包(packet)
链路层——帧(frame)
物理层——P-PDU(bit)
1.报文(message)
报文是网络中交换与传输的数据单元,也是网络传输的单元。报文包含了将要发送的完整的数据信息,其长短不需一致。报文在传输过程中会不断地封装成分组、包、帧来传输,封装的方式就是添加一些控制信息组成的首部,那些就是报文头。
2.分组(packet)
分组是在网络中传输的二进制格式的单元,为了提供通信性能和可靠性,每个用户发送的数据会被分成多个更小的部分。在每个部分的前面加上一些必要的控制信息组成的首部,有时也会加上尾部,就构成了一个分组。
3.数据包(data packet)
数据包是TCP/IP协议通信传输中的数据单元,也称为“包”。是指自包含的,带有足够寻址信息,可独立地从源主机传输到目的主机,而不需要依赖早期的源主机和目的主机之间交换信息以及传输网络的数据包。
4.数据报(datagram)
面向无连接的数据传输,其工作过程类似于报文交换。采用数据报方式传输时,被传输的分组称为数据报。
5.帧(frame)
帧是数据链路层的传输单元。它将上层传入的数据添加一个头部和尾部,组成了帧。
在不同层有不同的协议,网络抓包工具可以指定协议进行抓包,因此抓包的实际内容就是数据封装到当前层时的全部信息。
简单的例子:
- 1.应用层的包:应用层的包需要包含全部5层的信息,因为应用层的消息是最原始的信息,需要层层封装后进行物理传输。
例如HTTP GET包应该包含:应用层,传输层,网络层,数据链路层,物理层。下面是抓包例子:
- 2.传输层的包:传输层应该包含4层的全部信息:传输层,网络层,数据链路层,物理层。
三、5层数据信息
下面详细介绍一下5层模型中,每一层数据单元包含的信息:
1.物理层:
下面是信息的解释:
2.数据链路层
下面是信息的解释:
3.网络层
下面是数据单元的解释:
4.传输层
下面是数据单元的解释:
5.应用层
四、TCP数据包头部信息
下面是TCP数据包头部的详细信息:
下图显示了TCP包头的组成:
下面是部分头部字段的解释:注意红色字体部分,对我们理解后面的TCP3次握手4次挥手有帮助。
序号(Sequence Number) 4字节:简写:seq
确认号(Acknowledge Number) 4字节:简写:ack(注意与ACK的区别)
标志位字段(U、A、P、R、S、F):占6比特。各 比特的含义如下:
URG:紧急比特(urgent),当URG=1时,表明紧急指针字段有效,代表该封包为紧急封包。它告诉系统此报文段中有紧急数据,应尽快传送(相当于高优先级的数据), 且上图中的 Urgent Pointer 字段也会被启用。
ACK:确认比特(Acknowledge)。只有当ACK=1时确认号字段才有效,代表这个封包为确认封包。当ACK=0时,确认号无效。
PSH:(Push function)若为1时,代表要求对方立即传送缓冲区内的其他对应封包,而无需等缓冲满了才送。
RST:复位比特(Reset) ,当RST=1时,表明TCP连接中出现严重差错(如由于主机崩溃或其他原因),必须释放连接,然后再重新建立运输连接。
SYN:同步比特(Synchronous),SYN置为1,就表示这是一个连接请求或连接接受报文,通常带有 SYN 标志的封包表示『主动』要连接到对方的意思。。
FIN:终止比特(Final),用来释放一个连接。当FIN=1时,表明此报文段的发送端的数据已发送完毕,并要求释放运输连接。
五、TCP3次握手建立连接
这个过程大家可能都挺熟悉,了解TCP连接建立需要3次(3个TCP包)。
下面是上面过程的抓包分析:客户端(10.30.30.13:20809端口)--->请求服务器(10.30.2.120:80端口)的过程抓包分析
下面对三次握手(3个TCP包)的详细信息进行分析:
- 1.第一次握手(截图第一行):10.30.30.13客户端---发送SYN包(SYN=1,seq=x)--10.30.2.120服务器
- 2.第二次握手(截图第二行):10.30.2.120服务器----发送SYN,ACK包(SYN=1,ACK=1,seq=y,ack=x+1)---10.30.30.13客户端
- 3.第三次握手(截图第3行的TCP):10.30.30.13客户端----发送ACK(ACK=1,seq=x+1,ack=y+1)---10.30.2.120服务器
总结三次握手过程:
最初两端的TCP进程都处于CLOSED关闭状态,A主动打开连接,而B被动打开连接。(A、B关闭状态CLOSED——B收听状态LISTEN——A同步已发送状态SYN-SENT——B同步收到状态SYN-RCVD——A、B连接已建立状态ESTABLISHED)
- B的TCP服务器进程先创建传输控制块TCB,准备接受客户进程的连接请求。然后服务器进程就处于LISTEN(收听)状态,等待客户的连接请求。若有,则作出响应。
- 1)第一次握手:A的TCP客户进程也是首先创建传输控制块TCB,然后向B发出连接请求报文段,(首部的同步位SYN=1,初始序号seq=x),(SYN=1的报文段不能携带数据)但要消耗掉一个序号,此时TCP客户进程进入SYN-SENT(同步已发送)状态。
- 2)第二次握手:B收到连接请求报文段后,如同意建立连接,则向A发送确认,在确认报文段中(SYN=1,ACK=1,确认号ack=x+1,初始序号seq=y),测试TCP服务器进程进入SYN-RCVD(同步收到)状态;
- 3)第三次握手:TCP客户进程收到B的确认后,要向B给出确认报文段(ACK=1,确认号ack=y+1,序号seq=x+1)(初始为seq=x,第二个报文段所以要+1),ACK报文段可以携带数据,不携带数据则不消耗序号。TCP连接已经建立,A进入ESTABLISHED(已建立连接)。
- 当B收到A的确认后,也进入ESTABLISHED状态。
(2)总结三次握手过程:
- 第一次握手:起初两端都处于CLOSED关闭状态,Client将标志位SYN置为1,随机产生一个值seq=x,并将该数据包发送给Server,Client进入SYN-SENT状态,等待Server确认;
- 第二次握手:Server收到数据包后由标志位SYN=1得知Client请求建立连接,Server将标志位SYN和ACK都置为1,ack=x+1,随机产生一个值seq=y,并将该数据包发送给Client以确认连接请求,Server进入SYN-RCVD状态,此时操作系统为该TCP连接分配TCP缓存和变量;
- 第三次握手:Client收到确认后,检查ack是否为x+1,ACK是否为1,如果正确则将标志位ACK置为1,ack=y+1,并且此时操作系统为该TCP连接分配TCP缓存和变量,并将该数据包发送给Server,Server检查ack是否为y+1,ACK是否为1,如果正确则连接建立成功,Client和Server进入ESTABLISHED状态,完成三次握手,随后Client和Server就可以开始传输数据。
起初A和B都处于CLOSED状态——B创建TCB,处于LISTEN状态,等待A请求——A创建TCB,发送连接请求(SYN=1,seq=x),进入SYN-SENT状态——B收到连接请求,向A发送确认(SYN=ACK=1,确认号ack=x+1,初始序号seq=y),进入SYN-RCVD状态——A收到B的确认后,给B发出确认(ACK=1,ack=y+1,seq=x+1),A进入ESTABLISHED状态——B收到A的确认后,进入ESTABLISHED状态。
TCB传输控制块Transmission Control Block,存储每一个连接中的重要信息,如TCP连接表,到发送和接收缓存的指针,到重传队列的指针,当前的发送和接收序号。
(3)为什么A还要发送一次确认呢?可以二次握手吗?
答:主要为了防止已失效的连接请求报文段突然又传送到了B,因而产生错误。如A发出连接请求,但因连接请求报文丢失而未收到确认,于是A再重传一次连接请求。后来收到了确认,建立了连接。数据传输完毕后,就释放了连接,A工发出了两个连接请求报文段,其中第一个丢失,第二个到达了B,但是第一个丢失的报文段只是在某些网络结点长时间滞留了,延误到连接释放以后的某个时间才到达B,此时B误认为A又发出一次新的连接请求,于是就向A发出确认报文段,同意建立连接,不采用三次握手,只要B发出确认,就建立新的连接了,此时A不理睬B的确认且不发送数据,则B一致等待A发送数据,浪费资源。
(4)Server端易受到SYN攻击?
服务器端的资源分配是在二次握手时分配的,而客户端的资源是在完成三次握手时分配的,所以服务器容易受到SYN洪泛攻击,SYN攻击就是Client在短时间内伪造大量不存在的IP地址,并向Server不断地发送SYN包,Server则回复确认包(SYN_RCVD状态),并等待Client确认,由于源地址不存在,因此Server需要不断重发直至超时,这些伪造的SYN包将长时间占用未连接队列,导致正常的SYN请求因为队列满而被丢弃,从而引起网络拥塞甚至系统瘫痪。
防范SYN攻击措施:降低主机的等待时间使主机尽快的释放半连接的占用,短时间受到某IP的重复SYN则丢弃后续请求。
六、TCP4次挥手断开连接
下面是4次挥手的抓包结果:
截图和TCP3次握手差不多,下面描述TCP4次挥手抓包的结果如下:
- 1.第1次挥手:客户端--发送FIN,ACK--服务器(FIN=1,ACK=1,seq=u,ack=v)
- 2.第2次挥手:服务器---发送ACK--客户端(ACK=1,seq=v,ack=u+1)
- 3.第3次挥手:服务器---发送FIN,ACK--客户端(FIN=1,ACK=1,seq=w,ack=u+1)
- 4.第4次挥手:客户端---发送ACK---服务器(ACK=1,seq=u+1,ack=w+1)
(1)总结4次挥手过程:
数据传输结束后,通信的双方都可释放连接,A和B都处于ESTABLISHED状态。(A、B连接建立状态ESTABLISHED——A终止等待1状态FIN-WAIT-1——B关闭等待状态CLOSE-WAIT——A终止等待2状态FIN-WAIT-2——B最后确认状态LAST-ACK——A时间等待状态TIME-WAIT——B、A关闭状态CLOSED)
- 1)A的应用进程先向其TCP发出连接释放报文段(FIN=1,序号seq=u),并停止再发送数据,主动关闭TCP连接,进入FIN-WAIT-1(终止等待1)状态,等待B的确认。
- 2)B收到连接释放报文段后即发出确认报文段,(ACK=1,确认号ack=u+1,序号seq=v),B进入CLOSE-WAIT(关闭等待)状态,此时的TCP处于半关闭状态,A到B的连接释放。
- 3)A收到B的确认后,进入FIN-WAIT-2(终止等待2)状态,等待B发出的连接释放报文段。
- 4)B没有要向A发出的数据,B发出连接释放报文段(FIN=1,ACK=1,序号seq=w,确认号ack=u+1),B进入LAST-ACK(最后确认)状态,等待A的确认。
- 5)A收到B的连接释放报文段后,对此发出确认报文段(ACK=1,seq=u+1,ack=w+1),A进入TIME-WAIT(时间等待)状态。此时TCP未释放掉,需要经过时间等待计时器设置的时间2MSL后,A才进入CLOSED状态。
(2)四次挥手过程:
起初A和B处于ESTABLISHED状态——A发出连接释放报文段并处于FIN-WAIT-1状态——B发出确认报文段且进入CLOSE-WAIT状态——A收到确认后,进入FIN-WAIT-2状态,等待B的连接释放报文段——B没有要向A发出的数据,B发出连接释放报文段且进入LAST-ACK状态——A发出确认报文段且进入TIME-WAIT状态——B收到确认报文段后进入CLOSED状态——A经过等待计时器时间2MSL后,进入CLOSED状态。
(3)为什么A在TIME-WAIT状态必须等待2MSL的时间?
MSL最长报文段寿命Maximum Segment Lifetime,MSL=2
答: 两个理由:1)保证A发送的最后一个ACK报文段能够到达B。2)防止“已失效的连接请求报文段”出现在本连接中。
- 1)这个ACK报文段有可能丢失,使得处于LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认,B超时重传FIN+ACK报文段,而A能在2MSL时间内收到这个重传的FIN+ACK报文段,接着A重传一次确认,重新启动2MSL计时器,最后A和B都进入到CLOSED状态,若A在TIME-WAIT状态不等待一段时间,而是发送完ACK报文段后立即释放连接,则无法收到B重传的FIN+ACK报文段,所以不会再发送一次确认报文段,则B无法正常进入到CLOSED状态。
- 2)A在发送完最后一个ACK报文段后,再经过2MSL,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失,使下一个新的连接中不会出现这种旧的连接请求报文段。
(4)为什么连接的时候是三次握手,关闭的时候却是四次握手?
答:因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。
(5)为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?
答:虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。