计算机网络（持续更新）

OSI七层模型及其作用

OSI（Open Systems Interconnection）七层模型是一个用于描述网络协议和通信的概念模型。它将网络通信过程分为七个层次，从低层到高层依次是：物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。下面是每一层的作用简介：

1. 物理层（Physical Layer）：物理层负责在不同设备之间传输比特流（0和1）。它处理物理连接的建立、维护和断开，包括电气特性、机械特性和时序特性等。常见的物理层设备有集线器（Hub）、中继器（Repeater）等，常见的物理层协议有电缆标准（如Ethernet、Token Ring等）。

2. 数据链路层（Data Link Layer）：数据链路层将比特流组织成帧（Frame），并负责在相邻设备之间进行点对点的数据传输。它提供了数据的透明传输、错误检测和流量控制等功能。常见的数据链路层设备有网桥（Bridge）、交换机（Switch）等，常见的数据链路层协议有MAC（媒体访问控制）、LLC（逻辑链路控制）等。

3. 网络层（Network Layer）：网络层负责处理数据包的路由和转发，即确定数据包从源到目的地的路径。它提供了逻辑地址（如IP地址）和网络互连等功能。常见的网络层设备有路由器（Router），常见的网络层协议有IP（互联网协议）、ICMP（互联网控制报文协议）、IGMP（互联网组管理协议）等。

4. 传输层（Transport Layer）：传输层负责在端系统之间提供可靠或不可靠的数据传输服务。它提供了端到端的数据传输、错误检测和恢复、流量控制等功能。常见的传输层协议有TCP（传输控制协议）、UDP（用户数据报协议）等。

5. 会话层（Session Layer）：会话层负责在通信双方之间建立、维护和断开会话。会话层提供了双工、半双工或单工通信等功能。会话层协议有RPC（远程过程调用）、SQL（结构化查询语言）等。

6. 表示层（Presentation Layer）：表示层负责处理数据的表示、编码和解码。它将应用层数据转换为网络可传输的格式，以确保数据在发送端和接收端之间的一致性。表示层协议有ASN.1（抽象语法表示）、MIME（多用途互联网邮件扩展）等。

7. 应用层（Application Layer）：应用层是用户与网络应用程序交互的接口，负责处理应用程序之间的通信。应用层协议有HTTP（超文本传输协议）、FTP（文件传输协议）、SMTP（简单邮件传输协议）、DNS（域名系统）等。

OSI七层模型可以帮助理解网络通信的不同阶段，并在各个层次上实现不同功能，使得网络协议和设备能够相互协同工作。

五层模型

五层模型（也称为TCP/IP模型）是另一种用于描述网络协议和通信过程的概念模型。相较于OSI七层模型，五层模型将网络通信过程简化为5个层次。从低层到高层依次是：物理层、数据链路层、网络层、传输层和应用层。下面是每一层的作用简介：

1. 物理层（Physical Layer）：与OSI七层模型中的物理层相同，负责在不同设备之间传输比特流（0和1）。它处理物理连接的建立、维护和断开，包括电气特性、机械特性和时序特性等。

2. 数据链路层（Data Link Layer）：与OSI七层模型中的数据链路层相同，将比特流组织成帧（Frame），并负责在相邻设备之间进行点对点的数据传输。它提供了数据的透明传输、错误检测和流量控制等功能。

3. 网络层（Network Layer）：与OSI七层模型中的网络层相同，负责处理数据包的路由和转发，即确定数据包从源到目的地的路径。它提供了逻辑地址（如IP地址）和网络互连等功能。

4. 传输层（Transport Layer）：与OSI七层模型中的传输层相同，负责在端系统之间提供可靠或不可靠的数据传输服务。它提供了端到端的数据传输、错误检测和恢复、流量控制等功能。

5. 应用层（Application Layer）：五层模型的应用层包含了OSI七层模型中的会话层、表示层和应用层。它负责处理应用程序之间的通信，数据的表示、编码和解码，以及会话的建立、维护和断开等功能。

五层模型相对于OSI七层模型更加简洁，它将OSI模型中的会话层、表示层和应用层合并为一个统一的应用层，更加符合实际的网络协议和设备的工作方式。

TCP/IP四层模型

TCP/IP四层模型是一个用于描述网络协议和通信过程的概念模型。它是基于TCP/IP协议簇设计的，相较于OSI七层模型和五层模型，TCP/IP模型进一步简化了网络通信过程。从低层到高层依次是：网络接口层、网络层、传输层和应用层。下面是每一层的作用简介：

1. 网络接口层（Network Interface Layer）：网络接口层对应了OSI模型中的物理层和数据链路层。它负责将数据帧在网络设备之间进行传输，处理物理连接的建立、维护和断开，以及数据的透明传输、错误检测和流量控制等功能。

2. 网络层（Network Layer）：与OSI模型和五层模型中的网络层相同，负责处理数据包的路由和转发，即确定数据包从源到目的地的路径。它提供了逻辑地址（如IP地址）和网络互连等功能。常见的网络层协议有IP（互联网协议）、ICMP（互联网控制报文协议）、IGMP（互联网组管理协议）等。

3. 传输层（Transport Layer）：与OSI模型和五层模型中的传输层相同，负责在端系统之间提供可靠或不可靠的数据传输服务。它提供了端到端的数据传输、错误检测和恢复、流量控制等功能。常见的传输层协议有TCP（传输控制协议）、UDP（用户数据报协议）等。

4. 应用层（Application Layer）：TCP/IP模型的应用层包含了OSI模型中的会话层、表示层和应用层。它负责处理应用程序之间的通信，数据的表示、编码和解码，以及会话的建立、维护和断开等功能。常见的应用层协议有HTTP（超文本传输协议）、FTP（文件传输协议）、SMTP（简单邮件传输协议）、DNS（域名系统）等。

TCP/IP四层模型以实际应用为基础，将网络通信过程进一步简化，使得网络协议和设备能够更有效地协同工作。

键入网址到网页显示，期间发生了什么？

当你在浏览器中输入网址并按下回车键后，从输入网址到页面显示，整个过程涉及到多个步骤。以下是一个简化的概述：

1. 域名解析（DNS查询）：首先，浏览器需要将输入的域名解析为服务器的IP地址。这个过程由DNS（域名系统）完成。浏览器会向本地或配置的DNS服务器发送查询请求，DNS服务器会逐级查询，找到对应的IP地址后返回给浏览器。

2. 建立连接（TCP三次握手）：浏览器获取到目标服务器的IP地址后，会尝试通过TCP协议与服务器建立连接。这个过程通常包括“三次握手”：

   • 浏览器向服务器发送一个SYN（同步）报文；

   • 服务器收到SYN报文后，返回一个SYN+ACK（确认）报文；

   • 浏览器收到SYN+ACK报文后，再发送一个ACK报文。

   当三次握手成功完成后，浏览器与服务器之间建立了TCP连接。

3. 发送HTTP请求：TCP连接建立后，浏览器会通过该连接向服务器发送一个HTTP请求。这个请求包含了请求方法（如GET或POST）、请求路径（如/index.html）、HTTP版本（如HTTP/1.1）以及其他请求头信息（如User-Agent、Accept等）。

4. 服务器处理请求：服务器接收到浏览器的HTTP请求后，会根据请求信息处理并生成一个HTTP响应。这个响应包含了响应状态码（如200表示成功），响应头信息（如Content-Type、Content-Length等）以及响应主体（通常是HTML文档）。

5. 接收并显示页面：浏览器接收到服务器的HTTP响应后，会解析响应头信息和HTML文档。然后，浏览器会根据HTML文档中的CSS和JavaScript文件，再次发起请求以获取这些资源。最后，浏览器根据HTML、CSS和JavaScript渲染页面并显示给用户。

6. 断开连接（TCP四次挥手）：页面显示完成后，浏览器和服务器会通过TCP四次挥手过程关闭TCP连接。具体过程如下：

   • 浏览器发送一个FIN（结束）报文给服务器；

   • 服务器收到FIN报文后，发送一个ACK报文给浏览器；

   • 服务器发送一个FIN报文给浏览器；

   • 浏览器收到FIN报文后，发送一个ACK报文给服务器。

   当四次挥手成功完成后，TCP连接关闭。

以上就是从键入网址到网页显示所经历的过程。实际上，这个过程涉及到许多细节和异常处理，但这里只列出了主要步骤。

HTTP是什么

HTTP是超文本传输协议

HTTP的主要特点有：

1. 无状态：HTTP是无状态协议，这意味着服务器不会保存客户端请求之间的任何信息。每个请求都被视为独立的事务。可以通过使用Cookie或Session等技术在服务器端和客户端之间维护状态信息。

2. 可靠传输：HTTP使用TCP协议作为其传输层，因此它能够确保数据在客户端和服务器之间可靠地传输。

3. 简单易用：HTTP的设计使其易于理解和实现，请求和响应消息的结构清晰，易于分析和处理。

4. 可扩展性：HTTP支持扩展，可以通过自定义请求头和响应头来传递额外的信息。此外，通过使用不同的请求方法（如GET、POST、PUT、DELETE等），HTTP可以支持多种操作。

HTTP常见的状态码

1. 1xx（信息响应）：表示请求已被接收，服务器正在处理。

   • 100 Continue：客户端可以继续发送请求。

2. 2xx（成功）：表示请求已成功处理。

   • 200 OK：请求成功，服务器已返回请求的数据。

   • 201 Created：请求成功，服务器已创建了新的资源。

   • 204 No Content：请求成功，但没有资源返回（通常用于DELETE请求）。

3. 3xx（重定向）：表示请求需要进一步操作才能完成。

   • 301 Moved Permanently：资源已永久移动到新的URL。

   • 302 Found：资源已临时移动到新的URL。

   • 304 Not Modified：资源在上次请求后未发生变化，客户端可以使用缓存的版本。

4. 4xx（客户端错误）：表示客户端发送的请求有误。

   • 400 Bad Request：请求格式有误，服务器无法理解。

   • 401 Unauthorized：请求需要身份验证。

   • 403 Forbidden：客户端没有权限访问该资源。

   • 404 Not Found：请求的资源在服务器上不存在。

   • 405 Method Not Allowed：请求使用了不被允许的HTTP方法。

   • 408：表示请求超时（Request Timeout）客户端发起的请求在服务器端等待响应的过程中超时，服务器没有在规定的时间内返回响应结果

5. 5xx（服务器错误）：表示服务器在处理请求时发生了错误。

   • 500 Internal Server Error：服务器内部错误，无法处理请求。

   • 501 Not Implemented：服务器不支持当前请求所需要的功能。

   • 502 Bad Gateway：作为代理或负载均衡器的服务器从上游服务器收到了无效的响应。

   • 503 Service Unavailable：服务器暂时无法处理请求（可能由于过载或维护）。

   • 504 Gateway Timeout：作为代理或负载均衡器的服务器等待上游服务器的响应超时。

以上是HTTP常见的状态码，它们有助于了解请求处理过程中发生的情况。在实际应用中，开发者需要根据不同的状态码来处理不同的情况，例如重试请求、提示用户错误等。

GET与POST的区别

GET和POST是HTTP协议中最常见的两种请求方法，它们在设计和使用上有一些重要的区别：

1. 用途：

   • GET：用于从服务器获取资源。它是幂等的（idempotent），即多次执行相同的GET请求不会产生不同的效果。

   • POST：用于向服务器提交数据以创建或更新资源。它通常不是幂等的，因为多次执行相同的POST请求可能导致多次创建或更新资源。

2. 数据传输：

   • GET：将请求参数附加在URL上，如http://example.com/api/resource?key=value。这意味着参数对用户和服务器日志可见，可能导致安全和隐私问题。URL长度受限制，因此GET请求不适合传输大量数据。

   • POST：将请求参数放在请求体（body）中发送，这使得传输的数据对用户不可见，且理论上没有长度限制。这使得POST请求更适合传输敏感信息和大量数据。

3. 缓存和书签：

   • GET：由于请求参数在URL中，浏览器可以缓存GET请求的结果，也可以将其添加到书签或分享给其他用户。这使得GET请求更适合用于获取可缓存和可共享的资源。

   • POST：由于请求参数在请求体中，浏览器通常不会缓存POST请求的结果，也无法将其添加到书签或分享给其他用户。这使得POST请求更适合用于提交敏感信息和不可缓存的资源。

4. 安全性：

   • GET：相对不安全，因为请求参数在URL中可见，容易被拦截或篡改。此外，用户可能在浏览器历史记录中查看请求参数。

   • POST：相对更安全，因为请求参数在请求体中，对用户和拦截者不可见。然而，POST请求本身并不提供加密功能，对于传输敏感信息，应使用HTTPS来确保安全性。

总之，GET和POST各有用途和优缺点。在实际应用中，开发者需要根据实际需求和场景选择合适的请求方法。例如，对于获取资源的API，应使用GET请求；对于提交数据以创建或更新资源的API，应使用POST请求。

HTTP缓存技术

• 强制缓存

强缓存指的是只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边。

• 协商缓存

当我们在浏览器使用开发者工具的时候，你可能会看到过某些请求的响应码是 304，这个是告诉浏览器可以使用本地缓存的资源，通常这种通过服务端告知客户端是否可以使用缓存的方式被称为协商缓存。

HTTP1.0

优点：

1. 简单易实现：HTTP/1.0协议相对简单，易于理解和实现。它为Web的早期发展提供了基础，使得互联网能够快速普及。

2. 无状态（Stateless）：HTTP/1.0是无状态协议，这意味着每个请求都是独立的，服务器不需要存储关于客户端的状态信息。这简化了服务器的设计，使得服务器可以更容易地扩展。

缺点：

1. 非持久连接（Non-Persistent Connections）：HTTP/1.0默认使用非持久连接，即每个HTTP请求都需要建立一个新的TCP连接。这导致了较高的连接建立和关闭成本，降低了性能。

2. 缓存控制有限：HTTP/1.0支持Expires头字段，但它的功能相对有限。HTTP/1.1引入的Cache-Control头字段提供了更丰富的缓存控制选项。

3. 不支持管道传输（Pipelining）：HTTP/1.0不支持管道传输，即客户端必须等待当前请求的响应后才能发送下一个请求。这增加了请求的往返延迟（Round-Trip Time, RTT）。

4. 不支持分块传输编码（Chunked Transfer-Encoding）：HTTP/1.0不支持分块传输编码，这意味着服务器必须在生成完整的响应后才能开始发送数据。这可能导致客户端等待时间较长，尤其是对于动态生成的大型响应。

性能：

由于HTTP/1.0的非持久连接、无管道传输等限制，它在性能方面存在明显的不足。HTTP/1.1对这些问题进行了改进，如引入持久连接、管道传输等，从而提高了Web应用的性能。

HTTP1.1

HTTP/1.1是HTTP协议的一个版本，相较于HTTP/1.0，它引入了许多改进和优化，但也有一些缺点。下面列出了HTTP/1.1的优缺点和性能：

优点：

1. 持久连接（Persistent Connections）：HTTP/1.1默认使用持久连接，这意味着在一个TCP连接上可以发送多个HTTP请求，而不是每个请求都建立一个新的TCP连接。这减少了TCP连接建立和关闭的开销，提高了性能。

2. 管道传输（Pipelining）：HTTP/1.1支持管道传输，允许客户端在收到上一个请求的响应之前发送多个请求。这可以进一步减少请求的往返延迟（Round-Trip Time, RTT）。

3. 更细粒度的缓存控制：HTTP/1.1引入了Cache-Control头字段，提供了更丰富的缓存控制选项，如max-age、no-cache等。这使得开发者能够更灵活地控制资源的缓存策略，提高应用的性能。

缺点：

1. 队头阻塞（Head-of-Line Blocking）：由于HTTP/1.1在一个TCP连接上顺序处理请求和响应，因此一个请求的延迟会影响后续请求的处理。这导致了队头阻塞问题，降低了性能。

2. 多个TCP连接：由于队头阻塞问题，浏览器通常会为一个域名建立多个TCP连接（通常为6个），以并行处理请求。然而，这增加了服务器的连接开销，并可能导致网络拥塞。

3. 文本格式（非二进制）：HTTP/1.1使用文本格式来表示头部字段，这使得解析和生成头部字段的过程相对低效。

4. 请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩 Body 的部分；

5. 发送冗长的首部。每次互相发送相同的首部造成的浪费较多；

6. 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞；

7. 没有请求优先级控制；

8. 请求只能从客户端开始，服务器只能被动响应。

性能：

尽管HTTP/1.1引入了许多优化，如持久连接、管道传输等，但它仍然面临队头阻塞等问题，限制了性能的提升。为了解决HTTP/1.1的性能问题，HTTP/2和HTTP/3协议应运而生，它们采用了多路复用、二进制格式等改进，进一步提高了Web应用的性能。

HTTP2.0

• HTTP/2是HTTP协议的一个较新版本，旨在解决HTTP/1.1中的一些性能问题。以下是HTTP/2的优缺点和性能：

  优点：

  1. 二进制格式：HTTP/2使用二进制格式表示头部字段，这使得解析和生成头部字段的过程更加高效。此外，二进制格式还可以提高传输的稳定性和可靠性。

  2. 头部压缩（Header Compression）：HTTP/2使用HPACK算法对头部字段进行压缩，减少了头部字段的传输大小。这有助于降低带宽消耗，提高性能。

  3. 服务器推送（Server Push）：HTTP/2支持服务器主动向客户端推送资源，而不需要客户端显式请求。这可以进一步减少请求的往返延迟，提高页面加载速度。

  4. 优先级控制（Priority Control）：HTTP/2允许客户端指定请求的优先级，使得服务器能够根据优先级分配带宽和资源。这有助于提高关键资源的加载速度，提升用户体验。

  缺点：

  1. 加密开销：虽然HTTP/2本身不强制使用TLS加密，但大多数浏览器要求HTTP/2连接必须使用TLS。TLS加密会带来一定的计算和传输开销，可能影响性能。

  2. 实现复杂性：HTTP/2引入了多路复用、头部压缩等新特性，增加了实现的复杂性。这可能导致在某些场景下性能不如预期，需要进行优化。

  3. 兼容性问题：虽然大多数现代浏览器和服务器都支持HTTP/2，但仍有一些旧版本的客户端和服务器不支持。这可能导致需要维护HTTP/1.1和HTTP/2的双重实现。

  性能：

  相较于HTTP/1.1，HTTP/2引入了多路复用、头部压缩等特性，显著提高了Web应用的性能。实际测试表明，HTTP/2可以在某些场景下减少页面加载时间约50%。然而，HTTP/2的性能优势可能受到TLS加密开销、实现复杂性等因素的影响。因此，在实际应用中，性能提升可能因网络环境、服务器配置等因素而异。

HTTP3.0

HTTP/3是HTTP协议的最新版本，它基于QUIC协议（Quick UDP Internet Connections），旨在解决HTTP/2中的一些性能问题。以下是HTTP/3的优缺点和性能：

优点：

1. 快速建立连接：HTTP/3使用QUIC协议，可以在一个往返延迟（Round-Trip Time, RTT）内建立连接，而传统的HTTP/1.1和HTTP/2基于TCP协议，需要多个RTT才能建立连接。这显著减少了页面加载时间，尤其是在高延迟网络环境下。

2. 无队头阻塞（No Head-of-Line Blocking）：HTTP/3中，每个请求和响应的流使用单独的QUIC连接，这使得即使某个连接受到丢包影响，其他连接仍能正常传输，避免了HTTP/2中的队头阻塞问题。

3. 内置加密：HTTP/3基于QUIC协议，QUIC协议将TLS加密直接集成在传输层，提供了更强的安全性，同时减少了加密和解密的延迟。

4. 更好的拥塞控制：HTTP/3使用QUIC协议，QUIC协议具有更先进的拥塞控制算法，可以更好地适应各种网络环境，提高传输性能。

5. 前向错误纠正（Forward Error Correction, FEC）：QUIC协议支持前向错误纠正，可以在不重新传输数据的情况下恢复丢失的数据包，降低了数据传输的延迟。

缺点：

1. 实现复杂性：HTTP/3基于全新的QUIC协议，与HTTP/1.1和HTTP/2的TCP协议有较大差异，增加了实现和部署的复杂性。

2. 兼容性问题：虽然大多数现代浏览器和服务器都开始支持HTTP/3，但仍有一些旧版本的客户端和服务器不支持。这可能导致需要维护HTTP/1.1、HTTP/2和HTTP/3的多重实现。

3. UDP阻塞：QUIC协议基于UDP，而某些网络环境（如企业或学校网络）可能会限制或阻止UDP流量，影响HTTP/3的可用性。

性能：

HTTP/3引入了基于QUIC协议的新特性，例如快速建立连接、无队头阻塞等，显著提高了Web应用的性能。实际测试表明，HTTP/3在高延迟和丢包率的网络环境下表现尤为优异。然而，在实际应用中，性能提升可能因网络环境、服务器配置等因素而异。需要注意的是，HTTP/3仍处于发展初期，随着实现和部署的不断完善，性能有望进一步提高。

HTTP与HTTPS

HTTP和HTTPS区别

HTTP（HyperText Transfer Protocol）和HTTPS（HyperText Transfer Protocol Secure）都是用于传输超文本的协议。它们之间的主要区别在于安全性和数据传输方式。以下是HTTP和HTTPS的区别：

1. 安全性：HTTP是明文传输，意味着传输的数据没有加密，容易被中间人攻击者截获和篡改。而HTTPS使用了SSL/TLS协议对数据进行加密，可以保护数据的隐私和完整性，提高了安全性。

2. 端口：HTTP使用默认端口80，而HTTPS使用默认端口443。

3. 证书：HTTPS需要服务器获取并安装SSL/TLS证书。证书由证书颁发机构（CA）签发，用于验证服务器的身份和提供加密所需的密钥。HTTP不需要证书。

4. 性能：因为HTTPS使用了SSL/TLS加密，加解密会带来一定的计算开销。虽然现代硬件和优化的加密算法已经降低了这种开销，但在某些情况下，HTTPS的性能可能略逊于HTTP。

5. 浏览器显示：当使用HTTPS时，浏览器会在地址栏显示一个绿色的锁图标，表示连接是安全的。部分浏览器还会显示网站的组织名称，提高用户对网站安全性的信任度。而HTTP连接不会显示锁图标。

总结：HTTP和HTTPS的主要区别在于安全性。HTTPS使用SSL/TLS协议对数据进行加密，保护用户数据的隐私和完整性。虽然HTTPS的性能可能略逊于HTTP，但随着技术的发展，这种差距已经不再明显。鉴于安全性的重要性，越来越多的网站和应用选择使用HTTPS。

HTTPS解决了HTTP什么问题

HTTPS（HyperText Transfer Protocol Secure）解决了HTTP（HyperText Transfer Protocol）在数据传输过程中的安全问题。具体来说，它主要解决了以下几个问题：（窃听问题、篡改问题、冒充问题）

1. 数据泄露：HTTP以明文形式传输数据，容易被中间人攻击者截获。而HTTPS通过SSL/TLS协议对数据进行加密，即使被截获，攻击者也无法轻易解密并获取原始数据。这保护了用户数据的隐私，防止了数据泄露。

2. 数据篡改：HTTP传输的数据容易被中间人攻击者篡改。攻击者可以修改传输的内容，例如插入恶意代码、广告等。而HTTPS提供了数据完整性保护，确保数据在传输过程中不被篡改。这降低了被攻击的风险，提高了网站和应用的可信度。

3. 身份伪装：攻击者可以通过伪装成合法网站来诱使用户泄露敏感信息，例如账号密码等。而HTTPS使用SSL/TLS证书对服务器进行身份验证，证书由可信的证书颁发机构（CA）签发。用户可以通过浏览器的安全提示（如绿色的锁图标）来确认网站的身份，防止访问伪装的网站。

4. 会话劫持：HTTP协议中的会话信息（如Cookie）也是明文传输，容易被中间人攻击者截获并利用。而HTTPS对会话信息进行加密，降低了会话劫持的风险。

总之，HTTPS解决了HTTP在数据传输过程中的安全问题，包括数据泄露、数据篡改、身份伪装和会话劫持。通过使用HTTPS，可以提高网站和应用的安全性、可信度和用户体验。

什么是粘包问题

粘包问题是指在基于 TCP 协议的数据传输过程中，由于 TCP 是一个面向字节流的可靠传输协议，接收方在接收数据时可能会将多个数据包收到一起，形成一个“粘在一起”的数据包。这种现象称为粘包。粘包问题通常出现在客户端和服务器之间发送的数据包较小或发送速度较快的情况下。

粘包问题的主要原因有以下几点：

1. TCP 无法识别应用层数据边界：TCP 是一个面向字节流的传输协议，它只负责保证数据的可靠传输，但无法识别应用层数据的边界。因此，当发送方连续发送多个数据包时，接收方可能会一次性接收到这些数据包，导致粘包问题。

2. TCP 流量控制和拥塞控制：TCP 协议通过流量控制和拥塞控制来保证网络的稳定性。在传输过程中，根据网络状况和接收方的处理能力，TCP 可能会将多个小数据包合并成一个较大的数据包，或者将一个大数据包拆分成多个小数据包进行传输。这也可能导致粘包问题。

3. 应用层缓冲区处理：发送方和接收方的应用层缓冲区也可能导致粘包问题。例如，当发送方的应用层缓冲区满时，可能会将多个数据包合并成一个数据包发送；而接收方在处理接收到的数据时，如果一次性读取了多个数据包，也可能导致粘包。

为了解决粘包问题，通常采用以下几种方法：

1. 固定长度的数据包：将每个数据包的长度固定，这样接收方在接收数据时可以根据固定长度来分割数据包。

2. 添加分隔符：在每个数据包的末尾添加特定的分隔符，接收方在接收数据时可以根据分隔符来分割数据包。

3. 长度前缀：在每个数据包的开头添加表示数据包长度的字段，接收方在接收数据时可以根据这个长度字段来分割数据包。

4. 应用层协议：实现自定义的应用层协议，该协议可以包含数据包的边界信息，以便在接收方正确地分割数据包。

通过以上方法，可以在一定程度上解决 TCP 协议中的粘包问题，确保应用层数据的正确传输和处理。

TCP和UDP的区别，以及场景

TCP（传输控制协议）和UDP（用户数据报协议）是两种常见的传输层协议，它们在网络通信中有着不同的特点和应用场景。

TCP的特点和应用场景：

1. 面向连接：TCP使用三次握手建立连接，确保通信双方建立可靠的连接后再进行数据传输。

2. 可靠性：TCP保证数据的可靠传输，通过序列号、确认应答和重传机制来确保数据的完整性和正确性。

3. 有序性：TCP会按照发送顺序保证数据包在接收端按序重组，避免数据包乱序的情况。

4. 流控制和拥塞控制：TCP通过流量控制和拥塞控制算法来平衡发送和接收数据的速率，防止网络拥塞。

5. 应用场景：TCP适用于对数据完整性和可靠性要求较高的应用，如网页浏览、文件传输、电子邮件等。

UDP的特点和应用场景：

1. 无连接：UDP不需要建立连接，直接将数据包发送出去，适用于无需建立持久连接的通信场景。

2. 不可靠性：UDP不保证数据的可靠传输，数据包可能丢失、重复、乱序，需要应用层自行处理丢失情况。

3. 无序性：UDP的数据包可能按照发送顺序的不同在接收端乱序到达，应用层需要处理乱序的情况。

4. 低延迟：由于不需要建立连接和拥有较少的控制机制，UDP传输具有较低的延迟。

5. 应用场景：UDP适用于对实时性要求较高的应用，如视频直播、在线游戏、音频通话等。在这些场景下，实时性更重要，而对于数据丢失的情况，可以通过应用层的处理来进行容忍或纠正。

TCP和UDP能共用一个端口？

答案：可以

简介回答：端口号的目的主要是为了区分同一个主机不同应用程序的数据包，传输层有两个传输协议分别是 TCP 和 UDP，在内核中是两个完全独立的软件模块，当主机收到数据包后，可以在 IP 包头的「协议号」字段知道该数据包是 TCP/UDP，所以可以根据这个信息确定送给哪个模块（TCP/UDP）处理，送给 TCP/UDP 模块的报文根据「端口号」确定送给哪个应用程序处理。

详细回答：在一般情况下，TCP和UDP是不能共用一个端口的。TCP和UDP是两种不同的传输层协议，它们使用不同的端口来进行通信。每个网络通信应用都使用特定的端口号来与其他应用进行交流。TCP和UDP各自有独立的端口号空间，这意味着一个特定的端口号在TCP和UDP之间可以同时存在，但它们对应的是不同的应用或服务。例如，HTTP通常使用TCP协议在80端口进行通信，DNS通常使用UDP协议在53端口进行通信。这意味着在同一时间，80端口可能被TCP协议的HTTP使用，而53端口可能被UDP协议的DNS使用，二者不会相互干扰。然而，也有一些特殊情况下，某些应用或协议可以同时使用TCP和UDP共享同一个端口。这被称为"TCP/UDP多路复用"或"TCP/UDP Port Sharing"。这种情况下，应用程序需要负责处理接收到的数据，并根据数据包的内容区分使用TCP还是UDP来处理数据。这样的机制通常由应用层协议自行实现，而不是由TCP和UDP协议栈提供的默认功能。总的来说，大多数情况下，TCP和UDP使用独立的端口来避免混淆和冲突。但特定的应用场景下，TCP/UDP多路复用可以实现在同一个端口上同时使用TCP和UDP。

TCP的建立

TCP三次握手过程

TCP三次握手是建立TCP连接的过程，它用于确保客户端和服务器之间建立可靠的连接。以下是TCP三次握手的过程：

1. 第一次握手（SYN）：

   • 客户端向服务器发送一个连接请求报文段，其中设置了SYN标志位（SYN=1）。

   • 客户端选择一个初始序列号（ISN，Initial Sequence Number），用于后续数据的传输。

2. 第二次握手（SYN+ACK）：

   • 服务器收到客户端的连接请求后，回复一个确认报文段作为回应。

   • 服务器在回复的报文段中设置了SYN和ACK标志位（SYN=1，ACK=1）。

   • 服务器也选择一个初始序列号（ISN）用于后续数据传输，并将确认号（ACK）设置为客户端的初始序列号（ISN + 1）。

3. 第三次握手（ACK）：

   • 客户端收到服务器的确认报文段后，向服务器发送一个确认报文段。

   • 客户端在这个报文段中设置了ACK标志位（ACK=1）。

   • 客户端的确认号（ACK）被设置为服务器的初始序列号（ISN + 1），表示已收到服务器的回应。

一旦服务器收到客户端的确认报文段，TCP连接就建立成功，可以开始进行数据传输。在这个过程中，客户端和服务器通过交换序列号和确认号来确保彼此能够正确接收数据，从而建立可靠的连接。第三次握手是可以携带数据的，前两次握手是不可以携带数据的

为什么是三次握手、不是两次、四次

• 三次握手才可以阻止重复历史连接的初始化（主要原因）

• 三次握手才可以同步双方的初始序列号

• 三次握手才可以避免资源浪费

• 「两次握手」：无法防止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序列号；

• 「四次握手」：三次握手就已经理论上最少可靠连接建立，所以不需要使用更多的通信次数。

为什么每次建立连接，初始化序列号要求不一样

• 为了防止历史报文被下一个相同四元组的连接接收（主要方面）；

• 为了安全性，防止黑客伪造的相同序列号的 TCP 报文被对方接收；

增强安全性： 选择不同的初始序列号可以增强安全性。如果每次建立连接时初始序列号都是相同的，那么攻击者可以利用这个预测性来发动网络攻击，例如TCP序列号预测攻击。通过选择不同的初始序列号，可以增加攻击者猜测序列号的难度，提高连接的安全性。

防止旧连接的混淆： TCP协议要求，当处于TIME_WAIT状态的连接结束后，必须经过一段时间的等待才能确保网络上的所有数据包都被丢弃。在此期间，如果有新的连接建立并选择了与已结束的旧连接相同的初始序列号，可能会导致新连接收到旧连接的数据包，从而造成混淆。通过选择不同的初始序列号，可以避免这种情况的发生。

TCP连接断开

四次挥手过程

TCP四次挥手是终止TCP连接的过程，用于断开客户端和服务器之间的连接。以下是TCP四次挥手的过程：

1. 第一次挥手（FIN）：

   • 客户端向服务器发送一个连接关闭请求，其中设置了FIN标志位（FIN=1）。

   • 客户端不再发送数据，但仍可以接收服务器发送的数据。

2. 第二次挥手（ACK）：

   • 服务器收到客户端的连接关闭请求后，回复一个确认报文段作为回应。

   • 服务器在回复的报文段中设置了ACK标志位（ACK=1），确认客户端的关闭请求。

   • 服务器可能仍有数据要发送给客户端，所以服务器的FIN标志位尚未设置。

3. 第三次挥手（FIN）：

   • 服务器继续发送数据给客户端，在数据发送完毕后，将自己的连接关闭请求发送给客户端。

   • 服务器设置FIN标志位（FIN=1），表示服务器准备关闭连接。

4. 第四次挥手（ACK）：

   • 客户端收到服务器的连接关闭请求后，回复一个确认报文段作为回应。

   • 客户端在回复的报文段中设置了ACK标志位（ACK=1），确认服务器的关闭请求。

   • 至此，TCP连接正式关闭。

注意：在进行四次挥手过程中，客户端和服务器都可以在最后一次挥手前发送数据，因为FIN标志位只表示自己不再发送数据，而并不表示对方不再发送数据。因此，四次挥手可能是"FIN-WAIT-1"，"FIN-WAIT-2"，"TIME-WAIT"等状态之间的过程。等待一段时间后，处于TIME-WAIT状态的一方会关闭连接，完成整个四次挥手过程。

为什么TIME_WAIT等待时间是2MSL

MSL：报文最大生存时间

TTL：经过路由跳数

TTL 的值一般是 64，Linux 将 MSL 设置为 30 秒，意味着 Linux 认为数据报文经过 64 个路由器的时间不会超过 30 秒，如果超过了，就认为报文已经消失在网络中了。

网络中可能存在来自发送方的数据包，当这些发送方的数据包被接收方处理后又会向对方发送响应，所以一来一回需要等待 2 倍的时间TIME_WAIT等待时间为2倍的MSL（Maximum Segment Lifetime），这个值是为了确保在网络中所有可能的冗余数据包都已经被丢弃，从而保证TCP连接的可靠关闭。

滑动窗口

窗口大小：指无需等待确认应答，而可以继续发送数据的最大值

TCP头部有个字段叫Window，也就是窗口的大小，这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来，通常窗口的大小是由接受方的窗口大小决定的。

发送方的窗口

• #1 是已发送并收到 ACK确认的数据：1~31 字节

• #2 是已发送但未收到 ACK确认的数据：32~45 字节

• #3 是未发送但总大小在接收方处理范围内（接收方还有空间）：46~51字节

• #4 是未发送但总大小超过接收方处理范围（接收方没有空间）：52字节以后

TCP滑动窗口方案使用三个指针来跟踪四个传输类别中的每个类别中的字节。其中两个指针是绝对指针（指确定的序列号），一个是相对指针（需要做偏移）

• SND.WND：表示发送窗口的大小（大小是由接收方指定的）

• SND.UNA（Send Unacknoleged）：是一个绝对指针，它指向的是已发送但未收到确认的第一个字节的序列号，也就是 #2 的第一个字节

• SND.NXT：也是一个绝对指针，它指向未发送但可发送范围的第一个字节的序列号，也就是 #3 的第一个字节

• 指向 #4 的第一个字节是个相对指针，它需要 SND.UNA 指针加上 SND.WND 大小的偏移量，就可以指向 #4 的第一个字节了

那么可用窗口大小的计算就可以是：可用窗口大小 = SND.WND -（SND.NXT - SND.UNA）

接受方的窗口

• #1 + #2 是已成功接收并确认的数据（等待应用进程读取）；

• #3 是未收到数据但可以接收的数据；

• #4 未收到数据并不可以接收的数据；

接收和发送窗口相等吗

并不是完全相等，接收窗口的大小是约等于发送窗口的大小的。

因为滑动窗口并不是一成不变的。比如，当接收方的应用进程读取数据的速度非常快的话，这样的话接收窗口可以很快的就空缺出来。那么新的接收窗口大小，是通过 TCP 报文中的 Windows 字段来告诉发送方。那么这个传输过程是存在时延的，所以接收窗口和发送窗口是约等于的关系。

流量控制

TCP 提供一种机制可以让「发送方」根据「接收方」的实际接收能力控制发送的数据量，这就是所谓的流量控制。

TCP 流量控制是指通过一系列的机制来确保发送方与接收方之间的数据传输速率适应接收方的处理能力，以防止过多的数据发送导致接收方无法及时处理而发生数据丢失或网络拥塞的情况。

TCP流量控制的主要目标

1. 防止数据丢失和拥塞：如果发送方一次性发送大量数据，可能会导致网络拥塞，数据丢失或延迟增加。

2. 适应接收方速率：接收方可能处理数据的速度较慢，流量控制可以使发送方的速率适应接收方的处理能力。

TCP 流量控制的主要机制是通过滑动窗口（Sliding Window）和确认机制来实现的。

TCP 流量控制的基本原理

1. 滑动窗口（Sliding Window）： 发送方和接收方之间维护一个滑动窗口，该窗口指示了接收方当前能够接受的数据量。发送方根据接收方报告的窗口大小来动态调整发送数据的量，以保证不会超过接收方的处理能力。

2. 确认机制： 接收方会周期性地向发送方发送确认（ACK）信息，表明接收方成功接收了某个特定序号的数据。发送方收到确认后，会将对应的数据序号从发送窗口中移除，从而允许发送新的数据。

TCP 流量控制实现的特性

• 滑动窗口大小调整： 接收方可以根据自身的处理能力和缓冲区情况来动态调整窗口大小。如果接收方的缓冲区还有空间，窗口会增大，允许发送更多数据；如果缓冲区满了，窗口会减小，限制发送数据的速率。

• 慢启动和拥塞避免： TCP 在建立连接时采用慢启动算法，初始窗口较小，然后逐渐增加发送窗口，以便探测网络的拥塞情况。一旦网络出现拥塞，TCP 会进入拥塞避免状态，通过线性增加发送窗口来稳定网络拥塞情况。

• 超时重传： 如果发送方没有在一定时间内收到接收方的确认，就会认为数据丢失，触发超时重传机制，重新发送数据。这也有助于控制网络拥塞情况。

TCP流量控制的过程

1. 发送方发送数据段给接收方。

2. 接收方接收数据并发送确认。

3. 发送方根据接收方发送的确认来确定接收窗口的大小，确保发送数据的数量不会超过接收方的处理能力。

4. 发送方还根据拥塞窗口的大小来控制发送速率，以避免网络拥塞。

总之，TCP 流量控制确保了在发送方和接收方之间的数据传输速率匹配，从而保证了可靠的数据传输，避免了数据丢失和网络拥塞问题。

窗口关闭

如果窗口大小为 0 时，就会阻止发送方给接收方传递数据，直到窗口变为非 0 为止，这就是窗口关闭。

那么，当发生窗口关闭时，接收方处理完数据后，会向发送方通告一个窗口非 0 的 ACK 报文，如果这个通告窗口的 ACK 报文在网络中丢失了，那麻烦就大了。这会导致发送方一直等待接收方的非 0 窗口通知，接收方也一直等待发送方的数据，如不采取措施，这种相互等待的过程，会造成了死锁的现象。

如何解决窗口关闭潜在的死锁问题

为了解决这个问题，TCP 为每个连接设有一个持续定时器，只要 TCP 连接一方收到对方的零窗口通知，就启动持续计时器。如果持续计时器超时，就会发送窗口探测 ( Window probe ) 报文，而对方在确认这个探测报文时，给出自己现在的接收窗口大小。

• 如果接收窗口仍然为 0，那么收到这个报文的一方就会重新启动持续计时器；

• 如果接收窗口不是 0，那么死锁的局面就可以被打破了。

窗口探测的次数一般为 3 次，每次大约 30-60 秒（不同的实现可能会不一样）。如果 3 次过后接收窗口还是 0 的话，有的 TCP 实现就会发 RST 报文来中断连接。

拥塞控制

为什么需要拥塞控制

尽管TCP已经引入了流量控制机制来确保发送方不会以过快的速率向接收方发送数据，但流量控制仅仅关注于发送方和接收方之间的数据传输。然而，网络中的其他因素，如网络拥塞、延迟、丢包等问题，可能会影响整体的网络性能和吞吐量。这就是为什么TCP还需要引入拥塞控制机制的原因。

拥塞窗口，和发送窗口有什么关系

拥塞窗口 cwnd是发送方维护的一个的状态变量，它会根据网络的拥塞程度动态变化的。

我们在前面提到过发送窗口 swnd 和接收窗口 rwnd 是约等于的关系，那么由于加入了拥塞窗口的概念后，此时发送窗口的值是swnd = min(cwnd, rwnd)，也就是拥塞窗口和接收窗口中的最小值。

拥塞窗口 cwnd 变化的规则：

• 只要网络中没有出现拥塞，cwnd 就会增大；

• 但网络中出现了拥塞，cwnd 就减少；

只要「发送方」没有在规定时间内接收到 ACK 应答报文，当发生了超时重传，就会认为网络出了拥塞

拥塞控制的控制算法

慢启动

TCP刚开始建立连接，一点一点发送数据包，当发送方每收到一个ACK，拥塞控制cwnd的大小就会加1

有一个叫慢启动门限 ssthresh （slow start threshold）状态变量。

• 当 cwnd < ssthresh 时，使用慢启动算法。

• 当 cwnd >= ssthresh 时，就会使用「拥塞避免算法」。

拥塞避免

一般来说 ssthresh 的大小是 65535 字节。

那么进入拥塞避免算法后，它的规则是：每当收到一个 ACK 时，cwnd 增加 1/cwnd。

我们可以发现，拥塞避免算法就是将原本慢启动算法的指数增长变成了线性增长，还是增长阶段，但是增长速度缓慢了一些。就这么一直增长着后，网络就会慢慢进入了拥塞的状况了，于是就会出现丢包现象，这时就需要对丢失的数据包进行重传。当触发了重传机制，也就进入了「拥塞发生算法」。

拥塞发生

当发生了「超时重传」，则就会使用拥塞发生算法。这个时候，ssthresh 和 cwnd 的值会发生变化：

• ssthresh 设为 cwnd/2，

• cwnd 重置为 1 （是恢复为 cwnd 初始化值，我这里假定 cwnd 初始化值 1）

当发生了「快速重传」，则就会使用拥塞发生算法。这个时候，ssthresh 和 cwnd 的值会发生变化：

• cwnd = cwnd/2 ，也就是设置为原来的一半;

• ssthresh = cwnd;

• 进入快速恢复算法

快速恢复

进入快速恢复算法如下：

• 拥塞窗口 cwnd = ssthresh + 3 （ 3 的意思是确认有 3 个数据包被收到了）；

• 重传丢失的数据包；

• 如果再收到重复的 ACK，那么 cwnd 增加 1；

• 如果收到新数据的 ACK 后，把 cwnd 设置为第一步中的 ssthresh 的值，原因是该 ACK 确认了新的数据，说明从 duplicated ACK 时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态；

ping的工作原理

什么是ping

ping 是应用层命令，ping应用的底层，用的是网络层的ICMP协议，ICMP是利用了IP协议进行消息的传输。。

Ping 是计算机网络中常用的诊断工具，用于测试网络连接和测量网络延迟。它通过发送 ICMP（Internet Control Message Protocol）回显请求报文，并接收对应的回显应答报文来实现。

Ping 的工作原理

1. 发送请求：

   • 客户端（发送方）向目标主机发送一个 ICMP 回显请求报文（Echo Request）。

   • ICMP 回显请求报文中包含一个随机的标识符和序列号，以及一些其他的控制字段。

2. 接收回应：

   • 目标主机（接收方）收到 ICMP 回显请求报文后，会返回一个 ICMP 回显应答报文（Echo Reply）。

   • 回应报文中包含与请求报文相同的标识符和序列号，以及其他的控制字段。

3. 计算往返时间（Round-Trip Time）：

   • 客户端收到 ICMP 回显应答报文后，会计算往返时间（RTT），即从发送请求到接收回应的时间差。

   • RTT 可以用来测量网络连接的延迟，即从客户端到目标主机的往返时间。

4. 重复发送和统计信息：

   • Ping 工具通常会重复发送一定数量的 ICMP 回显请求，并对每个请求的往返时间进行统计，如最小值、最大值和平均值等。

   • 这样可以更准确地评估网络的状况和性能。

需要注意的是，Ping 工具使用 ICMP 协议来进行测试，而 ICMP 报文并不属于传输层的 TCP 或 UDP 协议。因此，Ping 只能测试基于 IP 协议的网络连接，而不能测试特定端口或应用层协议的可用性。

另外，由于 ICMP 报文的优先级较低，有些网络设备或防火墙可能会限制或过滤 ICMP 报文，导致 Ping 不可用或不准确。因此，在使用 Ping 进行网络测试时，需要考虑网络环境和设备的限制。

断网了，能ping通127.0.0.1吗

当网络断开时，通常情况下是无法进行网络通信的，包括无法进行 Ping 测试。然而，在某些情况下，尽管网络连接断开，仍然可以通过本地回环地址（loopback address）127.0.0.1 进行 Ping 测试。

本地回环地址是网络协议栈中的一部分，专门用于在本地主机上进行测试和通信。它指向本地主机自身，通过回环接口（loopback interface）进行通信，而不经过物理网络接口。

因此，即使网络断开，本地主机仍然可以通过发送 ICMP 回显请求到 127.0.0.1，然后接收回显应答来进行 Ping 测试。这是因为 Ping 测试在本地主机上进行，不需要经过网络接口。

需要注意的是，尽管可以 Ping 通 127.0.0.1，但这并不意味着网络连接正常。Ping 通 127.0.0.1 只是表示本地主机的网络协议栈正常工作，而不涉及物理网络连接。如果无法 Ping 通其他 IP 地址，可能是由于物理网络连接故障、路由器配置问题或其他网络故障引起的。在这种情况下，需要进一步检查和排除网络故障。

127.0.0.1、localhost和0.0.0.0的区别

127.0.0.1、localhost 和 0.0.0.0 都是与本地主机相关的 IP 地址，它们有一些区别和不同的使用场景。

1. 127.0.0.1：

   • 127.0.0.1 是本地回环地址（loopback address），指向本地主机自身。它是 IPv4 的回环地址之一。

   • 当你在本地主机上访问 127.0.0.1 时，实际上是通过回环接口在本地主机内部进行通信，而不经过物理网络接口。

   • 它常被用于测试和调试本地网络服务或应用程序，例如通过访问本地的 Web 服务器进行测试。

   • 127.0.0.1 是一个固定的地址，对应于本地主机的回环接口。

2. localhost：

   • localhost 是一个主机名，在大多数系统中都映射到 127.0.0.1，用于表示本地主机。

   • 当你在本地主机上使用 localhost 访问时，实际上是在访问 127.0.0.1。

   • localhost 可以用于在本地主机上进行网络测试和通信。

3. 0.0.0.0：

   • 0.0.0.0 是一个特殊的 IP 地址，通常用作通配符地址（wildcard address）或未指定地址（unspecified address）。

   • 当一个服务监听在 0.0.0.0 上时，表示该服务会监听在所有可用的网络接口上，即同时监听本地主机的所有 IP 地址。

   • 0.0.0.0 通常用于服务器配置中，表示该服务会接受来自任何网络接口的连接。

总结来说：

• 127.0.0.1 是本地主机的回环地址，用于本地主机内部的测试和通信。

• localhost 是一个主机名，通常映射到 127.0.0.1，用于表示本地主机。

• 0.0.0.0 是一个特殊的 IP 地址，用作通配符地址，表示服务会监听所有可用的网络接口。