============================================
	项目总结：
	1、服务端
		网络通信：
			tcp协议，长连接
			粘包问题：tcp协议本身没有报文长度的字段
			解决的话是在应用层加一个自定义的数据头，在数据头里面增加一个封包长度字段，按封包长度来进行收包解包即可
			【也可以加一些特殊的标志位来分隔--标志位的风险是内容可能会包含标志位，导致解包出问题】
			
			针对长连接的半开闭连接，使用心跳检测来去除无用的长连接，并且进行客户端的断线重连的保活
			
			
			性能优化：由多线程升级为线程池
				线程池：不会对线程频繁的创建和销毁
					只是控制线程的使用，配合任务队列完成操作；
				操作过程：
					有个总的调度，负责判断任务队列中有没有任务以及线程队列中还有没有空闲线程
					
					如果有任务来并且有空闲线程，就会将任务分发给空闲线程来执行
					
					细节：
					任务队列：
						满的话，就是达到了任务能排的最大值
						就需要抛一个满的异常或者使用条件变量来等待放入队列中；
						
					线程队列：
						线程数最小值、最大值的设定
						最小值：保证常规的操作
						最大值：可能最大的极限，在允许的范围内设定一个合理值
						【一般从最小到最大之间，可以由并发量的增加来对应开辟更多数量的线程，减少也是一样的道理】
				用了线程池之后，业务的操作由同步的方式切换到了异步的方式，性能也能得到进一步提升。 
				
			通信模型：
				select模型：[轮询--按时间间隔每次从头到尾遍历]
					基于数组存放套接字的轮询模型
					数组长度有默认大小：windows-64，linux-1024
					大小可以修改
					量级：1000个左右[千级]
					
				poll模型：
					基于链表存放套接字的轮询模型
					链表无长度限制
					量级：10000个左右[万级]
					
				epoll模型：
					基于事件触发的一个poll模型，效率更高
					使用回调的方式处理
					量级：1000000个左右[百万级]
				
		数据库封装：MySQL数据库的连接数量默认最大值100个
			单例模式--多处地方共用同一个对象
				优点：省内存
				缺点：效率不够高
			
			提升性能：连接池[类似线程池的操作]
				连接池的核心是有一定数量的数据库连接
				有任务来了，可以给一个空闲连接，来执行任务
				
		日志封装：
			单例模式 
			文件滚动--改名算法--用ID或者时间戳的方式改名
				
				
				
				
			
	
	2、客户端
		有界面，最容易碰到的问题是界面卡顿的问题
		解决：将耗时业务放到子线程中去执行，这样就不会阻塞主线程里面的界面响应操作，从而解决卡顿问题
		
		文件传输：断点续传
			一般要在服务端专门弄个表来记录一下传输信息
			当发生传输中断之后，就可以通过查询记录来确定断点处
			再多比较已传内容断点之前的几个字节内容是否和原始文件的一致，一致则开始从断点处重传。
			若记录找不到或已传文件丢失都需要从头开始传输。
		
		超大文件的读取：按行读取，不能一下子全读进来，否则内存不够用