computer networks interview questions

• 用户输入：用户通过单击链接、提交表单或输入 URL 与浏览器交互。
• HTTP请求：
• DNS 查找：将域名解析为 IP 地址
• TCP 连接：浏览器使用解析的 IP 地址和适当的端口号（通常是 HTTP 的端口 80 或 HTTPS 的端口 443）发起到服务器的 TCP 连接
• HTTP 请求发送：TCP 连接建立后，浏览器向服务器发送 HTTP 请求。
• 服务器处理
• 服务器响应
• TCP 连接关闭
• 浏览器处理
• 渲染

网络断开或者DNS解析出错了。

协议://域名或IP地址:端口号

• 应用层：应用层协议包括 HTTP 和 SMTP
• 表示层：表示层负责数据的转换、加密和压缩。
• 会话层: 会话层确保会话保持打开状态足够长的时间以数据
• 传输层：传输层协议包括传输控制协议（TCP）和用户数据报协议（UDP）
• 网络层：网络层协议包括IP、互联网控制消息协议(ICMP)、互联网组消息协议(IGMP) 和IPsec 套件。
• 数据链路层: 据链路层从网络层获取数据包并将其分解为称为帧的更小的部分。
• 物理层：包括数据传输中涉及的物理设备，例如电缆和交换机。

• 应用层：应用层协议包括 HTTP 和 SMTP
• 传输层：传输层协议包括传输控制协议（TCP）和用户数据报协议（UDP）
• 网络层：网络层协议包括IP、互联网控制消息协议(ICMP)、互联网组消息协议(IGMP) 和IPsec 套件。
• 数据链路层: 据链路层从网络层获取数据包并将其分解为称为帧的更小的部分。
• 物理层：包括数据传输中涉及的物理设备，例如电缆和交换机。

• HTTP：超文本传送协议
• DNS：域名系统
• FTP：文件传输协议
• Telnet: 远程终端协议
• SMTP: 简单邮件传输协议
• POP3/IMAP: 邮件接收协议
• RTP: 实时传输协议
• SSH：安全的网络传输协议
• Websocket: 全双工通信协议

HTTP 协议的请求报文和响应报文的结构基本相同，由三大部分组成：

• 起始行: 请求方法和URI以及HTTP版本号
• HTTP Header: 请求方法和URI以及HTTP版本号
• 空行
• HTTP Body: 请求方法和URI以及HTTP版本号

对于响应消息，格式类似，但它包括状态代码、附加标头以及可能包含所请求资源的正文。

只是语义上面的区别，GET用于获取数据，POST用于提交数据。协议并没有规定GET请求不能带body的，也没有规定POST不能传Query参数。

语义上的区别，PUT用于修改数据，POST用于提交数据。

• 200 OK
• 201 Created
• 204 No Content：表示该请求已经成功了，但是客户端客户不需要离开当前页面。
• 301 Moved Permanently 请求的资源已经被移动到了由 Location 头部指定的url上, 需要重定向
• 304 Not Modified 没有修改，不需要刷新
• 400 Bad Request, 客户端错误
• 401 Unauthorized 客户端错误：未经过身份验证
• 403 Forbidden 客户端错误，拒绝访问
• 405 Method Not Allowed
• 500 Internal Server Error 服务器端错误
• 502 Bad Gateway 网关或代理的服务器错误

资源移动到了HTTP响应的响应头Location指定的URL上，浏览器会重定向到这个URL。

多次操作等同于操作一次。不用担心重复操作会造成改变。

PUT会对已存在的单一资源以相同的值修改，结果不变。POST多次发送，会创建多个资源。

• Accept: 请求头用来告知（服务器）客户端可以处理的内容类型
• Accept-Charset: Accept-Charset 请求头用来告知（服务器）客户端可以处理的字符集类型。
• Accept-Encoding: 客户端能够理解的内容编码方式
• Authorization: 请求标头用于提供服务器验证用户代理身份的凭据
• Cache-Control: 通过指定指令来实现缓存机制
• Connection: 控制网络连接在当前会话完成后是否仍然保持打开状态
• Content-Encoding: 当前实体消息（消息荷载）应用的任何编码类型
• Content-Length: 消息主体的大小
• Location：将页面重新定向至的地址

HTTP（Hypertext Transfer Protocol）是一种用于传输超文本（如 HTML）数据的协议，它被设计成无状态的。这意味着每个单独的 HTTP 请求都是独立的，服务器不会保存关于客户端请求的任何信息。

缺乏状态维护：HTTP 协议本身没有提供在多次请求之间保持客户端状态的机制。每个请求都是相互独立的，服务器无法直接识别这些请求是否来自同一个客户端。

简化通信模型：无状态性简化了 Web 服务器的设计和实现，使其更容易扩展和处理大量并发请求，因为它不需要维护客户端的状态信息。

提高可靠性和可伸缩性：由于每个请求都是相互独立的，所以系统中的某一台服务器出现故障时，可以很容易地将该请求分配给其他可用的服务器进行处理。

尽管 HTTP 协议本身是无状态的，但是通过引入 Cookie、Session 等机制，开发人员可以在一定程度上实现状态管理，使得服务器能够跟踪和管理客户端的状态信息。例如，在 Web 应用程序中，可以使用 Cookie 来存储客户端的会话标识，从而实现用户的状态管理。

HTTP长连接，也称为持久连接，允许客户端发送额外的请求，而不必重复建立新连接。 这可以减少为每个请求建立新连接的开销并提高整体性能，特别是对于需要加载多个资源的Web应用程序。HTTP长连接的实现涉及到使用诸如HTTP/1.1中的“Connection: keep-alive”标头之类的技术，以指示连接应为后续请求保持打开状态。

HTTP 短连接或非持久连接涉及为每个请求和响应交换建立一个新连接。 一旦收到响应，连接就会关闭，并为下一个请求建立新的连接。 此方法是早期版本的HTTP中的默认行为。HTTP短连接的实现涉及到使用诸如HTTP/1.1中的“Connection: close”标头之类的技术，以指示响应后立即关闭连接。

HTTP依赖于应用程序层内的机制来描绘消息边界和构建数据。对于 HTTP/1.0 和 HTTP/1.1，协议使用标头通过“Content-Length”标头或通过使用“chunked”传输编码来指定消息长度。 这些机制为接收者提供了一种了解TCP字节流内各个消息的边界的方法。

“Content-Length”标头指示消息正文的大小（以字节为单位），允许接收者知道何时收到完整消息。分块传输编码允许发送者将消息分成更小的块，每个块都有自己的大小指示符，使接收者能够重建完整的消息。

HTTP通过换行符确定HTTP Header和HTTP Body的边界。

通过HTTP响应报文的Header里Set-cookie字段。浏览器获取并设置。

Cookie存储在客户端，Cookie通常用于存储用户首选项、身份验证令牌和其他浏览信息。Cookie通常用于实现会话，但它们也可用于其他目的，例如跟踪用户行为和个性化内容。

Session通常使用cookie在客户端存储唯一标识符（会话 ID），而在服务器则存储实际的会话数据。会话数据可以包括特定于用户的信息，例如登录状态、购物车内容以及与用户与站点交互相关的其他临时数据。

服务器端的会话通常以下列方式之一存储：

• 内存存储：会话数据直接存储在服务器的内存中。 此方法提供对会话数据的快速读写访问，但可能不适合大规模应用程序或分布式服务器环境，因为它不提供跨服务器重新启动或故障转移场景的持久性。
• 数据库存储：会话数据存储在数据库中，例如 MySQL、PostgreSQL 或 NoSQL 数据库（如 MongoDB 或 Redis）。 将会话存储在数据库中可以实现持久性、可扩展性以及在分布式环境中的多个服务器之间共享会话数据的能力。
• 文件系统存储：会话数据作为文件存储在服务器的文件系统上。 每个用户会话都与包含会话数据的唯一文件相关联。 此方法提供持久性，可用于可能不需要成熟的数据库解决方案的场景。

每个用户第一次访问服务器后，会自动获得一个Session ID。 Session ID会存储在Cookie中，每次请求会附带Session ID。

动态更新cookies，让session保持alive

会话初始化：在用户与 Web 应用程序交互开始时，会生成唯一的会话 ID 来标识用户的会话。这可以在用户登录、首次访问站点或执行任何需要会话跟踪的操作时完成。

会话数据存储：在用户会话期间，相关数据（例如用户身份验证状态、购物车内容或其他用户特定信息）存储在服务器端的会话对象中。该数据与唯一的会话ID相关联。

会话ID传输：会话ID通常通过使用cookie或URL参数传输到客户端。 Cookie是管理会话ID的最常用方法，但在某些情况下，可能会使用URL重写或隐藏表单字段。

会话验证：根据客户端的后续请求，服务器接收并验证会话ID，以确保其对应于活动会话。 如果会话ID有效，服务器将检索关联的会话数据以个性化用户体验。

会话过期和清理：会话通常设置为在一段时间不活动后过期，以释放服务器资源。 实施清理过期会话和相关数据的机制以防止内存泄漏并优化服务器性能非常重要。

具体实现细节可能会根据所使用的 Web 开发框架和编程语言而有所不同。 大多数现代 Web 开发框架都提供对管理用户会话的内置支持，包括用于创建、访问和销毁会话数据的 API。

• 安全性：HTTPS 使用加密来保护客户端
• 数据加密：HTTP 以纯文本形式发送数据，HTTPS使用SSL/TLS对数据进行加密
• 协议：HTTP 在端口 80 上运行，而 HTTPS 使用端口 443。
• 证书要求：使用HTTPS的网站需要SSL/TLS证书才能与客户端的 Web 浏览器建立安全连接。
• 信任和身份验证：防止中间人攻击并确保用户正在与目标网站进行通信。

HTTPS（安全超文本传输协议）的主要原理是通过向标准 HTTP 协议添加加密和身份验证措施来保护客户端（例如 Web 浏览器）和 Web 服务器之间的通信。 HTTPS 的核心原则包括：

• 加密：HTTPS 使用 SSL/TLS（安全套接字层/传输层安全）协议对客户端和服务器之间传输的数据进行加密。
• 数据完整性：通过使用加密算法，HTTPS 验证正在传输的数据的完整性，确保数据在传输过程中没有被更改或损坏。
• 身份验证：HTTPS 提供了一种通过使用 SSL/TLS 证书向客户端验证服务器身份的机制。

HTTPS连接过程可以详细描述如下：

• Client Hello：当客户端向服务器发送“ClientHello”消息时，该过程开始，表明其支持 SSL/TLS 并提供支持的加密算法、密码套件和其他参数的列表。
• 服务器Hello：收到“ClientHello”消息后，服务器会响应“ServerHello”消息，从客户端提供的列表中选择最合适的加密算法和密码套件以及其他连接参数。
• 证书交换：服务器将其 SSL/TLS 证书发送给客户端，其中包括服务器的公钥及其来自受信任证书颁发机构的数字签名。 该证书提供服务器身份的证明，并允许客户端对服务器进行身份验证。
• 客户端密钥交换：使用服务器证书中的信息，客户端生成预主密钥，使用服务器的公钥对其进行加密，然后将其发送回服务器。 此过程称为“ClientKeyExchange”。
• 服务器密钥交换：在某些情况下，特别是使用某些密钥交换方法时，服务器还可以通过发送附加密钥材料或使用客户端的公钥来建立会话密钥来执行密钥交换操作。
• 会话密钥派生：客户端和服务器都使用加密函数从交换的信息（预主密钥、随机值等）独立地派生会话密钥。 这些会话密钥将在会话的剩余时间内用于对称加密和完整性保护。
• 密码套件协商：基于所选的密码套件（定义要使用的特定加密算法、密钥交换方法和哈希算法），客户端和服务器协商如何加密、解密和验证数据的详细信息。
• 加密数据传输：有了会话密钥，客户端和服务器之间随后交换的数据（包括 HTTP 请求和响应）将使用对称加密算法进行加密。 这种加密可确保数据保密，并且不会被未经授权的各方轻易拦截或破译。

• 是否是公认且受信任的CA颁发
• 客户端检查证书的有效期
• 检查证书中的主题信息与其正在访问的网站的域名匹配
• 用根CA的公钥验证证书上的数字签名，以确保证书的完整性。

HTTPS采用混合加密的方式，即同时采用了对称加密和非对称加密。非对称加密只作用在密钥交换阶段。HTTPS在内容传输的加密上使用的是客户端生成的随机字符串Key进行对称加密。

对称加密：使用单个共享密钥进行加密和解密。

非对称加密：使用一对相关的密钥，包括公钥和私钥。公钥用于加密，而私钥用于解密。

• 加权优先顺序：HTTP/2 提供了一个称为加权优先顺序的功能。开发人员可以决定每次首先加载哪些页面资源。
• 多路复用：HTTP/2 可以使用单个TCP连接来一次发送多个数据流，使得任何资源都不会会阻碍其他资源。
• 服务器推送：HTTP/2 通过允许服务器在客户端请求之前向客户端“推送”内容
• 标头压缩：更高级压缩方法从而加快了加载速度

使用重定向：在Web服务器的配置中，通过重定向将所有的HTTP请求自动转发到HTTPS。这可以通过设置HTTP 301（永久重定向）或HTTP 302（临时重定向）来实现。

配置TLS证书：确保Web服务器已经正确配置了有效的TLS/SSL证书，以支持HTTPS连接。可以从可信任的证书颁发机构（CA）获得有效的证书，或者使用免费的证书服务（如Let's Encrypt）。

Web服务器配置：具体的配置方法取决于所使用的Web服务器。例如，对于Nginx，可以在配置文件中添加重定向规则，对所有HTTP请求进行重定向到HTTPS。示例配置：

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}
server {
    listen 443 ssl;
SSL/TLS配置
    server_name example.com;
    # 其他 HTTPS 配置
}
    

应用程序级别处理：如果需要更加灵活的控制，也可以在应用程序中添加代码，实现对HTTP请求的自动转换为HTTPS。例如，在Django、Flask等框架中，可以编写中间件或过滤器来实现自动重定向。

WebSocket 是一种在单个 TCP 连接上进行全双工通信的协议，它能够实现客户端和服务器之间的实时数据传输。

握手阶段：客户端发起 WebSocket 连接请求时，会向服务器发送一个 HTTP 请求，包括一个特殊的 Upgrade 头部，表示希望协议升级为 WebSocket。如果服务器支持 WebSocket，它将发送一个类似的响应，表明协议已经升级成功。

建立连接：一旦握手成功，TCP 连接就被升级为 WebSocket 连接，此时客户端和服务器之间直接可以进行全双工通信，而不再需要经过 HTTP 协议的中间层。

数据传输：一旦建立了 WebSocket 连接，客户端和服务器就可以通过发送数据帧来进行实时的双向通信。数据帧可以是文本类型或二进制类型，允许实时地在客户端和服务器之间传输数据。

保持连接：与传统的 HTTP 连接不同，WebSocket 连接可以保持在打开状态，使得客户端和服务器之间可以随时进行双向通信，而无需每次通信都重新建立连接。

总的来说，WebSocket 协议通过在常规 HTTP 握手之后升级连接为全双工的数据传输通道，从而实现了实时、低延迟的双向通信。这使得 WebSocket 成为了实现实时 Web 应用（如聊天应用、实时数据展示等）的重要技术之一。

域名服务商或 CDN 提供商可能会使用各种负载均衡算法来智能地将用户的 DNS 查询请求分配到最近或最合适的服务器上，以提高系统的性能和可靠性。

子网掩码是用于确定 IP 地址中哪些部分标识网络，哪些部分标识主机的一组位模式。它的作用包括以下几个方面：

划分网络：子网掩码帮助将 IP 地址划分为网络号和主机号两部分。通过与 IP 地址进行逻辑与运算，可以确定 IP 地址中网络部分的范围。

路由：在 IP 网络中，路由器使用子网掩码来确定要转发数据包的目标网络。通过查询目标 IP 地址和对应的子网掩码，路由器可以决定将数据包发送到哪个子网或下一跳路由器。

限制广播域：子网掩码能够限制广播域的范围，使得广播数据包只在特定的子网内传播，避免整个网络范围内的广播风暴。

安全性：通过合理设置子网掩码，可以实现对不同子网之间的访问控制，提高网络的安全性。

面向连接与无连接：TCP：面向连接的协议，在数据交换之前在发送方和接收方之间建立可靠且有序的连接。 它确保数据包以正确的顺序传送，并重试丢失或损坏的数据包。UDP：无连接协议，在数据传输之前不建立专用连接。 它提供不可靠、无序的数据包传送，没有内置的纠错或重传机制。

可靠性和错误处理：TCP：提供可靠的数据传输、错误检测以及自动重传丢失或损坏的数据包。它使用流量控制和确认机制来确保数据传输成功且有序。UDP：提供尽力而为的传送，但不保证数据包到达或顺序。它不执行错误检查或重传，因此适合低延迟比保证交付更重要的实时应用程序。

通信开销：TCP：由于其连接设置、确认和流量控制机制，造成更高的通信开销。 与 UDP 相比，这可能会导致延迟和资源消耗增加。UDP：具有较低的通信开销，因为它缺少连接建立、确认和错误恢复的额外处理。 这使得UDP更适合时间敏感的应用程序，例如流媒体和在线游戏。

用例：TCP：通常用于需要可靠、有序和错误检查数据传输的应用程序，例如网页浏览、电子邮件、文件传输 (FTP) 和远程登录 (SSH)。UDP：非常适合实时通信、多媒体流、VoIP、在线游戏、DNS（域名系统）查找以及其他需要低延迟、快速数据传输且可接受偶尔丢包的应用。

1. 客户端通过向服务器端发送一个SYN来创建一个主动打开，作为三次握手的一部分。客户端把这段连接的序号设定为随机数 A。 2. 服务器端应当为一个合法的SYN回送一个SYN/ACK。ACK 的确认码应为 A+1，SYN/ACK 包本身又有一个随机序号 B。 3. 最后，客户端再发送一个ACK。当服务端受到这个ACK的时候，就完成了三路握手，并进入了连接创建状态。此时包序号被设定为收到的确认号 A+1，而响应则为 B+1。

客户端发送一个数据分段, 其中的 FIN 标记设置为1. 客户端进入 FIN-WAIT 状态. 该状态下客户端只接收数据, 不再发送数据.

服务器接收到带有 FIN = 1 的数据分段, 发送带有 ACK = 1 的剩余数据分段, 确认收到客户端发来的 FIN 信息.

服务器等到所有数据传输结束, 向客户端发送一个带有 FIN = 1 的数据分段, 并进入 CLOSE-WAIT 状态, 等待客户端发来带有 ACK = 1 的确认报文.

客户端收到服务器发来带有 FIN = 1 的报文, 返回 ACK = 1 的报文确认, 为了防止服务器端未收到需要重发, 进入 TIME-WAIT 状态. 服务器接收到报文后关闭连接. 客户端等待 2MSL 后未收到回复, 则认为服务器成功关闭, 客户端关闭连接.

通常需要四个分节的，在两端同时没有数据发送，②和③有可能合并，成为三次。

建立连接：数据传输之前，TCP 会启动三向握手过程以在客户端和服务器之间建立连接。 此过程涉及同步 (SYN) 和确认 (ACK) 数据包的交换，以同步序列号并就可靠数据交换的初始序列号达成一致。

可靠的数据传输：连接建立后，TCP 通过确认接收到的数据段、管理丢失或损坏的数据段的重传以及实施排序来确保数据按正确的顺序传送，从而确保可靠、有序的数据传送。

错误检测和纠正：TCP 包括错误检测机制，例如校验和以及自动重传丢失或损坏的数据包，以确保数据传输的完整性和可靠性。

流量控制和拥塞管理：TCP 结合了流量控制机制，根据接收器处理传入数据的能力来管理数据传输速率。 它还通过使用拥塞控制算法调整其传输速率来响应网络拥塞。

全双工通信：TCP 支持全双工通信，允许客户端和服务器之间同时进行双向数据交换。 这意味着数据可以在同一连接内独立地双向传输。

连接终止：当数据交换完成后，TCP通过四次握手执行优雅的连接终止过程，确保在连接关闭之前交换所有剩余的数据。

允许客户端和服务器之间同时进行双向数据交换,数据可以在同一连接内独立地双向传输。

MSL 是段（数据包）可以在网络中存在的最长时间。 一旦 MSL 过期，与连接关联的任何剩余段都将被丢弃。 实际上，MSL 表示在假设与连接相关的所有潜在段已离开网络之前必须经过的时间。

不同的操作系统和TCP实现可能具有默认的 MSL 值。 例如，在许多系统中，MSL的传统值是2分钟（120 秒），但它可能会根据系统的 TCP 堆栈和配置而变化。

TCP 的最大段大小 (MSS) 是指设备愿意在单个 TCP 段中接受的最大数据量（以字节为单位）。

在 TCP 握手期间，客户端和服务器都使用 SYN 数据包中的 TCP 选项相互传达各自的 MSS 值。发送方指定的MSS值表示可以接收且不分片的最大TCP段。

MSS 主要影响每个段内 TCP 有效负载的大小，影响数据传输的效率以及接收端段重组的潜在需求。

MSS值与底层网络层的最大传输单元（MTU）有关。 MSS 不应超过网络链路的 MTU，以避免分段，因为 MTU 定义可以通过特定网络链路传输的 IP 数据报的最大大小。

底层网络层的最大传输单元（MTU）,MTU 定义了可以通过特定网络链路传输的 IP 数据报的最大大小。

字节流解析就是如何设计应用层协议的问题。

• 确认和重传：TCP使用确认机制来确保数据的可靠传输。接收方会对收到的数据段发送确认，发送方则会根据确认情况进行必要的重传，以确保数据的完整性和可靠性。
• 序列号和排序：TCP对发送的数据进行编号，并要求接收方按正确的顺序重新组装数据。这样可以确保数据按预期的顺序到达目的地。
• 拥塞控制：TCP通过拥塞窗口、慢启动和拥塞避免等机制来监控网络拥塞并调整数据传输速率，以避免网络过载和数据丢失。
• 流量控制：TCP使用滑动窗口机制来控制发送方与接收方之间的数据流量，确保接收方可以按自身处理能力接收数据，避免数据丢失或过载。
• 超时重传：TCP使用超时定时器来检测丢失的数据段，并在超时后触发重传机制，以弥补可能的数据包丢失。

超时重传: 在超时重传策略中，发送方为每个发送的数据段设置一个定时器。如果发送方在特定时间内未收到接收方对该数据段的确认，则会假定数据段丢失，并触发该数据段的重新传输。超时定时器的设定通常基于网络往返时间（Round-Trip Time, RTT）和其他因素。

快速重传：快速重传策略是针对接收方对乱序接收到的数据段进行响应的一种机制。当发送方接收到三个重复的对同一数据段的确认时，它会立即重传该数据段，而不必等待超时定时器的触发。这样可以更快地弥补可能的丢失数据段。

TCP的滑动窗口机制允许发送方根据接收方的处理能力来动态调整发送的数据量，以确保网络中的数据传输不会导致丢失或过载。

接收窗口：接收方通过通知发送方其当前可接收的数据量来定义接收窗口。这个值取决于接收方缓冲区的剩余空间大小，表示接收方可以接收的数据的最大量。

发送窗口：发送方通过通知接收方它还有多少可用的发送缓冲区空间来定义发送窗口。这个值表示发送方可以发送的数据的最大量。

滑动窗口大小：滑动窗口大小是发送窗口和接收窗口中较小的那个值，决定了当前可以在网络上传输的数据量。

动态调整：根据接收端返回的通知和确认信息，发送端会动态地调整发送窗口的大小，以避免向接收方发送过多的数据，从而防止过载和数据丢失。这使得发送方能够根据网络状况和接收方的处理能力灵活地调整数据流量。

流量控制：通过滑动窗口机制，TCP实现了流量控制，即发送方根据接收方的反馈控制数据的发送速率，以适应网络的变化和接收方的处理能力，避免过载和数据丢失。

缓存乱序帧：TCP 接收端会将乱序帧临时存储在缓冲区中，而不会立即交付给应用程序。这样，TCP 可以等待剩余的乱序帧或后续的数据段，以便按正确的顺序将完整的数据传递给应用层。

接收端会向发送端发送重复确认（Duplicate ACK），通知发送端已经收到了某个乱序帧或乱序片段，同时请求发送端重传丢失的数据段。

序列号和确认机制：TCP 对每个发送的数据段进行编号，并要求接收方对其收到的数据段进行确认。通过这种机制，TCP 可以确保数据按正确的顺序到达目的地，且没有丢失或重复。

超时重传: 如果发送方在特定时间内未收到接收方对某个数据段的确认，它会假定该数据段丢失，并触发超时重传机制，以确保数据的完整性。

快速重传：当发送方接收到多个对同一数据段的重复确认时，它会立即重传该数据段，而不必等待超时定时器的触发。这有助于及时弥补可能的数据丢失，从而保证数据的完整性。

校验和：TCP 在每个数据段中包含校验和字段，用于检测数据在传输过程中是否发生了损坏。接收端会验证校验和，以确保收到的数据段没有被篡改或损坏。

滑动窗口机制：TCP 的滑动窗口机制可根据接收方的处理能力动态调整数据流量，避免过载和数据丢失，从而有助于保证数据的完整性。

接收窗口：接收方通过通知发送方其当前可接收的数据量来定义接收窗口。这个值取决于接收方缓冲区的剩余空间大小，表示接收方可以接收的数据的最大量。

发送窗口：发送方通过通知接收方它还有多少可用的发送缓冲区空间来定义发送窗口。这个值表示发送方可以发送的数据的最大量。

滑动窗口大小：滑动窗口大小是发送窗口和接收窗口中较小的那个值，决定了当前可以在网络上传输的数据量。

动态调整：根据接收端返回的通知和确认信息，发送端会动态地调整发送窗口的大小，以避免向接收方发送过多的数据，从而防止过载和数据丢失。这使得发送方能够根据网络状况和接收方的处理能力灵活地调整数据流量。

流量控制：通过滑动窗口机制，TCP实现了流量控制，即发送方根据接收方的反馈控制数据的发送速率，以适应网络的变化和接收方的处理能力，避免过载和数据丢失。

滑动窗口大小是发送窗口和接收窗口中较小的那个值，决定了当前可以在网络上传输的数据量。

可以通过修改 net.ipv4.tcp_wmem 和 net.ipv4.tcp_rmem 参数来调整TCP连接的发送窗口和接收窗口的大小。

sysctl -w net.ipv4.tcp_wmem="4096 16384 4194304"

sysctl -w net.ipv4.tcp_rmem="4096 87380 4194304"

慢启动：发送方在开始发送数据时，以指数增长的速率增加发送窗口大小，以便快速填满网络的可用带宽，但在网络出现拥塞迹象时会触发拥塞避免阶段。慢开始算法的思路就是，不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。

拥塞避免：一旦发送方的发送窗口大小达到一个阈值（拥塞窗口阈值），它将进入拥塞避免阶段。在这个阶段，发送方以线性增长的速率增加发送窗口大小，以避免加剧网络拥塞。

拥塞检测：TCP 发送方通过监视网络中的丢包情况来检测是否发生了拥塞。当发送方检测到丢失的数据包时，它会降低发送速率，以缓解可能的网络拥塞。

快速重传：当发送方接收到比期望序列号大的序列号，并且发送方在收到三个重复的 ACK后，并且发送方可以立即重传期望的数据段，而不必等待超时定时器的触发。这有助于及时恢复由于网络拥塞导致的数据丢失。

拥塞避免算法：TCP 使用拥塞避免算法来动态调整拥塞窗口的大小，以反映网络的拥塞状况，避免过度拥塞并提高网络利用率。

TCP的TIME_WAIT状态是指在连接被关闭后，等待一段时间以确保远端收到了连接释放的确认消息。

确保完整的数据传输：在连接关闭后，处于TIME_WAIT状态的一端仍可以接受对方发送来的最后的 ACK 确认消息。这样可以确保在关闭连接前所有的数据都已经被完整地传输。

防止旧的重复分组干扰新连接：TIME_WAIT 状态会在足够长的时间内保留连接信息，从而避免之前的连接残留导致的随后新的连接中出现混淆和干扰。

提供可靠的连接释放信号：在 TIME_WAIT 状态期间，如果有任何延迟传输的报文段出现，它们会被丢弃，并且不会干扰其他的连接。这有助于确保连接释放的可靠性。

在TCP协议中，TIME_WAIT状态的持续时间通常被设置为2倍的最大报文段生存时间（Maximum Segment Lifetime，MSL）

确保之前的连接信息已经完全消失：TIME_WAIT状态的目的是等待足够长的时间以确保网络中关于之前连接的所有数据传输都已经完成并且与该连接相关的所有报文都已经从网络中消失。通过等待2MSL的时间，可以确保之前连接的所有残留数据都已经从网络中消失。

避免旧连接信息对新连接的干扰：由于网络中的报文可能会存在延迟或乱序等问题，因此在释放连接后的一段时间内，如果有来自旧连接的报文到达，它们不会与新的连接混淆。2MSL的时间可以确保在此期间内，任何与旧连接相关的报文都不会干扰到新的连接。

这个时间限制是为了防止旧的或者失效的报文在网络中无限期地循环。

报文寿命限制：MSL 规定了一个报文在网络中允许存在的最长时间。一旦超过这个时间限制，就应该将其丢弃，以避免旧的报文继续在网络中传播。

报文寿命限制：MSL 规定了一个报文在网络中允许存在的最长时间。一旦超过这个时间限制，就应该将其丢弃，以避免旧的报文继续在网络中传播。

连接释放后的等待时间：在TCP连接中，一旦连接被正常释放，根据TCP规范，需要等待2倍的MSL时间才能确保之前连接的所有残留数据都已经从网络中消失。这也与TIME_WAIT状态的持续时间有关。

通常情况下，MSL 的默认值为 2 分钟，但可以根据不同的实现和配置进行调整。

UDP（用户数据报协议）本身并不提供可靠传输的机制，其关键特征之一是其尽力而为的交付模型，这意味着它不保证数据包的交付或确保其顺序。

构建在 UDP 之上的应用程序可能会实现自己的方法来实现一定程度的可靠性。 用于弥补 UDP 缺乏内置可靠性的一些常用技术包括：

• 应用程序级确认：应用程序可以实现自己的确认机制，接收方确认 UDP 数据包的成功接收。 如果在指定的时间范围内没有收到确认，发送方可以重传数据包。
• 重传逻辑：通过在应用程序级别合并数据包重传逻辑，发送方可以重新发送丢失或未确认的数据包。 这使得应用程序能够处理可靠交付至关重要的场景，尽管会带来额外的复杂性和开销。
• 排序和排序：为了确保数据的有序传送，使用 UDP 的应用程序可以在发送方和接收方包含序列号和排序机制，以重建接收数据包的正确顺序。
• 超时和恢复机制：在应用程序级别实现超时和恢复机制可以帮助管理数据包丢失和重传，提供一种错误恢复形式并确保数据包的及时传送。

UDP

UDP本身是没有重传机制的。

UDP 具有最大有效负载大小限制,对于大数据传输，可以考虑以下策略：

• 数据包分片和重组：应用程序可以在传输之前将消息分段处理成较小的数据包，并在接收端重新组装数据包。 这涉及到将大消息分解成适合最大 UDP 有效负载大小的较小块，单独传输它们，然后在接收方重建原始消息。
• 错误检测和恢复：由于UDP不提供内置的错误检测和恢复机制，应用程序可能需要实现自己的错误检测、确认和重传逻辑，以确保大型UDP消息的可靠传送。

地址解析协议(Address Resolution Protocol)，其基本功能为透过目标设备的IP地址，查询目标的MAC地址，以保证通信的顺利进行。它是IPv4网络层必不可少的协议，不过在IPv6中已不再适用，并被邻居发现协议（NDP）所替代。

Ping是一种网络诊断工具，用于测试与目标主机的连接状态。它通过发送ICMP（Internet Control Message Protocol）回显请求消息到目标主机，并等待目标主机返回 ICMP 回显应答消息，从而来判断两者之间的通信是否正常。

发送 ICMP 请求：当用户在命令行中输入 ping 命令并指定目标主机时，操作系统会创建一个 ICMP Echo Request 消息，并向目标主机发送该消息。

目标主机响应：目标主机收到 ICMP Echo Request 消息后，会生成一个 ICMP Echo Reply 消息，并将其返回给发起请求的主机。

计算往返时间：发起请求的主机接收到 ICMP Echo Reply 消息后，根据发送请求和接收回复的时间差，计算出往返时间（Round-Trip Time，RTT），以及其他相关信息如丢包率等。

显示结果：ping 命令会将收到的回复打印输出，显示往返时间、包大小以及其他统计信息，供用户进行分析。