资料来源小林codinghttps://www.xiaolincoding.com/TCP 模型分几层TCP 协议分成应用层运输层网络层网络接口层。其中应用层是工作在用户态的剩下三层都是工作在内核态的。应用层应用层采用的协议是 HTTP FPTDNS 等协议。传输层传输层最重要的就是 TCP 和 UDP 两个协议。UDP 将消息打包在一起发送不像 TCP 是基于字节流的。TCP 有许多特性如流量控制超时重传拥塞控制这样能更加可靠地传输数据。相比之下 UDP 就没有那么可靠。网络层网络层主要就是 IP 协议。用 IP 地址为设备进行编号IP 地址分两部分第一部分是网络号第二部分是主机号。网络号标记目标设备属于哪个子网主机号标注是子网下的哪个主机。可以配合子网掩码按位与来获得目标地址。键入网址到网址显示发生了什么第一步解析 URL第二步生成 HTTP 请求第三步根据 URL 中的网址去 DNS 服务器中查找对应的 IP 地址第四步建立 TCP 连接进行发送TCP 三次握手建立连接。第五步服务器接受响应并返回数据客户端解析返回数据HTTP 状态码为 2 开头是返回成功3 开头是重定向到新地址4 开头是出现错误。第六步渲染网页或下载数据HTTP 是什么HTTP 定义超文本传输协议。超文本指的是 HTML 这种包含链接、图片、音频、视频、甚至复杂交互脚本的文本。HTTP 的最初目的就是为了传输这些“超越普通文本”的内容。HTTP 常见状态码GET 和 POST 请求GET 从语义上来说是请求服务器中的资源比如客户端要一个网页那么就请求服务器把这个网页返回给你。POST 从语义上来说是请求服务器对你提交的资源进行处理比如说你提交了一个文件希望服务器对这个文件进行处理。下面是一个例子。POST 会新增或者提交数据。HTTP 缓存技术强制缓存当浏览器请求资源时首先会检查本地缓存。如果命中强制缓存浏览器直接使用本地副本甚至不向服务器发送任何请求。核心字段Cache-Control (HTTP/1.1推荐)通过max-age设置资源有效期。例如Cache-Control: max-age31536000代表该资源在一年内都有效。Expires (HTTP/1.0老旧)指定一个绝对的过期时间点。缺点如果客户端和服务器时间不一致会导致缓存失效。协商缓存如果强制缓存失效了比如超过了 max-age浏览器就必须去问问服务器“我手里的这份旧文件还能继续用吗”这就是协商。如果没变服务器返回 304 Not Modified不带报文主体。浏览器继续用旧的。如果变了服务器返回 200 OK并带上全新的数据。HTTP1.1HTTP 1.1 支持长连接HTTP 1.0 是每次传输都需要进行 TCP 连接需要三次握手HTTP 1.1 支持长连接一旦 TCP 连接建立就可以在同一条管道上连续发送多个请求。HTTP 1.1 支持虚拟主机在 1.1 之前协议假设一个 IP 地址只对应一台物理服务器一个网站。改进引入了必须携带的Host请求头字段。意义现在一台服务器可以同时托管成千上万个网站虚拟主机。HTTP/1.1 强制要求所有请求必须包含 Host 字段。这使得一台物理服务器可以同时托管成千上万个不同的网站即使它们共享同一个 IP 地址。下面举一个例子。具体流程如下浏览器端你想访问 www.apple.com浏览器解析出 IP 是 1.2.3.4。建立连接浏览器连接到 1.2.3.4 的 80 端口。发送请求服务器处理服务器比如 Nginx 或 Apache收到请求。它一看 Host 字段是 www.apple.com就会去对应的文件夹里找苹果公司的网页如果是 Host: www.banana.com它就去另一个文件夹找香蕉公司的网页。HTTP 1.1 支持管道化管道化是指在信息发送时可以连续发送好几个信息而不是发送第一个之后必须等待第二个回来才能发送第二个。HTTP 1.1 存在队头堵塞HTTP 1.1 可以连续发好几个请求但是在响应上存在队头堵塞。比如说现在服务器要响应 ABC其中 A 要花时间特别长,B 和 C 不用花那么长的时间B 和 C 仍然要等待不能立刻响应而是要等待 A 响应完成之后。HTTPS 是什么HTTP 是超文本传输协议信息明文传输容易被窃取。HTTPS 引入了 SSL/TLS。HTTP 是无状态的协议HTTPS 是由 SSL HTTP 构建的可进行加密传输身份认证的网络协议。HTTPS 需要数字证书HTTP 不需要。HTTPS 和 HTTP 使用的端口号不同HTTP 是 80HTTPS 是 443.如何理解是 TCP 面向字节流协议UDP 会将一个完整的消息发送出去。而 TCP 则不是TCP 有可能一条消息被分成好几份那么就需要在接受时知道自己接受的是从哪里到哪里的消息也就是消息的范围。因为 TCP 是字节流没有边界所以会产生“粘包”现象场景你连续发送了两条消息“Hello” 和 “World”。结果接收方可能一次性读到了 “HelloWorld”它不知道这两句话从哪里断开。解决方法 由于 TCP 协议层不帮你分包应用程序必须自己定义边界。常见的办法有固定长度规定每条消息固定 100 字节。分隔符在消息末尾加回车换行符如 HTTP 协议。长度前缀在消息头先写上“本条消息长度为 5 字节”然后再发“Hello”下面是一个粘包的例子TCP 连接建立三次握手注意里面的 Ack_Num 和 Seq_Num.TCP 连接断开四次握手TCP 重传超时重传以时间为驱动当客户端在一定时间内没有收到回复时就认为丢包了启动重传。RTT客户端正常一次发送接受的时间。 RTO启动重传的时间就是说客户端在发送之后的 RTO 秒内没有收到回复认为它超时了启动重传。 RTO 应该设置的略大于 RTT如果 RTO 设置的太大那么会浪费时间设置的太小又会引发不必要的重传加重网络负担。快速重传快速重传是基于数据的重传。比如一个数据重发了三次仍然没有收到回复那么认为它丢包了启动重传。SACK 方法选择性确认上面的快速重传存在一个问题那就是已知 ACK2 传送了三次那么接下来是重传一个还是重传所有。Seq 2 肯定没有收到,但是 Seq 3, Seq 4 和后面的有可能收到,那么是否需要把他们也进行重传呢?由此引出了 SACK 方法也就是选择性确认。SACK 就像是接收方给发送方发了一份**“已收到货物的清单”**。在 TCP 报文头的Options选项字段中SACK 会记录已经收到的、但不连续的数据块即“空洞”之后的“孤岛”。TCP 滑动窗口发送方的滑动窗口接受方的滑动窗口TCP 流量控制流量控制就是接受方和发送方沟通让发送方不要发送的太快因为接受方不一定接受得过来。把下面这张图看懂就明白流量控制的模型了。窗口关闭窗口关闭是指接受方因为处理数据不及时导致窗口越变越小最后窗口为 0 导致窗口关闭。窗口关闭时接受方会给发送方发一个信号告知窗口关闭。窗口关闭可能会导致死锁现象比如在接受方告知发送方窗口关闭之后发送方会等待接受方将数据处理完之后再发。接受方处理完之后会发一个 ACK 给接受方如果这个 ACK 丢失了那么就会陷入死锁接受方和发送方互相等待。这种死锁如何解决呢解决办法是设置一个持续计数器当收到窗口为 0 时开始计时持续计数器超时时给对方发一个请求要求返回窗口大小如果窗口大小仍然为 0继续等待如果不是则开始通信。糊涂窗口糊涂窗口现象是指随着窗口越变越小发送方一次发送的数据也越来越少最后一次只发送几个字节。TCP 的报头都有 40 个字节结果实际发送的有用数据就几个字节导致资源浪费。解决办法有两个:1.让接受方不存在通知发送方小数据的情况 2.发送方避免发送小数据接受方不通告小窗口这个只要设定一个数值当窗口大小小于这个数值时将窗口大小设置为 0 停止发送就可以了。发送方避免发送小数据只要满足下面任意一条就可以发否则就缓存等着已经发出去的所有数据都收到 ACK 了要发送的数据已经攒到一个最大报文段MSS大小到了超时时间一般 200ms 左右必须发。TCP 拥塞控制拥塞控制是发送时考虑整个网络的情况不要一直发把网络堵上。慢启动在拥塞窗口小于慢拥塞门限前拥塞窗口按指数增长。拥塞避免当达到慢拥塞门限时拥塞窗口按照线性增长直到出现超时重传。拥塞发生发生超时重传快速重传和快速恢复
计算机网络学习
发布时间：2026/6/28 22:57:23
资料来源小林codinghttps://www.xiaolincoding.com/TCP 模型分几层TCP 协议分成应用层运输层网络层网络接口层。其中应用层是工作在用户态的剩下三层都是工作在内核态的。应用层应用层采用的协议是 HTTP FPTDNS 等协议。传输层传输层最重要的就是 TCP 和 UDP 两个协议。UDP 将消息打包在一起发送不像 TCP 是基于字节流的。TCP 有许多特性如流量控制超时重传拥塞控制这样能更加可靠地传输数据。相比之下 UDP 就没有那么可靠。网络层网络层主要就是 IP 协议。用 IP 地址为设备进行编号IP 地址分两部分第一部分是网络号第二部分是主机号。网络号标记目标设备属于哪个子网主机号标注是子网下的哪个主机。可以配合子网掩码按位与来获得目标地址。键入网址到网址显示发生了什么第一步解析 URL第二步生成 HTTP 请求第三步根据 URL 中的网址去 DNS 服务器中查找对应的 IP 地址第四步建立 TCP 连接进行发送TCP 三次握手建立连接。第五步服务器接受响应并返回数据客户端解析返回数据HTTP 状态码为 2 开头是返回成功3 开头是重定向到新地址4 开头是出现错误。第六步渲染网页或下载数据HTTP 是什么HTTP 定义超文本传输协议。超文本指的是 HTML 这种包含链接、图片、音频、视频、甚至复杂交互脚本的文本。HTTP 的最初目的就是为了传输这些“超越普通文本”的内容。HTTP 常见状态码GET 和 POST 请求GET 从语义上来说是请求服务器中的资源比如客户端要一个网页那么就请求服务器把这个网页返回给你。POST 从语义上来说是请求服务器对你提交的资源进行处理比如说你提交了一个文件希望服务器对这个文件进行处理。下面是一个例子。POST 会新增或者提交数据。HTTP 缓存技术强制缓存当浏览器请求资源时首先会检查本地缓存。如果命中强制缓存浏览器直接使用本地副本甚至不向服务器发送任何请求。核心字段Cache-Control (HTTP/1.1推荐)通过max-age设置资源有效期。例如Cache-Control: max-age31536000代表该资源在一年内都有效。Expires (HTTP/1.0老旧)指定一个绝对的过期时间点。缺点如果客户端和服务器时间不一致会导致缓存失效。协商缓存如果强制缓存失效了比如超过了 max-age浏览器就必须去问问服务器“我手里的这份旧文件还能继续用吗”这就是协商。如果没变服务器返回 304 Not Modified不带报文主体。浏览器继续用旧的。如果变了服务器返回 200 OK并带上全新的数据。HTTP1.1HTTP 1.1 支持长连接HTTP 1.0 是每次传输都需要进行 TCP 连接需要三次握手HTTP 1.1 支持长连接一旦 TCP 连接建立就可以在同一条管道上连续发送多个请求。HTTP 1.1 支持虚拟主机在 1.1 之前协议假设一个 IP 地址只对应一台物理服务器一个网站。改进引入了必须携带的Host请求头字段。意义现在一台服务器可以同时托管成千上万个网站虚拟主机。HTTP/1.1 强制要求所有请求必须包含 Host 字段。这使得一台物理服务器可以同时托管成千上万个不同的网站即使它们共享同一个 IP 地址。下面举一个例子。具体流程如下浏览器端你想访问 www.apple.com浏览器解析出 IP 是 1.2.3.4。建立连接浏览器连接到 1.2.3.4 的 80 端口。发送请求服务器处理服务器比如 Nginx 或 Apache收到请求。它一看 Host 字段是 www.apple.com就会去对应的文件夹里找苹果公司的网页如果是 Host: www.banana.com它就去另一个文件夹找香蕉公司的网页。HTTP 1.1 支持管道化管道化是指在信息发送时可以连续发送好几个信息而不是发送第一个之后必须等待第二个回来才能发送第二个。HTTP 1.1 存在队头堵塞HTTP 1.1 可以连续发好几个请求但是在响应上存在队头堵塞。比如说现在服务器要响应 ABC其中 A 要花时间特别长,B 和 C 不用花那么长的时间B 和 C 仍然要等待不能立刻响应而是要等待 A 响应完成之后。HTTPS 是什么HTTP 是超文本传输协议信息明文传输容易被窃取。HTTPS 引入了 SSL/TLS。HTTP 是无状态的协议HTTPS 是由 SSL HTTP 构建的可进行加密传输身份认证的网络协议。HTTPS 需要数字证书HTTP 不需要。HTTPS 和 HTTP 使用的端口号不同HTTP 是 80HTTPS 是 443.如何理解是 TCP 面向字节流协议UDP 会将一个完整的消息发送出去。而 TCP 则不是TCP 有可能一条消息被分成好几份那么就需要在接受时知道自己接受的是从哪里到哪里的消息也就是消息的范围。因为 TCP 是字节流没有边界所以会产生“粘包”现象场景你连续发送了两条消息“Hello” 和 “World”。结果接收方可能一次性读到了 “HelloWorld”它不知道这两句话从哪里断开。解决方法 由于 TCP 协议层不帮你分包应用程序必须自己定义边界。常见的办法有固定长度规定每条消息固定 100 字节。分隔符在消息末尾加回车换行符如 HTTP 协议。长度前缀在消息头先写上“本条消息长度为 5 字节”然后再发“Hello”下面是一个粘包的例子TCP 连接建立三次握手注意里面的 Ack_Num 和 Seq_Num.TCP 连接断开四次握手TCP 重传超时重传以时间为驱动当客户端在一定时间内没有收到回复时就认为丢包了启动重传。RTT客户端正常一次发送接受的时间。 RTO启动重传的时间就是说客户端在发送之后的 RTO 秒内没有收到回复认为它超时了启动重传。 RTO 应该设置的略大于 RTT如果 RTO 设置的太大那么会浪费时间设置的太小又会引发不必要的重传加重网络负担。快速重传快速重传是基于数据的重传。比如一个数据重发了三次仍然没有收到回复那么认为它丢包了启动重传。SACK 方法选择性确认上面的快速重传存在一个问题那就是已知 ACK2 传送了三次那么接下来是重传一个还是重传所有。Seq 2 肯定没有收到,但是 Seq 3, Seq 4 和后面的有可能收到,那么是否需要把他们也进行重传呢?由此引出了 SACK 方法也就是选择性确认。SACK 就像是接收方给发送方发了一份**“已收到货物的清单”**。在 TCP 报文头的Options选项字段中SACK 会记录已经收到的、但不连续的数据块即“空洞”之后的“孤岛”。TCP 滑动窗口发送方的滑动窗口接受方的滑动窗口TCP 流量控制流量控制就是接受方和发送方沟通让发送方不要发送的太快因为接受方不一定接受得过来。把下面这张图看懂就明白流量控制的模型了。窗口关闭窗口关闭是指接受方因为处理数据不及时导致窗口越变越小最后窗口为 0 导致窗口关闭。窗口关闭时接受方会给发送方发一个信号告知窗口关闭。窗口关闭可能会导致死锁现象比如在接受方告知发送方窗口关闭之后发送方会等待接受方将数据处理完之后再发。接受方处理完之后会发一个 ACK 给接受方如果这个 ACK 丢失了那么就会陷入死锁接受方和发送方互相等待。这种死锁如何解决呢解决办法是设置一个持续计数器当收到窗口为 0 时开始计时持续计数器超时时给对方发一个请求要求返回窗口大小如果窗口大小仍然为 0继续等待如果不是则开始通信。糊涂窗口糊涂窗口现象是指随着窗口越变越小发送方一次发送的数据也越来越少最后一次只发送几个字节。TCP 的报头都有 40 个字节结果实际发送的有用数据就几个字节导致资源浪费。解决办法有两个:1.让接受方不存在通知发送方小数据的情况 2.发送方避免发送小数据接受方不通告小窗口这个只要设定一个数值当窗口大小小于这个数值时将窗口大小设置为 0 停止发送就可以了。发送方避免发送小数据只要满足下面任意一条就可以发否则就缓存等着已经发出去的所有数据都收到 ACK 了要发送的数据已经攒到一个最大报文段MSS大小到了超时时间一般 200ms 左右必须发。TCP 拥塞控制拥塞控制是发送时考虑整个网络的情况不要一直发把网络堵上。慢启动在拥塞窗口小于慢拥塞门限前拥塞窗口按指数增长。拥塞避免当达到慢拥塞门限时拥塞窗口按照线性增长直到出现超时重传。拥塞发生发生超时重传快速重传和快速恢复
![华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
![华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
