)
本人为了复习计网写了这篇文章,主要讲述我认为必须掌握,面试中高频考点,开发中必须熟悉的计网知识,物理层和数据链路层的某些重要一点的知识也会讲解,根据我个人的学习和开发经验.
这篇文章讲解的传输层,应用层的核心知识,这部分的内容很重要,我认为应该对这篇文章的大致每一段话都能理解并且对于关键的知识点能复述个大概.不仅是对于计网的学习,针对前后端开发,在我看来也必须熟练掌握.网络层的知识比较多,将放在下一篇文章中讲解.
从输入 URL 到页面展示，到底发生了什么？
这道题几乎是计算机网络面试的必考题，一道题就能考察你对DNS 域名解析、TCP/IP 协议、HTTP/HTTPS、网络层、应用层等整个网络体系的理解。
总体来说，整个过程可以分为这几个关键步骤：
在浏览器中输入指定网页的 URL。
浏览器通过 DNS 协议，获取域名对应的 IP 地址。
浏览器根据 IP 地址和端口号，向目标服务器发起一个 TCP 连接请求。
浏览器在 TCP 连接上，向服务器发送一个 HTTP 请求报文，请求获取网页的内容。
服务器收到 HTTP 请求报文后，处理请求，并返回 HTTP 响应报文给浏览器。
浏览器接收响应报文，解析 HTML、CSS、JS，进行页面渲染；同时根据页面中的图片、样式、脚本等资源 URL，继续发起请求，直到页面完整显示。
浏览器在不需要和服务器通信时，可以主动关闭 TCP 连接，或者等待服务器的关闭请求。
一.应用层
1.DNS(域名系统)
DNS就是把域名转化成对于IP地址的协议,因为我们更容易记住域名而不是Ip地址,比如我们记住的是www.baidu.com而不是百度的ip地址,而且域名可以屏蔽底层复杂的地址,域名背后的IP更换,只要域名不换,也可以访问到目标服务器,对于用户这边是没有感知的,一个域名还可以解析到多个IP,实现负载均衡.你的电脑先查本地缓存，有没有记住这个域名对应的 IP。如果没有，就去问本地 DNS 服务器（比如运营商提供的 DNS）。本地 DNS 没有的话，会逐级去问根服务器、顶级域名服务器、权威 DNS 服务器。最终查到 IP 地址，返回给你的电脑。你的电脑拿到 IP，才真正开始和服务器通信。
本地域名服务器(比如学校可以配置一台本地域名服务器,缓存最近查询的域名到ip地址的映射,可以缓解顶级域名服务器,根服务器之间的压力,提高查询效率)
DNS的底层协议
DNS 基于UDP协议实现，DNS使用UDP协议进行域名解析和数据传输。因为基于UDP实现DNS能够提供低延迟、简单快速、轻量级的特性，更适合DNS这种需要快速响应的域名解析服务。
低延迟： UDP是一种无连接的协议，不需要在数据传输前建立连接，因此可以减少传输时延，适合DNS这种需要快速响应的应用场景。
简单快速： UDP相比于TCP更简单，没有TCP的连接管理和流量控制机制，传输效率更高，适合DNS这种需要快速传输数据的场景。
轻量级：UDP头部较小，占用较少的网络资源，对于小型请求和响应来说更加轻量级，适合DNS这种频繁且短小的数据交换。
尽管 UDP 存在丢包和数据包损坏的风险，但在 DNS 的设计中，这些风险是可以被容忍的。DNS 使用了一些机制来提高可靠性，例如查询超时重传、请求重试、缓存等，以确保数据传输的可靠性和正确性。
2.HTTP
HTTP报文包含请求报文和响应报文。
请求报文：
请求行：包含请求方法、请求目标（URL或URI）和HTTP协议版本。
请求头：包含关于请求的附加信息，如Host、User-Agent、Content-Type（application/json）等。
空行：请求头部和请求体之间用空行分隔。
请求体：可选，包含请求的数据，通常用于POST请求等需要传输数据的情况。
响应报文：
状态行：包含HTTP协议版本、状态码和状态信息。
响应头部：包含关于响应的附加信息，如Content-Type、Content-Length等。
空行：响应头部和响应体之间用空行分隔。
响应体：包含响应的数据，通常是服务器返回的HTML、JSON等内容。
HTTP状态码
其中常见的具体状态码有：
200 OK：请求成功，服务器正常处理并返回数据。
301 Moved Permanently：永久重定向（资源永久迁移，浏览器会记住新地址）
302 Found：临时重定向（资源临时迁移，本次跳转不永久记录）
400 Bad Request：客户端发送的请求报文格式或参数有误，导致服务器无法解析。
404 Not Found：请求资源不存在，服务器无法找到对应内容。
405 Method Not Allowed：请求方法不被支持（你用的GET方法，服务器端的目标接口是POST，不支持）
500 Internal Server Error：服务器内部出错（服务器正常接收请求，但处理时出现错误）。
HTTP的301与302状态码
3xx 类状态码表示客户端请求的资源发生了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是重定向。
「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。
「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。
301 和 302 都会在响应头里使用字段 Location，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。
HTTP层常见的请求类型
GET：用于请求获取指定资源，通常用于获取数据。
POST：用于向服务器提交数据，通常用于提交表单数据或进行资源的创建。
PUT：用于向服务器更新指定资源，通常用于更新已存在的资源。
DELETE：用于请求服务器删除指定资源。
HEAD：类似于GET请求，但只返回资源的头部信息，用于获取资源的元数据而不获取实际内容。
HTTP的短链接和长连接
客户端每一次向服务器请求资源,都必须先建立TCP连接,再按照HTTP请求报文的方式发送请求,服务器接收请求后响应,经过浏览器的渲染之后就能查看对应的网页了,最后释放连接.HTTP 的 Keep-Alive 特性支持使用同一个 TCP 连接发送和接收多个 HTTP 请求与应答，避免重复建立和释放连接的开销，这种方式称为 HTTP 长连接。HTTP 长连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。
HTTP默认的端口
http 是 80，https 默认是 443。
解决HTTP的不安全问题
HTTP 之所以不安全，核心原因是其数据传输过程是明文的，没有加密保护。
对应的解决方案就是 HTTPS，它相当于给 HTTP 加了一层「加密外衣」：
HTTPS 会用 SSL/TLS 协议对传输的数据进行加密，数据在网络上传输时是「密文」状态，黑客即使抓到数据包，也无法看懂内容。
HTTPS 有身份验证机制（通过数字证书），可以确认你访问的服务器是真实合法的，避免被钓鱼网站欺骗。
简单总结：HTTP 是明文传输，HTTPS 是加密传输,HTTP（超文本传输协议）和 HTTPS（超文本传输安全协议）的核心区别是 HTTPS 在 HTTP 基础上增加了 SSL/TLS 加密层，解决了 HTTP 明文传输的安全隐患.
HTTP、WebSocket 和 SSE
HTTP（超文本传输协议）
核心定位：基于 TCP 的应用层协议，是 Web 通信的基础标准。
通信方向：单向通信—— 只能由客户端主动发起请求，服务器被动响应，响应完成后连接立即断开（HTTP/1.1 默认开启 Keep-Alive 可复用连接，但通信模式仍是「请求 - 响应」）。
WebSocket（全双工通信协议）
核心定位：基于 TCP 的全双工通信协议，专为解决 HTTP 单向通信的痛点设计。
通信方向：全双工通信—— 客户端和服务器建立连接后，双方可同时双向发送数据，无需等待对方的请求或响应。
你使用在线聊天工具时:
客户端发起 WebSocket 握手请求，服务器响应后建立长连接；
你发送一条消息，客户端通过 WebSocket 直接将数据推送给服务器，服务器无需等待请求即可接收；
服务器收到消息后，可立即推送给其他在线用户，其他用户的客户端通过 onmessage 实时接收消息，全程无需重复发起请求。
SSE（Server-Sent Events，服务器推送事件）
核心定位：基于 HTTP 的服务器向客户端单向推送技术，属于 HTTP 协议的扩展。
通信方向：服务器单向推送—— 客户端发起一次 HTTP 请求后，连接保持长开，服务器可以持续向客户端推送数据，客户端只能接收，无法主动向服务器发送数据（若需客户端发数据，需额外发起 HTTP 请求）。
总结一下:HTTP在客户端和服务端建立起连接之后,只能单方面的由客户端向服务端发起请求,而webSocket则实现了客户端和服务端之间的双向通信,使得服务器可以主动推送消息给客户端,而SSE则是服务端推送消息给客户端,但是客户端无法发送消息给服务端.HTTP需要频繁的建立和销毁连接,有一定的开销,相比之下webSocket的开销更低,传统轮询需要客户端周期性向服务器发起请求，可能产生大量无效请求。Webhook 则通过事件发生时由服务提供方主动调用接收方的 HTTP 接口，避免了接收方不断轮询。可以去了解一下webhook.
3.cookie session token
HTTP的无状态性
HTTP是无状态的，这意味着每个请求都是独立的，服务器不会在多个请求之间保留关于客户端状态的信息。在每个HTTP请求中，服务器不会记住之前的请求或会话状态，因此每个请求都是相互独立的。
虽然HTTP本身是无状态的，但可以通过一些机制来实现状态保持，其中最常见的方式是使用 Cookie和Session 来跟踪用户状态。通过在客户端存储会话信息或状态信息，服务器可以识别和跟踪特定用户的状态，以提供一定程度的状态保持功能。
为什么 HTTP 协议本身仍被定义为「无状态」
HTTP 被称为无状态协议，核心原因在于协议的设计初衷和底层机制本身不保存客户端的状态信息，具体如下：
请求的独立性：每个 HTTP请求都是完全独立的，服务端在处理请求时，不会主动保存上一次请求的任何信息。即使是同一个客户端的连续请求，服务端也不会默认关联它们的关系。
Cookie 是「补充机制」而非协议固有属性：虽然 Cookie 属于 HTTP 协议簇的一部分，但它只是在无状态协议基础上，实现状态保持的一种额外手段：状态信息并未存储在服务端或协议本身，而是存储在客户端；服务端需要依赖客户端主动携带的 Cookie 才能识别状态，而非协议自身具备记忆能力。
无状态设计的初衷这种无状态的设计让 HTTP 协议更简单、易于规模化扩展，服务端无需为每个客户端维护会话状态，降低了资源消耗。
Session、Cookie、Token 均是 Web 开发中用于跟踪用户状态的核心机制，三者的核心区别围绕存储位置、工作逻辑、状态特性、使用方式展开：
1. Cookie
存储位置：数据存储于客户端（浏览器）。
核心作用：类似「令牌」，主要用来装载 sessionId。
使用方式：浏览器在向服务器发送请求时，会自动将对应域名下的 Cookie 附加到请求中，无需开发者手动操作。
登录时：服务器直接把用户信息写入 Cookie
你输入账号密码登录网站，服务器验证通过后：
不生成 sessionId，也不创建 Session 数据；
把你的「用户名、登录状态、权限等级」等信息加密（避免被篡改），直接写入 Cookie（比如 user=zhangsan; is_login=true）；
把这个 Cookie 通过响应头下发给你的浏览器，浏览器存在本地。
后续访问：服务器直接解析 Cookie 识别状态
你访问网站的个人中心时：
浏览器自动把包含「用户名 + 登录状态」的 Cookie 发给服务器；
服务器不用查任何「状态列表」，直接解密 / 解析 Cookie 里的内容，就能确认「你是已登录的张三」，然后显示你的个人中心数据。
2. Session
存储位置：数据存储于服务器端，可理解为服务器维护的一份「用户状态列表」。
核心标识：拥有唯一的识别符号 sessionId，该 sessionId 通常被存放于 Cookie 中。
工作逻辑：服务器接收到客户端请求后，先解析请求中的 Cookie 提取 sessionId，再通过 sessionId 到「状态列表」中查找对应的 Session 数据。
核心依赖：依赖 Cookie 实现用户状态的关联。
登录时：服务器创建 Session 并下发 sessionId 到 Cookie
你第一次登录某购物网站，输入账号密码后：
服务器验证账号密码正确后，为你创建专属的 Session 数据（比如记录「用户 A 已登录」），并生成唯一的 sessionId（比如 123456）；
服务器把这个 sessionId=123456 写入你的浏览器 Cookie（相当于给你一张编号 123456 的存包小票）。
后续访问：服务器通过 Cookie 中的 sessionId 查找 Session 数据
你接着访问该网站的个人中心页面时：
浏览器自动把包含 sessionId=123456 的 Cookie 发给服务器；
服务器先解析 Cookie，提取出 sessionId=123456；
服务器用 123456 去自己的 Session 列表里查，找到对应的 Session 数据「用户 A 已登录」；
基于这个数据，服务器知道你是已登录的用户 A，能正常显示你的个人中心数据。
3. Token
存储位置：通常放在 Authorization 头中，如 Authorization: Bearer <token值>。
核心特性：类似「令牌」，具备无状态特性，用户相关信息均被加密到 Token 中。
工作逻辑：服务器接收到 Token 后，无需查询额外的状态列表，仅通过解密 Token即可识别对应的用户。
使用：需要开发者手动将 Token 添加到请求中（如请求头、参数等），而非浏览器自动携带。
你登录时：
服务器验证账号密码正确后，把「用户 ID=123、权限 = 普通用户」加密成 Token（比如 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...）；
服务器把这个 Token 返回给前端，前端把它存到浏览器 LocalStorage 里。
你访问个人中心时：
前端手动把 Token 放到请求头里发给服务器；
服务器解密 Token，直接拿到「用户 ID=123」，不用查任何服务器存储，就能返回该用户的个人数据。
Cookie和Session的区别
Cookie 和 Session 均是 Web 开发中用于跟踪用户状态的核心技术，但二者在存储位置、数据容量、安全性、生命周期、性能等维度存在显著差异：
1. 存储位置
Cookie：数据存储在客户端（浏览器），浏览器向服务器发送请求时，会自动携带对应域名下的 Cookie 数据。
Session：数据存储在服务器端，服务器为每个用户分配唯一的 Session ID，该 ID 通常通过 Cookie 或 URL 重写方式发送至客户端；客户端后续请求会携带此 ID，服务器据此查找对应的 Session 数据。（Set-Cookie 响应头）
2. 数据容量
Cookie：单个 Cookie 大小通常限制在 4KB 左右，且多数浏览器对每个域名的总 Cookie 数量也有明确限制。
Session：数据存储在服务器，理论上无数据大小限制，仅受服务器内存容量的约束。
3. 安全性
Cookie：安全性较低，因数据存储在客户端，易遭受 XSS（跨站脚本攻击）；虽可通过设置 HttpOnly 属性阻止 JavaScript 访问以降低 XSS 风险，但仍可能面临 CSRF攻击。
Session：安全性更高，敏感数据存储在服务器端；但需防范 Session 劫持。
4. 生命周期
Cookie：可手动设置过期时间，到期后自动删除；也可设为会话 Cookie，浏览器关闭时即删除。
Session：默认情况下，用户关闭浏览器后 Session 结束；服务器也可设置 Session 超时时间，超过该时间无用户活动则 Session 失效。
session依赖于cookie实现,Session 的正常工作依赖 sessionId 在客户端与服务器之间的传递，而默认情况下 sessionId 是通过 Cookie 承载的.
4.JWT
JWT 令牌整体结构为 Header.Payload.Signature，由头部、载荷、签名三部分组成，三部分之间用英文句点 . 分隔，具体细节如下：
1. 头部（Header）
暂时无法在飞书文档外展示此内容
格式：JSON 格式数据。
作用：主要声明 JWT 的加密算法和令牌类型。
处理方式：使用 Base64 编码进行序列化，生成字符串作为 JWT 的第一部分。
示例（JSON 原始内容）：
2.载荷（Payload）
格式：JSON 格式数据。
作用：存放需要传递的核心信息，包括标准声明字段和自定义字段。
处理方式：同样使用 Base64 编码进行序列化，生成字符串作为 JWT 的第二部分。
注意：Base64 是可逆编码，而非加密，因此载荷中不建议存放敏感信息。
示例（JSON 原始内容）：
3. 签名（Signature）
作用：验证 JWT 的完整性和真实性，防止令牌被篡改。
生成方式：将编码后的头部、编码后的载荷用句点拼接，再结合密钥，按照头部声明的加密算法进行签名计算，最终生成的字符串作为 JWT 的第三部分。
核心逻辑（以 HS256 算法为例）：
JWT 令牌的优点
无状态性：
JWT 令牌：具备无状态特性，服务器端无需存储任何会话信息。用户身份、权限等所有必要数据，均被加密封装在 JWT 令牌本身中；服务器接收到令牌后，只需通过密钥解密验证，即可获取用户信息，无需查询服务器本地的会话列表。这种特性让 JWT 更适用于分布式系统，能轻松实现服务扩展。
传统认证方式：基于 Session+Cookie 实现，服务器需要在本地维护 Session 列表存储用户状态，客户端通过 Cookie 携带 sessionId 实现身份关联；在分布式场景下，需要额外做 Session 共享保证多服务节点的身份一致性。
安全性：
JWT 令牌：使用密钥对令牌进行签名处理，能有效保证令牌的完整性和真实性。只有持有正确密钥的服务器，才能对令牌进行验证和解析，可有效防止令牌被篡改；相比传统方式，能更好地抵御 CSRF（跨站请求伪造）等攻击。(比如新闻报道某某公司的密钥泄露了...)
传统认证方式：依赖 Cookie 传递 sessionId，Cookie 易被窃取或利用，存在 CSRF 攻击风险；且 Session 数据存储在服务器端，一旦服务器被入侵，可能导致大量用户会话信息泄露。
跨域支持
JWT 令牌：天然支持跨域访问场景。JWT 令牌可通过 HTTP 请求头（如 Authorization）或请求参数携带，能轻松实现跨域身份验证。
传统认证方式：基于 Cookie 传递 sessionId，受同源策略约束，配置复杂且存在安全风险。
JWT的缺点
JWT 存在一个核心问题：令牌一旦发放，在过期前无法被即时撤销，仍保持有效性。
解决该问题的核心方案是在业务层补充校验逻辑，最常用的是黑名单机制：
借助 Redis 等内存数据库维护 JWT 黑名单；
若需让某个 JWT 立即失效，将其加入该黑名单；
每次接收到 JWT 请求时，先校验令牌是否在黑名单中，若在则拒绝请求，以此实现 JWT 的即时撤销。
二.传输层-TCP (传输控制协议)
TCP（传输控制协议），是一种面向连接、可靠、基于字节流的传输层协议。它的作用就是在不可靠的网络上，通过序号、确认应答、超时重传、校验和、按序交付机制，保证数据不丢失、不出错、不重复、按顺序从发送方传送到接收方。你可以把它理解成：两个人打电话，必须先拨通（建立连接），说话要对方听清才会继续，挂电话也要礼貌道别，全程保证每句话都完整传达。
为什么要用 TCP？
保证数据可靠：网络本身会丢包、乱序，TCP 能自动修复这些问题，适合必须完整传输的场景。
面向连接：通信前先建立连接，通信后正常断开，更稳定、更安全。
流量控制与拥塞控制：防止发送方发太快把接收方或网络冲垮，让传输更平稳。
全双工通信：双方可以同时发送和接收数据，效率更高。
控制位：
ACK：该位为1时，「确认号」的字段变为有效，TCP规定除最初建立连接时的 SYN 包之外该位必须置为 1 。
RST：该位为 1 时，表示 TCP 连接中出现异常必须强制断开连接。
SYN：该位为 1 时，表示希望建立连接，并在其「序列号」的字段进行序列号初始值的设定。
FIN：该位为 1 时，表示今后不会再有数据发送，希望断开连接。当通信结束希望断开连接时，通信双方的主机之间就可以相互交换 FIN 位为 1 的 TCP 段。
TCP的三次握手
TCP 是面向连接的协议，所以使用TCP前须先建立连接，而建立连接是通过三次握手来进行的.
流程：客户端先向服务端发送SYN 包请求建立连接，服务端收到后回复SYN+ACK 包表示同意连接并确认请求，客户端再向服务端回复ACK 包完成最终确认，双方确认彼此的发送和接收能力都正常后，TCP 连接正式建立。
详细流程：客户端首先向服务端发送 SYN 包，携带自己的初始序列号，请求建立连接；服务端收到后，确认客户端发送能力正常，回复一个 SYN+ACK 包，其中 SYN 表示服务端也同意建立连接并携带自身初始序列号， ACK 表示已收到客户端的 SYN；客户端收到 SYN+ACK 后，确认服务端的发送和接收能力都正常，再向服务端发送 ACK 包确认收到服务端的应答，双方都进入连接已建立状态，完成连接建立。
为什么不能两次握手？
这是为了防止已失效的请求报文，突然又传到服务器，引发错误
假设采取两次握手建立连接，客户端向服务端发送一个SYN包，来请求建立连接，因为某些未知的原因，并没有达到服务器，在中间某个网络节点产生了滞留，为了建立连接，客户端会重发SYN包，这次的数据包正常送达，服务端回复SYN+ACK之后，建立起了连接，但是第一包阻塞的网络节点突然恢复，第一包SYN包又送达到服务端，这时服务端会误认为是客户端又发起了一个新连接，从而在两次握手之后，进入数据等待状态，服务端认为是两个连接，而客户端认为是一个连接，造成了状态不一致，如果在三次握手的情况下，服务端收不到最后的ACK包，自然不会认为连接建立成功，所以，三次握手本质上来说，就是为了解决网络信道不可靠问题，为了能在不可靠的信道上，建立可靠的连接。
TCP四次挥手
处于连接状态的客户端和服务端，都可以发起关闭连接的请求，此时需要四次挥手来请求连接关闭。
第一次挥手：假设客户端主动发起连接关闭请求，它需要向服务端发起一个FIN包，表示要关闭连接，自己进入终止等待一状态（FIN-WAIT-1）。
第二次挥手：服务端收到FIN包，发送一包ACK包，表示自己进入了关闭等待状态（CLOZE-WAIT），客户端进入终止等待二状态（FIN-WAIT-2）；
第三次挥手：此时，服务端后还可以发送未发送的数据，而客户端还可以接收数据，待服务端发送完数据之后，发送一包FIN包，进入最后确认状态（LAST-ACK）。
第四次挥手：客户端收到之后，回复ACK包，进入超时等待状态（TIME-WAIT），经过超时时间后关闭连接，而服务端收到ACK包后，立即关闭连接。
为什么需要第四次挥手？/ 为什么不能是三次挥手？
这是为了保证对方已经收到ACK包。因为假设客户端发送完最后一包ACK包之后就释放了连接，一旦ACK包在网络中丢失，服务端将一直停留在最后确认阶段；如果客户端发送最后一包ACK包后，等待一段时间，这时服务端因为没有收到ACK包，会重发FIN包，客户端会响应这个FIN包，重发ACK包并刷新超时时间。
这个机制和第三次握手一样，也是为了保证在不可靠的网络链路中，进行可靠的连接断开确认。
超时重传机制
服务器没有收到客户端发送的第一个 SYN 报文
当客户端发送的第一个 SYN 报文丢失，服务器未收到时，客户端会触发超时重传机制，具体过程如下：
客户端发送 SYN 报文后，进入 SYN_SENT 状态，等待服务端回复 SYN-ACK 报文；
若客户端迟迟收不到服务端的第二次握手报文，会判定 SYN 报文可能丢失，触发超时重传，且重传的 SYN 报文序列号保持一致；
SYN 报文的最大重传次数由内核参数 tcp_syn_retries 控制（默认值为 5）；
重传的超时时间采用指数退避策略：第一次超时重传间隔通常为 1 秒，第二次为 2 秒，以此类推，每次超时时间都是上一次的 2 倍；
当客户端达到tcp_syn_retries设定的最大重传次数后，会再等待一段超时时间（最后一次间隔的 2 倍），若仍未收到 SYN-ACK 报文，客户端就会断开连接。例如默认最大重传次数为 5 时，总耗时为 1+2+4+8+16+32=63秒，约 1 分钟后客户端终止连接建立流程。
服务器收到第一个 SYN 报文，但在回复时 SYN+ACK 报文丢失
当服务端回复的 SYN+ACK 报文丢失时，客户端和服务端会分别触发超时重传机制，具体过程如下：
客户端发送 SYN 包后，如果在超时时间内没有收到服务端的 SYN+ACK，会进行重传；当重传次数达到 tcp_syn_retries 的上限仍未收到应答，客户端会超时关闭连接。
服务端发送 SYN+ACK 包后，如果在超时时间内没有收到客户端的 ACK，同样会进行重传；当重传次数达到 tcp_synack_retries 的上限仍未收到应答，服务端也会超时关闭连接。
TCP 保证传输的可靠性
TCP 作为面向连接的可靠传输协议，核心通过连接管理、序列号与确认应答、重传机制、流量控制、拥塞控制等一系列机制，确保数据无丢失、无重复、无出错、有序地交付，具体实现如下：
1.可靠的连接管理：基于三次握手建立连接，确保客户端和服务端双向确认 "收发能力正常"；通过四次挥手关闭连接，保证双方数据都传输完毕后再断开，为可靠传输奠定基础。
2.序列号与确认应答机制：TCP 会给发送的每个字节数据都分配唯一序列号，接收方收到数据后，会基于序列号对数据包排序重组，并丢弃重复的数据包；同时接收方会回复 ACK 确认报文，告知发送方 "已正确收到某序列号之前的所有数据"，明确数据传输的边界。
3.多重重传机制：针对数据包丢失或延迟的情况，TCP 会触发重传
超时重传：发送方启动计时器，若超时未收到 ACK，自动重传对应数据包。
快速重传：当接收方收到失序数据包时，会连续发送重复的 ACK；发送方收到 3 个冗余重复 ACK 后，无需等待计时器超时，立即重传丢失的数据段。
SACK：接收方告知发送方已收到的数据区间，让发送方只重传真正丢失的数据段，提高传输效率。
D-SACK：额外告知发送方哪些数据被重复接收，避免不必要的重传。
4.校验校验和：发送方会对 TCP 报文的首部和数据部分计算一个校验和；接收方收到报文后，也用相同方法重新计算校验和，并与报文中携带的校验和进行对比校验。如果两者不一致，说明数据在传输过程中被篡改或损坏，接收方会直接丢弃该报文，且不回复 ACK，最终触发发送方的超时重传。
5. 流量控制：接收方通过滑动窗口机制，告知发送方自己的缓冲区剩余容量（窗口大小），发送方只能发送窗口大小以内的数据，避免因发送速度过快导致接收方缓冲区溢出而丢包，匹配收发双方的处理能力。
6.拥塞控制：发送方维护拥塞窗口，通过慢开始、拥塞避免、快重传、快恢复四个阶段，感知网络拥塞状态，动态调整发送速率，避免因发送过量数据加剧网络拥堵，从全局层面保障传输可靠性。
TCP 拥塞控制是一种端到端的网络流量调节机制，它通过动态调整发送方的拥塞窗口（cwnd），来避免发送数据过快导致网络路由器缓存溢出、丢包和整体性能下降。你可以把它理解成：在一条双向车道的公路上，交警（拥塞控制算法）会根据车流密度（网络状况）动态调整车辆放行速度，防止整条路被堵死，保证整体通行效率。
慢开始（Slow Start）
慢开始是 TCP 拥塞控制的初始阶段，它的核心思想是从一个很小的速率开始，快速探测网络的承载能力。
核心机制：拥塞窗口 cwnd 从 1 个 MSS（最大分段大小）开始，每收到一个对新报文段的确认（ACK），cwnd 就增加 1 个 MSS。这意味着，在每个往返时间（RTT）内，cwnd 的大小会指数级增长。
触发条件：当 cwnd 小于慢开始门限 ssthresh 时，TCP 处于慢开始阶段。
终止条件：当 cwnd 增长到 ≥ ssthresh，或者检测到网络拥塞（如超时丢包）时，慢开始阶段结束。
拥塞避免（Congestion Avoidance）
拥塞避免是在慢开始之后的阶段，核心思想是缓慢、线性地增加发送速率，以接近但不超过网络的最大承载能力。
核心机制：当 cwnd 大于等于 ssthresh 时，TCP 进入拥塞避免阶段。此时，即使收到多个 ACK，在一个 RTT 内 cwnd 也只增加 1 个 MSS，使 cwnd 呈线性增长。
触发条件：当 cwnd ≥ ssthresh 时，TCP 从慢开始切换到拥塞避免。
终止条件：当检测到网络拥塞（如超时丢包或收到 3 个重复 ACK）时，拥塞避免阶段结束。
慢开始与拥塞避免的典型工作过程
初始阶段（慢开始）：连接建立后，cwnd 从 1 开始，每收到一个 ACK 就加 1，呈指数增长。当 cwnd 达到初始的慢开始门限 ssthresh = 16 时，切换到拥塞避免。
拥塞避免阶段：cwnd 开始线性增长，每经过一个 RTT 增加 1，缓慢逼近网络极限。
网络拥塞：当 cwnd 增长到 24 时，网络发生拥塞（如超时丢包）。
响应拥塞：TCP 执行 "乘法减小"，将新ssthresh 设置为当前 cwnd 的一半（即 12），并将 cwnd 重置为 1，重新进入慢开始阶段。
恢复阶段：cwnd 再次从 1 开始指数增长，当达到新的 ssthresh = 12 时，再次切换到拥塞避免，线性增加发送速率。
一句话总结：TCP 拥塞控制通过慢开始快速探测网络能力，再通过拥塞避免线性逼近带宽极限，一旦检测到拥塞就主动降速，从而在保证网络稳定的前提下最大化传输效率。
三.传输层-UDP(用户数据报协议)
UDP（用户数据报协议），是一种无连接、不可靠、面向数据报的传输层协议。它的作用是在网络上以最小开销、低延迟传递数据，不保证送达、不保证有序，丢包与重传由应用层自行处理。
你可以把它理解成：两个人发微信语音条，不用先拨通等待对方接听，直接发过去就行，对方没听到也不会自动重发，适合追求快、偶尔漏一句也能接受的场景。
为什么要用 UDP？
极致低延迟：无握手、无确认、无拥塞控制，数据直达，适合直播、在线游戏等对实时性要求极高的场景。
头部开销小：仅 8 字节（源端口、目的端口、长度、校验和），远小于 TCP 至少 20 字节，传输效率更高。
面向数据报：保留应用层消息边界，发一个包收一个包，无需拼接拆分，适合短报文交互。
支持多播 / 广播：可向多个接收者同时发送，适合流媒体组播、局域网设备发现等场景。
UDP 的核心原理
无连接通信：发送前无需建立连接，发送后无需挥手断开；想发就发，接收方随时接收，省去连接开销。
不可靠传输机制：
给数据加简单头部，仅用校验和检测数据损坏，不修复。
不编号、不排序，接收方可能乱序收到或收不到，发送方不重传。
无流量控制与拥塞控制，网络拥塞时仍按原速率发送，避免延迟但可能加剧拥塞。
端口与数据交付：通过源端口标识发送应用，目的端口标识接收应用；将应用层数据封装成数据报，交给 IP 层发送，接收方根据端口交付给对应应用。
TCP和UDP的区别
1.是否面向连接：
TCP 是面向连接的。在传输数据之前，必须先通过 "三次握手" 建立连接；数据传输完成后，还需要通过 "四次挥手" 来释放连接。这保证了双方都准备好通信。
UDP 是无连接的。发送数据前不需要建立任何连接，直接把数据包（数据报）扔出去。
2.是否是可靠传输：
TCP 提供可靠的数据传输服务。它通过序列号、确认应答 (ACK)、超时重传、流量控制、拥塞控制等一系列机制，来确保数据能够无差错、不丢失、不重复且按顺序地到达目的地。
UDP 提供不可靠的传输。它尽最大努力交付，但不保证数据一定能到达，也不保证到达的顺序，更不会自动重传，收到报文后，接收方也不会主动发确认。
3.是否有状态：
TCP 是有状态的。为了保证可靠传输，TCP 通信双方需要持续维护连接状态，包括序号、确认号、窗口大小、发送和接收进度等信息。
UDP 是无状态的。UDP 不需要建立连接，也不维护任何传输状态，发送数据后不关心是否到达、是否丢失，因此协议开销更小。
4.传输效率：
TCP 因为需要建立连接、发送确认、处理重传等，其开销较大，传输效率相对较低。
UDP 结构简单，没有复杂的控制机制，开销小，传输效率更高，速度更快。
5.传输形式：
TCP 是面向字节流的。它将应用程序交付的数据视为一连串无结构的字节流，会对数据进行拆分或合并。
UDP 是面向报文的。UDP 会原样发送应用程序交给它的数据块，既不拆分也不合并，完整保留应用层的消息边界。
TCP与UDP的应用场景
选择 TCP 还是 UDP，核心判断依据是应用对数据传输的可靠性要求，以及对实时性、传输效率的优先级需求。
一、 选择 TCP 的场景
当数据准确性和完整性至关重要，不允许任何丢失或错序时，优先选择 TCP。TCP 具备三次握手、确认应答、超时重传、流量控制等机制，可保障数据可靠、有序地送达。典型应用场景：
Web 浏览（HTTP/HTTPS）：网页内容、图片、脚本需完整加载才能正常显示
文件传输（FTP、SCP）：文件内容不允许出现字节丢失或顺序错乱
邮件收发（SMTP、POP3、IMAP）：邮件内容需要完整无误地传递
远程登录（SSH、Telnet）：命令与响应的传输必须准确无误
二、 选择 UDP 的场景
当实时性、传输速度和效率优先，且应用可以容忍少量数据丢失或乱序时，优先选择 UDP。UDP 无需建立连接，没有复杂的可靠性保障机制，传输开销小、速度快。典型应用场景：
实时音视频通信（视频会议、直播）：偶尔丢失少量数据包仅会造成短暂卡顿，远优于 TCP 重传机制导致的长时间延迟，部分场景下应用层会自带补偿机制
在线游戏：需快速传输玩家位置、状态等信息，对实时性要求极高，旧数据无重传价值，少量数据丢失对游戏体验影响较小
DHCP（动态主机配置协议）：客户端请求 IP 时自身无 IP 地址，无法满足 TCP 建立连接的前提；同时 DHCP 支持广播、交互逻辑简单，且自带可靠性保障机制
物联网（IoT）数据上报：部分传感器定期上报数据的场景中，丢失个别数据点不会影响整体趋势分析
