【在Linux世界中追寻伟大的One Piece】传输层协议TCP

枫叶丹4

已于 2024-09-02 19:42:57 修改

阅读量1.4k

点赞数 93

分类专栏： Linux 文章标签： tcp/ip linux 网络网络协议服务器

于 2024-08-31 22:06:42 首次发布

本文链接：https://blog.csdn.net/weixin_74809706/article/details/141756148

版权

Linux 专栏收录该内容

15 篇文章 0 订阅

订阅专栏

1 -> TCP协议

6 -> 理解TIME_WAIT状态

7 -> 理解CLOSE_WAIT状态

15 -> TCP小节

1 -> TCP协议

TCP(Transmission Control Protocol，传输控制协议)是一种面向连接的、可靠的、基于字节流的传输层通信协议。它是互联网协议套件中的核心协议之一，由IETF的RFC 793定义。TCP提供了一种全双工通信方式，确保数据的顺序性、完整性和可靠性。TCP通过三次握手建立连接，并在数据传输过程中使用序列号、确认应答、重传机制、流量控制和拥塞控制等技术来维护通信的可靠性。在TCP连接的生命周期中，还包括数据传送和连接终止两个阶段。数据传送阶段中，TCP使用滑动窗口机制来控制发送速率，避免接收方缓冲区溢出。连接终止阶段则通过四次挥手来优雅地关闭连接。

2 -> TCP协议段格式

TCP(Transmission Control Protocol，传输控制协议)协议段的格式包括固定长度的首部和可变长度的数据部分。首部中包含了用于建立和维护连接、传输控制和错误检测等功能的各种字段。

固定首部字段

源端口(Source Port)：16位，标识发送端应用程序的端口。
目的端口(Destination Port)：16位，标识接收端应用程序的端口。
序号(Sequence Number)：32位，标识发送的数据字节流中的第一个字节。
确认号(Acknowledgment Number)：32位，接收端期望接收的下一个序号，用于确认已正确接收的数据。
数据偏移(Header Length)：4位，指示TCP首部的长度，单位为32位字(4字节)。
保留(Reserved)：6位，当前保留，必须设置为0。
控制位(Control Bits)：9位，包含了6个标志位。
- 6位标志位：
  - URG：紧急指针是否有效。
  - ACK：确认号是否有效。
  - PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走。
  - RST：对方要求重新建立连接；我们把携带RST标识的称为复位报文段。
  - SYN：请求建立连接; 我们把携带SYN标识的称为同步报文段。
  - FIN：通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段。
窗口大小(Window Size)：16位，发送端的接收窗口大小，用于流量控制。
校验和(Checksum)：16位，用于检测首部和数据在传输过程中的错误。
紧急指针(Urgent Pointer)：16位，仅在URG控制位为1时有效，指示紧急数据的结束位置。

可变选项字段

选项(Options)：长度可变，最多可达40字节，包含了如最大报文段大小(MSS)、窗口缩放因子、时间戳等可选信息。

填充(Padding)

填充(Padding)：用于确保TCP首部的长度是4字节的整数倍。

数据部分

数据(Data)：可变长度，包含了实际传输的应用层数据。

TCP段的首部长度最小为20字节，这是不包含任何选项时的长度。选项字段的存在使得TCP首部可以根据需要扩展，以支持不同的网络环境和应用需求。

3 -> 确认应答(ACK)机制

TCP将每个字节的数据都进行了编号。即为序列号。

每一个ACK都带有对应的确认序列号，意思是告诉发送者，我已经收到了哪些数据；下一次从哪里开始发。

4 -> 超时重传机制

主机A发送数据给B之后，可能因为网络拥堵等原因，数据无法到达主机B。
如果主机A在一个特定时间间隔内没有收到B发来的确认应答，就会进行重发。

但是，主机A未收到B发来的确认应答，也可能是因为ACK丢失了。

因此主机B会收到很多重复数据。那么TCP协议需要能够识别出那些包是重复的包，并且把重复的丢弃掉。

这时候我们可以利用前面提到的序列号，就可以很容易做到去重的效果。

那么，如果超时的时间如何确定？

最理想的情况下，找到一个最小的时间，保证"确认应答一定能在这个时间内返回"。
但是这个时间的长短，随着网络环境的不同，是有差异的。
如果超时时间设的太长，会影响整体的重传效率。
如果超时时间设的太短，有可能会频繁发送重复的包。

TCP为了保证无论在任何环境下都能比较高性能的通信，因此会动态计算这个最大超时时间。

Linux中(BSD Unix 和 Windows 也是如此)，超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。
如果重发一次之后，仍然得不到应答，等待2*500ms后再进行重传。
如果仍然得不到应答，等待4*500ms进行重传。依次类推，以指数形式递增。
累计到一定的重传次数，TCP认为网络或者对端主机出现异常，强制关闭连接。

5 -> 连接管理机制

在正常情况下，TCP要经过三次握手建立连接，四次挥手断开连接。

服务端状态转化：

[CLOSED -> LISTEN]服务器端调用listen后进入LISTEN状态，等待客户端连接。
[LISTEN -> SYN_RCVD]一旦监听到连接请求(同步报文段)，就将该连接放入内核等待队列中，并向客户端发送SYN确认报文。
[SYN_RCVD -> ESTABLISHED]服务端一旦收到客户端的确认报文，就进入ESTABLISHED状态，可以进行读写数据了。
[ESTABLISHED -> CLOSE_WAIT]当客户端主动关闭连接(调用close)，服务器会收到结束报文段，服务器返回确认报文段并进入CLOSE_WAIT。
[CLOSE_WAIT -> LAST_ACK]进入CLOSE_WAIT后说明服务器准备关闭连接(需要处理完之前的数据)；当服务器真正调用close关闭连接时，会向客户端发送FIN，此时服务器进入LAST_ACK状态，等待最后一个ACK到来(这个ACK是客户端确认收到了 FIN)。
[LAST_ACK -> CLOSED]服务器收到了对FIN的ACK，彻底关闭连接。

客户端状态转化：

[CLOSED -> SYN_SENT]客户端调用connect，发送同步报文段。
[SYN_SENT -> ESTABLISHED]connect调用成功，则进入ESTABLISHED状态，开始读写数据。
[ESTABLISHED -> FIN_WAIT_1]客户端主动调用close时，向服务器发送结束报文段，同时进入FIN_WAIT_1。
[FIN_WAIT_1 -> FIN_WAIT_2]客户端收到服务器对结束报文段的确认，则进入FIN_WAIT_2，开始等待服务器的结束报文段。
[FIN_WAIT_2 -> TIME_WAIT]客户端收到服务器发来的结束报文段，进入TIME_WAIT，并发出LAST_ACK。
[TIME_WAIT -> CLOSED]客户端要等待一个2MSL(Max Segment Life，报文最大生存时间)的时间，才会进入CLOSED状态。

下图是TCP状态转换的一个汇总：

较粗的虚线表示服务端的状态变化情况。
较粗的实线表示客户端的状态变化情况。
CLOSED是一个假想的起始点，不是真实状态。

6 -> 理解TIME_WAIT状态

现在做一个测试，首先启动server，然后启动client，然后用Ctrl-C使server终止，这时马上再运行server，结果是：

这是因为，虽然server的应用程序终止了，但TCP协议层的连接并没有完全断开，因此不能再次监听同样的server端口。我们用netstat命令查看一下：

TCP协议规定，主动关闭连接的一方要处于TIME_ WAIT状态，等待两个MSL(maximum segment lifetime)的时间后才能回到CLOSED状态。
我们使用Ctrl-C终止了server，所以server是主动关闭连接的一方，在TIME_WAIT期间仍然不能再次监听同样的server端口。
MSL在RFC1122中规定为两分钟，但是各操作系统的实现不同，在Centos7上默认配置的值是 60s。
可以通过cat /proc/sys/net/ipv4/tcp_fin_timeout查看msl的值。
规定TIME_WAIT的时间请读者参考UNP 2.7节。

为什么是TIME_WAIT的时间是2MSL？

MSL是TCP报文的最大生存时间，因此TIME_WAIT持续存在2MSL的话。
就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失(否则服务器立刻重启，可能会收到来自上一个进程的迟到的数据，但是这种数据很可能是错误的)。
同时也是在理论上保证最后一个报文可靠到达(假设最后一个ACK丢失，那么服务器会再重发一个FIN。这时虽然客户端的进程不在了，但是TCP连接还在，仍然可以重发LAST_ACK)。

7 -> 理解CLOSE_WAIT状态

#pragma once
#include <functional>
#include "tcp_socket.hpp"

typedef std::function<void(const std::string& req, std::string*
	resp)> Handler;

class TcpServer 
{
public:
	TcpServer(const std::string& ip, uint16_t port) : ip_(ip),
		port_(port) {
	}

	bool Start(Handler handler) 
	{
		// 1. 创建 socket;
		CHECK_RET(listen_sock_.Socket());
		// 2. 绑定端口号
		CHECK_RET(listen_sock_.Bind(ip_, port_));
		// 3. 进行监听
		CHECK_RET(listen_sock_.Listen(5));
		// 4. 进入事件循环
		for (;;) 
		{
			// 5. 进行 accept
			TcpSocket new_sock;
			std::string ip;
			uint16_t port = 0;
			if (!listen_sock_.Accept(&new_sock, &ip, &port)) 
			{
				continue;
			}

			printf("[client %s:%d] connect!\n", ip.c_str(), port);
			// 6. 进行循环读写
			for (;;) 
			{
				std::string req;
				// 7. 读取请求. 读取失败则结束循环
				bool ret = new_sock.Recv(&req);
				if (!ret) 
				{
					printf("[client %s:%d] disconnect!\n", ip.c_str(),
						port);
					// [注意!] 将此处的关闭 socket 去掉
					// new_sock.Close();
					break;
				}

				// 8. 计算响应
				std::string resp;
				handler(req, &resp);

				// 9. 写回响应
				new_sock.Send(resp);
				printf("[%s:%d] req: %s, resp: %s\n", ip.c_str(), port,
					req.c_str(), resp.c_str());
			}
		}

		return true;
	}

private:
	TcpSocket listen_sock_;
	std::string ip_;
	uint64_t port_;
};

编译运行服务器。启动客户端链接，查看TCP状态，客户端服务器都为ESTABLELISHED状态，没有问题。

然后我们关闭客户端程序，观察TCP状态。

tcp

0

0 0.0.0.0:9090

0.0.0.0:*

LISTEN

5038/./dict_server

tcp

0

0 127.0.0.1:49958

127.0.0.1:9090

FIN_WAIT2

-

tcp

0

0 127.0.0.1:9090

127.0.0.1:49958

CLOSE_WAIT 5038/./dict_server

此时服务器进入了CLOSE_WAIT状态，结合我们四次挥手的流程图，可以认为四次挥手没有正确完成。

小结：对于服务器上出现大量的CLOSE_WAIT状态，原因就是服务器没有正确的关闭socket，导致四次挥手没有正确完成。这是一个BUG。只需要加上对应的close即可解决问题。

8 -> 滑动窗口

对每一个发送的数据段，都要给一个ACK确认应答。收到ACK后再发送下一个数据段。这样做有一个比较大的缺点，就是性能较差。尤其是数据往返的时间较长的时候。

既然这样一发一收的方式性能较低，那么我们一次发送多条数据，就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了)。

窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是4000个字节(四个段)。
发送前四个段的时候，不需要等待任何ACK，直接发送。
收到第一个ACK后，滑动窗口向后移动，继续发送第五个段的数据依次类推。
操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有应答；只有确认应答过的数据，才能从缓冲区删掉。
窗口越大，则网络的吞吐率就越高。

那么如果出现了丢包，如何进行重传？这里分两种情况讨论。

情况一：数据包已经抵达，ACK被丢了。

这种情况下，部分ACK丢了并不要紧，因为可以通过后续的ACK进行确认。

情况二：数据包就直接丢了。

当某一段报文段丢失之后，发送端会一直收到1001这样的ACK，就像是在提醒发送端"我想要的是 1001"一样。
如果发送端主机连续三次收到了同样一个"1001"这样的应答，就会将对应的数据1001 - 2000重新发送。
这个时候接收端收到了1001之后，再次返回的ACK就是7001了(因为 2001 - 7000)接收端其实之前就已经收到了，被放到了接收端操作系统内核的接收缓冲区中。

这种机制被称为"高速重发控制"(也叫"快重传")。