http post协议实现简单的rpc协议,WireShark抓包分析

1.http 客户端-RPC客户端

import json
import requests

# 定义 RPC 客户端类
class RPCClient:
    def __init__(self, server_url):
        self.server_url = server_url

    def call(self, method, params):
        # 构建 JSON-RPC 请求
        request_data = {
            'method': method,
            'params': params,
            'id': 1
        }
        #json数据转化为网络字节流数据
        json_data = json.dumps(request_data).encode('utf-8')

        # 发送 POST 请求
        response = requests.post(self.server_url, json_data, headers={'Content-type': 'application/json'})

        # 解析响应
        result = response.json()
        if 'error' in result:
            raise Exception(result['error'])
        return result['result']

# 创建 RPC 客户端实例
client = RPCClient('http://192.168.1.9:8000')

# 调用远程方法
result = client.call('add', [3, 5])
print("Result:", result)

1.http 服务端-RPC服务端

import json
from http.server import BaseHTTPRequestHandler, HTTPServer

# 自定义处理程序类
class RPCHandler(BaseHTTPRequestHandler):
    def do_POST(self):
        # 解析接收到的 JSON 数据
        content_length = int(self.headers['Content-Length'])
        json_data = self.rfile.read(content_length).decode('utf-8')
        print("-------json_data:{}".format(json_data))
        data = json.loads(json_data)
        print("-------data:{}".format(data))
        # 处理 RPC 请求
        result = self.process_request(data)

        # 构建响应
        self.send_response(200)
        self.send_header('Content-type', 'application/json')
        self.end_headers()
        # 将python对象转为json字符串,encode用于将字符串转换为字节流b开头,默认用utf-8编码
        print(json.dumps(result).encode('utf-8'))
        self.wfile.write(json.dumps(result).encode('utf-8'))

    def process_request(self, data):
        # 在这里处理 RPC 请求
        # 根据请求内容调用相应的函数或方法
        # 返回结果
        if 'method' in data:
            method = data['method']
            if method == 'add':
                if 'params' in data and len(data['params']) == 2:
                    a, b = data['params']
                    result = a + b
                    return {'result': result}
        return {'error': 'Invalid request'}

# 启动 RPC 服务器
def run_server():
    port = 8000
    server_address = ('192.168.1.9', port)
    httpd = HTTPServer(server_address, RPCHandler)
    httpd.serve_forever()

if __name__ == '__main__':
    run_server()

在这里插入图片描述

3.WireShark抓包分析

在这里插入图片描述

3.1客户端到服务端的HTTP/JSON报文

在这里插入图片描述

3.2服务端到客户端的HTTP/JSON报文

在这里插入图片描述

<think>好的,我现在需要回答用户关于SOME/IP和HTTP作为二进制协议与文本协议的问题。首先,我得回忆一下用户之前的对话历史,确保这次的回答符合之前提到的系统级指令和用户可见的要求。用户之前已经了解过二进制协议和文本协议的基本区别,现在他们想知道如何将这些概念应用到SOME/IP和HTTP上。 首先,我要确认SOME/IP确实是二进制协议,而HTTP是文本协议。SOME/IP(Scalable service-Oriented MiddlewarE over IP)主要用于汽车和嵌入式系统,强调高效通信。HTTP作为Web的基础协议,是文本形式的,可读性强。接下来需要将它们的特性与之前提到的二进制和文本协议的特点对应起来。 用户可能需要具体的例子来说明两者的不同,比如数据编码方式、传输效率、可读性等。比如,SOME/IP使用紧凑的二进制格式,不需要可读性,而HTTP使用文本命令如GET或POST,附带可读的头部信息。同时,性能方面,SOME/IP适合实时系统,低延迟;而HTTP由于文本解析和冗余数据,可能效率较低,但易于调试和扩展。 还要注意结构清晰,分点说明。可能需要分为几个部分,比如基本概念、核心差异、应用场景等。同时要使用用户之前提供的格式,比如使用$$...$$来包裹独立公式,不过这里可能例子较少,但如果有数值对比的话可以用到。此外,需要检查是否符合LaTeX语法,虽然这个问题可能不需要太多数学公式,但如果有数据对比的话要正确使用。 用户可能还想知道为什么在特定场景下选择SOME/IP而不是HTTP,或者反之。需要提到应用场景的不同,比如汽车系统需要高效可靠,而Web需要灵活和可读性。此外,可能还需要提到协议设计的考虑因素,比如带宽、延迟、可维护性等。 要确保回答准确,可能需要查阅SOME/IP和HTTP的具体规范,确认它们的编码方式和设计目标。例如,SOME/IP使用二进制来优化传输效率和减少开销,而HTTP的文本特性使其易于开发和调试,但牺牲了一定的性能。 另外,可能需要提到一些实际应用中的例子,比如车载网络中SOME/IP如何传输传感器数据,而HTTP处理用户界面或远程服务请求。同时,可以指出现代协议HTTP/2引入了二进制帧,结合了两者的优点,但核心仍然是文本协议,而SOME/IP保持纯粹的二进制设计。 最后,总结时需要强调根据需求选择合适的协议,没有绝对的好坏,只有适用场景的不同。确保回答结构清晰,逐步展开,帮助用户理解两者的差异和应用场景。</think>以下是关于**SOME/IP是二进制协议**与**HTTP是文本协议**的对比解析: --- ### 一、基本概念 1. **SOME/IP**(Scalable service-Oriented MiddlewarE over IP) - **设计目标**:面向汽车电子、嵌入式系统的高效通信协议。 - **协议特性**: - 使用**二进制编码**,数据紧凑无冗余。 - 支持服务发现(Service Discovery)、远程方法调用(RPC)等。 2. **HTTP**(HyperText Transfer Protocol) - **设计目标**:为Web应用提供标准化文本交互协议。 - **协议特性**: - 使用**文本编码**(ASCII/UTF-8),可读性强。 - 基于请求-响应模型(如`GET /index.html HTTP/1.1`)。 --- ### 二、核心差异解析 #### 1. **数据组织方式** - **SOME/IP(二进制)**: - 数据以**紧凑字节流**传输,例如: - 整数`123`直接编码为`0x0000007B`(4字节)。 - 协议头固定格式(如消息类型、长度字段),无需分隔符。 - **示例结构**: ```plaintext | Message ID (4B) | Length (4B) | Request ID (4B) | Payload (N Bytes) | ``` $$ \text{总长度} = 12\text{B} + N\text{B} $$ - **HTTP(文本)**: - 数据以**可读字符串**传输,例如: - 整数`123`编码为字符串`"123"`(3字节)。 - 依赖换行符(`\r\n`)、空格、冒号等分隔字段。 - **示例请求**: ```http GET /data?id=123 HTTP/1.1 Host: example.com Content-Type: text/plain ``` #### 2. **性能对比** | **维度** | SOME/IP(二进制) | HTTP(文本) | |----------------|--------------------------------------|------------------------------------| | **传输效率** | 高(无冗余字节,头部固定长度) | 低(冗余字符如空格、冒号、换行符) | | **解析速度** | 快(直接内存映射,无需逐字符解析) | 慢(需分词、类型转换) | | **带宽占用** | 低(例如:传输布尔值仅需1字节) | 高(例如:传输`"true"`需4字节) | #### 3. **可读性与调试** - **SOME/IP**: - ❌ **人工不可读**:需专用工具(如Wireshark插件)解析字节流。 - ✅ **防篡改**:二进制编码天然隐蔽,不易被直接修改。 - **HTTP**: - ✅ **直接可读**:可通过网络抓包工具(如Chrome开发者工具)直接查看内容。 - ❌ **易篡改**:文本内容可被手动修改(如URL参数、Headers)。 --- ### 三、应用场景差异 #### 1. **SOME/IP的典型应用** - **汽车电子**: - 传输传感器数据(如车速、温度)、控制指令(如刹车信号)。 - 要求**低延迟、高可靠性**(如自动驾驶系统)。 - **嵌入式系统**: - 资源受限设备间的通信(如车载ECU单元)。 #### 2. **HTTP的典型应用** - **Web服务**: - 浏览器与服务器交互(如加载网页、提交表单)。 - 支持灵活扩展(如通过JSON/XML传递复杂数据)。 - **RESTful API**: - 跨平台服务调用(如手机APP与云服务器通信)。 --- ### 四、示例对比(传输相同数据) #### 场景:发送一个控制指令(开关状态) - **SOME/IP(二进制)**: ```plaintext | 0x00010001 (Message ID) | 0x00000001 (Length) | 0x00000001 (Request ID) | 0x01 (Payload: True) | ``` **总长度:13字节** - **HTTP(文本)**: ```http POST /api/switch HTTP/1.1 Host: device.example.com Content-Type: application/json Content-Length: 15 {"status": true} ``` **总长度:~120字节**(包含Headers、换行符等) --- ### 五、设计选择背后的原因 1. **SOME/IP选择二进制的理由**: - **实时性需求**:汽车系统需在毫秒级响应。 - **资源限制**:嵌入式设备内存、带宽有限。 - **确定性**:固定格式减少协议解析复杂度。 2. **HTTP选择文本的理由**: - **人类友好**:便于开发调试、日志分析。 - **灵活性**:支持动态扩展字段(如HTTP Headers)。 - **跨平台兼容**:文本编码天然适配不同系统。 --- ### 六、总结 - **SOME/IP**: 适合**高实时性、低带宽、资源受限**场景(如汽车、工业控制)。 - **HTTP**: 适合**可读性优先、灵活性高**场景(如Web服务、API交互)。 > **补充**:HTTP/2及gRPC协议已引入二进制帧(如HTTP/2的二进制分帧层),但协议核心交互逻辑(如Headers定义)仍保持文本特性,与SOME/IP的纯二进制设计有本质区别。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Alex1_Code

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值