您好,欢迎访问代理记账网站
移动应用 微信公众号 联系我们

咨询热线 -

电话 15988168888

联系客服
  • 价格透明
  • 信息保密
  • 进度掌控
  • 售后无忧

计算机网络总结

一、计算机网络基础

1.1 应用层

应用层位于网络模型的最上层,也是我们能直接接触到的应用层,为特定的进程提供服务,我们的日常手机或者电脑使用的软件需要通信时就是基于应用层实现的数据传输,应用层把数据交给下一层传输层

所以说,应用层的核心功能就是专注于为用户提供数据传输服务,至于如何传输,那是传输层应该做的事情,应用层不关心。而且应用层是工作在操作系统的用户态,传输层及以下则是工作在操作系统的内核态。

应用层常见的协议有HTTP、HTTPS、SSL,数据单位为报文。

在这里插入图片描述

1.2 传输层

传输层为应用层提供网络支持,接收应用层传输下来的报文数据,为线程提供服务

传输层常用的两个协议:TCP(传输控制协议)、UDP

TCP:大部分应用运用的是TCP协议,因为TCP是一个可靠的协议,有流量控制、超时重传、拥塞控制等,这些都是能够保证数据包能可靠地发给对方,数据太大时会拆包发送,数据单位是报文段

UDP:实现相对简单,是一个尽最大努力交付的协议,消耗低、性能好、传输效率高,但是不可靠,数据单位是数据用户报

TCP和UDP通常以IP地址+端口号来区分数据是否是自己的。

在这里插入图片描述

1.3 网络层

网络层是模型中的第三层,路由器在此层,负责是主机之间数据传输服务,网络层接收传输层传递下来的报文段或者用户数据包,并转化为分组,交给下一层数据链路层

常见的协议有ARP地址解析协议:实现由IP地址转化为MAC地址

网络地址转换 NAT:专用网内部的主机使用本地 IP 地址又想和互联网上的主机通信时,可以使用 NAT 来将本地 IP 转换为全球 IP

在这里插入图片描述

1.4 数据链路层

数据链路层是模型的第四层,负责的是主机之间的某一条具体的链路,数据链路层接收网络层传递下来的分组,并把分组封装成帧,传递给物理层

目前数据链路层广泛使用了循环冗余检验(CRC)来检查比特差错

常见的协议:CSMA/CD 协议

CSMA/CD 表示载波监听多点接入 / 碰撞检测

  • 多点接入 :说明这是总线型网络,许多主机以多点的方式连接到总线上
  • 载波监听 :每个主机都必须不停地监听信道。在发送前,如果监听到信道正在使用,就必须等待
  • 碰撞检测 :在发送中,如果监听到信道已有其它主机正在发送数据,就表示发生了碰撞。虽然每个主机在发送数据之前都已经监听到信道为空闲,但是由于电磁波的传播时延的存在,还是有可能会发生碰撞

在这里插入图片描述

1.5 物理层

物理层是模型的最底层,负责的是如何在具体传输媒体中传输数据,物理层的作用是尽可能屏蔽传输媒体的差异,使数据链路层感受不到这些差异,为数据链路层提供二进制传输服务

物理层接收数据链路层传递下来的帧,把帧转化为比特,以比特流的形式传输

根据信息在传输线上的传送方向,分为以下三种通信方式:

  • 单工通信:单向传输
  • 半双工通信:双向交替传输
  • 全双工通信:双向同时传输

在这里插入图片描述

二、HTTP

2.1 HTTP是什么?

HTTP全称超文本传输协议,它是一个用在计算机世界里的协议,规范了计算机之间的交流通信规范和约定。

常见的HTTP状态码:

状态码含义常见的码
1XX提示信息,是一个中间状态的信息,表示还有后续处理
2XX成功,报文已经收到并且被正确处理200
3XX重定向,资源位置发生移动,需要客户端重新发送新的请求301(永久重定向),302(临时移动),304
4XX客户端错误,请求报文有错,服务器无法处理400,403,404
5XX服务器错误,服务器在内部发生错误,无法正确处理报文500,501,502,503

常见的HTTP字段:

字段名含义代表
Host客户端发送请求时,用来指定服务器的域名Host: www.jysx.xzy
Content-Length服务器返回数据时,会有Content-Length,表明本次回应数据的长度Content-Length: 1000
Connection表明本次TCP连接是长连接还是短连接,HTTP/1.1 默认长连接Connection: keep-alive
Content-Type服务器返回信息,告诉客户端,本次数据是什么格式Content-Type: text/html; charset=utf-8
Accept客户端声明自己可以接受什么类型的数据Accept: * / *

2.2 GET 和 POST

GET 方法是请求从服务器获取资源,这个资源可以是静态的文本,页面,图片等,GET方法是安全的,因为它没有改变服务器的任何数据

POST 方法是向服务器提交数据,数据可以是文本,图片等,POST方法不是安全的,因为它改变服务器的状态或者数据

2.3 HTTP的特性

无状态:无状态是服务器不会去记录HTTP的状态,不需要额外的内存去记录客户端的状态,节省内存,但是对于同一个客户端短时间内多次请求的情况可能会造成每次请求都询问客户端的身份信息,解决方法:用cookie技术代替客户端的身份信息,客户端第一次请求,服务器会生成一个唯一的cookie,以后客户端每次请求都带上cookie,服务器就知道是谁访问了

无连接:无连接是指服务器在处理完一个TCP请求之后就断开连接,无连接可以减少服务器消耗,避免过多TCP连接占用内存,但是对于同一个客户端短时间大量请求资源的连接,比如打开一个网站后,该网站有大量图片,每一张都需要发送一次请求,这样服务器频繁建立TCP连接和断开TCP连接会造成非常大的资源消耗,如果在同一个TCP连接中处理完所有请求,这能够极大减少服务器消耗,从HTTP/1.1开始,HTTP连接默认是长连接,也可以在HTTP/1.0中指定长连接:Connection: keep-alive

2.4 HTTP 和 HTTPS

区别:

HTTP 是超文本传输协议,信息是明文传输,存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷,在 TCP 和 HTTP 传输层之间之间加入入 SSL/TLS 安全协议,使得报文能够加密传输。

HTTP 连接建立相对简单,TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后,还需要进行 SSL/TLS 的握手过程,才可进入加密报文传输。

HTTP 的端口号是 80,HTTPS 的端口号是 443 。

HTTPS 协议需要向 CA (证书权威机构)申请数字证书,来保证服务器的身份是可信的。

HTTPS 解决了 HTTP 哪些问题?

窃听风险:比如通信链路上可以获取通信内容;

篡改风险:比如强制植入垃圾广告,视觉污染;

冒充风险:比如冒充淘宝网站;

HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议,可以很好的解决了上述风险:

信息加密:交互信息无法被窃取;

校验机制:无法篡改通信内容,篡改了就不能正常显示;

身份证书:证明网站的真实性;

那么 HTTPS 是如何解决上述问题呢?

混合加密:实现信息的机密性,解决了窃听的风险;

摘要算法:实现完整性,能够为数据生成独一无二的“指纹”,保证了数据的完整性;

数字证书:把服务器加入数字证书中,解决了冒充风险;

1. 混合加密

HTTPS 采用的是对称加密非对称加密结合的混合加密方式:

在通信建立前采用非对称加密的方式交换“会话密钥”,后续不再使用非对称加密,直接使用该“会话密钥”进行加密解密通信。

在通信过程中全部使用的是对称加密的“会话密钥”的方式加密明文数据和解密明文数据。

为什么使用混合加密的方式?
对称加密只使用一个密钥,运算速度快,但是密钥必须保密,需要用非对称加密对 “会话密钥” 进行加密传输。

2. 摘要算法

摘要算法用来实现完整性,能够为数据生成独一无二的“指纹”,用于校验数据的完整性,解决了篡改的风险。

客户端在发送明文之前会通过摘要算法算出明文的 “指纹” ,发送的时候把 “指纹 + 明文” 一同加密成密文后,发给服务器,服务器解密后,用相同的摘要算法算出发送过来的明文,通过比较客户端携带的 “指纹” 和当前算出的 “指纹” 做比较,若相同,则说明数据完整的,没有被篡改。

3. 数字证书

客户端先向服务器索要公钥,然后用公钥加密信息,服务器收到密文后,用自己的私钥解密。

这就存在问题了,如何保证公钥不被篡改和信任度?

所以这里就需要借助第三方权威机构 CA (数字证书认证机构),将服务器公钥放在数字证书(由数字证书认证机构颁发)中,只要证书是可信的,公钥就是可信的,通过数字证书的方式保证了服务器公钥的身份,解决了冒充的风险。

4. SSL/TLS 协议简历的详细流程

  1. 客户端向服务器发送获取 CA 证书请求

首先,由客户端向服务器发起加密通信请求:

  • 客户端支持的 SSL/TLS 协议版本;
  • 客户端生成的随机数,后面用于生成 “会话密钥”;
  • 客户端支持的密码套件列表 ,如 RSA 加密算法;
  1. 服务器收到客户端请求,向客户端发出响应
  • 确认 SSL/TLS 协议版本,如果浏览器不支持,则关闭加密通信;
  • 服务器生成的随机数,后面用于生成 “会话密钥”;
  • 确认的密码套件列表,如 RSA 加密算法;
  • 服务器的数字证书;
  1. 客户端回应
  • 一个随机数(由客户端根据自己生成的随机数和服务器端生成的随机数产生的),改随机数会被客户端用公钥加密;
  • 加密通信算法改变通知,表示随后的信息都将会用 “会话密钥” 加密通信;
  • 客户端握手结束通知,表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要,用来供服务端校验;
  1. 服务器的最后回应
  • 加密通信算法改变通知,表示随后的信息都将用 “会话密钥” 加密通信;
  • 服务器握手结束通知,表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要,用来供客户端校验;

5. HTTP 1.0/1.1/2.0 改进了什么

HTTP/1.1 使用 TCP 长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。
支持管道网络传输,只要第一个请求发出去了,不必等其回来,就可以发第二个请求出去,可以减少整体的响应时间。

HTTP/2.0协议改进:

  1. HTTP/2.0 会压缩头部,如果同时发出多个请求,他们的头是一样的或者相似的,那么,协议会帮你消除重复部分。

  2. HTTP/2.2 不再像 HTTP/1.1 里的纯文本形式的报文了,而是采用了二进制格式,头信息和数据体都是二进制,并且统称为帧。

在这里插入图片描述

  1. HTTP/2.0 的数据包不是按顺序发送的,同一个连接里面连续的数据包,可能属于不同的回应,因此,必须对数据包做标记,指出它属于哪个回应。

  2. 多路复用,HTTP/2.0 是可以在一个连接中并发多个请求或回应,而不用按照顺序一一对应。

  3. 服务器推送,HTTP/2.0 还在一定程度上改善了传统的 请求 - 应答 工作模式,服务不再是被动地响应,也可以主动向客户端发送消息。比如,在请求 HTML 的时候,可能提前把用到的 JS/CSS 等文件主动发给客户端。

6. HTTP/1.1 和 HTTP/2.0 的主要问题

  1. HTTP/1.1 中的管道传输中如果有一个请求阻塞了,那么队列后请求也统统被阻塞了。
  2. HTTP/2.0 中,多个 HTTP 请求在复用一个 TCP 连接,下层的 TCP 协议是不知道有多少个 HTTP 请求的,所以一旦发生了丢包现象,就会触发 TCP 的重传机制,这样在一个 TCP 连接中的所有 HTTP 请求都必须等待这个丢了的包被重传回来。

HTTP/3.0 把下层的 TCP 协议改为了 UDP 协议,不会发生 HTTP/1.1 的队头阻塞情况 和 HTTP/2.0 的丢包重传问题。

7. HTTP/1.1 优化方法

  1. 避免发送 HTTP 请求,采用 缓存技术,把数据缓存在本地;
  2. 减少发送 HTTP 请求,服务器把 js、css 等资源合并成一个大文件,发送一次;
  3. 减少 HTTP 响应的数据大小,采用压缩技术;

三、TCP

3.1 TCP 三次握手 与 四次挥手

TCP 的建立,离不开三次握手,断开离不开四次挥手

3.1.1 什么是 TCP?

TCP 是工作在传输层的面向连接的、可靠的、基于字节流的协议。

面向连接:TCP 是一对一模式,一个 TCP 对应 一个连接。

可靠的:无论网络发生了什么变化, TCP 都会保证数据发送到对方并确保对方接收成功。

字节流:消息是“没有边界”的,所以有多大的消息都可以传输,并且消息是有序的。

通过 TCP 的四个部分可以唯一确定一个 TCP 连接:源地址、源端口、目的地址、目的端口

3.1.2 TCP 连接建立

建立前

一开始,客户端和服务端都处于 CLOSED 状态。先是服务端主动监听某个端口,处于 LISTEN 状态

第一个报文

客户端会随机初始化序号,将此序号置于 TCP 首部的 “序号” 字段中,同时把 SYN 标志位置为 1 ,表示 SYN 报文。接着把第一个 SYN 报文发送给服务端,表示向服务端发起连接,该报文不包含应用层数据,之后客户端处于 SYN-SENT 状态

第二个报文

服务端收到客户端的 SYN 报文 后,首先服务端也随机初始化自己的序号,将此序号天日 TCP 首部的 “序号” 字段中,其次把 TCP 首部的 “确认应答号” 字段填入 客户端序号 + 1 ,接着把 SYN 和 ACK 标志位置为 1 。最后把该报文发给客户端,该报文也不包含应用层数据,之后服务端处于 SYN RCVD状态

第三个报文

客户端收到服务端的报文后,还要向服务端回应最后一个应答报文,首先该应答报文 TCP 首部 ACK 标志位置为 1 ,其次 “确认应答号” 字段填入 服务端序号 + 1,最后把报文发送给服务端,这次报文可以携带客户到服务器的数据,之后客户端处于 ESTABLISHED 状态

服务端收到客户端的应答报文后,也进入 ESTABLISHED 状态

建立完成

一旦完成三次握手,双方都处于 ESTABLISHED 状态,此时连接就已经建立完成,客户端和服务端就可以相互发送数据了。

3.1.3 为什么是三次握手?

为什么 TCP 连接 是三次握手,而不是两次或者四次?

  1. 确保 客户端服务端 双方都具备 发送接收 的能力;
  2. 避免历史连接:通过 序号 与 确认序号 避免历史旧连接;
  3. 避免资源浪费:如果只有 “两次握手”,当客户端的 SYN 请求连接在网络中阻塞,客户端没有接收到 ACK 报文,就会重发 SYN ,由于没有第三次握手,服务器不清楚客户端是否收到了自己发送的建立连接的 ACK 确认信好,所以每收到一个 SYN 就只能先主动建立一个连接。
  4. 四次握手,资源浪费,三次握手已经可以建立可靠连接,不需要更多的通信次数。

3.1.4 连接断开

双方都可以主动断开连接

一旦断开连接后,双方连接占用的资源都会被释放

第一个报文

客户端打算关闭连接,此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文,也即 FIN 报文,之后客户端进入 FIN_WAIT_1 状态

第二个报文

服务端收到该报文后,就向客户端发送 ACK 应答报文,接着服务端进入 CLOSED_WAIT 状态

客户端收到服务端的 ACK 应答报文后,进入 FIN_WAIT_2 状态

第三个报文

服务端向客户端发送 FIN 报文,之后服务端进入 LAST_ACK 状态

第四个报文

客户端收到服务端的 FIN 报文后,回一个 ACK 应答报文,之后进入 TIME_WAIT 状态

服务端收到 ACK 应答报文后,就进入了 CLOSED 状态,至此服务端已经完成连接关闭

等待 2MSL 时间,客户端才进入 CLOSED 状态

3.1.5 为什么需要挥手四次 和 等待 2MSL

挥手四次原因

服务端通常需要等待完成数据的发送和处理,所以服务端的 ACK 和 FIN 一般都会分开发送,从而 比三次握手导致多了一次。

等待 2 MSL 原因

MSL 是 报文最大生存时间,它是任何报文在网络上存在的最长时间,超过这个时间报文将被丢弃。

TIME_WAIT 等待 2 倍的 MSL ,比较合理的解释是:网络中可能存在来自发送方的数据包,当这些发送数据包被接受方处理后又会向对方发送响应,所以一来一回需要等待 2 倍的时间。

同时也保证网络上没有该连接的数据包,防止被新连接接收

3.2 TCP 是如何保证可靠传输?

TCP 是一个可靠传输的协议,那么它是如何保证可靠的?

TCP 通过序列号、确认应答、重传机制、重传机制、重发控制、窗口控制机制等实现可靠传输的。

3.2.1 重传机制

TCP 实现可靠传输的方式之一是通过序列号与确认应答。

在 TCP 中,当发送端的数据到达接受主机时,接收端主机会返回一个确认应答消息,表示已收到消息。

所以,当发生 TCP 数据包丢失的情况时,会用 重传机制 解决:常见的重传机制:

  1. 超时重传
  2. 快速重传
  3. SACK
  4. D - SACK

超时重传

超时重传 是 重传机制 的其中一个方式,就是在发送数据时,设定一个定时器,当超过指定的时间后,没有收到对方的 ACK 确认应答报文,就会重新发送该数据。

TCP 会在两种情况发生超时重传:数据包丢失 和 确认应答丢失

在这里插入图片描述

那么超时时间应该设置为多少呢?

首先来了解一下什么是 RTT 往返时延:包的往返时间,即传输到另一端再回来的时间。

超时重传时间是 RTO 表示,RTO 应该略大于 RTT 为宜。

每当遇到一次超时重传的时候,都会将下一次超时时间的间隔设为先前值的两倍。如果有两次超时,就说明网络环境差,不宜频繁反复发送。

超时触发重传存在的问题是:超时周期可能相对较长,那是不是可以有更快的方式呢?有 快速重传 诞生了。

快速重传

快速重传不以时间为驱动,而是以为数据驱动重传。

在这里插入图片描述

快速重传 的工作方式:

当收到三个相同的 ACK 报文时,会在定时器过期之前,重传丢失的报文段。但是它依然面临着另外一个问题,就是重传的时候,是重传之前的一个,还是重传数据包及之后的所有呢?

SACK 方法

选择性确认,在 TCP 头部“选项”字段里加一个 SACK 的东西,它可以将缓存的地图发送给发送方,这样发送发就可以知道哪些数据收到了,哪些数据没收到,知道了这些信息,就可以只重传丢失的数据。

3.2.2 滑动窗口

为每个数据包确认应答的缺点:包的往返时间越长,网络的吞吐量会越低。

为了解决这个问题, TCP 引入了窗口这个概念,即使在往返时间较长的情况下,它也不会降低网络通信的效率。

有了窗口,就可以指定窗口的大小,窗口大小就是指无需等待确认应答,而可以继续发送数据的最大值。

窗口的实现实际上是操作系统开辟的一个缓存空间,发送方主机在等到确认应答返回之前,必须在缓存区中保留已保留已发送的数据。如果按期收到确认应答,此时数据就可以从缓存区清除。

TCP 的窗口大小由哪一方决定呢?

TCP 头里有一个字段叫 Window ,也就是窗口大小。

这个字段是接收端告诉发送端自己还有多少缓冲区可以接受数据。于是发送端就可以根据这个接收端的处理能力来发送数据,而不会导致接收端处理不过来。

但是,实际上,窗口的大小是由发送方和接受方共同控制的。

3.2.3 流量控制

发送方不能无脑的发数据给接收方,要考虑接收方处理能力。

如果一直无脑的发数据给对方,但对方处理不过来,那么就会导致触发重传机制,从而导致网络流量的资源浪费。

为了解决这个问题,TCP 提供了一种机制可以让 发送方 根据 接收方 的实际接收能力控制发送的数据量,这就是所谓的流量控制。

接收方会在确认报文中设置自己当前的可接收窗口的大小,如果该大小为 0 ,则是窗口关闭。

发送方会根据确认报文中的窗口大小再结合拥塞控制的窗口大小,选取最小值作为发送窗口的大小。

窗口关闭可能带来危险

接收方 告诉 发送方 自己窗口的大小是通过 ACK 报文,那么当窗口关闭时,接收方处理完数据后,会向发送方通告一个窗口非 0 的 ACK 报文,如果这个 ACK 报文在网络中丢失了,那么发送方的窗口可能一直无法开启,双方都在等待对方的数据(可通过窗口探测报文解决)。

3.2.4 拥塞控制

流浪控制 主要是控制接收方来得及接收数据,而 拥塞控制 是控制整个网络的拥塞度。

前面的 流量控制 是避免 发送发 的数据填满 接收方 的缓存,但是不知道网络中发生了什么。

在网络出现拥堵时,如果继续发送大量数据包,可能会导致数据包时延、丢失等,这时 TCP 就会重传数据,但是一重传就会导致网络的负担更重,于是会导致更大的延迟以及更多的丢包,这个情况就会进入恶性循环被不断地放大。。。

于是,就有了 拥塞控制,控制目的就是避免 发送方的数据填满整个网络。

为了在 发送方 调节所要发送数据的量,定义了一个叫做 拥塞窗口 的概念。

那么,拥塞窗口 的大小是靠什么机制控制的?

拥塞窗口 的大小靠拥塞控制:主要有四个算法

  1. 慢启动
  2. 拥塞避免
  3. 拥塞发生
  4. 快速恢复

慢启动

TCP 在刚建立连接完成后,首先是有个慢启动的过程,这个慢启动的意思就是一点一点的提高发送数据包的数量,如果一上来就发大量的数据,这不是给网络添堵吗?

慢启动算法记住一个规则就行:当发送方每收到一个 ACK ,拥塞窗口 cwnd 的大小就会 * 2 。

在这里插入图片描述

可以看出慢启动算法,发包的个数是指数型的增长。

那么慢启动涨到什么时候是个头呢?

有一个叫慢启动门限 ssthresh 状态变量:当 拥塞窗口 大小大于或等于门限时,启动拥塞避免算法

拥塞避免

当 拥塞窗口 cwnd 大小 大于或者等于 设定门限之后,会进入拥塞避免算法,它的规则是:每收到一个 ACK 时,cwnd 只会 + 1 。

在这里插入图片描述

所以,我们可以发现,拥塞避免算法就是将原本慢启动算法的指数增长变成了线性增长,还是增长阶段,但是增长速度缓慢了一些。

就这么一直增长后,网络就会慢慢进入了拥塞的状况了,于是就会出现丢包现象,这时就需要对丢失的数据包进行重传。

当发生重传机制时,会进入拥塞发生算法。

拥塞发生

当网络出现拥塞,也就是会发送数据包重传,重传机制主要有两种:

  1. 超时重传(时间)
  2. 快速重传(数据包)

这两种使用的拥塞发生算法是不用的,下面分别说说这两种情况:

  • 发生超时重传的拥塞发生算法时,ssthresh 门限会设定为 cwnd / 2,cwnd 设置为 1 ,并重新启动慢开始

  • 发生快速重传的拥塞发生算法时,cwnd = ssthresh = cwnd / 2,当前直接进入拥塞避免,并且进入快速恢复算法

快速恢复

快速重传 和 快速恢复 一般同时使用,快速恢复算法是认为,你还能收到 3 个重复的 ACK 包说明网络也没有那么糟糕,所以没有必要实施慢开始。

进入快速恢复算法:重传丢失的包;


分享:

低价透明

统一报价,无隐形消费

金牌服务

一对一专属顾问7*24小时金牌服务

信息保密

个人信息安全有保障

售后无忧

服务出问题客服经理全程跟进