抓包分析DSCP字段在FTP/RSTP协议中的应用

抓包分析DSCP字段在FTP协议中的应用

简介

本文介绍DSCP字段的作用，以及抓包分析DSCP字段在FTP协议中的应用。最后通过实验证明有可能DSCP字段实际上对普通用户没啥用，原因是运营商可能会将用户设置的DSCP字段重置。

DSCP

IP报文中有个TOS字段 ，TOS字段（Type of Service）是IP报文头部中的一个8位字段，用于指定IP数据包的服务类型或优先级。它可以用来指定数据包的延迟、吞吐量、可靠性或成本等方面的要求，以支持网络质量的不同需求。TOS字段已经被DSCP字段（Differentiated Services Code Point）所取代。

DSCP（Differentiated Services Code Point）是IP报文头部中的一个6位字段，用于指定IP数据包的服务类型或优先级。它可以用来指定数据包的延迟、吞吐量、可靠性或成本等方面的要求，以支持网络质量的不同需求。

DSCP字段可以组合成不同的服务等级（Service Level Agreement，SLA），以满足不同应用的需求。例如，视频应用需要低延迟和高带宽，而文件传输应用则需要高吞吐量和较低的成本。DSCP可以通过路由器、交换机等网络设备进行流量分析和分类，以实现不同服务等级的流量控制和优先级处理。

FTP协议中的DSCP

FTP协议中一般使用21端口传输控制指令，20端口传输数据。虽然FTP协议标准本身并没有规定各种数据包的优先级，但是按道理将传输指令的优先级应该较高，而传输数据的优先级较低，所以笔者猜想可能部分FTP实现会将传输控制的DSCP优先级设置得高一些。下面通过具体抓包分析验证下这个猜想。

下述实验所抓数据可在这里下载：linux和windows下分别wireshark抓包ftp协议

Linux下抓包

• 服务端:vsftpd
• 客户端: ftp命令

通过实际抓包发现，FTP request的DSCP为4，FTP data的DSCP为2，FTP Response的DSCP为0。

看起来像是印证了笔者的猜想：指令的优先级的确比数据优先级高。
但是，真的是所有的FTP实现都是如此吗？我们接下来再看windows下的抓包情况。

windows下抓包

• 服务端: windows自带的FTP服务
• 客户端: MobaXterm
  
  通过抓包发现，windows下FTP的各种报文中的DSCP值都为默认值0。

RSTP协议中的DSCP

笔者又抓包发现RSTP协议中的指令等各种报文的DSCP的值也都是0.

真实场景下的DSCP

进一步地想，DSCP在实际用户场景中真的有作用吗？如果有作用的话，那我将我所有业务数据报文中的DSCP值都设为最高，是不是就可以保证我的数据在互联网中都以最高的优先级传输？那岂不是所有人都会将自己的数据包的优先级设置得很高？怀着这些疑问，笔者又进行了以下实验。

1. 在腾讯云服务器上启动一个服务端，用于接收数据。代码如下：

import socket

HOST = '0.0.0.0'  # 绑定所有可用的网络接口
PORT = 8080  # 监听的端口号

# 创建一个 TCP 套接字
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    # 绑定到指定的地址和端口
    s.bind((HOST, PORT))
    # 开始监听传入的连接
    s.listen()

    print(f'正在监听 {HOST}:{PORT}')

    while True:
        # 等待连接
        conn, addr = s.accept()
        print(f'已连接 {addr}')

        with conn:
            while True:
                # 接收数据
                data = conn.recv(1024)
                if not data:
                    break  # 如果没有数据了，退出循环

                # 处理数据
                print(f'接收到的数据: {data}')
                response = b'Hello, client!'

                # 发送响应
                conn.sendall(response)

2. 在本地机器启动一个客户端，设置DSCP值并向上述服务端传送数据，代码如下：

use std::os::unix::prelude::AsRawFd;

use tokio::io::AsyncWriteExt;
use tokio::net::TcpStream;

#[tokio::main]
async fn main() {
    let mut client = TcpStream::connect("118.24.148.33:8080").await.unwrap();

    let dscp = 0x2E << 2; // DSCP为46（EF）
    nix::sys::socket::setsockopt(client.as_raw_fd(), nix::sys::socket::sockopt::IpTos, &dscp)
        .unwrap();

    let buf = [0; 10];

    // 发送
    client.write_all(&buf[..10]).await.unwrap();
}

3. 抓包分析
   从上述代码中可以发现，客户端发出去时DSCP设置的是46，而笔者在服务端进行抓包却发现收到的报文中DSCP值却是26.
   
   由此可见，用户设置的DSCP可能根本没啥用。在中间的网络节点中会被重置为其他值。笔者猜测为运营商的路由器之类的会将所有出口流量的DSCP重置为某些值，毕竟你没有额外花钱，凭什么优先传输的你的消息？

一些参考

• 目前互联网上部署的路由器对于DSCP的支持究竟如何？