Unity网络编程(一)常见概念

Posted 2023-03-21

参考技术A 一直用Http用多了 复习一下基础
Unity通讯一般分为2类
Http : 应用层 Unity内置的UnityWebRequest类进行通信（之前写过一个分发器垃圾框架）用于交互量比较小
Socket：传输层 比较底层 实现TCP/UDP 用于频繁的通信

这个是基于TCP 和IP传输不同消息

这个是三种常见的网络层次划分

基本数据单位为帧
主要的协议：以太网协议

基本数据单位为IP数据报；
IP协议（Internet Protocol，因特网互联协议）
ICMP协议（Internet Control Message Protocol，因特网控制报文协议）
ARP协议（Address Resolution Protocol，地址解析协议）
RARP协议（Reverse Address Resolution Protocol，逆地址解析协议）

包含的主要协议：TCP协议（Transmission Control Protocol，传输控制协议）、UDP协议（User Datagram Protocol，用户数据报协议）

数据传输基本单位为报文
包含的主要协议：
FTP（文件传送协议）、Telnet（远程登录协议）、DNS（域名解析协议）、SMTP（邮件传送协议），POP3协议（邮局协议），HTTP协议（Hyper Text Transfer Protocol）。

分配给用户上网使用的网际协议
目前IPv4多 比如192.168.1.1
新的IPv6(因为IPv4数量不够分配)如3ffe:3201:1401:1280:c8ff:fe4d:db39:1984。

Internet最基本的协议
TCP负责发现传输的问题，一有问题就发出信号，要求重新传输，直到所有数据安全正确地传输到目的地。
可靠的协议 通过三次握手建立的面向连接通信协议

3次握手 四次挥手 实习生常考
TCP连接建立过程(三次握手)：
1.首先Client端发送连接请求报文
2.Server段接受连接后回复ACK报文，并为这次连接分配资源。
3.Client端接收到ACK报文后也向Server段发生ACK报文，并分配资源，这样TCP连接就建立了。
TCP连接断开过程(四次挥手)：
1.Client端发起中断连接请求(FIN报文)
2.Server端接到FIN报文后，发送ACK服务器还有消息没发完让Client待命，Client端就进入FIN_WAIT，继续等待Server端的FIN报文
3.Server端确定数据已发送完成，则向Client端发送FIN报文，
4.Client端收到FIN报文后发送ACK后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传，Server端收到ACK后 关闭，Client等待了2MSL后依然没有收到回复客户端也关闭
SYN:"synchronize"请求同步标志；；ACK:"acknowledge"确认标志"；FIN："Finally"结束标志。

为什么要三次握手？
防止因为网卡导致Sever收到多次Client请求 建立N个监听 造成资源浪费
为什么要四次挥手？
自己不请求直接关闭 但是服务器还能给你发数据 服务器浪费资源 而且客户端也会强行接收
使用TCP的协议：FTP（文件传输协议）、Telnet（远程登录协议）、SMTP（简单邮件传输协议）、POP3（和SMTP相对，用于接收邮件）、HTTP协议等。

面向无连接的通讯协议
UDP通讯时不需要接收方确认，属于不可靠的传输 会丢包
UDP与TCP位于同一层，但它不管数据包的顺序、错误或重发
主要用于面向查询---应答的程序
每个UDP报文分UDP报头和UDP数据区两部分
UDP报头由4个域组成，其中每个域各占用2个字节
（1）源端口号；
（2）目标端口号；
（3）数据报长度；
（4）校验值。

使用UDP协议包括：TFTP（简单文件传输协议）、SNMP（简单网络管理协议）、DNS（域名解析协议）、NFS、BOOTP。

超文本传输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议

HTTP协议特点：
简单快速 灵活 无连接 无状态 支持B/S(浏览器/服务器)及C/S(客户端/服务器)模式。
URL

和服务器有一些频繁的交互 用http时不时请求 叫轮询 效率低下
soket可以理解为插座 插头接上了可以保持通信

端口:
每个Socket连接都是从一台计算机网卡的一个端口连接到另外一台计算机网卡的某个端口。
IP是房子的话 端口就是门
TCP端口和UDP端口相互独立 如TCP255端口 和UDP255端口 不冲突

周知端口
范围从0到1023，其中80端口分配给WWW服务，21端口分配给FTP服务等。
浏览器的地址栏里输入一个网址的时候是不必指定端口号的，因为在默认情况下WWW服务的端口是“80”。
网络服务是可以使用其他端口号的 比如 网址：8080
但是有些系统协议使用固定的端口号，它是不能被改变的，比如139 端口专门用于NetBios与TCP/IP之间的通信，不能手动改变。
自己开发时尽量不要使用1024之下的端口，可能会与系统端口冲突。

服务端:
创建socket对象
bind：绑定IP地址和端口
listen：开始监听绑定的IP地址和端口，等待客户端的连接
accept：如果有客户端发起连接，通过accept接受连接请求，连接成功后会复制一个socket出来用于和当前接受连接的客户端进行通信。(服务端最初创建的那个socket只是用来监听并建立连接用的，实际和客户端通信并不是最初的socket，而是在accept这一步会自动创建一个新的socket出来和客户端通信。)
read/write：使用新的socket读写数据
close：关闭socket，如果关闭的是服务端的监听socket，则无法接收新的连接，但是已经创建的和客户端的连接不会被关闭。
客户端:
创建socket对象
connect：连接服务端，连接成功后系统会自动分配端口
read/write：连接成功后，就可以进行数据的读写了，这里读写使用的socket还是第一步创建的socket对象。
close：关闭连接。
如果收到了长度为0的数据，则代表远程socket关闭了连接。

服务器:
创建socket对象
bind：绑定IP和端口，用于接收数据（注意这里绑定完就可以直接接收数据了，并不需要等待连接）
read/write：读写数据
客户端:
创建socket对象
read/write：读写数据，不需要先建立连接，直接给对应的IP+端口发送数据即可。

由于没有建立连接以及连接的保障，UDP在传输效率上会很高
UDP有一个功能是TCP所不具备的，那就是广播功能（UDP可以将消息发送到在同一广播网络上的每个主机 CS、魔兽争霸局域网对战）。

HTTP/HTTPS(比http更安全):小游戏 网页 间歇性发送链接 偶尔延迟。
TCP长连接： 卡牌游戏 某些mmo 客户端和服务器都可以独立发包 偶尔延迟
UDP：动作游戏 mmo 枪战 客户端和服务器都可以独立发包 无法接受延迟

可以混合使用你的MMO客户端也许首先使用HTTP去获取上一次的更新内容，然后使用UDP跟游戏服务器进行连接。
现在也有kcp 就是tcp和udp结合 快速安全可靠

简单直接的长连接
可靠的信息传输
数据包的大小没有限制

坑多 断线检测、慢速客户端响应阻塞数据包，对开放连接的各种dos攻击，阻塞和非阻塞IO模型
丢包会有阻塞机制(一般是重发 tcp相反) 所以手机游戏ping跳1000就这个原因

只使用一个socket进行通信
快速
基于数据包构建
灵活 多种方式处理延迟

很多东西没有要自己构建
不可靠
丢包

客户端直接开始进行计算而不等待服务端确认是一种典型的隐藏延迟的技术(容易被抓包篡改)。
我们到底是使用TCP还是UDP取决于我们能否隐藏延迟。
比如TCP 在棋牌 卡牌游戏 卡1S无所谓 在动作游戏moba游戏就很致命
可靠的UDP/kcp和TCP不一样，要去实现一个特殊的阻塞控制，而且还要保证可靠性，也可以使用许多支持可靠通信的UDP库，但是库一般为了通用会降低某种新能，自己根据项目情况写可以发挥到极致
如果不知道用什么就TCP

ET框架学习-ECS组件式编程的基本思想之于UNITY

参加实习一个月了 公司新项目准备使用ET框架进行开发 在走通et的流程之前 我们必须了解一个概念:ECS组件式编程

这个概念有区别于我们我们常见的unity开发思路(虽然unity本身也是采用了组件是开发) ，在unity开发中，常见的思路是 entity-manager，就是说把业务抽象成 实体 - 管理器的模式 ，实体就是抽象出来的 比如说主角啊 怪物等等类(实例)，管理器就是那些protomanager，scenemanager，uimanager之类的封装一些相对抽象的逻辑的类(实例)。对象和管理器各自遵循oop的思想设计 ，玩家类继承角色类，实现不同接口 ；角色类可以被npc类继承，也可以被玩家类继承；每个阶段的类都封装了这个阶段该(继承)有的属性和操作，manager和enity的交互通过相应事件系统(有可能是某些manager本身)从而组成一个相对完整的生态系统。

这样做的话，数据和逻辑的耦合程度比较高，于是人们尝试把mvc(puremvc,strangeioc)框架加入其中，将实体的数据和逻辑进行解耦，实体和管理器被分为view和controller和model。然而，游戏本来就是一个相当复杂的产品，逻辑和逻辑，逻辑和数据有的时候强行解耦的话并不能使得开发变得简单，有时候反而会加大工作量（比如说开发一个相对简单的项目）。那么除了这种常见的开发思路有没有其他的想法呢?答案是肯定的。

组件式开发ECS其实不是新的东西，在非游戏开发的领域(特别是服务器开发)其实这个概念十分常见，而ecs在游戏开发领域的开发概念最早是从守望先锋服务器开发流传出来的(不敢肯定，虽然大家都这么说，毕竟我没有亲自去考证过)，感兴趣的朋友可以自己去搜索。

什么是ecs呢？e即是enity 实体 c即是component s即是system 。

最纯粹的ecs开发就是将数据和逻辑强解耦(我认为的，不一定正确),System承载逻辑，Enity承载数据，Component定义数据(和unity的component，即我想当然以为的"组件"不同，ecs的component是纯数据不包含逻辑)。

打个比方，描述:一个红色虫吃面积为5叶子。这句话中 ，虫-entity，叶子-entity，吃-system，虫的属性(食量)-component，叶子的属性(面积)-component。

一个红色虫吃面积为5叶子->一个的不管什么样的虫可以吃叶子->虫吃叶子->......->生物吃生物->......->名词动词名词 

virtualEntiy拥有x个specificComponent组成了specificEnity，virtualSystem实现了具体逻辑变成specificSystem，实体需要对另一个实体产生作用，就挂载需要的组件，系统面向组件实现，组件和系统关联。实体和系统之间强行解耦（除开特殊情况，除非这系统是为一个特定组件设计的，而这个组件又是某个实体的特定必不可缺的）。这个是我自己对于ecs总结或者说是感想(不一定正确)

说完了基本的ecs概念，就来说一下在unity开发中的一些常用的基于ecs概念设计的框架:

ET--u3d双端开发框架

Entitas-c#框架

unity2018 ecs&jobsystem

这三个算是在unity开发中比较常见的ecs框架。感兴趣的朋友可以自己先去搜索（后面的文章会详写et）

最后，我必须说的一点是，并不是说ecs是unity开发绝对唯一，无敌棒的开发模式。软件开发的核心不在于用了什么牛逼的框架，造了牛逼的轮子，代码是为产品服务的，只要框架有助于提升产品质量，速度就是好框架。每个框架需要真正深入思考过，才能真正用好这些框架。

 

下面是我自己看过，感觉对自己有收获的文章，分享出来

https://www.cnblogs.com/yangrouchuan/p/7436533.html   --Entitas框架简介

https://www.zhihu.com/question/286963885/answer/452979420 --ecs开发的思考（会成为未来的主流吗？）、

https://zhuanlan.zhihu.com/p/32787878 --ecs无框架原理级实现

https://github.com/egametang/ET --et的Github地址

 

 

最后:本人只是一个大四在公司实习的小菜鸟，很多地方写的不好还请大家见谅。

有兴趣的朋友可以加我的qq大家一起学习一起成长 qq:872732381