网络协议(一)

协议

• 协议，网络协议的简称，网络协议是指通信计算机双方必须共同遵从的一组约定。

• 为了使数据在网络上从源到达目的，网络通信的参与方必须遵循相同的规则，这套规则称为协议（protocol），它最终体现为在网络上传输的数据包的格式。

  • 协议的三要素包括 语法 语义 时序

• 以上内容来自百度百科

  不谈它在网络中的表示，我们所理解的，字面上的协议，就是约定，双方都明白且遵循的一种规则，也就是说是人为规定的，不是自然产生的。有人的地方就有江湖，协议也不例外，人有时代局限性，协议当然也有，也可以说网络协议是人们为了避免纷争，妥协出来的产物。协议一直在不断完善中，我们要学习与理解现在的协议发展，就要从头开始去理解。

• ISO/OSI 协议模型

层次	说明
物理层	物理层（Physical Layer）在局部局域网上传送数据帧（data frame），它负责管理电脑通信设备和网络媒体之间的互通。包括了针脚、电压、线缆规范、集线器、中继器、网卡、主机接口卡等。
数据链路层	数据链路层（Data Link Layer）负责网络寻址、错误侦测和改错。当表头和表尾被加至数据包时，会形成帧。数据链表头（DLH）是包含了物理地址和错误侦测及改错的方法。数据链表尾（DLT）是一串指示数据包末端的字符串。例如以太网、无线局域网（Wi-Fi）和通用分组无线服务（GPRS）等。分为两个子层：逻辑链路控制（logical link control，LLC）子层和介质访问控制（Media access control，MAC）子层
网络层	网络层（Network Layer）决定数据的路径选择和转寄，将网络表头（NH）加至数据包，以形成报文。网络表头包含了网络数据。例如:互联网协议（IP）等。
传输层	传输层（Transport Layer）把传输表头（TH）加至数据以形成数据包。传输表头包含了所使用的协议等发送信息。例如:传输控制协议（TCP）等。
会话层	会话层（Session Layer）负责在数据传输中设置和维护电脑网络中两台电脑之间的通信连接。
表示层	表达层（Presentation Layer）把数据转换为能与接收者的系统格式兼容并适合传输的格式。
应用层	应用层（Application Layer）提供为应用软件而设的接口，以设置与另一应用软件之间的通信。例如: HTTP，HTTPS，FTP，TELNET，SSH，SMTP，POP3,HTML等。

• 1984年，ISO发布了著名的ISO/IEC 7498标准，它定义了网络互联的7层框架，也就是开放式系统互联参考模型 （OSI，Open Systems Interconnection）(by来自维基百科)

• 因为协议由人设计，所以各大公司都有一套自己的玩意，这些东西一直到现在（2019）依然对兼容性有着很大的约束.

• 七层模型也称为理想中的模型，实际上一般的业务程序员在工作中能感知的 无非就是上层的应用层 http 网络层 IP 传输层 TCP 一般没事都不会关心，这也体现出分层的好处，减少心智负担

  • 所以 也有

    • 五层划分为：应用层（应用，表示，会话）、传输层、网络层、数据链路层、物理层。

    • 四层划分为：应用层（应用，表示，会话）、传输层、网络层、网络接口层（数据链路层、物理层）。

• 通俗来说 物理层就是来保证数据能正常在实体设备间进行传输的，它只负责跟硬件设备打交道，数据链路层就是对电信号进行分组

• 数据链路层的以太网协议Ethernet。

  • 一组电信号称之为一个数据包，或者叫做一个**“帧”**
  • 每一数据帧分成：报头head和数据data两部分
  • [【head】【data】]
    • head包含：（固定18个字节）
      • 发送者（源地址，6个字节）
      • 接收者（目标地址，6个字节）
      • 数据类型（6个字节）
    • data包含：（最短46字节，最长1500字节）
    • 其中的源地址和目标地址指的是mac地址
  • Ethernet规定接入Internet的设备都必须具备网卡，发送端的和接收端的地址便是指网卡的地址，即Mac地址。每块网卡出厂时都被烧录上一个实际上唯一的Mac地址，长度为48位2进制，通常由12位16进制数表示

• 有了以太网协议后，在同一局域网内的设备就可以通信，局域网内的计算机不管是对内还是对外都是靠吼，这就是数据链路层的工作方式-----广播（ARP协议），这个里面肯定还有细节点，之后再写

• 当然，数据链路层仅限于局域网的信息传递，问题是，跨局域网设备通讯是怎么做的呢？

HTTP

• HTTP 协议始于 1991 年的 HTTP/0.9，

• 1996 年 HTTP/1.0 规范的发布

  • 在 HTTP/1.0 中，客户端和服务器之间交换的每个请求 / 响应都会创建一个新的 TCP 连接
  • 这意味着所有 TCP 握手均在每个请求之前完成，因此所有请求都会产生延迟。
  • TCP 不是在建立连接后尽快发送所有未完成的数据，而需要“慢启动”的预热时间，这使 TCP 拥塞控制算法能够随时确定可以传输的数据量，防止网络路径发生拥塞，并避免将无法处理的数据包都堆到网络中。但是，由于新连接必须经过缓慢的启动过程，因此它们无法立即使用所有可用的网络带宽。

• 1999 年演变为 HTTP/1.1，并由 IETF（互联网工程任务组）负责进行标准化。

  • 引入保持活动连接的概念来解决这些问题 Connection: keep-alive

  • 允许客户端复用 TCP 连接，从而分摊了建立初始连接和针对多个请求缓慢启动的成本

  • 尽管多个请求可以共享同一个连接，但它们仍需逐个序列化它们，因此任意时点上客户端和服务器只能为每个连接执行一次请求 / 响应交换

  • 随着网络的发展，多年来网站所需资源（CSS、JavaScript 和图像等）不断增长，浏览器在获取和呈现网页时需要越来越多的并发性。但由于 HTTP/1.1 只允许客户端同时进行一次 HTTP 请求 / 响应交换，因此在网络层上获得并发能力的唯一方法是并行使用多个 TCP 连接到同一来源，代价就是牺牲了活动连接的大多数好处。尽管连接仍会在一定程度上（但程度不大）被复用，但我们又回到了起点。

  • **Chrome 有个机制，对于同一个域名，默认允许同时建立 6 个 TCP 持久连接。**使用持久连接时，虽然能共用一个 TCP 管道，但是在一个管道中同一时刻只能处理一个请求，在当前的请求没有结束之前，其他的请求只能处于阻塞状态。另外，如果在同一个域名下同时有 10 个请求发生，那么其中 4 个请求会进入排队等待状态，直至进行中的请求完成。

  • HTTP/1.1 有两个主要的缺点：安全不足和性能不高。

    • 明文传输 – 带来不安全性
    • 高延迟 – 带来页面加载速度的降低
      • 网络延迟问题主要由于队头阻塞 (Head-Of-Line Blocking) 产生，导致带宽无法被充分利用
      • TCP协议的堵塞
    • 无状态特性 – 带来巨大的 HTTP 头部 ，Header 里携带的内容过大，在一定程度上增加了传输成本
    • 不支持服务器推送消息

• HTTP/2 在 2015 年出现了。

  • HTTP/2 基于 SPDY，专注于性能，最大的目标是在用户和网站间只用一个连接（connec-tion）

  • 率先引入了 HTTP“流”的概念：这是一种抽象概念，允许 HTTP 实现将不同的 HTTP 交换并发地复用到同一 TCP 连接上， 使浏览器更高效地复用 TCP 连接。

  • HTTP/2 解决了最初的问题——单个 TCP 连接的使用效率低——因为现在可以通过同一连接同时传输多个请求 / 响应。但是，即使只有单个请求丢失数据，所有请求和响应也会同样受到数据包丢失（比如因为网络拥塞）的影响。这是因为尽管 HTTP/2 层可以在不同的流上隔离不同的 HTTP 交换，但是 TCP 不了解这种抽象，并且后者所看到的只是字节流，没有特殊含义。

  • TCP 的作用是以正确的顺序从一个端点到另一端点传递整个字节流。当承载某些字节的 TCP 数据包在网络路径上丢失时将在流中造成间隙，并且 TCP 需要在检测到丢失时重新发送受影响的数据包来弥补这一间隙。这样做时，即使丢失数据之后的数据属于完全不同的 HTTP 请求，自己也根本没有丢失，也能正常传递成功，它们还是不能正常传递给应用程序。因此它们只能毫无必要地产生延迟，因为 TCP 无法知道应用程序缺少了丢失的数据包时能否处理后面的数据。这个问题称为“行首阻塞”

  • SPDY 位于 HTTP 之下，TCP 和 SSL 之上，这样可以轻松兼容老版本的 HTTP 协议 (将 HTTP1.x 的内容封装成一种新的 frame 格式)，同时可以使用已有的 SSL 功能

  • 二进制传输

  • HTTP/2 传输数据量的大幅减少, 主要有两个原因: 以二进制方式传输和 Header 压缩

  • HTTP/2 将请求和响应数据分割为更小的帧，并且它们采用二进制编码。

  • 多个帧之间可以乱序发送，根据帧首部的流标识可以重新组装。

  • Header 压缩

    • 采用了新的压缩算法，主要解决了header头重复的问题

  • 多路复用

    • 在 HTTP/2 中引入了多路复用的技术。多路复用很好地解决了浏览器限制同一个域名下请求数量的问题，同时也更容易实现全速传输，毕竟新开一个 TCP 连接都需要慢慢提升传输速度。
    • 同域名下所有通信都在单个连接上完成。
    • 单个连接可以承载任意数量的双向数据流。
    • 数据流以消息的形式发送，而消息又由一个或多个帧组成，多个帧之间可以乱序发送，因为根据帧首部的流标识可以重新组装。

  • 服务器推送

  • 服务器不再完全被动地响应请求，也可以新建“流”主动向客户端发送消息。比如，在浏览器刚请求 HTML 的时候就提前把可能会用到的 JS、CSS 文件发给客户端，减少等待的延迟，这被称为 ” 服务器推送 ”（ Server Push，也叫 Cache push）

  • 提高安全性

    • 内容不再明文，而是以 二进制传输, 实际上 目前的http/2 基本上都是跑在 TLS 上的 都需要解密

  • HTTP/2 的缺点

    • 主要是底层支撑的 TCP 协议造成的
      • TCP 和 TCP+TLS 建立连接的延时
      • TCP 的队头阻塞并没有彻底解决
        • HTTP/2 中，多个请求是跑在一个 TCP 管道中的。但当出现了丢包时，HTTP/2 的表现反倒不如 HTTP/1 了。因为 TCP 为了保证可靠传输，有个特别的“丢包重传”机制，丢失的包必须要等待重新传输确认，HTTP/2 出现丢包时，整个 TCP 都要开始等待重传，那么就会阻塞该 TCP 连接中的所有请求。而对于 HTTP/1.1 来说，可以开启多个 TCP 连接，出现这种情况反倒只会影响其中一个连接，剩余的 TCP 连接还可以正常传输数据

• 2018年底，IETF 又推出新版本 HTTP/3（QUIC 和 HTTP/3）

  • 这就是 HTTP/3 的用武之地：它不是使用 TCP 作为会话的传输层，而是使用 QUIC （一种新的互联网传输协议）。该协议率先在传输层将流作为一等公民引入。多个 QUIC 流共享相同的 QUIC 连接，因此不需要额外的握手和慢启动来创建新的 QUIC 流。但 QUIC 流是独立交付的，因此在大多数情况下，只影响一个流的丢包不会影响其他流。这是因为 QUIC 数据包封装在 UDP 数据报的顶部。
  • 与 TCP 相比，使用 UDP 可以提供更大的灵活性，并且可以使 QUIC 实现完全存在于用户空间中——协议实现的更新不像 TCP 那样依赖操作系统的更新。借助 QUIC，可以将 HTTP 级别的流简单地映射到 QUIC 流的顶部，从而在享受 HTTP/2 所有好处的同时避免了行首阻塞。
  • QUIC 还结合了典型的 3 向 TCP 握手和 TLS 1.3 的握手。结合这些步骤意味着加密和身份验证能够默认提供，并且还可以更快地建立连接。换句话说，即使 HTTP 会话中的初始请求需要新的 QUIC 连接，在数据开始流动之前的等候延迟也比使用 TLS 的 TCP 要低。

• 总结

  • `HTTP/1.1· 有两个主要的缺点：安全不足和性能不高。
  • HTTP/2 完全兼容 HTTP/1，是“更安全的 HTTP、更快的 HTTPS”，头部压缩、多路复用等技术可以充分利用带宽，降低延迟，从而大幅度提高上网体验。
  • QUIC 基于 UDP 实现，是 HTTP/3 中的底层支撑协议。该协议基于 UDP，又汲取了 TCP 中的精华，实现了既快又可靠的协议。

以上就解释了为什么会出现 http/2与http/3？

http + tls 传输的基本结构

• 三次握手后 使用 tls 协议（也是三次握手）沟通传输密钥，最后才是 http内容的请求

http/3 + tls 传输的基本结构

• 三次握手时 顺便使用 tls 协议沟通传输密钥，最后才是 http内容的请求

参考

• infoQ-解密 HTTP/2 与 HTTP/3 的新特性