C/C++面试（九）_send c++-CSDN博客

本文链接：https://blog.csdn.net/weixin_44920770/article/details/132678346

本文讨论了在编程中遇到的发送数据不全问题及其原因，介绍了TCP的粘包现象、TCP和UDP的区别，以及TCP连接的三次握手、四次挥手过程及超时机制，特别强调了TIME_WAIT状态的作用。

摘要由CSDN通过智能技术生成

1、调用send函数发送数据不全怎么办？

调用send函数发送数据不全的原因可能有多种，以下是一些可能的原因：

发送缓冲区不足：套接字的发送缓冲区大小有限，如果要发送的数据量超过了发送缓冲区的大小，send函数可能无法一次性发送全部数据，导致数据不全。
网络拥塞：在网络拥塞的情况下，数据包可能会被延迟或丢失，从而导致部分数据无法完全发送到目标。
连接中断：如果在发送数据的过程中连接意外中断，send函数可能无法将所有数据成功发送。
数据错误或格式问题：如果发送的数据包含错误或不符合协议规范，接收端可能拒绝接受或处理数据，导致发送不全。

当调用send函数发送数据不全时，通常需要采取以下步骤来处理：

检查发送缓冲区大小：首先，确保发送缓冲区足够大以容纳要发送的数据。如果发送缓冲区太小，可能会导致数据截断或丢失。你可以通过操作系统提供的相关函数或设置套接字选项来调整发送缓冲区大小。
使用循环发送：如果要发送的数据量较大，可以使用循环发送的方式。这意味着多次调用send函数，每次发送一部分数据，直到所有数据都被发送完毕。要注意在每次发送时更新发送数据的指针和剩余数据量。
检查send返回值：send函数通常会返回已成功发送的字节数。你可以检查send的返回值是否小于要发送的数据长度，以确定发送是否不完整。如果发送不完整，你可以根据返回值来调整发送数据的指针和剩余数据量。
错误处理：在send函数返回-1时，检查errno变量以获取具体的错误代码，并根据错误代码采取适当的处理措施。不同的错误代码表示不同的发送问题，例如连接中断、套接字关闭等。

2、什么是 TCP 的"粘包"问题？怎么解决？

TCP/IP协议簇为Internet中的通信协议建立了概念模型，簇中的两个主要协议是TCP和IP。TCP/IP协议簇中的TCP保证了数据段的可靠性和有序性，并且有了可靠的传输层协议，应用层协议可以直接使用TCP来传输数据，而不需要关心数据段的丢失和重复

IP协议解决了数据包的路由和传输，上层TCP协议不再关心路由和寻址。那么TCP协议解决了传输的可靠性和顺序性问题，上层不需要关心数据能否传输到目标进程，只要将数据写入TCP协议的缓冲区，协议栈几乎就可以始终保证数据的传递。

当应用层协议使用TCP协议传输数据时，TCP协议可能会将应用层发送的数据拆分成多个数据包依次发送，数据的接收方收到的数据段可能由多个“应用层”组成。因此当应用层从TCP缓冲区读取数据时发现粘包时，需要对接收到的数据进行拆分。

粘包并不是TCP协议造成的，而是应用层协议设计者对TCP协议的误解，忽视了TCP协议的定义，缺乏应用层协议设计经验。

TCP协议中粘包可能出现的原因包括：

TCP协议是面向字节流的协议，可以对应用层协议的数据进行组合或拆分。
应用层协议没有定义消息的边界，导致数据的接收者无法拼接数据。

于 TCP 协议是基于字节流的，这意味着应用层协议必须绘制自己的消息边界。

如果我们能够在应用层协议中定义消息的边界，那么无论TCP协议如何拆分和重组应用层协议的报文过程，接收方都可以按照协议的规则恢复出相应的消息。应用层协议中最常见的两种解决方案是基于长度或基于终止符（Delimiter）。

基于长度的实现有两种方式，一种是使用固定长度，所有应用层消息都使用统一的大小，另一种是使用可变长度，但需要一个指示负载长度的字段添加到应用层协议的协议头中，以便接收者能够从字节流中分离出不同的消息，HTTP协议的消息边界是基于长度来实现的。

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 138
...
Connection: close

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <p>Hello World, this is a very simple HTML document.</p>
  </body>
</html>

在上面的HTTP报文中，我们使用Content-Length报文头来表示HTTP报文的负载大小，一旦应用层协议解析了足够的字节，就可以从报文中分离出完整的HTTP报文，并且我们可以按照这个规则完成对HTTP报文的重组。 HTTP 消息，无论发送者如何处理相应的数据包

当HTTP使用Chunked Transfer机制时，HTTP头不再包含Content-Length，它使用负载大小为0的HTTP消息作为终止符来指示消息边界。例如，当使用TCP协议发送JSON数据时，接收方可以根据接收到的数据是否能够解析为合法的JSON来判断消息是否终止。

详细链接🔗：Why TCP protocol has sticky packet problem - SoByte

3、tcp和udp的区别？

TCP创建了一条安全的通信线路，以确保所有数据的可靠传输。发送消息后，将验证收据以确保所有数据均已传输。

UDP发送数据时不建立连接。它发送数据而不确认接收或检查错误。这意味着部分或全部数据可能在传输过程中丢失。

连接性：
- TCP是一种面向连接的协议，建立连接后可进行可靠的双向通信。它提供了错误检测、流控制和重传等机制，确保数据的可靠性。
- UDP是一种无连接的协议，每个UDP数据包都是独立的，没有建立连接的过程。UDP不提供可靠性保证，数据包可能会丢失或乱序。
可靠性：
- TCP保证数据的可靠性，如果数据包丢失或损坏，TCP会进行重传，直到数据正确被接收。
- UDP不提供可靠性保证，数据包的传输和接收没有确认机制。
延迟和效率：
- TCP的可靠性和流控制机制可能引入一些延迟，特别是在高负载情况下。因此，TCP通常比UDP更适合对延迟要求较高的应用。
- UDP的无连接性和简单性使其具有较低的开销，适用于对实时性要求高、可以容忍少量丢失数据的应用，如视频流和音频传输。
数据包顺序：
- TCP保证数据包按顺序交付，即使它们以不同的顺序到达，TCP会对它们进行重新排序。
- UDP不保证数据包的顺序，数据包可能以不同的顺序到达。
用途：
- TCP常用于需要可靠数据传输的应用，如Web浏览、电子邮件、文件传输等。
- UDP常用于实时性要求高、可以容忍数据丢失的应用，如语音通信、视频流、在线游戏等。
连接数量：
- TCP通常支持较少的并发连接，因为每个TCP连接都需要维护连接状态信息。
- UDP支持更多的并发连接，因为它是无连接的。

因素	传输控制协议	UDP协议
连接类型	传输数据之前需要建立连接	无需连接即可开始和结束数据传输
数据顺序	可以对数据进行排序（按特定顺序发送）	无法对数据进行排序或排列
数据重传	如果数据包未能到达，可以重传数据	没有数据重传。丢失的数据无法找回
传输	传输有保证	部分或全部数据可能在传输过程中丢失
检查是否有错误	彻底的错误检查保证数据到达其预期状态	最小错误检查涵盖了基础知识，但可能无法防止所有错误
广播	不支持	支持的
速度	缓慢但完整的数据传输	速度快，但存在数据交付不完整的风险

4、tcp三次握手建立连接的过程？

TCP 的工作原理如下：

第一次握手（SYN）：
- 客户端向服务器端发送一个带有SYN（同步）标志位的TCP数据包，表明客户端希望建立连接。
- 此时客户端处于 SYN_SENT 状态，等待服务器的确认。
第二次握手（SYN + ACK）：
- 服务器端收到客户端的SYN数据包后，会回复一个带有SYN和ACK（确认）标志位的数据包。
- 此时服务器端处于 SYN_RCVD 状态，表示服务器已经收到了客户端的请求，并愿意建立连接。
第三次握手（ACK）：
- 客户端收到服务器端的SYN + ACK数据包后，会发送一个带有ACK标志位的数据包给服务器端。
- 此时客户端和服务器端都进入 ESTABLISHED 状态，表示连接已经建立，双方可以开始进行数据传输。

5、tcp四次挥手的过程。

TCP的四次挥手（Four-Way Handshake）是终止TCP连接的过程，它确保通信双方都能够正确地关闭连接。下面是TCP四次挥手的过程和各自的状态：

假设通信双方仍然是客户端（Client）和服务器端（Server）。

第一次挥手（FIN）：
- 客户端向服务器端发送一个带有FIN（结束）标志位的TCP数据包，表明客户端希望关闭连接。
- 此时客户端处于 FIN_WAIT_1 状态，等待服务器的确认。
第二次挥手（ACK）：
- 服务器端收到客户端的FIN数据包后，会回复一个带有ACK标志位的数据包，表示收到了客户端的关闭请求。
- 此时服务器端处于 CLOSE_WAIT 状态，表示服务器已经准备好关闭连接，但客户端仍然可以向服务器端发送数据。
第三次挥手（FIN）：
- 当服务器端准备好关闭连接时，服务器端向客户端发送一个带有FIN标志位的数据包，表示服务器端也希望关闭连接。
- 此时服务器端进入 LAST_ACK 状态，等待客户端的确认。
第四次挥手（ACK）：
- 客户端收到服务器端的FIN数据包后，会回复一个带有ACK标志位的数据包，表示收到了服务器端的关闭请求。
- 此时客户端进入 TIME_WAIT 状态，等待一段时间（2倍的最大报文段寿命，以确保服务器端已经收到ACK并完成关闭），然后关闭连接。
- 服务器端在收到ACK后关闭连接，进入 CLOSED 状态。

6、TCP的超时机制

TCP的超时机制是为了处理网络中可能发生的各种异常情况，确保数据的可靠传输。超时机制涉及到以下几个重要的概念和过程：

重传（Retransmission）：当发送方发送一个TCP数据包后，会启动一个定时器（称为重传定时器）。如果在定时器超时之前未收到对应的确认（ACK）数据包，发送方会认为数据包丢失，然后重传该数据包。
超时时间（Timeout）：超时时间是指发送方等待接收确认的最大时间间隔。超时时间的选择在TCP中非常重要，它需要权衡网络的延迟和可靠性。如果超时时间设置得太短，可能会导致不必要的重传，降低网络效率；如果设置得太长，可能会导致数据包传输延迟。
指数退避（Exponential Backoff）：为了避免在网络拥塞时大量的重传导致更严重的拥塞，TCP使用指数退避策略。当发生超时重传时，会将超时时间翻倍，然后再次启动重传定时器。
快速重传（Fast Retransmit）：除了依靠定时器来重传数据包外，TCP还采用了快速重传策略。当发送方连续收到相同序号的确认时，可以快速重传还未收到确认的数据包，而不必等到定时器超时。
选择性重传（Selective Repeat）：TCP还引入了选择性重传机制，允许发送方只重传丢失的数据包，而不是将整个窗口内的数据全部重传。

7、为什么TIME_WAIT状态需要经过2MSL才能返回到CLOSE状态

TIME_WAIT状态需要经过2倍的Maximum Segment Lifetime (MSL) 时间才能返回到CLOSE状态，这是为了确保在网络中所有可能存在的延迟、重复数据包和失序数据包都能够被正确处理，以保证通信的可靠性和完整性。以下是一些原因和解释：

确保数据包能够达到目的地：在网络中，数据包的传输是不确定的，可能会因为各种原因而出现延迟，丢失或者重复。TIME_WAIT状态的持续时间允许任何滞留在网络中的数据包能够到达目的地，确保了通信的完整性。
保证后续连接不会被误认为是旧连接：TCP连接是通过四元组（源IP、源端口、目标IP、目标端口）来唯一标识的。在TIME_WAIT状态下，保持连接的时间等于2倍的MSL，确保了后续的连接不会被误认为是之前的连接。这防止了新的连接因为与旧连接的标识信息相同而出现问题。
处理失序数据包：TIME_WAIT状态可以确保失序的数据包最终能够按顺序被正确处理。如果两个连接之间的数据包在网络中失序，那么在TIME_WAIT状态期间，重复的数据包将会被丢弃，而失序的数据包会被重新排序，以保证数据的正确性。
处理迷途的数据包：有时候，旧的数据包可能在网络中滞留，并在之后的连接中被错误地接收。TIME_WAIT状态的持续时间允许这些迷途的数据包在之后的连接中被正确地丢弃，而不会引发混淆。