TCP和UDP区别

TCP和UDP都是传输层协议，但是两者具有不同的特性和应用场景

	TCP	UDP
可靠性	可靠	不可靠
连接性	面向连接	面向无连接
报文	面向字节流	面向报文
效率	低	高
双工性	全双工	一对一、一对多、多对一、多对多
流量控制	滑动窗口	无
拥塞控制	慢开始、拥塞避免、快重传、快恢复	无
传输速度	慢	快
应用场景	对效率要求低，对准确度要求高或者要求有连接的场景。比如：电子邮件(SMTP)、万维网(HTTP)、文件传输(FTP)	对效率要求高，对准确度要求低的场景。比如：域名转换(DNS)、远程文件服务器(NFS)

名词解释：

 1. 面向报文和面向字节流

面向报文的传输方式就是应用层交给UDP多长的报文，UDP就发送多长的报文，即一次发送一个报文。因此应用程序必须选择大小合适的报文。报文太长，则IP层需要分片，降低效率。

面向字节流的传输方式是应用程序和TCP的交互式一次一个数据块（大小不等），TCP把这些数据块看成是一连串无结构的字节流。TCP有一个缓冲，当应用程序传送的数据块太长，TCP就会把它分割成多块进行传送。

2. 双工性

全双工：是指在发送数据的同时也能接受数据。TCP中既有发送缓冲区也有接受缓冲区。

半双工：一个时间段内只有一个动作发生。只能发数据或接收数据。

UDP

• 报头 
  

UDP数据报最大长度64K（包含UDP首部），如果数据长度超过64K就需要在应用层手动分包，UDP无法保证包序，需要在应用层进行编号。

特点

• 无连接：知道对端的IP和端口号就直接进行传输, 不需要建立连接。
• 不可靠：没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方, UDP协议层也不会给应用层返回任何错误信息。
• 面向数据报：不能够灵活的控制读写数据的次数和数量，应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并。
• 数据收不够灵活，但是能够明确区分两个数据包，避免粘包问题。

协议：

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

TCP

• 报头 
  

源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去;
32位序号/32位确认号: 不一定从0开始（作用：保证确认应答；保证数据按序到达；去重）
4位TCP报头长度: 表示该TCP头部有多少个32位bit(有多少个4字节); 所以TCP报头最大长度是15 * 4 = 60 字节
6位标志位:
    1. URG: 紧急指针是否有效
    2. ACK: 确认号是否有效
    3. PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走
    4. RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
    5. SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段
    6. FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段
16位窗口大小: 接收缓冲区剩余的空间大小 
16位校验和: 发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP 首部, 也包含TCP数据部分. 
16位紧急指针: 标识哪部分数据是紧急数据

• 特点

面向连接 

TCP三次握手过程

• 主机A通过向主机B 发送一个含有同步序列号标志位的数据段（SYN）给主机B ，向主机B 请求建立连接，通过这个数据段，主机A告诉主机B 两件事：我想要和你通信；你可以用哪个序列号作为起始数据段来回应我。
• 主机B 收到主机A的请求后，用一个带有确认应答(ACK)和同步序列号(SYN)标志位的数据段响应主机A，也告诉主机A两件事：我已经收到你的请求了，你可以传输数据了；你要用哪个序列号作为起始数据段来回应我。
• 主机A收到这个数据段后，再发送一个确认应答，确认已收到主机B 的数据段：“我已收到回复,我现在要开始传输实际数据了”。
• 这样3次握手就完成了，主机A和主机B 就可以传输数据了。

TCP四次挥手过程

• 当主机A完成数据传输后，将控制位FIN置1，提出停止TCP连接的请求。
• 主机B收到FIN后对其作出响应，确认这一方向上的TCP连接将关闭，将ACK置1。
• 由B 端再提出反方向的关闭请求，将FIN置1。
• 主机A对主机B的请求进行确认，将ACK置1，双方向的关闭结束。

TIME_WAIT状态

TCP协议规定,主动关闭连接的一方要处于TIME_ WAIT状态,等待两个MSL(最大报文生存周期)的时间后才能回到CLOSED状态。

TIME_WAIT持续存在2MSL的话，就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失(否则服务器立刻重启, 可能会收到来自上一个进程的迟到的数据, 但是这种数据很可能是错误的)。 
同时也是在理论上保证最后一个报文可靠到达(假设最后⼀一个ACK丢失, 那么服务器会再重发一个 FIN.。这时虽然客户端的进程不在了, 但是TCP连接还在, 仍然可以重发LAST_ACK)。

可靠传输：序列号、确认应答、超时重传、拥塞控制

1、确认应答机制&序列号

TCP将每个字节的数据都进行了编号，即为序列号

每一个ACK都带有确认的序列号，意思是告诉发送者，我已经收到了哪些数据，下一次从哪里开始发。

2、 超时重传&序列号

主机A发送数据给主机B后，可能因为网络拥塞等原因，数据无法到达主机B；如果主机A在一个特定的时间间隔内没有收到B发来的确认应答，就会进行重发。

主机A未收到B发来的确认应答，也可能是因为ACK丢失，因此主机B会收到很多重复数据。那么TCP协议需要能够识别出哪些包是重复的包，并且把重复的包丢弃掉，这时候我们可以利用序列号，就可以很容易做到去重的效果。

3、 拥塞控制

每次发送数据包的时候，将拥塞窗口和接收端主机反馈的窗口大小做比较，取较小的值作为实际发送的窗口。

拥塞控制，归根结底是TCP协议想尽快的把数据传输给对方，但是又要避免给网络造成太大压力的折中方案。

提高传输效率：滑动窗口、流量控制、延迟应答、捎带应答

滑动窗口机制

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

流量控制

接收端处理数据的速度是有限的，如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应。

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

延迟应答

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

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

捎带应答

在延迟应答的基础上，我们发现，客户端服务器在应用层也是“一收一发”的。

意味着客户端给服务器说了“How are you”，服务器也会给客户端回一个“fine， thank you”，那么这个时候ACK就可以搭顺风车，和服务器回应的“fine， thank you”一起回给客户端。

面向字节流：

创建一个TCP的socket, 同时在内核中创建一个发送缓冲区和一个接收缓冲区； 
另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做 全双工 。

1. 调用write时, 数据会先写入发送缓冲区中;
2. 如果发送的字节数太长, 会被拆分成多个TCP的数据包发出; 如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;
3. 接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;
4. 然后应用程序可以调用read从接收缓冲区拿数据;

TCP粘包问题

1. 首先要明确，粘包问题中的“包”指的是应用层的数据包。

2. 在TCP的协议头中，没有如同UDP一样的“报文长度”这样的字段，但是有一个序号这样的字段。

3. 站在传输层的角度，TCP是一个一个报文过来的，按照序号排好序放在缓冲区中。

4. 站在应用层的角度，看到的只是一串连续的字节数据，那么应用程序看到了这么一连串的字节数据，就不知道从哪个部分开始到哪个部分是一个完整的应用层数据包。

如何避免粘包问题呢？归根结底就是明确两个包之间的边界。

1. 对于定长的包，明确两个包之间的边界。

2. 对于变长的包，可以在报头的位置，约定一个包总长度的字段，从而就知道了包的结束位置。

3. 对于变长的包，还可以在包和包之间使用明确的分隔符。

4. TLV格式的数据传输。

协议

HTTP 
HTTPS 
SSH 
Telnet 
FTP 
SMTP

参考

(1) https://blog.csdn.net/sifanchao/article/details/82285018

(2) https://www.jianshu.com/p/3991e8390c79