HTTP协议
HTTP1.0定义了三种请求方法：GET, POST 和 HEAD方法。
HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
我们平时最常用的是GET和POST请求。
| 请求方法 | 解释 |
|---|---|
| GET | 使用给定URI向服务器请求信息，GET仅仅用于请求数据不应该对数据有任何影响 |
| HEAD | 类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头 |
| POST | 向服务器提交数据，例如用户信息、文件上传等。使用HTML格式传送数据 |
| PUT | 从客户端向服务器传送的数据取代指定的文档的内容。 |
| DELETE | 请求服务器删除指定的页面。 |
| CONNECT | HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。 |
| OPTIONS | 允许客户端查看服务器的性能。 |
| TRACE | 回显服务器收到的请求，主要用于测试或诊断。 |
HTTP消息请求格式
客户端发送一个HTTP请求到服务器的请求消息包括以下格式：
请求行（request line）、请求头部（header）、空行加请求数据四个部分组成。
GET请求的一个实例
GET请求的服务器回应
注：这个例子中服务器回应的数据采用的是JSON格式。
POST请求的一个实例
状态码
每次HTTP请求之后，服务器在应答报文中有一个状态码，用于告诉客户端服务器的请求处理状态。 状态代码有三位数字组成，第一个数字定义了响应的类别，共分五种类别:
- 1xx：指示信息–表示请求已接收，继续处理
- 2xx：成功–表示请求已被成功接收、理解、接受
- 3xx：重定向–要完成请求必须进行更进一步的操作
- 4xx：客户端错误–请求有语法错误或请求无法实现
- 5xx：服务器端错误–服务器未能实现合法的请求
常见状态码
| 状态码 | 解释 |
|---|---|
| 200 OK | 客户端请求成功 |
| 400 Bad Request | 客户端请求有语法错误，不能被服务器所理解 |
| 401 Unauthorized | 请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用 |
| 403 Forbidden | 服务器收到请求，但是拒绝提供服务 |
| 404 Not Found | 请求资源不存在，eg：输入了错误的URL |
| 500 Internal Server Error | 服务器发生不可预期的错误 |
| 503 Server Unavailable | 服务器当前不能处理客户端的请求，一段时间后可能恢复正常 |
URL解析
例如下面这个链接（我随便组装的一个链接）：
http://cxd2014.github.io:80/2017/02/05/linux-file-system.html?username=cxd&ID=24618#vfs-inode
http://为协议部分，如https、ftp等协议，//为分隔符cxd2014.github.io域名部分:80指定端口号，一般没有指定就使用默认端口号80/2017/02/05/路径部分，从域名后的第一个“/”开始到最后一个“/”为止linux-file-system.html文件部分，从域名后的最后一个“/”开始到“?”为止username=cxd&ID=24618参数部分，从“?”开始到“#”为止，参数可以允许有多个参数，参数与参数之间用“&”作为分隔符。vfs-inode锚部分又叫段标识符，从“#”开始到最后，通常用于定位页面中的片段
URL只能使用ASCII字符集在网络上传输，但是URL中经常包含一些ASCII字符集以外的字符例如中文字符。
所以这些字符需要使用base64进行编码，例如中文字符编码转码后的字符为%E7%BC%96%E7%A0%81
百分号后面的数字为对应字符的十六进制编码。
参考
HTTPS协议
HTTPS:超文本安全传输协议,和HTTP相比,多了一个SSL/TSL的认证过程,端口为443。 在http(超文本传输协议)基础上提出的一种安全的http协议，因此可以称为安全的超文本传输协议。 http协议直接放置在TCP协议之上，而https提出在http和TCP中间加上一层加密层。从发送端看， 这一层负责把http的内容加密后送到下层的TCP，从接收方看，这一层负责将TCP送来的数据解密还原成http的内容。
HTTPS握手过程
HTTPS在握手过程中使用非对称加密算法，而在实际通信过程中使用对称加密算法。 HTTPS握手过程的主要目的就是交换对称加密算法的密钥。
为什么要使用两种不同的加密算法？
因为非对称加密算法一次只能加密少量数据，并且需要大量的计算资源，如果使用非对称加密算法进行实际通信会严重消耗CPU资源。 而对称加密算法可以一次加密大量数据，并且加解密需要的计算资源很小。 但是对称加密算法在通信之前需要交换密钥。所以HTTPS协议在握手阶段使用非对称加密算法交换密钥， 密钥交换成功后使用对称加密算法进行实际通信。
为什么需要证书？
防止中间人攻击，客户端在和服务器通信之间可能会被黑客拦截，黑客冒出服务器欺骗客户端。 所以客户端需要验证服务端是否真实。验证的方法就是通过服务器的证书来验证。
证书的工作原理
要了解证书是怎么做“身份验证”，得从2个角度来说明：
申请证书，即需要被验证身份的一端，需要申请一份能够验证自己身份的证书
验证证书，即需要验证对方身份的一端，拿到证书后验证对端的身份
- 申请证书
用户向CA机构提交自己的信息（如域名）和公钥（用户自己生成的非对称加密公钥，用于TLS握手阶段和另一端协商密钥用）， CA机构将用户提交的信息进行哈希运算得到一个哈希值，接着在用CA机构的私钥对这个哈希值做加密，得到数字签名。CA机构生成数字证书，如下图：
- 验证证书
接受证书的一端先对除数字签名的其他部分做一次相同的哈希算法（证书中指明了哈希算法），得到这段文本的哈希值，记作H1； 获取CA机构的公钥对数字签名属性做解码，得到了CA机构计算出的哈希映射，记作H2。 对比H1和H2两个字符串是否相等，若是，代表该证书的信息未被篡改，证书有效；否则，证书内容被篡改，证书无效。 若证书有效，接受端会再进行对端的身份校验（验证域名是否和证书上的一样）。CA机构的公钥是提前内置在浏览器中。
