Wireshark抓包实战：TCP三次握手、四次挥手与超时重传全解析

发布时间：2026/10/20 4:07:23

1. 抓包之前先想清楚TCP实验到底在验证什么很多人做Wireshark的TCP实验打开软件就开始抓抓完一看满屏的包完全不知道从哪下手。我刚开始接触的时候也是这样抓了上百个包最后只看出哦有三次握手然后就没了。后来带过几批新人做实验我发现问题的根源不在工具而在于动手之前没有想清楚这个实验到底要验证哪些TCP的核心机制。TCP协议本身是一个庞大的话题但落到Wireshark实验这个场景里核心就是几件事连接怎么建立、数据怎么传、连接怎么断、出了问题怎么恢复。这四件事对应到协议层面就是三次握手、数据传输与确认、四次挥手、超时重传与流量控制。你抓包的目的就是用真实的报文把这几件事看见。所以这篇内容适合两类人一类是正在做计算机网络课程实验的学生需要一份能直接照着操作的指南另一类是想重新梳理TCP底层细节的开发者平时写代码调网络问题总觉得抓包看到的东西和课本对不上。不管你是哪一类我都会从环境准备开始一步步把每个环节的操作、参数、判断依据讲清楚并且告诉你哪些地方容易踩坑。关键词方面Wireshark抓包、TCP三次握手、TCP四次挥手、序列号与确认号、超时重传、滑动窗口、流量控制这些会贯穿全文。我不会堆砌术语而是把每个术语放到具体的报文里让你看到它长什么样、为什么是这个值。另外说一句做这个实验不需要多复杂的网络环境。一台电脑装好Wireshark能上网或者能访问局域网内的某台服务器就够了。真正重要的是你对报文字段的解读能力这个能力一旦建立起来以后排查任何网络问题都用得上。2. 实验环境搭建与抓包前的关键设置2.1 工具准备与网卡选择Wireshark的安装没什么好说的官网下载对应系统的版本一路下一步就行。Windows上安装的时候会提示安装Npcap这个必须装它是底层抓包驱动不装的话Wireshark找不到任何网卡。安装过程中有一个选项叫Restrict Npcap to administrators only如果你不是管理员账户建议不要勾选否则普通用户权限下抓不了包。装完之后打开Wireshark你会看到网卡列表。这里有个选择的问题到底抓哪块网卡。如果你用的是有线网络选以太网那块如果用WiFi选WLAN那块。怎么确认看网卡旁边的实时流量波形图哪个在动就选哪个。我见过有同学对着一个完全没流量的虚拟网卡抓了半天还纳闷为什么一个包都没有。提示如果你不确定选哪块网卡可以先随便选一块然后看Wireshark左上角的接口列表有流量波动的就是当前活跃的网卡。选好网卡之后先不要急着点开始。Wireshark默认会抓取网卡上的所有流量在实验室或者宿舍这种共享网络环境下你会抓到大量和你无关的包。所以下一步是设置过滤器。2.2 捕获过滤器的正确写法过滤器分两种捕获过滤器Capture Filter和显示过滤器Display Filter。这两个的区别很关键很多人搞混。捕获过滤器是在抓包之前设置的它决定Wireshark只抓哪些包不满足条件的包直接丢弃不写入内存。显示过滤器是在抓包之后用的它不丢弃任何包只是把满足条件的包筛出来给你看。捕获过滤器用BPF语法显示过滤器用Wireshark自己的语法两者写法完全不同。做TCP实验我建议在捕获阶段就加上过滤条件减少干扰。常用的捕获过滤器写法# 只抓某台特定主机的流量 host 192.168.1.100 # 只抓某台主机且协议为TCP的流量 host 192.168.1.100 and tcp # 只抓某个端口相关的TCP流量 tcp port 80 # 抓某台主机与另一台主机之间的TCP流量 host 192.168.1.100 and host 203.0.113.5 and tcp这里有个实操经验如果你要访问的是某个网站先用ping或者nslookup拿到它的IP地址然后把IP填进捕获过滤器。但要注意很多大型网站用的是CDN你解析出来的IP和实际建立TCP连接的IP可能不一样。更稳妥的做法是先用一个宽松的过滤器抓一小段看看实际通信的对端IP是什么再收紧过滤条件。注意捕获过滤器一旦设置不满足条件的包就彻底看不到了。如果你不确定过滤条件写得对不对宁可先不加过滤器抓完再用显示过滤器筛。抓多了可以删抓少了就得重来。2.3 抓包位置的选择与影响这一点很多人忽略但它直接影响你看到的报文内容。Wireshark抓包的位置决定了你能看到什么层次的协议数据。如果你在本机抓包看到的是本机网卡进出的流量。这种情况下你看到的TCP报文是完整的序列号、确认号、窗口大小、标志位都能看到。但有一个问题本机的TCP/IP协议栈可能会对报文做一些处理比如网卡硬件卸载TSO、LRO导致你看到的报文长度和实际传输的不一致。如果你在中间设备上抓包比如交换机镜像端口、路由器看到的是经过转发的流量。这种方式的优点是不影响本机协议栈看到的是真实在网络上跑的包。缺点是需要额外的设备配置权限。对于课程实验来说本机抓包完全够用。但你要知道一个现象有时候你会看到一些奇怪的报文比如长度特别大的TCP段或者校验和显示不正确。这通常是网卡硬件卸载导致的不是真的有问题。可以在Wireshark的设置里关掉相关选项或者直接忽略这些异常。2.4 实验目标的确定与流量构造抓包之前你得明确这次要抓什么。TCP实验通常要覆盖以下几个场景三次握手建立连接的过程数据传输发送数据、确认收到、窗口更新四次挥手断开连接的过程超时重传丢包后的恢复机制流量控制接收方通过窗口大小控制发送方速率要触发这些场景你需要构造相应的流量。最简单的办法是访问一个网页HTTP over TCP的交互过程天然包含握手、数据传输和挥手。但网页访问的流量比较杂有多个并发连接分析起来不够干净。我更推荐用curl或者wget访问一个简单的HTTP资源比如一个纯文本文件。这样只有一条TCP连接报文序列清晰。如果要触发超时重传可以用tc命令Linux或者网络模拟工具人为制造丢包。如果要观察流量控制可以传输一个大文件同时观察接收窗口的变化。# 用curl访问一个HTTP资源只请求一次 curl -v http://example.com/test.txt # 如果要持续传输大文件观察窗口变化 curl -o /dev/null http://example.com/largefile.bin在Windows上可以用PowerShell的Invoke-WebRequest或者直接用浏览器访问。关键是一次只做一件事不要同时开多个应用否则抓到的包会混在一起分析难度直线上升。3. 三次握手从报文里读出连接建立的每一步3.1 抓取三次握手的操作步骤先启动Wireshark选好网卡设置捕获过滤器为tcp port 80假设你访问的是HTTP服务。然后点开始抓包接着在浏览器或命令行里发起请求。请求完成后回到Wireshark点停止。这时候你应该能看到一串TCP报文。找到第一个SYN包这就是三次握手的起点。Wireshark的显示过滤器在这里很好用输入tcp.flags.syn 1就能筛出所有SYN包。三次握手的三个报文分别是客户端发送SYN序列号为初始序列号ISN比如Seq0服务端回复SYNACK序列号为服务端的ISN确认号为客户端ISN1客户端发送ACK确认号为服务端ISN1在Wireshark的报文详情面板里展开Transmission Control Protocol这一层你能看到所有关键字段。我建议你把这三个包的这几个字段都记下来报文标志位序列号确认号窗口大小第一个包SYN客户端ISN0客户端窗口第二个包SYN, ACK服务端ISN客户端ISN1服务端窗口第三个包ACK客户端ISN1服务端ISN1客户端窗口3.2 序列号与确认号的解读逻辑序列号和确认号是TCP里最容易让人迷糊的东西但理解了之后其实很直观。序列号表示我这个报文里携带的数据的第一个字节在整个数据流中的位置。注意SYN和FIN这两个标志位虽然不携带数据但它们各占一个序列号。这就是为什么第二个包的确认号是客户端ISN1——那个1就是确认收到了客户端的SYN。确认号表示我期望下一次收到你的数据的第一个字节的序号。它等于我已经收到的最后一个字节的序号1。这是一种累积确认机制确认号N表示N之前的所有字节都收到了。举个例子客户端ISN是1000发送SYN。服务端回复SYNACK确认号是1001意思是我收到了你的SYN占序号1000我期望你下一个字节从1001开始。服务端的ISN假设是5000那么客户端回复的ACK确认号就是5001。提示Wireshark默认显示的是相对序列号也就是把ISN显示为0后续的序列号都是相对于ISN的偏移。这样看起来更直观。如果你想看真实的绝对序列号可以在TCP协议首选项里关掉Relative sequence numbers。3.3 为什么是三次而不是两次或四次这个问题面试经常问但很多人背答案不理解。从报文的角度看三次握手的本质是双方各自确认自己和对方的收发能力都正常。第一次握手客户端发SYN服务端收到。服务端确认了客户端的发送能力正常我的接收能力正常。第二次握手服务端发SYNACK客户端收到。客户端确认了我的发送能力正常服务端的接收和发送能力都正常。第三次握手客户端发ACK服务端收到。服务端确认了客户端的接收能力正常。两次不够因为服务端无法确认客户端能收到自己的报文。四次多余因为第二次握手已经把服务端的SYN和ACK合并了。从抓包的角度你可以验证这一点第一个SYN包之后如果服务端没有回复SYNACK客户端会重传SYN。重传的时间间隔是指数退避的通常是1秒、2秒、4秒、8秒这样递增。你可以在Wireshark里看到这些重传的SYN包序列号相同时间间隔逐渐拉大。3.4 握手阶段的常见异常与排查实际抓包时三次握手不一定都顺利。几种常见情况SYN没有响应客户端发了SYN但一直没有收到SYNACK。可能原因是对端服务没启动、防火墙拦截、或者路由不可达。在Wireshark里表现为只有SYN包没有后续。SYN被拒绝服务端回复的是RSTACK而不是SYNACK。这通常意味着目标端口没有服务在监听。RST包在Wireshark里会标红很容易识别。SYN重传客户端发了多个SYN序列号相同时间间隔递增。这说明第一个SYN丢了或者响应丢了。如果最终握手成功说明是偶发丢包如果一直重传到超时说明连接建立失败。SYNACK重传服务端发了多个SYNACK说明客户端没有回复ACK。可能是客户端的ACK丢了也可能是客户端已经放弃了连接。排查的时候重点看时间间隔和序列号。时间间隔能告诉你重传了几次、退避到什么程度序列号能告诉你这些包是不是同一个连接的。4. 数据传输与确认看懂滑动窗口和确认机制4.1 数据报文的抓取与筛选三次握手完成后紧接着就是数据传输。在Wireshark里你可以用显示过滤器tcp.len 0来筛出所有携带数据的TCP报文。这些报文的TCP载荷长度大于0说明它们承载了应用层数据。如果你访问的是一个网页数据报文可能比较多因为HTML、CSS、JS、图片都是通过TCP传输的。为了分析方便建议访问一个纯文本文件这样数据报文少而清晰。抓取数据报文的时候注意观察几个关键字段Seq这个报文携带的数据的起始序号Ack对之前收到的数据的确认LenTCP载荷长度Win接收窗口大小这四个字段的组合能让你还原出整个数据传输的过程。4.2 序列号推进与累积确认TCP的数据传输是字节流不是报文流。每个字节都有一个序号序列号标识的是这个报文里第一个字节的序号。如果报文携带了100字节的数据那么下一个报文的序列号就是当前序列号100。确认号是累积的。假设客户端连续发了三个报文序列号分别是1、101、201每个携带100字节。服务端收到后可以只发一个ACK确认号是301表示1到300字节我都收到了我期望下一个字节从301开始。这就是累积确认它减少了确认报文的数量。在Wireshark里你可以通过tcp.analysis.ack_rtt字段看到每个ACK的往返时间。这个值反映了从发送数据到收到确认的时间差是评估网络延迟的重要指标。注意Wireshark的Expert Information功能会自动标记一些异常比如重传、乱序、重复ACK。在菜单栏的分析里可以打开。做实验的时候这个功能能帮你快速定位问题报文。4.3 滑动窗口的工作机制滑动窗口是TCP流量控制的核心。接收方通过TCP头部的窗口大小字段告诉发送方我还能接收多少字节的数据。发送方根据这个值调整发送速率确保不会把接收方的缓冲区撑爆。窗口大小是动态变化的。当接收方处理了缓冲区里的数据窗口会变大当接收方来不及处理窗口会变小甚至变成0。窗口为0的时候发送方会停止发送数据直到接收方发送窗口更新通知。在Wireshark里你可以通过tcp.window_size_value字段看到每个报文的窗口大小。如果要做流量控制实验可以传输一个大文件同时观察窗口大小的变化曲线。Wireshark的统计菜单里有TCP流图形可以画出窗口大小随时间的变化。这里有一个容易混淆的概念窗口缩放因子。TCP头部的窗口字段只有16位最大表示65535字节。但在高速网络中这个值太小了。所以TCP引入了窗口缩放选项在握手阶段协商一个缩放因子实际的窗口大小等于窗口字段值左移缩放因子位。Wireshark会自动计算实际窗口大小显示在tcp.window_size字段里。4.4 延迟确认与Nagle算法的影响实际抓包时你会发现有些数据报文没有立即被确认而是等了一小段时间。这是延迟确认机制在起作用。接收方不会每收到一个报文就发一个ACK而是等一小段时间通常40ms到200ms看有没有更多数据可以一起确认。这样可以减少ACK报文的数量提高网络效率。另一个影响报文发送节奏的是Nagle算法。它要求发送方在收到前一个报文的ACK之前不发送新的小报文。这样可以把多个小数据合并成一个大的TCP段发送减少网络上的小包数量。这两个机制在Wireshark里的表现是你可能会看到一个ACK确认了多个数据报文或者多个小数据被合并成一个大的TCP段。这些都不是异常而是TCP的正常优化行为。但有时候这些优化会带来问题。比如在交互式应用中延迟确认和Nagle算法叠加可能导致明显的延迟。这时候可以通过设置TCP_NODELAY选项来禁用Nagle算法。在Wireshark里你可以通过观察报文的时间间隔来判断是否存在这种问题。4.5 数据阶段的异常分析数据传输阶段常见的异常包括重传同一个序列号的数据被发送了多次。Wireshark会标记为TCP Retransmission。重传的原因可能是数据丢了也可能是ACK丢了。快速重传接收方收到乱序报文时会立即发送重复ACK。发送方收到三个重复ACK后不等超时就重传丢失的报文。这就是快速重传机制。在Wireshark里你会看到三个相同的ACK紧接着一个重传的数据报文。乱序报文的序列号不连续后面的报文先到了。Wireshark会标记为TCP Out-of-Order。乱序本身不是错误但如果频繁发生说明网络路径上存在多路径或者负载均衡。零窗口接收方通告窗口大小为0发送方停止发送。这通常意味着接收方应用层处理速度跟不上。如果零窗口持续很长时间可能是接收方应用出了问题。窗口探测当窗口为0时发送方会定期发送窗口探测报文询问接收方窗口是否更新。这个报文只携带1字节数据或者不携带数据序列号是上一个已发送字节的序号。5. 四次挥手连接释放的完整过程5.1 挥手报文的抓取与识别四次挥手发生在数据传输结束之后。主动关闭方发送FIN被动关闭方回复ACK然后被动关闭方也发送FIN主动关闭方回复ACK。这四个报文完成了连接的完全释放。在Wireshark里用显示过滤器tcp.flags.fin 1可以筛出所有FIN包。通常你会看到两个FIN包一个来自客户端一个来自服务端。挥手的四个报文主动关闭方发送FINACK序列号为最后一个数据字节的序号1被动关闭方回复ACK确认号为FIN的序列号1被动关闭方发送FINACK序列号为它最后一个数据字节的序号1主动关闭方回复ACK确认号为FIN的序列号1注意FIN和SYN一样虽然不携带数据但各占一个序列号。这就是为什么确认号要1。5.2 为什么挥手需要四次挥手比握手多一次原因是TCP连接是全双工的。握手的时候服务端可以把SYN和ACK合并成一个报文因为服务端收到SYN后可以立即决定是否接受连接。但挥手的时候被动关闭方收到FIN后可能还有数据没发完不能立即发送FIN。所以它先回复一个ACK等数据发完了再发送FIN。这就导致了四次挥手FIN、ACK、FIN、ACK。中间的两个报文不能合并因为被动关闭方的数据发送和连接关闭是两个独立的事件。在某些情况下被动关闭方没有数据要发了它可以把ACK和FIN合并成一个报文这样就变成了三次挥手。在Wireshark里你会看到第二个报文同时带有ACK和FIN标志。5.3 TIME_WAIT状态的意义主动关闭方发送最后一个ACK后会进入TIME_WAIT状态等待2MSL最大报文段生存时间后才真正关闭连接。在Linux上这个时间通常是60秒。TIME_WAIT的作用有两个一是确保最后一个ACK能到达被动关闭方如果ACK丢了被动关闭方会重传FIN主动关闭方还能响应二是让本次连接的所有报文在网络中消失避免影响后续使用相同四元组的新连接。在Wireshark里你无法直接看到TIME_WAIT状态因为它是协议栈内部的状态。但你可以通过netstat命令查看# Linux/Mac netstat -an | grep TIME_WAIT # Windows netstat -an | findstr TIME_WAIT如果TIME_WAIT状态的连接过多可能会耗尽本地端口资源。这时候可以调整内核参数比如开启TIME_WAIT重用。但这是把双刃剑需要根据实际场景权衡。5.4 挥手阶段的异常情况FIN重传主动关闭方发了FIN但没有收到ACK会重传FIN。在Wireshark里表现为多个FIN包序列号相同。RST代替FIN有时候连接不是正常关闭的而是被RST强制终止。RST包表示连接异常立即终止。常见于应用崩溃、端口关闭、或者协议错误。在Wireshark里RST包会被标红。半关闭状态一方发送了FIN但另一方还在发送数据。这时候连接处于半关闭状态。在Wireshark里你会看到FIN之后还有数据报文。这是正常的TCP允许半关闭。连接被拒绝如果主动关闭方发送FIN后收到RST说明对端已经不认这个连接了。可能是对端已经关闭了连接或者中间设备拦截了报文。6. 超时重传与流量控制TCP的可靠性保障6.1 超时重传的触发条件与观察方法超时重传是TCP保证可靠性的核心机制。发送方每发送一个报文就启动一个定时器。如果在定时器超时之前没有收到确认就重传这个报文。在Wireshark里超时重传的报文会被标记为TCP Retransmission。你可以通过tcp.analysis.retransmission过滤器筛出所有重传报文。要人为制造重传可以用网络模拟工具制造丢包。在Linux上tc命令可以模拟丢包# 在网卡eth0上模拟10%的丢包率 sudo tc qdisc add dev eth0 root netem loss 10% # 实验结束后删除规则 sudo tc qdisc del dev eth0 root在Windows上可以用Clumsy或者NetLimiter这类工具模拟丢包。观察重传的时候注意重传的时间间隔。TCP使用指数退避算法第一次重传等待1个RTO重传超时时间第二次等待2个RTO第三次等待4个RTO以此类推。RTO本身是根据RTT动态计算的Wireshark会显示每个重传报文的相对时间。6.2 快速重传与重复ACK超时重传的问题是等待时间太长。如果发送方收到三个重复ACK就可以推断某个报文丢了立即重传不用等超时。这就是快速重传。重复ACK的产生过程接收方收到乱序报文时会立即发送ACK确认号还是期望的那个序号。发送方收到多个相同的ACK就知道中间有报文丢了。在Wireshark里你会看到这样的序列发送方发了Seq1、Seq101、Seq201三个报文但Seq101丢了。接收方收到Seq1后回复Ack101收到Seq201后还是回复Ack101因为101没收到。发送方收到三个Ack101后立即重传Seq101。Wireshark会把重复的ACK标记为TCP Dup ACK把快速重传的报文标记为TCP Fast Retransmission。6.3 流量控制与拥塞控制的区别这两个概念经常被混淆但在Wireshark里它们的表现不同。流量控制是接收方通过窗口大小告诉发送方我能收多少。它是端到端的只涉及收发双方。在Wireshark里你看到的是窗口大小的变化。拥塞控制是发送方根据网络状况调整发送速率。它涉及整个网络路径。在Wireshark里你看到的是发送速率的変化以及拥塞窗口的变化但拥塞窗口是发送方内部状态Wireshark看不到只能通过发送速率推断。拥塞控制有四个阶段慢启动、拥塞避免、快速重传、快速恢复。在Wireshark里你可以通过统计菜单里的TCP流图形看到吞吐量的变化曲线。慢启动阶段吞吐量指数增长拥塞避免阶段线性增长发生丢包后吞吐量骤降。6.4 零窗口与窗口探测的实战分析当接收方的缓冲区满了它会通告窗口大小为0。发送方收到零窗口通知后停止发送数据但会定期发送窗口探测报文。窗口探测报文的特点是序列号是上一个已发送字节的序号携带1字节数据或者不携带数据。接收方收到探测报文后如果窗口已经更新会回复新的窗口大小如果窗口还是0会回复一个ACK窗口仍然为0。在Wireshark里你可以用tcp.analysis.zero_window过滤器找到零窗口报文用tcp.analysis.window_update找到窗口更新报文。零窗口持续的时间越长说明接收方应用处理越慢。如果零窗口一直不更新可能是接收方应用卡死了。这时候需要检查接收方的应用状态和系统资源。7. 常见问题与排查技巧实录7.1 抓不到包或抓到的包不完整这是新手最常遇到的问题。可能的原因和排查方法现象可能原因排查方法一个包都没有选错网卡看接口列表的流量波形选活跃的网卡只有部分包捕获过滤器太严先去掉过滤器抓完再用显示过滤器筛包不完整网卡硬件卸载关闭TSO/LRO或在Wireshark里忽略校验和错误看不到应用层数据加密协议HTTPS流量是加密的只能看到TCP层看不到HTTP内容提示如果抓HTTPS流量你只能分析TCP层的行为看不到HTTP请求和响应。要做应用层分析需要配置SSLKEYLOGFILE或者使用其他方法。7.2 序列号和确认号看不懂这是概念问题不是操作问题。记住几个要点序列号是字节序号不是报文序号SYN和FIN各占一个序列号确认号是累积确认表示期望收到的下一个字节Wireshark默认显示相对序列号ISN显示为0如果还是看不懂找一个简单的HTTP请求把每个报文的Seq、Ack、Len三个字段列出来手动算一遍。算过一遍就明白了。7.3 重传和乱序分不清重传和乱序在Wireshark里都会显示为异常的序列号但它们的含义不同重传同一个序列号的数据被发送了多次说明数据可能丢了乱序序列号不连续后面的报文先到了说明网络路径上存在多路径Wireshark会自动标记这两种情况但有时候会误判。判断的依据是时间和上下文。如果同一个序列号在短时间内出现多次大概率是重传如果序列号跳跃但每个只出现一次大概率是乱序。7.4 窗口大小为什么一直是0零窗口说明接收方缓冲区满了。排查思路检查接收方应用是否在处理数据还是卡住了检查接收方的系统资源CPU、内存是否正常检查接收方的TCP接收缓冲区设置是否太小如果是自己写的应用检查读取数据的逻辑是否有问题在Linux上可以用ss -tln查看socket的接收队列和发送队列。如果Recv-Q很大说明应用没有及时读取数据。7.5 实验报告怎么写才不像抄的这个问题很实际。我的建议是不要只贴截图要写你的分析过程。比如三次握手不要只放三个包的截图要写出你抓的是什么流量为什么选这个三个包的序列号和确认号分别是多少为什么是这个值你观察到了什么异常如果有你是怎么判断的你对三次握手有了什么新的理解这样的报告才有价值也才能体现出你真的动手做了实验而不是复制粘贴。8. 从实验到实战这些技能能用在什么地方做完这个实验你获得的不只是几个截图而是一种用报文验证协议行为的能力。这种能力在实际工作中有很多应用场景。排查网络性能问题用户反馈某个接口很慢你可以抓包看看是TCP重传多、窗口小、还是RTT高。每个指标对应不同的优化方向。调试分布式系统微服务之间的调用超时抓包能看到是连接建立慢、数据传输慢、还是对端处理慢。比看日志更直接。理解安全攻击SYN Flood、RST攻击、会话劫持这些攻击在Wireshark里都有明显的报文特征。理解了正常行为才能识别异常行为。优化应用性能通过观察TCP的行为你可以判断是否需要调整Nagle算法、延迟确认、窗口大小等参数。这些调整对高并发应用的影响很大。我个人在实际工作中的体会是抓包分析这项技能入门容易精通难。工具的使用几天就能学会但报文背后的协议逻辑和网络行为需要长期的积累和思考。每次遇到网络问题不要急着搜答案先抓个包看看往往能发现意想不到的线索。最后分享一个小技巧Wireshark的追踪TCP流功能Follow TCP Stream可以把一条TCP连接的所有应用层数据拼在一起显示。分析HTTP请求响应的时候特别有用能直接看到完整的交互内容。但要注意这个功能只对未加密的流量有效HTTPS流量看到的是乱码。