计算机网络基础必备(三次握手,四次握手,2024年前端开发者常见面试题

  • 服务器出现了大量CLOSE_WAIT状态如何解决

  • 讲一讲SYN超时,洪泛攻击,以及解决策略

  • 三、HTTP

    • URI 和 URL
  • HTTP消息的结构

    • HTTP事务:
  • 报文:

  • 方法

  • Get与POST的区别

  • 状态码

  • 协议版本

  • 四、HTTPS

    • HTTP和HTTPS对比
  • 对称加密与非对称加密

    • 共享密钥加密(对称秘钥加密)
  • 公开密钥(非对称密钥)

  • SSL/TSL

  • 证书

  • HTTPS的工作原理

  • HTTPS的优点

  • HTTPS的缺点

  • HTTP 切换到 HTTPS

  • 什么是Cookie,Cookie的使用过程是怎么样的?

  • 什么是session,有哪些实现session的机制?

  • session和cookie有什么区别

  • Other FAQ

    • 从输入网址到获得页面的过程
  • XSS 攻击

  • IP地址的分类

  • XSS 攻击

  • IP地址的分类

或许你会碰到这些问题

浏览器中输入一个 URL 至页面呈现,网络上都发生了什么事?

能说说 ISO 七层模型和 TCP/IP 四层模型吗?

TCP/IP 与 HTTP 有什么关系吗?

TCP协议与UDP协议的区别?

请详细介绍一下 TCP 的三次握手机制,为什么要三次握手?挥手却又是四次呢?

详细讲一下TCP的滑动窗口?知道流量控制和拥塞控制吗?

说一下对称加密与非对称加密?

状态码 206 是什么意思?

你们用的 https 是吧,https 工作原理是什么?

那么对于这些问题,你又是如何回答的呢。

一、计算机网络


通信协议

通信协议(communications protocol)是指双方实体完成通信或服务所必须遵循的规则和约定。通过通信信道和设备互连起来的多个不同地理位置的数据通信系统,要使其能协同工作实现信息交换和资源共享,它们之间必须具有共同的语言。交流什么、怎样交流及何时交流,都必须遵循某种互相都能接受的规则。这个规则就是通信协议。

网络模型

随着技术的发展,计算机的应用越来越广泛,计算机之间的通信开始了百花齐放的状态,每个具有独立计算服务体系的信息技术公司都会建立自己的计算机通信规则,而这种情况会导致异构计算机之间无法通信,极大的阻碍了网络通信的发展,至此为了解决这个问题,国际标准化组织(ISO)制定了OSI模型,该模型定义了不同计算机互联的标准,OSI模型把网络通信的工作分为7层,分别是物理层、数据链路层、网络层、传输层、会话层、表示层和应用层

这七层模型是设计层面的概念,每一层都有固定要完成的职责和功能,分层的好处在于清晰和功能独立性,但分层过多会使层次变的更加复杂,虽然不需要实现本层的功能,但是也需要构造本层的上下文,空耗系统资源,所以在落地实施网络通信模型的时候将这七层模型简化合并为四层模型分别是应用层、传输层、网络层、网络接口层(各层之间的模型、协议统称为:TCP/IP协议簇)。

img

从上图可以看到,TCP/IP模型合并了OSI模型的应用层、表示层和会话层,将OSI模型的数据链路层和物理层合并为网络访问层。

上图还列出了各层模型对应TCP/IP协议栈中的协议以及各层协议之间的关系。比如DNS协议是建立在TCP和UDP协议的基础上,FTP、HTTP、TELNET协议建立在TCP协议的基础上,NTP、TFTP、SNMP建立在UDP协议的基础上,而TCP、UDP协议又建立在IP协议的基础上,以此类推….

| OSI中的层 | 功能 | TCP/IP协议族 |

| :-- | :-- | :-- |

| 应用层 | 文件传输,电子邮件,文件服务,虚拟终端 | TFTP,HTTP,SNMP,FTP,SMTP,DNS,RIP,Telnet |

| 表示层 | 数据格式化,代码转换,数据加密 | 无 |

| 会话层 | 控制应用程序之间会话能力;如不同软件数据分发给不同软件 | ASAP、TLS、SSH、ISO 8327 / CCITT X.225、RPC、NetBIOS、ASP、Winsock、BSD sockets |

| 传输层 | 端到端传输数据的基本功能 | TCP、UDP |

| 网络层 | 定义IP编址,定义路由功能;如不同设备的数据转发 | IP,ICMP,RIP,OSPF,BGP,IGMP |

| 数据链路层 | 定义数据的基本格式,如何传输,如何标识 | SLIP,CSLIP,PPP,ARP,RARP,MTU |

| 物理层 | 以二进制数据形式在物理媒体上传输数据 | ISO2110,IEEE802 |

当我们某一个网站上不去的时候。通常会ping一下这个网站

ping 可以说是ICMP的最著名的应用,是TCP/IP协议的一部分。利用ping命令可以检查网络是否连通,可以很好地帮助我们分析和判定网络故障。

二、TCP/IP


数据在网络中传输最终一定是通过物理介质传输。物理介质就是把电脑连接起来的物理手段,常见的有光纤、双绞线,以及无线电波,它决定了电信号(0和1)的传输方式,物理介质的不同决定了电信号的传输带宽、速率、传输距离以及抗干扰性等等。网络数据传输就像快递邮寄,数据就是快件。只有路打通了,你的”快递”才能送到,因此物理介质是网络通信的基石。

寄快递首先得称重、确认体积(确认数据大小),贵重物品还得层层包裹填充物确保安全,封装,然后填写发件地址(源主机地址)和收件地址(目标主机地址),确认快递方式。对于偏远地区,快递不能直达,还需要中途转发。网络通信也是一样的道理,只不过把这些步骤都规定成了各种协议。

TCP/IP的模型的每一层都需要下一层所提供的协议来完成自己的目的。我们来看下数据是怎么通过TCP/IP协议模型从一台主机发送到另一台主机的。

img

当用户通过HTTP协议发起一个请求,应用层、传输层、网络互联层和网络访问层的相关协议依次对该请求进行包装并携带对应的首部,最终在网络访问层生成以太网数据包,以太网数据包通过物理介质传输给对方主机,对方接收到数据包以后,然后再一层一层采用对应的协议进行拆包,最后把应用层数据交给应用程序处理。

TCP/IP 与 HTTP

TCP/IP(Transmission Control Protocol/Internet Protocol,传输控制协议/网际协议)是指能够在多个不同网络间实现信息传输的协议簇。TCP/IP 协议不仅仅指的是 TCP 和 IP 两个协议,而是指一个由FTP、SMTP、TCP、UDP、IP等协议构成的协议簇, 只是因为在TCP/IP协议中TCP协议和IP协议最具代表性,所以被称为TCP/IP协议。

而HTTP是应用层协议,主要解决如何包装数据。

“IP”代表网际协议,TCP 和 UDP 使用该协议从一个网络传送数据包到另一个网络。把IP想像成一种高速公路,它允许其它协议在上面行驶并找到到其它电脑的出口。TCP和UDP是高速公路上的“卡车”,它们携带的货物就是像HTTP,文件传输协议FTP这样的协议等。

TCP 与 UDP

都属于传输层协议。

TCP(Transmission Control Protocol,传输控制协议)是面向连接的协议,也就是说,在收发数据前,必须和对方建立可靠的连接。一个TCP连接必须有三次握手、四次挥手。

UDP(User Data Protocol,用户数据报协议)是一个非连接的协议,传输数据之前源端和终端不建立连接, 当它想传送时就简单地去抓取来自应用程序的数据,并尽可能快地把它扔到网络上

| | TCP | UDP |

| :-- | :-- | :-- |

| 连接性 | 面向连接 | 面向非连接 |

| 传输可靠性 | 可靠 | 不可靠 |

| 报文 | 面向字节流 | 面向报文 |

| 效率 | 传输效率低 | 传输效率高 |

| 流量控制 | 滑动窗口 | 无 |

| 拥塞控制 | 慢开始、拥塞避免、快重传、快恢复 | 无 |

| 传输速度 | 慢 | 快 |

| 应用场合 | 对效率要求低,对准确性要求高或要求有连接的场景 | 对效率要求高,对准确性要求低 |

TCP和UDP协议的一些应用

img

TCP连接的建立与终止

TCP虽然是面向字节流的,但TCP传送的数据单元却是报文段。一个TCP报文段分为首部和数据两部分,而TCP的全部功能体现在它首部中的各字段的作用。

TCP报文段首部的前20个字节是固定的(下图),后面有4n字节是根据需要而增加的选项(n是整数)。因此TCP首部的最小长度是20字节。

img

TCP报文首部
  • 源端口和目的端口,各占2个字节,分别写入源端口和目的端口;

  • 序列号(Sequence number),占4字节。序号范围是【0,2^32 - 1】,共2^32个序号。序号增加到 2^32-1后,下一个序号就又回到 0。TCP是面向字节流的。在一个TCP连接中传送的字节流中的每一个字节都按顺序编号。整个要传送的字节流的起始序号必须在连接建立时设置。首部中的序号字段值则是指的是本报文段所发送的数据的第一个字节的序号。例如,一报文段的序号是301,而接待的数据共有100字节。这就表明:本报文段的数据的第一个字节的序号是301,最后一个字节的序号是400。显然,下一个报文段(如果还有的话)的数据序号应当从401开始,即下一个报文段的序号字段值应为401。这个字段的序号也叫“报文段序号”;

  • 确认号(Acknowledge number),占4个字节,是期望收到对方下一个报文的第一个数据字节的序号。例如,B收到了A发送过来的报文,其序列号字段是501,而数据长度是200字节,这表明B正确的收到了A发送的到序号700为止的数据。因此,B期望收到A的下一个数据序号是701,于是B在发送给A的确认报文段中把确认号置为701;

  • 数据偏移,占4位,它指出TCP报文段的数据起始处距离TCP报文段的起始处有多远。

  • 保留,占6位,保留为今后使用,但目前应置为0;

  • 紧急URG(URGent),当URG=1,表明紧急指针字段有效。告诉系统此报文段中有紧急数据;

  • 确认ACK(ACKnowledgment),仅当ACK=1时,确认号字段才有效。TCP规定,在连接建立后所有报文的传输都必须把ACK置1

  • 推送PSH(PuSH) ,当两个应用进程进行交互式通信时,有时在一端的应用进程希望在键入一个命令后立即就能收到对方的响应,这时候就将PSH=1;

  • 复位RST(ReSeT),当RST=1,表明TCP连接中出现严重差错,必须释放连接,然后再重新建立连接;

  • 同步SYN(SYNchronization),在连接建立时用来同步序号。当SYN=1,ACK=0,表明是连接请求报文,若同意连接,则响应报文中应该使SYN=1,ACK=1

  • 终止FIN(FINis),用来释放连接。当FIN=1,表明此报文的发送方的数据已经发送完毕,并且要求释放

    • 窗口,占2字节,指的是通知接收方,发送本报文你需要有多大的空间来接受;
  • 检验和,占2字节,校验首部和数据这两部分;

  • 紧急指针,占2字节,指出本报文段中的紧急数据的字节数;

  • 选项,长度可变,定义一些其他的可选的参数

TCP是一种面向连接的单播协议,在发送数据前,通信双方必须在彼此间建立一条连接。所谓的“连接”,其实是客户端和服务器的内存里保存的一份关于对方的信息,如ip地址、端口号等。

接下来通过这张图熟悉一下

image-20200601165029928

TCP 三次握手

image-20200601165217415

所谓三次握手(Three-way Handshake),是指建立一个 TCP 连接时,需要客户端和服务器总共发送3个包。

三次握手的目的是连接服务器指定端口,建立 TCP 连接,并同步连接双方的序列号和确认号,交换 TCP 窗口大小信息。

img

TCP连接建立需要经过“三次握手"(there way handshake)。这个过程可以描述如下。

  • 第一次握手(同步SYN=1, 连接请求报文seq=x)

(1)最初的客户端TCP进程是处于CLOSE(关闭)状态。当客户端准备发起一次TCP连接,进人SYN-SEND(准备发送)状态时,它首先向处于LISTEN(收听)状态的服务器端CP进程发送第一个控制位SYN=1的“连接建立请求报文”。“连接建立请求报文"不携带数据字段,但是需要给报文一个序号,图中标为“SYN=1,seq=x"。

需要注意的是:“连接建立请求报文”的序号seq 值x是随机产生的,但是不能为0。随机数x不能为0的理由是:避免因TCP连接非正常断开而可能引起的混乱。如果在连接突然中断时,可能有一个或两个进程同时等待对方的确认应答.而这个时候有一个新连接的建立连接。

序号也是从0开始,那么接收进程就有可能认为是对方重传的报文,这样就有可能造成连接过程的错误。为了避免可能引起的问题,协议规定SYN报文序号seq值I必须随机产生,并且不能为0,

​ 客户端发送连接请求报文段,这是报文首部中的同步位SYN=1,同时选择一个初始序列号 seq=x ,此时,客户端进程进入了 SYN-SENT(同步已发送状态)状态。TCP规定,SYN报文段(SYN=1的报文段)不能携带数据,但需要消耗掉一个序号;

  • 第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1)

​ 服务器端在接收到“连接建立请求报文”之后, 如果同意建立连接,则向客户端发送第二个控制位SYN=1、ACK=1的“连接建立请求确认报文”。确认号ack=x+1,表示是对第一个“连接建立请求报文”(序号seq=x)的确认。同样,“连接建立请求确认报文"不携带数据字段,但是需要给报文一个序号(seq=y)。图中标为“SYN= 1,ACK= l,seq=y,ack=x+1"。这时服务器进人SYN-RCVD(准备接收)状态。

​ 服务器收到客户端的SYN报文段,如果同意连接,则发出确认报文。确认报文中应该 ACK=1,SYN=1,确认号ACKnum=x+1,同时,自己还要发送SYN请求信息,SYN=1,为自己初始化一个序列号 seq=y,服务器端将上述所有信息放到一个报文段(即SYN+ACK报文段)中,一并发送给客户端,此时,TCP服务器进程进入了SYN-RCVD(同步收到)状态。这个报文也不能携带数据,但是同样要消耗一个序号

  • 第三次握手(ACK=1,ACKnum=y+1)

​ 在接收到“连接建立请求确认报文”之后,客户端发送第三个控制位ACK=1"连接建立请求确认报文”。由于该报文是对“连接建立请求确认报文”(序号seq=:y)的确认,因此确认序号ack=y+1。同样,“连接建立请求确认报文”不携带数据字段。但是需要给报文一个序号。按照TCP协议规定,这个“连接建立请求确认报文”的序号仍然为x十1.图中标为“ACK= 1,seq=x+1 ,ack=y+1"。这时客户端进入ESTABLISHED(已建立连接)状态。

​ 客户端收到服务器的SYN+ACK报文段,再次发送确认包(ACK),SYN 标志位为0,ACK 标志位为1,确认号 ACKnum = y+1,这个报文段发送完毕以后,客户端和服务器端都进入ESTABLISHED(已建立连接)状态,完成TCP三次握手。

为什么需要三次握手呢?两次不行吗?

为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误。

具体例子:“已失效的连接请求报文段”的产生在这样一种情况下:client发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后,就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段,同意建立连接。假设不采用“三次握手”,那么只要server发出确认,新的连接就建立了。由于现在client并没有发出建立连接的请求,因此不会理睬server的确认,也不会向server发送数据。但server却以为新的运输连接已经建立,并一直等待client发来数据。这样,server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况,client不会向server的确认发出确认。server由于收不到确认,就知道client并没有要求建立连接。”

TCP 四次挥手

TCP 的连接的拆除需要发送四个包,因此称为四次挥手(Four-way handshake),也叫做改进的三次握手。客户端或服务器均可主动发起挥手动作

image-20200601165240512

img

  • 第一次挥手(FIN=1,seq=x)

(1)当客户准备各结束一次数据传输,主动提出释放TCP连接时,进入FIN-WAIT-1(释放等待-1)状态。它向服服务器端发送第一个控制位FIN=1的“连接释放请求报文”,接出连接释放清求,停止发送数据。“连接释放请求报文"不携带数据字段。但是需要给报文一个序号

图中标为FIN=1,seq=u"”。 “u“等于客户端发送的最后一个字节的序号加1,

主机1(可以使客户端,也可以是服务器端),设置seq=x,向主机2发送一个FIN报文段;此时,主机1进入FIN_WAIT_1状态;这表示主机1没有数据要发送给主机2了;

  • 第二次挥手(ACK=1,ACKnum=x+1)

(2)服务器在接收到“连接释放请求报文”之后,需要向客户发回“连接释放请求确认报文”,表示对接收第一个连接释放请求报文的确认,因此ack =u+1。这个“连接释放请求报文”的序号为V等于服务器发送的最后一个字节序号加1。图中标为“ACK= l,seq=t,ack=u+1".

TCP服务器进程向高层应用进程通知客户请求释放TCP连接,客户到服务器的TCP连接断开。但是,服务器到客户的TCP连接还没有断开,如果服务器还有数据报文需要发送时,它还可以继续发送直至完毕。这种状态称为半关闭(helf-close)状态。这个状态需要持续一段时间。客户在接收到服务器发送的ACK报文之后进人FIN-WAIT-2状态:服务器进入CLOSE WAIT状态。

​ 主机2收到了主机1发送的FIN报文段,向主机1回一个ACK报文段,Acknnum=x+1,主机1进入FIN_WAIT_2状态;主机2告诉主机1,我“同意”你的关闭请求;

  • 第三次挥手(FIN=1,seq=y)

(3)服务器的高层应用程序已经没有数据需要发送时,它会通知TCP可以释放法地这时服务器向客户发送“连接释放请求报文”。这个“连接释放请求报文”的序号取决干大业关闭状态时,服务器端是否发送过数据报文。因此序号假定为w。图中标为“FIN=1ACK=1,seq=w,ack=u+1”。服务器端经过LAST-ACK状态之后转回到LISTENC听)状态。

主机2向主机1发送FIN报文段,请求关闭连接,同时主机2进入LAST_ACK 状态

  • 第四次挥手(ACK=1,ACKnum=y+1)

(4)客户在接收到FIN报文之后向服务器发送“连接释放请求确认报文”报文,表示对服务器"连接释放请求报文”的确认。图中ACK报文记为“ACK=1,seu+l,ack=w+1”。

主机1收到主机2发送的FIN报文段,向主机2发送ACK报文段,然后主机1进入TIME_WAIT状态;主机2收到主机1的ACK报文段以后,就关闭连接;此时,主机1等待2MSL后依然没有收到回复,则证明Server端已正常关闭,那好,主机1也可以关闭连接了,进入 CLOSED 状态。

主机 1 等待了某个固定时间(两个最大段生命周期,2MSL,2 Maximum Segment Lifetime)之后,没有收到服务器端的 ACK ,认为服务器端已经正常关闭连接,于是自己也关闭连接,进入 CLOSED 状态。

为什么连接的时候是三次握手,关闭的时候却是四次握手?

因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。

由于 TCP 协议是全双工的,也就是说客户端和服务端都可以发起断开连接。两边各发起一次断开连接的申请,加上各自的两次确认,看起来就像执行了四次挥手。

为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?

虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

还有一个原因,防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后,在这个2MSL时间中,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

四个计时器

保持计时器:

为了保证TCP工作正常、有序地进行,TCP设置了保持计时器(keep timer),用来防止TCP连接处以长时期空闲。如果客户端建立到服务器端的连接,传输一此数据,然后停止传输,可能是这个客户端出故障。在这种情况下,这个连接将永远处于打开状态。为了解决这种问题,一般是在服务器端设置保持计时器。当服务器端收到客户端的报文时,就将保持计时器复位。如果服务器端过了设定的时间没有收到客户端的信息,它就发送探测报文。如果发送10个探测报文(每一个相隔75s)还没有响应,就假设客户端出现故障,进而终止该连接。

时间等待计时器:

为了保证TCP连接释放过程正常地进行.TCP设置了时间等待计时器(TIME waITTimer)。当TCP关闭一个连接时,它并不认为这个连接马上就真正地关闭。这时,客户端进入TIME-WAIT状态,需要再等待两个最长报文寿命(maximum segment lfetime,MSL)时间之后,才真正进人CLOSE(关闭)状态。

客户端与服务器端经过“四次握手”之后,确认双方已经同意释放连接,客户端仍然需要采取延迟2MSL时间,确保服务器在最后阶段发送给客户端的数据,以及客户端发送给服务器的最后一个ACK报文都能正确地被接收防止因个别报文传输错误导致连接释放失败。

重传计时器

TCP使用重传计时器(retransmission timer)来控制报文确认与等待重传的时间,当发送端TCP发送一个报文时,首先将它的一个报文的副本放人重传队列,同时启动一个面传计时器。重传计时器设定一个值,例如400ms,然后开始倒计时。在重传计时器倒计时到0之前收到确认,表示该报文传输成功;如果在计时器倒计时到0之时没收到确认,表示该报文传输失败.准备重传该报文。

坚持计时器

在执行滑动窗口控制的过程中.要求发送端在接收到零窗口通告之后就停止发送,这个过程直到接收端的TCP再发出一个非零窗口通告为止。但是,如果下一个非零窗口通告丢失,那么发送端将无休止地等待接收端的通知,这就会造成死锁。为防止非零窗口通知丢失造成“死锁”的现象出现,TCP设置了一个“坚持计时器"(persistence timer)。

当发送端的TCP收到一个零窗口通知时,就启动坚持计时器。当坚持计时器时间到,发送端的TCP就发送一个零窗口探测报文。这个报文只有一个字节的数据,它有一个序号,但它的序号不需要确认。零窗口探测报文的作用是提示接收端:非零窗口通知丢失,必须重传。

坚持计时器的值设置为重传时间的数值,最大为60秒。如果发出的第一个零窗口探测报文没有收到应答,则需发送第二个零窗口探测报文,直到收到非零窗口为止。

TCP协议如何来保证传输的可靠性

对于可靠性,TCP通过以下方式进行保证:

  • 数据包校验:目的是检测数据在传输过程中的任何变化,若校验出包有错,则丢弃报文段并且不给出响应,这时TCP发送数据端超时后会重发数据;

  • 对失序数据包重排序:既然TCP报文段作为IP数据报来传输,而IP数据报的到达可能会失序,因此TCP报文段的到达也可能会失序。TCP将对失序数据进行重新排序,然后才交给应用层;

  • 丢弃重复数据:对于重复数据,能够丢弃重复数据;

  • 应答机制:当TCP收到发自TCP连接另一端的数据,它将发送一个确认。这个确认不是立即发送,通常将推迟几分之一秒;

  • 超时重发:当TCP发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。如果不能及时收到一个确认,将重发这个报文段;

  • 流量控制:TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据,这可以防止较快主机致使较慢主机的缓冲区溢出,这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。

详细讲一下TCP的滑动窗口

滑动窗口机制

如果发送方把数据发送得过快,接收方可能会来不及接收,这就会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快,要让接收方来得及接收。

利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。

img

从上面的图可以看到滑动窗口左边的是已发送并且被确认的分组,滑动窗口右边是还没有轮到的分组。滑动窗口里面也分为两块,一块是已经发送但是未被确认的分组,另一块是窗口内等待发送的分组。随着已发送的分组不断被确认,窗口内等待发送的分组也会不断被发送。整个窗口就会往右移动,让还没轮到的分组进入窗口内。

可以看到滑动窗口起到了一个限流的作用,也就是说当前滑动窗口的大小决定了当前 TCP 发送包的速率,而滑动窗口的大小取决于拥塞控制窗口和流量控制窗口的两者间的最小值。

流量控制

TCP 是全双工的客户端和服务器均可作为发送方或接收方,我们现在假设一个发送方向接收方发送数据的场景来讲解流量控制。首先我们的接收方有一块接收缓存,当数据来到时会先把数据放到缓存中,上层应用等缓存中有数据时就会到缓存中取数据。假如发送方没有限制地不断地向接收方发送数据,接收方的应用程序又没有及时把接收缓存中的数据读走,就会出现缓存溢出,数据丢失的现象,为了解决这个问题,我们引入流量控制窗口。

假设应用程序最后读走的数据序号是 lastByteRead,接收缓存中接收到的最后一个数据序号是 lastByteRcv,接收缓存的大小为 RcvSize,那么必须要满足 lastByteRcv - lastByteRead <= RcvSize 才能保证接收缓存不会溢出,所以我们定义流量窗口为接收缓存剩余的空间,也就是Rcv = RcvSize - (lastByteRcv - lastByteRead)。只要接收方在响应 ACK 的时候把这个窗口的值带给发送方,发送方就能知道接收方的接收缓存还有多大的空间,进而设置滑动窗口的大小。

拥塞控制

拥塞控制是指发送方先设置一个小的窗口值作为发送速率,当成功发包并接收到ACK时,便以指数速率增大发送窗口的大小,直到遇到丢包(超时/三个冗余ACK),才停止并调整窗口的大小。这么做能最大限度地利用带宽,又不至于让网络环境变得太过拥挤。

最终滑动窗口的值将设置为流量控制窗口和拥塞控制窗口中的较小值。

TCP的拥塞处理

计算机网络中的带宽、交换结点中的缓存及处理机等都是网络的资源。在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络的性能就会变坏,这种情况就叫做拥塞。拥塞控制就是防止过多的数据注入网络中,这样可以使网络中的路由器或链路不致过载。注意,拥塞控制和流量控制不同,前者是一个全局性的过程,而后者指点对点通信量的控制。拥塞控制的方法主要有以下四种:

  1. 慢启动:不要一开始就发送大量的数据,先探测一下网络的拥塞程度,也就是说由小到大逐渐增加拥塞窗口的大小;

  2. 拥塞避免:拥塞避免算法让拥塞窗口缓慢增长,即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1,而不是加倍,这样拥塞窗口按线性规律缓慢增长。

  3. 快重传:快重传要求接收方在收到一个 失序的报文段 后就立即发出 重复确认(为的是使发送方及早知道有报文段没有到达对方)而不要等到自己发送数据时捎带确认。快重传算法规定,发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段,而不必继续等待设置的重传计时器时间到期。

  4. 快恢复:快重传配合使用的还有快恢复算法,当发送方连续收到三个重复确认时,就执行“乘法减小”算法,把ssthresh门限减半,但是接下去并不执行慢开始算法:因为如果网络出现拥塞的话就不会收到好几个重复的确认,所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法,而是将cwnd设置为ssthresh的大小,然后执行拥塞避免算法。

服务器出现了大量CLOSE_WAIT状态如何解决

大量 CLOSE_WAIT 表示程序出现了问题,对方的 socket 已经关闭连接,而我方忙于读或写没有及时关闭连接,需要检查代码,特别是释放资源的代码,或者是处理请求的线程配置。

讲一讲SYN超时,洪泛攻击,以及解决策略

什么 SYN 是洪泛攻击?在 TCP 的三次握手机制的第一步中,客户端会向服务器发送 SYN 报文段。服务器接收到 SYN 报文段后会为该TCP分配缓存和变量,如果攻击分子大量地往服务器发送 SYN 报文段,服务器的连接资源终将被耗尽,导致内存溢出无法继续服务。

解决策略:当服务器接受到 SYN 报文段时,不直接为该 TCP 分配资源,而只是打开一个半开的套接字。接着会使用 SYN 报文段的源Id,目的Id,端口号以及只有服务器自己知道的一个秘密函数生成一个 cookie,并把 cookie 作为序列号响应给客户端。

如果客户端是正常建立连接,将会返回一个确认字段为 cookie + 1 的报文段。接下来服务器会根据确认报文的源Id,目的Id,端口号以及秘密函数计算出一个结果,如果结果的值 + 1等于确认字段的值,则证明是刚刚请求连接的客户端,这时候才为该 TCP 分配资源

这样一来就不会为恶意攻击的 SYN 报文段分配资源空间,避免了攻击。

三、HTTP


HTTP1.0、HTTP1.1、HTTP2.0 的区别

post 和 get 的区别

HTTP全称是 HyperText Transfer Protocal,即:超文本传输协议。是互联网上应用最为广泛的一种网络通信协议,它允许将超文本标记语言(HTML)文档从Web服务器传送到客户端的浏览器。目前我们使用的是HTTP/1.1 版本。所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。1960年美国人 Ted Nelson 构思了一种通过计算机处理文本信息的方法,并称之为超文本(hypertext),这成为了HTTP超文本传输协议标准架构的发展根基。

URI 和 URL

每个Web 服务器资源都有一个名字,这样客户端就可以说明他们感兴趣的资源是什么了,服务器资源名被称为统一资源标识符(Uniform Resource Identifier,URI)。URI 就像因特网上的邮政地址一样,在世界范围内唯一标识并定位信息资源。

统一资源定位符(URL)是资源标识符最常见的形式。URL 描述了一台特定服务器上某资源的特定位置。

现在几乎所有的 URI 都是 URL。

URI 的第二种形式就是统一资源名(URN)。URN 是作为特定内容的唯一名称使用的,与目前的资源所在地无关。

HTTP消息的结构

事务和报文

客户端是怎样通过HTTP与Web服务器及其资源进行事务处理的呢?一个HTTP事务由一条请求命令(从客户端发往服务器)和一个响应(从服务器发回客户端)结果组成。这种通信是通过名为HTTP报文(HTTP Message)的格式化数据块进行的。

HTTP事务:

img

报文:

HTTP 报文是纯文本,不是二进制代码。从 Web 客户端发往 Web 服务器的 HTTP 报文称为请求报文(request message)。从服务器发往客户端的报文称为响应报文。

img

HTTP 报文包括三部分:

  • 起始行

  • 首部字段

  • 主体

方法

Http协议定义了很多与服务器交互的方法,最基本的有4种,分别是GET,POST,PUT,DELETE. 一个URL地址用于描述一个网络上的资源,而HTTP中的GET, POST, PUT, DELETE就对应着对这个资源的查,改,增,删4个操作。我们最常见的就是GET和POST了。GET一般用于获取/查询资源信息,而POST一般用于更新资源信息。

  • GET

  • HEAD

  • PUT

  • POST

  • TRACE

  • OPTIONS

  • DELETE

小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。

深知大多数初中级前端工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Web前端开发全套学习资料》送给大家,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。

img
img
img
img

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助,可以添加下面V无偿领取!(备注:前端)
img

最后

开源分享:【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

给大家分享一些关于HTML的面试题。


  • GET

  • HEAD

  • PUT

  • POST

  • TRACE

  • OPTIONS

  • DELETE

小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。

深知大多数初中级前端工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Web前端开发全套学习资料》送给大家,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。

[外链图片转存中…(img-hszlVCuQ-1711192054599)]
[外链图片转存中…(img-xattSs7Q-1711192054600)]
[外链图片转存中…(img-FdpdjF9A-1711192054600)]
[外链图片转存中…(img-MFmjYhOz-1711192054601)]

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助,可以添加下面V无偿领取!(备注:前端)
[外链图片转存中…(img-1lKCUOw9-1711192054601)]

最后

开源分享:【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

给大家分享一些关于HTML的面试题。

[外链图片转存中…(img-8y5KvjwH-1711192054602)]
[外链图片转存中…(img-1jGxTQlQ-1711192054602)]

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值