HTTP
HTTP协议简介
HTTP，超文本传输协议，HyperText Transfer Protocol，是一种用于分布式、协作式和超媒体信息系统的应用层协议，是因特网上应用最为广泛的一种网络传输协议，所有的 WWW 文件都必须遵守这个标准。并且基于 TCP/IP 通信协议来传递数据的。
HTTPS，超文本传输安全协议，HyperText Transfer Protocol Secure，是一种通过计算机网络进行安全通信的传输协议。提供对网站服务器的身份认证，保护交换资料的隐私与完整性。
消息结构
客户端发送一个HTTP请求到服务器的请求消息包括以下格式：请求行（request line）、请求头部（header）、空行和请求数据四个部分组成。
HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。
请求方法
HTTP请求方法大家都知道，下面简单列个表描述一下。
| 序号 | 方法 | 描述 |
|---|---|---|
| 1 | GET | 请求指定的页面信息，并返回实体主体。 |
| 2 | HEAD | 类似于 GET 请求，只不过返回的响应中没有具体的内容，用于获取报头 |
| 3 | POST | 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。 |
| 4 | PUT | 从客户端向服务器传送的数据取代指定的文档的内容。 |
| 5 | DELETE | 请求服务器删除指定的页面。 |
| 6 | CONNECT | HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。 |
| 7 | OPTIONS | 允许客户端查看服务器的性能。 |
| 8 | TRACE | 回显服务器收到的请求，主要用于测试或诊断。 |
| 9 | PATCH | 是对 PUT 方法的补充，用来对已知资源进行局部更新 。 |
响应头信息
响应头很多，我们列举几个常见的响应头。
| 响应头 | 说明 |
|---|---|
| Allow | 服务器支持哪些请求方法（如GET、POST等） |
| Content-Encoding | 数据的编码形式 |
| Content-Length | 表示内容长度 |
| Content-Type | 表示后面的文档属于什么MIME类型。Servlet默认为text/plain，但通常需要显式地指定为text/html |
| Date | 当前的GMT时间 |
状态码
当访问一个网页时，浏览器会向网页所在服务器发出请求。当浏览器接收并显示网页前，服务器会返回一个包含 HTTP 状态码的响应头用以响应浏览器的请求。状态码（HTTP Status Code）大家常见的有200,201,400,404,500等等。
| 状态码 | 状态码英文名称 | 中文描述 |
|---|---|---|
| 200 | OK | 请求成功。一般用于GET与POST请求 |
| 201 | Created | 已创建。成功请求并创建了新的资源 |
| 202 | Accepted | 已接受。已经接受请求，但未处理完成 |
| 400 | Bad Request | 客户端请求的语法错误，服务器无法理解 |
| 401 | Unauthorized | 请求要求用户的身份认证 |
| 403 | Forbidden | 服务器理解请求客户端的请求，但是拒绝执行此请求 |
| 404 | Not Found | 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面 |
| 405 | Method Not Allowed | 客户端请求中的方法被禁止 |
| 500 | Internal Server Error | 服务器内部错误，无法完成请求 |
| 502 | Bad Gateway | 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应 |
请求流程
（来源于网络）
HTTP框架设计
分层设计
涉及到计算机网络中的OSI七层模型和TCP/IP框架协议四层概念模型。
设计目标有 高内聚低耦合，高复用和高扩展性。
（来源于网络）
一个切实可行的复杂系统势必是从一个切实可行的简单系统发展而来的。从头开始设计的复杂系统根本不切实可行，无法修修补补让它切实可行。你必须由一个切实可行的简单系统重新开始。————盖尔定律
应用层设计
应用层设计满足一些指标：
- 可理解性
- 简单性
- 冗余性
- 兼容性
- 可测性
- 可见性
不要试图在文档中说明，因为很多用户不看。
中间件设计
中间件需求:
- 配合Handler实现一个完整的请求处理生命周期
- 拥有预处理逻辑与后处理逻辑
- 可以注册多中间件
- 对上层模块用户逻辑模块易用
设计步骤：
- 既然要实现预处理和后处理，那这个就很像调用了一个函数
- 路由上可以注册多Middleware，同时也可以满足请求级别有效只需要将Middleware 设计为和业务和 Handler 相同即可。
但是也会存在一些问题。
路由设计
框架路由实际上就是为URL匹配对应的处理函数（Handlers)
- 静态路由:/a/b/c、/a/b/d
- 参数路由:/a/:id/c (/a/b/c，/a/d/c)、/*all
- 路由修复:/a/b <-> /a/b/
- 冲突路由以及优先级:/a/b、/:id/c
- 匹配 HTTP方法
- 多处理函数:方便添加中间件
- 明确需求:考虑清楚要解决什么问题、有哪些需求
- 业界调研:业界都有哪些解决方案可供参考
- 方案权衡:思考不同方案的取舍
- 方案评审:相关同学对不同方案做评审
- 确定开发:确定最合适的方案进行开发
协议层设计
抽象出合适的接口。
网络层设计
五种IO模型：
阻塞式IO（bloking IO）、非阻塞式IO（non-blocking IO）、多路复用IO模型（multiplexing IO）、信号驱动IO模型（signal-driven IO）以及异步IO模型（asynchronous IO）
