为什么我的modbustcpserver只能连一个client_TCP协议概览

文章说明&＃xff0c;视频分享 喜欢c&＃43;&＃43; Linux后台服务器开发的朋友可以后台私信【架构】获取图中视频

背景知识——互联网分层模型

1. 应用层(DNS&＃xff0c;FTP&＃xff0c;HTTP&＃xff0c;RTSP&＃xff0c;SSH&＃xff0c;TLS/SSL&＃xff0c; XMPP&＃xff0c; DHCP...)
2. 传输层(TCP&＃xff0c;UDP...)
3. 网络层(IP&＃xff0c;...)
4. 链路层(ARP&＃xff0c;...)
5. 实体层

另外&＃xff0c;也有将互联网分为7层的说法&＃xff0c;他们分别是&＃xff1a;应用层、
表示层(提供数据格式或转换服务。比如&＃xff1a;加密与解迷&＃xff0c;编码与解码&＃xff0c;压缩与解压)、
会话层(为客户端的应用程序提供了打开、关闭和管理会话的机制)、
传输层、网络层、数据链路层、物理层。

TCP 是什么&＃xff1f;

TCP(Transmission Control Protocol 传输控制协议)是一种面向连接的、可靠的、基于字节流(byte stream)的传输层通信协议&＃xff1b;
TCP 基于不可靠的 IP 协议&＃xff0c;提供稳定、可靠的数据传输服务&＃xff1b;
对于 TCP 需要知道的是&＃xff0c;TCP 所处的第2层传输的数据叫 Segment&＃xff0c;IP 所处的第3层传输的叫 Datagram&＃xff0c; 第4层传输的数据则叫做 Frame&＃xff1b;
数据从应用层往下传输&＃xff0c;每经过一层都会在数据头部被加上一个 header &＃xff0c;层层封装&＃xff1b;
反之&＃xff0c;则需要层层解封&＃xff0c;最后应用层才能取得数据。

TCP 特性

1. 点对点协议
2. 可靠
3. 管道传输(同时送多个segments)
4. sender & receiver 都有 buffer
5. byte stream
6. 双向传输
7. 面向连接(oriented connection)
8. 重传机制

TCP segment 结构体(这个非常重要)

tcp-segment.png

• source port&＃xff1a;源 Application 端口号
• dest port&＃xff1a;目标 Application 端口号

TCP 三次握手(如何建立连接&＃xff1f;)

1. Client 传送一个 SYN segment 给 Server(init sequence number)
2. Server 收到 SYN&＃xff0c;回一个 SYNACK segment 给 Client(alloc buffer; init sequence number)
3. Client 收到 SYNACK&＃xff0c;再回一个ACK&＃xff0c;从此连接才算是建立完成(同时&＃xff0c;可以带上 data 做数据传输)

TCP 为什么需要三次握手&＃xff1f;

TCP 四次分手(如何关闭连接&＃xff1f;)

1. client 传送一个 FIN segment 给 server&＃xff0c;请求关闭连接
2. server 回一个 ack 给 client&＃xff0c;表示 client 可以关闭连接了
3. server 再发一个 FIN segment 给 client&＃xff0c;请求关闭连接
4. client 回一个 ack 给 server&＃xff0c;表示 server 可以关闭连接&＃xff0c;server 收到 ack ,关闭连接。此时&＃xff0c;client 等待2MSL后依然没有收到回复&＃xff0c;则证明 server 端已正常关闭&＃xff0c;那好&＃xff0c;client 也可以关闭连接了。

tcp_close.png

TCP 为什么需要四次分手&＃xff1f;

简单来说&＃xff0c;因为 TCP 连接是双向的&＃xff0c;所以 sender 需要发送 FIN 征求 server 的同意&＃xff1b;随后&＃xff0c;server 收到 client 的请求&＃xff0c;给 client 回复 ack&＃xff0c;告诉它&＃xff0c;此时可以关闭连接&＃xff1b;而 server 同时也需要通知 client &＃xff0c;告诉它自己不会再传输数据了&＃xff0c;所以&＃xff0c;server 给 client 发送 FIN 信号&＃xff1b;最后&＃xff0c;client 收到 server 的请求&＃xff0c; 回复 ack 表示同意。

TCP 如何保证数据传输是可靠的&＃xff1f;

1. 给 byte stream 编号
2. receiver 校验数据的正确性
3. receiver 回复 ack
4. timer. 发生 timeout 时&＃xff0c;重传

TCP 重传机制

为什么会重传&＃xff1f;
1. 丢失 ack
Host A 给 Host B 传输 数据&＃xff0c; 随后 Host B 给 A 回复 ack&＃xff0c; 但由于网络原因&＃xff0c;这个 ack 在传输过程中 loss 了&＃xff0c; 那么经过一个 timeout 时间后&＃xff0c;Host A 给 Host B 重新传送这份数据。
2. timeout
Host A 给 Host B 传输数据&＃xff0c; 随后 Host B 给 A 回复 ack &＃xff0c;但由于网络延迟&＃xff0c;这个 ack 在一个 timeout 时间内没有被及时送给 Host A&＃xff0c;经过一个 timeout 时间后&＃xff0c;重送数据&＃xff0c;并且在收到延时的 ack 后&＃xff0c; 按实际收到的数据回复 ack
3. 收到3次重复的 ack
由于 receiver 回复给 sender 的 ack 序列号表示期望下次 sender 送过来的数据的序列号&＃xff0c;所以当 sender 收到 3次重复的 ack(也就是 ack 序列号都一样)&＃xff0c;这个时候就会重新发送丢包或者延迟的 packet

快速重传&＃xff1a;在发生 timeout 之前重传数据。

TCP Nagle Algorithm & Delay Ack

以上两种策略都是针对TCP 频繁传送小包的情况&＃xff0c;

1. Nagle Algorithm: 发送一个小包后&＃xff0c;如果这个小包还没有被 ack &＃xff0c;则后面等待发送的少量数据&＃xff0c;会进入 buffer 缓冲区&＃xff0c;
   这部分数据在等待时间到了后才会被统一发送出去。
2. Delay Ack: receiver 收到的数据如果不是按顺序送进来的&＃xff0c;则会先不发 ack &＃xff0c;等一定顺序的数据都到了后&＃xff0c;统一发 ack&＃xff0c; 尽量减少 ack 的次数。
   根据他们的处理机制可以知道&＃xff0c;这两种策略都是牺牲时效性来提升性能。遇到时效性高的应用场景&＃xff0c;可以自行关闭。