TCP 与 UDP

TCP

TCP(Transmission Control Protocol，传输控制协议)，属于传输层协议，
提供面向连接的，可靠的数据传输服务。

面向连接

TCP 是面向连接的协议，为了准确无误地把数据送达目标处，
TCP 协议采用了三次握手策略和四次挥手策略。

TCP 三次握手

左边为客户端（client），右边为服务器端（server）。

• SYN：同步序列编号(Synchronize Sequence Numbers)是建立连接时使用的握手信号。
• ACK：消息响应(Acknowledgement)是对SYN消息的响应。
• seq：包序列号。
• ack：确认信息。

建立一个tcp连接，三次握手步骤如图：

1. 第一次握手：客户端向服务器发起一个连接请求，请求中携带SYN(seq=x)标志的数据包，
   然后客户端进入SYN_SEND状态，等待服务端的确认。这一步，服务端可以确认自身接收功能
   正常，客户端发送功能正常；
2. 第二次握手：服务端接收到客户端的连接请求后，向客户端发送一个确认连接响应，响应中携带
   SYN+ACK(seq=y,ack=x+1)数据包，然后服务器进入SYN_RECV状态。这一步客户端可以确认
   自身和服务端发送接收功能都正常
3. 第三次握手：客户端接收到服务端发送的确认连接响应后，向服务端发送一个确认响应，响应中携带
   ACK(ack=y+1)数据包，然后客户端和服务端都进入ESTABLISHED状态。
   这一步服务端可以确认客户端接收功能正常，自身发送接收功能正常

TCP 四次挥手

左边为客户端（client），右边为服务器端（server）。

• FIN：结束(FINISH)是连接结束挥手信号。
• ACK：消息响应(Acknowledgement)是对FIN消息的响应。
• seq：包序列号。
• ack：确认信息。

已建立的连接在结束时，四次挥手步骤如图：

1. 第一次挥手：客户端向服务端发送一个带有FIN(seq=x)的数据包，表示要关闭现有连接，然后
   客户端进入FIN-WAIT-1状态
2. 第二次挥手：服务端接收到FIN标志数据包后，会发送一个ACK(ack=x+1)标志的数据包，表示确认
   收到，然后服务端进入CLOSE-WAIT状态，客户接收到后进入FIN-WAIT-2状态
3. 第三次挥手：服务端向客户端发送一个带有FIN(seq=y)标志数据包，然后进入LAST-ACK状态
4. 第四次挥手：客户端接收到后，发送一个ACK(ack=y+1)标志数据包，进入TIME-WAIT状态。
   服务端接收ACK(ack=y+1)数据包后，进入CLOSE状态。此时客户端等待2MSL后依然没有收到
   回复说明服务端已正常关闭，客户端也关闭连接

TCP 如何保证可靠性

TCP是面向连接的，可靠的数据传输协议。那么是如何保证数据传输可靠呢？

1. 基于数据块传输。数据会被切割成合适大小进行传输。
2. 对失序数据包进行重排与去重。TCP给每一个数据块设置一个序列号，可以根据序列号排序以及去重
3. 校验和。TCP会根据数据包header和携带数据进行校验和，用于保证传输过程中的可靠
4. 重传机制。TCP在丢包或者网络延迟情况，会重新发送数据包直到接收端确认。常见重传机制：
   1. 基于计时器重传机制（超时重传）
   2. 基于接收端反馈信息重传机制（快速重传）
   3. 基于快速重传，同时返回最近接收的序列号范围（SACK重传）
   4. 基于SACK重传，同时返回数据包重复序列号（D-SACK重传）
5. 流量控制。TCP连接有固定的缓冲区，当超出缓冲区容纳范围会提示发送方降低发送速率，防止丢包。
   TCP是利用可变大小的滑动窗口实现流量控制
6. 拥塞控制。拥塞控制是为了防止过多数据注入网络中，导致网络链路过载。TCP维护一个拥塞窗口状态
   变量来动态控制拥塞程度，提供4中算法：
   1. 慢开始。由小到大依次增大拥塞窗口数值，来探测网络情况。每经过一次传播轮次，拥塞窗口数值加倍
   2. 拥塞避免。拥塞窗口缓慢增大，每经过一个RTT，拥塞窗口加1
   3. 快重传与快恢复。接收方如果接收到一个失序数据包，立即给发送方一个重复确认，如果发送方接收
      3个重复确认则会认为该数据包已丢失并立即重传丢失数据包。

使用场景

TCP 用于对传输准确性要求特别高的场景，比如文件传输、发送和接收邮件、远程登录等等。

常见协议：HTTP协议、FTP协议、SMTP协议、SSH协议

UDP

UDP（User Datagram Protocol）是为应用程序提供一种以最少的协议机制向其他程序发送消息的协议。
其主要特点是无连接，不保证可靠传输和面向报文。属于传输层的协议

使用场景

UDP 一般用于即时通信，比如：语音、 视频、直播等等。

常见协议：DNS协议、DHCP协议

TCP 与 UDP 比较

	TCP	UDP
是否面向连接	是	否
是否可靠	是	否
是否有状态	是	否
传输效率	较慢	较快
传输形式	字节流	数据报文段
首部开销	20 ～ 60 bytes	8 bytes
是否提供广播或多播服务	否	是

ARQ 协议

自动重传请求（Automatic Repeat-reQuest，ARQ）是 OSI 模型中数据链路层
和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制，
在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内
没有收到确认信息（Acknowledgements，就是我们常说的 ACK），它通常会重新发送，
直到收到确认或者重试超过一定的次数。

停止等待ARQ协议

基本原理就是每发完一个分组就停止发送，等待对方确认（回复 ACK）。
如果过了一段时间（超时时间后），还是没有收到 ACK 确认，说明没有发送成功，
需要重新发送，直到收到确认后再发下一个分组；
在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认。

超时重传

是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组
丢失了）。因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组
传输的平均往返时间更长一些

• 确认丢失：接收方在接收到数据后发送的确认消息丢失，接收方超时重传一遍该数据包，导致
  接收方接收到两份一样的数据包，接收方会采取2种措施：
  1. 丢弃该多余重复数据包
  2. 向发送方发送确认消息
• 确认迟到：由于网络延迟等问题导致确认消息迟到，接收方超时重传一遍该数据包，导致
  接收方接收到两份一样的数据包，同时接收方随后接收到重复确认消息。处理方式：
  1. 发送方直接丢弃多余重复确认消息
  2. 接收方直接丢弃多余重复数据包

连续ARQ协议

连续ARQ协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以
连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组
发送确认，表明到这个分组为止的所有分组都已经正确收到了。

• 优点： 信道利用率高，容易实现，即使确认丢失，也不必重传。
• 缺点： 不能向发送方反映出接收方已经正确收到的所有分组的信息。
  • 比如：发送方发送了 5 条 消息，中间第三条丢失（3 号），这时接收方只能对前两个
    发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。
    这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的 N 个消息。

超时重传原理

当发送方发送数据之后，它启动一个定时器，等待目的端确认收到这个报文段。

接收端实体对已成功收到的包发回一个相应的确认信息（ACK）。如果发送端实体在合理的
往返时延（RTT）内未收到确认消息，那么对应的数据包就被假设为已丢失并进行重传。

• RTT（Round Trip Time）：往返时间，也就是数据包从发出去到收到对应 ACK 的时间。
• RTO（Retransmission Time Out）：重传超时时间，即从数据发送时刻算起，
  超过这个时间便执行重传。RTT 的值会随着网络的波动而变化，如加权移动平均算法，
  Jacobson 算法等，这些算法都是根据RTT的测量和变化来估计RTO的值。