构造 HTTP 请求的方式、HTTPS 的工作过程

一、构造 HTTP 请求的方式：

基于 HTML / JS (客户端构造HTTP请求，最常见的 HTTP 客户端，就是浏览器)

基于 form 表单基于 ajax

基于 Java (这种方案是完全可行的，但是实际开发中用的不如上面的方式多)

基于 socket

---

1、基于 form 表单构造 HTTP 请求 1.1、form

form (表单) 是 HTML 中的一个常用标签，可以用于给服务器发送 GET 或者 POST 请求

form 的重要参数：

action ： 构造的 HTTP 请求交给哪个服务器，是一个 URLmethod ：构造的 HTTP 请求的 方法 是 GET 还是 POST (form 只支持 GET 和 POST，不区分大小写)

光有这一个 form 标签，还没法提交，也没什么东西可提交的
还需要搭配 form 里面有一些其他的标签，比如 input

input 的重要参数：

type ： 表示输入框的类型，``text表示文本， password 表示密码，submit` 表示提交按钮value ： input 标签的值， 对于 type 为 submit 类型来说，value 就对应了按钮上显示的文本name ： 不是 id，也不是 class，name 属性与样式无关。 from 表单给服务器提交的数据，本质上是键值对。此处的 name 就表示构造出的 HTTP 请求的 query string 的 key， query string 的 value 就是输入框的用户输入的内容

<input type="text" name="username"> 
<input type="password" name="password"> 

假设用户在此处输入的用户名是 zhangsan，密码是 123
此时 form 表单生成的要提交的数据，就形如：username=zhangsan&password=123

光有两个输入框，还不太够，还需要有一个 “提交按钮” submit ，来触发这里的 HTTP 请求

---

1.2、get 请求

<form action="http://www.sogou.com/index.html" method="get">
    <input type="text" name="username">
    <input type="password" name="password">
    <input type="submit" value="提交">
form>

此处的 query string 正是页面要提交给服务器的数据：

---

1.3、post 请求

<form action="http://www.sogou.com/index.html" method="post">
    <input type="text" name="username">
    <input type="password" name="password">
    <input type="submit" value="提交">
form>

此时就 url 中就没有 name

查看请求：

注意： 如果换成 lisi 123，提交还是搜狗的主页，因为当前咱们是把这样的请求直接提交给搜狗主页了，但是搜狗没有处理这样的参数
自己写服务器时，自己的服务器就可以针对前端提交来的参数进行处理，就可以实现一些不同的功能了

---

2、ajax 构造 HTTP 请求 2.1、ajax

form 表单这种方式，是一个更加原始的构造方式，使用 form 一定会涉及到 页面跳转
浏览器需要加载出全新页面

这个事情就是非常的不科学了，尤其是页面非常复杂的时候
随着前端页面越来越复杂，就希望，能够让页面不去整个全部加载，而是只加载其中需要变化的某个小部分

这个情况，就可以使用 ajax 了
在 JavaScript 中可以通过 ajax 的方式构造 HTTP 请求，再通过 js 代码来处理这里的响应，并且把得到的一些数据给更新到页面上

ajax 全称 Asynchronous Javascript And XML ， 是 2005 年提出的一种 JavaScript 给服务器发送 HTTP 请求的方式特点是可以不需要 刷新页面/页面跳转 就能进行数据传输

---

2.2、异步

异步概念，是计算机中，非常常见的一个概念。此处说的 同步 和 加锁 处所说的同步不是一个同步，一个计算机术语，在不同的上下文中，表示的意思，是可能不同的

比如和女朋友出去玩，约好了时间，我先到了，先等着她，这里的等待，这个就是一种 同步 的等待，我是调用者，女朋友是被调用者，调用者会一直在这里等着，主动来获取到被调用者的结果

异步 的等待 ，我就直接给她说，我找个凉快地方玩会手机，一会你下来了给我打电话，调用者发起一个调用请求之后，就不管了，等到被调用者结果出来之后，会主动来通知调用者

同步等待中：

阻塞式地等 (不见不散)非阻塞式地等 (每隔一段时间，去查询一下结果)

再比如我去吃饭，来到店里：老板，来个蛋炒饭

同步阻塞等待：
我就蹲在前台这里，盯着后厨来做饭,直到饭做好，我自己端走

同步非阻塞等待：
我在前台这看一眼,发现饭没做好，我出去溜达一圈，
过一会又来到前台这里看，发现饭还是没做好，我去玩会手机… 经过若干次之后，发现饭好了，自己端走

异步等待：
一我就直接啥都不管了，就找个角落左下，玩手机，该干啥干啥，
筹到饭好了之后，人家直接给我端上来了

2 和 3 这两种方式，都是属于等的过程中可以干别的事情的，
区别就在于 第 2 种方式对于调用者来说开销要更大 (反复去查询结果)，第 3 种方式往往是更优的

在 IO 的场景中，经常会涉及到这三种情况
IO 就包含，你通过 控制台输入输出 / 通过文件输入输出 / 通过网络输入输出

Scanner，输入流对象输出流对象，默认都是同步阻塞等待

Ajax 使用的是 异步等待

同步和异步 ：区别主要就是看这个结果是调用者主动关注，还是被调用者来给调用者通知阻塞和非阻塞 ：区别是等的过程中，能不能干别的事情

---

2.3、Ajax 请求

Ajax 就是属于基于异步等待的方式来进行的

首先构造出一个 HTTP 请求，发给服务器但是浏览器不确定服务器啥时候才有响应，于是就先不管了，浏览器里面就继续执行其他代码 (该干啥干啥)等到服务器的响应回来了之后，再由浏览器通知咱们对应的 JS 代码，以回调函数的方式来处理响应

这是通过原生 JS 的 ajax 来构造请求并处理响应的，原生的写法非常麻烦，也比较抽象，不好理解
使用一个更加简单，也更好理解的方，基于 jQuery 中的 ajax 来演示相关代码
jQuery 是 JS 世界中，最知名的库 (没有之一)， jQuery 在 js 中地位，相当于 spring 在 Java 中的地位
曾经的地位，最近几年 jQuery 的风头被 JS 新生的一些框架给抢走了不少，Vue，React，Angela 这三大框架

引入 jquery ：

先在搜索引擎中搜索 jquery cdn 查询词在结果中，找一个合适的 cdn 的 url打开对应的 url，加载出 jquery 本体复制占贴内容到本地文件

http://libs.baidu.com/jquery/2.0.0/jquery.min.js

使用 jquery 的 ajax ： $

变量名 . js 允许 $ 作为变量名的一部分，这个 $ 就是 jquery 中最核心的对象，jquery 的各种 api，都是通过 $ 来触发的

$.ajax ({
	
});

通过 $ 对象来调用 ajax 函数，参数只有一个，但是是一个 “对象”

对象中的取值：

type ：表示 HTTP 请求的方法，不仅仅支持 GET 和 POST，也支持 PUT，DELETE 等其他方法url ：HTTP 请求的 urlsuccess ：对应一个回调函数，这个回调函数会在正确获取到 HTTP 响应之后，调用，就是异步的过程

ajax 参数这里还可以有一些其他的值： jQuery ajax - ajax() 方法

<script src="jquert.js"></script>
<script>
    $.ajax ({
        type: 'get',
        url: 'http;//www.sogou.com/index.html',
        success: function(body) {
            // 回调函数的参数就是 HTTP 响应的 body 部分
            console.log("获取到响应数据！" + body);
        },
        error: function() {
            // error 也对应一个回调函数 会在请求失败后触发 也是异步
            console.log("获取响应失败！");
        }
    });
</script>

刚才 ajax 请求，通过抓包看到，响应里面是 200 OK，并且 body 也是 html 数据

但是浏览器仍然认为这是一个 “出错” 的请求

出现这个报错的原因，是浏览器禁止 ajax 进行跨域访问 ，跨越多个域名 / 多个服务器

当前页面处在的服务器，是本地文件，页面中 ajax 请求的 URL，域名是 www.sogou.com

当前页面处在的服务器，就是在 www.sogou.com中。页面中再通过 ajax 请求 URL，域名为 www.sogou.com 这种就不算跨域

上述行为是浏览器给出的限制 ，当然，我们也是有办法绕过这个限制的
如果对方服务器返回的响应中带有相关的响应头，允许跨域 *** 作，就是可以正常被浏览器显示的

因此，当下咱们构造的 ajax 请求是无法被正确处理的，什么时候才能正确处理？就需要咱们自己有一个服务器，让页面和 ajax 的地址都是这一个服务器，就行了

---

3、通过 Java socket 构造 HTTP 请求

java 构造一个 HTTP 请求，主要就是基于 TCP socket，按照 HTTP 请求的报文格式，构造出一个匹配的字符串，再写入 socket 即可

在实际开发中，确实也会有一些基于 java 构造 http 请求的情况，可以直接基于第三方库来实现，不一定非得是直接使用 socket

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.net.Socket;

public class HttpClient {
    private Socket socket;
    private String ip;
    private int port;

    public HttpClient(String ip, int port) throws IOException {
        this.ip = ip;
        this.port = port;
        socket = new Socket(ip, port);
    }

    public String get(String url) throws IOException {
        StringBuilder request = new StringBuilder();
        // 构造首行
        request.append("GET " + url + " HTTP/1.1\n");
        // 构造 header
        request.append("Host: " + ip + ":" + port + "\n");
        // 构造 空行
        request.append("\n");
        // 发送数据
        OutputStream outputStream = socket.getOutputStream();
        outputStream.write(request.toString().getBytes());
        // 读取响应数据
        InputStream inputStream = socket.getInputStream();
        byte[] buffer = new byte[1024 * 1024];
        int n = inputStream.read(buffer);
        return new String(buffer, 0, n, "utf-8");
    }

    public String post(String url, String body) throws IOException {
        StringBuilder request = new StringBuilder();
        // 构造首行
        request.append("POST " + url + " HTTP/1.1\n");
        // 构造 header
        request.append("Host: " + ip + ":" + port + "\n");
        request.append("Content-Length: " + body.getBytes().length + "\n");
        request.append("Content-Type: text/plain\n");
        // 构造 空行
        request.append("\n");
        // 构造 body
        request.append(body);
        // 发送数据
        OutputStream outputStream = socket.getOutputStream();
        outputStream.write(request.toString().getBytes());
        // 读取响应数据
        InputStream inputStream = socket.getInputStream();
        byte[] buffer = new byte[1024 * 1024];
        int n = inputStream.read(buffer);
        return new String(buffer, 0, n, "utf-8");
    }

    public static void main(String[] args) throws IOException {
        HttpClient httpClient = new HttpClient("42.192.83.143", 8080);
        String getResp = httpClient.get("/AjaxMockServer/info");
        System.out.println(getResp);
        String postResp = httpClient.post("/AjaxMockServer/info", "this is body");
                System.out.println(postResp);
    }
}

使用 Java 构造的 HTTP 客户端不再有 “跨域” 限制了，此时也可以用来获取其他服务器的数据了
跨域只是浏览器的行为，对于 ajax 有效，对于其他语言来说一般都和跨域无关

HttpClient httpClient = new HttpClient("www.sogou.com", 80);
String resp = httpClient.get("/index.html");
System.out.println(resp);

// 此时可以获取到 搜狗主页 的 html

---

标准的http请求报文头中，以下哪个说法是正确的（ABCD）

A.User-Agent: 声明用户的 *** 作系统和浏览器版本信息B.Content-Type: 数据类型C.Host: 客户端告知服务器, 所请求的资源是在哪个主机的哪个端口上D.location: 搭配3xx状态码使用, 告诉客户端接下来要去哪里访问

---

二、HTTPS 1、运营商劫持

HTTPS 也是一个应用层协议， HTTPS相当于HTTP的孪生兄弟，是在 HTTP 协议的基础上引入了一个加密层

HTTP 协议内容都是按照文本的方式明文传输的，这就导致在传输过程中出现一些被篡改的情况

臭名昭著的 "运营商劫持：

下载一个 天天动听

未被劫持的效果，点击下载按钮，就会d出天天动听的下载链接

已被劫持的效果，点击下载按钮，就会d出 QQ 浏览器的下载链接

不止运营商可以劫持，其他的 黑客 也可以用类似的手段进行劫持，来窃取用户隐私信息，或者篡改内容
试想一下，如果黑客在用户登陆支付宝的时候获取到用户账户余额，甚至获取到用户的支付密码…

在互联网上，明文传输是比较危险的事情!!!

HTTPS 就是在 HTTP 的基础上进行了加密，进一步的来保证用户的信息安全

---

2、加密

加密就是把 明文 (要传输的信息)进行一系列变换，生成 **密文 **
解密就是把 密文 再进行一系列变换，还原成 明文

在这个加密和解密的过程中，往往需要一个或者多个中间的数据，辅助进行这个过程，这样的数据称为 密钥 (正确发音 yue 四声，不过大家平时都读作 yao 四声，或 shi 二声)

加密解密到如今已经发展成一个独立的学科：密码学
密码学的奠基人，也正是计算机科学的祖师爷之一，艾伦·麦席森·图灵

对比我们另一位祖师爷冯诺依曼

图灵年少有为，不光奠定了计算机， 人工智， 密码学的基础，并且在二战中大破德军的 Enigma 机，使盟军占尽情报优势，才能扭转战局反败为胜，但是图灵遭到英国皇室的迫害，享年 41 岁，电影《模仿游戏》讲述的就是图灵
计算机领域中的最高荣誉就是以他名字命名的 “图灵奖”

83 版 <<火烧圆明园>>， 有人要谋反干掉慈禧太后，恭亲王奕䜣(洋务派代表人物之一) 给慈禧递的折子，折子内容只是扯一扯家常，套上一张挖了洞的纸就能看到真实要表达的意思

明文：要传输的原始信息，“当心肃顺，端华，戴恒” ，(肃顺、端华、戴桓三人是老皇帝驾崩前任命的辅政大臣，后来被慈禧一锅端了)

密文：奏折全文，即使被别人获取到了，拿着密文，也看不出什么

密钥：通过密钥，把明文，转成密文，或者是把密文还原成明文，这里就是带有窟窿的纸

---

3、HTTPS 的工作过程

加密和解密这个事情，本身是一个和数学密切相关的事情
咱们此处，只能简单讨论"流程"，无法讨论加密解密的 “实现细节”

加密之后，也不是就绝对安全，只是说破解起来计算量很大，成本很高
有些数据经过加密之后，哪怕使用当前最牛的计算机，破解起来也需要个几十年，上百年的，这种就认为是安全的
只要破解成本高于数据本身的价值，就是安全的
(有个团伙，造假钞，造的贼好，以至于验钞机根本区分不出来… 但是造一个100块钱的假钞，实际成本，是110块钱…)

HTTPS 中引入的加密层，称为 SSL (旧的叫法) / TLS (新的叫法)

在SSL里面，涉及到的加密 *** 作，其实主要是两种方式：

对称加密：使用同一个密钥，既可以进行加密，也可以进行解密非对称加密

---

3.1、对称加密

对称加密其实就是通过同一个 “密钥”，把明文加密成密文，并且也能把密文解密成明文

一个简单的对称加密，按位异或

假设 明文 a = 1234, 密钥 key = 8888则加密 a ^ key 得到的密文 b 为 9834.然后针对密文 9834 再次进行运算 b ^ key, 得到的就是原来的明文 1234.(对于字符串的对称加密也是同理, 每一个字符都可以表示成一个数字)当然，按位异或只是最简单的对称加密. HTTPS 中并不是使用按位异或.

客户端和服务器持有同一个密钥

客户端传输的数据 (HTTP 请求的 header 和 body) 都通过这个密钥进行对称加密，实际在网络上传输的是密文

服务器收到密文之后，接下来就可以根据刚才的密钥，来进行解密，拿到明文

上面的这个过程，看起来挺美好的，但是存在一个致命缺陷
如何保证 客户端 和 服务器，持有同一个密钥?? 尤其是一个服务器，对应很多很多客户端的时候

显然，必须是不同客户端用不同密钥，才行
如果各个客户端都是同一个密钥，这个密钥就太容易被黑客拿到了 (黑客只要自己启动一个客户端…)

既然需要是不同的密钥，就需要让服务器能够记录，不同的客户端的密钥都是什么
而且得让客户端和服务器之间能够传递这个密钥

因为需要不同的客户端有不同的密钥，要么是客户端主动生成一个密钥，告诉服务器，要么是服务器生成一个密钥，告诉客户端，需要把这个密钥，通过网络进行传递的

这个图里，是假设客户端生成的密钥，客户端就需要把密钥通过网络告诉服务器

客户端生成了密钥，888888，客户端就得告诉服务器，咱们的密钥是888888

由于设备可能早就被黑客入侵了
密钥是啥，如果明文传输，也就很容易被黑客拿到了，如果黑客知道了你的密钥，后面咋加密，都是形同虚设了

---

3.2、非对称加密

经过上述讨论，就明确了，使用对称加密，最大的问题，在于说密钥得能够传递过去，如果明文传递，是不行的，必须针对这个密钥再进行加密

这里解决问题的关键，就是需要引入，非对称加密了

非对称加密，有两个密钥，分别叫做公钥和私钥

公钥，就是人人都能获取到

私钥，就是只有自己才知道

就可以使用公钥来加密，使用私钥来解密
或者，使用私钥加密，使用公钥解密

直观上理解公钥私钥：

很多小区，单元门口,有一个 “信箱”你有一把钥匙，和很多把锁头，你把这些锁头发给送信小哥每个送信的小哥都可以凭这个锁头，把信锁到你的信箱里，只有你自己持有着这把钥匙，能够开箱，拿出信此处锁头，就相当于公钥，你自己手里的钥匙，就是私钥

基于非对称加密，就可以让服务器自己生成一对公钥和私钥，公钥发出去(人人都能拿到)，私钥自己保存

客户端生成一个对称密钥，客户端就可以使用服务器的公钥，对对称密钥进行加密，然后把数据传给服务器，服务器再通过私钥进行解密

服务器自己持有私钥，客户端持有公钥，黑客可以拿到公钥，但是拿不到私钥

客户端生成了对称密钥，就可以基于刚才的公钥，对对称密钥进行加密

如果黑客拿到了这个密文，那么此时由于黑客没有私钥，是不能进行解密的，也就不知道对称密钥是啥

既然非对称加密这么好使，还要对称加密干啥?? 直接非对称加密一把梭就行了呗??

实际实现中，对称加密的计算开销 << 非对称加密如果只是少来少去的，用用这个非对称加密，成本还好但是如果所有数据都走非对称加密，这个事就成本太大了

---

3.3、中间人攻击

上述过程看起来好像很完美了，其实不然。这里仍然存在一个非常巨大的漏洞!!!

服务器要把自己的公钥返回给客户端在这个 *** 作中，就可能会涉及到一个非常经典的 “中间人攻击”

正常的情况：

中间人攻击：

中间人攻击的关键，是黑客自己也生成一对公钥私钥

拦截到 服务器给客户端返回的公钥，用自己生成的公钥，替换之

黑客拦截到对称密钥的密文之后，由于这个密文是使用 public key2 来进行加密的!! 因此黑客就可以使用 private key2 进行解密!!! 黑客就拿到了对称密钥，888888

紧接着，黑客为了隐藏自己，把 888888 再使用之前从服务器拿到的 public key 进行加密，得到了另外一个密文，返回给服务器

---

3.4、引入证书

既然存在中间人攻击，如何解决这个问题??
关键要点，得让客户端能够确认，当前的公钥，确实是来自于服务器，而不是由黑客伪造的

想想看，生活中其他场景是怎么验证的???
例如，你去网吧，或者去住小旅馆，需要进行身份登记

如何验证你的身份? 你有身份z网管就会拿着你的身份z刷一下，这一刷，其实就是在访问公安局的相关服务器，验证你的身份信息因此，就需要引入一个第三方公信机构，来证明这个公钥是一个合法的公钥因为咱们是信任这个公信机构的 (就像咱们信任 jc 一样)，公信机构说这个公钥 ok，我们就可以认为这个公钥可信!!!

服务器在最开始上线的时候，就需要先去 CA机构 这里，申请一个证书!!
然后服务器自己生成的公钥，就放在这个证书中 (就是一段数据)

在客户端和服务器刚一建立连接的时候，服务器给客户端返回一个 证书，这个证书包含了刚才的公钥，也包含了网站的身份信息

这个 证书 可以理解成是一个结构化的字符串，里面包含了以下信息：

证书发布机构证书有效期公钥证书所有者签名…

客户端这里黑客也是有可能会伪造证书的，

当客户端获取到这个证书之后，会对证书进行校验 (防止证书是伪造的)

客户端如何验证这个证书是否合理?

证书上自身有一些校验机制

向公信机构进行求证

如果是黑客伪造了证书，此时就会露馅，于是浏览器就会d框警报

判定证书的有效期是否过期判定证书的发布机构是否受信任( *** 作系统中已内置的受信任的证书发布机构)验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥, 对签名解密, 得到一个 hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对比 hash1 和 hash2 是否相等.
如果相等, 则说明证书是没有被篡改过的

如果每次都访问这个公信机构来求证，是不是太麻烦了呀?
确实如此，实际上，客户端自身就会包含一些公信机构的信息 (内置在 *** 作系统里)
不需要通过服务器网络请求，直接本地就能进行认证 (这就好像一个非常牛的网吧，直接公安局派了一个 jc 长期驻扎在这里)

以上描述的东西都是包含在 SSL 中的，SSL 不仅仅是应用于HTTPS，很多其他地方也会用到 SSL

这整个的加密过程，预期说是去防止数据被拦截，不如说更重要是防止数据被篡改

既然 HTTP 数据已经经过了加密了，为啥 fiddler 仍然能抓到并解析 HTTPS里的数据报?

之所以 fiddler 能抓包，是和咱们安装fiddler之后，第一次启用HTTPS功能时候，d出的那个对话框密切相关的!!!点是 *** 作，其实就是让 *** 作系统能够信任fiddler提供的证书相当于用户给fiddler授权了，允许fiddler进行“中间人攻击"

查看浏览器的受信任证书发布机构：
Chrome 浏览器, 点击右上角的 选择 “设置”, 搜索 “证书管理” , 即可看到以下界面

理解数据摘要 / 签名:

以后我们参加工作后, 经常会涉及到 “报销” 的场景. 你拿着发票想报销, 需要领导批准. 但是领导又
不能和你一起去找财务. 那咋办?

很简单, 领导给你签个字就行了. 财务见到领导的签字, “见字如见人”.
因为不同的人, “签名” 的差别会很大. 使用签名就可以一定程度的区分某个特定的人.

类似的, 针对一段数据(比如一个字符串), 也可以通过一些特定的算法, 对这个字符串生成一个 “签
名”. 并保证不同的数据, 生成的 “签名” 差别很大. 这样使用这样的签名就可以一定程度的区分不同的数据.

常见的生成签名的算法有: MD5 和 SHA 系列
以 MD5 为例, 我们不需要研究具体的计算签名的过程, 只需要了解 MD5 的特点:

定长: 无论多长的字符串, 计算出来的 MD5 值都是固定长度 (16字节版本或者32字节版本)

分散: 源字符串只要改变一点点, 最终得到的 MD5 值都会差别很大.

不可逆: 通过源字符串生成 MD5 很容易, 但是通过 MD5 还原成原串理论上是不可能的.

正因为 MD5 有这样的特性, 我们可以认为如果两个字符串的 MD5 值相同, 则认为这两个字符串相同

理解判定证书篡改的过程 : (这个过程就好比判定这个身份z是不是伪造的身份z)

假设我们的证书只是一个简单的字符串 hello, 对这个字符串计算hash值(比如md5), 结果为
BC4B2A76B9719D91

如果 hello 中有任意的字符被篡改了, 比如变成了 hella, 那么计算的 md5 值就会变化很大.
BDBD6F9CF51F2FD8

然后我们可以把这个字符串 hello 和 哈希值 BC4B2A76B9719D91 从服务器返回给客户端, 此时
客户端如何验证 hello 是否是被篡改过?

那么就只要计算 hello 的哈希值, 看看是不是 BC4B2A76B9719D91 即可

但是还有个问题, 如果黑客把 hello 篡改了, 同时也把哈希值重新计算下, 客户端就分辨不出来了呀

所以被传输的哈希值不能传输明文, 需要传输密文.

这个哈希值在服务器端通过另外一个私钥加密(这个私钥是申请证书的时候, 证书发布机构给服务
器的, 不是客户端和服务器传输对称密钥的私钥).

然后客户端通过 *** 作系统里已经存的了的证书发布机构的公钥进行解密, 还原出原始的哈希值, 再
进行校验.

---