TCP和UDP协议

最新推荐文章于 2023-10-17 21:32:47 发布

努力加油鸭！

最新推荐文章于 2023-10-17 21:32:47 发布

阅读量607

点赞数

分类专栏：网络文章标签： tcp/ip udp 网络

本文链接：https://blog.csdn.net/qq_52463861/article/details/127983396

版权

网络专栏收录该内容

6 篇文章 0 订阅

订阅专栏

一、TCP协议

TCP是传输控制协议，是传输层的重要协议。

1.1TCP的特点

面向连接的、可靠的、基于字节流的传输层通讯协议。

1.2TCP协议段格式

在这里插入图片描述
TCP首部通常包含20个字节
6位标志位说明：
1.URG:紧急指针是否有效
2.ACK:紧急指针是否有效
3.PSH:提示接收端应用程序立刻从TCP缓冲区把数据读走
4.RST:重建连接
5.SYN:请求建立连接，我们称携带SYN标识的为同步报文段
6.FIN:关闭连接标识，我们称携带FIN标识的为结束报文段

1.3TCP的八大机制

1.3.1确认应答机制（ACK）

安全机制
在这里插入图片描述
简单来说：确认序列号就是告诉发送者，我已经收到了哪些数据，下一次你从哪里开始发送。

1.3.2超时重传机制

安全机制
在这里插入图片描述
主机A发送数据给B之后，可能因为网络拥堵等原因，数据无法到达主机B；如果主机A在一个特定时间间隔内没有收到B发来的确认应答，就会进行重发；

未收到确认应答并不意味着数据一定丢失，也有可能是数据对方已经收到了，只是返回确认应答在途中丢失，这种情况也会导致发送端误以为数据没有到达目的地而重发数据。

超时时间的确定：
重发超时是指在重发数据之前，等待确认应答到来的那个特定时间间隔。如果超过这个时间仍未收到确认应答，发送端就会进行重发。超时时间在最理想的情况下，就是找到一个最小时间，保证“确认应答一定能在这个时间内返回”。
TCP为了保证无论在任何情况下都能比较高性能的通信，因此会动态计算这个最大超时时间。

1.3.3连接管理机制

安全机制
正常情况下，TCP需要经过三次握手建立连接，四次挥手断开连接。

1.3.3.1三次握手：

在这里插入图片描述
第一次握手：
客户端将标志位SYN（请求连接）置为1，随机产生一个值seq=J（序号），并将该数据包发送给服务器端，客户端进入SYN_SENT状态，等待服务器确认。
第二次握手：
服务器端收到数据包之后由标志位SYN=1知道客户端请求建立连接，服务器端将标志位SYN和ACK都置为1，ack=J+1(回复消息的序号)，随机产生一个seq=K，并将该数据包发送给客户端以确认连接请求，服务器端进入SYN_RCVD状态。
第三次握手：
客户端收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack置为K+1,并将该数据包发送给服务器端，服务器检查ack是否为K+1，ACK是否为1，如果正确则建立连接成功，客户端和服务器端进入ESTABLISHED状态，完成三次握手，随后客户端和服务器端就可以开始传输数据了。

1.3.3.2四次挥手

在这里插入图片描述
中断连接端可以是客户端也可以是服务器端。
第一次挥手：
客户端发送一个FIN=M，用来关闭客户端到服务器端的数据传送，客户端进入FIN_WAIT_1状态，意思是“客户端你没有数据要发给你了，但是如果你服务器端还有数据没发送完，不必着急关闭连接，你可以继续发送数据”。
第二次挥手：
客户端发送一个FIN=M，用来关闭客户端到服务器端的数据传送，客户端进入FIN_WAIT_1状态，意思是“客户端你没有数据要发给你了，但是如果你服务器端还有数据没发送完，不必着急关闭连接，你可以继续发送数据”。
第三次挥手：
当服务器端确定数据发送完成，则向客户但发送FIN=N的报文，告诉客户端：好了，我这边数据发完了，准备好关闭连接了，服务器端进入LAST_ACK状态。
第四次挥手：
客户端收到FIN=N的报文后，就知道可以关闭连接了，但是他还是不相信，所以发送ack=N+1后进入TIME_WAIT状态，服务器端收到ACK之后，就知道可以断开连接了。客户端等待2MSL后依然没有收到回复，则证明服务器端已经正常关闭，然后客户端也关闭连接，最终实现了四次握手。

1.3.4滑动窗口机制

效率机制

1.3.5流量控制机制

安全机制

1.3.6拥塞控制机制

安全机制

1.3.7延迟应答机制

效率机制

1.3.8捎带应答机制

效率机制

1.4TCP的粘包问题

在TCP的协议头中，没有如同UDP一样的 “报文长度” 这样的字段，但是有一个序号这样的字段。

a.站在传输层的角度，TCP是一个一个报文过来的。按照序号排好序放在缓冲区中。
b. 站在应用层的角度，看到的只是一串连续的字节数据。
c.那么应用程序看到了这么一连串的字节数据，就不知道从哪个部分开始到哪个部分，是一个完整的应用层数据包。

那么如何避免粘包问题呢？
其实就是要明确两个包的边界，对于定长的包，每次按固定大小读取即可，对于变长的包既可以在包头的位置约定一个总包长度的字段，从而就可以知道包的结束位置，又可以在包和包之间使用明确的分隔符。

基于TCP应用层的协议：
HTTP
HTTPS
SSH

二、UDP协议

2.1UDP协议特点

1.无连接
2.不可靠
3.面向数据报
4.没有发送缓冲区只有接收缓冲区
5.大小受限：UDP协议首部中有一个16位的最大长度。也就是说一个UDP能传输的数据最大长度是64K（包含UDP首部）。

2.2常见面试题

1.UDP本身是无连接，不可靠，面向数据报的协议，如果要基于传输层UDP协议，来实现一个可靠传输，应该如何设计？
解答：
最简单的方式就是在应用层模仿传输层TCP的可靠性传输，添加保证可靠性的机制：
实现确认应答机制：把每个数据收到之后，都要反馈一个ACK（这就不是内核返回的了，而是应用程序自己定义一个ack包，发送回去）
实现序号/确认序号，以及实现去重。
实现连接管理机制
实现滑动窗口（提高效率）
为了限制滑动窗口，实现流量控制/拥塞控制
实现延时应答，捎带应答，心跳机制