[网络协议] 计算机网络知识点复习（适合春招面试复习）

开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> 网络协议 -> 计算机网络知识点复习（适合春招面试复习） -> 正文阅读

[网络协议]计算机网络知识点复习（适合春招面试复习）

HTTP协议

HTTP协议是客户端和服务端交互的一种通讯格式

java3y-对线面试官HTTP

HTTP协议各版本之间的区别

在这里插入图片描述

HTTP1.0默认是短链接。

每次与服务器交互，都需要新开一个连接，会对服务器产生较大的资源性能损耗

HTTP1.1默认持久连接。

只要不断开TCP连接，就可以多次发送请求
断点续传，利用HTTP消息头使用分块传输编码，将实体主题分块进行传输。
- 请求头Range:bytes=0-499，响应头Content-Range:bytes=0-499
新增了一批Request method：OPTIONS,PUT, DELETE, TRACE, CONNECT
Pipelining（请求流水线、管线化理论）

在这里插入图片描述

HTTP1.x 的缺点：

HTTP/1.0一次只允许在一个TCP连接上发起一个请求，HTTP/1.1使用的流水线技术也只能部分处理请求并发，仍然会存在队列头阻塞问题，因此客户端在需要发起多次请求时，通常会采用建立多连接来减少延迟。
单向请求，只能由客户端发起。
请求报文与响应报文首部信息冗余量大。
数据未压缩，导致数据的传输量大

HTTP2.0

采用二进制分帧层（不再使用文本传输）改进了传输性能实现低延迟高吞吐量
- 应用层（HTTP2.0）和传输层（TCP or UDP）之间增加一个二进制分帧层。在二进制分帧层上，HTTP2.0会将所有传输的信息分为更小的消息和帧，并采用二进制格式编码，其中HTTP1.x的首部信息会被封装到Headers帧，而Request Body则封装到Data帧。
对头部进行压缩，支持流控
多路复用 通过单一的TCP，并行发起多个请求和响应消息，一定程度上避免队头阻塞问题（只解决了HTTP层队头阻塞的问题，没解决TCP层队头阻塞的问题）

在这里插入图片描述

服务器推送
- 服务端根据客户端的请求，提前返回多个响应，推送额外的资源给客户端

HTTP3.0

为什么HTTP3.0使用UDP协议

在这里插入图片描述

QUIC底层基于UDP，能够减少RTT（往返时间）
QUIC解决队头阻塞问题
- 在一条链接上可以有多个流，流与流之间是互不影响的，当一个流出现丢包影响范围非常小，从而解决队头阻塞问题。
QUIC（Quick UDP Internet Connections）第一个数据包就可以发业务数据（非首次连接可以0RTT时间），从而在连接延时有很大优势，可以节约数百毫秒的时间。

在这里插入图片描述

HTTPS的过程

在这里插入图片描述

HTTP是如何保存用户状态，Cookie和Session

Session 存放在服务器端，在服务端保存 Session 的?法很多，最常?的就是内存和数据库(?如是使?内存数据库redis保存)。?部分情况下，我们都是通过在 Cookie 中附加?个 Session ID 来?式来跟踪。

Cookie ?般?来保存?户信息

Session 的主要作?就是通过服务端记录?户的状态。

Cookie 存储在客户端中，?Session存储在服务器上，相对来说 Session 安全性更?。

Cookie 中存储?些敏感信息，不要直接写? Cookie 中，最好能将 Cookie 信息加密然后使?到的时候再去服务器端解密。

单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。(Session对象没有对存储的数据量的限制，其中可以保存更为复杂的数据类型）

OSI体系结构

在这里插入图片描述

应?层(application-layer）的任务是通过应?进程间的交互来完成特定?络应?。
运输层(transport layer)的主要任务就是负责向两台主机进程之间的通信提供通?的数据传输服务
在计算机?络中进?通信的两个计算机之间可能会经过很多个数据链路，也可能还要经过很多通信? ?。?络层的任务就是选择合适的?间路由和交换结点，确保数据及时传送。
数据链路层(data link layer)通常简称为链路层。两台主机之间的数据传输，总是在?段?段的链路上传送的，这就需要使?专?的链路层的协议
- RAP协议地址解析协议 MAC-IP
- 封装成帧，透明传输，差错控制
在物理层上所传送的数据单位是?特。物理层(physical layer)的作?是实现相邻计算机节点之间? 特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异

TCP的三次握手和四次挥手

参考博客

三次握手

在这里插入图片描述

三次握?的?的是建?可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，?三次握?最主要的?的就是双?确认??与对?的发送与接收是正常的。

第?次握?：Client 什么都不能确认；Server 确认了对?发送正常，??接收正常

第?次握?：Client 确认了：??发送、接收正常，对?发送、接收正常；Server 确认了：对?发送正常，??接收正常

第三次握?：Client 确认了：??发送、接收正常，对?发送、接收正常；Server 确认了：??发送、接收正常，对?发送、接收正常

所以三次握?就能确认双发收发功能都正常，缺?不可。

第三次握手的ACK可以携带数据，不携带则不消耗序列号。

客户端TCP为什么要发送最后一次确认：主要防止已经失效的连接请求报文突然又传送到了服务器

四次挥手

在这里插入图片描述

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

因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四次挥手。

2MSL时间

第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。

第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

SYN泛洪攻击

SYN攻击利用的是TCP的三次握手机制，攻击端利用伪造的IP地址向被攻击端发出请求，而被攻击端发出的响应报文将永远发送不到目的地，那么被攻击端在等待关闭这个连接的过程中消耗了资源，如果有成千上万的这种连接，主机资源将被耗尽，从而达到攻击的目的。

SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。SYN 攻击是一种典型的 DoS/DDoS 攻击。

解决方案

缩短超时（SYN Timeout）时间
增加最大半连接数
过滤网关防护
SYN cookies技术

三次握手流程中，出现失败了怎么办

第三次握手当失败时服务器并不会重传ack报文，而是直接发送RTS（复位报文段——通知对方关闭连接或者重新建立连接）报文段，进入CLOSED状态。这样做的目的是为了防止SYN洪泛攻击。

已经建立连接，客户端出现故障？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

什么是半链接队列？

服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。

当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

这里在补充一点关于SYN-ACK 重传次数的问题：
服务器发送完SYN-ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传。如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。
注意，每次重传等待的时间不一定相同，一般会是指数增长，例如间隔时间为 1s，2s，4s，8s…

三次握手可以携带数据吗？

其实第三次握手的时候，是可以携带数据的。但是，第一次、第二次握手不可以携带数据

为什么这样呢?大家可以想一个问题，假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据。因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发 SYN 报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。

也就是说，第一次握手不可以放数据，其中一个简单的原因就是会让服务器更加容易受到攻击了。而对于第三次的话，此时客户端已经处于 ESTABLISHED 状态。对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据也没啥毛病。

TCP与UDP的区别以及TCP怎么保证可靠

在这里插入图片描述

应?数据被分割成 TCP 认为最适合发送的数据块。
TCP 给发送的每?个包进?编号，接收?对数据包进?排序，把有序数据传送给应?层。
校验和： TCP 将保持它?部和数据的检验和。这是?个端到端的检验和，?的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报?段和不确认收到此报? 段。
TCP 的接收端会丢弃重复的数据。
流量控制： TCP 连接的每??都有固定??的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收?来不及处理发送?的数据，能提示发送?降低发送的速率，防? 包丢失。TCP 使?的流量控制协议是可变??的滑动窗?协议。（TCP 利?滑动窗?实现流量控制）
拥塞控制：当?络拥塞时，减少数据的发送。
ARQ协议：也是为了实现可靠传输的，它的基本原理就是每发完?个分组就停?发送，等待对? 确认。在收到确认后再发下?个分组。
超时重传：当 TCP 发出?个段后，它启动?个定时器，等待?的端确认收到这个报?段。如果不能及时收到?个确认，将重发这个报?段。

ARQ协议

参考知乎

?动重传请求（Automatic Repeat-reQuest，ARQ）是OSI模型中数据链路层和传输层的错误纠正协议之 ?。它通过使?确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送?在发送后?段时间之内没有收到确认帧，它通常会重新发送。ARQ包括停?等待ARQ协议和连续ARQ协议。

停止等待ARQ协议

停?等待协议是为了实现可靠传输的，它的基本原理就是每发完?个分组就停?发送，等待对? 确认（回复ACK）。如果过了?段时间（超时时间后），还是没有收到 ACK 确认，说明没有发送成功，需要重新发送，直到收到确认后再发下?个分组；

在停?等待协议中，若接收?收到重复分组，就丢弃该分组，但同时还要发送确认；

在这里插入图片描述

连续ARQ协议

连续 ARQ 协议可提?信道利?率。发送?维持?个发送窗?，凡位于发送窗?内的分组可以连续发送出去，?不需要等待对?确认。接收??般采?累计确认，对按序到达的最后?个分组发送确认，表明到这个分组为?的所有分组都已经正确收到了。

缺点：不能向发送?反映出接收?已经正确收到的所有分组的信息。 ?如：发送?发送了 5条消息，中间第三条丢失（3号），这时接收?只能对前两个发送确认。发送??法知道后三个分组的下落，?只好把后三个全部重传?次。这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的 N 个消息。

滑动窗口和流量控制

在这里插入图片描述

TCP 利?滑动窗?实现流量控制。流量控制是为了控制发送?发送速率，保证接收?来得及接收。接收?发送的确认报?中的窗?字段可以?来控制发送?窗???，从?影响发送?的发送速率。将窗? 字段设置为 0，则发送?不能发送数据

拥塞控制

在这里插入图片描述

在某段时间，若对?络中某?资源的需求超过了该资源所能提供的可?部分，?络的性能就要变坏。这种情况就叫拥塞。拥塞控制就是为了防?过多的数据注?到?络中，这样就可以使?络中的路由器或链路不致过载。拥塞控制所要做的都有?个前提，就是?络能够承受现有的?络负荷。拥塞控制是?个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低?络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

为了进?拥塞控制，TCP 发送?要维持?个拥塞窗?(cwnd) 的状态变量。拥塞控制窗?的??取决于 ?络的拥塞程度，并且动态变化。发送?让??的发送窗?取为拥塞窗?和接收?的接受窗?中??的 ?个。

TCP的拥塞控制采?了四种算法，即慢开始、拥塞避免、快重传和快恢复。在?络层也可以使路由器采?适当的分组丢弃策略（如主动队列管理 AQM），以减少?络拥塞的发?。

慢开始：慢开始算法的思路是当主机开始发送数据时，如果?即把?量数据字节注?到?络，那么可能会引起?络阻塞，因为现在还不知道?络的符合情况。经验表明，?好的?法是先探测 ?下，即由?到?逐渐增?发送窗?，也就是由?到?逐渐增?拥塞窗?数值。cwnd初始值为 1，每经过?个传播轮次，cwnd加倍。
拥塞避免：拥塞避免算法的思路是让拥塞窗?cwnd缓慢增?，即每经过?个往返时间RTT就把发送放的cwnd加1.
快重传与快恢复：在 TCP/IP 中，快速重传和恢复（fast retransmit and recovery，FRR）是 ?种拥塞控制算法，它能快速恢复丢失的数据包。没有 FRR，如果数据包丢失了，TCP 将会使? 定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到?个不按顺序的数据段，它会**?即（而不是再发送数据时捎带发送一个确认）**给发送机发送?个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并?即重传这些丢失的数据段。有了 FRR，就不会因为重传时要求的暂停被耽误。　当有单独的数据包丢失时，快速重传和恢复（FRR）能最有效地?作。当有多个数据信息包在某?段很短的时间内丢失时，它则不能很有效地?作。