JAVA八股—计算机网络（自用）

2.7

1.介绍一下TCP/IP模型和OSI模型的区别

OSI模型是国际标准化组织(ISO)制定的一个用于计算机或通信系统间互联的标准体系，将计算机网络通信划分为七个不同的层级，每个层级都负责特定的功能。每个层级都构建在其下方的层级之上，并为上方的层级提供服务。七层从上到下分别是应用层、表示层、会话层、传输层、网络层、数据链路层和物理层。虽然OSI模型在理论上更加全面，但是在实际网络通信中，TCP/IP模型更为实用。TCP/IP模型分为四个层级，每个层级负责特定的网络功能。

应用层与OSI模型的应用层、表示层、会话层类似，专注于为用户提供应用功能。比如HTTP提供网页浏览，SMTP提供电子邮件、FTP提供文件传输、Telnet提供远程控制。
传输层对应OSI模型的传输层。负责端到端的数据传输，提供可靠的、无连接的数据传输服务。主要的传输层协议有TCP协议和UDP协议。TCP提供可靠的数据传输，确保数据的正确性和完整性；而UDP则是无连接的，适用于不要求可靠性的传输，但是传输速度较快，适用于视频通话功能和语音功能。
- 并且在接收方可能会有很多应用在等待接收数据，因此传输层的报文(消息)中会携带端口号，以帮助接收方识别出该报文时发送给哪个应用的。
网络层对应OSI模型的网络层。实际上传输层并不提供数据传输功能，他只是充当在应用间数据传输的媒介，帮助实现应用到应用的通信。而传输功能是交给网络层实现的。在网络层中主要的协议是IP协议，它负责数据包的寻址和路由。帮助我们把数据从一个设备传输到另一个设备，因此需要有区分设备的编号。而IP地址分成两种意义，一个是网络号一个是主机号，配合子网掩码计算出IP地址的网络号和主机号（按位与，取反后按位与），以此寻址找到对应的主机。然后通过路由算法选择最佳的路径（网关、路由器、交换机）把数据从源主机传输到目标主机。
网络接口层对应着OSI模型的数据链路层和物理层。负责物理传输媒介的传输，例如以太网、WIFI等，并提供错误检测和纠正功能。此外网络接口层还包括有MAC地址的管理功能，确保网络设备之间能正确识别并进行数据的传输。
（消息（报文）、段、包、帧）

2.从输入URL到页面展示发生了什么?

首先，我们输入 URL 地址，准备发送HTTP请求。
检查浏览器缓存中是否缓存有该资源，如果有的话直接返回，没有的话进入下一步的网络资源请求。
但在获取相关资源信息之前，需要解析 URL 中的内容以提取所需信息。第一步是通过 DNS 解析获取 URL 域名对应的 IP 地址。解析时会按照本地浏览器缓存、本地Host文件、路由器缓存、DNS服务器、根DNS服务器的顺序查询域名对应的IP，直至找到为止。
获得 IP 地址后，在发送数据之前，我们需要建立 TCP 连接（通过三次握手），以确保数据传输通道的可靠性。三次握手的过程包括：第一次，客户端发送 SYN 请求连接；第二次，服务器回应 SYN+ACK 同意建立连接；第三次，客户端发送 ACK 确认，连接成功建立。
连接建立后，客户端发送请求报文给服务器，请求报文包括请求行、请求头、空行和可选的数据部分。服务器收到请求报文后，会响应 HTTP 请求，响应报文包括状态行、响应头、空行和响应数据。
浏览器与服务器IP四次挥手断开TCP连接
浏览器接收到响应后，将进行渲染：
- 如果响应头的状态码是301或302，会重定向到新地址；若响应数据类型是字节流类型。一般会将请求提交给下载管理器；若是HTML类型，会进行下一步渲染。
- 浏览器解析HTML文件，创建DOM树，解析CSS进行样式计算，然后将CSS和DMO合并，构建出渲染树；最后布局和绘制渲染树，完成页面的展示。

2.8

1.HTTP请求报文和响应报文是怎样的?

HTTP报文可以分为请求报文和响应报文。

请求报文由请求行、请求头、空行和请求体组成。

响应报文由状态行、响应头、空行和响应体组成。

请求报文

请求行主要包括以下字段：

方法：指定我们要执行的操作，如get、post、put、delete等；
资源访问路径：告诉我们要访问的资源在哪里
HTTP版本：告诉我们要使用的HTTP协议版本，因为不同的协议版本处理的方式不同。

请求头的字段比较多，通常包括以下字段：

与客户端接收的信息有关（接收谁的 什么类型的 内容）
- Host：请求的服务器的域名
- Accept：客户端能够处理的媒体类型
- Accept-Encoding：客户端能够解码的内容
与客户端自己传输的信息有关（证明我发送了什么类型的 信息）
- Authorization：用户凭证，允许服务器对其身份进行验证和授权
- Content-Length：请求体的长度
- Content-type：请求体的媒体类型
- Cookie：由于HTTP协议是无状态的，通过Cookie存储相关的用户信息
如果之前就访问过服务器，告诉我们是否可以直接使用本地缓存的内容
- If-Nnone-Match：存储资源的ETag值，与响应报文中的Etag对比，如果相同则返回304.
Connection：管理连接的选项

空行是请求头部和请求体之间的空行，用于分割请求头部和请求体。

请求体通常用于POST和PUT请求，包含发送给服务器的数据。

响应报文

状态行主要包含HTTP版本信息、状态码和状态信息。因为客户端和服务端使用的HTTP协议版本可能是不一样的。

响应头类似于请求头，用于告诉客户端有关响应的信息：

比如，它会指明响应体的媒体类型（Content-Type）、响应的长度（Content-Length），以及服务器的相关信息（Server）。
此外，为了支持不同的缓存机制，响应头还需要设置一些字段。比如，响应的过期时间（Expires）、实体标签（ETag），还有最后修改日期和时间（Last-Modified）。在判断缓存时，ETag 会优先于最后修改日期。
当发生重定向时，响应头中也会包含新的资源位置（Location）。
如果需要为客户端设置身份验证的 Cookie，响应头会使用 Set-Cookie 字段。
最后，还有一个叫 Access-Control-Allow-Origin 的字段，用于指定跨源资源共享策略。

空行在响应头和响应体之间，表示响应头的结束。而响应体是服务端实际传输的数据，可以是文本、HTML页面、图片、视频等，也可能为空。

2.HTTP有哪些请求方式？

GET：用于获取指定的资源
POST：向服务器发送数据以创建资源，如提交表单数据
PUT：向服务器发送数据以更新现有资源。如果资源不存在，则创建新的资源
DELETE：从服务器删除指定的资源
PATCH：对资源进行部分的修改。与PUT类似，但是PATCH只更改部分数据而不是替换整个资源
HEAD：获取报文的首部，不返回报文主体
OPTIONS：返回服务器支持的HTTP方法

3.GET请求和POST请求的区别？

用途：GET用于获取数据；而POST用于提交数据
数据传输方式不同：GET将参数附加在URL之后；而POST请求将数据放在请求体中。
安全性：这种传输方式导致GET请求由于参数暴露在URL中，安全性比较低；POST请求参数不会暴露在URL中，相对来说比较安全
数据大小：并且GET请求本身大小没有限制，但是会受到URL长度限制，数量有限；而POST请求理论上没有大小限制
幂等性：GET请求是幂等的，就是说多次请求资源的状态不会发生改变；而POST请求不是幂等的，会修改服务器上的资源，且多次提交就会创建多个资源。
**缓存：**所以GET请求可以被缓存，POST请求默认不会被缓存。

2.10

1.HTTP中常见的状态码有哪些？

HTTP中常见的状态码如下所示：

以1开头表示提示信息，是协议处理的中间状态
以2开头表示请求成功，其中：
- 200表示客户端请求成功
- 201表示创建了新的资源，通常在POST或某些PUT请求后返回的响应
- 204表示无内容，服务器成功处理请求，但是没有返回任何内容
以3开头表示请求重定向，其中：
- 301表示请求资源的URL已经永久修改，在响应中给出了新的URL
- 302表示请求资源的URL暂时更改。
- 304表示请求的内容没有修改过，所以服务器返回此响应时，不会返回网页的内容，而是使用缓存
以4开头表示客户端请求错误，其中：
- 401表示客户端需要进行身份验证
- 403表示请求的对应资源被禁止访问
- 404表示服务端找不到请求的资源
以5开头表示服务器端响应错误，其中：
- 500表示服务器内部错误，遇到了不知道如何处理的情况
- 503表示服务器不可用，通常由于服务器维护或因为过载而停机

2.什么是强缓存和协商缓存？

强缓存和协商缓存是HTTP缓存机制的两种类型，他们用于减少服务器的负担和提高网页加载速度

强缓存

客户端在没有向服务端发送请求的情况下，直接从本地缓存中获取资源

Expires强缓存（绝对时间）：设置一个强缓存时间，此时间范围内，从内存中读取缓存并返回，但是因为Expires判断强缓存过期的机制是获取本地时间戳，与之前拿到的资源文件中的Expires字段的时间做比较判断是否需要对服务器发起请求。但是这里有一个巨大漏洞：”如果本地的时间不准确怎么办？”所以当前已经被废弃了。
Cache-Control强缓存：目前使用多个强缓存是通过HTTP响应头的Cacha-Control字段实现的，通过max-age来告诉浏览器在指定时间内可以直接使用缓存数据，无序再次请求。

协商缓存

当强缓存失效时，浏览器会发送请求到服务器，通过Etag或Last-Modified等HTTP响应头与服务器进行验证，以确定资源是否被修改。如果资源未修改，服务器返回304Not Modified状态码，告知浏览器使用本地缓存；如果资源已修改，则返回新的资源，浏览器更新本地缓存。这种方式需要与服务器通信，但可以确保用户总是获取最新的内容

基于Last-Modified的协商缓存
- Last-Modified是资源修改的最后时间，服务器会在响应头部中返回
- 当客户端读取到Last-Modified的时候，会在下次的请求头中携带一个字段:If-Modified-Since，而这个请求头中的If-Modified-Since就是服务器第一次修改时给他的时间
- 服务器比较请求头中的If-Modified-Since值与当前资源的Last-Modified值，如果比对的时间没有发生变化，表示资源没有发生变化，返回状态码304 Not Modified。如果比对的结果说资源已经更新了，就会给浏览器正常返回资源，返回200状态码。
但是这样协商缓存有两个缺点：
- 因为是更改文件的修改时间来判定的，所以在文件内容本身不修改的情况下，一九有可能更新文件修改时间(比如修改文件名称再改回来)，这个时候文件的内容没有发生改变，但是缓存依然失效了。
- 当文件在极短的时间内发生修改（例如几百毫秒）。因为文件修改时间记录的最小单位是秒，所以，如果文件在几百毫秒内完成修改的话，文件修改时间不会发生改变，这样，即使文件内容修改了，依然不会返回原先的文件。
基于Etag的协商缓存：将原先协商缓存比较时间戳的形式修改成了比较文件指纹(根据文件内容计算出的唯一哈希值)。
- Etag是服务器未资源生成的唯一标识符(文件指纹)，可以是根据文件内容计算出的哈希值，服务端将其和资源一起放回给客户端。
- 客户端在请求头中的If-None-Match字段中携带上次响应的Etag值。
- 服务器比较请求中的If-None-Match值与当前资源中的ETag值，如果匹配，表示资源未发生变化，返回状态码304 Not Modified。如果两个文件指纹不吻合，则说明文件被修改，那么将新的文件指纹重新存储到响应头的ETag中并返回给客户端。

2.11

1.HTTP1.0和HTTP1.1的区别？

HTTP1.1默认支持长连接，允许在一个TCP连接上发送多个HTTP请求和响应，减少了连接建立和关闭的开销。而HTTP1.0默认为短连接，每次请求都需要建立一个TCP连接，并通过Connection：keep-alive头来实现持久连接
解决请求的队头堵塞，HTTP1.1支持管道化(不是默认开启)，允许客户端在第一个请求的响应到达之前发送多个请求，这可以减少等待的时间，提高效率。而HTTP1.0不支持管道化。
缓存机制：HTTP1.0采用if-Modified-Since/Last-Modified来作为缓存判断的标准。而HTTP1.1引入了更多的缓存控制策略，如Etag/If-None-Match等更多的缓存来控制缓存策略。

2.HTTP2.0与HTTP1.1的区别？

HTTP1.1的性能瓶颈：

请求/响应的头部未经压缩就发送，首部信息越多延迟就越大。值能压缩Body部分
发送冗长的首部。每次互相发送相同的首部造成的浪费较多
响应队头堵塞。
没有请求的优先控制级
请求只能从客户端开始，服务器只能被动的响应。

区别：

HTTP2.0引入了HPACK压缩算法，对请求和响应的头部信息进行压缩，减少了冗余头部信息的传输，提高了传输的效率。
HTTP2.0采用二进制格式传输数据，而不是HTTP1.1的文本格式，使得解析更高效，减少了解析时间。
多路复用：HTTP/2.0支持多路复用，允许在单个TCP连接上并行交错发送多个请求和响应。解决了HTTP1.1中的响应队头堵塞问题。
服务器推送：HTTP2.0允许服务器主动给客户端推送资源，而不需要客户端的明确需求。减少了页面加载时间。
优先级和依赖：HTTP2.0允许客户端为请求设置优先级，并表达请求之间的依赖关系，资源加载更加有序。

3.HTTP3.0是什么？

HTTP3.0是HTTP协议的最新版本，使用基于UDP的QUIC协议，可以实现类似TCP的可靠性传输。

无队头堵塞
更快建立连接
连接迁移

特点：

QUIC使用UDP协议来传输数据。一个连接上的多个stream之间没有依赖，如果一个stream丢了一个UDP包，不会影响后面的stream，不存在队头堵塞问题
零RTT连接建立：QUIC允许在后续重复连接时进行零往返时间连接建立，从而减少了连接延迟，加快了页面的加载速度。
连接迁移：QUIC允许网络切换时，将连接迁移到新的IP地址，从而减少了连接的中断时间(如从wifi到移动网络)
向前纠错机制：每个数据包除了他本身的内容外，还包括了部分其他数据包的数据，因此少量的丢包可以通过其他包的冗余数据直接组装而无序重传。向前纠错牺牲了每个数据包可以发送数据的上限，但是减少了因为丢包导致的数据重传。
安全性：HTTP3.0默认使用TLS加密，确保了数据的安全性。

2.12

1.HTTPS和HTTP有哪些区别?

HTTP是超文本传输协议，信息是明文传输，存在安全风险问题。而HTTPS在HTTP的基础上增加了SSL/TLS协议作为加密层，确保数据传输的安全性。
HTTP连接相对比较简单，在TCP三次握手之后便可以进行HTTP报文传输。而HTTPS在TCP三次握手后，还需要进行SSL/TLS的握手过才可以进入加密报文传输。
两者的默认端口号不一样，HTTP默认端口号是80，HTTPS默认端口号是443。
HTTPS协议需要向CA（整数权威机构）申请数字证书，来保证服务器的身份是可信的。

2.HTTPS的工作原理是什么？（HTTPS建立连接的过程）

混合加密的方式实现信息的机密性，解决了窃听的风险
摘要算法的方式来实现完整性，它能够为数据生成独一无二的指纹，用于校验数据的完整性，解决了篡改的风险
将服务器的公钥放在数字证书中，解决了冒充的风险

1.混合加密

在通信建立之前，采用非对称加密的方式交换[会话密钥]，后续就不再使用非对称加密。
在通信过程中全部使用对称加密的[会话密钥]的方式加密明文数据。

采用[混合加密]的方式的原因：

对称加密只是用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换
非对称加密使用俩个密钥：公钥和私钥，公钥可以任意分发，而私钥保密，解决了密钥交换问题但速度较慢

2.摘要算法+数字签名

为了保证传输的内容不被修改，需要对内容做出一个指纹，然后同内容一起传输给对方。

接收到后对内容也计算出一个指纹，然后对比指纹是否一样，如果相同，说明内容没有被修改，否则就可以判断出内容被修改了。

但是不能保证内容+哈希值不会被中间人替换，因为这里缺少对客户端收到的消息是否来源于服务端的证明。

为了避免这种情况，使用非对称加密算法：

公钥加密，私钥解密：保证信息不会被泄漏，只让想看的人看到消息。

私钥加密，公钥解密：保证消息的真实性，传输的消息是正版的不是盗版的。

非对称加密的用途，通过私钥加密+公钥解密的方式，来确认消息的身份，常说的数字签名算法，就是用的这种方式。

3.数字证书

服务器把自己的公钥注册到CA
CA使用自己的私钥将服务器的公钥数字签名并颁发数字整数
客户端拿到服务器的数字整数后，使用CA的公钥确认服务器的数字证书的真实性
从数字证书获取服务器公钥后，使用它对报文加密后发送
服务器用私钥对报文进行解密

HTTPS是如何建立连接的?期间交互了什么？

HTTPS主要基于SSL/TLS协议。确保了数据传输的安全性和完整性，其建立连接并传输数据的过程如下：

密钥交换：客户端发发起HTTPS请求后，服务器会发送其公钥证书给客户端
证书验证：客户端回验证服务器的证书是否由受信任的证书颁发机构(CA)签发，并检查证书的有效性
加密通信：一旦证书验证通过，客户端回生成一个随机的对称加密密钥，并使用服务器的公钥加密这个密钥，然后发送给服务器。
建立安全连接：服务器使用自己的私钥解密得到对称加密密钥，此时客户端和服务端就有了相同的密钥，可以进行加密和解密。
数据传输：使用对称加密密钥对所有传输的数据进行加密，确保数据在传输过程中的安全性。
完整性校验：SSL/TLS协议还包括消息完整性校验机制，如消息认证码，确保数据在传输过程中未被篡改
结束连接：数据传输完成后，通信双方会进行会话密钥的销毁，以确保不会留下安全隐患。

3.TCP和UDP的区别？

TCP是面向连接的协议，需要在数据传输前建立连接；UDP是无连接的，不需要建立连接。
TCP提供可靠的数据传输，保证数据包的属性呢和完整性；UDP不保证数据包的顺序和完整性
TCP具有拥塞控制机制，可以根据网络状况调整数据传输速率；UDP没有拥塞控制，发送速率通常固定
TCP通过滑动窗口机制进行流量控制，避免接收方处理不过来；UDP没有流量控制
TCP能够检测并重传丢失或损坏的数据包；UDP不提供错误恢复机制
TCP有复杂的报文头部，包含序列号、确认好等信息；UDP的报文头部相对接单。
由于TCP连接建立、数据校验和重传机制，其性能开销通常比UDP大；UDP由于简单，性能开销小。
适用场景：TCP适用于需要可靠传输的应用，如网页浏览、文件传输等；UDP适用于对实时性要求高的应用，如语音通话、视频会议等。

2.13

1.TCP连接如何确保可靠性

RTT指的是数据发送时刻到接收到确认的时刻的差值，也就是包的往返时间。

RT0是以超时重传表示的。

超时重传
快速重传
SACK方法，选择性确认
D-SACK（Duplicate）
滑动窗口
TCP每发送一个数据，都要进行一次确认应答。
流量控制（避免发送方的数据填满接收方的缓存，但是不知道网络中发生了什么
拥塞控制（从慢启动到拥塞避免，从指数增长变成了线性增长）

TCP通过差错控制（序列号、确认应答、数据校验）、超时重传、流量控制、拥塞控制等机制，确保了数据传输的可靠性和效率。

在发送方向接收方发送数据包时，每个发送的数据都会有一个序列号，以此保证传输数据包的顺序的正确性；
当接收方接收到数据时，会向发送方发送ACK确实信息，如果发送方在一点时间内没有收到确认就会重新发送数据。
这里可以使用超时重传，超时重传的时间RT0应该大于报文往返时间RTT的值，非诉讼放可以设置一个定时器，如果在定时器超时前没有收到ACK，就i可以重新发送数据。但是超时重传的超时周期可能相对来说比较长；
因此，TCP还有一种快熟重传的机制，不是以时间为驱动，而是使用数据作为驱动，当发送方连续三次收到相同的ACK确认时，就会重新发送相应的数据包。
但是快速重传也只是告诉我们丢失了数据，而没有告诉我们丢失了什么数据，因此这里还有一种重传机制，叫做SACK方法（选择性确认）。
这种重传机制，需要在TCP头部字段里加一个SACK，可以把接收到的数据信息发送给发送方，这样发送方就可以知道哪些数据收到了，哪些数据没有收到，知道了这些信息就可以只重新传输丢失的信息。
此外还出现了DSACK，可以告诉我们有哪些数据被重复接受了。
但是上述这些重传机制，还是比较低效的，因此在这里出现了滑动窗口机制，滑动窗口根据操作系统给定的缓存区的大小来确认可以发送和接收的数据量，不需要等待ACK，可以把滑动窗口中的数据连续发送
进而TCP可以通过滑动窗口机制进行流量控制，以此确保接收方能够处理发送方的数据量。
此外，为了根据网络拥塞程度来动态调整发送数据的数量，这里提出了拥塞窗口，这是发送方维护的一个状态遍历。此时发送窗口的大小为接收窗口和拥塞窗口的最小值。
拥塞窗口在网络中没有发生堵塞时，会一直变大，发送拥塞时，就会变小。变大时主要由慢启动算法和拥塞控制算法进行控制，可以由指数增长变为线性增长（前者没收到一个ACK拥塞窗口就会加一，后者在超过慢启动门限（SSTHRESH）时，增长量变为1/cwnd。
当拥塞发送时可以采用两种重传机制，超时重传和快速重传，但超时重传会一下进入解放前，将拥塞窗口大小设置为一，会导致网络卡顿，因此可以采用快速重传，cwnd=ssthresh，ssthresh=cwnd/2。进入快速恢复算法等来控制数据的发送速率，防止网络的拥塞。

2.既然提到了拥塞控制，那你能说说说拥塞控制是怎么实现的嘛

TCP拥塞控制可以在网络出现拥塞时动态的调整数据传输的速率，以防止网络过载。TCP拥塞控制主要在以下几个方面：

慢启动：初始阶段，TCP发送方会以较小的发送窗口开始传输数据。每次成功发送数据，并收到ACK确认信息时，发送方逐步增加发送窗口的大小，实现指数级别的增长，这称为慢启动。有助于网络在刚开始传输谨慎的逐步增加速率，以避免引发拥塞。
拥塞控制（拥塞避免）：当发送窗口达到阈值（即慢启动门限），TCP就会进入拥塞控制阶段。在拥塞控制阶段，发送方以线性的方式增加发送窗口的大小，而不再是指数级的增长。这有助于控制发送速率，避免引起网络拥塞。
超时重传，将拥塞窗口设置为初始值，会导致一下进入解放前，导致网络拥塞。因此可以采用快速重传
快速重传：如果发送方连续三次收到相同的ACK确认，他会认为发生数据包的丢失，并会快速重传未确认的数据包，而不必等待超时重传。这有助于更快地恢复由于拥塞引起地数据包丢失。
快速恢复：在快速重传后，TCP进入快速恢复阶段。在这个阶段，发送方不会回到慢启动阶段，而是将慢启动阈值设置为当前窗口的一半，并将拥塞窗口的大小设置为慢启动阈值加上已确认但未被快速重传的数据块的数量，这样有助于更快的从拥塞控制中恢复。

3.TCP流量控制是如何实现的？

流量控制就是让发送方发送的速率不要过快，让接收方来得及接收。利用滑动窗口机制就能实施流量控制，主要方法就是动态调整发送方和接收方之间数据传输速率。

接收方空间的大小是根据自己缓存区可用的空间进行动态调整确认的，当可用的缓存区空间发生改变时，接收方会动态的调整自己接收窗口的大小，而发送方会根据接收方窗口的大小，通过TCP报文段的窗口字段的值，动态的调整发送方窗口的大小，进而动态的调整发送数据的速率。当接收方的窗口大小增加，发送方可以加快发送的速率，当减小时，可以减缓发送数据的速率。并且在TCP通信过程中，并且TCP会为每个连接定时发送窗口探测，看发送方的窗口是否关闭，避免发生潜在的死锁现象。而流量控制的目的就是确保发送方不要发送超过接收方缓冲区容量的数据。如果接收方的缓冲区快满了，就会减小窗口的大小，通知发送方暂停发送，以防止溢出。
并且接收方可以通过不通告小窗口的大小给发送方和发送发开启Nagle算法，避免糊涂窗口综合征，更好的进行流量控制。

4.UDP怎么实现可靠传输？

TCP协议四个方面的缺陷：

升级TCP的工作很困难；
TCP建立连接的延迟；
TCP存在队头阻塞问题；
网络迁移需要重新建立TCP连接。

可以使用基于UDP协议实现的可靠传输协议QUIC协议，并且已经应用在了HTTP/3。

QUIC 是如何实现可靠传输的

TCP在重传报文的时候，原始报文和重传报文的序列号一样，会导致TCP重传的歧义问题，导致计算RTT是不准确，而RTO（超时时间）是根据RTT计算的，如果RTT计算不准确，RTO就会计算不准确，就会导致重传的概率事件增大。
而在QUIC报文中的Packet Number是严格递增的，及时重传报文，也是递增的，因此可以精确计算出报文的RTT。
并且由于QUIC采取Packet Number单调递增的设计，可以让数据包不再像TCP那样必须有序确认，QUIC支持乱序确认，当数据包Packet N丢失后，只要有新的已接收数据包确认，当前窗口就会继续向右滑动。
并且对重传的数据包处理和发送新的数据包一样，这样就不会因为丢包重传将当前窗口阻塞再原地，从而解决了队头阻塞问题。
- Packet Number单调递增的好处：
  - 可以更加精确的计算RTT，没有TCP重传的歧义性问题；
  - 可以支持乱序确认，不会因为丢包重传将当前窗口阻塞在原地，而TCP必须是顺序确认的，丢包时会导致窗口不滑动。
引入Frame Header这一层，通过Stream ID +Offset字段信息实现数据的有序性，通过比较数据包的Stream ID与Stream Offset，如果是一致的，就说明这两个数据包的内容一致。
- QUIC通过单向递增的Packet Number，配合Stream ID 和 Offset字段信息，可以支持乱序确认而不影响数据包的正确组装，摆脱了TCP必须按顺序确认应答ACK的限制，解决了TCP因某个数据包重传而阻塞后序所有待发送数据包的问题。

队头阻塞问题的解决

什么是HTTP队头阻塞问题？就是TCP协议中，接收方接收到的数据必须是有序的，如果接收到2-30字节的数据，但是没有收到第一个字节的数据，这些数据也没办法被读取到应用层，窗口就会停留，使得应用层无法读取到新的数据。
HTTP/2队头阻塞：在HTTP/2的连接上，不同Stream的帧可以乱序发送(因此可以并发不同的Stream)，因为每个帧会携带Stream ID信息，所以接收端可以通过Stream ID有序组装成HTTP消息，而同一Stream内部的帧必须是严格有序的。
但是HTTP/2的多个Stream请求都是在同一条TCP连接上传输的，多个Stream就会公用同一个TCP滑动窗口，当Stream内部的帧丢失时，就会发生TCP队头层的阻塞。
QUIC则可以并发发送多个Stream，并且给每一个Stream都分配了一个独立的窗口，彼此之间都没有依赖关系，都是相互独立的，各自控制滑动窗口，不存在队头阻塞问题。

QUIC如何做到流量控制？

TCP流量控制是让接收方告诉发送发，接收方的接收窗口有多大，从而让发送方根据接收方的实际接收能力控制发送的数据量。

QUIC实现流量控制：

通过window_update帧告诉对端自己可以接收的字节数，这样发送方就不会发送超过这个数量的数据
通过BlockFrame告诉对端由于流量控制被阻塞了，无法发送数据

stream级别的流量控制：一个Stream就是一条HTTP请求，每个Stream都有独立的滑动窗口，所以每个Stream都可以做到流量控制，防止单个Stream消耗连接的全部接收缓冲
Connection流量控制：限制连接中所有Stream相加起来的总字节数，防止发送方超过连接的缓冲容量

Stream级别流量控制：

TCP的接收窗口只有在前面所有的Segment都接收的情况下才会移动左边界，当在前面还有字节未接收，但收到后面字节的情况下，窗口也不会移动。

QUIC的接收窗口的左边界滑动条件取决于接收到的最大偏移字节数。

什么时候右滑？当已收到并已被上层读取到的数据超过最大接收窗口的一半时。

最大绝对字节偏移量是控制数据发送的唯一限制，该值是基于当前已提交的偏移量（连续已确认并向上层应用提交的数据包offset）和发送方协商得出。

Connection流量控制

就是所有Stream可用窗口之和

QUIC对拥塞控制改进

默认使用了tcp的拥塞控制算法（慢开始、拥塞避免、快重传、快恢复策略）

QUIC基于应用层，不需要操作系统和内核支持，可以随着浏览器的更新而更新，拥塞控制算法可以有较快的迭代速度。

QUIC更快的建立连接

对于HTTP/1和HTTP/2，tcp和TLS是分层的，分别属于内核实现的传输层、oppenssl库实现的表示层，需要分批次握手，TCP握手、TLS握手，在不用Session会话服务的情况下，至少需要2个RTT。

而HTTP/3传输钱虽然需要QUIC协议握手，但是这个握手过程只需要1RTT，握手的目的是为确认双方的连接ID，连接迁移就是基于连接ID实现的。

HTTP/3的QUIC协议并不与TLS分层，QUIC内部包好了TLS，第二次连接时，应用数据包可以和QUIC握手信息（连接信息和TLS信息）一起发送，达到0-RTT的效果。

QUIC如何迁移连接的？

基于TCP传输协议的HTTP协议，由于是通过四元组（源IP、源端口、目的IP、目的端口）确定一条TCP连接。

那么当移动设备的网络从4G切换到wifi时，就意味着IP地址变化了，那么就必须要断开连接，重新建立TCP连接）。而QUIC通过连接ID来标记通信的两个端点，客户端和服务段各自选用一组ID来标记自己，就能无缝的复用原连接，消除重连的成本，没有丝毫卡顿。

参考答案：

UDP它不属于连接型协议，因而具有资源消耗小，处理速度快的优点，所以通常音频、视频和普通数据在传送时使用UDP较多，因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。关键在于两点，从应用层角度考虑：

（1）提供超时重传，能避免数据报丢失。

（2）提供确认序列号，可以对数据报进行确认和排序。

本端：首先在UDP数据报定义一个首部，首部包含确认序列号和时间戳，时间戳是用来计算RTT(数据报传输的往返时间)，计算出合适的RTO(重传的超时时间)。然后以等-停的方式发送数据报，即收到对端的确认之后才发送下一个的数据报。当时间超时，本端重传数据报，同时RTO扩大为原来的两倍，重新开始计时。

对端：接受到一个数据报之后取下该数据报首部的时间戳和确认序列号，并添加本端的确认数据报首部之后发送给本端。根据此序列号对已收到的数据报进行排序并丢弃重复的数据报。

UDP如何实现可靠传输（QUIC协议）总结

重传机制与准确的RTT计算：
- QUIC使用严格递增的包序号（Packet Number），即使在重传时也会使用新的序号。这种设计消除了TCP在重传时可能出现的序号歧义，使得每个数据包都有唯一的标识。
- 通过准确的包序号，QUIC可以精确计算RTT（往返时间），从而优化RTO（重传超时时间）。这种机制提高了重传的效率，降低了因超时引发的错误重传概率。
支持乱序确认：
- QUIC允许数据包的乱序接收和确认，这意味着即使某些包丢失，只要新的数据包被接收，窗口也可以继续滑动。这与TCP的顺序确认机制形成鲜明对比，后者在丢包时会阻塞后续的数据处理。
- 这种设计提高了数据传输的灵活性和效率，特别是在网络条件不稳定的情况下。
Frame Header与数据有序性管理：
- QUIC通过Stream ID + Offset字段组合来管理数据的顺序和完整性。每个数据流都有唯一的Stream ID，配合Offset字段，确保数据的正确组装。
- 即使数据包乱序到达，接收方也可以根据这些信息重新排列数据，确保应用层能够接收到完整的信息。
消除队头阻塞：
- 在TCP中，队头阻塞问题是由于所有数据包必须按序接收造成的，即使后续数据包已到达，前面的丢失包也会导致阻塞。QUIC通过允许多个独立的Stream并行处理数据，消除了这一问题。
- 每个Stream有独立的流量控制和滑动窗口，彼此之间没有依赖关系，这样即使某个Stream中发生丢包，其他Stream仍然可以继续传输数据。
流量控制机制：
- QUIC实现了更灵活的流量控制，通过window_update帧告知对方当前可接收的字节数。这样可以有效避免发送方发送超过接收能力的数据。
- QUIC支持Stream级别和Connection级别的流量控制，确保单个Stream不会消耗连接的全部缓冲容量，提升整体性能。
快速建立连接：
- QUIC的握手过程只需1 RTT，且通过集成TLS，第二次连接时可以实现0-RTT。这减少了连接建立的延迟，提高了用户体验。
- QUIC的设计允许在首次连接时就协商必要的连接参数，从而使后续的连接更快。
连接迁移能力：
- QUIC使用连接ID来标识通信双方，支持在移动设备切换网络时（如从4G切换到Wi-Fi）无缝迁移连接。这样即使IP地址发生变化，连接仍然保持活跃，避免了重连带来的延迟和卡顿。
- 通过连接ID的标识，QUIC能够在不同网络之间平滑过渡，确保持续的数据传输。

核心要点总结

递增包序号：消除重传歧义，提高RTT计算准确性。
乱序确认支持：提高传输灵活性，避免队头阻塞。
Frame Header管理：确保数据有序性，增强数据完整性。
独立流量控制：多Stream并行处理，提升整体性能。
快速连接建立：减少握手延迟，改善用户体验。
连接迁移能力：支持网络切换，保持连接稳定。

这些要点展示了QUIC如何在UDP上实现可靠的传输，同时克服了TCP的多项限制。

2.14

1.TCP连接三次握手的过程，为什么是三次，可以是两次或者更多吗？

三次握手的过程：

第一次握手：客户端向服务端发送一个SYN(同步序列编号)报文，请求建立连接，客户端就进入SYN_SENT状态。
第二次握手：服务端接收到SYN报文后，如果同意建立连接，就会发送一个SYN_ACK(同步确认报文)作为响应，同时进入SYN_RCVD状态。
第三次握手：客户端收到服务器的SYN_ACK报文后，会发送一个ACK确认报文作为最终的响应，之后客户端和服务器都进入ESTABLISHED状态，连接建立成功。

为什么要进行三次握手？

通过三次握手，客户端和服务端都能够确认对方的接收和发送能力。第一次握手确认了客户端到服务器的通道是开放的，第二次握手确认了服务端到客户端的通道是开放的。第三次握手确认了客户端能接收到服务器的确认，从而确保了双方的通道都是可靠的。

如果仅仅进行两次握手，当客户端发送SYN延迟后，会重新发送SYN，当这次顺利到达，并且服务端成功响应建立连接。如果此时延迟的SYN到达后，服务端就会认为这是客户端又发来了一个连接，此时，服务端认为有两个连接，而客户端认为只有一个连接，造成双方的状态不同步。

而如果是三次握手，客户端认为自己没有发送第二次连接，就不会发送ACK，就不会建立两次连接，可以同步双发的状态。

而四次或更多的连接是可以的，但是可以优化为三次握手，比如在服务端接收到消息响应的时候可以把自己的同步序列编号和对客户端发送过来的SYN的响应一同发送给客户端，这时，四次握手就变成了三次握手。

2.TCP连接四次挥手的过程，为什么是四次？

四次挥手的过程：

第一次挥手：客户端发送一个FIN报文给服务端，表示自己要断开数据传送，报文中会指定一个序列号（seq=x）。然后客户端进入FIN_WAIT-1状态。
第二次挥手：服务端收到FIN报文后，回复ACK给客户端，且把客户端的序列号seq+1，作为ACK报文的序列号，然后服务端进入CLOSE_WAIT(seq=x+1)状态，客户端进入FIN-WAIT-2状态。
第三次挥手：服务端也要断开连接，发送FIN报文给客户端，指定一个序列号seq=y+1，随后进入LAST_ACK状态。
第四次挥手：客户端收到FIN报文后，发出ACK报文进行应答，并把服务端的序列号值加一作为ACK报文的序列号，此时，客户端进入TIME_WAIT状态。服务端在收到客户端的ACK报文后进入CLOSE状态。如果客户端等待2MSL没有收到回复，才会关闭连接。

为什么要进行四次挥手：

比如说两个人要通过面对面射击的方式清空弹夹，但是也要保证双方的安全。第一个人告诉你我要开枪了，等到第二个人说：你开枪吧，然后第一个人才开枪。现在轮到第二个人清空弹夹了，第二个人也要告诉第一个人他要开枪了，第二个人回复你开枪吧，然后第二个人才开枪。如果仅仅三次，第二个人就无法确保第一个人的安全。

TCP是全双工通信，可以双向传输数据。任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，就发出连接释放通知，对方确认后才会完全关闭TCP连接。因此两次挥手可以释放一端到另一端的TCP连接，完全释放连接一共需要四次挥手。

只有通过四次挥手，才可以确保双方都能接收到对方的最后一个数据段的确认，主动关闭方在发送完最后一个ACK后进入TIME_WAIT状态，这是为了确保被动关闭方能够收到最后一个ACK，如果被动关闭方没有收到，就可以重新发送FIN博文，主动关闭方可以再次发送ACK。

如果仅仅进行三次挥手，被动关闭方可能在发送最后一个数据段后立即关闭连接，而主动关闭方可能还没有接收到这个数据段的确认。

3.HTTP的Keep-Alive是什么？TCP 的 Keepalive 和 HTTP 的 Keep-Alive 是一个东西吗？

HTTP的Keep-Alive，是由应用层实现的，称为HTTP长连接，每次请求都要经历这样的过程：建立TCP连接–HTTP请求资源–响应资源–释放连接，这就是HTTP短连接，但是这样每次建立连接都只能请求一次资源，所以HTTP的Keep-Alive实现了使用同一个TCP连接来发送和接收多个HTTP请求/应当，避免了连接建立和释放的开销，这就是HTTP长连接。通过设置HTTP头Connection：keep-alive来实现。

并且在HTTP1.0中默认是关闭的，如果浏览器要开启Keep-Alive，就必须在请求的包头中添加：Connection：keep-alive。当服务器收到请求时，作出回应时，他也会添加一个头在响应中。

而从HTTP1.1开始，浏览器中的Keep-Alive都是默认打开的。一旦客户端和服务端达成协议，那么长连接就建立好了。如果想要关闭它，就需要在头部添加Connection:close。

但是为了避免资源浪费的情况，web服务软件一般会提供keepalive_timeout参数，用来指定HTTP长连接的时间，如果在设置时间内，都没有发起新的请求，定时器时间一到，就会触发回调函数来释放该连接。

TCP的Keepalive就是TCP的保活机制，如果两端的TCP连接一直没有数据交互，达到了触发保活机制的条件，那么内核里的TCP协议栈就会发送探测报文。

如果对端程序是正常工作的，当TCP保活探测报文发送给对端，对端会正常响应，这样TCP保活时间就会被重置，等待下一个TCP保活时间的到来，而不是持续发送探测包，减少网络流量和资源消耗。
但是如果对端主机宕机，或对端由于其他原因导致报文不可达。当TCP保活的探测报文发送给对端后，石沉大海，没有响应，连续几次，达到保活探测次数后，TCP就会报告该TCP连接已经死亡。

应用程序若想使用TCP保活机制，需要通过socket接口设置SO_KEEPALIVE选项才能够生效，如果没有设置，那么就无法使用TCP保活机制。

2.15

1.DNS查询过程

DNS用来将主机名和域名转换为IP地址，其查询过程一般遵循以下步骤：

本地DNS缓存检查：首先查询本地DNS缓存，如果缓存中有对应的IP地址，则直接返回结果。
如果本地缓存中没有，则会向本地的DNS服务器(通常由互联网服务提供商(ISP)提供，比如中国移动)发送一个DNS查询请求
如果本地DNS解析器有该域名的ip地址，就会直接返回，如果没有缓存该域名的解析记录，他就会向根DNS服务器发出查询请求。根DNS服务器并不负责解析域名，但它能告诉本地DNS解析器应该向哪个顶级域(.com/.net/.org)的DNS服务器继续查询。
本地解析器接着指向指定的顶级域名DNS服务器发出查询请求。顶级域名DNS服务器也不负责具体的域名解析，但是他能告诉本地DNS解析器应该前往哪个权威DNS服务器查询下一步的信息。
本地DNS解析器最后向权威DNS服务器发送查询请求。权威DNS是负责存储特定域名和IP地址映射的服务器。当权威DNS服务器收到查询请求时，他会查找"example.com"域名对应的IP地址，并将结果返回给本地DNS解析器。
本地DNS解析器将收到的IP地址返回给浏览器，并且还会将域名解析结果缓存在本地，以便下次访问时更快地响应。
浏览器发起连接：本地DNS解析器已经将IP地址返回给计算机，浏览器就可以使用该IP地址与目标服务器建立连接，开始获取网页内容。

2.CDN是什么？有什么作用？

CDN是一种分布式网络服务，通过将内容存储在分布式的服务器上，使用户可以从距离较近的服务器获取所需的内容，从而加速互联网上的内容传输。

就近访问：CDN在全球范围内部署了多个服务器节点，用户的请求会被路由到距离最近的CDN节点，提供快速的内容访问。
内容缓存：CDN节点会缓存静态资源，如图片、样式表、脚本等。当用户请求访问这些资源时，CDN会首先检查是否已经缓存了该资源。如果有缓存，CDN节点会直接返回缓存的资源，如果没有缓存所需要的资源他就会从源服务器（原始服务器）回源获取资源，并将资源缓存到节点中，以便以后的请求。通过缓存内容，减少了对原始服务器的请求，减轻了源站的负载。
可用性：即使某些节点出现问题，用户请求可以背重定向到其他健康的节点。

3.Cookie和Session是什么？有什么区别？

Cookie和session是什么？

Cookie和Session都用于管理用户的状态和身份，Cookie通过在客户端记录信息确认用户身份，Session通过在服务器端记录信息确认用户身份。

Cookie
- 通常，服务器会将一个或多个Cookie发送到用户浏览器，然后浏览器将这些Cookie存储在本地。
- 服务器在接收到来自客户端浏览器的请求之后，就能够通过分析存于请求头的Cookie得到客户端特有的信息，从而动态生成与该客户端相对应的内容。
Session
- 客户端在访问服务器的时候，服务器就会把客户端的信息以某种形式记录在服务器上。这种存储的形式就是session。session主要用于维护用户登录状态、存储用户的临时数据和上下文信息等。服务器为每个用户分配一个唯一的Session ID，通常存储在Cookie中。

Cookie和Session的区别？

存储位置：Cookie数据通常存储在客户端（浏览器）中，而Session数据存储在服务器上。
数据容量：Cookie的容量较小，一般为几kb。Session存储容量较大，通常没有固定的限制，而是取决于服务器的配置和资源。
安全性：由于Cookie存储在用户浏览器中，因此可以被用户读取和篡改。相比之下，Session数据存储在服务器上，更难被用户访问和修改。
生命周期（过期机制）：Cookie可以通过设置具体的过期时间来控制，而Session会依赖于会话的持续时间（会话超时或浏览器关闭）
传输方式：Cookie在每次HTTP请求中都会被自动发送到服务器，而Session ID通常通过Cookie或URL参数传递。

JAVA八股—计算机网络（自用）