计算机网络

1.什么是HTTP? HTTP 和 HTTPS 的区别?

HTTP为一种浏览器web端和服务器server端之间传输内容的传输协议，以明文方式发送内容，不对传输内容进行加密。

HTTPS就是为了解决上述的安全性问题出现的，为了能够加密传输，让HTTP协议运行在SSL/TLS协议上，通过SSL证书来验证服务器的身份，实现浏览器和服务器之间的传输加密。

区别：

• HTTPS是HTTP协议的安全版本，HTTP协议的数据传输是明文的，是不安全的，HTTPS使用了SSL/TLS协议进行了加密处理，相对更安全
• HTTP 和 HTTPS 使用连接方式不同，默认端口也不一样，HTTP是80，HTTPS是443
• HTTPS 由于需要设计加密以及多次握手，性能方面不如 HTTP
• HTTPS需要SSL，SSL 证书需要钱，功能越强大的证书费用越高

2.为什么说HTTPS比HTTP安全? HTTPS是如何保证安全的？

HTTPS通过SSL/TSL协议对通信的过程进行加密处理，具体的操作有：

• 信息加密
• 完整性校验
• 身份验证

信息加密即采用对称加密和非对称加密的混合加密方式，通过非对称加密的公钥对对称加密的密钥进行加密，再通过非对称加密的私钥对对称加密的密钥解密。

即两层结构。

实现完整性检验用的是摘要算法，也就是常说的散列函数、哈希函数。

对任意的数据进行'压缩'成固定长度的一串字符串，该字符串是独一无二的，像身份证一样。

这样在传输数据时，在传输明文的基础上再加上摘要，通过信息加密后传给对方，对方拿到数据进行摘要的对比，若一致则说明数据是完整的。

实现身份验证是通过数字签名来实现的，在传输摘要的时候加一个签名，该签名采用的是私钥加密，公钥解密。

且中间要加一个CA验证机构以确保服务端在收到消息时，对方使用的公钥是自己的那个公开密钥，过程就是服务器向中间CA机构发送申请，把公开密钥给他们，CA机构根据这个公钥做一个数字签名，然后以证书方式公布这个有数字签名公钥；

接到这个证书的客户端、浏览器会验证该数字签名的真实性，通过验证后说明该公开密钥是可信的。这样有人想做一个假的公钥没有数字签名是不行的。

3.UDP 和 TCP?

UDP(用户数据包协议)，

是面向报文的无连接数据通信协议；

只保证尽可能地传递数据，不保证对方有没有收到，可靠性很差，但是传输效率高；

支持一对一、一对多、多对一、多对多通信；

TCP(传输控制协议)，是面向字节流的有连接通信协议，建立连接时需要三次握手，断开连接时需要四次握手；

提供可靠地服务，传输过程采用流量控制、编号与确认、计时器等手段确保数据无差错、不丢失，但传输效率低；

点对点的全双工通信；

应用场景:

4.OSI七层模型？TCP/IP?

OSI为计算机网络标准模型主要分为七层，每一层实现各自的功能和协议，并完成与相邻层的接口通信。

应用层：

提供各种应用程序的协议标准，如支持域名系统的DNS协议，支持万维网应用的HTTP协议，支持电子邮件系统的SMTP协议。

应用程序之间的交互数据单元为报文

表示层：

对数据进行解释、压缩、解压、加密和解密等格式转化操作。

会话层：

负责建立、管理和维护不同机器上的用户之间的会话。

传输层：

为会话层的机器提供透明、可靠的数据传输服务，保证端到端数据传输的完整性。

主要的传输层协议为TCP和UDP

TCP/IP指能在多个网络间实现信息传输的协议族，其四层结构如下：

应用层：

包括OSI模型的上三层，负责实现所有和应用程序相关的功能，

其中有FTP（文件传输协议）、HTTP（超文本传输协议）、DNS（域名服务器协议）、SMTP（简单邮件传输协议）、NFS（网络文件系统协议）

传输层： 单位：报文段

对应OSI模型的第四层传输层，负责提供可靠的传输服务，

其中有TCP（控制传输协议）、UDP（用户数据报协议）

网络层： 单位：数据报

对应OSI模型的第三层网络层，负责网络间的寻址数据传输，

其中包括IP（网际协议）、ICMP（网际控制消息协议）、ARP（地址解析协议）、RARP（反向地址解析协议）

网络接口层： 单位:帧

对应OSI模型的最下面两层，负责实际数据的传输，

其中包括HDLC（高级链路控制协议）、PPP（点对点协议）、SLIP（串行线路接口协议）

5.DNS协议？

DNS（Domain Names System），域名系统，是互联网的一个服务，用来将域名与之对应的IP地址进行转换的服务器。

也就是将域名翻译为IP地址。www.xxx.com ==>xxx.xxx.x.x

域名是一个有层次的结构：

www.baidu.com依次为三级域名www、二级域名baidu、顶级域名com、根域名.（一般省略不写

每一层域名都有对应的域名服务器

除了这三种服务器还有电脑默认的本地域名服务器

• DNS查询方式：

  • 递归查询：一直问到底
  • 迭代查询：挨个去问，从根域名服务器获取信息依次到下层去问，一直到权限域名服务器

• 域名缓存方式（保存域名和IP地址的映射）：

  • 浏览器缓存：浏览器在获取网站域名的实际ip地址后会对其缓存，以减少网络请求的损耗
  • 操作系统缓存：用户自己配置的hosts文件

DNS查询过程（解析域名过程）：

• 首先在浏览器缓存中查找DNS缓存，缓存中维护着一个域名与ip地址对应的表格。

• 若没有找到，则继续搜索操作系统缓存的DNS缓存。

• 若还没找到，则操作系统将域名发送到本地域名服务器，本地域名服务器采用递归查询的方式查询自己的DNS缓存，

• 若本地域名服务器的DNS缓存中没有，则本地域名服务器继续向上级域名服务器中迭代查询：

  • 首先本地域名服务器向根域名服务器发起请求，获取顶级域名服务器的地址
  • 本地域名服务器向顶级域名服务器发起请求，获取权限域名服务器的地址
  • 本地域名服务器向权限域名服务器的地址发起请求，获取最后的IP地址

• 本地域名服务器将获取的IP地址返回给操作系统，操作系统将此映射缓存下来

• 操作系统将IP地址返回给浏览器，浏览器将此映射缓存下来

• 至此，浏览器得到了域名对应的IP地址，并将之缓存下来

6.CDN?原理？

CDN (全称 Content Delivery Network)，即内容分发网络

构建在现有网络基础上的智能虚拟网络，依靠部署在本地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能，使用户就近获取数据，降低网络阻塞，提高用户访问响应速度和命中率。

CDN的关键技术包括内容存储和分发技术。

简单来说，CDN技术就是根据用户位置就近分配资源。用户在访问资源时，不是直接访问源站，而是访问离他最近的一个CDN节点，也就是边缘节点，该边缘节点就是缓存了源站对应数据内容的代理服务器。

原理分析:

没有应用CDN时，使用域名访问一个站点时通过DNS返回的是IP地址，应用CDN后，返回一个CNAME别名记录中间人，指向CDN的全局负载均衡。

• 当用户点击了url或者输入了网址访问域名时，经过本地DNS服务器解析，DNS服务器会将域名的解析权交给CNAME指向的CDN专用DNS服务器。

• CDN专业DNS服务器将CDN的全局负载均衡设备IP地址返回用户。

• 用户根据此全局负载均衡设备IP地址向CDN服务器再次发送请求，进入该服务器后

  • 看用户的IP地址，查表得到地理位置，找最近的边缘节点
  • 看用户所在的运营商网络，找相同网络的边缘节点
  • 检查边缘节点负载情况，找负载最轻的节点
  • 根据节点服务能力、带宽、响应时间等因素找到最合适的节点

• 把找到的最合适的节点返回给用户，用户就能访问CDN的缓存代理。

缓存代理：CDN服务器有选择缓存一些常用的资源，通过命中率和回源率评估CDN服务质量。

7.HTTP1.0/1.1/2.0 的区别?

HTTP1.0：

• 浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接

HTTP1.1：

• 引入了持久连接，即TCP连接默认不关闭，可以被多个请求复用
• 在同一个TCP连接里面，客户端可以同时发送多个请求
• 虽然允许复用TCP连接，但是同一个TCP连接里面，所有的数据通信是按次序进行的，服务器只有处理完一个请求，才会接着处理下一个请求。如果前面的处理特别慢，后面就会有许多请求排队等着
• 新增了一些请求方法
• 新增了一些请求头和响应头

HTTP2.0：

• 采用二进制格式而非文本格式，解析更高效
• 完全多路复用，而非有序并阻塞的、只需一个连接即可实现并行
• 使用报头压缩，降低开销
• 服务器推送

8.HTTP常见的状态码？适用场景？

http状态码的作用是服务器告诉客户端当前请求响应的状态，通过状态码就能判断和分析服务器的运行状态。

状态码一般有三位。

状态码第一位数字决定了不同的响应状态，有如下：

• 1 表示消息
• 2 表示成功
• 3 表示重定向
• 4 表示请求错误
• 5 表示服务器错误

下面给出一些状态码的适用场景：

• 100：客户端在发送POST数据给服务器前，征询服务器情况，看服务器是否处理POST的数据，如果不处理，客户端则不上传POST数据，如果处理，则POST上传数据。常用于POST大数据传输
• 206：一般用来做断点续传，或者是视频文件等大文件的加载
• 301：永久重定向会缓存。新域名替换旧域名，旧的域名不再使用时，用户访问旧域名时用301就重定向到新的域名
• 302：临时重定向不会缓存，常用 于未登陆的用户访问用户中心重定向到登录页面
• 304：协商缓存，告诉客户端有缓存，直接使用缓存中的数据，返回页面的只有头部信息，是没有内容部分
• 400：参数有误，请求无法被服务器识别
• 403：告诉客户端进制访问该站点或者资源，如在外网环境下，然后访问只有内网IP才能访问的时候则返回
• 404：服务器找不到资源时，或者服务器拒绝请求又不想说明理由时
• 503：服务器停机维护时，主动用503响应请求或 nginx 设置限速，超过限速，会返回503
• 504：网关超时

9.get和post请求的区别？

两者都是http协议中两种发送请求的方法，而http是基于TCP/IP的数据在网络中通信的协议标准。

• get是从服务器上获取数据，post是从服务器传送数据。
• get提交的数据会放在URL之后，以？分割URL和传输数据，数据的参数之间用&分割；post方法是把要传送的数据放在HTTP包的body里。
• get提交的数据会有大小限制，一般在2k字节以内，而post没有限制，但一般也不会超过80 100kb.
• get提交数据时，存在的安全隐患较大，用户数据会显示在URL上
• get是通过地址栏来取值，post是通过提交表单来传值。
• get智能进行url编码，而post支持多种编码方式。
• get请求会被浏览器主动cache，而post不会，需要手动设置
• 对于参数的数据类型，get只接受ASCII字符，而POST没有限制

10.讲讲输入完网址按下回车，到看到网页这个过程中发生了什么

0. 域名解析（DNS查询
1. 发起TCP的三次握手
2. 建立TCP连接后发起http请求
3. 服务器端响应http请求
4. 浏览器接收到请求的资源，解析资源。
5. 对页面进行渲染

• URL解析

• DNS 查询---获取域名对应的目标服务器IP地址

• 建立TCP 连接---发起TCP的三次握手来建立TCP连接

• 发起HTTP 请求---请求的内容包括：请求行、请求头、请求主体

• 响应请求---处理完请求后返回一个http响应消息，包括：状态行、响应头、响应正文

• 页面渲染---浏览器拿到资源后，会对资源进行解析：

  • 查看响应头的信息，根据不同的指示做对应处理，比如重定向，存储cookie，解压gzip，缓存资源等等
  • 查看响应头的 Content-Type的值，根据不同的资源类型采用不同的解析方式

关于页面的渲染过程如下：

• 解析HTML，构建 DOM

  • 解析 CSS ，生成 CSSOM

• 合并 DOM 树和 CSS 规则，生成render (渲染）树

• 布局 render 树（ Layout / reflow ），负责各元素尺寸、位置的计算

• 绘制 render 树（ paint ），绘制页面像素信息

• 浏览器会将各层的信息发送给 GPU，GPU 会将各层合成（ composite ），显示在屏幕上

• 注意：js代码会阻塞解析的进程

11.TCP为什么需要三次握手和四次挥手？

建立一个TCP连接，需要客户端和服务器共发送三个包，以确保双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。

解释：seq-序列号，ack-确认号，ACK-确认标志，SYN-同步标志，FIN-结束标志

过程：

第一次握手： 客户端给服务端发一个SYN报文，并指明一个初始化序列号seq，此时客户端为SYN_SENT状态。

第二次握手：服务端收到SYN报文后，以自己的SYN报文作为应答，将客户端传来的序列号加一作为ack确认号的值，同时也传一个序列号y，此时服务端为SYN_RCVD状态。

第三次握手：同理客户端收到报文后，将服务端传来的序列号y加一作为ack的值，自身序列号x也加一，此时客户端处于ESTABLISHED状态，服务端收到报文后，也处于ESTABLISHED状态，此时，双方建立了连接。

为什么不是两次握手呢？

如果没有第三次握手，接收方就不知道自己发的包对方能不能收到。

而且两次握手的话，客户端有可能因为网络阻塞等原因会发送多个请求报文，延时到达时又和服务端建立了连接，浪费了服务端的资源。（为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误）

tcp终止一个连接，需要经过四次挥手。

过程如下：

第一次挥手：客户端发送一个FIN报文，报文同时指定一个序列号u。此时客户端处于FIN_WAIT1状态，停止发送数据，等待服务端的确认。

第二次挥手：服务端收到FIN报文，会发送ACK报文，且把客户端的序列号u加一作为ACK报文的序列号值，表明已经收到客户端的报文了，此时服务端处于CLOSE_WAIT状态

第三次挥手：如果服务端也想断开连接了，也像第一次挥手一样发送FIN报文，且指定一个序列号w，此时服务端处于LAST_ACK状态。

第四次挥手：客户端收到FIN报文后，一样发送一个ACK报文作为应答，w+1作为其序列号值，此时客户端处于TIME_WAIT状态。需要过一会以确保服务端收到了自己的ACK报文之后才会进入CLOSED状态，而服务端收到ACK报文后，就进入CLOSED状态。

为什么要四次挥手？

服务端收到客户端断开连接FIN报文后，并不会立即关闭连接，而是发送一个ACK包先告诉客户端收到关闭连接的请求了，只有当服务端的所有报文发送完毕后，才发送FIN报文断开连接，这样就多了一次挥手。

服务端收到FIN报文仅仅表示客户端不再发送数据了，但是还能接受数据，也可能后续还会给客户端发送数据，因此确认收到FIN请求ACK和实际关闭FIN会分开发送，这样就多了一次。

12.WebSocket？应用场景？

WebSocket为一种网络传输协议，位于OSI模型的应用层，可以在单个TCP连接上进行全双工通信，能更好的节省服务器资源和带宽并达到实时通信。

客户端和服务器只需要完成一次握手，两者之间就可以创建持久性的连接，并进行双向数据传输。

没有他之前都是通过不断地发送http请求问对方有没有数据，近似实现实时通信，这样会消耗大量带宽和CPU资源。

优点

• 使客户端和服务器之间的数据交换更加简单，允许服务端主动向客户端发送数据。
• 只需要完成一次握手，两者之间就可以创建持久性的连接，并进行双向数据传输。
• 没有同源限制，客户端可以和任意服务器通信
• 可以发送文本，也可以发送二进制数据
• 数据格式比较轻量化，性能开销小，通信高效
• 建立在TCP协议的基础上，和http协议具有较好的兼容性，都同属于应用层

应用场景

基于websocket的事实通信的特点，其存在的应用场景大概有：

• 弹幕
• 媒体聊天
• 协同编辑
• 基于位置的应用
• 体育实况更新
• 股票基金报价实时更新

\