tcp和udp协议的特点？

TCP和UDP都是网络通信协议，但它们有不同的特点。

TCP（Transmission Control Protocol）是一种面向连接的协议，提供可靠的数据传输服务。TCP在通信之前需要建立连接，进行错误检测和纠正，并且保证数据的顺序性。TCP还提供流控制和拥塞控制功能，可以调整数据发送速率，防止网络拥塞。

UDP（User Datagram Protocol）是一种无连接的协议，提供不可靠的数据传输服务。UDP不需要建立连接，没有错误检测和纠正功能，并且不能保证数据的顺序性。UDP适用于一些实时应用，如视频和音频传输，因为它能够快速地传输数据，但对数据的准确性没有太高要求。

总之，TCP提供可靠的数据传输服务，适用于对数据准确性要求较高的应用，而UDP则提供快速的数据传输服务，适用于对数据准确性要求不高的实时应用。

tcp三次握手改成二次握手行不行？

TCP三次握手是为了确保客户端和服务器之间建立了可靠的连接，如果把三次握手改成两次握手，可能会导致一些问题。

在TCP三次握手中，第一次握手是客户端向服务器发送SYN报文，第二次握手是服务器收到SYN报文后发送ACK报文作为应答，同时也向客户端发送SYN报文，第三次握手是客户端收到服务器的SYN报文后发送ACK报文作为应答。这样可以确保客户端和服务器之间建立起了可靠的连接，并且双方都知道对方已经准备好了数据传输。

如果将TCP三次握手改为两次握手，例如只有客户端向服务器发送SYN报文并等待服务器回复ACK报文，这样可能会导致一些问题。比如说，如果客户端发送了SYN报文但没有收到ACK报文，此时客户端不知道是否连接成功，因此无法进行数据传输。另外，如果服务器在接收到SYN报文后很长时间才发送ACK报文，客户端也无法确定是否连接成功，这会导致连接的不确定性。

因此，为了确保TCP连接的可靠性，三次握手是必要的，将三次握手改为两次握手是不可取的。

tcp保证数据安全可靠传输的机制有哪些？（需要解释每种机制）

TCP提供了多种机制来保证数据的安全可靠传输，主要包括以下几种：

序号和确认机制：TCP通过为每个数据包分配一个序号，可以确保数据的顺序性。同时，TCP还使用确认机制来检测丢失的数据包，并重新发送这些数据包，以确保数据的完整性和可靠性。

流量控制机制：TCP使用流量控制机制来限制发送方发送数据的速率，以防止接收方无法处理过多的数据导致数据的丢失或延迟。TCP使用滑动窗口机制来实现流量控制。

拥塞控制机制：TCP使用拥塞控制机制来避免网络拥塞，以确保数据传输的可靠性。当网络出现拥塞时，TCP会降低发送的速率，减少数据包的丢失和重传，以避免进一步加剧网络拥塞。

超时重传机制：当数据包在传输过程中丢失或损坏时，TCP会进行超时重传，即重新发送该数据包，以确保数据的可靠传输。

校验和机制：TCP使用校验和机制来检测数据包是否正确到达目标地址，以避免由于传输错误导致的数据损坏或丢失。

总之，TCP通过序号和确认机制、流量控制机制、拥塞控制机制、超时重传机制和校验和机制等多种机制来保证数据的安全可靠传输。这也是TCP被广泛应用于互联网和其他计算机网络中的主要原因之一。

TCP断开连接时为什么是4次挥手？三次挥手行不行？

TCP断开连接的时候需要进行4次挥手，而不是3次挥手。这是因为在TCP连接中，客户端和服务器都可能在同一时间向对方发送数据。

四次挥手步骤如下：

客户端发送一个FIN报文给服务器，表示客户端不再发送数据，但可以接收数据。
服务器收到客户端发送的FIN报文后，发送ACK报文作为响应，表示已经收到了客户端的请求，并准备关闭连接。
当服务器准备好关闭连接时，发送一个FIN报文给客户端，表示服务器不再发送数据。
客户端收到服务器发送的FIN报文后，发送ACK报文作为响应，确认收到服务器要求关闭连接的请求。

通过四次挥手过程，客户端和服务器都可以确认对方已经关闭了连接，并且不会再发送任何数据。如果只使用三次挥手，则无法保证客户端和服务器同时关闭连接，其中一方可能会继续发送数据，导致数据包丢失。

例如，当客户端发送最后一个ACK报文时，该报文可能会在网络中被延迟或丢失，从而导致服务器认为连接已关闭，但实际上客户端仍然在发送数据。如果使用四次挥手，客户端可以等待一段时间以确保服务器已经关闭连接，否则客户端会重新发送ACK报文，从而避免了这种问题。

因此，TCP断开连接时需要使用4次挥手，以确保客户端和服务器都已经关闭了连接并不再发送数据。

为什么主动断开的一方要经历TIME_WAIT状态？

在 TCP 的四次挥手过程中，最后一次挥手是由被动关闭连接的一方发起的，也就是服务器。当服务器发送了最后一个 ACK 报文后，它并不会立即关闭连接，而是进入 TIME_WAIT 状态，并等待一段时间（通常为 2MSL，即两倍的最长报文分组寿命）。

这个等待时间主要是为了处理网络上可能存在的延迟报文或者失序报文。因为在网络传输过程中，数据包可能会因为网络拥堵、链路故障等原因被延迟或乱序到达。如果服务器没有等待一段时间就立即关闭连接，那么可能导致之前发送的数据包在网络中丢失或被重发，从而与后续建立的新连接混淆。

在 TIME_WAIT 状态下，服务器可以确保所有之前发送的数据都已经被对端正确地接收，并且对端已经确认了连接的关闭。如果服务器在这个状态下收到了异常的报文（比如之前发送的 FIN/ACK 报文丢失），则它依然可以重新发送并与对端进行重传，以确保数据的可靠性。

因此，主动断开连接的一方需要等待 TIME_WAIT 状态，以确保之前发送的所有数据都已经被对端确认并且连接已经完全关闭，同时避免和后续的连接冲突。

什么是MSS、MTU

MSS 和 MTU 都是网络传输中的参数，用于控制数据包的大小和传输效率。它们分别代表最大报文段长度（Maximum Segment Size）和最大传输单元（Maximum Transmission Unit）。

MTU 是指在一个网络中最大的数据包大小限制，由通信双方协商后确定。它通常包括数据包头部、数据以及尾部校验和等信息的总和。在 IP 网络中，MTU 的默认值为 1500 字节，但在不同的网络类型或设备上可能会有所不同。

MSS 则是 TCP 协议中的一个参数，指的是在一个 TCP 报文段中 TCP 数据字段的最大长度。该值是通过 TCP 握手时，双方协商得出的。因为 TCP 协议需要将一个大的数据流切割成多个小的报文段进行传输，而 MSS 参数则会影响到每个报文段的大小。

在实际传输过程中，如果要发送的数据包比 MTU 大，那么就需要对数据包进行分片，将数据分解成一系列更小的数据包进行传输。同时，如果 MSS 值设置过大，那么每个 TCP 报文段的数据量就会增加，从而导致每次传输的时间延长，网络效率下降。

因此，在实际应用中，需要根据当前的网络环境和需求来合理地设置 MTU 和 MSS 参数，以保证网络传输的效率和可靠性。

TCP协议与UDP协议在编程当中如何选择？

在编程中选择使用 TCP 还是 UDP 协议取决于具体的应用场景和需求。下面列举一些参考因素：

可靠性要求：TCP 是一种可靠的传输协议，可以保证数据的有序、完整、不重复以及传输的正确性，而 UDP 则是无连接、不可靠的传输协议，数据可能会出现丢失、重复或者乱序等问题。

传输效率：TCP 在保证可靠性的基础上，需要进行拥塞控制和流量控制等机制，以确保网络的稳定和公平，从而带来一定的传输延迟和额外的开销。而 UDP 则没有这些机制，因此可以更快地传输数据，但也更容易受到网络状况的影响。

数据量大小：TCP 适合传输大量数据，因为它能够将数据流分割成多个报文段进行传输，并保证数据的完整性和顺序。而 UDP 则适合传输小量数据或者实时数据，例如音视频流等。

通信模式：TCP 是面向连接的协议，需要先建立连接再进行数据传输，适合点对点的通信和长连接方式。而 UDP 则是无连接的协议，可以支持广播、多播和任意连接数等多种通信模式。

综上所述，TCP 适合于需要可靠数据传输和长连接的应用场景，例如文件传输、网页浏览等；而 UDP 则适合于需要高效传输和实时性要求高的应用场景，例如音视频通话、实时游戏等。在编程中应根据具体需求选择合适的协议，并对网络环境进行充分测试和优化，以保证网络传输的性能和稳定性。

什么是套接口？

套接口（Socket）是在应用层和传输层之间的一个抽象层，它为应用程序提供了一组标准的API，使得应用程序能够使用网络传输协议进行通信。套接口可以看作是一个端点，用于标识不同主机上的进程与网络之间的连接。

在 TCP/IP 协议栈中，套接字通常由 IP 地址、端口号和通信协议三个部分组成。其中 IP 地址和端口号用于标识网络中的具体进程，而通信协议则指定了数据传输的方式，例如 TCP 或 UDP 等。

通过套接口，应用程序可以实现如下功能：

建立连接：应用程序可以使用套接口来建立连接并发送数据到其他主机上的进程。

监听端口：应用程序可以使用套接口来监听某个特定端口上的连接请求，并对这些请求进行响应。

发送和接收数据：应用程序可以使用套接口向远程主机发送数据，并接收来自远程主机的数据。

关闭连接：应用程序可以使用套接口来关闭网络连接，释放资源。

套接口是网络编程中重要的概念，通常以类似文件操作的方式进行调用和处理。在不同的平台和编程语言中，套接口的具体实现可能有所不同，但其核心概念和使用方法基本相同。

tcp协议通信服务端的流程？

TCP 协议通信服务端的流程主要包括以下几个步骤：

创建套接字：服务端首先需要创建一个监听套接字，该套接字用于监听特定的端口号，等待客户端发起连接请求。
绑定端口号：服务端需要将监听套接字与特定的端口号进行绑定，并指定在该端口上监听来自客户端的连接请求。
监听连接请求：服务端通过调用 listen() 方法开始监听连接请求。在此期间，服务端会处于阻塞状态，等待客户端的连接请求到来。
接受连接请求：当有客户端连接请求到达监听套接字时，服务端使用 accept() 方法接受该连接请求，并返回一个新的套接字，用于与客户端进行数据交换。
数据交换：服务端可以使用新的套接字向客户端发送数据，也可以从该套接字接收来自客户端的数据。在此期间，服务端可以根据应用程序需求对数据进行处理和解析。
关闭连接：当服务端不再需要响应客户端的请求时，可以通过调用 close() 方法关闭套接字，释放资源。

总体而言，TCP 服务端的流程是先创建并绑定监听套接字，然后进入阻塞模式等待客户端请求，一旦有新的客户端请求到来，就接受连接并创建新的套接字进行数据交换，最后在不需要响应客户端请求时关闭套接字。

tcp建立三次握手时，内核做了哪些事情？

TCP 建立连接的三次握手过程主要涉及到客户端和服务端之间的消息交互，而操作系统内核也扮演了重要的角色。下面是 TCP 建立连接时，内核做的几个主要事情：

客户端发送 SYN 报文：当客户端需要与服务端建立连接时，它会发送一个包含 SYN 标志位的 TCP 报文段，同时将初始序列号设为一个随机数。
服务端接收 SYN 报文并发送 ACK 报文：服务端收到客户端的 SYN 报文后，会将该请求放入等待队列中，并返回一个带有 SYN 和 ACK 标志位的报文段，其中 SYN 表示服务端同意建立连接，ACK 则表示服务端已经收到了客户端的 SYN 请求，并将初始序列号设为另一个随机数。
客户端接收 ACK 报文：客户端收到服务端发来的 SYN/ACK 报文后，会将其放入等待队列中，在该报文段的基础上再发送一个带有 ACK 标志位的报文段，确认服务端已经正确地收到了客户端的 SYN 请求，并将初始序列号加 1。
服务端接收 ACK 报文：服务端收到客户端发来的 ACK 报文后，就完成了三次握手的过程，可以将该连接从等待队列中移除，并开始正常的数据传输。

在三次握手过程中，操作系统内核主要完成了以下几个主要任务：进行队列管理、处理报文段、控制定时器等。具体来说，内核需要将客户端发来的 SYN 请求放入到服务端的等待队列中，确保客户端与服务端之间的序列号和确认号正确无误，并根据当前的拥塞情况和网络状况控制定时器的时间，以及对异常情况的处理等等。

recv返回0代表啥？

在网络编程中，recv() 函数用于从已连接的套接字上接收数据。当 recv() 函数返回 0 时，表示对端已经关闭了连接，此时应用程序可以认为当前连接已经结束，并且需要进行清理和资源释放操作。

一般情况下，recv() 函数返回值的含义如下：

如果返回值大于 0，则表示成功接收到了指定长度的数据，并将数据存储在了指定的缓冲区中。此时应用程序可以继续调用 recv() 函数以接收更多的数据。

如果返回值等于 0，则表示对端已经关闭了连接，此时应用程序需要认为当前连接已经结束，并进行相应的清理和资源释放操作。

如果返回值小于 0，则表示出现了错误，该错误代码通常可以通过 errno 变量获取。此时应用程序需要根据具体的错误码进行相应的处理和恢复。

在使用 recv() 函数接收数据时，应用程序需要注意对返回值进行及时检查，并根据不同的返回值进行相应的处理。特别是当返回值为 0 时，应用程序需要立即结束当前连接，并释放相关资源，以避免造成不必要的后果。

select 效率低的原因

select() 函数是一种基于轮询的 I/O 多路复用技术，它可以同时监视多个文件描述符，并在其中有数据可读或可写时进行响应。但是，由于 select() 函数的效率较低，主要原因如下：

运行效率低：select() 函数需要轮询需要监视的文件描述符列表，并且需要不断地遍历整个列表，这样会导致 CPU 占用率较高，而且随着监视的文件数量增加，性能逐渐下降。
句柄数量受限：在 Windows 系统中，socket 句柄数量是有限制的，默认情况下每个进程最多可以打开 1024 个 socket 连接。而 select() 函数本身存在句柄数限制，不能处理超过 FD_SETSIZE 个 socket 连接的情况，这限制了该函数处理大规模并发连接的能力。
数据拷贝复制：当一个文件描述符就绪时，内核需要将数据从内核缓冲区拷贝到用户缓冲区，然后再将数据从用户缓冲区拷贝到目标位置，这样会导致数据拷贝次数较多，降低了效率。

为了解决上述问题，现代操作系统和网络编程框架通常采取了更加高效的 I/O 多路复用技术，例如 epoll、kqueue 等。这些技术可以通过事件通知机制实现零拷贝、内核空间和用户空间的数据共享，以及更加高效的事件处理方式。

epoll对select的提升

epoll 是一种高效的 I/O 多路复用机制，相对于传统的 select() 和 poll() 等函数，它具有以下三个主要的优势：

提高了效率：epoll 可以处理大规模并发连接，它能够有效地避免遍历整个文件描述符列表的操作，并且使用事件驱动机制，只有当文件描述符发生变化（例如有数据可读、可写或出现错误等）时才会通知应用程序，从而减少了无用的 CPU 占用。
支持更多文件描述符：epoll 的设计理念是“事件驱动”，不像 select() 和 poll() 函数那样受到文件描述符数量限制，可以支持上万甚至百万级别的并发连接。
零拷贝特性：在 epoll 模型中，内核和用户空间之间可以共享同一份数据缓存区，避免了重复的数据拷贝操作，从而提高了数据传输的效率。

总体来说，相对于 select() 函数，epoll 具有更高的效率、更强的扩展性和更好的可维护性，使得网络编程更加高效、灵活和稳定。因此，在高并发的网络编程场景中，epoll 已经成为了首选的解决方案之一。

调用epoll的三个函数分别是干嘛的？

在使用 epoll 实现高效的 I/O 多路复用时，需要调用以下三个函数：

epoll_create()：创建一个 epoll 对象，并返回一个代表该对象的文件描述符。该函数的原型为 int epoll_create(int size)，其中 size 参数表示注册的文件描述符数量的建议值，该值仅作为一个提示，实际上内核会根据实际情况对其进行自动调整。
epoll_ctl()：向 epoll 对象中添加、修改或删除文件描述符，并设置相应的事件类型和回调函数。该函数的原型为 int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)，其中 epfd 表示 epoll 对象的文件描述符，op 表示操作类型（EPOLL_CTL_ADD，EPOLL_CTL_MOD 或 EPOLL_CTL_DEL），fd 表示要添加、修改或删除的文件描述符，event 表示要添加、修改或删除的事件信息结构体。
epoll_wait()：等待 epoll 中任意一个已注册的文件描述符就绪，并返回就绪的文件描述符列表。该函数的原型为 int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout)，其中 epfd 表示 epoll 对象的文件描述符，events 表示事件信息结构体数组的指针，maxevents 表示 events 数组的大小，timeout 表示超时时间。当有文件描述符就绪时，epoll_wait() 函数将把就绪的文件描述符信息填充到 events 数组中，并返回就绪的文件描述符数量。

这三个函数分别用于创建 epoll 对象、添加、修改或删除文件描述符以及等待事件的触发。通过调用这些函数，我们可以轻松实现高效的 I/O 多路复用，并提高网络编程的性能和稳定性。

什么是epoll的边沿触发？什么是水平触发？用边沿触发，优势在哪？

epoll 是一种高效的 I/O 多路复用机制，在使用时可以选择边沿触发（Edge-Triggered）和水平触发（Level-Triggered）两种模式。

在边沿触发模式下，当文件描述符上有数据可读或可写时，epoll_wait() 函数仅通知一次，即只有在状态发生变化时才会触发事件，而不是像水平触发那样持续通知。例如，若一个 socket 缓冲区中已有 100 字节数据，应用程序在非阻塞模式下调用 recv() 函数每次只能接收到一部分数据，并且需要反复调用才能将所有数据都读取完毕。如果使用边沿触发模式，则只会在缓冲区有新数据到来时才触发一次事件通知，从而避免了不必要的 CPU 浪费和重复操作，提高了事件处理的效率。

相比之下，水平触发模式在有数据到来时会持续通知，直到数据被全部读取，这样容易造成死循环、CPU 占用过高等问题。

总体来说，边沿触发模式更加高效，特别适合处理网络编程中的高并发连接场景，但它对事件处理的精度要求更高，需要开发人员根据具体情况进行适当的设计和优化。而水平触发模式则更加稳定，适合对数据读写的实时性要求不特别高的场景。

什么是SYN FLood攻击？如何防护？

SYN Flood 攻击是一种常见的 DoS（拒绝服务）攻击方式，也是最常见、最有效的攻击方式之一。它利用 TCP 协议中的三次握手来实现攻击，向目标主机发送大量伪造的 SYN 报文，然后不断等待对方回复 ACK 报文，从而耗尽目标主机的资源，导致其无法处理正常请求。

SYN Flood 攻击的主要特点包括：发送大量伪造的 SYN 报文；不进行第三次握手，即没有建立真正的连接；占用目标主机的系统资源，导致其无法响应正常请求。

为了防止 SYN Flood 攻击，可以采取以下几种措施：

过滤恶意流量：可以使用防火墙或入侵检测系统（IDS/IPS）等技术进行流量过滤和识别，对那些来源不明、异常频繁和重复的 SYN 报文进行拦截和过滤。
增加系统资源：可以调整系统参数，增加 TCP 连接数和内核缓存等资源，并将最大连接数设置得较高，以便更好地抵御 SYN Flood 攻击。
使用 SYN Cookie 技术：这是一种针对 SYN Flood 攻击的特殊技术，通过在客户端和服务器之间的交互中生成一个 cookie，以避免在连接建立前进行三次握手。当服务器收到 SYN 报文时，它会根据一定的算法计算出一个 cookie，发送给客户端。而客户端在发送 ACK 报文时需要将该 cookie 回传给服务器，从而完成连接的建立。

综上所述，SYN Flood 攻击是一种常见且危险的网络攻击方式，针对这种攻击可以采取多种技术手段进行预防和防御，以保护网络环境的安全和稳定。

什么是进程池？为什么要使用进程池？

进程池是一种通用的并发编程模型，它采用预先创建一定数量的子进程，并将它们放入一个池中（即进程池），当需要进行并发处理时，从进程池中获取一个子进程来执行任务。在任务完成后，该子进程会返回到进程池中等待下一次使用。

进程池可以避免由于频繁创建和销毁进程而导致的系统开销和性能损失，并且可以有效地控制并发连接的数量，提高应用程序的性能和稳定性。进程池通常具备以下几个特点：

预先创建固定数量的子进程：通常根据系统资源和应用程序需求来设置池中子进程的数量，以便更好地适应并发量的变化。

可复用的子进程：一个子进程可以多次使用，而不需要重复创建和销毁，减少了系统开销和性能消耗。

任务队列：进程池中通常会维护一个任务队列，当有新的任务到达时，进程池会从队列中获取一个空闲的子进程来执行任务。

动态管理：进程池可以根据实际情况自动调整子进程的数量，以适应并发量的变化。

进程池常用于构建高并发的网络应用程序中，例如 Web 服务器、消息队列等。它可以避免频繁地创建和销毁进程，从而减少了系统开销和性能损失，并且可以更好地控制并发连接的数量，提高程序的并发处理能力和稳定性。

第十章 单调栈