TCP协议

安全机制

确认应答机制

超时重传机制

连接管理机制

三次握手

四次挥手

流量控制机制

编辑拥塞控制机制

效率机制

滑动窗口机制

延迟应答机制

捎带应答机制

TCP协议

· 传输层的作用负责数据能够从发送端到接收端，TCP协议是传输层的一个重点协议.

· TCP即传输控制协议，它需要对数据的传输进行一个详细的控制

· TCP对数据传输提供的管控机制，主要体现在安全和效率，这些机制与多线程的设计原则类似，在保证安全的前提下尽可能地提高效率.

TCP协议段格式

· 源/目的端口号：表示数据是哪个进程发送，哪个进程接收

· 4位TCP报头长度：表示该TCP头部有多少个32位bit(即有多少个4字节)，TCP头部最大长度为60(15 * 4)

· 6位标志位，boolean值，0/1数据.

ACK：确认号是否有效(应答)

SYN：请求建立连接，把携带SYN标识的称为同步报文段

FIN：申请断开连接，把携带FIN表示的称为结束报文段

安全机制

确认应答机制

发送的数据，接收端需要返回确认接收到数据报的应答

TCP将每个字节的数据都进行了编号(序列号)，并使用32位序号保存

每一个ACK都带有对应的确认序列号，它的目的是告诉发送端，接收端已经收到了哪些数据，下一次你应该从哪里开始发.

超时重传机制

发送端超过一定时限没有收到ACK应答包，就会发生重传。

· 时限是动态的，跟网络环境有关

· 没有收到ACK应答包的原因：①发送数据丢包、ACK应答包丢包

· 重传：发送的数据包才重新发送

例如上图中，主机A发送数据给主机B后，可能因为网络拥堵等原因，数据无法到达主机B，此时B没有收到A发送的数据包就不会确认应答，主机A在一个特定时间间隔内没有收到主机B发来的确认应答，就会重新发送数据.

主机A未收到主机B发来的确认应答，也可能是因为ACK的丢失

此时主机B就会收到主机A重新发来的数据包，此时TCP协议就需要识别出这重复的数据报，并把重复的包丢掉，根据序列号，就可以做到去重.

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

· Linux、Unix、Windows中，超时以500ms为一个单位进行控制，每次判定超时重发的时间都是500ms的整数倍

· 如果重发一次后，仍然得不到应答，就等待2 * 500ms后再次重发，如果还是得不到应答，就间隔4 * 500ms再重发，以指数形式递增

· 累计到一定的重传次数后，TCP认为网络或者对端主机出现异常，就会强制关闭连接

连接管理机制

在正常情况下，TCP要经过三次握手建立连接，四次挥手断开连接

三次握手

三次握手时TCP建立连接，其本质是双方都保存了一个连接状态ESTABUSHED.

` SYN：连接请求/接收报文段

· seq：发送的第一个字节的序号

· ACK：确认报文段

· ack：确认号，希望收到的下一个数据的第一个字节的序号

刚开始客户端处于Closed状态，服务端处于Listen状态

① 第一次握手：客户端向服务端发送一个SYN报文(SYN = 1)，并指明客户端的初始化序列号ISN(x)，即图中的seq = x，表示本报文段所发送的数据的第一个字节的序列号，此时客户端处于SYN_SENT状态(发送连接请求后等待匹配的连接请求)

② 第二次握手：服务端在接收到客户端发送的请求报文段后，会向客户端发送确认报文，在确认报文段中将SYN和ACK置为1，确认号ack = x + 1，同时也为自己选择与i个初始化序列号ISN(y)，seq = y，此时服务端处于SYN_RCVD状态(在收到和发送一个连接请求后等待对连接请求的确认)

③ 第三次握手：客户端在收到服务端的确认后，还要再向服务端给出确认，确认报文段ACK位置为1，把服务端的ISN + 1作为ack的值，表示已经收到了服务端发来的SYN报文，希望收到的下一个数据的第一个字节的序号是y+1，并指明此时客户端的序列号seq = x + 1(因为初始时的seq = x，所以第二个报文段要+1)，此时客户端处于Established状态.服务端在收到ACK报文后，也处于Established状态，至此，双方都建立起了TCP连接.

四次挥手

· FIN：连接终止位

· seq：发送的第一个字节的序号

· ACK：确认报文段

· ack：确认号

① 第一次挥手：客户端发送一个FIN报文(请求终止连接：FIN = 1)，报文中会有一个指定序列号seq = u.并停止发送数据，主动关闭TCP连接，此时客户端处于FIN_WAIT_1状态，等待服务端的确认

② 第二次挥手：服务端收到FIN后，会对客户端发送ACK报文，并把客户端的序列号+1作为ACK报文的序列号值，表明已经收到了客户端的报文，此时客户端处于CLOSE_WAIT状态.

此时的TCP进入半关闭状态，客户端到服务端的连接释放.客户端收到服务端的确认后，进入FIN_WAIT_2(终止等待2)状态，等待服务端发出的连接释放报文段

③ 第三次挥手：如果服务端也想关闭连接，和客户端第一次挥手一样，发送FIN报文，并指定一个序列号此时服务端处于LAST_WAIT状态，等待客户端确认

④ 第四次挥手：客户端收到FIN后，一样发送一个ACK报文作为应答(ack = w + 1)，并把服务端的序列值+1作为自己ACK报文的序号值(seq = u + 1)，此时客户端处于TIME_WAIT状态

流量控制机制

接收端处理数据的速度是有限的，如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会发生丢包，进而引起丢包重传等一系列连锁反应.

TCP支持根据接收端的处理能力，来决定发送端的发送速度，这个机制就叫做流量控制机制

· 接收端将自己可以接收的缓冲区大小放在TCP首部中的“窗口大小”字段，通过ACK端通知发送端

· 窗口大小字段越大，说明网络的吞吐率越大

· 接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置为一个更小的值通知给发送端

· 发送端接收到这个窗口之后，就会降低发送速度

· 如果接收端缓冲区满了，就将窗口大小设置为0，这时发送端就不再发送数据了，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端

拥塞控制机制

网络状态不明的情况下，如果贸然发送大量数据报，就可能产生网络拥堵.TCP实现拥塞控制的方法：慢启动、拥塞避免、快重传、快恢复

· 慢启动：先发送少量数据，摸清当前的网络拥堵状态，再决定按照多大的速度传输数据

· 发送开始的时候，定义拥塞窗口大小为1

· 每次收到一个ACK应答，拥塞窗口+1

· 每次发送数据报的时候，将拥塞窗口和主机反馈的窗口进行比较，取较小的值作为实际发送的窗口

· 拥塞避免：当拥塞窗口增长达到慢开始门限值后，使拥塞窗口按照线性规律增长

· 当TCP开始启动时，慢启动的阈值等于窗口最大值

· 在每次超时重发(网络拥塞)的时候，慢启动的阈值会变成原来的一半，同时拥塞窗口置为1

· 快重传：当接收端发现丢了一个中间包的时候，立刻发送三次前一个包的ACK，当发送端连续收到三个重复确认，就会快速的重传，不必等待超时再重传.

· 快恢复：快速重传和快恢复一般同时使用，快恢复算法将拥塞窗口调整为原来的一半，即cwnd = cwnd / 2，并使拥塞阈值ssthresh = cwnd，有的快恢复算法是将快恢复开始时的拥塞窗口cwnd的值在增大一些，即cwnd = ssthresh + 3，因为发送方收到了3个重复的确认，就表明有三个分组已经离开了网络.之后再开始执行拥塞避免算法.

效率机制

滑动窗口机制

根据确认应答机制可知，发送端没发送一个数据段，接收端都需要给出一个ACK应答，收到ACK应答后再发送下一个数据段，这样做的话性能比较差，尤其是在数据往返时间较长的情况下.此时就引入了滑动窗口机制：每次发送多条数据，将多个段的等待时间重合在一起，这样就可以提高性能

发送端滑动窗口的大小 = Min(拥塞窗口，接收方流量窗口)

· 窗口大小是指无需等待确认应答而可以继续发送数据的最大值，上图的窗口大小就是4000个字节

· 发送前四个数据段时，不需要等待接收端的ACK应答，直接发送

· 在收到第一个ACK后，滑动窗口向下移动，继续发送第五个数据段，以此类推

· 操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有被应答.只有确认应答后的数据，才能从缓冲区删掉

· 发送窗口越大，网路的吞吐率越高

如果发生了丢包的情况，如何进行重传？

①如果发生了ack丢包：没有影响，后续的ack也能表示序号前的数据段全部被接收

②如果发送的数据报发生丢包的情况，使用快重传机制

例如下图中10001~2000这一段报文发生丢失，发送端就会一直收到确认号位1001的ACK应答，当连续收到三次同样的应答后，就会将对应的数据重新发送，这个时候接收端接收到1001~2000报文段后，就会返回7001，因为2001~7000接收端已经接收到了，被放到了操作系统内核的接收缓冲区中

延迟应答机制

接收端返回流量窗口代表缓冲区的可用空间大小，如果立刻返回就不划算，立即返回的流量窗口大小就比较小.而接收端的接受速度可能还是比较快的，即使窗口设置的更大一些，也能处理的过来.

延迟应答就是使接收端返回的流量窗口不是立刻返回，而是等待一定的时间再返回，这样返回的流量窗口的大小就可能更大.这样可以提高效率

延迟应答的条件：

①数量限制：每隔N个包就应答以此

②时间限制：超过最大延迟时间就应答一次

一般情况下，N取2，超时时间取200ms

捎带应答机制

不论是客户端还是服务端，每一端都可以是发送端，也可以是接收端

不论是客户端还是服务端，在接收到数据后返回ACK应答包(作为接收端)，可以和发送的数据报(作为发送端)合并在一起发送给对方

网络原理 | 传输层重点协议之TCP协议(TCP连接的三次握手与四次挥手、TCP的安全机制与效率机制)相关推荐

解析TCP连接之“三次握手”和“四次挥手”
葡萄美酒夜光杯,欲饮琵琶马上催. 醉卧沙场君莫笑,古来征战几人回?----唐 · 王翰 · <凉州词> 前言不管是面试别人还是被别人面试,有很大的可能会被问到TCP的"三次握手 ...
TCP 连接的“ 三次握手 ”与“ 四次挥手 ”
TCP 协议简介 TCP 是互联网核心协议之一,本文介绍它的基础知识. 一.TCP 协议的作用互联网由一整套协议构成.TCP 只是其中的一层,有着自己的分工. (图片说明:TCP 是以太网协议和 I ...
详解 TCP 连接的“三次握手”与“四次挥手”
详解 TCP 连接的"三次握手"与"四次挥手" 前言 TCP的三次握手(Three-Way Handshake) 1."三次握手"的详解 2 ...
TCP三次握手和四次挥手?TCP如何保证可靠性?什么是TCP滑动窗口?
TCP三次握手和四次挥手? 三次握手 tcp3handshake.gif tcp3handshake2.gif tcp3handshake3.gif tcp3handshake4.gif 四次挥手 t ...
TCP的连接和释放连接（三次握手和四次挥手的过程）
参考文章: javascript - 看图理解TCP的三次握手和四次挥手_个人文章 - SegmentFault 思否 TCP'三次握手'和'四次挥手'(通俗易懂)_大黄的Java笔记的博客-CSDN ...
三次握手和四次挥手图解_详解 TCP 连接的“三次握手”与“四次挥手”
作者 | AhuntSun 责编 | Elle TCP connection 客户端与服务器之间数据的发送和返回的过程当中需要创建一个叫TCP connection的东西: 由于TCP不存在连接的概念 ...
详解 TCP 连接的“ 三次握手 ”与“ 四次挥手 ”
作者 | AhuntSun 责编 | Elle TCP connection 客户端与服务器之间数据的发送和返回的过程当中需要创建一个叫TCP connection的东西: 由于TCP不存在连接的概 ...
Python常见面试题：TCP 协议中的三次握手与四次挥手相关概念详解
今天来聊聊Python常见面试题中面试频率特别高的一个题目:TCP 协议中的三次握手与四次挥手. 涉及到的知识点有: 1.TCP.UDP 协议的区别 2.TCP 头部结构 3.三次握手与四次挥手过程详 ...
tcp 协议中发送窗口的大小应该是_TCP 协议中的三次握手与四次挥手
今天来聊聊面试频率特别高的一个题目:TCP 协议中的三次握手与四次挥手.涉及到的知识点有: 1.TCP.UDP 协议的区别 2.TCP 头部结构 3.三次握手与四次挥手过程详解 4.什么是 TIME_ ...

网络原理 | 传输层重点协议之TCP协议(TCP连接的三次握手与四次挥手、TCP的安全机制与效率机制)

TCP协议

安全机制

确认应答机制

超时重传机制

连接管理机制

三次握手

四次挥手

流量控制机制

拥塞控制机制

效率机制

滑动窗口机制

延迟应答机制

捎带应答机制

网络原理 | 传输层重点协议之TCP协议(TCP连接的三次握手与四次挥手、TCP的安全机制与效率机制)相关推荐

最新文章

热门文章