网络基本知识点汇总

作者: 码上就说 | 来源:发表于2019-02-13 10:32 被阅读307次

1.TCP/IP五层网络架构
2.OSI七层网络架构
3.TCP 3次握手,四次挥手
4.TCP/UDP协议区别
5.浏览器工作原理:从 URL 输入到页面展现到底发生了什么?
6.chromium浏览器内核架构
7.http1.1 vs http2.0
8.http2.0 vs quic
9.https的加密过程
10.对称加密和非对称加密
11.TLS1.3 vs TLS1.2

1.TCP/IP五层网络架构

TCP/IP层 网络设备
应用层 HTTP协议工作的层
传输层 四层交换机,也有工作在四层的路由器
网络接口层 路由器,3层交换机
数据链路层 网桥、以太网交换机、网卡
物理层 中继器、集线器等

2.OSI七层网络架构

OSI层 功能 TCP/IP协议
应用层 文件传输,电子邮件,文件服务,虚拟终端 TFTP, HTTP, SNMP, FTP, SMTP, DNS, Telnet
表示层 数据格式化,代码转换,数据加密 没有协议
会话层 解除或者建立与其他节点的联系 没有协议
传输层 提供端对端的接口 TCP, UDP
网络层 为数据包选择路由 IP, ICMP, RIP, OSPF, BGP, IGMP
数据链路层 传输有地址的帧,错误检测功能 SLIP, CSLIP, PPP, ARP, RARP, MTU
物理层 以二进制数据形式在物理媒体上传输数据 ISO2110, IEEE802

除了层的数量之外,开放式系统互联(OSI)模型与TCP/IP协议有什么区别?

  • TCP/IP协议中的应用层处理开放式系统互联模型中的第五层、第六层和第七层的功能。
  • TCP/IP协议中的传输层并不能总是保证在传输层可靠地传输数据包,而开放式系统互联模型可以做到。这是因为TCP/IP协议还提供一项名为UDP(用户数据报协议)的选择。UDP不能保证可靠的数据包传输。

3.TCP 3次握手,四次挥手

TCP建立连接时要经过3次握手:


三次握手建立连接时,发送方再次发送确认的必要性?
主要是为了防止已失效的连接请求报文段突然又传到了B,因而产生错误。假定出现一种异常情况,即A发出的第一个连接请求报文段并没有丢失,而是在某些网络结 点长时间滞留了,一直延迟到连接释放以后的某个时间才到达B,本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后,就误认为是A又发出一次 新的连接请求,于是就向A发出确认报文段,同意建立连接。假定不采用三次握手,那么只要B发出确认,新的连接就建立了,这样一直等待A发来数据,B的许多 资源就这样白白浪费了。

TCP关闭连接是需要4次挥手:


四次挥手释放连接时,等待2MSL的意义?
第一,为了保证A发送的最有一个ACK报文段能够到达B。这个ACK报文段有可能丢失,因而使处在LAST-ACK状态的B收不到对已发送的FIN和ACK 报文段的确认。B会超时重传这个FIN和ACK报文段,而A就能在2MSL时间内收到这个重传的ACK+FIN报文段。接着A重传一次确认。
第二,就是防止上面提到的已失效的连接请求报文段出现在本连接中,A在发送完最有一个ACK报文段后,再经过2MSL,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。

4.TCP/UDP协议区别

  • TCP协议是有连接的,有连接的意思是开始传输实际数据之前TCP的客户端和服务器端必须通过三次握手建立连接,会话结束之后也要结束连接。而UDP是无连接的
  • TCP协议保证数据按序发送,按序到达,提供超时重传来保证可靠性,但是UDP不保证按序到达,甚至不保证到达,只是努力交付,即便是按序发送的序列,也不保证按序送到。
  • TCP协议所需资源多,TCP首部需20个字节(不算可选项),UDP首部字段只需8个字节。
  • TCP有流量控制和拥塞控制,UDP没有,网络拥堵不会影响发送端的发送速率
  • TCP是一对一的连接,而UDP则可以支持一对一,多对多,一对多的通信。
  • TCP面向的是字节流的服务,UDP面向的是报文的服务。

5.浏览器工作原理:从 URL 输入到页面展现到底发生了什么?

  • 1.键盘或触屏输入URL并回车确认
  • 2.URL解析/DNS解析查找域名IP地址
  • 3.网络连接发起HTTP请求
  • 4.HTTP报文传输过程
  • 5.服务器接收数据
  • 6.服务器响应请求
  • 7.服务器返回数据
  • 8.客户端接收数据
  • 9.浏览器加载/渲染页面
  • 10.打印绘制输出

DNS查询分为*递归查询和迭代查询两种。

6.chromium浏览器内核架构

image.png

Blink中采用了多进程架构,它的优点如下

  • 1.避免单个page crash影响整个浏览器;
  • 2.避免第三方插件crash影响整个浏览器;
  • 3.多进程充分利用多核优势;
  • 4.方便使用沙盒模型隔离插件等进程,提高浏览器稳定性。

Blink中包含的主要进程如下:

  • 1.Browser进程:主进程,只有一个。它的作用有负责浏览器界面显示,与用户交互。如前进,后退等,负责各个页面的管理,创建和销毁其他进程,将Renderer进程得到的内存中的Bitmap,绘制到用户界面上网络资源的管理,下载等。
  • 2.Renderer进程:默认每个页面一个,互不影响。主要作用为解析HTML,CSS,构建DOM树和RenderObject树,布局和绘制等。
  • 3.第三方插件进程:每种类型的插件对应一个进程,仅当使用该插件时才创建。
  • 4.GPU进程:最多一个,用于3D绘制等。

Browser和Renderer通信过程:

  • 1.Browser进程收到用户请求,首先UI线程处理,转交给IO线程,随后通过RendererHost接口转交给Renderer进程
  • 2.Renderer进程的Renderer接口收到消息,IO线程简单处理后,交给渲染线程,进行HTML解析和DOM树构建,CSS解析,JS执行,RenderObject树构建,布局和绘制等过程,生成用户可见区域(ViewPort)的Bitmap。最后通过共享内存方式IPC给Browser进程
  • 3.Browser进程使用Bitmap内存在界面上绘制出图像。

7.http1.1 vs http2.0

*(1)HTTP/2采用二进制格式而非文本格式
这个功能非常有效,因为二进制格式会加上frame,frame有序,这样我们不必像之前传输文本那样按序传输,可以直接并行传输,frame数据中包含序号,在服务端重组即可。
*(2)HTTP/2是完全多路复用的,而非有序并阻塞的——只需一个连接即可实现并行
同域名下可以复用一个连接,Apache支持的并发数是300,这次可以最大程度的支持并发。
*(3)使用报头压缩,HTTP/2降低了开销,HPack压缩算法。
*(4)HTTP/2让服务器可以将响应主动“推送”到客户端缓存中

8.http2.0 vs quic

*(1)减少了 TCP 三次握手及 TLS 握手时间。

  • 第一次建立连接需要1RTT,之后需要0RTT,当客户端首次发起QUIC连接时,客户端想服务器发送一个client hello消息,服务器回复一个server reject消息。该消息中有包括server config,类似于TLS1.3中的key_share交换。这需要产生1-RTT
    当客户端获取到server config以后,就可以直接计算出密钥,发送应用数据了,可以认为是0-RTT。
    因此,QUIC握手除去首次连接需要产生1-RTT,理论上,后续握手都是0-RTT的。

*(2)改进的拥塞控制。
*(3)避免队头阻塞的多路复用。

  • SPDY 和 HTTP/2 协议现在都支持将页面的多个数据(如图片、js 等)通过一个数据链接进行传输。该特性能够加快页面组件的传输速度,但是对于 TCP 协议来说,这会遇到前序包阻塞的问题。这是由于 TCP 协议在处理包时是有严格顺序的,当其中一个数据包遇到问题,TCP 连接需要等待这个包完成重传之后才能继续进行。因此,即使逻辑上一个 TCP 连接上并行的在进行多路数据传输,其他毫无关联的数据也会因此阻塞。



    QUIC 协议直接通过底层使用 UDP 协议天然的避免了该问题。由于 UDP 协议没有严格的顺序,当一个数据包遇到问题需要重传时,只会影响该数据包对应的资源,其他独立的资源(如其他 css、js 文件)不会受到影响。


*(4)连接迁移。

  • 底层协议切换到 UDP 协议之后的另一大好处是,连接不再依赖于来源 IP。
    对于 TCP 协议来说,标识一个 TCP 连接需要 4 个参数,既来源 IP、来源端口、目的 IP 和目的端口。其中的任一参数改变,TCP 连接就需要重新创建。

这对于传统网络来说影响不大,因为来源和目的 IP 相对固定。但是在无线网络中,情况就大不相同了。设备在移动过程中,可能会因为网络切换(如从 WIFI 网络切换到 4G 网络环境),导致 TCP 连接需要重新创建。
QUIC 协议使用了 UDP 协议,不再需要这四元组参数。同时 QUIC 协议实现了自己的会话标记方式,称为连接 UUID。当设备网络环境切换时,连接 UUID 不会发生变化,因此无需重新进行握手。

*(5)前向冗余纠错。

  • QUIC 协议有一个非常独特的特性,称为向前纠错(Forward Error Correction),每个数据包除了它本身的内容之外,还包括了部分其他数据包的数据,因此少量的丢包可以通过其他包的冗余数据直接组装而无需重传。
    向前纠错牺牲了每个数据包可以发送数据的上限,但是减少了因为丢包导致的数据重传,因为数据重传将会消耗更多的时间(包括确认数据包丢失、请求重传、等待新数据包等步骤的时间消耗)。

参考:QUIC原理

QUIC 协议的主要目的,是为了整合 TCP 协议的可靠性和 UDP 协议的速度和效率。



QUIC 协议内置了 TLS 栈,实现了自己的传输加密层,而没有使用现有的 TLS 1.2。同时 QUIC 还包含了部分 HTTP/2 的实现。
QUIC 底层通过 UDP 协议替代了 TCP,上层只需要一层用于和远程服务器交互的 HTTP/2 API。这是因为 QUIC 协议已经包含了多路复用和连接管理,HTTP API 只需要完成 HTTP 协议的解析即可。

9.https的加密过程

最近重新了解了下HTTP和HTTPS: 首先二者都是网络传输协议;HTTPS在传输过程中是可以通过加密来保护数据安全的,以免用户敏感信息被第三方获取。 可以说HTTPS是HTTP的升级版、安全版。下面我们就简单看下HTTPS的加密过程,先看下图。


  • 1.客户端发起HTTPS请求
    这个没什么好说的,就是用户在浏览器里输入一个HTTPS网址,然后连接到服务端的443端口。
  • 2.服务端的配置
    采用HTTPS协议的服务器必须要有一套数字证书,可以自己制作,也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过,才可以继续访问,而使用受信任的公司申请的证书则不会弹出提示页面。这套证书其实就是一对公钥和私钥。如果对公钥不太理解,可以想象成一把钥匙和一个锁头,只是世界上只有你一个人有这把钥匙,你可以把锁头给别人,别人可以用这个锁把重要的东西锁起来,然后发给你,因为只有你一个人有这把钥匙,所以只有你才能看到被这把锁锁起来的东西。
  • 3.传送证书
    这个证书其实就是公钥,只是包含了很多信息,如证书的颁发机构,过期时间等等。
  • 4.客户端解析证书
    这部分工作是由客户端的SSL/TLS来完成的,首先会验证公钥是否有效,比如颁发机构,过期时间等等,如果发现异常,则会弹出一个警示框,提示证书存在的问题。如果证书没有问题,那么就生成一个随机值。然后用证书(也就是公钥)对这个随机值进行加密。就好像上面说的,把随机值用锁头锁起来,这样除非有钥匙,不然看不到被锁住的内容。
  • 5.传送加密信息
    这部分传送的是用证书加密后的随机值,目的是让服务端得到这个随机值,以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
  • 6.服务端解密信息
    服务端用私钥解密后,得到了客户端传过来的随机值,然后把内容通过该随机值进行对称加密,将信息和私钥通过某种算法混合在一起,这样除非知道私钥,不然无法获取内容,而正好客户端和服务端都知道这个私钥,所以只要加密算法够彪悍,私钥够复杂,数据就够安全。
  • 7.传输加密后的信息
    这部分信息就是服务端用私钥加密后的信息,可以在客户端用随机值解密还原。
  • 8.客户端解密信息
    客户端用之前生产的私钥解密服务端传过来的信息,于是获取了解密后的内容。整个过程第三方即使监听到了数据,也束手无策。

10.对称加密和非对称加密

对称加密(Symmetric Cryptography),又称私钥加密。
对称加密是最快速、最简单的一种加密方式,加密(encryption)与解密(decryption)用的是同样的密钥(secret key),这种方法在密码学中叫做对称加密算法。对称加密有很多种算法,由于它效率很高,所以被广泛使用在很多加密协议的核心当中。对称加密通常使用的是相对较小的密钥,一般小于256 bit。因为密钥越大,加密越强,但加密与解密的过程越慢。如果你只用1 bit来做这个密钥,那黑客们可以先试着用0来解密,不行的话就再用1解;但如果你的密钥有1 MB大,黑客们可能永远也无法破解,但加密和解密的过程要花费很长的时间。密钥的大小既要照顾到安全性,也要照顾到效率,是一个trade-off。

非对称加密(Asymmetric Cryptography),又称公钥加密。
非对称密钥加密,它需要使用“一对”密钥来分别完成加密和解密操作,一个公开发布,即公开密钥,另一个由用户自己秘密保存,即私用密钥。信息发送者用公开密钥去加密,而信息接收者则用私用密钥去解密。公钥机制灵活,但加密和解密速度却比对称密钥加密慢得多。
非对称密钥加密的使用过程:

  • 1.A要向B发送信息,A和B都要产生一对用于加密和解密的公钥和私钥。
  • 2.A的私钥保密,A的公钥告诉B;B的私钥保密,B的公钥告诉A。
  • 3.A要给B发送信息时,A用B的公钥加密信息,因为A知道B的公钥。
  • 4.A将这个消息发给B(已经用B的公钥加密消息)。
  • 5.B收到这个消息后,B用自己的私钥解密A的消息,其他所有收到这个报文的人都无法解密,因为只有B才有B的私钥。
  • 6.反过来,B向A发送消息也是一样。

(1) 对称加密加密与解密使用的是同样的密钥,所以速度快,但由于需要将密钥在网络传输,所以安全性不高。
(2) 非对称加密使用了一对密钥,公钥与私钥,所以安全性高,但加密与解密速度慢。
(3) 解决的办法是将对称加密的密钥使用非对称加密的公钥进行加密,然后发送出去,接收方使用私钥进行解密得到对称加密的密钥,然后双方可以使用对称加密来进行沟通。


11.TLS1.3 vs TLS1.2

TLS(Transport Layer Security Protocol,传输层安全协议)主要目的是提供隐私和数据两个通信应用之间的完整性。该协议由两层组成:TLS 记录协议(TLS Record)和 TLS 握手协议(TLS Handshake)。
我们熟知的一般是SSL(Secure Sockets Layer 安全套接层),TLS是SSL标准化的协议。TLS处于应用层和传输层之间。


TLS 1.3 与之前的协议有较大差异,主要在于:
  • 相比过去的的版本,引入了新的密钥协商机制 — PSK
  • 支持 0-RTT 数据传输,在建立连接时节省了往返时间
  • 废弃了 3DES、RC4、AES-CBC 等加密组件,废弃了 SHA1、MD5 等哈希算法
  • ServerHello 之后的所有握手消息采取了加密操作,可见明文大大减少
  • 不再允许对加密报文进行压缩、不再允许双方发起重协商
  • DSA 证书不再允许在 TLS 1.3 中使用

参考:https://www.jianshu.com/p/efe44d4a7501

TLS1.3的核心优势是:1.访问速度更快;2.安全性更高。
TLS1.2握手流程:


从上图可以看出,使用 TLS 1.2 需要两次往返( 2-RTT )才能完成握手,然后才能发送请求。

TLS1.3握手流程:



TLS 1.3 的握手不再支持静态的 RSA 密钥交换,这意味着必须使用带有前向安全的 Diffie-Hellman 进行全面握手。从上图可以看出,使用 TLS 1.3 协议只需要一次往返( 1-RTT )就可以完成握手。
相比 TLS 1.2,TLS 1.3 的握手时间减半。这意味着访问一个移动端网站,使用 TLS 1.3 协议,可能会减少将近 100ms 的时间。

相关文章

网友评论

    本文标题:网络基本知识点汇总

    本文链接:https://www.haomeiwen.com/subject/pwcssqtx.html