计算机网络学习心得1——报文分析理解TCP/IP协议栈

1. 建立网络拓扑结构

2.  配置网络

2.1 客户端

2.2 服务端

3. 抓取报文并分析

3.1 概览

 报文1-3：DNS域名解析
 报文4-6和报文8：TCP连接建立    
 报文7和报文9-11：HTTP请求报文，响应报文
 报文12-15：TCP断开连接

3.2 DNS域名解析

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

3.2.1 DNS请求报文

给出抓取到的DNS请求报文示意图：

**基础结构**

每个字段含义如下：

（1）`Transaction ID: 0x5dac`

会话标识（2个字节），是DNS报文的标识，对于请求报文和其对应的应答报文，这个字段是相同的，通过它可以区分DNS应答报文是哪个请求的响应。

（2）标志（2个字节）
-   `QR`（1位），报文没有显示，查询/响应标志，0表示查询，1表示响应
-   `OPCODE: `0x01，操作码，0x01表示
-   `AA`：1位，指示是否是授权回答。
-   `TC`：1位，指示报文是否被截断。
-   `RD`：1位，指示是否要求进行递归查询。
-   `RA`：1位，指示服务器是否支持递归查询。
-   `Z`：3位，保留供将来使用。
-   `RCODE`：0x0，响应码，表示响应的状态成功。
（3）`QDCOUND`: 1，表示问题数目为1。
（4）`ANCOUNT`：0，表示回答数目为0。
（5）`授权记录数（NSCOUNT）`：0，表示授权数目为0。
（6）`附加记录数（ARCOUNT）`：0，表示附加数目为0。

**问题区域（Queries）**
每个字段含义如下：
（1）`Name`: xinying.huang
（2）`LENGTH`:0，指定了数据字段的长度。
（3）`TYPE`,1，用于指定查询或回答中的资源记录类型。Type为1表示的是A记录（Address Record），它用于将主机名映射到IPv4地址。 A记录是DNS中最常见的记录类型之一，它允许通过主机名查找其对应的IPv4地址。（注：这部分不懂，最后去寻求的百度帮助）
（4）`CLASS`：1，Class字段用于指定查询或回答中的资源记录类别。Class为1表示的是Internet类别（IN），它是最常用的DNS资源记录类别，用于表示Internet环境。（注：这部分也不懂，最后也去寻求的百度帮助）
（5）`TTL`：86400，表示资源记录在DNS缓存中可以被缓存的时间。

3.2.1 DNS响应报文

（1）`Name`: xinying.huang
（2）`LENGTH`:4，指定了数据字段的长度。
（3）`TYPE`,1，用于指定查询或回答中的资源记录类型。Type为1表示的是A记录（Address Record），它用于将主机名映射到IPv4地址。 A记录是DNS中最常见的记录类型之一，它允许通过主机名查找其对应的IPv4地址。（注：这部分不懂，最后去寻求的百度帮助）
（4）`CLASS`：1，Class字段用于指定查询或回答中的资源记录类别。Class为1表示的是Internet类别（IN），它是最常用的DNS资源记录类别，用于表示Internet环境。（注：这部分也不懂，最后也去寻求的百度帮助）
（5）`TTL`：86400，表示资源记录在DNS缓存中可以被缓存的时间。
（6）`IP`：访问域名的地址为：192.168.3.70

3.2.3 UDP

（1）`SOURCE PORT`：53，表示数据包的源端口号。
（2）`DESTINATION PORT`：1026，表示数据包的目标端口号。
（3）`LENGTH`：0X0040，表示整个UDP数据报的长度为64个字节。
（4）`CHECKSUM`：0，表示校验和字段的。0的数值表示在UDP数据报的校验和计算中没有发现错误。
（5）`DATA（VARIABLE LENGTH）`：表示数据。

3.3 TCP连接建立

3.3.1 概述

根据抓到的报文，TCP连接建立示意图如下：

 - `序号（seq）`：序号字段指示了 TCP 报文中的数据部分的第一个字节的序列号，序号用于按序传输数据和重新组装数据流，而接收方使用序号来确认收到的数据并按序组装数据流。在报文4与报文5中，序号均为0，而在报文6中，序号变为1，表示已经发送了1个字节的数据。
 - `确认号（ack）`：确认号的作用功能与序号大体相似。确认号字段指示了接收方期望收到的下一个字节的序列号。而发送方根据确认号知道接收方已经成功收到了哪些数据，接收方才能在发送确认报文时使用确认号来指示发送方下一个期望收到的字节序号。报文4的确认号为0，表示接收方期望下一个收到的数据包的序号为0；报文5的确认号转变为1，表示接收方期望下一个收到的数据包的序号为1；报文6的确认号也为1，表示接收方期望下一个收到的数据包的序号为1，并且已经发送了确认序号为1的数据包。
 - `标志位（SYN）`：SYN 用于建立连接时，当某个主机要求建立连接时，会将 SYN 置为1。所有三个报文的SYN标志位都为1，表示都是建立连接的请求。
 - `标志位（ACK）`：ACK 标志位表示确认号字段有效，当 ACK 置为1时，确认号字段中的值有效。在 TCP 握手过程中，当发送方收到 SYN 报文后，会发送包含 ACK 的报文进行确认。在数据传输过程中，ACK 用于确认收到的数据。报文4的ACK标志位为0，表示还未收到对方的确认；而报文5和报文6的ACK标志位都为1，表示已经确认了之前的数据包。

3.3.2 连接请求报文

-   报文4是建立连接的初始请求，标志位中的SYN=1表示请求建立连接，ACK=0表示还未收到对方确认。

3.3.3 连接接受报文

 - 报文5是接收方对报文4的回应，表示已经收到请求建立连接的数据包，并确认了报文4，SYN=1表示接收方也请求建立连接，ACK=1表示确认了报文4。

3.3.4 第三次握手

 - 报文6是发送方对报文5的回应，表示发送方已经收到了接收方的确认，SYN=1表示请求建立连接，ACK=1表示确认了报文5。

3.4 HTTP

分析HTTP请求和响应报文，除了关注HTTP请求和响应报文格式，还要关注被封装成TCP报文的序号、确认号和标志位的演变。

3.4.1 HTTP请求报文

 - seq=1。
>说明这是该TCP连接中的第一个报文段。
 - ACK=1
>表示期望收到服务器端返回的数据
 - HTTP Data:Accept-Language: en-us 
> 表示客户端它接受英语类型的内容。
 - Accept: */*  
>表示客户端接受所有类型的内容。
 - Connection: close  
> 表示服务器在发送完响应后将关闭连接。
 - Host: xinying.huang
> 表示客户端请求的主机名为xinying.huang。

3.4.2 HTTP响应报文

> 说明这是该TCP连接中的第一个报文段。

 - ACK=103。

> 表示该报文段期望接收到的下一个字节序号是103

 - HTTP Data:Connection: close  

> 服务器在发送完响应后会关闭连接，也就是TCP连接将被关闭。

 - Content-Length: 369  

> 内容长度为369字节。

 - Content-Type: text/html  

> 响应的内容类型为text/html。

 - Server: PT-Server/5.2

> 服务器为“PT-Server/5.2”。

3.4.3 IP数据报
我选取HTTP响应报文。（注：这部分很多含义不太了解，大部分来自CSDN的解释）

 - VER:4：表示IP协议的版本号，4表示IPv4。
 - IHL:5：表示IP头部长度，以32位字为单位。
 - DSCP:0X00：表示区分服务代码点，用于指示数据包的优先级或服务类型。
 - TL:491：表示IP数据报的总长度，包括IP头部和数据部分。
 - ID:0X0009：是用来标识数据报的唯一标识符。
 - FLAGS:0x2：包含三个比特位，用于控制分段。在这个数据报中，FLAGS字段的值为0x2，表示该数据报被分段，并且这是分段的最后一个分片。
 - FRAG OFFSET:0x000：表示分段偏移量，用于指示数据报的片段在原始数据报中的位置。0说明这个分段是原始数据报的开始处。
 - TTL:128：表示生存时间，用于防止数据包在网络中无限循环。
 - PRO:0x06：表示协议类型，指示数据报携带的上层协议类型。在这个数据报中，PRO的值为0x06，表示上层协议是TCP。
 - CHKSUM：表示IP头部的校验和，用于验证IP头部在传输过程中是否损坏。
 - SRC IP:192.168.3.70：表示发送者的IP地址。
 - DST IP:192.168.3.69：表示接收者的IP地址。
 - DATA (VARIABLE LENGTH)：表示数据部分。

3.5 TCP连接释放
3.5.1 概述

根据抓到的报文，TCP连接建立示意图如下：

由于上文已经介绍过各个名词的定义了，这里就只阐述其中的变化。
 -  编号12到编号13：
    -  seq从103变为427，表示发送了324个字节的数据。
    -  ack从427变为104，表示已经成功接收了编号12中的数据。
    -   FIN和ACK标志位都为1，表示发送端已经完成数据传输并且确认了接收端的数据。
  - 编号13到编号14—15：
    -   seq从427变为104，表示发送了323个字节的数据。
    -   ack从104变为427，表示已经成功接收了编号13中的数据。
    -   FIN为0，表明发送端关闭，ACK为1，表示确认了接收到的数据。

3.5.2 断开请求报文
发送端发送了所有数据并关闭连接，等待确认。

3.5.3 断开接受报文
接收端收到数据并确认，也发送了所有数据并关闭连接，等待确认。

3.5.4 第四次挥手
发送端收到确认，连接断开。

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

 - 一开始，我无法在客户端的Web中搜索域名。后面发现是在客户端的IP地址配置时，DNS SERVER那一栏没有将服务端的IP地址输入进去。
 - 为什么有一次的HTTP请求报文会与底下三个报文分开？最后我在网上搜索，终于在CSDN上找到了解答：“客户端会在收到第二次握手的确认报文后开始准备所需要的所有HTTP请求报文，同时发出第三次的握手报文，同时将准备好的HTTP请求报文放在缓冲区。等到所有的请求报文都准备完毕后，再拿出来连续发送给客户端”。不过似乎这个博主也不太确定，或许我在今后的学习中才能将这个问题彻底解决吧 。
 - 为什么最后TCP断开连接的时候会有4次请求？第3次和第4次的请求的数据几乎是一样的，为什么还要多此一举呢？最后我也在网上找到了解答：“这是由于TCP的半关闭(half-close)造成的。半关闭是指：TCP提供了连接的一方在结束它的发送后还能接受来自另一端数据的能力。通俗来说，就是不能发送数据，但是还可以接受数据。TCP不允许连接处于半打开状态时，就单向传输数据，因此完成三次握手后才可以传输数据(第三握手可以携带数据)。当连接处于半关闭状态时，TCP是允许单向传输数据的，也就是说服务器此时仍然可以向客户端发送数据，等服务器不再发送数据时，才会发送FIN报文段，同意现在关闭连接。这一特性是由于TCP双向通道互相独立所导致的，也使得关闭连接必须经过四次握手”。