JavaEE: 深入探索TCP网络编程的奇妙世界(一)

文章目录

TCP
- TCP协议段落格式
- TCP相关机制
- - TCP核心机制一: 确认应答
  - - 32位序号
    - 32位确认序号
    - 后发先至问题

TCP

TCP要比UDP更复杂一些~

TCP的全称为"传输控制协议".他负责对数据的传输进行一个详细的控制.

TCP协议段落格式

在这里插入图片描述

源/目的端口号: 表示数据是从哪个进程来.到哪个进程去.
32位序号/32位确认号: 后面再说~
4位首部长度: TCP报头的长度.表示该TCP头部有多少个32bit(有多少个4字节).

UDP协议报头固定就是8个字节.
对于TCP来说,它的报头长度是可变长的.(后面再说)
6位标志位:
- URG: 紧急指针是否有效
- ACK: 确认号是否有效
- PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走
- RST: 对方要求重新建立连接,我们把携带RST标识的称为复位报文段.
- SYN: 请求建立连接,我们把携带SYN标识的称为同步报文段
- FIN: 通知对方,本端要关闭了,我们称携带FIN标识的为结束报文字段
16位窗口大小: 后面再说
16位校验和: 发送端填充,CRC校验.接收端校验不通过,则认为数据有问题,此处的校验和不光包含TCP首部,也包含TCP数据部分.
16位紧急指针: 标识哪部分数据是紧急数据.
选项: 40字节头部选项,暂时忽略.

TCP相关机制

TCP最核心的机制,就是"可靠传输".

可靠传输不能做到"100%"送达,只能尽可能的使数据到达对方.

能感知到对方是否收到
如果发现对方没收到,就要进行重试.

TCP核心机制一: 确认应答

接收方收到数据之后,就要给发送方返回一个"应答报文"(ack/acknowledge)

TCP引入了序号和确认序号,来使应答报文和传输的数据能够对应上.

由于TCP是面向字节流的,此处的序号不是按照"一条两条"编号,而是按照"字节"进行编号的.
对于一个TCP数据报来说,知道了数据部分的第一个字节序号,就知道了后续所有字节的序号~
序号只是针对TCP数据报携带的载荷来进行编号的.(TCP报头不参与)

32位序号

在这里插入图片描述
32位序号,也就是4个字节,它能表示的范围是0~42亿9千万.也就是0~4GB.
这是否意味着,一个TCP数据报,最大就只能传输4GB呢?

当然不是,首先,TCP进行传输时,一次传输的基本单位不是一个TCP数据报.
不要忘了,TCP是字节流的.
一个TCP数据报,和下一个TCP数据报携带的数据,天然就是可拼接的.

比如要传输一个特别大的数据.
在传输过程中,本身就会通过多个TCP数据报来进行携带.
这些TCP数据报彼此之间携带的载荷都是可以在接收方自动被拼接起来的.

这就不像UDP那样存在传输上限~
使用UDP传输大数据,就要考虑,调用这一次send操作,参数是否超过64kb,超过64kb就不行.

使用TCP的话,就没关系,可以调用一次write,也可以调用多次write(无论怎么进行write,在网络传输和对端接收角度来看都是没差别的)

假设多次write,传输的总数据量,超过上述4GB也没关系,咱们这里的数据序号是可以从0重新设置的.

32位确认序号

在这里插入图片描述

TCP将每个字节的数据都进行了编号,即为序列号.

在这里插入图片描述

对于应答报文来说,确认序号就会按照收到的数据的最后一个字节的序号+1的方式来填写.

另外,六个标志位中,第二位(ACK),会设为1.

对于普通报文,ack是0
对于应答报文,ack是1

在这里插入图片描述

如果是普通报文,序号是有效的,确认序号是无效的.
如果是ack应答报文,序号和确认序号都是有效的.

这是另一套编号的体系,和传输数据的序号不是同一套的.

后发先至问题

什么是后发先至?
举个例子,我跟朋友发短信.
在这里插入图片描述

虽然朋友先发的"好啊",后发的"不行,有事",但是网络传输过程中,可能存在"后发先至".
对于我接收方来说,可能先收到"不行,有事"后收到"好啊".
此时歧义就出现了,我认为朋友有事,不能开黑,但是明天可以去北京.而朋友认为能开黑,但是明天有事,不能去北京.

后发先至是客观的情况,无法改变.

为了解决上述问题,TCP就针对接收方收到的数据,进行了重新排序.确保应用程序读取到的数据一定是和发送方的数据顺序是一致的!

更具体一点: A为发送方,B为接收方.
在这里插入图片描述
B接收方这边调用read的时候如果没有数据,就会阻塞等待.
当1001-2000这个数据先到了B时,B不会让read解除阻塞.
直到1-1000这个数据到达之后,read才会解除阻塞,才会读取到1-1000,1001-2000数据.
这样就确保了发送方write顺序和接收方read的顺序始终是保持一致的.