备战秋招010（20230717）
文章目录
- 前言
- 一、基础
-
-
- 1、网络模型
-
-
- 01、OSI 七层
- 02、TCP/IP 四层
- 04、Linux 网络协议栈
- 05、问题
-
- 2、常见的网络协议
-
-
- 01、应用层
- 02、传输层
- 03、网络层
-
- 3、输入网址到网页显示过程
-
-
- 01、基础
- 02、DNS 解析
- 03、URL 和 URI
-
-
- 二、HTTP
-
-
- 1、基础
-
-
- 01、概念
- 02、状态码
- 03、无状态
-
- 2、Get 和 Post
-
-
- 01、区别
- 02、安全和幂等
-
- 3、缓存
-
-
- 01、基础
- 02、工作机制
-
- 4、HTTP 版本
-
-
- 01、HTTP 1.1
- 02、HTTP 2.0
- 03、HTTP 3.0
-
- 5、HTTPS
-
-
- 01、基础
- 02、HTTP VS HTTPS
- 03、SSL/TLS
- 04、工作流程
-
-
- 三、TCP
-
-
- 1、TCP
-
-
- 01、基础
- 02、三次握手
- 03、四次挥手
- 04、问题
-
- 2、UDP
- 3、TCP 传输可靠性
-
-
- 01、基础
- 02、重传机制
- 03、流量控制
- 04、拥塞控制
-
-
- 四、IP
-
-
- 1、IP
-
-
- 01、基础
- 02、报文头部格式
- 03、工作流程
-
- 2、ARP
-
-
- 01、MAC
- 02、ARP 协议
- 03、工作原理
-
-
- 总结
前言
提示：这里为每天自己的学习内容心情总结；
Learn By Doing，Now or Never，Writing is organized thinking.
目前的想法是，根据 Java Guide 和 JavaLearning 和 小林coding进行第一轮复习，之后根据 Tiger 和 CS-Notes 进行最后的重点复习。
先多，后少。
提示：以下是本篇文章正文内容
一、基础
1、网络模型
OSI 七层、TCP/IP 四层。
01、OSI 七层
「OSI 七层模型」 是国际标准化组织提出一个网络分层理论模型，其大体结构以及每一层提供的功能如下图所示：
每一层都专注做一件事情，并且每一层都需要使用下一层提供的功能比如传输层需要使用网络层提供的路由和寻址功能，这样传输层才知道把数据传输到哪里去。
在实际生产中实现的网络协议是四层 TCP/IP 体系。
02、TCP/IP 四层
「TCP/IP 四层模型」 是目前被广泛采用的一种模型，是 OSI 七层模型的精简版本，由以下 4 层组成：
- 应用层：为计算机用户提供服务，比如 HTTP、DNS、FTP 等;
- 传输层：为两台主机进程之间的通信提供数据传输服务（负责端到端的通信），比如 TCP、UDP 等；
- 网络层：负责网络包的路由和寻址，比如 IP、ICMP 等；
- 网络接口层：数据在物理链路上的传输，，比如网络包的封帧、 MAC 寻址、差错检测，以及通过网卡传输网络帧等；
需要注意的是，我们并不能将 TCP/IP 四层模型 和 OSI 七层模型完全精确地匹配起来，不过可以简单将两者对应起来，各层之间的传输单位：
- 应用层：HTTP 的传输单位则是消息或报文（message）；
- 传输层：TCP 层的传输单位是段（segment）；
- 网络层：IP 层的传输单位是包（packet）;
- 网络接口层：帧（frame）
但这些名词并没有什么本质的区分，可以统称为数据包。
04、Linux 网络协议栈
05、问题
为什么网络要分层？
- 是为了让每一层只需要专注于做一类事情，保证各层之间的相互独立。各层之间只需要调用下层提供好的功能即可，不需要关注下层如何实现的。
- 每一层都可以选用最合适的技术实现，只需要提供接口以供调用，降低了耦合性，提高了整体的灵活性。
2、常见的网络协议
01、应用层
- **HTTP：**超文本传输协议，主要用于 Web 浏览器与 Web 服务器之间的通信，使用浏览器浏览网页的时候，就是通过 HTTP 请求进行加载的；
- SSH：安全的网络传输协议，通过加密和认证机制实现安全的访问和文件传输等业务；
- DNS: 域名管理系统，用于解决域名和 IP 地址的映射问题。
02、传输层
- TCP：传输控制协议，提供 面向连接 的，可靠 的数据传输服务。
- UDP：用户数据协议，提供 无连接 的，尽最大努力 的数据传输服务（不保证数据传输的可靠性），简单高效。
03、网络层
- IP：对数据包进行路由和寻址，以便它们可以跨网络传播并到达正确的目的地；
- ARP： IP 地址属于逻辑地址，而 MAC 地址才是物理地址，ARP 协议解决了 IP 地址转 MAC 地址的一些问题；
- ICMP：一种用于传输网络状态和错误消息的协议，常用于网络诊断和故障排除。例如，Ping 工具就使用了 ICMP 协议来测试网络连通性。
3、输入网址到网页显示过程
01、基础
面试中常会被问到一个问题：当在浏览器的地址栏中输入一个网址后，到显示网页，这个过程发生了什么？
浏览器做的步骤如下：
- DNS 解析：浏览器解析 URL ，查询 DNS，获取域名对应的 IP 地址；
- TCP 连接：浏览器获得对应域名的 IP 地址后，浏览器向服务器请求建立连接，发起三次握手；
- 发送 HTTP 请求：TCP 连接之后，浏览器向服务器发送 HTTP 请求。
- 服务器处理请求并返回 HTTP 报文：服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的 HTTP 报文返回给浏览器。
- 浏览器解析渲染页面：浏览器解析并渲染视图，若遇到对 js 文件、css 文件及图片等静态资源的引用，则重复以上步骤向服务器请求静态资源。浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。
- 连接结束。
02、DNS 解析
「DNS」（Domain Name System），域名管理系统，目的是解决域名和 IP 地址的映射问题。DNS 是应用层协议，基于 UDP 协议之上，端口为 53 。
**「DNS 域名解析」**是查询目标 Web 服务器的 IP 地址，域名是一个层级的树状结构：
- 根 DNS 服务器（.）
- 顶级域 DNS 服务器（.com）
- 权威 DNS 服务器（server.com）
域名解析是一个递归查询的过程，工作流程步骤如下：
- 查询本地 DNS 服务器，如果命中缓存，直接返回；
- 命中失败，查询根 DNS 服务器，判断 URL 的请求类型，去对应的顶级域名服务器查找；
- 找到权威 DNS 服务器，将对应的 IP 地址返回给客户端，建立连接；
03、URL 和 URI
「URI」（Uniform Resource Identifier），统一资源标志符，可以唯一标识一个资源。
「URL」（Uniform Resource Locator），统一资源定位符，提供该资源的路径，是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何定位到（locate） 这个资源。
URI 的作用像身份证号一样，URL 的作用更像家庭住址一样。
URL 是一种具体的 URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。
二、HTTP
1、基础
01、概念
HTTP 是「超文本传输协议」（HyperText Transfer Protocol），是一种在计算机世界里专门在**「两点」之间「传输」文字、图片、音频、视频等「超文本」**数据的「约定和规范」。
HTTP 是一个无状态（stateless）协议，服务器不维护任何有关客户端过去所发请求的消息。
HTTP 是应用层协议，它以 TCP（传输层）作为底层协议，默认端口为 80，通信过程主要如下：
- 服务器在 80 端口等待客户的请求。
- 浏览器发起到服务器的 TCP 连接（创建套接字 Socket）。
- 服务器接收来自浏览器的 TCP 连接。
- 浏览器（HTTP 客户端）与 Web 服务器（HTTP 服务器）交换 HTTP 消息。
- 关闭 TCP 连接。
02、状态码
03、无状态
HTTP 是不保存状态（无状态）的协议, 如何保存用户状态?
**「无状态」**是指，接收方不会保存请求方的信息，对于请求方的每一个请求，接收方都认为这个请求是第一次请求。
Session 机制的存在就是为了解决这个问题，通过在服务端记录用户的状态，就可以标识并且跟踪这个用户了（一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会自动销毁这个 Session）。
在服务端保存 Session 的方法很多，比如：使用内存数据库 redis 保存。
大部分情况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。如果Cookie 被禁用，利用 URL 重写把 Session ID 直接附加在 URL 路径的后面。
2、Get 和 Post
01、区别
**「Get」**是指，从服务器获取指定的资源（静态的文本、页面、图片、视频等）。
- 请求参数位置一般是写在 URL 中；
- URL 规定只能支持 ASCII，所以 GET 请求的参数只允许 ASCII 字符 ；
- 浏览器会对 URL 的长度有限制（HTTP协议本身对 URL长度并没有做任何规定）。
**「Post」**是指，根据请求负荷（报文 body）对指定的资源进行处理。
- 请求携带数据的位置一般是写在报文 body 中；
- body 中的数据可以是任意格式的数据，只要客户端与服务端协商好即可；
- 浏览器对 body 大小没有限制。
理论上**，任何请求都可以带 body 的** ，只是因为 RFC 规范定义的 GET 请求是获取资源，所以根据这个语义不需要用到 body。
URL 中的查询参数也不是 GET 所独有的，POST 请求的 URL 中也可以有参数的。
02、安全和幂等
**「安全」是指请求方法不会「破坏」服务器上的资源，「幂等」**是指多次执行相同的操作，结果都是「相同」的。
「Get」是安全且幂等的，是「只读」操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的。
可以对 GET 请求的数据做缓存，缓存可以做到浏览器本身上，也可以做到代理上（如nginx）。
「Post」是不安全且不幂等的，因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。浏览器一般不会缓存 POST 请求，也不能把 POST 请求保存为书签。
因为 HTTP 传输的内容都是明文的，虽然在浏览器地址拦看不到 POST 提交的 body 数据，但是只要抓个包就都能看到了。
所以，要避免传输过程中数据被窃取，就要使用 HTTPS 协议，这样所有 HTTP 的数据都会被加密传输。
3、缓存
01、基础
对于一些具有重复性的 HTTP 请求，如果每次请求获取到的数据都是一样的，可以把这对「请求-响应」的数据都缓存在本地，那么下次就直接读取本地的数据，不必在通过网络获取服务器的响应了。
避免重复发送 HTTP 请求的方法就是通过缓存技术，HTTP 有两种缓存实现方式：强制缓存、协商缓存。
**「强制缓存」**是指，只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边。
**「协商缓存」**是指，客户端与服务端协商后，告知客户端是否可以使用缓存。
02、工作机制
当浏览器发送请求时，首先会检查强制缓存是否过期：
- 如果没有过期，则直接使用本地缓存；
- 如果缓存过期了，判断是否有 Etag 标识；
- 如果有 Etag 标识，再次向服务器发送请求，根据服务器返回的响应状态码
200就表明数据有更新，请求更新结果；304无更新，直接从缓存中读取；
- 如果没有 Etag 表示，判断是否有 Last-Modified 标识；
- 如果有，再次向服务器发送请求，根据服务器返回的响应状态码，200 & 304；
- 没有，向服务器直接请求响应。
- 如果有 Etag 标识，再次向服务器发送请求，根据服务器返回的响应状态码
4、HTTP 版本
01、HTTP 1.1
HTTP/1.1 相比 HTTP/1.0 提高了什么性能？
- **长连接：**使用长连接的方式改善了 HTTP/1.0 短连接造成的性能开销；
- 状态响应码： HTTP/1.1 中新加入了大量的状态码；
- **缓存机制：**HTTP/1.1 则引入了更多的缓存控制策略；
- **管道：**支持管道（pipeline）网络传输，只要第一个请求发送成功，不必等其响应回来，就可以接着发送第二个请求，可以减少整体的响应时间；
但 HTTP/1.1 还是有性能瓶颈：
- 请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩
Body的部分； - 发送冗长的首部。每次互相发送相同的首部造成的浪费较多；
- 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞；
- 没有请求优先级控制；
- 请求只能从客户端开始，服务器只能被动响应。
02、HTTP 2.0
HTTP/1.1 和 HTTP/2.0 有什么区别？
- IO 多路复用（Multiplexing）：
- HTTP/2.0 在同一连接上可以同时传输多个请求和响应（可以看作是 HTTP/1.1 中长链接的升级版本）。
- HTTP/1.1 则使用串行方式，每个请求和响应都需要独立的连接。
- HTTP/2.0 在处理多个请求时更加高效，减少了网络延迟和提高了性能。
- 二进制帧（Binary Frames）：
- HTTP/2.0 使用二进制帧进行数据传输；
- HTTP/1.1 则使用文本格式的报文。
- 二进制帧更加紧凑和高效，减少了传输的数据量和带宽消耗。
- 头部压缩（Header Compression）：
- HTTP/1.1 支持 Body 压缩，Header 不支持压缩。
- HTTP/2.0 支持对 Header 压缩，减少了网络开销。
- 服务器推送（Server Push）：
- HTTP/2.0 支持服务器推送，可以在客户端请求一个资源时，将其他相关资源一并推送给客户端，从而减少了客户端的请求次数和延迟。
- 而 HTTP/1.1 需要客户端自己发送请求来获取相关资源。
03、HTTP 3.0
HTTP/2.0 和 HTTP/3.0 有什么区别？
- 传输协议：
- HTTP/2.0 是基于 TCP 协议实现的；
- HTTP/3.0 新增了 QUIC（Quick UDP Internet Connections） 协议来实现可靠的传输，提供与 TLS/SSL 相当的安全性，具有较低的连接和传输延迟。
- 连接建立：
- HTTP/2.0 需要经过经典的 TCP 三次握手过程；
- HTTP/3.0 由于 QUIC 协议的特性，在最佳情况下不需要任何的额外往返时间就可以建立新连接；
- 队头阻塞：HTTP/2.0 多请求复用一个 TCP 连接，一旦发生丢包，就会阻塞住所有的 HTTP 请求。由于 QUIC 协议的特性，HTTP/3.0 在一定程度上解决了队头阻塞（Head-of-Line blocking, 简写：HOL blocking）问题，一个连接建立多个不同的数据流，这些数据流之间独立互不影响，某个数据流发生丢包了，其数据流不受影响（本质上是多路复用+轮询）。
- 错误恢复：HTTP/3.0 具有更好的错误恢复机制，当出现丢包、延迟等网络问题时，可以更快地进行恢复和重传。而 HTTP/2.0 则需要依赖于 TCP 的错误恢复机制。
- 安全性：HTTP/2.0 和 HTTP/3.0 在安全性上都有较高的要求，支持加密通信，但在实现上有所不同。HTTP/2.0 使用 TLS 协议进行加密，而 HTTP/3.0 基于 QUIC 协议，包含了内置的加密和身份验证机制，可以提供更强的安全性。
5、HTTPS
01、基础
HTTPS 协议（Hyper Text Transfer Protocol Secure），是 HTTP 的加强安全版本，HTTPS 是基于 HTTP 的，也是用 TCP 作为底层协议，并额外使用 SSL/TLS 协议用作加密和安全认证，默认端口号是 443。
HTTPS 协议中，SSL 通道通常使用基于密钥的加密算法，密钥长度通常是 40 比特或 128 比特。
HTTP 是超文本传输协议，信息是明文传输的，存在安全风险问题。
HTTPS 解决了 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。
HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输，而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zKNiIHYM-1689563292892)(https://cdn.xiaolincoding.com/gh/xiaolincoder/ImageHost/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C/HTTP/19-HTTPS%E4%B8%8EHTTP.png)]
HTTPS 的优点是：保密性好、信任度高。
02、HTTP VS HTTPS
HTTP 和 HTTPS 有什么区别？
- 端口号：
- HTTP 默认是 80；
- HTTPS 默认是 443。
- URL 前缀：
- HTTP 的 URL 前缀是
http://； - HTTPS 的 URL 前缀是
https://；
- HTTP 的 URL 前缀是
- 安全性和资源消耗：
- HTTP 协议运行在 TCP 之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份；
- HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。
- HTTP 安全性没有 HTTPS 高，但是 HTTPS 比 HTTP 耗费更多服务器资源。
03、SSL/TLS
SSL 指安全套接字协议（Secure Sockets Layer），TLS 是基于 SSL 之上的，但由于习惯叫法，通常把 HTTPS 中的核心加密协议混称为 SSL/TLS。
「SSL/TLS 」的核心要素是**「非对称加密」，「非对称加密」**是指，通信双方加密和解密使用不同的密钥：
- 公钥，可以公开的；
- 私钥，不能公开；
公钥加密的密文只有私钥可以解密，私钥加密的内容，也只有公钥可以解密。
使用 SSL/TLS 进行通信的双方需要使用非对称加密方案来通信，但是非对称加密设计了较为复杂的数学算法，在实际通信过程中，计算的代价较高，效率太低，因此，SSL/TLS 实际对消息的 加密 使用的是对称加密。
对于 server 来说，保管好私钥，发布公钥给其他 client，其他 client 只要把对称加密的密钥加密传给 server 即可，如此一来由于公钥加密只有私钥能解密，而私钥只有 server 有，所以能保证 client 向 server 传输是安全的。
server 解密后即可拿到对称加密密钥，这样交换了密钥之后就可以用对称加密密钥通信了。
「对称加密」是指，通信双方共享唯一密钥 k，加密和解密使用同一个密钥的方式：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HmbHaTpb-1689563292893)(https://cdn.nlark.com/yuque/0/2021/png/1032788/1614684878401-9be1fa1b-5ff0-4b40-9c83-7281ce456429.png?x-oss-process=image%2Fresize%2Cw_759%2Climit_0)]
**「数字签名」**是指，保证服务端的合法性。
当客户端（浏览器）向服务器发送 HTTPS 请求时，一定要先获取目标服务器的证书，并根据证书上的信息，检验证书的合法性。
一旦客户端检测到证书非法，就会发生错误。客户端获取了服务器的证书后，由于证书的信任性是由第三方信赖机构认证的，而证书上又包含着服务器的公钥信息，客户端就可以放心的信任证书上的公钥就是目标服务器的公钥。
04、工作流程
- 用户在浏览器发起 HTTPS 请求，默认使用服务端的
443端口进行连接； - 服务端收到请求，返回配置好的包含 公钥Pub 的 CA数字证书 给客户端。
- 客户端收到证书，校验合法性，主要包括是否在有效期内、证书的域名与请求的域名是否匹配，上一级证书是否有效（递归判断，直到判断到系统内置或浏览器配置好的根证书），如果不通过，则显示 HTTPS 警告信息，如果通过则继续。
- 客户端生成一个用于对称加密的 随机Key，并用证书内的 公钥Pub 进行加密，发送给服务端。
- 服务端收到 随机Key 的密文，使用与 公钥Pub 配对的 私钥Private 进行解密，得到客户端真正想发送的 随机Key。
- 服务端使用客户端发送过来的 随机Key 对要传输的 HTTP 数据进行对称加密，将密文返回客户端。
- 客户端使用 随机Key 对称解密密文，得到 HTTP 数据明文。
- 后续 HTTPS 请求都使用这个交换过的 随机Key 进行对称加解密即可。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7Qu6YdW2-1689563292893)(https://cdn.nlark.com/yuque/0/2021/png/1032788/1614684879110-93bc4c6b-fa14-4e9d-b948-6bf15774b18d.png?x-oss-process=image%2Fresize%2Cw_1080%2Climit_0)]
三、TCP
1、TCP
01、基础
为什么需要 TCP 协议？
网络层是「不可靠」的，它不保证网络包的按序交付、也不保证网络包中的数据的完整性。TCP 能确保接收端接收的网络包是无损坏、无间隔、非冗余和按序的。
TCP 是面向连接的、可靠的、基于字节流的传输层通信协议。
- 面向连接：一定是「一对一」才能连接，不能像 UDP 协议可以一个主机同时向多个主机发送消息，也就是一对多是无法做到的；
- 可靠的：无论网络链路中出现了怎样的链路变化，TCP 都可以保证一个报文一定能够到达接收端；
- 基于字节流：消息是「没有边界」的，所以无论我们消息有多大都可以进行传输。并且消息是「有序的」，当「前一个」消息没有收到的时候，即使它先收到了后面的字节，那么也不能扔给应用层去处理，同时对「重复」的报文会自动丢弃。
端口号：
- 源端口号和目标端口号是不可少的，如果没有这两个端口号，数据就不知道应该发给哪个应用。
序列号：
- 在建立连接时由计算机生成的随机数作为其初始值，通过 SYN 包传给接收端主机，每发送一次数据，就「累加」一次该「数据字节数」的大小。
- 用来解决网络包乱序问题。
确认应答号：
- 指下一次「期望」收到的数据的序列号，发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收。
- 用来解决不丢包的问题。
状态位：
- TCP 是面向连接的，双方要维护连接的状态，状态位的变更会引起连接的状态变化；
- ACK：该位为
1时，「确认应答」的字段变为有效，TCP 规定除了最初建立连接时的SYN包之外该位必须设置为1。 - RST：该位为
1时，表示 TCP 连接中出现异常必须强制断开连接。 - SYN：该位为
1时，表示希望建立连接，并在其「序列号」的字段进行序列号初始值的设定。 - FIN：该位为
1时，表示今后不会再有数据发送，希望断开连接。当通信结束希望断开连接时，通信双方的主机之间就可以相互交换FIN位置为 1 的 TCP 段。
窗口大小：
- 流量控制、拥塞控制。
02、三次握手
最开始，客户端和服务端都处于 CLOSED 状态，服务端主动监听某个端口，处于 LISTEN 状态。
- 客户端发送一个
SYN = 1，序列号为x的报文给服务端，之后客户端处于SYN-SENT状态。 - 服务端收到客户端的报文后，会给客户端发送两个报文，之后服务端处于
SYN-RCVD状态；SYN = 1的初始化序列号seq = y；ACK = 1的序列号为seq = x + 1；
- 客户端收到服务端报文后，需要给服务端发送一个响应报文
ACK = 1，seq = y + 1，此时，客户端和服务端就建立了连接。
第三次握手是可以携带数据的，而前两次握手不能携带数据（应用层数据）。
三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。
03、四次挥手
- 第一次挥手：客户端发送一个 FIN（SEQ=x） 标志的数据包->服务端，用来关闭客户端到服务器的数据传送，然后，客户端进入 FIN-WAIT-1 状态。
- 第二次挥手：服务器收到这个 FIN（SEQ=X） 标志的数据包，它发送一个 ACK （ACK=x+1）标志的数据包->客户端 。然后，此时服务端进入 CLOSE-WAIT 状态，客户端进入 FIN-WAIT-2 状态。
- 第三次挥手：服务端关闭与客户端的连接并发送一个 FIN (SEQ=y)标志的数据包->客户端请求关闭连接，然后，服务端进入 LAST-ACK 状态。
- 第四次挥手：客户端发送 ACK (ACK=y+1)标志的数据包->服务端并且进入TIME-WAIT状态，服务端在收到 ACK (ACK=y+1)标志的数据包后进入 CLOSE 状态。此时，如果客户端等待 2MSL 后依然没有收到回复，就证明服务端已正常关闭，随后，客户端也可以关闭连接了。
只要四次挥手没有结束，客户端和服务端就可以继续传输数据！
「MSL」(Maximum Segment Lifetime) : 一个片段在网络中最大的存活时间，2MSL 就是一个发送和一个回复所需的最大时间。如果直到 2MSL，Client 都没有再次收到 FIN，那么 Client 推断 ACK 已经被成功接收，则结束 TCP 连接。
04、问题
为什么不可以两次或者四次握手？
三个方面分析三次握手的原因：
- 三次握手才可以阻止重复历史连接的初始化（主要原因）；
- 三次握手才可以同步双方的初始序列号；
- 三次握手才可以避免资源浪费；
第 2 次握手传回了 ACK，为什么还要传回 SYN？
服务端传回发送端所发送的 ACK 表明，从客户端到服务端的通信是正常的。
回传 SYN 则是为了建立并确认从服务端到客户端的通信。
为什么要四次挥手？
TCP 是全双工通信，可以双向传输数据。任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了 TCP 连接。
举个例子：A 和 B 打电话，通话即将结束后。
- 第一次挥手：A 说“我没啥要说的了”
- 第二次挥手：B 回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话
- 第三次挥手：于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”
- 第四次挥手：A 回答“知道了”，这样通话才算结束。
为什么不能把服务器发送的 ACK 和 FIN 合并起来，变成三次挥手？
因为服务器收到客户端断开连接的请求时，可能还有一些数据没有发完，这时先回复 ACK，表示接收到了断开连接的请求。等到数据发完之后再发 FIN，断开服务器到客户端的数据传送。
如果第二次挥手时服务器的 ACK 没有送达客户端，会怎样？
客户端没有收到 ACK 确认，会重新发送 FIN 请求。
为什么第四次挥手客户端需要等待 2 MSL（报文段最长寿命）时间后才进入 CLOSED 状态？
第四次挥手时，客户端发送给服务器的 ACK 有可能丢失，如果服务端因为某些原因而没有收到 ACK 的话，服务端就会重发 FIN，如果客户端在 2*MSL 的时间内收到了 FIN，就会重新发送 ACK 并再次等待 2MSL，防止 Server 没有收到 ACK 而不断重发 FIN。
如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP 有一个机制是保活机制，如果在一个时间段（默认2小时）内如果没有任何连接相关的活动，TCP 保活机制会每隔一个时间间隔（默认75s），发送一个探测报文，该探测报文包含的数据非常少，如果连续几个（默认9个）探测报文都没有得到响应，则认为当前的 TCP 连接已经死亡，系统内核将错误信息通知给上层应用程序。
2、UDP
TCP 与 UDP 的区别？
- 是否面向连接：
- UDP 在传送数据之前不需要先建立连接；
- TCP 提供面向连接的服务，在传送数据之前必须先建立连接，数据传送结束后要释放连接。
- 是否是可靠传输：
- 远地主机在收到 UDP 报文后，不需要给出任何确认，并且不保证数据不丢失，不保证是否顺序到达。
- TCP 提供可靠的传输服务，TCP 在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，保证传输的数据，无差错、不丢失、不重复、并且按序到达。
- 传输效率：
- 由于使用 TCP 进行传输的时候多了连接、确认、重传等机制，所以 TCP 的传输效率要比 UDP 低很多。
- 传输形式：
- TCP 是面向字节流的；
- UDP 是面向报文的。
- 首部开销：TCP 首部开销（20 ～ 60 字节）比 UDP 首部开销（8 字节）要大。
- 是否提供广播或多播服务：
- TCP 只支持点对点通信；
- UDP 支持一对一、一对多、多对一、多对多；
| TCP | UDP | |
|---|---|---|
| 是否面向连接 | 是 | 否 |
| 是否可靠 | 是 | 否 |
| 是否有状态 | 是 | 否 |
| 传输效率 | 较慢 | 较快 |
| 传输形式 | 字节流 | 数据报文段 |
| 首部开销 | 20 ～ 60 bytes | 8 bytes |
| 是否提供广播或多播服务 | 否 | 是 |
什么时候选择 TCP，什么时候选 UDP?
- UDP 一般用于即时通信，比如：语音、 视频、直播等等。这些场景对传输数据的准确性要求不是特别高，比如你看视频即使少个一两帧，实际给人的感觉区别也不大。
- TCP 用于对传输准确性要求特别高的场景，比如文件传输、发送和接收邮件、远程登录等等。
3、TCP 传输可靠性
01、基础
TCP 如何保证传输的可靠性？
- 序列号：
- TCP 为了保证不丢包，就给每个包一个序列号，根据序列号可以进行去重；
- 重传机制：
- TCP 针对数据包丢失的情况，会用重传机制解决。
- 流量控制：
- 通过滑动窗口进行流量控制；
02、重传机制
**「重传」**机制，是针对数据包丢失的情况，常见的重传机制有：超时重传、选择性重传；
**「超时重传」**是指，在发送数据时，设定一个定时器，当超过指定的时间后，没有收到对方的 ACK 确认应答报文，就会重发该数据。TCP 会在以下两种情况发生超时重传：
- 数据包丢失；
- 确认应答丢失；
超时重传时间 RTO（Retransmission Timeout 超时重传时间） 的值应该略大于报文往返 RTT （Round-Trip Time 往返时延）的值。
「选择性重传」（Selective Acknowledgment）是指，在 TCP 头部「选项」字段里加一个 SACK ，接收方可以将已经接收到的数据信息发送给「发送方」，发送方就可以根据信息，只重传丢失的数据。
03、流量控制
**「流量控制」**是指，发送方 需要根据 接收方 实际处理数据的能力，发送方 以一个合适的发送数据速率给 接收方 发送数据。
注意：
- 发送方 ≠ 客户端；
- 接收方 ≠ 服务端；
因为 TCP 是全双工通信，双方可以进行双向通信，客户端和服务端既可能是发送端又可能是服务端。两端各有一个发送缓冲区与接收缓冲区，两端都各自维护一个发送窗口和一个接收窗口，接收窗口大小取决于应用、系统、硬件的限制（TCP 传输速率不能大于应用的数据处理速率）。
「流量控制」是避免「发送方」的数据填满「接收方」的缓存。
如果发送方发送消息是必须等到接收方回应数据已被接收到，再去发送下个消息，效率很低，为了解决这个问题，引入了滑动窗口的概念。
「窗口」是指无需等待确认应答，而可以继续发送数据的最大值。
通常窗口的大小是由接收方的窗口大小来决定的，发送端根据接收端的处理能力来发送数据。发送方 发送的数据大小不能超过 接收方 的窗口大小，否则接收方就无法正常接收到数据。
接收窗口的大小是约等于发送窗口的大小的，因为滑动窗口的大小会随着接收方的读取数据能力而变化。
发送方 的**「滑动窗口」**分为四个部分：
- 已经发送并且确认的 TCP 段（已经发送并确认）；
- 已经发送但是没有确认的 TCP 段（已经发送未确认）；
- 未发送但是接收方准备接收的 TCP 段（可以发送）；
- 未发送并且接收方也并未准备接受的 TCP 段（不可发送）；
接收方 的**「滑动窗口」**分为三个部分：
- 已经接收并且已经确认的 TCP 段（已经接收并确认）；
- 等待接收且允许发送方发送 TCP 段（可以接收未确认）；
- 不可接收且不允许发送方发送 TCP 段（不可接收）。
04、拥塞控制
在某段时间内，如果对网络中的某一资源请求超过了该资源所能提供的可用部分，网络的性能就要变坏，这种情况就叫拥塞。
「拥塞控制」是为了防止在网络出现拥堵时，继续发送大量的数据包，导致网络拥塞更加严重，避免「发送方」的数据填满整个网络。
为了在**「发送方」**调节所要发送数据的量，定义了「拥塞窗口」（cwnd）（是发送方维护的一个的状态变量），拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化：
- 只要网络中没有出现拥塞，拥塞窗口 就会增大；
- 但网络中出现了拥塞，拥塞窗口 就减少；
加入了拥塞窗口的概念后，此时发送窗口的值是 swnd = min(cwnd, rwnd)，是拥塞窗口和接收窗口中的最小值。
如果「发送方」在规定时间内没有接收到 ACK 应答报文（也就是发生了超时重传），就会认为出现了网络拥塞。
拥塞控制主要采用四种算法，当网络出现拥塞，会利用快重传和快恢复：
- 慢开始：
- 在建立完 TCP 连接后，不会一开始就发送大量的数据，而是由小到大逐渐增大发送拥塞窗口，初始
cwnd = 1； - 指数级增长；
- 当发送方每收到一个 ACK，拥塞窗口 cwnd 的大小就会加 1，当到达慢开始启动阈值（
ssthreh，slow start threshold）时，会停止继续增长；
- 在建立完 TCP 连接后，不会一开始就发送大量的数据，而是由小到大逐渐增大发送拥塞窗口，初始
- 拥塞避免：
- 当拥塞窗口
cwnd「超过」慢开始阈值ssthresh就会进入拥塞避免算法； - 线性增长；
- 每当收到一个 ACK 时，cwnd 增加 1/cwnd。
- 拥塞避免算法就是将原本慢启动算法的指数增长变成了线性增长，还是增长阶段，但是增长速度缓慢了一些。
- 当拥塞窗口
- 快重传：
- 当接收方发现丢了一个中间包的时候，发送三次前一个包的 ACK，于是发送端就会快速地重传，不必等待超时再重传。
- TCP 认为这种情况不严重，大部分数据都没有丢包，只丢了一小部分的数据，此时
cwnd = cwnd/2，也就是设置为原来的一半;ssthresh = cwnd;- 进入快速恢复算法
- 快恢复：
- 快速重传和快速恢复算法一般同时使用，拥塞窗口
cwnd = ssthresh + 3（ 3 的意思是确认有 3 个数据包被收到了）； - 重传丢失的数据包，如果再收到重复的 ACK，那么 cwnd 增加 1；
- 如果收到新数据的 ACK 后，把 cwnd 设置为第一步中的 ssthresh 的值，原因是该 ACK 确认了新的数据，说明从 duplicated ACK 时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态；
- 快速重传和快速恢复算法一般同时使用，拥塞窗口
快速恢复算法的变化过程如下图：
「」
四、IP
1、IP
01、基础
「IP」（Internet Protocol），是 TCP/IP 协议中最重要的协议之一，属于网络层的协议，主要作用是定义数据包的格式、对数据包进行路由和寻址，以便它们可以跨网络传播并到达正确的目的地。
互联网中每一个资源都由 IP 地址唯一标识。
目前 IP 协议主要分为两种，一种是过去的 IPv4，另一种是较新的 IPv6，目前这两种协议都在使用，但后者已经被提议来取代前者。
02、报文头部格式
在 IP 协议里面需要有源地址 IP 和 目标地址 IP：
- 源地址IP，即是客户端输出的 IP 地址；
- 目标地址，即通过 DNS 域名解析得到的 Web 服务器 IP。
因为 HTTP 是经过 TCP 传输的，所以在 IP 包头的协议号，要填写为 06（十六进制），表示协议为 TCP。
03、工作流程
每个连入互联网的设备或域（如计算机、服务器、路由器等）都被分配一个 IP 地址（Internet Protocol address），互联网中每一个资源都由 IP 地址唯一标识。
每个 IP 地址都是一个字符序列，如 192.168.1.1（IPv4）、2001:0db8:85a3:0000:0000:8a2e:0370:7334（IPv6） 。
当网络设备发送 IP 数据包时，数据包中包含了 源 IP 地址 和 目的 IP 地址 ：
- 「源 IP 地址」，用于标识数据包的发送方设备或域；
- 「目的 IP 地址」，则用于标识数据包的接收方设备或域。
网络设备根据目的 IP 地址来判断数据包的目的地，并将数据包转发到正确的目的地网络或子网络，从而实现了设备间的通信。
这种基于 IP 地址的寻址方式是互联网通信的基础，它允许数据包在不同的网络之间传递，从而实现了全球范围内的网络互联互通**。IP 地址的唯一性和全局性保证了网络中的每个设备都可以通过其独特的 IP 地址进行标识和寻址。**
2、ARP
01、MAC
「MAC」（Media Access Control Address），媒体访问控制地址，是指在网络中一切的物理设备由 MAC 地址唯一标识。
MAC 地址具有可携带性、永久性。
而 IP 地址不具有这些性质，当一台设备更换了网络，它的 IP 地址也就可能发生改变，也就是它在互联网中的定位发生了变化。
02、ARP 协议
「ARP 」（Address Resolution Protocol）协议，地址解析协议，目的是解决的是网络层地址和链路层地址之间的转换问题。
一个 IP 数据报在物理链路上的传输过程中，需要知道下一跳（物理上的下一个目的地）该去往何处，但 IP 地址属于逻辑地址，而 MAC 地址才是物理地址，ARP 协议解决了 IP 地址转 MAC 地址的一些问题。
03、工作原理
在一个局域网内，每个网络设备都自己维护了一个 「ARP表 」，ARP 表记录了某些其他网络设备的 IP 地址 和 MAC 地址映射关系，该映射关系以
- 其中，TTL 为该映射关系的生存周期，典型值为 20 分钟，超过该时间，该条目将被丢弃。
ARP 协议是一个广播问询，单播响应协议，工作流程如下：
- 假设主机 A，需要给主机 B 发送 IP 数据包。
- 首先，主机 A 检索自己的 ARP 表，判断 ARP 表中是否有主机 B 的 IP 地址对应的映射条目；
- 有，直接发送；
- 如果主机 A 检索自己的 ARP 表，发现 ARP 表中并无主机 B 的 IP 地址对应的映射条目，主机 A 将构造一个 ARP 查询分组，并将其广播到所在的局域网中。理论上，当前局域网中的每一个设备都会收到该分组，并检查查询分组的接收 IP 地址是否为自己的 IP 地址。
- 如果是，说明查询分组已经到达了主机 B，接着构造一个 ARP 响应分组，该分组的目的地只有一个，主机 A，发送给主机 A。
- 同时，主机 B 提取查询分组中的 IP 地址和 MAC 地址信息，在自己的 ARP 表中构造一条主机 A 的 IP-MAC 映射记录。
- 主机 A 终将收到主机 B 的响应分组，提取出该分组中的 IP 地址和 MAC 地址后，构造映射信息，加入到自己的 ARP 表中。
- 发送主机 A 和接收主机 B 不在同一个子网中，需要通过路由器联通。路由器作为互联设备，具有多个接口，每个接口都各自维护一个 ARP 表。
- 根据目的主机 B 的 IP 地址，分析出 B 所在的子网，找到能够把报文转发到 B 所在子网的那个路由器。
- 通过路由器进行 MAC 寻址。
总结
提示：这里对文章进行总结：