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

whx1977

1很多用户登录服务器是协议用TCP还是UDP？
用TCP。用UDP还得处理重传、重整次序等。

2如果用UDP如何解决数据的不安全性
须增加加密等措施，不管是软加密还是硬加密

3如果用TCP如何解决占用大连网络资源造成网络阻塞的问题。
（多个用户相当于多个线程，并通过socket与服务器建立连接。）
多路复用，epoll／iocp／kqueue 都能很好地解决多线程问题。

heguangwu

个人认为还是抛真实案例好一些，如果12306界面不需要和数据库交互，网络连接神马都不是问题，还在几年前C1000K就已经有解决方案了，如果配合DNS+CDN一起，网络绝对不会是问题

小尾巴鱼 发表于 2015-07-07 16:25
嗯，正文内容有，我把标题也加上了，模拟两个字，可能是这位同学工作中真正的遇到了这个问题，预想12306也会 ...

小尾巴鱼

回复 22# heguangwu


    这几个问题，是真实问题 ，某位同学工作中真实遇到的。

heguangwu

那请问他用TCP是怎么做的，遇到什么问题？
此外，UDP也有一个变种叫UDT，不能发链接，自己搜一下就知道了
回复 23# 小尾巴鱼


   

jieforest

1. 很多用户登录服务器是协议用TCP还是UDP？
用TCP协议或UDP协议都可以，主要还是取决于实际的需求。
UDP提供了不可靠、不保证数据包的有序性的端到端的数据传输服务，要使其可靠，需要在UDP协议上构建自己的协议，比如RUDP（Reliable User Datagram Protocol）可靠用户数据报协议。
以12306购票系统为例，如果客户端限定为Android和iOS，那么采用UDP作为通信协议是可行的（也可以选择TCP）。因为客户端（Android和iOS）是自行开发的，协议可控，服务器端也是自行开发的。
但是12306购票系统的实际情况没有那么简单，客户端还有PC的浏览器，浏览器默认是使用HTTP/HTTPS协议访问的，而HTTP协议构建于TCP协议之上，这就要求服务器端至少需要支持TCP协议，所以为了简化服务器端的开发难度，应选择TCP协议，没必要同时开发TCP和UDP两套通信机制。
故协议确定使用TCP。

2. 如果用UDP如何解决数据的不安全性，
要保证UDP协议的数据安全性问题，可以考虑UDT协议，即UDP-based Data Transfer Protocol，基于UDP的数据传输协议。
引用百科的解释，UDT是一种互联网数据传输协议。UDT的主要目的是支持高速广域网上的海量数据传输，而互联网上的标准数据传输协议TCP在高带宽长距离网络上性能很差。顾名思义，UDT建于UDP之上，并引入新的拥塞控制和数据可靠性控制机制。UDT是面向连接的双向的应用层协议。它同时支持可靠的数据流传输和部分可靠的数据报传输。由于UDT完全在UDP上实现，它也可以应用在除了高速数据传输之外的其它应用领域，例如点到点技术（P2P），防火墙穿透，多媒体数据传输等等。
其次就是考虑引入加密算法，对称加密或非对称加密，把传输的数据进行加密。

3. 如果用TCP如何解决占用大量网络资源造成网络阻塞的问题。
这个问题相关的因素有很多：机房的带宽、网络设施、负载均衡/反向代理、应用服务器集群等。
单从TCP协议本身来讲，是解决不了网络阻塞的问题。
找出引起网络阻塞的瓶颈，解决它。
如果是Nginx反向代理，后端连接多台应用服务器，Nginx负载达到瓶颈了，那么可以用多台Nginx，通过智能DNS分配访问。或者是改为使用硬件负载均衡，连接多台应用服务器。
……

陌路巨额投入

1很多用户登录服务器是协议用TCP还是UDP？
     首先这个问题，这两个协议都是有用到的，用TCP协议或UDP协议都可以。任何一个和TCP打过交道的人都知道，要实现一个稳定的TCP网络连接，需要处理各种隐藏的坑，比如断线检测、慢速客户端响应阻塞数据包，对开放连接的各种dos攻击，阻塞和非阻塞IO模型等等。UDP是基于数据包构建，这意味着在某些方面需要你完全颠覆在TCP下的观念。UDP只使用一个socket进行通信，不像TCP需要为每一个客户端建立一个socket连接。这些都是UDP非常不错的地方。
   如果客户端和服务器都可以独立发包，但是偶尔发生延迟可以容忍（比如：在线的纸牌游戏，许多MMO类的游戏），那么使用TCP长连接吧。
   如果客户端和服务器都可以独立发包，而且无法忍受延迟（比如：大多数的多人动作类游戏，一些MMO类游戏），那么使用UDP吧。

2如果用UDP如何解决数据的不安全性
      来自互联网的UDP数据包可能是对合法服务的响应，也可能是恶意的扫描。只通过简单地查看UDP首部，是没有办法分辨数据包是通信的开始还是一个响应的。因此在安全性方面，控制UDP比处理TCP更困难。
个人觉得的解决办法：
      1.对于不符合条件的数据不予处理。只处理经过验证的数据。
      2.对于逻辑链路层进行改进，加入校验位。

3如果用TCP如何解决占用大连网络资源造成网络阻塞的问题。
      在这个方面现在TCP使用了一个叫慢启动门限(ssthresh)的变量，当cwnd超过该值后，慢启动过程结束，进入拥塞避免阶段。对于大多数TCP实现来说，ssthresh的值是 65536(同样以字节计算)。拥塞避免的主要思想是加法增大，也就是cwnd的值不再指数级往上升，开始加法增加。此时当窗口中所有的报文段都被确认时，cwnd的大小加1，cwnd的值就随着RTT开始线性增加，这样就可以避免增长过快导致网络拥塞，慢慢的增加调整到网络的最佳值。

陌路巨额投入

1很多用户登录服务器是协议用TCP还是UDP？
     首先这个问题，这两个协议都是有用到的，用TCP协议或UDP协议都可以。任何一个和TCP打过交道的人都知道，要实现一个稳定的TCP网络连接，需要处理各种隐藏的坑，比如断线检测、慢速客户端响应阻塞数据包，对开放连接的各种dos攻击，阻塞和非阻塞IO模型等等。UDP是基于数据包构建，这意味着在某些方面需要你完全颠覆在TCP下的观念。UDP只使用一个socket进行通信，不像TCP需要为每一个客户端建立一个socket连接。这些都是UDP非常不错的地方。
   如果客户端和服务器都可以独立发包，但是偶尔发生延迟可以容忍（比如：在线的纸牌游戏，许多MMO类的游戏），那么使用TCP长连接吧。
   如果客户端和服务器都可以独立发包，而且无法忍受延迟（比如：大多数的多人动作类游戏，一些MMO类游戏），那么使用UDP吧。

2如果用UDP如何解决数据的不安全性
      来自互联网的UDP数据包可能是对合法服务的响应，也可能是恶意的扫描。只通过简单地查看UDP首部，是没有办法分辨数据包是通信的开始还是一个响应的。因此在安全性方面，控制UDP比处理TCP更困难。
个人觉得的解决办法：
      1.对于不符合条件的数据不予处理。只处理经过验证的数据。
      2.对于逻辑链路层进行改进，加入校验位。

3如果用TCP如何解决占用大连网络资源造成网络阻塞的问题。
      在这个方面现在TCP使用了一个叫慢启动门限(ssthresh)的变量，当cwnd超过该值后，慢启动过程结束，进入拥塞避免阶段。对于大多数TCP实现来说，ssthresh的值是 65536(同样以字节计算)。拥塞避免的主要思想是加法增大，也就是cwnd的值不再指数级往上升，开始加法增加。此时当窗口中所有的报文段都被确认时，cwnd的大小加1，cwnd的值就随着RTT开始线性增加，这样就可以避免增长过快导致网络拥塞，慢慢的增加调整到网络的最佳值。

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

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