TCP与UDP传输层协议的理解

水煮白菜王

已于 2024-09-24 16:48:00 修改

阅读量575

点赞数 5

分类专栏：前端前端面试计算机网络文章标签： tcp/ip udp 网络协议前端面试

于 2024-06-13 20:50:44 首次发布

本文链接：https://blog.csdn.net/weixin_45511682/article/details/139663827

版权

前端同时被 3 个专栏收录

25 篇文章 3 订阅

订阅专栏

前端面试

13 篇文章 0 订阅

订阅专栏

计算机网络

6 篇文章 0 订阅

订阅专栏

在这里插入图片描述

🤖 作者简介：水煮白菜王，一位资深前端劝退师 👻
👀 文章专栏：计算机网络专栏，记录一下平时在博客写作中，总结出的一些开发技巧✍。
感谢支持💕💕💕

关联文章：
计算机网络模型认识
 WebSocket通信
 DNS协议
 TCP与UDP
HTTP协议
 HTTP3

TCP与UDP

三次握手

1.初始状态：

客户端开始时处于CLOSED状态，表明没有活动的连接。
服务器监听特定端口，处于LISTEN状态，等待连接请求。

步骤	描述	客户端状态	服务器状态
初始状态	客户端处于CLOSED状态，服务器处于LISTEN状态	CLOSED	LISTEN
第一次握手	客户端发送SYN报文，状态变为SYN_SENT	SYN_SENT	LISTEN
第二次握手	服务器发送SYN+ACK报文，状态变为SYN_RECEIVED	SYN_SENT	SYN_RECEIVED
第三次握手	客户端发送ACK报文，状态变为ESTABLISHED	ESTABLISHED	ESTABLISHED

2.第一次握手（SYN_SENT状态）

客户端随机生成一个初始序列号(ISN_c)，并向服务器发送一个SYN标志置位的报文段。这标志着客户端试图建立连接，此时客户端状态变为SYN_SENT，表示客户端正在等待服务器的确认。

3.第二次握手（SYN_RECEIVED状态）

服务器接收到客户端的SYN报文，如果同意连接，会生成自己的初始序列号(ISN_s)，并将ISN_c + 1作为确认号(Acknowledgment Number)包含在回应报文中，同时设置SYN和ACK标志位。服务器状态变为SYN_RECEIVED，表示服务器已发送了SYN+ACK且等待客户端的最后确认。

4.第三次握手（ESTABLISHED状态）

客户端接收到服务器的SYN+ACK报文后，会向服务器发送一个ACK报文作为应答，确认号设置为ISN_s + 1。此时，客户端进入ESTABLISHED状态，表示连接已经建立，可以开始传输数据。服务器在收到这个ACK后，也会进入ESTABLISHED状态。此时，双方以建立起了链接。

序列号(ISN)的动态性：ISN的动态生成是为了防止单纯递增的序列号被预测，增强连接的安全性，防止重放攻击。

数据携带问题：三次握手中，前两次握手主要用于连接的建立和确认，不携带数据以最小化初始连接建立的复杂性，防止恶意利用。第三次握手时，理论上客户端可以携带数据，因为连接已基本建立，但实践中通常不这么做，以减少网络拥塞和重传风险。

半连接队列与全连接队列：这是服务器端的两种队列管理机制，用以应对连接请求的处理压力。半连接队列存储了处于SYN_RECEIVED状态的连接请求，全连接队列则存储了已完成三次握手的连接。队列的大小配置影响着服务器对并发连接的处理能力。

SYN-ACK重传：这一机制体现了TCP的健壮性，通过逐步延长的重传时间间隔，有效平衡了连接建立的效率与资源消耗，防止恶意SYN泛洪攻击。

三次握手的作用

连接的可靠性验证：三次握手过程确保了客户端和服务端双方都具备发送和接收数据的能力。通过这个过程，双方确认了对方的存在并且有能力进行通信，从而建立了可靠的连接基础。
同步序列号：在握手过程中，客户端和服务端都会交换各自的初始序列号（ISN）。这个序列号在后续的数据传输中用于数据包的排序和确认，保证数据包按序到达且无遗漏。
防止旧连接请求的冲击：通过使用不同的ISN，可以防止来自旧连接的迟到数据包干扰新连接。即使旧的数据包在网络中延迟到达，由于其序列号与当前连接的期望不符，会被直接丢弃。
设定通信参数：握手期间，双方还可以协商TCP连接的参数，比如最大报文段大小（MSS），选择性确认（SACK）等选项，为后续的数据传输优化条件。
防止资源浪费：通过三次握手，服务器可以避免为那些无响应的连接请求分配资源。如果客户端没有响应服务器的SYN+ACK，服务器就不会为这个连接分配过多资源。
提供安全性基础：虽然三次握手本身不直接提供加密或身份验证，但它为后续可能的安全措施（如TLS握手）奠定了基础，确保双方准备好进行安全的数据交换。

总之，三次握手是一个精心设计的过程，旨在建立一个稳定、可靠、且双方都已准备好的通信环境，为后续的数据传输打下坚实的基础。

# 四次挥手

四次挥手是TCP连接断开的过程，确保了数据的可靠传输直至连接关闭，具体步骤及状态变迁如下：

步骤	描述	客户端状态	服务器状态
第一次挥手	客户端发送FIN报文，状态变为FIN_WAIT_1	FIN_WAIT_1	ESTABLISHED
第二次挥手	服务器发送ACK报文，状态变为CLOSE_WAIT	FIN_WAIT_1	CLOSE_WAIT
第三次挥手	服务器发送FIN报文，状态变为LAST_ACK	FIN_WAIT_2	LAST_ACK
第四次挥手	客户端发送ACK报文，状态变为TIME_WAIT	TIME_WAIT	CLOSED

1.第一次挥手（客户端发起断开请求）

客户端发送一个FIN报文给服务器，请求关闭连接。报文中会包含一个序列号，表明客户端希望断开连接。此时，客户端进入FIN_WAIT_1状态，等待服务器的确认。

2.第二次挥手（服务器确认客户端请求）

服务器接收到客户端的FIN报文后，会发送一个ACK报文作为应答，确认序列号为客户端FIN报文的序列号加1，表明服务器已收到关闭请求。服务器此时可能还有数据需要发送，因此状态变为CLOSE_WAIT，即等待应用程序关闭连接并完成数据发送。

3.第三次挥手（服务器请求关闭）

当服务器准备好关闭连接时，它会向客户端发送一个FIN报文，请求关闭其方向上的连接。服务器状态变为LAST_ACK，等待客户端的最终确认。

4.第四次挥手（客户端确认服务器请求）：

客户端收到服务器的FIN报文后，发送ACK报文作为响应，确认序列号同样为服务器FIN报文的序列号加1。此时，客户端进入TIME_WAIT状态，等待足够的时间（通常是2倍的最大段生存时间，MSL）以确保服务器收到了ACK，防止最后的ACK丢失而需要重新发送FIN。服务器收到ACK后，关闭连接，进入CLOSED状态。
TIME_WAIT状态的重要性：这一状态是为了确保网络中的延迟报文或者丢失的ACK报文不会引起连接的混淆。如果服务器没有收到最后的ACK，它会重发FIN，而TIME_WAIT状态下的客户端能够重新发送ACK，保证连接的正确关闭。

5.状态简述

LISTEN：服务器等待连接请求。
SYN_SENT：客户端已发送SYN，等待服务器确认。
SYN_RECEIVED：服务器接收到SYN，等待客户端的ACK。
ESTABLISHED：连接建立，数据传输可以进行。
FIN_WAIT_1：客户端已发送FIN，等待服务器的ACK。
FIN_WAIT_2：客户端收到服务器的ACK，等待服务器的FIN。
CLOSE_WAIT：服务器接收到FIN，但还未发送自己的FIN。
CLOSING：客户端接收到服务器的FIN，同时自己的FIN也在路上。
LAST_ACK：服务器已发送FIN，等待客户端的最后ACK。
TIME_WAIT：客户端等待足够时间确保最后的ACK被服务器收到。
CLOSED：连接完全关闭，双方均无状态。

这一过程确保了连接的双方都能明确知道连接何时关闭，且所有数据都被正确传输，无数据丢失。

# POST与GET区别

1.使用场景： GET 用于获取资源，而 POST 用于传输实体主体。

GET 通常用于请求服务器发送某个资源，比如请求一个网页或图片。它适合用于获取数据，不应有副作用。
POST 用于向服务器提交数据，常用于表单提交、上传文件或创建新资源。它可以包含更多的数据，且对数据格式没有限制。

特性	GET	POST
使用场景	获取资源	传输实体主体
参数处理	参数附加在URL中	参数放在请求正文中
安全性	可被浏览器缓存、保存在历史记录中，不安全	不会被浏览器缓存，更安全
幂等性	幂等	不幂等
可缓存	默认可缓存	通常不可缓存
数据量	受URL长度限制（通常不超过2048字符）	无长度限制，适合传输大量数据
敏感信息	不适合传输敏感信息	适合传输敏感信息
XMLHttpRequest与Ajax	同时发送Header和Data	先发送Header再发送Data

2.参数处理：

GET 将参数附加在URL中，作为查询字符串。由于URL长度有限制（通常不超过2048字符），这限制了GET能携带的数据量。
POST 将参数放在请求正文中，因此可以传输大量数据，且不显示在URL中，适合敏感信息的传输。尽管如此，通过网络监控工具仍可能被截获，因此不绝对安全。

3.安全性

GET 请求可被浏览器缓存、保存在浏览历史中，且可能在Referrer头部中暴露给第三方站点。它被认为是安全的，因为它不修改服务器状态。安全的方法除了 GET 之外还有：HEAD、OPTIONS。
POST 的目的是传送实体主体内容，经常用于提交数据到服务器，可能涉及数据的创建或修改，比如向数据库插入一条新的记录，因此具有改变服务器数据或状态的能力。这种潜在的改变状态的特性使得POST不被视为安全方法。。不安全的方法除了 POST 之外还有 PUT、DELETE。

3.幂等性

GET 是幂等的，多次请求具有相同效果，不会产生额外的副作用。
POST 不是幂等的，多次请求可能导致多次资源创建或其他副作用。

4.可缓存

GET 请求默认可被浏览器和代理服务器缓存，除非通过Cache-Control或Expires等头部信息指明不缓存。
POST 请求通常不会被缓存，因为它们可能改变服务器状态。

5.XMLHttpRequest与Ajax

GET 和 POST 都可用于Ajax（异步JavaScript和XML）请求，通过XMLHttpRequest实现。但两者在发送数据的时机上有别：POST先发送Header再发送Data，而GET则同时发送Header和Data，尽管不同浏览器可能有细微差别。

GET和POST各有优势和局限，选择时应考虑数据敏感性、数据量、是否需要幂等性以及缓存需求等因素。GET适合简单数据获取，而POST用于提交数据或执行可能改变服务器状态的操作。

TCP与UDP的区别

TCP与UDP作为传输层的两大协议，各自有着显著的特点和适用场景

特性	TCP	UDP
连接性	面向连接	无连接
可靠性	提供可靠传输	尽最大努力交付
传输模式	面向字节流	面向报文
速度与开销	传输速度较慢，开销较大	传输速度快，开销较小
应用场景	文件传输、网页浏览等	实时音视频通信、在线游戏等
流量控制	支持滑动窗口协议	不支持流量控制
拥塞控制	支持拥塞控制	不支持拥塞控制
多播和广播	不支持多播和广播	支持多播和广播
头部开销	20字节	8字节

TCP协议的主要特点及机制

1.面向连接：TCP连接的建立需要经过三次握手，确保双方都准备好进行数据传输。
2.可靠性：通过序列号、确认应答、重传机制、校验和等策略确保数据可靠传输。
3.流量控制：使用滑动窗口协议，根据接收方的处理能力调整发送速度，避免数据溢出。
4.拥塞控制：通过慢启动、拥塞避免、快速重传和快速恢复等策略动态调整发送速率，以缓解网络拥塞。
5.全双工通信：支持数据的同时发送和接收。
6.面向字节流：TCP将数据视为无边界的字节流，不保留应用层数据的原始边界。

UDP协议的特点

1.无连接：UDP通信不需要预先建立连接，减少了建立连接的开销，但也不保证数据的到达。
2.尽最大努力交付：不保证数据的可靠传输，可能丢包、乱序。
3.面向报文：保持应用层数据的边界，适合一次性传输小数据包。
4.头部开销小：UDP头部仅8字节，相比TCP的20字节头部更轻量。
5.支持多播和广播：TCP基于一对一的连接，而UDP可以实现一对多的通信。

TCP与UDP的区别总结

可靠性：TCP提供可靠传输，UDP不保证数据的可靠到达
连接性：TCP是面向连接的，UDP是无连接的。
传输模式：TCP是面向字节流，UDP是面向报文的。
速度与开销：TCP由于校验、确认等机制，传输速度相对较慢，开销较大；UDP因简单快速，适合对实时性要求高的应用。
应用场景：TCP适用于文件传输、网页浏览等对数据完整性和准确性要求较高的场景；UDP适用于实时音视频通信、在线游戏等对实时性要求高，能容忍少量丢包的场景。

TCP重传机制

机制	描述
超时重传	发送数据后启动定时器，超时未收到确认ACK，重传
快速重传	连续收到三个或更多相同的ACK，立即重传丢失的报文段

超时重传：TCP发送数据后启动定时器，若在规定时间内未收到确认ACK，则认为数据丢失或损坏，进行重传。超时时间动态调整，初试超时后，下次超时时间翻倍，以此类推。
快速重传：接收方收到失序的数据段时，会立即发送重复的ACK，若发送方连续收到三个或更多相同的ACK，无需等待超时，立即重传丢失的报文段。

TCP拥塞控制机制

机制	描述
慢启动	连接建立初期，拥塞窗口(cwnd)逐步增加
拥塞避免	cwnd达到阈值(ssthresh)，转为线性增长
快速重传与快速恢复	快速重传后，ssthresh设为cwnd一半，cwnd重置为1，执行拥塞避免