[计算机网络]第一周

TCP/IP 与OSI

TCP/IP

TCP/IP 四层模型是一个分层网络通信模型，它将网络通信过程分为四个层次，这四层分别是：网络接口层、互联网层、传输层和应用层。

网络接口层负责在计算机和网络硬件之间传输数据，负责在物理网络上发送和接收数据帧，包括以太网、Wi-Fi 等协议
互联网层（网络层）通过 IP 协议提供数据包的路由和转发
传输层负责在两个主机之间提供端到端的通信服务，常见的协议有 TCP 和 UDP
应用层通过各种协议提供网络应用程序的功能，如 HTTP、FTP、SMTP 等协议

在这里插入图片描述

OSI

OSI（Open Systems Interconnection）七层模型将网络通信分为七个层次，每一层都有特定的功能，且每层相对独立，可以与其他层交互但不会影响其他层的内部实现。

七层模型从高到低依次为：

应用层（Application Layer）：用户交互界面，提供网络服务，如HTTP、FTP、SMTP等。
表示层（Presentation Layer）：数据格式转换、加密、解密，如JPEG、MPEG、SSL/TLS等。
会话层（Session Layer）：建立、管理、终止会话，如NetBIOS、RPC等。
传输层（Transport Layer）：可靠传输，流量控制，错误检测，如TCP、UDP等。
网络层（Network Layer）：路径选择和逻辑地址（IP）管理，如IP、ICMP等。
数据链路层（Data Link Layer）：物理地址（MAC）寻址，错误检测与纠正，如以太网、PPP等。
物理层（Physical Layer）：比特流传输，物理连接，如光纤、网线、无线电波等。

区别

OSI 七层模型 是另一个著名的网络模型，它将网络通信过程分为七个层次：物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。
简化与实用性：TCP/IP 四层模型是对 OSI 七层模型的简化，省略了会话层和表示层，将数据链路层和物理层合并为网络接口层。这种简化更符合实际应用中的网络协议栈实现。
应用层的差异：在 OSI 模型中，应用层、表示层和会话层是分开的，而在 TCP/IP 模型中，它们被合并成了单一的应用层。这种设计简化了上层协议的开发和实现。

用户从输入URL到页面展示发生了什么

1）浏览器解析 URL

浏览器会解析 URL，根据请求信息生成对应的 HTTP 请求报文。

2）DNS 解析

请求需要知晓服务器域名对应的 IP 地址才能通信，浏览器会检查本地缓存、操作系统缓存，甚至路由器缓存。如果未命中缓存，浏览器向配置的 DNS 服务器发送查询请求，DNS 服务器递归查询最终返回 IP 地址。

3）TCP或者UDP

接着浏览器会调用 Socket 库委托协议栈工作，根据指定的情况选择 TCP 或 UDP。

如果使用 TCP，需要通过三次握手建立连接。需要在数据发送前通过三次握手与服务端建立连接。

此时得到了封装了 HTTP 数据的 TCP 数据包。

4）IP

在 TCP 数据包的基础上，再封装源地址 IP 和目标地址 IP 等信息，得到网络包。有了 IP 就能在多个网络节点中确定数据包的传输路径，最终能找到目标服务器。

5）MAC

得到网络包后，需要在 IP 头部的前面加上 MAC 头部，封装发送方 MAC 地址和接收方目标 MAC 地址。

MAC 用来确保子网内设备两点之间的通信寻址。（IP 是多个网络节点传输寻址）

6）网卡

这个时候，网络包还是存储在内存中的二进制数据，需要网卡把二进制数据转换为电信号，通过网线进行传输。

7）交换机

通过网线会连到交换机，交换机是二层网络设备。工作在 MAC 层，它会根据数据包中的 MAC 头找到另一个设备连接在交换机的哪个端口，然后传输。

如果找不到对应的端口，则会向交换机上的所有端口(除了源端口)广播。

8）路由器

路由器也是进行转发，但它是三层网络设备，包含 IP 层。利用路由器，数据在不同网络节点之间转发，最后到达服务器。

9）层层验证

服务器确认 MAC 地址匹配、IP 地址匹配，如果是 TCP 协议则看看序列号是否匹配，若匹配根据端口找到对应的监听进程，此时服务器上对应的应用就接收到数据了。

10）服务器处理

服务器接收到请求后，处理相应的业务逻辑，生成 HTTP 响应。这其间可能涉及到读取数据库、访问文件系统等。最终会生成响应给客户端（又是一层一层的封装 TCP、IP、MAC 等头部数据，得到最终传输的数据包），从网卡到交换机到路由器…

11）浏览器接收响应并渲染页面

经过多个路由器转发后，浏览器最终会接收到服务器返回的响应，进行页面渲染展示。

HTTP常见状态码

常见的http状态码分为5大类,每个状态码由3位数字组成,第一位表示类别

1XX 信息响应

100 Continue：服务器已接收请求的初步部分，客户端应继续请求。
101 Switching Protocols：服务器同意切换协议，如从 HTTP 切换到 WebSocket。

2XX 成功

200 OK：请求成功，服务器返回所请求的资源或数据。
201 Created：请求成功并创建了新的资源，常用于 POST 请求。
204 No Content：请求成功但服务器不返回任何内容，常用于删除操作。

3XX 重定向

301 Moved Permanently：资源已永久移动到新的 URL，客户端应使用新 URL 访问。
302 Found：资源临时移动到新的 URL，客户端应继续使用原来的 URL。
304 Not Modified：资源未修改，客户端可以使用缓存版本。

4XX 客户端错误

400 Bad Request：请求无效或语法错误，服务器无法处理。
401 Unauthorized：请求需要身份验证，客户端未提供有效的凭证。
403 Forbidden：服务器理解请求但拒绝执行，通常是权限问题。
404 Not Found：请求的资源在服务器上未找到。

5XX 服务端错误

500 Internal Server Error：服务器内部错误，无法完成请求。
502 Bad Gateway：服务器作为网关或代理，从上游服务器接收到无效响应。
503 Service Unavailable：服务器暂时无法处理请求，通常是因为过载或维护。

扩展知识

1）常见的重定向机制：

301 Moved Permanently 和 302 Found 都用于重定向，但前者用于永久重定向，通常会更新客户端的书签，而后者用于临时重定向，不会更新书签。
307 Temporary Redirect 与 302 Found 类似，但要求客户端必须使用相同的 HTTP 方法进行重定向请求，保证重定向的语义一致性。

2）4xx 与 5xx 状态码的区别：

4xx 系列状态码表示客户端的问题，如请求的格式错误（400）、未经授权访问（401）、请求的资源不存在（404）等。客户端应根据这些状态码调整请求内容或行为。
5xx 系列状态码表示服务器的内部问题，如服务器错误（500）、服务不可用（503）等。通常，客户端需要稍后重试请求。

3）204 和 304 区别：

204 No Content：适用于不需要返回响应体的成功操作，比如删除资源或表单提交后的页面跳转。
304 Not Modified：用于缓存机制中，当资源未修改时，服务器通过返回该状态码，通知客户端继续使用缓存资源，减少带宽消耗。

4）401 和 403 区别：

状态码 401 Unauthorized 和 403 Forbidden 常用于访问控制。当用户未认证时，返回 401 提示用户登录，而在用户认证后发现无权访问资源时，返回 403 提示权限不足。

HTTP请求报文

# 请求行
POST /api/user HTTP/1.1
# 请求头
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: application/json
Content-Type: application/json
Authorization: Bearer abcdefg12345
# 空行

# 请求体
{
    "username": "johndoe",
    "password": "password123"
}

组成

请求行（Request Line）：包含请求方法（如GET、POST）、请求的资源路径（如/index.html）、以及HTTP协议版本（如HTTP/1.1）。
请求头（Request Headers）：包含各种键值对，用于传递客户端环境、请求内容、认证信息等。
空行（Blank Line）：用于分隔请求头和请求体。
请求体（Request Body）：仅在POST、PUT等方法中存在，包含需要发送到服务器的数据。

HTTP响应报文

组成

状态行：由HTTP协议版本号、状态码和状态消息三部分组成。例如：HTTP/1.1 200 OK。
响应头部(header)：包含服务器返回的一些附加信息，比如内容类型、内容长度、服务器信息等。
空行：用来分隔响应头部和响应体。
响应体(body)：服务器返回给客户端的具体内容，比如HTML代码、JSON数据等。

//状态行
HTTP/1.1 200 OK 
//响应头
Date: Mon, 27 Jul 2023 12:00:00 GMT 
Content-Type: text/html; charset=UTF-8 Content-Length: 138 
Connection: keep-alive 
//空行

//响应体
<html> <head> <title>示例页面</title> </head> <body> <h1>欢迎来到我的示例页面！</h1> </body> </html>

HTTP请求方法

GET：请求指定的资源，通常用于获取数据，不包含请求体。
POST：向服务器提交数据，通常用于表单提交，数据在请求体中。
PUT：用于更新资源，数据也在请求体中。
DELETE：请求删除指定资源。

get 与post请求区别

GET

作用：从服务器获取资源
参数传递：GET请求的参数一般写在URL中，不安全
参数长度：GET传送的数据量小，小于2KB
编码方式：GET只能进行URL编码
缓存机制：GET请求会被浏览器主动缓存
请求参数会被完整的保存在浏览器
产生的URL可以为保存为书签
时间消耗：GET请求一次产生一个TCP数据包
请求流程：对于GET请求，浏览器会把请求的头部和数据一起发送，服务器响应200
安全幂等：由于GET请求是获取资源，因此GET是安全的，并且因为它不会修改服务器的资源，因此它每次返回的结果是一样的，因此它是幂等的。

POST

作用：向服务器提交资源
参数传递：参数存放在请求体，对数据类型无限制
参数长度：默认不受限制
编码方式：支持多种编码方式
缓存机制：POST不会被浏览器主动缓存
POST的参数不会被保留在历史记录
POST产生的URL不能保存为书签
时间消耗：一次产生两个TCP数据包
请求流程：浏览器会先发送头部，服务器在响应100之后，浏览器才会继续发送请求数据，服务器响应200，返回数据
安全幂等：POST请求向服务器提交资源，会改变服务器的资源，因此不安全，每次POST请求都会改变资源，因此返回的结果不一样，因此不幂等。

HTTP1.0 HTTP1.1 HTTP2.0区别

HTTP/1.0 版本主要增加以下几点：

增加了 HEAD、POST 等新方法。
增加了响应状态码。
引入了头部，即请求头和响应头。
在请求中加入了 HTTP 版本号。
引入了 Content-Type ，使得传输的数据不再限于文本。
HTTP/1.1 版本主要增加以下几点：
新增了连接管理即 keepalive ，允许持久连接。
支持 pipeline，无需等待前面的请求响应，即可发送第二次请求。
允许响应数据分块（chunked），即响应的时候不标明Content-Length，客户端就无法断开连接，直到收到服务端的 EOF ，利于传输大文件。
新增缓存的控制和管理。
加入了 Host 头，用在你一台机子部署了多个主机，然后多个域名解析又是同一个 IP，此时加入了 Host 头就可以判断你到底是要访问哪个主机。

HTTP/2 版本主要增加以下几点：

是二进制协议，不再是纯文本。
支持一个 TCP 连接发起多请求，移除了 pipeline。
利用 HPACK 压缩头部，减少数据传输量。
允许服务端主动推送数据。

http 1.0与http 1.1

更新主要是因为 HTTP/1.0 很大的性能问题，就是每请求一个资源都得新建一个 TCP 连接，而且只能串行请求。

http2.0 与http1.1

随着 HTTP/1.1 的发布，互联网也开始了爆发式的增长，这种增长暴露出 HTTP 的不足，主要还是性能问题，而 HTTP/1.1 无动于衷。

http3.0 与http2.0

这 HTTP/2 还没捂热， HTTP/3 怎么就来了？
这次又是 Google，它自己突破自己，主要也是源自于痛点，这次的痛点来自于 HTTP 依赖的 TCP。

HTTP 2.0 与HTTP3.0区别

基于的传输层协议不同：

HTTP/2：基于 TCP，使用二进制分帧层（Binary Framing Layer）实现多路复用。
HTTP/3：基于 UDP，使用 QUIC 协议（Quick UDP Internet Connections），提供类似TCP 的可靠性和多路复用。

2） 性能和可靠性区别：

HTTP/2：解决了HTTP/1.x中的队头阻塞问题，但仍然受制于TCP的队头阻塞，尤其在高延迟或丢包情况下。
HTTP/3：通过 QUIC 协议，避免了 TCP 队头阻塞，即使在网络不稳定的情况下也能提供更好的性能。

3）从安全性角度来看：

HTTP/2：可以使用 TLS 加密（HTTPS），但加密并非强制要求。
HTTP/3：默认使用 QUIC 自带的 TLS 1.3加密，安全性更高，且加密是强制的。

4） 从连接建立速度：

HTTP/2：需要 TCP 三次握手和 TLS 握手，连接建立相对较慢。
HTTP/3：QUIC 集成了连接建立和加密握手，连接建立速度更快，尤其在初次连接时。

quic

QUIC（Quick UDP Internet Connections）是一种由 Google 开发的基于 UDP 的传输层协议，旨在改进 HTTP/2 的性能。QUIC 的设计目标是减少连接延迟，提高传输效率和安全性。

HTTP与HTTPS的区别

1）数据传输安全性：

HTTP：数据以明文传输，容易被窃听、篡改。
HTTPS：通过 SSL/TLS 协议对数据进行加密传输，提供数据机密性和完整性保障。

2）端口号：

HTTP：默认使用端口 80。
HTTPS：默认使用端口 443。

3）性能：

HTTP：无加密过程，连接建立速度稍快。
HTTPS：基于 HTTP上又加了 SSL（Secure Sockets Layer）或 TLS（Transport Layer Security）协议来实现的加密传输,加解密过程增加了计算开销，握手时间较长，但现代硬件和协议优化已使性能差距减小。

4）SEO 影响：

HTTP：搜索引擎一般会降低未加密站点的排名。
HTTPS：搜索引擎更倾向于优先展示 HTTPS 网站。

https相较于http在三次握手之后还需要进行SSL/TLS 的握手过程，才可进入加密报文传输。

https 工作原理

HTTPS是在HTTP的基础上加入了SSL/TLS协议，用于保障网络通信的安全。它的工作原理主要依赖于非对称加密和对称加密的组合使用，以及数字证书来验证服务器身份。

首先呢，客户端发起HTTPS连接请求到服务器，服务器把自己的数字证书（包含公钥）发给客户端。客户端验证证书合法后，就生成一个随机的会话密钥，并用服务器的公钥加密后发给服务器。服务器再用自己的私钥解密，这样双方就共享了这个会话密钥啦。

然后呢，在后续的通信中，客户端和服务器就用这个会话密钥对发送和接收的数据进行加密和解密，保证数据的安全性和完整性。

数字证书的作用就像是服务器的身份证一样，可以确保客户端与合法的服务器进行通信哦

强制缓存与协商缓存

对于重复的http请求,每次请求得到的数据一样,
便可把缓存响应的数据到本地
http缓存方式分为强制缓存与协商缓存

强制缓存

浏览器判断缓存是否过期,决定是否使用缓存的主动权在浏览器
利用响应头部字段实现,表示资源在客户端缓存的有效期
Cache-Control 相对时间(优先级高)
Expires 绝对时间

协商缓存

通过服务端告知是否可以使用本地缓存
当本地资源过期,访问服务端,服务端判断数据是否变化,没有变化,就返回304状态码,客户端从本地缓存中加载资源否则就更新资源

TCP与UDP的区别

TCP 提供了可靠、面向连接的传输，适用于需要数据完整性和顺序的场景；UDP 则提供了更轻量、面向报文的传输，适用于实时性要求高的场景。

主要可以从以下五个方面来看待它们的不同：

1）连接性：

TCP：面向连接的协议。通信前需要建立连接（三次握手），通信结束后需要断开连接（四次挥手）。
UDP：无连接的协议。不需要建立连接，直接发送数据包。

2）可靠性：

TCP：可靠传输协议。通过确认机制、重传机制、序列号、流量控制和拥塞控制确保数据不丢失、不重复、按顺序到达。
UDP：不可靠传输协议。不提供确认和重传机制，数据包可能丢失、重复或乱序。

3）数据传输方式：

TCP：面向字节流的协议。数据作为一个连续的流传输，可以按需分片和重组。
UDP：面向报文的协议。数据作为独立的报文（数据包）传输，保留了应用层的消息边界。

4）性能：

TCP：由于需要连接建立、确认和重传机制，传输速度相对较慢，但提供了可靠性。
UDP：传输速度快，因为没有连接建立和维护的开销，也没有确认和重传机制。

5）应用场景：

TCP：适用于需要可靠传输的应用，如网页浏览（HTTP/HTTPS）、文件传输（FTP）、电子邮件（SMTP/IMAP）等。
UDP：适用于对速度要求高但对可靠性要求不高的应用，如视频直播、在线游戏、DNS 查询等。

TCP 如何确保可靠性

TCP（传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。它主要通过以下几种机制来确保数据传输的可靠性：

字节流传输与序列号：

TCP将应用层发送的数据划分成以字节为单位的报文段（Segment），并为每个报文段分配一个序列号。这样，接收方就能根据序列号对接收到的数据进行排序和重组，确保数据的顺序性和完整性。
确认重传机制：

TCP使用确认应答（ACK）机制来确保数据已被正确接收。当接收方收到报文段后，会发送一个ACK报文给发送方，其中包含了下一个期望接收的报文段的序列号。如果发送方在一段时间内没有收到ACK报文，就会认为该报文段丢失，并重新发送该报文段。这种机制能够确保数据的可靠传输。
滑动窗口机制：

TCP利用滑动窗口机制来实现流量控制和拥塞控制。窗口大小表示接收方能够接收的报文段数量，发送方根据接收方的窗口大小来调整自己的发送速度。当接收方的窗口大小变为0时，发送方会停止发送数据，直到接收方增加窗口大小并发送新的ACK报文。这种机制能够防止发送方发送速度过快而导致接收方处理不及时的问题。
头部校验和：

TCP在传输过程中，会为每个报文段添加一个头部校验和。接收方在收到报文段后，会对头部进行校验和计算，并与发送方的校验和进行比较。如果两者不一致，则说明数据在传输过程中发生了损坏或篡改，接收方会要求发送方重新传输该报文段。
连接管理：

TCP使用三次握手机制来建立连接，确保双方都能够正常通信。在连接建立后，双方会进行数据传输。当数据传输完毕后，TCP会使用四次挥手机制来关闭连接，确保数据已经完全传输并释放资源。
拥塞控制：

TCP还通过拥塞控制算法来避免网络拥塞。它根据网络的拥塞情况来动态调整传输速率，以确保网络的稳定性和可靠性。拥塞控制包括慢启动、拥塞避免、快速重传和快速恢复等阶段。

UDP怎么实现可靠运输

UDP本身是个无连接的协议，它可不保证数据包的可靠传输哦。但是呢，在某些应用场景下，我们确实需要UDP能更可靠地传输数据。那怎么办呢？别担心，我们可以通过在应用层引入一些机制和算法来实现UDP的可靠传输。

方法一：基于ACK和重传的机制

就像TCP那样，我们也可以在UDP的应用层引入ACK确认包和数据包的重传机制。发送方在发送数据包后，就等着接收方返回ACK确认包。如果在一定时间内没收到ACK确认包，那就认为数据包丢失了，需要进行重传。接收方在接收到数据包后，就发送ACK确认包给发送方，表示已经成功接收啦。这样一来二去的，虽然会增加点传输延迟和网络流量，但数据包的可靠传输就有保障啦！

方法二：序号和滑动窗口

我们还可以给每个数据包分配一个唯一的序号，接收方在接收到数据包后，就根据序号进行排序。为了支持流量控制和拥塞控制，我们还可以引入滑动窗口机制。发送方维护一个发送窗口，接收方维护一个接收窗口。发送方只能发送窗口内的数据包，接收方也只能接收窗口内的数据包。这样一来，数据包的有序传输和流量控制就都能实现啦！

方法三：FEC（Forward Error Correction）

FEC是一种通过添加冗余信息来实现可靠传输的机制。发送方在发送数据包前，可以使用一些编码算法对数据包进行处理，生成冗余信息，并和原始数据包一起发送。接收方在接收数据包时，解码并恢复原始数据包。如果发现丢失了一些数据包，还可以通过冗余信息来恢复丢失的数据包呢！不过呢，这种方法会增加传输的带宽和延迟哦。