Home 网络编程(I/O)

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

深入理解什么是端口(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 属于广泛应用的标准协议, 从而得到了广泛支持.

原来 8 张图,就可以搞懂「零拷贝」了 – 知乎 (zhihu.com)

深入剖析Linux IO原理和几种零拷贝机制的实现 – 知乎 (zhihu.com)

前情提要

在学习Netty时,了解到其底层模型是NIO,同时还用到了零拷贝技术,所以特此学习零拷贝。本文复制链接如上,注为我所做


一、DMA技术

磁盘可以说是计算机系统最慢的硬件之一,读写速度相差内存 10 倍以上,所以针对优化磁盘的技术非常的多,比如零拷贝、直接 I/O、异步 I/O 等等,这些优化的目的就是为了提高系统的吞吐量,另外操作系统内核中的磁盘高速缓存区,可以有效的减少磁盘的访问次数。

注:磁盘读写非常慢,因此出现了零拷贝、直接I/O、异步I/O、DMA、缓存等优化技术

这次,我们就以「文件传输」作为切入点,来分析 I/O 工作方式,以及如何优化传输文件的性能。

为什么要有 DMA 技术?

在没有 DMA 技术前,I/O 的过程是这样的:

  • CPU 发出对应的指令给磁盘控制器,然后返回;
  • 磁盘控制器收到指令后,于是就开始准备数据,会把数据放入到磁盘控制器的内部缓冲区中,然后产生一个中断
  • CPU 收到中断信号后,停下手头的工作,接着把磁盘控制器的缓冲区的数据一次一个字节地读进自己的寄存器,然后再把寄存器里的数据写入到内存,而在数据传输的期间 CPU 是无法执行其他任务的。

为了方便你理解,我画了一副图:

可以看到,整个数据的传输过程,都要需要 CPU 亲自参与搬运数据的过程,而且这个过程,CPU 是不能做其他事情的。

简单的搬运几个字符数据那没问题,但是如果我们用千兆网卡或者硬盘传输大量数据的时候,都用 CPU 来搬运的话,肯定忙不过来。

注:没有DMA技术时,CPU需要进行发送指令、响应IO中断、从磁盘控制器的缓冲区读取数据到CPU寄存器,再将数据写到用户缓冲区

计算机科学家们发现了事情的严重性后,于是就发明了 DMA 技术,也就是直接内存访问(Direct Memory Access 技术。

什么是 DMA 技术?简单理解就是,在进行 I/O 设备和内存的数据传输的时候,数据搬运的工作全部交给 DMA 控制器,而 CPU 不再参与任何与数据搬运相关的事情,这样 CPU 就可以去处理别的事务

那使用 DMA 控制器进行数据传输的过程究竟是什么样的呢?下面我们来具体看看。

具体过程:

  • 用户进程调用 read 方法,向操作系统发出 I/O 请求,请求读取数据到自己的内存缓冲区中,进程进入阻塞状态;
  • 操作系统收到请求后,进一步将 I/O 请求发送 DMA,然后让 CPU 执行其他任务;
  • DMA 进一步将 I/O 请求发送给磁盘;
  • 磁盘收到 DMA 的 I/O 请求,把数据从磁盘读取到磁盘控制器的缓冲区中,当磁盘控制器的缓冲区被读满后,向 DMA 发起中断信号,告知自己缓冲区已满;
  • DMA 收到磁盘的信号,将磁盘控制器缓冲区中的数据拷贝到内核缓冲区中,此时不占用 CPU,CPU 可以执行其他任务
  • 当 DMA 读取了足够多的数据,就会发送中断信号给 CPU;
  • CPU 收到 DMA 的信号,知道数据已经准备好,于是将数据从内核拷贝到用户空间,系统调用返回;

可以看到, 整个数据传输的过程,CPU 不再参与数据搬运的工作,而是全程由 DMA 完成,但是 CPU 在这个过程中也是必不可少的,因为传输什么数据,从哪里传输到哪里,都需要 CPU 来告诉 DMA 控制器。

早期 DMA 只存在在主板上,如今由于 I/O 设备越来越多,数据传输的需求也不尽相同,所以每个 I/O 设备里面都有自己的 DMA 控制器。

注:用户向CPU发起IO请求—>CPU向DMA发送IO请求—>DMA从磁盘中读取数据到磁盘控制器缓冲区,再写入到内核缓存区—>DMA发送中断信号给CPU—>CPU将数据从内核拷贝到用户空间,系统调用返回。
注:有了DMA,CPU只用发送IO请求,响应中断,把内核缓冲区的数据写入到用户缓冲区


二、传统的文件传输

如果服务端要提供文件传输的功能,我们能想到的最简单的方式是:将磁盘上的文件读取出来,然后通过网络协议发送给客户端。

传统 I/O 的工作方式是,数据读取和写入是从用户空间到内核空间来回复制,而内核空间的数据是通过操作系统层面的 I/O 接口从磁盘读取或写入。

代码通常如下,一般会需要两个系统调用:

read(file, tmp_buf, len);
write(socket, tmp_buf, len);

代码很简单,虽然就两行代码,但是这里面发生了不少的事情。

首先,期间共发生了 4 次用户态与内核态的上下文切换,因为发生了两次系统调用,一次是 read() ,一次是 write(),每次系统调用都得先从用户态切换到内核态,等内核完成任务后,再从内核态切换回用户态。

上下文切换到成本并不小,一次切换需要耗时几十纳秒到几微秒,虽然时间看上去很短,但是在高并发的场景下,这类时间容易被累积和放大,从而影响系统的性能。

其次,还发生了 4 次数据拷贝,其中两次是 DMA 的拷贝,另外两次则是通过 CPU 拷贝的,下面说一下这个过程:

  • 第一次拷贝,把磁盘上的数据拷贝到操作系统内核的缓冲区里,这个拷贝的过程是通过 DMA 搬运的。
  • 第二次拷贝,把内核缓冲区的数据拷贝到用户的缓冲区里,于是我们应用程序就可以使用这部分数据了,这个拷贝到过程是由 CPU 完成的。
  • 第三次拷贝,把刚才拷贝到用户的缓冲区里的数据,再拷贝到内核的 socket 的缓冲区里,这个过程依然还是由 CPU 搬运的。
  • 第四次拷贝,把内核的 socket 缓冲区里的数据,拷贝到网卡的缓冲区里,这个过程又是由 DMA 搬运的。

我们回过头看这个文件传输的过程,我们只是搬运一份数据,结果却搬运了 4 次,过多的数据拷贝无疑会消耗 CPU 资源,大大降低了系统性能。

这种简单又传统的文件传输方式,存在冗余的上文切换和数据拷贝,在高并发系统里是非常糟糕的,多了很多不必要的开销,会严重影响系统性能。

所以,要想提高文件传输的性能,就需要减少「用户态与内核态的上下文切换」和「内存拷贝」的次数

注:传统的文件传输发送了4次用户态和内核态的上下文切换(两次系统调用,一次read,一次write),还发生了4次数据拷贝(两次DMA拷贝,两次CPU拷贝)


三、如何优化文件传输的性能?

先来看看,如何减少「用户态与内核态的上下文切换」的次数呢?

读取磁盘数据的时候,之所以要发生上下文切换,这是因为用户空间没有权限操作磁盘或网卡,内核的权限最高,这些操作设备的过程都需要交由操作系统内核来完成,所以一般要通过内核去完成某些任务的时候,就需要使用操作系统提供的系统调用函数。

而一次系统调用必然会发生 2 次上下文切换:首先从用户态切换到内核态,当内核执行完任务后,再切换回用户态交由进程代码执行。

所以,要想减少上下文切换到次数,就要减少系统调用的次数

再来看看,如何减少「数据拷贝」的次数?

在前面我们知道了,传统的文件传输方式会历经 4 次数据拷贝,而且这里面,「从内核的读缓冲区拷贝到用户的缓冲区里,再从用户的缓冲区里拷贝到 socket 的缓冲区里」,这个过程是没有必要的。

因为文件传输的应用场景中,在用户空间我们并不会对数据「再加工」,所以数据实际上可以不用搬运到用户空间,因此用户的缓冲区是没有必要存在的

注:减少数据拷贝的次数。可以直接将数据从内核态拷贝到网卡缓冲区。

 


 

四、零拷贝(减少上下文切换和数据拷贝)

零拷贝技术实现的方式通常有 2 种:

  • mmap + write
  • sendfile

注:实际上可以有很多种方式,只要能减少上下文切换和数据拷贝的次数即可

下面就谈一谈,它们是如何减少「上下文切换」和「数据拷贝」的次数。

mmap + write

在前面我们知道,read() 系统调用的过程中会把内核缓冲区的数据拷贝到用户的缓冲区里,于是为了减少这一步开销,我们可以用 mmap() 替换 read() 系统调用函数。

buf = mmap(file, len);
write(sockfd, buf, len);

mmap() 系统调用函数会直接把内核缓冲区里的数据「映射」到用户空间,这样,操作系统内核与用户空间就不需要再进行任何的数据拷贝操作。

注:直接内存映射。Linux提供的mmap系统调用, 它可以将一段用户空间内存映射到内核空间, 当映射成功后, 用户对这段内存区域的修改可以直接反映到内核空间;同样地, 内核空间对这段区域的修改也直接反映用户空间。正因为有这样的映射关系, 就不需要在用户态(User-space)与内核态(Kernel-space) 之间拷贝数据, 提高了数据传输的效率,这就是内存直接映射技术

具体过程如下:

  • 应用进程调用了 mmap() 后,DMA 会把磁盘的数据拷贝到内核的缓冲区里。接着,应用进程跟操作系统内核「共享」这个缓冲区;
  • 应用进程再调用 write(),操作系统直接将内核缓冲区的数据拷贝到 socket 缓冲区中,这一切都发生在内核态,由 CPU 来搬运数据;
  • 最后,把内核的 socket 缓冲区里的数据,拷贝到网卡的缓冲区里,这个过程是由 DMA 搬运的。

我们可以得知,通过使用 mmap() 来代替 read(), 可以减少一次数据拷贝的过程。

但这还不是最理想的零拷贝,因为仍然需要通过 CPU 把内核缓冲区的数据拷贝到 socket 缓冲区里,而且仍然需要 4 次上下文切换,因为系统调用还是 2 次。

注:直接内存映射mmap()减少一次CPU拷贝

sendfile

在 Linux 内核版本 2.1 中,提供了一个专门发送文件的系统调用函数 sendfile(),函数形式如下:

#include <sys/socket.h>
ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);

它的前两个参数分别是目的端和源端的文件描述符,后面两个参数是源端的偏移量和复制数据的长度,返回值是实际复制数据的长度。

首先,它可以替代前面的 read()write() 这两个系统调用,这样就可以减少一次系统调用,也就减少了 2 次上下文切换的开销。

其次,该系统调用,可以直接把内核缓冲区里的数据拷贝到 socket 缓冲区里,不再拷贝到用户态,这样就只有 2 次上下文切换,和 3 次数据拷贝。如下图:

但是这还不是真正的零拷贝技术,如果网卡支持 SG-DMA(The Scatter-Gather Direct Memory Access)技术(和普通的 DMA 有所不同),我们可以进一步减少通过 CPU 把内核缓冲区里的数据拷贝到 socket 缓冲区的过程。

你可以在你的 Linux 系统通过下面这个命令,查看网卡是否支持 scatter-gather 特性:

$ ethtool -k eth0 | grep scatter-gather
scatter-gather: on

于是,从 Linux 内核 2.4 版本开始起,对于支持网卡支持 SG-DMA 技术的情况下, sendfile() 系统调用的过程发生了点变化,具体过程如下:

  • 第一步,通过 DMA 将磁盘上的数据拷贝到内核缓冲区里;
  • 第二步,缓冲区描述符和数据长度传到 socket 缓冲区,这样网卡的 SG-DMA 控制器就可以直接将内核缓存中的数据拷贝到网卡的缓冲区里,此过程不需要将数据从操作系统内核缓冲区拷贝到 socket 缓冲区中,这样就减少了一次数据拷贝;

所以,这个过程之中,只进行了 2 次数据拷贝,如下图:

这就是所谓的零拷贝(Zero-copy)技术,因为我们没有在内存层面去拷贝数据,也就是说全程没有通过 CPU 来搬运数据,所有的数据都是通过 DMA 来进行传输的。

零拷贝技术的文件传输方式相比传统文件传输的方式,减少了 2 次上下文切换和数据拷贝次数,只需要 2 次上下文切换和数据拷贝次数,就可以完成文件的传输,而且 2 次的数据拷贝过程,都不需要通过 CPU,2 次都是由 DMA 来搬运。

所以,总体来看,零拷贝技术可以把文件传输的性能提高至少一倍以上


使用零拷贝技术的项目

Kafka、Nginx等


PageCache 有什么作用?(磁盘高速缓存)

回顾前面说道文件传输过程,其中第一步都是先需要先把磁盘文件数据拷贝「内核缓冲区」里,这个「内核缓冲区」实际上是磁盘高速缓存(PageCache

由于零拷贝使用了 PageCache 技术,可以使得零拷贝进一步提升了性能,我们接下来看看 PageCache 是如何做到这一点的。

读写磁盘相比读写内存的速度慢太多了,所以我们应该想办法把「读写磁盘」替换成「读写内存」。于是,我们会通过 DMA 把磁盘里的数据搬运到内存里,这样就可以用读内存替换读磁盘。

但是,内存空间远比磁盘要小,内存注定只能拷贝磁盘里的一小部分数据。

那问题来了,选择哪些磁盘数据拷贝到内存呢?

我们都知道程序运行的时候,具有「局部性」,所以通常,刚被访问的数据在短时间内再次被访问的概率很高,于是我们可以用 PageCache 来缓存最近被访问的数据,当空间不足时淘汰最久未被访问的缓存。

所以,读磁盘数据的时候,优先在 PageCache 找,如果数据存在则可以直接返回;如果没有,则从磁盘中读取,然后缓存 PageCache 中。

还有一点,读取磁盘数据的时候,需要找到数据所在的位置,但是对于机械磁盘来说,就是通过磁头旋转到数据所在的扇区,再开始「顺序」读取数据,但是旋转磁头这个物理动作是非常耗时的,为了降低它的影响,PageCache 使用了「预读功能」

比如,假设 read 方法每次只会读 32 KB 的字节,虽然 read 刚开始只会读 0 ~ 32 KB 的字节,但内核会把其后面的 32~64 KB 也读取到 PageCache,这样后面读取 32~64 KB 的成本就很低,如果在 32~64 KB 淘汰出 PageCache 前,进程读取到它了,收益就非常大。

所以,PageCache 的优点主要是两个:

  • 缓存最近被访问的数据;
  • 预读功能;

这两个做法,将大大提高读写磁盘的性能。

但是,在传输大文件(GB 级别的文件)的时候,PageCache 会不起作用,那就白白浪费 DMA 多做的一次数据拷贝,造成性能的降低,即使使用了 PageCache 的零拷贝也会损失性能

这是因为如果你有很多 GB 级别文件需要传输,每当用户访问这些大文件的时候,内核就会把它们载入 PageCache 中,于是 PageCache 空间很快被这些大文件占满。

另外,由于文件太大,可能某些部分的文件数据被再次访问的概率比较低,这样就会带来 2 个问题:

  • PageCache 由于长时间被大文件占据,其他「热点」的小文件可能就无法充分使用到 PageCache,于是这样磁盘读写的性能就会下降了;
  • PageCache 中的大文件数据,由于没有享受到缓存带来的好处,但却耗费 DMA 多拷贝到 PageCache 一次;

所以,针对大文件的传输,不应该使用 PageCache,也就是说不应该使用零拷贝技术,因为可能由于 PageCache 被大文件占据,而导致「热点」小文件无法利用到 PageCache,这样在高并发的环境下,会带来严重的性能问题。


大文件传输用什么方式实现?

那针对大文件的传输,我们应该使用什么方式呢?

我们先来看看最初的例子,当调用 read 方法读取文件时,进程实际上会阻塞在 read 方法调用,因为要等待磁盘数据的返回,如下图:

具体过程:

  • 当调用 read 方法时,会阻塞着,此时内核会向磁盘发起 I/O 请求,磁盘收到请求后,便会寻址,当磁盘数据准备好后,就会向内核发起 I/O 中断,告知内核磁盘数据已经准备好;
  • 内核收到 I/O 中断后,就将数据从磁盘控制器缓冲区拷贝到 PageCache 里;
  • 最后,内核再把 PageCache 中的数据拷贝到用户缓冲区,于是 read 调用就正常返回了。

对于阻塞的问题,可以用异步 I/O 来解决,它工作方式如下图:

它把读操作分为两部分:

  • 前半部分,内核向磁盘发起读请求,但是可以不等待数据就位就可以返回,于是进程此时可以处理其他任务;
  • 后半部分,当内核将磁盘中的数据拷贝到进程缓冲区后,进程将接收到内核的通知,再去处理数据;

而且,我们可以发现,异步 I/O 并没有涉及到 PageCache,所以使用异步 I/O 就意味着要绕开 PageCache。

绕开 PageCache 的 I/O 叫直接 I/O,使用 PageCache 的 I/O 则叫缓存 I/O。通常,对于磁盘,异步 I/O 只支持直接 I/O。

前面也提到,大文件的传输不应该使用 PageCache,因为可能由于 PageCache 被大文件占据,而导致「热点」小文件无法利用到 PageCache。

于是,在高并发的场景下,针对大文件的传输的方式,应该使用「异步 I/O + 直接 I/O」来替代零拷贝技术

直接 I/O 应用场景常见的两种:

  • 应用程序已经实现了磁盘数据的缓存,那么可以不需要 PageCache 再次缓存,减少额外的性能损耗。在 MySQL 数据库中,可以通过参数设置开启直接 I/O,默认是不开启;
  • 传输大文件的时候,由于大文件难以命中 PageCache 缓存,而且会占满 PageCache 导致「热点」文件无法充分利用缓存,从而增大了性能开销,因此,这时应该使用直接 I/O。

另外,由于直接 I/O 绕过了 PageCache,就无法享受内核的这两点的优化:

  • 内核的 I/O 调度算法会缓存尽可能多的 I/O 请求在 PageCache 中,最后「合并」成一个更大的 I/O 请求再发给磁盘,这样做是为了减少磁盘的寻址操作;
  • 内核也会「预读」后续的 I/O 请求放在 PageCache 中,一样是为了减少对磁盘的操作;

于是,传输大文件的时候,使用「异步 I/O + 直接 I/O」了,就可以无阻塞地读取文件了。

所以,传输文件的时候,我们要根据文件的大小来使用不同的方式:

  • 传输大文件的时候,使用「异步 I/O + 直接 I/O」;
  • 传输小文件的时候,则使用「零拷贝技术」;

在 nginx 中,我们可以用如下配置,来根据文件的大小来使用不同的方式:

location /video/ { 
    sendfile on; 
    aio on; 
    directio 1024m; 
}

当文件大小大于 directio 值后,使用「异步 I/O + 直接 I/O」,否则使用「零拷贝技术」。


总结

早期 I/O 操作,内存与磁盘的数据传输的工作都是由 CPU 完成的,而此时 CPU 不能执行其他任务,会特别浪费 CPU 资源。

于是,为了解决这一问题,DMA 技术就出现了,每个 I/O 设备都有自己的 DMA 控制器,通过这个 DMA 控制器,CPU 只需要告诉 DMA 控制器,我们要传输什么数据,从哪里来,到哪里去,就可以放心离开了。后续的实际数据传输工作,都会由 DMA 控制器来完成,CPU 不需要参与数据传输的工作。

传统 IO 的工作方式,从硬盘读取数据,然后再通过网卡向外发送,我们需要进行 4 上下文切换,和 4 次数据拷贝,其中 2 次数据拷贝发生在内存里的缓冲区和对应的硬件设备之间,这个是由 DMA 完成,另外 2 次则发生在内核态和用户态之间,这个数据搬移工作是由 CPU 完成的。

为了提高文件传输的性能,于是就出现了零拷贝技术,它通过一次系统调用(sendfile 方法)合并了磁盘读取与网络发送两个操作,降低了上下文切换次数。另外,拷贝数据都是发生在内核中的,天然就降低了数据拷贝的次数。

Kafka 和 Nginx 都有实现零拷贝技术,这将大大提高文件传输的性能。

零拷贝技术是基于 PageCache 的,PageCache 会缓存最近访问的数据,提升了访问缓存数据的性能,同时,为了解决机械硬盘寻址慢的问题,它还协助 I/O 调度算法实现了 IO 合并与预读,这也是顺序读比随机读性能好的原因。这些优势,进一步提升了零拷贝的性能。

需要注意的是,零拷贝技术是不允许进程对文件内容作进一步的加工的,比如压缩数据再发送。

另外,当传输大文件时,不能使用零拷贝,因为可能由于 PageCache 被大文件占据,而导致「热点」小文件无法利用到 PageCache,并且大文件的缓存命中率不高,这时就需要使用「异步 IO + 直接 IO 」的方式。

在 Nginx 里,可以通过配置,设定一个文件大小阈值,针对大文件使用异步 IO 和直接 IO,而对小文件使用零拷贝。

注:零拷贝不会经过用户空间

零拷贝是从磁盘到内核缓冲区再到网卡
大文件传输室友异步IO+直接IO(未使用PageCache)

 

最近系统的学习了网络编程的相关知识,当然也离不开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的Socket项目的时候,想把简单的聊天室往消息队列的方向靠拢,因此在考虑怎么记录每个客户端所发送的消息(即实现聊天记录的保存功能)

客户端发送消息— 服务器端接收 转发 存储—-目标客户端

服务器接收转发我使用的是Read线程转发即可,那么存储呢?一开始的想法是,要不存储在内存中,即创建HashMap<senderName,msgList>来保存

具体如下:

<橙汁,List<“消息一”,“消息二”…>>

<小阮,List<“消息一”,”消息二”…>>

代码如下:

这样的实现好处在于:简单,明了。客户端将消息发送给服务器,服务器做转发,同时存入msgMemoryMap(全局变量);由于我的网络通信模型是使用的Bio,服务器循环监听,每来一个客户端就创建一个对应的读线程,而这些步骤也是在读线程里面完成的

也就是说 客户端A的消息存入 和客户端B的消息存入不是同一个线程实现的(当然已经使用了线程池进行优化,此处是有隐患的,如果客户端太多那么服务器就要创建很多线程),因为效率上不用太过担心

更高效的序列化

在存入msgMemoryMap之前,我将原来的Serialize序列化方式改为了Protostuff序列化,因为存入消息实在太占用内存了…

如果使用Serialize序列化,平均每条消息要占用300个字节(300B)这还得期望聊天用户发送的消息都是短消息,如果长消息那更恐怖,我计算了一下,如果同时有1000个用户在聊天,每人发送1条,也就是1*1000*300 = 300Kb!这个内存占用实在是太可怕了,因此我不得不考虑更高效的序列化方式,即Protostuff,关于Protostuff的文章会在之后写出,目前只需要知道它的序列化更高效且生成的byte数组大小更小,差不多是Serialize生成的十分之一,那么接下来直接看测试代码:

 

这样仿佛解决了写入的消息占用内存过大的问题?其实还可以进一步优化,比如再优化MessageRedis类的字段,或者先压缩再存入msgMemoryMap,等需要拿出来使用的时候再解压,也就是“时间换空间”的想法,听上去好像使用msgMemoryMap只要解决了内存占用问题就好了,其实并不然,因为内存具有掉电即失的特性。

任何实际开发的项目都不可能将数据简单的写在内存,必须要进行持久化,不然你的用户使用你的聊天室向其他人发送重要的资料和文件,等到后面他需要取查看这些消息的时候,却发现居然全丢了。持久化,欸,会做啊,我写入到数据库去不就不会丢失了嘛。

写入数据库有两种策略:

1.每来一条消息,服务器做转发后,将其写入到数据库;

2.每来一条消息,服务器将其写入到数据库后,再做转发;

我们来分析一下这两种策略,假设是 用户 橙汁 发送给 小阮的一条消息 ;

          策略1 :

           服务器先转发,那挺好,小阮可以立刻收到橙汁所发送的消息,然后橙汁的这条消息写入数据库,完美保存;橙汁第二条消息来的时候重复这个逻辑,因为橙汁发送消息中间是有间隔的,也就是不可能一直不停的发(假设消息有意义),那么这个间隔时间足够橙汁将第一条消息写入数据库了,到此,消息既转发了又保存了,服务器完成一次操作的时间为(T转发 + T存入)。

           似乎万事大吉?其实不然,现在都追求高可用,高并发,高可靠,我们的系统也不能落下。很显然目前的策略没有满足高并发和高可用,因为如果在服务器收到消息并转发后,断电了怎么办?消息并没有被写入数据库,如果小阮收到了消息,比如是 “明天一起去吃饭吧” 然后橙汁把这事忘了,第二天小阮来算账,说 “你昨天说的今天一起吃饭啊”;橙汁说:“噢 是吗? 我看看聊天记录”,结果消息记录居然真的没有!橙汁确实说了这句话,也就是说我们的系统会出现很多很多比这更复杂的问题,那么怎么解决呢?

                 策略2:

                  服务器先写入,再转发,如果写入失败则重试(或者其他策略),直到成功后再转发;这样的话,如果小阮收到了这条消息,一定和数据库中 的是一样的;同样的,如果写入数据库之后断电了,消息没被转发怎么办?只需要标记消息是否转发成功,如果没有的话就重新转发,可以从数据库去获取,不怕数据丢了,当然这里设计还可以详细展开。

分析了两种策略,如果是更追求消息一致性的话,优先选择策略2,当然策略2只是一个简版(悄咪咪的告诉你,这两个策略借鉴了Redis和Mysql的设计思路)

在上述策略的基础上继续思考,写入数据库是可以实现,但是不可忽略数据库的压力

数据库OS:对啊,你想的倒是好,每个线程都写数据库,如果采用策略2还需要从我身上拉取信息,线程压力小了,我数据库的压力大了喂,快找点人替我分担

 

是的,为了缓解数据库的压力,同时又可以完成我们的持久化功能,同时操作起来还快

缓存中间件:你他妈直接报我身份证得了

 

因此,我们可以采用Redis 来实现我们的需求—在转发消息的同时持久化保存消息

一样的:

1.每来一条消息,服务器做转发后,将其写入到Redis;

2.每来一条消息,服务器将其写入到Redis后,再做转发;

            策略1:服务器转发后,写入到Redis,Redis操作起来更快,对其上述写入数据库的策略1来说,就是T保存(保存需要的时间)更短了。如果转发完成后,断电了,没有写入到Redis,这里也会有问题,先按下不表

            策略2:先写入Redis,再转发,因为T保存的时间更短,写入Redis后转发失败的可能性就更小了,同样的,可以在接收消息的客户端设置一个接收反馈,接收到了反馈,没接收到的话这样服务器也知道,可以重发;

Redis的持久化功能保证了即使Redis所在的服务器机器掉电了,也不会丢失太多数据,丢失的数量取决了我们所采用的Redis持久化策略,比如是使用AOF还是使用RDB,其参数设置,以及是否做了Redis集群等等。

好啦,先介绍到这里啦~

0 21

今天在编写项目的时候遇到一个问题,特此记录

 

首先我的客户端向服务器端发送消息,告知其我需要得到当前所有连接的客户端列表

当时序列化会出错,而将object换成具体的list即可返回了

 

也就是说,如果需要序列化某个对象(该对象其中包含非基本数据类型)的话,最好还是清晰的定义该非基本数据类型,定义成Object可能会出问题

编程的时候遇到的

 

使用java的对象流出现java.io.StreamCorruptedException: invalid stream header异常

原因是数据发送端发送对象到接收端

接收端对于同一个输入流创建了不同的对象输入流,而后用不同的对象输入流进行接收

 

例子:

也就是说对对象的序列化和反序列化应当由同一组包装流来实现!!

在完成自己的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 18

https://blog.csdn.net/u012250875/article/details/78341874 

【java】IO详解之BIO

 

https://blog.csdn.net/zoe_ranxiaosu/article/details/82117782

jAVAIO流

 

https://blog.csdn.net/weixin_50205273/article/details/108590394?utm_medium=distribute.pc_relevant.none-task-blog-2~default~baidujs_title~default-1.essearch_pc_relevant&spm=1001.2101.3001.4242.2

JavaIO流

 

https://www.cnblogs.com/cmyxn/p/6360474.html

Socket与tcp与http

 

https://www.cnblogs.com/freebrid/p/4703096.html

监听套接字 连接套接字

https://blog.csdn.net/qq_21125183/article/details/83831495

Nio详解

https://www.jianshu.com/p/8ad464ed516e

Bio

https://blog.csdn.net/a78270528/article/details/80318571

Java 网络编程 之 socket 的用法与实现

0 18

主要有以下两种方式,我们来看一下

方式一:

Socket s=new Socket();
s.connect(new InetSocketAddress(host,port),10000);

方式二:

Socket s=new Socket("127.0.0.1",8080);
s.setSoTimeout(10000);

 

那么这两种方式设置的超时时间各自代表了什么意义呢?有什么区别呢?

第一种方式

我们先来看一下第1种方式,我们来测试一下:

在 main 方法中我们创建 Socket 连接到

ip :29.212.19.201,端口:2132

public static void main(String[] args) {
  Socket socket = new Socket();
  SocketAddress endpoint = new InetSocketAddress("29.212.19.201", 2132);
  long timeMillis = System.currentTimeMillis();
try {
socket.connect(endpoint, 10000);
} catch (IOException e) {
e.printStackTrace();
}
System.out.println(System.currentTimeMillis()-timeMillis);
System.out.println("end");
}

运行这段代码,控制台10秒之前没有任何信息输出,10秒后打印如下信息:

10002
java.net.SocketTimeoutException: connect timed out
at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method)
at java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:85)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at com.wakling.cn.SocketSever.main(SocketSever.java:33)
end

可以看出,我们尝试连接到29.212.19.201:2132时,连接了10秒都没有连接上,于是就报了 java.net.SocketTimeoutException: connect timed out 的异常。

解释一下,上述的 IP 是一个未知的 IP ,即我的 IP 在当前网络环境中访问不到这个 IP ,这样我们的这个 Socket 才会去一直尝试连接到此 IP 直到超时。如果 IP 是一个已知的 IP ,例如本地 127.0.0.1 加上一个未知的端口,那么此 Socket 连接会立马报错。另外,在不设置连接超时时间的情况下,Socket 默认大概是21s(测试了3次都是21020毫秒)连接超时。如下是不设置连接超时时间的代码:
Socket socket = new Socket("29.212.19.201", 2132);

 

第二种方式

然后我们来看一下第2种方式,这时候我们需要在我们本地写一套 Socket 服务以及客户端来模拟这个场景。

我们让客户端设置 setSoTimeout 为10s,在服务端代码拿到客户端请求信息后,休眠10s后再处理客户端请求,返回响应。

我们来看一下效果,关键代码如下:

//服务端
System.out.println("进入休眠,10s后醒来");
Thread.sleep(10000);
System.out.println("休眠结束");
//返回响应
OutputStream outputStream = socket.getOutputStream();// 获取一个输出流,向服务端发送信息
PrintWriter printWriter = new PrintWriter(outputStream);// 将输出流包装成打印流
printWriter.print("你好,服务端已接收到您的信息");
printWriter.flush();

//客户端
Socket socket = new Socket("127.0.0.1",2132);
socket.setSoTimeout(10000);//read的超时时间

运行后,等待客户端输出,10s后客户端控制台输出信息如下:

java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
at java.io.InputStreamReader.read(InputStreamReader.java:184)
at java.io.BufferedReader.fill(BufferedReader.java:161)
at java.io.BufferedReader.readLine(BufferedReader.java:324)
at java.io.BufferedReader.readLine(BufferedReader.java:389)
at com.wakling.cn.SocketClient.main(SocketClient.java:36)
10020
end

这里10s后客户端报错 java.net.SocketTimeoutException: Read timed out 查看客户端控制台信息正常输出,即使客户端已报超时,服务端仍然继续往下走,只是客户端已经收不到服务端10s后发给自己的消息。

另外经测试发现,服务端休眠很久很久,如500s,在客户端不设置 setSoTimeout 时,默认120s超时。

区别和意义
下面我们就来说一说二者的意义和区别。

方式1是客户端与服务端进行连接的超时时间,即10秒内建立不了连接就报java.net.SocketTimeoutException: connect timed out 连接超时的异常。此时二者未建立连接,更别说服务端收到客户端的消息了。

方式2是设置 inputStream.read() 方法的阻塞时间,即客户端发出请求后等待服务端返回响应的等待时长,超过这个时长将会引发 java.net.SocketTimeoutException: Read timed out 异常。此时二者正常建立连接,服务端接收到了客户端的请求。

两种方式控制超时的侧重点不同,就像打电话一样,方法1是打电话10秒你不接电话我就挂了,方法2是打电话接通后,等你10秒不说话就挂,10秒后说不说话都不听了。

 

总结:

设置超时
1.设置连接请求超时时间,如果连接无响应,则抛出超时异常
2.设置读操作超时时长,如过读取数据流时间超时,则抛出异常

Socket socket = new Socket();
socket.connect(new InetSocketAddress(ipAddress, port), 1000);//设置连接请求超时时间1 s
socket.setSoTimeout(30000);//设置读操作超时时间30 s

注意:socket.setSoTimeout必须在connect之后设置,不然将不会生效。读操作将永远不会超时。(方式二)