我为什么不断的更新博客呢？这是一次很好的提升机会。 平时解决问题的时候可能考虑进度问题没有更深刻地去理解，但是在写博客的时候，你会不知不觉中对一些内容进行思考，并有可能和评论者一起深入，这些都是难得的机会。
可能有人会问我，我为什么不断的更新博客呢？
我觉得吧，这是一次很好的提升机会。 平时解决问题的时候可能考虑进度问题没有更深刻地去理解，但是在写博客的时候，我会不知不觉中对一些内容进行思考，可以更深入的理解问题。在学习的过程中，不断的总结，不断的思考，不断记忆，慢慢知识就巩固了。
我是一个比较慢热的人，希望我可以用这个方式不断提高自己~
共同加油！
想要解锁更多新姿势？请访问我的博客
HTTP协议是什么？
HTTP协议（HyperText Transfer Protocol，超文本传输协议）:是客户端浏览器或其他程序与Web服务器之间的应用层通信协议 ，是基于请求/响应范式的。
一个客户机与服务器建立连接后，发送一个请求给服务器，请求方式的格式为，统一资源标识符、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可能的内容。
服务器接到请求后，给予相应的响应信息，其格式为一个状态行包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。
它在客户端和服务器端请求和相应
RT
- 传输资源
通过html传输 ：文本、word、avi电影、其他资源
- 传输的媒体类型
服务端向浏览器传输MIME类型的文件，浏览器拿到MIME类型的文件，就可以解析了 。 譬如text/html、 image/jpeg 、application/xml，json格式，都属于MIME类型
- URI和URL
要了解http的传输，首先要知道传输的对象是什么。
URI:web服务器中某个资源的名字。 譬如index.html
URL:网络资源描述
举个栗子：
( http://)[resume.tengshe789.tech][:80]/java/index.html[?query-string] #location
这时个典型的url，url里面是什么意思呢？
schema(协议): http/https/ftp.
host: web服务器的ip地址或者域名
port: 服务端端口， http默认访问的端口是80
path: 资源访问路径#location
query-string: 查询参数[?query-string]
- 方法
每个请求都会携带GET/PUT/DELETE/POST/HEAD这样的一个方法，服务器拿到方法就知道自己该做什么了。
那java中有doGet()doPost()方法，有什么区别呢？
doGet：GET方法会把名值对追加在请求的URL后面。因为URL对字符数目有限制，进而限制了用在客户端请求的参数值的数目。并且请求中的参数值是可见的，因此，敏感信息不能用这种方式传递。
doPOST：POST方法通过把请求参数值放在请求体中来克服GET方法的限制，因此，可以发送的参数的数目是没有限制的。最后，通过POST请求传递的敏感信息对外部客户端是不可见的。
| 方法 | GET | POST |
|---|---|---|
| 缓存 | 能被缓存 | 不能缓存 |
| 编码类型 | application/x-www-form-urlencoded | application/x-www-form-urlencoded 或 multipart/form-data。为二进制数据使用多重编码。 |
| 对数据长度的限制 | 是的。当发送数据时，GET 方法向 URL 添加数据；URL 的长度是受限制的（URL 的最大长度是 2048 个字符） | 无限制。 |
| 对数据类型的限制 | 只允许 ASCII 字符 | 没有限制。也允许二进制数据。 |
| 安全性 | 与 POST 相比，GET 的安全性较差，因为所发送的数据是 URL 的一部分。在发送密码或其他敏感信息时绝不要使用 GET | POST 比 GET 更安全，因为参数不会被保存在浏览器历史或 web 服务器日志中。 |
| 可见性 | 数据在 URL 中对所有人都是可见的。 | 数据不会显示在 URL 中。 |
报文
http交换与传输的数据单元是报文。报文由从客户机到服务器的请求和从服务器到客户机的响应构成。
应答报文格式如下：
状态行 － 通用信息头 － 响应头 － 实体头 － 报文主体
状态码元由3位数字组成，表示请求是否被理解或被满足。原因分析是对原文的状态码作简短的描述，状态码用来支持自动操作，而原因分析用来供用户使用。客户机无需用来检查或显示语法。有关通用信息头，响应头和实体头方面的具体内容可以参照相关文件。
request
request报文格式如下：
请求行 － 通用信息头 － 请求头 － 实体头 － 报文主体
request消息结构包含三部分： （起始行、首部字段、主体）
下面抓包验证，抓包使用的是Charles这个软件。
如图所示，起始行： METHOD /path / http/version-number
首部字段： 头信息Header-Name:value
主体 返回内容optional request body
请求行以方法字段开始，后面分别是 URL 字段和 HTTP 协议版本字段，并以 CRLF 结尾。SP 是分隔符。除了在最后的 CRLF 序列中 CF 和 LF 是必需的之外，其他都可以不要。有关通用信息头，请求头和实体头方面的具体内容可以参照相关文件。
response
response报文格式如下：
状态行 － 通用信息头 － 响应头 － 实体头 － 报文主体
第一部分 包括 协议版本http/version-number 状态status code message
第二部分 头信息header-name:value
第三部分 body
状态码元由3位数字组成，表示请求是否被理解或被满足。原因分析是对原文的状态码作简短的描述，状态码用来支持自动操作，而原因分析用来供用户使用。客户机无需用来检查或显示语法。有关通用信息头，响应头和实体头方面的具体内容可以参照相关文件。
常见状态码
http/1.1版本的协议里面定义了五种类型的状态码：
1XX 提示信息
2XX 成功
3XX 重定向
4XX 客户端错误
5XX 服务器端的错误
| 消息 | 描述 |
|---|---|
| 100 Continue | 服务器仅接收到部分请求，但是一旦服务器并没有拒绝该请求，客户端应该继续发送其余的请求。 |
| 101 Switching Protocols | 服务器转换协议：服务器将遵从客户的请求转换到另外一种协议。 |
| 消息 | 描述 |
|---|---|
| 200 OK | 请求成功（其后是对GET和POST请求的应答文档。） |
| 201 Created | 请求被创建完成，同时新的资源被创建。 |
| 202 Accepted | 供处理的请求已被接受，但是处理未完成。 |
| 203 Non-authoritative Information | 文档已经正常地返回，但一些应答头可能不正确，因为使用的是文档的拷贝。 |
| 204 No Content | 没有新文档。浏览器应该继续显示原来的文档。如果用户定期地刷新页面，而Servlet可以确定用户文档足够新，这个状态代码是很有用的。 |
| 205 Reset Content | 没有新文档。但浏览器应该重置它所显示的内容。用来强制浏览器清除表单输入内容。 |
| 206 Partial Content | 客户发送了一个带有Range头的GET请求，服务器完成了它。 |
| 消息 | 描述 |
|---|---|
| 300 Multiple Choices | 多重选择。链接列表。用户可以选择某链接到达目的地。最多允许五个地址。 |
| 301 Moved Permanently | 所请求的页面已经转移至新的url。 |
| 302 Found | 所请求的页面已经临时转移至新的url。 |
| 303 See Other | 所请求的页面可在别的url下被找到。 |
| 304 Not Modified | 未按预期修改文档。客户端有缓冲的文档并发出了一个条件性的请求（一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档）。服务器告诉客户，原来缓冲的文档还可以继续使用。 |
| 305 Use Proxy | 客户请求的文档应该通过Location头所指明的代理服务器提取。 |
| 306 Unused | 此代码被用于前一版本。目前已不再使用，但是代码依然被保留。 |
| 307 Temporary Redirect | 被请求的页面已经临时移至新的url。 |
| 消息 | 描述 |
|---|---|
| 400 Bad Request | 服务器未能理解请求。 |
| 401 Unauthorized | 被请求的页面需要用户名和密码。 |
| 401.1 | 登录失败。 |
| 401.2 | 服务器配置导致登录失败。 |
| 401.3 | 由于 ACL 对资源的限制而未获得授权。 |
| 401.4 | 筛选器授权失败。 |
| 401.5 | ISAPI/CGI 应用程序授权失败。 |
| 401.7 | 访问被 Web 服务器上的 URL 授权策略拒绝。这个错误代码为 IIS 6.0 所专用。 |
| 402 Payment Required | 此代码尚无法使用。 |
| 403 Forbidden | 对被请求页面的访问被禁止。 |
| 403.1 | 执行访问被禁止。 |
| 403.2 | 读访问被禁止。 |
| 403.3 | 写访问被禁止。 |
| 403.4 | 要求 SSL。 |
| 403.5 | 要求 SSL 128。 |
| 403.6 | IP 地址被拒绝。 |
| 403.7 | 要求客户端证书。 |
| 403.8 | 站点访问被拒绝。 |
| 403.9 | 用户数过多。 |
| 403.10 | 配置无效。 |
| 403.11 | 密码更改。 |
| 403.12 | 拒绝访问映射表。 |
| 403.13 | 客户端证书被吊销。 |
| 403.14 | 拒绝目录列表。 |
| 403.15 | 超出客户端访问许可。 |
| 403.16 | 客户端证书不受信任或无效。 |
| 403.17 | 客户端证书已过期或尚未生效。 |
| 403.18 | 在当前的应用程序池中不能执行所请求的 URL。这个错误代码为 IIS 6.0 所专用。 |
| 403.19 | 不能为这个应用程序池中的客户端执行 CGI。这个错误代码为 IIS 6.0 所专用。 |
| 403.20 | Passport 登录失败。这个错误代码为 IIS 6.0 所专用。 |
| 404 Not Found | 服务器无法找到被请求的页面。 |
| 404.0 | （无）–没有找到文件或目录。 |
| 404.1 | 无法在所请求的端口上访问 Web 站点。 |
| 404.2 | Web 服务扩展锁定策略阻止本请求。 |
| 404.3 | MIME 映射策略阻止本请求。 |
| 405 Method Not Allowed | 请求中指定的方法不被允许。 |
| 406 Not Acceptable | 服务器生成的响应无法被客户端所接受。 |
| 407 Proxy Authentication Required | 用户必须首先使用代理服务器进行验证，这样请求才会被处理。 |
| 408 Request Timeout | 请求超出了服务器的等待时间。 |
| 409 Conflict | 由于冲突，请求无法被完成。 |
| 410 Gone | 被请求的页面不可用。 |
| 411 Length Required | “Content-Length” 未被定义。如果无此内容，服务器不会接受请求。 |
| 412 Precondition Failed | 请求中的前提条件被服务器评估为失败。 |
| 413 Request Entity Too Large | 由于所请求的实体的太大，服务器不会接受请求。 |
| 414 Request-url Too Long | 由于url太长，服务器不会接受请求。当post请求被转换为带有很长的查询信息的get请求时，就会发生这种情况。 |
| 415 Unsupported Media Type | 由于媒介类型不被支持，服务器不会接受请求。 |
| 416 Requested Range Not Satisfiable | 服务器不能满足客户在请求中指定的Range头。 |
| 417 Expectation Failed | 执行失败。 |
| 423 | 锁定的错误。 |
| 消息 | 描述 |
|---|---|
| 500 Internal Server Error | 请求未完成。服务器遇到不可预知的情况。 |
| 500.12 | 应用程序正忙于在 Web 服务器上重新启动。 |
| 500.13 | Web 服务器太忙。 |
| 500.15 | 不允许直接请求 Global.asa。 |
| 500.16 | UNC 授权凭据不正确。这个错误代码为 IIS 6.0 所专用。 |
| 500.18 | URL 授权存储不能打开。这个错误代码为 IIS 6.0 所专用。 |
| 500.100 | 内部 ASP 错误。 |
| 501 Not Implemented | 请求未完成。服务器不支持所请求的功能。 |
| 502 Bad Gateway | 请求未完成。服务器从上游服务器收到一个无效的响应。 |
| 502.1 | CGI 应用程序超时。 · |
| 502.2 | CGI 应用程序出错。 |
| 503 Service Unavailable | 请求未完成。服务器临时过载或当机。 |
| 504 Gateway Timeout | 网关超时。 |
| 505 HTTP Version Not Supported | 服务器不支持请求中指明的HTTP协议版本。 |
缓存
作用有三，减少客户端请求频率，增加客户端响应速度，减少冗余数据的传输
下图是谷歌浏览器调试模式界面，在header栏中清晰的显示了缓存的最大保持时间
HTTP协议的特点
- 无状态（每次请求都是独立的）
通过cookie+session的机制，完成它的无状态特点
- 多次请求
- 基于TCP协议
协议版本号
Http1.1和Http1.0的区别
- HTTP/1.0协议使用非持久连接,即在非持久连接下,一个tcp连接只传输一个Web对象；
- HTTP/1.1默认使用持久连接(然而,HTTP/1.1协议的客户机和服务器可以配置成使用非持久连接)。
HTTP2.0与HTTP1.0的区别
HTTP2.0的多路复用
浏览器对同一域名下的并发连接数量有限制，一般为6个，HTTP1中的Keep-Alive用于长连接而不必重新建立连接，然而keep-alive必须等本次请求彻底完成后才能发送下一个请求，而HTTP2的请求与响应以二进制帧的形式交错进行，只需建立一次连接，即一轮三次握手，实现多路复用。
HTTP2.0压缩消息头
HTTP1的消息头很大冗余，而HTTP2.0利用HPACK对消息头进行压缩传输，假设将常用的请求GET/index.html用1表示，POST/index.html用2表示，即是将消息头中的不同的部分分别用不用的索引进行表示，且会用哈夫曼编码压缩字符串，最后封装成frame。索引表分为动态索引和静态索引，动态索引表在客户端和服务器端共同维护，静态索引采用硬编码形式。
HTTP2.0服务端推送
HTTP2.0中服务器会主动将资源推送给客户端，例如把js和css文件主动推送给客户端而不用客户端解析HTML后请求再响应。
HTTPS
HTTP请求过程中，客户端与服务器之间没有任何身份确认的过程，数据全部明文传输，“裸奔”在互联网上，所以很容易遭到黑客的攻击劫持让系统瘫痪，当客户端发送请求很容易被黑客截获，如果黑客冒充目标服务器，则可返回任意信息给客户端，不被客户端所察觉，我们经常会听到“劫持”一词，所以使用直接使用HTTP传输是有风险的。
HTTPS协议（HyperText Transfer Protocol over Secure Socket Layer）：可以理解为HTTP+SSL/TLS，即HTTP下加入SSL层，HTTPS的安全基础是 SSL，因此加密的详细内容就需要SSL，用于安全的HTTP数据传输。
历史
- 网警公司的SSL3.0
SSL（Secure Socket Layer，安全套接字层）：1994年为网景所研发，SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持。
- ISOC这个组织 在SSL的基础上发布了升级版本 TLS1.2
TLS（Transport Layer Security，传输层安全）：其前身是SSL，它最初的几个版本（SSL 1.0、SSL 2.0、SSL 3.0）由网景公司开发，1999年从3.1 开始被IETF标准化并改名，发展至今已经有 TLS 1.0、TLS 1.1、TLS 1.2 三个版本。SSL3.0和TLS1.0由于存在安全漏洞，已经很少被使用到。目前使用最广泛的是TLS 1.1、TLS 1.2。
HTTPS的工作原理
假设A要给B发“我爱你”
对称加解密
如果使用对称加解密
B有密钥，可以进行相应的解密。由于密钥是公开的，所有的客户端都可以拿到，如图：
若，针对不同的客户端使用不同的密钥
又会出现协商问题：由于没有公共的密钥了，服务端要给每个客户端发密钥，但协商过程是没有加密的，所以还会出现被截断的问题
非对称加解密
非对称：公钥和私钥的概念
那么问题就来了： 客户端如何拿到公钥？
方案：
- 服务器端把公钥发送给每一个客户端
- 服务器端把公钥放到远程服务器，客户端可以请求到
让浏览器保存所有的公钥（不现实）
结论： 公钥被调包的问题按照上面的方案，永远存在。
第三方机构与数字证书
这时候出现了通过第三方机构，使用第三方机构的私钥对我们需要传输的公钥进行加密。
数字证书是一个经证书授权中心数字签名的包含公开密钥拥有者信息以及公开密钥的文件。
数字证书里面包含的内容：
公司信息、网站信息、数字证书的算法、公钥
连接过程
如何查看公钥？浏览器有入口直接打开。
Charles也可以更改添加SSL
总体流程
客户端发起一个https请求
a) 客户端支持的加密方式
b) 客户端生成的随机数（第一个随机数）
服务端收到请求后，拿到随机数，返回
a) 证书（颁发机构（CA）、证书内容本身的数字签名（使用第三方机构的私钥加密）、证书持有者的公钥、证书签名用到的hash算法）
b) 生成一个随机数，返回给客户端（第二个随机数）
客户端拿到证书以后做验证
a) 根据颁发机构找到本地的跟证书
b) 根据CA得到根证书的公钥，通过公钥对数字签名解密，得到证书的内容摘要 A
c) 用证书提供的算法对证书内容进行摘要，得到摘要 B
d) 通过A和B的对比，也就是验证数字签名
验证通过以后，生成一个随机数（第三个随机数），通过证书内的公钥对这个随机数加密，发送给服务器端
（随机数1+2+3）通过对称加密得到一个密钥。（会话密钥）
通过会话密钥对内容进行对称加密传输
HTTPS的优点
1、SEO方面
谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”。
2、安全性
尽管HTTPS并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但HTTPS仍是现行架构下最安全的解决方案，主要有以下几个好处：
（1）使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
（2）HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
（3）HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
HTTPS的缺点
（1）SSL证书费用很高，以及其在服务器上的部署、更新维护非常繁琐
（2）HTTPS降低用户访问速度（多次握手）
（3）网站改用HTTPS以后，由HTTP跳转到HTTPS的方式增加了用户访问耗时（多数网站采用302跳转）
（4）HTTPS涉及到的安全算法会消耗CPU资源，需要增加大量机器（https访问)
（5）HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。
http与https的区别
HTTP的URL以 http://开头，而HTTPS的URL以https://开头。
HTTP是不安全的，而HTTPS是安全的。
HTTP标准端口是80 ，而HTTPS的标准端口是443。
在OSI网络模型中，HTTP工作于应用层，而HTTPS工作在传输层。
HTTP无需加密，而HTTPS对传输的数据进行加密。
HTTP无需证书，而HTTPS需要认证证书。
RESTful
REST ：表述性状态转移
RESTful是使用WEB标准来做一些准则和约束。
RESTful的基本概念：
在REST中，一切的内容都被认为是一种资源
每个资源都由URI唯一标识
使用统一的接口处理资源请求（POST/GET/PUT/DELETE/HEAD）
无状态
资源和URI
[/]表示资源的层级关系
？过滤资源
使用_或者-让URI的可读性更好
统一接口
GET 获取某个资源。 幂等
POST 创建一个新的资源
PUT 替换某个已有的资源（更新操作） ， 幂等
DELETE 删除某个资源
PATCH/HEAD 更新部分资源
资源表述
客户端通过HTTP获取资源
MIME 类型（）
accept: text/xml html文件
Content-Type告诉客户端资源的表述形式
资源链接
超媒体即应用状态引擎
状态转移
服务器端不应该保存客户端状态。
应用状态- >服务器端不保存应用状态
参考文献
感谢！
结束
此片完了~ 想要了解更多精彩新姿势？
请访问我的个人博客 本篇为原创内容，已在个人博客率先发表，随后CSDN，segmentfault，掘金，简书，开源中国同步发出。如有雷同，缘分呢兄弟。赶快加个好友~
