【HTTP协议——八股文（下）篇】

一、如何通过代码构造HTTP请求？

在前两篇我们介绍了关于HTTP请求响应当中的一些具体属性字段，那么我们如何通过代码构造出一个HTTP请求发送至服务器端呢？

常见的构造HTTP请求可以通过HTTP客户端，即浏览器构造，基于Form表单或是ajax。还有一种是基于java当中的socket，这种方式并不常见，但在某些特殊场合我们仍然在用，这里我们不做过多介绍。

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

核心在于使用HTML标签，也就是form标签。具体用法如下：

 from标签当中的action属性表示这个请求将要发往何处，即URL，method表示是按照GET方法来提交还是POST方法来提交。对于GET方法，参数则放在query string当中，对于POST方法，参数则是放在body当中。这里的method取值，只能是GET或POST，不支持其他的方法。对于提交的数据，可以通过input标签来输入，此处的key则对应于name属性当中的值，value就是用户在输入框当中输入的内容。将用户的数据输入进去后，还需要使用一个提交按钮将输入框当中的内容封装成K-V形式提交给服务器，通过这个按钮来触发HTTP请求。

当前我们把请求提交给了搜狗主页，但是搜狗主页并没有对我们提交的参数进行处理，原因是对于搜狗的程序员来说，人家编写的代码并不存在对咱们参数解析的处理，即搜狗服务器并没有对我们提交的数据进行处理，对于日后我们自己写服务器时，可以自定义自己的服务器针对前端提交的参数进行一系列处理，就可以实现我们想要的功能了。

 2、基于ajax构造HTTP请求

form表单这种方式，是属于比较原始的构造请求，使用form就一定会涉及到页面跳转，此时浏览器就需要加载出来全新的页面，因此这样就非常不科学，尤其是页面相对来说比较复杂的时候，就会比较低效。随着前端页面的不断丰富，不断复杂，此时我们就希望能够让页面不去加载整个页面，而是加载其中需要变化的某个部分，因此，就可以使用js代码来构造出HTTP请求，在通过js代码来处理响应，并把得到的数据更新到页面当中。

在具体实操之前，我们需要先了解一个概念——异步！

想要理解异步，我们先需要了解同步。举个例子：我去找我女朋友吃饭，我到她宿舍楼下打电话问她好了没，她说马上就来，于是我就在宿舍楼下一直等着她出来，这样的过程就是同步，其核心就是需要我一直不停的关注她有没有出宿舍楼，即调用者会一直等待，主动来获取被调用者的状态。那么异步是怎样的呢？异步可以这样理解——我问她好了没，她说马上就来，有女友的兄弟们可以理解这个“马上就来”是多久来！！！然后我就告诉她，那我找个凉快的地方玩会手机，你下来了给我打电话，这样，我就不用持续的关注她有没有下来，而是等待她的通知即可，这样的过程就是异步，对于调用者发起请求之后，就不再关注被调用者的状态，而是等被调用者的结果出来之后，会主动通知调用者。相比于同步，异步会大大减少调用者的等待时间，甚至可以说无需等待，只需等通知~

扩展：对于同步这种方式来说，又分为阻塞式的等和非阻塞式的等，阻塞式的等就是我就一直站在宿舍楼下等她，不去任何地方干任何事，而非阻塞式的等，就相当于我和女友没有约定她下来了给我打电话，而是我依然是找个凉快的地方玩手机，但是区别在于我得隔几分钟去看看她下没下来，她如果下来了，那我们就去吃饭~（作死行为，举个例子，别模仿）！

对于同步非阻塞等待和异步等待，都是可以在等的过程中干其他的事情，但是区别在于同步非阻塞等待方式对于调用者来说开销更大，需要反复的关注结果，而异步等待就省事不少，只需要等待通知即可。ajax所使用的的等待方式就是异步等待。

 下面我们来看如何使用ajax构造出一个HTTP请求，在此之前我们需要引入一个js的第三方库——jQuery。

 type表示所使用的的方法，此处为get，这个type支持HTTP协议当中的多种方法，不仅仅是个体和post，url对应HTTP请求中的URL。中间部分为处理响应的回调函数，回调函数就表示当服务器返回响应时所触发执行的函数。我们通过浏览器打开这段代码，并通过fiddler抓包观察其中的具体细节。

 我们可以观察到HTTP请求当中的方法为GET，URL为上面ajax当中的url。

二、HTTPS

HTTPS相当于HTTP的孪生兄弟，HTTPS在HTTP的基础之上引入了一个加密层。对于在网络中传递的数据，我们是不建议使用明文传输的，因此就需要对传递的数据进行加密，使用密文传输，那么如何实现密文传输呢？HTTPS当中引入的加密层，称为SSL或TLS，在SSL当中，涉及到的加密操作，主要有两种方式：一是对称加密，二是非对称加密。下面我们分别来看这两种加密方式~

1、对称加密

 对称加密是客户端和服务器持有相同的密钥，客户端传输的数据都将通过这个密钥来进行对称加密，服务器返回的响应也将使用这个密钥进行加密，即实际上在网络当中传输的是密文而非明文。服务器收到密文之后，接下来就可以根据刚才的密钥，来进行解密，拿到明文，同样的客户端也是通过这个密钥来对服务器返回过来的数据进行解密。

上述过程看似并没有什么缺陷，但是实际上却存在一个致命缺陷，那就是如何保证客户端和服务器持有相同的密钥，对于不同的客户端，服务器需要使用不同的密钥进行交互。

 如果各个客户端都使用相同的密钥，这个密钥就太容易被黑盒拿到了，黑客一旦拿到了，那不就芭比Q啦？既然需要是不同的密钥，就需要让服务器能够记录，不同的客户端所使用的的密钥是什么，针对不同客户端发送的数据，就使用其相对应的密钥进行解密。对此就需要由客户端服务器协商使用怎样的密钥，对此就存在这样的问题，在双方协商使用什么样的密钥的时候，一旦此时黑客入侵，那么后续的加密操作就形同虚设了。如图：

 在双方协商使用怎样的密钥的时候，仍需要使用明文进行协商，此时黑客一旦入侵，知道了你使用怎样的密钥，那么后续的加密操作便没有了意义。即便后续再怎么修改所使用的的密钥，都是形同虚设的。

经过上述的思考，就明确一点，使用对称加密，最大的问题，在于说密钥得能够安全的传递过去，如果明文传递，那就会存在黑客入侵的风险，这显然是行不通的，那么必须针对这个密钥在进行加密。因此要解决这个问题，就需要引入非对称加密。

2、非对称加密

非对称加密机制的核心在于引进了一对公钥和私钥，这对公钥和私钥具体是干甚的呢？

公钥和私钥一般由服务器生成，公钥就是人人都可以获取到的，而私钥是只有服务器自己本身持有的，不会对外公布的。

举个例子：邮差送信

过去的邮差会将你的信放到你的信箱当中，为了防止第三者对信进行篡改或者窃取，就会使用锁进行上锁，你自己本人复制了n把锁，这n把锁使用同一把钥匙，将这n把锁分配给各个邮差，当各个邮差给你送信时，使用这个锁对你的信箱进行上锁，之后你用你的钥匙进行解锁即可。这样就防止了第三者对你的信造成攻击。

 非对称加密和上述例子的核心相同，又服务器生成一对公钥和私钥，公钥公之于众，私钥自己保留。

 当客户端向服务器进行协商使用的密钥之前，会先向服务器询问其使用的公钥是什么，然后服务器将公钥返回给客户端，然后客户端根据服务器返回回来的公钥对自己所要使用的对称密钥进行加密，此时即使中间的网络设备被黑客入侵了，它因为没有私钥，所以不能对这个协商信息进行解密，这样就防止了对称密钥的泄漏。

这个时候我们思考一个问题，那当初次服务器返回公钥的时候，我们黑客对这个公钥进行了篡改，那结果将会如何？这个问题就是非常经典的“中间人攻击”（老六攻击）。

我们先来看上述不存在“中间人攻击”的流程图解：

 然后我们再来看存在“中间人攻击”的流程图解：

 “中间人攻击”的核心点在于，在被黑客入侵的网络设备当中传输公钥信息的时候，这个时候黑客也生成一对公钥私钥，将自己生成的公钥返回给客户端，当客户端使用这个黑客生成的公钥对自己的对称密钥加密的时候，当这条协商数据在此传输到这个网络设备的时候，这个时候黑客利用自己生成的私钥对这条信息进行解密，解密之后采取其他的操作，产生的后果同样也时不可忽视的。那这样一来，岂不是用什么都有危险了？

 老话说，道高一尺魔高一丈，这个时候就又有了新的机制来防止这样的情况发生，那就是“身份验证”~我们具体来看看这又是怎么一回事~

 可以看到图中我们引入了“公信机构”，有了这个机构，当服务器上线时，就需要先去公信机构这里申请自己专属的证书，然后服务器自己生成公钥，就存放到这个证书当中。在之后的客户端和服务器询问其公钥时，在拿到公钥时就会先去公信机构查询该公钥是否具有合法权威性，以防第三方黑客篡改公钥，这样一来，一旦拿到的证书是黑客伪造的，那么此时浏览器就会触发弹窗报警，这样一来就可以有效防止“中间人攻击”。

黑客能否冒充公信机构之类的？

公信机构就类似于警察蜀黍这样的身份，可以试想冒充的风险有多大？成本有多高？