计算机网络必须掌握的核心知识讲解(三)

本人为了复习计网写了这篇文章,主要讲述我认为必须掌握,面试中高频考点,开发中必须熟悉的计网知识,物理层和数据链路层的某些重要一点的知识也会讲解,根据我个人的学习和开发经验.这篇文章讲解的传输层,应用层的核心知识,这部分的内容很重要,我认为应该对这篇文章的大致每一段话都能理解并且对于关键的知识点能复述个大概.不仅是对于计网的学习,针对前后端开发,在我看来也必须熟练掌握.网络层的知识比较多,将放在下一篇文章中讲解.从输入 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.HTTPHTTP报文包含请求报文和响应报文。请求报文请求行包含请求方法、请求目标URL或URI和HTTP协议版本。请求头包含关于请求的附加信息如Host、User-Agent、Content-Typeapplication/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 是 80https 默认是 443。解决HTTP的不安全问题HTTP 之所以不安全核心原因是其数据传输过程是明文的没有加密保护。对应的解决方案就是 HTTPS它相当于给 HTTP 加了一层「加密外衣」HTTPS 会用 SSL/TLS 协议对传输的数据进行加密数据在网络上传输时是「密文」状态黑客即使抓到数据包也无法看懂内容。HTTPS 有身份验证机制通过数字证书可以确认你访问的服务器是真实合法的避免被钓鱼网站欺骗。简单总结HTTP 是明文传输HTTPS 是加密传输,HTTP超文本传输协议和 HTTPS超文本传输安全协议的核心区别是 HTTPS 在 HTTP 基础上增加了 SSL/TLS 加密层解决了 HTTP 明文传输的安全隐患.HTTP、WebSocket 和 SSEHTTP超文本传输协议核心定位基于 TCP 的应用层协议是 Web 通信的基础标准。通信方向单向通信—— 只能由客户端主动发起请求服务器被动响应响应完成后连接立即断开HTTP/1.1 默认开启 Keep-Alive 可复用连接但通信模式仍是「请求 - 响应」。WebSocket全双工通信协议核心定位基于 TCP 的全双工通信协议专为解决 HTTP 单向通信的痛点设计。通信方向全双工通信—— 客户端和服务器建立连接后双方可同时双向发送数据无需等待对方的请求或响应。你使用在线聊天工具时:客户端发起 WebSocket 握手请求服务器响应后建立长连接你发送一条消息客户端通过 WebSocket 直接将数据推送给服务器服务器无需等待请求即可接收服务器收到消息后可立即推送给其他在线用户其他用户的客户端通过 onmessage 实时接收消息全程无需重复发起请求。SSEServer-Sent Events服务器推送事件核心定位基于 HTTP 的服务器向客户端单向推送技术属于 HTTP 协议的扩展。通信方向服务器单向推送—— 客户端发起一次 HTTP 请求后连接保持长开服务器可以持续向客户端推送数据客户端只能接收无法主动向服务器发送数据若需客户端发数据需额外发起 HTTP 请求。总结一下:HTTP在客户端和服务端建立起连接之后,只能单方面的由客户端向服务端发起请求,而webSocket则实现了客户端和服务端之间的双向通信,使得服务器可以主动推送消息给客户端,而SSE则是服务端推送消息给客户端,但是客户端无法发送消息给服务端.HTTP需要频繁的建立和销毁连接,有一定的开销,相比之下webSocket的开销更低,传统轮询需要客户端周期性向服务器发起请求可能产生大量无效请求。Webhook 则通过事件发生时由服务提供方主动调用接收方的 HTTP 接口避免了接收方不断轮询。可以去了解一下webhook.3.cookie session tokenHTTP的无状态性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比如 userzhangsan; is_logintrue把这个 Cookie 通过响应头下发给你的浏览器浏览器存在本地。后续访问服务器直接解析 Cookie 识别状态你访问网站的个人中心时浏览器自动把包含「用户名 登录状态」的 Cookie 发给服务器服务器不用查任何「状态列表」直接解密 / 解析 Cookie 里的内容就能确认「你是已登录的张三」然后显示你的个人中心数据。2. Session存储位置数据存储于服务器端可理解为服务器维护的一份「用户状态列表」。核心标识拥有唯一的识别符号 sessionId该 sessionId 通常被存放于 Cookie 中。工作逻辑服务器接收到客户端请求后先解析请求中的 Cookie 提取 sessionId再通过 sessionId 到「状态列表」中查找对应的 Session 数据。核心依赖依赖 Cookie 实现用户状态的关联。登录时服务器创建 Session 并下发 sessionId 到 Cookie你第一次登录某购物网站输入账号密码后服务器验证账号密码正确后为你创建专属的 Session 数据比如记录「用户 A 已登录」并生成唯一的 sessionId比如 123456服务器把这个 sessionId123456 写入你的浏览器 Cookie相当于给你一张编号 123456 的存包小票。后续访问服务器通过 Cookie 中的 sessionId 查找 Session 数据你接着访问该网站的个人中心页面时浏览器自动把包含 sessionId123456 的 Cookie 发给服务器服务器先解析 Cookie提取出 sessionId123456服务器用 123456 去自己的 Session 列表里查找到对应的 Session 数据「用户 A 已登录」基于这个数据服务器知道你是已登录的用户 A能正常显示你的个人中心数据。3. Token存储位置通常放在 Authorization 头中如 Authorization: Bearer token值。核心特性类似「令牌」具备无状态特性用户相关信息均被加密到 Token 中。工作逻辑服务器接收到 Token 后无需查询额外的状态列表仅通过解密 Token即可识别对应的用户。使用需要开发者手动将 Token 添加到请求中如请求头、参数等而非浏览器自动携带。你登录时服务器验证账号密码正确后把「用户 ID123、权限 普通用户」加密成 Token比如 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...服务器把这个 Token 返回给前端前端把它存到浏览器 LocalStorage 里。你访问个人中心时前端手动把 Token 放到请求头里发给服务器服务器解密 Token直接拿到「用户 ID123」不用查任何服务器存储就能返回该用户的个人数据。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.JWTJWT 令牌整体结构为 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 更适用于分布式系统能轻松实现服务扩展。传统认证方式基于 SessionCookie 实现服务器需要在本地维护 Session 列表存储用户状态客户端通过 Cookie 携带 sessionId 实现身份关联在分布式场景下需要额外做 Session 共享保证多服务节点的身份一致性。安全性JWT 令牌使用密钥对令牌进行签名处理能有效保证令牌的完整性和真实性。只有持有正确密钥的服务器才能对令牌进行验证和解析可有效防止令牌被篡改相比传统方式能更好地抵御 CSRF跨站请求伪造等攻击。(比如新闻报道某某公司的密钥泄露了...)传统认证方式依赖 Cookie 传递 sessionIdCookie 易被窃取或利用存在 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 包请求建立连接服务端收到后回复SYNACK 包表示同意连接并确认请求客户端再向服务端回复ACK 包完成最终确认双方确认彼此的发送和接收能力都正常后TCP 连接正式建立。详细流程客户端首先向服务端发送 SYN 包携带自己的初始序列号请求建立连接服务端收到后确认客户端发送能力正常回复一个 SYNACK 包其中 SYN 表示服务端也同意建立连接并携带自身初始序列号 ACK 表示已收到客户端的 SYN客户端收到 SYNACK 后确认服务端的发送和接收能力都正常再向服务端发送 ACK 包确认收到服务端的应答双方都进入连接已建立状态完成连接建立。为什么不能两次握手这是为了防止已失效的请求报文突然又传到服务器引发错误假设采取两次握手建立连接客户端向服务端发送一个SYN包来请求建立连接因为某些未知的原因并没有达到服务器在中间某个网络节点产生了滞留为了建立连接客户端会重发SYN包这次的数据包正常送达服务端回复SYNACK之后建立起了连接但是第一包阻塞的网络节点突然恢复第一包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 时总耗时为 1248163263秒约 1 分钟后客户端终止连接建立流程。服务器收到第一个 SYN 报文但在回复时 SYNACK 报文丢失当服务端回复的 SYNACK 报文丢失时客户端和服务端会分别触发超时重传机制具体过程如下客户端发送 SYN 包后如果在超时时间内没有收到服务端的 SYNACK会进行重传当重传次数达到 tcp_syn_retries 的上限仍未收到应答客户端会超时关闭连接。服务端发送 SYNACK 包后如果在超时时间内没有收到客户端的 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最大分段大小开始每收到一个对新报文段的确认ACKcwnd 就增加 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数据上报部分传感器定期上报数据的场景中丢失个别数据点不会影响整体趋势分析