计网复习

计算机网络基础复习

OSI七层模型

Tcp三次握手四次挥手

• 为什么需要三次握手呢？为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

• 比如：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段，但是server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求，于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了，由于client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据，但server却以为新的运输连接已经建立，并一直等待client发来数据。所以没有采用“三次握手”，这种情况下server的很多资源就白白浪费掉了。

• 为什么需要四次挥手呢？TCP是全双工模式，当client发出FIN报文段时，只是表示client已经没有数据要发送了，client告诉server，它的数据已经全部发送完毕了；但是，这个时候client还是可以接受来server的数据；当server返回ACK报文段时，表示它已经知道client没有数据发送了，但是server还是可以发送数据到client的；当server也发送了FIN报文段时，这个时候就表示server也没有数据要发送了，就会告诉client，我也没有数据要发送了，如果收到client确认报文段，之后彼此就会愉快的中断这次TCP连接。

Http

简介

• 超文本传输协议
• 基于请求与响应，无状态的
• 应用层的协议
• 基于TCP/IP传输数据

  http/1

• 持久连接(长连接)
• 节约带宽
• HOST域
• 管道机制
• 分块传输编码

http/2

• 多路复用
• 服务器推送
• 头信息压缩
• 二进制协议

http/1与http/2对比

• http/2性能更优
• http/2支持多路复用：通过单一的http/2连接请求发起多重的请求-响应消息，多个stream共享一个tcp连接，从而实现多流并行
• http报文格式
  • 请求报文包含请求行与首部行
    • 请求行：
      • 包含：请求方法、请求路径、版本
    • 首部行：
      • 包含首部数据，key-value形式
  • 响应报文包含状态行与首部行
    • 状态行：
      • 包含：版本、状态码、短语
    • 首部行：
      • 包含：首部数据，key-value形式

https

• https是一种通过计算机网络进行安全通信的传输协议，经由http协议进行通信，利用SSL/TLS建立全信道，加密数据包
• SSL/TLS是传输层的加密协议
• https主要用于提供对网站服务器的身份认证，同时保护交换数据的隐私与完整性

Http VS Https

http特性

• 无状态：协议对客户端没有状态存储，对事物处理没有“记忆”能力，比如访问一个网站需要反复进行登录操作
• 无连接：HTTP/1.1之前，由于无状态特点，每次请求需要通过TCP三次握手四次挥手，和服务器重新建立连接。比如某个客户机在短时间多次请求同一个资源，服务器并不能区别是否已经响应过用户的请求，所以每次需要重新响应请求，需要耗费不必要的时间和流量。
• 基于请求和响应：基本的特性，由客户端发起请求，服务端响应
• 简单快速、灵活
• 通信使用明文、请求和响应不会对通信方进行确认、无法保护数据的完整性

https特性

• 基于http协议

• 通过SSL或TLS提供加密处理数据、验证对方身份、数据完整性保护

• 内容加密：采用混合加密技术，中间者无法直接查看明文内容

  • 混合加密：结合非对称加密和对称加密技术。客户端使用对称加密生成密钥对传输数据进行加密，然后使用非对称加密的公钥再对秘钥进行加密，所以网络上传输的数据是被秘钥加密的密文和用公钥加密后的秘密秘钥，因此即使被黑客截取，由于没有私钥，无法获取到加密明文的秘钥，便无法获取到明文数据。
  • 数字摘要：通过单向hash函数对原文进行哈希，将需加密的明文“摘要”成一串固定长度(如128bit)的密文，不同的明文摘要成的密文其结果总是不相同，同样的明文其摘要必定一致，并且即使知道了摘要也不能反推出明文
  • 数字签名：数字签名建立在公钥加密体制基础上，是公钥加密技术的另一类应用。它把公钥加密技术和数字摘要结合起来，形成了实用的数字签名技术

• 验证身份：通过证书认证客户端访问的是自己的服务器

• 保护数据完整性：防止传输的内容被中间人冒充或篡改

• SSL建立连接过程
  

①客户端的浏览器向服务器发送请求，并传送客户端SSL 协议的版本号，加密算法的种类，产生的随机数，以及其他服务器和客户端之间通讯所需要的各种信息。

②服务器向客户端传送SSL 协议的版本号，加密算法的种类，随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书。

③客户端利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开；如果合法性验证通过，将继续进行第四步。

④用户端随机产生一个用于通讯的“对称密码”，然后用服务器的公钥（服务器的公钥从步骤②中的服务器的证书中获得）对其加密，然后将加密后的“预主密码”传给服务器。

⑤如果服务器要求客户的身份认证（在握手过程中为可选），用户可以建立一个随机数然后对其进行数据签名，将这个含有签名的随机数和客户自己的证书以及加密过的“预主密码”一起传给服务器。

⑥如果服务器要求客户的身份认证，服务器必须检验客户证书和签名随机数的合法性，具体的合法性验证过程包括：客户的证书使用日期是否有效，为客户提供证书的CA 是否可靠，发行CA 的公钥能否正确解开客户证书的发行CA 的数字签名，检查客户的证书是否在证书废止列表（CRL）中。检验如果没有通过，通讯立刻中断；如果验证通过，服务器将用自己的私钥解开加密的“预主密码”，然后执行一系列步骤来产生主通讯密码（客户端也将通过同样的方法产生相同的主通讯密码）。

⑦服务器和客户端用相同的主密码即“通话密码”，一个对称密钥用于SSL 协议的安全数据通讯的加解密通讯。同时在SSL 通讯过程中还要完成数据通讯的完整性，防止数据通讯中的任何变化。

⑧客户端向服务器端发出信息，指明后面的数据通讯将使用的步骤⑦中的主密码为对称密钥，同时通知服务器客户端的握手过程结束。

⑨服务器向客户端发出信息，指明后面的数据通讯将使用的步骤⑦中的主密码为对称密钥，同时通知客户端服务器端的握手过程结束。

⑩SSL 的握手部分结束，SSL 安全通道的数据通讯开始，客户和服务器开始使用相同的对称密钥进行数据通讯，同时进行通讯完整性的检验。

Https优点

• 使用Https协议可以认证用户和服务器，确保数据发送到正确的客户机和服务器
• https协议是由SSL+http协议构建的可进行加密传输，身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取，修改，确保数据的完整性
• https是现行网络架构下最完全的解决方案，虽然不是绝对安全，但是大幅增加了中间人攻击的成本

Https缺点

• https协议握手阶段比较费时，加长了页面的加载时间
• https连接缓存不如http高效，会增加数据开销，甚至会影响已有的安全措施
• https的安全不是绝对的，在面对黑客攻击，拒绝服务攻击和服务器劫持时起不到作用
• SSL证书通常需要绑定ip，不能在同一个ip上绑定多个域名，IPv4资源无法支撑这种消耗
• 增加成本，SSL协议的加密算法和SSL的交互次数将占用一定的计算资源和服务器成本
• https协议的加密范围有限，SSL证书的信用链体系并不安全，特别是某些国家可以控制CA根证书的情况下，中间人攻击一样可行