6有关TCP编程论文

通讯系统程序开发中面临的问题---------主要是TCP下的Socket编程面临的问题4090511唐盼前言:首先进行通讯系统开发过程中要面临要虑的使用Socket进行通讯的方式,通讯方式一共有有下面的3种。

(1)字节流套接字(Stream Socket):TCP/IP协议族中TCP协议使用此类接口，它提供面向连接的(建立虚电路)、无差错的、发送顺序一致的、包长度不限和非重复的网络信包传输。

(2)数据报套接字(Datagram Socket):TCP/IP协议族中的UDP(User Datagram Protocol)协议使用此类接口，它是无连接的服务，以独立的信包进行网络传输，信包最大长度为32kB，传输不保证顺序性、可靠性和无重复性，通常用于单个报文传输或可靠性要求不高的场合。

(3)原始数据包套接字(Raw Socket):提供对网络下层通信协议(如IP协议)的直接访问，一般不是提供给普通用户的，主要用于开发新的协议或用于提取协议较隐蔽的功能。

其中字节流套接字是最常用的套接字类型。

在设计时要考虑的问题主要有以下问题:性能永远是第一位：有时候一个if判断都要考虑性能,毕竟要损耗一个CPU指令，而在通讯系统服务器，每秒钟都产生上百万级别的通讯量，这样一个if就浪费了1个毫秒了.∙系统环境极其恶劣：所有我们可以想象的恶意攻击、异常输入等都要考虑.∙网络说断就断：在socket环境下，客户端可以以各种理由断开链接，而且服务器根本不会知道，连一个流水作业的业务逻辑都无法保证正常执行，因此需要设计各种辅助的协议、架构去监督。

∙各种网络链接问题：例如代理、防火墙等等…现有的Socket编程资源------------------1.首选推荐开源的XMPP框架，也就是Google的Gtalk的开源版本。

里面的架构写的非常漂亮。

特点就是：简洁、清晰。

XMPP是一个分散型通信网络，这意味着，只要网络基础设施允许，任何XMPP用户都可以向其他任何XMPP用户传递消息。

多个XMPP服务器也可以通过一个专门的“服务器-服务器”协议相互通信，提供了创建分散型社交网络和协作框架的有趣可能性.顾名思义，XMPP可用于满足广泛的、对时间敏感的特性要求。

实际上，Google Wave，一个大型多用户协作环境，将XMPP作为其联合协议的基础。

2.其次推荐，这套框架本身写的一般般，但是腾讯的服务器非常的强大，这样必然导致客户端也要比较猛。

腾讯的实力是在国内互联网业内毫无争议的老大.并且可以通过学习这套框架，能够了解腾讯的IM传输协议设计，而且他们的协议是TCP/UDP结合，一举两得。

何乐而不为之?3.最后就是DotMsn。

这个写的实在很一般般，而且也主要针对了MSN的协议特点。

到了06年就停止开发了，后来出来了MSNPSharp，继承了DotMsn的框架，继续更新到了2010年4月。

DotMSN是一个开放源代码的独立类库提供即时通讯服务而无需MSN Messenger服务.类库是C＃编写的，因此.NET所支持的语言都能够使用。

由于其简洁自然的面向对象特性，使其易于使用和实施。

DotMSN 灵活易于扩展，稳健和轻量级的特性易于增强任何应用。

使用DotMSN的应用系统能实现从创建消息机器人到自定义客户端等各种不同的功能。

------------------Socket的选择------------------在Java，到了Java5终于出现了异步编程，NIO，于是各种所谓的框架冒了出来，例如MINA,xsocket等等；而在.NET，微软一早就为我们准备好了完善的Socket模型。

主要包括：同步Socket、异步Socket；我还听说了.net3.x之后，异步的Socket内置了完成端口。

综合各种模型的性能，总结如下：1.如果是短链接，使用同步socket。

例如http服务器、转接服务器等等。

2.如果是长链接，使用异步socket。

例如通讯系统（QQ/Fetion）、webgame 等。

的异步socket的连接数性能在7500/s（每秒并发7500个socket链接）。

而听说完成端口在1.5w所有.4.大概java的NIO性能在5000/s所有.------------------TCP Socket协议定义------------------下面主要介绍TCP的socket编程。

大多数人第一次写socket，总是以为在发送方压入一个"Helloworld",接收方收到了这个字符串，就“精通”了Socket编程了。

而实际上，这种编程根本不可能用在现实项目，因为：1.socket在传输过程中，helloworld有可能被拆分了，分段到达客户端），例如hello+world，一个分段就是一个包（Package），这个就是分包问题。

2.socket在传输过成功，不同时间发送的数据包有可能被合并，同时到达了客户端，这个就是黏包问题。

例如发送方发送了hello+world,而接收方可能一次就接受了helloworld.3.socket会自动在每个包后面补n个0x0byte，分割包.4.不同的数据类型转化为byte的长度是不同的，例如int转为byte是4位（int32），这样我们在制作socket协议的时候要特别小心了。

尽管socket环境如此恶劣，但是TCP的链接也至少保证了：包发送顺序在传输过程中是不会改变的，例如发送方发送H E L L，那么接收方一定也是顺序收到H E L L，这个是TCP协议承诺的，因此这点成为我们解决分包、黏包问题的关键。

如果发送方发送的是helloworld,传输过程中分割成为hello+world，那么TCP保证了在hello与world之间没有其他的byte。

但是不能保证hel loworld和下一个命令之间没有其他的byte。

因此，如果我们要使用socket编程，就一定要编写自己的协议。

目前业界主要采取的协议定义方式是：包头+包体长度+包体。

具体如下：1.一般包头使用一个int定义，例如int=173173173；作用是区分每一个有效的数据包，因此我们的服务器可以通过这个int去切割、合并包，组装出完整的传输协议。

有人使用回车字符去分割包体，例如常见的SMTP/POP协议，这种做法在特定的协议是没有问题的，可是如果我们传输的信息内容自带了回车字符串，那么就糟糕了。

所以在设计协议的时候要特别小心。

2.包体长度使用一个int定义，这个长度表示包体所占的比特流长度，用于服务器正确读取并分割出包。

3.包体就是自定义的一些协议内容，例如是对像序列化的内容（现有的系统已经很常见了，使用对象序列化、反序列化能够极大简化开发流程，等版本稳定后再转入手工压入byte操作）。

一个实际编写的例子：比如要传输2个整型int=1,int=2，那么实际传输的数据包如下：173173173812|------包头------|----包体长度----|--------包体--------|这个数据包就是4个整型，总长度=4*4=16。

应该在编程过程中避免的弯路：有很多人曾经偷懒，使用特殊结束符去分割包体，这样传输的数据包就不需要指名长度了。

可是如果使用特殊结束符去判断包，性能会损失很大，因为我们每次读取一个byte，都要做一次if判断，这个性能损失是非常严重的。

所以最终还是走主流路线为好，使用以上的结构体。

------------------Socket接收的逻辑概述------------------针对了数据包设计+socket的传输特点，接收逻辑主要是：1.寻找包头。

这个包头就是一个int整型。

但是写代码的时候要非常注意，一个int实际上占据了4个byte，而可悲的是这4个byte在传输过程中也可能被socket分割了，因此读取判断的逻辑是：∙判断剩余长度是否大于4∙读取一个int，判断是否包头，如果是就跳出循环。

∙如果不是包头，则倒退3个byte，回到第一点。

∙如果读取完毕也没有找到，则有可能包头被分割了，因此当前已读信息压入接收缓存，等待下一个包到达后合并判断。

2.读取包体长度。

由于长度也是一个int，因此判断的时候也要小心，同上。

3.读取包体，由于已知包体长度，因此读取包体就变得非常简单了，只要一直读取到长度未知，剩余的又回到第一条寻找包头。

这个逻辑不要小看,有时候就是很小的一个问题,让人在此地兜圈.而非常奇怪的是，c#写的socket，似乎没有这么复杂逻辑。

如同/DotMsn等，他们的socket接收代码都非常简单。

------------------Socket服务器参数概述------------------在开篇也说了，Socket服务器的环境是非常糟糕了，最糟糕的就是客户端断线之后服务器没有收到通知。

因为socket断线这个也是个信息，也要从客户端传递到我们socket服务器。

有可能网络阻塞了，导致服务器连断开的通知都没有收到。

因此，我们写socket服务器，就要面对2个环境：1.服务器在处理业务逻辑中的任何时候都会收到Exception,任何时候都会因为链接中断而断开。

2.服务器接收到的客户端请求可以是任意字符串，因此在处理业务逻辑的时候，必须对各种可能的输入都判断，防止恶意攻击。

针对以上几点，我们的服务器设计必须包含以下参数：1.客户端链接时间记录：主要判断客户端空连接情况，防止连接数被恶意占用。

2.客户端请求频率记录：要防止客户端频繁发送请求导致服务器负荷过重。

3.客户端错误记录：一次错误可能导致服务器产生一次exception，而这个性能损耗是非常严重的，因此要严格监控客户端的发送协议错误情况。

4.客户端发送信息长度记录：有可能客户端恶意发送非常长的信息，导致服务器处理内存爆满，直接导致宕机。

5.客户端短时间暴涨：有可能在短时间内，客户端突然发送海量数据，直接导致服务器宕机。

因此我们必须有对服务器负荷进行监控，一旦发现负荷过重，直接对请求的socket返回处理失败，例如我们常见的“404”。

6.服务器短时间发送信息激增：有可能在服务器内部处理逻辑中，突然产生了海量的数据需要发送，例如游戏中的“群发”；因此必须对发送进行队列缓存，然后进行合并发送，减轻socket的负荷。

5结束语Winsock使得Windows环境下底层通信协议的协议细节对网络应用程序开发人员而言是透明的，为广大程序员提供了一个统一的、简化的编程界面。

通过Winsock 不但可以很方便地实现不同计算机之间的相互通信，而且可以实现同一计算机中不同进程之间的通信,但是在设计通讯系统的时候,必须综合考虑到各方面的因素和可能会遇到的问题.以便设计出来程序达到最佳的运行状态.。