8.网络协议基本了解

1.网络七层协议

• 应用层:
  1 用户接口,应用程序.
  2 Application典型设备:网关.
  3 典型协议,标准和应用:TELNET,FTP,HTTP

• 表示层:
  1 数据表示,压缩和加密presentation
  2 典型设备:网关
  3 典型协议,标准和应用:ASCLL,PICT,TIFF,JPEG/MPEG
  4 表示层相当于一个东西的表示,表示的一些协议,比如图片,声音和视频MPEG.

• 会话层:
  1 会话的建立和结束
  2 典型设备:网关
  3 典型协议,标准和应用: RPC,SQL,NFS, X WINDOWS,ASP

• 传输层:
  1 主要功能:端到端控制Tansport.
  2 典型设备:网关
  3 典型协议,标注和应用:TCP,UDP,SPX.

• 网络层:
  1 主要功能:路由,寻址NetWork
  2 典型设备:路由器
  3 典型协议,标准和应用:IP,IPX,APPLETALK,ICMP

• 数据链路层:
  1 主要功能:保证无差错的疏忽链路data link
  2 典型设备:交换机,网桥,网卡
  3 典型协议,标准和应用:802.2,802.3ATM,HDLC,FRAME RELAY.

• 物理层:
  1 主要功能:传输比特流Physical.
  2 典型设备:集线器,中继器
  3 典型协议,标准和应用:V.35,EIA/TIA-232

2.HTTP 和HTTPS的区别? HTTPS 为什么更加安全?

• 区别
  1 HTTPS需要想机构申请CA证书,极少免费
  2 HTTP属于明文传输,HTTPS基于SSL进行加密传输
  3 HTTP端口号默认80,HTTPS端口号为443
  4 HTTPS是加密传输,有身份验证环节,更加安全
• 安全
  SSL(安全套接层)TLS(传输层安全)
  以上两者在传输层之上,对网络连接进行加密处理,保障数据的完整性,更加安全

3.HTTPS的连接建立流程

HTTPS为了兼顾安全与效率,同事使用了对称加密和非对称加密.在传输过程中会涉及三个秘钥:

• 服务器端的公钥和私钥,用来进行非对称加密

• 客户端生成的随机秘钥,用来进行对称加密

  
  image
  

  如上图,HTTPS连接过程大致分为八步:

• 1 客户端访问HTTPS连接:
  客户端会把安全协议版本号,客户端支持的加密算法列表,随机数C发送给服务端
• 2服务端发送证书给客户端:
  服务端接受秘钥算法配件后,会和自己支持的加密算法列表进行比对,如果不符合,则断开连接,否则,服务端会在该算法列表中,选择一个对称算法(如AES),一种公钥算法(如具有特定秘钥长度的RSA)和一种MAC算法发送给客户端.服务端有一个秘钥对,及公钥和私钥,是用来进行非对称加密使用的,服务器保存私钥,不能将其泄漏,公钥可以发送给任何人.在发送加密算法的同事还会把数字证书和随机数S发送给客户端
• 3客户端验证server证书:
  会对server公钥进行检查,验证其合法性,如果发现公钥有问题,那么HTTPS传输就无法继续进行.
• 4客户端组装会话密钥:
  如果公钥合格,那么客户端会用服务器公钥生成一个前主秘钥(Pre-Master Secret,PMS),并通过该前主秘钥和随机数C,S来组装会话密钥
• 5客户端讲前主秘钥加密发送给服务端:
  是通过服务端的公钥来对前主秘钥进行非对称加密,发送给服务端
• 6服务端通过私钥解密得到前主秘钥:
  服务端接收加密信息后,用私钥解密得到前主秘钥
• 7服务端组装会话秘钥:
  服务端通过前主秘钥和随机数C,S来组装会话秘钥,至此,服务端和客户端就已经知道了用于此次会话的主秘钥.
• 8数据传输:
  客户端收到服务端发送来的密文,用客户端秘钥对其进行解密,得到服务端发送的数据 ,同理服务端接收到客户端发送的密文,用服务端秘钥对其进行对称解密,得到客户端发送的数据

4.三次握手和四次挥手

• 三次握手: 刚开始的时候客户端和服务端都处于CLOSED状态.主动打开链接的是客户端,被动打开的是服务端.
  1.TCP服务器进程先创建传输控制块TCB，时刻准备接受客户进程的连接请求，此时服务器就进入了LISTEN（监听）状态.
  2.TCP客户进程也是先创建传输控制块TCB，然后向服务器发出连SYN接 同步报文，这是报文首部中的同部位SYN=1，同时选择一个初始序列号 seq=x ，此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态,TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号.
  3.TCP服务器收到SYN 同步报文之后，如果同意连接，会返回给客户端 SYN 同步报文和 ACK 确认报文. 确认报文中应该 ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己初始化一个序列号 seq=y，此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态. 这个报文也不能携带数据，但是同样要消耗一个序号.
  4.TCP客户进程收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态,TCP规定，此时ACK报文段可以携带数据，但是如果不携带数据则不消耗序号.
  5.当服务器收到客户端的ACK报文后也进入ESTABLISHED状态，此时客户端和服务端的连接正式建立。

  
  tcp.png

• 四次挥手:数据传输完毕之后刚开始客户端和服务端都处于ESTABLISHED状态,然后客户端首先关闭连接状态,服务端被动关闭连接状态
  1.客户端进程发出FIN结束报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
  2.服务器收到FIN报文后，发出ACK确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时,由客户端发起的断开连接已经完成,服务端就进入了CLOSE-WAIT（关闭等待）状态.TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
  3.客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
  4.服务器将最后的数据发送完毕后，就向客户端发送FIN报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认.
  5.客户端收到服务器的FIN报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态.
  6.服务器只要收到了客户端发出的确认，立即进入CLOSED状态.同样，撤销TCB后，就结束了这次的TCP连接.可以看到，服务器结束TCP连接的时间要比客户端早一些.

  
  close.png

5.TCP 和 UDP的区别

• TCP：面向连接、传输可靠(保证数据正确性,保证数据顺序)、用于传输大量数据(流模式)、速度慢，建立连接需要开销较多(时间，系统资源)。

• UDP：面向非连接、传输不可靠、用于传输少量数据(数据包模式)、速度快。

6.Cookie和Session

cookie

• 1.用户与服务器的交互

  cookie主要是用来记录用户状态，区分用户，状态保存在客户端。cookie功能需要浏览器的支持。如果浏览器不支持cookie（如大部分手机中的浏览器）或者把cookie禁用了，cookie功能就会失效。

  a).首次访问amazon时，客户端发送一个HTTP请求到服务器端 。服务器端发送一个HTTP响应到客户端，其中包含Set-Cookie头部

  b).客户端发送一个HTTP请求到服务器端，其中包含Cookie头部。服务器端发送一个HTTP响应到客户端

  c).隔段时间再去访问时，客户端会直接发包含Cookie头部的HTTP请求。服务器端发送一个HTTP响应到客户端

• 2.cookie的修改和删除

  在修改cookie的时候，只需要新cookie覆盖旧cookie即可，在覆盖的时候，由于Cookie具有不可跨域名性，注意name、path、domain需与原cookie一致

  删除cookie也一样，设置cookie的过期时间expires为过去的一个时间点，或者maxAge = 0(Cookie的有效期,单位为秒)即可

• 3.cookie的安全

  事实上，cookie的使用存在争议，因为它被认为是对用户隐私的一种侵害，而且cookie并不安全

  HTTP协议不仅是无状态的，而且是不安全的。使用HTTP协议的数据不经过任何加密就直接在网络上传播，有被截获的可能。使用HTTP协议传输很机密的内容是一种隐患。

  a).如果不希望Cookie在HTTP等非安全协议中传输，可以设置Cookie的secure属性为true。浏览器只会在HTTPS和SSL等安全协议中传输此类Cookie。

  b).此外，secure属性并不能对Cookie内容加密，因而不能保证绝对的安全性。如果需要高安全性，需要在程序中对Cookie内容加密、解密，以防泄密。

  c).也可以设置cookie为HttpOnly，如果在cookie中设置了HttpOnly属性，那么通过js脚本将无法读取到cookie信息，这样能有效的防止XSS（跨站脚本攻击）攻击

Session

• Session是服务器端使用的一种记录客户端状态的机制，使用上比Cookie简单一些，相应的也增加了服务器的存储压力。

• Session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。 客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。

  当程序需要为某个客户端的请求创建一个session时，服务器首先检查这个客户端的请求里是否已包含了一个session标识（称为SessionId）

  如果已包含则说明以前已经为此客户端创建过session，服务器就按照SessionId把这个session检索出来，使用（检索不到，会新建一个）

  如果客户端请求不包含SessionId，则为此客户端创建一个session并且生成一个与此session相关联的SessionId，SessionId的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个SessionId将被在本次响应中返回给客户端保存。

  保存这个SessionId的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给服务器。但cookie可以被人为的禁止，则必须有其他机制以便在cookie被禁止时仍然能够把SessionId传递回服务器。

Cookie 和Session 的区别：

• 1.cookie数据存放在客户的浏览器上，session数据放在服务器上。

• 2.cookie相比session不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗,考虑到安全应当使用session。

• 3.session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能,考虑到减轻服务器性能方面，应当使用cookie。

• 4.单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。而session存储在服务端，可以无限量存储

• 5.所以：将登录信息等重要信息存放为session;其他信息如果需要保留，可以放在cookie中