HTTP请求方法（所有方法全为大写）有多种，各个方法的解释如下：
GET     请求获取Request-URL所标识的资源（向服务器请求资源）
POST    在Request-URL所标识的资源后附加新的数据（常用于提交表单）
HEAD    请求获取由Request-URL所标识的资源的响应消息报头
PUT     请求服务器存储一个资源，并用Request-URL作为其标识
DELETE 请求服务器删除Request-URL所标识的资源
TRACE   请求服务器回送收到的请求信息，主要用于测试或诊断
CONNECT 保留将来使用
OPTIONS 请求查询服务器的性能，或者查询与资源相关的选项和需求

GET与POST的区别

1、get在浏览器回退时是无害的，而post会再次提交请求。（记住）
2、get请求会被浏览器主动缓存，而post不会，除非手动设置。（记住）
3、get产生的url地址可以被收藏，而post不可以。
4、get请求只能进行url编码，而post支持多种编码方式。
5、get请求参数会被完整保留在浏览器历史记录里，而post中的参数不会被保留。（记住）
6、get参数通过url传递，post放在request body 中。（记住)
7、get请求在url中传送的参数是有长度限制的，而post没有限制。
8、对参数的数据类型，get只接受ASCII字符，而post没有限制。
9、get比post更不安全，因为参数直接暴露在url上，所以不能用来传递敏感信息。

请求地址

即为URL:统一资源定位符，是一种资源位置的抽象唯一识别方法。

组成：<协议>：//<主机>：<端口>/<路径>（端口和路径有时可以省略，HTTP默认端口号是80）

协议版本

协议版本的格式为：HTTP/主版本号.次版本号，常用的有HTTP/1.0和HTTP/1.1

（2）请求头部

请求头部为请求报文添加了一些附加信息，由“名/值”对组成，每行一对，名和值之间使用冒号分隔。

（3）空行

表示请求头部结束，接下来为请求数据，这一行非常重要，必不可少。

（4）请求数据

下面是一个post请求的请求数据示例

POST 　/index.php　HTTP/1.1 　　请求行
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2　　请求头
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: zh-cn,zh;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://localhost/
Content-Length：25
Content-Type：application/x-www-form-urlencoded
　　空行
username=aa&password=1234　　请求数据

二.服务器发送响应

HTTP响应报文主要由状态行、响应头部、空行以及响应数据组成。

（1）状态行

由3部分组成，分别为：协议版本，状态码，状态码描述。

其中协议版本与请求报文一致，状态码描述是对状态码的简单描述，所以这里就只介绍状态码。

常见状态码：

状态代码为3位数字。
1xx：指示信息–表示请求已接收，继续处理。
2xx：成功–表示请求已被成功接收、理解、接受。
3xx：重定向–要完成请求必须进行更进一步的操作。
4xx：客户端错误–请求有语法错误或请求无法实现。
5xx：服务器端错误–服务器未能实现合法的请求。

（2）响应头部

与请求头部类似，为响应报文添加了一些附加信息

（3）响应数据

以下为一个响应示例

HTTP/1.1 200 OK　　状态行
Date: Sun, 17 Mar 2013 08:12:54 GMT　　响应头部
Server: Apache/2.2.8 (Win32) PHP/5.2.5
X-Powered-By: PHP/5.2.5
Set-Cookie: PHPSESSID=c0huq7pdkmm5gg6osoe3mgjmm3; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 4393
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
　　空行
　　响应数据

HTTP响应示例

Hello HTTP!

HTTP请求与响应的流程图

HTTP协议1.0、1.1、2.0以及HTTPS的区别

HTTP1.0

1.浏览器与服务器只保持短暂的连接

浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。

如果一个页面上有很多图画，而网页文件并没有包含真正的图像数据内容，而只是指明了这些图像的URL地址，那么在解析HTML文件的过程中，浏览器为了获取这些图画的内容，就要进行多次的请求和响应，每一次请求和响应都要重新建立建立连接。客户端和服务器端每次建立和关闭连接是一个相对比较费时的过程，并且会严重影响客户机和服务器的性能

2.head of line blocking 队头阻塞问题

HTTP1.0规定下一个请求必须在前一个请求响应到达之前才能发送。假设前一个请求响应一直不到达，那么下一个请求就不发送，同样的后面的请求也给阻塞了。

HTTP1.1

1.支持持久连接

在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。

这主要是通过在http请求头中增加了一个Connection字段，通过设置Keep-Alive可以保持HTTP连接不断开，如果客户端不想持久连接可以在请求头中携带Connection: false来告知服务器关闭请求。

2. 支持请求管道化（`pipelining`）

管线化使得请求能够“并行”传输。举个例子来说，假如响应的主体是一个html页面，页面中包含了很多img，这个时候keep-alive就起了很大的作用，能够进行“并行”发送多个请求，将很多请求放到一个“管道”里一起发送（注意这里的“并行”并不是真正意义上的并行传输，具体解释如下。）

需要注意的是，服务器必须按照客户端请求的先后顺序依次回送相应的结果，以保证客户端能够区分出每次请求的响应内容。

也就是说，HTTP管道化可以让我们把先进先出队列从客户端（请求队列）迁移到服务端（响应队列）。

户端同时发了两个请求分别来获取html和css，假如说服务器的css资源先准备就绪，服务器也会先发送html再发送css。

换句话来说，只有等到html响应的资源完全传输完毕后，css响应的资源才能开始传输。也就是说，不允许同时存在两个并行的响应。

HTTP1.1还是无法解决队头阻塞（head of line blocking）的问题，“管道化”技术存在各种各样的问题，它的开启条件很苛刻，很多浏览器不支持或直接关闭。

（实际上，现阶段的浏览器厂商采取了另外一种做法，它允许我们打开多个TCP的会话。也就是说，上图我们看到的并行，其实是不同的TCP连接上的HTTP请求和响应。这也就是我们所熟悉的浏览器对同域下并行加载6~8个资源的限制。而这，才是真正的并行！）

3.缓存处理

分为本地缓存和协商缓存

（1）本地缓存

在用户第一次访问一个资源文件时，浏览器会将符合条件的资源文件添加到缓存池中。在用户通过浏览器访问一个资源文件时，浏览器会先从本地缓存池中检索有无该文件的缓存，符合命中条件则直接使用该缓存资源，如缓存池中没有该文件，则会去服务器上请求该文件。

HTTP 有两个首部用来控制浏览器是否进行本地缓存：Expires和Cache-Control。HTTP 允许原始服务器向每个文档附加一个“过期日期”，说明可以在多长时间内将这些内容视为新鲜的。

Expires首部
HTTP/ 1.1 200 OK
Date: Sat, 20 Jun 2002, 14:30:00 GMT
content-type: text/plain
Content-length: 67
Expires: Fri, 05 Jul 2002, 05:00:00 GTM
Expires首部比较古老，它接受一个 Date 值指定文件的过期日期。该值是一个绝对日期，浏览器判断文件是否过期时，对比的是用户机器上的时间而不是服务器上的时间。所以使用 Expires 首部可能会出现的一个问题就是，用户本地时间是会影响到原先的缓存意图的。

Cache-Control首部
HTTP/ 1.1 200 OK
Date: Sat, 20 Jun 2002, 14:30:00 GMT
content-type: text/plain
Content-length: 67
Cache-Control: max-age=484200
Cache-Control 接受一个秒数作为文档的生存时间。这个时间是一个相对时间，一个倒计时的秒数，不依赖于机器时间。

如果同时使用 Expires 和 Cache-Control 首部，那么浏览器将以优先值更高的 Cache-Control 为准。

（2）协商缓存（再验证）

当本地缓存文件到达缓存期限时，如果此时用户再次发起请求，浏览器将会给原始服务器发出一个 HTTP 请求，假使服务器的文件并没有进行过任何更新，这时缓存虽然是过期的但实际上仍是有效的。

对于这种情况，如果服务器这时直接重发一份相同的文件，那么就可能造成浪费。针对此，HTTP 也制定了一些策略来进行优化，我们将这个阶段成为协商缓存或再验证。

当缓存未命中时，浏览器需要对它们缓存的副本进行新鲜度检测，看看它们是否仍是服务器上最新的版本。为了有效地进行再验证，HTTP 定义了一些特殊的请求，不用从服务器上获取整个对象，就可以较快地检测出内容是否是最新的。我们将这些请求称为“条件 GET”请求。

当服务器的资源未发生更新时，服务器会返回304 Not Modified响应，不会返回文档的主体，这样一来，网络请求效率就会比普通 GET 请求高一点。
当服务器的资源发生更新时，服务器会返回200响应，并在报文体中携带新的文件内容，这种情况下，与普通 GET 请求获取资源效率无异。

HTTP 定义了 5 个条件请求首部，这里详细介绍最有用的 2 个首部：If-Modified-Since和If-None-Match。所有的条件首部都以前缀If-开头。下表列出了在缓存再验证中使用的条件首部。

条件请求
首部	描述
If-Modified-Since:< date >	如果从指定日期之后文档被修改过了，就执行请求的方法获取新的内容。与服务器响应首部 Last-Modified 配合使用。
If-None-Match:< tag >	服务器可以为文档提供特殊的标签（ETag），而不是将其与最近修改日期相匹配，这些标签就像序列号一样。如果已缓存标签与服务器文档中的标签有所不同，If-None-Match 首部就会执行请求的方法，获取新的内容。与服务器响应首部 ETag 配合使用。
If-Unmodified-Since	在进行部分文件的传输时，获取文件的其余部分之前要确保文件未发生变化，此时这个首部是非常有用的。
If-Range	支持对不完整文档的缓存。用于判断实体是否发生改变，如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体
If-Match	用于与 Web 服务器打交道时的并发控制

下

下面详细介绍其中最重要的前两个首部

If-Modified-Since:Date 再验证

如果自指定日期后，文档被修改了，If-Modified-Since条件就为真，通常这个条件 GET 就会成功执行。携带新首部的新文档会被返回给缓存，新首部除了其他信息之外，还包含了一个新的过期日期。
如果自指定日期后，文档没被修改过，条件就为假，会向客户端返回一个小的304 Not Modified响应报文，不会返回文档的主体。但会返回那些需要在源端更新的首部，比如会发送一个新的过期日期。而一些没有被更新的首部则不会被返回，例如Content-Type。

该字段对应的服务器响应首部为Last-Modified，服务器在返回资源时会携带此首部，如果携带有此首部的资源，浏览器将会将它的值附加在该文档的If-Modified-Since中，在下一次对该资源进行再验证时一同发送。

如果有一个不认识 If-Modified-Since 首部的老服务器收到了条件请求，它会将其作为一个普通的 GET 来解释。在这种情况下，系统仍然能够工作。

If-None-Match:ETag 实体标签再验证

有些情况下只使用最后修改日期来进行再验证是不够的。

有些文档可能会被周期性地重写，但实际包含的数据常常是一样的。尽管内容没有变化，但修改日期会发生变化。
有些文档被修改了，但所做的修改并不重要，比如对拼写或注释的修改。
有些服务器提供的文档会在亚秒间隙发生变化，比如实时监视器，对这些服务器来说，以一秒为粒度的修改日期可能就不够用了。

为了解决这些问题，HTTP 允许用户对被称为实体标签（ETag）的“版本标识符”进行比较。实体标签是附加到文档上的任意标签，通常是由服务器来制定生成规则的。它们可能包含了文档的序列号或版本号，或者是文档内容的校验及其他指纹信息。

当发布者对文档进行修改时，可以修改文档的实体标签来说明这个新的版本。这样，如果实体标签被修改了，缓存就可以用If-None-Match条件首部来 GET 文档的新副本了。

什么时候使用实体标签和最近修改日期？

如果服务器回送了一个实体标签，HTTP/1.1 客户端就必须使用实体标签验证器（If-None-Match）。如果服务器只回送了一个 Last-Modified 值，客户端就可以使用 If-Modified-Since 验证。如果实体标签和最后修改日期都提供了，客户端就会同时使用这两种方法验证将If-None-Match和If-Modified-Since首部都发送给服务器，当两个验证都同时通过时，服务器才会返回 304 Not Modified。

（3）应用层缓存（不属于浏览器缓存，但是也可以了解）

LocalStorage、SessionStorage、Cookie 属于应用层的缓存，是可供开发者支配的缓存空间。

LocalStorage：

大小：一般为 5MB
生命期：除非被清除，否则永久保存
易用性：高，源生接口容易使用
仅在客户端（即浏览器）中保存，不参与和服务器的通信

SessionStorage：

大小：一般为 5MB
生命期：仅在当前会话下有效，关闭页面或浏览器后被清除
易用性：高，源生接口容易使用
仅在客户端（即浏览器）中保存，不参与和服务器的通信

Cookie：

大小：一般为 4KB
生命期：一般由服务器生成，可设置失效时间。如果在浏览器端生成 Cookie，默认是关闭浏览器后失效
易用性：差，需要程序员自己封装，源生的Cookie接口不友好
每次请求会默认携带在HTTP头中，如果使用 cookie 保存过多数据会降低 HTTP 利用率

因为考虑到每个 HTTP 请求都会带着 Cookie 的信息，所以 Cookie 当然是能精简就精简，比较常用的一个应用场景就是判断用户是否登录。针对登录过的用户，服务器端会在他登录时往 Cookie 中插入一段加密过的唯一辨识单一用户的辨识码，下次只要读取这个值就可以判断当前用户是否登录。曾经还有利用 Cookie 来保存用户在电商网站的购物车信息，而如今有了更胜任此场景的 LocalStorage。

LocalStorage 接替了 Cookie 管理购物车的工作，同时也能胜任其他一些工作。比如 HTML5 游戏通常会产生一些本地数据，LocalStorage 也是非常适用的。如果遇到一些内容特别多的表单，为了优化用户体验，我们可能要把表单页面拆分成多个子页面，然后按步骤引导用户填写。这时候 SessionStorage 的作用就发挥出来了。

4.支持断点传输/分块传输

有时用户上传/下载文件需要历时数小时，万一线路中断，不具备断点续传的 HTTP/FTP 服务器或下载软件就只能从头重传，比较好的 HTTP/FTP 服务器或下载软件具有断点续传能力，允许用户从上传/下载断线的地方继续传送，这样大大减少了用户的烦恼。HTTP1.1 协议开始支持获取文件的部分内容，这为并行下载以及断点续传提供了技术支持。

它通过在 Header 里两个参数实现的，客户端发请求时对应的是 Range ，服务器端响应时对应的是 Content-Range。

Range

用于请求头中，指定第一个字节的位置和最后一个字节的位置，一般格式：

Range:(unit=first byte pos)-[last byte pos]

Range 头部的格式有以下几种情况：

Range: bytes=0-499 表示第 0-499 字节范围的内容
Range: bytes=500-999 表示第 500-999 字节范围的内容
Range: bytes=-500 表示最后 500 字节的内容
Range: bytes=500- 表示从第 500 字节开始到文件结束部分的内容
Range: bytes=0-0,-1 表示第一个和最后一个字节
Range: bytes=500-600,601-999 同时指定几个范围

Content-Range

用于响应头中，在发出带 Range 的请求后，服务器会在 Content-Range 头部返回当前接受的范围和文件总大小。一般格式：

Content-Range: bytes (unit first byte pos) - [last byte pos]/[entity legth]

例如：

Content-Range: bytes 0-499/22400 //0－499 是指当前发送的数据的范围，而 22400 则是文件的总大小。

在实际场景中，会出现一种情况，即在终端发起续传请求时，URL 对应的文件内容在服务器端已经发生变化，此时续传的数据肯定是错误的。如何解决这个问题了？显然此时需要有一个标识文件唯一性的方法，方法与本文协商缓存判断文件是否改变的方法一样

5.增加Host字段

主要用来实现虚拟主机技术。虚拟主机（virtual hosting）即共享主机（shared web hosting），可以利用虚拟技术把一台完整的服务器分成若干个主机，因此可以在单一主机上运行多个网站或服务。

举个栗子：有一台服务器A， ip地址为120.79.92.223,有三个分别为www.baidu.com、www.google.com、www.sohu.com的域名解析到了这三个网站上，当我们通过http://www.baidu.com这个网址去访问时，DNS解析出的ip为120.79.92.223，这时候服务器就是根据请求头中的host字段选择使用www.baidu.com这个域名的网站程序对请求做响应，Host 请求头决定着访问哪个虚拟主机。。

6.缺点

（1）HTTP1.1版本的网络延迟问题主要由于队头堵塞导致，虽然通过持久性连接得到改善，但是每一个请求的响应依然需要按照顺序排队，如果前面的响应处理较为耗费时间，那么同样非常耗费性能。

（2）HTTP1.1虽然引进了管道机制，但是当前存在诸多问题，且默认处于关闭状态。

HTTP2.0

1.二进制分帧

HTTP2.0通过在应用层和传输层之间增加一个二进制分帧层，突破了HTTP1.1的性能限制、改进传输性能。

可见，虽然HTTP2.0的协议和HTTP1.x协议之间的规范完全不同了，但是实际上HTTP2.0并没有改变HTTP1.x的语义。简单来说，HTTP2.0只是把原来HTTP1.x的header和body部分用frame重新封装了一层而已。

在二进制分帧层中， HTTP/2 会将所有传输的信息分割为更小的消息和帧（frame）,并对它们采用二进制格式的编码，减少了传输量。其中 HTTP1.x 的首部信息会被封装到 HEADER frame，而相应的 Request Body 则封装到 DATA frame 里面。

2.多路复用（Multiplexing，解决队头阻塞问题）

先了解在HTTP2.0中的几个概念

流（stream）：已建立连接上的双向字节流。
消息：与逻辑消息对应的完整的一系列数据帧。
帧（frame）：HTTP2.0通信的最小单位，每个帧包含帧头部，至少也会标识出当前帧所属的流（stream id）。

从图中可见，所有的HTTP2.0通信都在一个TCP连接上完成，这个连接可以承载任意数量的双向数据流。

每个数据流以消息的形式发送，而消息由一或多个帧组成。这些帧可以乱序发送，然后再根据每个帧头部的流标识符（stream id）重新组装。

举个栗子，每个请求是一个数据流，数据流以消息的方式发送，而消息又分为多个帧，帧头部记录着stream id用来标识所属的数据流，不同属的帧可以在连接中随机混杂在一起。接收方可以根据stream id将帧再归属到各自不同的请求当中去。

另外，多路复用（连接共享）可能会导致关键请求被阻塞。HTTP2.0里每个数据流都可以设置优先级和依赖，优先级高的数据流会被服务器优先处理和返回给客户端，数据流还可以依赖其他的子数据流。

可见，HTTP2.0实现了真正的并行传输，它能够在一个TCP连接上进行任意数量HTTP请求。而这个强大的功能则是基于“二进制分帧”的特性。

下图展示了多路复用和HTTP1.1中的管道化的区别，可见多路复用是可以解决队头阻塞的问题的：

3.首部压缩（Header Compression）

在HTTP1.x中，头部元数据都是以纯文本的形式发送的，通常会给每个请求增加500~800字节的负荷。举个栗子cookie，默认情况下，浏览器会在每次请求的时候，把cookie附在header上面发送给服务器。（由于cookie比较大且每次都重复发送，一般不存储信息，只是用来做状态记录和身份认证）。

但在HTTP2.0中，客户端和服务器端使用“首部表”来跟踪和存储之前发送的键-值对，对于相同的数据，不再通过每次请求和响应发送;通信期间几乎不会改变的通用键-值对(用户代理、可接受的媒体类型,等等)只需发送一次。事实上,如果请求中不包含首部(例如对同一资源的轮询请求),那么首部开销就是零字节。此时所有首部都自动使用之前请求发送的首部。

如果首部发生变化了，那么只需要在Headers帧里面发送变化了的数据，新增或修改的首部帧会被追加到“首部表”。首部表在 HTTP 2.0 的连接存续期内始终存在,由客户端和服务器共同渐进地更新

4.服务端推送（Server Push）

HTTP 2.0 新增的一个强大的新功能，就是服务器可以对一个客户端请求发送多个响应。换句话说，除了对最初请求的响应外，服务器还可以额外向客户端推送资源，而无需客户端明确地请求。

HTTPS

HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全。为了保证这些隐私数据能加密传输，HTTPS应运而生。

HTTPS是一种透过计算机网络进行安全通信的传输协议。HTTPS 经由 HTTP 进行通信，但利用 SSL/TLS （Secure Socket Layer，安全套接字层/Transport Layer Security，传输层安全协议。TLS其实就是SSL的升级版）来加密数据包。HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。

HTTPS 默认工作在 TCP 协议443端口，它的工作流程一般如以下方式：

1.客户端向服务器发起HTTPS请求，连接到服务器的443端口

2.服务器端有一个密钥对，即公钥和私钥，是用来进行非对称加密使用的，服务器端保存着私钥，不能将其泄露，公钥可以发送给任何人。

3.服务器将自己的公钥发送给客户端。

4.客户端收到服务器端的公钥之后，会对公钥进行检查，验证其合法性，如果发现发现公钥有问题，那么HTTPS传输就无法继续。（严格的说，这里应该是验证服务器发送的数字证书的合法性，比如颁发机构，过期时间等等。）如果公钥合格，那么客户端会生成一个随机值，这个随机值就是用于进行对称加密的密钥，我们将该密钥称之为client key，即客户端密钥，这样在概念上和服务器端的密钥容易进行区分。然后用服务器的公钥对客户端密钥进行非对称加密，这样客户端密钥就变成密文了，至此，HTTPS中的第一次HTTP请求结束。

5.客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端密钥发送给服务器。

6.服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥，然后用客户端密钥对数据进行对称加密，这样数据就变成了密文。

7.然后服务器将加密后的密文发送给客户端。

8.客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成。

HTTPS之所以采用非对称加密和对称加密相结合的方式，是因为非对称加密的性能相对对称加密来说会慢上几倍甚至几百倍，比较消耗系统资源。

HTTP与HTTPS的区别

1.HTTP 明文传输，数据都是未加密的，安全性较差，HTTPS（SSL+HTTP）数据传输过程是加密的，安全性较好。

2.使用 HTTPS 协议需要到 CA（Certificate Authority，数字证书认证机构）申请证书，一般免费证书较少，因而需要一定费用。证书颁发机构如：Symantec、Comodo、GoDaddy 和 GlobalSign 等。

3.HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS除了 TCP 的三个包，还要加上 ssl 握手需要的 9 个包，所以一共是 12 个包。

4.http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。

5.HTTPS 其实就是建构在 SSL/TLS 之上的 HTTP 协议，所以，HTTPS 比 HTTP 要更耗费服务器资源。

HTTPS优化

1、HSTS重定向技术：将http自动转换为https，减少301重定向

2、TLS握手优化：在TLS握手完成前客户端就提前向服务器发送数据

3、会话标识符：服务器记录下与某客户端的会话ID，下次连接客户端发ID过来就可以直接用之前的私钥交流了

4、OSCP Stapling：服务器将带有 CA 机构签名的 OCSP 响应在握手时发给客户端，省的客户端再去CA查询

5、完全前向加密PFS：使用更牛逼复杂的秘钥算法

梨子的博客

发布了8 篇原创文章 · 获赞 0 · 访问量 233

私信关注

HTTP1.0、1.1、2.0及HTTPS

HTTP协议过程

一、客户端发送请求：