前端备战秋招之计算机网络，这一篇足矣

前端备战秋招之计算机网络

文章内容较长，但愿阅读的同窗可以细品，如内容有差错，还请评论区斧正

我的博客上查看原文

常见协议的端口

OSI体系结构

自低向上(7层结构)

1. 物理层
2. 数据链路层
3. 网络层
4. 传输层
5. 会话层
6. 表现层
7. 应用层

TODO：贴生动形象图

TCP/IP

自底向上（4层）

1. 网络接口层
2. 网络IP层
3. 运输层
4. 应用层

TODO：贴生动形象图

五层体协结构

自底向上

1. 物理层
2. 数据链路层
3. 网络层
4. 运输层
5. 应用层

TODO：贴生动形象图

网际层IP协议

• ARP:地址解析协议--从网络层使用的 IP 地址，解析出在数据链路层使用的硬件地址
• ICMP：网际控制报文协议--用于在IP主机、路由器之间传递控制消息
  • ICMP 容许主机或路由器报告差错状况和提供有关异常状况的报告
  • ICMP 属于IP 层的协议
  • PING 使用了 ICMP 回送请求与回送回答报文
• IGMP：网际组管理协议--

IP地址分类

类别	构成(x+网络号+主机号)	范围	用途
A	0+7+24	1.0.0.1---126.255.255.254
B	10+14+16	128.0.0.0---191.255.0.0
C	110+21+8	192.0.0.0--- 223.255.255.0
D	1110+ 28(多播)		多播地址
E	11110+留用		保留从此使用

通讯类型

• 单播：从一台主机向另外一台主机发送数据包的过程
• 组播：从一台主机向选定的一组主机发送数据包的过程
• 广播：从一台主机向该网络中的全部主机发送数据包的过程
  • A类、B类与C类IP地址中主机号全1的地址为直接广播地址

IP数据报

构成

• 首部
  • 前：固定长度20
  • 后：有可选字段，长度可变
• 数据

图解构成

TODO：想办法巧妙记住

• 版本：4位--IP协议版本，等于4表明IPV4
• 首部长度：4位--可表示的最大数值15*4=60字节，所以 IP 的首部长度的最大值是 60 字节
• 区分服务：8位--用来得到更好的服务，在通常的状况下都不使用这个字段
• 总长度：16位--首部和数据之和长度，单位字节，因而数据报的最大长度为65535字节 2^16-1
  • 总长度必须不超过最大传送单元 MTU
• 标识：16位--计数器，用来产生IP数据报的标识
• 标志：3位--目前只有前两位有意义
  • 最低位MF（More Fragment）：1--后面还有分片，0--为最后一个分片
  • 中间位DF（Don't Fragment）：0--才容许分片
• 片偏移：13位--指出：较长的分组在分片后，某片在原分组中的相对位置
  • 片偏移以 8 个字节为偏移单位
• 生存时间：8位--记为TTL（Time To Live），数据报在网络中可经过的路由器数的最大值
• 协议：8位--指出此数据报携带的数据使用何种协议
  • 以便目的主机的 IP 层将数据部分上交给那个处理过程
• 首部检验和：16位--只检验数据报的首部，不检验数据部分
  • 这里不采用 CRC 检验码而采用简单的计算方法
  • IP 数据报首部检验和的计算采用 16 位二进制反码求和算法
• 源地址：32位--4字节
• 目的地之：32位--4字节

PING

• PING 用来测试两个主机之间的连通性
• PING 使用了 ICMP 回送请求与回送回答报文
• PING 是应用层直接使用网络层 ICMP 的例子，它没有经过运输层的 TCP 或UDP

运输层

UDP

用户数据报协议（User Datagram Protocol）

• 数据单位协议：TCP报文段

特色

• 无链接服务协议
  • 传送数据以前不须要创建链接
• 尽最大努力交付，不提供可靠交付
  • 数据报文的搬运工，不保证有序且不丢失的传递到对端
• 面向报文的
• 没有拥塞控制，没有流量控制算法
• 支持一对1、一对多、多对一和多对多的交互通讯
• UDP 的首部开销小，只有 8 个字节，比 TCP 的 20 个字节的首部要短

面向无链接

• UDP 是不须要和 TCP 同样在发送数据前进行三次握手创建链接，想发数据就能够开始发送了
• 只是数据报文的搬运工，不会对数据报文进行任何拆分和拼接操做
  • 发送端：应用层将数据传递给传输层的 UDP 协议，UDP 只会给数据增长一个 UDP 头,表示用的是 UDP 协议，而后就传递给网络层了
  • 接收端：网络层将数据传递给传输层，UDP 只去除 IP 报文头就传递给应用层，不会任何拼接操做

不可靠性

• 不可靠性体如今无链接上
  • 通讯不须要创建链接,想发就发
• 收到什么数据就发生什么数据,不对数据进行校验与备份
• 不关心发送端是否收到了数据
• 没有拥堵控制会以恒定的速度发送数据
  • 在网络条件很差的状况下会致使丢包

高效

• UDP 的首部开销小，只有 8 个字节，比 TCP 的 20 个字节的首部要少得多

传输方式

• 一对多：单播
• 多对多：多播
• 多对一：广播

适合场景

对当前网络通信质量要求不高的时候,实时性要求高的地方均可以看到 UDP 的身影，要求网络通信速度尽可能的快，这时就使用UDP

• 网游
• 直播
• 语音
• 视屏等等

数据报格式

• 源端口--16位
• 目的端口--16位
• 整个数据报文的长度--16位
• 检验和--16位该字段用于发现头部信息和数据中的错误

总结

• UDP 相比 TCP 简单的多，不须要创建链接，不须要验证数据报文，不须要流量控制，只会把想发的数据报文直接发送给对端
• 虽然 UDP 并无 TCP 传输来的准确，可是也能在不少实时性要求高的地方有所做为

TCP

传输控制协议（Transmission Control Protocol）

• 数据单位协议：UDP报文、用户数据报

特色

• 面向链接的运输层协议
• 每一条 TCP 链接只能有两个端点 (endpoint)，每一条 TCP 链接只能是点对点的（一对一）
• 提供可靠交付的服务
• 提供全双工通讯
• 面向字节流
  • 但 TCP 传送的数据单元倒是报文段
• TCP 不提供广播或多播服务
• 首部的前 20 个字节是固定的，后面有 4n 字节是根据须要而增长的选项 (n 是整数)
  • 所以 TCP 首部的最小长度是 20 字节

创建链接三次握手

三报文握手主要是为了防止已失效的链接请求报文段忽然又传送到了，于是产生错误。

起初，两端都为 CLOSED 状态。在通讯开始前，双方都会建立 TCB。 服务器建立完 TCB 后便进入 LISTEN 状态，此时开始等待客户端发送数据

1. 第一次握手
   • 客户端发送的SYN=1（同步序列号seq=x）的包到服务端并变为SYN-SENT（请求链接）状态，等待服务端响应
2. 第二次握手
   • 服务端收到客户端请求后，发送一个包（SYN=1，ACK=1，seq=y,ack=x+1）给客户发端，服务端进入SYN_RECEVIED状态
3. 第三次握手
   • 客户端收到服务端响应的包（SYN=1，ACK=1）后，再向服务端发送确认包（ACK=1，seq=x+1，ack=y+1），发送完毕，客户端和服务端都进入ESTABLISHED状态，完成握手

链接释放四次挥手

数据传输结束后，通讯的双方均可释放链接

TCP 是全双工的，在断开链接时两端都须要发送 FIN 和 ACK

1. 第一次挥手
   • 客户端认为数据发送完成，向服务端发送连接释放请求(FIN=1,序号seq=u)，等待服务端确认
2. 第二次挥手
   • 服务端收到请求后,通知应用层要释放 TCP 连接。而后会发出确认包（ACK =1，seq=V,ACK=u+1），并进入 CLOSE_WAIT 状态
     • 此时代表 客户端 到 服务端 的链接已经释放，再也不接收 客户端 发的数据了
     • 可是由于 TCP 链接是双向的，此时处于半关闭状态服务端 仍旧能够发送数据给 客户端
     • 服务端若是此时还有没发完的数据会继续发送
3. 第三次挥手
   • 服务端发送完毕后向 客户端 发送链接释放请求(FIN=1,ACK=1,seq=w,ack=u+1),而后 服务端 便进入 LAST-ACK 状态
4. 第四次挥手
   • 客户端收到链接释放报文段后，向服务端发送确认应答
   • 而后 客户端 进入 TIME-WAIT 状态
     • 该状态会持续 2MSL（最大段生存期，指报文段在网络中生存的时间，超时会被抛弃） 时间，若该时间段内没有 B 的重发请求的话，就进入 CLOSED 状态。当 服务端 收到确认应答后，也便进入 CLOSED 状态。

首部格式

• 源端口：2字节
• 目的端口：2字节
  • 端口是运输层与应用层的服务接口。运输层的复用和分用功能都要经过端口才能实现
• 序号：4 字节
  • TCP 链接中传送的数据流中的每个字节都编上一个序号
  • 序号字段的值则指的是本报文段所发送的数据的第一个字节的序号
  • 报文段的序号字段值=301，而携带的数据共有100字节，则本报文段的数据第一个字节序号是301，最后一个字节的序号是400.那么下一个报文段的数据序号应当是401
• 确认号：4 字节，是指望收到对方的下一个报文段的数据的第一个字节的序号
  • 若确认号=N 则表示：到序号N-1为止的全部数据都已正确收到
  • 若是接收方B收到A发送过来的报文段，序号=501，数据长度是200字节，代表B收到了A发送的到序号700为止的数据。则B发送给A的确认报文段中把确认号设置为701
• 数据偏移：4位，指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远
  • 单位是4字节
  • 其实是TCP报文段的首部长度
  • 最大TCP报文段首部=60字节=(2^4-1)*4
• 保留字段：6 位，保留为从此使用
  • 目前应置为 0
• URG：1位，紧急（urgent）
  • 当 URG为1 时，代表紧急指针字段有效，它告诉系统此报文段中有紧急数据，应尽快传送(至关于高优先级的数据)
• ACK：1位，确认（acknowledge）
  • ACK=1时确认号才有效
• PSH：1位，推送（push）
  • PSH = 1 的报文段，就尽快地交付接收应用进程，而再也不等到整个缓存都填满了后再向上交付
• RST：1位，复位（reset）
  • RST=1，TCP 链接中出现严重差错（如因为主机崩溃或其余缘由），必须释放链接，而后再从新创建运输链接
• SYN：1位，同步（synchronous）
  • SYN = 1 表示这是一个链接请求或链接接受报文
    • SYN=1 ACK=0: 链接请求报文段
    • SYN=1 ACK=1：链接接收报文段
• FIN：1位，终止（finish）
  • FIN = 1 代表此报文段的发送端的数据已发送完毕，并要求释放运输链接
• 窗口字段：2 字节-窗口是发送本报文段的一方的接收窗口，是用来让对方设置发送窗口的依据
  • 如确认号=701，窗口字段=1000，则表示告诉对方：从701号开始，个人接收缓存还能够接收1000字节
• 检验和：2 字节，检验和字段检验的范围包括首部和数据这两部分
  • 在计算检验和时，要在 TCP 报文段的前面加上 12 字节的伪首部
• 紧急指针字段：2字节，指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文段数据的最前面）
• 选项字段：长度可变
  • TCP 最初只规定了一种选项，即最大报文段长度 MSS
    • MSS 告诉对方TCP：“个人缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节。”
    • 数据字段加上 TCP 首部才等于整个的 TCP 报文段
    • 因此，MSS是“TCP 报文段长度减去 TCP 首部长度”
• 填充字段：这是为了使整个首部长度是 4 字节的整数倍

可靠传输工做原理

中止等待ARQ

每发送完一个分组就中止发送，等待对方的确认。在收到确认后再发送下一个分组。

连续ARQ

发送方维持的发送窗口，它的意义是：位于发送窗口内的分组均可连续发送出去，而不须要等待对方的确认。这样，信道利用率就提升了

连续 ARQ 协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。

流量控制

流量控制所要作的就是抑制发送端发送数据的速率，以便使接收端来得及接收

利用滑动窗口实现流量控制

拥塞控制

拥塞控制就是防止过多的数据注入到网络中，使网络中的路由器或链路不致过载

• TCP 采用基于窗口的方法进行拥塞控制。该方法属于闭环控制方法。
• TCP发送方维持一个拥塞窗口 CWND
  • 拥塞窗口的大小取决于网络的拥塞程度，而且动态地在变化。
  • 发送端利用拥塞窗口根据网络的拥塞状况调整发送的数据量。
  • 因此，发送窗口大小不只取决于接收方公告的接收窗口，还取决于网络的拥塞情况，因此真正的发送窗口值为：min（公告窗口值，拥塞窗口值）

拥塞的判断

• 重传定时器超时
• 收到三个相同重复的ACK

四种控制算法

• 慢开始：由小到大逐渐增大拥塞窗口数值
• 拥塞避免：让拥塞窗口 cwnd 缓慢地增大，即每通过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是加倍，使拥塞窗口 cwnd 按线性规律缓慢增加
• 快重传：让发送方尽早知道发生了个别报文段的丢失
  • 发送方只要一连收到三个重复确认，就知道接收方确实没有收到报文段，于是应当当即进行重传
• 快恢复：当发送端收到连续三个重复的确认时，因为发送方如今认为网络极可能没有发生拥塞，所以如今不执行慢开始算法，而是执行快恢复算法

适合场景

• HTTP
• FTP
• SMTP
• 文件传输
• 游戏。。。

TCP与UDP相关问题

1.为何 TCP 创建链接须要三次握手，明明两次就能够创建起链接？

• 防止出现失效的链接请求报文段被服务端接收的状况，从而产生错误
• 若是只有1次：客户端收到请求后，没收到应答，没法判断连接是否链接成功
• 若是只有2次：
  • 客户端发送链接请求后，等待服务器端的应答。
  • 如过客户端的SYN过了一段时间没有到达服务器端，客户端连接超时，会从新发送一次链接请求
  • 若是重发的此次服务器端收到了，且应答了客户端，链接就创建了
  • 可是创建后，第一个SYN也到达服务端了，这时服务端会认为这是一个新链接，会再给客户端发送一个ACK，这个ACK固然会被客户端丢弃
  • 可是此时服务器端已经为这个链接分配资源了，并且服务器端会一直维持着这个资源，会形成浪费

2.三次握手过程当中能够携带数据么？

• 第三次能够携带
  • 客户端已经处于ESTABLIEISH状态，已经可以确认服务端的接收，发送能力正常，这个时候能够携带
• 前两次不能够
  • 一旦有人想攻击服务器，只须要在第一次握手中的 SYN 报文中放大量数据，那么服务器会消耗更多的时间和内存空间去处理这些数据，增大了服务器被攻击的风险

3.为何 A 要进入 TIME-WAIT 状态，等待 2MSL 时间后才进入 CLOSED 状态

MSL -- Maximum Segment Lifetime -- 报文最大生存时间,最长报文寿命

1. 为了保证 客户端 发送的最后一个 ACK 报文段可以到达 服务端
2. 防止 “已失效的链接请求报文段”出如今本链接中
   • 若 客户端 发完确认应答后直接进入 CLOSED 状态，若是确认应答由于网络问题一直没有到达，那么会形成 服务端 不能正常关闭。
   • 若是不等待客户端直接关闭，当服务端还有数据包要发送给客户端时，且还在传输的路上，若客户端的端口此时恰好被新的应用占用，那么就接收到了无用数据包，形成数据包混乱
3. 2MSL意义:
   • 1 个 MSL 确保四次挥手中主动关闭方最后的 ACK 报文最终能达到对端
   • 1 个 MSL 确保对端没有收到 ACK 重传的 FIN 报文能够到达
   • 通过2MSL,可使本连接持续时间内所产生的全部报文段,都从网络中消失

4.TCP与UDP的区别

• UDP 协议是面向无链接的:不须要在正式传递数据以前先链接起双方

• UDP 协议只是数据报文的搬运工:不保证有序且不丢失的传递到对端

• UDP 协议也没有任何控制流量的算法

• UDP 相较于 TCP 更加的轻便

• UDP 的首部开销小，只有 8 个字节，比 TCP 的 20 个字节的首部要少得多

• TCP面向链接的

• 基本与UDP反着来

• 创建链接3次握手

• 断开链接4次挥手

• 经过各类算法保持保证传输的可靠性

HTTP

超文本传输协议(HyperText Transfer Protocol）),基于TCP实现的应用层协议

特色

• 请求响应模型:客户端发送请求,服务端响应请求
• 无状态协议:不须要创建持久连接

工做过程

1. 地址解析
2. 封装HTTP请求数据包
3. 封装成TCP包，创建TCP连接
4. 客户端发送请求
5. 服务端响应
6. 关闭TCP连接
   • 保持连接的方案:在请求/响应头中加入 Connection:keep-alive就能够保持连接打开状态

请求构成

• 请求行
• 首部
• 实体

响应构成

• 协议/版本号 状态码
• 首部
• 实体

请求行

GET /images/logo.gif HTTP/1.1

由请求方法、URL、协议版本组成

请求方法

请求方法分为不少种，最经常使用的也就是 Get 和 Post 了。虽然请求方法有不少，可是更多的是传达一个语义，而不是说 Post 能作的事情 Get 就不能作了

• Get:应该只被用于获取数据
• Post:用于将实体提交到指定的资源，一般致使在服务器上的状态变化或反作用.
• Put:求有效载荷替换目标资源的全部当前表示,即更新操做.
• Delete:删除指定的资源
• Patch:用于对资源应用部分修改
• Head:请求一个与GET请求的响应相同的响应，但没有响应体.
• Connect:创建一个到由目标资源标识的服务器的隧道
• Options:描述目标资源的通讯选项
• Trace:沿着到目标资源的路径执行一个消息环回测试。

URI

Uniform Resource Identifier--统一资源标识符,用于区分互联网上不一样资源

URI 包含 URL 与 URN

URI只能使用ASCII, ASCII 以外的字符不支持显示,所以，URI 引入了编码机制，将全部非 ASCII 码字符和界定符转为十六进制字节值，而后在前面加个%

URL

scheme://host:port/path?query

• scheme:协议,HTTP,HTTPS,FTP
• host:主机名,sugarat.top
• port:端口号,默认80,https默认443
• path:资源路径
• query:用于查询的参数

URN

path?query

反作用和幂等

• 反作用:指对服务器上的资源作改变

  • 搜索是无反作用的，注册是反作用

• 幂等:指发送 M 和 N 次请求（二者不相同且都大于 1）

  • 服务器上资源的状态一致，好比注册 10 个和 11 个账号是不幂等的
  • 对文章进行更改 10 次和 11 次是幂等的。由于前者是多了一个帐号（资源），后者只是更新同一个资源。

常见首部

通用首部

字段	做用
Cache-Control	控制缓存的行为
Connection	浏览器想要优先使用的链接类型，好比 keep-alive
Date	建立报文时间
Pragma	报文指令
Via	代理服务器相关信息
Transfer-Encoding	传输编码方式
Upgrade	要求客户端升级协议
Warning	在内容中可能存在错误

请求首部

字段	做用
Host	访问资源所在的主机名
Accept	能正确接收的媒体类型(application/json)
Accept-Charset	能正确接收的字符集
Accept-Encoding	能正确接收的编码格式列表(gzip)
User-Agent	发送请求的客户端信息
Referer	浏览器所访问的前一个页面
Accept-Language	能正确接收的语言列表(zh-CN, zh, en)
If-Match	值与请求资源ETag相同才会处理请求
If-None-Match	值与请求资源ETag不相同才会处理请求

响应首部

字段	做用
Age	资源在代理缓存中存在的时间
Server	服务器名字
Content-Length	告知客户端资源长度
Expires	告知客户端资源失效日期
Last-Modified	告知客户端资源最后一次修改的时间
E-tag	文件指纹，资源惟一标识符
Location	客户端重定向到某个 URL
Proxy-Authenticate	向代理服务器发送验证信息

cookie

字段	做用
Cookie	请求时携带的cookie
Set-Cookie	响应时服务端传回的cookie

压缩相关

字段	做用
Content-Encoding	发送端使用的编码方式
Accept-Encoding	接收端支持的编码格式

状态码

1xx协议处理的中间状态

• 101 在HTTP升级为WebSocket的时候，若是服务器赞成变动，就会发送状态码 101

2xx成功

• 200 客户端的请求被服务端正确处理
• 204 请求成功但响应报文不包含实体的主体部分
• 206 范围请求,客户端进行了部分请求,服务端返回指定部分的内容
• 205 与204做用一致但要求请求方重置内容

3xx重定向

• 301 永久性重定向,表示资源已被分配了新的url
• 302 临时性重定向,表示资源临时被分配了新的url
• 304 当客户端拥有可能过时的缓存时，会携带缓存的标识 etag、时间等信息询问服务器缓存是否仍可复用，而304是告诉客户端能够复用缓存
• 303 资源存在另外一个url,服务端要求客户端使用get请求
• 307 临时重定向,向新的url发送一样的请求

4XX客户端错误

• 400 请求报文存在语法错误
• 401 发送的请求须要有经过 HTTP 认证的认证信息
• 403 对请求资源的访问被服务器拒绝,资源容许访问,但请求不知足条件
• 404 在服务器上没有找到请求的资源
• 405 当前的请求方法不被容许
• 415 不支持的媒体类型,检查Content-Type

5XX 服务器错误

• 500 服务器端在收到请求后后，执行相关动做时发生了错误
• 502 bad gate无效网关
• 501 表示服务器不支持当前请求所须要的某个功能
• 503 代表服务器暂时处于超负载或正在停机维护，没法处理请求

缺点

• 通讯使用明文，可能被窃听
• 不验证通讯方的身份，可能遭遇假装
• 没法证实报文的完整性，有可能遭遇篡改

HTTPS

HTTP + 加密 + 认证 + 完整性保护 = HTTPS

• 基于HTTP协议，经过SSL或TLS协议提供加密处理数据、验证对方身份以及数据完整性保护
• 在HTTP上创建SSL加密层，并对传输数据进行加密，是HTTP协议的安全版

特色

经过抓包获取到的数据不是明文传输的

• 内容加密：采用混合加密技术，中间者没法直接查看明文内容
• 验证身份：经过证书认证客户端访问的是本身的服务器
• 保护数据完整性：防止传输的内容被中间人冒充或者篡改

缺点

• 性能损耗
• 增长延时
• 消耗较多的CPU资源

优化方案

• CDN
• 会话缓存

TLS/SSL

TLS是传输层加密协议，前身是SSL协议

TLS 协议位于传输层之上，应用层之下

HTTPS 仍是经过了 HTTP 来传输信息，可是信息经过 TLS 协议进行了加密

功能实现

利用非对称加密实现身份认证和密钥协商，采用对称加密算法协商的密钥对数据加密，基于散列函数验证信息的完整性

• 散列函数 Hash:MD5,SHA,SHA256---完成校验
• 对称加密 1-1:AES,DES,RC4---信息加密
• 非对称加密 1-N:RSA,ECC,DH---身份验证秘钥协商

对称加密

对称加密就是两边拥有相同的秘钥，两边都知道如何将密文加密解密。

这种加密方式当然很好，可是问题就在于如何让双方知道秘钥。由于传输数据都是走的网络，若是将秘钥经过网络的方式传递的话，一旦秘钥被截获就没有加密的意义的。

非对称加密

有公钥私钥之分，公钥全部人均可以知道，能够将数据用公钥加密，可是将数据解密必须使用私钥解密，私钥只有分发公钥的一方才知道。

这种加密方式就能够完美解决对称加密存在的问题。假设如今两端须要使用对称加密，那么在这以前，能够先使用非对称加密交换秘钥。

简单流程以下：首先服务端将公钥公布出去，那么客户端也就知道公钥了。接下来客户端建立一个秘钥，而后经过公钥加密并发送给服务端，服务端接收到密文之后经过私钥解密出正确的秘钥，这时候两端就都知道秘钥是什么了。

TLS1.2握手过程

1. 客户端发出请求:
   • 一个随机值(用于生成对话秘钥)
   • 支持的协议
   • 支持加密方式
   • 支持压缩的方法
2. 服务端收到客户端的请求，向客户端发出回应:
   • 一个随机值(用于生成对话秘钥)
   • 肯定使用的协议
   • 肯定使用的加密方式
   • 发送本身的证书（若是须要验证客户端证书须要说明）
3. 客户端收到服务端的证书并验证是否有效，若是证书没问题,向服务端发送一个请求:
   • 生成一个随机值(用证书公钥加密)
   • 编码改变通知(随后的信息将使用双方商定的加密方法和秘钥发送)
   • 客户端握手结束通知(前面发送的全部内容的hash值，用来提供给服务端校验)
4. 服务端最后响应
   • 服务器收到客户端的第三个随机数以后(用私钥解密)结合以前的两个明文随机数，计算生成本次会话所用的"会话密钥"
   • 编码改变通知(随后的信息都将用双方商定的加密方法和密钥发送)
   • 服务器握手结束通知(前面发送的全部内容的hash值，用来提供给客户端校验)

经过以上步骤可知，在 TLS 握手阶段，两端使用非对称加密的方式来通讯，实现身份验证并协商对称加密使用的密钥,可是由于非对称加密损耗的性能比对称加密大，因此在正式传输数据时，两端使用对称加密的方式通讯。不一样的节点之间采用的对称密钥不一样，从而能够保证信息只能通讯双方获取

TLS1.3

TLS1.3 中废除了很是多的加密算法,若是私钥泄露,那么中间人能够破解全部密文

TLS1.3 在 TLS1.2 的基础上废除了大量的算法，提高了安全性。同时利用会话复用节省了从新生成密钥的时间，利用 PSK 作到了0-RTT链接

HTTP2

HTTP/2 相比于 HTTP/1，大幅度提升了网页的性能

在 HTTP/1 中,浏览器限制了同一个域名下的请求数量（Chrome 下通常是限制六个链接）

当页面中须要请求不少资源的时候，队头阻塞（Head of line blocking）会致使在达到最大请求数量时，剩余的资源须要等待其余资源请求完成后才能发起请求

特色

• HTTP/2 中引入了多路复用的技术，这个技术能够只经过一个 TCP 链接就能够传输全部的请求数据。多路复用很好的解决了浏览器限制同一个域名下的请求数量的问题，同时也间接更容易实现全速传输
• 在以前的 HTTP 版本中，咱们是经过文本的方式传输数据。在 HTTP/2 中引入了新的编码机制，全部传输的数据都会被分割，并采用二进制格式编码。

多路复用

在 HTTP/2 中，有两个很是重要的概念，分别是:

• 帧（frame） 表明最小的数据单位，每一个帧会标识出该帧属于哪一个流
• 流（stream） 是多个帧组成的数据流

多路复用，就是在一个 TCP 链接中能够存在多条流。换句话说，也就是能够发送多个请求，对端能够经过帧中的标识知道属于哪一个请求。

经过这个技术，多个请求共享一个TCP链接，能够避免 HTTP 旧版本中的队头阻塞问题，极大的提升传输性能

Header 压缩

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

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

服务端 Push

在 HTTP/2 中，服务端能够在客户端某个请求后，主动推送其余资源。

能够想象如下状况，某些资源客户端是必定会请求的，这时就能够采起服务端 push 的技术，提早给客户端推送必要的资源，这样在使用的时候就能够相对减小一点延迟时间。

设置请求优先级

• 可在新建的流所传递HEADERS帧中包含优先级priority属性
• 可单独经过PRIORITY帧专门设置流的优先级属性

使用前置条件

• 支持HTTP2的客户端与服务端
• 域名必须支持HTPPS协议（基于TLS/1.2或以上版本的加密链接）
• 服务器的openssl版本必须大于1.0.2

可经过Nginx搭建HTTP2服务器

HTTP3

HTTP/2 使用了多路复用

通常来讲同一域名下只须要使用一个 TCP 链接。当这个链接中出现了丢包的状况，那就会致使 HTTP/2 的表现状况反倒不如 HTTP/1 了

• 出现丢包的状况下，整个 TCP 都要开始等待重传，也就致使了后面的全部数据都被阻塞了
• 对于 HTTP/1 来讲，能够开启多个 TCP 链接，出现这种状况反到只会影响其中一个链接，剩余的 TCP 链接还能够正常传输数据

基于这个缘由，Google 就更起炉灶搞了一个基于 UDP 协议的 QUIC 协议，而且使用在了 HTTP/3 上

QUIC

QUIC 基于 UDP，在本来的基础上新增了不少功能

• 多路复用
• 0-RTT
• 使用TLS1.3加密
• 流量控制
• 有序交付
• 重传
• 。。。

一种全新的基于UDP的web开发协议。能够用一个公式大体归纳：

TCP + TLS + HTTP2 = UDP + QUIC + HTTP2’s API

QUIC协议虽然是基于UDP，但它不但具备TCP的可靠性、拥塞控制、流量控制等，且在TCP协议的基础上作了一些改进，好比避免了队首阻塞；

另外，QUIC协议具备TLS的安全传输特性，实现了TLS的保密功能，同时又使用更少的RTT创建安全的会话。

多路复用

无队头阻塞的多路复用

QUIC 原生实现了这个功能，而且传输的单个数据流能够保证有序交付且不会影响其余的数据流，这样的技术就解决了以前 TCP 存在的问题

QUIC 在移动端的表现也会比 TCP 好:

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

0-RTT

与其余协议比较

• TCP创建连接须要三次握手，每次链接须要额外的RTT
• HTTPS加入了TLS还须要额外的RTT

0-RTT状况

经过使用相似 TCP 快速打开的技术，缓存当前会话的上下文，在下次恢复会话的时候，只须要将以前的缓存传递给服务端验证经过就能够进行传输了

1-RTT状况

新的QUIC链接至少须要1 RTT才能完成握手

纠错机制

假如说此次我要发送三个包，那么协议会算出这三个包的异或值并单独发出一个校验包，也就是总共发出了四个包

当出现其中的非校验包丢包的状况时，能够经过另外三个包计算出丢失的数据包的内容。

固然这种技术只能使用在丢失一个包的状况下，若是出现丢失多个包就不能使用纠错机制了，只能使用重传的方式了

结构对比图

总结HTTP/2|3

• HTTP/2 经过多路复用、二进制流、Header 压缩等等技术，极大地提升了性能，可是仍是存在着必定的问题的
• QUIC 基于 UDP 实现，是 HTTP/3 中的底层支撑协议，该协议基于 UDP，又取了 TCP 中的精华，实现了即快又可靠的协议，但目前兼容性并很差

HTTP相关问题

1.POST和GET区别

使用场景上区分

• GET多用于无反作用，幂等
• POST多用于有反作用，不冪等

技术上

• GET会缓存，POST不会缓存
• GET请求参数会出如今url中，post相对安全一点
• URL有长度限制，会影响GET请求（浏览器规定）
• POST支持更多的编码类型，且不对数据作限制
• GET只能进行URL编码，只能接受ASCII字符

2.HTTP与HTTPS区别

• 安全：HTTP明文传输数据，HTTPS是在HTTP上创建SSL/TLS加密层，并对传输数据进行加密，更加安全
• 端口：http使用80端口，https使用443
• 速度：HTTP页面响应速度更快
  • HTTP只需创建TCP链接，发送3个包
  • HTTPS还须要经历TLS握手9个包须要，一共12个

3.HTTP1.1 如何解决 HTTP 的队头阻塞问题？

1. 域名分片：使用多个指向同一服务器的二级域名
2. 并发链接：也就是同时对一个域名发起多个长链接，用数量来解决质量的问题
   1. 浏览器通常会有限制

4.若是响应头Content-Length=0那么是发出来被截取了仍是没发出来

结论：发出来被截取了

• Content-Length比实际的长度大, 服务端/客户端读取到消息结尾后, 会等待下一个字节,无响应直到超时
• Content-Length < 实际长度:首次请求的消息会被截取
• Content-Length若是存在且生效, 必须是正确的, 不然会发生异常
• 若是报文中包含Transfer-Encoding: chunked首部, 那么Content-Length将被忽略.