系列文章目录

HTTP协议和HTTPS协议

文章目录

  • 系列文章目录
  • 一、TCP/IP 各层协议
  • 二、UDP协议和TCP协议
    • 1.TCP和UDP的区别
    • 2.UDP 协议
    • 3.TCP 协议
      • 1)特点
      • 2)TCP为什么可靠
      • 3)三次握手
      • 4) 四次挥手
      • 5)重传机制
      • 6)滑动窗口
      • 7)流量控制
      • 8)拥塞控制
      • 9)保活计时器
      • 10) TCP数据段
      • 11)TCP黏包问题
      • 12)Tcp拆包、组装包
        • ①拆包方式
        • ②socket
      • 13)SYN攻击(SYN 洪泛、SYN 攻击、DDos 攻击)
  • 三、QUIC协议
    • 1.QUIC协议特点

一、TCP/IP 各层协议

二、UDP协议和TCP协议

二者都属于传输层协议。

1.TCP和UDP的区别

①TCP提供面向对象的连接,通信前要建立三次握手机制的连接,每一条TCP连接只能是点到点的;通过确认和重传机制、分段排序、流量控制、拥塞控制等,提供可靠的,有序的,不丢失的传输;但是TCP传输速度相对UDP较慢;

UDP提供无连接的传输,传输前不用建立连接,UDP支持一对一,一对多,多对一和多对多的交互通信;提供不可靠的传输,不保证数据的有序性;由于UDP无连接、无重传确认、拥塞控制等,因此网络出现拥塞不会使源主机的发送速率降低,传输效率高、延时小,适合实时性要求高的应用(如IP电话,实时视频会议等)

②TCP提供面向字节流的传输,实际上是TCP把数据看成一连串无结构的字节流,它能将信息分割成组,不保存数据边界,然后在接收端重新组装信息。

UDP提供面向报文的传输,应用层交给UDP多长的报文,UDP就照样发送,即一次发送一个报文,保留数据边界;

③TCP是重量级协议,一个TCP 数据报的报头大小最少是 20 字节,TCP 报头中包含序列号,ACK 号,数 据偏移量,保留,控制位,窗口,紧急指针,可选项,填充项,校验位,源端口和目的端口。

UDP是轻量级协议,UDP 数据报的报头固定是8个字节,UDP 报头只包含长度,源端口号,目的端口,和校验和。

HTTP、HTTPS、FTP(文件传输协议)、SMTP(简单邮件传输协议)等都是基于TCP协议;

DNS(域名解析协议)、DHCP(动态主机配置协议)、TFTP(简单文件传输协议)等都是基于UDP协议的。


问题:TCP和UDP用一个端口发送信息是否冲突

参考回答:
不冲突,TCP、UDP可以绑定同一端口来进行通信,许多协议已经这样做了,例如DNS适用于udp / 53和tcp / 53。
因为数据接收时是根据五元组{传输协议,源IP,目的IP,源端口,目的端口}判断接受者的。

问题:接收udp数据_为何视频流/网游大都使用UDP协议,而不用TCP协议?

TCP适合实时性要求不高,但要求内容要完整传输的应用。

UDP由于无连接、无重传确认,所以传输效率高、延时小,适合实时性要求高的应用,如游戏服务器,音频,视频等;
另外,由于不用维持大的并发量,所以适合巨量服务的server,加上合适的时间控制,可以用来设计更大的并发服务器;
再者就是,UDP可以更高效的利用网络带宽。

举个例子:

视频流用UDP:若是链路中途丢包了导致丢了一两个帧,不影响到观影体验。视频传输不需要那么高的准确性,偶尔丢个包也没什么问题。

可以在应用层面去解决UDP丢包乱序的问题,重传也由上层协议来控制。

UDP 在许多方面非常有效。当某个程序的目标是尽快地传输尽可能多的信息时(其中任意给定数据的重要性相对较低),可使用 UDP。ICQ 短消息使用 UDP 协议发送消息。

许多程序将使用单独的TCP连接和单独的UDP连接。重要的状态信息随可靠的TCP连接发送,而主数据流通过UDP发送。

国人几乎都是用的QQ,在建立连接阶段,使用的是面向连接的TCP协议,通过三次握手来完成;然后,在文字数据传输阶段,使用的是UDP协议,但需要中间服务器转发(估计是使用了connect()的UDP,QQ离线发送/接收数据的基础)。
而音视频数据的发送一定要使用UDP协议,因为一般的客户可以容忍稍微模糊(略有缺失的数据块)的声音或视频,但估计不会接受一会断开,一会连接(因为TCP容易断线)的音视频。

RUDP((Reliable UDP)

将TCP和UDP的特性互相结合起来,让这个协议既可以保证可靠性,又可以保证实时性,常见的RUDP协议有QUIC,WebRTC,Aeron等。

问题:在当前网络环境下(2016年),手游使用长连接(TCP)好还是短连接(HTTP)好?

2.UDP 协议

User Datagram Protocol,用户数据报协议

1.特点

UDP不提供可靠性,它只是把应用程序传给IP层的数据报发送出去,但是并不能保证它们能到达目的地, 一个数据报包在运输中可能丢失。

由于UDP在传输数据报前不用在客户和服务器之间建立一个连接,且没有超时重发等机制,故而传输速度很快。

  • ①UDP是无连接的传输层协议;

  • ②UDP尽最大努力交付,不保证可靠交付, 可靠性由上层协议保证。

  • ③UDP是面向报文的,对应用层交下来的报文不合并,不拆分,保留原报文的边界;

  • ④UDP没有拥塞控制,因此即使网络出现拥塞也不会降低发送速率;

  • ⑤UDP是一对一,一对多,多对多的交互通信;

  • ⑥UDP的首部开销小,只有8字节。

3.TCP 协议

Transmission Control Protocol,传输控制协议

1)特点

  • ①TCP是面向连接的运输层协议,支持端到端通信。

所谓面向连接就是双方传输数据之前,必须先建立一条通道,例如三次握手就是建立通道的一个过程,而四次挥手则是结束销毁一个通道的过程。

  • ②每一条TCP连接只能有两个端点,只能是点对点的。

  • ③进行必要流量控制,避免发包过快而导致阻塞。

  • ④TCP提供可靠的传输服务,进行无差错控制;传送的数据不丢失、不重复、按序到达。

  • ⑤TCP提供全双工通信;允许通信双方的应用进程在任何时候都可以发送数据,因为两端都设有发送缓存和接受缓存。

  • ⑥面向字节流。虽然应用程序与TCP交互是一次一个大小不等的数据块,但TCP把这些数据看成一连串无结构的字节流,它不保证接收方收到的数据块和发送方发送的数据块具有对应大小关系。

2)TCP为什么可靠

TCP 提供交付保证,这意味着一个使用 TCP 协议发送的消息是保证交付给客户端的, 如果消息在传输过程中丢失,那么它将重发。

(超时重发,丢弃重复数据,检验数据,分段排序,拥塞处理,滑动窗口机制,保证数据能从一端传到另一端)

1、确认和重传机制

三次握手连接机制是确认重传和流量控制的基础,三次握手,访问不丢包,保持准确性,但是流量开销大。

传输过程中如果校验失败,丢包或延时,发送端重传。

TCP在数据包接收无序、丢失或在交付期间被破坏时,通过为其发送的每个数据包提供一个序号来完成数据恢复。TCP要保证丢失的package会被再次重发,确保对方能够收到。

为确保正确地接收数据,TCP要求在目标计算机成功收到数据时发回一个确认(即 ACK)。如果在某个时限内未收到相应的 ACK,将重新传送数据包。如果网络拥塞,这种重新传送将导致发送的数据包重复。但是,接收计算机可使用数据包的序号来确定它是否为重复数据包,并在必要时丢弃它。

(记住,较低的网络层会将每个数据包视为一个独立的单元,因此,数据包可以沿完全不同的路径发送,即使它们都是同一消息的组成部分。这种路由与网络层处理分段和重新组装数据包的方式非常相似,只是级别更高而已。)

包括:超时重传、快速重传、SACK、D-SACK。

2、数据排序

TCP有专门的序列号SN字段,可提供数据reorder

3、流量控制:滑动窗口、计时器
TCP 利用滑动窗口实现流量控制的机制。

TCP窗口中会指明双方能够发送接收的最大数据量,发送方通过维持一个发送滑动窗口来确保不会发生由于发送方报文发送太快导致接收方无法及时处理的问题。

4、拥塞控制:滑动窗口、计时器

控制的目的就是避免发送方的数据填满整个网络。

TCP建立连接时,各端分配一个缓冲区用来存储接受的数据,并将缓冲区的尺寸发送给另一端,接收方发送的确认消息中包含了自己剩余的缓冲区尺寸,剩余缓冲区空间的数量叫做窗口,所谓滑动窗口,就是接收端可以根据自己的状况通告窗口大小,从而控制发送端的接收,进行流量控制.

拥塞控制的基本算法有:

慢启动(Slow Start)、拥塞避免(Congestion avoidance)、拥塞发生(Fast Retransmit)、快速恢复(Fast Recovery)。

3)三次握手

刚开始客户端处于closed状态,服务端处于listen状态;

1.第一次握手:客户端发送syn=j到服务器

即客户端给服务端发一个SYN报文,并指明客户端的初始化序列号ISN(client),此时客户端就处于SYN_SEND状态,等待服务器确认。SYN:同步序列编号(Synchronize Sequence Numbers)。

2.第二次握手:服务器返回syn=k, ack=j+1

即服务端收到客户端的SYN报文之后,会以自己的SYN报文作为应答,并且也是指定了自己的初始化序列号ISN(server),
同时会把客户端的ISN+1作为ACK的值,表示自己已经收到了客户端的SYN,此时服务器处于SYN_REVD的状态。

3.第三次握手:客户端再向服务器发送ack=k+1

客户端收到SYN报文之后,会发送一个ACK报文,ACK=ISN+1表示已经收到了服务端的SYN报文,此时客户端处于established状态。

最后服务器收到ACK报文之后,也处于established状态。

三次握手结束,客户端和服务器建立连接

三次握手的作用:

发送且收到为一次握手

确保双方的收发能力:

第一次握手,客户端发送网络包,服务端收到了。
服务端得出结论:客户端的发送能力、服务端的接收能力是正常的。

第二次握手,服务端发包,客户端收到了。
客户端得出结论:服务端的接收、发送能力,客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。

第三次握手,客户端发包,服务端收到了。
服务端得出结论:客户端的接收、发送能力正常,服务器自己的发送、接收能力也正常。

指定自己的初始化序列号,为后面的可靠传输做准备。ISN是动态生成的,以便让对方知道接下来接受数据的时候如何按序列号组装数据。

三次握手的时候就第三次是可以携带数据的。

三次握手的状态变化:

LISTEN:侦听来自远方TCP端口的连接请求;

SYN-SENT:在发送连接请求后等待匹配的连接请求;

SYN-RECEIVED:在收到和发送一个连接请求后等待对连接请求的确认;

ESTABLISHED:代表一个打开的连接,数据可以传送给用户;

为什么不是两次:

在服务端对客户端的请求进行回应(第二次握手)后,就会理所当然的认为连接已建立,而如果客户端并没有收到服务端的回应,此时,客户端仍认为连接未建立,服务端会对已建立的连接保存必要的资源,如果大量的这种情况,服务端会崩溃。

4) 四次挥手

刚开始双方都处于established状态,假如是客户端先发起的关闭请求:

1.第一次挥手:客户端发送FIN = j 包用来关闭客户端到服务器的数据传送。

即客户端发送一个FIN报文,报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。

2.第二次挥手:服务器收到且返回 ack = j+1

即服务端收到FIN之后,会发送ACK报文,且把客户端的序列号值+1作为ACK报文的序列号值,表示已经收到客户端的报文了,此时服务端处于CLOSE_WAIT2状态。

3.第三次挥手:服务器发送FIN= k 包用于关闭服务器与客户端的连接。

即如果服务端也想断开连接了,和客户端的第一次挥手一样,发送FIN报文,且指定一个序列号。此时服务端处于LAST_ACK的状态。

4.第四次挥手:客户端返回ack = k+1

即客户端收到FIN之后,一样发送一个ACK报文作为应答,且把服务端的序列号值+1作为自己ACK报文的序列号值,

此时客户端处于TIME_WAIT状态。需要过一阵子(2MSL)以确保服务端收到自己的ACK报文之后才会进入CLOSED状态。

服务端收到ACK报文之后,就处于关闭连接了,处于CLOSED状态。

四次挥手结束,连接断开

四次挥手的状态变化:

FIN-WAIT1:等待远程TCP的连接中断请求,或先前的连接中断请求的确认;

CLOSE-WAIT:等待从本地用户发来的连接中断请求;

FIN-WAIT2:从远程TCP等待连接中断请求;

CLOSING:等待远程TCP对连接中断的确认;

LAST-ACK:等待原来发向远程TCP的连接中断请求的确认;

TIME-WAIT:等待足够的时间以确保远程TCP接收到连接中断请求的确认;

CLOSED:没有任何连接状态。

TIME_WAIT状态:

主动发起方需要等待2MSL的时间,即两个报文在发送过程中的最大生存时间。其作用是为了:

1.为了保证第三次挥手的ACK能够正确到达:如果没有收到的话,服务器会重新发送FIN报文给客户端,客户端再次收到FIN报文之后,就知道之前的ACK报文丢失了,然后再次发送ACK报文。

2.防止已失效的连接请求报文段出现在本连接中,即保证下一次新的连接建立都是新的报文而不是旧报文。

为什么连接三次,断开连接四次?

由于TCP连接是全双工的,因此每个方向都必须单独进行关闭。
这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。

收到一个 FIN只意味着这一方向上没有数据流动,一个TCP连接在收到一个FIN后仍能发送数据。

首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭。

在连接中,服务器的ack和syn包是同时发送的,而在断开连接的时候,服务器向客户端发送的ACK报文和FIN报文多数情况下都是分开发送的。

因为服务器收到客户端发送的FIN包时,可能还有数据要传送,所以先发送ack,等数据传输结束后再发送FIN断开这边的连接。

5)重传机制

  • 超时重传:设定定时器,当超过指定的时间后,没有收到对方的ACK确认应答报文,就会重发该数据。

  • 快速重传:快速重传只解决了超时时间的问题。但它不知道重传一个还是多个。

  • SACK(选择性重传):在TCP头部字段里加一个SACK的东西,它可以将缓存的信息发送给发送方,这样发送方就可以知道哪些数据收到了,哪些没有收到,就可以只重传丢失的数据。

  • D-SACK:使用了SACK来告诉发送方有哪些数据被重复接收了。

6)滑动窗口

传统传输数据包的往返时间越长,通信效率就越低,为解决这个问题引入窗口,窗口大小就是指无需等待确认应答,而可以继续发送数据的最大值

窗口实现实际上是操作系统开辟一个缓存空间,发送方主机在等到确认应答返回之前,必须在缓冲区中保留已发送的数据。如果按期收到确认应答,此时数据就可以从缓存区清除。若中途有ACK丢失,可以通过下一个确认应答进行确认。

早期的网络通信中,通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道网络拥塞状况,同时发送数据,导致中间节点阻塞掉包,谁也发不了数据,所以就有了滑动窗口机制来解决此问题。

滑动窗口协议的基本原理就是在任意时刻,发送方会维持了一个连续的允许发送的帧的序号,称为发送窗口。

发送方的窗口大小由接受方确定,目的在于控制发送速度,以免接受方的缓存不够大,而导致溢出,同时控制流量也可以避免网络拥塞。

同时,接收方也维持了一个连续的允许接收的帧的序号,称为接收窗口。

发送窗口和接收窗口的序号的上下界不一定要一样,甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。

发送方窗口内的序列号代表了那些已经被发送,但是还没有被确认的帧,或者是那些可以被发送的帧。


举例:


图中的4、5、6号数据帧已经被发送出去,但是未收到关联的ACK,7、8、9帧则是等待发送。

可以看出发送端的窗口大小为6,这是由接受端告知的(事实上必须考虑拥塞窗口 cwnd,这里暂且考虑 cwnd > rwnd )。此时如果发送端收到4号ACK,则窗口的左边缘向右收缩,窗口的右边缘则向右扩展,此时窗口就向前“滑动了”,即数据帧10也可以被发送。

rwnd:(Receiver Window) 滑动窗口

Receiver Window的是动态改变的,随着Sender每次发送seq的时候,Receiver都会根据当前机器的执行效率和缓存上限、当前缓存大小得出一个合适的Window Size,并且随着Ack回传到Sender。Sender在下次发送数据包的时候,就可以根据新的窗口大小去发送数据了。

CWND:(Congestion Window)拥塞窗口

7)流量控制

TCP 利用滑动窗口实现流量控制,流量控制是为了控制发送方发送速率,保证接收方来得及接收。

滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据。发送方可以通过滑动窗口的大小来确定应该发送多少字节的数据。当滑动窗口为 0 时,发送方一般不能再发送数据报。

接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率。将窗口字段设置为 0,则发送方不能发送数据。

发送方不能无脑的发数据给接收方,要考虑接收方处理能力。如果一直无脑的发数据给对方,但对方处理不过来,那么就会导致触发重发机制,从而导致网络流量的无端浪费。

为了解决这种情况TCP提供了一种机制可以让发送方根据接收方的实际接收能力控制发送的数据量,这就是流量控制。

8)拥塞控制

流量控制是避免发送方的数据填满接收方的缓存,但是并不知道网络中发生了什么。当网络发生拥塞控制时,TCP会自我牺牲,降低发送的数据量,于是有了拥塞控制。

拥塞控制的目的就是避免发送方的数据填满整个网络。为了在发送方调节所要发送的数据的量,定义了一个叫做拥塞窗口(CWND)的概念,

拥塞控制的基本算法有:慢启动、拥塞避免、拥塞发生、快速恢复。

  • 慢启动阈值+拥塞避免:

维护两个核心状态:拥塞窗口、慢启动阈值,在发送端使用拥塞窗口来控制发送窗口的大小。然后采用慢启动算法慢慢适应这个网络。

在开始传输的一段时间,发送端和接收端会首先通过三次握手建立连接,确定各自接收窗口大小,然后初始化双方的拥塞窗口,接着每经过一轮RTT(收发时延),拥塞窗口大小翻倍,直到达到慢启动阈值。

  • 拥塞发生:

当网络出现拥塞,也就是会发生数据包重传

  • 快速恢复:

如果发送端收到了3个重复的 ACK,发现了丢包,觉得现在的网络状况已经进入拥塞状态了,那么就会进入快速恢复阶段:会将拥塞阈值降低为拥塞窗口的一半、然后将拥塞窗口大小变为拥塞阈值、接着拥塞窗口再进行线性增加,以适应网络状况。

9)保活计时器

除时间等待计时器外,TCP 还有一个保活计时器。

设想这样的场景:客户已主动与服务器建立了 TCP 连接。但后来客户端的主机突然发生故障。显然,服务器以后就不能再收到客户端发来的数据。因此,应当有措施使服务器不要再白白等待下去。这就需要使用保活计时器了。

服务器每收到一次客户的数据,就重新设置保活计时器,时间的设置通常是两个小时。若两个小时都没有收到客户端的数据,服务端就发送一个探测报文段,以后则每隔 75 秒钟发送一次。若连续发送10个 探测报文段后仍然无客户端的响应,服务端就认为客户端出了故障,接着就关闭这个连接。

10) TCP数据段

源端口(Source port)和 目的端口(Destination port):
字段标明了一个连接的两个端点用来跟踪同一时间内通过网络的不同会话。一般每个端口对应一个应用程序。

序列号(Sequence number):字节号 (32 位),表示一个字节的编号:(进行数据排序,保证有序传输)

初始序列号ISNs(initial sequence numbers ):随机产生的

SYN:携带了ISNs 和SYN 控制位的数据段

确认号(Acknowledgement number):期望接收的字节号 (32位)

TCP段头长度(TCP header length): TCP段头长度, 单位32位(4字节)

保留域/字段:逐步启用,如做拥塞控制等

URG:当紧急指针使用的时候,URG 被置为1。紧急指针是一个对于当前序列号的字节偏移量,标明紧急数据从哪里开始

当URG=1时,表明有紧急数据,必须首先处理收方收到这样的数据后,马上处理,处理完后恢复正常操作即使win=0,也可以发送这样的数据

ACK:为1 表示确认号有效,为0标明确认号无效

PSH:表示这是带有PUSH标志的数据,接收方收到这样的数据,应该立刻送到上层,而不需要缓存它

RST:被用来重置一个已经混乱的连接

SYN:用在连接建立过程中

SYN=1,ACK=0 连接请求,当SYN=1,ACK=1 连接接受

FIN: 被用来释放连接,它表示发送方已经没有数据要传输了,但是可以继续接收数据

Window size: 告诉对方可以发送的数据字节数,从确认字节号开始(决定于接收方)

Checksum:提供额外的可靠性,校验的范围包括头部、数据和概念性的伪头部

选项域:选项域提供了一种增加基本头没有包含内容的方法

11)TCP黏包问题

1.TCP黏包问题产生的原因

因为TCP 是基于字节流的,虽然应用层和 TCP 传输层之间的数据交互是大小不等的数据块,但是 TCP 把这些数据块仅仅看成一连串无结构的字节流,不记录数据边界;

从 TCP 的帧结构也可以看出,在 TCP 的首部没有表示数据长度的字段。所以客户端连续不断的向服务端发送数据包时,服务端接收的数据会出现两个数据包粘在一起的情况。

一个数据包中包含了发送端的两个数据包的信息,这种现象称之为粘包。

2.TCP黏包问题的分类

  • 发送方产生黏包:

采用 TCP 协议传输数据的客户端与服务器经常是保持一个长连接的状态,双方在连接不断开的情况下,可以一直传输数据。但当发送的数据包过于小的时候,那么 TCP 协议默认的会启用 Nagle 算法,将这些较小的数据包进行合并发送;这个合并过程就是在发送缓冲区中进行的,也就是说数据发送出来它已经是粘包的状态了

  • 接收方产生黏包:

我们在程序中调用的读取数据函数不能及时的把缓冲区中的数据拿出来,而下一个数据又到来并有一部分放入的缓冲区末尾,等我们读取数据时就是一个粘包。(放数据的速度 > 应用层拿数据速度)

  • 解决办法:

特殊字符控制和在包头首部添加数据包的长度。

12)Tcp拆包、组装包

①拆包方式

对于拆包目前常用的是以下两种方式:动态缓冲区暂存方式,利用底层的缓冲区来进行拆包

1、动态缓冲区暂存方式
之所以说缓冲区是动态的是因为当需要缓冲的数据长度超出缓冲区的长度时会增大缓冲区长度。大概过程描述如下:

  • A 为每一个连接动态分配一个缓冲区,同时把此缓冲区和 SOCKET关联,常用的是通过结构体关联。

  • B 当接收到数据时首先把此段数据存放在缓冲区中。

  • C 判断缓存区中的数据长度是否够一个包头的长度,如不够,则不进行拆包操作。

  • D 根据包头数据解析出里面代表包体长度的变量。

  • E 判断缓存区中除包头外的数据长度是否够一个包体的长度,如不够,则不进行拆包操作。

  • F 取出整个数据包,这里的"取"的意思是不光从缓冲区中拷贝出数据包,而且要把此数据包从缓存区中删除掉。删除的办法就是把此包后面的数据移动到缓冲区的起始地址。

动态缓冲区暂存方式的缺点:

  • 1)为每个连接动态分配一个缓冲区增大了内存的使用;

  • 2)有三个地方需要拷贝数据,一个地方是把数据存放在缓冲区,一个地方是把完整的数据包从缓冲区取出来,一个地方是把数据包从缓冲区中删除。这种拆包的改进方法会解决和完善部分缺点。

2、利用底层的缓冲区来进行拆包

由于TCP也维护了一个缓冲区,所以我们完全可以利用TCP的缓冲区来缓存我们的数据,这样一来就不需要为每一个连接分配一个缓冲区了。另一方面我们知道 recv 或者 wsarecv 都有一个参数,用来表示我们要接收多长长度的数据。利用这两个条件我们就可以对第一种方法进行优化了。

对于阻塞 SOCKET 来说,我们可以利用一个循环来接收包头长度的数据,然后解析出代表包体长度的那个变量,再用一个循环来接收包体长度的数据。

②socket

Socket是应用层与TCP/IP协议族通信的中间软件抽象层,它是一组接口。

在设计模式中,Socket其实就是一个门面模式,它把复杂的TCP/IP协议族隐藏在Socket接口后面,对用户来说,一组简单的接口就是全部,让Socket去组织数据,以符合指定的协议。

Socket原理讲解

13)SYN攻击(SYN 洪泛、SYN 攻击、DDos 攻击)

攻击者短时间伪造不同IP地址的SYN报文,服务端每接收到一个SYN报文,就进入SYN_RCVD状态,但服务端发送出去的ACK+SYN报文无法得到未知IP的ACK应答,久而久之就会占满服务端的SYN半连接队列,使得服务器不能为正常用户服务。

  • 半连接队列和全连接队列:

服务器第一次收到客户端的SYN之后,就会处于SYN_RCVD状态,此时双方还没有完全建立起连接,服务器会把此种状态下请求连接放在一个队列里,称之为半连接队列。完成三次握手后,就会从半连接队列中移除并放在全连接队列中,如果队列满了就可能出现丢包现象

当超过了 TCP 最大全连接队列,服务端则会丢掉后续进来的 TCP 连接,丢掉的 TCP 连接的个数会被统计起来,我们可以使用 netstat -s 命令来查看。

从模拟结果,可以得知,当服务端并发处理大量请求时,如果 TCP 全连接队列过小,就容易溢出。发生 TCP 全连接队溢出的时候,后续的请求就会被丢弃,这样就会出现服务端请求数量上不去的现象。

三、QUIC协议

参考:https://blog.csdn.net/weixin_43167418/article/details/108656273

QUIC(Quick UDP Internet Connection)是Google公司提出的基于UDP的高效可靠协议,他和HTTP一样同样是应用层协议。

用UDP代替了TCP,UDP是一个非连接的协议,传输数据之前源端和终端不建立连接。UDP信息包的标题很短,对系统资源的要求比TCP要低。并在UDP协议上开发了QUIC协议,来保证数据的可靠传输。

为什么高效呢?是因为其基于无连接的UDP而不是基于TCP去实现的。

为什么可靠呢?因为其模仿TCP协议的可靠性,在应用层上做了可靠性的保证。

1.QUIC协议特点

  • 1.无队头阻塞:QUIC连接上的多个Stream之间并没有依赖,能独立运行,也不会有底层协议限制,某个流发生包丢了,只会影响该流,其它流不受影响。

  • 2.连接迁移:QUIC协议没有用四元组的方式来绑定连接,而是通过连接ID来表示通信的两个端点,客户端和服务器可以各自选择一组ID来标识自己,因此即使移动设备的网络变化后,导致IP地址变了,只要仍保存上下文信息,就可以“无缝”地复用原链接,消除重连的成本。

  • 3.建立连接速度快:因为QUIC内部包含了TLS1.3,因此仅需要1个RTT就可以同时完成建立连接与TLS密钥协商,甚至在第二次连接的时候,应用数据包可以和QUIC握手信息一起发送,达到0RTT的效果。

  • 4.QPACK通过两个特殊的单向流来同步双方的动态表,解决了HTTP/2的HPACK队头阻塞问题。

但是由于QUIC使用的是UDP协议,大部分路由器在网络繁忙的时候,会丢掉UDP包,把空间让给TCP包,所以QUIC的推广并不容易。

计算机网络整理:UDP协议和TCP协议相关推荐

  1. http协议与https协议+UDP协议和TCP协议+WebSocket协议下服务端主动去发送信息+对称加密与非对称加密+get和post请求方式区别详解+浏览器内核以及jsj解析引擎

    TCP和UDP协议是TCP/IP协议的核心. 在TCP/IP网络体系结构中,TCP(传输控制协议,Transport Control Protocol).UDP(用户数据报协议,User Data P ...

  2. IP协议和TCP协议详解

    IP协议和TCP协议详解 IP协议 IP协议的特点 IPV4头部信息 IP分片 重定向 IPV6头部结构 TCP协议 TCP协议的特点 TCP头部结构 TCP连接的建立与关闭 异常终止连接 异常终止连 ...

  3. http协议及http协议和tcp协议的区别

    http是应用层的协议,并且无连接,无状态的协议. http协议的特点: 1.支持c/s模式 2.简单快速:客户端向服务器端传送数据的时候,只需要发送请求方法和路径,请求方法有:post,get,he ...

  4. 计算机网络实验(华为eNSP模拟器)——第十四章 RIP协议和OSPF协议

    目录 一.RIP协议和OSPF协议 (一)自治系统AS (二)内部.外部网关协议 (三)RIP协议 (四)OSPF路由协议 二.实验目的 三.实验内容 四.实验结果 结语 一.RIP协议和OSPF协议 ...

  5. osi七层协议和tcp/ip四层协议

    (大部分内容为转载) OSI(Open System Interconnection)是一个开放性的通行系统互连参考模型,他是一个定义的非常好的协议规范,共包含七层协议.OSI七层协议是由ISO (I ...

  6. 计算机网络——数据链路层局域网、以太网、PPP协议和HDLC协议、链路层设备

    文章目录 前言 一.局域网简介 1.局域网的基本概念和特点 2.局域网的主要要素 3.局域网的分类与 IEEE 802 标准 4.LLC 子层和 MAC 子层 二.以太网 三.无线局域网 四.PPP ...

  7. 计算机网络(二十)-广域网-PPP协议和HDLC协议

    一.广域网 广域网,通常跨接很大的物理范围,所覆盖的范围从几十公里到几千公里,它能连接多个城市或国家,远距离通信,形成国际性的远程网络. 广域网的通信子网主要使用分组交换技术.广域网的通信子网可以利用 ...

  8. 【计算机网络】数据链路层——PPP协议和HDLC协议/数据链路层设备

    文章目录 PPP协议和HDLC协议 PPP协议 HDLC协议 站 数据操作方式 HDLC帧 PPP协议和HDLC协议区别 数据链路层设备 网桥的概念及其基本原理 透明网桥 源路由网桥 两种网桥的比较 ...

  9. 计算机网络 -广域网WAN (PPP协议和HDLC协议)

    文章目录 广域网WAN PPP协议 PPP协议需要实现的三个功能 PPP协议帧格式 HDLC协议 PPP协议 and HDLC协议 广域网WAN 广域网覆盖层次:物理层,链路层,网络层 局域网覆盖层次 ...

最新文章

  1. 06.Java虚拟机问题
  2. 这10句话,迷茫时读一读。
  3. 云服务器系统租赁费用,云服务器创建租赁费用
  4. Java中isAssignableFrom()方法与instanceof()方法用法
  5. putty的基本使用
  6. bash 中的行处理命令 awk
  7. mysql ignore space_MySQL日志存储空间满引发的错误
  8. 确认和回调_右侧突破但是不能追买,等待回调确认,圣诞节附近接回,波段反弹到大寒附近将是一波好收成,但是大寒又是顶部区域需要高抛。...
  9. Flutter入门进阶之旅(二)Hello Flutter
  10. ajax请求进error怎么弹出错诶信息,在ajax请求jqgrid之后出现错误时显示错误消息...
  11. python运维实战pdf_python运维实例.pdf
  12. 全国计算机等级考试一级试题免费,全国计算机等级考试一级试题
  13. STM32 独立按键扫描功能大全-支持连击、组合连击、任意连击
  14. JS,CSS是前端,JAVA PHP ASP是后端,数据库是后端的处理对象,非代表前后底
  15. bootstrap 实现吸顶效果_多种方式实现吸顶效果
  16. JS算法笔记---移除元素
  17. 自订安装套件选单(转)
  18. 深度之眼Pytorch打卡(十三):Pytorch全连接神经网络部件——线性层、非线性激活层与Dropout层(即全连接层、常用激活函数与失活 )
  19. 蓝桥杯历年省赛JAVA-B组真题汇总及题目详解
  20. 搞机吧 | 刷rec、线刷、卡刷教程

热门文章

  1. Linux学习笔记6 文件操作——文件描述符
  2. Python可视化-县市按经纬度坐标在地图标记数值
  3. 实现内网洪水攻击DOS击破手机无法上网
  4. 计算机分隔线教程,装电脑必知 机箱理线基础图文教程
  5. 异步社区的一个专访记录
  6. 所有的道别里,我最喜欢,明天见
  7. 架构师是如何炼成的?以天猫APP架构&开发模式升级工程为例
  8. 迅雷联盟推送狗狗流量
  9. Word图片自动编号,Mathtype引用自动编号,交叉引用上标设置
  10. 仿海报工厂效果的自定义View