**     **之前在https://blog.csdn.net/fengbingchun/article/details/85039308 中介绍过HTTP协议，在https://blog.csdn.net/fengbingchun/article/details/85208853 中介绍过HTTPS协议。

**      HTTP(HyperText Transfer Protocol****，超文本传输协议)****：是一种用于分布式、协作式和超媒体信息系统的应用层协议**。HTTP是万维网的数据通信的基础。通过HTTP或者HTTPS协议请求的资源由统一资源标识符(Uniform Resource Identifiers，URI)来标识。

**      HTTP协议概述：HTTP****是一个客户端终端(****用户)****和服务器端(****网站)****请求和应答的标准(TCP)**。通过使用网页浏览器、网络爬虫或者其它的工具，客户端发起一个HTTP请求到服务器上指定端口(默认端口为80)。我们称这个客户端为用户代理程序(user agent)。应答的服务器上存储着一些资源，比如HTML文件和图像。我们称这个应答服务器为源服务器(origin server)。在用户代理和源服务器中间可能存在多个”中间层”，比如代理服务器、网关或者隧道(tunnel)。

**      通常，由HTTP客户端发起一个请求，创建一个到服务器指定端口(默认是80端口)的TCP连接。HTTP服务器则在那个端口监听客户端的请求。一旦收到请求，服务器会向客户端返回一个状态，比如”HTTP/1.1 200 OK”，以及返回的内容，如请求的文件、错误消息、或者其它信息**。

**      HTTP版本**：超文本传输协议已经演化出了很多版本，它们中的大部分都是向下兼容的。在RFC 2145中描述了HTTP版本号的用法。客户端在请求的开始告诉服务器它采用的协议版本号，而后者则在响应中采用相同或者更早的协议版本。主要版本包括：HTTP/0.9、HTTP/1.0、HTTP/1.1、HTTP/2.0。

**      HTTP/1.1**：持久连接被默认采用，并能很好地配合代理服务器工作。还支持以管道方式同时发送多个请求，以便降低线路负载，提高传输速度。HTTP/1.1相较于HTTP/1.0协议的区别主要体现在：缓存处理、带宽优化及网络连接的使用、错误通知的管理、消息在网络中的发送、互联网地址的维护、安全性及完整性。

**     **HTTP/1.1版的头信息肯定是文本(ASCII编码)，数据体可以是文本，也可以是二进制。HTTP/2则是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为”帧”(frame)：头信息帧和数据帧。

**      状态码**：所有HTTP响应的第一行都是状态行，依次是当前HTTP版本号，3位数字组成的状态代码，以及描述状态的短语，彼此由空格分隔。如下图所示：

**     **状态代码的第一个数字代表当前响应的类型：

**     **(1). 1xx消息：请求已被服务器接收，继续处理。

**     **(2). 2xx成功：请求已成功被服务器接收、理解、并接受。

**     **(3). 3xx重定向：需要后续操作才能完成这一请求。

**     **(4). 4xx请求错误：请求含有词法错误或者无法被执行。

**     **(5). 5xx服务器错误：服务器在处理某个正确请求时发生错误。

**      持续连线**：在HTTP 0.9和1.0中，TCP连线在每一次请求/回应对之后关闭。在HTTP 1.1中，引入了保持连线的机制，一个连接可以重复在多个请求/回应使用。持续连线的方式可以大大减少等待时间，因为在发出第一个请求后，双方不需要重新运行TCP握手程序。

**      HTTP协议工作于客户端----**服务端架构上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。Web服务器根据接收到的请求后，向客户端发送响应信息。HTTP默认端口为80，但是也可以改为8080****或者其它端口。一个HTTP客户端是一个应用程序(Web浏览器或其它任何客户端)，通过连接到服务器达到向服务器发送一个或多个HTTP的请求的目的。一个HTTP服务器同样也是一个应用程序(通常是一个Web服务，如Apache Web服务器或IIS服务器等)，通过接收客户端的请求并向客户端发送HTTP响应数据。HTTP使用统一资源标识符(URI)来传输数据和建立连接。HTTP响应分为Header和Body两部分(Body是可选项)。

**      HTTPS(HyperText Transfer Protocol Secure，超文本传输安全协议)：是一种透过计算机网络进行安全通信的传输协议。HTTPS经由HTTP进行通信，但利用SSL/TLS来加密数据包。HTTPS****开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性**。

**      HTTPS的主要思想：是在不安全的网络上创建一安全信道，并可在使用适当的加密包和服务器证书可被验证且可被信任时，对窃听和中间人攻击提供合理的防护**。

**     **HTTPS的信任继承基于预先安装在浏览器中的证书颁发机构(如Symantec、Comodo、GoDaddy和GlobalSign等)(意即”我信任证书颁发机构告诉我应该信任的”)。因此，一个到某网站的HTTPS连接可被信任，当且仅当：

**     **(1). 用户相信他们的浏览器正确实现了HTTPS且安装了正确的证书颁发机构；

**     **(2). 用户相信证书颁发机构仅信任合法的网站；

**     **(3). 被访问的网站提供了一个有效的证书，意即，它是由一个被信任的证书颁发机构签发的(大部分浏览器会对无效的证书发出警告)；

**     **(4). 该证书正确地验证了被访问的网站(如，访问https://example.com时收到了给example.com而不是其它组织的证书）；

**     **(5). 或者互联网上相关的节点是值得信任的，或者用户相信本协议的加密层(TLS或SSL)不能被窃听者破坏。

**      HTTPS与HTTP的差异**：**与HTTP的URL由”http://”起始且默认使用端口80不同，HTTPS的URL由”https://”**起始且默认使用端口443。HTTP是不安全的，且攻击者通过监听和中间人攻击等手段，可以获取网站帐户和敏感信息等。HTTPS被设计为可防止前述攻击，并在正确配置时被认为是安全的。

**     **HTTP协议和安全协议同属于应用层(OSI模型的最高层)，具体来讲，安全协议工作在HTTP之下，运输层之上。安全协议向运行HTTP的进程提供一个类似于TCP的套接字，供进程向其中注入报文，安全协议将报文加密并注入运输层套接字；或是从运输层获取加密报文，解密后交给对应的进程。严格地讲，HTTPS并不是一个单独的协议，而是对工作在一加密连接(TLS****或SSL)上的常规HTTP协议的称呼。

**      HTTPS报文中的任何东西都被加密，包括所有报头和荷载**。

**     **要使一网络服务器准备好接受HTTPS连接，管理员必须创建一数字证书，并交由证书颁发机构签名以使浏览器接受。证书颁发机构会验证数字证书持有人和其声明的为同一人。浏览器通常都预装了证书颁发机构的证书，所以他们可以验证该签名。

**     **HTTPS是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL。凡是使用了HTTPS的网站，都可以通过点击浏览器地址栏的锁头标志来查看网站认证之后的真实信息，也可以通过CA机构颁发的安全签章来查询。

**     **HTTP协议被用于在Web浏览器和网站服务器之间传递信息。HTTP****协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此HTTP协议不适合传输一些敏感信息，比如信用卡号、密码等。为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL协议，SSL依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。不使用SSL/TLS的HTTP****通信，就是不加密的通信，所有信息明文传播。

**      传输层安全协议(Transport Layer Security，TLS)及其前身安全套接层(Secure Sockets Layer，SSL)**是一种安全协议，目的是为互联网通信提供安全及数据完整性保障。SSL/TLS****协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

**     **SSL包含记录层(Record Layer)和传输层，记录层协议确定传输层数据的封装格式。传输层安全协议使用X.509认证，之后利用非对称加密演算来对通信方做身份认证，之后交换对称密钥作为会谈密钥(Session key)。这个会谈密钥是用来将通信两方交换的数据做加密，保证两个应用间通信的保密性和可靠性，使客户与服务器应用之间的通信不被攻击者窃听。

**     **TLS协议采用主从式架构模型，用于在两个应用程序间透过网络创建起安全的连线，防止在交换数据时受到窃听及篡改。TLS协议的优势是与高层的应用层协议(如HTTP、FTP、Telnet等)无耦合。应用层协议能透明地运行在TLS协议之上，由TLS协议进行创建加密通道需要的协商和认证。应用层协议传送的数据在通过TLS协议时都会被加密，从而保证通信的私密性。

**     **TLS协议是可选的，必须配置客户端和服务器才能使用。主要有两种方式实现这一目标：一个是使用统一的TLS协议通信端口(例如：用于HTTPS的端口443)；另一个是客户端请求服务器连接到TLS时使用特定的协议机制(例如：邮件、新闻协议和STARTTLS)。一旦客户端和服务器都同意使用TLS协议，他们通过使用一个握手过程协商出一个有状态的连接以传输数据。通过握手，客户端和服务器协商各种参数用于创建安全连接：

**     **(1). 当客户端连接到支持TLS协议的服务器要求创建安全连接并列出了受支持的密码组合(加密密码算法和加密哈希函数)，握手开始。

**     **(2). 服务器从该列表中决定加密和散列函数，并通知客户端。

**     **(3). 服务器发回其数字证书，此证书通常包含服务器的名称、受信任的证书颁发机构(CA)和服务器的公钥。

**     **(4). 客户端确认其颁发的证书的有效性。

**     **(5). 为了生成会话密钥用于安全连接，客户端使用服务器的公钥加密随机生成的密钥，并将其发送到服务器，只有服务器才能使用自己的私钥解密。

**     **(6). 利用随机数，双方生成用于加密和解密的对称密钥。

**     **这就是TLS协议的握手，握手完毕后的连接是安全的，直到连接(被)关闭。如果上述任何一个步骤失败，TLS握手过程就会失败，并且断开所有的连接。

**      在应用程序设计中，TLS通常在传输层协议之上实现**。

**      SSL协议的工作方式**：客户端要收发几个握手信号，如下图所示

**     **(1). 发送一个”Client Hello”消息，内容包括：支持的协议版本，比如TLS1.0版，一个客户端生成的随机数(稍后用于生成”会话密钥”)，支持的加密算法(如RSA公钥加密)和支持的压缩算法。

**     **(2). 然后收到一个”Server Hello”消息，内容包括：确认使用的加密通信协议版本，比如TLS 1.0版本(如果浏览器与服务器支持的版本不一致，服务器关闭加密通信)，一个服务器生成的随机数(稍后用于生成”对话密钥”)，确认使用的加密方法(如RSA公钥加密)，服务器证书。

**     **(3). 当双方知道了连接参数，客户端与服务器交换证书(依靠被选择的公钥系统)。这些证书通常基于X.509，不过已有草案支持以OpenPGP为基础的证书。

**     **(4). 服务器请求客户端公钥。客户端有证书即双向身份认证，没证书时随机生成公钥。

**     **(5). 客户端与服务器通过公钥保密协商共同的主私钥(双方随机协商)，这通过精心谨慎设计的伪随机数功能实现。结果可能使用Diffie-Hellman交换，或简化的公钥加密，双方各自用私钥解密。所有其他关键数据的加密均使用这个”主密钥”。数据传输中记录层(Record layer)用于封装更高层的HTTP等协议。记录层数据可以被随意压缩、加密，与消息验证码压缩在一起。每个记录层包都有一个Content-Type段用以记录更上层用的协议。

**      HTTP请求方法**：

**     **HTTP/1.0定义了三种：GET、POST、HEAD。

**     **HTTP/1.1新增了六种：OPTIONS、PUT、PATCH、DELETE、TRACE、CONNECT，来以不同方式操作指定的资源。

**     **HTTP客户端会根据需要构建合适的HTTP请求方法，而HTTP服务器会根据不同的HTTP请求方法做出不同的响应。

**     **1. GET：向指定的资源发出”显示”请求。使用GET方法应该只用在读取数据，即获取资源，而不应当被用于产生”副作用”的非幂等的操作中，例如在Web Application中。GET被认为是不安全的方法，一个原因是GET可能会被网络蜘蛛等随意访问。

**     **GET方法提交的数据会直接填充在请求报文的URL上。

**     **2. HEAD：与GET方法一样，都是向服务器发出指定资源的请求。只不过服务器在响应HEAD请求时将不会回传资源的内容部分，即响应主体。它的好处在于，使用这个方法可以在不必传输全部内容的情况下，就可以获取服务器的响应头信息。

**      HEAD方法常被用于客户端查看服务器的性能**。GET方法有实体，HEAD方法无实体。

**     **3. POST：向指定资源提交数据，请求服务器进行处理(例如提交表单或者上传文件)。数据被包含在请求文本中(在body部分)。这个请求可能会创建新的资源或修改现有资源，或二者皆有。POST是非幂等的方法。

**     **POST方法提交的数据会附在正文上，一般请求正文的长度是没有限制的，但不推荐过长。POST方法的安全性比GET方法要高。

**     **4. PUT：向指定资源位置上传其最新内容。PUT是幂等的方法。通过该方法客户端可以将指定资源的最新数据传送给服务器取代指定的资源的内容。

**     **5. DELETE：请求服务器删除Request-URI(Uniform Resource Identifier，统一资源标识符)所标识的资源。与PUT方法相反，DELETE请求后指定资源会被删除。DELETE是幂等的方法。

**     **6. TRACE：回显服务器收到的请求，主要用于测试或诊断。

**     7. OPTIONS：这个方法可使服务器传回该资源所支持的所有HTTP请求方法**。用”*”来代替资源名称，向Web服务器发送OPTIONS请求，可以测试服务器功能是否正常运作。与HEAD类似，一般也是用于客户端查看服务器的性能。

**     **8. CONNECT：HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接(经由非加密的HTTP代理服务器)。

**      CONNECT方法要求在与代理服务器通信时建立隧道，实现用隧道协议进行TCP****通信**。

**     **9. PATCH：PATCH方法出现的较晚，是对PUT方法的补充，用来对已知资源进行局部更新。

**     **PATCH一般用于资源的部分更新，而PUT一般用于资源的整体更新。当资源不存在时，PATCH会创建一个新的资源，而PUT只会对已在资源进行更新。

**     **方法名称是区分大小写的。当某个请求所针对的资源不支持对应的请求方法的时候，服务器应当返回状态码405(Method Not Allowed)，当服务器不认识或者不支持对应的请求方法的时候应当返回状态码501(Not Implemented)。

**      幂等**：对同一个系统，使用同样的条件，一次请求和重复的多次请求对系统资源的影响是一致的。

**     HTTP服务器至少应该实现GET和HEAD方法，其它方法都是可选的**。当然，所有的方法支持的实现都应当匹配下述的方法各自的语义定义。此外，除了上述方法，**特定的HTTP****服务器还能够扩展自定义的方法**。

**     **可通过Wireshark来获取采用的是哪种请求方法，如下图所示：

**     **以上内容主要来自于网络整理。

**     **GitHub：https://github.com/fengbingchun/OpenSSL_Test