TCP实现可靠传输的原理

TCP是传输层的一个协议，在了解他的原理之前先简单介绍一下传输层:

       传输层为应⽤层进程之间的通信提供服务，传 输层向⾼层⽤户屏蔽了下⾯⽹络核⼼的细节（如⽹络拓扑、所采⽤的路由选择协议等），使应⽤进程看⻅的就是好像在两个传输层实体之间有⼀条端到端的逻辑通信信道。这个信道分为可靠信道和不可靠信道，tcp协议实现的就是提供可靠的，面向连接的运输服务，TCP 传送的数据单位协议是 TCP 报⽂段 (segment)

所以接下来介绍一下TCP报文段的格式.

TCP报文段的首部格式

 

具体介绍：

源端⼝和⽬的端⼝

源端⼝和⽬的端⼝各占 2 字节。端⼝是传输层与应⽤层的服务接⼝；

序号

序号占 4 字节。 TCP 连接中传送的数据流中的每⼀个字节都有⼀个序号，序号字段的值则指的是本报⽂段所发送的数据的第⼀个字节的序号

确认号

确认号：占 4 字节，是期望收到对⽅的下⼀个报⽂段的数据的第⼀个字节的序号

数据偏移

数据偏移（即⾸部⻓度）：占 4 位，指出 TCP 报⽂段的数据起始处距离 TCP 报⽂段的起始处有多远。 单位是 32 位字（以 4 字节为计算单位）

保留

保留：占 6 位，保留为今后使⽤，但⽬前应置为 0

以下较为重点：

紧急 URG

紧急 URG：控制位。

当 URG = 1 时，表明紧急指针字段有效，告诉系统此报⽂段中有紧急数据，应尽快传送 (相当于⾼优先级的数据)

确认 ACK

确认 ACK：控制位。

只有当 ACK =1 时，确认号字段才有效。当 ACK =0 时，确认号⽆效

推送 PSH (PuSH)

推送 PSH (PuSH) ：控制位。

接收 TCP 收到 PSH = 1 的报⽂段后，就尽快（即“推送”向前）交付接收应⽤进程，⽽不再等到整个缓存都填满后再交付

复位 RST (ReSeT)

复位 RST (ReSeT) ：控制位。

当 RST=1 时，表明 TCP 连接中出现严重差错（如主机崩溃或其他原因），必须释放连接，然后再重新建⽴运输连接

同步 SYN (SYNchronization)

同步 SYN (SYNchronization) ：控制位。同步 SYN = 1 表示这是⼀个连接请求或连接接受报⽂

● 当 SYN = 1，ACK = 0 时，表明这是⼀个连接请求报⽂段

● 当 SYN = 1，ACK = 1 时，表明这是⼀个连接接受报⽂段

终⽌ FIN (FINish)

终⽌ FIN (FINish) ：控制位。⽤来释放⼀个连接。

● FIN=1 表明此报⽂段的发送端的数据已发送完毕，并要求释放运输连接

窗⼝

窗⼝：占 2 字节。

窗⼝值告诉对⽅：从本报⽂段⾸部中的确认号算起，接收⽅⽬前允许对⽅发送的数据量（以字节为单位）

检验和

检验和：占 2 字节。检验和字段检验的范围包括⾸部和数据这两部分

紧急指针

紧急指针：占 2 字节

在 URG = 1时，指出本报⽂段中的紧急数据的字节数（紧急数据结束后就是普通数据），指出了紧急数据的末尾在报⽂段中的位置

可靠传输的工作原理

我们知道网络传输是不可靠的，因为网络有着许多的不可控因素。那么要达成可靠的传输，我们需要满足以下两点。

1.数据能够准确传递到接收端

2.接收端处理数据的速度要能够跟上发送方发送数据的速度。

针对这两点，于是就有了停止等待协议。

什么是停止等待协议呢？

简单来说发送方在每次发送数据之后，必须要等到接收方的确认响应之后再继续发送后面的数据。很明显这样做虽然很简单，但是同样会带来一些问题。

问题一：发送方在发送完数据之后，需要一直等待接收方的确认答复。这样网络传输的效率非常低。

问题二：如果传输过程中有差错导致接收方没有接收到数据，那么接收端不会恢复确认，而发送方一直等待接收端的答复，那么就形成了死锁。

针对问题二，为了避免死锁的出现，于是有了超时重试机制。发送方会维护一个超时时间和一个信息的副本（用于重试，接收到确认信息后才删除），发送方发送完信息之后就会启动一个超时计时器，超时之后如果没有收到接收方的确认信息，那么就会重新再次发送。如果在超时时间内接收到了确认信息就撤销超时计时器。

这样死锁问题得到了解决，但是问题一的问题依旧存在，信道的利用率太低了，导致网络传输的速率太慢了。所以需要进一步优化。于是就有了滑动窗口协议。而TCP正是基于滑动窗口协议来实现可靠传输的，所以我们重点分析滑动窗口协议。

滑动窗口协议

什么是滑动窗口协议？

将数据以字节为单位，并且为每个字节设置一个序号，并且发送端和接收端都需要维护一个窗口。

发送端：只有在发送窗口内的数据才可以被发送，发送窗口发送完数据之后需要等待接收端的确认，如果数据被确认之后，那么发送窗口就向右移动。

发送端滑动窗口示意图：

接收端：接收并且已经发送过确认消息的数据可以不用保存，只有在接收窗口内的数据才可以被接收。并且在接收端会维护一个期望收到的序列号（在图中也就是3），如果接收端接收到了4，5，6，但是没有接收到3，那么是不能够发送确认消息的。直到接收到序号3的数据，才会发送3，4，5，6的确认信息给发送端，然后将接收完的数据丢弃，并且向右移动接收窗口的预期接收序号值。

接收端滑动窗口示意图：

 

同样为了避免死锁，发送窗口协议同样有超时重发机制。

超时重发机制需要注意的是：接收端如果接收到一样的数据，那么可以直接丢弃数据，但是每次接收到数据，依旧需要发送确认接收消息给发送端。

很明显，滑动窗口协议相对于停止等待协议的信道利用率得到了很大的提高

“三次握⼿”和“四次挥⼿”

传输连接的三个阶段

TCP 是⾯向连接的协议

TCP 连接有三个阶段

● 连接建⽴->数据传送->连接释放

TCP 连接的建⽴采⽤客户服务器⽅式

主动发起连接建⽴的应⽤进程叫做客户 (client)

被动等待连接建⽴的应⽤进程叫做服务器 (server)

TCP 的“三次握⼿”

TCP 建⽴连接的过程叫做握⼿

采⽤三报⽂握⼿：

● 在客户和服务器之间交换三个 TCP 报⽂段，以防⽌已失效的连接请求报⽂段突然⼜传送到了，因⽽ 产⽣ TCP 连接建⽴错误

“三次握⼿”：

 

 

“四次挥⼿”

● TCP 连接释放过程⽐较复杂

● 数据传输结束后，通信的双⽅都可释放连接

● TCP 连接释放过程是四报⽂握⼿

四报⽂握⼿

MSL：最⼤报⽂⽣存时间

等待2MSL的目的：

1. 保证发送的最后⼀个 ACK 报⽂段能够到达 B

2. 防⽌“已失效的连接请求报⽂段”出现在本连接中

想观察TCP的三次握手与四次挥手的过程可以使用wireshark来实现，安装与使用在此不多做介绍网上一搜都是教程，所以这里直接观看结果：

 过程介绍：

其中[ ]就代表1；例如[SYN]就代表SYN = 1，此处我们使用的是本机向39.156.66.18这个地址（百度的地址）发送信息

三次握手：序号1,2,3

第一次握手：由本机地址向目标地址发送连接请求，其中SYN = 1，ACK = 0就代表这是一个连接请求报文段。

第二次握手：目标地址接收到本机地址发送的请求并发送确认，其中SYN = 1，ACK = 1代表这是一个连接确认报文段。

第三次握手：本机地址接收到目标地址的确认后向目标地址再次发送确认，建立连接成功

四次挥手：序号6,7,8   序号4,5是本机向目标发送完信息后目标接收的过程 ，接收后目标地址主动关闭，开启四次挥手过程

第一次挥手：由目标地址向本地地址发送终止信息，也就是FIN = 1，并且让 PSH = 1 使其快速推送

第二次挥手：本地地址接收到目标地址发送的信息并向目标地址发送确认

第三次挥手：本地地址像目标地址发送终止信息

！第二次和第三次挥手可能会一起发生

第四次挥手：目标地址接收到本地地址的信息并发送确认，本机地址接收到确认后关闭，目标地址在发送确认的2MSL后关闭，连接释放