进程间通信的方式——信号、管道、消息队列、共享内存

    1. 匿名管道pipe:管道是一种半双工的通信方式,数据只能单向流动,而且只能在具有亲缘关系的进程间使用。进程的亲缘关系通常是指父子进程关系。
    2. 命名管道FIFO:有名管道也是半双工的通信方式,但是它允许无亲缘关系进程间的通信。
    3. 消息队列MessageQueue:消息队列是由消息的链表,存放在内核中并由消息队列标识符标识。消息队列克服了信号传递信息少、管道只能承载无格式字节流以及缓冲区大小受限等缺点。
    4. 共享存储SharedMemory:共享内存就是映射一段能被其他进程所访问的内存,这段共享内存由一个进程创建,但多个进程都可以访问。共享内存是最快的 IPC 方式,它是针对其他进程间通信方式运行效率低而专门设计的。它往往与其他通信机制,如信号两,配合使用,来实现进程间的同步和通信。
    5. 信号量Semaphore:信号量是一个计数器,可以用来控制多个进程对共享资源的访问。它常作为一种锁机制,防止某进程正在访问共享资源时,其他进程也访问该资源。因此,主要作为进程间以及同一进程内不同线程之间的同步手段。
    6. 套接字Socket:套解口也是一种进程间通信机制,与其他通信机制不同的是,它可用于不同主机间的进程通信。
    7. 信号 ( sinal ) : 信号是一种比较复杂的通信方式,用于通知接收进程某个事件已经发生。

注意:在第6点socket的基础上发展出一种IPC机制,就是UNIX Domain Socket。虽然网络socket也可用于同一台主机的进程间通讯(通过loopback地址127.0.0.1),但是UNIX Domain Socket用于IPC更有效率:不需要经过网络协议栈,不需要打包拆包、计算校验和、维护序号和应答等,只是将应用层数据从一个进程拷贝到另一个进程。这是因为,IPC机制本质上是可靠的通讯,而网络协议是为不可靠的通讯设计的。

UNIX Domain Socket也提供面向流面向数据包两种API接口,类似于TCP和UDP,但是面向消息的UNIX Domain Socket也是可靠的,消息既不会丢失也不会顺序错乱

inode解释(解决linux有空间却提示磁盘空间不足的问题)

转自:
http://www.ruanyifeng.com/blog/2011/12/inode.html
http://blog.s135.com/post/295/
http://hi.baidu.com/leejun_2005/blog/item/d9aa13a53b3af6e99152ee7e.html

一、inode是什么?

理解inode,要从文件储存说起。
文件储存在硬盘上,硬盘的最小存储单位叫做”扇区”(Sector)。每个扇区储存512字节(相当于0.5KB)。
操作系统读取硬盘的时候,不会一个个扇区地读取,这样效率太低,而是一次性连续读取多个扇区,即一次性读取一个”块”(block)。这种由多个扇区组成的”块”,是文件存取的最小单位。”块”的大小,最常见的是4KB,即连续八个 sector组成一个 block。

 

文件数据都储存在”块”中,那么很显然,我们还必须找到一个地方储存文件的元信息,比如文件的创建者、文件的创建日期、文件的大小等等。这种储存文件元信息的区域就叫做inode,中文译名为”索引节点”。

二、inode的内容

inode包含文件的元信息,具体来说有以下内容:
  •   文件的字节数
  •   文件拥有者的User ID
  •   文件的Group ID
  •   文件的读、写、执行权限
  •   文件的时间戳,共有三个:
    ctime指inode上一次变动的时间,
    mtime指文件内容上一次变动的时间,
    atime指文件上一次打开的时间。
  •   链接数,即有多少文件名指向这个inode
  •   文件数据block的位置
可以用stat命令,查看某个文件的inode信息:
stat example.txt
总之,除了文件名以外的所有文件信息,都存在inode之中。至于为什么没有文件名,下文会有详细解释。

三、inode的大小

inode也会消耗硬盘空间,所以硬盘格式化的时候,操作系统自动将硬盘分成两个区域。一个是数据区,存放文件数据;另一个是inode区(inode table),存放inode所包含的信息。
每个inode节点的大小,一般是128字节或256字节。inode节点的总数,在格式化时就给定,一般是每1KB或每2KB就设置一个inode。假定在一块1GB的硬盘中,每个inode节点的大小为128字节,每1KB就设置一个inode,那么inode table的大小就会达到128MB,占整块硬盘的12.8%。
查看每个硬盘分区的inode总数和已经使用的数量,可以使用df命令。
df -i
查看每个inode节点的大小,可以用如下命令:
sudo dumpe2fs -h /dev/hda | grep "Inode size"
由于每个文件都必须有一个inode,因此有可能发生inode已经用光,但是硬盘还未存满的情况。这时,就无法在硬盘上创建新文件。

四、inode号码

每个inode都有一个号码,操作系统用inode号码来识别不同的文件。

 

这里值得重复一遍,Unix/Linux系统内部不使用文件名,而使用inode号码来识别文件。对于系统来说,文件名只是inode号码便于识别的别称或者绰号。表面上,用户通过文件名,打开文件。实际上,系统内部这个过程分成三步:首先,系统找到这个文件名对应的inode号码;其次,通过inode号码,获取inode信息;最后,根据inode信息,找到文件数据所在的block,读出数据。

使用ls -i命令,可以看到文件名对应的inode号码:

ls -i example.txt

五、目录文件

Unix/Linux系统中,目录(directory)也是一种文件。打开目录,实际上就是打开目录文件。
目录文件的结构非常简单,就是一系列目录项(dirent)的列表。每个目录项,由两部分组成:所包含文件的文件名,以及该文件名对应的inode号码。
ls命令只列出目录文件中的所有文件名:
ls /etc
ls -i命令列出整个目录文件,即文件名和inode号码:
ls -i /etc
如果要查看文件的详细信息,就必须根据inode号码,访问inode节点,读取信息。
ls -l命令列出文件的详细信息。
ls -l /etc
六、硬链接
一般情况下,文件名和inode号码是”一一对应”关系,每个inode号码对应一个文件名。但是,Unix/Linux系统允许,多个文件名指向同一个inode号码。这意味着,可以用不同的文件名访问同样的内容;对文件内容进行修改,会影响到所有文件名;但是,删除一个文件名,不影响另一个文件名的访问。这种情况就被称为”硬链接”(hard link)。

ln命令可以创建硬链接:

ln 源文件 目标文件
运行上面这条命令以后,源文件与目标文件的inode号码相同,都指向同一个inode。inode信息中有一项叫做”链接数”,记录指向该inode的文件名总数,这时就会增加1。反过来,删除一个文件名,就会使得inode节点中的”链接数”减1。当这个值减到0,表明没有文件名指向这个inode,系统就会回收这个inode号码,以及其所对应block区域。
这里顺便说一下目录文件的”链接数”。创建目录时,默认会生成两个目录项:”.”和”..”。前者的inode号码就是当前目录的inode号码,等同于当前目录的”硬链接”;后者的inode号码就是当前目录的父目录的inode号码,等同于父目录的”硬链接”。所以,任何一个目录的”硬链接”总数,总是等于2加上它的子目录总数(含隐藏目录),这里的2是父目录对其的“硬链接”和当前目录下的”.硬链接“。

七、软链接

除了硬链接以外,还有一种特殊情况。文件A和文件B的inode号码虽然不一样,但是文件A的内容是文件B的路径。读取文件A时,系统会自动将访问者导向文件B。因此,无论打开哪一个文件,最终读取的都是文件B。这时,文件A就称为文件B的”软链接”(soft link)或者”符号链接(symbolic link)。
这意味着,文件A依赖于文件B而存在,如果删除了文件B,打开文件A就会报错:”No such file or directory”。这是软链接与硬链接最大的不同:文件A指向文件B的文件名,而不是文件B的inode号码,文件B的inode”链接数”不会因此发生变化。
ln -s命令可以创建软链接。
ln -s 源文文件或目录 目标文件或目录

八、inode的特殊作用

由于inode号码与文件名分离,这种机制导致了一些Unix/Linux系统特有的现象。
  1. 有时,文件名包含特殊字符,无法正常删除。这时,直接删除inode节点,就能起到删除文件的作用。
  2. 移动文件或重命名文件,只是改变文件名,不影响inode号码。
  3. 打开一个文件以后,系统就以inode号码来识别这个文件,不再考虑文件名。因此,通常来说,系统无法从inode号码得知文件名。
      第3点使得软件更新变得简单,可以在不关闭软件的情况下进行更新,不需要重启。因为系统通过inode号码,识别运行中的文件,不通过文件名。更新的时候,新版文件以同样的文件名,生成一个新的inode,不会影响到运行中的文件。等到下一次运行这个软件的时候,文件名就自动指向新版文件,旧版文件的inode则被回收。

九 实际问题

在一台配置较低的Linux服务器(内存、硬盘比较小)的/data分区内创建文件时,系统提示磁盘空间不足,用df -h命令查看了一下磁盘使用情况,发现/data分区只使用了66%,还有12G的剩余空间,按理说不会出现这种问题。 后来用df -i查看了一下/data分区的索引节点(inode),发现已经用满(IUsed=100%),导致系统无法创建新目录和文件。

查找原因:

/data/cache目录中存在数量非常多的小字节缓存文件,占用的Block不多,但是占用了大量的inode

解决方案:
1、删除/data/cache目录中的部分文件,释放出/data分区的一部分inode。
2、用软连接将空闲分区/opt中的newcache目录连接到/data/cache,使用/opt分区的inode来缓解/data分区inode不足的问题:

ln -s /opt/newcache /data/cache

Q&A:为何选择Netty

1.Netty 是什么?

Netty 是一个基于 JAVA NIO 类库的异步通信框架,它的架构特点是:异步非阻塞、基于事件驱动、高性能、高可靠性和高可定制性。

2.使用 Netty 能够做什么?

  • 开发异步、非阻塞的 TCP 网络应用程序;
  • 开发异步、非阻塞的 UDP 网络应用程序;
  • 开发异步文件传输应用程序;
  • 开发异步 HTTP 服务端和客户端应用程序;
  • 提供对多种编解码框架的集成,包括谷歌的 Protobuf、JBoss Marshalling、Java 序列化、压缩编解码、XML 解码、字符串编解码等,这些编解码框架可以被用户直接使用;
    提供形式多样的编解码基础类库,可以非常方便的实现私有协议栈编解码框架的二次定制和开发;
  • 基于职责链模式的 Pipeline-Handler 机制,用户可以非常方便的对网络事件进行拦截和定制;
  • 所有的 IO 操作都是异步的,用户可以通过 Future-Listener 机制主动 Get 结果或者由IO 线程操作完成之后主动 Notify 结果,用户的业务线程不需要同步等待;
  • IP 黑白名单控制;
  • 打印消息码流;
  • 流量控制和整形;
  • 性能统计;
  • 基于链路空闲事件检测的心跳检测…

3.Netty 在哪些行业得到了应用?

互联网行业
随着网站规模的不断扩大,系统并发访问量也越来越高,传统基于 Tomcat 等 Web 容器的垂直架构已经无法满足需求,需要拆分应用进行服务化,以提高开发和维护效率。从组网情况看,垂直的架构拆分之后,系统采用分布式部署,各个节点之间需要远程服务调用,高性能的 RPC 框架必不可少,Netty 作为异步高性能的通信框架,往往作为基础通信组件被这些 RPC 框架使用。

典型的应用有:阿里分布式服务框架 Dubbo 的 RPC 框架使用 Dubbo 协议进行节点间通信,Dubbo 协议默认使用 Netty 作为基础通信组件,用于实现各进程节点之间的内部通信。

游戏行业
无论是手游服务端、还是大型的网络游戏,Java 语言得到了越来越广泛的应用。Netty 作为高性能的基础通信组件,它本身提供了 TCP/UDP 和 HTTP 协议栈,非常方便定制和开发私有协议栈。

大数据领域
经典的 Hadoop 的高性能通信和序列化组件 Avro 的 RPC 框架,默认采用 Netty 进行跨节点通信,它的 Netty Service 基于 Netty 框架二次封装实现。
大数据计算往往采用多个计算节点和一个/N个汇总节点进行分布式部署,各节点之间存在海量的数据交换。由于 Netty 的综合性能是目前各个成熟 NIO 框架中最高的,因此,往往会被选中用作大数据各节点间的通信。

4.使用传统的 Socket 开发挺简单的,我为什么要切换到 NIO 进行编程呢?

首先我们看下传统基于同步阻塞 IO(BIO)的线程模型图:

由上图我们可以看出,传统的同步阻塞 IO 通信存在如下几个问题:

  • 线程模型存在致命缺陷:一连接一线程的模型导致服务端无法承受大量客户端的并发连接;
  • 性能差:频繁的线程上下文切换导致 CPU 利用效率不高;
  • 可靠性差:由于所有的 IO 操作都是同步的,所以业务线程只要进行 IO 操作,也会存在被同步阻塞的风险,这会导致系统的可靠性差,依赖外部组件的处理能力和网络的情况。
  • 采用非阻塞 IO(NIO)之后,同步阻塞 IO 的三个缺陷都将迎刃而解:
  • Nio 采用 Reactor 模式,一个 Reactor 线程聚合一个多路复用器 Selector,它可以同时注册、监听和轮询成百上千个 Channel,一个 IO 线程可以同时并发处理N个客户端连接,线程模型优化为1:N(N < 进程可用的最大句柄数)或者 M : N (M通常为 CPU 核数 + 1, N < 进程可用的最大句柄数);
  • 由于 IO 线程总数有限,不会存在频繁的 IO 线程之间上下文切换和竞争,CPU 利用率高;
  • 所有的 IO 操作都是异步的,即使业务线程直接进行 IO 操作,也不会被同步阻塞,系统不再依赖外部的网络环境和外部应用程序的处理性能。

由于切换到 NIO 编程之后可以为系统带来巨大的可靠性、性能提升,所以,目前采用 NIO 进行通信已经逐渐成为主流。

5.为什么不直接基于 JDK 的 NIO 类库编程呢?

我们通过 JDK NIO 服务端和客户端的工作时序图来回答下这个问题

 

即便抛开代码和 NIO 类库复杂性不谈,一个高性能、高可靠性的 NIO 服务端开发和维护成本都是非常高的,开发者需要具有丰富的 NIO 编程经验和网络维护经验,很多时候甚至需要通过抓包来定位问题。也许开发出一套 NIO 程序需要 1 个月,但是它的稳定很可能需要 1 年甚至更长的时间,这也就是为什么我不建议直接使用 JDK NIO 类库进行通信开发的一个重要原因。

下面再一起看下 JDK NIO 客户端的通信时序图(它同样非常复杂)

 

6.为什么要选择 Netty 框架?

Netty 是业界最流行的 NIO 框架之一,它的健壮性、功能、性能、可定制性和可扩展性在同类框架中都是首屈一指的,它已经得到成百上千的商用项目验证,例如 Hadoop 的 RPC 框架 Avro 使用 Netty 作为通信框架。很多其它业界主流的 RPC 和分布式服务框架,也使用 Netty 来构建高性能的异步通信能力。

Netty 的优点总结如下:

  • API 使用简单,开发门槛低;
  • 功能强大,预置了多种编解码功能,支持多种主流协议;
  • 定制能力强,可以通过 ChannelHandler 对通信框架进行灵活的扩展;
  • 性能高,通过与其它业界主流的 NIO 框架对比,Netty 的综合性能最优;
  • 社区活跃,版本迭代周期短,发现的 BUG 可以被及时修复,同时,更多的新功能会被加入;
  • 经历了大规模的商业应用考验,质量得到验证。在互联网、大数据、网络游戏、企业应用、电信软件等众多行业得到成功商用,证明了它完全满足不同行业的商用标准。

(转载)TCP的粘包现象

原博文链接:TCP的粘包现象

今天被阿里面到了TCP粘包的问题,一时答不上来非常尴尬,收集下别人的回答做个笔记。

1 什么是粘包现象

TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包,从接收缓冲区看,后一包数据的头紧接着前一包数据的尾。

2 为什么出现粘包现象

(1)发送方原因

我们知道,TCP默认会使用Nagle算法。而Nagle算法主要做两件事:1)只有上一个分组得到确认,才会发送下一个分组;2)收集多个小分组,在一个确认到来时一起发送。

所以,正是Nagle算法造成了发送方有可能造成粘包现象。

(2)接收方原因

TCP接收到分组时,并不会立刻送至应用层处理,或者说,应用层并不一定会立即处理;实际上,TCP将收到的分组保存至接收缓存里,然后应用程序主动从缓存里读收到的分组。这样一来,如果TCP接收分组的速度大于应用程序读分组的速度,多个包就会被存至缓存,应用程序读时,就会读到多个首尾相接粘到一起的包。

3 什么时候需要处理粘包现象

(1)如果发送方发送的多个分组本来就是同一个数据的不同部分,比如一个很大的文件被分成多个分组发送,这时,当然不需要处理粘包的现象;

(2)但如果多个分组本毫不相干,甚至是并列的关系,我们就一定要处理粘包问题了。比如,我当时要接收的每个分组都是一个有固定格式的商品信息,如果不处理粘包问题,每个读进来的分组我只会处理最前边的那个商品,后边的就会被丢弃。这显然不是我要的结果。

4 如何处理粘包现象

(1)发送方

对于发送方造成的粘包现象,我们可以通过关闭Nagle算法来解决,使用TCP_NODELAY选项来关闭Nagle算法。

(2)接收方

遗憾的是TCP并没有处理接收方粘包现象的机制,我们只能在应用层进行处理。

(3)应用层处理

应用层的处理简单易行!并且不仅可以解决接收方造成的粘包问题,还能解决发送方造成的粘包问题。

解决方法就是循环处理:应用程序在处理从缓存读来的分组时,读完一条数据时,就应该循环读下一条数据,直到所有的数据都被处理;但是如何判断每条数据的长度呢?

两种途径:

1)格式化数据:每条数据有固定的格式(开始符、结束符),这种方法简单易行,但选择开始符和结束符的时候一定要注意每条数据的内部一定不能出现开始符或结束符;

2)发送长度:发送每条数据的时候,将数据的长度一并发送,比如可以选择每条数据的前4位是数据的长度,应用层处理时可以根据长度来判断每条数据的开始和结束。

当时在做购物车的时候,我最开始的做法是设置开始符(0x7e)和结束符(0xe7),但在测试大量数据的时候,发现了数据异常。正如我所猜测,在调试过程中发现某些数据内部包含了它们。因为要处理的数据是量非常庞大,为做到万无一失,最后我采用了发送长度的方式。再也没有因为粘包而出过问题。

计算机网络知识点总结

  • OSI,TCP/IP,五层协议的体系结构,以及各层协议

应用层:提供用户与网络间的接口。—-HTTP、FTP、SMTP

运输层:进程到进程间的数据传输。—TCP、UDP

网络层:主机到主机之间的数据传输。—IP、选路协议

数据链路层:相邻结点之间的数据传输。—PPP、以太网

物理层:在物理介质上传输比特流。

应用层———PDU是报文(message)
传输层———PDU是数据段(segment)
网络层———PDU是数据报(datagram)
数据链路层—–PDU是数据帧(frame)
物理层———PDU是比特(bit)

  • PING操作的原理

使用ICMP,在IP主机、路由器之间传递控制消息

  • HTTP1.0/1.1区别

HTTP1.1中才有cache-control响应头,主要用于控制信息在浏览器的缓存

1. HTTP 1.0规定浏览器与服务器只保持短暂的连接,浏览器的每次请求都需要与服务器建立一个TCP连接,服务器完成请求处理后立即断开TCP连接,服务器不跟踪每个客户也不记录过去的请求。

缺陷:访问一个包含有许多图像的网页文件的整个过程包含了多次请求和响应,每次请求和响应都需要建立一个单独的连接,每次连接只是传输一个文档和图像,器端每次建立和关闭连接却是一个相对比较费时的过程,并且会严重影响客户机和服务器的性能。

2. HTTP 1.1支持持久连接,在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟。HTTP 1.1还允许客户端不用等待上一次请求结果返回,就可以发出下一次请求,但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果。
HTTP 1.1还提供了Host、身份认证、状态管理和Cache缓存等机制相关的请求头和响应头。

  • IP地址分类

A类地址:以0开头, 第一个字节范围:0~126(1.0.0.0 – 126.255.255.255);
B类地址:以10开头, 第一个字节范围:128~191(128.0.0.0 – 191.255.255.255);
C类地址:以110开头, 第一个字节范围:192~223(192.0.0.0 – 223.255.255.255);
10.0.0.0—10.255.255.255, 172.16.0.0—172.31.255.255, 192.168.0.0—192.168.255.255。(Internet上保留地址用于内部)
IP地址与子网掩码相得到网络号

  • ARP是地址解析协议,简单语言解释一下工作原理。

1:首先,每个主机都会在自己的ARP缓冲区中建立一个ARP列表,以表示IP地址和MAC地址之间的对应关系
2:当源主机要发送数据时,首先检查ARP列表中是否有对应IP地址的目的主机的MAC地址,如果有,则直接发送数据,如果没有,就向本网段的所有主机发送ARP数据包,该数据包包括的内容有:源主机IP地址,源主机MAC地址,目的主机的IP地址。
3:当本网络的所有主机收到该ARP数据包时,首先检查数据包中的目的IP地址是否是自己的IP地址,如果不是,则忽略该数据包;如果是,则首先从数据包中取出源主机的IP和MAC地址写入到ARP列表中,如果已经存在,则覆盖,然后将自己的MAC地址写入ARP响应包中,告诉源主机自己是它想要找的MAC地址。
4:源主机收到ARP响应包后。将目的主机的IP和MAC地址写入ARP列表,并利用此信息发送数据。如果源主机一直没有收到ARP响应数据包,表示ARP查询失败。
广播发送ARP请求,单播发送ARP响应。

各种协议的介绍

  ICMP协议:因特网控制报文协议。它是TCP/IP协议族的一个子协议,用于在IP主机、路由器之间传递控制消息。
  TFTP协议:是TCP/IP协议族中的一个用来在客户机与服务器之间进行简单文件传输的协议,提供不复杂、开销不大的文件传输服务。
  HTTP协议:超文本传输协议,是一个属于应用层的面向对象的协议,由于其简捷、快速的方式,适用于分布式超媒体信息系统。
  NAT协议:网络地址转换属接入广域网(WAN)技术,是一种将私有(保留)地址转化为合法IP地址的转换技术,
  DHCP协议:动态主机配置协议,一个局域网的网络协议,使用UDP协议工作,用途:给内部网络或网络服务供应商自动分配IP地址,给用户或者内部网络管理员作为对所有计算机作中央管理的手段。

  • 描述RARP协议

RARP是逆地址解析协议,作用是完成硬件地址到IP地址的映射,主要用于无盘工作站,因为给无盘工作站配置的IP地址不能保存。工作流程:在网络中配置一台RARP服务器,里面保存着IP地址和MAC地址的映射关系,当无盘工作站启动后,就封装一个RARP数据包,里面有其MAC地址,然后广播到网络上去,当服务器收到请求包后,就查找对应的MAC地址的IP地址装入响应报文中发回给请求者。因为需要广播请求报文,因此RARP只能用于具有广播能力的网络。

  • 易混淆的协议所在层

ARP、RARP:属于网络层,工作在数据链路层。

ICMP:网络层

  • 在浏览器中输入www.baidu.com后执行的全部过程

1、客户端浏览器通过DNS解析到www.baidu.com的IP地址220.181.27.48,通过这个IP地址找到客户端到服务器的路径。客户端浏览器发起一个HTTP会话到220.161.27.48,然后通过TCP进行封装数据包,输入到网络层。
2、在客户端的传输层,把HTTP会话请求分成报文段,添加源和目的端口,如服务器使用80端口监听客户端的请求,客户端由系统随机选择一个端口如5000,与服务器进行交换,服务器把相应的请求返回给客户端的5000端口。然后使用IP层的IP地址查找目的端。
3、客户端的网络层不用关心应用层或者传输层的东西,主要做的是通过查找路由表确定如何到达服务器,期间可能经过多个路由器,这些都是由路由器来完成的工作,我不作过多的描述,无非就是通过查找路由表决定通过那个路径到达服务器。
4、客户端的链路层,包通过链路层发送到路由器,通过邻居协议查找给定IP地址的MAC地址,然后发送ARP请求查找目的地址,如果得到回应后就可以使用ARP的请求应答交换的IP数据包现在就可以传输了,然后发送IP数据包到达服务器的地址。

  • TCP三次握手和四次挥手的全过程

三次握手:
第一次握手:客户端发送syn包(syn=x)到服务器,并进入SYN_SEND状态,等待服务器确认;
第二次握手:服务器收到syn包,必须确认客户的SYN(ack=x+1),同时自己也发送一个SYN包(syn=y),即SYN+ACK包,此时服务器进入SYN_RECV状态;
第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=y+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。
握手过程中传送的包里不包含数据,三次握手完毕后,客户端与服务器才正式开始传送数据。理想状态下,TCP连接一旦建立,在通信双方中的任何一方主动关闭连接之前,TCP 连接都将被一直保持下去。

四次挥手
与建立连接的“三次握手”类似,断开一个TCP连接则需要“四次握手”。
第一次挥手:主动关闭方发送一个FIN,用来关闭主动方到被动关闭方的数据传送,也就是主动关闭方告诉被动关闭方:我已经不会再给你发数据了(当然,在fin包之前发送出去的数据,如果没有收到对应的ack确认报文,主动关闭方依然会重发这些数据),但是,此时主动关闭方还可以接受数据。
第二次挥手:被动关闭方收到FIN包后,发送一个ACK给对方,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号)。
第三次挥手:被动关闭方发送一个FIN,用来关闭被动关闭方到主动关闭方的数据传送,也就是告诉主动关闭方,我的数据也发送完了,不会再给你发数据了。
第四次挥手:主动关闭方收到FIN后,发送一个ACK给被动关闭方,确认序号为收到序号+1,至此,完成四次挥手。

  • TCP和UDP的区别?

TCP提供面向连接的、可靠的数据流传输,而UDP提供的是非面向连接的、不可靠的数据流传输。
TCP传输单位称为TCP报文段,UDP传输单位称为用户数据报。
TCP注重数据安全性,UDP数据传输快,因为不需要连接等待,少了许多操作,但是其安全性却一般。
TCP对应的协议和UDP对应的协议

TCP对应的协议:
(1)FTP:定义了文件传输协议,使用21端口。
(2)Telnet:一种用于远程登陆的端口,使用23端口,用户可以以自己的身份远程连接到计算机上,可提供基于DOS模式下的通信服务。
(3)SMTP:邮件传送协议,用于发送邮件。服务器开放的是25号端口。
(4)POP3:它是和SMTP对应,POP3用于接收邮件。POP3协议所用的是110端口。
(5)HTTP:是从Web服务器传输超文本到本地浏览器的传送协议。

UDP对应的协议:
(1) DNS:用于域名解析服务,将域名地址转换为IP地址。DNS用的是53号端口。
(2) SNMP:简单网络管理协议,使用161号端口,是用来管理网络设备的。由于网络设备很多,无连接的服务就体现出其优势。
(3) TFTP(Trival File Transfer Protocal),简单文件传输协议,该协议在熟知端口69上使用UDP服务。

  • TCP的三次握手过程?为什么会采用三次握手,若采用二次握手可以吗?

建立连接的过程是利用客户服务器模式,假设主机A为客户端,主机B为服务器端。

(1)TCP的三次握手过程:主机A向B发送连接请求;主机B对收到的主机A的报文段进行确认;主机A再次对主机B的确认进行确认。
(2)采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B,因而产生错误。失效的连接请求报文段是指:主机A发出的连接请求没有收到主机B的确认,于是经过一段时间后,主机A又重新向主机B发送连接请求,且建立成功,顺序完成数据传输。考虑这样一种特殊情况,主机A第一次发送的连接请求并没有丢失,而是因为网络节点导致延迟达到主机B,主机B以为是主机A又发起的新连接,于是主机B同意连接,并向主机A发回确认,但是此时主机A根本不会理会,主机B就一直在等待主机A发送数据,导致主机B的资源浪费。
(3)采用两次握手不行,原因就是上面说的失效的连接请求的特殊情况。

  • IP层为什么不对数据部分进行差错校验?
  因为网络层是“尽最大努力完整的传输数据包”,差错检测已由数据链路层实现,IP层没必要再进行一次校验。
  优点就是,因为不负责差错检测和纠错,所以可获得较高的传输性能。
  缺点就是,因为IP层不负责差错检测,那么错误检测只能在传输层或应用层被发现,使纠正错误的时间增加了。
  试想一下,如果两台PC跨INTERNET通信,之间隔了很多台路由器,PC1给PC2发了个数据包,到达第一台路由器后,在转发的过程中,数据包发生了错误:
  1-因为IP层不做差错校验,所以第2台路由器通过广域网协议(HDLC、PPP等)收到数据后,只要数据链路层正常,它就无法得知收到的IP包是否正确,错误就会这么传递下去,至到PC2才被发现。
  2-如果IP可以实现差错校验的功能,那么到了第2台路由器时,路由器2就不会再继续发错误包了,错误就会终止。
  不过现在网络传输的误码率都极低,所以IP层没必要再做一次校验!

(转载)Nginx location 在配置中的优先级

原文链接:nginx location在配置中的优先级

location表达式类型

~ 表示执行一个正则匹配,区分大小写
~* 表示执行一个正则匹配,不区分大小写
^~ 表示普通字符匹配。使用前缀匹配。如果匹配成功,则不再匹配其他location。
= 进行普通字符精确匹配。也就是完全匹配。
@ “@” 定义一个命名的 location,使用在内部定向时,例如 error_page, try_files

location优先级说明

在nginx的location和配置中location的顺序没有太大关系。只和location表达式的类型有关。相同类型的表达式,字符串长的会优先匹配。

以下是按优先级排列说明:

  1. 等号类型(=)的优先级最高。一旦匹配成功,则不再查找其他匹配项。
  2. ^~类型表达式。一旦匹配成功,则不再查找其他匹配项。
  3. 正则表达式类型(~ ~*)的优先级次之。如果有多个location的正则能匹配的话,则使用正则表达式最长的那个。
  4. 常规字符串匹配类型。按前缀匹配。

location优先级示例

location = / {
# 仅仅匹配请求 /
[ configuration A ]
}
location / {
# 匹配所有以 / 开头的请求。
# 但是如果有更长的同类型的表达式,则选择更长的表达式。
# 如果有正则表达式可以匹配,则优先匹配正则表达式。
[ configuration B ]
}
location /documents/ {
# 匹配所有以 /documents/ 开头的请求。
# 但是如果有更长的同类型的表达式,则选择更长的表达式。
# 如果有正则表达式可以匹配,则优先匹配正则表达式。
[ configuration C ]
}

location ^~ /images/ {
# 匹配所有以 /images/ 开头的表达式,如果匹配成功,则停止匹配查找。
# 所以,即便有符合的正则表达式location,也不会被使用
[ configuration D ]
}

location ~* \.(gif|jpg|jpeg)$ {
# 匹配所有以 gif jpg jpeg结尾的请求。
# 但是 以 /images/开头的请求,将使用 Configuration D
[ configuration E ]
}

请求匹配示例

/ -> configuration A

/index.html -> configuration B

/documents/document.html -> configuration C

/images/1.gif -> configuration D

/documents/1.jpg -> configuration E

注意,以上的匹配和在配置文件中定义的顺序无关。

Nginx开启HTTPS,跑步进入HTTP/2.0时代~

  • HTTPS可以理解成工作在SSL层以上的HTTP协议,相对传统的HTTP,HTTPS有很多实用而重要的功能,例如加密传输,有效防止运营商网络劫持,同时一些新型的HTTP算法也只有在HTTPS下才可使用
  • 但是HTTPS增加了握手包的处理,对服务器而言自然要占用更多一些的资源,但是相对于它带来的好处,HTTPS协议还是很值得推广的。为了缓解HTTPS带来的性能下降问题,HTTP/2提供了一种多路复用的解决方案,在单个连接上实现同时进行多个业务单元数据的传输,从而提供页面的并发性能。
  • 值得注意的是,目前HTTP/2仍然没有通过国际ISO标准委员会,所以严格来说,我们讨论的其实是HTTPS 结合 SPDY 草案2。

闲话说完了,下面开始介绍nginx下开启HTTPS支持进而支持HTTP 2.0的方法。

  • 四步走配置nginx开启HTTPS

  1. 首先,你得有个域名和域名对应的SSL证书,通常不建议用自行签发的证书,因为可用性几乎为0。国内的话建议在腾讯云或者阿里云上申请免费的域名SSL证书,有效期为1年,足够用了(域名要通过备案啥的我就不用说了哈)
  2. 点击下载,能下载到一个zip压缩包,里面包含了主流WEB服务器的SSL证书格式。假设下载到的压缩包为php.ultrasoftware.cn.zip ,用WinSCP之类的工具将此压缩包上传到你nginx所在的服务器并解压,命令如下:
unzip php.ultrasoftware.cn.zip

可以看到解压出来的目录有一个名为Nginx的,将该目录下的两个文件复制到你nginx配置文件所在位置,例如/etc/nginx/或者/usr/local/nginx/conf


编号断了,我只好重新编号

  1. Nginx文件夹内获得SSL证书文件 1_www.domain.com_bundle.crt 和私钥文件 2_www.domain.com.key。
  2. 修改配置文件中的内容,例如 vim /etc/nginx/nginx.conf
server {
        listen 443;
        server_name www.domain.com; #填写绑定证书的域名
        ssl on;
        ssl_certificate 1_www.domain.com_bundle.crt;
        ssl_certificate_key 2_www.domain.com.key;
        ssl_session_timeout 5m;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2; #按照这个协议配置
        ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;#按照这个套件配置
        ssl_prefer_server_ciphers on;
        location / {
            root   html; #站点目录
            index  index.html index.htm;
        }
    }

然后运行

nginx -t -s reload

如果提示配置没有出错,那么就已经成功配置nginx开启HTTPS了


  • 配置nginx开启HTTP2.0

  1. 最简单的情况:只需要在上述基础上修改一点点就行,具体为
    listen 443 ssl spdy;
  2. 但是现实往往没那么简单,因为RPM包安装的nginx默认不包含HTTP2模块,所以用nginx -t检查配置的时候会报以下的错
    nginx: [warn] invalid parameter "spdy": ngx_http_spdy_module was superseded by ngx_http_v2_module in /etc/nginx/nginx.conf:18

    对于这种情况,唯一的办法是在官网下载对应版本的nginx源码进行升级编译安装,configure时应加上–with-http_spdy_module,这超出了本文的内容,因此不再此细讲。

  3. 注意:从1.9.5版本开始, ngx_http_v2_module 取代http_spdy_module,所以此时应把参数修正为–with-http_v2_module,同样地配置文件修改处为
listen 443 ssl http2;

Linux常用Shell命令简介

 

  1. awk#处理文本和数据的高级工具

  2. base64#文件转Base64编码

  3. bunzip2#bzip2解压命令

  4. bzip2#bzip2压缩命令

  5. cal#日历

  6. cat#显示文件(高级用法:拼接文件)

  7. chattr#修改文件或目录属性(root专用)

  8. chgrp#改变文件或目录所属分组

  9. chmod#改变文件或目录的访问权限
    chmod +x shell.sh 或者 chmod -R +644 /dirname/

  10. chown#改变文件或目录所有权(root专用)
     chown -R www:www /usr/share/html

  11. chroot#改变当前环境执行时所参考的根目录位置

  12. clear#清屏

  13. cmp#逐个字节对比两个文件的异同

  14. cp#复制文件或目录

  15. crontab#查看或设置用户定时任务
    crontab -e 或者 crontab -l

  16. cut#逐行剪切字节、字符和字段并输出

  17. date#获取当前时间
    date 或者 date -R 或者 date '+%Y-%m-%d %H:%M:%S'
  18. dd#块设备级别的读写操作
    dd if=/dev/zero of=/dev/sda bs=1M
  19. df#获取系统硬盘分区及占用情况
    df -h
  20. diff#比较单个文件或者目录内容

  21. du#统计目录占用空间大小
    du -h -s
  22. echo#输出一行常量或变量
    echo $JAVA_HOME
  23. env#输出当前环境变量

  24. expand#制表符转变为空白字符并输出

  25. expr#表达式计算
    expr 25 \* 100 或者 expr abc : a
  26. fdisk#显示或操作磁盘分区表
    fdisk -l
  27. find#搜索文件
    find -name "Abc.class" 或者 find /home/username -name "*.java"
  28. free#输出内存使用情况
    free -h
  29. grep#匹配搜索文件内容并输出
    grep -v "\#" /path/filename
  30. gunzip#gzip解压命令

  31. gzip#gzip压缩命令

  32. head#查看文件的头几行

  33. id#显示当前用户的id和所属组别

  34. ifconfig#显示或设置网卡信息(旧版)

  35. ip#显示或设置网卡信息(新版命令)

  36. kill#暂停或终止进程(非常重要)
    kill -9 12345 或者 kill -3 12345

  37. killall#终止守护进程及子进程

  38. last#当前系统累计登录时间

  39. less#高级显示文本内容,与more相对

  40. ln#链接文件或目录
    ln -s /path/sourcefile /path/targetfile
  41. ls#显示当前文件夹下所有文件
    ls -l -h 或者 ls -l -t -h 或者ls -l -S -h
  42. lspci#显示所有已连接的PCI设备
  43. lsscsi#显示所有已连接的SCSI设备
  44. lsusb#显示所有已连接的USB设备
  45. man#标准命令的参考手册
    man expr
  46. md5sum#计算文件的md5值

  47. mkdir#新建文件夹
    mkdir -p /path/parent/children
  48. more#类似cat,不过会以一页一页的显示方便逐页阅读

  49. mount#挂载块设备到目录

  50. mv#移动,重命名文件或目录
    mv /path/source/* /path/target/ 或者 mv oldname newname
  51. nano#容易上手的编辑器

  52. netstat #显示网络连接、路由表和网络接口信息
    netstat -ntlp 或者 netstat -nlp
  53. nohup#以不挂断的方式运行命令

  54. nslookup#域名解析为IP

  55. passwd#修改密码命令

  56. pgrep#获取进程并输出其进程ID
    pgrep java
  57. ping#不解释

  58. ps#打印输出当前进程的情况
    ps -ef
  59. pwd#获取当前路径

  60. reboot#重启命令

  61. rm#删除文件或文件夹命令
    rm -rf /path/target
  62. rmdir#删除文件夹

  63. route#显示或设置路由表
    route -n
  64. sed#查找替换文件中的字符串
    sed -i 's/origin/target/g' /path/filename

  65. sha1sum #计算文件SHA-1值
  66. sha256sum #计算文件SHA-256值
  67. sha512sum #计算文件SHA-512值

  68. shutdown#关机命令

  69. sleep#等待,暂停当前任务

  70. sort#排序并输出

  71. stat#显示文件或文件系统的详细信息

  72. su#切换用户身份

  73. sysctl#显示或修改内核参数
    sysctl -p 或者 sysctl vm.overcommit_memory=1
  74. tail #输出文件末尾几行
    tail -n 1000 /path/filename 或者 tail -f /path/filename
  75. tar #tar压缩命令
    tar -xvf /path/compressd.tar.gz
  76. tee#将输入流转换为多个输出流

  77. time#计时器

  78. top#实时显示系统中各个进程的资源占用状况

  79. touch#修改文件时间戳

  80. tr#替换字符

  81. traceroute#追踪并输出数据包所经过的路径

  82. umount#卸载绑定的块设备(与mount相反)

  83. uname#输出一组系统信息(通常用于显示当前内核版本)

  84. unxz#xz解压命令
  85. unzip#zip解压命令

  86. uptime#系统负载情况

  87. vi #文件编辑器
  88. vim #增强版文本编辑器

  89. watch#持续监测一个命令的运行结果

  90. wc#行统计工具

  91. wget#网络下载工具

  92. whoami#不解释

  93. xargs#参数列表转换成小块分段传递给其他命令,以避免列表过长(非常重要)

  94. xz#xz压缩命令

 

Centos 下部署并优化Tomcat

  • 在上面几篇文章的基础上,本文将主要教新手如何在Centos系统上部署并优化tomcat

  • 首先,访问Apache Tomcat官网,下载合适的Tomcat版本的压缩包,一般推荐下载Tomcat 7.0或者Tomcat 8.0,如非特殊需求,尽量不要下载Tomcat 8.5和尚处于测试阶段的Tomcat 9.0。这里以下载tomcat 7.0.79为例
# wget http://mirrors.tuna.tsinghua.edu.cn/apache/tomcat/tomcat-7/v7.0.79/bin/apache-tomcat-7.0.79.tar.gz

解压apache-tomcat-7.0.79.tar.gz

# tar -xvf apache-tomcat-7.0.79.tar.gz

类比Windows上的tomcat 启动,通过bin目录下startup.sh脚本来启动tomcat

# cd apache-tomcat-7.0.79/bin
# ./startup.sh && tail -f ../logs/catalina.out

可以从窗口中看到平常熟悉的日志打印,稍等片刻,tomcat即可启动完成,用浏览器打开服务器的ip:8080就能看到那只猫的logo了

  • 优化tomcat启动

# vim $JAVA_HOME/jre/lib/security/java.security

或者

# vim $JRE_HOME/lib/security/java.security

查找securerandom.source=file:/dev/random,改为

securerandom.source=file:/dev/urandom

:wq保存并退出

  • 优化Tomcat对请求的处理能力

Tomcat Connector支持三种方式运行:BIO,NIO,APR。

  • BIO:
一个线程处理一个请求。缺点:并发量高时,线程数较多,浪费资源。
Tomcat7或以下,在Linux系统中默认使用这种方式。
  • NIO:
利用Java的异步IO处理,可以通过少量的线程处理大量的请求。
Tomcat8在Linux系统中默认使用这种方式。
Tomcat7必须修改Connector配置来启动:
  • APR:
即Apache Portable Runtime,从操作系统层面解决io阻塞问题。
Tomcat7或Tomcat8在Win7或以上的系统中启动默认使用这种方式。
Linux如果安装了apr和native,Tomcat直接启动就支持apr
传统意义上Linux下Tomcat想开启APR模式需进行较多编译工作,中间涉及到的知识点过于广泛,所以下文直接使用centos源中编译好了的库来使Tomcat开启APR模式
# yum install tcnative
重启tomcat,看到控制台显示 “Starting ProtocolHandler [“http-apr-8080”]”即为优化成功!