目录
HTTP协议
一、概念
二、http协议格式
http请求报文
http响应报文
URL格式
三、认识方法
四、认识报头
HTTP响应中的信息
HTTPS协议
对称加密
非对称加密
中间人攻击
解决中间人攻击
HTTP协议
一、概念
HTTP (全称为 "超⽂本传输协议") 是⼀种应⽤⾮常⼴泛的应⽤层协议，诞生于1991年，现在已经发展成为最主流使用的一种应用层协议。HTTP往往是基于传输层的TCP协议实现的，平时打开网页就是通过http协议来传输数据，当我们在浏览器中输⼊⼀个 搜狗搜索的 "⽹址" (URL) 时, 浏览器就给搜狗的服务器发送了⼀个 HTTP请求, 搜狗的服务器返回了⼀个 HTTP 响应 
理解http协议的工作过程：
但实际在我们在访问时会涉及很多个请求/响应。
二、http协议格式
想要进一步了解http的工作过程以及http的报文格式就需要用到抓包工具（能够把网络上传输的http数据捕捉获取到并且显示出来），抓包工具相当于一个代理程序。
代理可以分为两种角色：（1）帮客户端跑腿的：正向代理 (2)帮服务器跑腿的：反向代理。
这里我们使用Fiddler来作为我们的抓包工具作为演示（Fiddler下载教程已出）。
http是一个文本协议，本质上http数据包就是按照上述http协议的格式将数据写入到tcp socket中。
http请求报文
分为四部分
（1）首行，包含三部分：（a）请求的方法，例如GET，表示请求的目的，GET是要从服务器获取数据 （b）请求的URL（对方的地址） （c）版本号。我们可以在浏览器上输入baidu.com来抓取后得到，分别用红绿蓝代表abc
（2）请求头（Header）：此处本质上使用键值对（key-value）来表示，请求头可以是若干行，每一行本质上是一个键值对，键与值之间用：作为分割， 最后用空行代表结束 。
（3）空行：Header结尾处有一个空行作为结束，类似链表的null
（4）正文（body）：可选的，可以有也可以没有，可以存放任何你想要存放的数据
http响应报文
也分为四部分
（1）首行
，HTTP/1.1为版本号，200为状态码，OK为状态码描述，这样的首行代表是一个成功的响应，失败的响应会显示404not found（响应的几种状态在后面介绍）
（2）响应头（Header），与请求的一样不限制行数，以空行作为结束
（3）空行：可以看到在Header中的最后一行有一个Content-Length代表了响应头的行数，可以 通过行数来找到空行，避免了粘包问题
（4）正文：正文中存什么都可以，空行也可以存，只有http数据包中的第一行才作为Header的结尾。
URL格式
URL的详细标准由因特网RFC1783来规定
协议方案名：描述了我们的URL接下来要干啥，例如我们在使用java操作数据库时输入的jdbc：mysql：//
登录信息：是上古时期登录方式
服务器地址：要访问的服务器是哪个， 域名/IP地址
服务器端口号：url中的端口号可以不写，浏览器会自动设置一个端口号，这个端口是服务器的端口，http协议就是80，https协议就是443
带层次的文件路径：描述了要访问服务器的哪个资源，一个服务器会提供很多资源给外界访问，比如一个网站会有很多不同的网页，这样就可以通过文件路径区分不同的网页。
查询字符串：就是一些参数，通过这些参数将客户端想告知服务器的参数传递过去；例如当我们在浏览器搜索URL格式，
，就会出现q = URL格式的字样，这就是查询字符串。
当我们使用Fiddler进行抓取时可以得到URL是这样的
也可以看作是键值对结构，键值对之间用&分开，键与值之间用=分割，这些键值对都是由程序员自己规定的含义。
可以看到在我们的q = URL后面存在一些用百分号进行分割的字符，这些其实utf8进行将汉字编码的结果，我们输入的是URL格式，我们在编码转换器中输入汉字格式就可以从得到的结果中发现与这里的是一致的
浏览器为了让客户看起来更方便，在浏览器中使用的是转码前，实际发送的是转码后。
汉字通常使用utf8进行转码，对于符号需要用到urlencode进行转码，如果直接进行转码可能会导致汉字的某个字节与符号的产生冲突导致解析错误，需要转码的字符会显示出这个字符原始的十六进制编码，在这个基础上加上%。
构造http请求一定要把需要转码的部分进行url encode，不进行urlencode可能会造成跳转失败。
片段标识符：区分页面中不同的目录，像是我们在csdn博客中的目录功能，点击一个目录可以直接跳转到该目录所在的界面。
三、认识方法
虽然方法有这么多， 但常用的只有GET和POST，GET语义上是从服务器获取数据，POST语义是往服务器发送/提交数据，在实际开发中这两个方法的界限越来越模糊，get可以用来提交并且post也可以用来获取；GET通常不会使用body而是用query string来传输数据，POST通常不搭配query string而是body来传输数据（这是使用习惯上的差别，但GET和POST都是有query string和body的）。
网络上大部分请求都是GET，通过query string告诉服务器要搜啥，服务器返回搜索结果完整网页。POST的使用场景少一些，通常是这些场景：
（1）登录 （2）上传文件
上述http请求是如何构造的？
GET请求：（1）在浏览器地址栏直接输入url，此时就是GET请求；（2）网页html中可能会有一些特殊的标签，这些标签会带有一个url作为属性，页面被浏览器加载后解析到这些标签就会根据url构造出新的http请求；（3）表单，html中特殊的标签form；（4）通过js构造。
POST请求：（1）表单 （2）js。
小结：GET和POST的区别
（1）从本质上讲，GET和POST没有区别，GET能做的POST也能做，POST能做的GET也能做。
（2）从语义上来讲，GET用来获取数据，POST用来发送数据
（3）从传递数据来讲，GET用query string，POST用body
（4）从响应结果幂等来讲，对于GET请求的设计通常是幂等的，而POST的设计则不要求幂等。
（5）GET请求的结果可以被缓存，可以被浏览器收藏，而POST一般不可以。
四、认识报头
1、Host：请求对应的主机的端口和ip；（ 通常情况下和url中的服务器地址是一样的）
2、Content—Length：body的长度， 一旦有body就要知道body的长度才能知道一个完整的http请求， 此处涉及到http机制对于粘包问题的解决：（1）分隔符，GET请求没有body就通过空行 （2）POST请求有body，通过空行找到body的开始，通过Content—Length找到body的结尾
3、Content—Type：body的类型， 通过http协议传输的数据类型有很多种类，例如：图片/视频/音频等等，这些不同的数据浏览器有不同的处理方式。
4、User—Agent（UA）：主要信息包含两个， 浏览器版本/操作系统版本， 描述了用户使用什么样的设备打开你的网页。
UA的主要作用是用来实现兼容，在互联网发展的早期浏览器只能显示文字，后来发展出可以显示图片/视频/音频等不同功能的浏览器，UA就可以告诉服务器此时用户用的是可以显示什么画面的浏览器进而提供服务；而现在UA的主要功能是来区分手机端和电脑端，如果是电脑返回一个宽屏网页，如果是手机返回一个窄屏的网页。
5、Referer：表示当前页面从哪个网页跳转过来，如果是直接在地址栏输入url或者点击收藏栏中的网页此时Referer处为空。
6、Cookie：
cookie也是键值对格式的内容，和query string相似都是程序员自己定义的，每个网站都有自己的cookie，它的具体含义只有写这个的程序员自己知道；
cookie这里的键值对本质上都是能够在客户端硬盘持久保存的：网页是运行在浏览器上的，默认情况下网页是不能直接访问硬盘的，但有些情况下有的网站确实需要在客户端硬盘持久的保存一些必要信息，浏览器就给网页提供了特定的机制——Cookie，cookie机制不是让网页随意访问硬盘，网页对于硬盘是没法直接读写的，浏览器对于硬盘操作做了特殊的封装，相当于提供了一组特殊文件，只能往这个文件中读写，并且写的内容也要求是键值对。 不同网站的cookie独立存储互不影响。
Cookie从哪里来？
cookie中的数据来自于服务器，如果你的浏览器第一次访问某网站，那么此时你浏览器对应的cookie是空着的，网站的服务器就会返回一些http响应，响应中会包含set-Cookie这样的Header，就会把一些键值对保存到对应的cookie中；
当cookie保存到服务器后，后续浏览器访问该网站时就会把在请求Header中将对应的键值对都带入进去再返回给服务器。
小结：
Cookie是什么？
浏览器本地存储持久化数据的典型机制。
Cookie怎么存的？
按照不同的域名分别存储在硬盘上，不同域名之间的cookie互不干扰。
Cookie从哪里来？
从服务器来，如果浏览器第一次访问网站，服务器的响应Header中会带有set-Cookie字段
Cookie到哪里去？
在后续的请求中，请求的Header中带有cookie字段将信息传输给服务器。
Cookie的作用？
（1）存储用户偏好设置：通过使用Cookie网站可以记住用户的偏好设置，比如语言偏好/主题选择等；
（2）实现用户认证：在需要用户登录的网站中，Cookie可以用来保持用户的登录状态，服务器在用户登陆成功后创建一个包含用户身份信息的Cookie发送给浏览器，访问这个网站的其他网页时就可以实现自动登录。
Cookie的典型应用场景：保存会话id
HTTP响应中的信息
状态码
描述这次请求是否成功以及失败原因，在此介绍一些常见的：
（1）200-OK：本次访问成功
（2）404-NOT FOUND：客户端访问的请求在服务器不存在
（3）403-Forbidden：客户端权限不足无法访问
（4）405-Method Not Allowed：请求中的方法服务器不支持
（5）500-Internal Server Error：服务器内部错误（出现bug了）
（6）504-Gateway Timeout：服务器访问超时（问题常出现于服务器访问比较繁忙的时候）
（7）302-Move Temporarily：临时重定向（访问某个服务器时访问的是旧地址，自动跳转到新地址），302响应中的Header会有Location字段显示接下来要跳转到哪个网站
（8）301-Move Permanently：永久重定向（访问的旧地址和新地址之间的映射关系固定了，此时浏览器会缓存这样的结果），后续浏览器在访问时就可以直接构造新地址的请求，减少一次http访问
HTTPS协议
HTTPS协议本质上就是HTTP协议加了一个加密层，抛开加密层别的部分都是一样的。
HTTPS引入的背景是“运营商劫持事件”
给HTTP加密的过程涉及到几个密码学的概念：
明文：要传输的真正含义是什么
密文：加密之后得到的数据
密钥：用来加密和解密的重要道具
加密：明文通过密钥变成密文的过程
解密：密文通过密钥变成明文的过程
对称加密：加密和解密的密钥是同一个
非对称加密：密钥是一对（公钥&私钥），加密解密的时间变长，安全性更高；如果使用公钥加密那么就使用私钥解密，反之亦然。
对称加密
HTTP本身是一个不安全的协议，让它变成安全的协议最简单的做法可以使用对称加密来操作
这样就成功防止了黑客在中间劫持数据，但有个问题：对称密钥在有多个客户端时不能所有客户端使用同一个密钥，不然黑客的客户端不就也持有这个对称密钥了，所以应该每个客户端生成一个密钥再将这个密钥告诉服务器。
此时如果使用明文传输密钥那么黑客在中间也可以拿到密钥，使用对称加密传输这个密钥的话也需要先告诉服务器新的私钥是什么，事情陷入了死循环，此时就需要引入非对称加密来对我们的密钥进行加密。
引入非对称加密不是对后续传输的内容进行加密的（非对称加密的系统开销比对称加密大的多，所以不适合对业务数据进行加密），只是对对称密钥进行加密。
非对称加密
服务器生成公钥和私钥，当客户端连上服务器，服务器会将公钥发给每个客户端，而私钥只有服务器自己持有；
接下来客户端自己生成对称密钥，将对称密钥使用服务器公钥进行加密，再将带有对称密钥的密文发送给服务器
黑客此时只能拿到被公钥加密的对称密钥数据，公钥需要私钥来解密，黑客是无法对数据进行解密的。
上述场景是非对称加密的思路，实际黑客还是有办法获取到原始数据的。
中间人攻击
黑客冒充服务器伪造一些看似正确的信息
关键环节：黑客自己生成一对公钥和私钥，拿着私钥针对刚才传输给客户端的公钥进行解密，从这里拿到客户端的对称密钥，继续把对称密钥用服务器的公钥进行加密并传输给服务器。
此时黑客面对客户端是服务器的角色，面对服务器是客户端的角色，双方都不知道黑客的存在，对称密钥已经泄露意味着后续的数据都会泄露。
解决中间人攻击
关键在于让客户端辨别出当前公钥是否是服务器的公钥，引入第三方认证机构，公证机构会对公钥进行公正，客户端看到这个公钥被公正了就可以知道是合法的了。
客户端和服务器建立连接后客户端会先收到服务器的公正证书，证书中会包含发证机构/证书有效期/服务器公钥/证书的所有者/持有者的网路主域名/数字签名这些字段，通过这些字段计算出校验和1；
接下来客户端开始针对数字签名进行解密，数字签名是公证机构拿着私钥进行加密的，进行解密就需要公证机构的公钥来解密，这个公钥如果在网络上传播肯定是有风险的，所以这些公证机构的公钥都会内置在操作系统中，这样就可以拿着系统内置的公钥来对数字签名解密得到校验和2；
比较校验和1和校验和2，如果相等就说明整个证书没有被篡改过，此时证书既然是有效的，那么里面的公钥自然也是可信的服务器公钥。
对于黑客来说针对公证机构的数字签名进行解密是很容易的（黑客系统也可以内置公钥），但黑客如果修改了公钥但是不修改数字签名，此时客户端进行校验时就会发现校验和不一致，会标记为不信任网站；如果黑客修改了公钥并且自己重新计算校验和，重新加密得到数字签名，因为黑客不知道公证机构的私钥是什么，只能拿着自己的私钥进行加密，这样客户端拿到数字签名后拿着公证机构的公钥进行解密是会解密失败的，也可以判定非法
感谢观看
道阻且长，行则将至
