【JavaEE初阶】 TCP协议详细解析

蔚落 2024-04-17 10:43 105阅读 0赞

#### 文章目录 ####

*  ?TCP协议的概念
 *   *  ?TCP协议段格式
     *  ?TCP的特性
 *  ?TCP原理
 *   *  ?确认应答机制（安全机制）
     *  ?超时重传机制（安全机制）
     *  ?三次握手四次挥手（安全机制）
     *  ?滑动窗口（效率机制）
     *  ?流量控制（安全机制）
     *  ?拥塞控制（安全机制）
     *  ?延迟应答（效率机制）
     *  ?捎带应答（效率机制）
 *  ?面向字节流的粘包问题
 *   *  ?思考：
 *  ?TCP异常情况
 *  ?TCP小结
 *   *  ?基于TCP应用层协议
 *  ⭕总结

## ?TCP协议的概念 ##

TCP（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。

### ?TCP协议段格式 ###

![在这里插入图片描述][6c6ca40fc7cb4ff6ab43c455a917600f.png]

*  源/目的端口号：表示数据是从哪个进程来，到哪个进程去；
 *  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字节头部选项：这里博主不做讲解

### ?TCP的特性 ###

*  TCP提供一种面向连接的, 可靠的字节流服务;
 *  在一个TCP连接中，仅有两方进行彼此通信。广播和多播不能用于TCP;
 *  TCP使用校验和, 确认和重传机制来保证可靠传输;
 *  TCP使用累积确认
 *  TCP使用滑动窗口机制来实现流量控制，通过动态改变窗口的大小进行拥塞控制

上述特性，在下面的TCP原理里面回进行一一介绍

## ?TCP原理 ##

TCP对数据传输提供的管控机制，主要体现在两个方面：安全和效率。

这些机制和多线程的设计原则类似：***保证数据传输安全的前提下，尽可能的提高传输效率***。

### ?确认应答机制（安全机制） ###

确认应答机制图示如下  
![在这里插入图片描述][0b1221823ba849c48ab37d1bbe762eea.png]  
单看这一幅图还是比较懵逼的，接下来我为大家解答一下

我们知道TCP是属于可靠传输，它就为了解决UDP不可靠传输而发明的。我们有了确认应答机制后，我们每发送一个消息，都能收到对方的一个回应，确保自己知道自己的消息发过去了。

> 就像一个小伙子给他女神发消息说“我请你吃饭好吗？”，然后收到了女神的回复“好啊好啊”，小伙的请求收到了确认![在这里插入图片描述][b7ff0e6e4b804844a7b3b4d40e4d44e5.png]

在这个传输过程中了，我们用上述提到的ACK来表示请求和应答报文

*  ACK=0，表示是发送报文
 *  ACK=1，表示是应答报文

但是光有确认应答还是不够，比如出现以下情况

> 小伙子对女神说“我请你吃饭好吗？”，然后这时候女生还没有回复，然后小伙又发了一句“做我女朋友好吗？”，这时候女神回消息了，回了两句为“滚”，“好啊好啊”  
> ![在这里插入图片描述][d1798ec817ce4a5f985d4ce0778e7ec3.png]  
> 那么这时候的小伙就懵了，小伙就想
> 
>  *  女神是现在不想吃饭，给我发了一句滚，她还是愿意做为我的女朋友的
>  *  女神不想做我女朋友，但是想和一起吃饭
> 
> 这时候的小伙也就迷茫了，女神到底什么意思呢?

这时候我们为了解决这一类问题，我们引入一个序号和确认序号，发送数据是带上序号，确认应答时也带上一个确认序号一一对应  
![在这里插入图片描述][34ccd634eae64aeba77c682de51d0da3.png]  
做法不同的是

TCP将每个字节的数据都进行了编号。即为序列号  
![在这里插入图片描述][02b19d6a16e24563b72e6a603e53649e.png]  
每一个ACK都带有对应的确认序列号，意思是告诉发送者，我已经收到了哪些数据；下一次你从哪里开始发。

这样就保证了确认应答不会出错

### ?超时重传机制（安全机制） ###

有了确认应答后，我们的可靠性已经得到大大的提升，但是UDP中出现的丢包问题还是没有得到解决

意思也就是主机A向主机B发送数据，一定时间后，并没有收到应答，这里主机A没有收到应答报文有两种情况

1.  主机A发送数据给B之后，可能因为网络拥堵等原因，数据无法到达主机B
2.  主机B收到主机A的数据之后，做出应答后，应答报文没有到达主机A

这两种情况都当成第一种情况处理，客户端会进行重传数据  
![在这里插入图片描述][1a793a9b4938405498f4656b311ffa65.png]  
![在这里插入图片描述][980cb7aae7e4462aa962cc110595f894.png]

这时候有的人可能会想，如果是第一种情况，重传数据就好，但是如果出现第二种情况，那么这些数据不是相同了吗，不就出现数据重复了吗？

这时候我们可以利用前面提到的序列号，其实我们这里的主机B这里接收就像一个优先级的队列，我们会对传来的数据按照序列号进行排序，如果序列号相同，该队列还可以起到一个去重的效果

那么我们又会想超时的时间如何确定？

*  最理想的情况下，找到一个最小的时间，保证 “确认应答一定能在这个时间内返回”。
 *  但是这个时间的长短，随着网络环境的不同，是有差异的。
 *  如果超时时间设的太长，会影响整体的重传效率；
 *  如果超时时间设的太短，有可能会频繁发送重复的包；

TCP为了保证无论在任何环境下都能比较高性能的通信，因此会动态计算这个最大超时时间

>  *  Linux中（BSD Unix和Windows也是如此），超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。
>  *  如果重发一次之后，仍然得不到应答，等待 2\*500ms 后再进行重传。
>  *  如果仍然得不到应答，等待 4\*500ms 进行重传。依次类推，以指数形式递增。
>  *  累计到一定的重传次数，TCP认为网络或者对端主机出现异常，强制关闭连接。

### ?三次握手四次挥手（安全机制） ###

由于这里内容较多，我单独写了一篇进行介绍，大家可以博主写的《[【JavaEE初阶】 TCP三次握手四次挥手（超详细版）][JavaEE_ TCP]》进行学习观看。

### ?滑动窗口（效率机制） ###

关于该部分的内容博主在《[【JavaEE初阶】 TCP滑动窗口与流量控制和拥塞控制][JavaEE_ TCP 1]》有详细讲解。

### ?流量控制（安全机制） ###

关于该部分的内容博主在《[【JavaEE初阶】 TCP滑动窗口与流量控制和拥塞控制][JavaEE_ TCP 1]》有详细讲解。

### ?拥塞控制（安全机制） ###

关于该部分的内容博主在《[【JavaEE初阶】 TCP滑动窗口与流量控制和拥塞控制][JavaEE_ TCP 1]》有详细讲解。

### ?延迟应答（效率机制） ###

如果接收数据的主机立刻返回ACK应答，这时候返回的窗口可能比较小

>  *  假设接收端缓冲区为1M。一次收到了500K的数据；如果立刻应答，返回的窗口就是500K；
>  *  但实际上可能处理端处理的速度很快，10ms之内就把500K数据从缓冲区消费掉了；
>  *  在这种情况下，接收端处理还远没有达到自己的极限，即使窗口再放大一些，也能处理过来；
>  *  如果接收端稍微等一会再应答，比如等待200ms再应答，那么这个时候返回的口大小就是1M；

注意：一定要记得，窗口越大，网络吞吐量就越大，传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率；

那么所有的包都可以延迟应答么？肯定也不是，是存在一定限制的

>  *  数量限制：每隔N个包就应答一次；
>  *  时间限制：超过最大延迟时间就应答一次；

具体的数量和超时时间，依操作系统不同也有差异；一般N取2，超时时间取200ms  
![在这里插入图片描述][b98bdaea013f47a2b285929132c6f787.png]

### ?捎带应答（效率机制） ###

在延迟应答的基础上，我们发现，很多情况下，客户端服务器在应用层也是 “一发一收” 的。

意味着客户端给服务器说了 “How are you”，服务器也会给客户端回一个 “Fine, thank you”；

那么这个时候ACK就可以搭顺风车，和服务器回应的 “Fine，thank you” 一起回给客户端  
![在这里插入图片描述][0bc20c3c35c1413bb7fa1b0c39a1dba7.png]

## ?面向字节流的粘包问题 ##

首先我们需要明确的是

我们在开发中，创建一个TCP的socket，同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区

>  *  调用write时，数据会先写入发送缓冲区中；
>  *  如果发送的字节数太长，会被拆分成多个TCP的数据包发出；
>  *  如果发送的字节数太短，就会先在缓冲区里等待，等到缓冲区长度差不多了，或者其他合适的时机发送出去；
>  *  接收数据的时候，数据也是从网卡驱动程序到达内核的接收缓冲区；
>  *  然后应用程序可以调用read从接收缓冲区拿数据；
>  *  另一方面，TCP的一个连接，既有发送缓冲区，也有接收缓冲区，那么对于这一个连接，既可以读数据，也可以写数据。这个概念叫做 全双工

由于缓冲区的存在，TCP程序的读和写不需要一一匹配，例如：

>  *  写100个字节数据时，可以调用一次write写100个字节，也可以调用100次write，每次写一个字节；
>  *  读100个字节数据时，也完全不需要考虑写的时候是怎么写的，既可以一次read 100个字节，也可以一次read一个字节，重复100次；

那什么是粘包问题呢？

>  *  首先要明确，粘包问题中的 “包” ，是指的应用层的数据包。
>  *  在TCP的协议头中，没有如同UDP一样的 “报文长度” 这样的字段，但是有一个序号这样的字段。
>  *  站在传输层的角度，TCP是一个一个报文过来的。按照序号排好序放在缓冲区中。
>  *  站在应用层的角度，看到的只是一串连续的字节数据。
>  *  那么应用程序看到了这么一连串的字节数据，就不知道从哪个部分开始到哪个部分，是一个完整的应用层数据包。

那么如何避免粘包问题呢？归根结底就是一句话，明确两个包之间的边界

*  对于定长的包，保证每次都按固定大小读取即可；例如上面的Request结构，是固定大小的，那么就从缓冲区从头开始按sizeof（Request）依次读取即可；
 *  对于变长的包，可以在包头的位置，约定一个包总长度的字段，从而就知道了包的结束位置；
 *  对于变长的包，还可以在包和包之间使用明确的分隔符（应用层协议，是程序猿自己来定的，只要保证分隔符不和正文冲突即可）

### ?思考： ###

对于UDP协议来说，是否也存在 “粘包问题” 呢？

>  *  对于UDP，如果还没有上层交付数据，UDP的报文长度仍然在。同时，UDP是一个一个把数据交付给应用层。就有很明确的数据边界。
>  *  站在应用层的站在应用层的角度，使用UDP的时候，要么收到完整的UDP报文，要么不收。不会出现"半个"的情况。

## ?TCP异常情况 ##

进程终止：进程终止会释放文件描述符，仍然可以发送FIN。和正常关闭没有什么区别。

机器重启：和进程终止的情况相同。

机器掉电/网线断开：接收端认为连接还在，一旦接收端有写入操作，接收端发现连接已经不在了，就会进行reset。即使没有写入操作，TCP自己也内置了一个保活定时器，会定期询问对方是否还在。

如果对方不在，也会把连接释放。另外，应用层的某些协议，也有一些这样的检测机制。

例如HTTP长连接中，也会定期检测对方的状态。例如QQ，在QQ断线之后，也会定期尝试重新连接

## ?TCP小结 ##

为什么TCP这么复杂？因为要保证可靠性，同时又尽可能的提高性能。

*  可靠性：
 *   *  校验和
 *   *  序列号（按序到达）
 *   *  确认应答
 *   *  超时重发
 *   *  连接管理
 *   *  流量控制
 *   *  拥塞控制
 *  提高性能：
 *   *  滑动窗口
 *   *  快速重传
 *   *  延迟应答
 *   *  捎带应答
 *  其他：
 *   *  定时器（超时重传定时器，保活定时器，TIME\_WAIT定时器等）

### ?基于TCP应用层协议 ###

*  HTTP
 *  HTTPS
 *  SSH
 *  elnet
 *  FTP
 *  SMTP

当然，也包括你自己写TCP程序时自定义的应用层协议；

## ⭕总结 ##

关于《【JavaEE初阶】 TCP协议详细解析》就讲解到这儿，感谢大家的支持，欢迎各位留言交流以及批评指正，如果文章对您有帮助或者觉得作者写的还不错可以点一下关注，点赞，收藏支持一下！

[6c6ca40fc7cb4ff6ab43c455a917600f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/14/3445c0d00fe14b70adc84647f53eb7f1.png
[0b1221823ba849c48ab37d1bbe762eea.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/14/941da9887fd54db294e1c792f9ac490a.png
[b7ff0e6e4b804844a7b3b4d40e4d44e5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/14/8ca9cfda79144602ac976b84680becf5.png
[d1798ec817ce4a5f985d4ce0778e7ec3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/14/0139b9d9ac4e4ec7a843efc936fcf613.png
[34ccd634eae64aeba77c682de51d0da3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/14/8591b5eaf3374c93bb27df1510118f27.png
[02b19d6a16e24563b72e6a603e53649e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/14/96912607e5cf4b259ba1ba9310c90e19.png
[1a793a9b4938405498f4656b311ffa65.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/14/432022c85fd245bb96130f0e11e39b14.png
[980cb7aae7e4462aa962cc110595f894.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/14/5614f0abd3444b7f96db5dd24d03c84b.png
[JavaEE_ TCP]: https://blog.csdn.net/m0_71731682/article/details/134299638?spm=1001.2014.3001.5502
[JavaEE_ TCP 1]: https://blog.csdn.net/m0_71731682/article/details/134349362?spm=1001.2014.3001.5501
[b98bdaea013f47a2b285929132c6f787.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/14/299da4059b384fa696664a1573d22760.png
[0bc20c3c35c1413bb7fa1b0c39a1dba7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/14/46a876e342194c37a7c767bd1b6efe4f.png