计算机网络面试高频

计算机网络

网络体系结构

在向下传输的过程中要不断添加下层协议所需的首部和尾部,在向上层传输要不断拆开首部和尾部
路由器只有下面三层协议

五层协议
应用层:HTTP、DNS

为特定应用程序提供数据传输服务,数据单位为报文

DNS

DNS 是一个分布式数据库(每个站点只保留它自己的那部分数据),提供了主机名和 IP 地址相互转换的服务。

文件传送协议 FTP
动态主机配置协议 DHCP
远程登录协议 TELNET
电子邮件协议:SMTP、POP3、IMAP
传输层:TCP、UDP

为主机中的进程提供通用数据传输服务

  • TCP 面向连接,可靠传输,数据单位报文段,主要提供完整性服务
  • UDP 无连接,尽最大努力传输,数据单位用户数据报,主要提供及时性服务
TCP 三次握手

####### 流程

服务器处于 LISTEN 状态

  1. 客户端向服务器发送连请求报文
  2. 服务器收到后并同意连接后,向客户端发送连接确认报文
  3. 客户端收到连接确认报文后,还要再向服务器发出确认
  4. 服务器端收到客户的确认后,连接建立

####### 原因

  1. 防止失效的连接请求到达服务器,让服务器错误打开连接
  2. 客户端发送的连接请求如果再网络中滞留,就会隔很长时间才能收服务器发回来的连接确认,客户端等待超时重传的时间后,就会重新请求连接。如果不进行三次握手,服务器就会打开两个连接。
TCP 四次挥手

####### 流程

  1. 客户端发送连接释放报文
  2. 服务器收到后发出确认,此时 TCP 半关闭,服务器能向客户端发送数据,但是反过来不行
  3. 当服务器不再需要连接时,发送连接释放报文
  4. 客户端收到后进入 TIME-WAIT 状态,等待 2MSL 后释放连接
  5. 服务器收到客户端的确认后释放连接

####### 原因

  1. 为了让服务器发送还未传送完毕的数据,传送完毕后,服务器回发送 FIN 连接释放报文
  2. 客户端收到服务器端的 FIN 报文后 进入 TIME-WAIT 还要等待有两个原因
  • 确保最后一个确认报文能后到达,如果服务器没收到客户端发送来的确认报文,那么就会重新发送请求连接释放的报文,就是为了防止这种情况
  • 等待一段时间为了让本连接持续时间内所产生的所有报文都从网络中消失,使得下一个新的连接不会出现旧的连接请求报文
TCP 可靠传输

TCP 使用超时重传来实现可靠传输:如果一个已经发送的报文端在超时时间内没有收到确认,那么就重传这个报文段。

TCP 滑动窗口

窗口时缓存的一部分,用来暂时存放字节流。发送方和接收方各有一个自己的窗口,发送方根据接收方窗口的大小设置自己的窗口大小。
如果发送窗口左部得字节已经发送并得到确认,就将窗口向右滑动一定距离,直到左部第一个字节不是已发送并确认的状态
如果接收窗口左部字节已经发送确认并交付主机,就向右滑动接收窗口

TCP 流量控制

流量控制是为了控制发送方发送速率,保证接收方来得及接收

TCP 拥塞控制

如果网络出现拥塞,分组将会丢失,此时发送方会继续重传,从而导致网络拥塞程度更高,因此当出现拥塞时,应当控制发送方的速率。拥塞控制是为了降低整个网络的拥塞程度。
TCP 主要通过四个算法来进行拥塞控制:慢开始、拥塞避免、快重传、快恢复

网络层:IP

为主机提供数据传输服务,把传输层传输下来的报文段或者用户数据报封装成分组

数据链路层:

主机之间有很多链路,数据链路层就是为同一链路中的主机提供数据传输服务。把网络层传过来的分组封装成帧。

物理层:

考虑如何在传输媒体上传输数据比特流,由于传输媒体和通信手段的差异,物理层要尽量屏蔽使数据链路层察觉不到

OSI

五层协议中没有表示层和会话层,而是将这些问题留给开发者处理

  • 应用层
  • 表示层
  • 会话层
  • 传输层
  • 网络层
  • 数据链路层
  • 物理层
表示层

数据压缩、加密以及描述,使得各个主机无需担心内部数据格式不同

会话层

建立及管理会话

TCP/IP

相当于五层协议中数据链路层和物理层合并为网络接口层
TCP/IP 体系结构不严格遵循 OSI 分层概念,应用层可能会直接使用 IP 层或者网络接口层

  • 应用层
  • TCP/UDP
  • IP
  • 网络接口层

电路交换和分组交换

  • 电路交换用于电话通信系统,两个用户之间建立一条专用的物理链路,利用率低。
  • 每个分组都有首部和尾部,包含源地址和目标地址,在一条传输线路上互不影响。分组交换也使用了存储转发过程。

在一个邮局通信系统中,邮局收到一份邮件之后,先存储下来,然后把相同目的地的邮件一起转发到下一个目的地,这个过程就是存储转发过程,

HTTP

HTTP 方法
GET:获取资源
HEAD:获取报文首部

主要用于确定 URL 的有效性和资源更新日期时间等

POST:传输实体主体
PUT:上传文件/资源

由于自身不带验证机制,任何人都可以上传文件,所以不推荐使用该方法

PATCH:对资源进行部分修改

PUT 也可以用于修改资源,但只能完全替代原资源,PATCH 允许部分修改

DELETE:删除文件/资源

与 PUT 功能相反,并且同样不带验证机制

OPTIONS:查询允许方法

查询指定的 URL 允许的方法
会返回如下格式
Allow: GET, POST, HEAD, OPTIONS

CONNECT:要求与代理服务器通信时建立隧道

使用 SSL 和 TLS 把通信内容加密后经网络隧道传输

TRACE:追踪路径

服务器会将通信路径返回给客户端。

发送请求时,在 Max-Forwards 首部字段中填入数值,每经过一个服务器就会减 1,当数值为 0 时就停止传输。

通常不会使用 TRACE,并且它容易受到 XST 攻击(Cross-Site Tracing,跨站追踪)。

HTTP 状态码

服务器返回的响应报文第一行为响应码和原因短语,用来告知客户端反应的结果

1XX:信息性状态码

表明到目前为止都很正常,客户端可以继续发送请求或者忽略这个状态码

2XX:成功状态码
200:OK
204:No Content

请求已经成功处理,但是返回的响应报文不包含实体的主题部分。一般用于客户端不要求服务器返回消息时

206:Partial Content

表示客户端进行了范围请求,返回由响应报文中 Content-Range 指定的实体范围。

3XX:重定向状态码

虽然 HTTP 协议规定 301、302 状态下重定向时不允许把 POST 方法改成 GET 方法,但是大多数浏览器都会在 301、302 和 303 状态下的重定向把 POST 方法改成 GET 方法

301:Moved Permanently

永久性重定向

302:Found

临时性重定向

303:See Other

和 302 功能相同,但明确要求客户端使用 GET 方法获取资源

304:Not Modified

如果不满足请求报文首部的条件,如 if-match,则返回 304

307:Temporary Redirect

与 302 含义相同,但是要求浏览器不会把重定向的 POST 方法改成 GET 方法

4XX:客户端错误状态码
400:Bad Request

请求的报文中存在语法错误

401:UnAuthorized

该状态码说明发送的请求需要有认证信息

403:Forbidden

请求被拒绝

404:Not Found
5XX:服务器错误状态码
500:Internal Server Error

服务器正在执行请求时发生错误

503:Service Unavailable

服务器正超负载或者停机维护,无法处理请求

HTTP 首部
具体应用
连接管理
长连接和短连接

长连接建立一次 TCP 连接就能进行多次 HTTP 通信
HTTP 1.1 后默认长连接

流水线

在同一条长连接上连续发出请求,不等待响应返回,可以减少延迟

HTTP 无状态,所以引入 Cookie 来保存状态信息
Cookie 是服务器发送到浏览器并存储到本地得一小块数据,浏览器再次请求服务器时会带上 Cookie,告知服务器两个请求是否来自同一个浏览器
现代浏览器 API 已经允许开发者将数据直接存储到用户本地

用途
  • 会话状态管理(购物车,登录)
  • 个性化设置(用户自定义设置,主题)
  • 浏览器行为追踪(分析用户行为)
创建过程

服务器的响应首部包含 set-cookie 字段
之后浏览器把其中的内容放在请求首部中的 cookie 字段

分类

####### 会话期 Cookie

浏览器关闭后就会自动删除,也就是说只在会话期内有效

####### 持久性 Cookie

指定了 expires 或者 max-age 之后就是持久性 Cooki

作用域
JavaScript

浏览器可以通过 document.cookie 创建 Cookie

HttpOnly

标记为 HttpOnly 的 Cookie 不能被 JavaScript 脚本调用,可以防止通过 XSS(跨站脚本攻击获取用户Cookie)

Secure

标记为 Secure 的 Cookie 只能通过 Https 协议传输

此时无法使用 Cookie 来保存用户信息,只能使用 Session,且 SessionId 无法放入 Cookie 中,这是应该使用 URL 重写技术,将 SessionId 作为 URL 的参数进行传递。

Session

除了将用户信息通过 Cookie 存储在用户浏览器,也可以通过 Session 存储在服务器,存储在服务器端的信息更安全
Session 可以存储在服务器上的文件、数据库或者内存中,也可以将 Session 存储在 Redis 这种内存型数据库中,效率更高

维护用户登录状态
  1. 用户提交包含用户名和密码的表单,放入 HTTP 请求报文中
  2. 服务器验证用户名和密码,如果正确则把用户信息存储到 Redis 中,Redis 中的 key 称为 SessionId
  3. 服务器返回的响应信息中的 set-cookie 字段包含 SessionId,浏览器收到响应后将该 Cookie 值存入浏览器
  4. 浏览器再次发送请求时 Cookie 中包含了 SessionId,服务器查询 Redis 就可以继续该用户之前的业务操作
安全问题

为了不让恶意攻击者轻易获取 SessionId,应该将其设置为不容易猜到的值。在安全要求极高的操作场景中,如转账等操作,除了使用 Session 管理用户状态之外,还需要对用户进行重新验证,如再次输入密码,或者使用短信验证码等。

  • Cookie 只能存储 ASCII 码字符串,而 Session 可以存储任何类型的数据,因此考虑数据复杂性时首选 Session
  • Cookie 存储在浏览器中,容易被恶意查看,如果非要存储在 Cookie 中,可以加密,然后在服务器中进行解密
  • 对于大型网站,如果用户所有的信息都存储在 Session 中,开销时非常大的,因此不建议将所有的用户信息都存储到 Session 中
缓存
优点
  • 缓解服务器压力
  • 降低客户端获取资源的延迟:通常位于内存中,响应速度更快,并且缓存服务器在地理位置上离客户端也更近
实现方法
  • 代理服务器实现缓存
  • 客户端浏览器实现缓存
Cache-Control

HTTP 1.1 通过首部字段 Cache-Control 来控制缓存

####### no-store:禁止进行缓存

规定不能对请求或访问的任何一部分做缓存

####### no-cache:强制确认缓存

规定缓存服务器需要先向原服务器确认缓存的有效性,只有缓存有效时才能使用该缓存响应客户端的请求

####### private/public:私有缓存/公共缓存

  • 私用缓存只能被单个用户使用,一般存储在用户浏览器中
  • 公共缓存可以被多个用户使用,一般存储在代理服务器中

####### max-age/expires:缓存过期机制

max-age 出现在请求报文中,并且资源的缓存时间小于该值就能接收缓存
max-age 出现在响应报文中,表示资源的在服务器中的保存时间
expires 首部字段也可以告知缓存服务器该资源什么时候会过期

通信数据转发
代理

代理服务器接收客户端的请求,并且转发给其他服务器

####### 主要目的

  • 缓存
  • 负载均衡
  • 网络访问控制
  • 访问日志记录

####### 正向代理/反向代理

  • 用户察觉得到正向代理的存在
  • 而反向代理一般位于内部网络之中,用户察觉不到
网关

与代理服务器不同的是,网关服务器会将 HTTP 转化为其他协议进行通信,从而请求其他非 HTTP 服务器的服务

隧道

使用 SSL 加密等手段,在客户端与服务器之间建立一条安全的通信线路

HTTP 1.1 新特性
  • 默认长连接
  • 支持流水线
  • 支持同时打开多个 TCP 连接
  • 支持虚拟主机
  • 新增状态码100
  • 新增缓存处理指令 max-age
HTTP 2.0
  • 客户端需要使用多个连接才能实现并发和缩短延迟;
  • 不会压缩请求和响应首部,从而导致不必要的网络流量;
  • 不支持有效的资源优先级,致使底层 TCP 连接的利用率低下
GET 和 POST 比较
作用

GET 用于获取资源
POST 用于传输实体

参数

GET 和 POST 都能使用额外的参数
GET 的参数是以查询字符串出现在 URL 中
POST 的参数存储在实体主体中
不能认为 POST 安全性更高,POST 参数也可以通过抓包查看

安全

安全的 HTTP 方法不会改变服务器状态
安全的方法:GET,HEAD,OPTIONS
不安全的方法:POST,PUT,DELETE
POST 方法传输的实体可能是个表单,会被存储到服务器中,这就改变了服务器的状态,所以说 POST 不是安全的方法。

幂等性

幂等的 HTTP 方法,请求一次与连续请求多次的效果是一样的,服务器的状态也是一样的。
正确实现的条件下,GET、HEAD、PUT 和 DELETE 都是幂等的,POST 不是。

可缓存
XMLHttpRequest

XMLHttpRequest 是一个 API,它为客户端提供了在客户端和服务器之间传输数据的功能。它提供了一个通过 URL 来获取数据的简单方式,并且不会使整个页面刷新。这使得网页只更新一部分页面而不会打扰到用户。XMLHttpRequest 在 AJAX 中被大量使用。

  • XMLHttpRequest 的 POST 浏览器先发送 Header 在发送 Data
  • GET 方法浏览器 Header 和 Data 一起发送

HTTPS

HTTP 有三点安全性问题

  • 使用明文通信,内容可能被窃听
  • 不验证通信方的身份,通信方可能是伪装的
  • 无法证明报文的完整性,报文可能被篡改
    HTTPS 不是新协议,本质是 HTTP 先与 SSL 进行通信,SSL 再与 TCP 进行通信,也就是说 HTTPS 使用了隧道进行通信。
    HTTPS 具有 加密(防窃听)、认证(防伪装)、完整性保护(防篡改)
加密
对称密钥加密

加密和解密使用同一密钥

  • 运算速度快
  • 无法安全的将密钥传输给通信方
非对称密钥加密

加密和解密使用不同的密钥,公钥所有人都可以获得,私钥自己留着。
通信发送方先获得接收方的公钥,使用公钥进行加密,接收方收到后使用私钥进行解密。
非对称密钥还可以用来签名,通信发送方使用其私钥进行加密,接收方收到后使用对方的公钥解密即可验签。

  • 可以更安全的将密钥传输给通信发送方
  • 运算速度慢
HTTPS 加密方式

HTTPS 混用了对称密钥加密和非对称密钥加密。
HTTPS 先使用非对称密钥加密的方式传输密钥,之后再用该密钥和对称密钥加密方式进行通信传输,同时保证了安全性和运算速度。

认证

通过使用证书对通信方进行认证
数字证书机构(CA)是双方都可信的,服务器运营人员会向 CA 申请公开密钥的申请,CA 判明申请者身份后,会对已申请的公开密钥做签名,并将公开密钥放入密钥证书并绑定在一起。
进行 HTTPS 通信时,服务器会把证书发送给客户端,客户端取得其中的公钥后先进性验签,验证通过后就可以进行通信了。

完整性保护

SSL 提供报文摘要功能来进行完整性保护

WEB 页面请求过程

DHCP 配置主机信息

假设主机最开始没有 IP 地址和其他信息,就需要先使用 DHCP 来获取

ARP 解析 MAC 地址

主机通过浏览器生成一个 TCP 套接字,套接字向 HTTP 服务器发送 HTTP 请求,为了生成套接字主机需要知道网站域名对应的 IP 地址
所以生成一个 DNS cha’xun’bao’wen

DNS 解析域名
HTTP 请求页面

有了 HTTP 服务器的 IP 地址之后,主机就能够生成 TCP 套接字,生成套接字之前需要三次握手建立连接,连接建立后浏览器生成报文并发送请求。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值