清晰易懂TCP通信原理解析(附demo、简易TCP通信库源码、解决沾包问题等)C#版

本文涉及的产品
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介:

目录

  • 说明
  • TCP与UDP通信的特点
  • TCP中的沾包现象
  • 自定义应用层协议
  • TCPLibrary通信库介绍
  • Demo演示
  • 未完成功能
  • 源码下载

说明

我前面博客中有多篇文章讲到了.NET中的网络编程,与TCP和UDP相关的有:

1.http://www.cnblogs.com/xiaozhi_5638/p/3167794.html

2.http://www.cnblogs.com/xiaozhi_5638/p/3169641.html

3.http://www.cnblogs.com/xiaozhi_5638/p/3290283.html

4.http://www.cnblogs.com/xiaozhi_5638/p/3313959.html

另外也有一些讲的是通过Socket模拟浏览器访问Web服务器,或者模拟Web服务器接收浏览器的请求:

1.http://www.cnblogs.com/xiaozhi_5638/p/3912668.html

2.http://www.cnblogs.com/xiaozhi_5638/p/3917943.html

(之前文章的排版不太好,不好意思!)

之所有对.NET中网络编程写得比较多,主要原因有两个,一是我公司做的项目多数跟通信这个有关;二是研究Socket通信工作模式有益于对软件架构设计的理解,因为它里面到处都使用到了“泵”结构,而这个结构几乎是所有框架、大型模块所必需具备的。另外,工作之余写的一本书(即将要出版)中有一章专门讲到了“泵”结构在软件系统中的作用。

这次写这篇文章主要是看了网上一个人提的有关TCP编程的问题,所以就再次整理了一下这方面的知识,并且做了一个“简易通信库”发出来给大家看看,代码很简单,功能也不是特别全,但是具备很好的扩展性,基本上可以用来说明.NET中TCP通信的工作模式。

 

TCPUDP通信的特点

关于对这两者的比较,网上一搜一大片,讲得也比较清楚。TCP通信就像打电话,双方通信之前需要建立连接、双方就位后方可开始会话;而UDP通信就像发短信,一方给另一方发送数据前,并不需要对方就位。

上面两幅图显示了TCP与UDP通信过程建立的区别。

除了它们通信过程建立的不同之外,两者还有以下区别:

  • TCP通信特点

1)可靠性

   通信双方均就位,一方发送数据,另一方收到后会做出回应,如果超时未发送成功,会自动重发,数据不会丢失。

2)顺序性;

   既然数据是按顺序走在建立的一条隧道中,那么数据遵循“先走先达到”的规则,并且隧道中的数据以“流”的形式传输,发送方发送的前后两次数据之间没有边界,需要接收方自己根据事先规定好的“协议”去判断数据边界。

3)高损耗。

   “高损耗”包括机器性能损耗高、宽带流量损耗高。因为通信双方时刻需要维持着连接的存在,这必然会损耗通信双方主机性能,要想维持隧道的通畅,通信双方必须不断地发送检测包和应答包,同时,它还支持数据重发等数据纠错功能,这些都将导致网络流量的增加。

 

  • UDP通信特点

1)不可靠性;

   既然无连接,发送方只管发送数据,而不管对方是否能够正确地接收到数据,更不负责数据超时重发等功能。

2)无序性;

   数据以“数据报”的形式发送,可以把“数据报”看成是一个“包”。如果把TCP传输数据比如成“河里的流水”,那么UDP传输数据就是‘邮局寄信’。发送方先发送的数据可能后到达,后发送的数据可能先到达,这个跟短消息类似。

3)低损耗。

   “低损耗”包括机器性能损耗低、宽带流量损耗低。UDP通信不需要维持一个连接的存在,所以它不需要消耗额外的机器性能。同时它也没有像TCP通信那样为了保持隧道的通畅,而必须不停地发送检测包和应答包,更不会进行一些数据检测纠错、重发等行为。

这次我们只讨论TCP通信。

 

TCP通信中的“沾包”现象

上面提到过,TCP通信中,数据是以“流”的形式传输的。前一次发送的数据和后一次发送的数据之间并没有明显的界限,这就会出现一个问题:当你收到一部分数据时,你无法判断接收到的数据是否是完整的?

如上图,发送方发送三次数据,而接收方可能一共分四次接收。并且每次接收到的数据量不确定(虽然每次收到的数据不确定,但是将四次接收到的数据拼接起来,与发送时的一致)。这样以来,当我们每次收到一份数据时,我们无法轻易判断(几乎不能)收到的数据是否完整(是否可以正确地被处理)。

以上现象我们称之为“沾包”。TCP通信过程中,要想解决“沾包”问题,我们必须人工采取一些措施,比如在发送数据时遵循一些“规则”,在接收到数据时,再按照相同的“规则”去解析数据,最终得到一份完整的数据,并进行正确的处理。没错,这里说的“规则”便是我们通常听到的“协议”。

关于协议,讲到的地方也很多。简单的说,协议就是一种“数据结构”,合作双方必须同时按照相同的数据结构发送/接收数据,比如传输层的TCP/UDP协议,又比如应用层的HTTP/FTP等协议。B/S结构系统使用到的协议见下图:

在TCP通信中,在发送和接收数据的时候,如果我们遵循事先定义的一种“协议”(属于一种应用层协议)。比如,在发送数据时,按照“数据头(4Byte)+内容长度(4Byte)+内容正文(NByte)+附加信息(8Byte)”这种形式去“格式化”需要发送的数据;同理,在接收到数据后,按照这种形式去“反格式化”数据,这样我们便可以判断数据边界,轻松得到一条完整数据。

 

自定义应用层协议

是的。我们自己完全可以定义一个类似HTTP这样的应用层协议,只要你能力足够强,系统足够大。今天在这里,我只举个简单的例子,假设一个TCP通信系统中,客户端连接上服务器后,客户端向服务器发送一个字符串,并发送一个字符串转换指令(比如大小写转换、除去特殊字符等指令),服务器接收到数据后,按照对应的指令,将字符串转换后发送回给客户端。那么这里的应用层协议可以这样设计:

 字符串转换指令

序号

指令值(byte)

说明

1

0x01

将字符串中小写字符转换成大写

2

0x02

将字符串中大写字符转换成小写

3

0x03

去掉字符串中的百分号(%)字符

4

0x04

将字符串中的百分号(%)替换为空格

如上表所示,假设一共有四种字符串转换请求,那么我们可以按下面图设计应用层协议的数据结构:

如上图所示,开头一个字节代表字符串转换指令类型,后续四个字节存放一个Int32的整型数据,表示字符串的长度(字符串采用Unicode编码),最后N个字节表示字符串内容。数据发送方必须按照此协议格式发送数据,数据接收方必须按照此协议格式接收数据。

发送数据时按照协议格式化数据很简单,但是,接收数据后,按照协议去解析数据该怎样呢?事实上,这个相对来讲稍微复杂一点。我们可以将每次接收到的数据(字节流)写入一个缓冲区,然后判断缓冲区中是否存在一条完整的数据,如果存在,则处理这条完整的数据;否则,继续接收数据,将接收到的数据再次写入缓冲区...以此循环。

 

TCPLibrary通信库介绍

其实我只是将一些代码单独拿出来生成了一个dll,这部分代码可以为我们搭建起TCP通信的框架,包括服务端侦听、(服务端/客户端)接收数据、上下线、消息处理并通知Application以及“沾包”问题处理等等。功能并不全面,如果要拿去实际项目中使用还需要自己完善,文章末会列出未完成的功能。

TCP通信过程建立之后,大概结构如下:

整个通信库中,只包含5个抽象类,以及5个默认实现类(所以说简易):

使用该通信库的前提是要定义好程序使用到的“协议”,然后重点实现ZMessage.RawData属性和ZDataBuffer.TryReadMessage方法,前者可以按照协议格式化需要发送的数据,后者可以按照协议解析一条完整的消息。库中包含5个默认实现类(以Base开头的),它默认使用以下的协议进行通信:

其中,BaseDataBuffer.TryReadMessage方法具体实现为:

  View Code

BaseMessage.RawData属性具体的实现为:

  View Code

可以看到,上面一个按照协议格式化数据,而另一个按照协议解析数据。它们两个完全遵守同一个协议。

 

Demo演示

使用TCPLibrary中的默认实现类(以Base开头的类型),我做了一个简单的Demo。该Demo可以完成字符串、可序列化对象(图片)的发送与接收。Demo源码很简单:

l  Server端初始化:

  View Code

l  Client端的初始化:

  View Code

可以看到,使用起来很简单。注册事件后,既可以开始运行了。

下面可以看一下Demo截图:

注意,这个Demo只是利用库中的默认实现类来完成的。你完全可以自己定义一个协议,按照你自己的方式发送数据,比如“头(4Byte)+是否加密(1Byte)+发送方程序版本(8Byte)+消息长度(4Byte)+消息内容(NByte)+附加信息(8Byte)”这种方式发送数据/接收数据。只要你正确的实现了上面强调的方法和属性。

 

未完成功能

刚开始就说过,TCPLibrary功能不足,很多功能都没有。列举几个如下

1.线程安全

2.心跳检测

3.都只有开始,没有结束的功能

4.。。。

可以把源码下下来,自己尝试补充这些功能。

 

源码下载

下载地址:http://files.cnblogs.com/xiaozhi_5638/TCPDemo.rar

Win7+VS2010

希望有帮助!

作者:周见智 
出处:http://www.cnblogs.com/xiaozhi_5638/ 
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。


本文转自周见智博客博客园博客,原文链接:http://www.cnblogs.com/xiaozhi_5638/p/4244797.html,如需转载请自行联系原作者
目录
相关文章
|
21天前
|
存储 缓存 算法
HashMap深度解析:从原理到实战
HashMap,作为Java集合框架中的一个核心组件,以其高效的键值对存储和检索机制,在软件开发中扮演着举足轻重的角色。作为一名资深的AI工程师,深入理解HashMap的原理、历史、业务场景以及实战应用,对于提升数据处理和算法实现的效率至关重要。本文将通过手绘结构图、流程图,结合Java代码示例,全方位解析HashMap,帮助读者从理论到实践全面掌握这一关键技术。
69 13
|
14天前
|
存储 设计模式 算法
【23种设计模式·全精解析 | 行为型模式篇】11种行为型模式的结构概述、案例实现、优缺点、扩展对比、使用场景、源码解析
行为型模式用于描述程序在运行时复杂的流程控制,即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务,它涉及算法与对象间职责的分配。行为型模式分为类行为模式和对象行为模式,前者采用继承机制来在类间分派行为,后者采用组合或聚合在对象间分配行为。由于组合关系或聚合关系比继承关系耦合度低,满足“合成复用原则”,所以对象行为模式比类行为模式具有更大的灵活性。 行为型模式分为: • 模板方法模式 • 策略模式 • 命令模式 • 职责链模式 • 状态模式 • 观察者模式 • 中介者模式 • 迭代器模式 • 访问者模式 • 备忘录模式 • 解释器模式
【23种设计模式·全精解析 | 行为型模式篇】11种行为型模式的结构概述、案例实现、优缺点、扩展对比、使用场景、源码解析
|
14天前
|
设计模式 存储 安全
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析
结构型模式描述如何将类或对象按某种布局组成更大的结构。它分为类结构型模式和对象结构型模式,前者采用继承机制来组织接口和类,后者釆用组合或聚合来组合对象。由于组合关系或聚合关系比继承关系耦合度低,满足“合成复用原则”,所以对象结构型模式比类结构型模式具有更大的灵活性。 结构型模式分为以下 7 种: • 代理模式 • 适配器模式 • 装饰者模式 • 桥接模式 • 外观模式 • 组合模式 • 享元模式
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析
|
14天前
|
设计模式 存储 安全
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析
创建型模式的主要关注点是“怎样创建对象?”,它的主要特点是"将对象的创建与使用分离”。这样可以降低系统的耦合度,使用者不需要关注对象的创建细节。创建型模式分为5种:单例模式、工厂方法模式抽象工厂式、原型模式、建造者模式。
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析
|
6天前
|
存储 物联网 大数据
探索阿里云 Flink 物化表:原理、优势与应用场景全解析
阿里云Flink的物化表是流批一体化平台中的关键特性,支持低延迟实时更新、灵活查询性能、无缝流批处理和高容错性。它广泛应用于电商、物联网和金融等领域,助力企业高效处理实时数据,提升业务决策能力。实践案例表明,物化表显著提高了交易欺诈损失率的控制和信贷审批效率,推动企业在数字化转型中取得竞争优势。
45 14
|
15天前
|
网络协议 安全 网络安全
探索网络模型与协议:从OSI到HTTPs的原理解析
OSI七层网络模型和TCP/IP四层模型是理解和设计计算机网络的框架。OSI模型包括物理层、数据链路层、网络层、传输层、会话层、表示层和应用层,而TCP/IP模型则简化为链路层、网络层、传输层和 HTTPS协议基于HTTP并通过TLS/SSL加密数据,确保安全传输。其连接过程涉及TCP三次握手、SSL证书验证、对称密钥交换等步骤,以保障通信的安全性和完整性。数字信封技术使用非对称加密和数字证书确保数据的机密性和身份认证。 浏览器通过Https访问网站的过程包括输入网址、DNS解析、建立TCP连接、发送HTTPS请求、接收响应、验证证书和解析网页内容等步骤,确保用户与服务器之间的安全通信。
67 1
|
2月前
|
缓存 监控 Java
Java线程池提交任务流程底层源码与源码解析
【11月更文挑战第30天】嘿,各位技术爱好者们,今天咱们来聊聊Java线程池提交任务的底层源码与源码解析。作为一个资深的Java开发者,我相信你一定对线程池并不陌生。线程池作为并发编程中的一大利器,其重要性不言而喻。今天,我将以对话的方式,带你一步步深入线程池的奥秘,从概述到功能点,再到背景和业务点,最后到底层原理和示例,让你对线程池有一个全新的认识。
57 12
|
1月前
|
PyTorch Shell API
Ascend Extension for PyTorch的源码解析
本文介绍了Ascend对PyTorch代码的适配过程,包括源码下载、编译步骤及常见问题,详细解析了torch-npu编译后的文件结构和三种实现昇腾NPU算子调用的方式:通过torch的register方式、定义算子方式和API重定向映射方式。这对于开发者理解和使用Ascend平台上的PyTorch具有重要指导意义。
|
15天前
|
安全 搜索推荐 数据挖掘
陪玩系统源码开发流程解析,成品陪玩系统源码的优点
我们自主开发的多客陪玩系统源码,整合了市面上主流陪玩APP功能,支持二次开发。该系统适用于线上游戏陪玩、语音视频聊天、心理咨询等场景,提供用户注册管理、陪玩者资料库、预约匹配、实时通讯、支付结算、安全隐私保护、客户服务及数据分析等功能,打造综合性社交平台。随着互联网技术发展,陪玩系统正成为游戏爱好者的新宠,改变游戏体验并带来新的商业模式。
|
2月前
|
C# 开发者
C# 一分钟浅谈:Code Contracts 与契约编程
【10月更文挑战第26天】本文介绍了 C# 中的 Code Contracts,这是一个强大的工具,用于通过契约编程增强代码的健壮性和可维护性。文章从基本概念入手,详细讲解了前置条件、后置条件和对象不变量的使用方法,并通过具体代码示例进行了说明。同时,文章还探讨了常见的问题和易错点,如忘记启用静态检查、过度依赖契约和性能影响,并提供了相应的解决建议。希望读者能通过本文更好地理解和应用 Code Contracts。
44 3

热门文章

最新文章

推荐镜像

更多