ღゝ◡╹)ノ❤️

集中一点,登峰造极!

  menu
137 文章
0 浏览
0 当前访客
ღゝ◡╹)ノ❤️

网络

从输入URL到浏览器页面展示经历的步骤?

  1. 从浏览器的输入框中输入网址
  2. 浏览器向操作系统发起创建套接字的请求,但是创建套接字需要目的IP
  3. 于是浏览器开始进行域名解析(DNS是一个应用层的域名解析协议。)
    在浏览器DNS缓存中搜索
    在操作系统DNS缓存中搜索
    读取系统hosts文件,查找其中是否有对应的ip
    向本地配置的DNS服务器发起域名解析请求(递归查询),发送UDP数据包到默认网关,默认网关判断是否需要下一跳,如果需要则传送的吓一跳,否则,根据arp协议解析出mac地址,然后将udp数据包交付给dns服务器。
    本地域名服务器向根域名服务器,顶级域名服务器,权限域名服务器发起请求(迭代查询)
  4. 传输层经过三次握手,建立TCP连接。由内核来完成,程序不需要管。开辟资源,接受发送队列。
  5. 如果是https建立SSL/TLS连接
  6. 连接成功应用层发送Http报文。
  7. 服务器收到Http报文,将响应信息发回客户端。
  8. 浏览器进行解析,并将数据显示到页面上。

TCP三次握手

TCP是面向连接的,安全可靠的传输协议,三次握手的机制是为了建立一个安全,可靠的连接。由系统内核就行处理的,程序员无感知。

第一次

客户端发起,客户端向服务器端发送一个报文,报文里面SYN标志位置1,

第二次

当服务端收到这条报文之后,服务端会发送一个确认报文,SYN标志位置为1,ACK也置为1,经过两次握手,客户端就知道了,他既能成功发送消息,也能成功接受信息。但是此时服务端还不知道自己是否成功发送信息,(如果指有两次握手就建立连接,那么服务端不知道,客户端请求建立连接的报文是什么时候发的,如果是因为服务器滞留了一些时间发过来的,那么服务端会变成一个变成连接已建立的状态,服务端系统内核会开辟接受和发送队列,会浪费很多资源。只有三次握手,才能保证客户端和服务端在同一时刻有接受和发送的能力。scoket:对资源的包装,源ip port 目的ip port)

第三次

客户端向服务端发送确认报文。ACK标志位置为1。

经过三次握手,服务端和客户端都已经知道了自己能成功发送信息也能成功接受信息。

TCP四次挥手

第一次

客户端发起,发送一个FIN标志位为1的报文,此时服务端不一定做好准备。

第二次

服务端发送一个确认报文,并做一些准备。

第三次

服务端发送一个FIN标志位为1的报文

第四次

客户端发送一个确认报文。

HTTP状态码

分类分类描述
1**信息,服务器收到请求,需要请求者继续执行操作
2**成功,操作被成功接收并处理
3**重定向,需要进一步的操作以完成请求
4**客户端错误,请求包含语法错误或无法完成请求
5**服务器错误,服务器在处理请求的过程中发生了错误

临时响应(1xx)

状态码原因含义
100继续请求者应当继续提出请求。服务器返回此代码表示已收到请求的第一部分,正在等待其余部分。
101切换协议请求者已要求服务器切换协议,服务器已确认并准备切换。

成功(2xx)

状态码原因含义
200成功服务器已成功处理了请求。
201已创建请求成功并且服务器创建了新的资源
202已接受服务器已接受请求,但尚未处理
203非授权信息服务器已成功处理了请求,但返回的信息可能来自另一来源。
204无内容服务器成功处理请求,耽美返回任何内容
205重置内容服务器成功处理了请求,但没返回任何内容,与 204 响应不同,此响应要求请求者重置文档视图
206部分内容服务器成功处理了部分GET请求。

重定向(3xx)

状态码原因含义
300多种选择针对请求,服务器可执行多种操作,服务器可根据请求者选择一项操作,或提供操作列表供请求者选择。
301永久移动请求的资源已被永久的移动到新URI,返回信息会包括新的URI,浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302临时移动与301类似。但资源只是临时被移动。客户端应继续使用原有URI
303查看其它地址与301类似。使用GET和POST请求查看
304未修改所请求的资源未修改,服务器返回此状态码时,不会返回任何资源。客户端通常会缓存访问过的资源,通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
305使用代理所请求的资源必须通过代理访问
306Unused已经被废弃的HTTP状态码
307临时重定向与302类似。使用GET请求重定向

客户端错误(4xx)

状态码原因含义
400错误请求客户端请求的语法错误,服务器无法理解
401未授权请求要求用户的身份认证
402
403禁止服务器理解请求客户端的请求,但是拒绝执行此请求
404未找到服务器无法根据客户端的请求找到资源(网页)。通过此代码,网站设计人员可设置"您所请求的资源无法找到"的个性页面
405方法禁用客户端请求中的方法被禁止
406不接受无法使用请求的内容特性响应请求的网页。
407需要代理授权请求要求代理的身份认证,与401类似,但请求者应当使用代理进行授权
408请求超时服务器等候请求时发生超时。
409冲突服务器在完成请求时发生冲突。服务器必须在响应中包含有关冲突的信息。服务器在响应与前一个请求相冲突的 PUT 请求时可能会返回此代码,以及两个请求的差异列表。
410已删除如果请求的资源已永久删除,服务器就会返回此响应。该代码与 404(未找到)代码类似,但在资源以前存在而现在不存在的情况下,有时会用来替代 404 代码。如果资源已永久移动,您应使用 301 指定资源的新位置。
411需要有效长度服务器不接受不含有效内容长度标头字段的请求。
412未满足前提条件服务器未满足请求者在请求中设置的其中一个前提条件。
413请求实体过大服务器无法处理请求,因为请求实体过大,超出服务器的处理能力。
414请求的 URI 过长请求的 URI(通常为网址)过长,服务器无法处理。
415不支持的媒体类型请求的格式不受请求页面的支持。
416请求范围不符合要求如果页面无法提供请求的范围,则服务器会返回此状态码。
417未满足期望值服务器未满足”期望”请求标头字段的要求。

服务端错误(5xx)

状态码原因含义
500服务器内部错误服务器遇到错误,无法完成请求。
501尚未实施服务器不具备完成请求的功能。例如,服务器无法识别请求方法时可能会返回此代码。
502错误网关服务器作为网关或代理,从上游服务器收到无效响应。
503服务不可用服务器目前无法使用(由于超载或停机维护)。通常,这只是暂时状态。
504网关超时服务器作为网关或代理,但是没有及时从上游服务器收到请求。
505HTTP 版本不受支持服务器不支持请求中所用的 HTTP 协议版本。

HTTP传输风险

  • 窃听风险:黑客可以获知通信内容
  • 篡改风险:黑客可以修改通信内容
  • 冒充风险:黑客可以冒充他人身份窜与通信

TLS连接建立过程

C:协议版本号、一个客户端生成的随机数(Client random),以及客户端支持的加密方法列表。

S:确认双方使用的加密方法,并给出数字证书、以及一个服务器生成的随机数(Server random)。

C:确认数字证书有效,然后生成一个新的随机数(Premaster secret),并使用数字证书中的公钥,加密这个随机数,发给服务端。

C:服务端使用自己的私钥,获取客户端发来的随机数(即Premaster secret)。

服务端和客户端根据约定的加密方法,使用前面的三个随机数,生成"对话密钥"(session key),用来加密接下来的整个对话过程。

数字证书的内容:

证书的版本信息;

证书的序列号,每个证书都有一个唯一的证书序列号;

证书所使用的签名算法;

证书的发行机构名称,命名规则一般采用X.500格式;

证书的有效期,现在通用的证书一般采用UTC时间格式,它的计时范围为1950-2049;

证书所有人的名称,命名规则一般采用X.500格式;

证书所有人的公开密钥;

证书发行者对证书的签名。

请求报文

响应报文

TCP和UDP的区别

连接性

TCP是面向连接的协议,在收发数据之前必须和对方建立可靠的连接,建立连接的3次握手、断开连接的四次挥手,为数据传输打下可靠的基础,UPD是面向无连接的协议,数据传输前,源端和终端不建立连接,源端尽量快的将数据扔到网络上,接收端从消息队列中读取消息段。

可靠性

TCP提供可靠交付的服务,传输过程中采用许多方法保证在连接上提供可靠的传输服务,如编号与确认,流量控制,计数器等,确保数据无差错,不丢失,不重复,切按序到达,UPD使用尽可能最大的努力交付,但不保证可靠交付。

报文首部

TCP报文首部20个字节,UDP只用8个字节,标题短,开销小。

使用场景

为了实现TCP的可靠性,增加校验和,序列校验和、序号标识、滑动窗口、确认应答、拥塞控制等复杂的机制,建立了繁琐的握手过程,增加了TCP对系统资源的消耗;TCP的对重传机制,顺序控制机制对数据传输有一定延时影响,降低了传输效率。TCP适合对传输效率要求低,但准确率要求高的应用场景,比如万维网,文件传输,电子邮件。

UDP是无连接的,不可靠传输,尽最大努力交付数据,协议简单、资源要求少、传输速度快、实时性高的特点,适用于对传输效率要求高,但准确率要求低的应用场景,比如域名转换(DNS)、实时音频聊天等。

TCP主要提供了检验和、序列号/确认应答、超时重传、滑动窗口、拥塞控制和流量控制等方法实现了可靠性传输。
检验和:通过检验和的方式,接收端可以检测出来数据是否有差错和异常,假如有差错就会直接丢弃TCP段,重新发送。
序列号/确认应答:序列号的作用不仅仅是应答的作用,有了序列号能够将接收到的数据根据序列号排序,并且去掉重复序列号的数据。TCP传输的过程中,每次接收方收到数据后,都会对传输方进行确认应答。也就是发送
ACK报文,这个ACK报文当中带有对应的确认序列号,告诉发送方,接收到了哪些数据,下一次的数据从哪里发。
滑动窗口:滑动窗口既提高了报文传输的效率,也避免了发送方发送过多的数据而导致接收方无法正常处理的异常。
超时重传:超时重传是指发送出去的数据包到接收到确认包之间的时间,如果超过了这个时间会被认为是丢包了,需要重传。最大超时时间是动态计算的。
拥塞控制:在数据传输过程中,可能由于网络状态的问题,造成网络拥堵,此时引入拥塞控制机制,在保证TCP可靠性的同时,提高性能。
流量控制:如果主机A -直向主机B发送数据,不考虑主机B的接受能力,则可能导致主机B的接受缓冲区满了而无法再接受数据,从而会导致大量的数据丢包,引发重传机制。而在重传的过程中,若主机B的接收缓冲区情况仍未好转,则会将大量的时间浪费在重传数据上,降低传送数据的效率。所以引入流量控制机制,主机B通过告诉主机A自己接收缓冲区的大小,来使主机A控制发送的数据量。流量控制与TCP协议报头中的窗口大小有关。

Time_wait的作用

先看图:

名词解释:

time_wait是开始的时间是tcp四次挥手中主动关闭连接方发送完最后一次挥手时所处的状态。一般持续时间是2MSL,MSL是报文最大生存时间,一般根据网络的情况而定。

为什么持续这么长时间?

原因1:为了保证客户端发送的最后一个ack报文段能够到达服务器。因为这最后一个ack确认包可能会丢失,然后服务器就会超时重传第三次挥手的fin信息报,然后客户端再重传一次第四次挥手的ack报文。如果没有这2msl,客户端发送完最后一个ack数据报后直接关闭连接,那么就接收不到服务器超时重传的fin信息报(此处应该是客户端收到一个非法的报文段,而返回一个RST的数据报,表明拒绝此次通信,然后双方就产生异常,而不是收不到。 ),那么服务器就不能按正常步骤进入close状态。那么就会耗费服务器的资源。当网络中存在大量的timewait状态,那么服务器的压力可想而知。

原因2:在第四次挥手后,经过2msl的时间足以让本次连接产生的所有报文段都从网络中消失,这样下一次新的连接中就肯定不会出现旧连接的报文段了。也就是防止已经失效的连接请求报文段出现在本次连接中。如果没有的话就可能这样:这次连接一挥手完马上就结束了,没有timewait。这次连接中有个迷失在网络中的syn包,然后下次连接又马上开始,下个连接发送syn包,迷失的syn包忽然又到达了对面,所以对面可能同时收到或者不同时间收到请求连接的syn包,然后就出现问题了。

TCP滑动窗口与缓冲区

答案

缓冲区的大小决定了滑动窗口的上限,但是不能盲目的增大缓存区的大小,这样会造成浪费,可以根据网络带宽动态的设置缓冲区的大小。

OSI七层模型

物理层: 物理层规定了电平、速度、电缆针脚。传输介质

数据链路层:数据链路层会封装上MAC地址,交换机可以根据MAC地址找到对应的主机,所以有了MAC地址就能在局域网中进行通信。

网络层:网络层上会封装上IP地址,如果网络上的主机A想要与主机B进行通信,必须知道对方B的IP地址,A发送的数据报,首先会走到自己的默认网关,然后,路由器会判断需不需要进行下一跳,直到转发到,目的的局域网,然后解析出MAC地址,将数据包交付到目的主机。

传输层:传输层建立了端到端的链接,向高层屏蔽了数据通信的细节,TCP协议还通过滑动窗口,流量控制,拥塞控制使传输层变的可靠。

会话层:建立,创建,管理会话。

应用层:确保一个系统的应用能被另一个系统所识别。

应用层: 直接为用户提供服务。

TCP的keep-live是什么?

TCP 的Keepalive 也叫TCP 保活机制 ,该功能是由「内核」实现的,当客户端和服务端长达一定时间没有进行数据交互时,内核为了确保该连接是否还有效,就会发送探测报文,来检测对方是否还在线,然后来决定是否要关闭该连接。

TCP 的 Keepalive 和 HTTP 的 Keep-Alive 是一个东西吗?

HTTP 的 Keep-Alive 也叫 HTTP 长连接,该功能是由「应用程序」实现的,可以使得用同一个 TCP 连接来发送和接收多个 HTTP 请求/应答,减少了 HTTP 短连接带来的多次 TCP 连接建立和释放的开销。如果关闭,需要显示的在请求头中显示

TCP 的 Keepalive 也叫 TCP 保活机制,该功能是由「内核」实现的,当客户端和服务端长达一定时间没有进行数据交互时,内核为了确保该连接是否还有效,就会发送探测报文,来检测对方是否还在线,然后来决定是否要关闭该连接。

HTTP1.0和HTTP1.1的一些区别

  1. 缓存处理,在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准,HTTP1.1则引入了更多的缓存控制策略例如Entity tag,If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
  2. 带宽优化及网络连接的使用 ,HTTP1.0中,存在一些浪费带宽的现象,例如客户端只是需要某个对象的一部分,而服务器却将整个对象送过来了,并且不支持断点续传功能,HTTP1.1则在请求头引入了range头域,它允许只请求资源的某个部分,即返回码是206(Partial Content),这样就方便了开发者自由的选择以便于充分利用带宽和连接。
  3. 错误通知的管理 ,在HTTP1.1中新增了24个错误状态响应码,如409(Conflict)表示请求的资源与资源的当前状态发生冲突;410(Gone)表示服务器上的某个资源被永久性的删除。
  4. Host头处理 ,在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名(hostname)。但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域,且请求消息中如果没有Host头域会报告一个错误(400 Bad Request)。
  5. 长连接 ,HTTP 1.1支持长连接(PersistentConnection)和请求的流水线(Pipelining)处理,在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟,在HTTP1.1中默认开启Connection: keep-alive,一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

HTTP2.0和HTTP1.X相比的新特性

多路复用

HTTP 队头阻塞的问题,其根本原因在于HTTP 基于请求-响应的模型,在同一个 TCP 长连接中,前面的请求没有得到响应,后面的请求就会被阻塞。

HTTP 1.1 用并发连接域名分片 的方式来解决这个问题,但这并没有真正从 HTTP 本身的层面解决问题,只是增加了 TCP 连接,分摊风险而已。而且这么做也有弊端,多条 TCP 连接会竞争有限的带宽 ,让真正优先级高的请求不能优先处理。

二进制分帧

首先,HTTP/2 认为明文传输对机器而言太麻烦了,不方便计算机的解析,因为对于文本而言会有多义性的字符,比如回车换行到底是内容还是分隔符,在内部需要用到状态机去识别,效率比较低。于是 HTTP/2 干脆把报文全部换成二进制格式,全部传输01串,方便了机器的解析。

原来Headers + Body的报文格式如今被拆分成了一个个二进制的帧,用Headers帧 存放头部字段,Data帧 存放请求体数据。分帧之后,服务器看到的不再是一个个完整的 HTTP 请求报文,而是一堆乱序的二进制帧。这些二进制帧不存在先后关系,因此也就不会排队等待,也就没有了 HTTP 的队头阻塞问题。

二进制帧到达后对方会将 Stream ID 相同的二进制帧组装成完整的请求报文响应报文

通信双方都可以给对方发送二进制帧,这种二进制帧的双向传输的序列 ,也叫做流(Stream)。HTTP/2 用流来在一个 TCP 连接上来进行多个数据帧的通信,这就是多路复用 的概念。

流传输的特性

  • 并发性。一个 HTTP/2 连接上可以同时发多个帧,这一点和 HTTP/1 不同。这也是实现多路 复用的基础。
  • 自增性。流 ID 是不可重用的,而是会按顺序递增,达到上限之后又新开 TCP 连接从头开始。
  • 双向性。客户端和服务端都可以创建流,互不干扰,双方都可以作为发送方或者接收方。
  • 可设置优先级。可以设置数据帧的优先级,让服务端先处理重要资源,优化用户体验。

header压缩 ,如上文中所言,对前面提到过HTTP1.x的header带有大量信息,而且每次都要重复发送,HTTP2.0使用encoder来减少需要传输的header大小,通讯双方各自cache一份header fields表,既避免了重复header的传输,又减小了需要传输的大小。

服务端推送 (server push),同SPDY一样,HTTP2.0也具有server push功能。


标题:网络
作者:哇哇哇哇
地址:https://wuxiangshi.vip/articles/2022/02/17/1645096427624.html