TCP常见的一些面试题目小结

三次握手发生在哪些函数里面？

三次握手（Three-way handshake）是在TCP协议中用于建立可靠的连接的过程。它涉及到两个端点（通常是客户端和服务器）之间的通信。在TCP协议栈中，三次握手通常发生在操作系统的网络协议栈中的传输层，具体发生在以下函数或过程中：

1. 服务器端的监听函数：服务器通过监听特定的端口来等待客户端的连接请求。在这个监听函数中，服务器将等待客户端的连接请求，并准备建立新的连接。

2. 客户端的连接函数：客户端通过连接函数向服务器发送连接请求。在这个连接函数中，客户端会发送一个SYN（同步）包给服务器，以请求建立连接。

3. 服务器端的接收函数：服务器接收到客户端发送的SYN包后，会进行处理。在接收函数中，服务器会回复一个SYN-ACK（同步-确认）包给客户端，表示接收到了连接请求，并同意建立连接。

4. 客户端的确认函数：客户端接收到服务器发送的SYN-ACK包后，会进行处理。在确认函数中，客户端会发送一个ACK（确认）包给服务器，表示客户端接收到了服务器的回复。

通过以上的交互，完成了三次握手的过程，确保了客户端和服务器之间的连接的建立和可靠性。

三次握手对应的TCP状态？

tcp的6种标志位的分别代表：

SYN(synchronous建立联机)

ACK(acknowledgement 确认)

PSH(push传送)

FIN(finish结束)

RST(reset重置)

URG(urgent紧急)

Sequence number(顺序号码)

Acknowledge number(确认号码)

客户端TCP状态迁移：
CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
服务器TCP状态迁移：
CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED

各个状态的意义如下：
LISTEN - 侦听来自远方TCP端口的连接请求；
SYN-SENT -在发送连接请求后等待匹配的连接请求；
SYN-RECEIVED - 在收到和发送一个连接请求后等待对连接请求的确认；
ESTABLISHED- 代表一个打开的连接，数据可以传送给用户；
FIN-WAIT-1 - 等待远程TCP的连接中断请求，或先前的连接中断请求的确认；
FIN-WAIT-2 - 从远程TCP等待连接中断请求；
CLOSE-WAIT - 等待从本地用户发来的连接中断请求；
CLOSING -等待远程TCP对连接中断的确认；
LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认；
TIME-WAIT -等待足够的时间以确保远程TCP接收到连接中断请求的确认；
CLOSED - 没有任何连接状态；

listen()的backlog

`listen()`函数的`backlog`参数用于指定已完成连接队列的长度，表示等待被接受的连接的最大数量。

具体来说，当服务器调用`listen()`函数后，操作系统内核会创建一个已完成连接队列，用于存储已建立连接但尚未被服务器应用程序接受的连接请求。这些连接请求处于SYN-RECEIVED状态，等待服务器调用`accept()`函数来接受连接。

`backlog`参数指定了已完成连接队列的长度，也就是可以排队等待的最大连接数。如果已完成连接队列已满，新的连接请求将会被操作系统拒绝或忽略。

需要注意的是，`backlog`参数的实际表现可能因操作系统和系统配置而有所不同。较大的`backlog`值可以提供更大的连接请求排队容量，但也会占用更多的系统资源。根据应用程序的需求和系统负载情况，需要适当选择合适的`backlog`值。

值得注意的是，`backlog`参数只影响已完成连接队列的长度，不直接限制实际的并发连接数。实际的并发连接数还受限于系统资源、应用程序处理能力和网络条件。

全链接队列和半链接队列？

全连接队列（Fully Established Connection Queue）和半连接队列（Half-Open Connection Queue）是在TCP连接建立过程中使用的两个队列。

1. 全连接队列：
全连接队列用于存储已经完成三次握手并完全建立的连接。在服务器端，当服务器收到客户端的连接请求并成功完成三次握手后，这个连接会被放入全连接队列中。连接在全连接队列中等待服务器应用程序调用`accept()`函数来接受连接并进行数据交换。

2. 半连接队列：
半连接队列用于存储已经收到客户端的连接请求，并完成了三次握手中的前两个步骤（服务器收到SYN包并发送SYN-ACK包）。这些连接请求处于半开状态，等待服务器完成第三次握手的最后一步（接收到客户端的ACK包）。

当服务器收到客户端的连接请求时，会先将连接请求放入半连接队列中。在半连接队列中，服务器会继续等待客户端发送最后的ACK包来完成三次握手，或者在一定的超时时间内等待，超时后将连接请求从队列中移除。

半连接队列的存在是为了控制服务器的资源分配。它可以限制并发连接的数量，防止服务器被过多的连接请求拥塞。只有当服务器准备好处理连接并调用`accept()`函数时，连接请求才会从半连接队列中取出，进入全连接队列，并建立完整的连接。

需要注意的是，全连接队列和半连接队列的长度都是由操作系统和系统配置决定的，可以通过调整系统参数进行调整。适当设置队列长度可以平衡服务器资源和连接请求的处理。

close_wait,fin_wait_1,time_wait如何解决？

`CLOSE_WAIT`、`FIN_WAIT_1`和`TIME_WAIT`是TCP连接关闭过程中的不同状态，它们在连接关闭后的处理阶段中起到不同的作用。下面是对这些状态的解释以及如何解决它们的方法：

1. CLOSE_WAIT（关闭等待）：
   - `CLOSE_WAIT`状态发生在应用程序关闭连接之后，但仍然收到来自对方的数据包（通常是对方发送的最后一个数据包）。
   - 这个状态表示应用程序已经关闭了连接，但是还没有接收到对方的关闭请求。
   - 解决方法：确保应用程序正确关闭连接，及时调用`close()`函数，处理完所有的数据交换后关闭连接，避免长时间保持在`CLOSE_WAIT`状态。

2. FIN_WAIT_1（结束等待1）：
   - `FIN_WAIT_1`状态发生在本端发送了关闭请求（FIN包）后，等待对方发送确认（ACK）的状态。
   - 在这个状态下，本端仍可以接收对方发送的数据。
   - 解决方法：确保对方发送了确认（ACK），并且处理可能接收到的对方的数据。如果长时间停留在`FIN_WAIT_1`状态，可能是对方没有正确发送确认或关闭请求，可以考虑设置适当的超时时间，并采取适当的动作，如重传关闭请求或终止连接。

3. TIME_WAIT（时间等待）：
   - `TIME_WAIT`状态发生在本端发送了关闭请求（FIN包）并接收到对方的确认（ACK）后，等待足够的时间以确保对方接收到了最后的确认，并丢弃了可能滞留在网络中的重复数据。
   - 这个状态的持续时间通常为2倍的最大段生存期（MSL），MSL的典型值为2分钟。
   - 解决方法：无需直接解决，因为`TIME_WAIT`状态是为了网络中的稳定性和可靠性。尽管持续时间较长，但它确保了对方正确接收到了最后的确认，并清除了滞留在网络中的重复数据。如果频繁出现`TIME_WAIT`状态耗尽了系统资源，可以调整操作系统的参数来缩短`TIME_WAIT`时间。

总的来说，对于`CLOSE_WAIT`状态，确保应用程序正确关闭连接；对于`FIN_WAIT_1`状态，确保对方发送了确认并正确处理对方的数据；对于`TIME_WAIT`状态，无需直接解决，但可以调整系统参数来缩短持续时间。理解这些状态并采取适当的措施可以保证TCP连接的正常关闭和释放相关资源。

time_wait的持续时间？

在TCP连接的四次挥手过程中，当连接关闭后，主动关闭连接的一方会进入 `TIME_WAIT` 状态，并保持在该状态一段时间。`TIME_WAIT` 状态的持续时间通常是2倍的最大段生存期（Maximum Segment Lifetime，MSL）。

MSL 是指数据报在网络中最长的存活时间。根据 TCP 协议规范，MSL 的典型值是2分钟（120秒）。因此，`TIME_WAIT` 状态的持续时间通常为4分钟（2倍的 MSL），尽管具体实现可能会有所变化。

`TIME_WAIT` 状态的持续时间的目的是确保最后一个 ACK 包能够被对方正确接收。在 `TIME_WAIT` 状态期间，如果对方没有收到最后一个 ACK 包，它可以重传最后的 FIN 包，以确保对方能够正确关闭连接。

需要注意的是，`TIME_WAIT` 状态的持续时间可以通过操作系统的 TCP 参数进行调整。较短的 `TIME_WAIT` 时间可能会导致一些问题，如连接复用中的冲突或网络数据包的混乱。因此，在调整 `TIME_WAIT` 时间之前，应该仔细评估对系统和应用的影响。

TCP如何保证顺序？

TCP通过以下机制来保证数据的顺序传输：

1. 序列号和确认机制：TCP在发送端和接收端都使用序列号来对发送的数据进行编号。接收端会根据序列号对数据包进行排序，以确保按正确的顺序接收。接收端会发送确认（ACK）包，其中确认号字段指示期望接收的下一个字节的序列号，以便发送端得知数据已被正确接收。

2. 窗口管理：TCP使用滑动窗口机制来管理发送和接收的数据。接收端通过告知发送端可接收的窗口大小，即窗口字段中的数值，来控制发送端发送的数据量。发送端会根据窗口大小和接收端的确认情况来动态调整发送的数据量，确保在可接受窗口范围内进行传输。

3. 重传机制：如果发送端没有收到接收端的确认或接收端检测到数据包丢失，TCP会进行重传。重传会确保丢失的数据包能够被重新发送，并按正确的顺序被接收端接收。

这些机制结合起来确保了数据的有序传输。发送端按序列号发送数据，接收端按序列号对数据进行排序和处理，而窗口管理和重传机制确保了数据的可靠性和完整性。这使得TCP成为一种可靠的传输协议，适用于对数据顺序有严格要求的应用，如文件传输、网页浏览等。

send()返回正数，是否代表发送成功？为什么？

在TCP套接字编程中，`send()`函数返回一个正数代表发送成功，但不能仅凭返回值来确定是否真正成功发送了数据。返回的正数表示成功将数据传递给操作系统的发送缓冲区，但并不保证数据已经到达接收方。

`send()`函数将数据放入发送缓冲区后，操作系统会负责将数据从缓冲区发送到目标地址。然而，这个过程中可能发生网络延迟、拥塞或其他问题，导致数据未能及时到达接收方。

为了确保数据的可靠传输，TCP协议使用了序列号、确认机制和重传机制。接收方会发送确认（ACK）包，指示已经接收到的数据的范围，以便发送方知道哪些数据已经成功到达。如果发送方没有收到确认或接收方检测到数据包丢失，会进行重传以确保数据的可靠性。

因此，即使`send()`函数返回正数，仅表示数据成功发送到发送缓冲区，并不能保证数据已经被接收方接收到。要确保数据的可靠传输，应用程序需要结合确认机制和重传机制来处理发送和接收的数据。

TCP的三次握手过程？

TCP的三次握手过程用于建立一个可靠的连接。以下是TCP三次握手的步骤：

1. 第一步（SYN）：客户端向服务器发送一个同步（SYN）包。该包包含客户端初始化序列号（ISN）并设置SYN标志位。

2. 第二步（SYN-ACK）：服务器收到客户端的SYN包后，会发送一个带有确认（ACK）和同步（SYN）标志位的包作为回应。服务器也会选择自己的初始化序列号（ISN）并将其包含在ACK中。

3. 第三步（ACK）：客户端接收到服务器的SYN-ACK包后，会发送一个确认（ACK）包作为回应。该包确认服务器的ISN，并将序列号设置为服务器的ISN加1。

完成了以上三个步骤后，TCP连接就建立起来了，双方可以开始进行数据传输。三次握手过程的目的是确保双方都能够正常收发数据，同时进行序列号的初始化，以便在数据传输过程中进行包的顺序管理和丢失包的重传。

TCP的四次挥手过程？

TCP的四次挥手过程用于关闭一个已建立的连接。以下是TCP四次挥手的步骤：

1. 第一步（FIN）：当一个端点（通常是客户端）想要关闭连接时，它发送一个带有FIN标志位的包来表示它已经没有数据要发送了，即准备关闭连接。这个包被称为"FIN包"。

2. 第二步（ACK）：接收到FIN包的另一个端点（通常是服务器）会发送一个确认（ACK）包作为回应，表示已经收到了关闭请求。

3. 第三步（FIN）：当另一个端点（通常是服务器）也准备关闭连接时，它发送一个带有FIN标志位的包来表示它已经没有数据要发送了。

4. 第四步（ACK）：接收到第三步的FIN包的端点（通常是客户端）会发送一个确认（ACK）包作为回应，表示已经收到了关闭请求。

完成以上四个步骤后，TCP连接就彻底关闭了，双方都确认不再有数据传输。

这个四次挥手过程的目的是确保双方都完成了数据的传输并且都准备好关闭连接。在关闭连接的过程中，双方可以确保最后的数据包都被接收到，避免数据丢失。

为什么建立连接需要三次握手，而断开连接需要四次挥手？

TCP建立连接需要三次握手的原因是确保双方都能够确认彼此的收发能力正常，建立起可靠的通信环境。而断开连接需要四次挥手的原因是确保双方都能够完成数据传输并安全地关闭连接。

以下是建立连接需要三次握手的原因：

1. 确认双方的收发能力：第一次握手（SYN）时，客户端向服务器发送连接请求，服务器收到后确认自己能够收到客户端的数据。第二次握手（SYN-ACK）时，服务器向客户端发送确认，并发送自己的初始化序列号，确认服务器的收发能力。第三次握手（ACK）时，客户端向服务器发送确认，确认客户端的收发能力。通过这个过程，双方确认彼此的收发能力正常。

而断开连接需要四次挥手的原因如下：

1. 完成数据传输：在断开连接前，双方可能还有未传输完的数据包。第一次挥手（FIN）时，一方发送一个FIN包，表示自己没有数据要发送了。第二次挥手（ACK）时，另一方收到FIN包后发送一个确认，但仍然可以发送数据。通过这个过程，双方确认彼此的数据已经传输完毕。

2. 双方都准备好关闭连接：在第二次挥手后，发送确认的一方会进入半关闭状态，不再发送数据，但仍可以接收数据。这是因为双方可能在关闭连接前还有一些未完成的数据交换。第三次挥手（FIN）时，另一方发送一个FIN包，表示自己没有数据要发送了。第四次挥手（ACK）时，发送确认的一方发送一个确认，表示收到了对方的关闭请求，进入完全关闭状态。通过这个过程，双方都确认对方已经准备好关闭连接。

总结起来，建立连接需要三次握手是为了确认双方的收发能力正常，而断开连接需要四次挥手是为了确保数据传输完毕并双方都准备好关闭连接。这样可以保证数据的可靠传输和连接的正常关闭。

time_wait持续时间及原因？

在TCP连接关闭的四次挥手过程中，主动关闭连接的一方会进入TIME_WAIT状态，并保持在该状态一段时间。TIME_WAIT状态的持续时间通常是两倍的最大段生存期（Maximum Segment Lifetime，MSL）。

MSL是指数据报在网络中最长的存活时间。根据TCP协议规范，MSL的典型值是2分钟（120秒）。因此，TIME_WAIT状态的持续时间通常为4分钟（2倍的MSL），尽管具体实现可能会有所变化。

主要原因如下：

1. 可靠关闭连接：TIME_WAIT状态的持续时间确保最后一个ACK包能够被对方正确接收。在TIME_WAIT状态期间，如果对方没有收到最后一个ACK包，它可以重传最后的FIN包，以确保对方能够正确关闭连接。

2. 避免旧连接的数据干扰：TIME_WAIT状态的持续时间确保足够长的时间内，网络中所有的旧连接数据都能够消失。这样可以防止在新的连接中出现对旧连接的数据干扰。

3. 允许重复连接的建立：TIME_WAIT状态的持续时间使得相同的本地IP地址和端口号可以用于新的连接，而不会与之前的连接冲突。这是因为在TIME_WAIT状态期间，之前的连接已经彻底关闭，不再使用本地端口。

需要注意的是，TIME_WAIT状态的持续时间可以通过操作系统的TCP参数进行调整。较短的TIME_WAIT时间可能会导致一些问题，如连接复用中的冲突或网络数据包的混乱。因此，在调整TIME_WAIT时间之前，应该仔细评估对系统和应用的影响。

超时重传和快速重传？

超时重传（Timeout retransmission）和快速重传（Fast retransmission）是TCP协议中用于处理丢失数据包和拥塞情况的机制。

超时重传：
1. 当发送方发送一个数据包后，会启动一个定时器，等待对应的确认（ACK）。
2. 如果在定时器超时之前未收到确认，发送方会认为该数据包丢失，并重新发送该数据包。
3. 定时器的超时时间通常由往返时延（Round Trip Time，RTT）来确定，RTT是数据包从发送方到接收方并返回的时间。

快速重传：
1. 接收方在接收到乱序的数据包时，会发送一个重复的确认（Duplicate ACK），表示已经接收到了乱序数据包之前的数据。
2. 当发送方连续收到相同的重复确认时，它会认为某个数据包丢失，并尝试快速重传该数据包，而不等待定时器超时。
3. 发送方在收到一定数量的重复确认后，即可触发快速重传。

快速重传的目的是更快地恢复丢失的数据包，而不必等待定时器超时。通过快速重传，发送方可以更及时地重新发送丢失的数据包，从而提高传输效率和响应速度。

需要注意的是，超时重传和快速重传都是TCP协议用于处理丢失数据包的机制，但它们的触发条件和行为略有不同。超时重传依赖于定时器的超时，而快速重传则是基于接收方的重复确认。两种机制通常结合使用，以提供更可靠的数据传输和拥塞控制。

TCP首部长度，有哪些字段？

TCP首部长度为20字节（160位），包含以下字段：

1. 源端口（Source Port）：16位，指示发送端使用的源端口号。

2. 目标端口（Destination Port）：16位，指示接收端使用的目标端口号。

3. 序列号（Sequence Number）：32位，用于对发送的数据进行编号，用于有序传输和重组数据包。

4. 确认号（Acknowledgment Number）：32位，确认接收方期望收到的下一个字节的序列号，用于确认已接收的数据。

5. 数据偏移（Data Offset）：4位，指示TCP首部的长度，以4字节为单位。用于确定首部的结束位置和数据的开始位置。

6. 保留（Reserved）：6位，保留供将来使用，目前置为0。

7. 控制位（Flags）：6位，包括以下标志位：
   - URG（Urgent）：指示紧急指针字段是否有效。
   - ACK（Acknowledgment）：指示确认号字段是否有效。
   - PSH（Push）：表示接收方应立即将数据传送给应用程序，而不是等待缓冲区填充或缓冲区满。
   - RST（Reset）：用于复位连接。
   - SYN（Synchronize）：用于建立连接。
   - FIN（Finish）：用于关闭连接。

8. 窗口大小（Window Size）：16位，指示接收方当前可接收的字节数。

9. 校验和（Checksum）：16位，用于检测TCP首部和数据的传输错误。

10.紧急指针（Urgent Pointer）：16位，指示紧急数据的结束位置。

11.选项（Options）：可变长度，可包含一些可选字段，如最大段大小（MSS）、时间戳等。

12.填充（Padding）：用于使TCP首部长度为4字节的倍数，以确保对齐。

这些字段组成了TCP首部，提供了对TCP连接的控制和管理。

TCP在listen()时的参数backlog的意义？

在TCP的`listen()`函数中，`backlog`参数用于指定已完成连接队列的长度，表示等待被接受的连接的最大数量。它指示操作系统内核在应用程序尚未接受连接时可以排队等待的最大连接数。

当应用程序调用`listen()`函数后，操作系统内核会创建一个已完成连接队列，用于存储已建立连接但尚未被应用程序接受的连接请求。这些连接请求处于SYN-RECEIVED状态，等待应用程序调用`accept()`函数接受连接。

`backlog`参数的意义在于限制这个已完成连接队列的长度。如果队列已满，新的连接请求将会被操作系统拒绝或忽略。这个参数的作用是在高负载情况下，确保系统能够处理并接受适当数量的连接请求，以避免连接丢失或客户端无法连接的问题。

具体的含义和行为可能因操作系统和系统配置而有所不同，但通常来说，`backlog`参数是一个整数，其范围可能在数十到数百之间。较大的`backlog`值能够提供更大的连接请求排队容量，但也会占用更多的系统资源。应根据应用程序的需求和系统的负载情况来选择合适的`backlog`值。

需要注意的是，`backlog`参数仅影响已完成连接队列的长度，并不限制实际并发连接的数量。实际的并发连接数还受系统资源、应用程序处理能力以及网络条件的限制。

Accept发生的三次握手在哪一步？

在TCP连接的三次握手过程中，`accept()`函数并不直接参与。`accept()`函数在服务器端用于接受客户端的连接请求，并创建一个新的套接字来与客户端进行通信。它在三次握手已经完成、连接已经建立的阶段进行调用。

具体来说，在三次握手完成后，服务器会处于`LISTEN`状态，等待客户端的连接请求。当客户端发起连接请求，并完成三次握手后，服务器端的操作系统会将这个已建立的连接放入已完成连接队列中。然后，`accept()`函数被调用，从已完成连接队列中取出一个连接进行处理。

所以，可以说，在`accept()`函数调用之前，客户端和服务器之间的三次握手已经完成，连接已经建立。`accept()`函数的调用是建立连接后的一部分，用于接受已完成连接的套接字，以便服务器端可以与客户端进行通信。

三次握手过程中有哪些不安全性？

在TCP的三次握手过程中，存在一些潜在的不安全性问题，尽管这些问题并不常见，但在某些特定情况下可能会被利用。以下是一些可能的不安全性：

1. SYN 攻击（SYN Flooding）：攻击者可以发送大量的伪造源IP地址的SYN包给服务器，但不回应服务器的 SYN-ACK 包，从而使服务器资源耗尽。这会导致拒绝服务（Denial of Service）攻击，使服务器无法处理正常的连接请求。

2. 连接劫持（Connection Hijacking）：在三次握手的过程中，如果攻击者能够截获双方的握手数据包，并且能够预测或猜测序列号的生成方式，就有可能劫持连接。攻击者可以伪造双方的握手数据包，建立一个与服务器或客户端通信的连接，并在双方不知情的情况下进行数据传输或进行恶意操作。

3. SYN 窗口递增攻击（TCP SYN Window Increase Attack）：攻击者可以通过发送一系列SYN包，每个SYN包的窗口大小逐渐增加，来占用服务器的资源。这会导致服务器在等待握手完成的过程中，消耗大量的资源，从而影响服务器的正常运行。

要注意的是，这些不安全性问题都是在特定的攻击条件下才会成为问题，而且现代的操作系统和网络设备通常会采取各种防御措施来减轻这些风险。此外，网络安全意识和实施安全防护措施也是至关重要的，以确保网络和系统的安全。

TCP和UDP的区别？

TCP（传输控制协议）和UDP（用户数据报协议）是互联网协议套件中的两个主要传输协议，它们在功能和特性上有很大的区别。

主要区别如下：

1. 连接性：TCP是面向连接的协议，它在通信之前需要建立连接，确保可靠的数据传输。UDP是无连接的协议，它不需要建立连接，数据包可以直接发送。

2. 可靠性：TCP提供可靠的数据传输。它使用序列号、确认应答、重传机制等来确保数据的完整性和可靠性。UDP不提供可靠性保证，它发送的数据包可能会丢失、重复或者顺序错乱。

3. 速度：UDP比TCP更加轻量级，没有建立连接和保持状态的开销。因此，UDP的传输速度通常比TCP快。但是，UDP在传输过程中无法保证数据的顺序和可靠性。

4. 拥塞控制：TCP具有拥塞控制机制，它可以根据网络情况动态调整传输速率，以避免网络拥塞。UDP没有拥塞控制机制，数据包会以最大速度发送，可能导致网络拥塞。

5. 适用场景：TCP适用于对数据传输可靠性要求较高的应用，例如文件传输、电子邮件、网页浏览等。UDP适用于实时性要求较高、对可靠性要求较低的应用，例如实时音视频传输、DNS查询等。

总结起来，TCP提供可靠的、有序的、面向连接的数据传输，适用于需要数据完整性和顺序性的场景。UDP则是一种轻量级的、无连接的传输协议，适用于实时性要求高、可靠性要求相对较低的场景。

以上内容来自于网络整理，如有错误，欢迎指正。