本人准研三,面临秋招压力,遂总结部分计算基础知识,以备不时之需,有些是从大佬博文摘抄的,都附有相应博文链接,如有遗漏,烦请联系本人更改,如有侵权,我会修改矫正。最后祝各位OFFER多多,进大厂!
一次完整的HTTP请求过程
当我们在web浏览器的地址栏中输入: www.baidu.com,然后回车,到底发生了什么
过程概览
1.对www.baidu.com这个网址进行DNS域名解析,得到对应的IP地址
2.根据这个IP,找到对应的服务器,发起TCP的三次握手
3.建立TCP连接后发起HTTP请求
4.服务器响应HTTP请求,浏览器得到html代码
5.浏览器解析html代码,并请求html代码中的资源(如js、css图片等)(先得到html代码,才能去找这些资源)
6.浏览器对页面进行渲染呈现给用户
注:1.DNS域名解析采用的是递归查询的方式,过程是,先去找DNS缓存->缓存找不到就去找根域名服务器->根域名又会去找下一级,这样递归查找之后,找到了,给我们的web浏览器
2.为什么HTTP协议要基于TCP来实现? TCP是一个端到端的可靠的面相连接的协议,HTTP基于传输层TCP协议不用担心数据传输的各种问题(当发生错误时,会重传)
3.最后一步浏览器是如何对页面进行渲染的? a)解析html文件构成 DOM树,b)解析CSS文件构成渲染树, c)边解析,边渲染 , d)JS 单线程运行,JS有可能修改DOM结构,意味着JS执行完成前,后续所有资源的下载是没有必要的,所以JS是单线程,会阻塞后续资源下载
1.域名解析
a)首先会搜索浏览器自身的DNS缓存(缓存时间比较短,大概只有1分钟,且只能容纳1000条缓存)
b)如果浏览器自身的缓存里面没有找到,那么浏览器会搜索系统自身的DNS缓存
c)如果还没有找到,那么尝试从 hosts文件里面去找
d)在前面三个过程都没获取到的情况下,就递归地去域名服务器去查找,具体过程如下
DNS优化:两个方面:DNS缓存、DNS负载均衡
2.TCP连接(三次握手)
拿到域名对应的IP地址之后,User-Agent(一般指浏览器)会以一个随机端口(1024<端口<65535)向服务器的WEB程序(常用的有httpd,nginx)等的80端口。这个连接请求(原始的http请求经过TCP/IP4层模型的层层封包)到达服务器端后(这中间有各种路由设备,局域网内除外),进入到网卡,然后是进入到内核的TCP/IP协议栈(用于识别连接请求,解封包,一层一层的剥开),还有可能要经过Netfilter防火墙(属于内核的模块)的过滤,最终达到WEB程序,最终建立了TCP/IP的连接
HTTP请求报文由三部分组成:请求行,请求头和请求正文
请求行:用于描述客户端的请求方式,请求的资源名称以及使用的HTTP协议的版本号(例:GET/books/java.html HTTP/1.1)
请求头:用于描述客户端请求哪台主机,以及客户端的一些环境信息等
注:这里提一个请求头 Connection,Connection设置为 keep-alive用于说明 客户端这边设置的是,本次HTTP请求之后并不需要关闭TCP连接,这样可以使下次HTTP请求使用相同的TCP通道,节省TCP建立连接的时间
请求正文:当使用POST, PUT等方法时,通常需要客户端向服务器传递数据。这些数据就储存在请求正文中(GET方式是保存在url地址后面,不会放到这里)
4.服务器端响应http请求,浏览器得到html代码
HTTP响应也由三部分组成:状态码,响应头和实体内容
状态码:状态码用于表示服务器对请求的处理结果
列举几种常见的:200(没有问题) 302(要你去找别人) 304(要你去拿缓存) 307(要你去拿缓存) 403(有这个资源,但是没有访问权限) 404(服务器没有这个资源) 500(服务器这边有问题)
若干响应头:响应头用于描述服务器的基本信息,以及客户端如何处理数据
实体内容:服务器返回给客户端的数据
注:html资源文件应该不是通过 HTTP响应直接返回去的,应该是通过nginx通过io操作去拿到的吧
5.浏览器解析html代码,并请求html代码中的资源
浏览器拿到html文件后,就开始解析其中的html代码,遇到js/css/image等静态资源时,就向服务器端去请求下载(会使用多线程下载,每个浏览器的线程数不一样),这是时候就用上 keep-alive特性了,建立一次HTTP连接,可以请求多个资源,下载资源的顺序就是按照代码里面的顺序,但是由于每个资源大小不一样,而浏览器又是多线程请求请求资源,所以这里显示的顺序并不一定是代码里面的顺序。
6.浏览器对页面进行渲染呈现给用户
最后,浏览器利用自己内部的工作机制,把请求的静态资源和html代码进行渲染,渲染之后呈现给用户
浏览器是一个边解析边渲染的过程。首先浏览器解析HTML文件构建DOM树,然后解析CSS文件构建渲染树,等到渲染树构建完成后,浏览器开始布局渲染树并将其绘制到屏幕上。这个过程比较复杂,涉及到两个概念: reflow(回流)和repain(重绘)。DOM节点中的各个元素都是以盒模型的形式存在,这些都需要浏览器去计算其位置和大小等,这个过程称为relow;当盒模型的位置,大小以及其他属性,如颜色,字体,等确定下来之后,浏览器便开始绘制内容,这个过程称为repain。页面在首次加载时必然会经历reflow和repain。reflow和repain过程是非常消耗性能的,尤其是在移动设备上,它会破坏用户体验,有时会造成页面卡顿。所以我们应该尽可能少的减少reflow和repain。
JS的解析是由浏览器中的JS解析引擎完成的。JS是单线程运行,JS有可能修改DOM结构,意味着JS执行完成前,后续所有资源的下载是没有必要的,所以JS是单线程,会阻塞后续资源下载
总结:
HTTPS(全称: Hypertext Transfer Protocol Secure,超文本传输安全协议),是以安全为目标的HTTP通道,简单讲是HTTP的安全版。
HTTPS其实是有两部分组成:HTTP + SSL / TLS,也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密,所以传输的数据都是加密后的数据。
具体是如何进行加密,解密,验证的,且看下图。
HTTPS加密请求(一次握手)过程
客户端和服务端之间的加密机制:
TLS协议是基于TCP协议之上的,图中第一个蓝色往返是TCP的握手过程,之后两次橙色的往返,我们可以叫做TLS的握手。握手过程如下:
client1:TLS版本号+所支持加密套件列表+希望使用的TLS选项
Server1:选择一个客户端的加密套件+自己的公钥+自己的证书+希望使用的TLS选项+(要求客户端证书);
Client2:(自己的证书)+使用服务器公钥和协商的加密套件加密一个对称秘钥(自己生成的一个随机值);
Server2:使用私钥解密出对称秘钥(随机值)后,发送加密的Finish消息,表明完成握手
一般的对称加密像这样:
encrypt(明文,秘钥) = 密文
decrypt(密文,秘钥) = 明文
共享密钥加密也称对称密钥加密。采用的是使用相同密钥对报文进行加密解密
我们可以将共享密钥加密这样理解:我们把我们要给别人的东西放到一个箱子里面,然后给箱子上了一把锁。当箱子到了我们想给的那个人
身上时,他也需要这把钥匙才能开锁。
这样就产生了一个问题了,我们怎么将这把钥匙安全的交给对方呢,如果钥匙在半路被人截取了,那么对箱子有没有加锁有什么区别呢。因此
共享密钥加密需要解决的一个大问题就是如何安全的将密钥交给解密方。
也就是说加密和解密用的是同一个秘钥。而非对称加密是这样的:
encrypt(明文,公钥) = 密文
decrypt(密文,私钥) = 明文
假设客户发送报文,服务器接收报文。客户在发送报文的时候需要对报文加密,服务器有两把密钥,一把私钥,一把公钥。客户在发送报文前需要先向服务器获取公钥进行报文的加密。这把公钥只能加密,不能解密,因此被任何人截获到都没什么用处。服务器收到加密后的报文,使用私钥解密。整个过程中只涉及到公钥的获取,加密,密文传输,解密。并不涉及到解密用的私钥传输。因此这种方式是安全的。但是涉及到太多细节,整个流程下来耗时耗费资源。
再拿上面那个例子,这时候我们还想把一些东西锁到箱子里给某人,我们称他为大傻。我们先跟大傻联系,大傻身上有两把钥匙,我们称为钥匙A和钥匙B。钥匙A可以用来造锁,但是造好的锁自己却不能开,只能通过钥匙B来开。跟大傻取得联系后大傻把钥匙A给我们。我们拿着钥匙A找造锁师傅造了一把锁,并且给箱子上锁。然后将带锁的箱子通过物流发给大傻,就算钥匙A被强盗截取了,强盗也开不了箱子。大傻收到箱子后使用那把钥匙B进行开锁,拿到东西。由于钥匙B一直再大傻身上,所以不用担心被人拿走。
加密和解密是需要不同的秘钥的。
经过这几次握手成功后,客服端和服务端之间通信的加密算法和所需要的密钥也就确定下来了,之后双方的交互都可以使用对称加密算法加密了。
HTTPS为了追求性能,又要保证安全,采用了共享密钥加密和公开密钥加密混合的方式进行报文传输。
还是拿上面的锁和箱子的例子来说明。现在我们嫌弃每次加锁都要造个新的锁效率太慢了。我们现在有两个箱子,一个箱子用于方我们要给大傻的东西,并且这个箱子加上了锁。另一个箱子用于存放那把锁的钥匙。我们这时候找大傻拿到钥匙A造了一把锁后将那个存放钥匙的箱子锁起来,然后将这个箱子给大傻,大傻拿到箱子使用钥匙B开锁拿到钥匙。这时候我们将那个存放了东西的箱子给大傻,大傻就可以通过这把钥匙开锁拿到东西了。这样以后我们就可以一直通过这把锁和箱子互相给东西了,而不用发一次数据造一次锁了。
就是说采用共有密钥加密方式传输共享密钥,当共享密钥安全到达服务端后往后的数据就都采用该密钥进行加密解密。
该部分选自简书博客
HTTP状态码
当浏览者访问一个网页时,浏览者的浏览器会向网页所在服务器发出请求。当浏览器接收并显示网页前,此网页所在的服务器会返回一个包含HTTP状态码的信息头(server header)用以响应浏览器的请求。
下面是常见的HTTP状态码:
200 - 请求成功
301 - 资源(网页等)被永久转移到其它URL
404 - 请求的资源(网页等)不存在
500 - 内部服务器错误
400 - 请求无效
403 - 禁止访问
HTTP状态码分类
HTTP状态码由三个十进制数字组成,第一个十进制数字定义了状态码的类型,后两个数字没有分类的作用。HTTP状态码共分为5种类型:
详细具体含义参考CSDN博文
1)请求方法URI协议/版本
Request URL: http://localhost:8080/Gary_Text/ 资源的请求url
Request Method: GET HTTP方:GET
Status Code: 200 OK 响应状态码
Remote Address: [::1]:8080 请求的远程地址
根据HTTP标准,HTTP请求可以使用多种请求方法。具体的方法以及区别后面我们介绍。
2)请求头(Request Header)
Accept 可接受的内容类型
Accept-Language 语言
Connection连接状态
Host 请求的域名(这里我设置的是请求本地,当然,关于域名,就是所谓的URL)
User-Agent 浏览器端浏览器型号和版本
Accept-Encoding 可接受的压缩类型 gzip,deflate
3)请求正文
请求头和请求正文之间是一个空行,它表示请求头已经结束,接下来的是请求正文。请求正文中可以包含客户提交的查询字符串信息:
username=siki&password=123
在以上的例子中,请求的正文只有一行内容。当然,在实际应用中,HTTP请求正文可以包含更多的内容。
HTTP响应与HTTP请求相似,HTTP响应也由3个部分构成:
1)状态行
2)响应头
3)响应正文
该部分转载自博客园
1、HTTP 1.1支持长连接(PersistentConnection)和请求的流水线(Pipelining)处理
HTTP 1.0规定浏览器与服务器只保持短暂的连接,浏览器的每次请求都需要与服务器建立一个TCP连接,服务器完成请求处理后立即断开TCP连接,服务器不跟踪每个客户也不记录过去的请求。
HTTP 1.1则支持持久连接Persistent Connection, 并且默认使用persistent connection. 在同一个tcp的连接中可以传送多个HTTP请求和响应. 多个请求和响应可以重叠,多个请求和响应可以同时进行. 更加多的请求头和响应头(比如HTTP1.0没有host的字段).
在1.0时的会话方式:
HTTP 1.1的持续连接,也需要增加新的请求头来帮助实现,例如,Connection请求头的值为Keep-Alive时,客户端通知服务器返回本次请求结果后保持连接;Connection请求头的值为close时,客户端通知服务器返回本次请求结果后关闭连接。HTTP 1.1还提供了与身份认证、状态管理和Cache缓存等机制相关的请求头和响应头。
请求的流水线(Pipelining)处理,在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟。例如:一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输,但每个单独的网页文件的请求和应答仍然需要使用各自的连接。 HTTP 1.1还允许客户端不用等待上一次请求结果返回,就可以发出下一次请求,但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果,以保证客户端能够区分出每次请求的响应内容。
2.HTTP 1.1增加host字段
在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名(hostname)。但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。
HTTP1.1的请求消息和响应消息都应支持Host头域,且请求消息中如果没有Host头域会报告一个错误(400 Bad Request)。此外,服务器应该接受以绝对路径标记的资源请求。
3、100(Continue) Status(节约带宽)
HTTP/1.1加入了一个新的状态码100(Continue)。客户端事先发送一个只带头域的请求,如果服务器因为权限拒绝了请求,就回送响应码401(Unauthorized);如果服务器接收此请求就回送响应码100,客户端就可以继续发送带实体的完整请求了。100 (Continue) 状态代码的使用,允许客户端在发request消息body之前先用request header试探一下server,看server要不要接收request body,再决定要不要发request body。
4、HTTP/1.1中引入了Chunked transfer-coding来解决上面这个问题,发送方将消息分割成若干个任意大小的数据块,每个数据块在发送时都会附上块的长度,最后用一个零长度的块作为消息结束的标志。这种方法允许发送方只缓冲消息的一个片段,避免缓冲整个消息带来的过载。
5、HTTP/1.1在1.0的基础上加入了一些cache的新特性,当缓存对象的Age超过Expire时变为stale对象,cache不需要直接抛弃stale对象,而是与源服务器进行重新激活(revalidation)。
该部分转载自博客园
http2.0协议再http1.1 http1.0及以前的版本基础上,进行相应的修改。主要的特性有:
1。 二进制协议
http1.0之前都是文本协议,http1.1版本的头信息是文本,数据体可以是文本或者二进制数据。
http2.0协议整个都是二进制数据,协议头和数据体都是二进制协议。
协议头和数据体,都被称为“帧”(frame):头信息帧和数据帧。
2. 多工(Multiplexing)
HTTP/2 复用TCP连接,在一个连接里,客户端和浏览器都可以同时发送多个请求或回应,而且不用按照顺序一一对应,这样就避免了"队头堵塞"。
3. 数据流
HTTP/2的数据包不是顺序发送的,同一个连接,可以连续发不同的请求包,每个请求包都有唯一的ID。另外还规定,客户端发出的数据流,ID一律为奇数,服务器发出的,ID为偶数。
数据流发送一半的时候,可以取消,只需要给服务器发送信号(RST_STREAM帧)。而HTTP1.1版本只能关闭TCP连接,而HTTP2.0不需要关闭TCP连接。
客户端可以指定数据流优先级,优先级越高,越快获得响应。
4. 头信息压缩
HTTP 协议不带有状态,每次请求都必须附上所有信息。所以,请求的很多字段都是重复的,比如Cookie和User Agent,一模一样的内容,每次请求都必须附带,这会浪费很多带宽,也影响速度。
HTTP/2 对这一点做了优化,引入了头信息压缩机制(header compression)。一方面,头信息使用gzip或compress压缩后再发送;另一方面,客户端和服务器同时维护一张头信息表,所有字段都会存入这个表,生成一个索引号,以后就不发送同样字段了,只发送索引号,这样就提高速度了。
5. 服务器推送
HTTP/2 允许服务器未经请求,主动向客户端发送资源,这叫做服务器推送(server push)。
常见场景是客户端请求一个网页,这个网页里面包含很多静态资源。正常情况下,客户端必须收到网页后,解析HTML源码,发现有静态资源,再发出静态资源请求。其实,服务器可以预期到客户端请求网页后,很可能会再请求静态资源,所以就主动把这些静态资源随着网页一起发给客户端了。
该部分转载自CSDN博客
1.TCP
TCP 的全称是Transmission Control Protocol ,传输控制协议。其首部字节为20~60字节
2 .UDP
UDP 的全称是 User Datagram Protocol,用户数据报协议。由8个字节(即4个字段)组成
3. 区别
TCP面向连接(如打电话要先拨号建立连接);UDP是无连接的,即发送数据之前不需要建立连接
TCP要求的系统资源较多,UDP较少
TCP提供可靠的服务。也就是说,通过TCP连接传送的数据,无差错,不丢失,不重复,且按序到达;UDP尽最大努力交付,即不保证可靠交付
TCP面向字节流,实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的UDP没有拥塞控制,因此网络出现拥塞不会使源主机的发送速率降低(对实时应用很有用,如IP电话,实时视频会议等)
每一条TCP连接只能是点到点的;UDP支持一对一,一对多,多对一和多对多的交互通信
TCP首部开销20字节;UDP的首部开销小,只有8个字节
TCP的逻辑通信信道是全双工的可靠信道;UDP则是不可靠信道
4. 补充
该部分节选自CSDN博客
三次握手过程理解
第一次握手:建立连接时,客户端发送syn包(syn=x)到服务器,并进入SYN_SENT状态,等待服务器确认;SYN:同步序列编号(Synchronize Sequence Numbers)。
第二次握手:服务器收到syn包,必须确认客户的SYN(ack=x+1),同时自己也发送一个SYN包(syn=y),即SYN+ACK包,此时服务器进入SYN_RECV状态;
第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=y+1),此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手。
【问题1】为什么连接的时候是三次握手,关闭的时候却是四次握手?
答:因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。
【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?
答:虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复,但该ACK可能丢失。Server如果没有收到ACK,将不断重复发送FIN片段。所以Client不能立即关闭,它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器,等待2MSL的时间。如果在该时间内再次收到FIN,那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间,2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL,Client都没有再次收到FIN,那么Client推断ACK已经被成功接收,则结束TCP连接。
【问题3】为什么不能用两次握手进行连接?
答:3次握手完成两个重要的功能,既要双方做好发送数据的准备工作(双方都知道彼此已准备好),也要允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手,死锁是可能发生的。作为例子,考虑计算机S和C之间的通信,假定C给S发送一个连接请求分组,S收到了这个分组,并发 送了确认应答分组。按照两次握手的协定,S认为连接已经成功地建立了,可以开始发送数据分组。可是,C在S的应答分组在传输中被丢失的情况下,将不知道S 是否已准备好,不知道S建立什么样的序列号,C甚至怀疑S是否收到自己的连接请求分组。在这种情况下,C认为连接还未建立成功,将忽略S发来的任何数据分 组,只等待连接确认应答分组。而S在发出的分组超时后,重复发送同样的分组。这样就形成了死锁。
【问题4】如果已经建立了连接,但是客户端突然出现故障了怎么办?
TCP还设有一个保活计时器,显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。
这里浓缩了CSDN大佬精华,原博文有60W+的访问量
1.TCP的状态
简单解释:
CLOSED:初始状态,表示TCP连接是“关闭着的”或“未打开的”。
LISTEN :表示服务器端的某个SOCKET处于监听状态,可以接受客户端的连接。
SYN_RCVD :表示服务器接收到了来自客户端请求连接的SYN报文。在正常情况下,这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态,很短暂,基本上用netstat很难看到这种状态,除非故意写一个监测程序,将三次TCP握手过程中最后一个ACK报文不予发送。当TCP连接处于此状态时,再收到客户端的ACK报文,它就会进入到ESTABLISHED 状态。
SYN_SENT :这个状态与SYN_RCVD 状态相呼应,当客户端SOCKET执行connect()进行连接时,它首先发送SYN报文,然后随即进入到SYN_SENT 状态,并等待服务端的发送三次握手中的第2个报文。SYN_SENT 状态表示客户端已发送SYN报文。
ESTABLISHED :表示TCP连接已经成功建立。
FIN_WAIT_1 :这个状态得好好解释一下,其实FIN_WAIT_1 和FIN_WAIT_2 两种状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是:FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时,它想主动关闭连接,向对方发送了FIN报文,此时该SOCKET进入到FIN_WAIT_1 状态。而当对方回应ACK报文后,则进入到FIN_WAIT_2 状态。当然在实际的正常情况下,无论对方处于任何种情况下,都应该马上回应ACK报文,所以FIN_WAIT_1 状态一般是比较难见到的,而FIN_WAIT_2 状态有时仍可以用netstat看到。
FIN_WAIT_2 :上面已经解释了这种状态的由来,实际上FIN_WAIT_2状态下的SOCKET表示半连接,即有一方调用close()主动要求关闭连接。注意:FIN_WAIT_2 是没有超时的(不像TIME_WAIT 状态),这种状态下如果对方不关闭(不配合完成4次挥手过程),那这个 FIN_WAIT_2 状态将一直保持到系统重启,越来越多的FIN_WAIT_2 状态会导致内核crash。
TIME_WAIT :表示收到了对方的FIN报文,并发送出了ACK报文。 TIME_WAIT状态下的TCP连接会等待2*MSL(Max Segment Lifetime,最大分段生存期,指一个TCP报文在Internet上的最长生存时间。每个具体的TCP协议实现都必须选择一个确定的MSL值,RFC 1122建议是2分钟,但BSD传统实现采用了30秒,Linux可以cat /proc/sys/net/ipv4/tcp_fin_timeout看到本机的这个值),然后即可回到CLOSED 可用状态了。如果FIN_WAIT_1状态下,收到了对方同时带FIN标志和ACK标志的报文时,可以直接进入到TIME_WAIT状态,而无须经过FIN_WAIT_2状态。(这种情况应该就是四次挥手变成三次挥手的那种情况)
CLOSING :这种状态在实际情况中应该很少见,属于一种比较罕见的例外状态。正常情况下,当一方发送FIN报文后,按理来说是应该先收到(或同时收到)对方的ACK报文,再收到对方的FIN报文。但是CLOSING 状态表示一方发送FIN报文后,并没有收到对方的ACK报文,反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢?那就是当双方几乎在同时close()一个SOCKET的话,就出现了双方同时发送FIN报文的情况,这是就会出现CLOSING 状态,表示双方都正在关闭SOCKET连接。
CLOSE_WAIT :表示正在等待关闭。怎么理解呢?当对方close()一个SOCKET后发送FIN报文给自己,你的系统毫无疑问地将会回应一个ACK报文给对方,此时TCP连接则进入到CLOSE_WAIT状态。接下来呢,你需要检查自己是否还有数据要发送给对方,如果没有的话,那你也就可以close()这个SOCKET并发送FIN报文给对方,即关闭自己到对方这个方向的连接。有数据的话则看程序的策略,继续发送或丢弃。简单地说,当你处于CLOSE_WAIT 状态下,需要完成的事情是等待你去关闭连接。
LAST_ACK :当被动关闭的一方在发送FIN报文后,等待对方的ACK报文的时候,就处于LAST_ACK 状态。当收到对方的ACK报文后,也就可以进入到CLOSED 可用状态了。
2.如何优化高并发TCP链接中产生的大量的TIME_WAIT的状态
通过上图,我们可以看到TIME_WAIT状态是在tcp断开链接时产生的,因为TCP连接是双向的,所以在关闭连接的时候,两个方向各自都需要关闭。先发FIN包的一方执行的是主动关闭;后发FIN包的一方执行的是被动关闭。主动关闭的一方会进入TIME_WAIT状态,并且在此状态停留两倍的MSL时长。
MSL指的是报文段的最大生存时间,如果报文段在网络活动了MSL时间,还没有被接收,那么会被丢弃。关于MSL的大小,RFC 793协议中给出的建议是两分钟,不过实际上不同的操作系统可能有不同的设置,以Linux为例,通常是半分钟,两倍的MSL就是一分钟,也就是60秒,并且这个数值是硬编码在内核中的,也就是说除非你重新编译内核,否则没法修改它。
TIME_WAIT状态存在的必要性。虽然双方都同意关闭连接了,而且握手的4个报文也都协调和发送完毕,按理可以直接回到CLOSED状态(就好比从SYN_SEND状态到ESTABLISH状态那样);但是因为我们必须要假想网络是不可靠的,你无法保证你最后发送的ACK报文会一定被对方收到,比如丢包或者延迟到达,因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文,而重发FIN报文,所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文,并保证于此。
简单说timewait之所以等待2MSL的时长,是为了避免因为网络丢包或者网络延迟而造成的tcp传输不可靠,而这个time_wait状态则可以最大限度的提升网络传输的可靠性。
TIME_WAIT状态过多的危害
TIME_WAIT状态是TCP链接中正常产生的一个状态,但凡事都有利弊,TIME_WAIT状态过多会存在以下的问题:
(1)在socket的TIME_WAIT状态结束之前,该socket所占用的本地端口号将一直无法释放。这也是文章开头的提到问题的一个原因之一。
(2)在高并发(每秒几万qps)并且采用短连接方式进行交互的系统中运行一段时间后,系统中就会存在大量的time_wait状态,如果time_wait状态把系统所有可用端口
都占完了且尚未被系统回收时,就会出现无法向服务端创建新的socket连接的情况。此时系统几乎停转,任何链接都不能建立。
(3)大量的time_wait状态也会系统一定的fd,内存和cpu资源,当然这个量一般比较小,并不是主要危害
如何优化TIME_WAIT过多的问题
总体来说,有两种方式:
方式一:调整系统内核参数
方式二:调整短链接为长链接
短连接和长连接工作方式的区别:
短连接
连接->传输数据->关闭连接
HTTP是无状态的,浏览器和服务器每进行一次HTTP操作,就建立一次连接,但任务结束就中断连接。
也可以这样说:短连接是指SOCKET连接后发送后接收完数据后马上断开连接。
长连接
连接->传输数据->保持连接 -> 传输数据-> 。。。->关闭连接。
长连接指建立SOCKET连接后不管是否使用都保持连接,但安全性较差。
从区别上可以看出,长连接比短连接从根本上减少了关闭连接的次数,减少了TIME_WAIT状态的产生数量,在高并发的系统中,这种方式的改动非常有效果,可以明显减少系统TIME_WAIT的数量。
该部分选自腾讯云博客
3.TCP CLOSE_WAIT 过多解决方案
linux 下 CLOSE_WAIT过多的解决方法
情景描述:系统产生大量“Too many open files”
原因分析:在服务器与客户端通信过程中,因服务器发生了socket未关导致的closed_wait发生,致使监听port打开的句柄数到了1024个,且均处于close_wait的状态,最终造成配置的port被占满出现“Too many open files”,无法再进行通信。
close_wait状态出现的原因是被动关闭方未关闭socket造成
一、解决:
原因是因为调用ServerSocket类的accept()方法和Socket输入流的read()方法时会引起线程阻塞,所以应该用setSoTimeout()方法设置超时(缺省的设置是0,即超时永远不会发生);超时的判断是累计式的,一次设置后,每次调用引起的阻塞时间都从该值中扣除,直至另一次超时设置或有超时异常抛出。
比如,某种服务需要三次调用read(),超时设置为1分钟,那么如果某次服务三次read()调用的总时间超过1分钟就会有异常抛出,如果要在同一个Socket上反复进行这种服务,就要在每次服务之前设置一次超时。
二、规避:
调整系统参数,包括句柄相关参数和TCP/IP的参数;
该部分选自CSDN博客
图解,server A免登录到server B:
1.在A上生成公钥私钥。
2.将公钥拷贝给server B,要重命名成authorized_keys(从英文名就知道含义了)
3.Server A向Server B发送一个连接请求。
4.Server B得到Server A的信息后,在authorized_key中查找,如果有相应的用户名和IP,则随机生成一个字符串,并用Server A的公钥加密,发送给Server A。
5.Server A得到Server B发来的消息后,使用私钥进行解密,然后将解密后的字符串发送给Server B。Server B进行和生成的对比,如果一致,则允许免登录。
总之:A要免密码登录到B,B首先要拥有A的公钥,然后B要做一次加密验证。对于非对称加密,公钥加密的密文不能公钥解开,只能私钥解开。
该部分选自CSDN博客
**十一\网络的七层通信模型
关于七层模型的介绍
七层模型,也称为OSI(Open System Interconnection)参考模型,是国际标准化组织(ISO)制定的一个用于计算机或通讯系统间互联的标准体系。它是一个七层的、抽象的模型体,不仅包括一系列抽象的术语或概念,也包括具体的协议。
ISO 就是 Internationalization Standard Organization(国际标准组织)。
起源
看一下OSI的起源和出现过程还是挺有意思的。
OSI的大部分设计工作实际上只是Honeywell Information System公司的一个小组完成的,小组的技术负责人是Charlie Bachman。在70年代中期,这个小组主要是为了开发一些原型系统而成立的,主要关注数据库系统的设计。
70年代中,为了支持数据库系统的访问,需要一个结构化的分布式通信系统体系结构。于是这个小组研究了现有的一些解决方案,其中包括IBM公司的SNA(System Network Architecture)、ARPANET(Internet的前身)的协议、以及为标准化的数据库正在研究中的一些表示服务(presentation services)的相关概念,在1977年提出了一个七层的体系结构模型,他们内部称之为分布式系统体系结构(DSA)。
与此同时,1977年英国标准化协会向国际标准化组织(ISO)提议,为了定义分布处理之间的通信基础设施,需要一个标准的体系结构。结果,ISO就开放系统互联(OSI)问题成立了一个专委会(TC 97, Subcomittee 16),指定由美国国家标准协会(ANSI)开发一个标准草案,在专委会第一次正式会议之前提交。Bachman 参加了ANSI早期的会议,并提交了他的七层模型,这个模型就成了提交ISO专委会的唯一的一份草案。
1978年3月,在ISO的OSI专委会在华盛顿召开的会议上,与会专家很快达成了共识,认为这个分层的体系结构能够满足开放式系统的大多数需求,而且具有可扩展的能力,能够满足新的需求。于是,1978年发布了这个临时版本,1979年稍作细化之后,成了最终的版本。所以,OSI模型和1977年DSA模型基本相同。
模型优点
建立七层模型的主要目的是为解决异种网络互连时所遇到的兼容性问题。它的最大优点是将服务、接口和协议这三个概念明确地区分开来:服务说明某一层为上一层提供一些什么功能,接口说明上一层如何使用下层的服务,而协议涉及如何实现本层的服务;这样各层之间具有很强的独立性,互连网络中各实体采用什么样的协议是没有限制的,只要向上提供相同的服务并且不改变相邻层的接口就可以了。网络七层的划分也是为了使网络的不同功能模块(不同层次)分担起不同的职责,从而带来如下好处:
● 减轻问题的复杂程度,一旦网络发生故障,可迅速定位故障所处层次,便于查找和纠错;
● 在各层分别定义标准接口,使具备相同对等层的不同网络设备能实现互操作,各层之间则相对独立,一种高层协议可放在多种低层协议上运行;
● 能有效刺激网络技术革新,因为每次更新都可以在小范围内进行,不需对整个网络动大手术;
● 便于研究和教学。
详细介绍
OSI中的上面4层(应用层、表示层、会话层、传输层)为高层,定义了程序的功能;下面3层(网络层、数据链路层、物理层)为低层,主要是处理面向网络的端到端数据流。
有一张网络图总结的很好:
应用层(Application Layer)
应用层是最靠近用户的OSI层。这一层为用户的应用程序(例如电子邮件、文件传输和终端仿真)提供网络服务。。
协议有:HTTP FTP TFTP SMTP SNMP DNS TELNET HTTPS POP3 DHCP等。
应用层也称为应用实体(AE),它由若干个特定应用服务元素(SASE)和一个或多个公用应用服务元素(CASE)组成。每个SASE提供特定的应用服务,例如文件运输访问和管理(FTAM)、电子文电处理(MHS)、虚拟终端协议(VAP)等。CASE提供一组公用的应用服务,例如联系控制服务元素(ACSE)、可靠运输服务元素(RTSE)和远程操作服务元素(ROSE)等。主要负责对软件提供接口以使程序能使用网络服务。术语“应用层”并不是指运行在网络上的某个特别应用程序 ,应用层提供的服务包括文件传输、文件管理以及电子邮件的信息处理。
表示层(Presentation Layer)
数据的表示、安全、压缩。可确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取。
格式有:JPEG、ASCll、DECOIC、加密格式等。
应用程序和网络之间的翻译官,在表示层,数据将按照网络能理解的方案进行格式化;这种格式化也因所使用网络的类型不同而不同。
表示层管理数据的解密与加密,如系统口令的处理。例如:在 Internet上查询你银行账户,使用的即是一种安全连接。你的账户数据在发送前被加密,在网络的另一端,表示层将对接收到的数据解密。除此之外,表示层协议还对图片和文件格式信息进行解码和编码。
会话层(Session Layer)
建立、管理、终止会话,对应主机进程,指本地主机与远程主机正在进行的会话。
通过传输层(端口号:传输端口与接收端口)建立数据传输的通路。主要在你的系统之间发起会话或者接受会话请求(设备之间需要互相认识可以是IP也可以是MAC或者是主机名)。
负责在网络中的两节点之间建立、维持和终止通信。 会话层的功能包括:建立通信链接,保持会话过程通信链接的畅通,同步两个节点之间的对话,决定通信是否被中断以及通信中断时决定从何处重新发送。
你可能常常听到有人把会话层称作网络通信的“交通警察”。当通过拨号向你的 ISP (因特网服务提供商)请求连接到因特网时,ISP 服务器上的会话层向你与你的 PC 客户机上的会话层进行协商连接。若你的电话线偶然从墙上插孔脱落时,你终端机上的会话层将检测到连接中断并重新发起连接。会话层通过决定节点通信的优先级和通信时间的长短来设置通信期限。
传输层(Transport Layer)
定义传输数据的协议端口号,以及流控和差错校验。
协议有:TCP UDP等,数据包一旦离开网卡即进入网络传输层。
定义了一些传输数据的协议和端口号(WWW端口80等),如:TCP(传输控制协议,传输效率低,可靠性强,用于传输可靠性要求高,数据量大的数据),UDP(用户数据报协议,与TCP特性恰恰相反,用于传输可靠性要求不高,数据量小的数据,如QQ聊天数据就是通过这种方式传输的)。 主要是将从下层接收的数据进行分段和传输,到达目的地址后再进行重组。常常把这一层数据叫做段。
O S I 模型中最重要的一层。传输协议同时进行流量控制或是基于接收方可接收数据的快慢程度规定适当的发送速率。除此之外,传输层按照网络能处理的最大尺寸将较长的数据包进行强制分割。例如,以太网无法接收大于1 5 0 0 字节的数据包。发送方节点的传输层将数据分割成较小的数据片,同时对每一数据片安排一序列号,以便数据到达接收方节点的传输层时,能以正确的顺序重组。该过程即被称为排序。工作在传输层的一种服务是 T C P / I P 协议套中的T C P (传输控制协议),另一项传输层服务是I P X / S P X 协议集的S P X (序列包交换)。
网络层(Network Layer)
进行逻辑地址寻址,实现不同网络之间的路径选择。
协议有:ICMP IGMP IP(IPV4 IPV6) ARP RARP等。
在位于不同地理位置的网络中的两个主机系统之间提供连接和路径选择。Internet的发展使得从世界各站点访问信息的用户数大大增加,而网络层正是管理这种连接的层。
O S I 模型的第三层,其主要功能是将网络地址翻译成对应的物理地址,并决定如何将数据从发送方路由到接收方。
网络层通过综合考虑发送优先权、网络拥塞程度、服务质量以及可选路由的花费来决定从一个网络中节点A 到另一个网络中节点B 的最佳路径。由于网络层处理,并智能指导数据传送,路由器连接网络各段,所以路由器属于网络层。在网络中,“路由”是基于编址方案、使用模式以及可达性来指引数据的发送。
网络层负责在源机器和目标机器之间建立它们所使用的路由。这一层本身没有任何错误检测和修正机制,因此,网络层必须依赖于端端之间的由D L L提供的可靠传输服务。
网络层用于本地L A N网段之上的计算机系统建立通信,它之所以可以这样做,是因为它有自己的路由地址结构,这种结构与第二层机器地址是分开的、独立的。这种协议称为路由或可路由协议。路由协议包括I P、N o v e l l公司的I P X以及A p p l e Ta l k协议。
网络层是可选的,它只用于当两个计算机系统处于不同的由路由器分割开的网段这种情况,或者当通信应用要求某种网络层或传输层提供的服务、特性或者能力时。例如,当两台主机处于同一个L A N网段的直接相连这种情况,它们之间的通信只使用L A N的通信机制就可以了(即OSI 参考模型的一二层)。
数据链路层(Datalink Layer)
建立逻辑连接、进行硬件地址寻址、差错校验等功能。(由底层网络定义协议)
将比特组合成字节进而组合成帧,用MAC地址访问介质,错误发现但不能纠正。
数据链路层协议的代表包括:SDLC、HDLC、PPP、STP、帧中继等。
定义了如何让格式化数据以进行传输,以及如何让控制对物理介质的访问。这一层通常还提供错误检测和纠正,以确保数据的可靠传输。
OSI模型的第二层,它控制网络层与物理层之间的通信。它的主要功能是如何在不可靠的物理线路上进行数据的可靠传递。为了保证传输,从网络层接收到的数据被分割成特定的可被物理层传输的帧。帧是用来移动数据的结构包,它不仅包括原始数据,还包括发送方和接收方的物理地址以及检错和控制信息。其中的地址确定了帧将发送到何处,而纠错和控制信息则确保帧无差错到达。 如果在传送数据时,接收点检测到所传数据中有差错,就要通知发送方重发这一帧。
数据链路层的功能独立于网络和它的节点和所采用的物理层类型,它也不关心是否正在运行 Wo r d 、E x c e l 或使用I n t e r n e t 。有一些连接设备,如交换机,由于它们要对帧解码并使用帧信息将数据发送到正确的接收方,所以它们是工作在数据链路层的。
数据链路层(DataLinkLayer):在物理层提供比特流服务的基础上,建立相邻结点之间的数据链路,通过差错控制提供数据帧(Frame)在信道上无差错的传输,并进行各电路上的动作系列。
数据链路层在不可靠的物理介质上提供可靠的传输。该层的作用包括:物理地址寻址、数据的成帧、流量控制、数据的检错、重发等。
物理层(Physical Layer)
建立、维护、断开物理连接。(由底层网络定义协议)
主要定义物理设备标准,如网线的接口类型、光纤的接口类型、各种传输介质的传输速率等。它的主要作用是传输比特流(就是由1、0转化为电流强弱来进行传输,到达目的地后在转化为1、0,也就是我们常说的数模转换与模数转换)。这一层的数据叫做比特。
O S I 模型的最低层或第一层,该层包括物理连网媒介,如电缆连线连接器。物理层的协议产生并检测电压以便发送和接收携带数据的信号。在你的桌面P C 上插入网络接口卡,你就建立了计算机连网的基础。换言之,你提供了一个物理层。尽管物理层不提供纠错服务,但它能够设定数据传输速率并监测数据出错率。网络物理问题,如电线断开,将影响物理层。 用户要传递信息就要利用一些物理媒体,如双绞线、同轴电缆等,但具体的物理媒体并不在OSI的7层之内,有人把物理媒体当做第0层,物理层的任务就是为它的上一层提供一个物理连接,以及它们的机械、电气、功能和过程特性。如规定使用电缆和接头的类型、传送信号的电压等。在这一层,数据还没有被组织,仅作为原始的位流或电气电压处理,单位是bit比特。
补充知识
一个设备工作在哪一层,关键看它工作时利用哪一层的数据头部信息。网桥工作时,是以MAC头部来决定转发端口的,因此显然它是数据链路层的设备。
具体说:
物理层:网卡,网线,集线器,中继器,调制解调器
数据链路层:网桥,交换机
网络层:路由器
网关工作在第四层传输层及其以上。
集线器是物理层设备,采用广播的形式来传输信息。
交换机就是用来进行报文交换的机器。多为链路层设备(二层交换机),能够进行地址学习,采用存储转发的形式来交换报文.。
路由器的一个作用是连通不同的网络,另一个作用是选择信息传送的线路。选择通畅快捷的近路,能大大提高通信速度,减轻网络系统通信负荷,节约网络系统资源,提高网络系统畅通率。
交换机和路由器的区别
交换机拥有一条很高带宽的背部总线和内部交换矩阵。交换机的所有的端口都挂接在这条总线上,控制电路收到数据包以后,处理端口会查找内存中的地址对照表以确定目的MAC(网卡的硬件地址)的NIC(网卡)挂接在哪个端口上,通过内部交换矩阵迅速将数据包传送到目的端口,目的MAC若不存在则广播到所有的端口,接收端口回应后交换机会“学习”新的地址,并把它添加入内部MAC地址表中。
使用交换机也可以把网络“分段”,通过对照MAC地址表,交换机只允许必要的网络流量通过交换机。通过交换机的过滤和转发,可以有效的隔离广播风暴,减少误包和错包的出现,避免共享冲突。
交换机在同一时刻可进行多个端口对之间的数据传输。每一端口都可视为独立的网段,连接在其上的网络设备独自享有全部的带宽,无须同其他设备竞争使用。当节点A向节点D发送数据时,节点B可同时向节点C发送数据,而且这两个传输都享有网络的全部带宽,都有着自己的虚拟连接。假使这里使用的是10Mbps的以太网交换机,那么该交换机这时的总流通量就等于2×10Mbps=20Mbps,而使用10Mbps的共享式HUB时,一个HUB的总流通量也不会超出10Mbps。
总之,交换机是一种基于MAC地址识别,能完成封装转发数据包功能的网络设备。交换机可以“学习”MAC地址,并把其存放在内部地址表中,通过在数据帧的始发者和目标接收者之间建立临时的交换路径,使数据帧直接由源地址到达目的地址。
从过滤网络流量的角度来看,路由器的作用与交换机和网桥非常相似。但是与工作在网络物理层,从物理上划分网段的交换机不同,路由器使用专门的软件协议从逻辑上对整个网络进行划分。例如,一台支持IP协议的路由器可以把网络划分成多个子网段,只有指向特殊IP地址的网络流量才可以通过路由器。对于每一个接收到的数据包,路由器都会重新计算其校验值,并写入新的物理地址。因此,使用路由器转发和过滤数据的速度往往要比只查看数据包物理地址的交换机慢。但是,对于那些结构复杂的网络,使用路由器可以提高网络的整体效率。路由器的另外一个明显优势就是可以自动过滤网络广播。
集线器与路由器在功能上有什么不同?
首先说HUB,也就是集线器。它的作用可以简单的理解为将一些机器连接起来组成一个局域网。而交换机(又名交换式集线器)作用与集线器大体相同。但是两者在性能上有区别:集线器采用的式共享带宽的工作方式,而交换机是独享带宽。这样在机器很多或数据量很大时,两者将会有比较明显的。而路由器与以上两者有明显区别,它的作用在于连接不同的网段并且找到网络中数据传输最合适的路径。路由器是产生于交换机之后,就像交换机产生于集线器之后,所以路由器与交换机也有一定联系,不是完全独立的两种设备。路由器主要克服了交换机不能路由转发数据包的不足。
总的来说,路由器与交换机的主要区别体现在以下几个方面:
(1)工作层次不同
最初的的交换机是工作在数据链路层,而路由器一开始就设计工作在网络层。由于交换机工作在数据链路层,所以它的工作原理比较简单,而路由器工作在网络层,可以得到更多的协议信息,路由器可以做出更加智能的转发决策。
(2)数据转发所依据的对象不同
交换机是利用物理地址或者说MAC地址来确定转发数据的目的地址。而路由器则是利用IP地址来确定数据转发的地址。IP地址是在软件中实现的,描述的是设备所在的网络。MAC地址通常是硬件自带的,由网卡生产商来分配的,而且已经固化到了网卡中去,一般来说是不可更改的。而IP地址则通常由网络管理员或系统自动分配。
(3)传统的交换机只能分割冲突域,不能分割广播域;而路由器可以分割广播域
由交换机连接的网段仍属于同一个广播域,广播数据包会在交换机连接的所有网段上传播,在某些情况下会导致通信拥挤和安全漏洞。连接到路由器上的网段会被分配成不同的广播域,广播数据不会穿过路由器。虽然第三层以上交换机具有VLAN功能,也可以分割广播域,但是各子广播域之间是不能通信交流的,它们之间的交流仍然需要路由器。
(4)路由器提供了防火墙的服务
路由器仅仅转发特定地址的数据包,不传送不支持路由协议的数据包传送和未知目标网络数据包的传送,从而可以防止广播风暴。
负载均衡设备也常被称为四到七层交换机,那么四层和七层两者到底区别在哪里?
1、技术原理上的区别
所谓四层负载均衡,也就是主要通过报文中的目标地址和端口,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器。四层负载均衡是目标地址和端口的交换。
以常见的TCP为例,负载均衡设备在接收到第一个来自客户端的SYN 请求时,即通过上述方式选择一个最佳的服务器,并对报文中目标IP地址进行修改(改为后端服务器IP),直接转发给该服务器。TCP的连接建立,即三次握手是客户端和服务器直接建立的,负载均衡设备只是起到一个类似路由器的转发动作。在某些部署情况下,为保证服务器回包可以正确返回给负载均衡设备,在转发报文的同时可能还会对报文原来的源地址进行修改。
所谓七层负载均衡,也称为内容交换,也就是主要通过报文中的真正有意义的应用层内容,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器。
以常见的TCP为例,负载均衡设备如果要根据真正的应用层内容再选择服务器,只能先代理最终的服务器和客户端建立连接(三次握手)后,才可能接受到客户端发送的真正应用层内容的报文,然后再根据该报文中的特定字段,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器。负载均衡设备在这种情况下,更类似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别建立TCP连接。所以从这个技术原理上来看,七层负载均衡明显的对负载均衡设备的要求更高,处理七层的能力也必然会低于四层模式的部署方式。那么,为什么还需要七层负载均衡呢?
2、应用场景的需求
七层应用负载的好处,是使得整个网络更智能化, 参考这篇文章 利用负载均衡优化和加速HTTP应用,就可以基本上了解这种方式的优势所在。例如访问一个网站的用户流量,可以通过七层的方式,将对图片类的请求转发到特定的图片服务器并可以使用缓存技术;将对文字类的请求可以转发到特定的文字服务器并可以使用压缩技术。当然这只是七层应用的一个小案例,从技术原理上,这种方式可以对客户端的请求和服务器的响应进行任意意义上的修改,极大的提升了应用系统在网络层的灵活性。很多在后台,(例如Nginx或者Apache)上部署的功能可以前移到负载均衡设备上,例如客户请求中的Header重写,服务器响应中的关键字过滤或者内容插入等功能。
另外一个常常被提到功能就是安全性。网络中最常见的SYN Flood攻击,即黑客控制众多源客户端,使用虚假IP地址对同一目标发送SYN攻击,通常这种攻击会大量发送SYN报文,耗尽服务器上的相关资源,以达到Denial of Service(DoS)的目的。从技术原理上也可以看出,四层模式下这些SYN攻击都会被转发到后端的服务器上;而七层模式下这些SYN攻击自然在负载均衡设备上就截止,不会影响后台服务器的正常运营。另外负载均衡设备可以在七层层面设定多种策略,过滤特定报文,例如SQL Injection等应用层面的特定攻击手段,从应用层面进一步提高系统整体安全。
现在的7层负载均衡,主要还是着重于应用广泛的HTTP协议,所以其应用范围主要是众多的网站或者内部信息平台等基于B/S开发的系统。 4层负载均衡则对应其他TCP应用,例如基于C/S开发的ERP等系统。
3、七层应用需要考虑的问题
TCP的流量控制
所谓的流量控制就是让发送方的发送速率不要太快,让接收方来得及接受。利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制。TCP的窗口单位是字节,不是报文段,发送方的发送窗口不能超过接收方给出的接收窗口的数值。
如图所示,说明了利用可变窗口大小进行流量控制。设主机A向主机B发送数据。双方确定的窗口值是400.再设每一个报文段为100字节长,序号的初始值为seq=1,图中的箭头上面大写ACK,表示首部中的却认为为ACK,小写ack表示确认字段的值。
接收方的主机B进行了三次流量控制。第一次把窗口设置为rwind=300,第二次减小到rwind=100最后减到rwind=0,即不允许发送方再发送过数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。
假如,B向A发送了零窗口的报文段后不久,B的接收缓存又有了一些存储空间。于是B向A发送了rwind=400的报文段,然而这个报文段在传送中丢失 了。A一直等待收到B发送的非零窗口的通知,而B也一直等待A发送的数据。这样就死锁了。为了解决这种死锁状态,TCP为每个连接设有一个持续计时器。只 要TCP连接的一方收到对方的零窗口通知,就启动持续计时器,若持续计时器设置的时间到期,就发送一个零窗口探测报文段(仅携带1字节的数据),而对方就在确认这个探测报文段时给出了现在的窗口值。
TCP报文段发送时机的选择
TCP报文段发送时机主要有以下几种选择途径。
TCP的拥塞控制
1.拥塞控制的原理
在某段时间,若对网络中的某一资源的需求超过了该资源所能提供的可用部分,网络的性能就要变化,这种情况叫做拥塞。网络拥塞往往是由许多因素引起的,简单的提高节点处理机的速度或者扩大结点缓存的存储空间并不能解决拥塞问题。拥塞问题的是指往往是整个系统的各个部分不匹配,只有各个部分平衡了,问题才会得到解决。
2.拥塞控制和流量控制的差别
所谓拥塞控制就是防止过多的数据注入到网络中,这样可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提,就是网络能承受现有的网络负荷。拥塞问题是一个全局性的问题,涉及到所有的主机、所有的路由器、以及与降低网络传输性能有关的所有因素。流量控制往往指的是点对点通信量的控制,是个端到端的问题。流量控制所要做的就是控制发送端发送数据的速率,以便使接收端来得及接受。
3.拥塞控制设计
拥塞控制是很难设计的,因为它是一个动态的问题,许多情况下,甚至正是拥塞控制机制本身成为引起网络性能恶化甚至死锁的原因。从控制理论的角度来看拥塞控制这个问题,可以分为开环控制和闭环控制两种方法。开环控制就是在设计网络时事先将有关拥塞发生的所有因素考虑周到,一旦系统运行起来就不能在中途改正。
闭环控制是基于反馈环路的概念,包括如下措施:
4.拥塞控制方法
因特网建议标准RFC2581定义了进行拥塞控制的四种算法,即慢开始(Slow-start)、拥塞避免(Congestion Avoidance)、快重传(Fast Restrangsmit)和快回复(Fast Recovery)。我们假定
这里用报文段的个数的拥塞窗口大小举例说明慢开始算法,实时拥塞窗口大小是以字节为单位的。如下图:
为了防止cwnd增长过大引起网络拥塞,还需设置一个慢开始门限ssthresh状态变量。ssthresh的用法如下:
当cwnd
当cwnd>ssthresh时,改用拥塞避免算法。
当cwnd=ssthresh时,慢开始与拥塞避免算法任意。
拥塞避免算法思路:让拥塞窗口缓慢增长,即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1,而不是加倍。这样拥塞窗口按线性规律缓慢增长。
无论是在慢开始阶段还是在拥塞避免阶段,只要发送方判断网络出现拥塞(其根据就是没有收到确认,虽然没有收到确认可能是其他原因的分组丢失,但是因为无法判定,所以都当做拥塞来处理),就把慢开始门限设置为出现拥塞时的发送窗口大小的一半。然后把拥塞窗口设置为1,执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数,使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。
如下图:
乘法减小和加法增大
乘法减小:是指不论在慢开始阶段还是拥塞避免阶段,只要出现超时,就把慢开始门限减半,即设置为当前的拥塞窗口的一半(于此同时,执行慢开始算法)。当网络出现频繁拥塞时,ssthresh值就下降的很快,以大大将小注入到网络中的分组数。
加法增大:是指执行拥塞避免算法后是拥塞窗口缓慢增大,以防止网络过早出现拥塞。
快重传和快恢复
一条TCP连接有时会因等待重传计时器的超时而空闲较长的时间,慢开始和拥塞避免无法很好的解决这类问题,因此提出了快重传和快恢复的拥塞控制方法。快重传算法并非取消了重传机制,只是在某些情况下更早的重传丢失的报文段(如果当发送端接收到三个重复的确认ACK时,则断定分组丢失,立即重传丢失的报文段,而不必等待重传计时器超时)。
快重传要求接收方在收到一个失序的报文段后就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方)而不要等到自己发送数据时捎带确认。**快重传算法规定,发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段,而不必继续等待设置的重传计时器时间到期。**如下图:
快重传配合使用的还有快恢复算法,有以下两个要点:
①当发送方连续收到三个重复确认时,就执行“乘法减小”算法,把ssthresh门限减半。但是接下去并不执行慢开始算法。
②考虑到如果网络出现拥塞的话就不会收到好几个重复的确认,所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法,而是将cwnd设置为ssthresh减半后的大小,然后执行拥塞避免算法。如下图:
在采用快恢复算法时,慢开始算法只是在TCP连接建立时和网络出现超时时才使用。
接受窗口又称为通知窗口。因此从接收方对发送方的流量控制角度考虑,发送方的发送窗口一定不能超过对方给出的接受窗口的RWND。
也就是说:发送窗口的上限=Min[rwnd,cwnd].
随机早期检测RED
以上的拥塞避免算法并没有和网络层联系起来,实际上网络层的策略对拥塞避免算法影响最大的就是路由器的丢弃策略。在简单的情况下路由器通常按照先进先出的策略处理到来的分组。当路由器的缓存装不下分组的时候就丢弃到来的分组,这叫做尾部丢弃策略。这样就会导致分组丢失,发送方认为网络产生拥塞。更为严重的是网络中存在很多的TCP连接,这些连接中的报文段通常是复用路由路径。若发生路由器的尾部丢弃,可能影响到很多条TCP连接,结果就是这许多的TCP连接在同一时间进入慢开始状态。这在术语中称为全局同步。全局同步会使得网络的通信量突然下降很多,而在网络恢复正常之后,其通信量又突然增大很多。
为避免发生网路中的全局同步现象,路由器采用随机早期检测(RED:randomearly detection)。该算法要点如下:
使路由器的队列维持两个参数,即队列长队最小门限min和最大门限max,每当一个分组到达的时候,RED就计算平均队列长度。然后分情况对待到来的分组:
①平均队列长度小于最小门限——把新到达的分组放入队列排队。
②平均队列长度在最小门限与最大门限之间——则按照某一概率将分组丢弃。
③平均队列长度大于最大门限——丢弃新到达的分组。
RED不是等到已经发生拥塞后才把所有队列尾部的分组全部丢弃,而是在检测到网络拥塞的早期征兆时(即路由器的平均队列长度超过一定门限值时),以概率p随机丢弃分组,让拥塞控制只在个别的TCP连接上执行,因而避免全局性的拥塞控制。
RED的关键就是选择三个参数最小门限、最大门限、丢弃概率和计算平均队列长度。最小门线必须足够大,以保证路由器的输出链路有较高的利用率。而最大门限和最小门限只差也应该足够大,是的在一个TCP往返时间RTT中队列的正常增长仍在最大门限之内。经验证明:使最大门限等于最小门限的二倍是合适的。
平均队列长度采用加权平均的方法计算平均队列长度,这和往返时间(RTT)的计算策略是一样的。
1. ARP出现原因
ARP协议是“Address Resolution Protocol”(地址解析协议)的缩写。其作用是在以太网环境中,数据的传输所依懒的是MAC地址而非IP地址,而将已知IP地址转换为MAC地址的工作是由ARP协议来完成的。
在局域网中,网络中实际传输的是“帧”,帧里面是有目标主机的MAC地址的。在以太网中,一个主机和另一个主机进行直接通信,必须要知道目标主机的MAC地址。但这个目标MAC地址是如何获得的呢?它就是通过地址解析协议获得的。所谓“地址解析”就是主机在发送帧前将目标IP地址转换成目标MAC地址的过程。ARP协议的基本功能就是通过目标设备的IP地址,查询目标设备的MAC地址,以保证通信的顺利进行。
2. ARP映射方式
2.1. 静态映射
静态映射的意思是要手动创建一张ARP表,把逻辑(IP)地址和物理地址关联起来。这个ARP表储存在网络中的每一台机器上。例如,知道其机器的IP地址但不知道其物理地址的机器就可以通过查ARP表找出对应的物理地址。这样做有一定的局限性,因为物理地址可能发生变化:
(1)机器可能更换NIC(网络适配器),结果变成一个新的物理地址。
(2)在某些局域网中,每当计算机加电时,他的物理地址都要改变一次。
(3)移动电脑可以从一个物理网络转移到另一个物理网络,这样会时物理地址改变。
要避免这些问题出现,必须定期维护更新ARP表,此类比较麻烦而且会影响网络性能。
2.2. 动态映射
动态映射时,每次只要机器知道另一台机器的逻辑(IP)地址,就可以使用协议找出相对应的物理地址。已经设计出的实现了动态映射协议的有ARP和RARP两种。ARP把逻辑(IP)地址映射为物理地址。RARP把物理地址映射为逻辑(IP)地址。
3. ARP原理及流程
在任何时候,一台主机有IP数据报文发送给另一台主机,它都要知道接收方的逻辑(IP)地址。但是IP地址必须封装成帧才能通过物理网络。这就意味着发送方必须有接收方的物理(MAC)地址,因此需要完成逻辑地址到物理地址的映射。而ARP协议可以接收来自IP协议的逻辑地址,将其映射为相应的物理地址,然后把物理地址递交给数据链路层。
3.1.ARP请求
任何时候,当主机需要找出这个网络中的另一个主机的物理地址时,它就可以发送一个ARP请求报文,这个报文包好了发送方的MAC地址和IP地址以及接收方的IP地址。因为发送方不知道接收方的物理地址,所以这个查询分组会在网络层中进行广播。
3.2.ARP响应
局域网中的每一台主机都会接受并处理这个ARP请求报文,然后进行验证,查看接收方的IP地址是不是自己的地址,只有验证成功的主机才会返回一个ARP响应报文,这个响应报文包含接收方的IP地址和物理地址。这个报文利用收到的ARP请求报文中的请求方物理地址以单播的方式直接发送给ARP请求报文的请求方。
ARP协议报文字段抓包解析
1.PING命令的实现原理
ping属于一个通信协议,是TCP/IP协议的一部分。利用“ping”命令可以检查网络是否通畅或者网络连接速度,很好地分析和判定网络故障。
Ping发送一个ICMP(Internet Control Messages Protocol),即因特网信报控制协议;接收端回声消息给目的地并报告是否收到所希望的ICMPecho (ICMP回声应答)。它的原理是:利用网络上机器IP地址的唯一性,给目标IP地址发送一个数据包,通过对方回复的数据包来确定两台网络机器是否连接相通,时延是多少。
ping是端对端连通,通常用来作为可用性的检查,但是某些病毒木马会强行远程执行大量ping命令抢占你的网络资源,导致系统变慢,网速变慢。严禁ping入侵作为大多数防火墙的一个基本功能提供给用户进行选择。通常的情况下你如果不用作服务器或者进行网络测试,可以放心的选中它,保护你的电脑。
2.PING命令为什么不需要端口号呢?
ICMP全称Internet Control Message Protocol(网际控制信息协议)。提起ICMP,一些人可能会感到陌生,实际上,ICMP与我们息息相关。在网络体系结构的各层次中,都需要控制,而不同的层次有不同的分工和控制内容,IP层的控制功能是最复杂的,主要负责差错控制、拥塞控制等,任何控制都是建立在信息的基础之上的,在基于IP数据报的网络体系中,网关必须自己处理数据报的传输工作,而IP协议自身没有内在机制来获取差错信息并处理。为了处理这些错误,TCP/IP设计了ICMP协议,当某个网关发现传输错误时,立即向信源主机发送ICMP报文,报告出错信息,让信源主机采取相应处理措施,它是一种差错和控制报文协议,不仅用于传输差错报文,还传输控制报文。
它是控制协议,不需要端口号。
3.ICMP协议查看远程服务器的原理
向远程计算机通过ICMP协议发送特定的数据包,然后等待回应并接收返回的数据包
,对每个接收的数据包均根据传输的消息进行验证。默认情况下,传输四个包含 32 字节
数据(由字母组成的一个循环大写字母序列)的回显数据包。过程如下:
(1)通过将 ICMP 回显数据包发送到计算机并侦听回显回复数据包来验证与一台或多台
远程计算机的连接。
(2)每个发送的数据包最多等待一秒。
(3)打印已传输和接收的数据包数。
从用户输入一个网址到网页最终展现到用户面前,中间的大致流程总结如下:
在客户端浏览器中输入网址URL。
发送到DNS(域名服务器)获得域名对应的WEB服务器的IP地址。
客户端浏览器与WEB服务器建立TCP(传输控制协议)连接。
客户端浏览器向对应IP地址的WEB服务器发送相应的HTTP或HTTPS请求。
WEB服务器响应请求,返回指定的URL数据或错误信息;如果设定重定向,则重定向到新的URL地址。
客户端浏览器下载数据,解析HTML源文件,解析的过程中实现对页面的排版,解析完成后,在浏览器中显示基础的页面。
分析页面中的超链接,显示在当前页面,重复以上过程直至没有超链接需要发送,完成页面的全部显示。
1)什么是DNS?
DNS(Domain Name System,域名系统),因特网上作为域名和IP地址相互映射的一个分布式数据库,能够使用户更方便的访问互联网,而不用去记住能够被机器直接读取的IP数串。通过主机名,最终得到该主机名对应的IP地址的过程叫做域名解析(或主机名解析)。
通俗的讲,我们更习惯于记住一个网站的名字,比如www.baidu.com,而不是记住它的ip地址,比如:167.23.10.2。而计算机更擅长记住网站的ip地址,而不是像www.baidu.com等链接。因为,DNS就相当于一个电话本,比如你要找www.baidu.com这个域名,那我翻一翻我的电话本,我就知道,哦,它的电话(ip)是167.23.10.2。
2)DNS查询的两种方式:递归查询和迭代查询
1、递归解析
当局部DNS服务器自己不能回答客户机的DNS查询时,它就需要向其他DNS服务器进行查询。此时有两种方式,如图所示的是递归方式。局部DNS服务器自己负责向其他DNS服务器进行查询,一般是先向该域名的根域服务器查询,再由根域名服务器一级级向下查询。最后得到的查询结果返回给局部DNS服务器,再由局部DNS服务器返回给客户端。
2、迭代解析
当局部DNS服务器自己不能回答客户机的DNS查询时,也可以通过迭代查询的方式进行解析,如图所示。局部DNS服务器不是自己向其他DNS服务器进行查询,而是把能解析该域名的其他DNS服务器的IP地址返回给客户端DNS程序,客户端DNS程序再继续向这些DNS服务器进行查询,直到得到查询结果为止。也就是说,迭代解析只是帮你找到相关的服务器而已,而不会帮你去查。比如说:baidu.com的服务器ip地址在192.168.4.5这里,你自己去查吧,本人比较忙,只能帮你到这里了。
什么是域名?
域名是由一串用点分隔符 . 组成的互联网上某一台计算机或计算机组的名称,用于在数据传输时标识计算机的方位。域名可以说是一个 IP 地址的代称,目的是为了便于记忆后者。例如,wikipedia.org 是一个域名,和 IP 地址 208.80.152.2 相对应。人们可以直接访问 wikipedia.org 来代替 IP 地址,然后域名系统(DNS)就会将它转化成便于机器识别的 IP 地址。这样,人们只需要记忆 wikipedia.org 这一串带有特殊含义的字符,而不需要记忆没有含义的数字。
在域名系统的层次结构中,各种域名都隶属于域名系统根域的下级。域名的第一级是顶级域,它包括通用顶级域,例如 .com、.net 和 .org;以及国家和地区顶级域,例如 .us、.cn 和 .tk。顶级域名下一层是二级域名,一级一级地往下。这些域名向人们提供注册服务,人们可以用它创建公开的互联网资源或运行网站。顶级域名的管理服务由对应的域名注册管理机构(域名注册局)负责,注册服务通常由域名注册商负责。
授权型 DNS - 一种授权型 DNS 服务提供一种更新机制,供开发人员用于管理其公用 DNS 名称。然后,它响应 DNS 查询,将域名转换为 IP 地址,以便计算机可以相互通信。授权型 DNS 对域有最终授权且负责提供递归型 DNS 服务器对 IP 地址信息的响应。Amazon Route 53 是一种授权型 DNS 系统。
递归型 DNS - 客户端通常不会对授权型 DNS 服务直接进行查询。而是通常连接到称为解析程序的其他类型 DNS 服务,或递归型 DNS 服务。递归型 DNS 服务就像是旅馆的门童:尽管没有任何自身的 DNS 记录,但是可充当代表您获得 DNS 信息的中间程序。如果递归型 DNS 拥有已缓存或存储一段时间的 DNS 参考,那么它会通过提供源或 IP 信息来响应 DNS 查询。如果没有,则它会将查询传递到一个或多个授权型 DNS 服务器以查找信息。
记录类型
DNS 中,常见的资源记录类型有:
NS 记录(域名服务) ─ 指定解析域名或子域名的 DNS 服务器。
MX 记录(邮件交换) ─ 指定接收信息的邮件服务器。
A 记录(地址) ─ 指定域名对应的 IPv4 地址记录。
AAAA 记录(地址) ─ 指定域名对应的 IPv6 地址记录。
NAME(规范) ─ 一个域名映射到另一个域名或 CNAME 记录( example.com 指向 www.example.com )或映射到一个 A记录。
PTR 记录(反向记录) ─ PTR 记录用于定义与 IP 地址相关联的名称。 PTR 记录是 A 或 AAAA 记录的逆。 PTR 记录是唯一的,因为它们以 .arpa 根开始并被委派给 IP 地址的所有者。
域名解析
主机名到 IP 地址的映射有两种方式:
通过域名去查询域名服务器,得到 IP 地址的过程叫做域名解析。在解析域名时,一般先静态域名解析,再动态解析域名。可以将一些常用的域名放入静态域名解析表中,这样可以大大提高域名解析效率。
该部分来自简书
参看这里06年博文
路由器(router)是互联网的枢纽,是连接英特网中各局域网、广域网的设备,它会根据信道的情况自动选择和设定路由,以最佳路径,按前后顺序发送数据。
作用在OSI模型的第三层,提供了路由与转发两种重要机制
路由:路由器控制层面的工作,决定数据包从来源端到目的端所经过的路由路径(host到host至今的最佳传输路径)
转发:路由器数据层面的工作,将路由器输入端的数据包移送至适当的路由器输出端(在路由器内部进行)
路由器是一种具有多个输入端口和多个输出端口的专用计算机,其任务是转发分组。
也就是说,将路由器某个输入端口收到的分组,按照分组要去的目的地,把该分组从路由器的某个合适的输出端口转发给下一跳的路由器。
下一跳的路由器也按照这种方法处理分组,直到该分组到达终点为止。
路由器工作在OSI模型三层(网络层)
收到数据包后根据OSI模型层层将数据包拆开,到网络层后根据IP进行路由转发
根据接口协议层层封装,实现异种网络的互联
路由器内部整体分为两部分:路由选择部分、分组转发部分
路由选择部分:软件、控制层面、核心是路由选择处理机
分组转发部分:硬件、数据层面、核心是处理芯片和交换结构
控制路径: 处理目的地址是本路由器的高层协议报文,特别是各种路由协议报
文。虽然控制路径不是路由器的关键路径,但是它负责完成路由信息的交互,从
而保证了数据路径上的报文沿着最优的路径转发
数据路径: 处理目的地址不是本路由器而需要转发的报文,因此数据路径是整个
路由器的关键路路径,它直接影响路由器的整体性能
后面还有很详细的讲解,参看CSDN博文
这里只讲算法,不讲实现,实现看原文
前言
数字签名、信息加密 是前后端开发都经常需要使用到的技术,应用场景包括了用户登入、交易、信息通讯、oauth 等等,不同的应用场景也会需要使用到不同的签名加密算法,或者需要搭配不一样的 签名加密算法 来达到业务目标。这里简单的给大家介绍几种常见的签名加密算法和一些典型场景下的应用。
正文
1. 数字签名
数字签名,简单来说就是通过提供 可鉴别 的 数字信息 验证 自身身份 的一种方式。一套 数字签名 通常定义两种 互补 的运算,一个用于 签名,另一个用于 验证。分别由 发送者 持有能够 代表自己身份 的 私钥 (私钥不可泄露),由 接受者 持有与私钥对应的 公钥 ,能够在 接受 到来自发送者信息时用于 验证 其身份。
**注意:**图中 加密过程 有别于 公钥加密,更多 介绍戳这里。签名 最根本的用途是要能够唯一 证明发送方的身份,防止 中间人攻击、CSRF 跨域身份伪造。基于这一点在诸如 设备认证、用户认证、第三方认证 等认证体系中都会使用到 签名算法 (彼此的实现方式可能会有差异)。
2. 加密和解密
2.1. 加密
数据加密 的基本过程,就是对原来为 明文 的文件或数据按 某种算法 进行处理,使其成为 不可读 的一段代码,通常称为 “密文”。通过这样的途径,来达到 保护数据 不被 非法人窃取、阅读的目的。
2.2. 解密
加密 的 逆过程 为 解密,即将该 编码信息 转化为其 原来数据 的过程。
3. 对称加密和非对称加密
加密算法分 对称加密 和 非对称加密,其中对称加密算法的加密与解密 密钥相同,非对称加密算法的加密密钥与解密 密钥不同,此外,还有一类 不需要密钥 的 散列算法。
常见的 对称加密 算法主要有 DES、3DES、AES 等,常见的 非对称算法 主要有 RSA、DSA 等,散列算法 主要有 SHA-1、MD5 等。
3.1. 对称加密
对称加密算法 是应用较早的加密算法,又称为 共享密钥加密算法。在 对称加密算法 中,使用的密钥只有一个,发送 和 接收 双方都使用这个密钥对数据进行 加密 和 解密。这就要求加密和解密方事先都必须知道加密的密钥。
数据加密过程:在对称加密算法中,数据发送方 将 明文 (原始数据) 和 加密密钥 一起经过特殊 加密处理,生成复杂的 加密密文 进行发送。
数据解密过程:数据接收方 收到密文后,若想读取原数据,则需要使用 加密使用的密钥 及相同算法的 逆算法 对加密的密文进行解密,才能使其恢复成 可读明文。
3.2. 非对称加密
非对称加密算法,又称为 公开密钥加密算法。它需要两个密钥,一个称为 公开密钥 (public key),即 公钥,另一个称为 私有密钥 (private key),即 私钥。
因为 加密 和 解密 使用的是两个不同的密钥,所以这种算法称为 非对称加密算法。
如果使用 公钥 对数据 进行加密,只有用对应的 私钥 才能 进行解密。
如果使用 私钥 对数据 进行加密,只有用对应的 公钥 才能 进行解密。
例子:甲方生成 一对密钥 并将其中的一把作为 公钥 向其它人公开,得到该公钥的 乙方 使用该密钥对机密信息 进行加密 后再发送给甲方,甲方再使用自己保存的另一把 专用密钥 (私钥),对 加密 后的信息 进行解密。
4. 常见的签名加密算法
4.1. MD5算法
MD5 用的是 哈希函数,它的典型应用是对一段信息产生 信息摘要,以 防止被篡改。严格来说,MD5 不是一种 加密算法 而是 摘要算法。无论是多长的输入,MD5 都会输出长度为 128bits 的一个串 (通常用 16 进制 表示为 32 个字符)。
4.2. SHA1算法
SHA1 是和 MD5 一样流行的 消息摘要算法,然而 SHA1 比 MD5 的 安全性更强。对于长度小于 2 ^ 64 位的消息,SHA1 会产生一个 160 位的 消息摘要。基于 MD5、SHA1 的信息摘要特性以及 不可逆 (一般而言),可以被应用在检查 文件完整性 以及 数字签名 等场景。
4.3. HMAC算法
HMAC 是密钥相关的 哈希运算消息认证码(Hash-based Message Authentication Code),HMAC 运算利用 哈希算法 (MD5、SHA1 等),以 一个密钥 和 一个消息 为输入,生成一个 消息摘要 作为 输出。
HMAC 发送方 和 接收方 都有的 key 进行计算,而没有这把 key 的第三方,则是 无法计算 出正确的 散列值的,这样就可以 防止数据被篡改。
测试结论:HMAC 算法实例在 多线程环境 下是 不安全的。但是需要在 多线程访问 时,进行同步的辅助类,使用 ThreadLocal 为 每个线程缓存 一个实例可以避免进行锁操作。
4.4. AES/DES/3DES算法
AES、DES、3DES 都是 对称 的 块加密算法,加解密 的过程是 可逆的。常用的有 AES128、AES192、AES256 (默认安装的 JDK 尚不支持 AES256,需要安装对应的 jce 补丁进行升级 jce1.7,jce1.8)。
4.4.1. DES算法
DES 加密算法是一种 分组密码,以 64 位为 分组对数据 加密,它的 密钥长度 是 56 位,加密解密 用 同一算法。
DES 加密算法是对 密钥 进行保密,而 公开算法,包括加密和解密算法。这样,只有掌握了和发送方 相同密钥 的人才能解读由 DES加密算法加密的密文数据。因此,破译 DES 加密算法实际上就是 搜索密钥的编码。对于 56 位长度的 密钥 来说,如果用 穷举法 来进行搜索的话,其运算次数为 2 ^ 56 次。
4.4.2. 3DES算法
是基于 DES 的 对称算法,对 一块数据 用 三个不同的密钥 进行 三次加密,强度更高。
4.4.3. AES算法
AES 加密算法是密码学中的 高级加密标准,该加密算法采用 对称分组密码体制,密钥长度的最少支持为 128 位、 192 位、256 位,分组长度 128 位,算法应易于各种硬件和软件实现。这种加密算法是美国联邦政府采用的 区块加密标准。
AES 本身就是为了取代 DES 的,AES 具有更好的 安全性、效率 和 灵活性。
4.5. RSA算法
RSA 加密算法是目前最有影响力的 公钥加密算法,并且被普遍认为是目前 最优秀的公钥方案 之一。RSA 是第一个能同时用于 加密 和 数字签名 的算法,它能够 抵抗 到目前为止已知的 所有密码攻击,已被 ISO 推荐为公钥数据加密标准。
RSA 加密算法 基于一个十分简单的数论事实:将两个大 素数 相乘十分容易,但想要对其乘积进行 因式分解 却极其困难,因此可以将 乘积 公开作为 加密密钥。
A:文件传输协议(英文:File Transfer Protocol,缩写:FTP)是用于在网络上进行文件传输的一套标准协议。它属于网络传输协议的应用层。
B:SPX:顺序包交换 (Sequenced Packet Exchange)协议。是IPX协议簇中的第四层的面向连接的协议,相当于TCP/IP协议簇中的TCP协议;
C:Telnet协议是TCP/IP协议族的其中之一,是Internet远程登录服务的标准协议和主要方式,常用于网页服务器的远程控制,可供用户在本地主机运行远程主机上的工作。属于应用层;
D:点对点协议(英语:Point-to-Point Protocol,PPP)工作在数据链路层
E:TCP(Transmission Control Protocol 传输控制协议)是一种面向连接(连接导向)的、可靠的、基于IP的传输层协议,传输层
F:网际网络组管理协议(Internet Group Management Protocol或简写IGMP)是用于管理网际网络协议多播组成员的一种通信协议。网络层
第七层 应用层
协议:DHCP · DNS · FTP · Gopher · HTTP · IMAP4 · IRC · NNTP · XMPP · POP3 · SIP · SMTP · SNMP · SSH · TELNET · RPC · RTCP · RTSP · TLS · SDP · SOAP · GTP · STUN · NTP · 更多
第六层 表示层
不用协议
第五层 会话层
不用协议
第四层 传输层
协议:TCP · UDP · DCCP · SCTP · RTP · RSVP · PPTP · 更多
第三层 网络层 协议:IP (IPv4 · IPv6) · ARP · RARP · ICMP · ICMPv6 · IGMP · RIP · OSPF · BGP · IS-IS · IPsec · 更多
第二层 数据链路
层协议: 802.11 · 802.16 · Wi-Fi · WiMAX · ATM · DTM · 令牌环 · 以太网 · FDDI · 帧中继 · GPRS · EVDO · HSPA · HDLC · PPP · L2TP · ISDN · 更多
第一层 物理层
协议: RS-443 、RS-232C、RS-485 、理-2593
DHCP(Dynamic Host Configuration Protocol,动态主机配置协议)通常被应用在大型的局域网络环境中,主要作用是集中的管理、分配IP地址,使网络环境中的主机动态的获得IP地址、Gateway地址、DNS服务器地址等信息,并能够提升地址的使用率。
RARP(Reverse Address Resolution Protocol) 反向地址转换协议,允许局域网的物理机器从网关服务器的 ARP 表或者缓存上请求其 IP 地址。
IMAP(Internet Mail Access Protocol,Internet邮件访问协议)以前称作交互邮件访问协议(Interactive Mail Access Protocol)。IMAP是斯坦福大学在1986年开发的一种邮件获取协议。它的主要作用是邮件客户端(例如MS Outlook Express)可以通过这种协议从邮件服务器上获取邮件的信息,下载邮件等。
Hub 嗅探
MAC 欺骗
MAC 冲刷
ARP 攻击
DHCP 钓鱼
DNS 劫持
CDN 入侵
路由器弱口令
路由器 CSRF
PPPoE 钓鱼
蜜罐***
WiFi 弱口令
WiFi 伪热点
WiFi 强制断线
WLAN 基站钓鱼
(1). HTTP协议***服务器常用端口号:80/8080/3128/8081/9080
(2). SOCKS***协议服务器常用端口号:1080
(3). FTP(文件传输)协议***服务器常用端口号:21
(4). Telnet(远程登录)协议***服务器常用端口:23
HTTP服务器,默认的端口号为80/tcp(木马Executor开放此端口);
HTTPS(securely transferring web pages)服务器,默认的端口号为443/tcp 443/udp;
Telnet(不安全的文本传送),默认端口号为23/tcp(木马Tiny Telnet Server所开放的端口);
FTP,默认的端口号为21/tcp(木马Doly Trojan、Fore、Invisible FTP、WebEx、WinCrash和Blade
Runner所开放的端口);
TFTP(Trivial File Transfer Protocol ),默认的端口号为69/udp;
SSH(安全登录)、SCP(文件传输)、端口重定向,默认的端口号为22/tcp;
SMTP Simple Mail Transfer Protocol (E-mail),默认的端口号为25/tcp(木马Antigen、Email
Password Sender、Haebu Coceda、Shtrilitz Stealth、WinPC、WinSpy都开放这个端口);
POP3 Post Office Protocol (E-mail) ,默认的端口号为110/tcp;
WebLogic,默认的端口号为7001;
Webshpere应用程序,默认的端口号为9080;
webshpere管理工具,默认的端口号为9090;
JBOSS,默认的端口号为8080;
TOMCAT,默认的端口号为8080;
WIN2003远程登陆,默认的端口号为3389;
Symantec AV/Filter for MSE ,默认端口号为 8081;
Oracle 数据库,默认的端口号为1521;
ORACLE EMCTL,默认的端口号为1158;
Oracle XDB( XML 数据库),默认的端口号为8080;
Oracle XDB FTP服务,默认的端口号为2100;
MS SQL*SERVER数据库server,默认的端口号为1433/tcp 1433/udp;
MS SQL*SERVER数据库monitor,默认的端口号为1434/tcp 1434/udp;
QQ,默认的端口号为1080/udp
发送时延:结点在发送数据时使数据块从结点进入到传输媒体所需的时间,也就是从数据块的第一个比特开始发送算起,到最后一个比特发送完毕所需的时间。发送时延又称为传输时延。发送时延=数据帧长度/发送速率
传播时延:从链路起点到终点传播所需要的时间。传播时延=d/s(其中d为起点和终点距离,s为传播速率)
处理时延:进行转发处理所花费的时间,如首部处理、差错检验等
往返时延:从发送端发送数据开始,到发送端接收到来自接收端的确认,总共经历的时延。
信道复用技术
一、基本的信道复用技术
(1)频分复用技术(FDM):所有的用户在相同的时间占用不同的带宽资 源。(带宽:此处指频率带宽)
(2)时分复用技术(TDM):所有的用户在相同的时间占用不同的频带 宽度。
(1)统计时分复用技术(Statistic TDM):改进时分复用技术,通过一个集中器将数据集中起来通过高速线路发送到一个远地计算机。
二、其他的信道复用技术
(1)波分复用技术(WDM):光的频分复用技术。
(2)码分复用技术(C D M):是一种共享信道的方法。每一个用户在相同的时间使用同样的频率进行通信。因为各个用户使用经过特殊挑选的不同码型,因此互不干扰。
多路复用通常表示在一个信道上传输多路信号或数据流的过程和技术。因为多路复用能够将多个低速信道整合到一个高速信道进行传输,从而有效地利用了高速信道。
多路复用根据使用的技术可以分为时分复用(TDM)、频分复用(FDM)、空分复用(SDM)和码分复用(CDM)。
时分复用的特点是:高速信道根据时间划分成多个时隙供多个低速信道轮流使用,在一个时隙内,只能有一个低速信道占有高速信道的资源。
频分复用的特点是:多路复用器将各个低速信道的信号通过调制分布到高速信道的各个频段,然后进行叠加,形成高速信道上传输的信号,在接收端,分路器一般通过带通滤波器分离各个频段,然后转发给对应的低速信道。在光通信领域,根据光波波长的不同进行多路复用的技术被称为波分复用(WDM)。
空分复用的特点是:使用多天线技术,通过波束成形技术将信号对准特定的发射源或接收站进行接收或发送。通过空分复用,多个发射源或者接受站可以同时使用同一个频率。在实际的通信工程里,空分复用通常和其它复用技术结合使用。
码分复用的特点是:采用扩频通信技术,各个低速信道可以在同一个地方同时使用相同的频率进行通信,不同的低速信道通过采用不同的地址码复用整个频段。
DNS攻击:攻击者攻击了域名解析服务器,修改了其中IP和域名的对应关系,使得用户输入域名时候,会进入到错误的网站上去,攻击者可以截获信息,等等
DOS攻击:DOS攻击是指攻击者发送大量请求使得正常用户的请求无法到达,或者是攻击者在某一个时间发送大量数据给服务器,造成服务器瘫痪两种方式
DDOS攻击:攻击者发送大量请求,使得正常用户的请求无法到达
MAC地址欺骗:使局域网内主机无妨访问局域网,通过修改交换机端口和MAC地址的映射关系
广播域是OSI模型中第二层的概念,所以Hub、中继器、交换机、网桥等第一,第二层设备连接的节点被认为都是在同一个广播域。而路由器这样的第三层交换机才可以划分广播域。
而冲突域是OSI模型中第一层的概念,连接同一冲突域的设备有Hub,中继器或者其他进行简单复制信号的设备。用Hub或者中继器连接的所有节点可以被认为是在同一个冲突域内。而第二层设备(网桥,交换机),和第三层设备(路由器)都可以划分冲突域。
路由器的每个接口是一个广播域。交换机的每个接口是一个冲突域,交换机在未配置策略前是所有接口是一个广播域。集线器的所有接口是一个冲突域。
TCP/IP协议,或称为TCP/IP协议栈,或互联网协议系列。
TCP/IP协议栈(按TCP/IP参考模型划分),TCP/IP分为4层,不同于OSI,他将OSI中的会话层、表示层规划到应用层。
包含了一系列构成互联网基础的网络协议。
公有IP地址(公网IP):
组建一个企业级网络,需要去向“电信运营商ISP”申请一个接入Internet的宽带,
同时ISP还会给我们分配一个或多个IP地址,这些IP地址可以供我们企业内部上
网,这些ISP分配给我们的IP,就是公有IP。
私有IP地址(私网IP):
我们企业或家庭内部组建局域网用的IP,一般都会用私有IP。
公有IP地址的范围:
A类的公有IP:
1.0.0.0~9.255.255.255
11.0.0.0~126.255.255.255
B类的公有IP:
128.0.0.0~172.15.255.255
172.32.0.0~191.255.255.255
C类的公有IP:
192.0.0.0~192.168.255.255
192.169.0.0~223.255.255.255
私有IP地址的范围:
A类私有IP地址:
10.0.0.0~10.255.255.255
B类私有IP地址:
172.16.0.0~172.31.255.255
C类私有IP地址:
192.168.0.0~192.168.255.255
网关:网关又称协议转换器,仅用于两个高层协议不同的网络互连。网关是一个翻译器,对收到的信息要重新打包,以适应目的系统的需求。工作在网络层以上