123342342334

_Shyshy

于 2019-04-05 10:22:47 发布

阅读量153

点赞数 1

因特网的两种描述方法：
1.根据硬件和软件组件描述：主机(端系统)通过通信链路和分组交换机连接到一起，遵守一定协议以分组的形式相互传递数据。
2.服务描述：各种涉及多台相互交换数据的端系统的应用程序通过因特网提供给每台端系统的应用编程接口(API)完成不同端系统的数据交换，以完成该应用程序的运行。即因特网是为应用程序提供服务的基础设施。

网络协议概述：
在因特网中，凡是涉及两个或多个远程通信实体的所有活动都受协议的制约。
一个协议定义了在两个或多个通信实体之间交换的报文格式和次序，以及报文发送和接收一条报文或其他事件所采取的动作。

家庭接入因特网：DSL，电缆，FTTH，拨号卫星
1.DSL：
当使用DSL时，用户的本地电话公司是他的ISP(因特网服务提供商)。端系统的网络信号通过家庭的DSL调制解调器将数字信号转换为高频音，再通过电话线传输给本地中心局的DSLAM，然后由DSLAM将高频音转换回数字信号送入因特网。接收信息时同理。
家庭电话线同时承载了网络信号和电话信号

高速下行信道，位于50kHz到1MHz频段，24Mbps传输速率；
中速上行信道，位于4kHz到50kHz频段，2.5Mbps传输速率；
电话信道，位于0到4kHz频段；
实际传输速率比这个小，因为dps供应商根据收费对不同用户进行不同的限速。

版权声明：本文为博主原创文章，转载请附上博文链接！
了解过之前老版本OpenCV的童鞋们都应该清楚，对于OpenCV1.0时代的基于 C 语言接口而建的图像存储格式IplImage*，如果在退出前忘记release掉的话，就会照成内存泄露。而且用起来超级麻烦，我们往往在debug的时候，很大一部分时间在纠结手动释放内存的问题。虽然对于小型的程序来说手动管理内存不是问题，但一旦我们写的代码变得越来越庞大，我们便会开始越来越多地纠缠于内存管理的问题，而不是着力解决你的开发目标。

这，就有些舍本逐末的感觉了。

而浅墨在这篇文章开头想说，自从OpenCV踏入2.0时代，用Mat类数据结构作为主打之后，OpenCV变得越发像需要很少编程涵养的Matlab那样，上手超级快。甚至有些函数名称都和matlab一样，比如大家所熟知的imread，imwrite，imshow等函数。

这对于我们广大图像处理领域的孩子们来说，这的确是一个可喜可贺的事情。

前言
随着移动网络的发展与演化，我们手机上现在除了有原生 App，还能跑“WebApp”——它即开即用，用完即走。一个优秀的 WebApp 甚至可以拥有和原生 App 媲美的功能和体验。WebApp 优异的性能表现，有一部分原因要归功于浏览器存储技术的提升。cookie存储数据的功能已经很难满足开发所需，逐渐被WebStorage、IndexedDB所取代，本文将介绍这几种存储方式的差异和优缺点。

想阅读更多优质文章请猛戳GitHub博客，一年五十篇原创一直在努力！

一、Cookie
1.Cookie的来源
Cookie 的本职工作并非本地存储，而是“维持状态”。
因为HTTP协议是无状态的，HTTP协议自身不对请求和响应之间的通信状态进行保存，通俗来说，服务器不知道用户上一次做了什么，这严重阻碍了交互式Web应用程序的实现。在典型的网上购物场景中，用户浏览了几个页面，买了一盒饼干和两瓶饮料。最后结帐时，由于HTTP的无状态性，不通过额外的手段，服务器并不知道用户到底买了什么，于是就诞生了Cookie。它就是用来绕开HTTP的无状态性的“额外手段”之一。服务器可以设置或读取Cookies中包含信息，借此维护用户跟服务器会话中的状态。

我们可以把Cookie 理解为一个存储在浏览器里的一个小小的文本文件，它附着在 HTTP 请求上，在浏览器和服务器之间“飞来飞去”。它可以携带用户信息，当服务器检查 Cookie 的时候，便可以获取到客户端的状态。

在刚才的购物场景中，当用户选购了第一项商品，服务器在向用户发送网页的同时，还发送了一段Cookie，记录着那项商品的信息。当用户访问另一个页面，浏览器会把Cookie发送给服务器，于是服务器知道他之前选购了什么。用户继续选购饮料，服务器就在原来那段Cookie里追加新的商品信息。结帐时，服务器读取发送来的Cookie就行了。