计算机网络之TCP和UDP的底层机制
文章目录
- 1. TCP和UDP区别?
- 2.TCP为什么可靠传输
- 3. 怎么用UDP实现HTTP?
- 4. TCP粘包怎么解决
- 5. 滑动窗口
- 6. 拥塞控制
1. TCP和UDP区别?
TCP:
- 报头
- TCP发送数据
客户端:
#include<iostream>#include<string>#include<cstring>#include<sys/socket.h>#include<arpa/inet.h>#include<unistd.h>intmain(){// 1. 创建 TCP Socket (SOCK_STREAM 代表面向字节流的 TCP)intclient_fd=socket(AF_INET,SOCK_STREAM,0);if(client_fd==-1){std::cerr<<"TCP Socket 创建失败"<<std::endl;return-1;}// 2. 配置服务端的 IP 和端口structsockaddr_inserver_addr;memset(&server_addr,0,sizeof(server_addr));server_addr.sin_family=AF_INET;server_addr.sin_port=htons(8080);// 目标端口inet_pton(AF_INET,"127.0.0.1",&server_addr.sin_addr);// 目标 IP// 3. 发起连接 (此处会阻塞,底层自动完成 TCP 三次握手)if(connect(client_fd,(structsockaddr*)&server_addr,sizeof(server_addr))==-1){std::cerr<<"TCP 连接失败"<<std::endl;close(client_fd);return-1;}std::cout<<"TCP 三次握手成功,连接已建立!"<<std::endl;// 4. 发送业务数据 (连接建立后,只需关注发送的数据本身)std::string msg="Hello, TCP Server!";send(client_fd,msg.c_str(),msg.length(),0);// 5. 业务结束,关闭连接 (底层触发四次挥手的第一步,发送 FIN)close(client_fd);return0;}服务端:
监听socket只负责迎客,通信socket才负责收发数据。
- 前置准备:socket函数创建监听,socket->bind绑定端口->listen开始监听。
- 迎客(阻塞等待):调用accept函数,当有客户端完成三次握手连上来时,accept函数会返回一个全新的socket文件描述符通信fd。
- 接收数据针对那个新的通信fd调用recv函数或read函数来读取字节流数据。
#include<iostream>#include<string>#include<cstring>#include<sys/socket.h>#include<arpa/inet.h>#include<unistd.h>intmain(){// 1. 创建 TCP Socket (SOCK_STREAM 代表面向字节流、可靠的 TCP)intlisten_fd=socket(AF_INET,SOCK_STREAM,0);if(listen_fd==-1){std::cerr<<"TCP Socket 创建失败"<<std::endl;return-1;}// 2. 配置服务端要绑定的 IP 和端口structsockaddr_inserver_addr;memset(&server_addr,0,sizeof(server_addr));server_addr.sin_family=AF_INET;server_addr.sin_port=htons(8888);// 监听 8888 端口server_addr.sin_addr.s_addr=htonl(INADDR_ANY);// 监听本机所有网卡// 3. 绑定 (Bind):把 Socket 固定在 8888 端口上if(bind(listen_fd,(structsockaddr*)&server_addr,sizeof(server_addr))==-1){std::cerr<<"端口绑定失败"<<std::endl;close(listen_fd);return-1;}// 4. 监听 (Listen):告诉内核,这个 Socket 进入“被动等待”状态,准备迎接客人// 第二个参数 128 是“积压队列”的长度,表示允许多少个连接在排队等待 acceptif(listen(listen_fd,128)==-1){std::cerr<<"监听失败"<<std::endl;close(listen_fd);return-1;}std::cout<<"TCP 服务端启动成功,正在 8888 端口等待连接..."<<std::endl;// --- 开始处理连接和接收数据 ---while(true){structsockaddr_inclient_addr;socklen_t client_len=sizeof(client_addr);// 5. 接受连接 (Accept):这是 TCP 特有的步骤// accept 会阻塞,直到有客户端完成“三次握手”。// 它会返回一个全新的 Socket FD (conn_fd),专门用于和这一个客户端说话。intconn_fd=accept(listen_fd,(structsockaddr*)&client_addr,&client_len);if(conn_fd==-1){std::cerr<<"接收连接出错"<<std::endl;continue;}std::cout<<"新客户端已连上!IP: "<<inet_ntoa(client_addr.sin_addr)<<", 端口: "<<ntohs(client_addr.sin_port)<<std::endl;charbuffer[1024];while(true){// 针对这一个连接,循环读取数据memset(buffer,0,sizeof(buffer));// 6. 接收数据 (Recv):使用专属的 conn_fd,而不是监听的 listen_fdssize_t bytes_read=recv(conn_fd,buffer,sizeof(buffer)-1,0);if(bytes_read>0){std::cout<<"收到数据: "<<buffer<<std::endl;// 回复客户端send(conn_fd,"OK",2,0);}elseif(bytes_read==0){// recv 返回 0,代表对方关闭了连接(发了 FIN)std::cout<<"客户端已断开连接。"<<std::endl;break;}else{std::cerr<<"读取出错"<<std::endl;break;}}// 7. 关闭与该客户端的连接close(conn_fd);}// 8. 关闭监听 Socketclose(listen_fd);return0;}UDP:
- UDP报头
- UDP发送数据
客户端:
#include<iostream>#include<string>#include<cstring>#include<sys/socket.h>#include<arpa/inet.h>#include<unistd.h>intmain(){// 1. 创建 UDP Socket (SOCK_DGRAM 代表面向报文的 UDP)intclient_fd=socket(AF_INET,SOCK_DGRAM,0);if(client_fd==-1){std::cerr<<"UDP Socket 创建失败"<<std::endl;return-1;}// 2. 配置服务端的 IP 和端口structsockaddr_inserver_addr;memset(&server_addr,0,sizeof(server_addr));server_addr.sin_family=AF_INET;server_addr.sin_port=htons(8080);// 目标端口inet_pton(AF_INET,"127.0.0.1",&server_addr.sin_addr);// 目标 IP// 3. 直接发送数据 (没有握手过程,拿着地址直接发)std::string msg="Hello, UDP Server!";// 注意:每次发送都需要带上目标地址 server_addrssize_t sent_bytes=sendto(client_fd,msg.c_str(),msg.length(),0,(structsockaddr*)&server_addr,sizeof(server_addr));if(sent_bytes==-1){std::cerr<<"UDP 数据发送失败"<<std::endl;}else{std::cout<<"UDP 数据包已投递进网络层,不保证对方一定收到。"<<std::endl;}// 4. 关闭 Socket (本地资源回收,没有任何网络交互报文)close(client_fd);return0;}服务端:
UDP服务端的流程极其简单粗暴,没有握手,没有Listen函数,也没有ACCEPT函数。
- 前置准备:socket函数创建socket,bind函数绑定本机的端口。
- 直接接收:调用函数recvfrom函数。直谁给这个端口发送数据,他就收谁的。由于没有连接状态,recvfrom函数必须提供一个空的地址结构体,用来让内核把发送的IP和端口填进去,否则服务端连接该把回报发给谁。都不知道。
#include<iostream>#include<string>#include<cstring>#include<sys/socket.h>#include<arpa/inet.h>#include<unistd.h>intmain(){// 1. 创建 UDP Socket (SOCK_DGRAM 代表不可靠的、面向报文的 UDP)intudp_fd=socket(AF_INET,SOCK_DGRAM,0);if(udp_fd==-1){std::cerr<<"UDP Socket 创建失败"<<std::endl;return-1;}// 2. 配置服务端要监听的 IP 和端口structsockaddr_inserver_addr;memset(&server_addr,0,sizeof(server_addr));server_addr.sin_family=AF_INET;server_addr.sin_port=htons(8080);// 使用 htons 转换端口号为网络字节序// 注意这里:INADDR_ANY 表示监听本机的所有网卡 IP。// 假设你的服务器有内网 IP 和外网 IP,设为 INADDR_ANY 意味着无论数据包从哪个网卡进来,只要端口是 8080 都能收到。server_addr.sin_addr.s_addr=htonl(INADDR_ANY);// 3. 绑定 (Bind):把这个 Socket 和刚才配置的 IP 端口“死死绑定”在一起if(bind(udp_fd,(structsockaddr*)&server_addr,sizeof(server_addr))==-1){std::cerr<<"端口绑定失败,可能端口 8080 已被占用"<<std::endl;close(udp_fd);return-1;}std::cout<<"UDP 服务端启动成功,正在监听 8080 端口..."<<std::endl;// --- 以下是你之前看到的接收逻辑 ---charbuffer[1024]={0};structsockaddr_insender_addr;// 用来存放发件人的地址信息socklen_t sender_len=sizeof(sender_addr);while(true){// 服务端通常是一个死循环,不断接收数据memset(buffer,0,sizeof(buffer));// 每次接收前清空缓冲区// 4. 接收数据 (阻塞等待)ssize_t bytes_received=recvfrom(udp_fd,buffer,sizeof(buffer)-1,0,(structsockaddr*)&sender_addr,&sender_len);if(bytes_received>0){// 利用 inet_ntoa 和 ntohs 把对方的网络字节序 IP 和端口转回我们能看懂的格式std::cout<<"收到来自 ["<<inet_ntoa(sender_addr.sin_addr)<<":"<<ntohs(sender_addr.sin_port)<<"] 的消息: "<<buffer<<std::endl;// 如果需要回包,直接用 sendto// std::string reply = "服务端已收到";// sendto(udp_fd, reply.c_str(), reply.length(), 0, (struct sockaddr*)&sender_addr, sender_len);}else{std::cerr<<"接收数据出错"<<std::endl;}}// 5. 关闭 Socket (实际上死循环服务端很少走到这里,通常通过捕获终止信号来关闭)close(udp_fd);return0;}区别:
- 连接:TCP是面向连接的传输层协议传输数据前先要建立连接。 UDP是不需要连接,即刻传输数据。
- 服务对象:TCP是一对一的两点服务,即一条连接只有两个端点,UDP支持一对一,一对多,多对多的交互通信。
- 可靠性:TCP是可靠交付数据的数据,可以无差错不丢失、不重复按序到达。UDP是不可靠的传输协议,不保证可靠交付数据发送数据丢了就丢了,不会有任何措施。但是我们可以基于UDP传输协议实现一个可靠的传输协议,比如QUIC协议。
- 拥塞控制,流量控制:TCP有拥塞控制和流量控制机制,保证数据传输的安全性。UDP则没有,即使网络,非常拥堵了,也不会影响UDP发送速率。
- 首部开销:TCP首部长度较长,会有一定的开销,首部在没有使用选项字段时是20个字节,如果使用了选项字段则会变得更长。UDP首部只有八个字节,并且是固定不变的,开销较小。
- 传输方式:TCP是流式传输,没有边界,但保证顺序和可靠。UDP是一个包,一个包的发送是有边界的,但可能会丢包和乱序。
2.TCP为什么可靠传输
TCP主要通过以下几点来保证传输可靠性:连接管理、序列号、确认序列号、超时重传、流量控制、拥塞控制。
- 连接管理:即通过三次握手和四次挥手确保连接可靠性。这是保证可靠传输的前提。
- 序列号:TCP将每个字节数据都进行编号。序列号具体作用如下,能保证数据可靠性,既能防止数据丢失,又能防止数据重复。避免乱序,按照序列号将数据进行还原。能够提高效率,基于序列号可以实现多次发送,一次接收。
- 确认序列号:接收方接收到数据后会回传ACK报文。报文中带有此的次确认序列号,用于告知发送方此次已经接收情况。在指定时间后,发送端仍未收到确认应答,就会启动超时重传。
- 流量控制:接收端处理数据速度是有限的。如果发送方发送数据过快,这会导致接收端缓冲区溢出,从而丢包。为了避免上述情况发生,TCP支持根据接收端处理能力来决定发送端的发送速度,这就是流量控制。流量控制是通过在TCP报文,首部维护一个滑动窗口来实现。
- 拥塞控制:拥塞控制是当网络严重拥堵,发送端减少发送数据。拥塞控制是通过发送端维护一个拥塞窗口来实现。可以得出发,送端发送速度受限于滑动窗口和拥塞窗口的最小值。拥塞控制方法分为慢开始,拥塞避免、快重传和快恢复。
3. 怎么用UDP实现HTTP?
实现思路:把TCP在操作系统内核中做的事情搬到用户态自己实现一遍。
- 解决乱序与去重
- 问题:UDP发送的包可能错误顺序被接收端接收。或因为网络问题导致重传,导致接收端收到重复包。
- 实现:在udp包内自定义一个应用层包头。加入序列号(seq),接收端需要在内存中维护一个接收缓冲区,按照序列号把乱序的包重新拼装成连续的字节后再交给HTTP协议器处理。
- 解决丢包问题
问题:udp发出后就不管了,丢了也不知道。
实现:引入确认应答ACK机制。
- 客户端发送seq=100的udp包,开启一个定时器。
- 服务端收到后会回复一个带有ACK=101的包。
- 如果客户端的定时器超时,还没有收到ACK,就主动重传seq=100的包。
- 大文件传输的分片与重组
- 问题:HTTP经常用来传大图片或视频,如果把1M的HTTP报文扔给udp,这会导致底层IP层严重分片,一旦丢一个IP分片,整个1M数据全部作废。
- 实现:应用层必须主动将巨大HTTP报文切分成小于网络MTU(通常是1500字节减去IP和udp头部后,大约1400字节左右)的小块。每一块独立封装成一个udp包发送。
- 连接状态管理
- 问题:TCP是由[源IP,源端口,目的IP,目的端口]四元组唯一标识的。如果用户拿着手机从5G切换到WiFi, IP变了,TCP连接也会断开。
- 实现:既然用udp,我们可以彻底摒弃IP和端口的束缚,在自定义的报头里加一个唯一的连接标识符。不管客户端的IP怎么变,只要报头里的ID没变,服务端就认为这是同一个HTTP会话。这就是QUIC协议,连接迁移的特性。
- 流量控制与拥塞控制(滑动窗口)
- 问题:不能因为udp快就往死里发,这会把对方接收缓冲区打满,或者把中间路由器打挂。
- 实现:需要在应用层实现一套类似于TCP滑动窗口机制,根据接收端处理能力(流量控制),和网络拥堵程序度(拥塞控制)动态调整发送窗口的大小。
4. TCP粘包怎么解决
TCP是面向字节流的协议底层根本没有包的概念。数据就像流水一样,源源不断的从发送端流向接收端。因此,在应用层人为地规定消息的边界。主要解决办法有以下3种。
- 消息定长
- 核心思路:规定发送的每一个消息长度都是固定不变的(比如固定1024个字节),如果真实数据不够1024字节,就用空格或/0补齐。
- 接收端逻辑:每次死循环recv,只要缓冲区里凑够了1024字节就直接截断拿出来,作为一个完整消息处理。
- 优缺点:极其简单,但非常浪费网络带宽。
- 特殊分隔符
- 核心思路:在每个消息的尾部加上一个约定的特殊字符(比如/r或/r/n)
- 接收端逻辑:不断读取字节流,并在内存中扫描,一旦扫到这个特殊字符,就把前面数据当做一个完整的包切出来。
- 经典应用:HTTP协议的header部分通过/r/n/r/n分割Header和Body。
- 优缺点:实现较为直观,但不适合传输二进制数据,比如图片视频,因为二进制正文中很容易碰到和分割符一模一样字节,导致被错误截断。如非要传,正文必须先做BASE64编码或转义。
- 消息头带长度
该方法是最常用最标准的解决方案。
核心思路:将网络包分为Header包头和Body包体两部分。包头的长度是固定的,比如固定四字节,里面存放一个32位整数,这个整数精确记录了后面包体的总长度。
接收端处理逻辑:
- 先读包头强制recv固定的4字节解析出Body的长度N。
- 再读包体,写一个while循环继续recv,直到精确地把这个N个字节全部读完,多一个字节都不要。此时,一个完整干净的业务包就拿到了。
经典应用:HTTP/1.1的Body部分利用Header中的Content-Length字段表明正文长度,绝大多数自定义私有协议。
5. 滑动窗口
- 核心作用
移动窗口是TCP协议中用于实现流量控制和提升传输效率的核心机制。
- 提升效率。传统的停等协议发一个就要等待一个AC K效率太低。滑动窗口允许发送方在没有收到确认的情况下。连续发送多个数据包极大提高了网络的吞吐量。
- 流量控制可以防止发送方发的太快导致接收方缓冲区。被打满而丢包的问题让发送方的发送速率与接收方的处理能力相匹配。
- 工作机制。
接收方的通知窗口。接收方在每次回复ACK时会通知TCP报头告诉发送方自己当前的接收缓冲区还能容纳多少字节。
发送方窗口的状态划分。发送方的窗口大小由接收方通告的窗口大小决定。发送方会将维护的字节序列分为四部分:
- 已发送,且已收到AC K确认的数据窗口左侧。
- 已发送,但未收到ACK确认的数据窗口内。
- 未发送但允许发送的数据窗口内,这是剩余的可用额度。
- 未发送且不允许发送的数据窗口左侧。超出接收方能力。
滑动过程,只有当窗口最左侧的数据收到ACK后。整个窗口才会向右滑动,从而释放额度,允许发送后续的新数据。
- 如果接收方缓冲区满了通告窗口为零会发生什么?(零窗口探测)
- 当发送方收到零窗口通知时,会停止发送应用数据。为了防止接收方后来发送的窗口恢复ACK报文丢失,导致双方死锁,发送方会启动一个坚持定时器。定时器超时后,发送方会主动发送一个零窗口探测报文,强制接收方重新发送窗口大小。
- 什么是糊涂窗口综合症,怎么解决?
如果接收方应用程序处理的很慢,每次只从缓冲区读几个字节,然后向发送方通告一个只有几个字节的小窗口,发送方一收到就立刻发送这几个字节数据,这会导致TCP报文头部20加20字节的开销远大于有效载荷,极大浪费网络带宽。
解决方案:
- 接收端:如果可用空间太小,干脆通告窗口为零,直到缓冲区可用空间,达到总空间一半或能容纳一个MSS最大报文长度时,在通告真实窗口。
- 发送端:配合使用Nagle算法,只要还有未确认数据就把零碎小数据攒起来,等收到前一个ACK,或攒够一个MSS时再一起发。
6. 拥塞控制
滑动窗口解决的是收发双方点对点的处理速度匹配问题。而拥塞控制解决是全局网络链路的过载问题,防止过多数据同时注入网络导致路由瘫痪。
核心技术:四大算法
TCP通过维护一个拥塞窗口(cwnd)和一个慢启动阀值(ssthresh)。来动态调整发送速率。整个过程分为四个阶段联动。
- 慢启动:连接刚建立或严重超时时触发,cwnd初始为极小值,如十个mss。这表明发送方会发送十个MSS,此后每收到一个ACK, cwnd就加一,也就是 RTT往返时间窗口大小呈指数级翻倍,它的目的是快速探测网络的承载能力。
- 拥塞避免:当cwnd增长到等于或超过ssthresh时,指数增长停止,转为线性增长。每个RTT内的cwnd增加一个MSS,这是一种保守的示范,避免瞬间压垮网络。
- 快重传: TCP不会死板等待超时定时器触发。如果发送方连续收到三个重复ACK说明,该ACK后序列的包丢失,但网络整体没断。此时会立即重传丢失的包,提高响应速度。
- 快恢复:触发快重传后TCP认为网络只是轻微拥塞。此时会将ssthresh减半,cwnd也设置为减半后的值(部分实际会加上三个mss)。然后直接进入拥塞避免的,线性增长阶段,而不是退回到慢启动,从而维持较高的吞吐量。
拥塞判定的两种程度:
- 严重拥塞(RTO超时):数据包石沉大海,连重复的ACK都收不到。此时极其严厉,cwnd直接重置为1,ssthresh减半,重新进入慢启动。
- 轻微拥塞(收到三个重复ACK):触发快重传和快恢复,平滑处理性能抖动较小。
