前端面试思维导图 - 网络基础相关知识点
2021-01-26 19:36:57 0 举报
AI智能生成
整理了前端面试中,网络通信基础的相关知识点以及概念等,供参考
作者其他创作
大纲/内容
应用层
HTTP协议
定义:HTTP 是超文本传输协议,它定义了客户端和服务器之间交换报文的格式和方式,是基于TCP/IP通信协议传递数据,默认使用 80 端口(不涉及数据包(packet)传输)
特性
无状态(服务器不会保存任何客户端信息)
媒体独立:只要客户端和服务器知道如何处理的数据内容,任何类型的数据都可以通过HTTP发送。客户端以及服务器指定使用适合的MIME-type内容类型。
无连接:限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接。采用这种方式可以节省传输时间。
HTTP1.1之后默认采用持续连接,connection:keep-alive
报文
请求报文
组成内容:请求行、请求头、空行和请求数据
例子:
GET index.html / HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*
请求方法
GET:请求指定的页面信息,并返回实体主体
POST:向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改
HEAD:类似于 GET 请求,只不过返回的响应中没有具体的内容,用于获取报头
PUT:从客户端向服务器传送的数据取代指定的文档的内容
DELETE:请求服务器删除指定的页面
CONNECT:HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器
OPTIONS:允许客户端查看服务器的性能
TRACE:回显服务器收到的请求,主要用于测试或诊断
PATCH:是对 PUT 方法的补充,用来对已知资源进行局部更新
响应报文
组成内容:
状态行、消息报头、空行和响应正文
例子:
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain
响应头信息
Allow:服务器支持哪些请求方法(如GET、POST等)
Content-Encoding:文档的编码方法。只有在解码之后才可以得到Content-Type头指定的内容类型。利用gzip压缩文档能够显著地减少HTML文档的下载时间
Content-Length:表示内容长度。只有当浏览器使用持久HTTP连接时才需要这个数据。如果你想要利用持久连接的优势,可以把输出文档写入 ByteArrayOutputStream,完成后查看其大小
Content-Type:表示后面的文档属于什么MIME类型。Servlet默认为text/plain,但通常需要显式地指定为text/html
Date:当前的GMT时间。你可以用setDateHeader来设置这个头以避免转换时间格式的麻烦
Expires:应该在什么时候认为文档已经过期,从而不再缓存它
Last-Modified:文档的最后改动时间。客户可以通过If-Modified-Since请求头提供一个日期,该请求将被视为一个条件GET,只有改动时间迟于指定时间的文档才会返回,否则返回一个304(Not Modified)状态
Location:表示客户应当到哪里去提取文档
Refresh:表示浏览器应该在多少时间之后刷新文档,以秒计。除了刷新当前文档之外,你还可以通过setHeader("Refresh", "5; URL=http://host/path")让浏览器读取指定的页面
Server:服务器名字,由Web服务器自己设置
Set-Cookies:设置和页面关联的Cookie
WWW-Authenticate:客户应该在Authorization头中提供什么类型的授权信息?在包含401(Unauthorized)状态行的应答中这个头是必需的
状态码
1**
100:Continue,客户端应继续其请求
101:Switching Protocols,服务器根据客户端的请求切换协议。只能切换到更高级的协议,例如,切换到HTTP的新版本协议
2**
200:OK,一般用于GET与POST请求
201:Created,成功请求并创建了新的资源
202:Accepted,已经接受请求,但未处理完成
203:Non-Authoritative Information,非授权信息。请求成功。但返回的meta信息不在原始的服务器,而是一个副本
204:No Content,无内容。服务器成功处理,但未返回内容。在未更新网页的情况下,可确保浏览器继续显示当前文档
205:Reset Content,重置内容。服务器处理成功,用户终端(例如:浏览器)应重置文档视图。可通过此返回码清除浏览器的表单域
206:Partial Content,部分内容。服务器成功处理了部分GET请求
3**
300:Multiple Choices, 多种选择。请求的资源可包括多个位置,相应可返回一个资源特征与地址的列表用于用户终端(例如:浏览器)选择
301:Moved Permanently,永久移动。请求的资源已被永久的移动到新URI,返回信息会包括新的URI,浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302:Found,临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI
303:See Other,查看其它地址。与301类似。使用GET和POST请求查看
304:Not Modified,未修改。所请求的资源未修改,服务器返回此状态码时,不会返回任何资源。客户端通常会缓存访问过的资源,通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
305:Use Proxy,使用代理。所请求的资源必须通过代理访问
306:Unused,已经被废弃的HTTP状态码
307:Temporary Redirect,临时重定向。与302类似。使用GET请求重定向
4**
400:Bad Request,客户端请求的语法错误,服务器无法理解
401:Unauthorized,请求要求用户的身份认证
402:Payment Required,保留,将来使用
403:Forbidden,服务器理解请求客户端的请求,但是拒绝执行此请求
404:Not Found,服务器无法根据客户端的请求找到资源(网页)。通过此代码,网站设计人员可设置"您所请求的资源无法找到"的个性页面
405:Method Not Allowed,客户端请求中的方法被禁止
406:Not Acceptable,服务器无法根据客户端请求的内容特性完成请求
407:Proxy Authentication Required,请求要求代理的身份认证,与401类似,但请求者应当使用代理进行授权
408:Request Time-out,服务器等待客户端发送的请求时间过长,超时
409:Conflict,服务器完成客户端的 PUT 请求时可能返回此代码,服务器处理请求时发生了冲突
410:Gone,客户端请求的资源已经不存在。410不同于404,如果资源以前有现在被永久删除了可使用410代码,网站设计人员可通过301代码指定资源的新位置
411:Length Required,服务器无法处理客户端发送的不带Content-Length的请求信息
412:Precondition Failed,客户端请求信息的先决条件错误
413:Request Entity Too Large,由于请求的实体过大,服务器无法处理,因此拒绝请求。为防止客户端的连续请求,服务器可能会关闭连接。如果只是服务器暂时无法处理,则会包含一个Retry-After的响应信息
414:Request-URI Too Large,请求的URI过长(URI通常为网址),服务器无法处理
415:Unsupported Media Type,服务器无法处理请求附带的媒体格式
416:Requested range not satisfiable,客户端请求的范围无效
417:Expectation Failed,服务器无法满足Expect的请求头信息
5**
500:Internal Server Error,服务器内部错误,无法完成请求
501:Not Implemented,服务器不支持请求的功能,无法完成请求
502:Bad Gateway,作为网关或者代理工作的服务器尝试执行请求时,从远程服务器接收到了一个无效的响应
503:Service Unavailable,由于超载或系统维护,服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中
504:Gateway Time-out,充当网关或代理的服务器,未及时从远端服务器获取请求
505:HTTP Version not supported,服务器不支持请求的HTTP协议的版本,无法完成处理
HTTP的缺点
使用明文方式发送,可能被第三方窃听
可能被第三方截取后修改通信内容,接收方没有办法发现报文内容的修改
存在认证的问题,第三方可以冒充他人参与通信
HTTP/1.0协议
缺点:每个TCP连接只能发送一个请求。发送数据完毕,连接就关闭,如果还要请求其他资源,就必须再新建一个连接。
TCP连接的新建成本很高,因为需要客户端和服务器三次握手,并且开始时发送速率较慢(slow start)。所以,HTTP 1.0版本的性能比较差。随着网页加载的外部资源越来越多,这个问题就愈发突出了。
为了解决这个问题,有些浏览器在请求时,用了一个非标准的Connection(keep-alive)字段。
HTTP/1.1协议
特点
持久连接(persistent connection),即TCP连接默认不关闭,可以被多个请求复用,不用声明Connection: keep-alive;(主动关闭连接。不过,规范的做法是,客户端在最后一个请求时,发送Connection: close)
管道机制(pipelining),即在同一个TCP连接里面,客户端可以同时发送多个请求
多个回应如何区分:
1.使用Content-Length标识一次回应数据长度,来区分多个回应
2.使用Transfer-Encoding:chunked,每个非空数据块前使用一个16进制的数字标识该段数据长度,最后一个为长度为0即结束
新增PUT/PATCH/HEAD/OPTIONS/DELETE
缺点:所有的数据通信是按次序进行的。服务器只有处理完一个回应,才会进行下一个回应。要是前面的回应特别慢,后面就会有许多请求排队等着。这称为"队头堵塞"(Head-of-line blocking)。
解决方法:
1.减少请求数
2.同时多开持久连接。
与HTTP/1.0的区别
缓存处理:在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准,HTTP1.1则引入了更多的缓存控制策略例如Entity tag,If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略
带宽优化:HTTP1.0中,存在一些浪费带宽的现象,例如客户端只是需要某个对象的一部分,而服务器却将整个对象送过来了,并且不支持断点续传功能,HTTP1.1则在请求头引入了range头域,它允许只请求资源的某个部分,即返回码是206(Partial Content),这样就方便了开发者自由的选择以便于充分利用带宽和连接
错误通知的管理优化:在HTTP1.1中新增了24个错误状态响应码,如409(Conflict)表示请求的资源与资源的当前状态发生冲突;410(Gone)表示服务器上的某个资源被永久性的删除
Host头处理:在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名(hostname)。但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域,且请求消息中如果没有Host头域会报告一个错误(400 Bad Request)
长连接:HTTP 1.1支持长连接(PersistentConnection)和请求的流水线(Pipelining)处理,在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟,在HTTP1.1中默认开启Connection: keep-alive,一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。
HTTP/2协议
特点
二进制协议:头信息和数据体都是二进制,并且统称为"帧"(frame):头信息帧和数据帧
多工:HTTP/2 复用TCP连接,在一个连接里,客户端和浏览器都可以同时发送多个请求或回应,而且不用按照顺序一一对应,这样就避免了"队头堵塞"。
数据流:HTTP/2 将每个请求或回应的所有数据包,称为一个数据流(stream)。每个数据流都有一个独一无二的编号。数据包发送的时候,都必须标记数据流ID,用来区分它属于哪个数据流。另外还规定,客户端发出的数据流,ID一律为奇数,服务器发出的,ID为偶数;可通过发送信号(RST_STREAM帧),取消这个数据流。
头信息压缩:头信息使用gzip或compress压缩后再发送;另一方面,客户端和服务器同时维护一张头信息表,所有字段都会存入这个表,生成一个索引号,以后就不发送同样字段了,只发送索引号,这样就提高速度了。
服务器推送:允许服务器未经请求,主动向客户端发送资源
缺点:由于多个数据流使用同一个 TCP 连接,遵 守同一个流量状态控制和拥塞控制。只要一个数据流遭遇到拥塞,剩下的数据流就没法发出去,这样就导致了后面的所有数据都 会被阻塞。HTTP/2 出现的这个问题是由于其使用 TCP 协议的问题,与它本身的实现其实并没有多大关系。
HTTP网络请求影响因素
带宽
延迟
浏览器阻塞:浏览器对于同一个域名,同时只能有 4 个连接(大多数是6个),超过浏览器最大连接数限制,后续请求就会被阻塞
DNS查询:浏览器需要知道目标服务器的 IP 才能建立连接。将域名解析为 IP 的这个系统就是 DNS。这个通常可以利用DNS缓存结果来达到减少这个时间的目的
建立连接:HTTP 是基于 TCP 协议的,浏览器最快也要在第三次握手时才能捎带 HTTP 请求报文,达到真正的建立连接,但是这些连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显,慢启动则对文件类大请求影响较大
HTTPS
特点
需要到CA申请证书,一般免费证书很少,需要交费
运行在SSL/TLS之上,SSL/TLS运行在TCP之上,所有传输的内容都经过加密的
完全不同的连接方式,用的端口也不一样,前者是80,后者是443
可以有效的防止运营商劫持,解决了防劫持的一个大问题
TLS握手过程
客户端向服务器发起请求,请求中包含客户端支持的加密方法(加密算法清单)
服务器端接收到请求后,确认双方使用的加密方法、并给出服务器的证书、以及一个服务器生成的随机数
客户端确认服务器证书有效后,生成一个随机数,并使用数字证书中的公钥,加密这个随机数,然后发给服务器
服务器使用自己的私钥,来解密客户端发送过来的随机数。并提供前面所有内容的 hash 值来供客户端检验
客户端和服务器端根据约定的加密方法使用前面的三个随机数,生成对话秘钥,以后的对话过程都使用这个秘钥 来加密信息
客户端给服务端发送消息使用非对称加密,服务端给客户端发送消息使用对称加密
WebSocket
定义:HTML5 开始提供的一种在单个 TCP 连接上进行全双工通讯的协议;使得客户端和服务器之间的数据交换变得更加简单,允许服务端主动向客户端推送数据。在 WebSocket API 中,浏览器和服务器只需要完成一次握手,两者之间就直接可以创建持久性的连接,并进行双向数据传输
数据轮询与推送
短轮询:浏览器每隔一段时间向浏览器发送 http 请求,服务器端在收到请求后,不论是否有数据更新,都直接进行响应
缺点:浏览器和服务器都很浪费资源,用户增加会导致服务器端压力变大
长轮询:客户端发起请求,服务端判断数据有更新则相应,无响应则挂起。客户端得到响应后才进行下一次请求
缺点:连接挂起后也会导致资源浪费
SSE:HTTP/2允许服务器向客户端发送数据流
WebSocket:以上三种都是基于HTTP协议的,WebSocket是全双工的协议,可以互相发送消息;
传输层
两个进程间的通信,比如TCP和UDP,使用端口号(port number)来识别收信人(某个进程)。在写信的时候,我们写上目的地的端口。当信到达目的地的管理员手中,他会根据传输层协议,识别端口号,将信送给不同的人。
TCP
特点
面向连接的,在通信双方进行通信前,需要通过三次握手建立连接。它需要在端系统中维护双方连接的状态信息
通过序号、确认号、定时重传、检验和等机制,来提供可靠的数据传输服务
对点的服务,即它是在单个发送方和单个接收方之间的连接
全双工的服务,也就是说连接的双方的能够向对方发送和接收数据
提供了拥塞控制机制,在网络拥塞的时候会控制发送数据的速率,有助于减少数据包的丢失和减轻网络中的拥塞程度
提供了流量控制机制,保证了通信双方的发送和接收速率相同。如果接收方可接收的缓存很小时,发送方会降低发送 速率,避免因为缓存填满而造成的数据包的丢失
报文
首部(20个字节)
数据
三次握手:建立TCP连接
第一次握手(SYN=1, seq=x):客户端发送一个 TCP 的 SYN 标志位置1的包,指明客户端打算连接的服务器的端口,以及初始序号 X,保存在包头的序列号(Sequence Number)字段里。发送完毕后,客户端进入 SYN_SEND 状态
SYN, seq=x
第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1):服务器发回确认包(ACK)应答。即 SYN 标志位和 ACK 标志位均为1。服务器端选择自己 ISN 序列号,放到 Seq 域里,同时将确认序号(Acknowledgement Number)设置为客户的 ISN 加1,即X+1。 发送完毕后,服务器端进入 SYN_RCVD 状态
SYN, ACK, ack=x+1, seq=y
第三次握手(ACK=1,ACKnum=y+1):客户端再次发送确认包(ACK),SYN 标志位为0,ACK 标志位为1,并且把服务器发来 ACK 的序号字段+1,放在确定字段中发送给对方,并且在数据段放写ISN的+1;发送完毕后,客户端进入 ESTABLISHED 状态,当服务器端接收到这个包时,也进入 ESTABLISHED 状态,TCP 握手结束。
ACK, seq=x+1, ack=y+1
三次握手的原因:避免服务器端接收到无效连接请求,而导致服务端一直等待浪费资源
四次挥手:TCP连接的释放
客户端认为没有数据要再发送给服务器端,它就向服务器发送一个 FIN 报文段,申请断开客户端到服务器端的 连接。发送后客户端进入 FIN_WAIT_1 状态
FIN, seq=u
服务器端接收到客户端释放连接的请求后,向客户端发送一个确认报文段,表示已经接收到了客户端释放连接的 请求,以后不再接收客户端发送过来的数据。但是因为连接是全双工的,所以此时,服务器端还可以向客户端发送数据。服务器端进入 CLOSE_WAIT 状态。客户端收到确认后,进入 FIN_WAIT_2 状态
ACK, seq=v, ack=u+1
服务器端发送完所有数据后,向客户端发送 FIN 报文段,申请断开服务器端到客户端的连接。发送后进入 LAS T_ACK 状态
FIN, ACK, seq=w, ack=u+1
客户端接收到 FIN 请求后,向服务器端发送一个确认应答,并进入 TIME_WAIT 阶段。该阶段会持续一段时间, 这个时间为报文段在网络中的最大生存时间,如果该时间内服务端没有重发请求的话,客户端进入 CLOSED 的状态。如果收到 服务器的重发请求就重新发送确认报文段。服务器端收到客户端的确认报文段后就进入 CLOSED 状态,这样全双工的连接就被 释放了
ACK, seq=u+1, ack=w+1
UDP
定义:UDP 是一种无连接的,不可靠的传输层协议。它只提供了传输层需要实现的最低限度的功能,除了复用/分解功能和少量的差 错检测外,它几乎没有对 IP 增加其他的东西。UDP 协议适用于对实时性要求高的应用场景。
特点
无连接:在发送报文段之前,通信双方没有握手的过程,因此 UDP 被称为是无连接的传输层协议。因为没有握手 过程,相对于 TCP 来说,没有建立连接的时延。因为没有连接,所以不需要在端系统中保存连接的状态
UDP 协议不保证数据的可靠交付
没有拥塞控制和流量控制的机制,所以 UDP 报文段的发送速率没有限制
一个 UDP 套接字只使用目的地址和目的端口来标识,所以 UDP 可以支持一对一、一对多、多对一和多对多的交互通信
首部小,只有 8 个字节
网络层
两个计算机间的通信
数据链路层(连接层)
信息以帧(frame)为单位传输。所谓的帧,是一段有限的0/1序列。连接层协议的功能就是识别0/1序列中所包含的帧。比如说,根据一定的0/1组合识别出帧的起始和结束。在帧中,有收信地址(Source, SRC)和送信地址(Destination, DST),还有能够探测错误的校验序列(Frame Check Sequence)。当然,帧中最重要的最重要是所要传输的数据 (payload)。这些数据往往符合更高层协议,供网络的上层使用。与数据相配套,帧中也有数据的类型(Type)信息。连接层协议不关心数据中到底包含什么。帧就像是一个信封,把数据包裹起来;例如以太网和WiFi协议是最常见的连接层协议
物理层
指光纤、电缆或者电磁波等真实存在的物理媒介。这些媒介可以传送物理信号,比如亮度、电压或者振幅。对于数字应用来说,我们只需要两种物理信号来分别表示0和1,比如用高电压表示1,低电压表示0,就构成了简单的物理层协议。针对某种媒介,电脑可以有相应的接口,用来接收物理信号,并解读成为0/1序列
DNS
定义:主机名到 IP 地址的转换服务,就是我们常说的域名系统;是一个由分层的 DNS 服务器组成的分 布式数据库,是定义了主机如何查询这个分布式数据库的方式的应用层协议。DNS 协议运行在 UDP 协议之上,使用 53 号端口
域名层级:主机名.次级域名.顶级域名.根域名
查询过程
请求发送到本地的 DNS 服务器中,本地 DNS 服务 器会判断是否存在该域名的缓存
从"根域名服务器"查到"顶级域名服务器"的 NS 记录和 A 记录( IP 地址)
从"顶级域名服务器"查到"次级域名服务器"的 NS 记录和 A 记录( IP 地址)
从"次级域名服务器"查出"主机名"的 IP 地址
CDN(内容分发网络)
CDN 是一个内容分发网络,通过对源网站资源的缓存,利用本身多台位于不同地域、不同运营商的服务器,向用户提供资就近访问的功能。也就是说,用户的请求并不是直接发送给源网站,而是发送给 CDN 服务器,由 CDN 服务器将请求定位到最近的含有该资源的服务器上去请求。这样有利于提高网站的访问速度,同时通过这种方式也减轻了源服务器的访问压力
缓存
遵循http标准协议,可以通过http响应头中的Cache-Control: max-age字段来控制
优势
CDN节点解决了跨运营商和跨地域访问的问题,访问延时大大降低
大部分请求在CDN边缘节点完成,CDN起到了分流作用,减轻了源服务器的负载
浏览器缓存机制
定义:浏览器保存通过HTTP获取的所有资源,是浏览器将网络资源存储在本地的一种行为
三级缓存原理
memory cache
将资源缓存到内存中,等待下次访问时不需要重新下载资源,而直接从内存中获取。Webkit早已支持memoryCache
主资源
HTML页面
下载项
派生资源
内嵌图片
脚本链接
特点
只能存储派生类资源文件
退出进程时数据删除
一般缓存脚本、字体、图片等
disk cache
将资源缓存到磁盘中,等待下次访问时不需要重新下载资源,而直接从磁盘中获取,它的直接操作对象为CurlCacheManager
特点
只能存储派生类资源文件
退出进程不会删除数据
一般非脚本存在内存当中,css等
先在内存中查找,如果有,直接加载
如果内存中不存在,则在硬盘中查找,如果有直接加载
如果硬盘中也没有,那么就进行网络请求
请求获取的资源缓存到硬盘和内存
缓存分类
强缓存
浏览器在加载资源时,会先根据本地缓存资源的 header 中的信息判断是否命中强缓存,如果命中则直接使用缓存中的资源不会再向服务器发送请求
header设置字段
Expires
这个资源的失效绝对时间,在此时间之前,即命中缓存,当服务器与客户端时间偏差较大时,就会导致缓存混乱
Cache-Control
值分类
max-age
一个相对时间
no-cache
需要进行协商缓存,发送请求到服务器确认是否使用缓存
no-store
禁止使用缓存,每一次都要重新请求数据
public
可以被所有的用户缓存,包括终端用户和 CDN 等中间代理服务器
private
只能被终端用户的浏览器缓存,不允许 CDN 等中继缓存服务器对其缓存
Cache-Control 与 Expires 可以在服务端配置同时启用,同时启用的时候 Cache-Control 优先级高
协商缓存
当强缓存没有命中的时候,浏览器会发送一个请求到服务器,服务器根据 header 中的部分信息来判断是否命中缓存。
Last-Modify
第一次请求,服务器返回该标识;标识该资源的最后修改时间
If-Modify-Since
再次请求,浏览器会在请求头中添加,缓存之前的Last-Modify值;服务器收到 If-Modify-Since 后,根据资源的最后修改时间判断是否命中缓存
Etag
第一次请求,服务器返回一个校验码,保证每个资源唯一
If-None-Match
再次请求,浏览器会带上If-None-Match判断是否命中缓存
Last-Modified 与 ETag 是可以一起使用的,服务器会优先验证 ETag,一致的情况下,才会继续比对 Last-Modified,最后才决定是否返回 304
0 条评论
下一页