分布式架构的基础-HTTP协议

HTTP协议简介

HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写,是用于从万维网服务器传输超文本到本地浏览器的传送协议。。

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

客户端和服务端的请求原理

我们在请求服务器资源时，会通过几层通信，分别是应用层、传输层、网络层、数据链路层。每层使用的协议HTTP（FTP等）协议、TCP（UDP）协议、IP协议，而HTTP协议是基于TCP协议的基础上进行通信，确保了通信的有效性(分布式架构的基础-TCP通信协议)，也是日常生活中使用广泛的一种协议。

客户端和服务端的请求原理.jpg

HTTP协议的组成

既然HTTP是一种协议，那必然是制定了一些约束组成，我们通过抓取一次请求www.csdn.net。
获取到客户端的请求信息，服务端的响应信息，抓包教程。

客户端的请求信息

POST https://re.csdn.net/csdnbi HTTP/1.1

Host: re.csdn.net
Connection: keep-alive
Content-Length: 167
Accept: /
Origin: https://www.csdn.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.23 Safari/537.36
Content-Type: text/plain;charset=UTF-8
Referer: https://www.csdn.net/
Accept-Encoding: gzip, deflate, br Accept-Language: zh-CN,zh;q=0.9
Cookie: uuid_tt_dd=10_19119862890-1514946902631- 786149; __utma=17226283.1502834598.1514952032.1514952032. 1514952032.1; _utmz=17226283.1514952032.1.1.utmcsr=(direct)|ut mccn=(direct)|utmcmd=(none); kd_user_id=accb9177- 52d8-41f3-b69e-54bb338ffb23; UN=q331464542; UM_distinctid=1610314af5bb3a-012f62bad56aa5- 71103742-1fa400-1610314af5ca34; Hm_ct_6bcd52f51e9b3dce32bec4a3997715ac=17881PC VC; BT=1523867282719; smidV2=20180517165125ad3024b867497a0fbd79f81ef81c dd4400ceee13dc5e27d30; dc_session_id=10_1527227855207.688716; Hm_lvt_6bcd52f51e9b3dce32bec4a3997715ac=152741308 2,1527413263,1527413731,1527415074; Hm_lpvt_6bcd52f51e9b3dce32bec4a3997715ac=15274229 24; dc_tos=p9dz2k

[{"headers":{"component":"enterprise","datatype": "re","version":"v1"},"body":"{"re":"ref=- &mtp=4&mod=ad_popu_131&con=ad_content_2961%2Cad_o rder_731&uid=-&ck=-"}"}]

请求信息可以分为三部分，分别是：

请求方法/URL协议/版本
- POST https://re.csdn.net/csdnbi HTTP/1.1
  表明使用POST请求，https://re.csdn.net/csdnbi地址，通过协议的版本号1.1
  请求方法汇总地址
请求头
- 请求头包含许多有关的客户端环境和请求正文的有用信息。
  例如，请求头可以声明浏览器所用的语言，请求正文的长度等
  常用的HTTP请求头与响应头
请求正文
- 请求头和请求正文之间是一个空行，这个空行非常重要，它表示请求头已经结束，接下来的是请求正文。
  请求正文中可以包含客户提交的查询字符串信息

www.csdn.net响应信息

HTTP/1.1 200 OK

Server: openresty
Date: Sun, 27 May 2018 12:08:44 GMT Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=20 Access-Control-Allow-Origin: https://www.csdn.net Access-Control-Allow-Methods: GET, POST, OPTIONS Access-Control-Allow-Credentials: true Access-Control-Allow-Headers: DNT,X- CustomHeader,Keep-Alive,User-Agent,X-Requested- With,If-Modified-Since,Cache-Control,Content- Type,body

2
ok
0

响应信息可以也分为三部分，分别是：

状态行
- HTTP/1.1 200 OK
  由协议版本、数字形式的状态代码、及相应的状态描述，各元素之间以空格分隔
  HTTP状态码汇总
响应头
- 与请求头类似，记录一些有用信息。常用的HTTP请求头与响应头
响应正文
- 响应头和响应正文之间是一个空行，这个空行非常重要，它表示响应头已经结束，接下来的是响应正文。
  响应正文中可以包含服务端返回的查询信息

URL和URI有什么区别？

URL(Uniform Resource Locator) 地址用于描述一个网络上的资源，基本格式例如: http://www.gupaoedu.com:80/java/index.html?name=mic#head
模版：schema://host[:port#]/path/.../?[url-params]#[ query-string]
schema：指定应用层使用的协议(例如:http, https, ftp)
host：HTTP 服务器的 IP 地址或者域名
port：HTTP 服务器的默认端口是80，这种情况下端口号可以省略。如果使用了别的端口，必须指明例如:http://www.gupaoedu.com:8080
path：访问资源的路径
query-string：查询字符串

URI(Uniform Resource Identifier)
每个 web 服务器资源都有一个名字，这样客户端就可以根据这个名字来找到对应的资源，这个资源称之为(统一资源标识符)

URI是用一个字符串来表示互联网上的某一个资源。而URL表示资源的地点(互联网所在的位置)

HTTP协议的特点

1. HTTP协议是无状态的

什么是无状态呢? 就是说 HTTP 协议本身不会对请求和响应之间的通信状态做保存。
如用户登录后，再请求购物车，我们的服务器是无法知道用户是否已经登录的。两次请求是毫无关系的

2. 如何实现有状态的协议？

HTTP 协议中引入了 cookie 技术，用来解决 HTTP 协议无状态的问题。通过在请求和响应报文中写入Cookie 信息来控制客户端的状态;
Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的首部字段信息，通知客户端保存Cookie。
当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。
在基于 tomcat 这类的 jsp/servlet 容器中，会提供 session 这样的机制来保存服务端的对象状态。

Cookie 与 Session的区别
一、cookie：
在网站中，http请求是无状态的。也就是说即使第一次和服务器连接后并且登录成功后，第二次请求服务器依然不能知道当前请求是哪个用户。cookie的出现就是为了解决这个问题，第一次登录后服务器返回一些数据（cookie）给浏览器，然后浏览器保存在本地，当该用户发送第二次请求的时候，就会自动的把上次请求存储的cookie数据自动的携带给服务器，服务器通过浏览器携带的数据就能判断当前用户是哪个了。cookie存储的数据量有限，不同的浏览器有不同的存储大小，但一般不超过4KB。因此使用cookie只能存储一些小量的数据。

二、session:
session和cookie的作用有点类似，都是为了存储用户相关的信息。不同的是，cookie是存储在本地浏览器，而session存储在服务器。存储在服务器的数据会更加的安全，不容易被窃取。但存储在服务器也有一定的弊端，就是会占用服务器的资源，但现在服务器已经发展至今，一些session信息还是绰绰有余的。

三、cookie和session结合使用：
web开发发展至今，cookie和session的使用已经出现了一些非常成熟的方案。在如今的市场或者企业里，一般有两种存储方式：

1、存储在服务端：通过cookie存储一个session_id，然后具体的数据则是保存在session中。如果用户已经登录，则服务器会在cookie中保存一个session_id，下次再次请求的时候，会把该session_id携带上来，服务器根据session_id在session库中获取用户的session数据。就能知道该用户到底是谁，以及之前保存的一些状态信息。这种专业术语叫做server side session。

2、将session数据加密，然后存储在cookie中。这种专业术语叫做client side session。flask采用的就是这种方式，但是也可以替换成其他形式。

3. HTTP 协议的缺陷

通信使用明文可能会被窃取
- HTTP本身不具备加密的功能，无法做到对通信整体进行加密。
  - 按TCP/IP协议族的工作机制，通信内容在所有的通信线路（即互联网）上都有可能遭到窥视。
  - 通信即使加密，也会被窥视到，只不过窥视到的是密文。
  - 窃听相同段上的通信非常简单。只需要收集流动在互联网上的数据包（帧）就可以了。解析这些包的工作，可以交给抓包（Packet Capture）或嗅探器（Sniffer）工具；
不验证通信双方的身份
- HTTP协议中的请求和响应不会对通信方进行确认。
  - 也就是说"服务器是否就是发送请求中URI真正指定的主机，返回的响应是否真的返回到实际提出请求的客户端"等问题。
- 任何人都可发起请求
  - HTTP协议通信不存在确认通信方的处理步骤，任何人都可以发送请求；
  - 服务器只接收到请求，不管对方是谁都会返回一个响应（前提：仅限于发送端的IP地址和端口号没有被Web服务器设定限制访问的前提下），这样会存在以下隐患：
    - 无法确定请求发送至目标的Web服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的Web服务器；
    - 无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端；
    - 无法确定正在通信的对方是否具备访问权限；
    - 无法判定请求是来在何方，出自谁手；
    - 即使是无意义的请求也会照单全收。无法阻止海量请求下的Dos攻击（拒绝服务攻击）；
- 查明对手的证书
  - 虽然HTTP协议无法确定通信方，但SSL可以。SSL不仅提供加密处理，而且还使用了一种被称为证书的手段，应用于确定方；
    - 证书由信赖的第三方机构颁发，用以证明服务器和客户端是实际存在的；
    - 伪造证书从技术角度来看是及其困难的；
无法验证报文的完整性，报文可能被篡改
- 完整性是指信息的准确度。如果无法证明其完整性，通常也就意味着无法判断信息是否准确；
- 接收到的内容可能有误
  - HTTP协议无法证明通信的报文完整性，在请求或响应送出之后直到对方接收之前的这段时间内，如果请求或响应遭到篡改，是没有办法获悉的；
- 如何防止篡改
  - 确定报文完整性常用的方法是MD5和SHA-1等散列值校验的方法，以及确认文件数字签名的方法；
  - 提供文件下载服务的Web网站也会提供相应的以PGP创建的数字签名及MD5算法生成的散列值；
    - PGP是用来证明创建文件的数据签名；
    - MD5是单向函数生成的散列值；
    - 这两种方式，都需要操作客户端的用户本人亲自检查，浏览器无法参与；
    - 但是，如果PGP和MD5本身被改写的话，用户是没有办法意识到的；

HTTP的缺点文章引用

SSL提供认证和加密处理及摘要功能；仅靠HTTP自身确保安全性非常困难，应与其他协议组合达成目标
综上，有必要使用HTTPS。