HTTP vs HTTPS

HTTP和HTTPS的概念     
　    1 HTTP 是超文本传输协议，它定义了客户端和服务器之间交换报文的格式和方式，默认使用 80 端口。它使用 TCP 作为传 输层协议，保证了数据传输的可靠性。

       优点：扩展性强、速度快、跨平台支持性好
        2 http协议属于明文传输协议，交互过程以及数据传输都没有进行加密，通信双方也没有进行任何认证，通信过程非常容易遭遇劫持、监听、篡改，严重情况下，会造成恶意的流量劫持等问题，

       甚  至  造成个人 隐 私泄露（比如银行卡卡号和密码泄露）等严重的安全问题。

       3 HTTP 是一个无状态的协议 如何保存用户状态?

    Session 的主要作用就是通过服务端记录用户的状态。保存在服务器。一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个 Session）。

    在服务端保存 Session 的方法很多，最常用的就是内存和数据库(比如是使用内存数据库 redis 保存)。

    既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？大部分情况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。 

    Cookie 被禁用怎么办？ 最常用的就是利用 URL 重写把 Session ID 直接附加在 URL 路径的后面。

    (1 cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户的状态，就使用response向客户端浏览器颁发一个cookie。

客户端浏览器会把cookie保存起来。当浏览器再次请求该网站时，浏览器就会把请求地址和cookie一同给服务器。服务器检查该cookie，从而判断用户的状态。服务器还可以根据需要修改cookie的内容。

cookie 一般可以存储 4k 大小的数据，并且只能够被同源的网页所共享访问。
。
服务器端可以使用 Set-Cookie 的响应头部来配置 cookie 信息。一条cookie 包括了5个属性值 expires、domain、path、secure、HttpOnly。其中 expires 指定了 cookie 失效的时间，domain 是域名、path是路径，domain 和 path 一起限制了 cookie 能够被哪些 url 访问。secure 规定了 cookie 只能在确保安全的情况下传输，HttpOnly 规定了这个 cookie 只能被服务器访问，不能使用 js 脚本访问。

在发生 xhr 的跨域请求的时候，即使是同源下的 cookie，也不会被自动添加到请求头部，除非显示地规定。


# 表现形式：
k：v键值对(可以存多个)

。例如：在 Cookie 中保存已经登录过的用户信息，下次访问网站的时候页面可以自动帮你把登录的一些基本信息给填了。

session是另一种记录客户状态的机制。不同的是cookie保存在客户端浏览器中，而session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上，

这就是session。客户端浏览器再次访问时只需要从该session中查找该客户的状态就可以了。 如果说cookie机制是通过检查客户身上的“通信证”，那么session机制就是通过检查服务器上的“客户明细表”来确认客户身份。
# 表现形式
数据时保存在服务端的并且他的表现形式一般也是k：v键值对(可以有多个)

       Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。

      服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。

    (2)Cookie 数据保存在客户端(浏览器端)。Session 数据保存在服务器端。 3.session是基于cookie工作的。(大部分的保存用户状态的操作都需要使用到cookie)

    (3)相对来说 Session 安全性更高。 如果要在 Cookie 中存储一些敏感信息，不要直接写入 Cookie 中，最好能将 Cookie 信息加密，然后使用到的时候再去服务器端解密。

去读取存储用户浏览器中的session id，然后依照这个session id去寻找session，这和读取cookie比起来，感觉也安全不到哪里去啊

section 相对安全

1 没错，其实HTTP本身就不安全，只要是存在cookie中的数据都可以获取到并加以利用，
但是session的安全性也是相对的，由于数据存储在数据库中，就算sessionid被获取利用，
但是session中的数据并不会被恶意程序获取，这一点相对cookie来说就安全了一些；

2 

经常存在session -id还存储在浏览器，但是session信息已经过期的情况，此时进行登录，
它会依照你当前的session -id创建session文件。也就是说黑客获得了用户的session -id后并不一定
可以利用这个id进行登录，因为对应的session信息可能已经被销毁了，而且session id中也并没有存储其
它有价值的信息，这就是session比单纯的cookie安全性更高的原因

coolie的一些属性

 

 

HttpOnly
Set-Cookie: token=abcd; HttpOnly

设置后，只能通过 HTTP 响应报文的 Set-Cookie 来新增或更新 cookie ，客户端无法通过脚本的方式来读写 cookie。

对于敏感信息比如用户凭证，请一定要加上 HttpOnly。如果攻击者成功地实施了 XSS 攻击，会因为无法读取 cookie 而拿不到敏感信息。

Secure

Set-Cookie: token=en-US; Secure

该属性没有值，属性本身存在就代表设置为安全模式。

即请求必须为安全连接（HTTPS），cookie 才会被保存下来。HTTP 协议下，cookie 无效

 max-age

负整数：当前会话有效，浏览器关闭则清除。
0：立即清除。
正整数：以秒为单位设置存活时间。

domain 和 path 属性

domain 指定了该 cookie 所属的域名，默认情况下，domain 会被设置为创建该 cookie 时所在的域名； 而 path 则指定了该 cookie 所属的路径； domain 和 path 两者一起来限制了该 cookie 允许被哪些 URL 访问， 当我们请求某个资源（URL）时只有当该 URL 域名能够同时被 domain 和 path 属性匹配时， 浏览器才会将此 cookie 添加到该请求的 cookie 头部中

Etag

https://blog.csdn.net/weixin_42989576/article/details/123695991

ETag 是由 Web 服务器分配给在URL中找到的特定版本资源的不透明标识符。如果该 URL 的资源表示发生了变化，则会重新分配一个新的 ETag。

ETag生成结论

1. 对于静态文件（如css、js、图片等），ETag的生成策略是：文件大小的16进制+修改时间

2. 对于字符串或Buffer，ETag的生成策略是：字符串/Buffer长度的16进制+对应的hash值

 token的认证机制？

使用基于 Token 的身份验证方法，在服务端不需要存储用户的登录记录。大概的流程是这样的：

客户端使用用户名跟密码请求登录
服务端收到请求，去验证用户名与密码
验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端
客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里
客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据

token的优点

  • 支持跨域访问，将token置于请求头中，而cookie是不支持跨域访问的；
  • 无状态化，服务端无需存储token，只需要验证token信息是否正确即可，而session需要在服务端存储，一般是通过cookie中的sessionID在服务端查找对应的session；
  • 无需绑定到一个特殊的身份验证方案（传统的用户名密码登陆），只需要生成的token是符合我们预期设定的即可；
  • 更适用于移动端（Android，iOS，小程序等等），像这种原生平台不支持cookie，比如说微信小程序，每一次请求都是一次会话，当然我们可以每次去手动为他添加cookie，详情请查看博主另一篇博客；
  • 避免CSRF跨站伪造攻击，还是因为不依赖cookie

   HTTP 通信过程：

  • 服务器在 80 端口等待客户的请求。
  • 浏览器发起到服务器的 TCP 连接（创建套接字 Socket）。
  • 服务器接收来自浏览器的 TCP 连接。
  • 浏览器（HTTP 客户端）与 Web 服务器（HTTP 服务器）交换 HTTP 消息。
  • 关闭 TCP 连接。

-HTTP请求方法   8种方法    pcdot

 

 

 get post区别

1.Get 向特定的资源发出请求，Get是不安全的，因为在传输过程，数据被放在请求的URL中；POST向指定资源提交数据进行处理请求。Post的所有操作对用户来说都是不可见的, 数据放在请求体中。

2.Get传送的数据量较小，这主要是因为受URL长度限制；Post传送的数据量较大，一般被默认为不受限制。

3.Get限制Form表单的数据集的值必须为ASCII字符；而Post支持整个ISO10646字符集。

4. Get执行效率却比Post方法好。Get是form提交的默认方法。

  • 1.HTTP 协议未规定 GET 和 POST 的长度限制
  • 2.GET 的最大长度显示是因为浏览器和 web 服务器限制了 URI 的长度
  • 3.不同的浏览器和 WEB 服务器，限制的最大长度不一样
  • 4.要支持 IE，则最大长度为 2083byte，若只支持 Chrome，则最大长度 8182byte

5 缓存一般只适用于那些不会更新服务端数据的请求。一般 get 请求都是查找请求，不会对服务器资源数据造成修改，而 post 请求一般都会对服务器数据造成修改，所以，一般会对 get 请求进行缓存，很少会对 post 请求进行缓存。

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

post put 区别

PUT是幂等的，POST是非幂等的  幂等：对于相同的输入，每次得到的结果都是相等的，

PUT请求：如果两个请求相同，后一个请求会把第一个请求覆盖掉。（所以PUT用来改资源）

Post请求：后一个请求不会把第一个请求覆盖掉。（所以Post用来增资源）

options

OPTIONS 请求与 HEAD 类似，一般也是用于客户端查看服务器的性能。这个方法会请求服务器返回该资源所支持的所有 HTTP 请
 求方法，该方法会用'*'来代替资源名称，向服务器发送 OPTIONS 请求，可以测试服务器功能是否正常。JS 的 XMLHttpRequest
 对象进行 CORS 跨域资源共享时，对于复杂请求，就是使用 OPTIONS 方法发送嗅探请求，以判断是否有对指定资源的访问权限。

HTTP请求/响应报文结构

HTTP请求报文

一个HTTP请求报文由四个部分组成：请求行、请求头部、空行、请求数据。

请求行

请求行由请求方法字段、URL字段和HTTP协议版本字段3个字段组成，它们用空格分隔

空行

它的作用是通过一个空行，告诉服务器请求头部到此为止

请求头部

请求头部通知服务器有关于客户端请求的信息 ，关键字/值对组成

https://www.flysnow.org/tools/table/http-request-headers/   

Content-Length：表示请求消息正文的长度。Cookie。User-Agent：传达浏览器的种类。

kv = {'user-agent':'Mozilla/5.0'}
r = requests.get(url,headers = kv)

通过更改User-Agent字段就可以轻易骗过该网站。京东会从HTTP的头部判断这是一个爬虫请求还是一个网络请求，它可以拒绝爬虫请求

请求数据

若方法字段是GET，则此项为空，没有数据

若方法字段是POST,则通常来说此处放置的就是要提交的数据

 

HTTP响应报文

同样的，HTTP响应报文也由三部分组成：响应行、响应头、响应体

1.响应行

响应行一般由协议版本、状态码及其描述组成 比如 HTTP/1.1 200 OK

2.响应头

响应头用于描述服务器的基本信息，可以通知客户端如何处理等一会儿它回送的数据。

Allow：服务器支持哪些请求方法(如GET、POST等)。Transfer-Encoding：告诉浏览器数据的传送格式。

3.响应体

响应体就是响应的消息体，如果是纯数据就是返回纯数据，如果请求的是HTML页面，那么返回的就是HTML代码等

 

 

 

     

 简述http状态码和对应的信息

      https://www.runoob.com/http/http-status-codes.html
     1xx - 信息提示
     2xx-成功  200表示从客户端发来的请求在服务器端被正确处理
     3xx -重定向 302 found，临时性重定向，表示资源临时被分配了新的 URL

     4xx-客户端错误 404 not found，表示在服务器上没有找到请求的资源。400 Bad Request 客户端请求的语法错误，服务器无法理解

http状态码中301和302有什么区别

301 redirect: 301 代表永久性转移(Permanently Moved)

302 redirect: 302 代表暂时性转移(Temporarily Moved )

✔ 相同点：都表示重定向，就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址，这个地址可以从响应的Location首部中获取（用户看到的效果就是他输入的地址A瞬间变成了另一个地址B）

✔ 不同点：

1、301表示旧地址A的资源已经被永久地移除了（这个资源不可访问了），搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址；

    302表示旧地址A的资源还在（仍然可以访问），这个重定向只是临时地从旧地址A跳转到地址B，搜索引擎会抓取新的内容而保存旧的网址。

2、302会出现“网址劫持”现象，从A网址302重定向到B网址，由于部分搜索引擎无法总是抓取到目标网址，或者B网址对用户展示不够友好，因此浏览器会仍旧显示A网址，但是所用的网页内容却是B网址上的内容

✔ 应用场景

301：域名需要切换、协议从http变成https；

302：未登录时访问已登录页时跳转到登录页面、404后跳转首页

 

http状态码中403和404有什么区别

 

404 Not Found 

请求失败，请求所希望得到的资源未被在服务器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的

404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。

403 Forbidden 

服务器收到请求，但是拒绝提供服务。服务器通常会在响应正文中给出不提供服务的原因；

  5xx-服务器错误  500 internal sever error服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。

 502

表示Internet上的一台服务器收到来自另一个服务器的无效响应，也就是指网关错误，无效网关；在互联网中表示一种网络错误。表示web浏览器中给出的页面反馈。

  • 504 Gateway Timeout 服务器再次充当代理或网关时，没有及时从另一个服务器（例如DNS）获得响应，因此它无法处理请求

502是代理服务器后面的真实服务器节点配置出了问题或者已经挂掉了，而504是代理服务器后面的真实服务器已经过载.要处理的请求报文实在太多，忙不过来了

首部行

 

首部可以分为四种首部，请求首部、响应首部、通用首部和实体首部。通用首部和实体首部在请求报文和响应报文中都可以设 置，区别在于请求首部和响应首部。

常见的请求首部有 Accept 通知服务器，用户代理可处理的媒体类型及媒体类型的相对优先级、Accept-Charset 可接收的字符集、Host 请求资源所处的的主机名和端口号。

常见的响应首部有Accept-Ranges 告知客户端能够处理范围请求  ETag 是一种将资源以字符串形式唯一标识的方式，Location 将相应接收方引导至某个与请求URI位置不同的资源。

常见的通用首部有 Cache-Control 操作缓存的工作机制、Connection 管理持久连接和控制不在转发的首部字段。

常见的实体首部有 Allow：服务器支持哪些请求方法，Content-Type 实体主体内对象的媒体类型、Expires 实体主体的过期时间、Last-Modified 资源的最后修 改时间


   端到端首部和逐跳首部

 

   

HTTP 1.0 vs HTTP 1.1

 

  • 响应状态码  HTTP/1.0仅定义了16种状态码。HTTP/1.1中新加入了大量的状态码  如 409 (Conflict)——请求与当前资源的规定冲突

  • 缓存处理   

  •  1.0  ：服务器端使用Expires标签来标志（时间）一个响应体，在Expires标志时间内的请求，都会获得该响应体缓存。
    服务器端在初次返回给客户端的响应体中，有一个Last-Modified标签，该标签标记了被请求资源在服务器端的最后一次修改。
  • 在请求头中，使用If-Modified-Since标签，该标签标志一个时间，意为客户端向服务器进行问询：“该时间之前，我要请求的资源是否有被修改过？

    如果服务器接收到了请求头，并判断If-Modified-Since时间后，资源确实没有修改过，则返回给客户端一个304 not modified响应头，表示”缓冲可用，你从浏览器里拿吧！”。

    如果服务器判断If-Modified-Since时间后，资源被修改过，则返回给客户端一个200 OK的响应体，并附带全新的资源内容，表示”你要的我已经改过的，给你一份新的”

    1.1 基本工作原理和HTTP/1.0保持不变，而是增加了更多细致的特性。其中，请求头中最常见的特性就是Cache-Control  ( Cache-Control 通用消息头字段，被用于在http请求和响应中，通过指定指令来实现缓存机制。缓存指令是单向的，这意味着在请求中设置的指令，不一定被包含在响应中)。还有例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match
  • 连接方式 
  • HTTP/1.0 默认使用短连接 。每遇到这样一个 Web 资源，浏览器就会重新建立一个TCP连接，这样就会导致有大量的“握手报文”和“挥手报文”占用了带宽。
  • 为了解决 HTTP/1.0 存在的资源浪费的问题， HTTP/1.1 优化为默认长连接模式 。 

  • HTTP 协议的长连接和短连接，实质上是 TCP 协议的长连接和短连接。实现长连接需要客户端和服务端都支持长连接

  • Host头处理 

  •  域名系统（DNS）允许多个主机名绑定到同一个IP地址上，但是HTTP/1.0并没有考虑这个问题.HTTP/1.0的请求报文中,就是不会加入主机名。这样的报文送到服务器端，服务器是理解不了客户端想请求的真正网址。

  • HTTP/1.1在请求头中加入了Host字段。这样，服务器端就可以确定客户端想要请求的真正的网址了。

  • 带宽优化

  • 范围请求  HTTP/1.1引入了范围请求（range request）机制，以避免带宽的浪费。HTTP/1.1可以在请求中加入Range头部，以请求（并只能请求字节型数据）数据的一部分。即返回码是 206

  • 状态码100 HTTP/1.1中新加入了状态码100。该状态码的使用场景为，存在某些较大的文件请求，服务器可能不愿意响应这种请求，此时状态码100可以作为指示请求是否会被正常响应

  • 压缩  HTTP/1.0对数据压缩的选项提供的不多，不支持压缩细节的选择，也无法区分端到端（end-to-end）压缩或者是逐跳（hop-by-hop）压缩。

    许多格式的数据在传输时都会做预压缩处理。数据的压缩可以大幅优化带宽的利用。然而，HTTP/1.0对数据压缩的选项提供的不多，不支持压缩细节的选择，也无法区分端到端（end-to-end）压缩或者是逐跳（hop-by-hop）压缩。

    HTTP/1.1则对内容编码（content-codings）和传输编码（transfer-codings）做了区分。内容编码总是端到端的，传输编码总是逐跳的。

    HTTP/1.0包含了Content-Encoding头部，对消息进行端到端编码。HTTP/1.1加入了Transfer-Encoding头部，可以对消息进行逐跳传输编码。HTTP/1.1还加入了Accept-Encoding头部，是客户端用来指示他能处理什么样的内容编码 

         请求方法

           http1.1 相对于 http1.0 还新增了很多方法，如 PUT、HEAD、OPTIONS 等。

  • 简述HTTP短连接与长连接区别

  HTTP中的长连接短连接指HTTP底层TCP的连接。
     短连接： 客户端与服务器进行一次HTTP连接操作，就进行一次TCP连接，连接结束TCP关闭连接。
     长连接：如果HTTP头部带有参数keep-alive，即开启长连接网页完成打开后，底层用于传输数据的TCP连接不会直接关闭，会根据服务器设置的保持时间保持连接，保持时间过后连接关闭

 

简述http1.1的改进

HTTP1.1默认开启长连接，在一个TCP连接上可以传送多个HTTP请求和响应。使用 TCP 长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。

支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。

HTTP/1.1 协议缺点

HTTP/1.1 默认使用了持久连接，多个请求可以复用同一个 TCP 连接，但是在同一个 TCP 连接里面，数据请求的通信次序 是固定的。服务器只有处理完一个请求的响应后，才会进行下一个请求的处理，如果前面请求的响应特别慢的话，就会造成许 多请求排队等待的情况，这种情况被称为“队头堵塞”。队头阻塞会导致持久连接在达到最大数量时，剩余的资源需要等待其他 资源请求完成后才能发起请求。

为了避免这个问题，一个是减少请求数，一个是同时打开多个持久连接。这就是我们对网站优化时，使用雪碧图、合并脚本的 原因

简述http2.0的改进

HTTP/2 则是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为"帧"引入了二进制数据帧。其中帧对数据进行顺序标识，有了序列id，服务器就可以进行并行传输数据

HTTP/2 实现了多路复用，HTTP/2 仍然复用 TCP 连接，但是在一个连接里，客户端和服务器都可以同时发送多个请求或回 应，而且不用按照顺序一一发送，这样就避免了"队头堵塞"的问题。

HTTP/2 使用了数据流的概念，因为 HTTP/2 的数据包是不按顺序发送的，同一个连接里面连续的数据包，可能属于不同的 请求。因此，必须要对数据包做标记，指出它属于哪个请求。HTTP/2 将每个请求或回应的所有数据包，称为一个数据流。每 个数据流都有一个独一无二的编号。数据包发送的时候，都必须标记数据流 ID ，用来区分它属于哪个数据流。

HTTP/2 实现了头信息压缩，由于 HTTP 1.1 协议不带有状态，每次请求都必须附上所有信息。所以，请求的很多字段都是 重复的，比如 Cookie 和 User Agent ，一模一样的内容，每次请求都必须附带，这会浪费很多带宽，也影响速度。HTTP/2 对这一点做了优化，引入了头信息压缩机制。一方面，头信息使用 gzip 或 compress 压缩后再发送；另一方面， 客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引 号，这样就能提高速度了。

 

HTTP/2 允许服务器未经请求，主动向客户端发送资源，这叫做服务器推送。使用服务器推送，提前给客户端推送必要的资源 ，这样就可以相对减少一些延迟时间。这里需要注意的是 http2 下服务器主动推送的是静态资源，和 WebSocket 以及使用 SSE 等方式向客户端发送即时数据的推送是不同的。

HTTP/2 协议缺点

因为 HTTP/2 使用了多路复用，一般来说同一域名下只需要使用一个 TCP 连接。由于多个数据流使用同一个 TCP 连接，遵 守同一个流量状态控制和拥塞控制。只要一个数据流遭遇到拥塞，剩下的数据流就没法发出去，这样就导致了后面的所有数据都 会被阻塞。HTTP/2 出现的这个问题是由于其使用 TCP 协议的问题，与它本身的实现其实并没有多大关系

 

如何看待 HTTP/3 ？

https://www.zhihu.com/question/302412059

由于 TCP 本身存在的一些限制，Google 就开发了一个基于 UDP 协议的 QUIC 协议，并且使用在了 HTTP/3 上。 QUIC 协议在 UDP 协议上实现了多路复用、有序交付、重传等等功能　

　HTTPS：

 

HTTP 存在的问题

  1. HTTP 报文使用明文方式发送，可能被第三方窃听。

  2. HTTP 报文可能被第三方截取后修改通信内容，接收方没有办法发现报文内容的修改。

  3. HTTP 还存在认证的问题，第三方可以冒充他人参与通信。

HTTPS 指的是超文本传输安全协议，HTTPS 是基于 HTTP 协议的，不过它会使用 TLS/SSL 来对数据加密。使用 TLS/ SSL 协议，所有的信息都是加密的，第三方没有办法窃听。并且它提供了一种校验机制，信息一旦被篡改，通信的双方会立 刻发现。它还配备了身份证书，防止身份被冒充的情况出现。

   SSL 通道通常使用基于密钥的加密算法，密钥长度通常是 40 比特或 128 比特

 

       HTTPS 的核心—SSL/TLS协议

       SSL 和 TLS 没有太大的区别。SSL 指安全套接字协议（Secure Sockets Layer）TLS 是基于 SSL 之上的，但由于习惯叫法，通常把 HTTPS 中的核心加密协议混成为 SSL/TLS。

 

 

通过 Wireshark 抓包我们不难发现：不论客户端和服务端的连接走 HTTP 还是 TLS 协议，所有连接最初都要经过 TCP 三次握手，而 TLS 四次握手是在 TCP 建立连接之后进行的。

因此，HTTPS 首次通信需要 7 次握手！

TLS 握手过程

 https://blog.51cto.com/u_10125763/3825793

  1. 第一步，客户端向服务器发起请求，请求中包含使用的协议版本号、生成的一个随机数1、以及客户端支持的加密方法。

  2. 第二步，服务器端接收到请求后，确认双方使用的加密方法、并给出服务器的证书、以及一个服务器生成的随机数2。

  3. 第三步，客户端确认服务器证书有效后，生成一个新的随机数3，并使用数字证书中的公钥，加密这个随机数3 生成PreMaster Key，然后发给服 务器。并且还会提供一个前面所有内容的 hash 的值，用来供服务器检验。

  4. 第四步，服务器使用自己的私钥，来解密客户端发送过来的随机数3。至此，客户端和服务端都拥有 Random1 + Random2 + Random3，两边再根据同样的算法就可以生成一份秘钥，握手结束后的应用层数据都是使用这个秘钥进行对称加密.并提供前面所有内容的 hash 值来供客户端检验。

     为什么要使用三个随机数呢？这是因为 SSL/TLS 握手过程的数据都是明文传输的，并且多个随机数种子来生成秘钥不容易被暴力破解出来。

        SSL/TLS 的核心要素是非对称加密。非对称加密采用两个密钥——一个公钥，一个私钥。

        其中公钥 是公开的，私钥是持有方才有。一般私钥放在服务器里。

       公钥加密后只能用私钥解密

       私钥加密后只能用公钥解密

 

握手过程优化
如果每次重连都要重新握手还是比较耗时的，所以可以对握手过程进行优化。从下图里我们看到 Client Hello 消息里还附带了上一次的 Session ID，服务端接收到这个 Session ID 后如果能复用就不再进行后续的握手过程。

 

       非对称加密的公钥和私钥需要采用一种复杂的数学机制生成（密码学认为，为了较高的安全性，尽量不要自己创造加密方案）。

公私钥对的生成算法依赖于单向陷门函数。

 

      单向陷门函数：一个较弱的单向函数。已知单向陷门函数 f，陷门 h，给定任意一个输入 x，易计算出输出 y=f(x;h)；而给定一个输出 y，假设存在 f(x;h)=y，很难根据 f 来计算出 x，但可以根据          f  和  h 来推导出 x 

       对称加密

       对称加密：通信双方共享唯一密钥 k，加解密算法已知，加密方利用密钥 k 加密，解密方利用密钥 k 解密，保密性依赖于密钥 k 的保密性。

      使用 SSL/TLS 进行通信的双方需要使用非对称加密方案来通信，但是非对称加密设计了较为复杂的数学算法，在实际通信过程中，计算的代价较高，效率太低，因此，SSL/TLS 实际对消息的加密使用的是对称加密。

      为什么需要非对称加密

      我们知道网络通信的信道是不安全的，传输报文对任何人是可见的，密钥的交换肯定不能直接在网络信道中传输。因此，使用非对称加密，对对称加密的密钥进行加密，保护该密钥不在网络信道中被窃听。这样，通信双方只需要一次非对称加密，交换对称加密的密钥，在之后的信息通信中，使用绝对安全的密钥，对信息进行对称加密，即可保证传输消息的保密性。

非对称密钥的优点：安全性高。非对称加密使用一对秘钥，一个用来加密，一个用来解密，而且公钥是公开的，秘钥是自己保存的，不需要像对称加密那样在通信之前要先同步秘钥。因此非对称加密算法更安全，密钥越长，它就越难破解。

 

 

 

       公钥即使做加密，也难以避免这种信任性问题   例如准备和某台服务器建立公钥加密的通信时，如何证明收到的公钥就是预想服务器的公钥。

      为了公钥传输的信赖性问题，第三方机构应运而生——证书颁发机构（CA，Certificate Authority）。CA 默认是受信任的第三方。CA 会给各个服务器颁发证书，

证书存储在服务器上，并附有 CA 的电子签名

      当客户端（浏览器）向服务器发送 HTTPS 请求时，一定要先获取目标服务器的证书，并根据证书上的信息，检验证书的合法性。一旦客户端检测到证书非法，就会发生错误。客户端获取了服务器的证书 后，由于证书的信任性是由第三方信赖机构认证的，而证书上又包含着服务器的公钥信息，客户端就可以放心的信任证书上的公钥就是目标服务器的公钥。

       数字签名

       数字签名要解决的问题，是防止证书被伪造。第三方信赖机构 CA 之所以能被信赖，就是靠数字签名技术。

        数字签名，是 CA 在给服务器颁发证书时，使用散列+加密的组合技术，在证书上盖个章，以此来提供验伪的功能。具体行为如下

        (1)CA 知道服务器的公钥，对该公钥采用散列技术生成一个摘要。CA 使用 CA 私钥对该摘要进行加密，并附在证书下方，发送给 服务器。

     （2)现在服务器将该证书发送给客户端，客户端需要验证该证书的身份。  

       (3)客户端找到第三方机构 CA，获知 CA 的公钥，并用 CA 公钥对证书的签名进行解密，获得了 CA 生成的摘要。客户端对证书数据（也就是服务器的公钥）做相同的散列处理，得到摘要，并将该摘要与之前从签名中解码出的摘要做对比，如果相同，则身份验证成功；否则验证失败。

       验证身份的证书一定是由 CA 的私钥进行签名，而不能由发送者自己来签名。这是为了抵抗以下的攻击场景：

      攻击者使用某种手段，欺骗了客户端，将服务器的公钥替换为攻击者的诱饵公钥。

      假使证书的签名使用的是服务器的私钥，那么客户端在解码的时候，将会使用假的服务器公钥（实则为诱饵公钥）。

     那么，如果该证书实则由攻击者（使用自己的私钥签名）发出，那么客户端就会成功验证（攻击者的）身份为真，从而信赖了证书中的公钥。

      如果使用 CA 的私钥和公钥来对签名处理，则不会出现上述问题。

　　HTTPS协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性

       服务器与客户端传递数据的过程中HTTPS是如何保证数据的安全呢   答案就是上面的3点 对称加密 非对称加密 和数字签名

 

HTTPS实际就是在应用层和传输层协议之间加了一层加密层（SSL&TLS），这层加密层本身也是属于应用层的，它会对用户的个人信息进行各种程度的加密。HTTPS在交付数据时先把数据交给加密层，由加密层对数据加密后再交给传输层。
通信双方使用的应用层协议必须是一样的，因此对端的应用层也必须使用HTTPS，当对端的传输层收到数据后，会先将数据交给加密层，由加密层对数据进行解密后再将数据交给应用层。

 

————————————————

两者的区别

  • 端口号 ：HTTP 默认是 80，HTTPS 默认是 443。
  • UTL 前缀 ：HTTP 的 URL 前缀是 http://，HTTPS 的 URL 前缀是 https://。
  • 安全性和资源消耗 ： HTTP 协议运行在 TCP 之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS 高，但是 HTTPS 比 HTTP 耗费更多服务器资源。通信：   通常HTTP 直接和TCP通信，HTTPS 是先和SSL通信，再由SSL和 TCP通信

  • 在浏览器中输入 url 地址 ->> 显示主页的过程

    DNS 解析   得到ip地址 111
TCP 连接  三次握手
浏览器发送 HTTP 请求   请求报文 ：空行 请求行 请求头 请求数据
服务器处理请求并返回 HTTP 报文  相应报文：响应体 响应头 相应行
浏览器解析渲染页面  222
TCP 断开  四次握手 连接结束
    • 111  当浏览器得到 IP 地址后，数据传输还需要知道目的主机 MAC 地址，因为应用层下发数据给传输层，TCP 协议会指定源
端口号和目的端口号，然后下发给网络层。网络层会将本机地址作为源地址，获取的 IP 地址作为目的地址。然后将下发给
数据链路层，数据链路层的发送需要加入通信双方的 MAC 地址，我们本机的 MAC 地址作为源 MAC 地址，目的 MAC 地
址需要分情况处理，通过将 IP 地址与我们本机的子网掩码相与，我们可以判断我们是否与请求主机在同一个子网里，如果
在同一个子网里，我们可以使用 APR 协议获取到目的主机的 MAC 地址，如果我们不在一个子网里，那么我们的请求应该
转发给我们的网关，由它代为转发，此时同样可以通过 ARP 协议来获取网关的 MAC 地址，此时目的主机的 MAC 地址应
该为网关的地址。
    • 222 浏览器首先会根据 html 文件构建 DOM 树，根据解析到的 css 文件构建 CSSOM 树，如果遇到 script 标签，则判端
是否含有 defer 或者 async 属性，要不然 script 的加载和执行会造成页面的渲染的阻塞。当 DOM 树和 CSSOM 树建
立好后，根据它们来构建渲染树。渲染树构建好后，会根据渲染树来进行布局。布局完成后，最后使用浏览器的 UI 接口对页
面进行绘制。这个时候整个页面就显示出来了。

    • 各种协议与 HTTP 协议之间的关系

    •  

       

      上面这张图片能够很好的解释发生了什么。首先发给DNS服务器，进行域名解析，得到IP地址后生成针对目标Web服务器的HTTP请求报文，然后报文由TCP协议负责传输，为了方便通信，HTTP请求报文被分为报文段，然后每个报文段可靠的传输给对方，然后报文段由IP层负责一边中转一遍传送，服务器收到报文段后重组报文段，然后由应用层的HTTP协议处理请求的内容，请求的结果以 同样的方式进行回传。

       

 




posted on 2022-03-05 18:38  cltt  阅读(188)  评论(0)    收藏  举报

导航