interview-网络

再来100个需求
402 阅读21分钟

网络 tcp http https

网络七层结构

  • 物理层，数据名称：比特。这层基于物理设备，定义物理设备标准(网线的接口类型、光纤的接口类型)
  • 数据链路层，数据名称：帧。定义了如何让数据格式化的传输。
  • 网络层，数据名称：数据报。IP地址。
  • 传输层，数据名称：报文段/用户数据报。TCP/UDP
  • 会话层：SSL、TLS 数据加密协议
  • 表示层：进行设备数据格式与网络标准格式之间的转化
  • 应用层，数据名称：报文。HTTP

TCP & UDP

TCP

传输控制协议（TCP，Transmission Control Protocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议

  • 特征
  1. 数据被编码成字节流写入TCP通道。
  2. TCP不保证字节流到达目的地，但能保证到达的字节流是正确、有序的
  3. TCP通道像一个无形管道，管道流量由网络环境决定，但是TCP协议能自动调节(即拥塞控制)。
  4. TCP是全双工协议，读写互不干扰。全双工指可以同时（瞬时）进行信号的双向传输（A→B且B→A）。
三次握手：连接过程

TCP 三次握手就好比两个人在街上隔着50米看见了对方，但是因为雾霾等原因不能100%确认，所以要通过招手的方式相互确定对方是否认识自己。

  1. 张三(客户端)首先向李四(服务端)招手(syn)，李四看到张三向自己招手后，向对方点了点头挤出了一个微笑(ack)。张三看到李四微笑后确认了李四成功辨认出了自己(进入estalished状态)。
  2. 李四还有点狐疑，向四周看了一看，有没有可能张三是在看别人呢，他也需要确认一下。所以李四也向张三招了招手(syn)，张三看到李四向自己招手后知道对方是在寻求自己的确认，于是也点了点头挤出了微笑(ack)，李四看到对方的微笑后确认了张三就是在向自己打招呼(进入established状态)。
  3. 之后就可以正常通讯，传输数据了。

四次挥手：断开过程

TCP断开链接的过程和建立链接的过程比较类似，只不过中间的两部并不总是会合成一步走，所以它分成了4个动作，张三(客户端)挥手(fin)——李四(服务端)伤感地微笑(ack)——李四挥手(fin)——张三伤感地微笑(ack)。 注意有一个wait(计时等待)的过程。

为什么是三次握手四次挥手？

当Server端收到Client端的SYN请求后，可以直接发送ACK+SYN报文。其中ACK用来应答，SYN用来同步。但是关闭连接时，Server端收到Client端的FIN请求后，很可能还有其他报文没有发送完，并不会立即关闭SOCKET，所以先发个ACK报文告诉Client端:"FIN请求我收到了"。等Server端所有的报文都发送完了，才发送FIN报文给Client端。故需要四步

为什么需要TIME_WAIT？

四个报文都发送完毕，讲道理应该直接进入CLOSE状态，但是如果网络不好，最后一个ACK报文丢失了，那么就需要重发。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文(最后一个)。

TCP保证数据可靠做了哪些操作
  • 将数据截断为合理的长度： 应用数据被分割成TCP认为最适合发送的数据块
  • 超时重传机制： 当TCP发出一个段后，它启动一个定时器开始计时，等待目的端确认收到这个报文段。如果不能及时收到目的端发出的确认，将重发这个报文段。
  • 流量控制： TCP可以通过可变大小的滑动窗口机制提供流量控制。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这将防止较快主机致使较慢主机的缓冲区溢出
  • 校验和： TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到端的检验和有差错，TCP将丢弃这个报文并不确认收到此报文段
  • 拥塞控制：当出现拥塞时，TCP协议会控制发送方的速率。
  • 对失序数据进行重新排序并丢弃重复数据：当IP数据报失序或者重复时，TCP的接收端会进行检查排序、丢弃重复数据后再交给应用层

UDP

UDP协议全称是用户数据报协议，在网络中它与TCP协议一样用于处理数据包，是一种无连接的协议。UDP有不提供数据包分组、组装和不能对数据包进行排序的缺点，也就是说，当报文发送之后，是无法得知其是否安全完整到达的。

  • 特征
  1. 面向无连接：不需要像TCP那样先建立连接。想发数据就可以开始发送。并且不会对数据报进行拆分和拼接操作，只是数据报的搬运工
  2. 单播，多播，广播的功能：UDP支持一对一，一对多，多对一
  3. UDP是面向报文的：发送方的UDP所在应用向下ip层交付时，不会对报文操作，只保留报文边界，所以报文大小需要应用程序自己控制。
  4. 不可靠性：因为无连接保障，数据不一定到达；且UDP没有拥塞控制，一直以恒定速率发送数据包，在网络拥塞的时候，还是会发送，容易导致丢包
  5. 头部开销小：UDP的头部开销小，传输数据报文时很高效。

TCP和UDP区别

  1. 对比
  2. 总结
  • TCP向上层提供面向连接的可靠服务，UDP向上层提供无连接不可靠服务。
  • 虽然 UDP 并没有TCP传输来的准确，但是也能在很多实时性要求高的地方有所作为
  • 对数据准确性要求高，速度可以相对较慢的，可以选用TCP

Socket

Socket 本质是编程接口(API)，对 TCP/IP 的封装，TCP/IP 也要提供可供程序员做网络开发所用的接口，这就是 Socket 编程接口；TCP/IP也要提供可供程序员做网络开发所用的接口，这就是 Socket 编程接口。HTTP是轿车，提供了封装或者显示数据的具体形式；Socket 是发动机，提供了网络通信的能力。

http

  • 介绍
  1. HTTP(Hypertext Transfer Protocol)超文本传输协议
  2. 是一个基于TCP/IP通信协议之上来传输数据协议；
  3. 该协议用于规定客户端和服务端之前的传输规则，传输的内容不局限于文本(传输任意类型的数据)
  • 一次HTTP事务过程步骤
  1. 客户端与服务器建立连接
  2. 连接成功后，客户端给服务器发送数据请求
  3. 服务器收到数据请求消息后，根据请求的内容，回发数据给客户端
  4. 客户端收到消息，进行展示或者处理
  • http缺点
  1. 通信使用明文，可能被窃听
  2. 不验证通信方的身份，可能遭遇伪装
  3. 无法证明报文的完整性，有可能遭遇篡改

http请求和响应全过程

  1. 域名解析：这一步就是通过域名找到对应的IP地址
  2. 客户端与服务器建立TCP/UDP连接
  3. 客户端发送http请求给服务器
  4. 服务器给客户端响应
  5. 释放链接：根据协议类型选择是否释放链接(1.0:非持久，1.1持久)
  6. 客户端解析响应数据：eg：json 解析

http中get和post区别

前期回答

  1. get在浏览器回退时是无害的，而post还会再次请求
  2. get产生的URL地址可以被BookMark(书签收藏)，而post不可以
  3. get请求会被浏览器主动cache，而post不会，除非手动设置
  4. get请求的参数会被浏览器保存在历史记录里，而post中的参数不会被保留
  5. get参数是通过URL传递的，所以请求参数长度是有限的；post参数放在Request body中，没有长度限制。
  6. 对参数的数据类型，get只接受ASCII字符，而post没有限制
  7. get比post更不安全，因为参数直接暴露在url上，所以不能传递敏感数据
  8. get只能进行url编码，而post支持多种编码方式
1.application/x-www-form-urlencoded
2.multipart/form-data
3.application/json
4.text/xml

后期回答

GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同

  1. GET和POST本质上没有区别：都只是HTTP协议中的两种发送请求的方法
  2. HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP
  3. 在万维网世界中，TCP就像汽车，我们用TCP来运输数据。为了防止车子都是一样的，HTTP给车子加了类型标签(GET, POST, PUT, DELETE...)
  4. GET就是把货物放到车顶的TCP，POST就是把货物放到车厢的TCP

GET产生一个TCP数据包；POST产生两个TCP数据包。

长的说：对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）； 而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。

也就是说，GET只需要汽车跑一趟就把货送到了，而POST得跑两趟，第一趟，先去和服务器打个招呼“嗨，我等下要送一批货来，你们打开门迎接我”，然后再回头把货送过去。

GET和POST最大的区别主要是GET请求是幂等性的，POST请求不是。 幂等性是指一次和多次请求某一个资源应该具有同样的副作用。简单来说意味着对同一URL的多个请求应该返回同样的结果。

https

https = http + TLS/SSL，即HTTP协议的安全版。HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的。

  • HTTPS主要作用
  1. 对数据进行加密，并建立一个信息安全通道，来保证传输过程中的数据安全。
  2. 对网站服务器进行真实身份认证(CA认证)

TLS/SSL

  • 简介 TLS/SSL全称安全传输层协议Transport Layer Security, 是介于TCP和HTTP之间的一层安全协议，不影响原有的TCP协议和HTTP协议，所以使用HTTPS基本上不需要对HTTP页面进行太多的改造。

  • 原理 之所以能保证安全，是因为TLS/SSL基于三类算法：散列函数 Hash、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性。

三种加密算法

  • 散列函数Hash

常见的有MD5、SHA1、SHA256。特点：不可逆、对输入敏感、输出长度固定。针对数据的任何修改都会改变散列函数的结果，用于防止信息篡改并验证数据的完整性;在信息传输过程中，散列函数不能单独实现信息防篡改，因为明文传输，中间人可以修改信息之后重新计算信息摘要，因此需要对传输的信息以及信息摘要进行加密;

  • 对称加密

常见的有AES-CBC、DES、3DES、AES-GCM等，相同的密钥可以用于信息的加密和解密，掌握密钥才能获取信息，能够防止信息窃听，通信方式是1对1;对称加密的优势是信息传输1对1，需要共享相同的密码，密码的安全是保证信息安全的基础，服务器和N个客户端通信，需要维持 N 个密码记录，且缺少修改密码的机制;

  • 非对称加密

即常见的 RSA 算法，特点：密钥成对出现，一般称为公钥(公开)和私钥(保密)，公钥加密的信息只能私钥解开，私钥加密的信息只能公钥解开。因此掌握公钥的不同客户端之间不能互相解密信息，只能和掌握私钥的服务器进行加密通信，服务器可以实现1对多的通信，客户端也可以用来验证掌握私钥的服务器身份。非对称加密的特点是信息传输1对多，服务器只需要维持一个私钥就能够和多个客户端进行加密通信，但服务器发出的信息能够被所有的客户端解密，且该算法的计算复杂，加密速度慢。

HTTP2.0

  • 有关基本概念
  1. 帧：HTTP2.0通信的最小单位，所有帧都共享一个8字节的首部，帧承载着特定类型的数据，如HTTP首部、负荷、等等。
  2. 消息：比帧大的通讯单位，是指逻辑上的HTTP消息，比如请求、响应等。
  3. 流：比消息大的通讯单位。是TCP连接中的一个虚拟通道，可以承载双向的消息。每个流都有一个唯一的整数标识符
  • HTTP2.0的特点
  1. 二进制传输：传输的数据都会被分割，并采用二进制格式编码。。为了兼容HTTP，2.0在HTTP和TLS之间增加了一层二进制分帧层。在二进制分帧层上，HTTP2.0会将所有传输的信息分为更小的消息和帧，并采用二进制格式编码，其中HTTP1.x的首部信息会被封装到Headers帧，而Request Body则封装到Data帧。
  2. 首部压缩：2.0使用HPACK（HTTP2头部压缩算法）压缩格式对传输的header进行编码，减少了header的大小。并在两端建立索引表，记录出现过的header，后面的传输可以通过header键值名，对端收到数据后就可以通过键名找到对应的值。
  3. 多路复用：基于二进制分帧层，HTTP2.0可以在共享TCP连接的基础上同时发送请求和响应。HTTP消息被分解为独立的帧，交错发出去，在另一端组装。通过这个技术可以避免HTTP旧版本的队头阻塞问题，极大提高传输性能。
  4. 请求优先级：基于二进制分帧层，HTTP消息分成多个独立帧，其可以通过优化这些帧交错和传输顺序进一步优化性能。
  5. 服务器推送：服务器可以对一个客户端请求发送多个响应，即推送。

SSE

SSE(Sever-sent Events) 是WebSocket的轻量代替方案,使用HTTP协议。服务器单向的向客户端发送流信息。

原理：严格地说，HTTP 协议是没有办法做服务器推送的，但是当服务器向客户端声明接下来要发送流信息时，客户端就会保持连接打开，SSE 使用的就是这种原理。

SSE 能做什么？

理论上， SSE 和 WebSocket 做的是同一件事情。当你需要用新数据局部更新网络应用时，SSE 可以做到不需要用户执行任何操作，便可以完成。

SSE与WebSocket的区别

  • WebSocket是全双工通道，可以双向通信，功能更强；SSE是单向通道，只能服务器向浏览器端发送。如果客户端需要向服务器发送消息，则需要一个新的 HTTP 请求。 这对比 WebSocket 的双工通道来说，会有更大的开销。
  • WebSocket是一个新的协议，需要服务器端支持；SSE则是部署在 HTTP协议之上的，现有的服务器软件都支持。
  • SSE是一个轻量级协议，相对简单；WebSocket是一种较重的协议，相对复杂。
  • SSE默认支持断线重连，WebSocket则需要额外部署。
  • SSE支持自定义发送的数据类型。
  • SSE不支持CORS(跨域)，参数url就是服务器网址，必须与当前网页的网址在同一个网域（domain），而且协议和端口都必须相同。WebSocket支持

ping 原理

  1. 由于互联网之间通讯会涉及很多网关和主机，为了能报告错误、更加高效的转发IP数据、提高交付成功机率--所以产生了：ICMP协议
  2. ICMP协议的header包含4个字节，用来说明和校验ICMP报文。
  3. 当发起ping 192.168.2.179请求时，第一次会先根据ARP协议(根据IP地址查找出对应ip地址的MAC地址)获取MAC地址.之后ping操作会缓存ARP
  4. 而发起ping reqeust到收到消息这部分是耗时的，根据时间戳就能算出耗时，在返回的ICMP消息详情内部就显示 。

抓包原原理

  1. 基本原理：即监控App与服务器交互之间的网络节点,即监控在数据经过的节点(网卡)中对数据进行解析
  2. 手机和本地路由之间加一个代理服务器，所有的数据都会经过这个代理服务器。

http签名

eg：用户登录

  1. 生成签名
将MD5(userAccout和password)
用RSA公钥对MD5数据做加密，生成签名signature

2. 加密请求报文

动态生成一个AES秘钥AESKey
用AESKey将(userAccout和password)加密生成bodyStr

3. 加密AES秘钥

用Base64将AESKey转成AESKeyStr
使用RSA公钥对AESKeyStr加密生成AESKeySecertStr

4. 构建Http请求

构造http post 请求对象
将签名signature 放到http 的header(请求头)中的Authentication中
将AESKeySecertStr放到http 的header(请求头)中的SecurityKey中
将当前时间放到http 的header(请求头)中的TimesTamp中
将bodyStr放到http 的body中

5. 服务器接收处理http请求

  1. 服务器发回响应
返回结果：使用AEKKey对返回的结果做加密处理

7. 发送方解析响应结果

返回结果:使用AEKKey解密

思路图

网络鉴权

URL的详细组成

http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name

  • http:: 协议, //为分隔符。网页使用的是HTTP协议,互联网有多重协议eg: https,FTP。
  • www.aspxfans.com: 域名。域名部分也可以是一个ip地址eg：http://90.90.90.255
  • 8080: 端口号。端口号不是必须的，如果缺失，默认80
  • /news/: 虚拟部分。从域名后的第一个“/”开始到最后一个“/”为止，是虚拟目录部分。虚拟目录也不是一个URL必须的部分
  • index.asp: 从域名后的最后一个“/”开始到“？”为止，是文件名部分，如果没有“?”,则是从域名后的最后一个“/”开始到“#”为止，是文件部分，如果没有“？”和“#”，那么从域名后的最后一个“/”开始到结束，都是文件名部分。
  • name:锚部分。从“#”开始到最后，都是锚部分。锚部分也不是一个URL必须的部分
  • boardID=5&ID=24618&page=1: 参数部分。从“？”开始到“#”为止之间的部分为参数部分，又称搜索部分、查询部分。参数可以允许有多个参数，参数与参数之间用“&”作为分隔符。

从输入URL到浏览器显示页面过程中都发生了什么？

参考 从输入URL到浏览器显示页面过程中都发生了什么？

1.解析URL

浏览器首先解析你输入的 URL，确定协议（如 HTTP 或 HTTPS）、域名、路径和查询参数等。

2. 通过DNS解析域名IP

  • 按顺序从浏览器 -> 系统 -> 路由器 -> ISP这四个里面的缓存中查找有没有对应的缓存，如果有就直接进入下一步
  • 没有找到，就通过公共的域名解析服务发起 DNS 查找请求

3. 与服务器建立 TCP 连接

三次握手建立tcp链接

  • 客户端通过 SYN 报文段发送连接请求，确定服务端是否开启端口准备连接。状态设置为 SYN_SEND;
  • 服务器如果有开着的端口并且决定接受连接，就会返回一个 SYN+ACK 报文段给客户端，状态设置为 SYN_RECV；
  • 客户端收到服务器的 SYN+ACK 报文段，向服务器发送 ACK 报文段表示确认。此时客户端和服务器都设置为 ESTABLISHED 状态。连接建立，可以开始数据传输了

翻译成大白话

  1. 客户端：你能接收到我的消息吗？
  2. 服务端：可以的，那你能接收到我的回复吗？
  3. 客户端：可以，那我们开始聊正事吧。

为什么是3次？ ：避免历史连接，确认客户端发来的请求是这次通信的人。
为什么不是4次？ ：3次够了第四次浪费

3.1 若协议是https则会做加密

HTTPS = HTTP + 加密 + 认证 + 完整性保护

3.2 CA认证流程

  • 要先申请CA证书，并安装在服务器上（一个文件，配置nginx支持监听443端口开启ssl并设置证书路径）

  • 浏览器发送请求；

  • 网站从浏览器发过来的加密规则中选一组自身也支持的加密算法和hash算法，并向浏览器发送带有公钥的证书，当然证书还包含了很多信息，如网站地址、证书的颁发机构、过期时间等。

  • 浏览器解析证书。

    • 验证证书的合法性。如颁发机构是否合法、证书中的网站地址是否与访问的地址一致，若不合法，则浏览器提示证书不受信任，若合法，浏览器会显示一个小锁头。
    • 若合法，或用户接受了不合法的证书，浏览器会生成一串随机数的密码（即密钥），并用证书中提供的公钥加密。
    • 使用约定好的hash计算握手消息，并使用生成的随机数（即密钥）对消息进行加密，最后将之前生成的所有消息一并发送给网站服务器。

  • 网站服务器解析消息。用已有的私钥将密钥解密出来，然后用密钥解密发过来的握手消息，并验证是否跟浏览器传过来的一致。然后再用密钥加密一段握手消息，发送给浏览器。

  • 浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。这里浏览器与网站互相发送加密的握手消息并验证，目的是为了保证双方都获得了一致的密码，并且可以正常的加密解密数据，为后续真正数据的传输做一次测试。

下图表示https加密通信的过程：

4.发送 HTTP 请求

建立 TCP 连接后，浏览器构建并发送 HTTP 请求，包括请求行、请求头和可选的请求体。

5. 服务器响应客户端请求

  • 服务器收到客户端发来的请求后，根据具体请求返回资源有可能是服务端渲染好的HTML，也可能是页面数据，需要客户端根据代码自己渲染

6. 浏览器解析 HTML

  • 浏览器下载 HTML 数据，将html文档解析成为一个个标签，这些标签组成了树状结构
  • 解析style标签则开始解析css
  • 解析script标签则执行脚本

7. 浏览器渲染页面

  • 标签解析好后，浏览器会渲染
  • 渲染好后就会有一部分内容在页面显示

8. 浏览器解析执行js脚本

  • 根据脚本发起网络请求,进行正常的页面交互处理

如何防止hash碰撞

  • 拉链法：如果发生碰撞就加到碰撞元素后面，以链表的形式绑定

  • 开放定址法：如果发生碰撞那就通过某种探测技术找到一个不碰撞的位置。 某种技术：即找到空位置的公式

  • 再哈希法：有多个不同的Hash函数，当发生冲突时，使用第二个，第三个，….，等哈希函数 计算地址，直到无冲突。虽然不易发生聚集，但是增加了计算时间。

  • 建立公共溢出空间：将哈希表分为基本表和溢出表两部分，凡是和基本表发生冲突的元素，一律填入溢出表

avatar
文章
阅读
粉丝