http及https通信原理

HTTP

HTTP 是一种 超文本传输协议(Hypertext Transfer Protocol)， HTTP 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范

HTTP 主要内容分为三部分，超文本（Hypertext）、传输（Transfer）、协议（Protocol）。

HTTP 1.0

是在 1996 年引入的，从那时开始，它的普及率就达到了惊人的效果。

HTTP 1.0 仅仅提供了最基本的认证，这时候用户名和密码还未经加密，因此很容易收到窥探。

HTTP 1.0 被设计用来使用短链接，即每次发送数据都会经过TCP 的三次握手和四次挥手，效率比较低。

HTTP 1.0 只使用header中的If-Modified-Since和Expires作为缓存失效的标准。

HTTP 1.0 不支持断点续传，也就是说，每次都会传送全部的页面和数据。

HTTP 1.0 认为每台计算机只能绑定一个IP，所以请求消息中的URL并没有传递主机名（hostname）

HTTP 1.1

HTTP 1.1 是 HTTP 1.0 开发三年后出现的，也就是1999年，它做出了以下方面的变化

HTTP 1.1 使用了摘要算法来进行身份验证

HTTP 1.1 默认使用长连接，长连接就是只需一次建立就可以传输多次数据，传输完成后，只需要一次切断连接即可。长连接的连接时长可以通过请求头中的 keep-alive 来设置

HTTP 1.1 中新增加了 E-tag，If-Unmodified-Since, If-Match, If-None-Match 等缓存控制标头来控制缓存失效。

HTTP 1.1 支持断点续传，通过使用请求头中的Range来实现。

HTTP 1.1 使用了虚拟网络，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。

HTTP 1.0 和 HTTP 1.1 的主要区别是什么。

• 长连接 :

在 HTTP/1.0 中，默认使用的是短连接，也就是每次请求都要重新建立一次连接。

HTTP 是基于 TCP/IP 协议的，每一次建立或者断开连接，都需要三次握手四次挥手的开销，如果每次请求都要这样的话，开销会比较大， 因此最好能维持一个长连接，可以用长连接来发多个请求。

HTTP 1.1 起，默认使用长连接 Connection： keep-alive。

HTTP/1.1 的持续连接，有非流水线方式和流水线方式。

流水线方式，是客户在收到HTTP的响应报文之前，就能接着发送新的请求报文；

与之相对应的非流水线方式，是客户在收到前一个响应后才能发起下一个请求；

• 错误响应码：

在 HTTP 1.1 中，新增了24 个错误状态响应码，如409（Conflict）：表示请求的资源与资源的当前状态发生冲突； 410（Gone）：表示服务器上的某个资源被永久性的删除；

• 缓存处理：

HTTP 1.0 中，主要使用 header 头里的 If-Modified-Since、Expires 来做为缓存判断的标准；

HTTP 1.1，则引入了更多的缓存控制策略，如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match 等；

• 带宽优化及网络连接的使用： HTTP 1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象传送了过来，并且不支持断点续传功能；

HTTP 1.1 中，则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content）， 这样方便开发者自由的选择，以便于充分利用带宽和连接。

HTTP 2.0（RFC7540，2015.5）

是2015年开发出来的标准，它主要做的改变如下

• 头部压缩，由于HTTP 1.1经常会出现 User-Agent、Cookie、Accept、Server、Range等字段可能会占用几百甚至几千字节， 而 Body 却经常只有几十字节，所以导致头部偏重。 HTTP 2.0 使用 HPACK 算法进行压缩。

• 二进制格式，HTTP 2.0使用了更加靠近TCP/IP的二进制格式，而抛弃了ASCII码，提升了解析效率

• 强化安全，由于安全已经成为重中之重，所以HTTP2.0一般都跑在 HTTPS 上。

• 多路复用，即每一个请求都是是用作连接共享。一个请求对应一个id，这样一个连接上可以有多个请求。

SPDY协议（2012-2016）

因为HTTP/1.x的问题，我们会引入雪碧图、将小图内联、使用多个域名等等的方式来提高性能。

不过这些优化都绕开了协议，直到2009年，谷歌公开了自行研发的SPDY 协议，主要解决HTTP/1.1效率不高的问题。

谷歌推出SPDY，才算是正式改造HTTP协议本身。

降低延迟，压缩header等等，SPDY的实践证明了这些优化的效果，也最终带来HTTP/2的诞生。

SPDY协议在Chrome浏览器上证明可行以后，就被当作HTTP/2的基础，主要特性都在HTTP/2之中得到继承。

HTTP/2应用状况

截止2019.5.17 号，互联网上使用HTTP/2 协议的站点已经达到37.2%

快速推广的原因

• 未改变 HTTP/1.1 的语义

• 基于TCP，仅在应用层变动

对比：

https://http2.akamai.com/demo

http2.akamai.com/demo

HTTP3？

运行在QUIC之上的HTTP协议被称为 HTTP/3(HTTP-over-QUIC)

QUIC协议(Quick UDP Internet Connection)基于UDP，正是看中了UDP的速度与效率。

同时QUIC也整合了 TCP、TLS 和 HTTP/2 的优点，并加以优化。

特点:

减少了握手的延迟(1-RTT或0-RTT)

多路复用，并且没有TCP的阻塞问题

连接迁移，(主要是在客户端)当由 Wifi 转移到 4G 时，连接不会被断开。

HTTP 3与HTTP 1.1和HTTP 2没有直接的关系，也不是http2的扩展

HTTP 3将会是一个全新的WEB协议

HTTP 3目前处于制订和测试阶段

HTTP2的问题

主要是底层支撑的TCP协议造成的；

HTTP/2使用了多路复用，一般来说同一域名下只需要使用一个TCP连接。 但当这个连接中出现了丢包的情况，那就会导致HTTP/2的表现情况反倒不如HTTP/1了； 在出现丢包的情况下，整个TCP都要开始等待重传，也就导致了后面的所有数据都被阻塞了

QUIC特点

• 0-RTT

通过使用类似 TCP 快速打开的技术，缓存当前会话的上下文，在下次恢复会话的时候， 只需要将之前的缓存传递给服务端验证通过就可以进行传输了。 0RTT 建连可以说是QUIC 相比 HTTP2 最大的性能优势。

这里面有两层含义:

1.传输层 0RTT 就能建立连接。

2.加密层 0RTT 就能建立加密连接。

• 多路复用

同HTTP2.0一样，同一条QUIC连接上可以创建多个stream，来发送多个HTTP请求，但是QUIC是基于UDP的， 一个连接上的多个stream之间没有依赖。 不存在 TCP 队头阻塞。

TCP是基于IP和端口去识别连接的，这种方式在多变的移动端网络环境下是很脆弱的。 但是QUIC是通过ID的方式去识别一个连接，不管你网络环境如何变化，只要ID不变，就能迅速重连上。

• 加密认证的报文

TCP协议头部没有经过任何加密和认证，所以在传输过程中很容易被中间网络设备篡改，注入和窃听。 比如修改序列号、滑动窗口。这些行为有可能是出于性能优化，也有可能是主动攻击。

但是QUIC的packet可以说是武装到了牙齿。 除了个别报文比如PUBLIC_RESET和CHLO，所有报文头部都是经过认证的，报文Body都是经过加密的。

这样只要对QUIC报文任何修改，接收端都能够及时发现，有效地降低了安全风险。

• 向前纠错机制

QUIC协议有一个非常独特的特性，称为向前纠错 (Forward Error Correction，FEC)，每个数据包除了它本身的内容之外， 还包括了部分其他数据包的数据，因此少量的丢包可以通过其他包的冗余数据直接组装而无需重传。

向前纠错牺牲了每个数据包可以发送数据的上限，但是减少了因为丢包导致的数据重传， 因为数据重传将会消耗更多的时间(包括确认数据包丢失、请求重传、等待新数据包等步骤的时间消耗)

总结

HTTP/1.x有连接无法复用、队头阻塞、协议开销大和安全因素等多个缺陷

HTTP/2 通过多路复用、二进制流、Header压缩等等技术，极大地提高了性能，但是还是存在着问题的

QUIC 基于UDP实现，是HTTP/3中的底层支撑协议，该协议基于UDP，又取了TCP中的精华，实现了即快又可靠的协议

https

HTTPS（Hyper Text Transfer Protocol over Secure Socket Layer），简单来讲就是加了安全的HTTP，即HTTP+SSL

而 HTTPS 的全称是 Hypertext Transfer Protocol Secure，从名称我们可以看出 HTTPS 要比 HTTPS 多了 secure 安全性这个概念， 实际上， HTTPS 并不是一个新的应用层协议，它其实就是 HTTP + TLS/SSL 协议组合而成，而安全性的保证正是 TLS/SSL 所做的工作。 也就是说，HTTPS 就是身披了一层 SSL 的 HTTP。

HTTP 和 HTTPS 的主要区别是什么呢？

• HTTP 在地址栏上的协议是以 http:// 开头，而 HTTPS 在地址栏上的协议是以 https:// 开头
• HTTP 是未经安全加密的协议，它的传输过程容易被攻击者监听、数据容易被窃取、发送方和接收方容易被伪造；而 HTTPS 是安全的协议，它通过 密钥交换算法 - 签名算法 - 对称加密算法 - 摘要算法 能够解决上面这些问题。
• HTTP 的默认端口是 80，而 HTTPS 的默认端口是 443。

https流程

Client发起一个HTTPS（https:/demo.linianhui.dev）的请求，根据RFC2818的规定，Client知道需要连接Server的443（默认）端口。

Server把事先配置好的公钥证书（public key certificate）返回给客户端。

Client验证公钥证书：比如是否在有效期内，证书的用途是不是匹配Client请求的站点，是不是在CRL吊销列表里面，它的上一级证书是否有效，这是一个递归的过程，直到验证到根证书（操作系统内置的Root证书或者Client内置的Root证书）。如果验证通过则继续，不通过则显示警告信息。

Client使用伪随机数生成器生成加密所使用的会话密钥，然后用证书的公钥加密这个会话密钥，发给Server。

Server使用自己的私钥（private key）解密这个消息，得到会话密钥。至此，Client和Server双方都持有了相同的会话密钥。

Server使用会话密钥加密“明文内容A”，发送给Client。

Client使用会话密钥解密响应的密文，得到“明文内容A”。

Client再次发起HTTPS的请求，使用会话密钥加密请求的“明文内容B”，然后Server使用会话密钥解密密文，得到“明文内容B”。

HTTP常见请求头

通用标头、实体标头、请求标头、响应标头

通用标头

通用标头主要有三个，分别是 Date、Cache-Control 和 Connection

• Date
  Date 是一个通用标头，它可以出现在请求标头和响应标头中，它的基本表示如下 Date: Wed, 21 Oct 2015 07:28:00 GMT

• Connection
  Connection 决定当前事务（一次三次握手和四次挥手）完成后，是否会关闭网络连接。Connection 有两种，一种是持久性连接，即一次事务完成后不关闭网络连接

实体标头

实体标头是描述消息正文内容的 HTTP 标头。实体标头用于 HTTP 请求和响应中。 头部Content-Length、 Content-Language、 Content-Encoding 是实体头。

• Content-Length 实体报头指示实体主体的大小，以字节为单位，发送到接收方。

• Content-Language 实体报头描述了客户端或者服务端能够接受的语言。

• Content-Encoding 这又是一个比较麻烦的属性，这个实体报头用来压缩媒体类型。Content-Encoding 指示对实体应用了何种编码。 常见的内容编码有这几种： gzip、compress、deflate、identity ，这个属性可以应用在请求报文和响应报文中

请求标头

Host

Referer

If-Modified-Since

If-None-Match

Accept

Accept-Language

响应标头

Access-Control-Allow-Origin

Keep-Alive

Server

Set-Cookie

地址栏输入 URL 发生了什么？

1。DNS解析
2。建立 TCP 连接
3。发起 HTTP-GET 请求
4。服务器返回

HTTP Get 和 Post 区别？

• get 请求的 URL 有长度限制，而 post 请求会把参数和值放在消息体中，对数据长度没有要求。

• get 请求会被浏览器主动 cache，而 post 不会，除非手动设置。

• get 请求在浏览器反复的 回退/前进 操作是无害的，而 post 操作会再次提交表单请求。

• get 请求在发送过程中会产生一个 TCP 数据包；post 在发送过程中会产生两个 TCP 数据包。 对于 get 方式的请求，浏览器会把 http header 和 data 一并发送出去，服务器响应 200（返回数据）； 而对于 post，浏览器先发送 header，服务器响应 100 continue，浏览器再发送 data，服务器响应 200 ok（返回数据）。

什么是无状态协议，HTTP是无状态协议吗，怎么解决？

• cookies机制
• JWT机制

web应用开发里就出现了保持http链接状态的技术： 一个是cookie技术，另一种是session技术。

Cookie就是由服务器发给客户端的特殊信息，而这些信息以文本文件的方式存放在客户端，然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息。

session技术则是服务端的解决方案，它是通过服务器来保持状态的。 在服务器端程序运行的过程中创建的，不同语言实现的应用程序有不同创建Session的方法

cookie与session的关系:

cookie和session的方案虽然分别属于客户端和服务端，但是服务端的session的实现对客户端的cookie有依赖关系的， 服务端执行session机制时候会生成session的id值，这个id值会发送给客户端， 客户端每次请求都会把这个id值放到http请求的头部发送给服务端，而这个id值在客户端会保存下来， 保存的容器就是cookie，因此当我们完全禁掉浏览器的cookie的时候，服务端的session也会不能正常使用

将session数据存储到内存是最佳的选择。 因此最好的解决方案就是使用分布式缓存技术，例如：memcached和redis，将session信息的存储独立出来也是解决session同步问题的方法。

HTTP Status Code

1xx Informational

100 Continue

101 Switching Protocols

102 Processing (WebDAV)

2xx Success

200 OK

201 Created

202 Accepted

203 Non-Authoritative Information

204 No Content

205 Reset Content

206 Partial Content

207 Multi-Status (WebDAV)

208 Already Reported (WebDAV)

226 IM Used

3xx Redirection

300 Multiple Choices

301 Moved Permanently

302 Found

303 See Other

304 Not Modified

305 Use Proxy

306 (Unused)

307 Temporary Redirect

308 Permanent Redirect (experimental)

4xx Client Error

400 Bad Request

401 Unauthorized

402 Payment Required

403 Forbidden

404 Not Found

405 Method Not Allowed

406 Not Acceptable

407 Proxy Authentication Required

408 Request Timeout

409 Conflict

410 Gone

411 Length Required

412 Precondition Failed

413 Request Entity Too Large

414 Request-URI Too Long

415 Unsupported Media Type

416 Requested Range Not Satisfiable

417 Expectation Failed

418 I’m a teapot (RFC 2324)

420 Enhance Your Calm (Twitter)

422 Unprocessable Entity (WebDAV)

423 Locked (WebDAV)

424 Failed Dependency (WebDAV)

425 Reserved for WebDAV

426 Upgrade Required

428 Precondition Required

429 Too Many Requests

431 Request Header Fields Too Large

444 No Response (Nginx)

449 Retry With (Microsoft)

450 Blocked by Windows Parental Controls (Microsoft)

451 Unavailable For Legal Reasons

499 Client Closed Request (Nginx)

5xx Server Error

500 Internal Server Error

501 Not Implemented

502 Bad Gateway

503 Service Unavailable

504 Gateway Timeout

505 HTTP Version Not Supported

506 Variant Also Negotiates (Experimental)

507 Insufficient Storage (WebDAV)

508 Loop Detected (WebDAV)

509 Bandwidth Limit Exceeded (Apache)

510 Not Extended

511 Network Authentication Required

制作https私有key&证书的方法：

openssl genrsa -aes256 -out ca-key.pem 2048
openssl req -new -x509 -days 3650 -key ca-key.pem -sha256 -out ca.pem （在提示输入Common Name时，输入https访问的host，如10.10.5.103）
openssl genrsa -out server-key.pem 2048
openssl req -subj "/CN=10.10.5.103" -new -key server-key.pem -out server.csr

echo subjectAltName = IP:10.10.5.103,IP:127.0.0.1 > extfile.cnf

openssl x509 -req -days 3650 -in server.csr -CA ca.pem -CAkey ca-key.pem \
                -CAcreateserial -out **server-cert.pem** -extfile extfile.cnf

产生三个文件： ca-key.pem，server-key.pem，server-cert.pem

设置kube-apiserver参数：

--tls-cert-file=./server-cert.pem   \
--tls-private-key-file=./server-key.pem

在client访问时，通过ca-key.pem来进行访问

refs

https://zhuanlan.zhihu.com/p/76302817