大家都在问的网络协议——UDP和TCP

一、UDP

1.UDP报头

16位源端口号：发送端的端口号
16位目的端口号：接收端的端口号
16位UDP长度：数据报总长度（UDP首部+UDP数据）
16位UDP检验和：如果检验和出错，就会直接丢弃

2. UDP的特点

UDP传输的过程类似于寄信。

1. 无连接：知道对端的IP和端口号就直接进行传输，不需要建立连接。
2. 不可靠：没有确认机制，没有重传机制；如果因为网络故障该段无法发送到对方，UDP协议层也不会给应用层返回任何错误 信息；
3. 面向数据报：不能够灵活的控制读写数据的次数和数量；

3. 面向数据报

应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并；
用UDP传输100个字节的数据：
如果发送端调用一次sendto, 发送100个字节, 那么接收端也必须调用对应的一次recvfrom, 接收100个字节; 而不能循环调用10次recvfrom，每次接收10个字节。

4. UDP的缓冲区

1. UDP没有真正意义上的发送缓冲区. 调用sendto会直接交给内核, 由内核将数据传给网络层协议进行后续的传输动作；
2. UDP具有接收缓冲区. 但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致; 如果缓冲区满了,再到达的UDP数据就会被丢弃。
3. UDP的socket既能读, 也能写, 这个概念叫做 全双工

5. UDP使用注意事项

我们注意到, UDP协议首部中有一个16位的最大长度. 也就是说一个UDP能传输的数据最大长度是64K(包含UDP首部)。
然而64K在当今的互联网环境下, 是一个非常小的数字.
如果我们需要传输的数据超过64K, 就需要在应用层手动的分包, 多次发送, 并在接收端手动拼装。

6. 基于UDP协议的应用层协议

1. NFS: 网络文件系统
2. TFTP: 简单文件传输协议
3. DHCP: 动态主机配置协议
4. BOOTP: 启动协议(用于无盘设备启动)
5. DNS: 域名解析协议

当然, 也包括你自己写UDP程序时自定义的应用层协议;

二、TCP

1.TCP报头

16位源端口号：发送端的端口号
16位目的端口号：接收端的端口号
4位TCP报头长度: 表示该TCP头部有多少个32位bit(有多少个4字节); 所以TCP头部最大长度是15 * 4 = 60
16位窗口大小：填“自己”的接受缓冲区大小。
6位标志位
URG: 紧急指针是否有效
ACK: 确认号是否有效
PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走
RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段
FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段
16位校验和: 发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部, 也
包含TCP数据部分.
16位紧急指针: 标识哪部分数据是紧急数据;

32位序号和32位确认序号

TCP为了确保可靠性，引进了序号和确认序号的概念。
在互联网通信中，没有绝对的可靠性。每次发送数据，必须收到数据接受方发来的确认才能保证数据送达。而这样，总会有一条最新的数据没办法确认。
TCP在确保可靠性时，只要收到了对方的应答，就认为之前的数据对方已经收到。
当每次发多条数据时，我们不能保证第一个数据会第一个到达，所以才有了序号。
32位的序号：
客户端->服务器 服务器->客户端 为了保证数据的准确，给每次的数据带上序号，这样就可以使得收到的数据按序到达。
32位确认序号
因为有序号，每次发送数据时，会将当前的数据序号也一同发出，这时候我们在进行数据确认时，需要将确认序号设置为序号+1。这样保证了刚才发的数据我已经收到。

2. 超时重传机制

超时重传机制会有两种情况产生：

当数据由主机A发出后如果因网络拥堵等原因丢失的话，该数据将无法到达主机B。此时，如果主机A在一个特定时间间隔内都未收到主机B发来的确认应答，将会对此数据进行重发。

由主机B返回的确认应答，因网络拥堵等原因在传送的途中丢失，没有到达主机A。主机A会等待一段时间，若在特定的时间间隔内始终未能收到这个确认应答，主机A会对此数据的确认应答。由于主机B其实已经收到过1-1000的数据，当再有相同数据送达时他会放弃。
那么，我们怎么确定超时的时间

1. 最理想的情况下, 找到一个最小的时间, 保证 “确认应答一定能在这个时间内返回”.
2. 但是这个时间的长短, 随着网络环境的不同, 是有差异的.
3. 如果超时时间设的太长, 会影响整体的重传效率;
4. 如果超时时间设的太短, 有可能会频繁发送重复的包;

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

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

3. 连接管理机制

（1）如何理解链接

1. 链接本身是有成本的：空间加时间。
2. TCP面向链接：3次握手成功，意味着客户端和服务器都要维护链接。

（2）三次握手

三次挥手：客户端给服务器发送SYN报文进行连接请求，服务器返回SYN+ACK报文进行连接回复，客户端再回复ACK报文实现TCP连接建立。
为什么要有或者说为什么会是3次握手？
当进行1次或者2次握手链接时，容易受到syn洪水攻击。
为什么3次握手行？

1. 最小成本验证全双工
2. 让服务器不要出现链接建立的误判情况，减少服务器的资源浪费。

（3）四次挥手

四次挥手：客户端给服务器发送FIN报文进行断开连接请求，服务器回复ACK报文同意该请求，此时客户端向服务器的连接断开；然后服务器给客户端发送FIN报文进行断开链接请求，客户端回复ACK报文，此时服务器向客户端的连接断开。
因为断开链接是双方的，并且TCP是全双工的，所以要进行4次挥手。

（4）链接实质

服务端状态转化:

1. [CLOSED -> LISTEN] 服务器端调用listen后进入LISTEN状态, 等待客户端连接;
2. [LISTEN -> SYN_RCVD] 一旦监听到连接请求(同步报文段), 就将该连接放入内核等待队列中, 并向客户端发送SYN确认报文.
3. [SYN_RCVD -> ESTABLISHED] 服务端一旦收到客户端的确认报文, 就进入ESTABLISHED状态, 可以进行读写数据了.
4. [ESTABLISHED -> CLOSE_WAIT] 当客户端主动关闭连接(调用close), 服务器会收到结束报文段, 服务器返回确认报文段并进入CLOSE_WAIT;
5. [CLOSE_WAIT -> LAST_ACK] 进入CLOSE_WAIT后说明服务器准备关闭连接(需要处理完之前的数据); 当服务器真正调用close关闭连接时, 会向客户端发送FIN, 此时服务器进入LAST_ACK状态, 等待最后一个ACK到来(这个ACK是客户端确认收到了FIN)
6. [LAST_ACK -> CLOSED] 服务器收到了对FIN的ACK, 彻底关闭连接

客户端状态转化:

1. [CLOSED -> SYN_SENT] 客户端调用connect, 发送同步报文段
2. [SYN_SENT -> ESTABLISHED] connect调用成功, 则进入ESTABLISHED状态, 开始读写数据;
3. [ESTABLISHED -> FIN_WAIT_1] 客户端主动调用close时, 向服务器发送结束报文段, 同时进入
   FIN_WAIT_1;
4. [FIN_WAIT_1 -> FIN_WAIT_2] 客户端收到服务器对结束报文段的确认, 则进入FIN_WAIT_2, 开始等待服务器的结束报文段;
5. [FIN_WAIT_2 -> TIME_WAIT] 客户端收到服务器发来的结束报文段, 进入TIME_WAIT, 并发出LAST_ACK;
6. [TIME_WAIT -> CLOSED] 客户端要等待一个2MSL(Max Segment Life, 报文最大生存时间)的时间, 才会进入CLOSED状态

4. 滑动窗口

刚才我们讨论了确认应答策略, 对每一个发送的数据段, 都要给一个ACK确认应答. 收到ACK后再发送下一个数据段.这样做有一个比较大的缺点, 就是性能较差. 尤其是数据往返的时间较长的时候.

为每个数据包进行确认应答的缺点是，包的往返时间越长，网络的吞吐量会越差。

根据窗口为4000字节时返回的确认应答，下一步就发送比这个值还要大4000个序列号为止的数据。这跟前面每个段接收确认应答以后再发送另一个新段的情况相比，即使往返时间变长也不会影响网路的吞吐量。

那么如果出现了丢包, 如何进行重传? 这里分两种情况讨论

情况1：

窗口在一定程度较大时，即使有少部分的确认应答丢失也不会进行数据重传。可以通过下一个确认应答进行确认。

接收端在没有收到自己所期望序号的数据时，会对之前收到的数据进行确认应答。发送端则一旦收到某个确认应答后，又连续三次收到同样的确认应答后，又连续三次收到同样的确认应答，则认为数据段已经丢失，则需要进行重发。这种机制比起超时机制可以提供更快速的重发服务。
这种机制被称为 “高速重发控制”(也叫 “快重传”)

5. 流量控制

接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送,就会造成丢包, 继而引起丢包重传等等一系列连锁反应.
因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制(Flow Control)

1. 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段, 通过ACK端通知发送端;
2. 窗口大小字段越大, 说明网络的吞吐量越高;
3. 接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;
4. 发送端接受到这个窗口之后, 就会减慢自己的发送速度;
5. 如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端
   
   发送端主机根据接收端主机的窗口大小通知进行流量控制。由此也可以防止发送端主机一次发送过大数据导致接受端主机无法处理的情况发生。

6. 拥塞控制

虽然TCP有了滑动窗口这个大杀器, 能够高效可靠的发送大量的数据. 但是如果在刚开始阶段就发送大量的数据, 仍然可能引发问题.
因为网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵. 在不清楚当前网络状态下, 贸然发送大量的数据,是很有可能引起雪上加霜的.
TCP引入 慢启动 机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据;

最初发送端的窗口（拥塞窗口）设置为1.每收到一个确认应答，窗口的值会增加1个段。
像上面这样的拥塞窗口增长速度, 是指数级别的. “慢启动” 只是指初使时慢, 但是增长速度非常快

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

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

少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为网络拥塞;
当TCP通信开始后, 网络吞吐量会逐渐上升; 随着网络发生拥堵, 吞吐量会立刻下降;
拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案.
TCP拥塞控制这样的过程, 就好像 热恋的感觉。

7. 延迟应答

如果接收数据的主机立刻返回ACK应答, 这时候返回的窗口可能比较小.

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

一定要记得, 窗口越大, 网络吞吐量就越大, 传输效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率;
那么所有的包都可以延迟应答么? 肯定也不是;

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

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

每收到两个数据段发送一次的确认应答。不过，等待0.2秒以后没有其他数据包到达的情况下才会发送确认应答。

8. 捎带应答

在延迟应答的基础上, 我们发现, 很多情况下, 客户端服务器在应用层也是 “一发一收” 的. 意味着客户端给服务器说了 “How are you”, 服务器也会给客户端回一个 “Fine, thank you”;
那么这个时候ACK就可以搭顺风车, 和服务器回应的 “Fine, thank you” 一起回给客户端

捎带应答是指同一个TCP包中既发送数据又发送确认应答的一种机制。由此，网络的利用率会提高，计算机的负荷也会减轻。不过，确认应答必须得等到应用处理完数据并将作为回执的数据返回为止，才能进行捎带应答。

9. 面向字节流

创建一个TCP的socket, 同时在内核中创建一个 发送缓冲区 和一个接收缓冲区;

1. 调用write时, 数据会先写入发送缓冲区中;
2. 如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;
3. 如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;
4. 接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;
5. 然后应用程序可以调用read从接收缓冲区拿数据;
6. 另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做 全双工

由于缓冲区的存在, TCP程序的读和写不需要一一匹配, 例如:

1. 写100个字节数据时, 可以调用一次write写100个字节, 也可以调用100次write, 每次写一个字节;
2. 读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100个字节, 也可以一次read一个字节, 重复100次;

10. 粘包问题

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

那么如何避免粘包问题呢? 归根结底就是一句话, 明确两个包之间的边界.

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

思考: 对于UDP协议来说, 是否也存在 “粘包问题” 呢?

1. 对于UDP, 如果还没有上层交付数据, UDP的报文长度仍然在. 同时, UDP是一个一个把数据交付给应用
   层. 就有很明确的数据边界.
2. 站在应用层的站在应用层的角度, 使用UDP的时候, 要么收到完整的UDP报文, 要么不收. 不会出现"半 个"的情况

11. TCP异常情况

1. 进程终止: 进程终止会释放文件描述符, 仍然可以发送FIN. 和正常关闭没有什么区别.
2. 机器重启: 和进程终止的情况相同.
3. 机器掉电/网线断开: 接收端认为连接还在, 一旦接收端有写入操作, 接收端发现连接已经不在了, 就会进行reset. 即使没有写入操作, TCP自己也内置了一个保活定时器, 会定期询问对方是否还在. 如果对方不在, 也会把连接释放.
4. 另外, 应用层的某些协议, 也有一些这样的检测机制. 例如HTTP长连接中, 也会定期检测对方的状态. 例如QQ, 在QQ断线之后, 也会定期尝试重新连接.

12. 基于TCP应用层协议

HTTP
HTTPS
SSH
Telnet
FTP
SMTP
当然, 也包括你自己写TCP程序时自定义的应用层协议

三、TCP/UDP对比

我们说了TCP是可靠连接, 那么是不是TCP一定就优于UDP呢? TCP和UDP之间的优点和缺点, 不能简单, 绝对的进行比较

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

归根结底, TCP和UDP都是程序员的工具, 什么时机用, 具体怎么用, 还是要根据具体的需求场景去判定.