socket一些经验和总结

新手们（例如当初的我），第一次写socket，总是以为在发送方压入一个"Helloworld",接收方收到了这个字符串，就“精通”了Socket编程了。而实际上，这种编程根本不可能用在现实项目，因为：


 


1. socket在传输过程中，helloworld有可能被拆分了，分段到达客户端），例如 hello   +   world，一个分段就是一个包（Package），这个就是分包问题。


 


2. socket在传输过成功，不同时间发送的数据包有可能被合并，同时到达了客户端，这个就是黏包问题。例如发送方发送了hello+world,而接收方可能一次就接受了helloworld.


 


3. socket会自动在每个包后面补n个 0x0 byte，分割包。具体怎么去补，这个我就没有深入了解。


 


4. 不同的数据类型转化为byte的长度是不同的，例如int转为byte是4位（int32），这样我们在制作socket协议的时候要特别小心了。具体可以使用以下代码去测试：


代码 
        public void test()
        {
            int myInt = 1;
            byte[] bytes = new byte[1024];
            BinaryWriter writer = new BinaryWriter(new MemoryStream(bytes));
            writer.Write(myInt);
            writer.Write("j");
            writer.Close();
        } 


 


尽管socket环境如此恶劣，但是TCP的链接也至少保证了：


包发送顺序在传输过程中是不会改变的，例如发送方发送 H E L L，那么接收方一定也是顺序收到H E L L，这个是TCP协议承诺的，因此这点成为我们解决分包、黏包问题的关键。
如果发送方发送的是helloworld, 传输过程中分割成为hello+world，那么TCP保证了在hello与world之间没有其他的byte。但是不能保证helloworld和下一个命令之间没有其他的byte。
 


因此，如果我们要使用socket编程，就一定要编写自己的协议。目前业界主要采取的协议定义方式是：包头+包体长度+包体。具体如下：


 


1. 一般包头使用一个int定义，例如int = 173173173；作用是区分每一个有效的数据包，因此我们的服务器可以通过这个int去切割、合并包，组装出完整的传输协议。有人使用回车字符去分割包体，例如常见的SMTP/POP协议，这种做法在特定的协议是没有问题的，可是如果我们传输的信息内容自带了回车字符串，那么就糟糕了。所以在设计协议的时候要特别小心。


 


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


 


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


 


一个实际编写的例子：比如我要传输2个整型 int = 1, int = 2，那么实际传输的数据包如下：


   173173173               8                  1         2


|------包头------|----包体长度----|--------包体--------|


这个数据包就是4个整型，总长度 = 4*4  = 16。 


 


说说我走的弯路：


我曾经偷懒，使用特殊结束符去分割包体，这样传输的数据包就不需要指名长度了。可是后来高人告诉我，如果使用特殊结束符去判断包，性能会损失很大，因为我们每次读取一个byte，都要做一次if判断，这个性能损失是非常严重的。所以最终还是走主流，使用以上的结构体。


 


 


------------------


Socket接收的逻辑概述


------------------


针对了我们的数据包设计+socket的传输特点，我们的接收逻辑主要是：


1. 寻找包头。这个包头就是一个int整型。但是写代码的时候要非常注意，一个int实际上占据了4个byte，而可悲的是这4个byte在传输过程中也可能被socket 分割了，因此读取判断的逻辑是：


判断剩余长度是否大于4
读取一个int，判断是否包头，如果是就跳出循环。
如果不是包头，则倒退3个byte，回到第一点。
如果读取完毕也没有找到，则有可能包头被分割了，因此当前已读信息压入接收缓存，等待下一个包到达后合并判断。
2. 读取包体长度。由于长度也是一个int，因此判断的时候也要小心，同上。


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


 


这个逻辑不要小看，就这点东西忙了我1天时间。而非常奇怪的是，我发现c#写的socket，似乎没有我说的这么复杂逻辑。大家可以看看LumaQQ.net / DotMsn等，他们的socket接收代码都非常简单。我猜想：要么是.net的socket进行了优化，不会对int之类的进行分割传输；要么就是作者偷懒，随便写点代码开源糊弄一下。




 


------------------


Socket服务器参数概述


------------------


我在开篇也说了，Socket服务器的环境是非常糟糕了，最糟糕的就是客户端断线之后服务器没有收到通知。 因为socket断线这个也是个信息，也要从客户端传递到我们socket服务器。有可能网络阻塞了，导致服务器连断开的通知都没有收到。


因此，我们写socket服务器，就要面对2个环境：


1. 服务器在处理业务逻辑中的任何时候都会收到Exception, 任何时候都会因为链接中断而断开。


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


 


针对以上几点，我们的服务器设计必须包含以下参数：


1. 客户端链接时间记录：主要判断客户端空连接情况，防止连接数被恶意占用。


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


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


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


 


5. 客户端短时间暴涨：有可能在短时间内，客户端突然发送海量数据，直接导致服务器宕机。因此我们必须有对服务器负荷进行监控，一旦发现负荷过重，直接对请求的socket返回处理失败，例如我们常见的“404”。


 


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


 


 


------------------


后记


------------------


本文从架构设计分析了一个socket服务器的设计要点。如果您有其他见解，欢迎留言与讨论。
本文转载自：http://wenku.baidu.com/link?url=mL2XFLQeLU1btWRynwCp2XDHFThaZeqrvj05OZCsSJHEg6icYGcZbhi3YbpGAZOQ_VqoXmupx8vRvTHd3ZTIhSiyqHcMw4cWjeJjYRDvDpq###