【网络编程】 粘包问题/TCPdump(抓包)/滑动窗口(糊涂窗口)

本文深入探讨了TCP协议中的粘包现象,解释了为何会出现粘包问题以及它可能带来的影响。针对粘包,提出了按长度发送和接收的解决方案,并介绍了TCP的三次握手和四次挥手过程,确保连接的可靠建立和关闭。同时,讨论了TIME_WAIT状态的重要性,防止旧连接报文干扰新连接。此外,还提到了糊涂窗口综合征及其解决方法,以及TCP的流量控制机制如滑动窗口。最后,简单介绍了TCP抓包工具TCPdump的应用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

请添加图片描述
大于4096 临时端口
由于TCP是面向连接的,所以可以连接多个客户端支持并发。
粘包(流式服务的特点):TCP流式服务,recv从接收缓冲一次读取数据,而send时多次写入发送缓冲区
不是所有的粘包都会出现问题。
比如 :
1.发1000个数据,不论对方如何接收,一次接收,10个10个接收,并不影响。
2.但是比如发送 一个长方体的长2宽3高4,计算其长宽高,但是接收方一次收取234。体积就无法返回。
【粘包问题】如何解决:

  • 第一方案
    send(2)一次
    recv (2)一次
    send(3)一次
    recv (3)一次
    send(4)
    recv (4)
  • 解析包:【2】【3】【4】,将最后的收到的数据包进行解析。
  • 对每个报文进行起始标记/结束标记
    2; 3; 4;
  • 三次握手状态
    CLOSED : 没有任何连接
    SYN:发起一个链接
    RST:重新发起连接``
    LISTEN ;侦听状态,等待TCP连接
    SYN_SENT: 已发送请求连接等待匹配链接(发送能力正常)
    SYN_RCVD:接收和发送一个连接后等待匹配连接(发送和接收能力正常)
  • 四次挥手的状态
    ESTABLISHED 连接状态
    FIN_WAIT1:等待TCP中断请求
    CLOSE_WAIT:等待从本地用户发来的 连接中断请求 FIN_WAIT2: 等待TCP中断请求
    LAST_ACK:最后确认
    TIME_WAIT : 等待2MSL(两个报文时间)后关闭连接
    MSL:一个报文在网络中存活的最长时间
    为什么要有TIME_WAIT
    请添加图片描述

请添加图片描述

  1. 保证客户端发送的最后一个ACK报文段能够到达服务端。(可靠的终止TCP连接)
    如果如果客户端发送的ACK,没有被(处于LAST_ACK
    状态的)服务器端在2MSL没有收到客户端的最后ACK,就会重新发送FIN ACK,等待客户端收到并且回复确认序列ACK,服务器端收到ACK报文,才会正常关闭,处于CLOSED状态。
    如果没有这2MSL,(FIN_WAIT2)客户端收到 (处于LAST_ACK状态的)服务器发送的FIN+ACK,后回复ACK,立即关闭连接,如果该ACK报文,没有被服务器收到,那么服务器就无法进入正常的CLOSED状态。
  2. 防止“已失效的连接请求报文段”出现在本连接中。(保证迟来的TCP报文段有足够的时间识别并丢弃 )
    等待2MSL,是为了让网络中产生的所有报文消失。否则,那些由于客户端和服务器关闭,滞留在网络中的报文,很可能会出现下一次新连接中。(且该链接绑定的端口和服务器的端口一样,但是不能让其被下个连接接收)
    请添加图片描述
    同发FIN 同时关闭
    请添加图片描述
  • 当AB在局域网内,a ,b两台主机建立连接。拔掉网线。在插上网线,会是什么状态。
    服务器端就会关闭,重新打开服务器也是处于CLOSED状态,客户端没有收到任何关闭的信息,但是客户端以为已经完成三次握手,直到一发数据,发现数据发不了(序号值不匹配)。需要重新发起连接。(RST 重新连接)
    可靠性:
    tcp:确认应答:发送方每发送一次数据,接收方都会回复ack
    超时重传(没有收到对方的确认ack,就会重新发送报文)
    乱序重排(去重,序号相同的报文会丢弃)(报文发送的早,不一定先到达,因此会给每个报文都带有一个序号(随机产生),到达后,会重新排序)
    滑动窗口(流量控制,控制开关):每次发送数据,都是一段数据。(发送数据的大小 由窗口决定)
    请添加图片描述
    使用TCPdump观察TCP连接的建立和关闭(抓包过程)
    抓包命令:(管理员身份)
    请添加图片描述
    请添加图片描述
    带S,会显示ACK的值而不是1。

  • 三次握手
    请添加图片描述

  • 客户端发送"hello"
    服务器回复"ok"
    请添加图片描述
    实际上客户端发送数据hello,服务器会回复ack
    服务器回复ok,客户端回复ack

  • 四次挥手
    请添加图片描述

  • 思考问题:

  1. 接收端填充的接收通过窗口为0,发送端接下来怎么处理?
    滑动窗口的大小不能超过,接收一次允许传递的最大数据量

  2. 什么叫糊涂窗口综合征?
    定义:当发送端应用进程产生数据很慢、或接收端应用进程处理接收缓冲区数据很慢,或二者兼而有之;
    因为糊涂窗口综合征的原因使大量小数据在网络上传输,而且由于TCP是一种可靠的传输协议,每个数据包都要用一个ACK来确认(没用使用延迟确认情况下如此),所以浪费一些时间,而且丢包和失序的可能性也增加了。
    解决方案:发送端:a.全长的报文段可以发送
    b.数据段长度>=接收端通告过的最大窗口值的一半的,可以发送
    c.满足一下任一条件的都可以发送:
    (i)某一ACK不是目前期盼的(即没有未经确认的在传数据)。
    (ii)该连接禁用Nagle算法。
    接收端:在窗口可增至一个全长的报文段(即接收端的MSS)或缓冲空间一半之前,不能·通告比当前窗口(可能是0)更大的窗口值。

  3. 在 TCP 的实现中广泛使用的 Nagle 算法是什么?

  4. 什么是抓包?
    就是将网络传输发送与接收的数据包进行截获、重发、编辑、转存等操作,也用来检查网络安全。抓包也经常被用来进行数据截取等。
    抓包的目的就是为了获取到想要的原始数据,拿到数据以后,我们就可以做以下一些事情:

  • 分析数据传输协议。

     定位网络协议的问题。 
    
    从数据包中获取想要的信息。 
    
    将截取到的数据包进行修改,伪造,重发。
    
  • ping 查看物理网络是否连通。
    请添加图片描述
    《unix网络编程》第四章和第五章死锁

<think>好的,用户现在想了解与测试相关的UDP和TCP知识。首先,我需要回忆一下之前用户的历史问题,之前他们询问过进程和线程的知识,作为测试工程师需要掌握的内容。现在他们转向网络协议,特别是UDP和TCP,这可能在测试网络应用、性能、稳定性等方面很重要。 首先,用户可能是在准备面试,或者在工作中需要处理网络相关的测试任务。他们的真实需求可能是想了解这两个协议的区别,以及如何在测试中应用这些知识,比如如何设计测试用例,定位问题,或者性能调优。 接下来,我需要整理UDP和TCP的关键点。两者的主要区别在于连接性、可靠性、传输方式等。测试工程师需要知道这些差异,因为不同的应用场景会使用不同的协议,比如视频流常用UDP,而网页浏览用TCP。测试时,针对不同的协议,侧重点也不同。 然后,考虑测试中的应用场景。比如,对于TCP,需要测试连接建立和终止的正确性,重传机制,流量控制等。而对于UDP,则要关注丢处理,无序数据传输,以及如何保证应用层的可靠性。此外,性能测试方面,UDP可能更关注吞吐量和延迟,而TCP可能需要测试在高延迟或丢情况下的表现。 还要括常见的测试工具,比如Wireshark用于抓包分析,iperf3用于带宽测试,tc命令模拟网络状况等。这些工具在测试中非常实用,用户可能需要具体的例子来理解如何使用。 另外,用户可能关心面试常见问题,比如三次握手、四次挥手的过程,如何测试TCP的重传,或者UDP的丢处理。需要准备一些示例,比如用代码片段展示如何模拟丢或测试并发连接。 最后,总结测试重点,强调协议特性对测试策略的影响,以及如何利用工具进行分析。确保回答结构清晰,分点明确,帮助用户逐步理解并应用到实际测试工作中。</think>以下是测试工程师需要掌握的**UDP**和**TCP**核心知识整理,结合测试场景的实践应用说明: --- ### **一、协议基础对比** | **特性** | **TCP** | **UDP** | |------------------|----------------------------------------|----------------------------------| | **连接性** | 面向连接(三次握手、四次挥手) | 无连接 | | **可靠性** | 可靠传输(确认、重传、排序) | 不可靠(可能丢、乱序) | | **传输方式** | 流式传输(数据无明确边界) | 数据报文(有明确边界) | | **头部开销** | 大(20~60字节) | 小(8字节) | | **典型应用** | HTTP、FTP、数据库连接 | 视频流、DNS、实时游戏 | --- ### **二、测试中的应用场景** #### **1. TCP测试重点** - **连接管理** - 验证三次握手建立连接的可靠性(如SYN洪水攻击防御测试)。 - 测试异常断开(如强制终止连接、网络抖动)是否触发四次挥手。 - **重传机制** - 模拟丢(工具:`tc`命令限速/丢),观察TCP重传次数是否符合预期。 - 测试超时重传时间(RTO)的自适应调整(如高延迟网络下的性能)。 - **流量控制** - 验证滑动窗口机制(如接收方缓冲区满时是否暂停发送)。 - 测试拥塞控制算法(如TCP Reno、Cubic在不同网络条件下的表现)。 #### **2. UDP测试重点** - **丢容忍性** - 设计高丢率场景(如弱网模拟),验证应用层是否补偿(如重传或容错)。 - 示例:视频会议工具在UDP丢时是否降画质保流畅。 - **报文完整性** - 检查UDP报文边界(如发送`"Hello|World"`,接收端是否收到完整的两条消息)。 - 测试大数据分片(MTU限制)后的重组是否正确。 - **无序处理** - 模拟报文乱序(工具:`Scapy`),验证应用层是否重新排序。 --- ### **三、常见测试问题与工具** #### **1. 性能测试** - **TCP瓶颈分析** - 测试最大并发连接数(工具:`wrk`、`JMeter`)。 - 观察长连接场景下的内存泄漏(如未正确释放连接)。 - **UDP吞吐量测试** - 使用`iperf3`测量UDP带宽(命令:`iperf3 -u -c <server_ip>`)。 - 验证应用层协议是否因UDP无拥塞控制导致带宽占满。 #### **2. 可靠性测试** - **TCP/拆** - 发送快速连续的小数据(如`A`和`B`),验证接收端是否能区分(如设计协议头标记长度)。 - 示例: ```python # 客户端发送两个连续消息 sock.send(b"Hello") sock.send(b"World") # 服务端可能一次性接收"HelloWorld"(需应用层拆解) ``` - **UDP服务可用性** - 模拟UDP端口耗尽攻击(如伪造大量源IP发送请求),测试服务是否崩溃。 #### **3. 工具与命令** - **抓包分析** - `Wireshark`:查看TCP握手过程或UDP报文内容。 - `tcpdump`:过滤特定协议(命令:`tcpdump tcp port 80`)。 - **网络模拟** - `tc`命令模拟延迟/丢: ```bash # 添加100ms延迟 + 10%丢 tc qdisc add dev eth0 root netem delay 100ms loss 10% ``` --- ### **四、面试常见问题** 1. **TCP三次握手过程是什么?为什么要三次?** - **答案**: 1. 客户端发送`SYN=1, seq=x`。 2. 服务端回复`SYN=1, ACK=1, seq=y, ack=x+1`。 3. 客户端发送`ACK=1, seq=x+1, ack=y+1`。 - **原因**:防止历史连接请求造成混乱(两次无法确认客户端接收能力)。 2. **如何测试TCP问题?** - **方法**: - 快速发送多个小,观察接收端是否合并。 - 设计固定长度的协议头(如4字节表示数据长度)。 3. **UDP如何实现可靠传输?** - **方案**:在应用层添加确认重传机制(如QUIC协议)。 --- ### **五、总结** - **TCP测试核心**:连接管理、重传机制、流量控制。 - **UDP测试核心**:丢容忍、报文边界、无序处理。 - **高阶技巧**:结合抓包工具分析协议细节,模拟极端网络条件验证健壮性。 掌握这些知识,能帮助你在网络通信测试中精准定位协议层问题! 🔧
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值