TCP的安全和服从机制

打印 上一主题 下一主题

主题 971|帖子 971|积分 2923

目次
0.TCP协议格式
​编辑
一.确认应答(安全机制)
二.超时重传(安全机制)
1.SYN丢包
 2.ACK丢包
三.毗连管理(安全机制)
1.三次握手建立毗连
​编辑
2.四次挥手断开毗连
3.建立和断开毗连
四.滑动窗口(服从机制)
五.流量控制(服从机制)
六.拥塞控制(安全机制)
七.延长应答(服从机制)
八.捎带应答(服从机制)
九.面向字节流
1.粘包题目
2.具体的现象
 3.解决方案
1.在消息末端加上特殊的分隔符来标识消息的竣事
2.利用一个专门用来描述消息体长度的字段,来标识消息体的具体长度
十.TCP异常情况
1.步伐崩溃 
2.正常关机
3.主机掉电操纵
4.网线断开
十一.常晤面试题


0.TCP协议格式



 传输层协议

  • 源/目的端口号:表现数据是从哪个进程来,到哪个进程去;
  • 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  对数据传输提供的管控机制,主要表如今两个方面:安全和服从。     这些机制和多线程的计划原则雷同:保证数据传输安全的条件下,尽可能的进步传输服从。   
一.确认应答(安全机制)

假如我们给一个人发送多条信息,由于网络的题目,可能会出现,乱序的题目.好比我们发送两条信息:1.你好.2.吃了吗? 由于网络题目,可能会出现接收方先接受到了"吃了吗?",后接受到了"你好.",这样的情况我们是不想出现的,因此确认应答机制可以很好的解决这种题目.
 
 如下图,为相识决这种题目,每次发送消息的时候,TCP数据中的字节进行了编号,好比主机B接受到了1-1000byte的数据,32位序列号中1-1000标记已经接受到了1000个字节,确认序列号返回1001,表现下次从第1001个字节进行发送.

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

   每一个  ACK  都带有对应简直认序列号,意思是告诉发送者,我已经收到了哪些数据;下一次你从哪里开始发。      每次发消息的时候
将SYN置为1
  每次接受消息确认的时候,将ACK置为1
  二.超时重传(安全机制)

1.SYN丢包

主机A发送数据(SYN)给主机B,可能由于网络拥挤等原因,消息无法到达主机B,因此主机B也不会给主机A发送确认应发ACK.假如主机A特定时间内没有接收到主机B发送来简直认应答ACK,就会将上次的数据进行重发

 2.ACK丢包

主机B接受到了主机A的数据,并且发送了确认应答ACK,但是由于网络拥堵等原因,ACK发送了丢包,主机A并没有主机B发送来的ACK应答.
这个时候也会触发超时重传机制.由于我们发送的消息主机B已经接受到了主机A发送的数据,只不过ACK应答丢包.主机B没有须要存储重复的数据,因此第二次发送消息的时候(超时重传),可以利用前面提到的序列号(前面一次发送序列号已经保存,第二次发送的时候已经存在这个序列号了),就可以很容易做到去重的效果,主机B只需要发送一个确认应答的ACK就可以了.

三.毗连管理(安全机制)

   在正常情况下,  TCP  要颠末三次握手建立毗连,四次挥手断开毗连   1.三次握手建立毗连

对于网络通讯来说,三次握手可以查抄双发的收发能力是否正常,例如高铁每天都会空跑一趟.
从下图可以看出,通过两次SYN和ACK的过程可以确保双方的收发能力都没有题目,在这个基础上就可以进行正常的数据发送和接收


由于接收方的ACK和SYN可以归并为一次通讯完成(都是在传输层进行发送,在背面的捎带机制也有解说),进步了服从,四次握手可以简化为三次握手
 

三次握手标记位发生的变革

2.四次挥手断开毗连

发送方发送断开毗连,被接收方接收和应答,接收方会做一些断开前的预备工作.
一样平常来说FIN是由应用步伐发起的,好比调用close()方法,所以是应用层面的,之后接收到发送方ACK应答,服务器就可以开释资源

为什么断开毗连四次挥手不能转变为三次?
第一个ACK是操纵体系(传输层)实现的TCP应答,第二个FIN是应用步伐层面的,这两个操纵是偶然间差的,大概率是不会集并在一起的.
3.建立和断开毗连


   服务端状态转化:   

  • [CLOSED -> LISTEN] 服务器端调用listen后进入LISTEN状态,等待客户端毗连;
  • [LISTEN -> SYN_RCVD] 一旦监听到毗连请求(同步报文段),就将该毗连放入内核等待队列中,并向客户端发送SYN确认报文。
  • [SYN_RCVD -> ESTABLISHED] 服务端一旦收到客户端简直认报文,就进入ESTABLISHED状态,可以进行读写数据了。
  • [ESTABLISHED -> CLOSE_WAIT] 当客户端主动关闭毗连(调用close),服务器会收到竣事 报文段,服务器返回确认报文段并进入CLOSE_WAIT;
  • [CLOSE_WAIT -> LAST_ACK] 进入CLOSE_WAIT后阐明服务器预备关闭毗连(需要处理完之前的数据);当服务器真正调用close关闭毗连时,会向客户端发送FIN,此时服务器进入
  • LAST_ACK状态,等待最后一个ACK到来(这个ACK是客户端确认收到了FIN)
  • [LAST_ACK -> CLOSED] 服务器收到了对FIN的ACK,彻底关闭毗连。
   客户端状态转化:   

  • [CLOSED -> SYN_SENT] 客户端调用connect,发送同步报文段;
  • [SYN_SENT -> ESTABLISHED] connect调用乐成,则进入ESTABLISHED状态,开始读写数 据;
  • [ESTABLISHED -> FIN_WAIT_1] 客户端主动调用close时,向服务器发送竣事报文段,同时进入FIN_WAIT_1;
  • [FIN_WAIT_1 -> FIN_WAIT_2] 客户端收到服务器对竣事报文段简直认,则进FIN_WAIT_2,
  • 开始等待服务器的竣事报文段;[FIN_WAIT_2 -> TIME_WAIT] 客户端收到服务器发来的竣事报文段,进入TIME_WAIT,并发出LAST_ACK;
  • [TIME_WAIT -> CLOSED] 客户端要等待一个2MSL(Max Segment Life,报文最大生存时 间)的时间,才会进入CLOSED状态。
四.滑动窗口(服从机制)

   刚才我们讨论了确认应答策略,对每一个发送的数据段,都要给一个  ACK  确认应答.收到  ACK  后再发送下一个数据段.这样做有一个比较大的缺点,就是性能较差.尤其是数据来回的时间较长的时候.  

 因此,我们计划了滑动窗口,一次发送特定命目的数据,可以大大进步服从.下面的案例窗口的大小为4,即一次可以发送四条SYN请求,当主机A接收到主机B发送的ACK应答的时候,滑动窗口向下进行移动,此时可以发送下一条的数据(4001--5000).



  • 窗口大小指的是无需等待确认应答而可以继承发送数据的最大值。上图的窗口大小就是4000个字节(四个段)。
  • 发送前四个段的时候,不需要等待任何ACK,直接发送;
  • 收到第一个ACK后,滑动窗口向后移动,继承发送第五个段的数据;依次类推;
  • 操纵体系内核为了维护这个滑动窗口,需要开辟 发送缓冲区 来记载当前还有哪些数据没有应答;只有确认应答过的数据,才能从缓冲区删掉;
  • 窗口越大,则网络的吞吐率就越高;
  • 假设窗口无穷大,这个时候就服从就相当于UDP了.

那假如发生了丢包的题目,该如何解决呢?下面还是分两种情况进行思量.
 情况一:数据包已经抵达,ACK被丢了。
这种情况下,部门ACK丢包了不要紧,可以根据背面的ACK进行确定.
好比确定序列为1001的ACK丢包了,但是背面2001的ACK应答被主机A乐成接收了,我们可以根据这个应答确定前面的数据(1001)都已经接收了,因为假如没有接收到1--1000数据,序列号不会改变,就不会发送2001的ACK应答.
现实案例:别人问你学历,你说是初中,这阐明你已经上过小学了.

思量一下,假如最后一次ACK丢包,会发生什么情况?这个时候背面已经没有ACK应答了,因此这个时候我们只能触发超时重传完成最后一次的SYN和ACK应答.
 情况二:数据包就直接丢了。


  • 当某一段报文段丢失之后,发送端会不停收到 1001 这样的ACK,就像是在提醒发送端 "我想要的是 1001" 一样;
  • 假如发送端主机一连三次收到了同样一个 "1001" 这样的应答,就会将对应的数据 1001 -2000 重新发送;
  • 这个时候接收端收到了 1001 之后,再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了,被放到了接收端操纵体系内核的接收缓冲区中;
这种机制被称为 "高速重发控制"(也叫 "快重传")。 

五.流量控制(服从机制)

主要是确定滑动窗口的大小,通过发送方与接收方动态协商来确认
每个步伐在启动的时候都会去申请体系资源,发送和接收方缓冲区就是申请来的资源.

每次进行ACK应答的时候,ACK应答中将剩余空间的大小放在16位窗口大小,表现具体可以接收多少数据,通过接收方反制发送方对窗口大小的限定,发送方不能为了进步服从而无穷的扩展窗口的大小.

 假如接收方的处理能力比较低,可能会出现缓冲区装满的情况,这个时候窗口的大小变为0,这个时候发送方不能再发送数据给接收.

 解决窗口大小题目
   那么题目来了,  16  位数字最大表现  65535  ,那么  TCP  窗口最大就是  65535  字节么?     现实上,  TCP  首部  40  字节选项中还包含了一个窗口扩大因子  M  ,现实窗口大小是窗口字段的值左移   M  位;  六.拥塞控制(安全机制)

虽然TCP有了滑动窗口这个大杀器,可以或许高效可靠的发送大量的数据。但是假如在刚开始阶段就发送大量的数据,仍旧可能引发题目。
因为网络上有许多的计算机,可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下,贸然发送大量的数据,是很有可能引起雪上加霜的。
TCP引入 慢启动 机制,先发少量的数据,探探路,摸清当前的网络拥堵状态,再决定按照多大的速度传输数据;


  • 发送方第一次发送数据,窗口大小是1
  • 接下来每一次发送数据,窗口大小以指数扩大2 4 8 16
  • 当达到初始阈值时,不再以指数扩大,而是线性的方式增长,每次加1
  • 当窗口达到或个值时,出现了大量的丢包现象,也就是说频仍的出现超时重传,就阐明网络出现了堵塞
  • 拥塞窗口的大小直接回到最小值1,新的拥塞窗口阈值也会被调整=当前拥塞窗口值/2
  • 重复1-5步


具体窗口的大小以以下两个因素决定:①接收方缓存区的大小 ②拥塞控制中根据网络的状态确定下来的窗口大小       我们一样平常取两者的较小值作为现实窗口的大小
少量的丢包,我们仅仅是触发超时重传;大量的丢包,我们就认为网络拥塞;
当TCP通讯开始后,网络吞吐量会逐渐上升;随着网络发生拥堵,吞吐量会立即降落;
拥塞控制,归根结底是TCP协议想尽可能快的把数据传输给对方,但是又要避免给网络造成太大压力的折中方案。
七.延长应答(服从机制)

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


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

可以选择以下两种情况来进行延长应答:


  • 数目限定:每隔N个包就应答一次;
  • 时间限定:凌驾最大延长时间就应答一次;
好比我们可以每两次请求,应答一次,好比第2,4,6应答.假如是偶数次请求,可以完成应答,假如是奇数次应答,那么最后一次就接纳时间限定,凌驾一个体系默认的时间就应答.
八.捎带应答(服从机制)

由于延长应答的存在,可能存在SYN报文和ACK报文同时发送的情况那么体系就会把两个报文合二为一(这就是三次握手建立毗连可以把第一次ACK和第二次SYN归并在一起的原因)

九.面向字节流

1.粘包题目

在面向字节流中会出现的一个题目就是粘包题目
2.具体的现象

当发送方将数据发送给接受方的时候,发送的数据是以二进制(Java中的byte数组)进行传输的.接收方接受到之后,会存储到接收方的缓冲区中,发送方将多条数据发送给接收方,这多条数据一起存储到缓冲区中,此时假如我们不采取任何方式,多条数据存储到一块,这种不能有用区分消息边界的现象叫做粘包

 3.解决方案

如何解决粘包题目其实就是如何区分这些消息的边界.
1.在消息末端加上特殊的分隔符来标识消息的竣事

好比我们在每条消息的末端加上\n来作为一条消息的竣事.
你好啊,一会去吃暖锅吧!!!\nHow are you.\n不复书息你是个猪吗?\n
在获取消息的时候我们可以利用特殊字符截取缓冲区的内容
2.利用一个专门用来描述消息体长度的字段,来标识消息体的具体长度


1.读取消息的时候,先把4byte的表现消息体长度的字段读取出来,好比第一个长度为:42
2.继承在缓冲区读取42个字节,这42个字节表现消息的内容
3.在读取4个byte的下一个消息的长度,重复上面操纵.
举例:
JSON,用大括号来包裹消息,那么就可以理解为他是利用大括号做为特殊字符来表现消息结尾的HTTP,应用层的协议,既利用分隔符也利用了表现消息长度的字段解决粘包题目
十.TCP异常情况

1.步伐崩溃 

操纵体系是会感知到的,可以做相应的处理
操纵体系会回收进程的资源,其中开释包括文件描述符表,就想当于调用了对应socket的close之后触发FIN操纵,进而开始进入四次挥手,和普通的四次挥手没有区别.
2.正常关机

通过开始菜单或实验关机命令,体系会强制结所有进程,回收资源,与步伐崩溃实验的流程雷同
3.主机掉电操纵

体系不会做出任何反应

  • 接收方掉电


  • 发送方并不知道接收方挂了,继承发送数据·发送数据后收不到ACK应答,触发超时重传
  • 多次重传都没有收到ACK应答,会尝试进行毗连重置(RST标识位)
  • 毗连重置也失败,只能放弃毗连

  • 发送方掉电


  • 一样平常出如今长毗连中,服务器与客户端会维护一个心跳包客户端每隔1秒给服务器发送一个数据包,证明本身存活)告诉对方我还在线,没有真实数据
  • 假如服务器不停收不到这个心跳包,好比过了10秒之后还没有收到,就判定为客户端挂了,自行断开毗连
  • 客户端网络恢复之后再次进行重连即可
4.网线断开

与主机掉电的情况相同,只不过是主机都是正常工作的

十一.常晤面试题

1.简述下三次握手,四次挥手的流程
上面已经解说了,可以自行去看
2.为什么需要三次握手,两次不行吗?
上面已经解说了,可以自行去看
3. UDP本身是无毗连,不可靠,面向数据报的协议,假如要基于传输层UDP协议,来实现一个可靠传输,应该怎样计划?
4.UDP大小是受限的,假如要基于传输层UDP协议,传输凌驾64K的数据,应该如何计划?
题目三和题目四都可以基于TCP安全和服从机制进行回答,好比:
引入序列号,保证数据顺序;
引入确认应答,确保对端收到了数据;
引入超时重传,假如隔一段时间没有应答,就重发数据;
5.TCP和UDP的对比和区别.
TCP用于可靠传输的情况,应用于文件传输,紧张状态更新等场景;
UDP用于对高速传输和实时性要求较高的通讯范畴,例如,早期的QQ,视频传输等。                 别的UDP可以用于广播;

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
回复

使用道具 举报

0 个回复

正序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

泉缘泉

金牌会员
这个人很懒什么都没写!
快速回复 返回顶部 返回列表