大家好,又见面了,我是你们的朋友全栈君。
目录
TCP通信
概述
服务端架构
客户端架构
应用层协议
客户端连接服务端(错误示范)
UDP通信
概述
程序结构
通信数据处理
TCP通信
概述
TCP通信双方在进行数据交换之前,先要建立连接,连接建立后,通信双方之间相当于有一条隧道,数据按顺序在该隧道中传输,数据传输完毕后,双方可以选择关闭隧道,连接结束。
TCP 通信编程中,“请求方”主动连接“被请求方”,该过程称为“连接”(Connect),被请求方收到“连接”的请求后,接受Accept)并创建一个Socket 代理与请求方进行数据交互,该过程如下图:
通信双方中主动请求方称为“客户端(Client)”,被请求方称为“服务端(Server)”,图中经过connect、accept 之后,服务端与客户端之间的数据交换发生在客户端Socket 和服务端代理Socket 之间。由于TCP 通信中,数据以“流”的形式传输,数据之间没有边界,如下图所示:
虽然接收到的数据无法确认边界,但是将每次接收到的数据拼接在一起,它们的字节顺序跟发送方发送数据的顺序一致,这就是TCP通信中数据的“顺序性”。
服务端架构
客户端架构
应用层协议
一般TCP的应用层协议中帧头、帧长度、数据区、校验码必不可少:
- 帧头:用于TCP通信数据的界定,一般取4byte(如:0xABE5),太长会增加帧头的寻找难道,太短会增加误识别的概率;
- 帧长度:“数据区 校验码”的byte长度,推荐使用4byte的32位无符号数,数据量不大的可以取2byte的16位无符号数;
- 数据区:要传输的数据,如果要对帧进行识别可以在数据区的前4个byte加帧标志(32位无符号数);
- 校验码:数据区(不包括帧头、帧长度)的数据校验码,可以是16位、32位,校验算法可使用ACC(小规模通信使用)、CRC(推荐)校验。
推荐使用的完整通信帧:帧头(4byte) 帧长度(4byte-32位无符号数) 数据区(帧标志可选 传输数据) 校验码(CRC32)
帧标志由客户端提供,服务端对请求帧的回复使用客户端请求帧的帧标志,客户端把服务端发送过来的应答帧的帧标志与客户端已经发送的请求帧的帧标志进行对比,通过对比结果就可知道该帧标志所在的请求帧有没有得到服务端回复。
注:大规模企业级应用建议加帧标志检查请求帧是否得到服务端的回复。
客户端连接服务端(错误示范)
客户端连入服务端之后通信结构如下:
每个客户端都对应一个通信线程,这种结构便于理解编程但不支持高并发的服务器,尽量少用这种编程方式,网络通信一般使用异步编程方式达到循环接受、发送的目的。如异步连接的回调函数启动异步接受,异步接受的回调函数中启动下一个异步接受,中间发生异常则视为通信断开,以此达到循环接受数据的目的。
UDP通信
概述
UDP 通信之前不需要建立连接,它仅仅是单方面的一个操作。
UDP 通信编程中,没有TCP 通信中所谓的“服务端”,只存在“客户端”,每个客户端之间是平等的,发送数据之前不需要进行“连接”请求。客户端跟客户端发送数据时直接进行,如下图所示:
由于UDP 通信中,数据以“数据报”的形式传输,数据以一个整体发送、以一个整体接收,存在数据边界。但是接收到的数据是无序的,先发送的可能后接收,后发送的可能先接收,甚至有的接收不到。数据传输如下图所示:
UDP 通信中虽然数据报的传输是无序的,但是对于每一次发送的数据而言,接收方接收到的数据顺序跟发送时的顺序相同。
程序结构
通信数据处理
通信数据的循环处理可分为顺序执行的循环和非顺序执行的循环,二者的区别在于是否将数据的处理解析放在数据接收循环中处理,如下图所示:
顺序执行的循环易于理解和编程,非顺序执行的循环通信效率最高(数据处理不影响接收)。网络编程中,TCP通讯尽量使用非顺序执行的循环少使用顺序执行的循环处理数据,只有对数据处理顺序有特殊要求且通讯频率较低的TCP通讯才建议使用顺序执行的循环处理数据(能避免则避免)。
在UDP 通信中,没有必要保证先接收到的数据先处理,而后接收到的数据后处理,所以在UDP 通信中统一使用非顺序执行的循环处理数据。
注:本文所有图片来自《修炼之道:.NET开发要点精讲V5.1》
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
发布者:全栈程序员栈长,转载请注明出处:https://javaforall.cn/191060.html原文链接:https://javaforall.cn