HTTP协议分析实验是计算机网络课程里最能让人“开窍”的一个实验。我当初做这个实验的时候第一次在抓包工具里亲眼看到自己访问网页时发出的那些字节才真正理解课本上说的“请求报文”“响应报文”不是抽象框架而是实实在在写在网线上的数据。这篇内容就围绕一次完整的HTTP协议分析实验展开实验怎么设计、抓包工具怎么配、请求和响应报文怎么逐行拆解、GET和POST到底差在哪、Cookie是怎么跟着请求走的以及我在实验里踩过的一堆坑。不管你是正在写实验报告的在读学生还是刚入行想补一下网络基础的开发者这篇都能给你一套可以直接照着做的思路。1. 实验目标与整体设计思路1.1 为什么非得抓包看HTTP很多人学HTTP都是从背报文格式开始的请求行、请求头、空行、请求体背得滚瓜烂熟但真让说一次浏览器访问网页时发生了什么又说不清楚。原因很简单课本把协议静态地摆在那里而实际网络里的报文是动态交互的有先后顺序有来有回有各种课本没写进去的“意外”。抓包分析就是把这个动态过程变成“可视化”的手段。抓包工具会记录网卡上经过的所有数据包把二进制数据解析成我们能看懂的协议字段等于给网络通信装了一台行车记录仪。我常跟人打比方只看报文格式说明就像看菜谱知道步骤抓包分析则是站到厨师旁边看着他怎么起锅烧油中间火大了他会关小盐放少了他会补一勺这些都是菜谱上不会写的“真实过程”。HTTP协议分析实验选HTTP而不是TCP、IP也有它的道理。HTTP是人类最熟悉的应用层协议之一你天天刷网页、看视频、调接口都在用它但恰恰因为它太常见反而容易被当作“理所当然”。用抓包工具把它拆开你才会注意到原来一个网页请求背后有这么多字段原来缓存命中时根本不会重新下载资源原来Cookie是这样被塞进请求头里的。对这些机制有了“亲眼所见”的基础后面再去学HTTPS、HTTP/2、WebSocket都会轻松很多。这个实验适合谁来参考首先当然是计算机网络相关专业的同学课程要求写实验报告这里的内容能帮你把报告写出真正的分析深度而不是堆几行默认报文截图。其次是刚工作不久的开发者尤其是做Web前端、后端接口联调的同学理解HTTP报文能让你排查问题快很多。运维和测试同学也能从中受益至少能看懂抓包工具的过滤器在干什么。1.2 实验目标拆成三层我个人习惯把实验目标分成三层由浅入深每层对应一类能力。第一层能看懂。看到一份请求报文能准确说出请求方法是GET还是POST、请求的资源路径是什么、带了哪些头部字段、请求体里装了什么看到响应报文能说出状态码含义、响应头里的关键字段、响应体的格式。说白了就是“逐字翻译”。第二层能理清。把一次完整的HTTP交互放在时间轴上说明TCP三次握手发生在HTTP请求发出之前HTTP响应到达之后连接如何关闭或复用Cookie是什么时候种下、什么时候携带的。这个层面强调的是流程感和时序感。第三层能用上。遇到网络问题时知道怎么通过抓包缩小排查范围比如页面加载慢是DNS慢、TCP建立慢还是HTTP服务端响应慢接口报错是请求没发出去、被重定向了还是服务端返回了5xx。这一层已经接近实际工作中的网络排查能力。实验报告里这三层最好都覆盖到但很多同学的报告往往卡在第一层贴了两张截图就算完事。我后面会详细讲每一层具体该做什么以及怎么在报告里把分析写到位。1.3 实验流程怎么排才不容易翻车做实验最容易翻车的地方不是不会抓包而是抓到的一堆包根本没法分析。比如开着浏览器满互联网跑页面上各种子资源、后台请求、广告追踪全混在一起抓了几千个包过滤出来几百条HTTP记录根本分不清哪个是哪个。所以实验流程一定要设计成“可控的请求”加上“清晰的观察窗口”。我推荐的流程是三步走。第一步准备一个干净的实验环境关掉不必要的后台应用固定要访问的测试服务或页面。第二步从最简单的单次请求开始用命令行工具发起一个HTTP请求在抓包工具里定位到这一条请求逐行拆解。第三步再做对比实验比如把GET改成POST、观察Cookie的产生和携带、对比长连接和短连接的差异每换一个变量只改一个条件观察一次报文。这样设计的好处是每个实验结论都能和抓包结果一一对应写实验报告的时候也特别有底气因为每一步都有报文截图和字段解释作为证据。对比实验尤其重要它能把课本上“GET和POST的区别”这类知识点变成你自己验证过的结论而不是背下来的教条。2. 实验环境与工具选型解析2.1 工具清单三件套缺一不可做HTTP协议分析实验我建议就准备三样东西一台能正常联网的电脑、一款抓包软件、一个能精确发起请求的命令行工具。再加一个“辅助位”浏览器自带的开发者工具。电脑系统无所谓Windows、macOS、Linux都能做。抓包软件我用的是Wireshark开源、跨平台、解析协议种类最全几乎算行业默认标准。命令行工具我推荐curl也是跨平台的预装率很高能把请求参数控制得很精细比用鼠标点页面更适合实验。浏览器开发者工具不是必需品但它查看页面加载的资源清单非常方便在分析多请求场景时能当辅助参考。选这三样而不是别的东西核心原因是分工清晰。Wireshark负责看“路上跑的所有数据”curl负责“制造一个干净的请求”浏览器开发者工具负责“从应用视角看结果”。三样配合起来你既能知道请求从哪发出的又能看到它在网络层走了什么路还能确认最终效果整个链路才是完整的。2.2 为什么是这三样各有分工先说Wireshark。它能抓取网卡上经过的每一个数据包支持几百种协议解析。HTTP解析后会直接在报文列表里显示请求方法、URI、状态码这些摘要信息点开一条记录就能看到完整的请求头和响应头同时下面还有原始十六进制数据。这个“从抽象字段到原始字节”的切换能力对理解协议编码极其有用。你可以在界面里同时看到“GET /index.html HTTP/1.1”这行文本以及它在真实数据帧里对应的十六进制字节能直观体会到协议本质就是“有约定格式的字节流”。再说curl。它是命令行下的HTTP客户端工具最大的价值是精确可控。浏览器会主动做很多事比如自动携带Cookie、自动请求子资源、自动做连接复用这些对普通用户是便利对实验是干扰。curl则默认只干你让它干的事你可以用curl -v http://example.com看详细交互用-X POST改方法用-d加数据用-H加自定义头部。每个参数对应一个实验变量改起来干净利落。浏览器开发者工具则提供“应用层视角”。按F12打开后可以查看页面的每个请求、耗时、响应体内容、Cookie状态。它的缺点是看不到TCP握手之类的东西但优点是直观适合用来核对Wireshark里看到的信息是不是和实际效果一致。还有一个容易被忽略的选项本地搭一个极简测试服务。如果你不想依赖外网用Python的python3 -m http.server 8000在本地起一个静态文件服务再用curl访问本机地址整个抓包过程完全在本地闭环排除公网DNS、代理等干扰。我在实验里就常用这种方式做“纯净对照”效果很好。2.3 实验前的环境准备和过滤配置环境准备这一步很多人跳过结果后面全在跟干扰数据搏斗。我的做法是关闭微信、邮箱、系统更新等可能在后台产生网络请求的软件。如果是无线网卡尽量切换到有线网络无线网卡的抓包表现有时不太稳定容易漏包。关掉浏览器里所有不相关的标签页只保留实验要访问的页面。用管理员权限启动Wireshark否则可能因为权限不足抓不到包。启动Wireshark后第一步是选对网卡。千万不能随便双击一块网卡就开始抓要选择电脑当前正在上网用的那块。Windows下通常是“以太网”或“WLAN”macOS下常见的是“en0”不确定就先在系统设置里看看当前连接的是哪个网络接口。选对网卡后抓包前先设置过滤条件。Wireshark有捕获过滤和显示过滤两种前者在抓包开始前设置只抓条件匹配的包能节省资源后者在抓包完成后设置只显示符合条件的包更适合分析。做HTTP实验最常用的是显示过滤表达式http它会过滤出所有包含HTTP协议信息的报文。但如果你只想看访问某个服务器的流量就要用ip.addr 服务器IP这样的条件组合。我第一次做实验时就不懂这回事直接默认抓包结果主机名解析、系统更新、各种杂七杂八的UDP包全进来了过滤出来几百条HTTP记录却不知道哪条是自己的实验请求。后来学会一个笨但有效的方法抓包前先准备一个明确的触发动作比如在Wireshark里点“开始捕获”后立刻在终端执行一次curl http://example.com抓一会就停止这样第一条HTTP请求基本就是你的目标定位非常快。3. 核心实验过程请求与响应报文逐行拆解3.1 第一步构造一个最干净的请求实验的直接目标是看到一份清晰的HTTP报文因此请求本身要干净。“干净”指三方面没有多余的请求头、没有复杂的跳转、没有缓存干扰。用curl构造这样一个请求最合适curl -v http://example.com/不要加-L参数否则遇到重定向会自动跟随一次操作就产生多个请求干扰拆解。-v参数让curl打印详细交互过程方便和Wireshark对照。执行命令的同时Wireshark里应该已经捕获到了对应流量。过滤栏输入http后可以看到一条HTTP请求和一条HTTP响应再往下是TCP的三次握手包和结束连接的四次挥手包。如果这些你都看不到说明过滤条件或者网卡选择有问题回炉检查一下环境准备那一步。从Wireshark里双击请求报文展开中间的“Hypertext Transfer Protocol”部分就进入了报文拆解环节。这一部分是整个实验报告的“重头戏”每一个字段都值得逐行说明。3.2 请求报文逐字段拆解一份HTTP请求报文分四部分请求行、请求头、空行、请求体。GET请求通常没有请求体所以看到空行就结束了。请求行是第一行。比如GET /index.html HTTP/1.1三个元素分别是请求方法、请求URI、协议版本。方法说明客户端想做什么URI说明对哪个资源做协议版本说明客户端支持的HTTP版本。在Wireshark里展开后这三个字段会被分别标注报告里应该逐一说明而不是整体截图了事。请求头是接下来若干行每一行是“字段名: 值”。实验报告里不需要列全所有字段但核心几个必须讲明白Host目标主机名和端口。HTTP/1.1开始必须带这个头因为一台服务器可以同时托管多个域名服务器靠它区分请求的是哪个站点。User-Agent客户端类型和版本。服务器用来识别浏览器或工具很多网站也用它做简单的设备适配。Accept客户端期望接收的媒体类型。比如text/html表示希望收到HTML。Accept-Encoding客户端支持的压缩算法如gzip。响应内容会自动压缩后传输。Connection连接管理方式keep-alive表示请求结束后保持连接不关闭。Cookie客户端保存的会话标识在需要保持登录状态的请求里一定会有。每解释一个字段我建议在报告里写一句话说明“这个字段如果缺失会怎么样”。比如没有Host服务器就可能不知道把请求交给哪个虚拟主机没有Accept-Encoding响应就可能是未压缩的大块数据。这种逆向思考最能体现你真的理解了头部字段的作用。请求头和请求体之间有一个空行这是HTTP协议里最容易忽略的内容。空行不是格式美观问题而是“分界线”告诉接收方头部到此结束。接收方看到空行才知道后面内容是请求体了。字段解析时按行读取遇到空行停止这个机制在协议的“边界划分”上非常重要。3.3 响应报文逐字段拆解响应报文同样是四部分状态行、响应头、空行、响应体。状态行是第一行比如HTTP/1.1 200 OK包含协议版本、状态码、原因短语。状态码是实验报告里最值得展开的部分因为它是服务器对请求结果的“一句话评价”。200表示成功301表示永久重定向302表示临时重定向304表示客户端缓存还可以继续用不用重新下载404表示资源不存在500表示服务器内部错误。实验报告里即使只触发过一次请求也应该把这些常见状态码列出来对比体现对机制的理解而不只是对单次结果的记录。响应头里关键的几个字段Server服务器软件类型信息有时会隐藏细节以降低暴露面。Content-Type响应体的媒体类型。比如text/html; charsetutf-8浏览器靠它决定如何解析响应体。Content-Length响应体字节数。接收方靠它知道要读多少字节才算读完。Set-Cookie服务器下发Cookie的指令。客户端收到后会保存并在后续请求中带回。Cache-Control缓存策略no-cache等取值决定了浏览器能不能缓存响应。响应体按Content-Type解释。如果是HTML就把它保存下来用浏览器打开看看能直观对应上报文和页面效果如果是JSON可以格式化后分析字段。实验报告里响应体不用全部粘贴截取代表性片段即可重点是说明格式。3.4 把请求和响应放回时间线里看拆解完单独报文再把整个交互放回时间线里看这一步容易被忽略但恰恰是“计算机网络与通信实验”和普通“HTTP协议介绍”的分水岭。在Wireshark的报文列表里按时间顺序观察你会看到这样一组序列客户端发送SYN发起TCP连接请求。服务器回复SYNACK同意建立连接。客户端发送ACK三次握手完成。客户端发送HTTP请求报文。服务器发送HTTP响应报文。客户端发起TCP断开连接过程。从时间戳和序号上你能直观看到HTTP请求是“寄生”在TCP连接之上的。没有TCP的三次握手HTTP请求根本发不出去。一次“简单”的网页访问底层至少要经历三次握手加四次挥手加上数据传输一共六个关键网络动作。我写实验报告时习惯把这张时间线整理成一张表格序号、时间、来源、目的、协议、摘要。每行对应报文列表里的一条记录再配一段文字说明这套流程。老师看报告的时候能一眼看出你看到了数据包层面的真实交互而不是只抄了课本流程图。4. 关键机制对比实验GET与POST、Cookie、连接管理4.1 GET与POST表面区别和报文本质区别GET和POST的区别几乎是每次面试和技术博客都会谈的话题但很多人回答时停留在“GET参数在URL里POST参数在Body里”“GET有长度限制”这种表面说法。抓包实验能把这个问题聊透。用curl发起两个实验curl -v http://example.com/search?keywordhello curl -v -X POST -d keywordhello http://example.com/api/search第一个请求的请求行里URI部分会是/search?keywordhello查询参数写在问号后面通过?分隔路径和参数通过分隔多个参数。第二个请求的请求行还是/api/search但请求体里会多一行keywordhello同时请求头里会带上Content-Type: application/x-www-form-urlencoded和Content-Length告诉服务器请求体的格式和长度。Wireshark里的报文对比非常清晰两者在请求行上的差异、请求体的有无、请求头的差异一目了然。从报文本质看GET和POST是两种语义不同的请求GET用于获取资源应该是“无副作用”的参数作为查询条件写在URI里POST用于提交数据参数放在请求体里服务器收到后可能创建或修改资源。至于长度限制是因为URL本身有长度限制而请求体没有严格限制两者承载数据的方式不同。还有一个值得一提的差别浏览器历史记录和缓存。GET请求可以被浏览器缓存刷新页面时可能直接复用POST默认不缓存。这个特性在抓包时也有体现连续刷新一个GET页面你会发现有时候根本没有新的HTTP请求发出这就是缓存机制在起作用。这个细节我们后面在问题排查章节还会遇到。4.2 Cookie机制一次完整的“发-存-带”链路Cookie机制实验做得好的话能把“会话保持”这个抽象概念变成完全具体的报文动作。很多同学以为Cookie是天然存在的东西其实它只是HTTP头部里的一个字段完全由服务器和浏览器共同维护。实验步骤如下。第一步用curl访问一个需要登录或记录会话的测试服务服务端通常会在第一个响应里返回Set-Cookie响应头。第二步查看Wireshark中响应报文能看到类似Set-Cookie: sessionidabc123; Path/的内容。第三步把第一次请求返回的Cookie手动带在第二次请求里比如curl -v -H Cookie: sessionidabc123 http://example.com/这时在第二个请求报文里你会看到Cookie请求头。把两次请求放一起对比整套链路就清楚了服务器在响应里“种”下Cookie客户端收到后按规则保存下一次请求时按域名和路径匹配把Cookie塞进请求头“带”回去。服务器看到请求头里的Cookie就知道“这个人是谁”。Wireshark里的证据链条完整一次Set-Cookie一次Cookie中间不需要任何其他神秘环节。Cookie的安全问题这个实验也能引出一点。抓包工具能直接看到Cookie明文说明HTTP协议本身不加密。如果你的登录会话走HTTP明文传输网络链路上任何能抓包的人都能看到你的会话标识。这就是为什么密码、会话等信息必须走HTTPS的根本原因之一。实验报告里写这一点是从明文抓包现象推导出HTTPS必要性很有说服力。4.3 Keep-Alive持久连接到底省了什么默认情况下HTTP/1.1的Connection: keep-alive会让TCP连接在请求完成后保持打开供后续请求复用。要理解这个机制的收益得对比“短连接”的情况。用curl可以模拟两种模式。默认模式通常保持连接连续请求两次会复用同一条TCP连接加-H Connection: close可以强制短连接模式。对照Wireshark报文持久连接模式下第一个请求和第二个请求之间没有新的三次握手报文列表里是连续的请求响应来回。短连接模式下每个请求之前都重新出现完整的SYN、SYNACK、ACK三次握手结束后还有四次挥手连接开销完全翻倍。三次握手加四次挥手的开销在网络状况良好时增加的时延可能只有几十毫秒但积少成多。一个网页包含几十个资源如果每个资源都用短连接光是建立和断开连接的时间就非常可观。持久连接把多次请求的“固定开销”摊薄到一条连接上这就是它存在的意义。这个实验在报告里适合画一张“连接复用次数与握手次数”的对照表。我用过这样的表格模板请求模式请求次数TCP握手次数特点持久连接21连接复用开销小短连接22每次请求独立建立连接表格比长篇大论直观得多老师扫一眼就能知道实验结论。4.4 状态码进阶用抓包结果理解重定向与缓存只看到一次200响应是不够的建议主动触发几种典型状态码让报告更充实。触发302重定向很简单用curl访问一个会跳转的地址但不加-L参数curl -v http://example.com/redirect响应的状态行会是HTTP/1.1 302 Found响应头里带Location: http://example.com/target。Location字段就是“请移步这里”的指令。如果加了-Lcurl会再发一次到Location地址的请求整个交互就变成两条HTTP请求、两条HTTP响应。报告里对照“手动处理重定向”和“自动跟随重定向”两种方式可以体现出对状态码语义的把握。触发404更简单访问一个不存在的路径即可。响应状态行HTTP/1.1 404 Not Found响应体是错误页面数据。状态码的价值就是机器可读的结果分类客户端程序不用解析页面内容就能知道请求是否成功、下一步该怎么处理。304缓存响应的触发稍微麻烦一点需要同一个资源请求两次。浏览器或curl会先请求一次服务端返回200并带上Last-Modified或ETag第二次请求时客户端带上If-Modified-Since或If-None-Match服务端发现资源没变返回304而不是重新传一遍资源。响应行是HTTP/1.1 304 Not Modified响应体为空。这个机制在网页加载性能优化里非常核心通过抓包验证一次你对“协商缓存”的理解会变得异常扎实。5. 实验中的常见问题与排查技巧实录5.1 过滤器写不对抓了一堆“垃圾包”这是我见过最多人踩的坑我自己也踩过。表现是Wireshark里数据包疯狂刷新过滤后HTTP记录成百上千根本找不到自己那一条。根本原因是没有在抓包前做计划也没有及时使用过滤表达式。解决思路分两步。第一步抓包前尽量减少噪声这就是前面说的关闭无关应用、只保留实验请求。第二步抓包后一定要会用过滤表达式。最常用的有过滤表达式作用http只显示包含HTTP的报文http.request.method GET只显示GET请求ip.addr 192.168.1.100只看和某IP通信的报文tcp.port 80只看80端口的报文http.response.code 404只看404响应另外Wireshark有“标记”功能选中目标报文后按CtrlM标记为高亮之后在几百条记录里一眼就能找到。配合“导出特定分组”功能可以把标记的报文保存成单独文件报告附件就只留下和分析相关的记录。5.2 浏览器缓存“偷走”请求看到的不是完整交互做实验时用浏览器访问一个之前访问过的页面结果发现Wireshark里几乎没有新HTTP请求或者只有304响应可能会误以为抓包失败了。其实不是失败是缓存生效了。浏览器对静态资源有很强的缓存能力未过期资源直接读取本地副本不产生网络请求。这种情况下我建议实验时统一用curl因为curl默认不加载本地缓存。如果实验要求必须分析浏览器行为那就在开发者工具里勾选“禁用缓存”或者在抓包前用无痕窗口访问才能看到完整的网络请求过程。顺带一提304响应本身也是很好的分析素材。它说明浏览器带着If-Modified-Since去问服务器“这个文件我上次缓存的是某某时间现在有没有更新”服务器回答“没更新”于是响应体为空节省了流量和带宽。这个机制不仅是实验知识更是日常优化网站性能的重要手段。5.3 HTTPS加密流量抓不到明文怎么办很多同学做完HTTP实验后会试着访问一些平时用的网站打开Wireshark一看HTTP过滤出来的记录几乎没有了取而代之的是大量TLS报文。这不是工具坏了是因为HTTPS把HTTP明文包在了TLS加密隧道里抓包工具看不到内部的HTTP内容。要分析HTTPS流量有两条思路。第一条浏览器开发者工具的“网络”面板它能在应用层直接展示HTTPS请求的详细信息虽然没有到报文层面的逐字段拆解但日常调试已经足够。第二条让Wireshark解密TLS流量做法是在启动浏览器前设置环境变量导出会话密钥然后把密钥文件导入Wireshark的TLS协议设置里。这个方法能让你看到一个已被解密还原的HTTP请求原理是解密后的内容被Wireshark重新组装成HTTP显示。不过实验报告还是建议以明文HTTP为主。原因很简单明文HTTP能让你直接看到协议本身的结构降低理解门槛。先把HTTP搞透再去看HTTPS的区别就只差一个“TLS层做了加密握手和密钥协商”的知识点而已。我见过不少人连HTTP报文都没看过一上来就解密HTTPS结果被TLS握手、证书链、密钥导出这些前置概念劝退得不偿失。5.4 环境干扰项后台进程、预连接与广播排除所有干扰后Wireshark里还是会有一些“莫名其妙”的包。比如访问某个网站时发现在你发出的HTTP请求之前就已经有到同一IP的TCP连接了。这可能是浏览器在后台做的预连接优化目的是提前建好连接等用户真正点击时直接复用。还有可能是操作系统在预解析DNS或者系统更新服务在后台下载数据。这些干扰不用逐一消灭关键是学会“认出来”。看到报文列表里的源端口和目标IP能大致判断是哪个进程的行为这种敏感度是抓包分析的核心能力。用Wireshark的“统计-端点”功能可以查看所有通信对端按数据量排序一眼找出谁在“偷跑流量”。我在实验里还习惯搭配一条命令netstat -ano在Windows上这条命令会显示每个TCP连接对应的进程PID再配合任务管理器能反查出某个连接是哪个软件建立的。这样遇到干扰连接时就能定位来源而不是停留在“猜测”层面。做网络实验思路越接近“排查现场”收获越大。6. 实操总结与个人经验6.1 做实验得到的最重要直觉做完这个实验我最大的收获不是记住了各个字段的名字而是建立了一种“协议即数据格式”的直觉。以前看到一个Web问题只会从业务逻辑角度想现在会下意识地想这个问题的表现对应到报文层面应该是什么样是请求没发出去还是响应异常还是连接根本就没建立成功这种思路一旦形成排查问题的效率是质的提升。6.2 几个能提升实验效率的操作习惯分享几个我后续做实验时一直在用的习惯。第一不要一次性抓很长时间。抓包前先想好要验证什么然后发起一个可控的触发动作抓到目标后立刻停止。抓包时间越长分析成本越高。第二学会用Wireshark的“追踪TCP流”功能。选中一条HTTP请求或响应右键选择“追踪TCP流”工具会把这次连接里的原始数据完整拼接出来以文本形式显示能看到HTTP报文的全貌。这比自己手工翻堆系统字段快得多。第三为每个实验结论保存证据。截图时不要只截报文列表要把展开的协议字段、十六进制区一起截进去报告里写“某某字段出现在请求报文中”时才能有一一对应的证据。6.3 后续可以怎么扩展HTTP协议分析实验做扎实之后可以顺着两条线继续深入。一条往底层走把抓包视角转向TCP分析三次握手、拥塞控制、重传机制另一条往上层走分析HTTPS的TLS握手过程、HTTP/2的多路复用、WebSocket的建立流程。底层让你懂得网络“为什么可靠”上层让你懂得现代应用“为什么高效”。无论哪条线抓包分析的方法都是通用的能力是可以直接迁移的。这次实验最值回票价的地方在于它让你亲手拆开了一直在用却又视而不见的“黑盒子”。以后无论写代码还是查问题心里都有一份对HTTP协议的具象认识这份认识不会过时。