分布式学习笔记（三）——HTTP和HTTPS协议

HTTP协议

HTTP通信协议的基本原理

DNS: （Domain Name System）服务是和 HTTP 协议一样位于应用层的协议。它提供域名到 IP 地址之间的解析服务, 用户通常使用主机名或域名来访问对方的计算机，而不是直接通过 IP 地址访问。DNS 协议提供通过域名查找 IP 地址，或逆向从IP 地址反查域名的服务。

URL (Uniform Resource Locator)统一资源定位符

通过在浏览器中输入一个地址，可以找到对应的网络资源，这个地址就是URL，用于于描述一个网络上的资源，具体格式如下：

schema://host[:port#]/path/.../?[url-params]#[ query-string]
scheme： 指定应用层使用的协议(例如：http, https, ftp)
host： HTTP 服务器的 IP 地址或者域名
port#： HTTP 服务器的默认端口是 80，这种情况下端口号可以省略。如果使用了别的端口，必须指明，例如 http://www.cnblogs.com:8080/
path： 访问资源的路径
query：-string 查询字符串
#： 片段标识符（使用片段标识符通常可标记出已获取资源中的子资源（文档内的某个位置））

MIME Type

服务器根据用户请求的资源找到对应的文件以后，会返回一个资源给到客户端浏览器，浏览器会对这个资源解析并且渲染。但是服务器上的资源类型有很多，比如图片类型、视频类型、Js、Css、文本等。而·MIME Type：是描述消息内容类型的因特网标准，常见的几种类型：
文本文件：text/html,text/plain,text/css,application/xhtml+xml,application/xml
图片文件：image/jpeg,image/gif,image/png.
视频文件：video/mpeg,video/quicktime
可以通过两种方式来设置文件的渲染类型，第一种是 Accept，第二种是 Content-TypeAccept: 表示客户端希望接受的数据类型，即告诉服务器我需要什么媒体类型的数据，此时服务器应该根据 Accept 请求头生产指定媒体类型的数据Content-Type: 表示发送端发送的实体数据类型，例如：resposne.setContentType(“application/json;charset=utf-8”)，表示服务端返回的数据格式是 json。如果 Accept 和 Content-Type 不一致，假如说 Accept 要接收的类型是 image/gif，但是服务端返回的数据text/html，那么浏览器将会无法解析。

状态码

状态码的职责是当客户端向服务端发送请求时，描述服务端返回的请求处理结果，通过状态码，浏览器可以知道服务器是正常处理请求还是出现了错误。比较常见的有200（正常）、301（永久重定向）、404（请求资源不存在）、500（服务端内部错误）。

请求方式

浏览器定义了 8 种方法来表示对于不同请求的操作方式：
GET：一般是用于客户端发送一个 URI 地址去获取服务端的资源（一般用于查询操作），Get不支持的传输数据有限制，具体限制由浏览器决定
POST：一般用户客户端传输一个实体给到服务端，让服务端去保存（一般用于创建操作）
PUT：向服务器发送数据，一般用于更新数据的操作
DELETE：客户端发起一个 Delete 请求要求服务端把某个数据删除（一般用于删除操作）
HEAD:获得报文首部
OPTIONS：询问支持的方法
TRACE：追踪路径
CONNECT：用隧道协议连接代理

HTTP协议报文格式

请求报文：

响应报文：

HTTP协议扩展

http基于tcp协议，每次连接需要进行三次握手，但是这样会增加开销，所以在 HTTP/1.1 中改用了持久连接，就是在一次连接建立之后，只要客户端或者服务端没有明确提出断开连接，那么这个 tcp 连接会一直保持连接状态。HTTP1.1 中有一个 Transport 段。会携带一个 Connection:Keep-Alive，表示希望将此条连接作为持久连接。在默认情况下是激活的，除非特别指明，否则 HTTP/1.1 假定所有的连接都是持久的，要在事务处理结束之后将连接关闭，HTTP/1.1 应用程序必须向报文中显示地添加一个 Connection：close 首部。
管道化连接: http/1.1 允许在持久连接上使用请求管道。以前发送请求后需等待并收到响应，才能发送下一个请求。管线化技术出现后，不用等待响应亦可直接发送下一个请求。这样就能够做到同时并行发送多个请求，而不需要一个接一个地等待响应了。

cookie和session

HTTP协议是无状态的，因为HTTP 协议本身不会对请求和响应之间的通信状态做保存。所以HTTP引入了cookie和session。
cookie：通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态；Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的首部字段信息，通知客户端保存 Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。
session：session保存在服务器上，当程序需要为某个客户端的请求创建一个 session 的时候，服务器首先检查这个客户端的请求是否包含了一个 session 标识- session id；如果已包含一个 session id 则说明以前已经为客户端创建过 session，服务器就按照 session id 把这个 session 检索出来使用（如果检索不到，会新建一个）。如果客户端请求不包含 sessionid，则为此客户端创建一个 session 并且生成一个与此 session相关联的 session id， session id 的值是一个既不会重复，又不容易被找到规律的仿造字符串，这个 session id 将会返回给客户端保存。

HTTPS协议

由于 HTTP 协议在通信过程中，是基于明文通信，并且底层是基于 TCP/IP 协议进行通信，那么按照 TCP/IP 协议族的工作机制，通信内容在所有的通信线路上都有可能遭到拦截和窃取。窃取这个过程其实很简单，通过抓包工具 Wireshark 就可以截获请求和响应的内容。由于 HTTP 协议通信的不安全性，所以人们为了防止信息在传输过程中遭到泄漏或者篡改，就想出来对传输通道进行加密的方式 https。

https 是一种加密的超文本传输协议，它与 HTTP 在协议差异在于对数据传输的过程中，https对数据做了完全加密，由于 http 协议或者 https 协议都是处于 TCP 传输层之上，同时网络协议又是一个分层的结构，所以在 tcp 协议层之上增加了一层 SSL（Secure Socket Layer，安全层）或者 TLS（Transport Layer Security） 安全层传输协议组合使用用于构造加密通道；

加密算法

对称加密

对称加密算法是通过一个秘钥将需要传输的信息加密成密文，接收方通过秘钥再解密得到信息。

非对称加密

非对称加密算法是维护一对公钥和私钥，通过公钥加密，私钥解密的方式来进行加密传输。或者私钥签名，公钥验签来进行数字签名。

CA和数字证书

即使使用非对称加密算法，信息在传输过程中，依然有被劫持和篡改的可能。所以https引入了第三方机构CA (Certificate Authority)证书中心来颁布数字证书，保证数据安全。