面试计网向

请求方法	描述	幂等性
GET	客户端向服务器端发出获取资源请求（获取页面、图片、文档等资源）	是
POST	客户端向服务器提交数据（提交表单数据、上传文件等）	否
PUT	在服务器上创建或更新资源（向URL指定资源提交数据）	是
DELETE	删除服务器上的资源	是
PATCH	对服务器上的资源进行局部更新	否
HEAD	类似于GET请求，但只返回响应头部信息（资源元信息），不返回实际的资源内容	是
OPTIONS	获取服务器支持的请求方法列表，以及针对特定资源的其他功能选项	是
TRACE	用于回显服务器收到的请求，主要用于诊断和调试	是

POST和GET区别：

特点	GET	POST
数据传输方式	通过URL参数传递数据	通过请求体传递数据
参数数据类型	只接受ASCII字符	无数据类型限制
数据可见性	参数数据附加在URL上，可见	数据不会直接显示在URL上，不可见
数据安全性	相对较低，数据以明文形式传输且可被缓存、截获、篡改	相对较高，数据以请求体方式传输，无缓存模式（除非手动设置缓存），不易被篡改和缓存
请求语义	获取服务器上的资源	向服务器提交数据，执行操作
幂等性	是	否
数据大小限制	URL长度有限制，传输较小的数据	理论可传输较大数据量，但服务器可能有限制
缓存	请求可以被缓存	请求一般不会被缓存

状态码：

状态码	含义
1xx	接受的请求正在处理（信息性状态码）
101	切换请求协议，从 HTTP 切换到 WebSocket
2xx	请求正常处理完毕（成功状态码）
200	请求成功，表示正常返回信息
3xx	重定向状态，需要重新请求
301	永久重定向，会缓存，资源有效，返回新位置的内容
302	临时重定向，不会缓存，资源失效，返回临时代替页
4xx	服务器无法处理请求（客户端发送报文有误错误状态码）
400	请求错误
403	服务器禁止访问
404	找不到与 URI 相匹配的资源
5xx	服务器处理请求出错（服务端内部出错错误状态码）
500	常见的服务器端错误

什么是http无状态请求：

特点	描述
请求隔离	每个HTTP请求都是独立的，服务器不会将请求与其他请求关联。服务器处理后不会保留相关的状态信息。多个请求相对透明
无法跟踪状态	服务器无法自动识别同一个客户端发送的多个请求之间的关系。服务器无法知道请求是否来自同一个客户端。无请求历史，多请求相对透明
会话管理	由于无状态性，通常需要使用会话管理机制（如Cookie或会话标识符）来在多个请求之间跟踪和识别客户端。实现有状态应用程序行为。
优点	无状态性使服务器简单、可扩展, 减轻服务器负担, 更容易扩展应对高负载和大规模的请求。

小情景：

特点	有状态	无状态	使用Cookie维护状态
对话示例	A：今天吃啥子？ B：罗非鱼！ A：味道怎么样呀？B：还不错，好香。	A：今天吃啥子？ B：罗非鱼！ A：味道怎么样呀？ B：？啊？什么鬼？啥味道？	A：今天吃啥子？ B：罗非鱼 A：你今天吃的罗非鱼味道怎么样呀？ B：还不错，好香。

特点

有状态

无状态

使用Cookie维护状态

对话示例

A：今天吃啥子？

B：罗非鱼！

A：味道怎么样呀？B：还不错，好香。

A：今天吃啥子？

B：罗非鱼！

A：味道怎么样呀？

B：？啊？什么鬼？啥味道？

A：今天吃啥子？

B：罗非鱼

A：你今天吃的罗非鱼味道怎么样呀？

B：还不错，好香。

HTTP1.0,1.1,2.0:

特点	HTTP 1.0	HTTP 1.1	HTTP 2
连接方式	短连接，每次请求建立一个TCP连接,(可以设置connection:keep-alive)	长连接，默认TCP连接不关闭，可复用多个请求	长连接，默认TCP连接不关闭，支持多路复用
安全性	明文传输	增加了cookie等验证措施	利用hpack将验证措施压缩一般用https建立连接请求。
管道机制	不支持	支持管道机制, 允许同一TCP连接中发送多个请求	不支持，使用多路复用替代
缓存控制	控制较弱，缓存策略有限	引入更多的缓存控制策略，如Cache-Control等	支持更强大的缓存控制策略，提供更精细的缓存管理
错误状态管理	有限的错误状态响应码	新增了24个错误状态响应码	无变化
多路复用	不支持	不支持	支持，一个链接允许同时发送多个请求或回应
服务端推送	不支持	不支持	支持，服务器可主动向客户端推送资源
传输方式	文本协议	文本协议	二进制传输，减少传输数据的大小和解析的复杂性
性能与效率	相对较低	较高	更高，多路复用和二进制传输提高了性能和效率

管道机制：

特点	描述
定义	HTTP/1.1管道机制是一种优化HTTP请求-响应的机制，允许在单个TCP连接上并行发送多个请求。
作用	减少延迟，提高性能，通过在同一连接上连续发送多个请求来充分利用TCP连接的带宽。
问题	服务器和客户端都必须支持管道机制，存在兼容性问题。
并发请求	客户端可以在发送第一个请求后立即发送下一个请求，无需等待响应。
顺序响应	服务器按照请求的顺序依次返回响应，确保客户端正确处理每个请求的响应。

长连接实现：

TCP的长连接：TCP保持一段时间不关闭，复用一个TCP发起多次请求，减少资源消耗

对于HTTP1.0，默认短连接，若想进行长连接 connection：keep-alive
对于HTTP1.1，默认长连接

长连接超时：

在HTTP中有HTTPD守护进程，设置keep-alive timeout，即超出时间会关闭。

参数	含义	默认值	作用
tcp_keepalive_intvl	TCP发送保活探测报文的间隔时间	2小时	用于检测空闲连接是否仍然有效，保持长时间空闲的连接不被断开
tcp_keepalive_probes	TCP保活机制发送保活探测报文的尝试次数	9次	当连接空闲时，发送多个保活探测报文来判断连接是否仍然有效
tcp_keepalive_time	TCP连接空闲时间的阈值	2小时	用于判定连接是否处于空闲状态，超过该时间将启动保活机制发送探测报文

intvl 长连接保活探测间隔（采样间隔）
probes 长连接允许一直探测不到的次数（检测失败阈值）
time 长连接容许一直空闲的时间（最大空闲作用时间）

小情景：

A: 听到吗？

B：...

A: 好，一次了奥

（过了一段时间intvl）

A: 听到吗？

B: ...

A: 好，两次了奥

（过了probes次）

A: 听到吗？

B: ...

A: 再见断连接

TCP 的 keepalive，以及和 HTTP 的 keepalive 的区别：

名称

描述

作用

HTTP Keep-Alive

在HTTP请求头中添加Connection: keep-alive字段，用于在一次TCP连接中持续发送多份数据

减少TCP连接建立次数，提高性能和吞吐量

重点 一次TCP连接可以支持多次请求服务

TCP Keepalive

在连接空闲一段时间后主动发送空数据包来检测连接的可用性，及时关闭不活动的连接，避免长时间无效占用系统资源。

重点 保活检测机制

HTTP请求转发和重定向的区别：

HTTPS,HTTP区别：

SSL : 网络通信提供安全及数据完整性的一种安全协议.

HTTPS = HTTP + SSL（安全套接层协议）/TLS（SLL3,0 加强版 = 安全传输层协议）(证书）

特点	HTTP	HTTPS
安全性	传输的数据是明文的，不提供加密保护	传输的数据经过加密，使用SSL/TLS协议提供更高的安全性
数据传输方式	明文传输	加密传输
端口号	默认使用端口号80	默认使用端口号443
证书	不需要证书	需要使用SSL/TLS证书进行安全连接的建立
URL前缀	以"http://"开头	以"https://"开头
连接建立过程	不需要进行握手和身份验证	需SSL/TLS握手过程，包括证书验证,密钥交换和协商加密等
性能	相对较快	略慢一些，因为加密和解密过程需要消耗计算资源

HTTPS向服务器请求数据流程：

步骤	描述
1	用户在浏览器里输入HTTPS网址，连接到服务器的443端口（默认的HTTPS端口）。
2	服务器必须拥有一套数字证书，包含公钥和私钥。服务器可以自己制作自签名证书或向CA申请证书。服务器将自己的数字证书（含公钥）发送给客户端。
3	客户端收到服务器端的数字证书（CA），验证证书的有效性和真实性。如果不通过，则弹出警告框。
4	客户端生成一个随机的对称密钥（会话密钥），并使用服务器的公钥对其加密，发送给服务器。
5	服务器使用自己的私钥对客户端发来的加密会话密钥进行解密，得到客户端生成的会话密钥。
6	服务器和客户端现在都拥有相同的会话密钥，用于后续通信的对称加密和解密。
7	服务器使用会话密钥对返回的数据进行对称加密，然后发送给客户端。
8	客户端接收到加密后的数据，使用会话密钥进行解密，得到服务器返回的原始数据。

小情景：

客：请求
服：ok给你密卡
客：我看看密卡有问题吗？ok，给你我的解密卡，用你的密卡加密了昂
服：用我的私有密卡解密下，OK, 你的解密卡我也有了, 给你加密数据（加密形式:客户端的）
客：哦？收到了，我解密试试，okk原始数据get

对称加密与非对称加密：

特点	对称加密	非对称加密
密钥类型	使用相同的密钥进行加密和解密	使用一对密钥，包括公钥和私钥
加密/解密过程（速度）	加密和解密过程非常高效	加密和解密过程较复杂，相对较慢
密钥管理	需要确保密钥的安全性	公钥可公开发布，私钥保密保存
安全性	密钥泄漏会导致数据不安全	提供更高的安全性，不需要共享密钥
适用范围	适用于大量数据的加密和解密操作	适用于少量数据的加密和解密操作

数据签名与数据证书：

为防止建立HTTPS连接时服务端发送公钥被篡改，增加CA验证流程。

数字签名带有对消息摘要的私钥加密信息

从浏览器地址栏输入url到显示主页的过程：

DNS解析，查找真正的ip地址
与服务器建立TCP连接（TCP -> IP -> OSPF（ip路由协议网络层协议） -> ARP（物理地址转换协议） -> HTTP（访问页面协议））
客户端发送HTTP请求
服务器处理请求并返回HTTP报文
浏览器html解析渲染页面
下载页面资源
连接结束

（跨站脚本攻击）XSS攻击：

指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意攻击用户的特殊目的。

XSS攻击一般分三种类型：存储型、反射型、DOM型XSS

全网最详细XSS跨站脚本攻击，不是过来打死我!! 反射型xss

全网最详细XSS跨站脚本攻击，不是过来打死我!!

跨站请求伪造CSRF攻击：

攻击者盗用了你的身份，以你的名义发送恶意请求。

跟跨网站脚本（XSS）相比，XSS 利用的是用户对指定网站的信任，

CSRF 利用的是网站对用户网页浏览器的信任。

Tom 登陆银行，没有退出，浏览器包含了Tom在银行的身份认证信息。
黑客Jerry将伪造的转账请求，包含在在帖子
Tom在银行网站保持登陆的情况下，浏览帖子
将伪造的转账请求连同身份认证信息，发送到银行网站
银行网站看到身份认证信息，以为就是Tom的合法操作，最后造成Tom资金损失。

解决方法：

HTTP请求头的referer信息段
请求令牌（token）：session中返回给客户端的token，隐藏保存与客户端，客户端每次请求都会带token，服务器每次根据token验证请求的合法性

forward 和 redirect 的区别：

转发方式	描述
直接转发方式（Forward）	客户端和浏览器只发出一次请求，Servlet、HTML、JSP或其它信息资源，由第二个信息资源响应该请求，在请求对象request中，保存的对象对于每个信息资源是共享的。通过服务器端内部的跳转，将请求转发到另一个资源，用户浏览器并不知道发生了转发。
间接转发方式（Redirect）	实际是两次HTTP请求，服务器端在响应第一次请求的时候，让浏览器再向另外一个URL发出请求，从而达到转发的目的。通过服务器端返回的302状态码，告知浏览器发起新的请求。

小情景：

A ：B借我点钱

B：我没有

于是B找C帮A借钱

A ：B借我点钱

B：我没有,你找C借去

A ：C借我点钱

C：拿走

session cookie机制：

session与cookie的区别

特点	Session	Cookie
定义	服务器端的用户状态管理机制	服务器发送到客户端内存储的小数据片段
存储位置	服务器端	客户端（浏览器）
信息安全	相对较安全，在服务器端	相对不安全，在客户端
存储容量	无限制	有限制，一般不超过4KB
存储周期	与用户会话相关，通常会话结束后自动失效	可设置过期时间，长期存储
传输方式	通过Session ID在客户端和服务器之间传递	通过HTTP请求头在客户端和服务器之间传递
实现方式	由服务器生成和管理	由服务器在HTTP响应中发送给浏览器，并由浏览器存储

session建立流程

步骤	描述
1. 客户端发送请求	用户通过浏览器向服务器发送请求，请求访问Web应用。
2. 服务器创建Session（包含8）	服务器接收到客户端的请求后，检查请求中是否包含有效的Session ID。如果没有有效的Session ID，服务器创建新的Session。
3. 生成Session ID	服务器生成一个唯一的Session ID，通常是一个随机字符串。
4. 返回Session ID	服务器将生成的Session ID通过HTTP响应的Set-Cookie头发送给客户端，保存在浏览器的Cookie中。
5. 客户端保存Session ID	浏览器保存服务器返回的Session ID，通常通过Cookie或其他方式保存。
6. Session数据存储	服务器将Session数据存储在内存或持久化存储中，用于记录用户的状态信息和其他需要保存的数据。
7. Session ID传递	客户端在后续的请求中通过Cookie或URL参数发送保存的Session ID，以便服务器识别用户的Session。
8. 服务器验证Session ID	服务器接收到客户端请求后，验证Session ID的有效性，获取相应的Session数据，根据需要更新或使用这些数据。
9. 会话结束	当用户关闭浏览器或超过一定的空闲时间。 Session会自动过期，服务器释放相应资源。用户再次访问需重新创建新的Session。

小情景：

a第一次来店，b：您是会员吗，我看下哈，哟不是，我给你办个卡（session），把你的名字告我（cookie），b把会员卡给a了（返回session ID，浏览器保存session ID），a体验完b店（数据存储），走了下次来，b在验证一遍会员的事（session ID传递和验证），如果会员卡到期了或者a去别的地方了不来了，会员卡就失效嘟（会话结束）

TCP（传输控制协议（传输层协议）：

TCP的头部结构：

16位端口号：源端口号，主机该报文段是来自哪里；目标端口号，要传给哪个上层协议或应用程序
32位序号：一次TCP通信（从TCP连接建立到断开）过程中某一个传输方向上的字节流的每个字节的编号。
32位确认号：用作对另一方发送的tcp报文段的响应。其值是收到的TCP报文段的序号值加1。
4位头部长度：表示tcp头部有多少个32bit字（4字节）。因为4位最大能标识15，所以TCP头部最长是60字节。
6位标志位：URG(紧急指针是否有效)，ACk（表示确认号是否有效），PSH（缓冲区尚未填满），RST（表示要求对方重新建立连接），SYN（建立连接消息标志接），FIN（表示告知对方本端要关闭连接了）
16位窗口大小：是TCP流量控制的一个手段。这里说的窗口，指的是接收通告窗口。它告诉对方本端的TCP接收缓冲区还能容纳多少字节的数据，这样对方就可以控制发送数据的速度。
16位校验和：由发送端填充，接收端对TCP报文段执行CRC算法以检验TCP报文段在传输过程中是否损坏。注意，这个校验不仅包括TCP头部，也包括数据部分。这也是TCP可靠传输的一个重要保障。
16位紧急指针：一个正的偏移量。它和序号字段的值相加表示最后一个紧急数据的下一字节的序号。因此，确切地说，这个字段是紧急指针相对当前序号的偏移，不妨称之为紧急偏移。TCP的紧急指针是发送端向接收端发送紧急数据的方法。
TCP协议详解（一）：TCP头部结构_urgent pointer_听风ing的博客-优快云博客

3次握手 4次挥手：

步骤	描述
三次握手	TCP连接的建立过程，确保客户端和服务器之间建立可靠的通信。
第一步（SYN）	客户端向服务器发送一个带有SYN标志的请求，表示客户端请求建立连接。
第二步（SYN+ACK）	服务器收到客户端的请求后，向客户端发送一个带有SYN和ACK（确认）标志的响应，表示服务器同意建立连接。
第三步（ACK）	客户端收到服务器的响应后，再次向服务器发送一个带有ACK标志的确认，表示客户端接受了服务器的同意请求，连接成功建立。

步骤	描述
四次挥手	TCP连接的关闭过程，确保客户端和服务器之间连接的顺利关闭和资源释放。
第一步（FIN）	客户端发送一个带有FIN标志的请求，表示客户端要关闭连接。
第二步（ACK）	服务器收到客户端的关闭请求后，向客户端发送一个带有ACK标志的确认，表示服务器已收到客户端的关闭请求。服务器进入关闭等待过程 CLOSE_WAIT，客户端接到ACK后进入FIN-WAIT
第三步（FIN）	服务器向客户端发送一个带有FIN标志的请求，表示服务器也要关闭连接。
第四步（ACK）	客户端收到服务器的关闭请求后，向服务器发送一个带有ACK标志的确认，表示客户端已收到服务器的关闭请求，连接成功关闭客户端发出断连确认包后进入TIME-WAIT（2MSL，即确定服务器收到断连信号）后进入CLOSED状态服务器收到断连确认包进如CLOSED状态

通过三次握手，TCP连接的双方建立起通信，开始数据传输。
通过四次挥手则是在数据传输结束后，双方关闭连接，释放资源。

这样的连接建立和关闭过程，保证了数据传输的可靠性和完整性。

小情景：

A : 请求连接 SYN

B : 同意连接 SYN + ACK

A : 收到B的同意连接信号咯！ ACK

为啥不能两次或四次握手：

解：2次握手拟化场景 -> a：我喜欢你 b:我知道了我也喜欢你（a不知道收没收到b的回复，可能断网了，可能收到了但是a没告诉b，b也不知道a到底知不知道）

4次握手场景：-> a:我喜欢你 b：我知道廖，我也喜欢你 a：嘻嘻太好了 b：你知道了吧（废话仙人，显得很捞，其实说不说a都知道了b也喜欢a）

A : 请求断连 FIN

B : 同意断连 ACK 但是我再处理下后续进程

A : 可以，那我等你处理完吧 FIN-WAIT

B : OK我处理好后续的玩意了，断连吧 FIN ACK

A : OK那断连确认了哈，ACK 进入TIME-WAIT

为啥不能两次或三次挥手：

解：2 次挥手拟化场景 --> a：别说了我想去吃饭了！ b: 巴拉巴拉，啊？知道了，马上说完（a把电话挂了，很尴尬）

3 次挥手拟化场景 --> a：别说了我想去吃饭了！ b: 巴拉巴拉，啊？知道了，马上说完 b: 巴拉巴拉我说完了。。。（a不理b，听完以后把电话挂了，很不礼貌）

--> a：别说了我想去吃饭了！ b: 巴拉巴拉，啊？知道了，马上说完 a：好的拜拜（a只想干饭，不是在和b商量，不听b多bb直接告b拜拜，后把电话挂了，很不礼貌）

TIME-WAIT时间为啥是2MSL 最大段生命周期：

MSL : 最大段生命周期：它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。

两保证

为什么TIME_WAIT状态是2MSL？（2个原因）_为什么2msl_啊大1号的博客-优快云博客

TCP如何保证可靠性的：

3次握手4次挥手，保证连接断连的可靠性
有状态性，记录哪些数据被接受了或未被接收，保证数据包有序到达
TCP特性：流控，拥控，数据包校验，ACK应答，超时重传，失序数据重传，去重数据

TCP重传机制：

当TCP发送端发出数据包后，等待ACK响应确认ACK信号，若未正常响应有以下三种重传机制：

方法名称	描述
1. 超时重传(RTO)	情景：如果在等待时间内没有收到ACK响应。判定：发送端认为数据包丢失或丢弃，并触发超时重传。操作：发送端将相同的数据包重新发送给接收端。
2. 倍增退避算法	情景：如果发送端连续多次超时重传相同的数据包，判定：表示网络可能出现拥塞或不稳定情况。在这种情况下，TCP会采用退避算法。操作：每次超时重传后，等待时间会逐渐增加，以避免过度拥塞网络。
3. 快速重传	情景：当接收端收到一个失序的数据包时，立即向发送端发送带有期望的序列号的ACK响应。操作：触发发送端快速重传丢失的数据包。

方法名称

描述

1. 超时重传(RTO)

情景：如果在等待时间内没有收到ACK响应。

判定：发送端认为数据包丢失或丢弃，并触发超时重传。

操作：发送端将相同的数据包重新发送给接收端。

2. 倍增退避算法

情景：如果发送端连续多次超时重传相同的数据包，

判定：表示网络可能出现拥塞或不稳定情况。在这种情况下，TCP会采用退避算法。

操作：每次超时重传后，等待时间会逐渐增加，以避免过度拥塞网络。

3. 快速重传

情景：当接收端收到一个失序的数据包时，立即向发送端发送带有期望的序列号的ACK响应。

操作：触发发送端快速重传丢失的数据包。

超时重传（RTO）：

RTT：

RTT指的是一个数据包从发出去到回来的时间，即数据包的一次往返时间。

RTO设置	可能出现的情况
过小	数据并没有丢失，就重发了，导致网络阻塞
过大	数据丢失了但是没有判定丢失，导致数据传输的响应过差

RTO的缺点：

缺点	描述
传输延迟	超时重传会引入传输延迟，因为发送方必须等待一定时间来检测是否需要进行重传。如果RTO设置过长，可能会导致数据传输的响应时间变长。
重发已接收的数据	超时重传可能会导致已经接收的数据被错误地判定为丢失，从而触发不必要的重传，浪费了网络资源和带宽。解决方案：倍增退避算法
不适用于高延迟网络	在高延迟的网络中，可能需要较长的时间才能检测到超时，从而导致传输效率降低。
不适用于长距离传输	在长距离传输中，由于信号传播时间增加，导致较高的RTT，导致较长的RTO设置。会增加数据传输的时延。
不适用于实时性要求高的应用	对于实时性要求较高的应用（如流媒体），超时重传可能不是最优的选择，因为超时重传会引入较高的传输延迟，影响实时性。在这种情况下，其他更适合实时传输的机制可能更合适。

快速重传：

快速重传机制，它不以时间驱动，而是以数据驱动。基于接收端的反馈信息来引发重传。

第一份 Seq=1 先送到了，于是就 Ack 回 2；
第二份 Seq=2 也送到了，假设也正常，于是ACK 回 3；
第三份 Seq=3 由于网络等其他原因，没送到；
第四份 Seq=4 也送到了，但是因为Seq3没收到。所以ACK回3；
后面的 Seq=5，6的也送到了，但是ACK还是回复3，因为Seq=3没收到。
发送端连着收到三个重复（判定丢失）冗余ACK=3的确认（实际上是4个，但是前面一个是正常的ACK，后面三个才是重复冗余的），便知道哪个报文段在传输过程中丢失了，于是在定时器过期之前，重传该报文段。
最后，接收到收到了 Seq3，此时因为 Seq=4，5，6都收到了，于是ACK回7.

出现问题：快速重传怎么确定是哪个报文段丢失呢？比如收到了ack2 3个，确定不了是哪几个报文段丢失

SACK重传机制：

接收方收到数据段后，检查数据段的序号，如果有序到达，则发送一个普通的ACK确认；else 如果有丢失的数据段，接收方就会收集这些丢失的数据段的序号范围，并发送SACK确认。
发送方收到SACK确认后，根据SACK确认中指示的丢失的数据段范围，只重传这些丢失的数据段。

TCP滑动窗口控制机制：

解决问题：主要解决了1）流量控制、2）拥塞控制、3）有序传输的问题

TCP 滑动窗口分为两种: 发送窗口和接收窗口。

发送端的滑动窗口包含四大部分，如下：

已发送且已收到ACK确认（吃完也消化完的）
已发送但未收到ACK确认（吃完未消化玩的）
未发送但可以发送（没吃到但还能吃的数量）
未发送也不可以发送（没吃到但是吃不了的数量）

虚线矩形框，就是发送窗口。
SND.WND: 表示发送窗口的大小,上图虚线框的格子数就是14个。
SND.UNA: 一个绝对指针，它指向的是已发送但未确认的第一个字节的序列号。
SND.NXT：下一个发送的位置，它指向未发送但可以发送的第一个字节的序列号。

接收方的滑动窗口包含三大部分，如下：

已成功接收并确认
未收到数据但可以接收
未收到数据并不可以接收的数据

虚线矩形框，就是接收窗口。
REV.WND: 表示接收窗口的大小,上图虚线框的格子就是9个。
REV.NXT:下一个接收的位置，它指向未收到但可以接收的第一个字节的序列号

滑动窗口步骤：

步骤	描述
1	发送方将数据划分为多个数据段，并为每个数据段分配一个序号。
2	发送方维护发送窗口大小，根据接收方通告的接收窗口大小、往返时延（RTT）和拥塞窗口动态调整发送窗口大小。
3	发送方将数据段发送给接收方，并等待接收方的确认（ACK）。
4	如果发送方收到接收方的确认，发送窗口向前滑动，允许发送更多的数据。
5	如果发送方未收到确认，或接收方通告的接收窗口变小，发送窗口大小减小，限制发送的数据量。

TCP流量控制：

定义：用于限制发送方向接收方发送数据的速率，确保接收方能够及时处理接收的数据，避免数据的丢失和缓冲区溢出。

解决问题：流量控制是为了解决发送方发送速率过快而导致接收方无法处理的问题。

流量控制流程	描述
1. 发送方发送数据	发送方将数据划分为数据段，并发送给接收方。
2. 接收方通告窗口大小	接收方通过TCP报文的窗口字段通告自己当前的接收窗口大小。
3. 发送方调整发送窗口	发送方根据接收方通告的窗口大小动态调整自己的发送窗口大小。
4. 限制发送速率	发送方根据接收方的接收能力和网络状况限制自己的发送速率，确保数据发送的速率不超过接收方的处理能力。
5. 确认接收	接收方接收数据并发送确认（ACK）给发送方，通知发送方可以发送下一批数据。
6. 动态调整	发送方根据接收方的接收情况和网络状况动态调整发送速率，保持流量控制的有效性。

win：传入当前可接受数据量

小情景：

A：包子给B吃，给你1个

B：好滴我还能吃2个

A：再给你俩包砸！

B：好滴我吃不动了，得消化消化

A：好滴

过了一会

A：消化完了吗B（试探报文）

B：消化完了2个，现在还能再吃2个

TCP拥塞控制：

定义：

用于控制在网络中发生拥塞时（最大化利用网络上瓶颈链路的带宽）TCP连接的数据传输速率，以避免网络过载和性能下降，保持网络的高性能和稳定性。

与流量控制区别：控制位置不同（流量控制：根据接收端实际接收能力），控制对象不同（拥塞链路和接收端）

策略：

算法/策略	描述
慢启动（Slow Start）	在连接刚开始时，TCP发送方会以较慢的速率逐渐增加发送的数据量，从而避免对网络造成突然的压力。
拥塞避免（Congestion Avoidance）	一旦连接进入拥塞状态，TCP发送方会减慢数据传输速率，以避免进一步加重网络拥塞。
快速重传（Fast Retransmit）	当发送方接收到重复确认（Duplicate ACKs）时，表示可能发生数据包丢失，触发快速重传，立即重传丢失的数据包。
快速恢复（Fast Recovery）	当发送方触发快速重传后，进入快速恢复状态，继续以较慢的速率发送数据，然后逐渐增加发送速率。
超时重传（Timeout Retransmission）	当发送方等待确认的时间超过了超时阈值，认为数据丢失，触发超时重传，重新发送未确认的数据包。

慢启动：

拥塞窗口cwnd（congestion window）

慢启动步骤：

TCP连接完成，初始化cwnd = 1，表明可以传一个MSS（最大报文段长度）单位大小的数据。
每当收到一个ACK，cwnd就加一;
每当过了一个RTT，cwnd就增加一倍; 呈指数让升
为了防止cwnd增长过大引起网络拥塞，还需设置一个慢启动阀值ssthresh（slow start threshold）状态变量（一般ssthresh是65535字节 2^16）。
当cwnd到达该阀值后，就好像水管被关小了水龙头一样，减少拥塞状态。即当cwnd >ssthresh时，进入了拥塞避免算法。

拥塞避免算法：

当每过一个RTT时，cwnd = cwnd + 1 ----------------------------> 线性上升算法，避免过快导致网络拥塞问题。

拥塞发生时：网络出现丢包情况

采取解决方案：快速重传/RTO超时重传

快速重传及快速恢复：

RTO：

慢启动阀值sshthresh = cwnd /2
cwnd 重置为 1
进入新的慢启动过程

缺点：一夜回到解放前

优化方案：快速重传 + 快速恢复：

快速重传：

拥塞窗口大小 cwnd = cwnd/2
慢启动阀值 ssthresh = cwnd
进入快速恢复算法

快速恢复：

cwnd = sshthresh + 3 （3个连续丢包 -> 认为断连接）
重传重复的那几个ACK（即丢失的那几个数据包）
- 如果再收到重复的 ACK，那么 cwnd = cwnd +1
- 如果收到新数据的 ACK 后, cwnd = sshthresh。因为收到新数据的 ACK，表明恢复过程已经结束，可以再次进入了拥塞避免的算法了。

总结拥塞控制过程：

阶段	描述
慢启动（Slow Start）	初始化cwnd = 1，表示可以传输一个MSS单位大小的数据。每收到一个ACK，cwnd增加1，进入指数增长。每过一个RTT时间，cwnd翻倍，指数级增长。
拥塞避免（Congestion Avoidance）	当cwnd > ssthresh时，进入拥塞避免状态。在拥塞避免状态下，每过一个RTT时间，cwnd增加1个MSS的发送量。线性增长，避免指数级增长。防止cwnd增长过大引起网络拥塞，保持网络稳定性。
快速重传和快速恢复	当发生超时或接收到重复的确认（Duplicate ACKs），触发快速重传和快速恢复。将慢启动阀值ssthresh设置为当前拥塞窗口的一半。将cwnd设置为ssthresh后继续进入拥塞避免状态，线性增长。

阶段

描述

慢启动（Slow Start）

初始化cwnd = 1，表示可以传输一个MSS单位大小的数据。

每收到一个ACK，cwnd增加1，进入指数增长。

每过一个RTT时间，cwnd翻倍，指数级增长。

拥塞避免（Congestion Avoidance）

当cwnd > ssthresh时，进入拥塞避免状态。

在拥塞避免状态下，每过一个RTT时间，cwnd增加1个MSS的发送量。

线性增长，避免指数级增长。防止cwnd增长过大引起网络拥塞，保持网络稳定性。

快速重传和快速恢复

当发生超时或接收到重复的确认（Duplicate ACKs），触发快速重传和快速恢复。

将慢启动阀值ssthresh设置为当前拥塞窗口的一半。

将cwnd设置为ssthresh后继续进入拥塞避免状态，线性增长。

TCP粘包和拆包：

定义：

TCP粘包和拆包	定义
定义	前提背景：TCP是基于流！！的传输协议，数据被划分为数据段发送的。TCP不明白上层业务数据含义，无法划分包的关联性问题1：粘包：接收方可能会将多个数据段合并成一个完整的消息（粘包），接收到的数据含有多个完成数据问题2：拆包：将一个消息拆分成多个数据段（拆包）。接收到的数据不完整影响：粘包和拆包可能导致数据的解析错误和业务逻辑混乱。
发生原因	发生原因包括网络延迟（未及时处理）缓冲区大小不合适（报文本身长度/缓存区长度）、数据发送速率不同等。

TCP粘包和拆包

定义

前提背景：TCP是基于流！！的传输协议，数据被划分为数据段发送的。TCP不明白上层业务数据含义，无法划分包的关联性

问题1：粘包：接收方可能会将多个数据段合并成一个完整的消息（粘包），接收到的数据含有多个完成数据

问题2：拆包：将一个消息拆分成多个数据段（拆包）。接收到的数据不完整

影响：粘包和拆包可能导致数据的解析错误和业务逻辑混乱。

发生原因

发生原因包括网络延迟（未及时处理）缓冲区大小不合适（报文本身长度/缓存区长度）、数据发送速率不同等。

粘拆包解决方案：

TCP粘包解决方案	描述
1. 消息定长	发送方在发送消息时固定每个消息的长度，接收方按照固定长度进行拆包，保证每个消息长度一致，避免粘包和拆包问题。（传输数据长度一致性）
2. 使用特殊分隔符	发送方在消息之间添加特殊的分隔符，接收方根据分隔符将消息拆分成单独的数据包，从而解决粘包问题。常见的分隔符有换行符、回车符等。
3. 使用消息头和消息体	发送方在每个消息前面添加一个消息头，消息头包含消息的长度等信息，接收方首先读取消息头中的长度信息，然后根据长度信息读取对应长度的消息体，从而解决粘包问题。

TCP与UDP（传输层协议）的区别：

特点	TCP	UDP
连接类型	面向连接（连接导向型）	无连接（无连接导向型）
可靠性	可靠传输，保证数据可靠到达目标	不可靠传输，不保证数据可靠到达目标
传输机制	基于字节流，数据按顺序传输	面向数据报流，数据包之间相互独立，不保证按序到达或不保证到达
传输速度	较慢，有流控和拥控机制需要建立连接和断开连接	较快，无需建立连接和断开连接
错误检测和重传	支持错误检测和重传机制	不支持错误检测和重传机制
适用场景	适用于对数据可靠性要求高的应用	适用于对实时性要求较高的应用，如视频、音频传输
使用场景	Web浏览、文件传输、电子邮件等	实时通信、在线游戏、视频和音频传输等
连接量级	对点连接	一对一一对多多对多均可
基于协议的应用层协议	HTTP,FTP,SMTP（邮件）,TELNET（电传）	DNS,TFTP(简单文件传输）,SNMP（简单网络管理协议）

如何让UDP更加可靠（模仿TCP可靠性）：

方法	描述
应用层重传	在应用层实现数据的重传机制，发送方发送数据后，等待接收方的确认信息，如果在一定的超时时间内未收到确认，就进行数据的重传。
序列号（seq/ack）	在应用层加入序列号和校验和，发送方在发送数据时加上序列号和校验和，接收方在接收数据时进行校验。如果数据错误或丢失，接收方可以请求重传。
接收确认	接收方在收到数据后，发送确认信息给发送方，告知发送方数据已经收到。发送方在接收到确认信息后，才会发送下一个数据。
超时设置	设置合理的超时时间，避免等待时间过长导致延迟，同时避免超时时间过短导致频繁重传。

DNS（Domain Name System（应用层协议）：

DNS定义：

指用于将域名（例如www.example.com）转换为对应的IP地址（例如192.0.2.1）的系统。

URL与URI：

特点	URI (Uniform Resource Identifier)	URL (Uniform Resource Location)
全称	统一资源标志符	统一资源定位符
定义	用于唯一标识一个资源的字符串	用于提供资源的路径和访问方式
类比	像身份证，用于唯一标识一个资源	像住址，用于定位资源的位置和访问方式
包含	URL是URI的子集，每个URL都是一个有效的URI	URI包括URL和URN（Uniform Resource Name）
用途	用于唯一标识、定位和访问资源	用于提供资源的路径，可以通过URL访问资源
示例	URI: mailto:example@example.com	URL: Example Domain Example Domain

通俗理解：

URI表示的是一个抽象的地址，URL表示的是一个详细的地址。
抽象的地址：辽宁省大连市（这是一个抽象的地址，相当于URI）
详细的地址：辽宁省大连市高新园区软件园B2（这是一个详细的地址，相当于URL）
为什么URL是URI的子集，高新园区软件园B2（URL）属于辽宁省大连市（URI）
那么https://www.youkuaiyun.com 是一个URI（URI只指明了服务器的地址，没有具体到文件是什么类型）
那么https://www.youkuaiyun.com/image/logo.gif就是一个URL（他具体到了logo文件的位置并且logo文件是gif类型的）

DNS解析查询流程：

步骤	描述
1. 浏览器缓存	首先检查浏览器缓存，查找对应的IP地址，如果有缓存则直接返回IP地址，否则进入下一步。
2. 本地DNS查询 www.baidu.com	浏览器将请求发送给本地DNS服务器，在本地DNS服务器的缓存中查询，如果有缓存则直接返回IP地址，否则进入下一步。
3. 根域名服务器查询	本地DNS服务器向根域名服务器发送查询请求，根域名服务器告知本地DNS服务器去查询哪个顶级域名服务器。 ps：根域名服务器不直接存储所有顶级域名的解析信息，而是存储所有顶级域名服务器的IP地址（顶级域名服务器的菜单）
4. 顶级域名服务器查询 .com	本地DNS服务器向顶级域名服务器发送查询请求，顶级域名服务器告知本地DNS服务器去查询哪个权限域名服务器。（权限域名服务器的菜单）
5. 权限域名服务器查询 .baidu	本地DNS服务器向权限域名服务器发送查询请求，权限域名服务器返回请求域名所对应的IP地址。
6. 返回IP地址 www.baidu.com的ip地址	最后，本地DNS服务器将请求域名所对应的IP地址返回给浏览器，使浏览器能够访问相应的服务器。并保存在本地缓存中

DNS劫持：

DNS劫持：通过篡改DNS服务器上的数据返回给用户一个错误的查询结果来实现的。

通过劫持了DNS服务器，通过某些手段取得某域名的解析记录控制权。
进而修改此域名的解析结果，导致对该域名的访问由原IP地址转入到修改后的指定IP。
对特定网址不能访问或访问的是假网址，从而实现窃取资料或者破坏原有正常服务的目的。

IP（网络层协议）与MAC地址：

IP地址分类：

类别	地址范围	高位比特	支持的主机数	用途
A类地址	0.0.0.0 - 127.255.255.255	0	约16.7百万个	大型网络
B类地址	128.0.0.0 - 191.255.255.255	10	约6.5万个网络	中型网络
C类地址	192.0.0.0 - 223.255.255.255	110	约20万个网络	小型网络
D类地址	224.0.0.0 - 239.255.255.255	1110	保留	多播地址
E类地址	240.0.0.0 - 255.255.255.255	1111	保留	保留

网络号：它标志主机（或路由器）所连接到的网络，网络地址表示属于互联网的哪一个网络
主机号：它标志该主机（或路由器），主机地址表示其属于该网络中的哪一台主机

IP地址与MAC地址：

IP地址与MAC地址的作用、区别和关联_mac地址与ip地址的作用__才疏学浅_的博客-优快云博客

特点	IP地址（收件地址）	MAC地址（收件人）
定义	逻辑地址，用于在Internet上唯一标识网络设备	物理地址，用于在局域网内唯一标识网络设备
使用层级	网络层（Internet层）	数据链路层（链路层）
地址类型	IP地址是数字格式，例如：192.168.0.1	MAC地址是由6组十六进制数字（共48位）组成，例如：00:1A:2B:3C:4D:5E
可变性	可以随着路由分配策略，更改	不可更改，每个制造商制造出来的唯一地址
范围		全球范围内唯一
功能	用于在Internet上进行全球范围内通信	用于在局域网内进行本地通信
路由与转发	IP地址用于在全球范围内路由和转发数据包	MAC地址用于在局域网内直接交换数据包
协议	使用IP协议（Internet Protocol）	使用ARP协议（Address Resolution Protocol）

IP地址可以有用户自行修改，管理较困难，MAC地址无法更改。

只使用MAC地址，直接交换：源到目标。随着网络设备增多需要存储的MAC地址很多占用内存很多，实现很麻烦；
而IP地址只需要将数据通过源地址通过路由发送到目标地址的子网，较简单。

IP地址是传送地址，MAC地址为收件人（通过ARP协议将IP转为MAC）

ARP（网络层协议）相关:

协议名称	Address Resolution Protocol (ARP)
定义	ARP是一种用于在局域网中将IP地址转换为MAC地址的协议
层级	数据链路层（链路层）与网络层之间（桥梁）
功能	解析目标IP地址对应的MAC地址，以便进行数据包的正确传输和路由
地址解析过程	1. 主机A发送ARP请求广播，询问目标IP地址对应的MAC地址
	2. 目标主机B收到ARP请求后，回复ARP响应，包含自己的MAC地址
	3. 主机A收到目标主机B的ARP响应后，将其存储在ARP缓存表中
ARP缓存表	主机A在收到ARP响应后，会将目标IP地址与对应的MAC地址存储在ARP缓存表中，以便以后通信时快速查找
使用方式	ARP通常使用广播方式在局域网内寻找目标设备的MAC地址
用途	在计算机网络中实现IP地址与MAC地址之间的映射，确保数据包的正确传输和路由
注意	ARP协议是一种简单且有效的地址解析协议，在局域网内相互发现和识别主机设备非常重要

ARP工作原理流程：

小情景：

BG: A想发数据包给B

A : 通过目标ip地址，路由发送到目标逻辑位置

A : 翻查ARP缓存表，看看以前有无和目标物理位置建立连接？有直接交换数据包 : 无下一步

A : 通过广播形式向局域网中所有主机发送ARP请求包（源主机ip，硬件地址，目标主机ip），问其他主机谁的IP地址与目标IP地址吻合

B : 发现自己IP地址与广播IP地址吻合，发送ARP回复包（包含自己的MAC地址）

A : 接收到B的ARP回复包，记录在ARP缓存表中，方便后续的数据包直接交换

A : A已知B的MAC地址，将发送数据在以太帧中封装，通过目标的MAC地址发送数据包到主机B。

RARP工作流程（过时协议）:

步骤	描述
1. 主机发送RARP请求广播	主机启动并发送RARP广播请求（包含自己的MAC地址）,并请求分配IP地址。
2. RARP服务器接收广播请求	在本地网段上的RARP服务器收到主机的广播请求，准备响应。
3. 查询RARP列表	RARP服务器检查自己的RARP列表，查找是否有该MAC地址对应的IP地址。
A ; 分配IP地址 B : IP地址未找到	A : RARP服务器在列表中找到该MAC地址对应IP地址,将此IP地址发送给主机。 B : 如果RARP服务器在列表中找不到对应的IP地址，它将不会做出响应。
4. 主机收到IP地址	主机收到RARP服务器响应的IP地址，可以用于进行通信。else 初始化失败

端到端（传输层协议）点到点PPP（链路层协议）：

类型	端到端通信	点到点通信
定义	在传输层为网络中的主机提供发端到接端的通信	链路层或网络层提供直接相连节点之间的通信
通信方式	从发送端到接收端，不论中间跨越多少节点	直接相连的两个节点对等实体之间的通信
中间节点	数据经过多个中间节点传输到接收端	数据直接从一个设备传递给与其相邻的下一个设备
传输延迟	端到端传输的延迟较小，无需存储转发	点到点传输的延迟相对较大，中间设备需进行存储转发
传输可靠性	端到端传输可靠，确认接收方收到数据	点到点传输不保证数据传输的可靠性，可采用存储转发技术增加传输可靠性
适用场景	用于应用程序(进程)之间的通信，如Internet通信	适用于网络环境中的主机之间的直接相连通信
通信效率	受网络拥塞、传输距离等因素影响，端到端传输相对较低的通信效率	直接连接，没有额外的转发和处理，点到点传输具有较高的通信效率
资源消耗	端到端传输较大的资源消耗，发送端需参与整个传输过程	点到点传输较小的资源消耗，发送端仅需送出数据即可
示例	网络中的主机之间的数据传输，TCP/UDP通信或复杂网络	直接相连的两台计算机之间的数据传输，以太网通信（简单网络）

WebSocket与Socket区别：

Socket = IP地址 + 端口 + 协议。

特点	Socket	WebSocket
定义	Socket是一套标准，完成了对TCP/IP的高度封装（属于接口类，不是协议类）	WebSocket是持久化应用层通信协议，解决HTTP不支持持久化连接的问题。
通信类型	Socket通常用于传输原始数据，如TCP和UDP数据	WebSocket通常用于实现全双工通信，支持客户端与服务器间的双向通信。
连接方式	基于Socket编程的连接是一次性的，请求-响应模式	基于HTTP协议升级而来，WebSocket连接是持久化的，建立连接后可以长时间保持通信通道。
应用场景	Socket适用于需要直接处理底层网络通信的场景	WebSocket适用于实时性要求较高的应用，如在线游戏、聊天应用、实时数据传输等。
数据传输方式	Socket通常需要自行定义数据格式和解析方式	WebSocket支持双向传输数据，可以发送文本或二进制数据，对数据格式有较好的支持。

ping过程：

定义：

通过ICMP协议在网络中发送和接收数据包，通过往返时间来评估网络的响应速度和可达性。结果中显示了与目标主机之间的通信状况和网络质量。

最终显示ping命令的结果，包括发送到目的主机的IP地址、发送、接收、丢失的分组数，以及往返时间的最小、最大和平均值。

MAC2MAC）过程： ICMP - > 源IP - > IP数据包 - > MAC物理层传输数据 - > 目标主机MAC - > IP数据包 - > 返回 ICMP + RTT

步骤	描述
1.	用户输入ping命令，通知系统发送ICMP请求数据包。
2.	ICMP协议将固定格式的数据包和目标机器B的IP地址打包，并交给IP协议层。
3.	IP层协议构建IP数据包，将本机IP地址作为源地址，机器B的IP地址作为目标地址，并加上其他控制信息。
4.	系统ARP先获取目标机器B的MAC地址。
5.	数据链路层构建数据帧，将IP数据包作为数据负载，目的地址设置为目标机器B的MAC地址，源地址设置为本机的MAC地址。
6.	数据帧通过物理网络传输到目标机器B。目标机器B接收到数据帧后，检查目的地址和本机MAC地址是否匹配，符合则继续处理，不符合则丢弃。
8.	目标机器B解析IP数据包，得到ICMP请求数据包，根据规定进行处理，构建ICMP回送回答报文，并将时间戳返回给源主机。
9.	源主机收到目标机器B的ICMP回送回答报文，根据时间戳计算往返时间。