标签：
http://blog.csdn.net/jay900323/article/details/18141217
http://blog.csdn.net/jay900323/article/details/18140847
重叠I/O模型的另外几个优点在于，微软针对重叠I/O模型提供了一些特有的扩展函数。当使用重叠I/O模型时，可以选择使用不同的完成通知方式。
采用事件对象通知的重叠I/O模型是不可伸缩的，因为针对发出WSAWaitForMultipleEvents调用的每个线程，该I/O模型一次最多都只能支持6 4个套接字。假如想让这个模型同时管理不止64个套接字，必须创建额外的工作者线程，以便等待更多的事件对象。因为操作系统同时能够处理的事件对象是有限的，所以基于事件对象的I/O模型不具备伸缩性。 使用完成例程通知的重叠I/O模型，因为以下几个原因，也不是开发高性能服务器的最佳选择。首先，许多扩展功能不允许使用APC（Asyncroneus Procedure Call，异步过程调用）完成通知。其次，由于APC在系统内部特有的处理机制，应用程序线程可能无限等待而得不到完成通知。当一个线程处于“可警告状态”时，所有挂起的APC按照先进先出的顺序（FIFO）接受处理。现在考虑这样一种情况，服务器已经建立起了一个连接，并且调用含有完成例程指针的WSARecv投递了一个重叠I/O请求。当有数据到达时（即I/O完成时），完成例程执行并且再次调用WSARecv抛出另外一个重叠I/O请求。一个APC抛出的I/O操作需要一定的时间才能完成，所以这期间可能另外一个完成例程等待执行（比如本次WSARecv还没接收完时，又有一个新的客户接入并发来数据），因为还有更多的数据需要读取（上一个客户发来的数据尚未读完）。只要（投递WSARecv的）那个套接字上还有“未决”（未接收完）的数据，就会导致调用线程长久阻塞。 基于完成端口通知的重叠I/O模型是Windows NT系统提供的一个真正支持高伸缩性的I/O模型。在上一章中，探讨了Winsock几种常见的I/O模型，并且说明了当应对大规模客户连接时，完成端口是最佳的选择，因为它提供了最好的伸缩性。 对不同Winsock I/O模型的性能测试结果如图1所示。其中服务器采用Pentium 4 1.7 GHz Xeon的CPU，768M内存；客户端有3台PC，配置分别是Pentium 2 233MHz ，128 MB 内存，Pentium 2 350 MHz ，128 MB内存，Itanium 733 MHz ，1 GB内存。服务器、客户端安装的操作系统都是Windows XP。
图1 不同I/O模型的性能比较
1.分析图表1提供的测试结果可知，在所用的I/O模型中，阻塞模式性能最差。这个测试程序中，服务器为每个客户创建两个线程：一个负责处理数据的接收，一个负责处理数据的发送。在多次测试中的共同问题就是，阻塞模式难以应对大规模的客户连接，因为它在创建线程上耗费了太多的系统资源。因此，服务器创建太多的线程后，再调用CreateThread函数时，将返回ERROR_NOT_ENOUGH_MEMORY的错误，这个错误码提示内存不够。那些发出连接请求的客户则收到WSAECONNREFUSED的错误提示，表示连接的尝试被拒绝。 让我们来看看监听函数listen，其原型如下： WINSOCK_API_LINKAGE int WSAAPI listen（SOCKET s, int backlog ）; 参数一s已绑定了地址的监听套接字。 参数二backlog指定了正在等待连接的最大队列长度。 参数backdog非常重要, 因为完全可能同时出现几个对服务器的连接请求。例如，假定backlog参数为2时有三个客户机同时发出连接请求，那么前两个会被放在一个“等待处理”队列中，以便应用程序依次为它们提供服务。而第三个连接的请求就会造成一个WSAECONNREFUSED错误。一旦服务器接受了一个连接请求，那个连接请求就会从队列中删去，以便可以继续接收其他客户发出的连接请求。即当一个连接请求到来时队列已满，那么客户将收到一个WSAECONNREFUSED错误。而backlog参数本身的大小就存在着限制，这个限制是由协议提供者决定的。 故阻塞模式下，由于系统资源的限制，其并发处理量是极难突破的。
2.非阻塞模式表现出的性能要比阻塞模式稍好，但是占用了太多的CPU处理时间。测试服务器将所有客户对应的socket分类放到FD_SET集合中，然后调用select函数筛选出对应集合中有事件发生的socket，并对集合更新。接下来调用FD_ISSET宏重新判断一个套接字是否在原来加入的FD_SET集合中。随着客户连接数量的增多，这种模型的局限性逐渐凸现。仅仅为了判断一个套接字是否有网络事件发生，就需要对集合FD_SET执行一次遍历!使用迭代搜索来对select更新的FD_SET进行扫描，性能可以得到一些提升。瓶颈在于，服务器必须能够很快地扫描出FD_SET集合中的有网络事件发生的套接字的相关信息。针对这个问题，可以使用更复杂的扫描算法，如哈希搜索，它的效率是极高的。还需要注意的一个问题就是，非分页池（即直接在物理内存中分配的内存）的使用极高。这是因为AFD（Ancillary Function Driver,由afd.sys提供的支持Windows Sockets应用程序的底层驱动程序，其中运行在内核模式下afd.sys驱动程序主要管理Winsock TCP/IP通信）和TCP都将使用I/O缓存，因为服务器读取数据的速度是有限的，相对于CPU的处理速度而言，I/O基本是零字节的吞吐量。
3.基于Windows消息机制的WSAAsyncSelect模型能够处理一定的客户连接量，但是扩展性也不是很好。因为消息泵很快就会阻塞，降低了消息处理的速度。在几次测试中，服务器只能处理大约1/3的客户端连接。过多的客户端连接请求都将返回错误提示码WSAECONNREFUSED，说明服务器不能及时处理FD_ACCEPT消息导致连接失败，这样监听队列中待处理的连接请求不致于爆满。然而，通过上表中的数据可以发现，对那些已经建立的连接，其平均吞吐量也是极低的（即使对于那些对比特率进行了限制的客户也如此）。
4.基于事件通知的WSAEventSelect模型表现得出奇的不错。在所有的测试中，大多数时候，服务器基本能够处理所有的客户连接，并且保持着较高的数据吞吐量。这种模型的缺点是，每当有一个新连接时，需要动态管理线程池，因为每个线程只能够等待64个事件对象。当客户连接量超过64个后再有新客户接入时，需要创建新的线程。在最后一次测试中，建立起了超过45,000个的客户连接后，系统响应速度变得非常缓慢。这时由于为处理大规模的客户连接创建了大量的线程，占用了过多的系统资源。791个线程基本达到了极限，服务器不能再接受更多的连接了，原因是WSAENOBUFS：无可用的缓冲区空间，套接字无法创建。另外，客户端程序也达到了极限，不能维持已经建立的连接。 使用事件通知的重叠I/O模型和WSAEventSelect模型在伸缩性上差不多。这两种模型都依赖于等待事件通知的线程池，处理客户通信时，大量线程上下文的切换是它们共同的制约因素。重叠I/O模型和WSAEventSelect模型的测试结果很相似，都表现得不错，直到线程数量超过极限。
5.最后是针对基于完成端口通知的重叠I/O模型的性能测试，由上表中数据可以看出，它是所有I/O模型中性能最佳的。内存使用率（包括用户分页池和非分页池）和支持的客户连接量与基于事件通知的重叠I/O模型和WSAEventSelect模型基本相同。真正不同的地方，在于对CPU的占用。完成端口模型只占用了60%的CPU，但是在维持同样规模的连接量时，另外两种模型（基于事件通知的重叠I/O模型和WSAEventSelect模型）占用更多的CPU。完成端口的另外一个明显的优势是，它维持更大的吞吐量。 对以上各种模型进行分析后，可以会发现客户端与服务器数据通信机制本身存在的缺陷是一个瓶颈。在以上测试中，服务器被设计成只做简单的回应，即只是将客户端发送过来的数据发送回去。客户端（即使有比特率限制）不停的发送数据给服务器，这导致大量数据阻塞在服务器上与这个客户端对应的套接字上（无论是TCP缓冲区还是AFD的单套接字缓冲区，它们都是在非分页池上）。在最后三种性能比较好的模型中，同一时间只能执行一个接受输入操作，这意味着在大多数时间，还是有很多数据处于“未决”状态。可以修改服务器程序使其以异步方式接受数据，这样一旦有数据达到，需要将数据缓存起来。这种方案的缺点是，当一个客户连续发送数据时，异步接受到了大量的数据。这会导致其他的客户无法接入，因为调用线程和工作者线程都不能处理其他的事件或完成通知。通常情况下，调用非阻塞异步接收函数，先返回WSAEWOULDBLOCK，然后数据间断性的传输，而不采取连续接收的方式。 从以上测试结果，可以看出WSAEventSelect模型和重叠I/O模型是性能表现最佳的。两种基于事件通知的模型中，创建线程池来等待事件完成通知并作后续处理是很繁琐的，但是并不影响以它们来架构中型服务器的良好性能。当线程的数量随着客户端连接数量而逐增时，CPU将花费大量时间在线程的上下文切换上，这将影响服务器的伸缩性，因为连接量达到一定数量后，便饱和了。完成端口模型提供了最佳的可扩展性，因为CPU使用率低，其支持的客户连接量相对其他模型最多。 I/O模型的选择 通过上一节对各种模型的测试分析，对于如何挑选最适合自己应用程序的I/O模型已经很明晰了。同开发一个简单的运行多线程的锁定模式应用相比，其他每种I/O模型都需要更为复杂的编程工作。因此，针对客户机和服务器应用开发模型的选择，有以下原则。 1. 客户端 若打算开发一个客户机应用，令其同时管理一个或多个套接字，那么建议采用重叠I/O或WSAEventSelect模型，以便在一定程度上提升性能。然而，假如开发的是一个以Windows为基础的应用程序，要进行窗口消息的管理，那么WSAAsyncSelect模型恐怕是一种最好的选择，因为WSAAsyncSelect本身便是从Windows消息模型借鉴来的。采用这种模型，程序需具备消息处理功能。 2. 服务器端 若开发的是一个服务器应用，要在一个给定的时间，同时控制多个套接字，建议采用重叠I/O模型，这同样是从性能角度考虑的。但是，如果服务器在任何给定的时间，都会为大量I/O请求提供服务，便应考虑使用I/O完成端口模型，从而获得更佳的性能。
作者：huangguisu
1. 概念理解
在进行网络编程时，我们常常见到同步(Sync)/异步(Async)，阻塞(Block)/非阻塞(Unblock)四种调用方式：
同步：
所谓同步，就是在发出一个功能调用时，在没有得到结果之前，该调用就不返回。也就是必须一件一件事做,等前一件做完了才能做下一件事。
例如普通B/S模式（同步）：提交请求->等待服务器处理->处理完毕返回 这个期间客户端浏览器不能干任何事
异步：
异步的概念和同步相对。当一个异步过程调用发出后，调用者不能立刻得到结果。实际处理这个调用的部件在完成后，通过状态、通知和回调来通知调用者。
例如 ajax请求（异步）: 请求通过事件触发->服务器处理（这是浏览器仍然可以作其他事情）->处理完毕
阻塞
阻塞调用是指调用结果返回之前，当前线程会被挂起（线程进入非可执行状态，在这个状态下，cpu不会给线程分配时间片，即线程暂停运行）。函数只有在得到结果之后才会返回。
有人也许会把阻塞调用和同步调用等同起来，实际上他是不同的。对于同步调用来说，很多时候当前线程还是激活的，只是从逻辑上当前函数没有返回而已。 例如，我们在socket中调用recv函数，如果缓冲区中没有数据，这个函数就会一直等待，直到有数据才返回。而此时，当前线程还会继续处理各种各样的消息。
非阻塞
非阻塞和阻塞的概念相对应，指在不能立刻得到结果之前，该函数不会阻塞当前线程，而会立刻返回。
对象的阻塞模式和阻塞函数调用
对象是否处于阻塞模式和函数是不是阻塞调用有很强的相关性，但是并不是一一对应的。阻塞对象上可以有非阻塞的调用方式，我们可以通过一定的API去轮询状 态，在适当的时候调用阻塞函数，就可以避免阻塞。而对于非阻塞对象，调用特殊的函数也可以进入阻塞调用。函数select就是这样的一个例子。
1. 同步，就是我调用一个功能，该功能没有结束前，我死等结果。
2. 异步，就是我调用一个功能，不需要知道该功能结果，该功能有结果后通知我（回调通知）
3. 阻塞， 就是调用我（函数），我（函数）没有接收完数据或者没有得到结果之前，我不会返回。
4. 非阻塞， 就是调用我（函数），我（函数）立即返回，通过select通知调用者
同步IO和异步IO的区别就在于：数据拷贝的时候进程是否阻塞！
阻塞IO和非阻塞IO的区别就在于：应用程序的调用是否立即返回！
对于举个简单c/s 模式：
同步和异步,阻塞和非阻塞,有些混用,其实它们完全不是一回事,而且它们修饰的对象也不相同。 阻塞和非阻塞是指当进程访问的数据如果尚未就绪,进程是否需要等待,简单说这相当于函数内部的实现区别,也就是未就绪时是直接返回还是等待就绪;
而同步和异步是指访问数据的机制,同步一般指主动请求并等待I/O操作完毕的方式,当数据就绪后在读写的时候必须阻塞(区别就绪与读写二个阶段,同步的读写必须阻塞),异步则指主动请求数据后便可以继续处理其它任务,随后等待I/O,操作完毕的通知,这可以使进程在数据读写时也不阻塞。(等待"通知")
1. Linux下的五种I/O模型
1)阻塞I/O（blocking I/O） 2)非阻塞I/O （nonblocking I/O） 3) I/O复用(select 和poll) （I/O multiplexing） 4)信号驱动I/O （signal driven I/O (SIGIO)） 5)异步I/O （asynchronous I/O (the POSIX aio_functions)）
前四种都是同步，只有最后一种才是异步IO。
简介：进程会一直阻塞，直到数据拷贝完成
应用程序调用一个IO函数，导致应用程序阻塞，等待数据准备好。 如果数据没有准备好，一直等待….数据准备好了，从内核拷贝到用户空间,IO函数返回成功指示。
阻塞I/O模型图：在调用recv()/recvfrom（）函数时，发生在内核中等待数据和复制数据的过程。
当调用recv()函数时，系统首先查是否有准备好的数据。如果数据没有准备好，那么系统就处于等待状态。当数据准备好后，将数据从系统缓冲区复制到用户空间，然后该函数返回。在套接应用程序中，当调用recv()函数时，未必用户空间就已经存在数据，那么此时recv()函数就会处于等待状态。
当使用socket()函数和WSASocket()函数创建套接字时，默认的套接字都是阻塞的。这意味着当调用Windows Sockets API不能立即完成时，线程处于等待状态，直到操作完成。
并不是所有Windows Sockets API以阻塞套接字为参数调用都会发生阻塞。例如，以阻塞模式的套接字为参数调用bind()、listen()函数时，函数会立即返回。将可能阻塞套接字的Windows Sockets API调用分为以下四种:
1．输入操作： recv()、recvfrom()、WSARecv()和WSARecvfrom()函数。以阻塞套接字为参数调用该函数接收数据。如果此时套接字缓冲区内没有数据可读，则调用线程在数据到来前一直睡眠。
2．输出操作： send()、sendto()、WSASend()和WSASendto()函数。以阻塞套接字为参数调用该函数发送数据。如果套接字缓冲区没有可用空间，线程会一直睡眠，直到有空间。
3．接受连接：accept()和WSAAcept()函数。以阻塞套接字为参数调用该函数，等待接受对方的连接请求。如果此时没有连接请求，线程就会进入睡眠状态。
4．外出连接：connect()和WSAConnect()函数。对于TCP连接，客户端以阻塞套接字为参数，调用该函数向服务器发起连接。该函数在收到服务器的应答前，不会返回。这意味着TCP连接总会等待至少到服务器的一次往返时间。
使用阻塞模式的套接字，开发网络程序比较简单，容易实现。当希望能够立即发送和接收数据，且处理的套接字数量比较少的情况下，使用阻塞模式来开发网络程序比较合适。
阻塞模式套接字的不足表现为，在大量建立好的套接字线程之间进行通信时比较困难。当使用“生产者-消费者”模型开发网络程序时，为每个套接字都分别分配一个读线程、一个处理数据线程和一个用于同步的事件，那么这样无疑加大系统的开销。其最大的缺点是当希望同时处理大量套接字时，将无从下手，其扩展性很差
我们把一个SOCKET接口设置为非阻塞就是告诉内核，当所请求的I/O操作无法完成时，不要将进程睡眠，而是返回一个错误。这样我们的I/O操作函数将不断的测试数据是否已经准备好，如果没有准备好，继续测试，直到数据准备好为止。在这个不断测试的过程中，会大量的占用CPU的时间。
把SOCKET设置为非阻塞模式，即通知系统内核：在调用Windows Sockets API时，不要让线程睡眠，而应该让函数立即返回。在返回时，该函数返回一个错误代码。图所示，一个非阻塞模式套接字多次调用recv()函数的过程。前三次调用recv()函数时，内核数据还没有准备好。因此，该函数立即返回WSAEWOULDBLOCK错误代码。第四次调用recv()函数时，数据已经准备好，被复制到应用程序的缓冲区中，recv()函数返回成功指示，应用程序开始处理数据。
当使用socket()函数和WSASocket()函数创建套接字时，默认都是阻塞的。在创建套接字之后，通过调用ioctlsocket()函数，将该套接字设置为非阻塞模式。Linux下的函数是:fcntl().
套接字设置为非阻塞模式后，在调用Windows Sockets API函数时，调用函数会立即返回。大多数情况下，这些函数调用都会调用“失败”，并返回WSAEWOULDBLOCK错误代码。说明请求的操作在调用期间内没有时间完成。通常，应用程序需要重复调用该函数，直到获得成功返回代码。
需要说明的是并非所有的Windows Sockets API在非阻塞模式下调用，都会返回WSAEWOULDBLOCK错误。例如，以非阻塞模式的套接字为参数调用bind()函数时，就不会返回该错误代码。当然，在调用WSAStartup()函数时更不会返回该错误代码，因为该函数是应用程序第一调用的函数，当然不会返回这样的错误代码。
要将套接字设置为非阻塞模式，除了使用ioctlsocket()函数之外，还可以使用WSAAsyncselect()和WSAEventselect()函数。当调用该函数时，套接字会自动地设置为非阻塞方式。
由于使用非阻塞套接字在调用函数时，会经常返回WSAEWOULDBLOCK错误。所以在任何时候，都应仔细检查返回代码并作好对“失败”的准备。应用程序连续不断地调用这个函数，直到它返回成功指示为止。上面的程序清单中，在While循环体内不断地调用recv()函数，以读入1024个字节的数据。这种做法很浪费系统资源。
要完成这样的操作，有人使用MSG_PEEK标志调用recv()函数查看缓冲区中是否有数据可读。同样，这种方法也不好。因为该做法对系统造成的开销是很大的，并且应用程序至少要调用recv()函数两次，才能实际地读入数据。较好的做法是，使用套接字的“I/O模型”来判断非阻塞套接字是否可读可写。
非阻塞模式套接字与阻塞模式套接字相比，不容易使用。使用非阻塞模式套接字，需要编写更多的代码，以便在每个Windows Sockets API函数调用中，对收到的WSAEWOULDBLOCK错误进行处理。因此，非阻塞套接字便显得有些难于使用。
但是，非阻塞套接字在控制建立的多个连接，在数据的收发量不均，时间不定时，明显具有优势。这种套接字在使用上存在一定难度，但只要排除了这些困难，它在功能上还是非常强大的。通常情况下，可考虑使用套接字的“I/O模型”，它有助于应用程序通过异步方式，同时对一个或多个套接字的通信加以管理。
简介：主要是select和epoll；对一个IO端口，两次调用，两次返回，比阻塞IO并没有什么优越性；关键是能实现同时对多个IO端口进行监听；
I/O复用模型会用到select、poll、epoll函数，这几个函数也会使进程阻塞，但是和阻塞I/O所不同的的，这两个函数可以同时阻塞多个I/O操作。而且可以同时对多个读操作，多个写操作的I/O函数进行检测，直到有数据可读或可写时，才真正调用I/O操作函数。
简介：两次调用，两次返回；
首先我们允许套接口进行信号驱动I/O,并安装一个信号处理函数，进程继续运行并不阻塞。当数据准备好时，进程会收到一个SIGIO信号，可以在信号处理函数中调用I/O操作函数处理数据。
简介：数据拷贝的时候进程无需阻塞。
当一个异步过程调用发出后，调用者不能立刻得到结果。实际处理这个调用的部件在完成后，通过状态、通知和回调来通知调用者的输入输出操作
同步IO引起进程阻塞，直至IO操作完成。 异步IO不会引起进程阻塞。 IO复用是先通过select调用阻塞。
1. select、poll、epoll简介
epoll跟select都能提供多路I/O复用的解决方案。在现在的Linux内核里有都能够支持，其中epoll是Linux所特有，而select则应该是POSIX所规定，一般操作系统均有实现
select：
select本质上是通过设置或者检查存放fd标志位的数据结构来进行下一步处理。这样所带来的缺点是：
1、 单个进程可监视的fd数量被限制，即能监听端口的大小有限。
一般来说这个数目和系统内存关系很大，具体数目可以cat /proc/sys/fs/file-max察看。32位机默认是1024个。64位机默认是2048.
2、 对socket进行扫描时是线性扫描，即采用轮询的方法，效率较低：
当套接字比较多的时候，每次select()都要通过遍历FD_SETSIZE个Socket来完成调度,不管哪个Socket是活跃的,都遍历一遍。这会浪费很多CPU时间。如果能给套接字注册某个回调函数，当他们活跃时，自动完成相关操作，那就避免了轮询，这正是epoll与kqueue做的。
3、需要维护一个用来存放大量fd的数据结构，这样会使得用户空间和内核空间在传递该结构时复制开销大
poll：
poll本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态，如果设备就绪则在设备等待队列中加入一项并继续遍历，如果遍历完所有fd后没有发现就绪设备，则挂起当前进程，直到设备就绪或者主动超时，被唤醒后它又要再次遍历fd。这个过程经历了多次无谓的遍历。
它没有最大连接数的限制，原因是它是基于链表来存储的，但是同样有一个缺点：
1、大量的fd的数组被整体复制于用户态和内核地址空间之间，而不管这样的复制是不是有意义。 2、poll还有一个特点是“水平触发”，如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd。
epoll:
epoll支持水平触发和边缘触发，最大的特点在于边缘触发，它只告诉进程哪些fd刚刚变为就需态，并且只会通知一次。还有一个特点是，epoll使用“事件”的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用类似callback的回调机制来激活该fd，epoll_wait便可以收到通知
epoll的优点：
1、支持一个进程所能打开的最大连接数
|
select |
单个进程所能打开的最大连接数有FD_SETSIZE宏定义，其大小是32个整数的大小（在32位的机器上，大小就是32*32，同理64位机器上FD_SETSIZE为32*64），当然我们可以对进行修改，然后重新编译内核，但是性能可能会受到影响，这需要进一步的测试。 |
|
poll |
poll本质上和select没有区别，但是它没有最大连接数的限制，原因是它是基于链表来存储的 |
|
epoll |
虽然连接数有上限，但是很大，1G内存的机器上可以打开10万左右的连接，2G内存的机器可以打开20万左右的连接 |
2、FD剧增后带来的IO效率问题
|
select |
因为每次调用时都会对连接进行线性遍历，所以随着FD的增加会造成遍历速度慢的“线性下降性能问题”。 |
|
poll |
同上 |
|
epoll |
因为epoll内核中实现是根据每个fd上的callback函数来实现的，只有活跃的socket才会主动调用callback，所以在活跃socket较少的情况下，使用epoll没有前面两者的线性下降的性能问题，但是所有socket都很活跃的情况下，可能会有性能问题。 |
3、 消息传递方式
|
select |
内核需要将消息传递到用户空间，都需要内核拷贝动作 |
|
poll |
同上 |
|
epoll |
epoll通过内核和用户空间共享一块内存来实现的。 |
总结：
综上，在选择select，poll，epoll时要根据具体的使用场合以及这三种方式的自身特点。
1、表面上看epoll的性能最好，但是在连接数少并且连接都十分活跃的情况下，select和poll的性能可能比epoll好，毕竟epoll的通知机制需要很多函数回调。
2、select低效是因为每次它都需要轮询。但低效也是相对的，视情况而定，也可通过良好的设计改善
Windows五种IO模型性能分析和Linux五种IO模型性能分析
标签：
原文地址：http://www.cnblogs.com/MYSQLZOUQI/p/4231463.html
