HTTP通信协议

HTTP简介

• HTTP协议是超文本传输​​协议的缩写，是用于从万维网（WWW：万维网）服务器传输超文本到本地浏览器的传送协议。

• HTTP是一个基于TCP / IP通信协议来传递数据（HTML文件，图片文件，查询结果等）。

• HTTP是一个属于应用层的面向对象的协议，由于其简捷，快速的方式，适用于分布式超媒体信息系统。它于1990年提出，经过几年的使用与发展，得到不断地完善和扩展。目前在WWW中使用的是HTTP / 1.0的第六版，HTTP / 1.1的规范化工作正在进行之中，而且HTTP-NG（下一代HTTP）的建议已经提出。

一次 HTTP 请求的通信流程

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

HTTP 通信协议的组成

HTTP之请求消息请求

客户端发送一个HTTP请求到服务器的请求消息包括以下格式：

请求行（request line）、请求头部（header）、请求数据三个部分组成。(当然有的版本是四个部分，多了个空行。就是在消息报头和响应正文中间有一个空行，因为这个空行是不能省略的，所以认为是由四个部分组成。)

第一部分：请求行，用来说明请求类型,要访问的资源以及所使用的HTTP版本.
第二部分：请求头部，紧接着请求行（即第一行）之后的部分，用来说明服务器要使用的附加信息
第三部分：请求数据也叫主体，可以添加任意的其他数据。

HTTP之响应消息Response

HTTP响应也由三个部分组成，分别是：状态行、消息报头、响应正文。(当然有的版本是四个部分，多了个空行。就是在消息报头和响应正文中间有一个空行，因为这个空行是不能省略的，所以认为是由四个部分组成。)

第一部分：状态行，（HTTP/1.1）表明HTTP版本为1.1版本，状态码为200，状态消息为（ok）
第二部分：消息报头，用来说明客户端要使用的一些附加信息
第三部分：响应正文，服务器返回给客户端的文本信息。

HTTP之状态码

状态代码有三位数字组成，第一个数字定义了响应的类别，共分五种类别:

码值	类别	原因
1xx	informational(信息型状态码值)	表示请求已接收，继续处理
2xx	success(成功)	表示请求已被成功接收、理解、接受
3xx	redirection(重定向)	要完成请求必须进行更进一步的操作
4xx	client error(客户端错误)	请求有语法错误或请求无法实现
5xx	server error(服务器端错误)	服务器未能实现合法的请求

常见码值：

200 OK                        //客户端请求成功
400 Bad Request               //客户端请求有语法错误，不能被服务器所理解
401 Unauthorized              //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用 
403 Forbidden                 //服务器收到请求，但是拒绝提供服务
404 Not Found                 //请求资源不存在，eg：输入了错误的URL
500 Internal Server Error     //服务器发生不可预期的错误
503 Server Unavailable        //服务器当前不能处理客户端的请求，一段时间后可能恢复正常

HTTP之请求方法

根据HTTP标准，HTTP请求可以使用多种请求方法。

• HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法。
• HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

类别	描述
GET	请求指定的页面信息，并返回实体主体。
HEAD	类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头
POST	向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
PUT	从客户端向服务器传送的数据取代指定的文档的内容。
DELETE	请求服务器删除指定的页面。
CONNECT	HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
OPTIONS	允许客户端查看服务器的性能。
TRACE	回显服务器收到的请求，主要用于测试或诊断。

HTTP之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
  表示客户端希望接受的数据类型， 即告诉服务器我需要什么媒体类型的数据，此时
  服务器应该根据 Accept 请求头生产指定媒体类型的数据
• Content-Type
  表 示 发 送 端 发 送 的 实 体 数 据 类 型 ， 比 如 我 们 应 该 写 过 类 似 的 ：
  resposne.setContentType(“application/json;charset=utf-8”)的代码，表示服务端返回的数据格式是 json。

Http 协议之扩展

http 协议除了基本组成以外，还有很多大家比较常见的属性或者配置。

传输的文件过大怎么办
服务器上返回的资源文件比较大，比如有些 js 文件大小可能就有几兆。文件过大就会影响传
输的效率，同时也会带来带宽的消耗。怎么办呢？

1. 常见的手段是，对文件进行压缩，减少文件大小。那压缩和解压缩的流程怎么实现呢？
   首先服务端需要能支持文件的压缩功能，其次浏览器能够针对被压缩的文件进行解压缩。浏览器可以指定 Accept-Encoding 来高速服务器，当前支持的编码类型Accept-Encoding:gzip,deflate那服务端会根据支持的编码类型，选择合适的类型进行压缩。常见的编码方式有：gzip/deflate
2. 分割传输
   在传输大容量数据时，通过把数据分割成多块，能够让浏览器逐步显示页面。这种把实体主体分块的功能称为分块传输编码（Chunked Transfer Coding）。

每次请求都要建立连接吗

在最早的 http 协议中，每进行一次 http 通信，就需要做一次 tcp 的连接。而一次连接需要进
行 3 次握手，这种通信方式会增加通信量的开销。

所以在 HTTP/1.1 中改用了持久连接，就是在一次连接建立之后，只要客户端或者服务端没有明确提出断开连接，那么这个 tcp 连接会一直保持连接状态，大大减少了连接的建立以及关闭时延。

HTTP1.1 中有一个 Transport 段。 会携带一个 Connection:Keep-Alive，表示希望将此条连接作为持久连接。HTTP/1.1 持久连接在默认情况下是激活的，除非特别指明，否则 HTTP/1.1 假定所有的连接都是持久的，要在事务处理结束之后将连接关闭， HTTP/1.1 应用程序必须向报文中显示地添加一个 Connection： close 首部。

##Http 协议的特点

Http 无状态协议

HTTP 协议是无状态的，什么是无状态呢？就是说 HTTP 协议本身不会对请求和响应之间的
通信状态做保存。

但是现在的应用都是有状态的，如果是无状态，那这些应用基本没人用，你想想，访问一个
电商网站，先登录，然后去选购商品，当点击一个商品加入购物车以后又提示你登录。这种
用户体验根本不会有人去使用。那我们是如何实现带状态的协议呢？

客户端支持的 cookie

Http 协议中引入了 cookie 技术，用来解决 http 协议无状态的问题。通过在请求和响应报文
中写入 Cookie 信息来控制客户端的状态； Cookie 会根据从服务器端发送的响应报文内的一
个叫做 Set-Cookie 的首部字段信息，通知客户端保存 Cookie。当下次客户端再往该服务器
发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。

服务端支持的 session

服务端是通过什么方式来保存状态的呢？ 在基于 tomcat 这类的 jsp/servlet 容器中，会提供
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） 安全层传输协议组合使用用于构造加密通道；Ssl 是 netscape 公司设计的（Secure sockets layer)， 后来互联网标准化组织 ISOC 接替了NETScape 公司，发布了 SSL 的升级版 TLS。接着 TLS 的版本又进行了多次升级； 实际上我们现在的 HTTPS 都是用的 TLS 协议，但是由于 SSL 出现的时间比较早，并且依旧被现在浏览器所支持，因此 SSL 依然是 HTTPS 的代名词。

Https 原理分析

HTTPS 证书的申请过程

1. 服务器上生成 CSR 文件（证书申请文件，内容包括证书公钥、使用的 Hash 签名算法、申
   请的域名、公司名称、职位等信息）；

2. 把 CSR 文件和其他可能的证件上传到 CA 认证机构， CA 机构收到证书申请之后，使用申请
   中的 Hash 算法，对部分内容进行摘要，然后使用 CA 机构自己的私钥对这段摘要信息进行
   签名（相当于证书的唯一编号）；

3. 然后 CA 机构把签名过的证书通过邮件形式发送到申请者手中；

4. 申请者收到证书之后部署到自己的 web 服务器中。

客户端请求交互流程

1. 客户端发起请求(Client Hello 包)
   a) 三次握手，建立 TCP 连接
   b) 支持的协议版本(TLS/SSL)
   c) 客户端生成的随机数 client.random，后续用于生成“对话密钥”
   d) 客户端支持的加密算法
   e) sessionid，用于保持同一个会话（如果客户端与服务器费尽周折建立了一个 HTTPS 链接，
   刚建完就断了，也太可惜）
2. 服务端收到请求，然后响应（Server Hello）
   a) 确认加密通道协议版本
   b) 服务端生成的随机数 server.random，后续用于生成“对话密钥”
   c) 确认使用的加密算法（用于后续的握手消息进行签名防止篡改）
   d) 服务器证书（CA 机构颁发给服务端的证书）
3. 客户端收到证书进行验证
   a) 验证证书是否是上级 CA 签发的, 在验证证书的时候，浏览器会调用系统的证书管理器
   接口对证书路径中的所有证书一级一级的进行验证，只有路径中所有的证书都是受信的，
   整个验证的结果才是受信
   b) 服务端返回的证书中会包含证书的有效期，可以通过失效日期来验证 证书是否过期
   c) 验证证书是否被吊销了
   d) 前面我们知道 CA 机构在签发证书的时候，都会使用自己的私钥对证书进行签名
   证书里的签名算法字段 sha256RSA 表示 CA 机构使用 sha256 对证书进行摘要，然后
   使用 RSA 算法对摘要进行私钥签名，而我们也知道 RSA 算法中，使用私钥签名之后，
   只有公钥才能进行验签。
   e) 浏览器使用内置在操作系统上的 CA 机构的公钥对服务器的证书进行验签。确定这个证
   书是不是由正规的机构颁发。验签之后得知 CA 机构使用 sha256 进行证书摘要，然后
   客户端再使用 sha256 对证书内容进行一次摘要，如果得到的值和服务端返回的证书验
   签之后的摘要相同，表示证书没有被修改过
   f) 验证通过后，就会显示绿色的安全字样
   g) 客户端生成随机数， 验证通过之后，客户端会生成一个随机数 pre-master secret， 客户
   端根据之前的： Client.random + sever.random + pre-master 生成对称密钥然后使用证书中的公钥进行加密， 同时利用前面协商好的 HASH 算法,把握手消息取 HASH 值，
   然后用 随机数加密 “握手消息+握手消息 HASH 值(签名)” 并一起发送给服务端 (在
   这里之所以要取握手消息的 HASH 值，主要是把握手消息做一个签名，用于验证握手
   消息在传输过程中没有被篡改过。 )
4. 服务端接收随机数
   a) 服务端收到客户端的加密数据以后，用自己的私钥对密文进行解密。然后得到
   client.random/server.random/pre-master secret, HASH 值，并与传过来的 HASH 值做
   对比确认是否一致。
   b) 然后用随机密码加密一段握手消息(握手消息+握手消息的 HASH 值 )给客户端
5. 客户端接收消息
   a) 客户端用随机数解密并计算握手消息的 HASH，如果与服务端发来的 HASH 一致，此
   时握手过程结束，
   b) 之 后 所 有 的 通 信 数 据 将 由 之 前 交 互 过 程 中 生 成 的 pre master secret /
   client.random/server.random 通过算法得出 session Key，作为后续交互过程中的对称
   密钥

GET和POST请求的区别

主要有四个地方的区别：

1. 请求方式。

   GET提交：请求的数据会附在URL之后（就是把数据放置在HTTP协议头中），以?分割URL和传输数据，多个参数用&连接；例 如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。如果数据是英文字母/数字，原样发送，如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如： %E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII。

   POST提交：把提交的数据放置在是HTTP包的包体中。上文示例中红色字体标明的就是实际的传输数据
   因此，GET提交的数据会在地址栏中显示出来，而POST提交，地址栏不会改变

2. 传输数据的大小。首先声明：HTTP协议没有对传输的数据大小进行限制，HTTP协议规范也没有对URL长度进行限制。
   而在实际开发中存在的限制主要有：
   GET：特定浏览器和服务器对URL长度有限制，例如 IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系 统的支持。因此对于GET提交时，传输数据就会受到URL长度的 限制。
   POST：由于不是通过URL传值，理论上数据不受限。但实际各个WEB服务器会规定对post提交数据大小进行限制，Apache、IIS6都有各自的配置。

3. 安全性。POST的安全性要比GET的安全性高。比如：通过GET提交数据，用户名和密码将明文出现在URL上，因为(1)登录页面有可能被浏览器缓存；(2)其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码了，除此之外，使用GET提交数据还可能会造成Cross-site request forgery攻击。

4. Http get,post,soap协议都是在http上运行的。

   1. get：请求参数是作为一个key/value对的序列（查询字符串）附加到URL上的查询字符串的长度受到web浏览器和web服务器的限制（如IE最多支持2048个字符），不适合传输大型数据集同时，它很不安全。
   2. post：请求参数是在http标题的一个不同部分（名为entity body）传输的，这一部分用来传输表单信息，因此必须将Content-type设置为:application/x-www-form- urlencoded。post设计用来支持web窗体上的用户字段，其参数也是作为key/value对传输。
      但是：它不支持复杂数据类型，因为post没有定义传输数据结构的语义和规则。
   3. soap：是http post的一个专用版本，遵循一种特殊的xml消息格式Content-type设置为: text/xml 任何数据都可以xml化。