分布式通信协议-http（分布式笔记）

HTTP协议概述

1、客户端和服务器端

2、URI和URL
URI：web服务器资源的名字。 index.html
URL：http://www.gupaoedu.com:80/java/index.html[?query-string] #location
URL的组成：
schema: http/https/ftp.
host: web服务器的ip地址或者域名
port: 服务端端口， http默认访问的端口是80
path: 资源访问路径
query-string: 查询参数
3、方法
POST 增
DELETE 删
PUT 改
GET 查

报文

1、报文流
HTTP 报文是在HTTP 应用程序之间发送的数据块。这些数据块以一些文本形式的元信息（meta-information）开头，这些信息描述了报文的内容及含义，后面跟着可选的数据部分。这些报文在客户端、服务器和代理之间流动。HTTP 使用术语流入（inbound）和流出（outbound）来描述事务处理（transaction）的方向，不管是请求报文还是响应报文，所有报文都会向下游（downstream）流动。
2、报文组成
HTTP 报文的三个部分：

• 起始行：报文的第一行就是起始行，在请求报文中用来说明要做些什么，在响应报文中说明出现了什么情况。
• 首部字段：起始行后面有零个或多个首部字段。每个首部字段都包含一个键和一个值，为了便于解析，两者之间用冒号（:）来分隔。首部以一个空行结束。添加一个首部字段和添加键值对一样简单。
• 主体：空行之后就是可选的报文主体了，其中包含了所有类型的数据。请求主体中包括了要发送给Web 服务器的数据；响应主体中装载了要返回给客户端的数据。起始行和首部都是文本形式且都是结构化的，而主体则不同，主体中可以包含任意的二进制数据（比如图片、视频、音轨、软件程序）。当然，主体中也可以包含文本。
• MIME 类型是一种文本标记，表示一种主要的对象类型和一个特定的子类型，中间由一条斜杠来分隔。
• HTML 格式的文本文档由 text/html 类型来标记。
•普通的 ASCII 文本文档由 text/plain 类型来标记。
• JPEG 格式的图片为 image/jpeg 类型。
• GIF 格式的图片为 image/gif 类型。
• Apple 的 QuickTime 电影为 video/quicktime 类型。
•微软的 PowerPoint 演示文件为 application/vnd.ms-powerpoint 类型。
常见的MIME 类型有数百个，实验性或用途有限的MIME 类型则更多。

3、报文的语法
这是请求报文的格式：

<method> <request-URL> <version>
<headers>
<entity-body>

这是响应报文的格式（注意，只有起始行的语法有所不同）：

<version> <status> <reason-phrase>
<headers>
<entity-body>

4、起始行（start line）
请求起始行：请求报文请求服务器对资源进行一些操作。请求报文的起始行，或称为请求行，包含了一个方法和一个请求URL，这个方法描述了服务器应该执行的操作，请求URL描述了要对哪个资源执行这个方法。请求行中还包含HTTP 的版本，用来告知服务器，客户端使用的是哪种HTTP。所有这些字段都由空格符分隔。
例如：POST /infoNewsAction_uploadxheditorfile.action?immediate=1 HTTP/1.1
响应起始行：响应报文承载了状态信息和操作产生的所有结果数据，将其返回给客户端。响应报文的起始行，或称为响应行，包含了响应报文使用的HTTP 版本、数字状态码，以及描述操作状态的文本形式的原因短语。 所有这些字段都由空格符进行分隔。
例如：HTTP/1.1 200 OK
5、首部（header）
1.每个HTTP 首部都有一种简单的语法：名字后面跟着冒号（：），然后跟上可选的空格，再跟上字段值，最后是一个CRLF。（或者换行符）
常见的首部实例
首部实例 描述
Date:Tue,3Oct 1997 02:16:03 GMT 服务器产生响应的日期
Content-length:15040 实体的主体部分包含了15 040 字节的数据
Content-type:image/gif 实体的主体部分是一个GIF 图片
Accept: image/gif, image/jpeg, text/html 客户端可以接收GIF 图片和JPEG 图片以及HTML
2. 首部延续行，将长的首部行分为多行可以提高可读性，多出来的每行前面至少要有一个空格或制表符（tab）。
HTTP/1.0 200 OK
Content-Type: image/gif
Content-Length: 8572
Server: Test Server
Version 1.0

• 通用首部
这些是客户端和服务器都可以使用的通用首部。可以在客户端、服务器和其他应
用程序之间提供一些非常有用的通用功能。比如，Date 首部就是一个通用首部，
每一端都可以用它来说明构建报文的时间和日期：
Date: Tue, 3 Oct 1974 02:16:00 GMT
• 请求首部
从名字中就可以看出，请求首部是请求报文特有的。它们为服务器提供了一些额
外信息，比如客户端希望接收什么类型的数据。例如，下面的Accept 首部就用
来告知服务器客户端会接受与其请求相符的任意媒体类型：
Accept: */*
Accept首部

安全请求首部

• 响应首部
响应报文有自己的首部集，以便为客户端提供信息（比如，客户端在与哪种类型
的服务器进行交互）。例如，下列Server 首部就用来告知客户端它在与一个版
本1.0 的Tiki-Hut 服务器进行交互：
Server: Tiki-Hut/1.0
• 实体首部
实体首部指的是用于应对实体主体部分的首部。比如，可以用实体首部来说明实
体主体部分的数据类型。例如，可以通过下列Content-Type 首部告知应用程
序，数据是以iso-latin-1 字符集表示的HTML 文档：
Content-Type: text/html; charset=iso-latin-1
• 内容首部

• 扩展首部
扩展首部是非标准的首部，由应用程序开发者创建，但还未添加到已批准的
HTTP 规范中去。即使不知道这些扩展首部的含义，HTTP 程序也要接受它们并
对其进行转发。
6、方法
常见的http方法，常用到的方法是HEAD GET POST。

1.GET，通常用于请求服务器发送某个资源。

2.HEAD ，HEAD 方法与GET 方法的行为很类似，但服务器在响应中只返回首部。不会返回实体的主体部分。这就允许客户端在未获取实际资源的情况下，对资源的首部进行检查。
使用HEAD，可以：在不获取资源的情况下
• 了解资源的情况（比如，判断其类型）；
• 通过查看响应中的状态码，看看某个对象是否存在；
• 通过查看首部，测试资源是否被修改了。

3.post，通常用于向服务器提交数据。表单提交常常用到post。

状态码
100～199——信息性状态码
200～299——成功状态码
300～399——重定向状态码
400～499——客户端错误状态码
500～599——服务器错误状态码

前端缓存

前端缓存可分为两大类：http缓存和浏览器缓存，这里重点讲一下http缓存。

1、什么是HTTP缓存 ？
http缓存指的是: 当客户端向服务器请求资源时，会先抵达浏览器缓存，如果浏览器有“要请求资源”的副本，就可以直接从浏览器缓存中提取而不是从原始服务器中提取这个资源。
常见的http缓存只能缓存get请求响应的资源，对于其他类型的响应则无能为力，所以后续说的请求缓存都是指GET请求。
http缓存都是从第二次请求开始的。第一次请求资源时，服务器返回资源，并在respone header头中回传资源的缓存参数；第二次请求时，浏览器判断这些请求参数，命中强缓存就直接200，否则就把请求参数加到request header头中传给服务器，看是否命中协商缓存，命中则返回304，否则服务器会返回新的资源。
2、为什么要使用HTTP缓存 ？
根据上面的学习可发现使用缓存的好处主要有以下几点：

1. 减少了冗余的数据传输，节省了网费。
2. 缓解了服务器的压力， 大大提高了网站的性能
3. 加快了客户端加载网页的速度
   详细内容见：https://www.jianshu.com/p/227cee9c8d15

HTTPS协议的特点

HTTP 是一个属于应用层的面向对象的协议，HTTP 协议一共有五大特点：1、支持客户/服务器模式；2、简单快速；3、灵活；4、无连接；5、无状态。
1、无连接
无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。。采用这种方式可以节省传输时间。
早期这么做的原因是 HTTP 协议产生于互联网，因此服务器需要处理同时面向全世界数十万、上百万客户端的网页访问，但每个客户端（即浏览器）与服务器之间交换数据的间歇性较大（即传输具有突发性、瞬时性），并且网页浏览的联想性、发散性导致两次传送的数据关联性很低，大部分通道实际上会很空闲、无端占用资源。因此 HTTP 的设计者有意利用这种特点将协议设计为请求时建连接、请求完释放连接，以尽快将资源释放出来服务其他客户端。
随着时间的推移，网页变得越来越复杂，里面可能嵌入了很多图片，这时候每次访问图片都需要建立一次 TCP 连接就显得很低效。后来，Keep-Alive 被提出用来解决这效率低的问题。
Keep-Alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive 功能避免了建立或者重新建立连接。市场上的大部分 Web 服务器，包括 iPlanet、IIS 和 Apache，都支持 HTTP Keep-Alive。对于提供静态内容的网站来说，这个功能通常很有用。但是，对于负担较重的网站来说，这里存在另外一个问题：虽然为客户保留打开的连接有一定的好处，但它同样影响了性能，因为在处理暂停期间，本来可以释放的资源仍旧被占用。当Web服务器和应用服务器在同一台机器上运行时，Keep-Alive 功能对资源利用的影响尤其突出。
这样一来，客户端和服务器之间的 HTTP 连接就会被保持，不会断开（超过 Keep-Alive 规定的时间，意外断电等情况除外），当客户端发送另外一个请求时，就使用这条已经建立的连接。
2、无状态
无状态是指协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。即我们给服务器发送 HTTP 请求之后，服务器根据请求，会给我们发送数据过来，但是，发送完，不会记录任何信息。
HTTP 是一个无状态协议，这意味着每个请求都是独立的，Keep-Alive 没能改变这个结果。
缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
HTTP 协议这种特性有优点也有缺点，优点在于解放了服务器，每一次请求“点到为止”不会造成不必要连接占用，缺点在于每次请求会传输大量重复的内容信息。
客户端与服务器进行动态交互的 Web 应用程序出现之后，HTTP 无状态的特性严重阻碍了这些应用程序的实现，毕竟交互是需要承前启后的，简单的购物车程序也要知道用户到底在之前选择了什么商品。于是，两种用于保持 HTTP 连接状态的技术就应运而生了，一个是 Cookie，而另一个则是 Session。
Cookie可以保持登录信息到用户下次与服务器的会话，换句话说，下次访问同一网站时，用户会发现不必输入用户名和密码就已经登录了（当然，不排除用户手工删除Cookie）。而还有一些Cookie在用户退出会话的时候就被删除了，这样可以有效保护个人隐私。
Cookies 最典型的应用是判定注册用户是否已经登录网站，用户可能会得到提示，是否在下一次进入此网站时保留用户信息以便简化登录手续，这些都是 Cookies 的功用。另一个重要应用场合是“购物车”之类处理。用户可能会在一段时间内在同一家网站的不同页面中选择不同的商品，这些信息都会写入 Cookies，以便在最后付款时提取信息。
与 Cookie 相对的一个解决方案是 Session，它是通过服务器来保持状态的。当客户端访问服务器时，服务器根据需求设置 Session，将会话信息保存在服务器上，同时将标示 Session 的 SessionId 传递给客户端浏览器，浏览器将这个 SessionId 保存在内存中，我们称之为无过期时间的 Cookie。浏览器关闭后，这个 Cookie 就会被清掉，它不会存在于用户的 Cookie 临时文件。
以后浏览器每次请求都会额外加上这个参数值，服务器会根据这个 SessionId，就能取得客户端的数据信息。如果客户端浏览器意外关闭，服务器保存的 Session 数据不是立即释放，此时数据还会存在，只要我们知道那个 SessionId，就可以继续通过请求获得此 Session 的信息，因为此时后台的 Session 还存在，当然我们可以设置一个 Session 超时时间，一旦超过规定时间没有客户端请求时，服务器就会清除对应 SessionId 的 Session 信息。
HTTP协议的主要特点可概括如下：
1.支持客户/服务器模式。
2.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
3.灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type（Content-Type是HTTP包中用来表示内容类型的标识）加以标记。
4.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
5.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
6.基于TCP协议

HTTPS

HTTPS的工作原理（HTTP+ SSL/TLS）

第一步， 使用 对称加解密

第二步，密钥是公开的，所有的客户端都可以拿到

第三步 针对不同的客户端使用不同的密钥

存在的问题：协商过程是没有加密的，所以还会出现被截断的问题
第四步：使用非对称加密

问题： 客户端如何拿到公钥？
1、服务器端把公钥发送给每一个客户端
2、服务器端把公钥放到远程服务器，客户端可以请求到
3、让浏览器保存所有的公钥（不现实）
第五步 公钥被调包的问题按照上面的方案，永远存在

第六步：使用第三方机构来解决
通过第三方机构，使用第三方机构的私钥对我们【需要传输的公钥】进行加密
第七部分
数字证里面包含的内容：公司信息、网站信息、数字证书的算法、公钥
连接过程（crt指证书）

REST和RESTful

Representational State Transfer，表述性状态转移是一组架构约束条件和原则，需要注意的是，REST是设计风格而不是标准，使用REST风格设计的应用程序就是RESTful。REST通常基于使用HTTP，URI，和XML（标准通用标记语言下的一个子集）以及HTML（标准通用标记语言下的一个应用）这些现有的广泛流行的协议和标准。
用URL定位资源，用HTTP动词（GET,POST,DELETE,DETC）描述操作。REST，即表现层状态转移。在设计web接口的时候，REST主要是用于定义接口名，接口名一般是用名词写，不用动词，那怎么表达“获取”或者“删除”或者“更新”这样的操作呢——用请求类型来区分。比如，我们有一个friends接口，对于“朋友”我们有增删改查四种操作，怎么定义REST风格的接口？
增加一个朋友，uri: generalcode.cn/va/friends 接口类型：POST
删除一个朋友，uri: generalcode.cn/va/friends 接口类型：DELETE
修改一个朋友，uri: generalcode.cn/va/friends 接口类型：PUT
查找朋友， uri: generalcode.cn/va/friends 接口类型：GET
上面我们定义的四个接口就是符合REST协议的，请注意，这几个接口都没有动词，只有名词friends，都是通过Http请求的接口类型来判断是什么业务操作。举个反例：generalcode.cn/va/deleteFriends 该接口用来表示删除朋友，这就是不符合REST协议的接口。一般接口的返回值是JSON或者XML类型的，互联网项目一般都是JSON类型的。
用HTTP Status Code传递Server的状态信息。比如最常用的 200 表示成功，500 表示Server内部错误，403表示Bad Request等。（反例：传统web开发返回的状态码一律都是200，其实不可取。）那这种风格的接口有什么好处呢？前后端分离。前端拿到数据只负责展示和渲染，不对数据做任何处理。后端处理数据并以JSON格式传输出去，定义这样一套统一的接口，在web，ios，android三端都可以用相同的接口，是不是很爽？！

**RESTful 架构详解：**https://www.runoob.com/w3cnote/restful-architecture.html

资源和URI
1、[/]表示资源的层级关系
2、？过滤资源
3、使用_或者-让URI的可读性更好

统一接口
GET 获取某个资源
POST 创建一个新的资源
PUT 替换某个已有的资源（更新操作）
DELETE 删除某个资源