【网络知识】TCP和UDP详解

TCP和UDP

在这里插入图片描述

文章目录

😊点此到文末惊喜↩︎

UDP协议

概述

TCP协议

概述

定义
- 传输控制协议（TCP，Transmission Control Protocol）是一种传输层通信协议，支持一对一 全双工通信的可靠交付服务，使用以字节为单位的窗口机制，进行流量控制和拥塞控制。
特点
- 只能一对一通信，每条TCP连接只能是双方
- 提供全双工通信，TCP连接两端都有发送和接收缓存
- 提供可靠交付，保证传输的数据是可靠无差错的
- 面向字节流，传送的数据流中每个字节都有序列编号

TCP报文段

报文段格式
格式详解
- 源端口和目的端口：各占2个字节，收发双方的应用进程标识
- 序号seq：占4个字节，以字节为单位给每次TCP连接中传输的数据进行顺序编号，初始值为系统生成的随机数
- 确认号ack：占4个字节，期望收到对方下一个报文段的数据部分的第一个字节序号，这也表明期望收到序号前的字节数据均已收到。（累积确认，只确认有序队列接收的最后一个，而不是每个都确认，有利于降低开销）
- 首部长度（数据偏移）：占2个字节，TCP报文段中TCP首部所占的长度
- 保留字段：占6位。保留为今后使用，但目前应置为0
- 控制位：每一个标志位表示一个控制功能
  - URG：紧急指针标志，为1时表示报文段中有紧急数据，需要配合紧急指针使用
  - ACK：确认序号标志，为1时表示确认号有效，为0表示报文中不含确认信息，忽略确认号字段；
  - PSH：快推送标志，为1表示是带有push标志的数据，指示接收方在接收到该报文段以后，应尽快将这个报文段交给应用程序，而不是在缓冲区排队；
  - RST：重置连接标志，用于重置由于主机崩溃或其他原因而出现错误的连接。或者用于拒绝非法的报文段和拒绝连接请求；
  - SYN：同步标志，用于建立连接过程，在连接请求中，SYN=1和ACK=0表示该数据段没有使用捎带的确认域，而连接应答捎带一个确认，即SYN=1和ACK=1；
  - FIN：finish标志，用于释放连接，为1时表示发送方已经没有数据发送了，即关闭本方数据流。
- 窗口字段：占2个字节，接受方表示的允许对方发送的最大窗口数据量
- 校验和：占2个字节，校验首部和数据两个部分
- 紧急指针：占2个字节，指出紧急数据的大小，约定紧急数据在报文段数据部分首部
- 选项字段：只有SYN =1才有用，表示TCP报文段所允许传送的最大数据部分的长度MSS
- 填充字段：这是为了使整个首部长度是4字节的整数倍。
端口号
- 作用：区分单个设备上的多个应用进程
- 服务端使用的端口号有两类
  - 服务端口号，数值为0~1023，分配给TCP/IP中的重要程序
  - 登记端口号，数值为1024~49151
  - 临时端口号，数值为49152~65535，仅在客户程序运行时才动态进行选择

协议	名称	默认端口	底层协议
HTTP	超文本传输协议	80	TCP
HTTPS	超文本传输安全协议	443	TCP
Telnet	远程登录服务的标准协议	23	TCP
FTP	文件传输协议	20数据端口 21控制端口	TCP
TFTP	简单文件传输协议	69	UDP
SMTP	简单邮件传输协议（发送用）	25	TCP
POP	邮局协议（接收用）	110	TCP
DNS	域名解析服务	53	服务器间进行域传输的时候用TCP 客户端查询DNS服务器时用 UDP

TCP连接的建立

TCP的连接建立是采用C/S方式进行的
三次握手
- 前提：服务器处于监听状态
- 第一次：客户端发送TCP连接请求，并进入同步已发送状态。
  - 客户端初始序列号seq=x，值由客户端随机生成，避免黑客进行序列号预测并绕过检查劫持TCP连接
  - 同步标志SYN=1，表明这是一个握手报文
- 第二次：服务端发送针对TCP连接请求的确认，并进入同步已发送状态。
  - 服务器初始序列号seq=y，值由服务器随机生成
  - 确认号ack=x+1，表示收到了客户端的序列号x之前的数据，希望客户端下次发送的数据从x+1开始。
  - 控制位SYN=1 和 ACK=1。表示这是一个SYN握手和ACK确认应答报文
- 第三次：客户端发送确认的确认。客户端发送对于第二次确认报文的确认（应答报文）
  - 序列号seq=x+1，数据部分首字节在本次TCP连接传输中的序号
  - 确认号ack=y+1 ，表示收到了服务器的y之前的数据，希望服务器下次发送的数据从y+1开始。
  - ACK=1：表示这是一个确认应答报文。
通信双方如何协商TCP的最大报文长度MSS（每次传输数据长度）？
- 前提：
  - MSS值由选项字段携带传送，只有SYN =1该字段才有用
  - MSS = MUT（1500） - IP首部长度（20字节） - TCP首部长度（20字节固定部分）
  - tips：一个标准的以太网的数据帧的大小为1518 ：头部有14个字节，尾部的CRC为4个字节，所以留给上层协议数据的大小为1500字节
- 过程：
  - 第一次握手：告知服务器最大发送数据大小，MSS值在客户端发送的SYN同步报文的选项段中
  - 第二次握手：告知客户端最大发送数据大小，当服务器端收到SYN报文后，会向请求端返回SYN+ACK（同步确认报文）报文，其中的“选项”字段也会有MSS值。
- 结果：
  - 通信双方选择SYN和SYN+ACK报文中最小的MSS作为此次TCP连接的MSS
  - 通信双方的协商，在第二次握手后就可以确定TCP中最大传输报文（MSS）大小
为什么需要三次握手
- 防止服务器连接过时的TCP请求
  - 第一次握手：客户端发送的请求同步SYN报文，因网络拥堵等情况，迟迟没能发送到服务端。那么客户端会发送多次请求同步SYN报文，可能出现后发送SYN 报文比早发送的 SYN 报文 早到达了服务端。
  - 第二次握手：如果服务器收到过去的请求同步SYN报文，无法判断是过去，仍然会发送同步确认SYN + ACK 报文给客户端
  - 第三次握手：客户端收到后判断这是一个过去的连接(序列号过期或超时)，会发送 RST 报文给服务端，中止这一次连接。
- 避免资源浪费
  - 如果只有两次握手，每收到一个 SYN 就只能先主动建立一个连接，如果客户端的SYN报文被网络阻塞了，重复发送多次 SYN 报文，那么服务器在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪费。
SYN攻击
- 原理：SYN攻击属于DoS攻击（Denial of Service 拒绝服务）的一种。通过大量发送伪造源IP的第一次握手同步SYN报文，服务器每接收到一个SYN包就会为这个连接信息分配核心内存并放入半连接队列，当攻击的SYN包超过半连接队列的最大值时，正常的客户发送SYN数据包请求连接就会被服务器丢弃，导致正常的连接请求无法成功。
- 解决方法
  - 限制ip连接次数：比如限制同一IP一分钟内新建立的TCP连接数仅为10
  - 增大半连接状态的连接数容量：但增大内存资源占用，不推荐
  - 延迟分配连接资源：当服务器收到第一次握手请求时，不马上分配TCP连接资源。而是计算一个随机值，在第二次握手时传给客户端，当客户端返回第三次握手时，服务器验证随机值的正确性，确认无误才会进入 TCP 的连接状态，才会分配资源
数据包丢失了该怎么办？
- 第一次握手的 SYN 丢包：重传SYN 数据包，重传次数超过阈值后放弃
- 第二次握手的 SYN+ACK 丢包
  - 客户端 SYN 包没有收到ACK，也会超时重传
  - 服务端 SYN包也没有收到ACK，也会超时重传。
- 第三次握手的 ACK 丢包
  - 服务端会一直重传 SYN、ACK 包，重传次数超过阈值后放弃
  - 客户端：1. 有保活机制会经过 2 小时 11 分 15 秒发现一个死亡连接，于是客户端就会断开连接。2. 无保活机制会一直重传该数据包，直到重传次数超过阈值后就会断开 TCP 连接。
一个已经建立的 TCP 连接中，客户端中途宕机了，客户端恢复后，向服务端发送SYN包重新建立连接，此时服务端会怎么处理？
- TCP 连接是由 $四元组（客户端的 I P 、服务端 I P 、目的端口、源端口）$ 唯一确认的，关键在于本次连接的源端口是否和上一次连接的源端口是否相同
  - 相同：客户端发送同步SYN报文后，收到的同步确认报文序列号错误，客户端会发送RST报文释放连接
  - 不相同：服务端认为是要建立新的TCP连接，会进行三次握手。以前的TCP连接会超时释放或者客户端收到服务端的询问报文而发送RST报文释放连接
如何手动关闭一个TCP连接
- 伪造一个能关闭 TCP 连接的 RST 报文，其中，合法的 RST 报文必须同时满足四元组相同和序列号正好落在对方的滑动窗口内

两天内完成下面的

在这里插入图片描述
为何快速重传是选择3次ACK？

通信双方如何协商TCP分段的大小
二、通信双方如何协商MSS
MSS的值是在TCP三次握手建立连接的过程中，经通信双方协商确定的。我们都知道链路层使用以太网的话，IP层的MTU是1500 byte，这样去掉IP数据报首部（20 byte），在去掉TCP首部（20 byte）后为1460 byte，此时在默认情况下TCP“选项”字段的MSS值为1460 byte = 1500 - 20 - 20。在 Internet 标准中，IP层的MTU是576 byte，那么此时TCP“选项”字段的MSS值为536 byte = 576 - 20 - 20。

什么是数据的正确传输？不丢失，不出错，顺序一致不重复

三次握手四次挥手
为什么是三次
TCP粘包问题
2MSL等待状态？
等待2MSL的意义?
为什么TIME_WAIT状态需要经过2MSL才能返回到CLOSE状态？
#第一种回答
https://blog.csdn.net/ThinkWon/article/details/104903925

建立TCP服务器的各个系统调用过程是怎样的？
TCP 协议如何保证可靠传输？
流量控制：TCP 利用滑动窗口实现流量控制的机制？
拥塞控制
可靠传输
差错控制
了解流量控制原理吗？
UDP
UDP的特点有哪些（
TCP对应的应用层协议

如何区分流量控制和拥塞控制？
流量控制属于通信双方协商；拥塞控制涉及通信链路全局。

流量控制需要通信双方各维护一个发送窗、一个接收窗，对任意一方，接收窗大小由自身决定，发送窗大小由接收方响应的TCP报文段中窗口值确定；拥塞控制的拥塞窗口大小变化由试探性发送一定数据量数据探查网络状况后而自适应调整。

实际最终发送窗口 = min{流控发送窗口，拥塞窗口}。

服务器出现大量close_wait的连接的原因是什么？有什么解决方法？
close_wait状态是在TCP四次挥手的时候收到FIN但是没有发送自己的FIN时出现的，服务器出现大量close_wait状态的原因有两种：

服务器内部业务处理占用了过多时间，都没能处理完业务；或者还有数据需要发送；或者服务器的业务逻辑有问题，没有执行close()方法
服务器的父进程派生出子进程，子进程继承了socket，收到FIN的时候子进程处理但父进程没有处理该信号，导致socket的引用不为0无法回收
处理方法：

停止应用程序
修改程序里的bug

少年，我观你骨骼清奇，颖悟绝伦，必成人中龙凤。秘籍（点击图中书籍）·有缘·赠予你