• 传输层


     

    多路复用与多路分解

    将传输层报文段中的数据交付到正确的套接字的工作被称为多路分解。

    在源主机上从不同的套接字中收集数据,封装头信息生成报文段后,将报文段传递到网络层,这个过程被称为多路复用。

    无连接的多路复用和多路分解指的是 UDP 套接字的分配过程,一个 UDP 套接字由一个二元组来标识,这个二元组包含了一 个目的地址和一个目的端口号。因此不同源地址和端口号的 UDP 报文段到达主机后,如果它们拥有相同的目的地址和目的端 口号,那么不同的报文段将会转交到同一个 UDP 套接字中。

    面向连接的多路复用和多路分解指的是 TCP 套接字的分配过程,一个 TCP 套接字由一个四元组来标识,这个四元组包含了 源 IP 地址、源端口号、目的地址和目的端口号。因此,一个 TCP 报文段从网络中到达一台主机上时,该主机使用全部 4 个 值来将报文段定向到相应的套接字。

    套接字???

     TCP UDP

    TCP

    协议特点

     全双工:两端都可以作为发送方或接收方。可以同时发送/接受数据

     报文段首部

     URG:插队

     

    TCP建立连接的三次握手过程

    第一次握手:起初两端都处于CLOSED关闭状态,CLient将标志位SYN置1,随机产生一个值seq=x,并将该数据包发送给Server,Client随即进入SYN-SENT状态,等待Server确认;
    
    第二次握手:Server收到数据包后,由标志位SYN=1得知Client是要请求建立连接,Server将标志位SYN和ACK都置为1,ack=x+1,随机产生一个值seq=y,并将该数据包发送给Client来确认连接请求,
    Server随即进入SYN-RCVD状态,此时服务器为该TCP连接分配TCP缓存和变量; 第三次握手:Client收到确认后,检查ack是否为x+1,ACK是否为1,如果正确则将标志位ACK置为1,ack=y+1,SYN还是0.并且此时客户端为该TCP连接分配TCP缓存和变量,并将该数据包发送给Server,
    Server检查ack是否为y+1,ACK是否为1,如果正确则连接建立成功,CLient和Server进入ESTABLISHED状态,完成三次握手,随后CLient和Server就可以开始传输数据。

    SYN-sent 同步已发送 SYN-recvd 同步已收到

    简述半连接队列

    TCP握手中,当服务器处于SYN_RCVD 状态,服务器会把此种状态下请求连接放在一个队列里,该队列称为半连接队列。

    第三次握手seq =x+1 :第一次握手SYN=1需要消耗一个序号(SYN报文段[SYN=1]不携带数据,但是消耗一个序号)。x-->x+1.

    规定:ACK报文可以携带数据,但没携带数据时不消耗序号,所以第三次握手的seq=x+1。

    上图字段解释

    序号(sequence number):seq序号,占32位,用来标识从TCP源端向目的端发送的字节流,发起方发送数据时对此进行标记。

    确认号(acknowledgement number):ack序号,占32位,只有ACK标志位为1时,确认序号字段才有效,ack=seq+1。

    标志位(Flags):共6个,即URG、ACK、PSH、RST、SYN、FIN等。具体含义如下:

    URG:紧急指针(urgent pointer)有效。
    
    ACK:确认序号有效。(为了与确认号ack区分开,我们用大写表示)
    
    PSH:接收方应该尽快将这个报文交给应用层。
    
    RST:重置连接。
    
    SYN:发起一个新连接。
    
    FIN:释放一个连接。
    

    SYN 泛洪攻击

    简述dos攻击

    DoS是Denial of Service的简称,也称为拒绝服务攻击,通过发送大量的无用请求数据包给服务器,耗尽服务器资源,从而无法通过正常的访问服务器资源,导致服务器崩溃。

    定期扫描  ,排查系统漏洞 

    防火墙

    过滤不必要的服务和端口

    TCP 为什么三次握手而不是两次握手

    为了实现可靠数据传输, 双方确认自己与对方的发送与接收是正常的.TCP 协议的通信双方, 都必须维护一个确认号, 以标识发送出去的数据包中, 哪些是已经被对方收到的。

    如果只是两次握手, 至多只有连接发起方(客户端)的起始序列号能被确认, 另一方(服务端)选择的序列号则得不到确认,即无法确定客户端可以收到服务端的数据

    第 2 次握手传回了 ACK,为什么还要传回 SYN?

    接收端传回发送端所发送的 ACK 是为了告诉客户端,我接收到的信息确实就是你所发送的信号了,这表明从客户端到服务端的通信是正常的。而回传 SYN 则是为了建立并确认从服务端到客户端的通信。

    TCP关闭连接的四次挥手机制

    第一次挥手:TCP客户端发送一个FIN报文,用来关闭客户到服务器的数据传送。客服端自己进入到终止等待1阶段,等待对端服务器回发的ACK

    第二次挥手: 服务器收到这个FIN报文,它发回一个ACK报文,确认序号为收到的序号加1。和SYN一样,一个FIN报文将占用一个序号。服务器自己进入关闭等待状态。\

    客户端接受到这个ACK报文后, 自己进入到终止等待2状态。等待对端服务器发过来FIN.

    第三次挥手: 服务器端发送完所有数据后,服务器关闭客户端的连接,发送一个FIN给客户端。自己进入最后确认状态, 等待最终的对端发来ACK确认。

    第四次挥手:  客户端发回ACK报文确认,并将确认序号设置为收到序号加1。并进入 2MSL的时间等待 阶段,如果该时间内服务端没有重发请求的话,客户端进入 CLOSED 的状态。如果收到 服务器的重发请求就重新发送确认报文段。服务器端收到客户端的确认报文段后就进入 CLOSED 状态,这样全双工的连接就被 释放了。

    为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态?

        两个存在的理由:1、无法保证最后发送的ACK报文会一定被对方收到,所以需要重发可能丢失的ACK报文。2、关闭链接一段时间后可能会在相同的IP地址和端口建立新的连接,为了防止旧连接的重复分组在新连接已经终止后再现。2MSL足以让分组最多存活msl秒被丢弃。

    MSL(Maximum Segment Lifetime)即报文最大生存时间,是任何报文在网络上存活的最长时间,超过这个时间报文将被丢弃。

    为什么建立连接协议是三次握手,而关闭连接却是四次握手呢?

    TCP 使用四次挥手的原因是因为 TCP 的连接是全双工的,所以需要双方分别释放到对方的连接,单独一方的连接释放,只代 表不能再向对方发送数据,连接处于的是半释放的状态。

    主要原因是当服务端收到客户端的 FIN 数据包后,服务端可能还有数据没发完,不会立即close。

    所以服务端会先将 ACK 发过去告诉客户端我收到你的断开请求了,但请再给我一点时间,这段时间用来发送剩下的数据报文,发完之后再将 FIN 包发给客户端表示现在可以断了。

    之后客户端发送 ACK 确认断开信息给服务端。

    TCP流量控制

    TCP 提供了流量控制的服务,这个服务的主要目的是控制发送方的发送速率,保证接收方来得及接收。因为一旦发送的速率大 于接收方所能接收的速率,就会造成报文段的丢失。接收方主要是通过接收窗口来告诉发送方自己所能接收的大小,发送方根据 接收方的接收窗口的大小来调整发送窗口的大小,以此来达到控制发送速率的目的。

     

     如果B重新给A设定窗口400,但是该报文丢失了。那么A一直等,AB无法通信。死锁

    此时需要持续计时器

    简述TCP协议的滑动窗口

    滑动窗口是传输层进行流量控制的一种措施,接收方通过通告发送方自己的窗口大小,从而控制发送方的发送速度,防止发送方发送速度过快而导致自己被淹没。

    TCP拥塞控制

    拥塞控制:在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络的性能就要变坏。这种情况就叫拥塞。拥塞控制就是为了防止过多的数据注入到网络中,这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提,就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程,涉及到所有的主机,所有的路由器,以及与降低网络传输性能有关的所有因素。
    流量控制:点到点,接受方接受不过来时他知道是发送方造成的

    拥塞窗口  

    发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个

    拥塞控制的4种算法  

    慢开始和拥塞控制  ssthresh为慢开始门限值

     

    注意:下一阶段会慢开始从1开始,到12。拥塞避免到16.以此类推。
    新的拥塞窗口是在网络拥塞时确定的。新的拥塞窗口为网络拥塞时拥塞窗口/2
    慢开始阶段只要收到报文确认拥塞窗口就翻倍

     

    快速重传:

     

    快速恢复

    出现3个冗余ACK,把拥塞窗口/2   .从12开始,在执行快恢复,接下来是拥塞避免(线性增大)

     为什么快?

    和慢开始对比 。因为出现拥塞后,开始的窗口从1开始,快恢复从新的门限值开始执行拥塞避免。

    为何TCP可靠

    可靠:保证接收方进程从缓存区读出的字节流和发送方发出的字节流是完全一样的

    1.TCP有三次握手建立连接,四次挥手关闭连接的机制。

    2.除此之外还有滑动窗口(流量控制)和拥塞控制算法。

    3.最最关键的是还保留超时重传的机制。

    确认和重传不分家,TCP的发送方在规定时间内没有收到确认就要重传已发送的 报文段

    TCP采用自适应算法,动态改变重传时间RTTs(加权平均往返时间)

     如果在超时重传定时器溢出之前,接收到连续的三个重复冗余ACK,发送端便知晓哪个报文段在传输过程中丢失了,于是重发该报文段,不需要等待超时重传定时器溢出再发送该报文

    4.对于每份报文也存在校验,保证每份报文可靠性。

    校验和

    TCP 将保持它首部和数据的检验和。这是一个端到端的检验和,目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错,TCP 将丢弃这个报文段和不确认收到此报文段

    tcp报文中,在tcp的首部之前,多了一个12字节的伪首部,伪首部中4个字节保存源ip信息,4个字节目的ip信息,一个字节的保留位置,

    一个字节保存协议号(6代表tcp,17代表udp),2个字节保存tcp的真正首部和数据。

    根据伪首部的信息通过位运算,得到了一个校验和数据,保存在tcp报文的checksum字段。接收端接收到tcp报文后,也按照特定算法计算出一个校验和,

    与checksum保存的校验和比较,如果相同,则完成此报文的接收。如果不相同,则丢弃此报文,让发送端重传。

    tcp校验和与ip校验和的区别是:TCP和UDP检验和覆盖首部和数据,而IP首部中的检验和只覆盖IP的首部,不覆盖IP数据报中的任何数据。

    tcp校验和和udp校验和的区别是:TCP的检验和是必需的,而UDP的检验和是可选的

    5. ARQ 协议:

     也是为了实现可靠传输的,它的基本原理就是每发完一个分组就停止发送,等待对方确认。在收到确认后再发下一个分组

    自动重传请求(Automatic Repeat-reQuest,ARQ)是 OSI 模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制,在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧,它通常会重新发送。ARQ 包括停止等待 ARQ 协议和连续 ARQ 协议。

    停止等待 ARQ 协议

    停止等待协议是为了实现可靠传输的,它的基本原理就是每发完一个分组就停止发送,等待对方确认(回复 ACK)。如果过了一段时间(超时时间后),还是没有收到 ACK 确认,说明没有发送成功,需要重新发送,直到收到确认后再发下一个分组。

    在停止等待协议中,若接收方收到重复分组,就丢弃该分组,但同时还要发送确认。

     连续 ARQ 协议

    连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口,凡位于发送窗口内的分组可以连续发送出去,而不需要等待对方确认。接收方一般采用累积确认,对按序到达的最后一个分组发送确认,表明到这个分组为止的所有分组都已经正确收到了

     

    粘包拆包

    TCP是个流协议,就是没有界限的一串数据。TCP底层并不了解上层业务数据的具体含义,它会根据TCP缓冲区的实际情况进行包的划分,所以在业务上认为一个完整的包可能会被TCP拆分为多个包进行发送,这就是拆包;也有可能把多个小的包封装成一个大的数据包发送,这就是粘包。

      TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包,从接收缓冲区看,后一包数据的头紧接着前一包数据的尾

    为什么出现粘包现象

      (1)发送方原因

      我们知道,TCP默认会使用Nagle算法。而Nagle算法主要做两件事:1)只有上一个分组得到确认,才会发送下一个分组;2)收集多个小分组,在一个确认到来时一起发送。

      所以,正是Nagle算法造成了发送方有可能造成粘包现象。

      (2)接收方原因

      TCP接收到分组时,并不会立刻送至应用层处理,或者说,应用层并不一定会立即处理;实际上,TCP将收到的分组保存至接收缓存里,然后应用程序主动从缓存里读收到的分组。

            这样一来,如果TCP接收分组的速度大于应用程序读分组的速度,多个包就会被存至缓存,应用程序读时,就会读到多个首尾相接粘到一起的包。

    TCP粘包现象处理方法

    固定发送信息长度,或在两个信息之间加入分隔符。

    UDP

    UDP 是一种无连接的,不可靠的传输层协议。它只提供了传输层需要实现的最低限度的功能,除了复用/分解功能和少量的差 错检测外,它几乎没有对 IP 增加其他的东西。

    UDP 协议适用于对实时性要求高的应用场景。

    特点:

    1. 使用 UDP 时,在发送报文段之前,通信双方没有握手的过程,因此 UDP 被称为是无连接的传输层协议。因为没有握手 过程,相对于 TCP 来说,没有建立连接的时延。因为没有连接,所以不需要在端系统中保存连接的状态。

    2. UDP 提供尽力而为的交付服务,也就是说 UDP 协议不保证数据的可靠交付。

    3. UDP 没有拥塞控制和流量控制的机制,所以 UDP 报文段的发送速率没有限制。

    4. 因为一个 UDP 套接字只使用目的地址和目的端口来标识,所以 UDP 可以支持一对一、一对多、多对一和多对多的交互 通信

    5. UDP 首部小,只有 8 个字节

    UDP 报文段结构

    UDP 报文段由首部和应用数据组成。报文段首部包含四个字段,分别是源端口号、目的端口号、长度和检验和,每个字段的长 度为两个字节

    长度字段指的是整个报文段的长度,包含了首部和应用数据的大小。校验和是 UDP 提供的一种差错校验机制。 虽然提供了差错校验的机制,但是 UDP 对于差错的恢复无能为力。

    我们为什么不直接使用IP协议而要额外增加一个UDP协议呢?

    一个重要的原因是IP协议中并没有端口(port)的概念。IP协议进行的是IP地址到IP地址的传输,这意味者两台计算机之间的对话。但每台计算机中需要有多个通信通道,并将多个通信通道分配给不同的进程使用(关于进程,可以参考Linux进程基础)。一个端口就代表了这样的一个通信通道。正如我们在邮局和邮差中提到的收信人的概念一样。UDP协议实现了端口,从而让数据包可以在送到IP地址的基础上,进一步可以送到某个端口

    为何UDP不可靠

    UDP面向数据报无连接的,数据报发出去,就不保留数据备份了。 仅仅在IP数据报头部加入校验和复用。 UDP没有服务器和客户端的概念。 UDP报文过长的话是交给IP切成小段,如果某段报废报文就废了

     

    TCP与UDP区别

    TCP作为面向流的协议,提供可靠的、面向连接的运输服务,传输慢,所需资源多。并且提供点对点通信.场景要求通信数据可靠。

    UDP作为面向报文的协议,不提供可靠交付,并且不需要连接,传输快,所需资源少。不仅仅对点对点,也支持多播和广播,用于实时性、高速传播的场景

     TCP 有超时重传

    UDP没有超时重传

     

    websocket是tcp还是udp

    是基于TCP的

    websocket的协议是在TCP/IP协议簇的应用层,和http在同一层。

    “自己定义的协议”是指websocket使用的是不同于http的另一种应用层协议,但websocket和http都是基于TCP传输层的。

     

     
  • 相关阅读:
    ME05 黑匣子思维
    F06 《生活中的投资学》摘要(完)
    ME03 关于运气要知道的几个真相
    ME02 做一个合格的父母To be good enough parent
    ME02 认知之2017罗胖跨年演讲
    F03 金融学第三定律 风险共担
    F05 敏锐的生活,让跟多公司给你免单
    ML04 Accord 调用实现机器算法的套路
    D02 TED Elon Mulsk The future we're building — and boring
    ML03 利用Accord 进行机器学习的第一个小例子
  • 原文地址:https://www.cnblogs.com/tingtin/p/15873926.html
Copyright © 2020-2023  润新知