TCP协议详解

最新推荐文章于 2024-03-23 12:08:27 发布

原创最新推荐文章于 2024-03-23 12:08:27 发布 · 664 阅读

0 ·

CC 4.0 BY-SA版权

网络专栏收录该内容

3 篇文章

订阅专栏

初识TCP协议

一、TCP简介
- 1.TCP协议
- 2.TCP协议的特点
二、可靠性传输保障
三、TCP存在的问题
- 1.粘包问题
- 2.TCP异常情况

本文参考了TCP的三次握手与四次挥手理解及面试题

一、TCP简介

1.TCP协议

TCP协议全称为（传输控制协议），是对数据的传输进行一个详细的控制。TCP协议段格式：
在这里插入图片描述

16位源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去，端与端之间
32位序号/32位确认号: 保证数据有序交付;
4位TCP报头长度: 表示该TCP头部有多少个32位bit(有多少个4字节); 所以TCP头部最大长度是15 * 4 = 60
6位标志位:

URG: 紧急指针是否有效
ACK: 确认号是否有效
PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走
RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段
FIN:通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段

16位窗口大小: 接收方的接收缓冲区剩余大小，进行流量控制
16位校验和: 发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部,也包含TCP数据部分.
16位紧急指针: 标识哪部分数据是紧急数据
40字节头部选项：可有可无

2.TCP协议的特点

有连接：TCP三次握手建立连接
很可靠：连接管理，确认应答，超时重传，序号/确认序号,检验和，滑动窗口机制（流量控制，拥塞控制，快速重传，拥塞机制），延迟应答都是为了保证可靠传输
面向字节流：TCP面向字节流，以字节流形式发送，对方可以一次接受全部，也可以一次接受一点，可分多次接受。数据不会直接发送，而是存放到缓冲区，操作系统选择合适的时机将合适大小的数据发送出去，由于缓冲区的存在，TCP程序不需要读和写一一匹配。传输灵活，但是会造成粘包问题，TCP把数据看成一连串无结构的字节流

二、可靠性传输保障

1.连接管理机制

在正常管理机制下，TCP要经过三次握手建立连接，四次挥手断开连接。

在建立连接前客户端，服务器会创建套接字，为套接字绑定地址信息，客户端向服务器发送连接请求，服务器正处于监听状态，在这个数据传送的时候一般客户端只有一个socket，服务器有两个，一个负责等待，一个进行数据处理。

1.1三次握手理解

在这里插入图片描述
第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包（减少TCP报头的发送），此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

1.2四次挥手理解

在这里插入图片描述

客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

为什么TIME_WAITE的时间是2MSL
TCP协议规定，主动关闭连接的一方要处于TIME_WAIT,等待2个MSL的时间后才能回到CLOSE状态。MSL是TCP报文的最大生命周期，MSL在不同平台上实现不同。等待2个MSL时间是为了让网络延迟的报文都消失（后续重传的ACK、FIN），使得网路中不会对后续连接造成影响。同时也理论上保证最后一个报文可靠到达。

大量的TIME_WAITE解决方案：
调整MSL时间，设置套接字选项（地址复用）

在server的TCP连接莫有完全断开之前不允许重新监听，哪些情况下可能是不合理的

服务器需要处理非常量大的客户端的连接（连接生存时间短）
如果服务器主动关闭连接（不活跃客户端），产生大量的TIME_WAITE
客户端请求很大

TCP连接管理中的保活机制：若通信双方，长时间莫有数据往来，会给对方发送保活探测数据包（要求对方进行回复），若是收到回复则默认正常，若是间隔（75秒）发送多次（9次）莫有回复，则认为连接断开。

2.确认应答机制

网络中莫有百分之百的报文，因为总有一个最新报文莫有确认。是在面向连接的基础上，对每条数据进行发送方确认，TCP将每个字节的数据进行了编号，即为序列号，目的是为了保证读取信息按顺序执行。每个ACK都带有对应的确认序列号，意思是告诉发送者，我们已经收到了哪些数据，下一次你从哪里开始发。目的是为了判断哪些序号丢失。

3.超时重传机制

发送数据等待一段时间（动态计算），若莫有收到确认回复，则认为数据丢失（ACK丢失，网络拥堵等原因），进行重传，但是降低了性能。累计到一定的重传次数，TCP认为网络或者端主机出现异常，强制关闭

协议字段中：序号+确认序号（保证数据有序的向应用层交付，去重）
协议字段中：校验和（校验接受数据与发送数据是否一致，不一致发送重传请求，否则确认回复）

TCP为了保证可靠传输，牺牲了性能（有些性能的损失是不必要的），比如ACK丢失导致重传。

4.滑动窗口机制

1.1快重发机制
就是将多个段的等待时间重叠在一起了，一次发送多条数据，大大的提高了性能。窗口大小指的是无需等待确认应答而可以继续发送数据的最大值，不会大于缓冲区空间大小。若果是四段，则发送前四段的时候，不需要等待任何ACK，直接发送。收到第一个ACK后，滑动窗口向后移动，继续发送第五段数据，依次类推。操作内核为了维护滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据莫有应答，只有确认应答过的数据才能从缓冲区删掉。窗口越大，则网络的吞吐率越高。

如果出现丢包，如何进行重传

数据包已经到达，ACK丢失。部分ACK丢失并不要紧，因为可以通过后续的ACK进行确认。每一条确认回复中的确认序号，都要保证之前的数据已经完全收到，避免因ACK丢失导致数据重传。
数据包直接丢失。接收方收到第二条数据，但是莫有收到第一条，则认为是第一条数据丢失，则立即发送连续3次重发请求。因避免网络延迟，导致数据重传。

1.2流量控制
TCP支持根据接收端的处理能力，来决定发送端的发送速度。
通过协议字段中的窗口大小（不会大于接受方的接受缓冲区中剩余空间大小）字段控制发送方式发送数据报大小，避免因发送过快而接受方数据处理慢导致接受缓冲区的数据放满后，大量数据丢失重传问题。窗口大小在每次数据确认回复之前的时候进行重新商定。
1.3拥塞控制
网络通信开始，并不会直接发送窗口大小的数据，而是以一种慢启动，快增长的方式进行数据传输，起到一个网络探测作用，摸清网络拥堵状态，再决定按照多大的速度传输数据，避免开始通信时因网络状况的不好导致的发送数据越多，数据丢失也越多的问题。在快增长的过程中，若是出现丢包则初始化拥塞窗口大小，重新开始探测网络状况。
1.4.延迟应答
接收方接受数据若是立即回复，则窗口大小会降低，会导致传输速度降低，因此接受方接受到的数据后，并不是立即回复，而延迟了一会（不超过500ms），在这期间，用户又可能将数据从接收缓冲区取出，可以尽最大能力保证窗口的大小，保证数据传输速度不会降低。窗口越大，网络吞吐量就越大，传输效率就越高。

那么所有的包都可以延迟吗？ 肯定不是啊！