传输层 - TCP / UDP 协议详解

网络传输：设计协议要考虑两个因素（效率，安全）

1、UDP协议：

UDP协议端格式：

UDP的特性：

• （1）无连接：没有建立连接就发数据
• （2）不可靠：没有类似TCP保证数据传输的机制（连接管理机制、确认应答机制、超时机制）（效率更高）
• （3）面向数据报：只能一次接收（系统级别的操作：调用系统函数）
• （4）没有发送缓冲区（发了消息就不管了），有接收缓存区
• （5）数据最大64K

2、TCP协议：

TCP全称为 “传输控制协议(Transmission Control Protocol”). 义如其名, 要对数据的传输进行一个详细的控制;

（1）TCP协议段格式：

• 源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去;
• URG: 紧急指针是否有效
• ACK: 确认号是否有效
• PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走
• RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
• SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段
• FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段
• 16位校验和: 发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部, 也包含TCP数据部分.
• 16位紧急指针: 标识哪部分数据是紧急数据;

（2）确认应答（ACK）机制

• （1）保证安全：我发送的消息，对方必须确认并回复
• （2）保证多条数据确认消息的安全（序号+确认序号）
  发送时：携带数据序号
  确认回复时：携带确认序号

（3）超时重传机制：

如果主机A在一个特定时间间隔内没有收到发来的确认应答，就会进行重发

没有收到确认应答的情况：
1、数据报丢了
2、ack确认应答数据丢了

超时时间如何确定？

一直收不到ack，超时时间会如何设置？

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

（4）连接管理机制（三次握手、四次挥手）

短连接（建立连接发完数据就关闭连接）

1）建立连接（三次握手）

三次握手的流程：

• 1、客户端请求建立连接，向服务端发送一个同步报文（SYN=1），同时选择一个随机数 seq = x 作为初始序列号，并进入SYN_SENT状态，等待服务器确认。
• 2、服务端收到连接请求报文后，如果同意建立连接，则向客户端发送同步确认报文（SYN=1，ACK=1），确认号为 ack = x + 1，同时选择一个随机数 seq = y 作为初始序列号，此时服务器进入SYN_RECV状态。
• 3、客户端回复第2步 syn 的 ack。客户端状态为 established，建立A到B的连接
  服务器接收到第3步的数据报，建立B到A的连接。服务器状态设置为established
  确认号为 ack = y + 1，序列号为 seq = x + 1

握手过程中的相关问题：

1、为什么需要三次握手，而不是两次？

• （1）防止已过期的连接请求报文突然又传送到服务器，因而产生错误和资源浪费。
• （2）确定双方均具备接受发数据的能力
• （3）告知对方自己的初始序号值，并确认收到对方的初始序号值。

2、为什么要三次握手，而不是四次？

• 因为三次握手已经可以确认双方的发送接收能力正常，双方都知道彼此已经准备好，而且也可以完成对双方初始序号值得确认，也就无需再第四次握手了。

3、什么是 SYN洪泛攻击？如何防范？

• SYN洪泛攻击属于 DOS 攻击的一种，它利用 TCP 协议缺陷，通过发送大量的半连接请求，耗费 CPU 和内存资源。
• 原理：
  • 在三次握手过程中，服务器发送 [SYN/ACK] 包（第二个包）之后、收到客户端的 [ACK] 包（第三个包）之前的 TCP 连接称为半连接（half-open connect），此时服务器处于 SYN_RECV（等待客户端响应）状态。如果接收到客户端的 [ACK]，则 TCP 连接成功，如果未接受到，则会不断重发请求直至成功。
  • SYN 攻击的攻击者在短时间内伪造大量不存在的 IP 地址，向服务器不断地发送 [SYN] 包，服务器回复 [SYN/ACK] 包，并等待客户的确认。由于源地址是不存在的，服务器需要不断的重发直至超时。
  • 这些伪造的 [SYN] 包将长时间占用未连接队列，影响了正常的 SYN，导致目标系统运行缓慢、网络堵塞甚至系统瘫痪。
• 检测：当在服务器上看到大量的半连接状态时，特别是源 IP 地址是随机的，基本上可以断定这是一次 SYN 攻击。
• 防范：
  • 通过防火墙、路由器等过滤网关防护。
  • 通过加固 TCP/IP 协议栈防范，如增加最大半连接数，缩短超时时间。
  • SYN cookies技术。SYN Cookies 是对 TCP 服务器端的三次握手做一些修改，专门用来防范 SYN 洪泛攻击的一种手段。

4、三次握手连接阶段，最后一次ACK包丢失，会发生什么？

• 服务端：
  第三次的ACK在网络中丢失，那么服务端该TCP连接的状态为SYN_RECV,并且会根据 TCP的超时重传机制，会等待3秒、6秒、12秒后重新发送SYN+ACK包，以便客户端重新发送ACK包。
  如果重发指定次数之后，仍然未收到 客户端的ACK应答，那么一段时间后，服务端自动关闭这个连接。
• 客户端：
  客户端认为这个连接已经建立，如果客户端向服务端发送数据，服务端将以RST包（Reset，标示复位，用于异常的关闭连接）响应。此时，客户端知道第三次握手失败。

2）关闭连接（四次挥手）

四次挥手的流程：

• 1、主机A发送 fin 到主机B，请求关闭 a 到 b 的连接
• 2、主机B回复 ack，主机B状态置为 close_wait
• 3、主机B发送 fin 到主机A，请求关闭 b 到 a 的连接
• 4、主机A回复 ack（第3步的 fin），状态置为 time_wait
  主机B接收到第4步的数据报，状态置为 closed
  主机A经过2msl（超时等待时间）之后，状态置为 closed

挥手过程中的相关问题：

1、为什么连接的时候是三次握手，关闭的时候却是四次握手？

• 第2步是 TCP协议在系统内核实现的，自动响应的ack。第3步是应用程序手动调用 close 来关闭连接
  程序在关闭连接之前，可能需要执行释放资源等前置操作，所以不能合并

2、为什么客户端的 TIME-WAIT 状态必须等待 2MSL ？

（MSL：报文最大生存时间）

• 确保 ACK 报文能够到达服务端，从而使服务端正常关闭连接。
• 防止已失效的连接请求报文段出现在之后的连接中。
• 为什么是2：客户端接收到 FIN 后发送 ACK 开始计时的。如果在 TIME-WAIT 时间内，因为客户端的 ACK 没有传输到服务端，客户端又接收到了服务端重发的 FIN 报文，那么 2MSL 时间将重新计时。
  比如如果服务端没有收到断开连接的最后的 ACK 报文，就会触发超时重发 FIN 报文，客户端接收到 FIN 后，会重发 ACK 给服务端， 一来一去正好 2 个 MSL。

3、服务器出现大量的 close_wait 状态，是啥原因 ？

• 服务端没有正确的关闭连接（程序没有调用 close，或没正确调用）

（5）滑动窗口：

① 滑动窗口 的概念：

为什么要引入 滑动窗口？
在确认应答机制下：

既然这样一发一收的方式性能较低, 那么我们一次发送多条数据, 就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了).

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

② 滑动窗口 丢包情况：

这种情况下, 部分ACK丢了并不要紧, 因为可以通过后续的ACK进行确认;

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

这种机制被称为 “高速重发控制”(也叫 “快重传”).

③ 滑动窗口 相关问题：

• 1、窗口大小：无需等待确认应答而可以继续发送数据的最大值
  如何确定窗口大小：由 拥塞窗口 和 流量窗口 决定（滑动窗口大小 = min（拥塞窗口大小，流量控制 窗口大小））

• 2、如何滑动？
  依赖 ack 的确认序号（ack 确认序号前的数据包都已经接收到了），在该次 ack 确认序号之前，当前并行接收到多少个数据包，就可以滑动多少

• （3）发送端为什么要有 发送缓冲区：记录已发送的数据（收到对应 ack，才可以清理数据）
  接收端为什么要由 接收缓冲区：记录已接收的数据（如果发送数据丢包，才知道让对方重发）

（6）流量控制：（接收端）

接收端 接收能力 是 有限 的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送, 就会造成丢包, 继而引起丢包重传等等一系列连锁反应.

因此TCP支持根据 接收端 的处理能力, 来决定 发送端 的发送速度. 这个机制就叫做 流量控制

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

流量控制 如何保证接收数据安全？
接收端使用流量控制窗口，告诉发送端后，影响发送端滑动窗口大小

（7）拥塞控制：（发送端）

发送端 网络状况不明的情况下，贸然发送大量的数据报，会造成网络拥堵

TCP引入 慢启动 机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据;

• 此处引入一个概念程为 拥塞窗口
• 发送开始的时候, 定义拥塞窗口大小为1;
• 每次收到一个ACK应答, 拥塞窗口加1;
• 每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口;

像上面这样的拥塞窗口增长速度, 是指数级别的. “慢启动” 只是指初使时慢, 但是增长速度非常快.

• 为了不增长的那么快, 因此不能使拥塞窗口单纯的加倍.
• 此处引入一个叫做慢启动的 阈值
• 当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长

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

（8）延迟应答：

如果接收数据的主机立刻返回ACK应答, 这时候返回的窗口可能比较小.（接收缓冲区空余空间会较小）
( 电脑配置好，处理速度快 )

• 假设接收端缓冲区为1M. 一次收到了500K的数据; 如果立刻应答, 返回的窗口就是500K;
• 但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了;
• 在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来;
• 如果接收端稍微等一会再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M;
• 解决思路：稍等一段时间，让接收端程序接收处理缓冲区数据在返回 ack

一定要记得, 窗口越大 , 网络 吞吐量就越大 , 传输 效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率;

那么所有的包都可以延迟应答么? 肯定也不是;

• 数量限制: 每隔N个包就应答一次;
• 时间限制: 超过最大延迟时间就应答一次;

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

（9）捎带应答：

在延迟应答的基础上, 我们发现, 很多情况下, 客户端服务器在应用层也是 “一发一收” 的. 意味着客户端给服务器说了 “How are you”, 服务器也会给客户端回一个 “Fine, thank you”;

那么这个时候ACK就可以搭顺风车, 和服务器回应的 “Fine, thank you” 一起回给客户端

（接收端响应 ack，和主动发送的数据，可以合并返回）

（10）五元组（源IP、源端口号、目的IP、目的端口号、协议号）

（1）在TCP/IP协议中, 用 “源IP”, “源端口号”, “目的IP”, “目的端口号”, “协议号” 这样一个 五元组 来 标识一个通信

• IP ： 标识主机（给人用）
  - 源IP：发送数据的主机
  - 目的IP：接收数据的主机
• 端口号： 标识某个主机进程
  - 源端口：标识发送数据的进程
  - 目的端口：接收数据的进程
• 协议号： 进程要封装、解析数据报的数据格式

（2）端口号范围划分：

• 0 - 1023: 知名端口号, HTTP, FTP, SSH等这些广为使用的应用层协议, 他们的端口号都是固定的.
• 1024 - 65535: 操作系统动态分配的端口号. 客户端程序的端口号, 就是由操作系统从这个范围分配的

知名端口号：

• ssh服务器, 使用22端口
• ftp服务器, 使用21端口
• telnet服务器, 使用23端口
• http服务器, 使用80端口
• https服务器, 使用443

3、总结：

（1）TCP 和 UDP 的区别：

UDP 的特性：

• （1）无连接：没有建立连接就发数据
• （2）不可靠：没有类似TCP保证数据传输的机制（连接管理机制、确认应答机制、超时机制）（效率更高）
• （3）面向数据报：只能一次接收（系统级别的操作：调用系统函数）
• （4）没有发送缓冲区（发了消息就不管了），有接收缓存区
• （5）数据最大64K

TCP 特性：

• （1）有连接的可靠协议
• （2）可靠（安全）：确认应答、超时重传、连接管理、流量控制、拥塞控制
• （3）提高性能（效率）：滑动窗口 / 快速重传、延迟应答、捎带应答
• （4）面向字节流
• （5）缓冲区：同时存在发送缓冲区、接收缓冲区
• （6）大小：没有限制

（2）粘包问题：

基于传输层 TCP 来实现应用层协议时，因为 TCP 时基于字节流，读取时需要考虑格式，包括读取多长，如果读取格式不对，或长度没设置好，会出现粘包问题

• 首先要明确, 粘包问题中的 “包” , 是指的应用层的数据包.
• 在TCP的协议头中, 没有如同UDP一样的 “报文长度” 这样的字段, 但是有一个序号这样的字段.
• 站在传输层的角度, TCP是一个一个报文过来的. 按照序号排好序放在缓冲区中.
• 站在应用层的角度, 看到的只是一串连续的字节数据.
• 那么应用程序看到了这么一连串的字节数据, 就不知道从哪个部分开始到哪个部分, 是一个完整的应用层数据包.

如何解决： 明确包之间的边界

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

（3）用 UDP 实现可靠传输（经典面试题）

参考 TCP 的可靠性机制，在应用层实现类似的逻辑