0


TCP协议

  • 🎥 个人主页:Dikz12
  • 📕格言:那些在暗处执拗生长的花,终有一日会馥郁传香
  • 欢迎大家👍点赞✍评论⭐收藏

TCP原理

TCP对数据传输提供的管控机制,主要体现在两个方面:安全和效率
这些机制和多线程的设计原则类似:保证数据传输安全的前提下,尽可能的提高传输效率

TCP相关特性

  1. 有连接
  2. 可靠传输
  3. 面向字节流
  4. 全双工

可靠传输,是TCP最核心的特性!

a)发送方发出去数据之后,能够知道接收方是否收到数据。

b)发现对方没收到,就可以通过一些手段进行“补救”。

可靠传输

确认应答(安全机制)

发送方,把数据发送给接受方之后,接收方收到数据就会给发送方返回一个应答报文(ack).

发送方,如果收到这个应答报文,就知道自己的数据发送成功. (ack就在六个标志位中)

图一:还是比较理想的情况。

网络传输是很复杂的,一个数据包在传输的过程中,走的路线可能是很复杂的,不同的数据包,走的路线可能不同。就会出现图二情况,ack和发送的数据对不上,顺序也乱了。

为了避免出现图二的情况,TCP协议就引入序号 确认序号来解决问题。

这个工做是32位序号 和 32位确认序号来做的.

1.保证ack和发送的数据,能对上号.

2.保证出现后发先至情况,仍然能按照正确的顺序来理解数据.

超时重传(安全机制)

确认应答描述了一个网络传输比较理想的情况;如果网络传输的过程中,出现丢包的情况?那么 发送方就无法收到ack了. 就可以使用超时重传机制了。

tcp传输过程中,丢包就存在两种情况:

1.传输的数据丢了

2.返回的ack丢了.

站在发送方的角度上看,是无法区分两面这两中情况的. 也就是无论出现那种情况,发送方都会进行“重新传输数据” 。这种重传机制,第一次重传,等待之后,ack还没有到达,第二次,等待时间会比第一次的时间更长,如果进行若干次后,时间长度达到一定的程度,就会放弃tcp的连接。

连接管理 (建立连接+断开连接)

a)建立连接

建立连接:也就是tcp的三次握手,需要通信双方一共打“三次招呼”才能建立连接.

比如:A 想和 B 建立连接,A就会主动发起握手操作,会发一个特殊的TCP数据包(syn),不携带任何业务数据的。(syn:同步报文段,在tcp协议报文的六个标志位中).

为什么不能二次握手 或者 四次握手呢?

举个例子:假如我有女朋友,要连麦打游戏。

答:不能二次握手,接收方无法确认是自己的发送能力还是发送方的接受能力有问题!!

四次握手:可以但没必要,syn 和 ack 都是有内核响应的,两个数据可以结合在一起发送,效率更高!!

** 三次握手的作用**

**b)断开连接 **

断开连接:也就是四次挥手操作。断开连接,客户端和服务器都可以主动发起,一般都是客户端主动发起的;(FIN:结束报文段)

此时的四次挥手能否跟前面的三次握手一样把中间两次合并一起发送呢?

**答: **不能合并,因为ACK 和 第二个 FIN的触发时机时是不同的。ACK是内核响应的,收到A发送的FIN,就会立即返回ACK;而第二个FIN是应用程序答的代码触发的,B这边调用了close()方法。才会触发。

为了避免最后一个ACK丢失,在A收到FIN后不会立刻断开,而是进入 TIME_WAIT的状态。

如果最后一个ACK丢了,站在B的角度,B机会触发超时重传,如果A没有TIME_WAIT这个状态,意味着真的释放连接了,没人处理FIN,没人返回ACK了。B永远也收不到ACK.

滑动窗口机制(效率)

TCP的可靠传输,是会影响传输的效率的.(有好处肯定也会有弊端)多出了一些等待ack的时间,而滑动窗口,就是为了TCP在可靠传输的基础上,提高一些传输效率.

滑动窗口:批量传输数据。

  • 窗口大小:指的是无需等待确认应答而可以继续发送数据的最大值
  • 窗口滑动:收到第一个ACK后,滑动窗口向后移动,继续发送第五个段的数据;回来一个ack,就发一个,而不是等所有ack回来。
                            如果出现丢包问题,又如何进行重传? 

情况一:ack丢了 .

确认序号表示的含义:当前序号之前的数据,已经确认收到了.下次从确认序号这里,继续发送.

情况二:数据包丢了.

  • 当某一段报文段丢失之后,发送端会一直收到 1001 这样的ACK,就像是在提醒发送端 "我想要的是 1001" 一样;
  • 如果发送端主机连续三次收到了同样一个 "1001" 这样的应答,就会将对应的数据 1001 -2000 重新发送;
  • 这个时候接收端收到了 1001 之后,再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了,被放到了接收端操作系统内核的接收缓冲区中

这种机制被称为 "高速重发控制"(也叫 "快重传").

流量控制(安全机制)

站在接收方的角度,反向制约发送方的传输速率.发送方的发送速率,不应该超过接受方的接受能力。

16位窗口大小:接收缓冲区剩余空间大小。(这里最大不只有64kb,在tcp报头中,选项里有有一个叫“窗口扩展因子”,通过这个可以变成一个更大的值)。

拥塞控制(安全机制)

虽然TCP有了滑动窗口这个大杀器,能够高效可靠的发送大量的数据。但是如果在刚开始阶段就发送大量的数据,仍然可能引发问题。

流量控制:考虑的是接收方处理数据的能力;

拥塞控制:考虑的是在通信过程中的中间节点的情况;

拥塞控制,归根结底是TCP协议想尽可能快的把数据传输给对方,但是又要避免给网络造成太大压力的折中方案。
TCP拥塞控制这样的过程,就好像 热恋的感觉。

延时应答(效率)

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

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

捎带应答 (效率)

面向字节流

TCP是面向字节流的机制,如果同时有多个应用层数据包传输过来,就会有一个重要的问题--粘包问题。

粘包问题

                                                解决粘包问题 
  1. 引入分隔符.

2.引入长度.

标签: 计算机网络

本文转载自: https://blog.csdn.net/m0_65465009/article/details/136410040
版权归原作者 Dikz12 所有, 如有侵权,请联系我们删除。

“TCP协议”的评论:

还没有评论