前端面试总结-计算机网络

445 阅读24分钟

DNS解析过程

.先在浏览器缓存中查找,如果找到域名对应ip,解析结束,否则下一步

2.在本地操作系统中查找,host查找(域名劫持就是通过修改host中域名到ip的映射),找到结束,否则下一步

3.到LDNS(本地域名服务器),一般就在你的城市,离你不会很远,大约80%的域名解析最多到这就结束了

4.到RootServer,根域名服务器,根域名服务器会返回给LDNS一个所查询域的主域名服务器(gTLD Server,国际顶尖域名服务器,如.com .cn .org)地址

5.LDNS根据这个地址向gTLD Server发送查询请求,gTLD返回一个Name Serve的地址,Nameserver就是网站注册的域名服务器

6.Name Server根据映射信息,返回目标ip给LDNS

7.LDNS缓存这个域名和对应的ip

8.LDNS把解析的结果返回给用户,客户端再将次域名ip缓存早本地,域名解析过程结束

TCP三次握手

第一次握手:起初客户端和服务器都处于CLOSED状态,在客户端打算建立TCP连接时,向服务器发出连接请求报文段,这时首部中的同步位SYN=1,同时选择一个初始序号seq=x。这时客户端进入SYN-SENT(同步已发送)状态。

第二次握手:服务器收到连接请求报文段后,如同意建立连接,则向客户端发送确认。在确认报文段中将SYN位和ACK位都置1,确认号是ack=x+1,同时也为自己选择一个初始序号seq=y。此时服务器端进入SYN-RCVD(同步收到)状态。

第三次握手:客户端收到服务器的确认后,还要向服务器发送确认。确认报文段的ACK置1,确认号ack=y+1,而自己的序号seq=x+1。此时,TCP连接已经建立,客户端进入ESTABLISHED状态(已建立连接)。当服务器收到客户端的确认后,也进入ESTABLISHED状态,完成三次握手,之后就可以传送数据了。

image.png

TCP四次挥手

第一次挥手:此时客户端和服务器都处于ESTABLISHED状态,客户端先向服务器发出连接释放报文段,并停止再发送数据,主动关闭TCP连接。客户端把连接释放报文段首部的终止控制位FIN置1,序号seq=u,此时客户端进入FIN-WAIT-1状态。

第二次挥手:服务器收到连接释放报文段后即发出确认,确认号是ack=u+1,自己的序号是v,然后服务器进入CLOSE-WAIT状态。此时TCP连接处于半关闭状态。客户端收到服务器的确认后,进入FIN-WAIT-2状态。

第三次挥手:若服务器没有要向客户端发送的数据了,其应用进程就通知TCP释放连接,此时服务器发出的连接释放报文段必须使FIN=1,假定服务器的序号为w,确认号ack=u+1,此时服务器进入LAST-ACK状态。

第四次挥手:客户端收到服务器的连接释放报文段后,对此发出确认。在确认报文段中将ACK置1,确认号ack=w+1,自己的序号seq=u+1,然后进入TIME-WAIT状态,经过时间等待计时器设置的时间2MSL后,客户端才进入到CLOSED状态,此时就结束了这次TCP连接。

image.png

TCP/IP四层模型

应用层

传输层

网络层

网络接口层

TCP/IP五层模型

应用层

传输层

网络层

数据链路层

物理层

OSI七层模型

从上到下分别是:

应用层:为用户提供服务,常用协议HTTP,snmp,FTP ,SMTP DNS

表示层:为数据提供表示、加密、压缩,ASCII

会话层:建立,解除会话,确定数据是否需要进行网络传递,SQL NFS

传输层:提供端对端的接口,对报文进行分组、传输协议、端口封装、差错校验 TCP UDP

网络层:ip地址编址,路由选择,ARP IP ICMP

数据链路层:MAC地址编译、传输有地址的帧 IEEE 802.3/802.2 HDLC

物理层:二进制的数据形式在物理媒体上传输数据 PPP(点对点协议) SLTP(串行线路网际协议)

TCP的拥塞控制

TCP的四种拥塞控制算法 1.慢开始 2.拥塞避免 3.快重传 4.快恢复

当cwnd<ssthresh时,使用慢开始(指数增加 1 2 4 8 16)

当cwnd>ssthresh时,停止使用慢开始改用拥塞避免算法(线性+1)

当cwnd=ssthresh时,既可以使用慢开始算法,也可以使用拥塞避免算法

image.png

image.png

HTTP

一、HTTP常见状态码

按第一个数字分类:1表示信息,2表示成功,3表示重定向,4表示客户端错误,5表示服务器错误

状态码含义
200 OK请求成功。一般用于get和post请求
301 Moved Permanently永久移动。请求的信息已经被移动到新的URI,会返回新的URI
302 Found临时移动。资源只是临时被移动,客户端继续使用原URI
304 Not Modified未修改。所请求的资源未修改,服务器返回此状态码,不会返回任何资源
400 Bad Request客户端请求的语法错误,服务器无法理解(产生原因:前端提交的数据在后台找不到与之相对应的实体)
401 Unauthorized当前请求需要用户验证
403 Forbidden服务器已经收到请求,但拒绝执行
404 Not Found服务器无法根据用户的请求找到资源
500 Internal Server Error服务器内部错误,无法完成请求

二、HTTP的首部有哪些?

  • 通用首部:表示一些通用信息,如date表示报文创建时间
  • 请求首部:请求报文独有,如cookie、If-Modified-Since
  • 响应首部:响应报文独有,如set-cookie、Last-Modified
  • 实体首部:描述实体部分,如allow用来描述可执行的请求方法、content-type描述主体类型、content-Encoding描述主体的编码方式

三、HTTP支持的方法

方法作用
get请求指定的页面信息并返回响应主体,一般用于数据的读取
post向指定资源提交数据,请求服务器去处理
head获取服务器的响应头信息,常用于客户端查看服务器的性能
options请求服务器返回该资源所支持的所有HTTP请求方法,常用于客户端查看服务器的性能
put向指定资源位置上传其最新内容
delete请求服务器删除所请求URI所标识的资源
connect将连接改为管道方式的代理服务器,常用于SSL加密服务器与非加密的HTTP代理服务器的通信
trace请求服务器回显其收到的请求信息,常用于HTTP请求的测试或诊断

四、get和post有什么区别?

get和post本质上就是TCP链接,并无差别,但由于HTTP的规定和浏览器、服务器的限制,导致它们在应用过程中有一些不同:

  • get参数通过URL传递;post放在request body中
  • get请求在URL中传递的参数有长度限制;post没有(HTTP协议未规定,是因为浏览器和服务器的限制)
  • get请求只能进行URL编码;post请求有多种编码方式
  • get请求参数会被完整保留在浏览历史记录里;post中的参数不会被保留
  • get产生一个TCP数据包;post产生两个TCP数据包
  • 对于get请求,浏览器将http header和data一并发送,服务器响应200 OK;对于post请求,浏览器先发送header,服务器响应100 Continue,浏览器再发送data,服务器响应200 OK
  • 缓存方面:get请求类似于查找的过程,用户获取数据,可以不用每次都与数据库连接,所以可以使用缓存;post请求一般做的是修改和删除工作,必须与数据库交互,所以不能使用缓存

五、http2.0的新特点

  • 基于HTTPS天然具有安全性
  • 二进制分帧层:将所有传输信息分割成更小的信息或帧,并进行二进制编码(http2.0性能增强核心)
  • 允许多路复用:基于二进制分帧层,在共享TCP连接的基础上,同时发送请求和响应。HTTP消息被分解为独立的帧,而不破坏消息本身的语义,交错发送出去,最后在另一端根据流ID和首部将他们重新组合起来
  • 服务器推送:服务端根据客户端的请求,提前返回多个响应,推送额外的资源给客户端,支持缓存(遵循同源策略;基于客户端的请求响应来确定的)

六、HTTP缓存机制

  1. 两种缓存方式,根据响应的header内容来决定
  2. 强缓存(状态码:200):浏览器不向服务器发送任何请求,直接从本地缓存中读取文件并返回(相关字段:Cache-Control、Expires)
  3. 协商缓存(状态码304):浏览器发送请求到服务器,通过服务器来告知缓存是否可用(相关字段:Last-Modified/If-Modified-Since、Etag/If-None-Match)
  4. 缓存相关header Cache-Control、Expires、Last-Modified/If-Modified-Since、Etag/If-None-Match
  5. 流程

image.png

七、HTTP请求包括哪几个部分

1.请求报文(请求行/请求头/空行/请求数据)

  • 请求行

    请求方法字段、URL字段和HTTP协议版本

    例如:GET /index.html HTTP/1.1

    get方法将数据拼接在url后面,传递参数受限

    请求方法:

    GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT

  • 请求头(key value形式)

User-Agent:产生请求的浏览器类型。

Accept:客户端可识别的内容类型列表。

Host:主机地址

Content-Type:请求体的MIME类型 (用于POST和PUT请求中)

  • 空行

发送回车符和换行符,通知服务器以下不再有请求头

  • 请求数据

post方法中,会把数据以key value形式发送请求

请求数据不在GET方法中使用,而是在POST方法中使用。POST方法适用于需要客户填写表单的场合。与请求数据相关的最常使用的请求头是Content-Type和Content-Length。

例如:

GET /sample.jsp HTTP/1.1

Accept:image/gif.image/jpeg, /

Accept-Language:zh-cn

Connection:Keep-Alive

Host:localhost

User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)

Accept-Encoding:gzip,deflate

username=jinqiao&password=1234

2.响应报文(状态行/响应头/空行/响应正文)

  • 状态行

    由http版本 + 状态码 + 状态代码的文本描述三个部分组成

    例如HTTP/1.1 200 ok

  • 响应头

    包含服务器类型,日期,长度,内容类型等

    Server:Apache Tomcat/5.0.12

    Date:Mon,6Oct2003 13:13:33 GMT

    Content-Type:text/html

    Last-Moified:Mon,6 Oct 2003 13:23:42 GMT

    Content-Length:112

  • 空行

  • 响应正文

    就是服务器返回的HTML页面或者json数据

    讲一下HTTP缓存

http缓存指的是: 当客户端向服务器请求资源时,会先抵达浏览器缓存,如果浏览器有“要请求资源”的副本,就可以直接从浏览器缓存中提取而不是从原始服务器中提取这个资源。

根据是否需要重新向服务器发起请求来分类,可分为(强制缓存,协商缓存) 根据是否可以被单个或者多个用户使用来分类,可分为(私有缓存,共享缓存) 强制缓存如果生效,不需要再和服务器发生交互,而协商缓存不管是否生效,都需要与服务端发生交互。

使用http缓存的好处:

1.减少了冗余的数据传输,节省了网费。

2.缓解了服务器的压力, 大大提高了网站的性能

3.加快了客户端加载网页的速度

http缓存方案:

1.md5/hash缓存

2.CDN缓存(CDN边缘节点缓存数据,当浏览器请求时,CDN将代替源站判断并处理此处请求)

HTTP缓存机制

强缓存

cache-control: max-age=xxxx,public 客户端和代理服务器都可以缓存该资源; 客户端在xxx秒的有效期内,如果有请求该资源的需求的话就直接读取缓存,statu code:200 ,如果用户做了刷新操作,就向服务器发起http请求

cache-control: max-age=xxxx,private 只让客户端可以缓存该资源;代理服务器不缓存 客户端在xxx秒内直接读取缓存,statu code:200

cache-control: max-age=xxxx,immutable 客户端在xxx秒的有效期内,如果有请求该资源的需求的话就直接读取缓存,statu code:200 ,即使用户做了刷新操作,也不向服务器发起http请求

cache-control: no-cache 跳过设置强缓存,但是不妨碍设置协商缓存;一般如果你做了强缓存,只有在强缓存失效了才走协商缓存的,设置了no-cache就不会走强缓存了,每次请求都回询问服务端。

cache-control: no-store 不缓存,这个会让客户端、服务器都不缓存,也就没有所谓的强缓存、协商缓存了。

协商缓存

发请求-->看资源是否过期-->过期-->请求服务器-->服务器对比资源是否真的过期-->没过期-->返回304状态码-->客户端用缓存的老资源。

当然,当服务端发现资源真的过期的时候,会走如下流程:

发请求-->看资源是否过期-->过期-->请求服务器-->服务器对比资源是否真的过期-->过期-->返回200状态码-->客户端如第一次接收该资源一样,记下它的cache-control中的max-age、etag、last-modified等。

如果资源没更改,返回304,浏览器读取本地缓存。 如果资源有更改,返回200,返回最新的资源。

HTTPS

一、HTTPS工作原理

image.png

  1. 客户端通过URL发起HTTPS请求,要求服务器建立SSL链接
  2. 服务器收到客户端的请求后,返回公钥证书
  3. 客户端验证公钥证书是否有效,验证不通过则显示警告信息;验证通过则利用伪随机数生成器生成会话密钥,然后用证书的公钥加密会话密钥并发送给服务器
  4. 服务器通过自己的私钥解密会话密钥。至此,客户端和服务器双方都持有了相同的会话密钥
  5. 服务器和客户端之间通过会话密钥加密双方间的通信 二、HTTPS加密方式

HTTPS使用非对称加密传输一个对称密钥,服务器和客户端使用这个对称密钥来加密解密收发数据;而具体传输数据则是用对称加密的方式。

  • 对称加密DES:加密和解密使用同一个密钥(速度快)
  • 非对称加密RSA:发送端使用公开的公钥加密,接收端使用私密的私钥解密(安全)

三、HTTPS优点和缺点

优点

  • 能够进行信息加密、完整性校验和身份验证,很大程度上避免了HTTP协议容易发生信息窃听、信息篡改、信息劫持的风险。

缺点

  • 握手阶段比较费时,会使页面加载时间延长,增加耗电
  • HTTPS缓存不如HTTP高效,会增加数据开销
  • SSL证书需要费用,功能越强大的证书费用越高
  • SSL证书需要绑定IP,不能在同一个IP上绑定多个域名,ipv4资源支持不了这种消耗

四、HTTPS和HTTP的区别

HTTP:超文本传输协议,TCP协议的一种,用于从WWW服务器传输超文本到本地浏览器的一种网络协议

HTTPS:HTTP+SSL,是HTTP的安全版,加入SSL层实现加密传输和身份认证

区别

  • HTTP传输的数据是未加密的,即明文传输;HTTPS是具有安全性的SSL加密传输协议
  • HTTPS需要使用SSL证书;HTTP不用
  • 端口号不同,HTTP端口号80;HTTPS端口号443
  • HTTPS基于传输层;HTTP基于应用层

五、HTTPS中间人攻击及其防范

MITM中间人攻击:攻击者相当于一个介入通信的传话员,攻击者知道通信双方的所有通信内容且可以任意增加、删除、修改双方的通信内容,而双方对此并不知情。

通信过程安全性的保证(自下而上)

image.png

  1. 公钥的正确性:双方通信采用非对称加密的方式,非对称加密中私钥不会传递,而公钥是公开的 。
  2. 数字证书的正确性:公钥由对方在通信初始提供,但很容易被中间人替换,因此发送公钥的时候也要提供对应的数字证书,用于验证公钥来自于对方而不是中间人。
  3. 上级CA证书的正确性:数字证书由上级CA签发给个人或组织,上级CA用自己的私钥给个人证书签名,保证证书的公钥不被篡改。
  4. 根证书的私钥不被泄露或其公钥不被篡改:上级CA证书也是由其上级CA签发的,这条信任链一直延续到根证书,而根证书是自签名的。
  5. 设备分发到消费者手中之前不被恶意修改:根证书一般通过操作系统而非网络分发;最初的操作系统应采用原始的当面交流的方式分发。因此,硬件厂商和证书签发机构合作,在设备出厂前在其操作系统中内置签发机构的根证书。

HTTPS/SSL/TLS三者关系

SSL(Secure Socket Layer 安全套接层)是基于HTTPS下的一个协议加密层,SSL是基于HTTP之下TCP之上的一个协议层,是基于HTTP标准并对TCP传输数据时进行加密,所以HPPTS是HTTP+SSL/TCP的简称。由于HTTPS的推出受到了很多人的欢迎,在SSL更新到3.0时,IETF(The Internet Engineering Task Force - 互联网工程任务组)对SSL3.0进行了标准化,并添加了少数机制(但是几乎和SSL3.0无差异),标准化后的IETF更名为TLS1.0(Transport Layer Security 安全传输层协议),可以说TLS就是SSL的新版本3.1。TLS(传输层安全协议)是更为安全的升级版 SSL。由于 SSL 这一术语更为常用,因此我们仍然将我们的安全证书称作 SSL。但当您从赛门铁克购买 SSL 时,您真正购买的是最新的 TLS 证书,有 ECC、RSA 或 DSA 三种加密方式可以选择。

TLS/SSL是一种加密通道的规范

HTTP1/2/3

HTTP1是97年发布的,以前的网页主要是文本,现在更多的时富媒体,由于这个协议是针对以前的情况设计的,所以现在很多时候就不太好用了

blog.csdn.net/weixin_4120…

队头阻塞是指当顺序发送的请求序列中的一个请求因为某种原因被阻塞时,在后面排队的所有请求也一并被阻塞,会导致客户端迟迟收不到数据。针对队头阻塞,人们尝试过以下办法来解决:

将同一页面的资源分散到不同域名下,提升连接上限。 Chrome有个机制,对于同一个域名,默认允许同时建立 6 个 TCP持久连接,使用持久连接时,虽然能公用一个TCP管道,但是在一个管道中同一时刻只能处理一个请求,在当前的请求没有结束之前,其他的请求只能处于阻塞状态。另外如果在同一个域名下同时有10个请求发生,那么其中4个请求会进入排队等待状态,直至进行中的请求完成。

缺点:高延迟(队头阻塞)、巨大的HTTP头部,成千上万个请求响应报文里面很多重复的、明文传输不安全

SPDY协议:谷歌公司改造了HTTP1,压缩了header

HTTP2:2015年发布,基于SPDY,专注于性能,最大的目标是用户和网站之间只用一个连接,从目前的情况来看,国内外一些排名靠前的站点基本都实现了HTTP/2的部署,使用HTTP/2能带来20%~60%的效率提升

HTTP2新特性:二进制传输(把tcp协议部分特性挪到了应用层)、header压缩,开发了一个专门了HPACK算法,可以达到50-90%的高压缩率、多路复用(解决了浏览器同一个域名下的请求数量问题)

HTTP2总结:

同域名下所有通信都在单个连接上完成。

单个连接可以承载任意数量的双向数据流。

数据流以消息的形式发送,而消息又由一个或多个帧组成,多个帧之间可以乱序发送,因为根据帧首部的流标识可以重新组装。

这一特性,使性能有了极大提升:

同个域名只需要占用一个 TCP 连接,使用一个连接并行发送多个请求和响应,这样整个页面资源的下载过程只需要一次慢启动,同时也避免了多个TCP连接竞争带宽所带来的问题。

并行交错地发送多个请求/响应,请求/响应之间互不影响。

在HTTP/2中,每个请求都可以带一个31bit的优先值,0表示最高优先级, 数值越大优先级越低。有了这个优先值,客户端和服务器就可以在处理不同的流时采取不同的策略,以最优的方式发送流、消息和帧。

serverpush,一定程度上改变了传统的请求-应答模式,服务器不再完全是被动的响应请求,也可以主动新建流,在浏览器刚请求HTML的时候就提前把可能会用到的JS、CSS文件发给客户端,减少等待的延迟,这被称为"服务器推送"( Server Push,也叫 Cache push)另外需要补充的是,服务端可以主动推送,客户端也有权利选择是否接收。如果服务端推送的资源已经被浏览器缓存过,浏览器可以通过发送RST_STREAM帧来拒收。主动推送也遵守同源策略,换句话说,服务器不能随便将第三方资源推送给客户端,而必须是经过双方确认才行

出于兼容的考虑,HTTP/2延续了HTTP/1的“明文”特点,可以像以前一样使用明文传输数据,不强制使用加密通信,不过格式还是二进制,只是不需要解密。

但由于HTTPS已经是大势所趋,而且主流的浏览器Chrome、Firefox等都公开宣布只支持加密的HTTP/2,所以“事实上”的HTTP/2是加密的。 虽然 HTTP/2 解决了很多之前旧版本的问题,但是它还是存在一个巨大的问题,主要是底层支撑的 TCP 协议造成的。HTTP/2的缺点主要有以下几点:

TCP 以及 TCP+TLS建立连接的延时

HTTP/2都是使用TCP协议来传输的,而如果使用HTTPS的话,还需要使用TLS协议进行安全传输,而使用TLS也需要一个握手过程,这样就需要有两个握手延迟过程:

TCP的队头阻塞并没有彻底解决

上文我们提到在HTTP/2中,多个请求是跑在一个TCP管道中的。但当出现了丢包时,HTTP/2 的表现反倒不如 HTTP/1 了。因为TCP为了保证可靠传输,有个特别的“丢包重传”机制,丢失的包必须要等待重新传输确认,HTTP/2出现丢包时,整个 TCP 都要开始等待重传,那么就会阻塞该TCP连接中的所有请求(如下图)。而对于 HTTP/1.1 来说,可以开启多个 TCP 连接,出现这种情况反到只会影响其中一个连接,剩余的 TCP 连接还可以正常传输数据。

Google 在推SPDY的时候就已经意识到了这些问题,于是就另起炉灶搞了一个基于 UDP 协议的“QUIC”协议,让HTTP跑在QUIC上而不是TCP上。而这个“HTTP over QUIC”就是HTTP协议的下一个大版本,HTTP/3。它在HTTP/2的基础上又实现了质的飞跃,真正“完美”地解决了“队头阻塞”问题。

上面我们提到QUIC基于UDP,而UDP是“无连接”的,根本就不需要“握手”和“挥手”,所以就比TCP来得快。此外QUIC也实现了可靠传输,保证数据一定能够抵达目的地。它还引入了类似HTTP/2的“流”和“多路复用”,单个“流"是有序的,可能会因为丢包而阻塞,但其他“流”不会受到影响。具体来说QUIC协议有以下特点:

实现了类似TCP的流量控制、传输可靠性的功能。

虽然UDP不提供可靠性的传输,但QUIC在UDP的基础之上增加了一层来保证数据可靠性传输。它提供了数据包重传、拥塞控制以及其他一些TCP中存在的特性。

实现了快速握手功能。

由于QUIC是基于UDP的,所以QUIC可以实现使用0-RTT或者1-RTT来建立连接,这意味着QUIC可以用最快的速度来发送和接收数据,这样可以大大提升首次打开页面的速度。0RTT 建连可以说是 QUIC 相比 HTTP2 最大的性能优势。

集成了TLS加密功能。

目前QUIC使用的是TLS1.3,相较于早期版本TLS1.3有更多的优点,其中最重要的一点是减少了握手所花费的RTT个数。

多路复用,彻底解决TCP中队头阻塞的问题

和TCP不同,QUIC实现了在同一物理连接上可以有多个独立的逻辑数据流(如下图)。实现了数据流的单独传输,就解决了TCP中队头阻塞的问题。

  • HTTP/1.1有两个主要的缺点:安全不足和性能不高。
  • HTTP/2完全兼容HTTP/1,是“更安全的HTTP、更快的HTTPS",头部压缩、多路复用等技术可以充分利用带宽,降低延迟,从而大幅度提高上网体验;
  • QUIC 基于 UDP 实现,是 HTTP/3 中的底层支撑协议,该协议基于 UDP,又取了 TCP 中的精华,实现了即快又可靠的协议。

CSRF和XSS攻击和防御手段

名称方式防御手段
CSRF(跨站请求伪造)攻击者盗用用户身份,以用户名义发送而已请求验证HTTP Referer字段,在请求头中添加token并验证
XSS(跨站脚本攻击)攻击者在页面中嵌入恶意JS脚本,当用户浏览该页面的时候进行攻击对用户提交的数据进行验证,对输入内容进行过滤,将重要的cookie设置为http only
SQL注入通过SQL语句实现无账号登录甚至篡改数据库检查变量数据类型和格式,过滤特殊符号,绑定变量使用预编译语句(最佳)

cookie如何防范XSS攻击:

在http头部配上set-cookie,其中

httponly:该属性会禁止JS脚本使用document.cookie来访问cookie

secure:该属性告诉浏览器仅在请求为HTTPS的时候才发送cookie

CDN原理

CDN的全称是Content Delivery Network,即内容分发网络。CDN网络是在用户和服务器之间增加Cache层,主要是通过接管DNS实现,将用户的请求引导到Cache上获得源服务器的数据,从而降低网络的访问的速度。