【计算机网络】— 认识 TCP和UDP协议 03

目录

一、 UDP

二、 TCP

2.1 TCP的一些特性

2.2 TCP的几种原理​​​​​​​

---

TCP和UDP的对比：

• TCP用于可靠传输的情况，应用于文件传输，重要状态更新等场景；
• UDP用于对高速传输和实时性要求较高的通信领域，例如，早期的QQ，视频传输等。另外UDP可以用于广播；

1.需要可靠性、传输单个数据报比较长（超出64K）-->TCP
2.注重效率  (机房内部的主机通信：网络环境简单、带宽充裕，丢包概率不大)、需要广播  (一个数据同时发送给多个主机)--->UDP

一、 UDP

udp报头8字节，此处的封装：也即是在应用层数据包的基础上+8字节报头，同时代码中的端口号也会被打包到UDP数据报中（报头体现）

 2字节（16位：0-65535，0-64k）,在目前的互联网时代已经不够用了，针对大数据报的传输科技逆行分包（拆分为多个部分），再通过UDP数据报进行发送，最后接收方对收到的子包进行拼接即可。（拆包组包代码复杂，且可能存在数据丢失，更好的操作就是使用TCP协议处理）

校验和：验证网络传输的数据是否正确（网络上传递数据的本质：光信号、电信号），但是校验和不一定能判断数据百分百正确，但是若校验和不正确，数据一定有问题

---

​​​​​​​二、 TCP

2.1 TCP的一些特性

有连接、可靠传输、面向字节流（读写通过字节流方式InputStream、OutputStream）、全双工

 TCP报头变长：4位首部长度表示（4个bit位，0-15），也即是报头长度15*4 => 60

6位标志位:TCP报文段的核心字段：

• URG：紧急指针是否有效
• ACK：确认号是否有效
• PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走
• RST：对方要求重新建立连接；我们把携带RST标识的称为复位报文段
• SYN：请求建立连接；我们把携带SYN标识的称为同步报文段
• FIN：通知对方，本端要关闭了，我们称携带FIN标识的为结束报文段

16位校验和：发送端填充，CRC校验。接收端校验不通过，则认为数据有问题。此处的检验和不
光包含TCP首部，也包含TCP数据部分。

---

TCP的几种原理：

在可靠性的基础上保证效率

• 1.确认应答(ACK)，针对传输数据以字节为单位进行编号
• 2.超时重传(数据丢包)：传输data丢了、ack应答报文丢了(重传产生重复数据会在缓冲区进行去重)超时时间是动态变化的：2^n*500ms(若连续两三次丢包则停止重传)
• -->1.2机制保证可靠性的基本传输
• 3.连接管理(3次握手，4次挥手)--意义-->投石问路，验证当前网络是否通畅，可进行后续的可靠连接。
• 4.滑动窗口：在可靠性基础上提高效率(批量发送多条数据，批量等待ACK)等待很耗时
• 5.流量控制：限制窗口大小(根据接收方处理能力(缓冲区剩余空间))
• 6.拥塞控制：慢启动，窗口大小先指数增长，达到阈值后线性增长
• -----------上面保证可靠性（除开4）------------------
• 7.延迟应答：提高效率(可靠的基础上，让窗口大小尽可能大)--->等待200ms再ack，缓冲区数据处理部分之后,容量变大,再次应答后可扩大传输窗口大小
• 8.捎带应答：延时应答基础上进行
• -----------------4、7、8保证效益-------------------
• 9.面向字节流：
• 10.异常情况：
• 进程终止：(释放对应PCB，触发4次挥手,不代表连接终止，只是调用了socket.close);
• 机器重启：(先杀进程，也即是4次挥手);
• 机器掉电/网线断开：突发情况机器来不及进行任何工作

2.2 TCP的几种原理

(1)确认应答（保障可靠传输的核心机制）

确认应答(ACK)，针对传输数据以字节为单位进行编号

可靠性：发送方发出数据后，能够知道对方是否收到数据（接收方发出一个应答报文ACK给发送方表明自己收到信息）

序号和确认序号用于确认发送和接收的数据是否对应；每一个ACK都带有对应的确认序列号，意思是告诉发送方，已经收到了哪些数据；下一次你从哪里开始发。

（2）超时重传机制（安全机制） 重传为TCP负责发送的

• 主机A发送数据给B之后，可能因为网络拥堵等原因，数据无法到达主机B；
• 如果主机A在一个特定时间间隔内没有收到B发来的确认应答，就会进行重发；
• 连续两次丢包就视为丢包，一般第二次发送是可以成功的，两次都丢失的概率较低
• 若第一次因确认应答ACK丢失，则再次发送时可能导致重复收到两份相同的数据（TCP内部有一个去重操作，OS内核中会有一个”接收缓冲区“（也可视为一个阻塞队列）存放接收到的数据，TCP根据序号判断数据是否在缓冲区里存在，若不存在，则放入二次接收到的数据，若存在，则丢弃二次接收的数据）

等待时间：

TCP为了保证在任何环境下都能比较高性能的通信，会动态计算这个最大超时时间：

• Linux中（BSD Unix和Windows也是如此），超时以500ms为一个单位，每次判定超时重发的超时时间都是500ms的整数倍。
• 重发一次仍然得不到应答，等待 2*500ms 后进行重传；若仍然得不到应答，等待 4*500ms 进行重传。依次类推，以指数形式递增。
• 累计到一定的重传次数，TCP认为网络或者对端主机出现异常，强制关闭连接。（一般两次重传就结束 ）

 （3）连接管理机制（安全机制）三次握手，四次挥手

在正常情况下，TCP要经过三次握手建立连接，四次挥手断开连接。握手由客户端发起，断开双方都可主动发起

 1）三次握手（客户端和服务器之间的交互，3次连接）

三次握手相当于”投石问路“，检查当前网络是否满足可靠性传输的基本条件（若网络本身很差，强行进行TCP传输，也会涉及大量丢包）.  

 SYN：同步报文段（若为1：主机A和主机B之间要建立连接）

ACK：确认应答（若为1：表明是一个确认报文段）

1.LISTEN：当前服务器已经准备就绪，客户端可进行连接

2. ESTABLISHED：连接建立成功，可进行通信了

TCP状态转换的一个汇总：

中间FIN和ack分两次进行(触发机制不一样)：

• ack由os内核决定，收到FIN，内核立即发送ack
• 而再次发送FIN由用户代码决定(调用socket.close)

2）四次挥手

三次握手中间两次（SYN+ACK）可以合并，只要使其都为1即可（SYN+ACK都是由内核负责的）

四次挥手中间两次不一定能合并（接收方B发送的ACK和FIN时机是不同的），FIN为1 是结束报文段。（ACK是内核负责发送的，FIN是用户代码负责（代码调用socket.close()方法，才会触发FIN,））

1.close_wait：收到FIN则等待用户调用socket.close

2.time_wait：主动发起FIN的一方进入的状态，收到FIN并返回ACK之后连接并不能立即销毁，等待对方是否还会重传FIN（防止最后一个次丢包）。设定的等待时间2*MSL（MSL表示网络上任意两点之间传输需要的最大时间），一般为60s

（4）滑动窗口（效率机制）

在保障可靠性的前提下，尽量提高效率。

确认应答策略：对每一个发送的数据段，都要给一个ACK确认应答。收到ACK后再发送
下一个数据段。导致性能较差，尤其是数据往返的时间较长的时候。一发一收的方式性能较低，若一次发送多条数据，就可大大的提高性能（将多个段的等待时间重叠在一起）

滑动窗口机制：一次发送多组数据，只有一次等待时间。

    

• 窗口大小：无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是4000个字节（四个段）。
• 发送前四个段的时候，不需要等待任何ACK，直接发送；
• 收到第一个ACK后，滑动窗口向后移动，继续发送第五个段的数据；依次类推；
• 操作系统内核为了维护这个滑动窗口，需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答；只有确认应答过的数据，才能从缓冲区删掉；
• 窗口越大，则网络的吞吐率就越高； ​​

 在滑动窗口的基础上，若出现丢包如何处理，如何重传？？
情况一：数据包已经抵达，ACK被丢了。

情况二：数据包就直接丢了。

1）情况一：数据包已经抵达，ACK被丢了。

 ACk的确认序号的特定含义：可以后一条ACK可以涵盖前一条（即收到了2001确认应答序号，表明1-2000的数据都收到了，即使没收到1001确认应答序号也不影响）

故部分ACK丢了并不要紧，因为可以通过后续的ACK进行确认；

2）情况二：数据包就直接丢了（3次之后重传丢失的数据段）

"高速重发控制"（也叫 "快重传"）。效率较高

丢失1001-2000的数据：

• 当某一段报文段丢失之后，发送端会一直收到 1001 这样的ACK，提醒发送端需要发送10001-2000的数据。
• 如果发送端主机连续三次收到了同样一个 "1001" 这样的应答，就会将对应的数据 1001 -2000 重新发送；
• 这个时候接收端收到了 1001 之后，再次返回的ACK就是7001了（因为2001 - 7000）接收端之前已经收到，被放到了接收端操作系统内核的接收缓冲区中；

（5）流量控制（安全机制）——窗口越大，效率越高

接收端处理数据的速度是有限的。如果发送端发的太快，导致接收端的缓冲区被打满，继续发送则会丢包。 继而引起丢包重传等等一系列连锁反应。因此，TCP支持根据接收端的处理能力，来决定发送端的发送速度。这个机制就叫做流量控制（FlowControl）；

• 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 "窗口大小" 字段，通过ACK端通知发送端；
• 窗口大小字段越大，说明网络的吞吐量越高；
• 接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端；
• 发送端接受到这个窗口之后，就会减慢自己的发送速度；
• 如果接收端缓冲区满了，就会将窗口置为0；这时发送方不再发送数据，但是需要定期发送
• 一个窗口探测数据段，使接收端把窗口大小告诉发送端。

若接收端B反馈的窗口大小为0时，发送端也不能完全不发数据，需要定期发送一个探测报文（不传输数据，只是触发ACK，获取当前窗口的大小是多少）

 （6）拥塞控制（滑动窗口的延伸，限制滑动窗口发送的速率）

TCP有了滑动窗口这个大杀器，能够高效可靠的发送大量的数据。但是如果在刚开始阶段就发送大
量的数据，仍然可能引发问题。故TCP引入 慢启动 机制（前期窗口大小呈指数增长（开始时设置窗口小，试探性的探查接收端缓冲区大小），到达慢启动阈值后变为线性增长），先发少量的数据，摸清当前的网络拥堵状态，再决定按照多大的速度传输数据；拥塞控制衡量得失，发送方到接收方之间拥堵的情况（处理能力）

•  当TCP开始启动的时候，慢启动阈值等于窗口最大值；
• 在每次超时重发的时候，慢启动阈值会变成原来的一半，同时拥塞窗口置回1；

少量的丢包，我们仅仅是触发超时重传；大量的丢包，我们就认为网络拥塞；当TCP通信开始后，网络吞吐量会逐渐上升；随着网络发生拥堵，吞吐量会立刻下降；

（7）延迟应答（效率机制）

在流量控制的基础上，尽量使窗口变得大一点。

• 假设接收端缓冲区为1M。一次收到了500K的数据；若立刻应答，返回的窗口就是500K；
• 但实际上可能处理端处理的速度很快，10ms之内就把500K数据从缓冲区消费掉了，此时可以延迟10ms，再应答，返回的窗口大小就是1M

窗口越大，网络吞吐量就越大，传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率；

延迟应答分为：
数量限制：每隔N个包就应答一次；
时间限制：超过最大延迟时间就应答一次；

具体的数量和超时时间，依操作系统不同也有差异；一般N取2，超时时间取200ms；

（8）捎带应答（效率机制）（可以把4次挥手变为3次）

客户端和服务器之间的通信的模型：

• 一问一答：客户端发出一个请求，服务器返回一个响应（最常见）
• 多问一答：上传文件
• 多问多答：直播、串流...

 对于捎带应答，ACK和数据已经合在一起了，若ACK丢失，则数据也是丢失的。

（9）面向字节流  ==> 粘包问题

TCP粘包的粘指的是：应用层的数据报，再TCP接收缓冲区中，若干个应用层数据包混在一起了，分不出来。

• TCP的协议头中，没有像UDP一样的 "报文长度" 这样的字段，但是有一个序号这样的字段。
• 传输层的角度：TCP是一个一个报文过来的。按照序号排好序放在缓冲区中。
• 应用层的角度：看到的只是一串连续的字节数据。
• 那么应用程序看到了这么一连串的字节数据，就不知道从哪个部分开始到哪个部分，是一个完整的应用层数据包。

如何避免粘包问题？？？明确两个包之间的边界

1. 定长的包：保证每次都按固定大小读取即可；如固定大小的Request结构，就从缓冲区从头开始按sizeof（Request）依次读取即可；
2. 变长的包：可以在包头的位置，约定一个包总长度的字段，从而就知道了包的结束位置；
3. 对于变长的包，还可以在包和包之间使用明确的分隔符（应用层协议，是程序猿自己来定的，只要保证分隔符不和正文冲突即可）；

使用一些库和框架来完成网络通信，粘包问题已经被处理了，若是自己实现库和框架就需考虑粘包问题。

（10）TCP异常情况处理

• 进程终止：直接杀死进程，PCB就没了，文件描述符表也没有了。和正常关闭没有什么区别。
• 机器关机：操作系统会关闭所有进程，然后再关机
• 机器掉电/网线断开：接收端认为连接还在，一旦接收端有写入操作，接收端发现连接已经不在了，就会进行reset。即使没有写入操作，TCP自己也内置了一个保活定时器，会定期询问对方是否还在。如果对方不在，也会把连接释放。