计算机网络——TCP的三次握手和四次挥手

1. 建立网络拓扑结构

2. 抓取报文并分析

2.1 概览


报文1-3:DNS域名解析
报文4-6,8:TCP连接建立
报文7,9-11:HTTP
报文12-15:TCP连接释放

2.2 DNS域名解析

客户端向本地域名服务器发送DNS请求报文,域名服务器给客户端返回DNS响应报文。

2.2.1 DNS请求报文

  • 基础结构

每个字段含义如下:
(1)Transaction ID:0x06b3
会话标识(2个字节),是DNS报文的标识,对于请求报文和其对应的应答报文,这个字段是相同的,通过它可以区分DNS应答报文是哪个请求的响应。
(2)标志
QR:报文没有显示,查询/响应标志,0表示查询,1表示响应。
OPCODE: 0x1:操作码,0x1表示反向查询。
AA:授权应答,该字段在响应报文中有效。值为 1 时,表示名称服务器是权威服务器;值为 0 时,表示不是权威服务器。
TC:表示是否被截断。值为 1 时,表示响应已超过 512 字节并已被截断,只返回前 512 个字节。
RD:期望递归。该字段能在一个查询中设置,并在响应中返回。该标志告诉名称服务器必须处理这个查询,这种方式被称为一个递归查询。如果该位为 0,且被请求的名称服务器没有一个授权回答,它将返回一个能解答该查询的其他名称服务器列表。这种方式被称为迭代查询。
RA:可用递归。该字段只出现在响应报文中。当值为 1 时,表示服务器支持递归查询。
Z:保留字段,在所有的请求和应答报文中,它的值必须为 0。
RCODE:0x0:返回码字段,表示响应的差错状态。0x0表示没有错误。
(3)QDCOUND: 1:问题计数
(4)ANCOUNT:0:回答资源记录数
(5)NSCOUNT:0:授权资源记录数
(6)ARCOUNT:0:额外资源记录数

  • 问题区域

每个字段含义如下:
(1)Name: hanqi.luo:DNS 请求的域名。
(2)TYPE:1:查询类型,1表示由域名获得IPv4地址。
(3)CLASS:1:查询类,1表示IN,表明是Internet数据。
(4)TTL:86400:生存时间,4字节无符号整数表示资源记录可以缓存的时间。以秒为单位,表示的是资源记录的生命周期,一般用于当地址解析程序取出资源记录后决定保存及使用缓存数据的时间,它同时也可以表明该资源记录的稳定程度,极为稳定的信息会被分配一个很大的值。
(5)LENGTH:0:资源数据长度。

2.2.2 DNS响应报文

  • 基础结构

每个字段含义如下:
(1)Transaction ID:0x06b3
(2)标志
OPCODE: 0x1:操作码,0x1表示反向查询。
RCODE:0x0:返回码字段,表示响应的差错状态。0x0表示没有错误。
(3)QDCOUND: 1:问题计数
(4)ANCOUNT:1:回答资源记录数
(5)NSCOUNT:0:授权资源记录数
(6)ARCOUNT:0:额外资源记录数

  • 问题区域

每个字段含义如下:
(1)Name: hanqi.luo:DNS 请求的域名。
(2)TYPE:1:查询类型,1表示由域名获得IPv4地址。
(3)CLASS:1:查询类,1表示IN,表明是Internet数据。
(4)TTL:86400:生存时间。
(5)LENGTH:0:资源数据长度。

  • 回答区域

每个字段含义如下:
(5)LENGTH:4:资源数据长度。
(6)IP:192.168.3.68:该域名对应的 IP 地址。

2.2.3 UDP

DNS请求报文的UDP

(1)SOURCE PORT:1026:源端口
(2)DESTINATION PORT:53:目的端口
(3)LENGTH:0x0021:长度,字段记录了该 UDP 数据包的总长度(以字节为单位),包括 8 字节的 UDP 头和其后的数据部分。
(4)CHECKSUM:0:校验和,检测 UDP 数据报在传输中是否有错,有错则丢弃。
(5)DATA (VARIABLE LENGTH):应用数据。

2.3 TCP连接建立

2.3.1 概述


编号:抓取到报文的编号
ID:IP报文首部的标识符
seq:序号,进程发送消息的号码。
ack:确认号,期望目的进程返回的号码。
SYN:TCP标志位

2.3.2 连接请求报文


每个字段含义如下:
(1)SOURCE PORT:1026:源端口号,标识了发送方的地址。
(2)DESTINATION PORT:80:目的端口号,标识了接收方的地址。
(3)SEQUENCE NUMBER:0:序号,进程发送消息的号码。
(4)ACKNOWLEDGEMENT NUMBER:0:确认号,期望目的进程返回的号码。
(5)OFFSET:0x0:报头长度 。
(6)RESERVED: 0:保留。
(7)FLAGS:0b00000010:标志位(RESERVED,NONCE,CWR,ECN,URG,ACK,PUSH,RESET,SYN,FIN)。
(8)WINDOW:65535:窗口大小。
(9)CHECKSUM:0x0000:校验和,验证传输的数据是否正确。
(10)URGENT POINTER:0x0000:紧急指针,标识哪部分数据是紧急数据。
(11)OPTION:选项,对这个TCP报文的一些属性进行解释说明。
(12)DATA (VARIABLE LENGTH):数据。
(13)PADDING: 0:填充。

2.3.3 连接接受报文


每个字段含义如下:
(1)SOURCE PORT:80:源端口号。
(2)DESTINATION PORT:1026:目的端口号。
(3)SEQUENCE NUMBER:0:序号。
(4)ACKNOWLEDGEMENT NUMBER:1:确认号。
(7)FLAGS:0b00010010:标志位。
(8)WINDOW:16384:窗口大小。

2.3.4 第三次握手


每个字段含义如下:
(1)SOURCE PORT:1026:源端口号。
(2)DESTINATION PORT:80:目的端口号。
(3)SEQUENCE NUMBER:1:序号。
(4)ACKNOWLEDGEMENT NUMBER:1:确认号。
(7)FLAGS:0b00010000:标志位。
(8)WINDOW:65535:窗口大小。

2.4 HTTP

2.4.1 HTTP请求报文

HTTP Data:Accept-Language: en-us
Accept: */*
Connection: close
Host: hanqi.luo


每个字段含义如下:
(1)SOURCE PORT:1026:源端口号。
(2)DESTINATION PORT:80:目的端口号。
(3)SEQUENCE NUMBER:1:序号。
(4)ACKNOWLEDGEMENT NUMBER:1:确认号。
(7)FLAGS:0b00011000:标志位。
(8)WINDOW:65535:窗口大小。

2.4.2 HTTP响应报文

HTTP Data:Connection: close
Content-Length: 369
Content-Type: text/html
Server: PT-Server/5.2
2.4.3 IP数据报

HTTP请求报文的IP数据

每个字段含义如下:
(1)VER:4:版本,目前使用的是 IPv4 版本。
(2)IHL:5:首部长度:表示IP数据报中报头的长度。
(3)DSCP:0x00:区分服务,期望获取的服务类型。
(4)TL:118: 总长度,一个IP数据报总的长度,也就是报头+数据。
(5)ID:0x000a:标识,在IP软件在存储器中维持着一个计数器,每产生一个数据报,计数器就+1,并将此值赋值给标识字段 。
(6)FLAGS:0x2:标志,最低位为MF,MF=1即表示后面“还有分片”的数据报,MF=0表示的是这个数据报的最后一个,中间一位记为DF,当DF记为1时,表示的是“不能分片”。
(7)FRAG OFFSET:0x000:片偏移,片偏移指出,较长的分组在分片后,某片在原分组中的相对位置。
(8)TTL:128:生存时间,数据报在网络中的寿命。
(9)PRO:0x06:协议,指出此数据携带的数据是使用何种协议,以便让使目的的IP层知道将数据部分上交到哪个处理过程。
(10)CHKSUM:首部检验和,只检验数据报的首部,不包括数据部分。
(11)SRC IP:192.168.3.67:源IP地址。
(12)DST IP:192.168.3.68:目的IP地址。
(13)DATA (VARIABLE LENGTH):数据。

2.5 TCP连接释放

2.5.1 概述

2.5.2 发送断开连接请求报文


每个字段含义如下:
(1)SOURCE PORT:1026:源端口号。
(2)DESTINATION PORT:80:目的端口号。
(3)SEQUENCE NUMBER:99:序号。
(4)ACKNOWLEDGEMENT NUMBER:472:确认号。
(7)FLAGS:0b00010001:标志位。
(8)WINDOW:65535:窗口大小。

2.5.3 回复断开连接请求报文


每个字段含义如下:
(1)SOURCE PORT:1026:源端口号。
(2)DESTINATION PORT:80:目的端口号。
(3)SEQUENCE NUMBER:99:序号。
(4)ACKNOWLEDGEMENT NUMBER:472:确认号。
(7)FLAGS:0b00010001:标志位。
(8)WINDOW:65535:窗口大小。

2.5.4 确认传输数据完毕


每个字段含义如下:
(1)SOURCE PORT:80:源端口号。
(2)DESTINATION PORT:1026:目的端口号。
(3)SEQUENCE NUMBER:472:序号。
(4)ACKNOWLEDGEMENT NUMBER:100:确认号。
(7)FLAGS:0b00010001:标志位。
(8)WINDOW:15913:窗口大小。

2.5.5 第四次挥手


每个字段含义如下:
(1)SOURCE PORT:1026:源端口号。
(2)DESTINATION PORT:80:目的端口号。
(3)SEQUENCE NUMBER:100:序号。
(4)ACKNOWLEDGEMENT NUMBER:472:确认号。
(7)FLAGS:0b00010000:标志位。
(8)WINDOW:65534:窗口大小。

3. 以太网




每个字段含义如下:
(1)PREAMBLE: 101010..10:前导码。
(2)DEST ADDR::目的地址。
(3)SRC ADDR::源地址。
(4)TYPE:0x0800:类型,以太网首部后面所跟数据包的类型,0x0800为IP协议包。
(5)DATA (VARIABLE LENGTH):数据。
(6)FCS:0x00000000:CRC校验值,0x00000000表示数据是完整的。

4. 实验过程中遇到的问题及解决方法

  1. 问题一:对TCP/IP协议栈各层次的理解不够深入
    解决方法: 仔细阅读和理解TCP/IP协议栈的每一层的功能和职责,包括应用层、传输层、网络层和链路层。
  2. 问题二:对TCP的三次握手和四次挥手过程理解不清
    解决方法:仔细阅读和理解TCP的三次握手和四次挥手的原理和作用,通过实验来观察和分析TCP连接的建立和释放过程,如在客户端和服务器之间发送和接收数据,同时使用网络抓包工具来捕获和分析相应的TCP数据包。
  3. 问题三:在分析报文时遇到不熟悉的字段或标志位
    解决方法: 查阅相关的TCP/IP协议文档或教程,了解这些字段或标志位的含义和作用。
<think>嗯,用户之前让我整理软件测试面试中的计算机网络知识,现在他们又专门问了TCP三次握手四次挥手。我需要先确认用户的需求是什么。可能他们正在准备面试,或者在实际工作中遇到了相关问题,需要深入理解这两个过程。 首先,用户之前得到了一个结构化的回答,里面提到了三次握手四次挥手,但可能现在需要更详细的解释。用户可能希望了解这两个过程的每个步骤,为什么需要三次握手而不是两四次挥手又是为什么,以及这些过程在软件测试中的实际应用场景。 接下来,我需要考虑如何组织内容。应该分步骤解释三次握手四次挥手,使用比喻或实际例子帮助理解。同时,结合软件测试的上下文,说明这些知识在测试中的实际应用,比如如何设计测试用例,或者如何排查网络问题。 另外,用户可能对状态转换常见问题感兴趣,比如TIME_WAIT状态,或者半关闭状态。需要解释这些状态的原因影响,以及测试时需要注意的地方,比如端口耗尽或资源泄漏。 还要注意用户提到的测试场景,比如验证连接稳定性或检测端口耗尽。可能需要给出具体的测试策略或工具使用建议,比如使用netstat或抓包工具来观察握手挥手过程。 最后,确保回答结构清晰,逐步引导用户理解每个步骤,并关联到实际测试工作中。避免使用过于专业的术语,但保持准确性,必要时使用比喻或示例。同时,检查之前的回答是否覆盖了所有要点,避免重复,但补充更详细的信息。</think>以下是关于**TCP三次握手四次挥手**的详细解析,结合测试场景与常见面试问题说明: --- ### **一、TCP三次握手(建立连接)** #### **核心过程** 1. **第一握手**(客户端 → 服务器) - 客户端发送`SYN=1`(同步请求),随机生成初始序列号`seq=x` - **状态变化**: 客户端进入`SYN_SENT`状态 *测试关注点:客户端能否发出SYN包?网络是否可达?* 2. **第二握手**(服务器 → 客户端) - 服务器返回`SYN=1, ACK=1`,确认号`ack=x+1`,并发送自己的初始序列号`seq=y` - **状态变化**: 服务器进入`SYN_RCVD`状态 *测试场景:服务器未响应SYN-ACK时,客户端重试机制验证* 3. **第三次握手**(客户端 → 服务器) - 客户端发送`ACK=1`,确认号`ack=y+1`,序列号`seq=x+1` - **状态变化**: 双方进入`ESTABLISHED`状态(连接建立) *测试工具:通过Wireshark抓包验证三次握手完整性* #### **为什么需要三次握手?** - **根本原因**:防止历史连接初始化导致的资源浪费 - **测试关联**: - 设计测试用例模拟网络延迟导致的旧SYN包干扰 - 验证服务端对重复SYN包的处理逻辑 --- ### **二、TCP四次挥手(断开连接)** #### **核心过程** 1. **第一挥手**(主动关闭方 → 被动关闭方) - 发送`FIN=1`,序列号`seq=u` - **状态变化**:主动方进入`FIN_WAIT_1` - *测试关注点:主动关闭方是否触发FIN包?* 2. **第二挥手**(被动关闭方 → 主动关闭方) - 返回`ACK=1`,确认号`ack=u+1` - **状态变化**:被动方进入`CLOSE_WAIT`,主动方进入`FIN_WAIT_2` - *测试场景:验证被动方在CLOSE_WAIT状态能否继续发送数据* 3. **第三次挥手**(被动关闭方 → 主动关闭方) - 发送`FIN=1`,序列号`seq=v` - **状态变化**:被动方进入`LAST_ACK` - *测试工具:使用`netstat`监控LAST_ACK状态数量* 4. **第四次挥手**(主动关闭方 → 被动关闭方) - 返回`ACK=1`,确认号`ack=v+1` - **状态变化**: 主动方进入`TIME_WAIT`(等待2MSL后关闭) 被动方收到ACK后关闭连接 - *测试问题:高并发下TIME_WAIT过多导致端口耗尽如何解决?* #### **为什么需要四次挥手?** - **本质原因**:TCP连接是全双工的,需双方独立关闭各自通道 - **测试关联**: - 模拟服务端未发送FIN包导致客户端长时间处于FIN_WAIT_2 - 验证`SO_REUSEADDR`参数对TIME_WAIT状态的优化效果 --- ### **三、关键测试场景与面试问题** #### **1. 连接建立失败分析** - **可能原因**: - 防火墙拦截SYN包(抓包验证) - 服务器backlog队列满(查看`ss -s`统计) - **测试方法**: 使用`telnet IP端口`或`nc`命令模拟连接尝试 #### **2. 半关闭状态(Half-Close)** - **场景**:一方发送FIN后仍可接收数据 - **测试用例**: 验证客户端FIN后服务端能否继续返回响应 #### **3. 网络延迟导致的重传** - **抓包分析**: 观察SYN/FIN包的重传数与间隔(默认重试5) #### **4. 高频面试题** - “TIME_WAIT状态为什么要等待2MSL?” **答案**: 1. 确保被动方的ACK丢失后能重传FIN包 2. 让旧连接的报文在网络中彻底消失 - “什么情况下会看到大量CLOSE_WAIT状态?” **答案**:服务端代码未正确调用`close()`(资源泄漏) --- ### **四、可视化辅助理解** ``` 三次握手: Client         Server   SYN(x) ———→             ←——— SYN(y)+ACK(x+1)   ACK(y+1) ———→ 四次挥手: Client         Server   FIN(u) ———→             ←——— ACK(u+1)           ←——— FIN(v)   ACK(v+1) ———→ ``` --- ### **总结** - **测试工程师需掌握**: 1. 通过抓包工具验证握手/挥手流程 2. 结合日志分析连接异常(如连接超时、重置) 3. 设计边界用例:快速重启服务、模拟网络闪断 - **典型故障**: `Too many open files`(文件描述符耗尽)、`Address already in use`(TIME_WAIT未释放)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值