Home 网络协议

先放链接,一位大佬行云流水的文章:

深入理解什么是端口(port) – 知乎 (zhihu.com)

 

前言

为了观察服务是否启动以及排查异常情况,我们常常需要查看服务器的日志信息,涉及到Linux一直是我的弱点,而本篇文章 《究竟什么是端口》则是源于服务发布时,通过tail -f info.log 观察实时日志,我无法确定服务是否正常启动,同事则给我推荐观察服务端口的方式来验证

通过端口观察服务是否正常启动,其操作十分简单:使用netstas -tunlp命令

本篇内容的重点并非Linux命令,因此其他说明略

起源

我第一次折腾阿里云服务器时,挂在云服务器上的网站打不开,当时的阿里技术人员让我看看是不是端口没打开;小时候玩电脑,有时网络连接不上,技术人员也会让我看看是不是网线端口没有插好。那时不懂端口分物理端口和逻辑端口,后来学习了TCP/IP协议,跑起来第一个Tomcat的8080应用,逐渐理解了端口类似于门户的概念,实际上也是一知半解,因此今天决意深入了解。

物理端口和逻辑端口

物理是用于连接物理设备之间的接口,逻辑是逻辑上用于区分服务的端口。

物理端口不作说明,下文详细介绍逻辑端口

常见端口

  • mysql 缺省用的 3306 端口,
  • redis 的 6379 端口,
  • tomcat 默认用的 8080 端口,
  • ssh 用的 22 端口,
  • 等等…

端口是必须的吗?

在本地 web 开发调试过程中, 我们可能都碰到过端口, 比如或许是/最著名的 8080 端口, 一般我们会这样去访问本地的 web 程序:

localhost:8080

但一旦 web 程序部署到了正式的网站中, 端口似乎就消失了, 正式的网址中就不需要端口了吗? 答案是否定的, 在这里起作用的是缺省值.

比如你访问我的网站: xiaogd.net, 这个 url 中似乎没有端口, 但其实是有的, 它有一个默认值 443, 所以完整的形式实际是这样的:

xiaogd.net:443.

你可以通过 Chrome 的开发人员调试工具看到这一点:

可以看到, ip 地址后面跟着一个 443

如果你输入一个错误的端口, 比如 80, 像这样: xiaogd.net:80, 结果就是无法访问.

但是如果你改成 xiaogd.net:80, 它又可以访问了.

注意, 因为我服务器后台配置了 http 自动跳转 https 的 301 重定向, 所以最终浏览器会再次跳转到 xiaogd.net:443.
注意勾选 ‘Preserve log’ 以保留日志, 可以看到第一个 80 端口的请求会被响应一个 301 跳转, 并指示跳转目标, 也即是 Location 字段中的 https 请求, 浏览器接收此跳转指示并重新发起 https 请求, 也即是图中第二个 xiaogd.net 的请求. 所以地址栏最终还是会变成 https 的, 特此说明.

此时如果你输入 xiaogd.net:443, 它又不能访问了…

那么原因是什么呢? 你找到规律了没有?

注意一个是 http, 一个是 https.

注:HTTP的端口缺省值是80,HTTPS的端口缺省值是443

  • https://www.baidu.com:443/
  • http://www.baidu.com:80/

这两种方式都能正常访问百度,平时我们是省略端口号,而访问时浏览器会根据所用的协议为我们加上缺省端口,因此,端口不仅是必须的,而且还是必须正确的。

那为什么我们平时在访问百度的时候,只需要输入”百度”两个字就可以了呢?

那是开发者为用户考虑。把用户当成傻瓜和懒汉就对了,如果每次访问百度都需要加上https,.com,443这些信息,无疑增加了用户负担。

为什么一定需要端口?

为了实现网络进程通信,利用三元组(ip地址,传输层协议,端口)可以标识网络的进程,网络中的进程通信就可以利用这个标志与其它进程进行交互。

进程间通讯(IPC)

你在浏览器地址栏输入某个网站的域名, 然后回车, 就生成了一次请求, 然后服务器响应你的请求, 浏览器再把结果渲染出来, 你就能最终看到到一个网页。

如果你曾经 ping 过一个域名, 比如你现在 ping 我的域名 xiaogd.net, 你就能得到一个 ip 地址, 118.89.55.54:

有了 ip, 浏览器自然就能找到我的主机, 但还是有个问题, 我的主机上运行着好多的进程, 好多的服务, 除了最常见的 web 服务, 我可能还有 ftp 服务, mysql 服务等等不一而足.

简单地讲, 如果一个请求只有 ip 地址这一信息, 操作系统将不知道把这个请求交给哪个进程去处理, 如果是你来设计整个系统, 你想象一下, 是不是这样?

如果你仅仅是输入域名, 经过 DNS 解析后, 只能得到一个 IP 地址.

所谓的一次请求, 从一个比较底层的角度去看, 就是一次进程间的通讯.

它可以是 navicat 客户端与 mysql 数据库服务的一次通讯, 也可以是 winScp 客户端与 vsftpd FTP 服务的一次通讯等等.

以上面的具体为例, 可以说就是 Chrome 浏览器这个本地操作系统上的进程与我的服务器上的一个叫做 Nginx 的进程间的一次通讯.

那么, 所谓的端口, 其实可以简单地视作为进程 ID.

当然, 它与进程 ID 还是有不同的, 下面再分析, 或者目前你可以认为端口就是进程 ID 的影子.

也即是说, 如果仅有域名(ip), 是无法定位到一个进程的, 通讯的发起方不但需要给出 ip, 还需要给出端口, 只有这样, 服务器才能知道由哪个进程去响应。

注:输入域名,通过DNS解析,换取对应IP,通过IP地址可以找到目标主机,但无法得到具体要通信的进程,因此必须借助端口进行判断

端口, 一个间接层

那么问题又来了, 为什么引入端口, 而不是直接使用进程 ID 呢? 这个原因想想也不难明白, 大概有这么几点原因:

  1. 作为客户端无法知道服务端对应进程的 ID
  2. 服务端对应进程重启后 ID 会改变
  3. 一个网站的 web 进程 ID 是这个, 另一个网站的可能又是另一个

自然, 原因是很多的, 我也是随便的列举了一些, 你或许还能想到更多. 而为了解决这些个问题, 就引入了端口这一间接层(indirection).

计算机世界里有一句名言: 任何计算机问题均可通过增加一个间接(indirection)层来解决.(Any problem in computer science can be solved with another layer of indirection. — David Wheeler)
这个名言其实还有后面一句: But what usually will create another problem.(但通常会带来另一个问题)
这里所谓另一个问题, 比如它会使得层次结构复杂化, 交互效率下降等等. 当然了, 这就是架构师们要去权衡的问题了, 很多时候, 架构就是关于平衡的艺术. 打死都不肯引入任何的间接层, 这是一个极端; 而一上来就引入好多个间接层, 这又是另一个极端.

如果没有这个间接层, 客户端要与服务端通讯, 就要知道服务端对应进程的 ID, 也就是客户端是依赖于服务端的:

显然, 这种模式对于 web 这种一个服务端对应大量客户端访问的情形是极不适应的, 你都不知道有谁可能会来访问你的网站! 你根本无法告诉它们.

而有了端口这一间接层, 对于 web 的情形, 这种依赖被倒置了, 客户端总是把请求发送到 80(或443) 端口, 这些成为标准的一部分, 并要求服务端反过来去适应, 服务端去监听端口的通讯并处理, 变成了一种反向依赖.

如果一个进程想要提供 web 服务, 它启动之后就要去绑定(binding) web 相关的端口,

如果端口已经被其它进程绑定了(即所谓占用了), 就会绑定失败; 又或者被自身前一个未完全退出的进程占据着, 也会绑定失败, 在开发过程中你可能会遇到类似的问题, 一个 web 进程没有关闭, 你又试图启动另一个, 而两者都用了相同的端口, 就会产生冲突.

并在其上持续的监听(listen), 同时在有请求到来的时候去响应(response). 这样一来, 进程 ID 的问题就消解了:

这类似于一个接口回调, 浏览器只需要面向接口索取服务, 而无需知道接口服务的具体提供者, 这些细节被端口层所封装并隐藏起来了.端口这一间接层的存在解耦(decouple)了客户端与服务端之间的强依赖, 整个体系变得很灵活.

可以把端口视作一般编程概念中的接口(interface), 而像 Nginx, apache, tomcat 等等可以认为是这个接口的不同实现(Implementation).

注:如果使用PID来标识进程会产生关键问题——通信前服务端必须要告知客户端它所提供的服务的PID。这种方案显然不可行,因为服务端无法预知哪些客户端将连接它。同时,每次通信前服务端都要向客户端发送PID(因为PID是动态变化的),开销其实是很大的因此,我们应当将提供的服务门户固定,而PID是操作系统层面的,想要固定十分麻烦,于是引入端口的概念,且服务端提供服务的端口固定化,HTTP的服务就绑定在80端口上,HTTPS的服务就绑定在443端口上,IMPL邮件服务就绑定在143端口上。原本是客户端依赖于服务端,现在是服务端依赖于端口,即 依赖倒置。依赖倒置原则在Spring的IOC中也有体现,可以戳这里查看详情(42条消息) spring IOC详解(依赖倒置原则)_wang_nian的博客-CSDN博客_spring依赖倒置

端口与现实世界的一个类比

为加深理解, 可以举一个现实世界中的例子. 相信大家都有过去市民中心办事的经历, 比如去办理居住证, 护照, 社保等等业务, 你通常会收到一个小纸条让你去某个窗口办理对应业务, 这个窗口其实就类似于端口了:

比如 80 窗口就对应港澳台通行证业务

那么你要办港澳台通行证, 你就奔向 80 号窗口就完了. 你不要去问门口保卫处的王大爷, 到底是哪位同志办理这个业务.

今天可能是小明在办理, 隔了几天, 小明可能受伤了, 流血了, 又轮到小红在那里办理, 又过段时间, 小红也出意外了, 流产了, 又轮到小张在办理, 又过段时间, 小张被发现在办理业务过程中徇私舞弊, 流放了…

等等, 如果此时你的同事问你怎么办港澳台通行证, 你需要知道这些个人事变动的细节吗? 根本不需要呀, 你只需告诉他去 80 号窗口办理就好了…

市民中心的整个体系, 会确保有个会办理这些业务的人员坐在那个窗口下面, 你唯一需要做的, 就是到那个窗口下请求服务即可.

端口与名称服务(naming service)

通过上面现实世界类比的例子, 对于端口的机制, 相信你已经理解得比较深入了. 广义上讲, 端口层也可以视作一个 naming service(名称服务), 这与比如 spring cloud 中的 eureka 里的机制本质上是一样的, 只是这个 name 就是一个抽象的数字, 比如 80. 80 就代表了一个 web 服务, Nginx 之类的 web server 绑定并监听就相当于把自身提供的 web 服务注册于其上.

DNS 域名系统其实也是 naming service, 你通过 xiaogd.net 这个名字(name), 就能获取到我所提供给你的网页服务.
类似的还有 java 里的 JNDI 等, 把一个名字与一个服务关联起来, 比如一个名字就代表一个数据源(数据库连接)之类的.

端口与 IoC(控制反转)

广义上, 端口的上述机制也是控制反转(Ioc: Inversion of Control)思想的一种体现, 如果客户端需要知道服务端的进程 ID, 实际上就被服务端控制了, 毕竟我服务端在哪个 ID 上提供服务, 你就得把你的请求发到相应的 ID 上来;

而有了端口这一中间层呢? 作为客户端, 总是把请求发到对应端口上, 并要求服务端绑定并监听那些端口以及作出响应, 你服务端是反过来被我客户端所控制, 我客户端发到哪个端口, 你服务端就要去相应端口上监听并响应.

大家可以体会一下这种转变. 这种设计或思想在编程领域其实是特别重要的, 在很多其它地方都有体现.

因为浏览器总是把 web 请求发到了 80 或 443 端口, 这就要求一个 web server 进程去监听这些端口. 比如在我的服务器上, web server 是 Nginx, 它启动之后就会去监听 80 和 443 端口, 任何想要访问我的主页的人, 并不需要知道我的 Nginx 进程 ID 是啥, 借助于端口这一间接层, 你就能够与我的 Nginx 进程通讯, 并获取你想要的东西.

事实上你可以这么认为, 浏览器实际上只是在与端口通讯, 端口层再把这些请求委托(delegate)或代理(proxy)给相应的 web server 去处理, 端口的角色就是一个中间人, 一个间接层。

再论缺省端口

现在, 我们应该明白了, 端口是必要的了, 当然, 对最终的用户来说, 则不需要知道这些实现的细节, 对于他们, 应该遵循最小知识原则, 知道得越少越好.

如果你一定要让用户在输入 url 的过程中输入端口, 又或者要输入个 www 等等, 用户就要给你扔过来”十万个为什么”了…

为什么要加个 443?
为什么不是 334, 443是啥意思?
为什么一会儿是 80, 一会儿又是 443?
为什么加个 www, 啥意思?
为什么末尾还加个斜杠, 不加会死吗?

惹不起, 惹不起…

还记得前面说的, 用户是笨蛋, 用户是懒汉吗?

这里又要引用一句计算机世界的名言了: 程序员和上帝打赌要开发出更大更好连傻瓜都会用的软件, 而上帝却总能创造出更大更傻的傻瓜。目前为止,上帝赢了。
Programmers are in a race with the Universe to create bigger and better idiot-proof programs. The Universe is trying to create bigger and better idiots. So far the Universe is winning.

说句心里话, 很多时候, 用户能记住你的域名就阿弥陀佛了, 你就该烧高香了, 你还想用户记住你的端口, 真的想多了…

另一方面, 说到这里我们应该也能明白了, 那就是理论上, web 服务实际上可以构建在任何端口之上. 比如在本地开发的时候, 用户只有你自己, 那当然你可以随便挑一个端口, 比如 8080, 只要自己知道就好了或顶多告诉另一个与你配合的前端同事.

同理, 其它非 web 的服务, 比如 ftp 服务, 也不一定说非得在 21 端口上等等; mysql 服务的端口同样可以调整为 3306 之外的端口.

又或者说, 你想提供一个服务, 但只想小范围内的人知道, 你可以挑一个很偏门的端口, 这样一般人只输一个域名就没法访问到你的服务了.

比如有人想偷偷提供一些服务, 放一些广大淫民群众喜闻乐见的小视频啥的…刑法警告, 后果自负!! 别说我没有提醒你.

端口与 TCP/UDP 协议

前面一直在说, 什么 3306 端口, 80 端口, 443 端口, 其实严格来说, 端口是分 TCP 端口和 UDP 端口的, 不过多数时候遇到的都是 TCP 端口, 但 TCP 80 端口和 UDP 80 端口是不同的端口.

UDP 的 80 端口, 包括 443 端口其实被保留了, 目前的 http 协议只构建在 TCP 协议之上.
当然, 理论上讲, 在 UDP 上构建 http 也不能说就完全不行, 毕竟, 无论 UDP 还是 TCP 都是构建在 IP 协议之上, 总之呢, 计算机的世界没什么是不可能的, 而且似乎真有人在做这些尝试, 不过这就属于两小母牛对屁股–比较牛逼的范畴了, 深水区了, 咱也不懂, 不多说了.

还有一点, 对于进程间的端口通讯, 实际上是对称的, 也即是说, 服务器的响应也是先回到一个客户端的端口上.

如果你用 Windows 10 系统, 可以在 任务管理器 > 性能 > 打开资源监视器 > 网络 > TCP 连接, 点击下远程端口可以按照从小到大排列, 通常就可以看到 443 的相关连接了, 可以看到左边有一栏本地端口, 一个 TCP 连接总是有一个远程端口, 一个本地端口:

当发起一个 TCP 连接时, 客户端首先自己先随机挑选一个没有被使用的端口作为服务器响应的接收端口, 比如 38672. 在一个 TCP 的包里, 无论是握手包还是后续的数据包, 包头部分最重要的两个字段, 一个就是源端口(source port), 比如 38672; 另一个就是目标端口(destination port), 比如 80, 或者 443.

可以这样看, 服务器的响应也是先回到源端口, 比如 38672 上, 源端口再转给最终的进程, 比如浏览器.

而对于一个 IP 包, 同样的, 包头部分最重要的两个字段, 一个就是源IP(source IP); 另一个就是目标 IP(destination IP).

而 TCP 包会作为 IP 包的数据包被打包到 IP 包里面, 也就是说一个 IP 包里其实包含了 IP + 端口.

IP 加端口再加上端口与进程间的关联, 分属两个不同主机间的进程就能通过 TCP(UDP)/IP 协议愉快地进行进程间的通讯(IPC)了.

当然了, 同一个主机间的进程也同样可以利用这套机制. 但同一个主机间还可以有其它选择, 这个具体看各个操作系统是否提供相关机制及支持. 而 TCP/IP 属于广泛应用的标准协议, 从而得到了广泛支持.

0 53

在学习计算机网络协议的时候,出现过HTTP无状态的介绍,但当时只是简单的理解为服务器与客户端的第二次会话无法辨别。

即,第一次会话,C — S;第二次会话,S无法分别C还是不是第一次的那个C

 

但我个人感觉这样的理解可能会有偏差,因此查阅资料,进行整理

且看案例:

https://www.zhihu.com/question/23202402/answer/515842304

另外一个维度的分析:

https://www.zhihu.com/question/23202402/answer/527748675

 

摘要:

作者:灵剑
链接:https://www.zhihu.com/question/23202402/answer/527748675
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

HTTP所谓的“无状态协议”,其实跟Cookies、Session这些都没有什么大的联系,它描述的主要是通信协议层面的问题

常见的许多七层协议实际上是有状态的,例如SMTP协议,它的第一条消息必须是HELO,用来握手,在HELO发送之前其他任何命令都是不能发送的;接下来一般要进行AUTH阶段,用来验证用户名和密码;接下来可以发送邮件数据;最后,通过QUIT命令退出。可以看到,在整个传输层上,通信的双方是必须要时刻记住当前连接的状态的,因为不同的状态下能接受的命令是不同的;另外,之前的命令传输的某些数据也必须要记住,可能会对后面的命令产生影响。这种就叫做有状态的协议。(1.连接的状态要记住 2.之前发送的命令要记住)

相反,什么说HTTP是无状态的协议呢?因为它的每个请求都是完全独立的,每个请求包含了处理这个请求所需的完整的数据,发送请求不涉及到状态变更。(对应上述的有状态的协议,即首先连接不分阶段,连接上了就连上了,其次就是不需要记住之前的命令,因为每个请求包含了所有的信息)即使在HTTP/1.1上同一个连接允许传输多个HTTP请求的情况下,如果第一个请求出错了,后面的请求一般也能够继续处理(当然,如果导致协议解析失败、消息分片错误之类的自然是要除外的)可以看出,这种协议的结构是要比有状态的协议更简单的,一般来说实现起来也更简单,不需要使用状态机,一个循环就行了——不过,HTTP本身很复杂,这是另一个故事了,这里暂时不提。

无状态的协议有一些优点,也有一些缺点。

和许多人想象的不同,会话(Session)支持其实并不是一个缺点,反而是无状态协议的优点,因为对于有状态协议来说,如果将会话状态与连接绑定在一起,那么如果连接意外断开,整个会话就会丢失,重新连接之后一般需要从头开始(当然这也可以通过吸收无状态协议的某些特点进行改进);而HTTP这样的无状态协议,使用元数据(如Cookies头)来维护会话,使得会话与连接本身独立起来,这样即使连接断开了,会话状态也不会受到严重伤害,保持会话也不需要保持连接本身。另外,无状态的优点还在于对中间件友好,中间件无需完全理解通信双方的交互过程,只需要能正确分片消息即可,而且中间件可以很方便地将消息在不同的连接上传输而不影响正确性,这就方便了负载均衡等组件的设计。

无状态协议的主要缺点在于,单个请求需要的所有信息都必须要包含在请求中一次发送到服务端,这导致单个消息的结构需要比较复杂,必须能够支持大量元数据,因此HTTP消息的解析要比其他许多协议都要复杂得多。同时,这也导致了相同的数据在多个请求上往往需要反复传输,例如同一个连接上的每个请求都需要传输Host、Authentication、Cookies、Server等往往是完全重复的元数据,一定程度上降低了协议的效率。(缺点是请求更复杂,占用的空间更多,效率更低)

协议的状态是指下一次传输数据的时候能考虑到这次传输信息的状态。也有是说有状态协议以前的请求导致协议所处的状态会影响后续的状态,协议会根据上一个状态创建上下文。
http协议里就是无状态协议不用考虑上下文;每个请求都是与服务器的独立连接,即下一次请求到来的时候协议不用维护这次请求中客户机-服务器间交互的信息。

最近系统的学习了网络编程的相关知识,当然也离不开Tcp这位重量级,而自己手里写的这个项目 基于Bio的聊天室 其本质也是消息的传递,最接近Tcp的实现原理,因此根据对Tcp的学习,引出本人对自己项目的思考。

起因是我考虑将该聊天室做的可靠,健壮,同时往消息队列的模型上靠拢,因此,必须考虑从客户端发往服务器端的消息的可靠性和安全性。

 

我们知道,基于Tcp实现的Socket编程,其本质就是Socket连接 = Tcp 连接,所以很多原本考虑在Socket层面实现的保证安全性和可靠性的机制其实Tcp已经实现了,Tcp具有以下机制:

保证可靠性的机制

  • 校验和
  • 序列号(按序到达)
  • 确认应答
  • 超时重传
  • 连接管理
  • 流量控制
  • 拥塞控制

提高性能的机制

  • 滑动窗口
  • 快速重传
  • 延迟应答
  • 捎带应答

 

 

针对这些机制,仔细梳理我所写的项目的实现

连接和断开

由于是基于Tcp实现的Socket编程,因此不用考虑连接和正常断开的问题(Tcp的三次握手和四次挥手)

但是如果已经建立了连接,而客户端突然故障,这种情况下开启Tcp的保活计时器,修改其参数,即开启其心跳机制,同时为了避免其Bug(详情可搜索另一篇博文),我在应用层实现了心跳机制,可以保证客户端突发故障,服务器端能快速知晓并关闭连接。

而服务器端突然故障,则没关系,因为客户端是在向服务器端写入的,比如 客户端发送消息 哈哈哈哈 成功(这个成功会有个显示,类似于QQ消息的已发送状态),而无论是在客户端下次发送之前还是发送中与服务器连接失败,客户端都会立即收到通知,即客户端显示 未发送成功 ,这样客户端就可以采取下一步动作了(采取什么动作需要再进行设计 例如重新连接 重传 等等)

 

消息确认的必要性

昨晚我思考了几个问题,在客户端发送消息给服务器端的过程中,可能出现以下几种情况:

消息还未发送

  1. 客户端刚准备发送消息,服务器端挂了,这个时候因为会抛出异常,客户端就知晓这条消息发不出去了,因此这条消息不会丢失也不会出错(丢失起码要先发出去)

消息已经在发送过程中

  1. 客户端的这条消息在传递过程中,服务器端挂了,也会抛出异常,但是客户端不知道这条消息是否发送成功(因为有可能服务器已经收到了才挂,也有可能是服务器端没收到就挂了),只知道服务器端挂了,而客户端此时不知道是否应该重发,导致迷茫

上述分析情况单纯的考虑了服务器端对消息的接收情况,而服务器端收到消息后,可能还有一些其他操作,例如转发,存储,加工等等,因此必须同时考虑服务器对消息的处理情况(建立在服务器端成功收到消息的基础上)

服务器端成功接收消息,但在对消息进行加工,转发,存储的时候,不管是成功还是失败,这个结果对客户端是不可知的,因为目前客户端只会对 “客户端和服务器端的连接中断或失败”这个事件作出反应,也就是抛出异常;这样肯定不行啊,我客户端一头雾水,一问三不知,不知道我的消息发送出去没,不知道服务器端收到消息没,不知道服务器端成功处理消息没。很显然,解决这个问题就是让客户端了解所发消息的状态

消息状态粗略的可分为:

  1. 未发送出去
  2. 服务器端成功接收了该消息但处理失败
  3. 服务器端成功处理了该消息

而确认应答就可以让客户端知道消息的状态,从而进行其他操作。

 

TCP的确认应答机制(ACK机制) 

 

TCP将每个字节的数据都进行了编号, 即为序列号.

每一个ACK都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据; 下一次你要从哪里开始发.
比如, 客户端向服务器发送了1005字节的数据, 服务器返回给客户端的确认序号是1003, 那么说明服务器只收到了1-1002的数据.
1003, 1004, 1005都没收到.
此时客户端就会从1003开始重发.

 

既然有了TCP的确认应答(ACK机制),为什么还需要我们在应用层实现应答机制?

我理解的是,TCP的确认应答确认的范围是在一条消息内,它对每个字节的数据进行标号,比如一条消息如果占300个字节,那么它可以确保这300个字节的消息中,如果有丢失的,可以重发

例如:这一条消息占300个字节,由于网络阻塞或其他原因,只发送了158个字节,那么服务器端的ACK只会回应159,这样的话客户端就会从159开始重发,确保这一条消息完全发送。

理解了TCP应答机制的实现,那么我们就知道了TCP的确认应答并不能解决我们上述所需要的 让客户端了解所发消息的状态,因此还需要我们在应用层实现应答机制。

 

应用层实现应答机制

那么如何设计该应用层的应答机制呢?首先需要区分消息状态是从客户端本身还是从服务器端来进行反馈

消息状态由客户端本身进行反馈(ACK)

从客户端A发送消息到该消息在网上进行传输之前,如果服务器端连接断开或客户端本身的原因,已经无法写入,则反馈 未发送成功

类似于QQ发送消息,结果本地网络已经中断了,会反馈发送失败,这个状态由客户端自身反馈。

消息状态由服务器端进行反馈(ACK)

客户端A发送消息后,由于网络拥堵等原因,消息无法到达服务器端B,因为服务器端根本没收到消息,则无法回应,而客户端本身也无法反馈该消息状态,这种情况必须在客户端使用超时重传策略进行解决;(问题一:消息在客户端发给服务器端的过程中丢失)

客户端A发送消息后,服务器端成功接收,但是在处理的时候失败了,这个时候需要由服务器端向客户端反馈状态,同样的,如果处理成功也需要反馈,也就是说服务器端只向客户端反馈对消息进行处理之后的状态;那么此处必须要考虑到的就是 由客户端本身进行反馈还好,该反馈一般不会丢失,但是由服务器端进行的反馈是有可能丢失的,如果这个ACK丢失了,客户端就还是不知道该消息的状态 因此 仅仅有确认应答机制是不够的。(问题二:ACK在服务器端发向客户端的途中丢失)

TCP则是使用超时重传机制来解决 消息在客户端发给服务器端的过程中丢失 和 ACK丢失 两个问题的

 

TCP超时重传机制

 

主机A发送数据给B之后, 可能因为网络拥堵等原因, 数据无法到达主机B
如果主机A在一个特定时间间隔内没有收到B发来的确认应答, 就会进行重发
但是主机A没收到确认应答也可能是ACK丢失了.

这种情况下, 主机B会收到很多重复数据.
那么TCP协议需要识别出哪些包是重复的, 并且把重复的丢弃.
这时候利用前面提到的序列号, 就可以很容易做到去重.

 

既然有了TCP的超时重传,为什么还需要应用层实现超时重传?

还是一个范围问题,TCP解决的是字节层面(或者称之为数据包层面的问题)而应用层则解决的是所发送的消息层面的问题

 

应用层实现超时重传

客户端A发送消息,服务器端接收并处理消息,反馈消息状态给客户端A,这是消息确认应答的流程

在这个流程中,如果确认应答过程中ACK丢失,则使用超时重传的策略来解决;

具体来说就是:

客户端A发送消息给服务器端,可能因为网络拥堵,数据无法到达服务器端(即消息在发送过程中,服务器端还没接收到消息就丢失了),在客户端A使用超时重传机制,如果客户端A在一个特定的时间间隔内没有收到服务器端发来的确认应答, 就进行重发;

发生超时重传的情景有两个:

  1. 第一个就是客户端消息在发送过程中丢失,
  2. 第二个就是来自服务器端的ACK丢失;

第一种情景还好,可是第二种情景,服务器端已经收到了该消息,客户端进行超时重传势必会导致服务器端收到许多重复消息;

那么必须在服务器端进行消息去重,由TCP的超时重传引出

关于消息去重我们可以用以下做法

每条发送的消息有一个唯一的序列号,在服务器端收到一条消息后,会先比较该ID表示是否存在,存在则表示该消息在服务器里面了,反馈客户端就好,不需要再对这条重复的消息进行太多操作

那么超时时间如何确定呢?

最理想的情况下, 找到一个最小的时间, 保证 “确认应答一定能在这个时间内返回”.
但是这个时间的长短, 随着网络环境的不同, 是有差异的.
如果超时时间设的太长, 会影响整体的重传效率; 如果超时时间设的太短, 有可能会频繁发送重复的包.

TCP为了保证任何环境下都能保持较高性能的通信, 因此会动态计算这个最大超时时间.

Linux中(BSD Unix和Windows也是如此), 超时以500ms为一个单位进行控制, 每次判定超时重发的超时时间都是500ms的整数倍.
如果重发一次之后, 仍然得不到应答, 等待 2*500ms 后再进行重传. 如果仍然得不到应答, 等待 4*500ms 进行重传.
依次类推, 以指数形式递增. 累计到一定的重传次数, TCP认为网络异常或者对端主机出现异常, 强制关闭连接.

到此,我们来回顾一下,我们为了让客户端了解它所发送的消息的状态并根据状态进行其他操作,使用了确认应答机制,而确认应答机制无法解决两个问题(ACK丢失和消息在发送的时候丢失),为了解决和完善确认应答机制,我们使用了超时重传机制,而超时重传在ack丢失的情况下会导致服务器端收到重复消息,我们又使用最开始设计的传递的消息的唯一序列号来进行去重,环环相扣,确保了消息从客户端传递到服务器端的可靠性。

 

 

参考:https://blog.csdn.net/sinat_36629696/article/details/80740678

在完成自己的Bio项目时,考虑到了心跳检测,有必要整理相关知识,特此记录

什么是掉线?

一. 从程序的角度看待TCP掉线

       TCP掉线的原因多种多样、不一而足,比如,客人的电脑突然断电、OS崩溃、路由器重启、网线接触不良、因为P2P下载软件而导致网络资源短缺、Internet网络的不稳定等等,但是从程序的角度来说,我们可以总结为两种情况:程序能立即感知的掉线和程序不能立即感知的掉线。

1. 程序能立即感知的掉线

       也就是说客户端一掉线,服务器端的某个读写对应的TCP连接的线程就会抛出异常,这种情况相对容易处理。

2. 程序不能立即感知的掉线(https://blog.csdn.net/kkkkkxiaofei/article/details/12966407?spm=1001.2101.3001.6650.5&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7Edefault-5.essearch_pc_relevant&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7Edefault-5.essearch_pc_relevant

  我们都知道,TCP连接的建立,需要经过三次握手;而TCP连接的断开,需要经过四次挥手。掉线通常没什么大不了的,掉就掉了呗,只要四次挥手顺利完成后,服务器和客户端分别做一些善后处理就可以。

       麻烦的事情在于,连接在没有机会完成4次挥手时已经断开了(比如当客人的电脑系统死机,或客人电脑与服务器之间的某处物理网线断开),而服务端以为客户端还正常在线,而客户端也自以为还正常在线。这种程序对现实状态的错误判断有可能引发诸多悲剧。比如,在此情况下,客户端发一个指令给服务器,服务器因为没有收到而一直处于等待指令的状态;而客户端了,以为服务器已经收到了,也就一直处于等待服务端回复的状态。如果程序的其它部分需要依据当前的状态来做后续的操作,那就可能会出问题,因为程序对当前连接状态的判断是错误的。

       毫无疑问,这种对连接状态错误的判断所持续的时间越久,带来可能的危害就越大。当然,如果我们不做任何额外的处理措施,服务器到最后也能感受到客户端的掉线,但是,这个时间可能已经过去了几分钟甚至几十分钟。对于大多数应用来说,这是不可忍受的。 所以,针对这种不能立即感知掉线的情况,我们要做的补救措施,就是帮助程序尽快地获知tcp连接已断开的信息。

      首先,我们可以在Socket上通过Socket.IOControl方法设置KeepAliveValues,来控制底层TCP的保活机制,比如,设定2秒钟检测一次,超过10秒检测失败时抛出异常。  

       据我们的经验,这种设定可以解决一部分问题,但是仍然会有一些连接在断开后,远远超过10秒才被感知掉。所以,这个补救措施还是远远不够的。我们还需要在应用层加入我们自己的TCP连接状态检测机制,这种机制就是通常所说的“心跳”。

 

使用socket.isConnected()或者socket.isClosed()等方法来判断Socket的实时状态的问题

https://blog.csdn.net/cshichao/article/details/8900446

很多人会说用socket.isConnected()或者socket.isClosed()等方法来判断就行了,但事实上这些方法都是访问socket在内存驻留的状态,当socket和服务器端建立链接后,即使socket链接断掉了,调用上面的方法返回的仍然是链接时的状态,而不是socket的实时链接状态

什么是心跳检测?(https://www.cnblogs.com/havenshen/p/3850167.html)

简单来说就是 客户端和服务器端建立连接后,有一段时间没有相互发送消息,这个时候为了知道对方是否还存活,发送心跳数据,看能否发送成功或对方有无回应,再根据结果执行其他的逻辑(例如重新建立连接)

通过什么实现心跳检测?

底层实现是:keepAlive对TCP连接进行设置

keep alive三个参数:

sk->keepalive_probes:探测次数
sk->keepalive_time 探测的超时
sk->keepalive_intvl 探测间隔

对 于一个已经建立的tcp连接。如果在keepalive_time时间内双方没有任何的数据包传输,则开启keepalive功能的一端将发送 keepalive数据包,若没有收到应答,则每隔keepalive_intvl时间再发送该数据包,发送keepalive_probes次。一直没有 收到应答,则发送rst包关闭连接。若收到应答,则将计时器清零。

 

那如何开启keepalive功能呢?

重点:通过Socket设置keepalive参数,开启keepalive方式来实现;

欸 不是说tcp的keepalive吗?怎么又提到Socket了?(简单来说就是Socket的数据传输方式可以是UDP也可以是TCP)

这就要说到Socket的本质:我们知道网络中进程间通信是利用三元组【ip地址,协议,端口】来实现的,而Socket就是一种技术 或者称之为 网络间通信的中间件工具,并且基本上现在所有的应用程序都采用Socket来进行通信。而Socket这种通信的数据传输方式有两种:

    a、SOCK_STREAM(TCP):表示面向连接的数据传输方式。数据可以准确无误地到达另一台计算机,如果损坏或丢失,可以重新发送,但效率相对较慢。常见的 http 协议就使用 SOCK_STREAM 传输数据,因为要确保数据的正确性,否则网页不能正常解析。
  b、SOCK_DGRAM(UDP):表示无连接的数据传输方式。计算机只管传输数据,不作数据校验,如果数据在传输中损坏,或者没有到达另一台计算机,是没有办法补救的。也就是说,数据错了就错了,无法重传。因为 SOCK_DGRAM 所做的校验工作少,所以效率比 SOCK_STREAM 高。
也就是说Socket可以通过TCP的数据传输方式实现,也可以通过UDP的数据传输方式实现。前面说了目前所有的应用程序都采用Socket来通信,那么当然,许许多多的语言也支持Socket的使用,接下来就看看在Java中Socket的使用吧~
TCP:
UDP:
因此 回到前面,Socket实现心跳,直接在客户端调用Socket.setKeepalive(true)方法即可(Java语言中)。

那么对于Java中的Socket的Keepalive 我们如何理解呢?

ava socket编程中有个keepalive选项,看到这个选项经常会误解为长连接,不设置则为短连接,实则不然。

socket连接建立之后,只要双方均未主动关闭连接,那这个连接就是会一直保持的,就是持久的连接。keepalive只是为了防止连接的双方发生意外而通知不到对方,导致一方还持有连接,占用资源。

其实这个选项的意思是TCP连接空闲时是否需要向对方发送探测包,实际上是依赖于底层的TCP模块实现的,java中只能设置是否开启,不能设置其详细参数,只能依赖于系统配置。

首先看看源码里面是怎么说的

源码的意思是,如果这个连接上双方任意方向在2小时之内没有发送过数据,那么tcp会自动发送一个探测探测包给对方,这种探测包对方是必须回应的,回应结果有三种:

1.正常ack,继续保持连接;

2.对方响应rst信号,双方重新连接。

3.对方无响应。

这里说的两小时,其实是依赖于系统配置,在linux系统中(windows在注册表中,可以自行查询资料),tcp的keepalive参数

net.ipv4.tcp_keepalive_intvl = 75 (发送探测包的周期,前提是当前连接一直没有数据交互,才会以该频率进行发送探测包,如果中途有数据交互,则会重新计时tcp_keepalive_time,到达规定时间没有数据交互,才会重新以该频率发送探测包)
net.ipv4.tcp_keepalive_probes = 9  (探测失败的重试次数,发送探测包达次数限制对方依旧没有回应,则关闭自己这端的连接)
net.ipv4.tcp_keepalive_time = 7200 (空闲多长时间,则发送探测包)

为了能验证所说的,我们来进行测试一下,本人测试环境是客户端在本地windows上,服务端是在远程linux上,主要测试服务器端向客户端发送探测包(客户端向服务端发送是一样的原理)。

验证链接:https://www.cnblogs.com/xiao-tao/p/9718017.html

 

为什么需要自己在应用层实现Keepalive?

上述只是从TCP底层角度来实现了Keepalive心跳功能,但实际上它是存在Bug的,即:正常情况下,连接的另一端主动调用colse关闭连接,tcp会通知,我们知道了该连接已经关闭。但是如果tcp连接的另一端突然掉线,或者重启断电,这个时候我们并不知道网络已经关闭。而此时,如果有发送数据失败,tcp会自动进行重传。重传包的优先级高于keepalive,那就意味着,我们的keepalive总是不能发送出去。 而此时,我们也并不知道该连接已经出错而中断。在较长时间的重传失败之后,我们才会知道。

 

为了避免这种情况发生,我们要在tcp上层,自行控制。对于此消息,记录发送时间和收到回应的时间。如果长时间没有回应,就可能是网络中断。如果长时间没有发送,就是说,长时间没有进行通信,可以自行发一个包,用于keepalive,以保持该连接的存在。

0 101

本文是我在大二学习计算机网络期间整理, 大部分内容都来自于谢希仁老师的《计算机网络》这本书。

为了内容更容易理解,我对之前的整理进行了一波重构,并配上了一些相关的示意图便于理解。

1. 计算机网络概述

1.1. 基本术语

  1. 结点 (node) :网络中的结点可以是计算机,集线器,交换机或路由器等。
  2. 链路(link ) : 从一个结点到另一个结点的一段物理线路。中间没有任何其他交点。
  3. 主机(host) :连接在因特网上的计算机。
  4. ISP(Internet Service Provider) :因特网服务提供者(提供商)。

ISP (Internet Service Provider) Definition

  1. IXP(Internet eXchange Point) : 互联网交换点 IXP 的主要作用就是允许两个网络直接相连并交换分组,而不需要再通过第三个网络来转发分组。

IXP Traffic Levels During the Stratos Skydive — RIPE Labs

https://labs.ripe.net/Members/fergalc/ixp-traffic-during-stratos-skydive

  1. RFC(Request For Comments) :意思是“请求评议”,包含了关于 Internet 几乎所有的重要的文字资料。
  2. 广域网 WAN(Wide Area Network) :任务是通过长距离运送主机发送的数据。
  3. 城域网 MAN(Metropolitan Area Network):用来将多个局域网进行互连。
  4. 局域网 LAN(Local Area Network) : 学校或企业大多拥有多个互连的局域网。

MAN & WMAN | Red de área metropolitana, Redes informaticas, Par trenzado

http://conexionesmanwman.blogspot.com/

  1. 个人区域网 PAN(Personal Area Network) :在个人工作的地方把属于个人使用的电子设备用无线技术连接起来的网络 。

Advantages and disadvantages of personal area network (PAN) - IT Release

https://www.itrelease.com/2018/07/advantages-and-disadvantages-of-personal-area-network-pan/

  1. 分组(packet ) :因特网中传送的数据单元。由首部 header 和数据段组成。分组又称为包,首部可称为包头。
  2. 存储转发(store and forward ) :路由器收到一个分组,先检查分组是否正确,并过滤掉冲突包错误。确定包正确后,取出目的地址,通过查找表找到想要发送的输出端口地址,然后将该包发送出去。

  1. 带宽(bandwidth) :在计算机网络中,表示在单位时间内从网络中的某一点到另一点所能通过的“最高数据率”。常用来表示网络的通信线路所能传送数据的能力。单位是“比特每秒”,记为 b/s。
  2. 吞吐量(throughput ) :表示在单位时间内通过某个网络(或信道、接口)的数据量。吞吐量更经常地用于对现实世界中的网络的一种测量,以便知道实际上到底有多少数据量能够通过网络。吞吐量受网络的带宽或网络的额定速率的限制。

1.2. 重要知识点总结

  1. 计算机网络(简称网络)把许多计算机连接在一起,而互联网把许多网络连接在一起,是网络的网络。
  2. 小写字母 i 开头的 internet(互联网)是通用名词,它泛指由多个计算机网络相互连接而成的网络。在这些网络之间的通信协议(即通信规则)可以是任意的。大写字母 I 开头的 Internet(互联网)是专用名词,它指全球最大的,开放的,由众多网络相互连接而成的特定的互联网,并采用 TCP/IP 协议作为通信规则,其前身为 ARPANET。Internet 的推荐译名为因特网,现在一般流行称为互联网。
  3. 路由器是实现分组交换的关键构件,其任务是转发收到的分组,这是网络核心部分最重要的功能。分组交换采用存储转发技术,表示把一个报文(要发送的整块数据)分为几个分组后再进行传送。在发送报文之前,先把较长的报文划分成为一个个更小的等长数据段。在每个数据端的前面加上一些由必要的控制信息组成的首部后,就构成了一个分组。分组又称为包。分组是在互联网中传送的数据单元,正是由于分组的头部包含了诸如目的地址和源地址等重要控制信息,每一个分组才能在互联网中独立的选择传输路径,并正确地交付到分组传输的终点。
  4. 互联网按工作方式可划分为边缘部分和核心部分。主机在网络的边缘部分,其作用是进行信息处理。由大量网络和连接这些网络的路由器组成核心部分,其作用是提供连通性和交换。
  5. 计算机通信是计算机中进程(即运行着的程序)之间的通信。计算机网络采用的通信方式是客户-服务器方式(C/S 方式)和对等连接方式(P2P 方式)。
  6. 客户和服务器都是指通信中所涉及的应用进程。客户是服务请求方,服务器是服务提供方。
  7. 按照作用范围的不同,计算机网络分为广域网 WAN,城域网 MAN,局域网 LAN,个人区域网 PAN。
  8. 计算机网络最常用的性能指标是:速率,带宽,吞吐量,时延(发送时延,处理时延,排队时延),时延带宽积,往返时间和信道利用率。
  9. 网络协议即协议,是为进行网络中的数据交换而建立的规则。计算机网络的各层以及其协议集合,称为网络的体系结构。
  10. 五层体系结构由应用层,运输层,网络层(网际层),数据链路层,物理层组成。运输层最主要的协议是 TCP 和 UDP 协议,网络层最重要的协议是 IP 协议。

s

下面的内容会介绍计算机网络的五层体系结构:物理层+数据链路层+网络层(网际层)+运输层+应用层

2. 物理层(Physical Layer)

物理层

2.1. 基本术语

  1. 数据(data) :运送消息的实体。
  2. 信号(signal) :数据的电气的或电磁的表现。或者说信号是适合在传输介质上传输的对象。
  3. 码元( code) :在使用时间域(或简称为时域)的波形来表示数字信号时,代表不同离散数值的基本波形。
  4. 单工(simplex ) : 只能有一个方向的通信而没有反方向的交互。
  5. 半双工(half duplex ) :通信的双方都可以发送信息,但不能双方同时发送(当然也就不能同时接收)。
  6. 全双工(full duplex) : 通信的双方可以同时发送和接收信息。

  1. 失真:失去真实性,主要是指接受到的信号和发送的信号不同,有磨损和衰减。影响失真程度的因素:1.码元传输速率 2.信号传输距离 3.噪声干扰 4.传输媒体质量

  1. 奈氏准则 : 在任何信道中,码元的传输的效率是有上限的,传输速率超过此上限,就会出现严重的码间串扰问题,使接收端对码元的判决(即识别)成为不可能。
  2. 香农定理 :在带宽受限且有噪声的信道中,为了不产生误差,信息的数据传输速率有上限值。
  3. 基带信号(baseband signal) : 来自信源的信号。指没有经过调制的数字信号或模拟信号。
  4. 带通(频带)信号(bandpass signal) :把基带信号经过载波调制后,把信号的频率范围搬移到较高的频段以便在信道中传输(即仅在一段频率范围内能够通过信道),这里调制过后的信号就是带通信号。
  5. 调制(modulation ) : 对信号源的信息进行处理后加到载波信号上,使其变为适合在信道传输的形式的过程。
  6. 信噪比(signal-to-noise ratio ) : 指信号的平均功率和噪声的平均功率之比,记为 S/N。信噪比(dB)=10*log10(S/N)。
  7. 信道复用(channel multiplexing ) :指多个用户共享同一个信道。(并不一定是同时)。

信道复用技术

  1. 比特率(bit rate ) :单位时间(每秒)内传送的比特数。
  2. 波特率(baud rate) :单位时间载波调制状态改变的次数。针对数据信号对载波的调制速率。
  3. 复用(multiplexing) :共享信道的方法。
  4. ADSL(Asymmetric Digital Subscriber Line ) :非对称数字用户线。
  5. 光纤同轴混合网(HFC 网) :在目前覆盖范围很广的有线电视网的基础上开发的一种居民宽带接入网

2.2. 重要知识点总结

  1. 物理层的主要任务就是确定与传输媒体接口有关的一些特性,如机械特性,电气特性,功能特性,过程特性。
  2. 一个数据通信系统可划分为三大部分,即源系统,传输系统,目的系统。源系统包括源点(或源站,信源)和发送器,目的系统包括接收器和终点。
  3. 通信的目的是传送消息。如话音,文字,图像等都是消息,数据是运送消息的实体。信号则是数据的电器或电磁的表现。
  4. 根据信号中代表消息的参数的取值方式不同,信号可分为模拟信号(或连续信号)和数字信号(或离散信号)。在使用时间域(简称时域)的波形表示数字信号时,代表不同离散数值的基本波形称为码元。
  5. 根据双方信息交互的方式,通信可划分为单向通信(或单工通信),双向交替通信(或半双工通信),双向同时通信(全双工通信)。
  6. 来自信源的信号称为基带信号。信号要在信道上传输就要经过调制。调制有基带调制和带通调制之分。最基本的带通调制方法有调幅,调频和调相。还有更复杂的调制方法,如正交振幅调制。
  7. 要提高数据在信道上的传递速率,可以使用更好的传输媒体,或使用先进的调制技术。但数据传输速率不可能任意被提高。
  8. 传输媒体可分为两大类,即导引型传输媒体(双绞线,同轴电缆,光纤)和非导引型传输媒体(无线,红外,大气激光)。
  9. 了有效利用光纤资源,在光纤干线和用户之间广泛使用无源光网络 PON。无源光网络无需配备电源,其长期运营成本和管理成本都很低。最流行的无源光网络是以太网无源光网络 EPON 和吉比特无源光网络 GPON。

2.3. 补充

2.3.1. 物理层主要做啥?

物理层主要做的事情就是 透明地传送比特流。也可以将物理层的主要任务描述为确定与传输媒体的接口的一些特性,即:机械特性(接口所用接线器的一些物理属性如形状尺寸),电气特性(接口电缆的各条线上出现的电压的范围),功能特性(某条线上出现的某一电平的电压的意义),过程特性(对于不同功能能的各种可能事件的出现顺序)。

物理层考虑的是怎样才能在连接各种计算机的传输媒体上传输数据比特流,而不是指具体的传输媒体。 现有的计算机网络中的硬件设备和传输媒体的种类非常繁多,而且通信手段也有许多不同的方式。物理层的作用正是尽可能地屏蔽掉这些传输媒体和通信手段的差异,使物理层上面的数据链路层感觉不到这些差异,这样就可以使数据链路层只考虑完成本层的协议和服务,而不必考虑网络的具体传输媒体和通信手段是什么。

2.3.2. 几种常用的信道复用技术

  1. 频分复用(FDM) :所有用户在同样的时间占用不同的带宽资源。
  2. 时分复用(TDM) :所有用户在不同的时间占用同样的频带宽度(分时不分频)。
  3. 统计时分复用 (Statistic TDM) :改进的时分复用,能够明显提高信道的利用率。
  4. 码分复用(CDM) : 用户使用经过特殊挑选的不同码型,因此各用户之间不会造成干扰。这种系统发送的信号有很强的抗干扰能力,其频谱类似于白噪声,不易被敌人发现。
  5. 波分复用( WDM) :波分复用就是光的频分复用。

2.3.3. 几种常用的宽带接入技术,主要是 ADSL 和 FTTx

用户到互联网的宽带接入方法有非对称数字用户线 ADSL(用数字技术对现有的模拟电话线进行改造,而不需要重新布线。ASDL 的快速版本是甚高速数字用户线 VDSL。),光纤同轴混合网 HFC(是在目前覆盖范围很广的有线电视网的基础上开发的一种居民宽带接入网)和 FTTx(即光纤到······)。

3. 数据链路层(Data Link Layer)

数据链路层

3.1. 基本术语

  1. 链路(link) :一个结点到相邻结点的一段物理链路。
  2. 数据链路(data link) :把实现控制数据运输的协议的硬件和软件加到链路上就构成了数据链路。
  3. 循环冗余检验 CRC(Cyclic Redundancy Check) :为了保证数据传输的可靠性,CRC 是数据链路层广泛使用的一种检错技术。
  4. 帧(frame) :一个数据链路层的传输单元,由一个数据链路层首部和其携带的封包所组成协议数据单元。
  5. MTU(Maximum Transfer Uint ) :最大传送单元。帧的数据部分的的长度上限。
  6. 误码率 BER(Bit Error Rate ) :在一段时间内,传输错误的比特占所传输比特总数的比率。
  7. PPP(Point-to-Point Protocol ) :点对点协议。即用户计算机和 ISP 进行通信时所使用的数据链路层协议。以下是 PPP 帧的示意图: PPP
  8. MAC 地址(Media Access Control 或者 Medium Access Control) :意译为媒体访问控制,或称为物理地址、硬件地址,用来定义网络设备的位置。在 OSI 模型中,第三层网络层负责 IP 地址,第二层数据链路层则负责 MAC 地址。因此一个主机会有一个 MAC 地址,而每个网络位置会有一个专属于它的 IP 地址 。地址是识别某个系统的重要标识符,“名字指出我们所要寻找的资源,地址指出资源所在的地方,路由告诉我们如何到达该处。

ARP (Address Resolution Protocol) explained

  1. 网桥(bridge) :一种用于数据链路层实现中继,连接两个或多个局域网的网络互连设备。
  2. 交换机(switch ) :广义的来说,交换机指的是一种通信系统中完成信息交换的设备。这里工作在数据链路层的交换机指的是交换式集线器,其实质是一个多接口的网桥

3.2. 重要知识点总结

  1. 链路是从一个结点到相邻节点的一段物理链路,数据链路则在链路的基础上增加了一些必要的硬件(如网络适配器)和软件(如协议的实现)
  2. 数据链路层使用的主要是点对点信道广播信道两种。
  3. 数据链路层传输的协议数据单元是帧。数据链路层的三个基本问题是:封装成帧透明传输差错检测
  4. 循环冗余检验 CRC 是一种检错方法,而帧检验序列 FCS 是添加在数据后面的冗余码
  5. 点对点协议 PPP 是数据链路层使用最多的一种协议,它的特点是:简单,只检测差错而不去纠正差错,不使用序号,也不进行流量控制,可同时支持多种网络层协议
  6. PPPoE 是为宽带上网的主机使用的链路层协议
  7. 局域网的优点是:具有广播功能,从一个站点可方便地访问全网;便于系统的扩展和逐渐演变;提高了系统的可靠性,可用性和生存性。
  8. 计算机与外接局域网通信需要通过通信适配器(或网络适配器),它又称为网络接口卡或网卡。计算器的硬件地址就在适配器的 ROM 中
  9. 以太网采用的无连接的工作方式,对发送的数据帧不进行编号,也不要求对方发回确认。目的站收到有差错帧就把它丢掉,其他什么也不做
  10. 以太网采用的协议是具有冲突检测的载波监听多点接入 CSMA/CD。协议的特点是:发送前先监听,边发送边监听,一旦发现总线上出现了碰撞,就立即停止发送。然后按照退避算法等待一段随机时间后再次发送。 因此,每一个站点在自己发送数据之后的一小段时间内,存在这遭遇碰撞的可能性。以太网上的各站点平等的争用以太网信道
  11. 以太网的适配器具有过滤功能,它只接收单播帧,广播帧和多播帧。
  12. 使用集线器可以在物理层扩展以太网(扩展后的以太网仍然是一个网络)

3.3. 补充

  1. 数据链路层的点对点信道和广播信道的特点,以及这两种信道所使用的协议(PPP 协议以及 CSMA/CD 协议)的特点
  2. 数据链路层的三个基本问题:封装成帧透明传输差错检测
  3. 以太网的 MAC 层硬件地址
  4. 适配器,转发器,集线器,网桥,以太网交换机的作用以及适用场合

4. 网络层(Network Layer)

网络层

4.1. 基本术语

  1. 虚电路(Virtual Circuit) : 在两个终端设备的逻辑或物理端口之间,通过建立的双向的透明传输通道。虚电路表示这只是一条逻辑上的连接,分组都沿着这条逻辑连接按照存储转发方式传送,而并不是真正建立了一条物理连接。
  2. IP(Internet Protocol ) : 网际协议 IP 是 TCP/IP 体系中两个最主要的协议之一,是 TCP/IP 体系结构网际层的核心。配套的有 ARP,RARP,ICMP,IGMP。
  3. ARP(Address Resolution Protocol) : 地址解析协议。地址解析协议 ARP 把 IP 地址解析为硬件地址。
  4. ICMP(Internet Control Message Protocol ) :网际控制报文协议 (ICMP 允许主机或路由器报告差错情况和提供有关异常情况的报告)。
  5. 子网掩码(subnet mask ) :它是一种用来指明一个 IP 地址的哪些位标识的是主机所在的子网以及哪些位标识的是主机的位掩码。子网掩码不能单独存在,它必须结合 IP 地址一起使用。
  6. CIDR( Classless Inter-Domain Routing ):无分类域间路由选择 (特点是消除了传统的 A 类、B 类和 C 类地址以及划分子网的概念,并使用各种长度的“网络前缀”(network-prefix)来代替分类地址中的网络号和子网号)。
  7. 默认路由(default route) :当在路由表中查不到能到达目的地址的路由时,路由器选择的路由。默认路由还可以减小路由表所占用的空间和搜索路由表所用的时间。
  8. 路由选择算法(Virtual Circuit) :路由选择协议的核心部分。因特网采用自适应的,分层次的路由选择协议。

4.2. 重要知识点总结

  1. TCP/IP 协议中的网络层向上只提供简单灵活的,无连接的,尽最大努力交付的数据报服务。网络层不提供服务质量的承诺,不保证分组交付的时限所传送的分组可能出错,丢失,重复和失序。进程之间通信的可靠性由运输层负责
  2. 在互联网的交付有两种,一是在本网络直接交付不用经过路由器,另一种是和其他网络的间接交付,至少经过一个路由器,但最后一次一定是直接交付
  3. 分类的 IP 地址由网络号字段(指明网络)和主机号字段(指明主机)组成。网络号字段最前面的类别指明 IP 地址的类别。IP 地址是一种分等级的地址结构。IP 地址管理机构分配 IP 地址时只分配网络号,主机号由得到该网络号的单位自行分配。路由器根据目的主机所连接的网络号来转发分组。一个路由器至少连接到两个网络,所以一个路由器至少应当有两个不同的 IP 地址
  4. IP 数据报分为首部和数据两部分。首部的前一部分是固定长度,共 20 字节,是所有 IP 数据包必须具有的(源地址,目的地址,总长度等重要地段都固定在首部)。一些长度可变的可选字段固定在首部的后面。IP 首部中的生存时间给出了 IP 数据报在互联网中所能经过的最大路由器数。可防止 IP 数据报在互联网中无限制的兜圈子。
  5. 地址解析协议 ARP 把 IP 地址解析为硬件地址。ARP 的高速缓存可以大大减少网络上的通信量。因为这样可以使主机下次再与同样地址的主机通信时,可以直接从高速缓存中找到所需要的硬件地址而不需要再去广播方式发送 ARP 请求分组
  6. 无分类域间路由选择 CIDR 是解决目前 IP 地址紧缺的一个好办法。CIDR 记法把 IP 地址后面加上斜线“/”,然后写上前缀所所占的位数。前缀(或网络前缀用来指明网络),前缀后面的部分是后缀,用来指明主机。CIDR 把前缀都相同的连续的 IP 地址组成一个“CIDR 地址块”,IP 地址分配都以 CIDR 地址块为单位。
  7. 网际控制报文协议是 IP 层的协议。ICMP 报文作为 IP 数据报的数据,加上首部后组成 IP 数据报发送出去。使用 ICMP 数据报并不是为了实现可靠传输。ICMP 允许主机或路由器报告差错情况和提供有关异常情况的报告。ICMP 报文的种类有两种 ICMP 差错报告报文和 ICMP 询问报文。
  8. 要解决 IP 地址耗尽的问题,最根本的办法是采用具有更大地址空间的新版本 IP 协议-IPv6。 IPv6 所带来的变化有 ① 更大的地址空间(采用 128 位地址)② 灵活的首部格式 ③ 改进的选项 ④ 支持即插即用 ⑤ 支持资源的预分配 ⑥IPv6 的首部改为 8 字节对齐。
  9. 虚拟专用网络 VPN 利用公用的互联网作为本机构专用网之间的通信载体。VPN 内使用互联网的专用地址。一个 VPN 至少要有一个路由器具有合法的全球 IP 地址,这样才能和本系统的另一个 VPN 通过互联网进行通信。所有通过互联网传送的数据都需要加密。
  10. MPLS 的特点是:① 支持面向连接的服务质量 ② 支持流量工程,平衡网络负载 ③ 有效的支持虚拟专用网 VPN。MPLS 在入口节点给每一个 IP 数据报打上固定长度的“标记”,然后根据标记在第二层(链路层)用硬件进行转发(在标记交换路由器中进行标记交换),因而转发速率大大加快。

5. 传输层(Transport Layer)

传输层

5.1. 基本术语

  1. 进程(process) :指计算机中正在运行的程序实体。
  2. 应用进程互相通信 :一台主机的进程和另一台主机中的一个进程交换数据的过程(另外注意通信真正的端点不是主机而是主机中的进程,也就是说端到端的通信是应用进程之间的通信)。
  3. 传输层的复用与分用 :复用指发送方不同的进程都可以通过统一个运输层协议传送数据。分用指接收方的运输层在剥去报文的首部后能把这些数据正确的交付到目的应用进程。
  4. TCP(Transmission Control Protocol) :传输控制协议。
  5. UDP(User Datagram Protocol) :用户数据报协议。

TCP和UDP

  1. 端口(port) :端口的目的是为了确认对方机器是那个进程在于自己进行交互,比如 MSN 和 QQ 的端口不同,如果没有端口就可能出现 QQ 进程和 MSN 交互错误。端口又称协议端口号。
  2. 停止等待协议(stop-and-wait) :指发送方每发送完一个分组就停止发送,等待对方确认,在收到确认之后在发送下一个分组。
  3. 流量控制 : 就是让发送方的发送速率不要太快,既要让接收方来得及接收,也不要使网络发生拥塞。
  4. 拥塞控制 :防止过多的数据注入到网络中,这样可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提,就是网络能够承受现有的网络负荷。

5.2. 重要知识点总结

  1. 运输层提供应用进程之间的逻辑通信,也就是说,运输层之间的通信并不是真正在两个运输层之间直接传输数据。运输层向应用层屏蔽了下面网络的细节(如网络拓补,所采用的路由选择协议等),它使应用进程之间看起来好像两个运输层实体之间有一条端到端的逻辑通信信道。
  2. 网络层为主机提供逻辑通信,而运输层为应用进程之间提供端到端的逻辑通信。
  3. 运输层的两个重要协议是用户数据报协议 UDP 和传输控制协议 TCP。按照 OSI 的术语,两个对等运输实体在通信时传送的数据单位叫做运输协议数据单元 TPDU(Transport Protocol Data Unit)。但在 TCP/IP 体系中,则根据所使用的协议是 TCP 或 UDP,分别称之为 TCP 报文段或 UDP 用户数据报。
  4. UDP 在传送数据之前不需要先建立连接,远地主机在收到 UDP 报文后,不需要给出任何确认。虽然 UDP 不提供可靠交付,但在某些情况下 UDP 确是一种最有效的工作方式。 TCP 提供面向连接的服务。在传送数据之前必须先建立连接,数据传送结束后要释放连接。TCP 不提供广播或多播服务。由于 TCP 要提供可靠的,面向连接的传输服务,这一难以避免增加了许多开销,如确认,流量控制,计时器以及连接管理等。这不仅使协议数据单元的首部增大很多,还要占用许多处理机资源。
  5. 硬件端口是不同硬件设备进行交互的接口,而软件端口是应用层各种协议进程与运输实体进行层间交互的一种地址。UDP 和 TCP 的首部格式中都有源端口和目的端口这两个重要字段。当运输层收到 IP 层交上来的运输层报文时,就能够 根据其首部中的目的端口号把数据交付应用层的目的应用层。(两个进程之间进行通信不光要知道对方 IP 地址而且要知道对方的端口号(为了找到对方计算机中的应用进程))
  6. 运输层用一个 16 位端口号标志一个端口。端口号只有本地意义,它只是为了标志计算机应用层中的各个进程在和运输层交互时的层间接口。在互联网的不同计算机中,相同的端口号是没有关联的。协议端口号简称端口。虽然通信的终点是应用进程,但只要把所发送的报文交到目的主机的某个合适端口,剩下的工作(最后交付目的进程)就由 TCP 和 UDP 来完成。
  7. 运输层的端口号分为服务器端使用的端口号(01023 指派给熟知端口,102449151 是登记端口号)和客户端暂时使用的端口号(49152~65535)
  8. UDP 的主要特点是 ① 无连接 ② 尽最大努力交付 ③ 面向报文 ④ 无拥塞控制 ⑤ 支持一对一,一对多,多对一和多对多的交互通信 ⑥ 首部开销小(只有四个字段:源端口,目的端口,长度和检验和)
  9. TCP 的主要特点是 ① 面向连接 ② 每一条 TCP 连接只能是一对一的 ③ 提供可靠交付 ④ 提供全双工通信 ⑤ 面向字节流
  10. TCP 用主机的 IP 地址加上主机上的端口号作为 TCP 连接的端点。这样的端点就叫做套接字(socket)或插口。套接字用(IP 地址:端口号)来表示。每一条 TCP 连接唯一被通信两端的两个端点所确定。
  11. 停止等待协议是为了实现可靠传输的,它的基本原理就是每发完一个分组就停止发送,等待对方确认。在收到确认后再发下一个分组。
  12. 为了提高传输效率,发送方可以不使用低效率的停止等待协议,而是采用流水线传输。流水线传输就是发送方可连续发送多个分组,不必每发完一个分组就停下来等待对方确认。这样可使信道上一直有数据不间断的在传送。这种传输方式可以明显提高信道利用率。
  13. 停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认,就重传前面发送过的分组(认为刚才发送过的分组丢失了)。因此每发送完一个分组需要设置一个超时计时器,其重转时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为自动重传请求 ARQ。另外在停止等待协议中若收到重复分组,就丢弃该分组,但同时还要发送确认。连续 ARQ 协议可提高信道利用率。发送维持一个发送窗口,凡位于发送窗口内的分组可连续发送出去,而不需要等待对方确认。接收方一般采用累积确认,对按序到达的最后一个分组发送确认,表明到这个分组位置的所有分组都已经正确收到了。
  14. TCP 报文段的前 20 个字节是固定的,后面有 4n 字节是根据需要增加的选项。因此,TCP 首部的最小长度是 20 字节。
  15. TCP 使用滑动窗口机制。发送窗口里面的序号表示允许发送的序号。发送窗口后沿的后面部分表示已发送且已收到确认,而发送窗口前沿的前面部分表示不允许发送。发送窗口后沿的变化情况有两种可能,即不动(没有收到新的确认)和前移(收到了新的确认)。发送窗口的前沿通常是不断向前移动的。一般来说,我们总是希望数据传输更快一些。但如果发送方把数据发送的过快,接收方就可能来不及接收,这就会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快,要让接收方来得及接收。
  16. 在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络的性能就要变坏。这种情况就叫拥塞。拥塞控制就是为了防止过多的数据注入到网络中,这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提,就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程,涉及到所有的主机,所有的路由器,以及与降低网络传输性能有关的所有因素。相反,流量控制往往是点对点通信量的控制,是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率,以便使接收端来得及接收。
  17. 为了进行拥塞控制,TCP 发送方要维持一个拥塞窗口 cwnd 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度,并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。
  18. TCP 的拥塞控制采用了四种算法,即慢开始,拥塞避免,快重传和快恢复。在网络层也可以使路由器采用适当的分组丢弃策略(如主动队列管理 AQM),以减少网络拥塞的发生。
  19. 运输连接的三个阶段,即:连接建立,数据传送和连接释放。
  20. 主动发起 TCP 连接建立的应用进程叫做客户,而被动等待连接建立的应用进程叫做服务器。TCP 连接采用三报文握手机制。服务器要确认用户的连接请求,然后客户要对服务器的确认进行确认。
  21. TCP 的连接释放采用四报文握手机制。任何一方都可以在数据传送结束后发出连接释放的通知,待对方确认后进入半关闭状态。当另一方也没有数据再发送时,则发送连接释放通知,对方确认后就完全关闭了 TCP 连接

5.3. 补充(重要)

以下知识点需要重点关注:

  1. 端口和套接字的意义
  2. UDP 和 TCP 的区别以及两者的应用场景
  3. 在不可靠的网络上实现可靠传输的工作原理,停止等待协议和 ARQ 协议
  4. TCP 的滑动窗口,流量控制,拥塞控制和连接管理
  5. TCP 的三次握手,四次挥手机制

6. 应用层(Application Layer)

应用层

6.1. 基本术语

  1. 域名系统(DNS) :域名系统(DNS,Domain Name System)将人类可读的域名 (例如,www.baidu.com) 转换为机器可读的 IP 地址 (例如,220.181.38.148)。我们可以将其理解为专为互联网设计的电话薄。

https://www.seobility.net/en/wiki/HTTP_headers

  1. 文件传输协议(FTP) :FTP 是 File TransferProtocol(文件传输协议)的英文简称,而中文简称为“文传协议”。用于 Internet 上的控制文件的双向传输。同时,它也是一个应用程序(Application)。基于不同的操作系统有不同的 FTP 应用程序,而所有这些应用程序都遵守同一种协议以传输文件。在 FTP 的使用当中,用户经常遇到两个概念:”下载”(Download)和”上传”(Upload)。 “下载”文件就是从远程主机拷贝文件至自己的计算机上;”上传”文件就是将文件从自己的计算机中拷贝至远程主机上。用 Internet 语言来说,用户可通过客户机程序向(从)远程主机上传(下载)文件。

FTP工作过程

  1. 简单文件传输协议(TFTP) :TFTP(Trivial File Transfer Protocol,简单文件传输协议)是 TCP/IP 协议族中的一个用来在客户机与服务器之间进行简单文件传输的协议,提供不复杂、开销不大的文件传输服务。端口号为 69。
  2. 远程终端协议(TELNET) :Telnet 协议是 TCP/IP 协议族中的一员,是 Internet 远程登陆服务的标准协议和主要方式。它为用户提供了在本地计算机上完成远程主机工作的能力。在终端使用者的电脑上使用 telnet 程序,用它连接到服务器。终端使用者可以在 telnet 程序中输入命令,这些命令会在服务器上运行,就像直接在服务器的控制台上输入一样。可以在本地就能控制服务器。要开始一个 telnet 会话,必须输入用户名和密码来登录服务器。Telnet 是常用的远程控制 Web 服务器的方法。
  3. 万维网(WWW) :WWW 是环球信息网的缩写,(亦作“Web”、“WWW”、“’W3’”,英文全称为“World Wide Web”),中文名字为“万维网”,”环球网”等,常简称为 Web。分为 Web 客户端和 Web 服务器程序。WWW 可以让 Web 客户端(常用浏览器)访问浏览 Web 服务器上的页面。是一个由许多互相链接的超文本组成的系统,通过互联网访问。在这个系统中,每个有用的事物,称为一样“资源”;并且由一个全局“统一资源标识符”(URI)标识;这些资源通过超文本传输协议(Hypertext Transfer Protocol)传送给用户,而后者通过点击链接来获得资源。万维网联盟(英语:World Wide Web Consortium,简称 W3C),又称 W3C 理事会。1994 年 10 月在麻省理工学院(MIT)计算机科学实验室成立。万维网联盟的创建者是万维网的发明者蒂姆·伯纳斯-李。万维网并不等同互联网,万维网只是互联网所能提供的服务其中之一,是靠着互联网运行的一项服务。
  4. 万维网的大致工作工程:

万维网的大致工作工程

  1. 统一资源定位符(URL) :统一资源定位符是对可以从互联网上得到的资源的位置和访问方法的一种简洁的表示,是互联网上标准资源的地址。互联网上的每个文件都有一个唯一的 URL,它包含的信息指出文件的位置以及浏览器应该怎么处理它。
  2. 超文本传输协议(HTTP) :超文本传输协议(HTTP,HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的 WWW 文件都必须遵守这个标准。设计 HTTP 最初的目的是为了提供一种发布和接收 HTML 页面的方法。1960 年美国人 Ted Nelson 构思了一种通过计算机处理文本信息的方法,并称之为超文本(hypertext),这成为了 HTTP 超文本传输协议标准架构的发展根基。

HTTP 协议的本质就是一种浏览器与服务器之间约定好的通信格式。HTTP 的原理如下图所示:

  1. 代理服务器(Proxy Server) : 代理服务器(Proxy Server)是一种网络实体,它又称为万维网高速缓存。 代理服务器把最近的一些请求和响应暂存在本地磁盘中。当新请求到达时,若代理服务器发现这个请求与暂时存放的的请求相同,就返回暂存的响应,而不需要按 URL 的地址再次去互联网访问该资源。代理服务器可在客户端或服务器工作,也可以在中间系统工作。
  2. 简单邮件传输协议(SMTP) : SMTP(Simple Mail Transfer Protocol)即简单邮件传输协议,它是一组用于由源地址到目的地址传送邮件的规则,由它来控制信件的中转方式。 SMTP 协议属于 TCP/IP 协议簇,它帮助每台计算机在发送或中转信件时找到下一个目的地。 通过 SMTP 协议所指定的服务器,就可以把 E-mail 寄到收信人的服务器上了,整个过程只要几分钟。SMTP 服务器则是遵循 SMTP 协议的发送邮件服务器,用来发送或中转发出的电子邮件。

一个电子邮件被发送的过程

https://www.campaignmonitor.com/resources/knowledge-base/what-is-the-code-that-makes-bcc-or-cc-operate-in-an-email/

  1. 搜索引擎 :搜索引擎(Search Engine)是指根据一定的策略、运用特定的计算机程序从互联网上搜集信息,在对信息进行组织和处理后,为用户提供检索服务,将用户检索相关的信息展示给用户的系统。搜索引擎包括全文索引、目录索引、元搜索引擎、垂直搜索引擎、集合式搜索引擎、门户搜索引擎与免费链接列表等。

搜索引擎

  1. 垂直搜索引擎 :垂直搜索引擎是针对某一个行业的专业搜索引擎,是搜索引擎的细分和延伸,是对网页库中的某类专门的信息进行一次整合,定向分字段抽取出需要的数据进行处理后再以某种形式返回给用户。垂直搜索是相对通用搜索引擎的信息量大、查询不准确、深度不够等提出来的新的搜索引擎服务模式,通过针对某一特定领域、某一特定人群或某一特定需求提供的有一定价值的信息和相关服务。其特点就是“专、精、深”,且具有行业色彩,相比较通用搜索引擎的海量信息无序化,垂直搜索引擎则显得更加专注、具体和深入。
  2. 全文索引 :全文索引技术是目前搜索引擎的关键技术。试想在 1M 大小的文件中搜索一个词,可能需要几秒,在 100M 的文件中可能需要几十秒,如果在更大的文件中搜索那么就需要更大的系统开销,这样的开销是不现实的。所以在这样的矛盾下出现了全文索引技术,有时候有人叫倒排文档技术。
  3. 目录索引 :目录索引( search index/directory),顾名思义就是将网站分门别类地存放在相应的目录中,因此用户在查询信息时,可选择关键词搜索,也可按分类目录逐层查找。

6.2. 重要知识点总结

  1. 文件传输协议(FTP)使用 TCP 可靠的运输服务。FTP 使用客户服务器方式。一个 FTP 服务器进程可以同时为多个用户提供服务。在进进行文件传输时,FTP 的客户和服务器之间要先建立两个并行的 TCP 连接:控制连接和数据连接。实际用于传输文件的是数据连接。
  2. 万维网客户程序与服务器之间进行交互使用的协议是超文本传输协议 HTTP。HTTP 使用 TCP 连接进行可靠传输。但 HTTP 本身是无连接、无状态的。HTTP/1.1 协议使用了持续连接(分为非流水线方式和流水线方式)
  3. 电子邮件把邮件发送到收件人使用的邮件服务器,并放在其中的收件人邮箱中,收件人可随时上网到自己使用的邮件服务器读取,相当于电子邮箱。
  4. 一个电子邮件系统有三个重要组成构件:用户代理、邮件服务器、邮件协议(包括邮件发送协议,如 SMTP,和邮件读取协议,如 POP3 和 IMAP)。用户代理和邮件服务器都要运行这些协议。

6.3. 补充(重要)

以下知识点需要重点关注:

  1. 应用层的常见协议(重点关注 HTTP 协议)
  2. 域名系统-从域名解析出 IP 地址
  3. 访问一个网站大致的过程
  4. 系统调用和应用编程接口概念

0 119

转载自:https://blog.csdn.net/CrankZ/article/details/82874158

 

这篇博客从数据库连接池的发展历史的角度出发,概要介绍C3P0,DBCP,HikariCP,Druid等数据库连接池的优缺点,同时介绍了连接池的概念和作用,收获良多,特此转载记录。

 

什么是连接池

数据库连接池负责分配、管理和释放数据库连接,它允许应用程序重复使用一个现有的数据库连接,而不是再重新建立一个。

为什么要使用连接池

数据库连接是一种关键的有限的昂贵的资源,这一点在多用户的网页应用程序中体现得尤为突出。  一个数据库连接对象均对应一个物理数据库连接,每次操作都打开一个物理连接,使用完都关闭连接,这样造成系统的 性能低下。 数据库连接池的解决方案是在应用程序启动时建立足够的数据库连接,并讲这些连接组成一个连接池(简单说:在一个“池”里放了好多半成品的数据库联接对象),由应用程序动态地对池中的连接进行申请、使用和释放。对于多于连接池中连接数的并发请求,应该在请求队列中排队等待。并且应用程序可以根据池中连接的使用率,动态增加或减少池中的连接数 连接池技术尽可能多地重用了消耗内存地资源,大大节省了内存,提高了服务器地服务效率,能够支持更多的客户服务。通过使用连接池将大大提高程序运行效率,同时,我们可以通过其自身的管理机制来监视数据库连接的数量、使用情况等。 

传统的连接机制与数据库连接池的运行机制区别

不使用连接池流程

下面以访问MySQL为例,执行一个SQL命令,如果不使用连接池,需要经过哪些流程。

不使用数据库连接池的步骤:

  1. TCP建立连接的三次握手
  2. MySQL认证的三次握手
  3. 真正的SQL执行
  4. MySQL的关闭
  5. TCP的四次握手关闭

可以看到,为了执行一条SQL,却多了非常多我们不关心的网络交互。

优点:

  1. 实现简单

缺点:

  1. 网络IO较多
  2. 数据库的负载较高
  3. 响应时间较长及QPS较低
  4. 应用频繁的创建连接和关闭连接,导致临时对象较多,GC频繁
  5. 在关闭连接后,会出现大量TIME_WAIT 的TCP状态(在2个MSL之后关闭)

使用连接池流程

使用数据库连接池的步骤:

第一次访问的时候,需要建立连接。 但是之后的访问,均会复用之前创建的连接,直接执行SQL语句。(复用的是Mysql认证这一部分,TCP复用则是HTTP1.1长连接)

优点:

  1. 较少了网络开销
  2. 系统的性能会有一个实质的提升
  3. 没了麻烦的TIME_WAIT状态

 

数据库连接池的工作原理

连接池的工作原理主要由三部分组成,分别为

  1. 连接池的建立
  2. 连接池中连接的使用管理
  3. 连接池的关闭

第一、连接池的建立。一般在系统初始化时,连接池会根据系统配置建立,并在池中创建了几个连接对象,以便使用时能从连接池中获取。连接池中的连接不能随意创建和关闭,这样避免了连接随意建立和关闭造成的系统开销。Java中提供了很多容器类可以方便的构建连接池,例如Vector、Stack等。

第二、连接池的管理。连接池管理策略是连接池机制的核心,连接池内连接的分配和释放对系统的性能有很大的影响。其管理策略是:

当客户请求数据库连接时,首先查看连接池中是否有空闲连接,如果存在空闲连接,则将连接分配给客户使用如果没有空闲连接,则查看当前所开的连接数是否已经达到最大连接数,如果没达到就重新创建一个连接给请求的客户如果达到就按设定的最大等待时间进行等待,如果超出最大等待时间,则抛出异常给客户。(与线程池有异曲同工之妙~~~)

当客户释放数据库连接时,先判断该连接的引用次数是否超过了规定值,如果超过就从连接池中删除该连接,否则保留为其他客户服务。

该策略保证了数据库连接的有效复用,避免频繁的建立、释放连接所带来的系统资源开销。

第三、连接池的关闭。当应用程序退出时,关闭连接池中所有的连接,释放连接池相关的资源,该过程正好与创建相反。

 

连接池主要参数

使用连接池时,要配置一下参数

最小连接数:是连接池一直保持的数据库连接,所以如果应用程序对数据库连接的使用量不大,将会有大量的数据库连接资源被浪费.

最大连接数:是连接池能申请的最大连接数,如果数据库连接请求超过次数,后面的数据库连接请求将被加入到等待队列中,这会影响以后的数据库操作

最大空闲时间

获取连接超时时间

超时重试连接次数

连接池需要注意的点

1、并发问题

为了使连接管理服务具有最大的通用性,必须考虑多线程环境,即并发问题。这个问题相对比较好解决,因为各个语言自身提供了对并发管理的支持像java,c#等等,使用synchronized(java)lock(C#)关键字即可确保线程是同步的。使用方法可以参考,相关文献。

2、事务处理

我们知道,事务具有原子性,此时要求对数据库的操作符合“ALL-OR-NOTHING”原则,即对于一组SQL语句要么全做,要么全不做
我们知道当2个线程共用一个连接Connection对象,而且各自都有自己的事务要处理时候,对于连接池是一个很头疼的问题,因为即使Connection类提供了相应的事务支持,可是我们仍然不能确定那个数据库操作是对应那个事务的,这是由于我们有2个线程都在进行事务操作而引起的。为此我们可以使用每一个事务独占一个连接来实现,虽然这种方法有点浪费连接池资源但是可以大大降低事务管理的复杂性。(待补充,有无连接池事务处理更好的方案)

3、连接池的分配与释放

连接池的分配与释放,对系统的性能有很大的影响。合理的分配与释放,可以提高连接的复用度,从而降低建立新连接的开销,同时还可以加快用户的访问速度。
对于连接的管理可使用一个List。即把已经创建的连接都放入List中去统一管理。每当用户请求一个连接时,系统检查这个List中有没有可以分配的连接。如果有就把那个最合适的连接分配给他(如何能找到最合适的连接文章将在关键议题中指出);如果没有就抛出一个异常给用户,List中连接是否可以被分配由一个线程来专门管理捎后我会介绍这个线程的具体实现。

4、连接池的配置与维护(重点)

连接池中到底应该放置多少连接,才能使系统的性能最佳?系统可采取设置最小连接数(minConnection)和最大连接数(maxConnection)等参数来控制连接池中的连接。比方说,最小连接数是系统启动时连接池所创建的连接数。如果创建过多,则系统启动就慢,但创建后系统的响应速度会很快;如果创建过少,则系统启动的很快,响应起来却慢。这样,可以在开发时,设置较小的最小连接数,开发起来会快,而在系统实际使用时设置较大的,因为这样对访问客户来说速度会快些。最大连接数是连接池中允许连接的最大数目,具体设置多少,要看系统的访问量,可通过软件需求上得到。
如何确保连接池中的最小连接数呢?有动态和静态两种策略。动态即每隔一定时间就对连接池进行检测,如果发现连接数量小于最小连接数,则补充相应数量的新连接,以保证连接池的正常运转。静态是发现空闲连接不够时再去检查。

数据库对比

第一、二代连接池

区分一个数据库连接池是属于第一代产品还是代二代产品有一个最重要的特征就是看它在架构和设计时采用的线程模型,因为这直接影响的是并发环境下存取数据库连接的性能。

一般来讲采用单线程同步的架构设计都属于第一代连接池采用多线程异步架构的则属于第二代。比较有代表性的就是Apache Commons DBCP,在1.x版本中,一直延续着单线程设计模式,到2.x才采用多线程模型。

用版本发布时间来辨别区分两代产品,则一个偷懒的好方法。以下是这些常见数据库连接池最新版本的发布时间:

 

 

从表中可以看出,C3P0已经很久没有更新了。DBCP更新速度很慢,基本处于不活跃状态而Druid和HikariCP处于活跃状态的更新中这就是我们说的二代产品

二代产品对一代产品的超越是颠覆性的,除了一些“历史原因”,你很难再找到第二条理由说服自己不选择二代产品,但任何成功都不是偶然的,二代产品的成功很大程度上得益于前代产品们打下的基础,站在巨人的肩膀上,新一代的连接池的设计师们将这一项“工具化”的产品,推向了极致。其中,最具代表性的两款产品是:

HikariCP
Druid

 

彻底死掉的C3P0(简单,但性能垫底)

C3P0是我使用的第一款数据库连接池,在很长一段时间内,它一直是Java领域内数据库连接池的代名词,当年盛极一时的Hibernate都将其作为内置的数据库连接池,可见业内对它的稳定性还是认可的。C3P0功能简单易用,稳定性好这是它的优点,但是性能上的缺点却让它彻底被打入冷宫C3P0的性能很差,差到即便是同时代的产品相比它也是垫底的,更不用和Druid、HikariCP等相比了。正常来讲,有问题很正常,改就是了,但c3p0最致命的问题就是架构设计过于复杂,让重构变成了一项不可能完成的任务。随着国内互联网大潮的涌起,性能有硬伤的c3p0彻底的退出了历史舞台。

咸鱼翻身的DBCP

DBCP(DataBase Connection Pool)属于Apache顶级项目Commons中的核心子项目(最早在Jakarta Commons里就有),在Apache的生态圈中的影响里十分广泛,比如最为大家所熟知的Tomcat就在内部集成了DBCP,实现JPA规范的OpenJPA,也是默认集成DBCP的。但DBCP并不是独立实现连接池功能的,它内部依赖于Commons中的另一个子项目Pool,连接池最核心的“池”,就是由Pool组件提供的,因此,DBCP的性能实际上就是Pool的性能,DBCP和Pool的依赖关系如下表:
可以看到,因为核心功能依赖于Pool,所以DBCP本身只能做小版本的更新,真正大版本的更迭则完全依托于pool。有很长一段时间,pool都还是停留在1.x版本,这直接导致DBCP也更新乏力。很多依赖DBCP的应用在遇到性能瓶颈之后,别无选择,只能将其替换掉,DBCP忠实的拥趸tomcat就在其tomcat 7.0版本中,自己重新设计开发出了一套连接池(Tomcat JDBC Pool)。好在,在2013年事情终于迎来转机,13年9月Commons-Pool 2.0版本发布,14年2月份,DBCP也终于迎来了自己的2.0版本,基于新的线程模型全新设计的“池”让DBCP重焕青春,虽然和新一代的连接池相比仍有一定差距,但差距并不大,DBCP2.x版本已经稳稳达到了和新一代产品同级别的性能指标(见下图)。

DBCP终于靠Pool咸鱼翻身,打了一个漂亮的翻身仗,但长时间的等待已经完全消磨了用户的耐心,与新一代的产品项目相比,DBCP没有任何优势,试问,谁会在有选择的前提下,去选择那个并不优秀的呢?也许,现在还选择DBCP2的唯一理由,就是情怀吧。

性能无敌的HikariCP

HikariCP号称“性能杀手”(It’s Faster),它的表现究竟如何呢,先来看下官网提供的数据:

不光性能强劲,稳定性也不差:

那它是怎么做到如此强劲的呢?官网给出的说明如下:

  • 字节码精简:优化代码,直到编译后的字节码最少,这样,CPU缓存可以加载更多的程序代码;
  • 优化代理和拦截器:减少代码,例如HikariCP的Statement proxy只有100行代码;
  • 自定义数组类型(FastStatementList)代替ArrayList:避免每次get()调用都要进行range check,避免调用remove()时的从头到尾的扫描;
  • 自定义集合类型(ConcurrentBag):提高并发读写的效率;
  • 其他缺陷的优化,比如对于耗时超过一个CPU时间片的方法调用的研究(但没说具体怎么优化)。

可以看到,上述这几点优化,和现在能找到的资料来看,HakariCP在性能上的优势应该是得到共识的,再加上它自身小巧的身形,在当前的“云时代、微服务”的背景下,HakariCP一定会得到更多人的青睐。

此处:Springboot 2.0选择HikariCP作为默认数据库连接池的五大理由

功能全面的Druid

近几年,阿里在开源项目上动作频频,除了有像fastJson、dubbo这类项目,更有像AliSQL这类的大型软件,今天说的Druid,就是阿里众多优秀开源项目中的一个。它除了提供性能卓越的连接池功能外,还集成了SQL监控,黑名单拦截等功能,用它自己的话说,Druid是“为监控而生”。借助于阿里这个平台的号召力,产品一经发布就赢得了大批用户的拥趸,从用户使用的反馈来看,Druid也确实没让用户失望。

相较于其他产品,Druid另一个比较大的优势,就是中文文档比较全面(毕竟是国人的项目么),在github的wiki页面,列举了日常使用中可能遇到的问题,对一个新用户来讲,上面提供的内容已经足够指导它完成产品的配置和使用了。
下图为Druid自己提供的性能测试数据:

现在项目开发中,我还是比较倾向于使用Durid,它不仅仅是一个数据库连接池,它还包含一个ProxyDriver,一系列内置的JDBC组件库,一个SQL Parser。

Druid 相对于其他数据库连接池的优点

Druid 相对于其他数据库连接池的优点
强大的监控特性,通过Druid提供的监控功能,可以清楚知道连接池和SQL的工作情况。
a. 监控SQL的执行时间、ResultSet持有时间、返回行数、更新行数、错误次数、错误堆栈信息;

b. SQL执行的耗时区间分布。什么是耗时区间分布呢?比如说,某个SQL执行了1000次,其中0~1毫秒区间50次,1~10毫秒800次,10~100毫秒100次,100~1000毫秒30次,1~10秒15次,10秒以上5次。通过耗时区间分布,能够非常清楚知道SQL的执行耗时情况;

c. 监控连接池的物理连接创建和销毁次数、逻辑连接的申请和关闭次数、非空等待次数、PSCache命中率等。

  • 方便扩展。Druid提供了Filter-Chain模式的扩展API,可以自己编写Filter拦截JDBC中的任何方法,可以在上面做任何事情,比如说性能监控、SQL审计、用户名密码加密、日志等等。
  • Druid集合了开源和商业数据库连接池的优秀特性,并结合阿里巴巴大规模苛刻生产环境的使用经验进行优化。

总结

时至今日,虽然每个应用(需要RDBMS的)都离不开连接池,但在实际使用的时候,连接池已经可以做到“隐形”了。也就是说在通常情况下,连接池完成项目初始化配置之后,就再不需要再做任何改动了。不论你是选择Druid或是HikariCP,甚至是DBCP,它们都足够稳定且高效!之前讨论了很多关于连接池的性能的问题,但这些性能上的差异,是相较于其他连接池而言的,对整个系统应用来说,第二代连接池在使用过程中体会到的差别是微乎其微的,基本上不存在因为连接池的自身的配饰和使用导致系统性能下降的情况,除非是在单点应用的数据库负载足够高的时候(压力测试的时候),但即便是如此,通用的优化的方式也是单点改集群,而不是在单点的连接池上死扣。

 

参加北森评测时遇到了,当时我用的是C语言写的生产者消费者

今天学习了NIO,BlockingQueue(阻塞队列),ThreadPool(线程池相关概念),为复习巩固记录一个简易的生产者消费者Demo

代码地址:ThreadPool\MyBlockingQueue

 

 

生产者:

package MyBlockingQueue;

import java.util.Scanner;
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.TimeUnit;

/**
 * @Author Chengzhi
 * @Date 2021/4/18 0:47
 * @Version 1.0
 *
 * 角色:生产者
 * 说明:以实现 Runnable 接口的形式
 *      将自己包装成单个线程
 *      从而实现多线程
 */
public class Producer implements Runnable{

    /* 生产者与消费者之间应该有 BlockingQueue,那么这个 Queue 应该定义在外部更合理
       因此需要传入Queue  */
    private BlockingQueue queue;
    private volatile boolean  isRunning = true;//是否在运行标志
    public Producer(BlockingQueue queue){
        this.queue = queue;
    }

    /* 重写 run() 方法
       实现消息的创建,并放置到 Queue 中 */
    @Override
    public void run() {
        System.out.println(Thread.currentThread().getName() + " 号生产者---启动");
        try {
            while (isRunning) {
                //输入要发送的消息
                Scanner scanner = new Scanner(System.in);
                String msg = scanner.nextLine();
                System.out.println(Thread.currentThread().getName() + " 号生产者---输入成功!!!内容为:" + msg);

                //将消息放入阻塞队列,设定等待时间为5秒,如果5秒没加进去则返回 false
                boolean isSuccess = queue.offer(msg,5, TimeUnit.SECONDS);

                if(isSuccess){
                    System.out.println(Thread.currentThread().getName() + " 号生产者---生产成功");

                    //生产成功后休息十秒,给其他线程生产机会
                    Thread.sleep(10000);
                }
            }
        }catch (Exception e){
            e.printStackTrace();

            //改变线程中断状态
            Thread.currentThread().interrupt();
        }finally {
            System.out.println(Thread.currentThread().getName() + " 号生产者---退出");
        }
    }
    public void stop() {
        isRunning = false;
    }
}

消费者:
package MyBlockingQueue;

import java.util.concurrent.BlockingQueue;
import java.util.concurrent.TimeUnit;

/**
 * @Author Chengzhi
 * @Date 2021/4/18 1:02
 * @Version 1.0
 *
 * 角色:消费者
 * 说明:以实现 Runnable 接口的形式
 *      将自己包装成单个线程
 *      从而实现多线程
 */
public class Customer implements Runnable{

    /* 同样需要传入阻塞队列 */
    private BlockingQueue<String> queue;

    public Customer(BlockingQueue queue){
        this.queue = queue;
    }

    /* 重写 run() 方法
       实现消息的消费,将消息从 Queue 中移除 */
    @Override
    public void run() {

        System.out.println(Thread.currentThread().getName() + " 号[消费者]---启动");
        // isRunning 用于判断是否有消息来到
        boolean isRunning = true;
        try {
            while (isRunning) {
                System.out.println(Thread.currentThread().getName() + " 号正在从阻塞队列 Queue 中获得消息...");
                //获取需要消费的消息
                System.out.println(Thread.currentThread().getName() + " 号[消费者]---等待五秒");

                //从阻塞队列取出一个队首的对象,如果在5秒内队列一旦有数据可取,则立即返回队列中的数据,否则返回false
                String msg = queue.poll(5, TimeUnit.SECONDS);//有数据时直接从队列的队首取走,无数据时阻塞,在5s内有数据,取走,超过5s还没数据,返回null

                //判断是否拿到消息
                if(null != msg){
                    //拿到数据并输出
                    System.out.println(Thread.currentThread().getName() + " 号[消费者]---拿到消息:"+ msg);
                }
                else{
                    // 超过5s还没数据,认为所有生产线程都已经退出,自动退出消费线程。
                    isRunning = false;
                }
            }
        } catch (InterruptedException e) {
            e.printStackTrace();

            //改变线程中断状态
            Thread.currentThread().interrupt();
        }finally {
            System.out.println(Thread.currentThread().getName() + " 号[消费者]---退出");
        }
    }
}

测试类:
package MyBlockingQueue;

import java.util.concurrent.*;

/**
 * @Author Chengzhi
 * @Date 2021/4/18 1:35
 * @Version 1.0
 */
public class MyBlockingTest {
    private static final int CORE_POOL_SIZE = 3;
    private static final int MAX_POOL_SIZE = 5;
    private static final int QUEUE_CAPACITY = 5;
    private static final Long KEEP_ALIVE_TIME = 1L;

    public static void main(String[] args) throws InterruptedException {

        BlockingQueue<String> Queue = new LinkedBlockingDeque<>(10);
        //创建一个生产者线程
        Producer Producer1 = new Producer(Queue);
        Producer Producer2 = new Producer(Queue);
        Producer Producer3 = new Producer(Queue);
        //创建一个消费者线程
        Customer customer1 = new Customer(Queue);

        //创建线程池接收线程任务
        //通过ThreadPoolExecutor构造函数自定义参数创建
        ThreadPoolExecutor executor = new ThreadPoolExecutor(
                CORE_POOL_SIZE,
                MAX_POOL_SIZE,
                KEEP_ALIVE_TIME,
                TimeUnit.SECONDS,
                new ArrayBlockingQueue<>(QUEUE_CAPACITY),
                new ThreadPoolExecutor.CallerRunsPolicy());

        //启动线程
        executor.execute(Producer1);
        executor.execute(Producer2);
        executor.execute(Producer3);
        executor.execute(customer1);

        // 执行60s
        Thread.sleep(10 * 1000);
        Producer1.stop();

        Thread.sleep(2000);
        // 退出Executor
        executor.shutdown();
    }
}

链接:https://www.zhihu.com/question/32255109/answer/68558623

首先明确:
1)TCP滑动窗口分为接受窗口,发送窗口
滑动窗口协议是传输层进行流控的一种措施,接收方通过通告发送方自己的窗口大小,从而控制发送方的发送速度,从而达到防止发送方发送速度过快而导致自己被淹没的目的。对ACK的再认识,ack通常被理解为收到数据后给出的一个确认ACK,ACK包含两个非常重要的信息:
一是期望接收到的下一字节的序号n,该n代表接收方已经接收到了前n-1字节数据,此时如果接收方收到第n+1字节数据而不是第n字节数据,接收方是不会发送序号为n+2的ACK的。举个例子,假如接收端收到1-1024字节,它会发送一个确认号为1025的ACK,但是接下来收到的是2049-3072,它是不会发送确认号为3072的ACK,而依旧发送1025的ACK。

二是当前的窗口大小m,如此发送方在接收到ACK包含的这两个数据后就可以计算出还可以发送多少字节的数据给对方,假定当前发送方已发送到第x字节,则可以发送的字节数就是y=m-(x-n).这就是滑动窗口控制流量的基本原理

重点:发送方根据收到ACK当中的期望收到的下一个字节的序号n以及窗口m,还有当前已经发送的字节序号x,算出还可以发送的字节数。

发送端窗口的第一个字节序号一定是ACK中期望收到的下一个字节序号,比如下图:

上图52 53 54 55 字节都是可以新发送的字节序

接受端窗口的第一个字节序之前一定是已经完全接收的,后面窗口里面的数据都是希望接受的,窗口后面的数据都是不希望接受的。

http://blog.chinaunix.net/uid-20778955-id-539945.html

http://www.netis.com.cn/flows/2012/08/tcp-%E6%BB%91%E
5%8A%A8%E7%AA%97%E5%8F%A3%E7%9A%84%E7%AE%80%E4%BB%8B/

TCP的滑动窗口分为接收窗口和发送窗口
不分析这两种窗口就讨论是不妥当的。

TCP的滑动窗口主要有两个作用,一是提供TCP的可靠性,二是提供TCP的流控特性。同时滑动窗口机制还体现了TCP面向字节流的设计思路。TCP 段中窗口的相关字段。

TCP的Window是一个16bit位字段,它代表的是窗口的字节容量,也就是TCP的标准窗口最大为2^16-1=65535个字节。

另外在TCP的选项字段中还包含了一个TCP窗口扩大因子,option-kind为3,option-length为3个字节,option-data取值范围0-14。窗口扩大因子用来扩大TCP窗口,可把原来16bit的窗口,扩大为31bit。

滑动窗口基本原理

1)对于TCP会话的发送方,任何时候在其发送缓存内的数据都可以分为4类,“已经发送并得到对端ACK的”,“已经发送但还未收到对端ACK的”,“未发送但对端允许发送的”,“未发送且对端不允许发送”。“已经发送但还未收到对端ACK的”和“未发送但对端允许发送的”这两部分数据称之为发送窗口。

当收到接收方新的ACK对于发送窗口中后续字节的确认是,窗口滑动,滑动原理如下图。

当收到ACK=36时窗口滑动。

2)对于TCP的接收方,在某一时刻在它的接收缓存内存在3种。“已接收”,“未接收准备接收”,“未接收并未准备接收”(由于ACK直接由TCP协议栈回复,默认无应用延迟,不存在“已接收未回复ACK”)。其中“未接收准备接收”称之为接收窗口。

发送窗口与接收窗口关系

TCP是双工的协议,会话的双方都可以同时接收、发送数据。TCP会话的双方都各自维护一个“发送窗口”和一个“接收窗口”。其中各自的“接收窗口”大小取决于应用、系统、硬件的限制(TCP传输速率不能大于应用的数据处理速率)。各自的“发送窗口”则要求取决于对端通告的“接收窗口”,要求相同。

滑动窗口实现面向流的可靠性

1)最基本的传输可靠性来源于“确认重传”机制。

2)TCP的滑动窗口的可靠性也是建立在“确认重传”基础上的。

3)发送窗口只有收到对端对于本段发送窗口内字节的ACK确认,才会移动发送窗口的左边界。

4)接收窗口只有在前面所有的段都确认的情况下才会移动左边界。当在前面还有字节未接收但收到后面字节的情况下,窗口不会移动,并不对后续字节确认。以此确保对端会对这些数据重传。

滑动窗口的流控特性

TCP的滑动窗口是动态的,我们可以想象成小学常见的一个数学题,一个水池,体积V,每小时进水量V1,出水量V2。当水池满了就不允许再注入了,如果有个液压系统控制水池大小,那么就可以控制水的注入速率和量。这样的水池就类似TCP的窗口。应用根据自身的处理能力变化,通过本端TCP接收窗口大小控制来对对对端的发送窗口流量限制。

应用程序在需要(如内存不足)时,通过API通知TCP协议栈缩小TCP的接收窗口。然后TCP协议栈在下个段发送时包含新的窗口大小通知给对端,对端按通知的窗口来改变发送窗口,以此达到减缓发送速率的目的

0 106
链接:https://www.zhihu.com/question/19577317/answer/103499193

https是什么?

https, 全称Hyper Text Transfer Protocol Secure,相比http,多了一个secure,这一个secure是怎么来的呢?这是由TLS(SSL)提供的,这个又是什么呢?估计你也不想知道。大概就是一个叫openSSL的library提供的。https和http都属于application layer,基于TCP(以及UDP)协议,但是又完全不一样。TCP用的port是80, https用的是443(值得一提的是,google发明了一个新的协议,叫QUIC,并不基于TCP,用的port也是443, 同样是用来给https的。谷歌好牛逼啊。)总体来说,https和http类似,但是比http安全。

https做得怎么样?

一般来说网络安全关心三个问题, CIA, (confidentiality, integrity, availability)。那https在这三方面做的怎么样呢?https保证了confidentiality(你浏览的页面的内容如果被人中途看见,将会是一团乱码。不会发生比如和你用同一个无线网的人收到一个你发的数据包,打开来一看,就是你的密码啊银行卡信息啊),intergrity(你浏览的页面就是你想浏览的,不会被黑客在中途修改,网站收到的数据包也是你最初发的那个,不会把你的数据给换掉,搞一个大新闻),最后一个availability几乎没有提供(虽然我个人认为会增加基础DOS等的难度,但是这个不值一提),不过https还提供了另一个A, authentication(你连接的是你连接的网站,而不是什么人在中途伪造了一个网站给你,专业上叫Man In The Middle Attack)。那https具体保护了啥?简单来说,保护了你从连接到这个网站开始,到你关闭这个页面为止,你和这个网站之间收发的所有信息,就连url的一部分都被保护了。同时DNS querying这一步也被保护了,不会发生你输入www.google.com,实际上跑到了另一个网站去了。(这个其实也属于authentication,我这里不是很确定,最开始还写错了一次,应该来说,https保护了DNS Spoofing 和DNS Cache Poisoning等DNS攻击)那么有哪些没有被保护的?你是谁,你访问了什么网站(这个就是anonymity,想要上不好的网站但是不被人知道?可以用VPN或者TOR,当然可能要付出金钱或者速度变慢的代价啦。)

https怎么做到的?

这个就很复杂了。有兴趣的朋友可以看一下这个“The First Few Milliseconds of an HTTPS Connection”。我来简单介绍一下里面的一些手段。比如你如何确信这个网站是一个好网站?好网站就会有一个“好网站证书”,也就是certification,这个证书是由CA(certificate authority)颁布的,每次链接,网站都先去找CA拿一份证书,然后把这个证书一起发给客户,来证明自己的清白。也许你会问,万一是一个坏网站自己伪造的证书呢?这就要牵扯到RSA的公钥,私钥加密。不过,google的https是他们自己公司的一个CA发的,感觉怪怪的。总之,你基本可以相信这是一个好网站(历史上也有CA被入侵之类的事件发生)。这就是authentication(应该也是保护DNS的一步)。当然你也会需要向网站证明一下你自己的身份,然后你们就要决定用什么方式加密。加密的方式有很多种,比如各种AES啦什么的。客户告诉网站,我的浏览器支持哪些加密方式,然后网站选择其中一种,于是你们之间的数据就被加密了。你问我怎么选择的?我告诉你是随机的。你问我是伪随机吗,我不知道,伪随机的话会不会有一种qd的感觉?总之,这就是confidentiality。那怎么保证你的数据不被修改呢?这就要说到hash,hash算法可以把一个长长的数据变短,一般情况下,不同的长数据变成的短数据,是不一样的。哪怕长数据里面只变化了一点点,短数据也会差别很大(专业术语叫avalanche effect)。传输数据的时候,把这个短数据一并传了,对方就可以知道整个数据包是否被修改。当然这需要双方都提前知道一些并没有被传输的秘密。常用的hash有md5和SHA256等,md5相对来说不安全,length extenstion attack和collision都很容易。总之,这样一来,你可以知道中途数据没有被修改。这就是integrity。

https足够安全吗?

最后这个https足够安全吗?世界上没有绝对的安全,首先我提到过,https本身不保证availability,而且别人也能知道你在上这个网站。同时,https本身想保护的东西也不是那么靠谱。例如赫赫有名的heartbleed,2014年的时候席卷全球。数据显示,前100的网站(我也不晓得怎么排的),44个受到heartbleed威胁,其中就有雅虎,stackoverflow这样的网站。当然我觉得黑客是不会黑掉stackoverflow的,黑掉了以后自己写程序遇到bug都不知道怎么办了。直到今天,还有的网站没有修复这个bug,而一些已经修复的网站,因为没有及时更换private key等原因,自以为安全了,其实和没修复一个样。当然,还有各种各样的安全隐患。比如提到的RSA加密,在某些情况下可以用wiener attack破解。其他的例如入侵CA,或者直接入侵用户的电脑(例如用ssh开remote root shell等)都非常有可能。一定还有很多真正的“黑”科技,答主也不了解了。

总结一下,https对于大部分人来说,意味着比较安全。相比http,让人更加放心。但是作为普通网民,无论在上什么网站,http还是https的时候,可都不能掉以轻心哦!安全隐患无处不在。

synchronized 为什么不能使用string对象而是要使用string.intern

Jarvis.y 2020-11-05 23:12:28 198 收藏
分类专栏: java多线程相关 文章标签: java 多线程
版权
先看代码:

/**
* Created by Jarvis.y on 2020/11/5
*/
public class StringTest {

 

public static void main(String[] args) {
String s1 = “Jarvis.y”;
String s2 = new String(“Jarvis.y”);
System.out.println(s1.equals(s2));
System.out.println(System.identityHashCode(s1));
System.out.println(System.identityHashCode(s2));
System.out.println(System.identityHashCode(s1.intern()));
System.out.println(System.identityHashCode(s2.intern()));
}
}

运行效果:

true
1870252780
1729199940
1870252780
1870252780

结论:
1、String 重写了equals 方法。所以不同对象但是值相等的时候在equals比较也会返回true,但是hashcode 不一定会相等。
2、synchronized 锁的是对象,这个时候string值相同,但是不同对象,所以就无法锁住。
3、所以使用String 的时候需要使用intern方法。intern是一个 native 的方法,如果常量池中存在当前字符串, 就会直接返回当前字符串. 如果常量池中没有此字符串, 会将此字符串放入常量池中后,再返回,因此intern每次返回同一个对象。这个时候使用synchronized 就可以锁住了。

原文链接:https://blog.csdn.net/weixin_38024782/article/details/109522726