TCP协议

我会带着你远行 2022-08-21 04:27 258阅读 0赞

**TCP提供一种面向连接的、可靠的字节流服务。**

*  **面向连接：**意味着两个使用 TCP的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个 TCP连接。
 *  **字节流：**所谓面向字节流，即：虽然应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序看成是一连串的无结构的字节流。TCP有一个缓冲，当应用程序传送的数据块太长，TCP就可以把它划分短一些再传送。如果应用程序一次只发送一个字节，TCP也可以等待积累有足够多的字节后再构成报文段发送出去。（UDP是面向数据报的协议）
 *  **可靠传输：** 所谓可靠传输，即TCP提供了差错纠正的机制，尽最大可能保证数据能够让接收者接收到。

**TCP协议通过以下机制实现可靠传输：**  
1. TCP是面向字节流的，应用数据被分割成 TCP认为最适合发送的数据块。而不是想UDP那样原样发送应用程序交付的数据。  
2. TCP有超时重传机制。发送一个报文时，会启动定时器，在一定时间内如果没受到接收方的确认报文，则重传数据。ACK的接收时间会影响其他数据报定时器的时间。  
3. TCP接收方在收到数据时，回复确认报文有延迟。  
4. TCP将保持它首部和数据的检验和。这样可以确保数据在传输过程中不会发生比特位差错。Checksum在TCP协议中是必须的，（在UDP中是可选的，尽管一般也都有）  
5. TCP能对收到的数据进行排序，以便数据能以正确的顺序交付给应用层。  
6. TCP会丢弃重复的报文。  
7. TCP提供流量控制。 TCP连接的每一方都有固定大小的缓冲空间。T C P的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。  
8. TCP提供全双工服务， 报文的发送和接收相互独立。

# TCP 报文 #

## 报文首部 ##

![这里写图片描述][20160315165625040]  
**端口号：**包含源端口号和目的端口号，TCP端口号与IP首部的IP地址能唯一标识一个TCP连接。  
\*\*序列号：\*\*Sequence Number，序列号用于标识TCP发送端到TCP接收端发送的数据字节流，（其实给发送的数据字节从0到2^32-1循环编号，不过起始编号是随机的，不一定是0），序列号则是发送的每个报文段的第一个字节的编号。  
**确认号：** Acknowledge Numbe，确认号标识TCP接收端想接受的下一个字节流的第一个字节的编号。因此确认号其实是接收端接收到的报文段的最后一个字节的编号+1. 确认号只有在ACK标志位为1时才合法。  
**首部长度：**单位是32bits（4个字节），比如Header Length值为10，则表示首部长度为10\*4=40bytes。TCP首部长度上限为60字节，至少有20字节（不含Options的情况）。  
**Resv：**保留位，全为0.  
**标识位：**

*  CWR：Congestion Window Reduced，表明发送端降低了发送速率。
 *  ECE：ECN Echo，表明发送端接收到了一个之间的拥挤宣告
 *  URG：紧急指针字段有效，（这个标志位比较少用）
 *  ACK：表明确认序号有效。该报文是确认报文。
 *  RST：重新建立连接
 *  PSH：Push，表明接收端应该尽可能快的吧报文段交付给应用层。
 *  SYN：表示建立一个新的TCP连接，携带SYN=1标志的报文也称为SYN报文。SYN报文的序列号是一个TCP连接的起始序列号（SYN：initial sequence number)，它是随机的，不一定是0或者1. SYN报文和FIN报文会消耗一个序列号，也就是说，建立TCP连接后，发送的第一个数据的序列号是SYN序列号+1. （ACK报文不消耗序列号）
 *  FIN：发送端完成发送任务。会消耗一个序列号。  
    **窗口大小：** 通告窗口大小。用于流量控制。  
    **Checksum：** 检验和，覆盖了TCP首部和数据负载。  
    **Urgent Pointer：**紧急指针。Urgent Pointer是一个正的偏移量，与序列号相加得出紧急数据的最后一个字节的序列号。  
    **Options：** TCP支持很多Option，最常用的是`最大报文段`选项，

## Option ##

# 连接管理 #

TCP是面向连接的单播协议，相对UDP面向非连接的协议，TCP协议要处理更多的细节，包括连接的管理。  
　　TCP连接设计到**四元组：源IP、目的IP、源端口、目的端口**

## TCP连接的建立和结束 ##

一个TCP的连接包含三个阶段：连接的建立、数据的传输、连接的关闭。  
![这里写图片描述][20160315165650415]

### TCP连接的建立 ###

TCP连接建立的过程分为三步，就是我们常说的TCP三次握手  
1. 主动方（一般是client）想被动方（一般是Server）发送SYN报文。这里，TCP首部的SYN标志位置为1， 序列号是系统的ISN（初始序列号）。  
2. 被动方（Server）在接收到主动方的SYN报文后，发送针对该报文的ACK报文（这也是Server对于Client的SYN报文）。这里TCP首部的SYN和ACK标志位均置为1。 本应答报文的序列号是Server自己的ISN（初始序列号），而确认好则是接收到的client发来的SYN报文的序列号加1.  
3. Client端接收到Server发来的SYN+ACK报文后，应答一个ACK报文，其Sequence Number是SYN+ACK报文的序列号+1.  
　　以上便是TCP建立连接的三次握手。我们可以看到，在三次握手之后，不管是client还是Server，她们接下去要发送的数据报文的第一个报文段的序列号是自己的初始序列号+1.

### TCP连接的关闭 ###

TCP连接的两端都可以主动关闭连接，（不过通常由client发起，不过可以有Server发起，更特殊的情况是两端同时发起）  
　　TCP连接的关闭包括四个步骤（需要四个报文段）  
1. 主动关闭的一方向被动方发送FIN+ACK报文，FIN表示要关闭连接，而ACK则是对最后一个受到的报文段的确认。此FIN+ACK报文段的序列号是接收端期望收到的序列号（根据前面序列号的解释，接收端在发送ACK报文的时候，其ACK Number就是接收端期望受到的下一个报文段的序列号）。FIN+ACK报文段的确认号则是主动关闭连接的一段收到的上一个报文的序列号+1.  
2. 被动关闭的一方在收到FIN+ACK报文后，首先应答一个ACK报文，报文的序列号是收到的FIN+ACK报文的确认号，报文的确认号则是收到的FIN+ACK报文段序列号+1.至此TCP连接进入了**半关闭**的状态。  
3. 被动关闭连接的一方还会发送一个FIN+ACK报文，来关闭TCP连接的另一端。  
4. 主动关闭连接的一方会应答收到的FIN+ACK报文，发送ACK报文。

*  **半关闭状态：** 如果TCP两端只执行了四个关闭步骤的前两步，则此时TCP属于半关闭状态（这种状态还是比较少见）
 *  **同时发起连接建立、连接关闭：** 在可以安排的情况下，TCP协议两端同时发起建立连接，或者同时发起连接关闭的情况是存在的。但其实过程差不多的，以连接的建立为例，主要是多了一个SYN报文段。
 *  **连接建立超时：** TCP连接的建立是有可能失败的，比如被动方不存在、不可达等原因。这时主动方的SYN报文就不会有回应，在主动方没收到SYN的ACK应答时，就会重发SYN报文，但是重发的次数是有限的，且间隔越来越长。

# 超时重传 #

TCP提供可靠的数据传输，然而在网络中，数据极有可能由于各种各样的原因丢失。为此，TCP提供了超时重传机制，发送端在发送一个报文时，启动一个定时器，接收端如果接收到报文则想发送端回复一个ACK确认报文，在定时器timeout之前，如果发送端接受到了接收端发来的ACK报文，则表明报文已经发送成功，如果没收到ACK报文（超时了）则对先前的报文进行重传。  
　　那么问题来了：（1）定时器的时间是多久？（2）ACK报文丢失了在传输过程中丢失了怎么办？（3）数据报文收到了，但是有错误怎么办？  
\+ 第（1）个问题比较复杂，用到了统计学的方法，RTT只能估算，RTT不是固定了，会自我学习。TCP实际使用的定时器时间一般会比平均往返时延RTT大，以避免不必要的重传。  
\+ 第（2）个问题，如果ACK报文丢失了，我们就当接收端没有发送ACK报文（接收端没有没有收到数据报文），如此发送端重传数据，这会导致接收端收到重复的报文，因此TCP也应提供解决该问题的方案(TCP为每一个报文设置一个唯一的序列号，接收端根据序列号判断报文是否收到重复的报文）。  
\+ 第（3）个问题，数据报文收到了，但是有错误，此时接收端应发送两次ACK报文。发送端就重发数据报文。

# 报文窗口 滑动窗口管理 #

TCP的发送端会等待接收到接收端发来的ACK报文才能确认自己的数据报文是否发送成功，在开始发送数据报文在接收到ACK报文（或者超时）之间有一段空闲时间，如果我们每次都等到接收到ACK报文（或者定时器超时）才发送下一个报文（或者重传），这就浪费了中间的等待（空闲）时间。为此，TCP实现了一种机制，允许在同一时间内，网络上存在多个发送的报文，也就是说在等待的空闲时间里，TCP可以发送其他数据报文。该机制在实现起来比较复杂，比如TCP需要管理、识别不同的数据报文和他们对应的ACK报文，为此提出了报文窗口和滑动窗口的概念  
　　 TCP使用窗口采集正在发送（还没收到ACK报文）的报文（或者它的序列号），  
　　**滑动窗口机制 是TCP可靠性的重要保证**

# 流量控制 和 阻塞控制 #

TCP发送端和接收端处理报文的能力（效率）有所差异，如果接收端的处理报文的速度慢于发送端， 那么发送端会降低自己的发送速率。这便是流量控制。 流量控制常用的方法有一下两种：

*  **基于速率的流量控制：**给定发送端一个固定的发送速率，常用与多播和广播。
 *  **基于窗口的流量控制：**最常用的流量控制手段。接收端发送信号高速发送端应该使用多大的窗口，发送端根据信号调整自己报文窗口的大小。即：**窗口宣告**
    
    　　流量控制要讨论两个方面，
    
    1.  发送端和接收端处理报文的能力，通过信号调节
    2.  发送端与接收端之间的网络（中间路由器）处理报文的能力。这是**阻塞控制**的范畴

[20160315165625040]: /images/20220731/869f6ac3e2764585ae73fe7cf58b598c.png
[20160315165650415]: /images/20220731/cc1aa6117bd3465d9f38fa2ff081850e.png