计算机网络的协议与结构

ß：引用
∂：备注
:: 只引用书名

协议

什么是协议,协议的作用

1、什么是协议，为什么需要协议？

首先，模拟一个场景，这个场景很多老师都会用到。

A讲汉语、B讲法语，两种不同的语言是无法进行沟通的。
如果统一语言，那么大家就可以很轻松的通信。
这个例子是讲：通信的主体之间，必须有相同的协议。
和计算机通信进行比较就是：

• 语言 = 协议
• 聊天 = 通信
• 内容 = 数据

2、协议具体包括那些?

模拟一个场景，也是老师常讲的。

A和B通过电话通话，需要将声音转化为电信号，再从电信号转为声音
这个过程中，存在两次转换，声音=>电信号，电信号=>声音
同样的，计算机也是如此

• 高低电压转为0、1数字，所以有了物理层协议
• 单纯的0、1数据没有意义+信号传输会衰减，所以有了链路层协议
• 解决了以上，还需要转向通信主体【目标对象】，所以有了网络层协议
  ... ...
  这个例子是讲： 协议是分层的 ，计算机网络中，下一层为上一层提供特定服务，每层都有其具体的责任和义务
  还有一点，协议是遵循语言三要素的，但是与语言三要素不同
  协议有三要素：语法、语义、时序
  ß：https://www.zybang.com/question/eab4e5b7622d1aadd5dcac3002b9222a.html
  ∂：非常不开心，引用了一个网页，课本找不到了，先用一下。。。

1. 语义：对构成协议的协议元素含义的解释（讲什么）,特定的符号或数值.
2. 语法：（要素之间的排列规则和格式）用于规定将若干个协议元素和数据组合在一起来表达一个更完整的内容是所应遵循的格式,即对所表达的内容的数据结构形式的一种规定（对更低层次则表现为编码格式和信号水平）（怎么讲）
3. 时序：（TCP三次握手）通信中各事件发生的因果关系,时序规定了某个通信事件及其由它而触发的一系列后续事件的执行顺序.

分组交换协议

分组交换与电路交换

ß：http://www.elecfans.com/dianzichangshi/20171129589006_a.html
都是交换数据的方法。
电路交换，是指 通行主体从创建连接到断开连接，用户一直使用一条电路。 主要的应用是‘电话网络’。
分组交换，是指 通过将数据分成多个数据包，在数据包首部写入‘通信主体的地址’，‘数据包顺序’。 现代的计算机网络，是基于分组交换的基础之上建立的。

分组交换应用场景

1. 计算机将数据分组，发送给路由器
2. 路由器将分组数据缓存到缓冲区
3. 转发给目标地址

分组交换也称为，蓄积交换

-- A讲汉语、B讲法语、C讲德语、D讲英语，三种不同的语言是无法进行沟通的。--

网络构成要素

∂：这个是重点 —— superNonsense
∂：这里不是讲计算机网络构成要素：协议、通信主体、物理设备；而是仅仅讲网络物理设备有哪些

• 网卡：计算机连接网络的设备
• 中继器
• 网桥（L2交换机）
• 路由器
• 4～7层交换机
• 网关

网桥

V8 引擎

• 排序
  https://v8.dev/blog/array-sort

Node.js

• 模块加载
  http://efe.baidu.com/blog/nodejs-module-analyze/

什么是好的

• 业务逻辑、代码逻辑拆分，分模块
• 页面逻辑不可太多，流程图、代码结
• 易迭代、可维护性高
• 维护期，分支问题反馈主版本
• 维护主分支，项目依赖文档

划分目标

• 如何让项目开发可预期
  • 流程化
  • 标准
  • 模块化
• 如何让项目质量可保证
  • 业务流程化
  • 模块化

计算机网络出现的背景

ß：引用
∂：备注
:: 只引用书名

计算机网络的演变

ß：摘自 -- 图解TCP/IP（第5版）

引子

计算机自诞生伊始，经历了一系列演变与发展。大型通用计算机、超级计算机、小型机、个人电脑、工作站、便携式电脑以及现如今的智能手机终端等都是这一过程的产物。它们的性能逐年增强，价格却逐年下降，机体规模也正在逐渐变小。

从独立模式到网络互连模式

起初，计算机以单机模式被广泛使用（这种方式也叫独立模式)。然而随着计算机的不断发展，人们已不再局限于单机模式，而是将一个个计算机连接在一起，形成一个计算机网铬。
连接多台计算机可以实现信息共享，同时还能在两台物理位置较远的机器之间即时传递信息 ∂1。
∂：独立模式=> 互联模式

∂0: 独立模式：一台计算机在一个时刻仅能处理一项工作

∂1：互联模式：共享数据出现

计算机与网络的发展阶段

ß： 摘自 -- 计算机网络基础

计算机的发展 —— 批处理/ Batch Processing

计算机的发展 —— 分时系统/ Time sharing System

∂：这个时刻出现了BASIC SYSTEM

网络的发展 —— 计算机间通信

1961--1972:早期分组交换原理的提出和引用

• 1961 Kleinrock - 排队论，证实分组交换的可行性
• 1964 Baran - 分组交换，应用于军事网络
• 1967 ARPA - 提出ARPAnet 构想
• 1972 第一个主机到主机的协议NCP
  ∂：

网络发展 —— 网络互联

1972--1980:大量网络出现

• 1970 ALOHAnet 卫星网络
• 1974： Cerf与Kahn - 提出网络互连体系结构
  &&极简/minimalism 自制/autonomy
• 1976: Xerox 设计了以太网

70‘s后期
1、私有网络体系结构：DECnet，SNA，XNA
2、固定长度分组交换（ATM）
1975 ARPAnet 交给美国国防部通信局管理（希望保证网路健壮性）

网络发展 —— 网络协议和网络激增

1980--1990

• 1983： 部署TCP/IP
• 1982： 定义smtp
• 1983： DNS
• 1985： FTP
• 1988： TCP堵塞控制

网络发展 —— 互联网普及

网络应用、P2P文件共享、主机与用户激增、主干链路带宽达到Gbps

网络发展 —— 物联网普及

至今
∂： 计算机的发展是，从大到小，从昂贵到廉价，从慢到快。计算机网络的发展是，点到点，网络到网络，同时，随着用户的递增，协议也在不断更新创建

问题

计算机网络通信 与 计算机网络 通信区别

接下来

这里面涉及了一些定义

• 什么是协议
• 计算机协议的作用
• 分组交换协议

相关参考

1、分时系统【我感觉这个没错】
https://blog.csdn.net/uniquewonderq/article/details/46482619
2、计算机网络基础课件
https://wenku.baidu.com/view/1a9a6debf8c75fbfc77db28e.html

前端性能检测

一、Performance

performance

1.1、timing or timeOrigin

ß：https://developer.mozilla.org/zh-CN/docs/Web/API/Performance/timing
mdn 文档上讲timeOrigin将替换timing。但是，文档上timing 是一个对象，timeOrigin 是一个高精度时间戳
所以，参考两个档案。

1.1.1、timing

ß：https://w3c.github.io/navigation-timing/
Performance.timing 也执行了‘高精度时间’标准

1.1.2、timeOrigin

ß：https://w3c.github.io/hr-time/
timeOrigin 是一个亚毫秒级别的单调时钟【High Resolution Time】【Monotonic Clock】，可用来解决

• 测量导航到文档的准确时间；获取资源时间；执行脚本等所需时间
• 脚本计算动画状态时，精准知晓动画经过的时间
• 计算基于脚本的动画帧速率【单位：FPS】
• 音频与动画的同步【需要动画和音频经过的准确时间】
• When multiple contexts need to synchronize work with sub-millisecond resolution (e.g. when using dedicated or shared workers to drive animation, audio, etc., in a renderer context), or to create a unified view of the event timeline.
• 等
  timeOrigin 是不受系统、用户时钟的影响，偏差等

1.2、使用timing 进行性能监测

1.2.1、生命周期：original text

∂：navigation [nævɪ'geɪʃ(ə)n] 导航/浏览

1、开始

• 导航被终止：上下文导航预先存在；；用户取消导航

原文：The navigation is aborted due to the sandboxed navigation browsing context flag, the sandboxed top-level navigation without user activation browsing context flag or the sandboxed top-level navigation with user activation browsing context flag, a preexisting attempt to navigate the browsing context, or the user canceling the navigation.

• 因页面内的片段标识符发起的导航
• 由内联内容触发的新资源
• 不影响浏览上下文触发的新资源
• 用户拒绝文档删除

2、创建一个新的PerformanceNavigationTiming对象，添加在performance entry buffer

[Exposed=Window]
interface PerformanceNavigationTiming : PerformanceResourceTiming {
  readonly attribute DOMHighResTimeStamp unloadEventStart;
  readonly attribute DOMHighResTimeStamp unloadEventEnd;
  readonly attribute DOMHighResTimeStamp domInteractive;
  readonly attribute DOMHighResTimeStamp domContentLoadedEventStart;
  readonly attribute DOMHighResTimeStamp domContentLoadedEventEnd;
  readonly attribute DOMHighResTimeStamp domComplete;
  readonly attribute DOMHighResTimeStamp loadEventStart;
  readonly attribute DOMHighResTimeStamp loadEventEnd;
  readonly attribute NavigationType type;
  readonly attribute unsigned short redirectCount;
  [Default] object toJSON();
};

3、设置 name 为document [属性为 DOMString]
4、设置entryType 和 initiatorType 为navigation
5、设置startTime 为FDOMHighResTimeStamp，时间值为0，并且 nextHopProtocol 设置为 空[DOMString]
6、记录当前导航类型，如果他尚未设置。
7、If the previous document does not pass the algorithm, set both unloadEventStart and unloadEventEnd to 0 then go to . Otherwise, record unloadEventStart as the time immediately before the unload event.
8、Immediately after the unload event is completed, record the current time as unloadEventEnd. If the navigation URL has an , immediately before the user agent record the time as workerStart, or if the worker is available, record the time before the at the active worker. Otherwise, if the navigation URL has no matching , set workerStart value to zero.
9、【分发步骤】如果是使用GET请求，则用户代理检查应用程序缓存，并且，记录当前时间作为fetchStart，workerStart 设置为零。
ß：

The workerStart attribute MUST return the time immediately before the user agent ran 
the worker (if the current document has an active service worker registration [SERVICE-WORKERS]) 
required to service the request, or if the worker was already available, 
the time immediately before the user agent fired an event named `fetch` 
at the active worker. Otherwise, if there is no active worker this attribute 
MUST return zero.

∂：workerStart：应该是记录一个触发请求事件之前的时间，在没有服务工作者【Run Service Worker】的时候，workerStart 为零。
10、Let domainLookupStart, domainLookupEnd, connectStart and connectEnd be the same value as fetchStart.
11、将名称设置为当前文档地址的DOMString值。
12、如果这个资源可以从相关应用缓存、本地资源中包括HTTP缓存[RFC7234] 中获取fetching的话，让我们跳转至【请求启动步骤】
13、如果可以不进行域查找，则跳转至【链接启动步骤】，否则，在用户代理启动域名查询之前，记录此刻作为domainLookupStart
14、在域名查询成功之后，记录此时为domainLookupEnd
15、【链接启动步骤】如果使用长链接[a persistent 持久 transport connection]获取资源，则让connectStart和connectEnd与domainLookupEnd保持一致。否则，记录开始连接到服务器之前的时刻作为connectStart，并且记录在连接服务器或者代理建立之后的时刻作为connectEnd。用户代理可能需要多次重试在[连接建立]之前。一旦建立连接将ALPN ID设置为nextHopProtocol的值用来连接。如果链接没有被建立，abort终止这个步骤接下来的部分。
16、用户代理务必根据此流程设置secureConnectionStart属性：

• 当使用安全传输时，用户代理必须记录握手之前的时刻作为secureConnectionStart的值，[When a secure transport is used, the user agent MUST record the time as secureConnectionStart immediately before the handshake process to secure the connection.]
• 当安全连接没有被使用，用户代理必须设置secureConnectionStart为零

17、【请求启动步骤】即刻，在用户代理启动发送请求文档的时刻，记录当前时间作为requestStart
18、记录用户代理接受响应的第一个byte的时间作为responseStart
19、记录接受响应的最后一个byte的时间作为responseEnd

• 如果用户代理发送请求或者接受响应失败，并且重新打开连接时，返回至【连接启动步骤】

NOTE
When persistent connection [RFC7230] is enabled, a user agent MAY first try to re-use an open connect to send the request while the connection can be asynchronously closed. In such case, connectStart, connectEnd and requestStart SHOULD represent timing information collected over the re-open connection.

• 设置tansferSize，encodeBodySize，decodeBodySize为相应[corresponding] 的值

20、如果获取的资源的导致重定向，那么：

a. If the timing allow check algorithm does not pass for the origin of the fetched resource, 
set redirectStart, redirectEnd, unloadEventStart, unloadEventEnd and redirectCount to 0. 
Then, return to fetch-start-step with the new resource.
b. Increment redirectCount by 1.
c. If the value of redirectStart is 0, let it be the value of fetchStart.
d. Let redirectEnd be the value of responseEnd.
e. Set all of the attributes in the PerformanceNavigationTiming object to 0 
except startTime, redirectStart, redirectEnd, redirectCount, type, nextHopProtocol, 
unloadEventStart and unloadEventEnd. Set nextHopProtocol to the empty DOMString.
f. Return to fetch-start-step with the new resource.

21、在用户代理将当前文档准备就绪时，记录domInteractive 为当时时间。
22、用户代理在文档上触发[fires] DOMContentLoaded event事件之前，立即记录domContentLoadedEventStart为当时时间
23、在DOMContentLoaded event 完成[completes] 时，立即记录domContentLoadedEventEnd
24、用户代理设置 current document readiness 为 complete 时，立即记录domComplete
25、loadEventStart：用户代理触发加载事件
26、loadEventEnd：用户代理完成加载事件
27、duration[持续时间]：DOMHighResTimeStamp = doadEventEnd - startTime [Set the duration to a DOMHighResTimeStamp equal to the difference between loadEventEnd and startTime, respectively.]
28、队列展示这个对象

1.2.2、方法实例

根据Resource Timing ，可以用别人家的实例举个例子

// 获取 performance 数据
var performance = {  
    // memory 是非标准属性，只在 Chrome 有
    // 财富问题：我有多少内存
    memory: {
        usedJSHeapSize:  16100000, // JS 对象（包括V8引擎内部对象）占用的内存，一定小于 totalJSHeapSize
        totalJSHeapSize: 35100000, // 可使用的内存
        jsHeapSizeLimit: 793000000 // 内存大小限制
    },
 
    //  哲学问题：我从哪里来？
    navigation: {
        redirectCount: 0, // 如果有重定向的话，页面通过几次重定向跳转而来
        type: 0           // 0   即 TYPE_NAVIGATENEXT 正常进入的页面（非刷新、非重定向等）
                          // 1   即 TYPE_RELOAD       通过 window.location.reload() 刷新的页面
                          // 2   即 TYPE_BACK_FORWARD 通过浏览器的前进后退按钮进入的页面（历史记录）
                          // 255 即 TYPE_UNDEFINED    非以上方式进入的页面
    },
 
    timing: {
        // 在同一个浏览器上下文中，前一个网页（与当前页面不一定同域）unload 的时间戳，如果无前一个网页 unload ，则与 fetchStart 值相等
        navigationStart: 1441112691935,
 
        // 前一个网页（与当前页面同域）unload 的时间戳，如果无前一个网页 unload 或者前一个网页与当前页面不同域，则值为 0
        unloadEventStart: 0,
 
        // 和 unloadEventStart 相对应，返回前一个网页 unload 事件绑定的回调函数执行完毕的时间戳
        unloadEventEnd: 0,
 
        // 第一个 HTTP 重定向发生时的时间。有跳转且是同域名内的重定向才算，否则值为 0 
        redirectStart: 0,
 
        // 最后一个 HTTP 重定向完成时的时间。有跳转且是同域名内部的重定向才算，否则值为 0 
        redirectEnd: 0,
 
        // 浏览器准备好使用 HTTP 请求抓取文档的时间，这发生在检查本地缓存之前
        fetchStart: 1441112692155,
 
        // DNS 域名查询开始的时间，如果使用了本地缓存（即无 DNS 查询）或持久连接，则与 fetchStart 值相等
        domainLookupStart: 1441112692155,
 
        // DNS 域名查询完成的时间，如果使用了本地缓存（即无 DNS 查询）或持久连接，则与 fetchStart 值相等
        domainLookupEnd: 1441112692155,
 
        // HTTP（TCP） 开始建立连接的时间，如果是持久连接，则与 fetchStart 值相等
        // 注意如果在传输层发生了错误且重新建立连接，则这里显示的是新建立的连接开始的时间
        connectStart: 1441112692155,
 
        // HTTP（TCP） 完成建立连接的时间（完成握手），如果是持久连接，则与 fetchStart 值相等
        // 注意如果在传输层发生了错误且重新建立连接，则这里显示的是新建立的连接完成的时间
        // 注意这里握手结束，包括安全连接建立完成、SOCKS 授权通过
        connectEnd: 1441112692155,
 
        // HTTPS 连接开始的时间，如果不是安全连接，则值为 0
        secureConnectionStart: 0,
 
        // HTTP 请求读取真实文档开始的时间（完成建立连接），包括从本地读取缓存
        // 连接错误重连时，这里显示的也是新建立连接的时间
        requestStart: 1441112692158,
 
        // HTTP 开始接收响应的时间（获取到第一个字节），包括从本地读取缓存
        responseStart: 1441112692686,
 
        // HTTP 响应全部接收完成的时间（获取到最后一个字节），包括从本地读取缓存
        responseEnd: 1441112692687,
 
        // 开始解析渲染 DOM 树的时间，此时 Document.readyState 变为 loading，并将抛出 readystatechange 相关事件
        domLoading: 1441112692690,
 
        // 完成解析 DOM 树的时间，Document.readyState 变为 interactive，并将抛出 readystatechange 相关事件
        // 注意只是 DOM 树解析完成，这时候并没有开始加载网页内的资源
        domInteractive: 1441112693093,
 
        // DOM 解析完成后，网页内资源加载开始的时间
        // 在 DOMContentLoaded 事件抛出前发生
        domContentLoadedEventStart: 1441112693093,
 
        // DOM 解析完成后，网页内资源加载完成的时间（如 JS 脚本加载执行完毕）
        domContentLoadedEventEnd: 1441112693101,
 
        // DOM 树解析完成，且资源也准备就绪的时间，Document.readyState 变为 complete，并将抛出 readystatechange 相关事件
        domComplete: 1441112693214,
 
        // load 事件发送给文档，也即 load 回调函数开始执行的时间
        // 注意如果没有绑定 load 事件，值为 0
        loadEventStart: 1441112693214,
 
        // load 事件的回调函数执行完毕的时间
        loadEventEnd: 1441112693215
 
        // 字母顺序
        // connectEnd: 1441112692155,
        // connectStart: 1441112692155,
        // domComplete: 1441112693214,
        // domContentLoadedEventEnd: 1441112693101,
        // domContentLoadedEventStart: 1441112693093,
        // domInteractive: 1441112693093,
        // domLoading: 1441112692690,
        // domainLookupEnd: 1441112692155,
        // domainLookupStart: 1441112692155,
        // fetchStart: 1441112692155,
        // loadEventEnd: 1441112693215,
        // loadEventStart: 1441112693214,
        // navigationStart: 1441112691935,
        // redirectEnd: 0,
        // redirectStart: 0,
        // requestStart: 1441112692158,
        // responseEnd: 1441112692687,
        // responseStart: 1441112692686,
        // secureConnectionStart: 0,
        // unloadEventEnd: 0,
        // unloadEventStart: 0
    }
};

##实例##

// 计算加载时间
function getPerformanceTiming () {  
    var performance = window.performance;
 
    if (!performance) {
        // 当前浏览器不支持
        console.log('你的浏览器不支持 performance 接口');
        return;
    }
 
    var t = performance.timing;
    var times = {};
 
    //【重要】页面加载完成的时间
    //【原因】这几乎代表了用户等待页面可用的时间
    times.loadPage = t.loadEventEnd - t.navigationStart;
 
    //【重要】解析 DOM 树结构的时间
    //【原因】反省下你的 DOM 树嵌套是不是太多了！
    times.domReady = t.domComplete - t.responseEnd;
 
    //【重要】重定向的时间
    //【原因】拒绝重定向！比如，http://example.com/ 就不该写成 http://example.com
    times.redirect = t.redirectEnd - t.redirectStart;
 
    //【重要】DNS 查询时间
    //【原因】DNS 预加载做了么？页面内是不是使用了太多不同的域名导致域名查询的时间太长？
    // 可使用 HTML5 Prefetch 预查询 DNS ，见：[HTML5 prefetch](http://segmentfault.com/a/1190000000633364)            
    times.lookupDomain = t.domainLookupEnd - t.domainLookupStart;
 
    //【重要】读取页面第一个字节的时间
    //【原因】这可以理解为用户拿到你的资源占用的时间，加异地机房了么，加CDN 处理了么？加带宽了么？加 CPU 运算速度了么？
    // TTFB 即 Time To First Byte 的意思
    // 维基百科：https://en.wikipedia.org/wiki/Time_To_First_Byte
    times.ttfb = t.responseStart - t.navigationStart;
 
    //【重要】内容加载完成的时间
    //【原因】页面内容经过 gzip 压缩了么，静态资源 css/js 等压缩了么？
    times.request = t.responseEnd - t.requestStart;
 
    //【重要】执行 onload 回调函数的时间
    //【原因】是否太多不必要的操作都放到 onload 回调函数里执行了，考虑过延迟加载、按需加载的策略么？
    times.loadEvent = t.loadEventEnd - t.loadEventStart;
 
    // DNS 缓存时间
    times.appcache = t.domainLookupStart - t.fetchStart;
 
    // 卸载页面的时间
    times.unloadEvent = t.unloadEventEnd - t.unloadEventStart;
 
    // TCP 建立连接完成握手的时间
    times.connect = t.connectEnd - t.connectStart;
 
    return times;
}

1.2.3、这里还有一个监测资源的方法Performance.getEntries()

返回一个数组，将所有http 请求包含在内，与timing大约一致

1.3、参考阅读

http://www.alloyteam.com/2015/09/explore-performance/

1.4、使用场景

很明显，他不易于可视化展示一些需求。