开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> 网络协议 -> 后端学习 - 计算机网络 -> 正文阅读

[网络协议]后端学习 - 计算机网络

一基本概念

1 计算机网络体系结构

数据在各层之间的传递过程：在向下的过程中，需要添加下层协议所需要的首部或者尾部，而在向上的过程中不断拆开首部和尾部
在这里插入图片描述

五层协议

名称	作用
应用层	为特定应用程序提供数据传输服务，例如 HTTP、DNS 等协议，数据单位为报文
传输层	为进程提供通用数据传输服务，包括两种协议：传输控制协议 TCP，提供面向连接、可靠的数据传输服务，数据单位为报文段（主要提供完整性服务）；用户数据报协议 UDP，提供无连接、尽最大努力的数据传输服务，数据单位为用户数据报（主要提供及时性服务）
网络层	为主机提供数据传输服务，把传输层传递下来的报文段或者用户数据报封装成分组
数据链路层	为同一链路的主机提供数据传输服务，把网络层传下来的分组封装成帧
物理层	在传输媒体上传输数据比特流

2.OSI七层协议

应用层、表示层、会话层、传输层、网络层、数据链路层、物理层
表示层：数据压缩、加密以及数据描述，这使得应用程序不必关心在各台主机中数据内部格式不同的问题
会话层：建立及管理会话
五层协议没有表示层和会话层，而是将这些功能留给应用程序开发者处理

3.TCP/IP 协议

应用层、传输层、网际层、网络接口层
相当于五层协议中数据链路层和物理层合并为网络接口层
不严格遵循 OSI 分层概念，应用层可能会直接使用 IP 层或者网络接口层

2 时延

总时延 = 排队时延 + 处理时延 + 传输时延 + 传播时延

排队时延：分组在路由器的输入队列和输出队列中排队等待的时间，取决于网络当前的通信量
处理时延：主机或路由器收到分组时进行处理所需要的时间，例如分析首部、从分组中提取数据、进行差错检验或查找适当的路由等
传输时延：主机或路由器传输数据帧所需要的时间
传播时延：电磁波在信道中传播所需要花费的时间，电磁波传播的速度接近光速

二应用层：HTTP

1 请求和响应报文

客户端发送一个请求报文给服务器，服务器根据请求报文中的信息进行处理，并将处理结果放入响应报文中返回给客户端
请求报文
第一行是包含了请求方法、URL、协议版本；
接下来的多行都是请求首部 Header，每个首部都有一个首部名称，以及对应的值；
一个空行用来分隔首部和内容主体 Body
最后是请求的内容主体

GET http://www.example.com/ HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Cache-Control: max-age=0
Host: www.example.com
If-Modified-Since: Thu, 17 Oct 2019 07:18:26 GMT
If-None-Match: "3147526947+gzip"
Proxy-Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 xxx

param1=1&param2=2

响应报文
第一行包含协议版本、状态码以及描述
接下来多行也是首部内容
一个空行分隔首部和内容主体
最后是响应的内容主体

HTTP/1.1 200 OK
Age: 529651
Cache-Control: max-age=604800
Connection: keep-alive
Content-Encoding: gzip
Content-Length: 648
Content-Type: text/html; charset=UTF-8
Date: Mon, 02 Nov 2020 17:53:39 GMT
Etag: "3147526947+ident+gzip"
Expires: Mon, 09 Nov 2020 17:53:39 GMT
Keep-Alive: timeout=4
Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT
Proxy-Connection: keep-alive
Server: ECS (sjc/16DF)
Vary: Accept-Encoding
X-Cache: HIT

<!doctype html>
<html>
<head>
    <title>Example Domain</title>
	// 省略... 
</body>
</html>

2 URL

URI（Uniform Resource Identifier，统一资源标识符）是抽象的标识资源的方式，它的具体实现包括 URL（ Uniform Resource Locator，统一资源定位符）和 URN （Uniform Resource Name，统一资源名称）
以上并不代表 URI = URL + URN，而是代表 URL 是 URI，URN 也是 URI
HTTP 使用 URL 来定位资源

3 HTTP 协议通信过程

HTTP 是应用层协议，它以 TCP（传输层）作为底层协议，默认端口为 80

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

4 HTTP 方法

安全的 HTTP 方法不会改变服务器的状态。从这个角度出发，GET、HEAD、OPTIONS 是安全的，而 POST、DELETE‘PUT 是不安全的
幂等的 HTTP 方法，同样的请求被执行一次与连续执行多次的效果是一样的（幂等方法不应该具有副作用）。从这个角度出发，GET，HEAD，PUT 和 DELETE 等方法都是幂等的，而 POST 方法不是

GET
获取资源
HEAD
获取报文首部，和 GET 方法类似，但是不返回报文实体主体部分
主要用于确认 URL 的有效性以及资源更新的日期时间等
POST
传输实体主体
PUT
上传文件
没有验证机制，存在安全性问题，一般不使用
PATCH
对资源进行部分修改
PUT 也可以用于修改资源，但是只能完全替代原始资源，PATCH 允许部分修改
DELETE
与 PUT 功能相反，并且同样不带验证机制
OPTIONS
查询指定的 URL 能够支持的 HTTP 方法
CONNECT
要求在与代理服务器通信时建立隧道
使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输
TRACE
追踪路径，服务器会将通信路径返回给客户端
发送请求时，在 Max-Forwards 首部字段中填入数值，每经过一个服务器就会减 1，当数值为 0 时就停止传输

5 HTTP 状态码

服务器返回的 响应报文 中第一行为状态行，包含了状态码以及原因短语，用来告知客户端请求的结果

6 短连接、长连接与流水线

短连接每进行一次 HTTP 通信就要新建一个 TCP 连接，长连接只需要建立一次 TCP 连接就能进行多次 HTTP 通信
在 HTTP/1.1 之前默认短连接，HTTP/1.1 及之后开始默认长连接
默认情况下，HTTP 请求是按顺序发出的，下一个请求只有在当前请求收到响应之后才会被发出。流水线是在 同一条长连接上连续发出请求，而不用等待响应返回，这样可以减少延迟

7 Cookie

在这里插入图片描述

HTTP 是无状态的协议，HTTP/1.1 引入 Cookie 来保存状态信息
Cookie 由服务器发送到用户浏览器，并存放在客户端，在浏览器之后向同一服务器再次发起请求时被携带上，用于告知服务端两个请求是否来自同一浏览器
创建过程：

# 服务器发送的响应报文包含 Set-Cookie 首部字段
# 客户端得到响应报文后把 Cookie 内容保存到浏览器中
HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

[page content]

# 客户端之后对同一个服务器发送请求时会从浏览器中取出 Cookie 信息
# 通过 Cookie 请求首部字段发送给服务器
GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

8 Session

除了可以将用户信息通过 Cookie 存储在用户浏览器中，也可以利用 Session 存储在服务器端，存储在服务器端的信息更加安全

用户进行登录时，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中；
服务器验证该用户名和密码，如果正确则把用户信息存储到 Redis 中，它在 Redis 中的 Key 称为 Session ID；
服务器返回的响应报文的 Set-Cookie 首部字段包含了这个 Session ID，客户端收到响应报文之后将该 Cookie 值存入浏览器中；
客户端之后对同一个服务器进行请求时会包含该 Cookie 值，服务器收到之后提取出 Session ID，从 Redis 中取出用户信息，继续之前的业务操作

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

9 缓存

使用缓存可以缓解服务器压力，并能降低客户端获取资源的延迟
可以利用 代理服务器，或客户端浏览器 进行缓存

三应用层：HTTPS

默认端口号是 443
让 HTTP 先和 SSL（Secure Sockets Layer）通信，再由 SSL 和 TCP 通信，也就是说 HTTPS 使用了隧道进行通信
通过使用 SSL，HTTPS 具有了加密（防窃听）、认证（防伪装）和完整性保护（防篡改）

1 加密方式

对称密钥：加密和解密使用同一密钥
非对称密钥：公开密钥所有人都可以获得，通信发送方获得 接收方的公开密钥 之后，就可以使用公开密钥进行加密，接收方收到通信内容后使用私有密钥解密
HTTPS 采用混合加密机制：
使用 非对称密钥 加密方式，传输 对称密钥 加密方式所需要的 Secret Key，从而保证安全性；
获取到 Secret Key 后，再使用 对称密钥加密方式进行通信 ，从而保证效率

2 证书认证

根本目的是传递服务器的公钥

数字证书认证机构（CA，Certificate Authority）是客户端与服务器双方都可信赖的第三方机构
CA 知道服务器的公钥，向服务器颁发证书，并附上 CA 私钥对消息摘要的加密签名
服务器获得 CA 办法的证书，并将证书传递给客户端
客户端获得证书，并且客户端知道 CA 公钥，使用 CA 公钥对证书上的签名解密，同时对消息进行散列处理得到摘要
比较摘要，验证证书的真实性。如果客户端验证服务器的证书是真实的，则信任服务器的公钥

四应用层：其它协议

1 DNS

DNS 是一个分布式数据库，提供了主机名和 IP 地址之间 相互转换 的服务
域名具有层次结构，从上到下依次为：根域名、顶级域名、二级（权威）域名
DNS 可以使用 UDP 或者 TCP 进行传输，使用的端口号都为 53
一般使用 UDP 进行传输，除非返回的响应超过的 512 字节（UDP 最大只支持 512 字节的数据）
查询可以通过两种方式：递归查询和迭代查询

2 FTP

使用两个 TCP 连接进行文件传输，分别是数据连接和控制连接
- 数据连接：用来传送文件数据
- 控制连接：服务器打开端口号 21 等待客户端的连接，客户端主动建立连接后，使用这个连接将客户端的命令传送给服务器，并传回服务器的应答
根据 数据连接 （而非控制连接，因为控制连接一定是客户端主动建立的）是否是服务器端主动建立，FTP 有主动和被动两种模式
- 主动连接：服务器端主动建立数据连接，服务器端口号为20，客户端端口号随机
- 被动模式：客户端主动建立数据连接，客户端端口号由客户端自己指定，服务器端口号随机

3 SMTP、POP3、IMAP

在这里插入图片描述

SMTP 是发送协议，POP3 和 IMAP 是读取协议
因为需要保证邮件传递可靠，所以都基于 TCP 连接

如何判断邮箱是否存在？利用 SMTP 协议

查找邮箱域名对应的 SMTP 服务器地址
尝试与服务器建立连接
连接成功后尝试向需要验证的邮箱发送邮件
根据返回结果判定邮箱地址的真实性

4 DHCP

动态主机配置协议提供了即插即用的连网方式，用户不再需要手动配置 IP 地址等信息

客户端发送 Discover 报文，该报文的目的地址为 255.255.255.255:67，源地址为 0.0.0.0:68，被放入 UDP 中，该报文被广播到同一个子网的所有主机上。如果客户端和 DHCP 服务器不在同一个子网，就需要使用中继代理
DHCP 服务器收到 Discover 报文之后，发送 Offer 报文给客户端，该报文包含了客户端所需要的信息。因为客户端可能收到多个 DHCP 服务器提供的信息，因此客户端需要进行选择
如果客户端选择了某个 DHCP 服务器提供的信息，那么就发送 Request 报文给该 DHCP 服务器
DHCP 服务器发送 Ack 报文，表示客户端此时可以使用提供给它的信息

五传输层：TCP & UDP

1 TCP vs UDP

UDP（User Datagram Protocol）是无连接的，尽最大可能交付，没有拥塞控制，面向报文（对于应用程序传下来的报文不合并也不拆分，只是添加 UDP 首部），支持一对一、一对多、多对一和多对多的交互通信
TCP（Transmission Control Protocol）是面向连接的，提供可靠交付，有流量控制，拥塞控制，提供全双工通信，面向字节流（把应用层传下来的报文看成字节流，把字节流组织成大小不等的数据块），每一条 TCP 连接只能是点对点的（一对一）

2 三次握手

在这里插入图片描述
三次握手的目的是建立可靠的通信信道，让双方确认自己与对方的发送与接收是正常的

第一次握手（SYN）：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常
第二次握手（SYN/ACK）：Client 确认自己发送、接收正常，对方发送、接收正常；Server 确认对方发送正常，自己接收正常
第三次握手（ACK）：Client 确认自己发送、接收正常，对方发送、接收正常；Server 确认自己发送、接收正常，对方发送、接收正常

3 四次挥手

在这里插入图片描述

第一次挥手（FIN）：客户端-发送一个 FIN，用来关闭客户端到服务器的数据传送
第二次挥手（ACK）：服务器-收到这个 FIN，它发回一个 ACK，确认序号为收到的序号加 1 。和 SYN 一样，一个 FIN 将占用一个序号
第三次挥手（FIN）：服务器-关闭与客户端的连接，发送一个 FIN 给客户端
第四次挥手（ACK）：客户端-发回 ACK 报文确认，并将确认序号设置为收到序号加 1

为什么客户端接收到服务器端的 FIN 报文后，进入 TIME_WAIT 状态而不是 CLOSED 状态？
是为了确保最后一个确认报文能够到达。如果 B 没收到 A 发送来的确认报文，那么就会重新发送连接释放请求报文，A等待一段时间就是为了处理这种情况的发生

4 TCP 如何实现可靠传输

TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层
TCP 报文段校验和。端到端的检验和，如果收到段的校验和有差错，TCP 将丢弃这个报文段
TCP 的接收端会丢弃重复的数据
流量控制：当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失（接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率）
拥塞控制：当网络拥塞时，减少数据的发送（发送方的发送窗口大小为 拥塞窗口 和接收方的 接受窗口 中较小的一个）
超时重传：当 TCP 发出一个段后，启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到确认，将重发报文段