前端开发之TCP与UDP

上一篇👉: 前端开发之性能优化

TCP与UDP

三次握手

1. 初始状态：

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

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泛洪攻击。

三次握手的作用

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

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

四次挥手

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

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 用于向服务器提交数据，常用于表单提交、上传文件或创建新资源。它可以包含更多的数据，且对数据格式没有限制。

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协议的主要特点及机制

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重传机制

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

TCP拥塞控制机制

• 慢启动：连接建立初期，拥塞窗口(cwnd)从小到大逐步增加，以探测网络拥塞情况，初始cwnd=1，每次收到ACK，cwnd翻倍。
• 拥塞避免：当cwnd达到慢启动阈值(ssthresh)，转为线性增长，每经过一个往返时间(RTT)增加1个MSS（最大报文段大小）。
• 快速重传与快速恢复：快速重传机制触发后，ssthresh设置为当前cwnd的一半，cwnd重置为1，然后执行拥塞避免算法，快速恢复到之前的传输速率。

TCP流量控制

• 滑动窗口：接收方通过在ACK中包含窗口大小信息告知发送方其还能接收多少数据，发送方据此调节发送速率，避免数据溢出接收方缓冲区。当接收方缓冲满时，会发送窗口更新为0的ACK，发送方需暂停发送，等待接收方窗口重新开放。

TCP的可靠传输机制

TCP的可靠传输基于一系列机制，包括：

• 序列号和确认应答：确保数据有序且无丢失。
• 重传机制：未收到确认时，重传数据包。
• 校验和：检查数据在传输过程中是否有误。
• 累积确认：接收方对按序到达的数据进行累积确认，减少确认报文数量。

这些机制共同保障了TCP协议的高可靠性，尽管牺牲了一定的传输效率，但在大多数需要高度可靠性的网络应用中，TCP是首选的传输协议。

下一篇👉: 前端开发之WebSocket通信