http各版本/https

最新推荐文章于 2025-05-05 22:37:22 发布

lxxxxxt

最新推荐文章于 2025-05-05 22:37:22 发布

阅读量6.4k

点赞数 1

分类专栏：计算机网络

本文链接：https://blog.youkuaiyun.com/qq_36281031/article/details/104887334

版权

计算机网络专栏收录该内容

7 篇文章

订阅专栏

http

超文本传输协议，信息明文传输，采用TCP连接，无状态（服务器不记得客户端），

http1.0

比http0.9增加了请求方式POST和HEAD；
不再局限于0.9版本的HTML格式，根据Content-Type可以支持多种数据格式，即MIME多用途互联网邮件扩展，例如text/html、image/jpeg等；
每次TCP连接只能发送一个请求，当服务器响应后就会关闭这次连接，下一个请求需要再次建立TCP连接，就是不支持keepalive。（但是浏览器发送请求时可以添加一个Connection字段Connection: keep-alive要求服务器不要关闭TCP连接）

http1.1：主流的协议版本

引入了持久连接（persistent connection），即TCP连接默认不关闭，可以被多个请求复用，不用声明Connection: keep-alive。客户端和服务器发现对方一段时间没有活动，就可以主动关闭连接。不过，规范的做法是，客户端在最后一个请求时，发送Connection: close，明确要求服务器关闭TCP连接。加入了管道机制，在同一个TCP连接里，允许多个请求同时发送，增加了并发性，进一步改善了HTTP协议的效率（不必等待服务器回应后在发下一个）；

一个TCP连接现在可以传送多个回应，势必就要有一种机制，区分数据包是属于哪一个回应的。这就是Content-length字段的作用，声明本次回应的数据长度。Content-Length: 3495告诉浏览器，本次回应的长度是3495个字节，后面的字节就属于下一个回应了。
分块传输：使用Content-Length字段的前提条件是，服务器发送回应之前，必须知道回应的数据长度。
对于一些很耗时的动态操作来说，这意味着，服务器要等到所有操作完成，才能发送数据，显然这样的效率不高。更好的处理方法是，产生一块数据，就发送一块，采用"流模式"（stream）取代"缓存模式"（buffer）。因此，1.1版规定可以不使用Content-Length字段，而使用"分块传输编码"（chunked transfer encoding）。只要请求或回应的头信息有Transfer-Encoding字段，就表明回应将由数量未定的数据块组成。每个非空的数据块之前，会有一个16进制的数值，表示这个块的长度。最后是一个大小为0的块，就表示本次回应的数据发送完了。
另外，客户端请求的头信息新增了Host字段，用来指定服务器的域名。在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。有了Host字段，就可以将请求发往同一台服务器上的不同网站，为虚拟主机的兴起打下了基础。（实现了在一台WEB服务器上可以在同一个IP地址和端口号上使用不同的主机名来创建多个虚拟WEB站点。也即是说，web server上的多个虚拟站点可以共享同一个ip和端口。）
虽然1.1版允许复用TCP连接，但是同一个TCP连接里面，所有的数据通信是按次序进行的。服务端是按队列顺序处理请求的，服务器只有处理完一个回应，才会进行下一个回应。假如前面的请求处理时间很长，后面就会有许多请求排队等着，这样就造成了“队头阻塞”的问题；同时HTTP是无状态的连接，因此每次请求都需要添加重复的字段，降低了带宽的利用率。

http2.0

为了解决1.1版本利用率不高的问题，提出了HTTP/2.0版本。增加双工模式，即不仅客户端能够同时发送多个请求，服务端也能同时处理多个请求，解决了队头堵塞的问题
多工：HTTP/2 复用TCP连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应，这样就避免了"队头堵塞"。举例来说，在一个TCP连接里面，服务器同时收到了A请求和B请求，于是先回应A请求，结果发现处理过程非常耗时，于是就发送A请求已经处理好的部分，接着回应B请求，完成后，再发送A请求剩下的部分。这样双向的、实时的通信，就叫做多工（Multiplexing）。
头信息压缩机制：一方面，头信息使用gzip或compress压缩后再发送；另一方面：HTTP请求和响应中，状态行和请求/响应头都是些信息字段，并没有真正的数据，因此在2.0版本中将所有的信息字段建立一张表，为表中的每个字段建立索引，客户端和服务端共同使用这个表，他们之间就以索引号来表示信息字段，这样就避免了1.0旧版本的重复繁琐的字段，并以压缩的方式传输，提高利用率。
增加服务器推送(server push)的功能，即不经请求服务端主动向客户端发送数据。意思是说，当我们对支持HTTP2.0的web server请求数据的时候，服务器会顺便把一些客户端需要的资源一起推送到客户端，免得客户端再次创建连接发送请求到服务器端获取。这种方式非常合适加载静态资源。

常见场景是客户端请求一个网页，这个网页里面包含很多静态资源。正常情况下，客户端必须收到网页后，解析HTML源码，发现有静态资源，再发出静态资源请求。其实，服务器可以预期到客户端请求网页后，很可能会再请求静态资源，所以就主动把这些静态资源随着网页一起发给客户端了。
工作流程：
- 1.建立TCP/IP连接，客户端与服务器通过Socket三次握手进行连接
- 2.客户端向服务端发起HTTP请求（例如：POST/login.html http/1.1）
- 3.客户端发送请求头信息，请求内容，最后会发送一空白行，标示客户端请求完毕
- 4.服务器做出应答，表示对于客户端请求的应答，例如：HTTP/1.1 200 OK
- 5.服务器向客户端发送应答头信息
- 6.服务器向客户端发送应答头信息后，也会发送一空白行，标示应答头信息发送完毕，接着就以Content-type要求的数据格式发送数据给客户端
- 7.服务端关闭TCP连接，如果服务器或者客户端增Connection:keep-alive就表示客户端与服务器端继续保存连接，在下次请求时可以继续使用这次的连接

https

https是以安全为目标的HTTP通道，简单讲是HTTP的安全版，即http下加入SSL层（secure socket layer），https的安全基础是SSL（或TLS），因此加密的详细内容就需要SSL。端口号443

TLS（传输层安全）是更为安全的升级版 SSL。事实上我们现在用的都是TLS，但因为历史上习惯了SSL这个称呼
https协议需要到ca申请证书，CA机构颁发的证书都是需要年费的
特点：内容加密：采用混合加密技术，中间者无法直接查看明文内容；验证身份：通过证书认证客户端访问的是自己的服务器；保护数据完整性：防止传输的内容被中间人冒充或者篡改。

对称加密：加密和解密使用同一个密钥的加密方式。常见的对称加密算法有DES、3DES、Blowfish、IDEA、RC4、RC5、RC6和AES。AES加密算法(Advanced Encryption Standard)
非对称加密算法需要两个密钥：公开密钥（public key）和私有密钥（private key）。公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。常见的非对称加密算法有：RSA、ECC（移动设备用）、Diffie-Hellman、El Gamal、DSA（数字签名用）。
工作流程：

第一步：客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。(附带自己能接受的加密算法)
第二步：Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。
第三步：客户端的浏览器与Web服务器开始协商SSL连接的安全等级，也就是信息加密的等级。
第四步：客户端的浏览器根据双方同意的安全等级，建立会话密钥（两个随机值+预主秘钥），然后利用网站的公钥将会话密钥加密，并传送给网站。
第五步：Web服务器利用自己的私钥解密出会话密钥。
第六步：Web服务器利用会话密钥加密与客户端之间的通信。（客户端通过会话秘钥加密一条消息发送给服务端，主要验证服务端是否正常接受客户端加密的消息。同样服务端也会通过会话秘钥加密一条消息回传给客户端，如果客户端能够正常接受的话表明SSL层连接建立完成了。）