boost官网上的例子（https://www.boost.org/doc/libs/1_67_0/doc/html/boost_asio/examples/cpp03_examples.html）实现了四种httpserver的处理方式：
1、http::server，简单的单线程服务器，只有一个主线程；
设计思想比较简单：主线程先预先申请一个连接对象connection并使用的acceptor对connection对象监听客户端的连接，连接到来后将该连接加入到连接管理connection_manager数组中，并重新预分配一个连接对象开始新一轮监听；
connection_manager调用connection的start()函数，开始向io_context投递接收请求，接收请求处理完后调用回调函数handle_read进行处理，并开始新一轮投递接收请求；
2、 http::server2 多个io_contex响应socket连接
基本原理：多个io_cotex对象可以同时存在，任何一个io_cotex对象只要调用io_contex::run()运行，它就能保证所有绑定在它身上的异步动作被检测。所以你需要检测的工作可以绑定在任意的io_cotex对象上，只要它在run()状态即可。
思路：建立io_contex池，为每一个io_contex对象开启一个线程运行io_contex::run()。其中boost::asio::signal_set对象（响应unix信号异步处理）、boost::asio::ip::tcp::acceptor对象（接收器异步监听连接的到来）绑定在固定一个io_cotex对象上，boost::asio::ip::tcp::socket对象则动态绑定到io_contex池中某个io_contex对象上，从而由io_contex池中多个io_contex对象共同分担socket需要处理的工作量。
核心代码：
//前置准备工作已经绑定信号处理signal_set对象、接收器对象acceptor_到固定的io_context对象（代码略）
//前置工作准备妥当之后进入start_accept()函数。
void server::start_accept()
{
new_connection_.reset(new connection(
io_context_pool_.get_io_context(), //从io_context池中取下一个io_context对象出来进行绑定
request_handler_));
acceptor_.async_accept(new_connection_->socket(),//新绑定池中某个io_context对象的socket
boost::bind(&server::handle_accept, this,
boost::asio::placeholders::error));
}
void server::handle_accept(const boost::system::error_code& e)
{
if (!e)
{
new_connection_->start(); //当前socket连接的异步处理
}
start_accept(); //重新将异步检测注册到io_context对象上，注io_context对象是接收器acceptor_所绑定的那个io_context对象。
}
3、 http::server3 一个io_context多个线程run()
和http::server的单线程相比，http::server3主要是（1）将io_context::run()改由多线程中执行，每个线程run()实际上都是共享一个io_context对象。（2）定义boost::asio::io_contex::strand对象，由strand对象确保多线程run()执行的安全有序。
核心代码：
void connection::start()
{
//使用strand来保证对该socket的访问是串行化的
socket_.async_read_some(boost::asio::buffer(buffer_),
boost::asio::bind_executor(strand_,
boost::bind(&connection::handle_read,
shared_from_this(),
boost::asio::placeholders::error,
boost::asio::placeholders::bytes_transferred)//end bind
)//end bind_executor
);
}4、 http::server4 单线程的协程
5、http 总结
http::server没什么好说的就是一个单线程
http::server2
思想:为每个线程分配一个io_context，每个线程访问自己相关io_context的任务队列。
优点：每个线程只访问自己的任务队列，不用增加额外的锁相关开销；且保证了一个socket连接只在一个线程中，不会出现两个线程同时访问该socket的情况
缺点：会出现一个线程忙死，另一个线程闲死的情况
http::server3
思想：分配一个共享io_context，让多个线程共同调用io_context::run()，即多个线程共同抢占Io_context任务队列；
优点：每个线程的机会是均等的不会出现一个线程忙死，另一个线程闲死的情况；
缺点：多个线程访问同一个任务队列，增加额外加锁，释放锁的开销；并且因为是多个线程访问同一个任务队列，就会出现两个线程同时等待访问一个socket的情况，
要么对该socket加锁，要么使用boost::strand来保证串行执行，不管用哪一个都增加额外开销
通过比较发现在serve2中的优点恰是serve3的缺点，serve2的缺点恰是serve3的优点，具体使用哪个方案要看具体的项目,
如果是大量同时登录且登录后操作不多的情况server2更好一点，
如果是传统应用中客户端连接数比较少，且一个客户端要对服务器做大量操作，则server3更适合；
6、https_server
https是http基础上加入ssl加密协议，相较http方式，主要差异：
a、以 boost::asio::ssl::stream<boost::asio::ip::tcp::socket> 代替 boost::asio::ip::tcp::socket。
b、服务端accept成功之后， 需要socket().async_handshake()； 成功之后才能发起异步读写。如果是客户端，也类似，客户端connect成功之后， 需要socket().async_handshake()； 成功之后才能发起异步读写。
与tcp socket相比， 多一个handshake过程。 数据的封包与解析与tcp完全一致，无需另行处理ssl协议数据，连接生成的socket对象已经自动在内部实现加解密。