目录

HTTP

HTTP 简介

HTTP消息结构

请求报文

响应报文

头部信息

头部字段整理

请求方法

状态码

form表单中enctype数据类型的使用（待完善）

HTTP 2.0

二进制传输

多路复用

Header 压缩

服务端 Push

多版本HTTP比较

HTTPS

密码学基础

对称加密

非对称加密

HTTPS通信过程

参考资料：《计算机网络 自顶向下方法第6版》

HTTP

HTTP 简介

HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写,是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。。

HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）。

HTTP 工作原理

HTTP协议工作于客户端-服务端架构上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。

Web服务器有：Apache服务器，IIS服务器（Internet Information Services）等。

Web服务器根据接收到的请求后，向客户端发送响应信息。

HTTP默认端口号为80，但是你也可以改为8080或者其他端口。

HTTP特点：

• HTTP是无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
• HTTP是媒体独立的：这意味着，只要客户端和服务器知道如何处理的数据内容，任何类型的数据都可以通过HTTP发送。客户端以及服务器指定使用适合的MIME-type内容类型。
• HTTP是无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
• 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。

以下图表展示了HTTP协议通信流程：

HTTP消息结构

请求报文

客户端发送一个HTTP请求到服务器的请求消息包括以下格式：请求行（request line）、首部行（header line）（请求头部啥的也行）、空行和实体主体（entity body）四个部分组成，下图给出了请求报文的一般格式。（配图来源《计算机网络自顶向下方法 第6版》）

• 请求行
  • 请求类型
  • 要访问的资源
  • HTTP协议版本号
• 请求头（首部行）
  • 用来说明服务器要使用的附加信息（一些键值对）
  • 例如：User-Agent、 Accept、Content-Type、Connection
• 空行
  • 分割请求头与请求体
• 请求体（实体主体）
  • 可以添加任意的其他数据

响应报文

HTTP响应也由四个部分组成，分别是：状态行（status line）、首部行（header line 也有叫消息报头）、空行和实体主体（entity body 也有叫响应正文）。

可以对比Wireshark捕获的来看一下

• 状态行
  • HTTP协议版本号
  • 状态码
  • 状态消息
• 消息报头
  • 说明客户端要使用的一些附加信息
  • 如：Content-Type、charset、响应的时间
• 响应正文
  • 返回给客户端的文本信息

头部信息（首部行的分类）

HTTP的头域包括通用头、请求头、响应头和实体头四个部分。每个头域由一个域名，冒号（:）和域值三部分组成。

通用头域：请求和响应消息都支持的头域，可以在客户端、服务器和其他应用程序之间提供一些非常有用的通用功能，如Date头部。

请求头部头域是请求报文特有的，它们为服务器提供了一些额外信息，比如客户端希望接收什么类型的数据，如Accept头部。

响应头域用于服务器为客户端提供信息，比如，客服端在与哪种类型的服务器进行交互，如Server头部。

实体头部：请求消息和响应消息都可包含实体信息，比如，可以用实体头部来说明实体主体部分的数据类型，如Content-Type头部。

常见头部

• Accept
  • 在请求中使用Accept可申明想要的数据格式
• Accept-Encoding
  • 告诉服务端使用什么的方式来进行压缩
  • 例如：gzip、deflate、br
• Accept-Language
  • 描述语言信息
• User-Agent
  • 用来描述客户端浏览器相关信息
  • 可以用来区分PC端页面和移动端页面响应头

• Content-Type
  • 对应Accept，从请求中的Accept支持的数据格式中选一种来返回
• Content-Encoding
  • 对应 Accept-Encoding，指服务端到底使用的是那种压缩方式
• Content-Language
  • 对应Accept-Language

头部字段整理

请求方法

HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法。

HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

HEAD方法：当服务器收到使用HEAD方法的请求时，将会用一个HTTP报文进行响应，但是并不返回请求对象。应用程序开发者常用HEAD方法进行调试跟踪。

PUT方法常与Web发行工具联合使用，它允许用户上传对象到指定的Web服务器上指定的路径（目录），PUT方法也被那些需要向Web服务器上传对象的应用程序使用。

DELETE方法允许用户或应用程序删除Web服务器上的对象。

Post 和 Get 的区别

GET在浏览器回退时是无害的，而POST会再次提交

• Get请求能缓存，Post不能
• Post相对Get相对安全一些，因为Get请求都包含在URL中，而且会被浏览器保存记录，Post不会。但是再抓包的情况下都是一样的。
• Post 可以通过 request body来传输比 Get 更多的数据
• URL有长度限制，会影响 Get 请求，但是这个长度限制是浏览器规定的
• Post 支持更多的编码类型且不对数据类型限制
• POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok(返回数据)

这里引入副作用和幂等的概念。

副作用指对服务器上的资源做改变，搜索是无副作用的，注册是副作用的。

幂等指发送 M 和 N 次请求（两者不相同且都大于 1），服务器上资源的状态一致，比如注册 10 个和 11 个帐号是不幂等的，对文章进行更改 10 次和 11 次是幂等的。

在规范的应用场景上说，Get 多用于无副作用，幂等的场景，例如搜索关键字。Post 多用于副作用，不幂等的场景，例如注册。

状态码

常用：

form表单中enctype数据类型的使用（待完善）

• application/x-www-form-urlencoded
  • key=value&key=value 格式
• multipart/form-data
  • 用于提交文件
  • multipart表示请求是由多个部分组成（因为上传文件的时候文件不能以字符串形式提交，需要单独分出来）
  • boundary 用来分隔不同部分
• text/plain

HTTP 2.0

https://blog.csdn.net/zqjflash/article/details/50179235

HTTP 2.0 相比于 HTTP 1.X，可以说是大幅度提高了 web 的性能。

在 HTTP 1.X 中，为了性能考虑，我们会引入雪碧图、将小图内联、使用多个域名等等的方式。这一切都是因为浏览器限制了同一个域名下的请求数量，当页面中需要请求很多资源的时候，队头阻塞（Head of line blocking）会导致在达到最大请求数量时，剩余的资源需要等待其他资源请求完成后才能发起请求。关于同源和跨域的问题恐怕得另作文章了，可以先看下阮一峰老师的

。http://www.ruanyifeng.com/blog/2016/04/same-origin-policy.html

二进制传输

HTTP 2.0 中所有加强性能的核心点在于此。在之前的 HTTP 版本中，我们是通过文本的方式传输数据。在 HTTP 2.0 中引入了新的编码机制，所有传输的数据都会被分割，并采用二进制格式编码。

多路复用

在 HTTP 2.0 中，有两个非常重要的概念，分别是帧（frame）和流（stream）。

帧代表着最小的数据单位，每个帧会标识出该帧属于哪个流，流也就是多个帧组成的数据流。

多路复用，就是在一个 TCP 连接中可以存在多条流。换句话说，也就是可以发送多个请求，对端可以通过帧中的标识知道属于哪个请求。通过这个技术，可以避免 HTTP 旧版本中的队头阻塞问题，极大的提高传输性能。

Header 压缩

在 HTTP 1.X 中，我们使用文本的形式传输 header，在 header 携带 cookie 的情况下，可能每次都需要重复传输几百到几千的字节。

在 HTTP 2.0 中，使用了 HPACK 压缩格式对传输的 header 进行编码，减少了 header 的大小。并在两端维护了索引表，用于记录出现过的 header ，后面在传输过程中就可以传输已经记录过的 header 的键名，对端收到数据后就可以通过键名找到对应的值。

服务端 Push

在 HTTP 2.0 中，服务端可以在客户端某个请求后，主动推送其他资源。

可以想象以下情况，某些资源客户端是一定会请求的，这时就可以采取服务端 push 的技术，提前给客户端推送必要的资源，这样就可以相对减少一点延迟时间。当然在浏览器兼容的情况下你也可以使用 prefetch。

多版本HTTP比较

参考 https://www.cnblogs.com/heluan/p/8620312.html

• HTTP/1.* 一次请求-响应，建立一个连接，用完关闭；每一个请求都要建立一个连接；
• HTTP/1.1 Pipeling解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的队头阻塞；
• HTTP/2多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行；

HTTPS

http默认采用80作为通讯端口，对于传输采用不加密的方式，https默认采用443，对于传输的数据进行加密传输。

密码学基础

明文： 明文指的是未被加密过的原始数据。

密文：明文被某种加密算法加密之后，会变成密文，从而确保原始数据的安全。密文也可以被解密，得到原始的明文。

密钥：密钥是一种参数，它是在明文转换为密文或将密文转换为明文的算法中输入的参数。密钥分为对称密钥与非对称密钥，分别应用在对称加密和非对称加密上。

对称加密

对称加密又叫做私钥加密，即信息的发送方和接收方使用同一个密钥去加密和解密数据。对称加密的特点是算法公开、加密和解密速度快，适合于对大数据量进行加密，常见的对称加密算法有DES、3DES、TDEA、Blowfish、RC5和IDEA。

其加密过程如下：明文 + 加密算法 + 私钥 => 密文

解密过程如下：密文 + 解密算法 + 私钥 => 明文

对称加密中用到的密钥叫做私钥，私钥表示个人私有的密钥，即该密钥不能被泄露。

其加密过程中的私钥与解密过程中用到的私钥是同一个密钥，这也是称加密之所以称之为“对称”的原因。由于对称加密的算法是公开的，所以一旦私钥被泄露，那么密文就很容易被破解，所以对称加密的缺点是密钥安全管理困难。

非对称加密

非对称加密也叫做公钥加密。非对称加密与对称加密相比，其安全性更好。对称加密的通信双方使用相同的密钥，如果一方的密钥遭泄露，那么整个通信就会被破解。而非对称加密使用一对密钥，即公钥和私钥，且二者成对出现。私钥被自己保存，不能对外泄露。公钥指的是公共的密钥，任何人都可以获得该密钥。用公钥或私钥中的任何一个进行加密，用另一个进行解密。

被公钥加密过的密文只能被私钥解密，过程如下：

明文 + 加密算法 + 公钥 => 密文， 密文 + 解密算法 + 私钥 => 明文

被私钥加密过的密文只能被公钥解密，过程如下：

明文 + 加密算法 + 私钥 => 密文， 密文 + 解密算法 + 公钥 => 明文

由于加密和解密使用了两个不同的密钥，这就是非对称加密“非对称”的原因。 非对称加密的缺点是加密和解密花费时间长、速度慢，只适合对少量数据进行加密。 在非对称加密中使用的主要算法有：RSA、Elgamal、Rabin、D-H、ECC（椭圆曲线加密算法）等。

HTTPS通信过程

HTTPS协议 = HTTP协议 + SSL/TLS协议，在HTTPS数据传输的过程中，需要用SSL/TLS对数据进行加密和解密，需要用HTTP对加密后的数据进行传输，由此可以看出HTTPS是由HTTP和SSL/TLS一起合作完成的。

SSL的全称是Secure Sockets Layer，即安全套接层协议，是为网络通信提供安全及数据完整性的一种安全协议。SSL协议在1994年被Netscape发明，后来各个浏览器均支持SSL，其最新的版本是3.0。

TLS的全称是Transport Layer Security，即安全传输层协议，最新版本的TLS（Transport Layer Security，传输层安全协议）是IETF（Internet Engineering Task Force，Internet工程任务组）制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本。在TLS与SSL3.0之间存在着显著的差别，主要是它们所支持的加密算法不同，所以TLS与SSL3.0不能互操作。虽然TLS与SSL3.0在加密算法上不同，但是在我们理解HTTPS的过程中，我们可以把SSL和TLS看做是同一个协议。

HTTPS为了兼顾安全与效率，同时使用了对称加密和非对称加密。数据是被对称加密传输的，对称加密过程需要客户端的一个密钥，为了确保能把该密钥安全传输到服务器端，采用非对称加密对该密钥进行加密传输，总的来说，对数据进行对称加密，对称加密所要使用的密钥通过非对称加密传输。

HTTPS在传输的过程中会涉及到三个密钥：

• 服务器端的公钥和私钥，用来进行非对称加密
• 客户端生成的随机密钥，用来进行对称加密

一个HTTPS请求实际上包含了两次HTTP传输，可以细分为8步。

1. 客户端向服务器发起HTTPS请求，连接到服务器的443端口
2. 服务器端有一个密钥对，即公钥和私钥，是用来进行非对称加密使用的，服务器端保存着私钥，不能将其泄露，公钥可以发送给任何人。
3. 服务器将自己的公钥发送给客户端。
4. 客户端收到服务器端的公钥之后，会对公钥进行检查，验证其合法性，如果发现发现公钥有问题，那么HTTPS传输就无法继续。严格的说，这里应该是验证服务器发送的数字证书的合法性。如果公钥合格，那么客户端会生成一个随机值，这个随机值就是用于进行对称加密的密钥，我们将该密钥称之为client key，即客户端密钥，这样在概念上和服务器端的密钥容易进行区分。然后用服务器的公钥对客户端密钥进行非对称加密，这样客户端密钥就变成密文了，至此，HTTPS中的第一次HTTP请求结束。
5. 客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端密钥发送给服务器。
6. 服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥，然后用客户端密钥对数据进行对称加密，这样数据就变成了密文。
7. 然后服务器将加密后的密文发送给客户端。
8. 客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成。

SSL协议的脆弱性分析

1. 因为SSL协议设计初衷是对Web站点及网上交易进行安全性保护，使消费者明白正在和谁进行交易要比使商家知道谁正在付费更为重要，为了不致于由于安全协议的使用而导致网络性能大幅下降， SSL协议并不是默认地要求进行客户鉴别，这样做虽然有悖于安全策略，但却促进了SSL的广泛应用。
2. 针对这个问题，可在必要的时候配置SSL协议，使其选择对客户端进行认证鉴别。
3. SSL协议需要在握手之前建立TCP连接，因此不能对UDP应用进行保护。如果要兼顾UDP协议层之上的安全保护，可以采用IP层的安全解决方案。
4. 由于SSL只对应用数据进行保护，数据包的IP头和TCP头仍然暴露在外，通过检查没有加密的IP源和目的地址以及TCP端口号或者检查通信数据量，一个通信分析者依然可以揭示哪一方在使用什么服务，有时甚至揭露商业或私人关系的秘密。
5. 除非SSL的工程实现大部分驻留在硬件中，否则主密钥将会存留在主机的主存储器中，这就意味着任何可以读取SSL进程存储空间的攻击者都能读取主密钥，因此，不可能面对掌握机器管理特权的攻击者而保护SSL连接，这个问题要依靠用户管理策略来解决。

TO BE CONTINUE......