计算机网络

ccc_0
196 阅读32分钟

参考

  1. (46条消息) 大厂常问：输入URL到显示页面的全过程（敲详细）_七钥的博客-CSDN博客
  2. juejin.cn/post/720654…
  3. 浏览器输入一个url到整个页面显示出来经历了哪些过程？ - 一粒一世界 - 博客园 (cnblogs.com)
  4. (49条消息) TCP/IP协议栈详细解释 小小白都能看懂！（强烈推荐）_协议栈的通俗解释_Moriartly的博客-CSDN博客

TCP/IP参考模型

TCP/IP协议最早得名是因为两个最重要最先被提出的协议，TCP 和 IP，后来，互联网通信的各类协议（HTTP、IP、DNS、TCP、ARP）整体都被纳入这一协议体系中，被统称为“TCP/IP 协议族”。

TCP/IP 协议族最早的确只有 TCP 和 IP 两个协议，现在则是一系列与网络通信有关的各类协议的集合。对应这一协议族，同时发展出了TCP/IP 参考模型，这一模型是一个抽象出来的分层模型，TCP/IP 协议族中的所有协议被归类到这一模型的 4 个层次中，每一层相互独立，下一层为上一层提供服务，各个层次间互相协作，完成了互联网通信的主要工作。

TCP/IP参考模型四层分别是：应用层、传输层、网络层、数据链路层(网络接口层)。各项通信协议各有归属： image.png
，请求数据到达服务器所在子网的路由器之后，又是一个由下而上的过程，这与客户端发送数据基本相反，每经过一个层次，都会解析前面添加到请求数据上的多层头部信息，交由上一层处理，在整个 TCP/IP 协议栈的帮助下，我们的请求数据终于到达了目标服务器，穿过服务器的网卡，服务器操作系统同样有协议栈来负责找到服务端程序对应的端口，将数据交由服务端应用程序处理。

服务器会根据我们的请求头信息，处理返回结果，之后，请求响应信息重新出发，再次回到浏览器。

浏览器收到请求后，经过解析、渲染过程，澳门荷官在线发牌 页面呈现在我们面前了。

输入URL到显示网页的全过程

解析 URL，DNS 查询，获得服务器 IP 地址，向目标地址发送 HTTP 请求，服务器收到，响应，返回页面，浏览器接收，渲染。 image.png

  1. 从浏览器接收 url 到开启⽹络请求线程（这⼀部分可以展开浏览器的机制以及进程与线程之间的关系）

  2. ！！从开启⽹络线程到发出⼀个完整的 HTTP 请求（这⼀部分涉及到dns查询， TCP/IP 请求，五层因特⽹协议栈等知识）

    • 解析URL：浏览器首先会对 URL 进行解析，获取到请求的协议（https），域名（google.com），路径（/）
    • DNS查询：域名查询系统，将URL解析为IP地址。
    • mac查询：通过ARP协议查询mac地址
    • 数据传输：打开socket与目标IP地址端口建立TCP链接。TCP链接建立后发送HTTP请求，将请求转发到服务程序，

  3. 从服务器接收到请求到对应后台接收到请求（这⼀部分可能涉及到负载均衡，安全拦截以及后台内部的处理等等）

    • 服务器接收请求并解析，将请求转发到服务程序，处理程序读取完整请求并准备HTTP响应，服务器将响应报⽂通过TCP连接发送回浏览器。
    • 浏览器接收HTTP响应，然后根据情况选择关闭TCP连接或者保留重⽤。浏览器检查响应状态吗：是否为1XX，3XX， 4XX， 5XX，这些情况处理与2XX不同，解析渲染页面。

全过程具体细节

在网络通信中，我们通常提到三个地址：IP 地址、Mac 地址以及端口号，三者分别代表的是：
IP地址：网络中互联的主机和路由器的标识。
Mac 地址：每个网卡硬件的物理地址。
端口号：识别同一个主机上不同的应用程序，也可以理解为程序地址。
所以，在一个网络通信中，我们需要用到五大识别符：源IP地址、目标IP地址、协议、源端口号和目标端口号。

  1. 解析URL：
    URL 只是为了人类更友好识别网络程序而设置的互联网资源的定位标识，浏览器首先会对 URL 进行解析，获取到请求的协议（https），域名（google.com），路径（/）
  2. 缓存解析：
    浏览器获取URL后，先去缓存中查找资源，从浏览器缓存-系统缓存-路由器缓存中查看； 如果有就从缓存中显示界面，不再发送请求； 如果没有，则发送HTTP请求。
  3. DNS查询域名解析：
    域名查询系统，将URL域名解析为IP地址。该过程由操作系统内置的Socket协议库中的解析器负责。
    IP地址：网际协议地址，是分配给网络上设备的数字标识，只要联网的设备都有IP地址，是我们的请求数据识别服务器在网络中的位置的必须标识。
    解析过程如下：
    1679208120012.png
  4. Mac地址查询：ARP
    IP地址在网络层使用，Mac地址在数据链路层使用。Mac地址是每一个网卡被生产的时候写死在其中的不变且唯一。通过ARP协议查询Mac地址。
    ARP协议：地址解析协议，根据IP地址获取通信设备的物理地址。工作原理类似于广播，将包发送给同一以太网的所有主机。若目标主机的Mac地址与对应的IP地址命中，则找到目标。

    APR缺点：若每次查询都要给所有的主机发送 ARP 请求，网络中则会出现很多 ARP 包。
    解决：每个主机都会有一个 ARP 缓存，里面存放着常用的 MAC 地址，主机会优先从缓存中查询是否有需要的信息，如果有，就不再发送广播。值得了解的是，在IPv6中，有一个 NDP（邻居发现协议）替代 ARP 来完成这个工作。

  5. 数据传输-socket
    当应用层获取到服务器的 IP 地址和 Mac 地址，已经拥有了数据传递的必要条件，接下来，浏览器会向操作系统的协议库发出委托指令，调用其中 Socket 库中的程序组件，建立套接字（socket），套接字的本质可以理解为一个数据通道的出入口，其执行的是一个“打开，读/写，关闭”的流程。
    在进行数据传输时，客户端和服务器都会创建一个套接字，之后调用 socket 库中的 connect 组件，该组件会依据描述符（套接字的匹配令符，与服务端的套接字的接头暗号），服务器的 IP 地址和端口号，在浏览器和目标服务器之间建立一个传输通道（实际上并没有真实的通道，中间隔着N多网关、路由器和防火墙，这样说更好理解），而大名鼎鼎的 TCP 三次握手实际就是发生在这个阶段。
    通道建立之后，接下来就是数据的读写操作，我们的程序代码无法直接控制套接字，它依然会委托 Socket 库中的组件来完成数据的读写（write 和 read），数据传输完成后，服务器会主动执行断开操作，调用 Socket 库中的 close 组件断开连接，浏览器发现之后，也会执行断开操作，数据传输完成。
  6. 浏览器发起HTTP请求报文：
    TCP 三次握手结束后，开始发送 HTTP 请求报文。 请求报文组成如下：
    • 请求行（request line）：请求方法(GET\POST)、URL(请求地址，<协议>：//<主机>：<端口>/<路径>?<参数> 组成)、协议版本 (http 版本号)
    • 请求头（header）：
    • 请求体：
  7. 服务器收到HTTP响应报文：
    响应报文组成如下：
    • 响应行：协议版本，状态码，状态码描述
      1679210953683.png
    • 响应头部：包含响应报文的附加信息，由 名/值 对组成
    • 响应体：回车符、换行符和响应返回数据，并不是所有响应报文都有响应数据
  8. 页面渲染：显示页面内容

数据是如何在庞大无比的因特网上找到服务器的呢？这就是网络层协议的用武之地了。

上面我们只提到发送和接收，但是在浏览器和服务器之间，可能隔着极多的网关、路由器、交换机等，数据是如何在庞大无比的因特网上找到服务器的呢？这就是网络层协议的用武之地了。 通过IP地址找：这一切在请求发送之前已经准备好了，我们使用 DNS 和 ARP 等方式，获取到了目标服务器的 IP 地址和 Mac 地址，这两个地址引导发送的数据包到达服务器，IP 地址用于在网络中的所有主机中匹配通信的目标主机，IP 地址包含网络标识和主机标识，前者用于区别不同的网段，后者找到同一网段的不同主机，数据到达路由器时，路由器会根据网络标识将数据转发到相应的网段，到达相应的网段之后，又会根据主机号，到达真正的主机。

**既然 IP 地址都能找到目标服务器，为什么还需要 Mac 地址？ **

  1. 在同一个网段内通信时，只用知道 Mac 地址，就可以精准找到目标，但是，互联网上的网络数量无比庞大，网络被各大运营商分割为多个网段，每个网段又有多个子网，如果仅仅知道一个 Mac 地址，要在所有的网络设备进行匹配，就是相当大的工程了，这时候，IP 地址的妙用体现出来了：它可以用来找路，这就类似于快递中的省市地区等，而 Mac 地址可能是唯一的名字，你在全中国找一个小强的人那就太多了，但是你要具体到某一个村或小区，就很简单了。
  2. 交换机这个东西，只认 Mac 地址，就如同路由器根据 IP 地址决定网络请求的转发路线，交换机通过 Mac 地址来确定具体的网卡位置。

你发送的请求是怎么到达目标服务器的，服务器的响应又是如何回来的？浏览器又是如何将请求发送出去的？

发送过程：
通过分层的顺序，发送端由上往下发送，接收端则由下向上接收。为了保证数据顺利发送到下一个层次，会在发送在其头部加上一些必要的信息，这些信息是为了保证数据的完整和符合需求的约束信息。发送 HTTP 请求时，经常会设置 Request Header，例如 Content-Type：text/html 是向服务器说明，我需要的是 HTML 页面，你返回其他东西是不行滴。
这些头部信息还可能包含协议信息，请求路径、请求方法等，但这仅仅是发生在应用层，整个通信过程，经过四个层次，会被依次加上 HTTP 请求头，TCP 头部、IP 头部以及以太网头部。数据加上这些头部信息之后，才会被发往下一层，数据经过重重包装，从你的网卡出发，穿过若干路由器，网线，交换机，到达目标服务器所在的子网，服务器要做的则是相反的过程，它会根据前面加上的头部信息，层层解析，最后到达服务器被处理（处理就是服务端程序代码的责任），之后再将响应数据返回。整体过程如下图：

image.png
数据在各个层次间依次传递，其传递的数据单位我们可以统一理解为数据包，数据包在不同的层次有不同的称呼，我们熟悉的是，其从应用层出发时，将之称为 HTTP 请求消息（message）或者报文，为其加上消息头之后，发送至传输层，加上 TCP 头部，叫它报文段（segment），到网络层，加上 IP 头部，成为 IP 数据包，到了最后的网络访问层，其已经套上层层包装，在这里在为其加上以太网首部的同时，还会加上一些尾部信息，摇身变为帧（framing），这个过程叫做封装过程。不管怎么叫，数据在各个层次间，是以数据包的形式传递，当数据量大时，还会出现分包传递的情况。

1. 协议：TCP/UDP

TCP怎么保证收发顺序

TCP协议工作在OSI的传输层，是一种可靠的面向连接的数据流协议，TCP之所以可靠，是因为它保证了传送数据包的顺序。

顺序是用一个序列号来保证的。响应包内也包括一个序列号，表示接收方准备好这个序列号的包。在TCP传送一个数据包时，它会把这个数据包放入重发队列中，同时启动计时器，如果收到了关于这个包的确认信息，便将此数据包从队列中删除，如果在计时器超时的时候仍然没有收到确认信息，则需要重新发送该数据包。

另外，TCP通过数据分段中的序列号来保证所有传输的数据可以按照正常的顺序进行重组，从而保障数据传输的完整！

TCP报文头部字段

image.png 在三次握手建立TCP链接的过程中，一般会关注TCP报文头部的序列号、确认号以及几个标记位（SYN/FIN/ACK/RST），其含义和用途解释如下：

  • 序列号：解决网络包乱序的问题
    在初次建立连接的时候，客户端和服务端都会为「本次的连接」随机初始化一个序列号。
  • 确认号：解决网络包丢失的问题
    该字段表示「接收端」告诉「发送端」对上一个数据包已经成功接收。
  • 标记位：不同标记位有不同的TCP语义
    SYN=1：希望创建连接。
    ACK=1：确认好字段有效。
    FIN=1：希望断开连接。
    RST=1：表示TCP连接出现异常，需要断开。

TCP三次握手建立连接详解

三次握手流程：
建立一个TCP链接时，需要客户端和服务器总共发送3个包，来确认双方的接收能力和发送能力是否正常。 image.png

  • 刚开始：客户端处于 Closed 的状态，服务端处于 Listen 状态主动监听某个端口。

  • 第一次握手：客户端希望建立链接
    客户端发送SYN报文-->进入SYN_SENT状态。

    发送SYN报文：

    1. 序列号：填入初始化的随机的生成序列号(ISN)(对应图中x)，
    2. 标志位：SYN置1表明想要链接。

    服务端收到来自客户端的SYN报文。

  • 第二次握手：服务端确认
    (收到SYN报文后)服务端发送自己的SYN报文-->进入SYN-REVD状态。

    发送SYN报文：

    1. 序列号：填入自己的初始化的序列号(图中为y)，
    2. 确认号：置为x+1（用于告诉客户端已经收到了你发送的序列号），
    3. 标志位：SYN置1，ACK置1

    客户端收到来自服务端的SYN报文。

  • 第三次握手：客户端确认建立链接
    (收到SYN报文后)客户端发送自己的ACK报文-->进入ESTABLISHED状态。

    ACK报文：

    1. 确认号：置为y+1（用于告诉服务端已经收到了你发送的序列号）
    2. 标记为：ACK置1

    服务端收到ACK报文-->进入ESTABLISHED状态。

  • 总结： 就是双方都把自身的序列号发给对方，看对方能不能接收到。如果「确认可以」，那就可以正常通信。（三次握手这个过程就可以看到双方都有接收和发送的能力）

    1. 第一次握手客户端发自己的序列号给服务端。
    2. 第二次握手服务端发自己的序列号给客户端，并通过确认号和标志位告诉对方我已经接收到了你发来的序列号。
    3. 第三次握手客户端通过确认号和标志位告诉对方我已经收到了你发来的序列号。成功建立链接。

TCP四次挥手释放链接详解：

建立一个连接需要三次握手，而终止一个连接要经过四次挥手（也有将四次挥手叫做四次握手的）。这由TCP的半关闭（half-close）造成的。所谓的半关闭，其实就是TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。
image.png

关闭链接双方都有权力，以下为客户端主动断开链接流程：

  • 第一次挥手：客户端希望断开链接
    客户端发送FIN报文-->进入FIN_WAIT1状态。

    FIN报文：连接释放报文

    1. 序列号：seq=u
    2. 标志位：FIN=1

    FIN_WAIT1状态：终止等待状态1。停止发送数据，主动关闭TCP链接，等待服务器的确认。

    服务端收到FIN报文。

  • 第二次挥手：服务端确认
    (收到FIN报文后)发送ACK报文-->进入CLOSE_WAIT状态。

    ACK报文：

    1. 序列号：seq=v
    2. 确认号：ack=u+1.
    3. 标志位：ACK置1

    CLOSE_WAIT状态：此时TCP处于半关闭状态。

    客户端收到ACK报文-->进入FIN_WAIT2状态。

    FIN_WAIT2状态：客户端到服务端链接释放。但是服务器可能还有数据要发给客户端。等待服务端发出FIN报文释放链接。

  • 第三次挥手：服务端希望断开链接
    服务端发送FIN报文-->进入LAST_ACK状态，

    FIN报文：连接释放报文

    1. 序列号：seq=w
    2. 确认号：ack=u+1
    3. 标志位：FIN=1，ACK=1

    LAST_ACK状态：最后确认状态，等待客户端确认

  • 第四次挥手：客户端确认 (收到FIN报文后)发送ACK报文-->进入TIME_WAIT状态。

    ACK报文：

    1. 序列号：seq=u+1
    2. 确认号：ack=w+1
    3. 标志位：ACK=1

    TIME_WAIT状态：此时TCP未释放掉，需要等待计时器设置的时间后，确保服务端收到自己的ACK报文后，客户端才进入CLOSED状态。

    服务端收到ACK报文-->进入CLOSED状态

  • 总结：客户端到服务端链接释放。等到服务端不再有数据发送给客户端时，才发送 FIN 报文给客户端，表示可以关闭了。

常见问题汇总

为什么需要三次握手呢？
为了保证数据传输的绝对可靠，三次确认是最少的次数，需要三次握手才能确认双方的接收与发送能力是否正常。

  1. 客户端发服务端收：服务端可以确认客户端的发送能力
  2. 服务端发客户端收：客户端可以确认服务端的收发能力
  3. 客户端发服务端收：服务端可以确认客户端的接收能力

TCP发送数据模式： TCP 传输数据时，并不是将所有数据一股脑全丢出去，而是会将数据存放在一个的发送缓冲区，并且会等待应用程序的下一段程序到达，之所以这样干，是因为一收到数据立马发送，很可能会造成信道的浪费与闲置，导致网络效率太低，就像明明很宽的马路，非要像过独木桥一样通过。

而 TCP 如何决定数据什么时候会发送，其拥有一套计算机制，整体来说，是按网络包的长度以及应用程序送包过来的时间，虽然你的数据很小，但你半天不发送，我也不会一直傻等着。

还有一种情况是，当发送过来的数据包很大时，会在缓冲区对包进行拆分发送，拆分的时候，TCP 模块会计算好每一块数据的开头和结尾的字节数，并将之写在 TCP 头部信息中，以待对方确认，根据这些起始序号，接收方可以判断是否有数据遗漏的情况。

什么时候出现多次timewait状态？ 频繁连接/端口耗尽/网络延迟导致关闭较慢

TCP协议简介

TCP首部：
image.png

百科对于TCP协议的定义：传输控制协议（TCP，Transmission Control Protocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议。

TCP特点：

  • 面向链接：
    建立连接的方法是“三次握手”，这样能建立可靠的连接。建立连接，是为数据的可靠传输打下了基础。
  • 可靠：
    TCP为了保证报文传输的可靠，就给每个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认(ACK)；如果发送端实体在合理的往返时延(RTT)内未收到确认，那么对应的数据（假设丢失了）将会被重传。
  • 基于字节流：
    TCP不像UDP一样那样一个个报文独立地传输，而是在不保留报文边界的情况下以字节流方式进行传输。
  • 提供拥塞控制：
    网络出现拥塞的时候，TCP能够减小向网络注入数据的速率和数量，缓解拥塞。
  • 全双工通信：
    TCP允许通信双方的应用程序在任何时候都能发送数据，因为TCP连接的两端都设有缓存，用来临时存放双向通信的数据。当然，TCP可以立即发送一个数据段，也可以缓存一段时间以便一次发送更多的数据段。
  • 仅支持单播传输 每条TCP传输连接只能有两个端点、点对点数据传输。

TCP 粘包/半包问题

TCP粘包是指：发送方发送的若干包数据到接收方接收时粘成一个包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。 在接收端，由于TCP是流协议，不保留消息的边界，因此无法直接知道哪些字节属于同一个消息。

造成原因：

  1. 操作系统优化算法：某些操作系统的TCP栈可能会对小数据包进行合并，以提高网络传输效率。这种合并可能导致接收端接收到粘包。
  2. 缓冲区大小限制：TCP协议栈在发送和接收数据时都使用缓冲区。如果发送端的数据包小于缓冲区的大小，而接收端的缓冲区比发送端小，那么多个小的数据包可能会在接收端的同一个缓冲区中被合并，形成粘包。
  3. 发送速度快于接收速度：如果发送端持续发送数据，而接收端处理数据的速度较慢，那么接收端可能会一次性接收到多个数据包，导致粘包。

处理方法： 发送端：关闭优化算法 接收端应用层：

  1. 固定数据包长度
  2. 特殊字符分隔：使用特殊字符（如换行符 \n）作为消息的分隔符，在接收端根据特殊字符将消息拆分开。
  3. 包头 + 包体格式 这种格式的包一般分为两部分，即包头和包体，包头是固定大小的，而且包头中必须含有一个字段来说明接下来的包体有多大。

UDP会不会产生粘包问题： 1698671269543.png

TCP如何处理丢包

  1. TCP重传机制——下下策(性能影响严重)
    对于TCP，它会给发出的消息打上一个编号（sequence） ，接收方收到后回一个确认(ack) 。发送方可以通过ack的数值知道接收方收到了哪些sequence的包。 如果长时间等不到对方的确认，TCP就会重新发一次消息，这就是所谓的重传机制。

--->以下方法都是避免重传机制

  1. 流量控制：——发多了接收不过来导致丢包问题
    依据数据发送方和接收方处理数据能力，控制发送的数据量来减小丢包概率。(发送窗口和接收窗口)

  2. 滑动窗口：——发多了收到了处理不过来丢包问题
    接收方的接收到数据之后，会不断处理，处理能力也不是一成不变的。动态的去调节这个接收窗口的大小。

  3. 拥塞控制：——网络环境导致丢包
    于是TCP希望能感知到外部的网络环境，根据网络环境及时调整自己的发包数量。
    怎么感知：TCP会先慢慢试探的发数据，不断加码数据量，越发越多，先发一个，再发2个，4个...。直到出现丢包，这样TCP就知道现在当前网络大概吃得消几个包了，这既是所谓的拥塞控制机制。

    流量控制与拥塞控制关系：流量控制针对的是单个连接数据处理能力的控制，拥塞控制针对的是整个网络环境数据处理能力的控制。

—>发送了丢包，以下方法可以降低它带来的影响

  1. 分段机制：
    当我们需要发送一个超大的数据包时，如果这个数据包丢了，那就得重传同样大的数据包。但如果我能将其分成一小段一小段，那就算真丢了，那我也就只需要重传那一小段就好了，大大减小了重传的压力，这就是TCP的分段机制。 而这个所谓的一小段的长度，在传输层叫MSS（Maximum Segment Size），数据包长度大于MSS则会分成N个小于等于MSS的包。

    而在网络层，如果数据包还大于MTU（Maximum Transmit Unit） ，那还会继续分包。 一般情况下，MSS=MTU-40Byte，所以TCP分段后，到了IP层大概率就不会再分片了。

image.png 8. 乱序重排
比如发数据包1,2,3。1号数据包走了其他网络路径，2和3数据包先到，1数据包后到，于是数据包顺序就成了2,3,1。这一点TCP也考虑到了，依靠数据包的sequence，接收方就能知道数据包的先后顺序。

后发的数据包先到是吧，那就先放到专门的乱序队列中，等数据都到齐后，重新整理好乱序队列的数据包顺序后再给到用户，这就是乱序重排机制。

  1. 链接机制
    前面提到，UDP是无连接的，而TCP是面向连接的。这里提到的连接到底是啥？

    TCP通过上面提到的各种机制实现了数据的可靠性。这些机制背后是通过一个个数据结构来实现的逻辑。而为了实现这套逻辑，操作系统内核需要在两端代码里维护一套复杂的状态机（三次握手，四次挥手，RST，closing等异常处理机制），这套状态机其实就是所谓的"连接" 。这其实就是TCP的连接机制，而UDP用不上这套状态机，因此它是"无连接"的。

流量控制和拥塞控制的实现机制

1）TCP采用大小可变的滑动窗口机制实现流量控制功能。窗口的大小是字节。在TCP报文段首部的窗口字段写入的数值就是当前给对方设置发送窗口的数据的上限。
在数据传输过程中，TCP提供了一种基于滑动窗口协议的流量控制机制，用接收端接收能力（缓冲区的容量）的大小来控制发送端发送的数据量。

  • 通过滑动窗口机制，接收方可以动态调整接收窗口的大小，以限制发送方的发送速率。当接收方的缓冲区快满时，它可以减小接收窗口的大小，告诉发送方降低发送速率，以避免数据丢失。
  • 发送方会根据接收窗口的大小来控制发送窗口内的数据量，确保不会超过接收方的处理能力。
  • 滑动窗口机制具有自适应性，能够根据网络状况和接收方处理能力动态调整发送速率，从而保持网络的稳定性和高效性。

2）采用滑动窗口机制还可对网络进行拥塞控制，将网络中的分组（TCP报文段作为其数据部分）数量维持在一定的数量之下，当超过该数值时，网络的性能会急剧恶化。传输层的拥塞控制有慢开始（Slow-Start）、拥塞避免（Congestion Avoidance）、快重传（Fast Retransmit）和快恢复（Fast Recovery）四种算法。这些TCP拥塞控制算法的设计是为了确保在网络拥塞的情况下，TCP连接能够自适应地调整传输速度，避免造成网络更严重的拥塞问题，从而保证了网络的稳定性和可靠性。
拥塞：　大量数据报涌入同一交换节点（如路由器），导致该节点资源耗尽而必须丢弃后面到达的数据报时，就是拥塞。

  • 慢启动：TCP连接刚开始的时候的拥塞控制策略。当一个新的TCP连接开始传输数据时，它会以一个较小的拥塞窗口（通常为1或者2）开始。每当成功接收到一个确认（ACK）时，拥塞窗口就会加倍，这种指数增长的方式可以使得数据传输速度快速增加，但同时避免了网络拥塞。
  • 拥塞避免：拥塞避免是为了防止慢启动阶段引发的网络拥塞。一旦拥塞窗口达到一个阈值（通常由网络的拥塞情况动态调整），TCP连接就进入拥塞避免阶段。在拥塞避免阶段，拥塞窗口不再指数增长，而是以线性增长的方式递增。当网络出现拥塞时，拥塞窗口会减小，以减轻网络负载。
  • 快重传：用于快速检测丢失的数据包并进行重传，而无需等待超时定时器触发。具体来说，当发送方连续收到相同的三个对同一个数据包的冗余确认（duplicate ACKs）时，它就知道之前发送的某个数据包已经丢失。此时，发送方不必等待超时，而是立即重传这个丢失的数据包，以加快数据包的到达时间。快重传机制减少了在网络拥塞时的等待时间，提高了网络的吞吐量。

    为什么是三个：避免误判。网络中的丢包是常态，偶尔的一两个冗余确认并不代表数据包丢失，可能是因为网络中的乱序或者其他原因引起的。通过连续收到三个冗余确认作为触发条件，减少了误判的可能性，提高了快速检测丢失数据包的准确性。一旦触发了快重传，发送方会立即重传丢失的数据包，提高了数据传输的效率。
    冗余确认：如果接收方收到了一个数据包，但是中间的某个数据包丢失，那么它会发送一个冗余确认，表示它已经接收到了后续的数据包，但是某个数据包（比如序列号为X的数据包）还未收到。

  • 快恢复：与快重传结合使用的一种机制。当发送方检测到数据包丢失时，它不会像慢启动那样把拥塞窗口减小为1。相反，它将拥塞窗口减小到之前的一半（即拥塞窗口的阈值Threshold），然后进入快恢复状态。在快恢复状态下，每次收到一个冗余确认，拥塞窗口就增加1个数据包，而不是像慢启动那样翻倍增加。这样，快恢复允许发送方继续发送数据，而不至于造成网络拥塞。

UDP协议简介

UDP首部：
image.png UDP 协议最大的特点就是简单，数据报传输数据

UDP特点：

  • 无连接
    UDP 是不需要和 TCP一样在发送数据前进行三次握手建立连接的，想发数据就可以开始发送了。并且也只是数据报文的搬运工，不会对数据报文进行任何拆分和拼接操作。

    • 在发送端，应用层将数据传递给传输层的 UDP 协议，UDP 只会给数据增加一个 UDP 头标识下是 UDP 协议，然后就传递给网络层了
    • 在接收端，网络层将数据传递给传输层，UDP 只去除 IP 报文头就传递给应用层，不会任何拼接操作

  • 不可靠

    • 不可靠性体现在无连接上，通信都不需要建立连接，想发就发。
    • 收到什么数据就传递什么数据，并且也不会备份数据.
    • 发送数据也不会关心对方是否已经正确接收到数据.
    • UDP 因为没有拥塞控制，一直会以恒定的速度发送数据。网络不好就可能导致丢包。

  • 基于消息报
    发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。因此，应用程序必须选择合适大小的报文

  • 有单播、多播、广播功能
    不止支持一对一的传输方式，同样支持一对多，多对多，多对一的方式。

使用场景： 实时性要求高的场景（比如电话会议）就需要使用 UDP 而不是 TCP。头部开销小，比TCP高效

TCP与UDP对比

1678190574097.png TCP与UDP都是传输层的协议,且都用端口号标识数据所达的进程。

TCP提供的是面向连接服务,提供可靠交付。且具有流量控制和拥塞控制。可用于可靠要求高的场合如:SMTP,FTP,HTTP等

UDP提供的是无连接服务,提供不可靠交付,且无确认机制。主要用于即时强的场合如:视频聊天,语音电话等。

如何防止视频,音频中出现的卡顿---> 如何让UDP可靠

blog.csdn.net/m0_60259116…?

参考

动图图解 | UDP就一定比TCP快吗？ - 掘金 (juejin.cn)
TCP和UDP比较 - 掘金 (juejin.cn) (43条消息) 三次握手和序列号和确认号的作用！_三次握手序列号的作用_奈何桥_的博客-CSDN博客 (43条消息) 三次握手和序列号和确认号的作用！_三次握手序列号的作用_奈何桥_的博客-CSDN博客 面试官问我TCP三次握手和四次挥手，我真的是 - 掘金 (juejin.cn)

其他常见协议

ICMP 协议

ping ICMP是（Internet Control Message Protocol）Internet控制报文协议。它是TCP/IP协议簇的一个子协议，用于在IP主机、路由器之间传递控制消息。属于网络层协议

控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据，但是对于用户数据的传递起着重要的作用。

ARP 协议

什么层，解决了同一个局域网上的主机和路由器IP与MAC地址的解析。 查询IP地址对应的MAC地址的流程：

  1. 查本机本地的ARP缓冲区
    每台主机都会在自己的ARP缓冲区中建立一个ARP列表，以表示IP地址和MAC地址的对应关系。
  2. 广播查询
    2.1 向本地网段发起ARP请求广播包，查询目的主机的MAC地址。 2.2 网络中的所有主机收到ARP请求，检查数据包中的目的IP是否和自己的IP地址一致，若一致，目的主机更新自己的ARP列表后给源主机发送一个ARP响应数据包告诉对方自己是它需要查找的MAC地址。 2.3 源主机收到这个ARP数据响应包后，更新自己的ARP列表。并利用此信息开始数据传输。没收到就表示ARP查询失败。

IP地址

IPv4和IPv6：
是用于在Internet上唯一标识设备的两个不同版本的网络协议。区别如下：

  1. 地址长度：IPv4使用32位地址，IPv6使用128为地址，提供地址的数量远超前者
  2. 地址表示：IPv4点分十进制，IPv6表示为冒号分隔的十六进制数

计算机网络常见八股

blog.csdn.net/qq_26109591…?

avatar
文章
阅读
粉丝