了解HTTPS

1.HTTP认识

2.HTTP请求

3.HTTP响应

4.URL

5.HTTP方法

面试题：POST 和 GET区别？

网上关于 GET 与 POST的差别有待商议

关于请求报头和响应报头

6..Host ：

7..USer-Agent（简称UA）

8.状态码

9.HTTPS 是在 HTTP 基础上引入的加密机制

1.尝试加密：

2.传输对称密钥给服务器：

3.非对称加密

4.引入证书

10.常见抓包工具是如何抓包的？

1.HTTP认识

HTTP:"超文本传输协议" 是最当前最广泛的应用层协议。

HTTP可以传输文本，图片，音频文件，视频文件，传输视频等多种数据。

https是htpp的升级版。区别认为 https多了一个“加密层”。安全性更高。

http协议是种典型的一问一答模型的协议

客户端 -> 服务器，服务器 -> 客户端

想要观察http请求/响应的详细情况需要用到 Fillder 抓包工具。

抓包：把通过网卡的数据获取到，并解析出来。

Fiddler 相当于代理。

这个代理就当与自己的跑腿小弟，我给小弟钱小弟帮我到商店买东西，这个过程的细节小弟是非常清楚的。

2.HTTP请求

首行：方法 + URL + 版本

1.POST 是HTTP请求的方法。

中间的部分：URL访问的资源是什么

HTTP/1.1 ：Fiddler表示版本号

2.请求头（header）

从第二行开始一直到空行结束。冒号+空格分割键与值，每对键值对之间以换行分割。

3.空行

请求头结束的标志。

4.正文（body）

有的请求中有body，有的没有。body可以是空的字符串.如果存在body，header中会有Content-Length 和 Content-Type 来表示body的长度和类型。

3.HTTP响应

1.首行：[版本号 + 状态码 + 状态码解释]

2.响应头（header）

每行是一个键值对，不确定有几行，以空行结尾。键和值之间“：+空格”分开。

响应头以空行结束。

3.空行

4.正文（body）

对于相应来说，正文通常是HTML，CSS，JS，JSON，图片，音频，字体

总结：

4.URL

唯一资源定位符 Uniform Resource Locator

URI(大写的 i）简单理解为URL的一种中实现。日常不会可以区分这个两个概念。

第一次接触URL 应该是jdbc ，dataSource。设置url，用户名，设置密码。

jdbc:mysql://127.0.0.1:3306/.......

HTPPS：协议方案名，常见有http 和 https，访问mysql时的jdbc：mysql

user：pass ：登录信息，现在网站进行身份验证一般不再通过URL进行。

服务器地址：可以是IP，也可以是域名。

端口号：IP确定主机，端口号确定主机哪一个程序

带层次文件路径：进行确定具体的资源。

查询字符串：对访问的资源进行补充说明，本质是键值对结构

片段标识符：表示一个页面中的某个部分。

对于一个URL，最关心的是四个部分：

1.IP地址（域名）

2.端口号

3.层次路径

4.查询字符串，这个是程序员自定义的

这里的百分号字符有一大串子，这里是键值对的值进行转义后的结果，通过url encode进行转义，把特殊字符替换掉。

转义规则：把要转义的符号/汉字，每个字节以十六进制方式表示出来前面都加上%就可以了。

5.HTTP方法

方法就是描述这个HTTP请求动作要干啥

GET请求场景：

1.直接在浏览器输入一个URL，会触发GET请求。

凡是带有百度字样的都是这个点击百度页面进一步出发的请求。

2.点击HTML页面中的内容会触发请求。

3.js代码可以出发请求。

POST请求场景：

1.登录/注册

2.上传文件

body中的内容是上传文件的二进制内容（base64转码后内容）

虽然有时候内容本身就是二进制，但是也会进行转码（不一定urlencode，是base64）

面试题：POST 和 GET区别？

POST 很多时候与 GET 是通用的。

这个方法没有本质区别，（GET能用的场景POST也可以用，POST也是一样）

1.语义不同，方法表示的含义：

GET表示从服务器拿数据。

POST表示从服务器提交数据。

如果想使用GET提交数据也不是不行。但是不常见。不建议使用

2.传递数据的方式不同

GET 传递数据，通常是通过query string（查询寻字符串）把自定义数据提交给服务器

POST 传递数据，通常是通过body（正文）把自定义的数据提交给服务器。

（GET也可以加Body，POST也可以加query string 但不推荐）

3.GET方法应对请求，通常设计成“幂等”的，POST方法应对请求，对于“幂等性”则无要求。

什么是幂等？

吃进去的是草，挤出来的是奶。如果吃进去的是草，今天出来的是奶，明天不知道是什么，那就

不幂等，幂等就是讲究结果稳定。

（这只是HTTP标准文档要求的做法，放在今天就不合适了）。

在日常中，幂等不幂等实则是看业务要求。和方法的关系不大。

4.承接幂等性
GET 如果设计成幂等的，此时GET的结果是可以被缓存的，POST不设计幂等，post就不应该被缓存。

网上关于 GET 与 POST的差别有待商议

1.网上资料说，POST 比 GET 更加安全。

以登录为例，需要把用户名与密码传输到服务器，

POST的登录用户名密码是在body上，从浏览器界面上是看不到的。

GET登录用户名密码是在URL 的query string 中，直接显示到浏览器地址栏，此时用户名密码是可以看见的。这样的说法太勉强了。

安全性在于加密。虽然POST是在body中，但是安全性还是不够，别人随便抓包就可以知道了。所以这个两个并没有安全性可言，也不好比较。

2.关于传输的数据量

网上有个说法，GET 请求能够传输的数据量有上限。（URL的query string传输数据）URL长度有限。

实际上 HTTP协议没有规定 URL的长度，之所以会这样的说法，因为上古时期IE浏览器引入的限制。

3.传输数据类型

GET只能传输文本数据，POST可以传输文本，也能传输二进制。这个是错误观点。

GET基于query string ，可以把二进制进行urlencode / base64转码，也可给GET添加body，确保使用的库（客户端，服务器）都支持。

POST 即使传输二进制数据，但是也常常要base64 转码。

关于请求报头和响应报头

6..Host ：

表示服务器主机地址和端口。在URL中已经有所体现。

Content-Length：表示body的数据长度，单位是字节。HTTP基于TCP面向字节流，存在粘包问题，这个就是在解决粘包问题。

如果一个HTTP数据包没有body，此时空行就是分隔符。如果有就用Conten-Length区分。

Content-Type ：表示body 的数据格式。取值比较固定：text/html，charset=utf-8.,text/CSS，application/javascript，application/json.....

7..USer-Agent（简称UA）

表示浏览器/操作系统的属性。

红色表示操作系统信息，绿色表示浏览器信息。

UA以前的功能是判别出用户在用什么设备上网，然后针对其设备显示内容比如：显示屏幕的尺寸，需不需要显示图片等等。

现在主要用来统计数据，比如广告在一天中被点击多少次。

3.Refer

表示一个页面从哪里跳转过来的。形如；

直接在浏览器输入 URL，或者 直接通过收藏夹访问页面是没有 Refer的

主要用于从浏览器跳转到广告页面。可以用来区分哪个浏览器跳转到广告页面的。

4.Cookie

Cookie存储了一个字符串，这个数据可能是 客户端（网页）通过 JS写入的，也可能来自服务器。

（服务器在 HTTP 的header 中通过 Set-Cookie 字段给浏览器返回数据的）

Cookie也是键值对结构，“；”分割键值对。”：“分割键和值。

Cookie 也是储存客户端数据的一种机制。

为了安全，浏览器禁止网页访问客户硬盘，而是允许网页通过键值对储存数据，这样的键值对储存到硬盘上，浏览器封装好，网页干涉不了。

第一次访问某个网页时，在响应中会有 Set-Cookie这样的header，把一些键值对写到浏览器，进而储存到客户硬盘，下次访问时不需要重新加载所有数据，此时这个网站就会有Cookie。

最常见的例子就是，登陆时会直接进入，不需要重新输入密码。

Cookie 是什么？

Cookie是浏览器本地持久储存数据的一种机制，按照键值对储存。按照域名为维度分别储存。（每个网站都有自己的Cookie）

Cookie从哪里来？

是服务器返回响应数据中包含 Set-Cookie字段。

Cookie到哪里去?

后续浏览器访问 同一个服务器时，就会把之前储存Cookie带上，发送到服务器这里。

每次请求是独立的，那么服务器是如何知道我当前请求的前提是否为登陆状态呢？

客户端发送请求时带有Cookie，服务器收到Cookie，就会依据session去类似hash结构中查询，验证value没有错误，就认为已经处于登陆状态。知道了用户的身份。

随着互联网技术的发展，Cookie不是在唯一一个在浏览器储存数据的机制了。

8.状态码

200 ： OK表示请求成功与否，以及失败原因。

404 Not Found：访问的资源没有找到，路径错误。

403Forbidden 访问被拒绝

405 Method Not Allowed :方法不被允许

500 服务器内部错误：服务器代码出现bug，没有catch

504 Gateway Timeout：服务器出问题，未在规定时间返回。

302重定向：从A网站跳转到B网站。

9.HTTPS 是在 HTTP 基础上引入的加密机制

很久以前，客户端与服务器进行数据传输都是 明文传输，这种传输是数据很容易被劫持。

如果中间路由器被人动了手脚，数据就很容易泄露。

1.尝试加密：

如果对传输的 data（明文）进行加密（密文）并且生成一本密码本（密钥），这个密码本在接受数据的人手一份。那么这个密码本就很容易落入到歹徒手里。这样也是不安全的。

因此大家都知道密钥，黑客搞一个客户端也可以知道密钥。

2.传输对称密钥给服务器：

对称加密实际就是客户端和服务器使用同一个密钥。双方建立联系时就将这个密钥传输给对方，以后都会用这个密钥进行解密加密。

这样来看也是不行的，当第一次进行密钥交流时，只要黑客在路由器做手脚，就可以截胡这个密钥。

那我可以不可以把再次生成一个密钥，来加密真正进行解密的密钥呢，答案也是不行的。情况与上述类似。

3.非对称加密

如果服务器生成一把钥匙（公钥）用来给客户端使用，另一把（私钥）用来自己解密怎么样？

也就是说，用非对称加密去加密对称加密。

公钥给所有的客户端用来加密密钥，私钥自己留着用来解密客户端发送过来密文，以得到密钥。

这个非对称加密来加密密钥这个流程看似完美实则有很大的漏洞。

如果黑客通过浏览器在双方中间伪造公钥私钥就会泄露密钥。

所以这样的方式也是不行的。

4.引入证书

避免上图那种中间人的攻击，只好引入证书机制。

问题就出现在客户端第一次跟服务器进行交流时候。黑客将服务器的公钥掉包。就是说 客户端并不知道服务器的公钥到底可不可靠。

解决这个问题就只好引入一个权威的认证机构。就是CA机构。

想要搭建服务器使用HTTPS，就需要在CA公证机构这里申请证书（电子，一串数据），提交一些资料：网站域名，营业执照，备案号，公钥等等。

CA机构生产出一个电子证书，内容包含：

认证机构也有自己的公钥私钥。 拿着服务端的公钥后用自己的私钥注册签名，往后客户端拿到的都是服务端的证书（签名和其他数据打包发布到网上就叫做证书），并且CA机构的公钥会发给各种客户端，客户端用CA机构的公钥去解密证书中的签名，这样客户端就不再请求服务器公钥了，而是请求证书。由于CA机构的公钥是有可能被黑客拿到的，所以客户端拿CA机构的公钥这一操作直接写死在操作系统里面。

有个问题：客户端正确解密证书之后得到服务端的公钥，只能知道这个公钥是被认证过的，但是不一定就是目的服务端的公钥，所以证书中还有其他的数据，可以帮检验这个公钥是不是目的服务器的公钥。