JavaEE初阶----网络原理之TCP篇（一）

1.TCP的报头格式

1.1 基本结构

我们的这个TCP的格式如图所示，有一部分内容例如这个端口号这个这个校验和和我们的这个UDP就是类似的，但是因为这个传输方式很特殊，因此这个里面相较于我们之前学习的这个UDP还是有很大的区别的；

数据包===报头+载荷；

其实上面的这个图里面有这个4位首部长度，这个就是我们的报头内容；

1.2 报头长度

我们的这个TCP的报头不是确定的：最小是20字节，最长是60字节，这个区别主要就是因为这个选项导致的，因为我们的这个选项是可选地，如果有这个选项，选项是4字节作为一个单位；

1.3 4位首部长度

4位其实指的就是4个比特位，一个比特位表示的数据范围就是0-15（原理如下图所示—）：

1.4保留6位

这个就是我们留存一部分富裕的空间，如果后面需要我们就可以随时进行扩展，但是我们的UDP就是64kb大小空间，无法进行扩展，这个也是两者很重要的一个区别；

2.确认应答的机制

我们的数据进行传输的时候，被分为这个发送方和接受方；

我们的发送方把这个数据发送给我们的接收方之后，我们的这个接收方就会根据自己的接收到的数据返回去一个应答报文给我们的发送方；

应答报文：acknowledge的意思，其中这个就是简称为这个ack，因此我们平常说的这个ack实际上就是这个应答方根据这个发送方的数据做出来的回应；

因此，发送方如果收到了这个应答报文，这个就可以说明我们的这个接收方已经收到了这个来自于发送方的数据，因此才做出来回应，这个也是验证我们的数据是否发送成功的一个手段；

我们的这个应答报文是使用下面的这个字节进行编号的；

下面的这个案例可以让我们更好的理解这个应答报文的过程以及这个相关的机制（虽然有些不合适~~）但是很适合我们理解，不信你试试，我觉得你会感兴趣的：

我们给女神发信息：请女神出去吃麻辣烫，然后这个女神就会根据我们的这个发送的信息做出来具体的回应，例如下面的这个：好啊好啊；

但是我们的这个情况往往不是理想的，可能会出现下面的这个后发先至的情况，这个时候可能对于这个接收方的理解造成误解：

我们的女神的第二个回复被我们先收到，第一条信息的回复我们是后收到的，这个时候对于我们的理解就会造成影响；这个时候我们可以进行编号，让他们彼此之间进行对应，这样就不会造成误解的情况；

但是实际情况下，我们的这个应答不是按照一条两条的方式衡量的，而是使用字节进行衡量的：其实就是上面放过的一个图片，我们的数据从第一个字节序号（假设是从1开始的）依次进行类推；

3.对于可靠传输的解读

3.1什么是可靠传输

发送应答机制介绍：我们的这个发送方把1~1000数据发送给我们的接收方，这样的话我们的这个TCO报头的这个字节序号就是1，因为这个里面一共是1000字节，因此这个最后的数据序号就是1000,；我们的这个TCP报头里面记录的这个是我们的这个载荷的第一个字节的序号，其他的这个字节的序号，都是进行推理出来的；

我们的这个应答报文里面的这个确认序号字段就是我们的接受的最后一个字节序号+1进行应答，也就是说前面的1000数据我们已经收到的，我们让这个发送方从这个1001进行发送；

通过ack应答数据包，我们的这个数据包里面携带的这个确认序号发送之后，我们的这个发送方就知道自己发送的那些数据已经被收到了，那些是没有收到的（因为我们的这个应答报文的确认序号是接收到的数据最后一个字节+1）》》》》》这个就是可靠传输的原因；

确认应答机制是我们的TCP的最核心的机制，这个是我们的TCP支持可靠传输的原因；

TCP的可靠传输如何进行的：以确认应答机制为核心，借助其他的机制，最终可以完成可靠的传输；

3.2应答数据普通数据区分

我们的这个保留（6位）这个里面的ack就是一个区分：

如果这个ack是1，这个说明就是应答数据，否则就是普通的数据；

4.超时重传的机制

4.1超时重传的原理

我们的数据传输的过程中出现问题：就是丢包了，这个就是我们的超时重传机制出现的原因；

为什么会丢包，主要是因为我们的数据包如果很多，就会出现“堵车”的情况，对于堵车的处理，就会直接被丢掉，而不是不断地积压，这个方式很残暴，直接就会扔了，这个就是我们数据被丢包的原因；

下面的就是我们的这个丢包的两个情况：

一个就是接受方根本就没有收到数据；

一个就是我们的这个接收方收到了数据，但是进行应答的时候被丢了；

上面的两个情况都是让我们的这个发送方无法接收到这个应答报文；

出现上面的这个情况，我们就重新传输，两次传输成功的这个概率就会被大大提高（这个是一个数学问题，一次丢包的概率是10%，两次都丢包的概率就是1%，这个概率变化是很明显的）；

正是因为这个可靠性的原因，以及这个效率，重传的原因，这个性能就会被降低，当我们追求这个性能的时候，对于这个准确性没有太高的要求，这个时候就会选择UDP，这个也是我们的UDP依然存在的原因，因为有些地方对于这个可靠性没有太高的要求，而是追求效率的；

4.2等待时间的界定

我们的重传肯定是有一个等待时间的，等了多少时间，我们没有接收到这个应答报文，我们才会进行重传，但是这个等待时间是不确定的；

等待时间的拉长：我们第一次传递，没有等到应答，这个时候进行重传，我们等待10min，还是没有收到，第二次重传的时候这个等待时间就会变长，大于10min，但是这个时间不会无限的拉长；

当我们多次重传都没有收到应答，这个时候是会出发我们的TCP的重置链接，就是认为没有连接上，就会重新连接；

4.3去重机制的引入

就是我们去买东西，100元，这个时候我们支付，但是接收方没有收到，这个时候难道我们要去重传吗，肯定不会，因为这个意味着我们需要重新支付，怎么可能~~~

这个去重机制就是处理这个情况的：

TCP会有一个接受的缓冲区，在这个缓冲区里面，存储接收到的数据并且进行编号；

如果我们的这个接收方发现发来的这个数据在这个缓冲区里面已经有了，这个时候就会把后来的这个数据丢弃掉，因此我们只能读取到一个数据；

接收缓冲区不仅可以进行去重，也可以重新排序，确保发送顺序和我们的应用程序的读取顺序是一样的；

5.连接管理–三次握手&四次挥手

握手：传输没有实际意义的数据包；

挥手：发一个没有业务逻辑的数据包，方便进行后面的操作；

三次握手：打三次招呼，才可以建立连接；

5.1三次握手的过程

下面的这个就是进行三次握手的过程，sys表示的就是同步报文段，别是的就是没有业务逻辑的报文，就是为了握手，我们的这个B返回去一个ack和一个syn，这个是一起返回的，然后我们的这个A再返回一个ack给我们的B，这个就是三次握手的过程；

这样之后，我们的这个AB就有了彼此之间的这个信息，这个就是相当于建立了链接

5.2三次握手的核心作用

• 确认当前的这个网络是畅通的；

• 发送方，接收方都知道自己的这个发送，接受能力都是正常的；（这个其实就是接受能力，发送能力的一个反复地确认的过程）；

• 对于重要的参数，进行协商（这个参数其实有很多，但是我们起码要知道这个tcp进行通信的时候，这个通信的序号是从哪一个开始算的，这个需要就是我们的通信双方进行协商出来的）；

  例如我们的网络不是很好的时候，我们需要刷新进行重新连接，如果连接之后原来的数据发了过来，这样的迟到的数据，应该是被丢弃掉的，我们如何判断这个数据是属于上个朝代的，这个主要就是我们的上面说的传输数据的序号的确定实现的，我们判断这个数据和当前的数据编号的差异很大，这个时候我们就可以认为这个数据是上一个朝代的数据（就是我们进行重新连接之前的数据），这个时候我们就可以丢弃掉了；

样的迟到的数据，应该是被丢弃掉的，我们如何判断这个数据是属于上个朝代的，这个主要就是我们的上面说的传输数据的序号的确定实现的，我们判断这个数据和当前的数据编号的差异很大，这个时候我们就可以认为这个数据是上一个朝代的数据（就是我们进行重新连接之前的数据），这个时候我们就可以丢弃掉了；