powerShell脚本开发 之收发UDP消息包
环境准备与基础概念
UDP通信基础
UDP（用户数据报协议）是互联网协议族（IP）中的一种无连接传输层协议，核心特性包括：
PowerShell环境要求
PowerShell 5.1及以上版本内置对.NET Framework的支持，因此无需额外安装组件即可使用
System.Net.Sockets
命名空间，若使用PowerShell Core（基于.NET Core），需确保目标环境已安装.NET Core运行时，建议在Windows Server或Windows 10/11等操作系统上测试，以保证Socket API的正常工作。
UDP消息包发送 脚本 开发
核心类与基本逻辑
实现UDP消息发送的核心是
System.Net.Sockets.UdpClient
类，其提供方法用于数据发送，基本流程如下：
发送脚本示例
以下示例展示了发送UDP消息的脚本（目标主机为本地回环地址，端口5000，消息为“Hello, UDP!”）：
# 发送UDP消息脚本param ([string]$TargetIp = "127.0.0.1",[int]$Port = 5000,[string]$Message = "Hello, UDP!")$udpClient = New-Object System.Net.Sockets.UdpClienttry {$endpoint = New-Object System.Net.IPEndPoint([System.Net.IPAddress]::Parse($TargetIp), $Port)$data = [System.Text.Encoding]::UTF8.GetBytes($Message)$udpClient.Send($data, $data.Length, $endpoint)Write-Host "消息已发送至 $TargetIp:$Port"}catch {Write-Error "发送失败: $_"}finally {$udpClient.Close()}
代码说明 ：
参数说明（发送脚本）
| 参数名 | 类型 | 默认值 | 说明 |
|---|---|---|---|
| “127.0.0.1” | 目标IP地址 | ||
| 目标端口 | |||
| “Hello, UDP!” | 发送消息内容 |
UDP消息包接收脚本开发
接收逻辑与核心方法
UDP接收的核心是通过的
BeginReceive
（异步）或（同步）方法监听指定端口，其流程如下：
接收脚本示例
以下示例展示了监听本地端口5001并打印源地址和消息内容的脚本：
# 接收UDP消息脚本param ([int]$LocalPort = 5001)$udpClient = New-Object System.Net.Sockets.UdpClient($LocalPort)try {$receiveTask = $udpClient.BeginReceive([ref]$null,[ref]$null,$null,[System.Threading.WaitHandle]::Default)$receiveResult = $udpClient.EndReceive($receiveTask)$buffer = $receiveResult.Buffer$message = [System.Text.Encoding]::UTF8.GetString($buffer)$remoteEndPoint = $receiveResult.RemoteEndPointWrite-Host "接收到来自 $remoteEndPoint 的消息:"Write-Host $message}catch {Write-Error "接收失败: $_"}finally {$udpClient.Close()}
代码说明 ：
参数说明（接收脚本）
| 参数名 | 类型 | 默认值 | 说明 |
|---|---|---|---|
| 本地监听端口 |
脚本整合与多线程处理
在实际应用中（如网络监控、物联网通信），需同时进行发送和接收操作，可通过多线程（如
Start-ThreadJob
）提升并发能力，避免阻塞主线程。
示例：发送-接收整合脚本
以下示例展示了通过并发任务实现UDP消息的发送与接收：
# 启动接收线程$receiveThread = Start-ThreadJob -ScriptBlock {param($localPort)$udpClient = New-Object System.Net.Sockets.UdpClient($localPort)try {$receiveTask = $udpClient.BeginReceive([ref]$null,[ref]$null,$null,[System.Threading.WaitHandle]::Default)while ($true) {$receiveResult = $udpClient.EndReceive($receiveTask)$buffer = $receiveResult.Buffer$message = [System.Text.Encoding]::UTF8.GetString($buffer)$remoteEndPoint = $receiveResult.RemoteEndPointWrite-Host "接收自 $remoteEndPoint: $message"}}catch {Write-Error "接收线程出错: $_"}finally {$udpClient.Close()}} -ArgumentList 5001# 等待接收线程启动Start-Sleep -Seconds 1# 发送消息（多次测试）for ($i = 0; $i -lt 5; $i++) {$udpClient = New-Object System.Net.Sockets.UdpClienttry {$endpoint = New-Object System.Net.IPEndPoint([System.Net.IPAddress]::Parse("127.0.0.1"), 5000)$data = [System.Text.Encoding]::UTF8.GetBytes("Message #$i")$udpClient.Send($data, $data.Length, $endpoint)Write-Host "发送消息 #$i"}catch {Write-Error "发送失败: $_"}finally {$udpClient.Close()}}# 停止接收线程Stop-ThreadJob -Id $receiveThread.Id
多线程优势 ：
性能与优化策略
缓冲区大小设置
UDP传输中，缓冲区大小影响性能，若数据量大，可增大缓冲区（如8192字节），减少内存拷贝；若数据量小，保持默认（1024字节），示例中通过
$bufferSize = 1024
设置接收缓冲区。
超时控制
在接收操作中，设置合理超时时间（如5000毫秒）可避免长时间等待，示例中通过
AsyncWaitHandle.WaitOne(5000)
设置接收超时。
错误处理
捕获
SocketException
等异常，并采取重试、记录日志等措施，示例中通过块处理异常。
安全注意事项
防火墙配置
UDP端口（如5000/5001）需在防火墙中开放，使用Windows防火墙添加入站规则：
New-NetFirewallRule -DisplayName "UDP Port 5000" -Direction Inbound -Protocol UDP -LocalPort 5000 -Action Allow
权限管理
绑定特定端口（如小于1024的端口）可能需要管理员权限，确保脚本以适当权限运行。
防止滥用
对发送/接收逻辑添加验证：
相关问答FAQs
问题1：如何处理UDP消息包中的数据解析问题？
解答 ：UDP不提供解析机制，需在发送前格式化数据（如JSON），接收后解析，示例：
# 发送JSON数据$json = @{"id" = 1"message" = "Test JSON"} | ConvertTo-Json$udpClient = New-Object System.Net.Sockets.UdpClient$endpoint = New-Object System.Net.IPEndPoint([System.Net.IPAddress]::Parse("127.0.0.1"), 5000)$udpClient.Send([System.Text.Encoding]::UTF8.GetBytes($json), $json.Length, $endpoint)$udpClient.Close()# 接收并解析JSON$udpClient = New-Object System.Net.Sockets.UdpClient(5001)$receiveTask = $udpClient.BeginReceive([ref]$null, [ref]$null, $null, [System.Threading.WaitHandle]::Default)$receiveResult = $udpClient.EndReceive($receiveTask)$jsonBytes = $receiveResult.Buffer$jsonString = [System.Text.Encoding]::UTF8.GetString($jsonBytes)$receivedJson = $jsonString | ConvertFrom-JsonWrite-Host "解析后的JSON数据:"Write-Host $receivedJson.idWrite-Host $receivedJson.message
问题2：UDP发送和接收脚本中如何实现超时控制？
解答
：使用
UdpClient.ReceiveTimeout
属性设置超时（单位毫秒），并通过捕获异常，示例：
# 接收脚本（带超时控制）param ([int]$LocalPort = 5001)$udpClient = New-Object System.Net.Sockets.UdpClient($LocalPort)try {$udpClient.ReceiveTimeout = 5000 # 设置超时为5000毫秒$receiveTask = $udpClient.BeginReceive([ref]$null,[ref]$null,$null,[System.Threading.WaitHandle]::Default)$receiveResult = $udpClient.EndReceive($receiveTask)if ($receiveResult.Buffer.Length -eq 0) {Write-Warning "接收超时"return}$message = [System.Text.Encoding]::UTF8.GetString($receiveResult.Buffer)$remoteEndPoint = $receiveResult.RemoteEndPointWrite-Host "接收到来自 $remoteEndPoint 的消息: $message"}catch [System.Net.Sockets.SocketException] {if ($_.Exception.Errorcode -eq 10060) { # WSAETIMEDOUTWrite-Warning "接收超时"}else {Write-Error "接收失败: $_"}}finally {$udpClient.Close()}
什么是OSI模型体系结构？
OSI（Open System Interconnect）开放式系统互联。 一般都叫OSI参考模型是ISO（国际标准化组织）组织在1985年研究的网络互联模型。 最早的时候网络刚刚出现的时候，很多大型的公司都拥有了网络技术，公司内部计算机可以相互连接。 可以却不能与其它公司连接。 因为没有一个统一的规范。 计算机之间相互传输的信息对方不能理解。 所以不能互联。 ISO为了更好的使网络应用更为普及，就推出了OSI参考模型。 其含义就是推荐所有公司使用这个规范来控制网络。 这样所有公司都有相同的规范，就能互联了。 其内容如下：第7层应用层—直接对应用程序提供服务，应用程序可以变化，但要包括电子消息传输第6层表示层—格式化数据，以便为应用程序提供通用接口。 这可以包括加密服务第5层会话层—在两个节点之间建立端连接。 此服务包括建立连接是以全双工还是以半双工的方式进行设置，尽管可以在层4中处理双工方式第4层传输层—常规数据递送－面向连接或无连接。 包括全双工或半双工、流控制和错误恢复服务第3层网络层—本层通过寻址来建立两个节点之间的连接，它包括通过互连网络来路由和中继数据第2层数据链路层—在此层将数据分帧，并处理流控制。 本层指定拓扑结构并提供硬件寻址第1层物理层—原始比特流的传输，电子信号传输和硬件接口数据发送时，从第七层传到第一层，接受方则相反。 上三层总称应用层，用来控制软件方面。 下四层总称数据流层，用来管理硬件。 数据在发至数据流层的时候将被拆分。 在传输层的数据叫段 网络层叫包 数据链路层叫帧 物理层叫比特流 这样的叫法叫PDU （协议数据单元）OSI中每一层都有每一层的作用。 比如网络层就要管理本机的IP的目的地的IP。 数据链路层就要管理MAC地址（介质访问控制）等等，所以在每层拆分数据后要进行封装，以完成接受方与本机相互联系通信的作用。 如以此规定。 OSI模型用途相当广泛。 比如交换机、集线器、路由器等很多网络设备的设计都是参照OSI模型设计的。 知道道这么多就可以了。 至少CCNA就考这么多。
协议的通讯过程
说真的，回答这个问题要查很多资料，楼主也不悬点儿赏~~囧。 我只能找到这么多啦——网际层协议：包括：IP协议、ICMP协议、ARP协议、RARP协议。 传输层协议：TCP协议、UDP协议。 应用层协议：FTP、Telnet、SMTP、HTTP、RIP、NFS、DNS。 FTP协议：1．ASCII传输方式：假定用户正在拷贝的文件包含的简单ASCII码文本，如果在远程机器上运行的不是Unix，当文件传输时ftp通常会自动地调整文件的内容以便于把文件解释成另外那台计算机存储文本文件的格式。 但是常常有这样的情况，用户正在传输的文件包含的不是文本文件，它们可能是程序，数据库，字处理文件或者压缩文件（尽管字处理文件包含的大部分是文本，其中也包含有指示页尺寸，字库等信息的非打印字符）。 在拷贝任何非文本文件之前，用binary 命令告诉ftp逐字拷贝，不要对这些文件进行处理，这也是下面要讲的二进制传输。 2．二进制传输模式：在二进制传输中，保存文件的位序，以便原始和拷贝的是逐位一一对应的。 即使目的地机器上包含位序列的文件是没意义的。 例如，macintosh以二进制方式传送可执行文件到Windows系统，在对方系统上，此文件不能执行。 如果你在ASCII方式下传输二进制文件，即使不需要也仍会转译。 这会使传输稍微变慢 ，也会损坏数据，使文件变得不能用。 （在大多数计算机上，ASCII方式一般假设每一字符的第一有效位无意义，因为ASCII字符组合不使用它。 如果你传输二进制文件，所有的位都是重要的。 ）如果你知道这两台机器是同样的，则二进制方式对文本文件和数据文件都是有效的。 UDP协议： 1、UDP传送数据前并不与对方建立连接，即UDP是无连接的，在传输数据前，发送方和接收方相互交换信息使双方同步。 2、UDP不对收到的数据进行排序，在UDP报文的首部中并没有关于数据顺序的信息（如TCP所采用的序号），而且报文不一定按顺序到达的，所以接收端无从排起。 3、UDP对接收到的数据报不发送确认信号，发送端不知道数据是否被正确接收，也不会重发数据。 4、UDP传送数据较TCP快速，系统开销也少。 5、由于缺乏拥塞控制（congestion control），需要基于网络的机制来减小因失控和高速UDP流量负荷而导致的拥塞崩溃效应。 换句话说，因为UDP发送者不能够检测拥塞，所以像使用包队列和丢弃技术的路由器这样的网络基本设备往往就成为降低UDP过大通信量的有效工具。 数据报拥塞控制协议(DCCP)设计成通过在诸如流媒体类型的高速率UDP流中增加主机拥塞控制来减小这个潜在的问题。 TELNET协议： 1）本地与远程主机建立连接。 该过程实际上是建立一个TCP连接，用户必须知道远程主机的Ip地址或域名； 2）将本地终端上输入的用户名和口令及以后输入的任何命令或字符以NVT（Net Virtual terminal）格式传送到远程主机。 该过程实际上是从本地主机向远程主机发送一个IP数据包； 3）将远程主机输出的NVT格式的数据转化为本地所接受的格式送回本地终端，包括输入命令回显和命令执行结果； 4）最后，本地终端对远程主机进行撤消连接。 该过程是撤销一个TCP连接。 HTTP协议首先客户机与服务器需要建立连接。 只要单击某个超级链接，HTTP的工作就开始了。 建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可能的内容。 服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。 客户端接收服务器所返回的信息通过浏览器显示在用户的显示屏上，然后客户机与服务器断开连接。 TCP协议当主动方发出SYN连接请求后，等待对方回答SYN，ACK。 这种建立连接的方法可以防止产生错误的连接，TCP使用的流量控制协议是可变大小的滑动窗口协议。 第一次握手：建立连接时，客户端发送SYN包(SEQ=x)到服务器，并进入SYN_SEND状态，等待服务器确认。 第二次握手：服务器收到SYN包，必须确认客户的SYN(ACK=x+1),同时自己也送一个SYN包(SEQ=y),即SYN+ACK包，此时服务器进入SYN_RECV状态。 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ACK=y+1),此包发送完毕，客户端和服务器时入Established状态，完成三次握手。
TCP和UDP的区别和特点
面向连接的TCP“面向连接”就是在正式通信前必须要与对方建立起连接。 比如你给别人打电话，必须等线路接通了、对方拿起话筒才能相互通话。 TCP协议能为应用程序提供可靠的通信连接，使一台计算机发出的字节流无差错地发往网络上的其他计算机，对可靠性要求高的数据通信系统往往使用TCP协议传输数据。 面向非连接的UDP协议“面向非连接”就是在正式通信前不必与对方先建立连接，不管对方状态就直接发送。 这与现在风行的手机短信非常相似：你在发短信的时候，只需要输入对方手机号就OK了。 UDP适用于一次只传送少量数据、对可靠性要求不高的应用环境UDP协议是面向非连接的协议，没有建立连接的过程。 正因为UDP协议没有连接的过程，所以它的通信效果高；但也正因为如此，它的可靠性不如TCP协议高。
发表评论