一、七层网络模型(OSI)

1.1、物理层

为数据端设备提供原始比特流的传输的通路,传输的内容是 比特流(Bit)

1.2、数据链路层

数据链路层最基本的服务是将源计算机网络层来的数据可靠的传输到相邻节点的目标计算机的网络层,数据链路层传输的数据是 帧(Framing)

  • 将数据封装成帧

数据链路层将网络层传递下来的 IP 数据报 进行包装,在数据前后分别添加帧头和帧尾,使其成帧,然后将帧转为比特流进行传输。

接收端在收到物理层上交的比特流后,就能根据首部和尾部的标记,从收到的比特流中识别帧的开始和结束。

image-20210811205729828

  • 透明传输

数据链路层实现透明传输和封装成帧时,使用到了转义字符

由于帧的开始和结束的标记是使用专门指明的控制字符,因此,所传输的数据中的任何 8 比特的组合一定不允许和用作帧定界的控制字符的比特编码一样,否则就会出现帧定界的错误。

image-20210811205956282

  • 差错检测

1.3、网络层

控制子网的运行,如逻辑编址、分组传输和路由选择,网络层负责在不同的网络之间(基于数据包的IP地址)尽力转发数据包,不负责丢包重传和接收顺序

1.4、传输层

传输层主要是提供不同主机上的进程之间的逻辑通信(端到端的通信),即使在不可靠的网络层(主机之间的逻辑通信)传输下,传输层也能提供可靠的传输。

(所谓的逻辑通信就是指:传输层之间看似是在水平方向传送数据,但是事实上这两个传输层之间并没有水平方向上的物理连接)

传输层对应的网络协议有 TCPUDP

1.5、会话层

用于在不同机器上的用户之间建立并管理会话。

HTTPS 使用的 SSL/TLS 协议就在这一层。

1.6、表示层

1.7、应用层

运输层仅为应用进程提供了端到端的通信服务。但不同的网络应用的应用进程之间,还需要有不同的通信规则,因此还需要有应用层协议

应用层对应的网络协议有:HTTPFTPSMTP

image-20210812094145539

二、IP 网络协议

2.1、网络协议是什么?

IP 协议是TCP/IP协议族的核心协议,其主要包含两个方面:

1、IP 头部信息

IP头部信息出现在每个IP数据报中,用于指定 IP 通信的源端 IP 地址、目的端 IP 地址,指导 IP 分片和重组,以及指定部分通信行为。

2、IP 数据报的路由和转发

IP 数据报的路由和转发发生在除目标机器之外的所有主机和路由器上。它们决定数据报是否应该转发以及如何转发。

2.2、IP 协议的特点

IP协议是TCP/IP协议族的动力,它为上层协议提供无状态、无连接、不可靠的服务。

1、无状态

无状态是指 IP 通信双方不同步传输数据的状态信息,因此所有 IP 数据报的发送、传输和接收都是相互独立、没有上下文关系的。这种服务最大的缺点就是无法处理乱序和重复的IP数据报

面向连接的协议(如 TCP )协议,能够自己处理乱序的、重复的报文段,它递交给上层协议的内容绝对是有序的、正确的。无状态服务的优点也很明显:简单、高效。我们无需为保持通信的状态而分配一些内核资源,也无需每次传输数据时都携带状态信息。

2、无连接

无连接是指IP通信双方都不长久地维持对方的任何信息。这样上层协议每次发送数据的时候,都必须明确指定对方的IP地址

3、不可靠

不可靠是指IP协议不能保证IP数据报准确地到达接收端,它只是承诺尽最大努力。很多情况都可以导致IP数据报发送失败。因此,使用 IP 服务的上层协议需要自己实现数据确认、超时重传等机制以达到可靠传输的目的。

三、TCP 协议

3.1、何谓协议?

所谓协议,是指通信的双方,为了保证通信效果,特意在通信形式和内容上的一致协商。在计算机世界中,计算机与计算机之间的沟通更加抽象复杂,为了保证能够各种应用场景下的正确通信,众多计算机世界中的协议应运而生。

这其中最重要的当属TCP协议和Http协议。

3.2、TCP 协议概述

TCP,英文全称 Transmission control protocol,直译为:传输控制协议。

它是为了在不可靠的互联网上提供可靠的端到端字节流而专门设计的一个传输协议。

  • TCP 是面向连接(虚连接)的传输层协议
  • TCP 提供可靠交付的服务,无差错、不丢失、不重复、按序到达(不丢不重,可靠有序)

可靠指保证接收方进程从缓存区中读出的字节流和发送方发出的字节流是完全一样的。

  • TCP 支持全双工通信,允许通信双方同时发送 / 接收数据,所以在双方都有设计发送缓存和接收缓存

发送缓存中存放准备发送的数据已经发送但接收方尚未确认收到的数据

接收缓存中存放按序到达但尚未被接收方应用程序读取的数据不按序到达的数据

3.3、TCP 如何保证传输可靠性

1、检验和

TCP 检验和的计算与 UDP 一样,在计算时要加上 12byte 的伪首部,检验范围包括 TCP 首部及数据部分,但是 UDP 的检验和字段为可选的,而TCP中是必须有的。

计算方法为:在发送方将整个报文段分为多个 16 位的段,然后将所有段进行反码相加,将结果存放在检验和字段中,接收方用相同的方法进行计算,如最终结果为检验字段所有位是全1则正确(UDP中为0是正确),否则存在错误。

2、序列号

TCP将每个字节的数据都进行了编号,这就是序列号,序列号的作用如下

  • 保证可靠性(当接收到的数据总共少了某个序号的数据时,可以马上知道)
  • 保证数据的按序到达
  • 提高效率,可实现多次发送,一次确认
  • 去除重复数据

数据传输过程中的确认应答处理、重发控制以及重复控制等功能都可以通过序列号来实现

3、确认应答机制(ACK)

TCP 通过确认应答机制实现可靠的数据传输

在TCP的首部中有一个标志位——ACK,此标志位表示确认号是否有效。接收方对于按序到达的数据会进行确认,当标志位ACK=1时确认首部的确认字段有效。进行确认时,确认字段值表示这个值之前的数据都已经按序到达了。而发送方如果收到了已发送的数据的确认报文,则继续传输下一部分数据;而如果等待了一定时间还没有收到确认报文就会启动重传机制

  • 正常情况下的应答机制:

image-20210812101851348

4、超时重发机制

当报文发出后在一定的时间内未收到接收方的确认,发送方就会进行重传(通常是在发出报文段后设定一个闹钟,到点了还没有收到应答则进行重传),有多种原因会导致发送方无法接收到接收端的 ACK

  • 数据包在发送的过程中丢了,接收方压根没收到数据,自然无法确认

image-20210812101939342

  • 接收方已经接收到了数据包,也向发送方发送了 ACK ,但 ACK 在发送过程中丢了

image-20210812102138526

当接收方接收到重复的数据时就将其丢掉,重新发送ACK。而要识别出重复的数据,就要用到前面提到的序列号了,利用序列号很容易就可以做到去重的效果

5、连接管理机制

TCP 建立时,使用三次握手建立连接,保证双端的发送、接收消息的能力可以得到保证。

TCP 断开时,使用四次挥手断开连接

6、流量控制

接收端处理数据的速度是有限的,如果发送方发送数据的速度过快,导致接收端的缓冲区满,而发送方继续发送,就会造成丢包,继而引起丢包重传等一系列连锁反应。
因此TCP支持根据接收端的处理能力,来决定发送端的发送速度,这个机制叫做流量控制

7、拥塞控制

流量控制解决了 两台主机之间因传送速率而可能引起的丢包问题,在一方面保证了TCP数据传送的可靠性。然而如果网络非常拥堵,此时再发送数据就会加重网络负担,那么发送的数据段很可能超过了最大生存时间也没有到达接收方,就会产生丢包问题。
为此TCP引入慢启动机制,先发出少量数据,就像探路一样,先摸清当前的网络拥堵状态后,再决定按照多大的速度传送数据

3.4、TCP / IP 协议

TCP / IP 协议全称为 传输控制协议 / 网络协议,是指能在多个不同网络间实现信息传输的协议族。

需要注意的是,TCP / IP 协议不仅仅指的是 TCP 和 IP 两个协议,而是指一个由 FTPSMTPTCPUDPIP 等协议构成的协议族,只是因为在 TCP/IP 协议中 TCP 协议和 IP 协议最具代表性,所以被称为 TCP/IP 协议

3.5、TCP 连接管理

1、TCP 连接建立过程

image-20210920174645245

  • 阶段一

客户端发送连接请求报文段无应用层数据,SYN = 1,seq = x (随机),seq 为序列号

  • 阶段二

服务器端为该 TCP 连接分配缓存(发送缓存和接收缓存)变量,并向客户端返回确认报文段,允许连接,无应用层数据, SYN = 1,ACK = 1 (确认比特),seq = y(随机),ack = x + 1 (确认号),当确认比特 ACK 为 1 时,确认号 ack 有效。

  • 阶段三

客户端为该 TCP 连接分配缓存(发送缓存和接收缓存)变量,并向服务端返回确认的确认,此时可以携带数据ACK = 1seq = x + 1ack = y + 1SYN = 0

2、TCP 连接关闭过程

参与一条 TCP 连接的两个进程中的任何一个都能终止该连接,连接结束后,主机中的资源(缓存和变量)将被回收。

四次挥手的示意图如下,我们假设是客户端想终止本次连接。

image-20210920180208007

  • 阶段一

客户端发送连接释放报文段,停止发送数据,主动关闭 TCP 连接,FIN = 1,seq = u

  • 阶段二

服务端返回一个确认报文段,此时客户端到服务器这个方向的连接就被释放了,称为半关闭状态。

ACK = 1,seq = v,ack = u + 1

  • 阶段三

服务端发送完数据,就发出连接释放报文段,主动关闭 TCP 连接,FIN = 1,ACK = 1,seq = w,ack = u + 1

  • 阶段四

客户端回送一个确认报文段,再等到时间等待计时器设置的 2MSL (最长报文段寿命)后,彻底关闭连接。ACK = 1,seq = u + 1,ack = w + 1

  • 为什么要进行等待?

这是为了避免阶段四发送的确认报文段在发送途中丢失而导致服务端收不到。如果第四个报文段丢失,那么服务器会再次发送一个连接释放报文段,然后让客户端再发送一个确认报文段,此时时间计时器重置。

3.6、SYN 洪泛攻击

SYN 洪泛攻击发生在 OSI 第四层(传输层),这种方式利用 TCP 的特性,也就是第三次握手

攻击者发送 TCP SYN,SYN 是 TCP 三次握手中的第一个数据包,当服务器返回 ACK 后,该攻击者就不对其进行再次确认,那么这个 TCP 连接就会处于挂起状态,也就是所谓的半连接状态,服务器收不到再确认的话,还会重复发送 ACK 给攻击者,这样会更加浪费服务器的资源。

攻击者会根据这个特性发送大量类似这样的 TCP 连接,由于每一个都无法完成三次握手,所以在服务器上,这些 TCP 连接会因为挂起这种状态而消耗 CPU 和内存,最后服务器可能死机,也就无法为正常用户提供服务了。

3.7、TCP 的滑动窗口

为了简单起见,我们现在假设有两台主机,由 A 发出数据, B 接受数据,此时数据的发送仅限于两个窗口,即 A 的发送窗口, B 的接收窗口, TCP 的窗口是以字节为单位的,我们假设 A 中有如下图显示的数据,每个小格子代表一个字节

image-20210924194456996

  • 此时,接收方 B 给 A 发送一个 ACK , ACK 报文段中的滑动窗口的值 rwnd 为 20 ,ack 的值为31

这表示告诉发送端,我可以接收的数据长度为 20 ,同时期望收到的数据从 31 开始

image-20210924194724661

  • 当 A 接收到 B 的确认报文后,它就可以根据这个报文段中的信息(ack = 31、rwnd = 20)构造出它的发送窗口,即从 31 开始长度为 20 的报文段,如图所示

image-20210924194942670

此时我们假设网络中不存在拥塞情况,即发送方的发送窗口为接收方的接收窗口,不考虑拥塞窗口

  • 对于尚未确认的数据,我们不能立即删除,而是要缓存起来留待超时重发使用,我们将发送窗口的左边界称为后沿,发送窗口右边界表示前沿

处于发送后沿左边的数据表示已经发送且收到确认的数据,这部分数据可以删除,而处于发送前沿右边的数据表示不允许发送的数据

image-20210924195506099

发送窗口后沿的移动情况存在两种可能

  1. 不动(此时表示没有收到新的确认)
  2. 前移(收到了新的确认)

发送窗口前沿的移动情况存在三种可能

  1. 通常是不断向前移动
  2. 不动
    1. 没有收到新的确认,对方通知的窗口大小不变
    2. 收到了新确认,但对方通知的窗口大小改变了,使得发送窗口前沿刚好不动
  3. 向后收缩(对方通知的窗口缩小了)

TCP 强烈不建议这样做

  • 发送窗口的滑动

在接收方接收到 31 32 33 数据后,此时它会给发送方返回一个 ACK ,同时将自己的接收窗口向右移动

image-20210924200840190

在发送方收到 ACK 后,它将自己的发送窗口向右移动,此时 34 - 53 落入发送窗口中,然后发送方删除已经发送且收到确认的数据

image-20210924200928757

四、UDP 协议

4.1、介绍

UDP 是 User Datagram Protocol 的简称, 中文名是用户数据报协议,是 OSI
(Open System Interconnection,开放式系统互联) 参考模型中一种无连接传输层协议,提供面向事务基于字符简单不可靠信息传送服务

4.2、特点

  • 相比于 TCP ,UDP 的传输效率更高,消耗的资源也更少
  • UDP 有不提供数据包分组、组装和不能对数据包进行排序的缺点,也就是说,当报文发送之后,是无法得知其是否安全完整到达的(不可靠,尽最大努力交付)
  • UDP 用来支持那些需要在计算机之间传输数据的网络应用。包括网络视频会议系统在内的众多的客户/服务器模式的网络应用都需要使用 UDP 协议。

4.3、UDP 与 TCP 的区别

1、概念说明

UDP 和 TCP 均位于网络模型的运输层,都是 socket 通信的两种协议

  • TCP是一种面向连接、全双工可靠、基于字节的传输层协议,TCP 只支持点对点通信,相当于在通信双方之间建立了一条可以双向通信的通道。
  • UDP 是一种无连接、不可靠、基于报文的传输层协议,UDP 支持一对多、多对一、多对多、一对一通信,UDP 只管发送,不管接收,也不会对接收到的包进行校验排序。

2、优缺点

类型安全有序速度对象个数开销方式
TCP安全有序1:1面向字节流
UDP不安全无序1:1,1:N,N:N,N:1面向报文
  • 传输速度

TCP:慢,必须等待上一个数据包传输完,下一个才能传输。

UDP:块,UDP 可以不管接收方的接收情况,连续发送数据包

  • 开销

TCP开销较大,首部有 20 个字节,而UDP 开销较小,首部只有八个字节

3、TCP UDP 比较总结

  • 是否面向连接

TCP 是面向连接的传输层协议,在进行通信前需要使用三次握手建立连接(只有第三次握手才能携带数据),在完成通信后需要使用四次挥手断开连接。

而 UDP 是无连接的。

  • 通信对象

TCP 仅支持点对点通信,而 UDP 既支持单播,也支持多播。

  • 传输的数据格式

TCP 是面向字节流的,TCP 在数据的发送和接收过程中会涉及拆分和合并,面向字节流是 TCP 实现可靠传输、流量控制和拥塞控制的基础

UDP 对应用进程交下来的报文既不拆分也不合并,它是面向应用报文的。

  • 应用场景

TCP 向上层提供面向连接的可靠服务,需要传输大量数据且对可靠性要求高的情况下使用 TCP,如:文件传输。

UDP 向上层提供无连接不可靠的服务,对实时性要求高和高速传输的场合下使用UDP,在可靠性要求低,追求效率的情况下使用UDP,如:视频会议。

  • 两个协议的首部不同

五、HTTP 协议

5.1、协议简介

HTTP 全称为超文本传输协议(HyperText Transfer Protocol),是一种用于分布式、协作式和超媒体信息系统的应用层协议。HTTP是万维网的数据通信的基础。

HTTP 是一种能够获取如 HTML 这样的网络资源的协议,是一种 Client-Server 协议

5.2、HTTP 协议概述

HTTP 协议中,客户端发起一个 HTTP 请求到服务器的指定端口(默认端口为 80),而后服务器用户需要的资源以 HTTP 响应的方式返回给客户端,我们将这个客户端称为用户代理(user agent),用户代理通常是浏览器,也可以是爬虫。

HTTP 协议中并没有规定必须使用它或它支持的层。因此,HTTP 可以在任何互联网协议上,或其他网络上实现,HTTP 假定其下层协议提供可靠的传输

因此,任何能够提供这种保证的协议都可以被其使用,所以,在 TCP/IP 协议族中,我们使用 TCP 作为传输层协议。

通常,由HTTP客户端发起一个请求,创建一个到服务器指定端口(默认是80端口)的 TCP 连接。HTTP服务器则在那个端口监听客户端的请求。一旦收到请求,服务器会向客户端返回一个状态,比如”HTTP/1.1 200 OK”,以及返回的内容,如请求的文件、错误消息、或者其它信息。

5.3、HTTP 工作原理

HTTP 协议定义 Web 客户端如何从 Web 服务器请求 Web 页面,以及服务器如何把 Web 页面传送给客户端。

HTTP 协议采用了请求/响应模型,客户端向服务器发送一个请求报文,请求报文中包含请求方法、URL 、协议版本、请求头和请求数据。

服务器以一个状态行作为响应,响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。

image-20210812150114787

在客户端和服务端中,还有许许多多被称为 proxies 的实体,它们主要有以下几种作用:

  • 缓存(可以是公开的也可以是私有的,像浏览器的缓存)
  • 过滤(像反病毒扫描,家长控制…)
  • 负载均衡(让多个服务器服务不同的请求)
  • 认证(对不同资源进行权限管理)
  • 日志记录(允许存储历史信息)

5.4、HTTP 请求 / 响应步骤

  • 客户端连接到 WEB 服务器

一个 HTTP 客户端(通常是浏览器),与 WEB 服务器的 HTTP 端口建立一个 TCP 套接字(socket)连接。

  • 发送 HTTP 请求

通过 TCP 套接字,客户端向 WEB 服务器发送一个文本的请求报文,一个请求报文由请求方法、URL 、协议版本、请求头和请求数据组成

  • 服务器接收 HTTP 请求并返回 HTTP 响应

WEB 服务器处理请求,然后响应用户,返回一个 HTTP 响应,响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据

  • 客户端接收响应并解析 HTTP 响应

5.5、HTTP 特点

  • 基于 请求 - 响应 的模式

HTTP 协议规定,请求从客户端发出,最后服务器端响应该请求并返回。换句话说,肯定是先从客户端开始建立通信的,服务器端在没有接收到请求之前不会发送响应

  • 无状态保存(服务端不保存任何客户端请求者信息)

HTTP 是一种不保存状态,即无状态(stateless)协议。HTTP 协议自身不对请求和响应之间的通信状态进行保存。也就是说在 HTTP 这个级别,协议对于发送过的请求或响应都不做持久化处理

  • 无连接

无连接的含义是限制每次连接只处理一个请求,服务器处理完客户的请求,并收到客户的应答后,即断开连接。

无连接有两种方式,早期的 HTTP 协议接收一个请求,返回一个响应后,连接直接断开;

在 HTTP 1.1 后引入了 Keep-Alive 模式,这个模式默认开启,在开启后,连接会等到 Keep-Alive 时间过期后再关闭,此时在 Keep-Alive 时间内有新的请求过来,那么就可以复用原来的连接通道。

  • 明文传输

HTTP 明文传输,数据都是未加密的,安全性较差,一些别有用心的人可以对传输的数据进行监听、篡改

5.6、HTTP 之 URL

HTTP 使用统一资源标识符(Uniform Resource Identifiers, URI)来传输数据和建立连接。URL是一种特殊类型的 URI,包含了用于查找某个资源的足够的信息

一个完整的 URL 包括以下几个部分,以 http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument 为例

  • 协议

http:// 告诉浏览器该请求使用何种协议,对于大部分资源,通常使用 HTTP 协议或者 HTTPS 协议

同时浏览器也可以处理其他请求,如 ws:// 表示 websocket 协议,ftp:协议指示浏览器处理文件传输。

image-20210813111126342

  • 主机(host)

在上面的 url 中,www.example.com 是一个域名,它指示了浏览器需要向网络上的哪一台主机发送请求,我们也可以直接向主机的 IP 地址直接发起请求。

image-20210813111311032

  • 端口(port)

两个主机发起 TCP 连接需要两个条件,即主机 + 端口。它表示用于访问 web 服务器上资源的入口。

如果访问的目标服务器使用 HTTP 协议的默认端口(80),那么就可以省略端口不写,否则端口是 URI 的必要部分

image-20210813111543024

  • 虚拟路径

/path/to/myfile.html 是 Web 服务器上资源的路径。以端口后面的第一个 / 开始,到 ? 号之前结束,中间的 每一个/ 都代表了层级(上下级)关系。这个 URL 的请求资源是一个 html 页面。

image-20210813111615295

  • 查询参数

?key1=value1&key2=value2 是提供给 Web 服务器的额外参数。如果是 GET 请求,一般带有请求 URL 参数,如果是 POST 请求,则不会在路径后面直接加参数。这些参数是用 & 符号分隔的键/值对列表。key1 = value1 是第一对,key2 = value2 是第二对参数

image-20210813111704087

  • 锚点

#SomewhereInTheDocument 是资源本身的某一部分的一个锚点。锚点代表资源内的一种“书签”,它给予浏览器显示位于该“加书签”点的内容的指示。 例如,在HTML文档上,浏览器将滚动到定义锚点的那个点上;在视频或音频文档上,浏览器将转到锚点代表的那个时间。

值得注意的是 # 号后面的部分,也称为片段标识符,永远不会与请求一起发送到服务器

六、HTTPS 协议

6.1、协议简介

HTTPS 即 Hypertext Transfer Protocol Secure,是一个专门在两点之间安全的传输文字、图片、音频、视频等超文本数据的约定和规范。

HTTPS 是 HTTP 协议的一种扩展,它本身并不保证传输的安全性,使用TLS/SSL对通信协议进行加密

image-20210813223351603

TLS / SSL 是介于 TCP 与 HTTP 之间的安全协议,不影响原有的TCP协议和HTTP协议,所以使用HTTPS基本上不需要对HTTP页面进行太多的改造。

image-20210813223436666

6.2、为什么要使用 HTTPS ?

1、HTTP 协议存在的风险

这是因为HTTP 是明文传输,所以HTTP 不安全,主要存在三大风险

  • 窃听风险

中间人可以获取到通信内容,由于内容是明文,所以获取明文后有安全风险

  • 篡改风险

中间人可以篡改报文内容后再发送给对方,风险极大

  • 冒充风险

2、HTTPS 如何解决以上问题?

  • 使用混合加密的方式实现信息的机密性,解决了窃听的风险
  • 摘要算法的方式来实现完整性,它能够为数据生成独一无二的「指纹」,指纹用于校验数据的完整性,解决了篡改的风险。
  • 将服务器公钥放入到数字证书中,解决了冒充的风险。

6.3、加密算法

加密算法大致可分为两种,分别是 对称加密非对称加密

1、对称加密

  • 对称加密中,加密和解密的密钥使用的是同一个
  • 优点

算法公开、计算量小、加密速度快、加密效率高

  • 缺点
  1. 在数据传送前,发送方和接收方必须商定好秘钥,双方都能保存好秘钥。如果一方的秘钥被泄露,那么加密信息也就不安全了

  2. 每对用户每次使用对称加密算法时,都需要使用其他人不知道的唯一秘钥,这会使得收、发双方所拥有的钥匙数量巨大,密钥管理成为双方的负担。

同时,由于 HTTP 是使用明文传输的,所以如果有人在传输密钥的过程中进行窃听,那么其他人取到密钥后,对称加密就失去了意义。

此时就算对密钥进行加密,在传输过程中仍然可能被截获,所以这种做法是不可行的

2、非对称加密

用于解决单向对称密钥的传输问题。

  • 在非对称加密中,公开密钥和私有密钥是一对,如果使用公钥进行加密,那么只有用对应的私钥才能解密
  • 反之亦然,如果使用私钥进行加密,那么只有使用对应的公钥才能解密

由于加密和解密使用的是两个不同的密钥,所以这种算法叫作非对称加密算法

  • 信息交换过程

甲方生成一对密钥并将其中的一把作为公用密钥向大家公开;乙方使用该密钥对机密信息进行加密后再发送给甲方;甲方再用私钥对加密后的信息进行解密。

  • 优点:安全
  • 缺点
  1. 速度较慢
  2. 直接传输公钥可能被中间人掉包

image-20210813222556618

3、HTTPS 的加密方式

  • HTTPS 使用混合加密的方式来保证安全
  1. 交换密钥环节使用非对称密钥加密方式,其中交换公钥利用第三方机构颁发的数字证书。
  2. 建立通信之后的交换报文阶段则使用对称密钥加密方式。
  • 为什么使用混合加密?
  1. 对称加密比非对称加密快
  2. 非对称加密比对称加密安全

所以应充分利用两者各自的优势,将多种方法组合起来用于通信。

6.4、HTTPS 连接方式

  • 客户端向服务器发送一个请求
  • 服务器发送一个 SSL 证书给客户端,内容包括
  1. 证书的发布机构
  2. 有效期
  3. 所有者
  4. 签名以及公钥
  • 客户端对发来的公钥进行真伪校验,校验结果为真则使用公钥对对称加密算法以及对称密钥进行加密
  • 服务器端使用私钥进行解密并使用对称密钥加密确认信息发送给客户端
  • 随后客户端和服务端就使用对称密钥进行信息传输

6.5、HTTP 与 HTTPS 的区别

1、安全性

  • HTTP 使用明文传输,数据都是未加密的,安全性较差
  • HTTPS (TLS / SSL + HTTP),使用混合加密来对数据进行加密,安全性较好

2、CA 证书

  • 使用 HTTPS 协议需要到数字证书认证机构申请证书

3、响应效率

  • HTTP 的响应速度比 HTTPS 快,这是因为 HTTP 使用 TCP 三次握手建立连接,客户端与服务端只需要交换三个包
  • 而 HTTPS 除了 TCP 三个包外,还需要加上 SSL 握手需要的 9 个包

4、连接方式、端口和资源消耗

  • HTTP 和 HTTPS 使用的是完全不同的连接方式,用的端口也不一样,前者是 80,后者是 443。
  • HTTPS 比 HTTP 更消耗服务器资源

6.6、GET 和 POST 请求的区别

  • GET 请求是幂等的,POST 请求不是幂等的
  • GET 请求的刷新是对浏览器无害的,而 POST 请求的刷新会被重新提交
  • GET 一般用于获取数据,POST 一般用于将数据发送到后台
  • GET 请求也可以传参数到后台,这些参数会在 URL 栏中可见,隐私性和安全性比较差,同时由于参数存放在 URL 中,所以 GET 请求提交的数据会有长度限制(这一般是浏览器或者服务器的原因,与请求方法无关)

GET 请求会被保存在浏览器的历史记录和网站的访问记录中,而 POST 不会。

  • POST 请求可以将请求参数放在 RequestBody 中,它不会展示在 URL 中

POST 请求其实也是不安全的,这是因为 HTTP 是明文传输

  • GET 请求会被浏览器主动缓存,而 POST 请求不会被缓存(除非手动设置)
  • GET 请求只能进行 URL 编码,而 POST 请求支持多种编码方式
  • GET 请求一般通过 URL 地址栏请求,而 POST 通常通过表单发送数据请求

6.7、误区说明

  • GET 请求会产生一个 TCP 数据包,而 POST 会产生两个 TCP 数据包?

网上给出的说法是:

  • GET 请求会将请求 header 和 data 一起发送出去,服务端响应 200 后,请求成功。
  • 对于 POST 请求,浏览器会先发送 http header 给服务端,告诉服务端等一下有数据传输过来,而服务端响应 100 continue,告诉浏览器服务端已经准备好接收数据,浏览器再发送请求 data 给服务端,服务端响应 200 请求成功

这种说法实际上不太严谨,POST 请求中多发的报文是客户端对 http 的 POST 和 GET 的请求策略决定的,其目的是为了避免资源带宽浪费,客户端会在发送 header 时添加 except 100 去探路,如果失败了,就不再发送 data ,从而减少资源浪费。

所以是否再发送一个包取决了客户端的实现策略,比如说 firefox 浏览器的 POST 请求只会发送一个包,与 POST 请求本身无关

七、WebSocket 协议

7.1、HTTP 协议的缺陷

在 Http 协议中,通信只能由客户端发起,在一些场景下,这种单项请求的特点,注定了如果服务器有连续的状态变化,客户端要获知就非常麻烦。

对于这个缺陷,我们可以使用 轮询 来解决,即每隔一段时间便发出一个请求,了解服务器是否有新的信息,最典型的场景就是聊天室。

  • 轮询的效率低,非常浪费资源
  • HTTP 中的轮询又分为长轮询与短轮询
  1. 短轮询指使用 AJAX 定时发送请求,接收服务端响应
  2. 长轮询指浏览器请求到服务器后,连接一直打开,直到服务端有数据可发送,在发送完数据后,关闭连接。

7.2、WebSocket 协议概述

WebSocket 是 Web 浏览器和服务器之间的一种全双工通信协议,一旦 Web 客户端与服务端建立起连接后,之后的全部数据通信都通过这个连接进行,双方可以通过这个连接自由地传递信息,并且这个连接会持续存在直到客户端或者服务端的某一方主动关闭连接。

WebSocket 本质上是一个基于 TCP 的协议,它是一个应用层协议。

7.3、WebSocket 协议与 Http 协议的区别

1、相同点

  • 都是基于 TCP 的应用层协议
  • 都是用 Request / Response 模型进行连接的建立
  • 在连接建立过程中对错误的处理方式相同,在这个阶段 WS 可能返回和 HTTP 相同的返回码
  • 都可以在网络中传输数据

2、不同之处

  • WS 使用 HTTP 来建立连接,但是定义了一系列新的header域,这些域在HTTP中并不会使用;

  • WS的连接不能通过中间人来转发,它必须是一个直接连接;

  • WS连接建立之后,通信双方都可以在任何时刻向另一方发送数据;

  • WS连接建立之后,数据的传输使用帧来传递,不再需要Request消息;

  • WS的数据帧有序。

3、通信过程

  • HTTP 的通信过程可以表示为下图,Http 的每次通信都以 Request / Response 模型进行

image-20210907202028048

  • WebSocket 的通信过程如下,除了建立连接时使用 Reqeust / Response 模型外,其余通信时间都是基于帧来传输数据

image-20210907202359560

7.4、WebSocket 的握手

WebSocket 连接的建立需要借助 Http,在进行以此 HTTP 握手后,脱离 HTTP 协议使用 WebSocket 进行通信

  • 客户端发出握手请求,然后服务器进行运算,将运算结果发送给客户端
  • 客户端接收到运算结果后,讲起与本地的数据进行比对,如果一致,那么说明此时握手成功

image-20210907201223669

在握手时,WebSocket 的握手数据会被 HTTP 服务器当成 HTTP 包来处理,这里主要使用 Update Reqeust Http 包建立起连接,之后的通信全部使用 WebSocket 协议。

  • 握手请求的 HTTP 请求报文头如下
1
2
3
4
5
6
7
GET /HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: xxx
Origin: xxx
Sec-WebSocket-Key: xxxx
Sec-WebSocket-Version: xxxxx
  1. Connection 必须设置为 Upgrade ,表示客户端希望连接升级
  2. Upgrade 必须设置为 websocket ,表示在取得服务器响应后,使用 HTTP 升级将 HTTP 协议升级为 WebSocket 协议
  3. Sec-WebSocket-Key 为一个随机字符串,用于验证协议是否为WebSocket协议而非HTTP协议,这个字符串由浏览器随机生成,用于防止恶意或者无意的连接。
  4. Sec-WebSocket-Version 表示使用WebSocket的哪一个版本。
  • 握手请求的服务器回应如下
1
2
3
4
5
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: xxxx
Sec-WebSocket-Version: xxxxx

HTTP/1.1 101 Switching Protocols 中, 101 状态码表示协议升级,在返回101状态码后,HTTP协议完成工作,转换为WebSocket协议。此时就可以进行全双工双向通信了。

  • 服务器与 Web 客户端建立连接,如果这个连接建立失败,那么不会执行后面的操作,Web 客户端会收到错误消息通知。

7.5、WebSocket 的缺点

  • 服务器长期维护长连接需要一定的成本
  • 各个浏览器支持程度不一
  • WebSocket 是长连接,受网络限制比较大,需要处理好重连

八、为什么网络需要分层?

复杂的系统需要分层,让每一层都专注做一类事情,网络分层也是为了这样,分层的具体原因如下

  • 让各层之间相互独立

分层之后,各层之间不需要关心其他层是如何实现的,只需要知道自己如何调用下层提供好的功能即可(计算机网络中,下层为上层提供服务)。

  • 提高了整体灵活性

每一层都可以使用最适合的技术来实现,你只需要保证你提供的功能以及暴露的接口的规则没有改变就行了。

  • 大事化小

分层可以将复杂的网络问题分解为许多比较小的、界线比较清晰简单的小问题来处理和解决。这样使得复杂的计算机网络系统变得易于设计,实现和标准化

同时,网络分层有助于各个部件的开发、设计及故障排除。

  • 便于扩展

计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决,计算机整个体系从上到下都是按照严格的层次结构设计的。

当我们需要实现一个新功能或者新需求时,可以通过增加中间层来解决,比如说 HTTPS 相比为 HTTP ,它中间添加了会话层的 SSL 协议来完成加密。

九、DNS

9.1、概念说明

1、域名

域名(英语:Domain Name),又称网域,是由一串用点分隔的名字组成的 Internet 上某一台计算机或计算机组的名称.

由于 IP 地址具有不方便记忆并且不能显示地址组织的名称和性质等缺点,所以人们设计了域名

2、域名服务器

  • 本地域名服务器

当一个主机发出 DNS 查询请求时,这个查询请求报文就发给本地域名服务器。

  • 权限域名服务器

管理自己域名下主机的 IP 地址

  • 顶级域名服务器

管理各自域名下的权威域名服务器,比如 com 顶级域名服务器可以返回 apple.com 域名服务器的 IP 地址

  • 根域名服务器

根域名服务器是最核心最大的域名服务器,它管理顶级域名服务器,返回 comnetcn 等顶级域名服务器的 IP 地址

image-20210920185755871

3、DNS

域名系统(英文:Domain Name System,缩写:DNS)是互联网的一项服务。它作为将域名和IP地址相互映射的一个分布式数据库,能够使人更方便地访问互联网。

4、DNS 缓存

如果全世界的域名解析都往这个系统里挤,这个系统可能被挤瘫痪了,即使不瘫痪,解析速度也会大打折扣,所以 DNS 采取了一种非常有效的手段来解决这个问题: 缓存

域名缓存有以下两种方式:

  • 非权威域名服务器(本地域名服务器)缓存:

各大运营服务商或大公司都有自己的 DNS 服务器,一般部署在距离用户较近地方,代替用户用户访问核心 DNS 系统,可以缓存之前的查询结果,如果已经有了记录,就无需再向根服务器发起查询,直接返回对应的 IP 地址

  • 本地计算机缓存
  1. 浏览器缓存

浏览器在获取某一网站域名的实际 IP 地址后,进行缓存,之后遇到同一域名查询之前的缓存结果即可,有效减少网络请求的损耗。

每种浏览器都有一个固定的 DNS 缓存时间。

  1. 操作系统缓存

操作系统里有一个特殊的“主机映射”文件,通常是一个可编辑的文本,在 Linux 里是 /etc/hosts ,在 Windows 里是 C:\WINDOWS\system32\drivers\etc\hosts ,如果操作系统在缓存里找不到 DNS 记录,就会找这个文件

image-20210920190047074

9.2、DNS 查询方式

DNS 有两种查询方式,即递归迭代

1、递归查询(委托他人)

递归查询是一种 DNS 服务器的查询模式,在该模式下 DNS 服务器接收到客户机请求,必须使用一个准确的查询结果回复客户机
如果 DNS 服务器本地没有存储查询 DNS 信息,那么该服务器会询问其他服务器,并将返回的查询结果提交给客户机。

image-20210920194144422

2、迭代查询(自力更生)

使用迭代查询时, DNS 服务器会向客户机提供其他能够解析查询请求的 DNS 服务器地址,当客户机发送查询请求时,DNS 服务器并不直接回复查询结果,而是告诉客户机另一台 DNS 服务器地址,客户机再向这台 DNS 服务器提交请求,依次循环直到返回查询的结果为止。

image-20210920194157290

9.3、DNS 使用的传输层协议

DNS 同时占用了 UDP 和 TCP 的 53 号端口,作为单个应用层协议,DNS 同时使用了两种传输层协议(UDP 和 TCP)

1、为什么基于 UDP 协议发起 DNS 查询,而不是 TCP ?

这是为了尽可能地减少 DNS 服务器响应时间(即从用户发出指令开始,到用户看到页面所花费的时间),即 响应时间 = DNS 域名解析时间 + TCP 连接建立时间 + HTTP 交易时间

由于请求中后两者的时间都不可能减少,所以我们只能希望 DNS 域名解析时间越小越好,而 UDP 是无连接的传输层协议,同时额外开销小于 TCP ,所以基于 UDP 发起查询服务可以减少响应时间。

2、什么时候使用 TCP 协议?

由于历史的原因,互联网上物理链路的最小 MTU = 576 ,基于 UDP 传输的 DNS 为了限制报文不超过 576 ,所以将 DNS 报文限制在 512 字节

这样一旦 DNS 查询应答超过 512 字节,基于 UDP 的 DNS 就只有截短为 512 字节,那么用户得到的 DNS 应答就是不完整的

所以当 DNS 查询被截断时,这个时候我们应该使用 TCP 协议进行重试,尽管这样花费的时间长,开销大,但起码可以得到一个准确的答案。

3、DNS 如何选择传输层协议?

  • 如果客户端事先知道 DNS 的响应报文的长度大于 512 字节,那么会直接使用 TCP 建立连接

  • 如果客户端实现不知道 DNS 的响应报文的长度,那么一般会先基于 UDP 协议发送 DNS 查询报文,如果返回的报文被阶段,那么客户端会基于 TCP 再次发起一次请求,从而获取准确的报文。

在域名解析的时候,一般返回的 DNS 响应报文都不会超过 512 字节,用 UDP 传输即可。事实上,很多 DNS 服务器进行配置的时候,也仅支持 UDP 查询包。

9.4、DNS 完整查询过程

  • 首先查询浏览器的 DNS 缓存,这个缓存中维护了一张域名与 IP 地址的对应表

  • 如果没有命中,则继续查询操作系统的 DNS 缓存

  • 如果依然没有命中,则操作系统将域名发送至本地域名服务器 ,本地域名服务器查询自己的 DNS 缓存,查找成功则返回结果(主机和本地域名服务器之间的查询方式是 递归查询

  • 若本地域名服务器的 DNS 缓存没有命中,则本地域名服务器向上级域名服务器进行查询,通过以下方式进行迭代查询

本地域名服务器和其他域名服务器之间的查询方式是迭代查询,防止根域名服务器压力过大

  1. 本地域名服务器向根域名服务器发起请求后,根服务器返回该域名对应的顶级域名服务器的地址,就是给它指条路让他自己去找
  2. 本地域名服务器拿到上一步根域名服务器的返回结果后,请求对应的顶级域名服务器,顶级域名服务器向本地域名服务器返回对应权限域名服务器的地址。
  3. 本地域名服务器根据权限域名服务器的地址向其发起请求,最终得到该域名对应的 IP 地址
  • 本地域名服务器 将得到的 IP 地址返回给操作系统,同时自己将 IP 地址 缓存 起来
  • 操作系统 将 IP 地址返回给浏览器,同时自己也将 IP 地址 缓存 起来
  • 浏览器 就得到了域名对应的 IP 地址,并将 IP 地址 缓存 起来

十、一次 HTTP 请求全过程

img

以 Tomcat 作为 Web 容器, Spring MVC 作为 Web 处理框架

10.1、输入地址

用户浏览器地址栏中输入地址,然后敲击回车发起请求

10.2、域名解析

具体请参考上面提到 DNS 域名解析过程,在这一步中将域名解析为 IP 地址

10.3、与服务器建立连接

此时,客户端与服务端通过三次握手建立 TCP 连接。

10.4、发起 HTTP 请求

客户端是终端用户,服务器端是网站。通过使用 web 浏览器、网络爬虫或者其它的工具,客户端发起一个到服务器上指定端口(默认端口为80)的 HTTP 协议进行,否则无法连接。

HTTP 请求报文的结构可以大致分为四个部分:请求头、空行、请求行和请求体

img

1、请求行

请求行由三部分组成

  1. 请求方法

在 HTTP/1.1 中定义的请求方法有八种,如果是 RESTful 接口的话一般会用到前四种,PUT 和 PATCH 的区别是前者常用于全量更新,而后者用于局部更新。

方法名描述
GET请求指定的页面信息,并返回实体主体。
POST向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。
PUT从客户端向服务器传送的数据取代指定的文档的内容。
DELETE请求服务器删除指定的页面。
CONNECTHTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。
OPTIONS允许客户端查看服务器的性能。
TRACE回显服务器收到的请求,主要用于测试或诊断。
PATCH是对 PUT 方法的补充,用来对已知资源进行局部更新
  1. 请求地址

URL:统一资源定位符,用来唯一表示互联网中一个资源的具体位置,是一种特殊的 URI

组成:<协议>://<主机>:<端口>/<路径>(端口和路径有事可以忽略)

  1. 协议版本

包含协议名称及版本号,格式为 HTTP / 主版本号.副版本号 ,如上图中的 HTTP / 1.1

2、请求头

请求头部为请求报文添加了一些附加信息,每行一对,格式为 属性名:属性值,常见属性如下

请求头说明
Host接受请求的服务器地址,可以是 IP:端口号,也可以是域名
User-Agent用户代理,发送请求的应用程序名称(一种向访问网站提供你所使用的浏览器类型及版本、操作系统及版本、浏览器内核、等信息的标识),可以进行伪装。
Connection指定与连接相关的属性,如 Connection:Keep-Alive
Accept-Charset通知服务端可以发送的编码格式
Accept-Encoding通知服务端可以发送的数据压缩格式
Accept-Language通知服务端可以发送的语言
Accept用于指定客户端可接受哪些类型的信息,比如说 text/plain
Cache-Control对缓存进行控制,如一个请求希望响应返回的内容在客户端要被缓存一年,或不希望被缓存就可以通过这个报文头达到目的。

请求头部的最后会有一个空行,表示请求头部结束,接下来为请求数据,这一行非常重要,必不可少

3、请求体

可选部分,如果请求方法为 GET ,则此项为空,没有数据;

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

10.5、Web 服务器接收 HTTP 请求并返回结果

  • 客户端浏览器将发出的请求被封装成为一个 HttpServletRequest 对象转交请求给 Web 服务器

  • Web服务器收到请求转交请求给 Tomcat

  • Tomcat 调用 Servlet 处理请求

  • Servlet 处理请求并返回处理结果

这一步就是 Spring MVC 的工作流程

  • Tomcat 接收到 Servlet 返回的结果,然后将页面返回给 Web 服务器
  • 客户端浏览器解析响应 HttpServletResponse 对象,然后将结果呈现给用户