• TCP和UDP、TCP三次握手、TCP为什么要进行三次握手不是两次、TCP四次挥手、TCP和UDP的区别、TCP抓包分析、TCP什么时候三次挥手


    获取报文需要用到抓包工具,抓包可以先看:
    Wireshark下载、Wireshark使用、Wireshark抓包、ARP抓包、ICMP抓包、TCP抓包、HTTP抓包

    TCP和UDP

    网络传输分为五层,应用层、传输层、网络层、数据链路层、物理层。
    TCP和UDP都工作在传输层, 目标是在程序之间传输数据,数据可以是文本、视频、图片
    对于TCP/UDP来说,都是一堆二进制数,没什么区别

    对于TCP/UDP最大的区别是:TCP基于连接,UDP是非连接
    请添加图片描述
    TCP如何保证上述三个步骤:分别是三次握手,确认连接,四次挥手,断开连接。

    模拟TCP协议

    如何模拟一个TCP协议,xshell远程连接服务器就可以捕获到完整的TCP3次握手的连接。

    在这里插入图片描述

    TCP三次握手

    请添加图片描述

    TCP三次握手是建立连接的过程: 客户端和服务端建立请求时,
    会先发送一包连接请求数据,
    先去询问一下,能否与你建立连接,这包数据称之为SYN包
    如果对端同意连接,客户端收到之后回复一包ACK包,并将SYN一同回复
    客户端收到之后,回复一包ACK包,连接建立

    交互过程中,互相发送了三包数据,因此称之为三次握手

    为什么要进行三次握手不是两次?
    两次也就是说在服务端回复完SYN+ACK之后建立连接,三次是为了防止因为已失效的请求报文,突然又传到服务器引起错误。

    两次握手举例如下:
    比如服务端传送SYN1包之后,由于网络滞留,服务端没有收到
    为了建立连接客户端会重发SYN2包,这次数据包正常送达服务端,服务端回复SYN2+ACK包,之后建立连接
    之后阻塞的网络节点回复,之前滞留的SYN1包重新发送到服务端,这时服务端会误认为是客户端又发起了一个新的连接,服务端回复SYN1+ACK包,之后建立连接,进入等待数据的状态。
    服务端认为是两个连接,而客户端认为是一个连接,因此造成了状态不一致。

    而三次握手之后,服务端收不到最后的ACK包,自然不会认为建立连接成功,所以三次握手就是为了解决网络信道不可靠的问题,为了能够在不可靠的信道上建立起可靠的连接,经过了三次握手之后,客户端和服务端都进入了数据传输状态。

    连接建立之后,又会面对新的问题:

    • 一包数据有可能被拆成多包发送
    • 如何处理丢包问题
    • 数据包到达的先后顺序不同,如何处理乱序问题

    请添加图片描述
    针对这些问题,TCP为每一个连接建立了一个发送缓冲区,从建立连接的第一个序列号为0,后面每个字节的序列号就会增加1,发送数据时,从发送缓冲区取一部分数据组成发送报文在其TCP协议头中会附带序列号和长度,接收端在收到数据后,需要回复确认报文,确认报文中的ACK等于接收序列号+长度,也就是下一包数据需要发送的起始序列号,这样一问一答的方式,能够使发送端确认发送的数据已经被对方收到,发送端也可以一次连续的发送多包数据,接收端只需要回复一次ACK就可以,这样发送端可以把待发送的数据分割成一系列的碎片,发送到对端,对端根据序列号和长度,在接收后重构出完整的数据,假设其中丢失了某些数据包,在接收端可以要求发送端重传,比如丢失了100~200序号的数据,接收端向发送端发送ACK=100的报文,发送端收到后,重传这一包数据,接收端进行补齐,以上过程不区分客户端和服务端,TCP连接是全双工的,对于两端来说,均采用上述机制

    TCP四次挥手

    四次挥手的过程

    1. 第一次挥手: 发起端A发起FIN+ACK,表示自己没数据要发了,请求断开连接,同时进入FIN_WAIT_1状态
    2. 第二次挥手: 对端B收到FIN后,知道发起端不再有数据进行传输,发送ACK进行确认,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号),对端B进入CLOSE_WAIT状态
    3. 第三次挥手: 对端B发送FIN+ACK给对方,表示自己也没有数据发送了,对端B进入LAST_ACK状态,然后直接断开TCP会话的连接,释放相应的资源
    4. 第四次挥手: 发起端收到对端B的FIN信号,进入TIMED_WAIT状态,并发送ACK确认消息。发起端在TIMED_WAIT状态下,等待一段时间,没有数据到来,就认为对面已经收到了自己发送的ACK并正确关闭了进入CLOSE状态,自己也断开了TCP连接,释放所有资源。当对端B收到ACK回应后,会进入CLOSE状态并关闭本端的会话接口,释放相应资源
      处于连接状态的客户端和服务端都可以发起关闭连接的请求,比如xshell连接,你可以自己关闭,也会超时关闭。
      此时需要四次挥手来进行连接关闭。

    请添加图片描述

    假设客户端主动发起连接关闭请求,

    • 它需要向服务端发起一份FIN包,自己进入终止等待1状态,这是第一次挥手,
    • 服务端收到FIN包,回复一包ACK包,表示自己进入了关闭等待状态,客户端进入终止等待2状态,这是第二次挥手,
    • 服务端此时还可以发送数据,客户端也可以接收数据,待服务端发送完数据之后,服务端发送一包FIN包,进入最后确认状态,这是第三次挥手
    • 客户端收到后回复ACK包,服务端收到ACK包后立即关闭连接,而客户端进入超时等待状态,经过超时时间后关闭连接

    为什么客户端需要等待超时时间?
    这是为了保证对方已经收到ACK包,因为假设客户端发送完最后一包ACK就立即释放连接,一旦ACK包在网络中丢失,服务端将一直停留在最后确认状态,如果客户端发送最后一包ACK包之后,等待一段时间,这时服务端会因为没有收到ACK包而重发FIN包(重复第三次挥手),客户端会响应这个FIN包,重发ACK包并刷新超时时间。
    这个机制和三次握手一样,为了能够在不可靠的信道上进行可靠的断开连接确认。

    UDP协议

    UDP协议是基于非连接的,发送数据就是简单的把数据包封装一下,然后从网卡发出去就可以了,数据包之间并没有状态上的联系,正因为UDP这种简单的处理方式,导致它的性能损耗非常少,对于CPU、内存资源的占用也远小于TCP,但是对于网络传输过程中的丢包,UDP协议并不能保证,所以UDP在传输稳定性上要弱于TCP

    TCP和UDP的区别

    TCP:稳定可靠, 适用于对网络通讯质量要求较高的场景,需要准确无误的传输给对方。
    比如传输文件、发送邮件、浏览网页等。
    UDP:速度快,但是可能产生丢包, 所以适用于对实时性要求较高,但是对少量丢包并没有太大的场景。
    比如域名查询、语音通话、视频直播等。
    UDP还有一个非常重要的应用场景就是隧道网络:比如VPN,以及在SDN中用到的VXLAN。

    TCP报文分析

    物理机想和client建立连接
    过滤器选择TCP、ip.addr选择xhell连接的ip地址即可
    在这里插入图片描述

    TCP三次握手建立连接

    三次握手就是三次确认的过程

    第一次握手,物理机发送SYN数据包给client

    在这里插入图片描述

    第一次握手的Flags标志位如下

    在这里插入图片描述
    在这里插入图片描述

    第二次握手,client同意连接,client发送SYN+ACK给物理机

    在这里插入图片描述

    在这里插入图片描述

    第三次握手,物理机发送ACK确认到client

    在这里插入图片描述

    在这里插入图片描述

    在这里插入图片描述

    前面三次握手是TCP建立连接的过程,后面就是相互通信,这个时候seq会根据数据包的大小改变
    可以查看图表,通过菜单:统计>流量图,选择对应类型

    在这里插入图片描述

    在这里插入图片描述

    TCP四次挥手断开连接

    三次挥手报文

    使用关闭按钮关闭终端
    在这里插入图片描述
    从图上报文看,可以发现少了一次挥手,少一次ACK确认,变成了三次挥手,这是因为TCP 延迟确认机制。

    当被动关闭方在 TCP 挥手过程中,如果「没有数据要发送」,同时「没有开启 TCP_QUICKACK(默认情况就是没有开启,没有开启 TCP_QUICKACK,等于就是在使用 TCP 延迟确认机制)」,那么第二和第三次挥手就会合并传输,这样就出现了三次挥手。

    四次挥手报文

    本机打开终端(监控的是WLAN),使用curl发送http请求

    # -I:仅返回头部信息
    curl -I baidu.com
    
    • 1
    • 2

    在这里插入图片描述

    在这里插入图片描述

    总结

    四次挥手,断开连接

    1.服务端FIN :Seq = a , Ack = b #我想断开连接
    2.客户端ACK:Seq = b, Ack = a+1 #收到,断开吧
    3.客户端FIN :Seq = b, Ack = a+1 #我也想断开连接
    4.服务端ACK:Seq = a+1, Ack = b+1 #收到,断开吧

    三次挥手,断开连接

    1.客户端FIN :Seq = a , Ack = b #我想断开连接
    2.服务端FIN :Seq = b, Ack = a+1 #收到,断开吧。我也想断开连接
    3.客户端ACK:Seq = a+1, Ack = b+1 #收到,断开吧

    基于TCP/UDP协议的应用层协议有哪些?

    TCP/UDP都是传输层的协议 (上面是应用层,下面是网络层IP层)

    1.基于TCP的应用层协议有:HTTP、FTP、SMTP、TELNET、SSH
    协议 全称 默认端口
    HTTP ( 用的最多) HyperText Transfer Protocol(超文本传输协议) 80
    FTP File Transfer Protocol (文件传输协议) 20用于传输数据,21用于传输控制信息
    SMTP Simple Mail Transfer Protocol (简单邮件传输协议) 25
    TELNET Teletype over the Network (网络电传) 23
    SSH Secure Shell 22
    2.基于UDP的应用层协议:DNS、TFTP(简单文件传输协议)、SNMP:简单网络管理协议
    协议 全称 默认端口
    DNS Domain Name Service (域名服务) 53
    TFTP Trivial File Transfer Protocol (简单文件传输协议) 69
    SNMP Simple Network Management Protocol (简单网络管理协议) 通过UDP端口161接收,只有Trap信息采用UDP端口162。
    NTP Network Time Protocol (网络时间协议) 123
    RADIUS是Remote Authentication Dial In User Service的简称,即远程验证拨入用户服务.
    RADIUS协议的认证端口号为1812(1645端口由于冲突已经不再使用),计费端口号为1813或(1646端口由于冲突已经
    不再使用).

    HTTP协议

    HTTP是TCP的上层协议,因此过滤时用TCP也可以,用HTTP过滤分为会更小

    本机打开终端(监控的是WLAN),使用curl发送http请求

    # -I:仅返回头部信息
    curl -I baidu.com
    
    • 1
    • 2

    在这里插入图片描述
    用本机终端curl的,因此,发起的源地址为IPv4地址
    在这里插入图片描述
    抓包
    在这里插入图片描述

    只过滤curl这个相关的,手动输入过滤器过滤信息、或者选中一条,右键跟踪流,执行对应流的跟踪,都可以整理出这个请求的完整跟踪会话。
    在这里插入图片描述

    在这里插入图片描述
    可以看到这是一次完整的三次挥手,建立连接,发送数据,四次挥手,断开连接的一个过程。

  • 相关阅读:
    板对板连接器选型
    centos7安装tomcat9过程
    【分布式应用】消息队列之卡夫卡 + EFLFK集群部署
    xv6源码解析(一)——系统启动
    Naive UI 中使用message组件,在.vue文件之外使用
    测试登录界面:Python
    springboot+基于web的传染病信息管理系统的设计与实现 毕业设计-附源码221124
    window office
    前端开发需要会什么?先掌握这三大核心关键技术
    edge收藏夹
  • 原文地址:https://blog.csdn.net/qq_41929714/article/details/126873809