模拟12306购票系统的处理多用户购票网络编程（已公布获奖）

shenlanyouyu

好活动支持一个。

shenlanyouyu

1 很多用户登录服务器是协议用TCP还是UDP？、
用户登录服务器大多用的TCP协议，基于Web的用户登录服务器，采用的TCP。TCP维持多人同时在线，占用较多的资源。QQ登陆时采用的TCP协议，在聊天数据传输采用的UDP。
对于12306网站，是典型的B/S架构，用户登录时基于HTTP/HTTPS，登录服务器协议是TCP。

2 如果用UDP如何解决数据的不安全性。
首先我们要明白为什么UDP协议不安全，而TCP协议是安全的。
(1)TCP传输控制协议，提供的是面向连接、可靠的字节流服务。当客户和服务器彼此交换数据前，必须先在双方之间建立一个TCP连接，之后才能传输数据。TCP提供超时重发，丢弃重复数据，检验数据，流量控制等功能，保证数据能从一端传到另一端。
(2)UDP用户数据报协议，是一个简单的面向数据报的运输层协议。UDP不提供可靠性，它只是把应用程序传给IP层的数据报发送出去，但是并不能保证它们能到达目的地。由于UDP在传输数据报前不用在客户和服务器之间建立一个连接，且没有超时重发等机制，没有控制位和序列号，故而传输速度很快。由于传输数据不建立连接，因此也就不需要维护连接状态，包括收发状态等，系统开销较小。

使用UDP解决数据的不安全性，需要从UDP存在的问题出发，基本上是采取了TCP协议的重发机制、拥塞控制，在应用层来保证数据的安全性。可以参考的协议有RTP/RUDP/UDT。基本的方法如下：
在发送端：
(1)  UDP传输的数据包没有TCP大，因此在应用层需要实现分包机制。
(2) 在应用层数据包中添加确认标识，重传计数，为每一个UDP分组设置定时器，处理定时器超时事件，对于不需求确认的包，默认发成功，对于需要确认的包，在没有达到最大重传计数的包，重传包并设置重传计数器，否则报告发送失败事件。
在接收端：
(1) 对于有确认字段的UDP包，发送确认包。
(2) 对于分段包，排序后提交应用层，非分段包直接提交。
为了保证传输过程中数据的安全性，不被非法分子窥见，采用数据加密的方法来解决，发送端和接收端加密算法和解密算法需要一致。

以UDT为例子，UDT拥塞控制算法将速率控制和流量控制合并起来，前者调整包的发送周期，后者限制最大的位被应答的包。UDT有两种包：数据包和控制包。通过包头的第一位来区分标志位。如是0，表示是数据包，1表示是控制包。
(1)数据包结构如下显示：

包序号是UDT数据包头中唯一的内容，序列号是个无符号整数，使用标志位后的31位，UDT使用包基础的需要，
(2)控制包控制包结构如下

UDT使用应答子序号的方法。每个ACK/ACK2包有一个无符号的16位序号。

关于第3个问题单独回复。

shenlanyouyu

3如果用TCP如何解决占用大连网络资源造成网络阻塞的问题。
（多个用户相当于多个线程，并通过socket与服务器建立连接。）
      关于这个问题，前面已经有人提到Nginx这个高并发的Web Server。Nginx的思想可以用来参考，Nginx是一个安全、快速并且灵活的开源Web服务器，占用系统资源少，并发能力强，稳定较高。我自己研究过Nginx的源代码，全部用C语言写的，代码质量非常高。
      Nginx的进程的模型，是主-从结构，一个master进程，多个worker进程。worker进程通常为CPU的数量。进程职责如下：
(1)        master进程是监控进程，充当进程组和用户交互的接口，同时监控worker进程，如果worker进程意外退出，master重新fork一个worker进程。
(2)        worker进程完成具体的业务逻辑，等待客户端建立连接，接收客户端的连接请求等等。
       Nginx采用事件驱动，采用select/poll/epoll等I/O多路复用函数实现，采用了进程 CPU亲和性，避免进程调度带来的开销，实现负载均衡，同时避免了“惊群效应”。
将Nginx的思想，从单机环境推广到分布式，集群环境。前端需要搭建一个反向代理服务器，将用户的请求分发到不同的后端服务器来处理，由这些服务器完成具体的业务逻辑，通过分布式计算能够大大减少业务处理时间。
PS:Nginx也支持反向代理功能。
[用户]----[反向代理服务器]----[后端服务器]
                      |
                 [后端服务器]   
因此，用TCP如何解决占用大量网络资源造成网络阻塞的问题，根据12306的改造资料，可以从以下方面入手：
(1)        升级网络带宽。原因就不用分析了。
(2)        业务优化，可以参考12306的经验，例如采用分时间段售票，减少用户并发量。
(3)        Scale-up方案，从硬件方面入手，更换性能更强大的服务器。
(4)        Scale-out方案，从软件平台方面入手，进行应用系统改造，采用弹性可扩展的框架设计。例如前端优化，减少HTTP连接的数量；数据库读写分离；CDN缓存等等措施。
       Scale-out方案可以借鉴12306的经验。12306最早的系统采用的是Unix小机，当并发量到一定范围时，小机没办法处理，而采用Scale-up方案，成本较高，且系统弹性差。改造后的12306采用的是分布式内存网格Gemfire技术，采用x86服务器集群，通过云计算虚拟化技术，将廉价的x86服务器集中起来，组成高达数十TB的内存资源池，将全部数据加载到内存中，通过内存计算，计算过程不需要读写磁盘，定期将数据同步到磁盘上。在《京东技术解密》中提到秒杀系统，也是采用了内存数据库Redis来实现，异曲同工之妙。推荐一本书《大型网站技术架构》，很不错。

shenlanyouyu

在高并发时，引入排队机制可以缓解系统拥塞。不能企图用技术解决所有问题。很多时候一些问题其实不在于技术架构，而在于其业务架构。通过调整业务架构，例如引入排队机制，业务上分流，能够控制并发访问量。 小米手机抢购，也是使用排队机制。12306也使用了分时段售票来控制并发访问量。

shenlanyouyu

补前面回复中反向代理的网络拓扑结构，没有图不太容易说清楚：