关于TCP，我懂的全写到这里了

图中的反复只是为了确认对方对你的 "请求" 是否有所 “回应”.

再比如,当你给朋友寄快递的时候,你寄完快递之后将单号拍了下来,发给了你的朋友并告诉他如果你收到这份包裹的话就给我发个消息或者回个电话.
这个快递发出去无非就是三种情况

• 1.你的朋友收到快递,给你发来确认信息
• 2.你的朋友收到快递,给你的回复消息的因断网而发送失败(他已经发送过了),你主动向你的朋友询问情况.
• 3.你的朋友没有收到快递,快递在运输过程中丢失(朋友告诉你他没有收到快递).

这三种情况中都需要通过你朋友的回应来确定具体是那种情况,

• 而这里的回应确保了寄件人对📦去向的掌握.

之前学习的通过UDP协议传输的信息并不具备这种通过对方回应来确定对方是否收到包裹的功能

所以我们该怎么知道对方的接收情况呢？

其实也很简单,我们需要一种可以通过双方互动来确认包裹是否正确接收的协议,这就是我们今天将要介绍的TCP协议了。

TCP

报文格式

16位源端口

• 本机的数据从哪里出去

16位目的端口

• 对方的数据从哪里进去

32位序号字段,32位确认序号

• TCP连接中传输的数据流中每一个字节都有对应的序号.
• 这两部分和TCP的ACK机制有关,发送端给应用层收到的数据进行打码,接收端通过接收到的数据码回馈接收状态

4位数据偏移(首部长度)

• 指出TCP报文段的数据起始处距离TCP报文段的起始处有多远,“数据偏移”的单位是32位字(以4字节位计算单位)
• 标明正文位置

保留字段

• 该字段主要是为了以后扩展是使用,其长度为4位。

控制位

• URG:当URG=1时,表名紧急指针字段有效,告诉系统此报文段中有紧急数据,应尽快传送(相当于高优先级的数据)
• ACK:当ACK=1时确认号有效,ACK=0无效
• PSH:当PSH=1就提示接收端应用程序立刻从TCP缓冲区把数据读走
• RST复位标志,当RST=1表明TCP连接出现严重差错,必须释放连接,然后再重新建立运输连接
• SYN同步标志:SYN=1表示这是一个连接请求或连接接收报文
• FIN结束标志,用来释放一个连接, FIN=1表示此报文段的发送端的数据已发送完毕,并要求释放运输连接

16位窗口大小

• 与TCP滑动窗口、流量控制有关,

16位校验和

• 校验和字段检验的范围包括首部和数据两部分,在计算校验和时,要在TCP报文前加上12字节伪首部

16位紧急指针字段

• 指出在本文中紧急数据共有多少个字节

TCP特点

• TCP是面向连接的运输层协议
• 每一条TCP连接只能有两个端点,每一条TCP连接只能是点对点的(一对一)
• TCP提供可靠交付的服务
• TCP提供全双工通信
• 面向字节流
  

TCP通过检验和、序列号、确认应答、重发控制、连接管理、以及窗口控制等机制实现可靠传输

• 所谓的面向有连接的“连接”
  

序列号与确认应答(保证可靠性)

我们之前说的寄快递的例子,你的朋友告诉你他收到了包裹,你才能确定快递没有丢失.
而在TCP中,当发送端的数据到达接受主机时,接收端主机会返回一个已收到的消息通知给发送端,这个消息叫做确认应答(ACK),正如你朋友告诉你快递收到了,而在没有收到你朋友的回复的时候,你就会担心会反问他,这好比一个否定确认应答(NACK)

未收到确认应答的情况分为两种

• 1.数据(包裹)丢失,等待一端时间后(等待多久?)重新发送
  
• 2.数据已接收(快递已签收),但是返回的确认应答在途中丢失(确认消息因断网而没有发给你).等待一段时间(等待多久?)后重新发送
  

在TCP协议中,在没有收到确认应答的情况下.会将之前的没有收到ACK的数据重新发送一次.

当然也有可能是网络原因导致的确认应答延迟到达,

• 对于这种情况,对于通信中的不同对象而言会造成不同的后果

对象	导致的问题
发送方	按照机制重发一份数据
目标主机	反复接收相同的数据
目标主机上层应用	必须放弃重复的数据包

为了解决这种情况带来的问题,我们需要引入一种既能识别已经接收数据,又能够判断是否需要接收该数据的机制

• 上述这种确认应答处理、重发控制以及重复控制等功能都可以通过序列号实现.

序列号是按照顺序给发送的数据的每一个字节都打上一个码,接收端查询接收数据TCP首部中的序列号和数据长度,并将下一次应该接收的序号作为确认应答返回给发送方.

• 互动图
  
• 操作端模拟图
  
• 确认应答序号的含义是当前序号之前的数据已经收到了,希望收到的下一条数据就是从确认序号开始的

超时重发如何确定

• 超时重发是指在重发数据之前,等待确认应答到来的那个特定时间间隔,如果超过了这个时间仍未收到确认应答,发送端就会重新发送未收到确认应答的数据,那么这个超时重发的等待时间该怎么确定呢?
  
  超时重发的计算既要考虑往返时间又要考虑偏差,是因为同一个报文在不同的网络环境中传输的速度是不同的.而TCP/IP 的目的是在于即使在不同的网络环境下也要对网络流量进行控制,不造成浪费.

• 在Unix和Windows系统中,超时都是以0.5秒为单位进行控制的,因此重发超时都是0.5秒的整数倍,不过,由于最初的数据报不知道这个时间,所以其重发超时一般设置为6秒左右.

数据被重发之后若还是收不到确认应答,则需要再次重发,此时等待确认应答的时间是以2的整数倍的方式延长的.

当然在网络中也不能对同一份数据反复进行重发,当这份数据的重发次数到达限制之后,仍然收不到任何确认应答.就会判断为网络或对端主机发生异常,强制关闭连接.并通知本端应用层通信异常强行终止连接.

连接管理

建立连接(三次握手)

• 用处

• 1.确定双方的交付能力

• 2.指定初始序列号,为可靠传输做准备

• 3.交互保密机制

• 握手过程(粗略的说法)

• 1.客户端给服务器发送一个SYN报文

• 2.服务器收到SYN报文后,会应答一个SYN+ACK报文

• 3.客户端收到SYN+ACK报文后,回应一个ACK报文
  

• 握手过程(精确的说法)
  

• 1.客户端发送SYN报文,指定序列号ISN,处于SYN_Send状态

• 2.服务端把SYN作为应答,指定ISN,把客户端的ISN+1作为ACK值发送给客户端,此时服务器处于SYN_RECV状态

• 3.客户端发送一个ACK报文,此时客户端处于established状态

• 4.服务器收到ACK报文之后也处于established状态

补充:

• 半连接队列:服务器第一次收到客户端的SYN之后,就会处于SYN_RCVD状态,此时双方还没有完全建立其连接,服务器回把这种状态下请求的连接放入一个队列,我们把这个队列称为半连接队列(用于保存处于SYN_SEND 和 SYN_RECV状态的请求)
• 全连接队列:已经完成三次握手,建立起连接的就会放到全连接队列中,如果队列满了就会出现丢包的可能性.

在该过程中的客户端在发送确认应答的同时也发送了建立连接的请求(SYN包)

• 因为SYN和ACK都是内核控制发送的,所以可以进行合并

断开连接(四次挥手)

端开连接的过程(粗略)

• 1.客户端给服务器发送一个FIN结束报文（分手通知,调用close()函数）
• 2.服务器给客户端发送一个ACK确认应答（对方告诉你他知道了,收到FIN报文,理解返回ACK）
• 3.服务器也给客户端发送一个FIN结束报文（对方同意分手，也向你提出分手,调用close()）
• ４.客户端给服务器发送一个ACK确认应答（你收到对方的分手通知，断开连接）
• 精确一点的说法

刚开始两者都处于ESTABLISHED状态

• 假设客户端先发起关闭请求
  

• 1.第一次挥手:客户端发送一个FIN报文,报文中会指定一个序列号,此时客户端处于FIN_WAIT1状态

• 2.第二次挥手:服务器收到FIN之后,会发送ACK报文,且把客户端的序列号值+1作为ACK报文的序列号值,表明已经收到客户端的报文了,此时服务器处于CLOSE_WAIT2 状态

• 3.第三次挥手:如果服务器也想断开连接了,向客户端发送FIN报文,且指定一个序列号,此时服务器处于LAST_ACK 状态

• 4.第四次挥手:客户端收到服务器端的FIN报文后,发送一个ACK报文作为应答,且把服务端的序列号值+1作为自己ACK报文的序列号值,此时客户端处于TIME_WAIT 状态.需要过一阵子(2MSL)以确保服务端收到自己的ACK报文后才会进入CLOSED 状态

• 5.服务器收到ACK报文之后,就处于关闭连接了,处于CLOSED状态

• FIN是函数close()进行触发的,由程序控制,而ACK是内核发送的.

• 第一个ACK和第二个FIN不一定能合并

• 连接管理的综合图
  

• 重要的TCP状态

• 1.LISTEN状态:服务器已启动,随时可以连接

• 2.ESTABLISHED状态:连接建立成功,随时可以通信

• 3.CLOSED_WAIT等待调用close()函数,对端已经执行过close()函数

如果服务器端出现大量的CLOSE_WAIT状态,

• 代码中忘记调用close

• 4.TIME_WAIT状态:

为什么客户端发送ACK之后不直接关闭,而要等一会才关闭?

• 因为最后发送的ACK也存在丢包的可能,所以客户端需要确保服务器已经收到了客户端发送的ACK
• 若最后发送的ACK丢包了,那么服务器端收不到确认应答就需要重发FIN报文给客户端,客户端再次收到FIN报文之后,就知道之前的ACK报文丢失了,重新发送ACK报文
• TIME_WAIT会保持一个报文的来回时间(2MSL).MSL表示网络中的两个结点之间,传输一个数据所经历的最大时间.过了这个时间客户端没有再次收到FIN报文,就表示对方成功接收了ACK报文,此时处于CLOSED状态

滑动窗口与重发控制

TCP以1个段为单位,每发一个段就需要进行一次确认应答的处理,这样再等待ACK的这段时间里发送端是闲置的,那么就会使得TCP的传输效率低下.

为了解决传输效率低的问题,TCP引入了窗口这个概念.即使在往返时间比较长的情况下,他也能控制网络性能的下降.因此确认应答不再是以每个分段,而是以更大的单位进行确认时,转发时间将会被大幅度的缩短.也就是说,发送端主机在发送了一个段之后不必要一直等待确认应答,而是继续发送(在窗口大小够用的情况下)

窗口大小:指无需等待确认应答而可以继续发送数据的最大值(真实的窗口大小值为流量控制和拥塞控制两者中的较小者).
发送前四个段的时候,不需要等待任何ACK,直接发送

• 收到第一个ACK后,滑动窗口向后移动,继续发送第五个段的数据,依次类推.
• 操作系统内核为了维护这个滑动窗口,需要开辟发送缓冲区来记录当前还有那些数据没有应答,只要确认应答过的数据,才能从缓冲区删掉
  

在这种机制下会出现的两种机制

• 情况一:数据包已经到达,返回的ACK丢失
  

• 这种情况下,部分ACK丢了并不要紧,因为可以通过后续的ACK进行确认
  例如:在发送了1~5000个自己的数据后均没有收到ACK,但是再发送了5001 ~ 6000 之后主机A收到ACK(下一个是6001),说明前6000个字节主机B　已经收到了,就不需要再去重发之前的数据了

• 情况二:数据包就直接丢了
  
  当某一段报文丢失后,发送端会一直收到序号为丢失段的确认应答
  如果发送端主机连续三次收到同样内容的确认应答,就会将对应的数据重新发送
  当接收端收到丢失段的确认应答后,再次返回的确认应答就是之前已经接收过到数据,被放到了接收端操作系统内核的接收缓冲区中,如上图中的7001,这种机制被称为"高速重发控制(也叫"快重传")"

流量控制

接收端处理数据的速度是有限的,如果发送端一直保持高速发送,就会导致接收端的缓冲区很快就被填满,之后如果接收缓冲区中的数据没有被读走(接收端缓冲区没有空余空间)，发送端继续发送数据就会造成丢包,继而引起包重传等一系列的连锁反应

因此TCP支持根据接收端的处理能力,来决定发送端的发送速度,这个机制叫做流量控制

• 接收端将自己可以接收的缓冲区大小放入TCP首部中的"窗口大小"字段,通过ACK报文通知发送端.

• 接收端一旦发现自己的缓冲区快满了,就会将窗口大小设置成一个更小的值通知给发送端

• 发送端接受到之后,就会减慢自己的发送速度

• 如果接收端缓冲区满了,接收端将会将窗口置为0,这时发送方不再发送数据,但是需要定期发送一个窗口探测数据段,让接收端把窗口大小告诉发送端
  

• 如上图中,当接收端收到从3001号开始的数据段后其缓冲区满了,需要暂停数据的接收.之后,在收到发送窗口更新通知后通信才能继续进行.但是这个更新通知可能在传送途中丢失,所以发送端会时不时的发送一个叫做窗口探测的数据段,此数据段仅含一个字节以获取最新的窗口大小信息

TCP协议报头中的窗口大小字段,这个字段是和接收缓冲区的空余大小相关联的

拥塞控制

• 为什么会引入拥塞控制?
  因为,TCP滑动窗口虽然能高效可靠的发送大量的数据,但是在某个连接刚建立的时候并不清楚网络的拥塞状况,发出数据后迟迟收不到ACK,就可能进行重发.在不清楚网络状态的情况下就进行重发的话,会使拥塞情况更加严重,所以需要我们设计出一种可以控制网络拥塞情况的机制
  
  网络中判定拥堵的依据:在交互过程中是否出现了丢包现像,若出现丢包,则认为比较拥堵。

慢启动(网络拥堵的解决)

TCP 引入了慢启动 机制,先发送少量数据,查看当前网络的拥堵情况,再决定按照多大的速度传输数据.

• 没有出现丢包就按指数形式增大窗口.若窗口大小达到阈值之后就开始线性增长,当窗口达到某个值后就会发生丢包,一旦发生丢包现像就认为网络出现拥堵,就立刻将窗口大小减小到一个很小的值.之后重复慢开始过程

• 当TCP开始启动的时候,慢启动阈值等于窗口最大值
• 每次发生超时重传,慢启动阈值就会减半,同时将拥塞窗口置为1

真实的窗口大小值为流量控制和拥塞控制两者中的较小者

延时应答(提高传输效率)

• 如果在收到数据报之后立即返回ACK,则有可能在ACK返回和下一次数据发送到来的这段时间内接收端的缓冲区已经比返回ACK的窗口大小要大了,这就导致网络资源利用率的降低

那么我们可以在第一次接收到数据后不立即返回ACK,而是暂缓一会再发送ACK,可能其在暂缓发送的这段时间里接收缓冲区中的数据就会拿走了,则ACK中返回的窗口大小就变大了,这个过程就是延时应答

那么暂缓的这段时间是多长时间呢？

• 数量限制:每隔N个包就应答一次
  
  上图中,每发两个包就应答一次
• 时间限制:超过最大延迟时间就应答一次

捎带应答

依赖于延时应答

• 在延时应答的基础上,引入的一个机制

TCP四次挥手有没有可能是三次呢?

有可能,因为稍等应答支持这件事情.
因为延时应答的存在,可能会使得第二次挥手和第三次挥手时间重合了,导致FIN和ACK在同一个包中发送给对方。

面向字节流

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

• 调用write时, 数据会先写入发送缓冲区中;

• 如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;

• 接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;然后应用程序可以调用read从接收缓冲区拿数据;

• 另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做 全双工

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

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

• 发送缓冲区调用send()本质上是把用户的数据拷贝到内核的发送缓冲区中,再由内核按照滑动窗口的方式把数据批量发送到对端,如果丢包就会重传对应的数据
• 接收缓冲区:收到的数据先到达接收缓冲区,用户代码从接收缓冲区中都读走(read/recv)数据后,才会把数据读走后才会清除掉,接收缓冲区也会帮助用户进行数据的去重

粘包问题

面向字节流相关,应用程序如何能够一次取出一个完整的应用层数据报,从应用层的角度来解决这个问题,只要能够确定数据报和数据报之间的边界就可以了

确认边界的两种方式

• 1.分隔符
• 2.指定长度

TCP异常情况

TCP小结

• 可靠性:
• 确认应答/超时重传
• 连接管理
• 传输效率
• 滑动窗口

流量控制/拥塞控制
延时应答 / 捎带应答

TCP/UDP的对比

• UDP

• 无连接

• 不可靠

• 面向报文(对上层来的报文不做拆分/合并,只是封装了UDP首部)

• 支持一对多,多对一

• TCP

• 面向有连接

• 可靠的

• 面向字节流(把报文看成字节流,拆分组织成大小不等的数据块)

• 只能一对一

• 1.如果需要可靠性(比如外网复杂的网络环境),优先考虑TCP

• 2.如果网络结构本身比较简答,可靠性比较高(机房内网),对传输效率要求更高,优先考虑UDP

• 3.如果你要传输的数据报较大,TCP(UDP的包有最大长度64K)

• 4.如果需要广播的话,只能使用UDP,TCP不能广播