转载自:https://www.jianshu.com/p/116ebf3034d9css
温习下如下知识点:html
一、TCP
二、TCP的3次握手和4次挥手
三、HTTP 四、HTTPS 五、SPDY 六、HTTP2.0 七、隧道 八、代理 九、InetAddress和InetSocketAddress
首先看下OSI七层协议(网络体系下的关系)java
咱们必须熟记着七层协议,发送时从应用层往下封装,每层都加上各自层的头部信息,而后经过最后一层物理层进行发送,在接收端进行解封装。算法
而后看下七层每层所表明的意义:数据库
链路层:就是设备驱动程序和计算机的网卡,他们一块儿处理与电缆的物理操做细节浏览器
网络层:处理数据在网络中的路由(IPV四、IPV6)。举例IP协议,就是一种不可靠的服务,只保证尽快的将数据从发送端传到接收端,缓存
不提供可靠性保证。安全
传输层:为两台主机上的应用提供端对端的传输。服务器
TCP:提供了安全可靠的端对端传输协议,面向链接,有着超时重传、发送和接收端对端的确认机制,所以在应用层放心cookie
UDP:提供了极简的传输,不面向链接,只保证发出,不确保是否收到,所以可靠性必须在应用层保证
应用层:传输与应用程序逻辑相关的数据
HTTP:无状态链接,
咱们来开始了解TCP,TCP是一个协议(Transfer Control Protocal),咱们须要熟记TCP协议的数据结构:
各自字段的含义:
Source Port和Destination Port:分别占用16位,表示源端口号和目的端口号;用于区别主机中的不一样进程,IP地址用来区分不一样主机的,源端口号和目的端口号配合上IP首部中的源IP地址就能肯定为一个TCP链接 Sequenece Number:用来标识从TCP发送端向TCP接收端的数据字节流,他表示在这个报文中的第一个数据字节流在数据流中的序号;主要用来解决网络乱序的问题。 Acknowledgment Number:32位确认序号包发送确认的一端所指望收到的下一个序号,所以,确认须要应该是上次已成功收到数据字节序号+1,不过只有当标志位中的ACK标志(下面介绍)为1时该确认序列号的字段才有效。主要用来解决不丢包的问题。 Offset:给出首部中32bit字的数目,须要这个值是由于任选字段的长度是可变的。这个字段占4bit(最多能表示15个32bit的字,即4*15=60个字节的首部长度),所以TCP最多有60个字节的首部。然而,没有任选字段,正常的长度是20字节。 TCP Flags:TCP首部中有6个比特,它们总的多个可同时被设置为1,主要是用于操控TCP的状态机,依次为URG,ACK,PSH,RST,SYN,FIN。 Window:窗口大小,也就是有名的滑动窗口,用来进行流量控制;这是一个复杂的问题
针对TCP Flags:在Tcp经过三次握手创建链接后,经过Flags便可标示传输的意义。
位码即tcp标志位,有6种标示:SYN(synchronous创建联机) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急)Sequence number(顺序号码) Acknowledge number(确认号码)
URG:次标志表示TCP包的紧急指针域(后面立刻就要说到)有效,用来保证TCP链接不被中断,并督促中间层设备要尽快处理这些数据。 ACK:此标志表示应答域有效,就是说前面所说的TCP的应答将会包含在TCP数据包中;有两个取值:0和1,为1的时候表示应答域有效,反之为0。 PSH:这个标志位表示Push操做。所谓Push操做就是是在数据包到达接受端之后,当即传送给应用程序,而不是在缓冲区排队。 RST:这个标志位表示链接复位请求。用来复位哪些产生错误的连接,也被用来拒绝错误和非法的数据包。 SYN:表示同步序号,用来创建链接。SYN标志位和ACK标志位搭配使用,当链接请求的时候, SYN=1,ACK=0;链接被响应的时候,SYN=1,ACK=1。这个标志的数据包经常被用来进行端口扫描。扫描者发送一个只有SYN的数据包,若是对方主机响应了一个数据包回来,就代表这台主机存在这个端口,可是因为这种扫描只是进行TCP三次握手的第一次握手,所以这种扫描的成功代表被扫描的机器很不安全,一台安全的主机将会强制要求一个链接严格的进行TCP的三次握手。 FIN:表示发送端已经达到数据末尾,也就是说双方数据传送完成,没有数据能够传送了,发送 FIN标志位的TCP数据包后,链接将断开。这个表示的数据包也常常被用于进行端口扫描。
由于TCP是面向链接的。因此须要创建链接以后才能够进行数据传输
握手说明:第一次,客户端发送SYN报文,置发送序号为X,发送后状态至为SYN_SNET
第二次,服务端接收到SYN报文后,向客户端发送ACK+SYN报文,置ACK序号为x+1,发送序号为Y,发送后状态置为SYN_Received
第三次,客户端接收到服务端的报文后,发送ACK报文,并置ACK序号为Y+1,发送序号为Z
挥手说明:1:客户端请求关闭链接,2:服务端收到后赞成关闭链接,3:服务端请求关闭链接,4:客户端确认服务端想关闭了链接,发送ack,并进入等待状态,服务端收到ack后就关闭本身,而客户端若是接下来再没有收到服务端的请求包,也关闭本身的链接。
由于防止发送端认为的失效的数据包又莫名其妙发送到了接收端。
可是能够接受,当接收端发送ACK表明他知道了发送端再也不发送数据包了,所以他也发送FIN包告诉接收端他也不发送数据包了,所以随着发送端发送一个ACK表明一次TCP
链接正常结束了。
说明:计算机经过网络通讯的协议,是一种基于请求与响应、无状态的、应用层的协议,常基于TCP/IP协议传输数据。
进一步说明:
请求与响应:客户端发送数据,服务端响应数据
无状态的:协议对通信事务处理没有记忆能力,所以链接以后,服务端返回数据以后,双方断开链接,不保存链接状态。
针对无状态的一些解决策略:引入了cookie技术保存信息
HTTP1.1提出了持久链接(HTTP keep-alive)
请求头和响应头中的控制缓存字符
<请求方式> 空格 <url>空格<协议版本>空格,换行 (请求行)
<请求头,键:值>空格,换行
<请求头,键:值>空格,换行
空格,换行
<请求体>
<协议版本> 空格 <url>状态码<状态缘由>空格,换行 (响应行)
<响应头,键:值>空格,换行
<响应头,键:值>空格,换行
空格,换行
<响应体>
端口号:
默认端口为80
状态码:
1xx:指示信息--表示请求已接收,继续处理。
2xx:成功--表示请求已被成功接收、理解、接受。
3xx:重定向--要完成请求必须进行更进一步的操做。
4xx:客户端错误--请求有语法错误或请求没法实现。
5xx:服务器端错误--服务器未能实现合法的请求。
强制缓存:Expries(http1.0使用,http1.1被淘汰,由于返回服务器认为过时的时间戳,可能两端时间戳不一致)、Cache-Control
对比缓存:Last-Modify/If-Modify-Since、ETag/If-none-Matched
在对比缓存生效时,状态码为304,而且报文大小和请求时间大大减小。缘由是,服务端在进行标识比较后,只返回header部分,经过状态码通知客户端使用缓存,再也不须要将报文主体部分返回给客户端。
体如今数据头(请求头或者响应头),cache-control字段控制,值有
public、缓存被公共缓存(客户端和服务器均可缓存)
private、缓存被私有缓存(只能被客户端缓存),
no-cache、不缓存
no-store、不缓存
Only-If-cached、表示只接受被缓存的数据,这样就在网络请求的时候直接返回自己的缓存,若是没有就报504.
max-age=60,60秒以后缓存过时
Transfer-Encoding:chunked,表示响应体或者请求体的长度不固定
Content-Length,表明请求体或者响应体的具体长度,与Transfer-Encoding互斥,即只能存在一个字段
为方便你们理解,咱们认为浏览器存在一个缓存数据库,用于存储缓存信息。
在客户端第一次请求数据时,此时缓存数据库中没有对应的缓存数据,须要请求服务器,服务器返回后,将数据存储至缓存数据库中。
强制缓存:
已存在缓存数据时,仅基于强制缓存,请求数据的流程以下
对比缓存:
已存在缓存数据时,仅基于对比缓存,请求数据的流程以下
Last-Modify/If-Modify-Since,对比缓存策略
第一次请求数据后返回有Last-Modified,服务器告诉浏览器数据最后的修改时间
在其请求时请求报文就能够具有If-Modified-Since字段了,服务器就收到该请求报文,发现有If-Modified-Since字段,则将该字段与请求资源的最后修改时间进行对比,若是比较后发现后来又修改了,则返回响应码200,若是发现没有修改,则返回响应码304,告诉浏览器上次的缓存能够继续使用。
ETag/If-none-Matched(优先级比Last-Modified/If-Modified-Since高)
第一次请求时返回的响应报文中又ETag字段,该字段由服务器按照必定规则生成,惟一标示该资源
第二次请求服务器时,请求报文中就带着In-None-Match字段,与最新资源比较,若是资源后来已经更改过那么就不匹配,返回200,从新返回新的数据;若是没有更改过,就返回304,告诉浏览器,缓存能够用
格式也能够多个拼接,例如
Cache-Control:public, only-if-cached, max-stale=2419200
Http的长链接、短连接其实就是TCP层面上的实现
短连接:(传输数据完了就进行TCP四次挥手)
创建链接->传输数据->断开连接
长链接:(传输数据完了不进行TCP四次挥手)
创建链接->传输数据->保持连接->断开链接
最初在http1.1上,connection:keep-alive。默认也是长链接。
长链接不表明永久链接,会设置超时时间。keep-alive:timeout=20
缓存:get可缓存,post不行
编码类型:get只有一种applicaiton/x-form-urlencoding,post至少有四种,上文有提到
对数据长度限制:因为get方式数据在url上,URL长度最长为2048个字符。post无限制
可见性:因为get方式数据在url上,可见,post不可见
安全性:post较get安全一点,可是若是被抓了包就没办法了,只有https了
当RSA做为加密操做时,公钥做为加密,私钥所谓解密(通常状况)
当RSA做为身份验证时,私钥做为加密,公钥做为解密
主要是依赖于计算离散对数的难度
通讯前两边A、B都约定好两个大整数n、g,其中1<g<n,都公开
1.A随机产生一个大整数a,计算Ka=g^a mod n【a须要保密】
2.B也随机产生一个大整数b,计算Kb = g^b mod n【b须要保密】
3.A把Ka发送給B,B把Kb发送給A
4.因为公式,两边都能获得相同的K,做为秘钥
明文->Hash算法->摘要->私钥加密(明文+摘要)->密文
过程:发送者用发送者的私钥对摘要进行加密而后发送给接收者,接收者收到后只能用发送者公开的公钥才能解密获得摘要1,而后接受者经过对除了摘要之外的其余数据进行Hash算法签名操做的到摘要2,经过摘要1和摘要2的对比,能够确保数据的完整性和安全性
对于接收者,如何肯定它所获得的公钥就是从发送者那里发送的,怎么确保该公钥没有进行过篡改处理。这就须要认证中心肯定数字证书。
数字证书的内容:
秘钥协商算法= 秘钥交换算法 + 身份认证
TLS-RSA:就是服务端将本身的证书传给客户端,客户端将证书进行验证后,客户端将秘钥A经过服务端CA证书上的公钥进行加密成ClientKeyExchange,而后传输给服务端,服务端经过本身的私钥解秘获得A。A就是premaster secret,该值为客户端指定。会话秘钥是经过RandomA+RandomB+Premaster secret三个值再进行一次算法计算获得的。
TLS-DH:只能作到秘钥交换,不能作到身份认证,所以必须和一些能作到身份认证的算法一块儿协同,例如和RSA一块儿,就是DH-RSA,
出现的背景:因为RSA的安全性彻底取决于第三个参数,尽管值很大很难破解,可是为了万无一失,制造出了DH算法。
具体使用:客户端:DHCalMethod(KeyA,共同算法参数(证书上的指数))=公钥a,服务端DHCalMethodDH(keyB,公共算法参数(证书上的指数))=公钥b,而后经过相互换公钥a、b,两边就能够知道彼此的的keyA和keyB了。
TLS-DH-RSA: 使用过程当中,keyA、keyB就是同一个; 公共的算法参数(即证书上的指数)就是permaster secret,会话秘钥就是keyA/keyB,在传输的过程当中,服务端用本身的秘钥对进行穿出的字段进行加密,而后客户端接收到后对服务端证书上的公钥解密,保证安全认证,双向认证的话就是两端都有这样的认证过程。
TLS-DHE: 具有前向安全性,在原有的DH算法的基础上多一个serverkeyexchange的握手
TLS-ECDHE:具有前向安全性,在原有的ECDH算法的基础上多一个serverkeyexchange的握手
DH算法:
针对银行等私密性强的单位,要求私钥存储在自家服务器
CloudFlare提供服务(分公钥私钥一块儿提供,能够不提供私钥(keyless SSL)),把网站放到它们的CDN上,能使用SSL加密连接。
握手为非对称加密,握手后通讯为对称加密
具体:如图
参考:http://blog.csdn.net/misslong/article/details/9698657
注意:
2012年google如一声惊雷提出了SPDY的方案,你们猜开始从正面看待和解决老版本HTTP协议自己的问题,SPDY能够说是综合了HTTPS和HTTP二者有点于一体的传输协议,
主要解决
SPDY构成图:
在HTTP/1.x中,若是客户端想发起多个并行请求必须创建多个TCP链接,这无疑增大了网络开销。
另外HTTP/1.x不会压缩请求和响应头,致使了没必要要的网络流量,HTTP/1.x不支持资源优先级致使底层TCP链接利用率低下。
HTTP2.0能够说是SPDY的升级版(其实也是基于SPDY设计的),可是HTTP2.0跟SPDY仍有不一样的地方,
HTTP2.0把HTTP协议通讯的基本单位缩小为一个一个的帧,这些帧对应着逻辑流中的消息。相应地,不少流能够并行地在同一个TCP链接上交换消息。
在HTTP/1.1中,若是客户端想发送多个平行的请求以及改进性能,必须使用多个TCP链接。
HTTP2.0的二进制分帧层突破了限制;客户端和服务器能够把HTTP消息分解为互不依赖的帧,而后乱序发送,最后再把另外一端把它们从新组合起来
定义
Web tunnel(Web 隧道)是http的另外一种用法,使用Http应用程序访问非Http协议的应用程序。Web隧道容许用户容许用户经过HTTP链接发送非HTTP流量,这样就能够在HTTP上捎带其余协议数据了。使用Web隧道最多见的缘由就是要在HTTP链接中嵌入非HTTP流量。这样这类流量就能够穿过只容许Web流量经过的防火墙了