wordpress 压缩网站百度一下官方网页版
终于是写完了，花费了2周时间，一点一点看，还没有扩展，但是基本功能是已经实现了。利用的是Tcp为网络链接，在其上面又写了http的壳。没有使用epoll，多路转接难度比较高，以后有机会再写，使用了多线程来对每一个链接请求做工作，每次处理一个工作后，响应结束后，服务器主动关闭对端链接，做到短链接，防止服务器链接过载宕机，主要是我的云服务器是学习用的，硬件就摆在哪里，过多的链接会导致我服务器崩溃，这是没有办法的呀。
项目我采用技术有：
- 线程池
- 定向对象池
- TCP/IP
- HTTP协议解析
- 生产消费者模型(线程池基于我们的方便)
- CGI模式
- C语言对数据库访问
- 其他杂七杂八的知识
设计的类有：
- object类：定向对象内存池，创建和析构对象的用户内存池
- Sock类：对listen初始化和获取外部链接的一个插件类，为TcpServer做配件。
- TcpServer类：对于链接的承上启下的，使用哈希桶在用户层管理每个链接的链接状态，为http提供接口，使用Sock类的接口。
- Connection类：对从Accept取得的外部链接做进一步封装。
-
HttpServer类：使用TcpServer类做的上层管理。也其实是中转站。
-
Log类：写日志的类。
-
HttpRequest类：管理链接发来的数据，解析协议后存放类。
-
HttpResponse类：管理给对端发送的数据，保存协议生成的类。
-
EndPoint类：处理协议的地方，并且并且构建响应，发送http响应报文
-
CallBack类：这是我们处理任务的地方，当任务结束析构该类，也会析构该链接。
-
Task类：构建对象，传递到任务队列中（不论阻塞还是环形）
-
GuardLock类：哨兵锁，我们定义了一个全局的锁，为了单例所使用
-
ThreadPool类：线程池一次性启动一堆线程，循环的方式等待任务队列有东西，有就拿，没就等
执行流程大致为：
- 前期：我们的服务器启动，单例线程池创建，多条线程开始等待，单例TcpServer生成，Connection池生成，开始listen套接字绑定，开启监听模式，accept开始等待链接。
- 浏览器->服务器：浏览器构建http报文，并且发送给服务器发起链接请求，在三次握手后，服务器从Sock拿到链接到HttpServer中，使用链接创建Task任务对象，然后将任务放入连接池中的任务队列后中，剩下对接其链接的事情就交给子线程了。然后放入后就继续等待链接了。
- 线程->协议解析：在等待的线程从任务队列中得到了一个任务，使用任务的回调方法，其实就是Callback的’()‘重载每个任务其实都一样都是调用运算符重载，只是传入的链接不同。CallBack的运算符重载函数中，生成EndPoint对象传入conn链接，EndPoint对象启动对链接的读取，协议解析，构建响应，发送响应。
- 构建响应：在构建响应的过程中，我们甄别是否为CGI模式请求，根据GET url是否有参数（看看有没有?字符存在），如果是POST模式，我们直接认为是CGI模式的请求。
- 非CGI模式：打开其url访问的路径文件，不用读取其路径文件(在我们的磁盘上)，然后其实就发送响应了,然后继续响应报文其他部分。
- CGI模式：创建2个管道做数据的交互，创建子进程，在程序替换前将子进程的0、1文件描述符dup为管道的读写端文件描述符，如果是GET方法的CGI模式，我们采用环境变量传参传递快，缺点参数不能太长，如果是POST则只能读取数据，然后子进程程序替换，当然在替换前我们还得传个环境变量，其是来帮助我们确定请求方法的，为了POST方法读取参数使用。在CGI程序中处理完毕后构建响应数据通过dup后的文件描述符1，写回父进程，然后关闭，父进程是使用响应报文的body来接收子进程发送给其的处理后的数据。
- 其他构建：构建协议状态行这是同一的构建，然后根据状态码，构建协议报头head。
- 响应发送：响应构建完毕，将响应报文以状态行，报头，空行，实际数据依次发送，在发送最后的数据body的时候，根据是否为CGI模式区分发送模式，是CGI模式，就发送响应中保存的body数据，不是CGI模式，就通过sendfile函数将_fd磁盘中数据直接发送给sock链接中，以内核数据拷贝到内核数据的方式，减少拷贝，body数据不在经过用户层。
- 发送完毕：发送完毕，EndPoint对象释放，当然也可以为其创建对象池。线程结束任务继续尝试从任务池获取下一个任务。
- 服务器->浏览器：浏览器得到响应，解析协议，这不是我该处理的活。
