【计算机网络】HTTP和HTTPS区别

一、HTTP报文格式

（一）HTTP请求报文

  HTTP请求报文由请求行（request line），请求头部（header）和请求数据3个部分组成。

1、请求行

   请求行有请求方法字段、URL字段和HTTP协议版本字段3个字段组成，他们用空格分隔。例如GET /index.html HTTP/1.1。常见的请求方法有GET、POST等。

2、请求头部

   请求头部为请求报文添加了一些附加信息，请求头部有关键字，由“名/值”对组成，每行一对，关键字和值用英文冒号“：”分隔，请求头部通知服务器有关于客户端请求的信息，典型的请求头有：

• User-Ageht:产生请求的浏览器类型
• Accept：客户端可识别的内容类型列表
• Host：请求的主机名，允许多个域名同处一个IP地址，即虚拟主机。
  

3、空行

  最后一个请求头之后是一个空行，发送回车符合换行符，通知服务器以下不再有请求头，请求头部结束，接下来为请求正文，这一行非常重要，必不可少。

4、请求数据（可选部分）

   请求数据不再GET方法中使用，而是在POST方法中使用，POST方法适用于需要客户填写表单的场合，与请求数据相关的最常使用的请求头是Content-Type和Content-Length。

（二）HTTP响应报文

  HTTP响应报文也由三个部分组成，分别是：状态行、响应头部、响应正文。

1、状态行

   由3部分组成，分别为：协议版本，状态码，状态码描述，之间由空格分隔。

HTTP中常见的状态码：

• 1xx：信息性状态码，表示服务器已接收了客户端请求，客户端可继续发送请求。

    100 Continue
  
    101 Switching Protocols
  1
  2
  3

• 2xx：成功状态码，表示服务器已成功接收到请求并进行处理。

   200 OK 表示客户端请求成功
  
   204 No Content 成功，但不返回任何实体的主体部分
  
   206 Partial Content 成功执行了一个范围（Range）请求
  1
  2
  3
  4
  5

• 3xx：重定向状态码，表示服务器要求客户端重定向，重定向到其他资源位置。

    301 Moved Permanently 永久性重定向，响应报文的Location首部应该有该资源的新URL
  
    302 Found 临时性重定向，响应报文的Location首部给出的URL用来临时定位资源
  
    303 See Other 请求的资源存在着另一个URI，客户端应使用GET方法定向获取请求的资源
  
    304 Not Modified 服务器内容没有更新，可以直接读取浏览器缓存
  
    307 Temporary Redirect 临时重定向。与302 Found含义一样。302禁止POST变换为GET，但实际使用时并不一定，307则更多浏览器可能会遵循这一标准，但也依赖于浏览器具体实现
  1
  2
  3
  4
  5
  6
  7
  8
  9

• 4xx：客户端错误状态码，表示客户端的请求报文有误，服务器无法处理。

  400 Bad Request 表示客户端请求有语法错误，不能被服务器所理解
  
  401 Unauthonzed 表示请求未经授权，该状态代码必须与 WWW-Authenticate 报头域一起使用
  
  403 Forbidden 表示服务器收到请求，但是拒绝提供服务，通常会在响应正文中给出不提供服务的原因
  
  404 Not Found 请求的资源不存在，例如，输入了错误的URL
  1
  2
  3
  4
  5
  6
  7

• 5xx：服务器错误状态码，表示服务器未能正常处理客户端的请求而出现内部错误。

    500 Internel Server Error 表示服务器发生不可预期的错误，导致无法完成客户端的请求
  
    503 Service Unavailable 表示服务器当前不能够处理客户端的请求，在一段时间之后，服务器可能会恢复正常
  1
  2
  3

2、响应头部

   与请求头部类似，为响应报文添加了一些附加信息。

HTTP中常见的响应头：

（三）常见的首部字段

1、通用首部字段：

HTTP请求报文和响应报文都包含的字段

• Date：创建报文的时间
• Connection：连接的管理
• Cache-Control：缓存的控制
• Transfer-Encoding：传输编码控制

2、请求首部字段：

HTTP请求报文的常用首部字段

• HOST：请求资源所在的服务器
• Accept：可处理的媒体类型
• Accept-Charset：可接收的字符集
• Accept-Encoding：可接收的内容编码
• Accept-Language：可接收的自然语言

3、响应首部字段：

HTTP响应报文的常用首部字段

• Accept-Range：可接收的字节范围
• Location：令客户端重定向的URI
• Server：HTTP服务器的安装信息

4、实体首部字段：

请求报文和响应报文的实体部分的常用首部字段

• Allow：资源可支持的HTTP方法
• Content-Type：实体类型（例文本、图像、视频……）
• Content-Encoding：实体适用的编码方式
• Content-Language：实体的自然语言
• Content-Length：实体主体的字节数
• Content-Range：实体主体的范围

二、HTTP和HTTPS

HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全，为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而诞生了HTTPS。

1、区别

  （1）证书申请方式不同：HTTP协议可以免费申请，而HTTPS协议需要到CA （Certificate Authority，证书颁发机构）申请证书，一般免费证书较少，需要一定费用。
  （2）传输信息安全性不同：HTTP是超文本传输协议，信息是明文传输，如果攻击者截取了Web浏览器和网站服务器之间的传输接文，就可以直接读懂其中的信息。HTTPS则是具有安全性的SSL加密传输协议，为浏览器和服务器之间的通信加密，确保数据传输的安全。

   （3）端口不同：HTTP协议使用的是80端口，HTTPS协议使用的是443端口。
  （4）连接方式不同：HTTP的连接很简单，是无状态的，HTTPS协议是由SSL+HTTP协议构建的可进行假面传输、身份认证的网络协议，比HTTP协议安全。（无状态的意思是其数据包的发送、传输和接受都是独立的，无连接的意思是指通信双方都不长久的维持对方的任何信息）。

2、HTTPS的工作原理

（1）cilent_hello

客户端发起请求，以明文传输请求信息，包含版本信息、加密套件候选列表、压缩算法候选列表、随机数、扩展字段等信息。

• 支持的最高TSL协议版本verision。
• 客户端支持的加密套件列表，每个加密套件对应TLS原理中的四个功能的组合：认证算法、密钥交换算法（密钥协商）、对称加密算法（信息加密）、信息摘要（完成行校验）。
• 支持的压缩算法列表，用户后续的信息压缩传输。
• 随机数random_C，用于后续的密钥的生成。
• 扩展字段，支持协议与算法的相关参数以及其他辅助信息。

（2）server_hello+server_certificate+sever_hello_done

• server_hello：服务端返回协商的信息结果，包括选择使用的协议版本version、选择的加密套件、选择的压缩算法、随机数random_S等，其中随机数用于后续的密钥协商；
• server_certificates：服务端配置对应的证书链，用于身份验证与密钥交换；
• server_hello_done：通知客户端server_hello信息发送结束；

证书制作过程：
对于CA机构来说，其也有两个密钥，我们暂且称之为CA私钥和CA公钥，CA机构先将服务端的公钥用数字摘要算法生成摘要。然后使用CA私钥将这个摘要进行加密处理，生成数字签名。服务端将数字签名和公钥绑定在一起形成数字证书，发送给客户端。

（4）客户端验证数字证书的合法性（验证是公钥是不是相应的服务端发送过来的，防止中途被篡改）

浏览器用内置的CA公钥对数字证书的数字签名进行解密，并用数字摘要算法对数字证书中的公钥进行处理生成本地的数字签名，然后与CA解密后的数字签名进行匹配，确认数字证书的有效性。如有问题，则提示风险。

（5）客户端生成随机数Pre-master，并用公钥加密发送给服务端。

此时客户端已经获取全部的计算协商密钥需要的信息：两个明文随机数random_C和random_S与计算产生的Pre_mastrer，计算得到协商密钥。

  enc_key=Fuc(random_C, random_S, Pre-Master)
1

客户端通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信。
encrypted_handshake_message，结合之前所有通信参数的 hash 值与其它相关信息生成一段数据，采用协商密钥 session secret 与算法进行加密，然后发送给服务器用于数据与握手验证;

（6）服务端用自己的私钥进行解密得到随机数，生成通信密钥。

服务器用私钥解密后得到Pre-master 数据，基于之前交换的两个明文随机数random_C和random_S，计算得到通信密钥

enc_key=Fuc(random_C, random_S, Pre-Master);
1

change_cipher_spec, 验证通过之后，服务器同样发送 change_cipher_spec 以告知客户端后续的通信都采用协商的密钥与算法进行加密通信;

（7）双方enc_key密钥进行通信。

个人认为：HTTPS通信的核心就是浏览器用非对称加密算法对密钥进行加密，服务端解密获得密钥后用该密钥进行传输。就是非对称加密算法+对称加密算法。而CA证书只有一个作用，因为非对称加密需要传送公钥，CA就是确保这个公钥中途没有被修改，是相应的服务端发过来的。

三、对称加密和非对称加密以及CA？

1、对称加密

对称加密（也叫私钥加密）指加密和解密使用相同秘钥的加密算法。优势又叫传统密码算法，就是加密密钥能够从解密密钥中推算出来，同时解密密钥也可以从加密密钥中推算出来。而在大多数的对称算法中，加密密钥和解密密钥是相同的，它要求接受方法和发送方在安全通信之前，商定一个密钥。对称加密算法的安全性依赖于密钥，泄露密钥就意味着任何人都可以对他们发送或接受的消息解密，所以密钥的保密性对通信至关重要。

特点：
算法公开，计算量小，加密速度快，加密效率高。不足之处是：交易双方都使用同样钥匙，安全性得不到保证。此外，每对用户每次使用对称加密算法时，都需要使用其他人不知道的唯一钥匙，这会使发收信双方所拥有的的钥匙数量呈几何级数增长，密钥管理称为用户的负担。对称加密算法在分布式网络系统上使用较为困难，主要是因为密钥管理困难，使用成本较高。

常见的对称加密算法有DES、3DES、Blowfish、IDEA、RC4、RC5、RC6、和AES。

2、非对称加密

与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥和私有密钥。

公开密钥和私有密钥是一对，**如果公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，**所以这种算法叫作非对称加密算法。

非对称加密算法实现信息交换的基本过程是：

甲方生成一对密钥并将其中的一把作为公钥向其他方公开；得到该公用密钥的乙方使用该密钥对机密信息进行加密后再发送给甲方；甲方再用自己保存的另一把专用密钥对加密后的信息进行解密。甲方只能用其专用密钥解密由其功用密钥加密后的任何信息。

常见的非对称加密算法有：RSA、ECC、Diffie-Hellman、El Gamal、DSA（数字签名用）。

3、CA证书

如果你自己通过RSA算法生成了一个私钥和公钥，在公钥发送给客户端的过程中有可能被篡改其他的公钥，而客户在没有其他措施的保护下是不知道该公钥是否就是服务器那边的私钥对应的公钥的。公钥有可能才分发的过程中被篡改。因此就需要一个第三方机构来证明客户端收到的公钥是没有被篡改的。这个中间认证机构，就是数字证书认证机构，其颁发的证书也就是我们常说的CA证书。

证书签名、证书分发以及证书验证的过程：

• 1、服务端在分发公钥之前需要向CA机构申请将给要分发的公钥进行数字签名。
• 2、对于CA机构来说，其也有两个密钥，我们暂且称之为CA私钥和CA公钥，CA机构先将服务端的公钥用数字摘要算法生成摘要。然后使用CA私钥将这个摘要进行加密处理，生成数字签名。服务端将数字签名和公钥绑定在一起形成数字证书，发送给客户端。
• 3、当客户端收到数字证书之后，会验证其有效性，大部分客户端都会预装CA机构的公钥，也就是CA公钥。客户端使用CA公钥对数字证书上的签名 进行验证，就是使用CA公钥对CA私钥加密的内容进行解密，将解密后的内容与服务端的公钥经过数字摘要算法生成的摘要进行匹配，如果匹配成功，则说明该证书合法，就是相应的服务端发过来的，否则就是非法证书。
• 4、验证完服务端公钥的合法性后，就可以使用该公钥进行加密通信了。

四、HTTP长连接、短连接

在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。

而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：

Connection:keep-alive
1

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

TCP短连接
模拟一下TCP短连接的情况：client向server发起连接请求，server接到请求，然后双方建立连接。client向server发送消息，server回应client，然后一次请求就完成了。这时候双方任意都可以发起close操作，不过一般都是client先发起close操作。上述可知，短连接一般只会在 client/server间传递一次请求操作。

短连接的优点是：管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段。

TCP长连接

我们再模拟一下长连接的情况：client向server发起连接，server接受client连接，双方建立连接，client与server完成一次请求后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。

TCP的保活功能主要为服务器应用提供。如果客户端已经消失而连接未断开，则会使得服务器上保留一个半开放的连接，而服务器又在等待来自客户端的数据，此时服务器将永远等待客户端的数据。保活功能就是试图在服务端器端检测到这种半开放的连接。

如果一个给定的连接在两小时内没有任何动作，服务器就向客户发送一个探测报文段，根据客户端主机响应探测4个客户端状态：

• 客户主机依然正常运行，且服务器可达。此时客户的TCP响应正常，服务器将保活定时器复位。
• 客户主机已经崩溃，并且关闭或者正在重新启动。上述情况下客户端都不能响应TCP。服务端将无法收到客户端对探测的响应。服务器总共发送10个这样的探测，每个间隔75秒。若服务器没有收到任何一个响应，它就认为客户端已经关闭并终止连接。
• 客户端崩溃并已经重新启动。服务器将收到一个对其保活探测的响应，这个响应是一个复位，使得服务器终止这个连接。
• 客户机正常运行，但是服务器不可达。这种情况与第二种状态类似。

长连接的优点是：长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。对于频繁请求资源的客户端适合使用长连接。

五、路由器和交换机的区别

这两个的主要工作都是转发数据，但是是不同的。

• 路由器是工作在网络层中的，交换机工作在链路层。
• 路由器：寻址，转发（依靠IP地址）；交换机：过滤，转发（依靠MAC地址）。
• 路由器内有一份路由表，里面有她的寻址信息，它收到网络层的数据报后，会根据路由表和选路算法将数据报转发到下一站（路由器、交换机、目的主机）。
• 交换机内部有一张MAC表，里面存放着和它相连的所有设备的MAC地址，它会根据收到的数据帧的首部信息内的目的MAC地址在自己的表中查找，如果有就转发，如果没有就放弃。

每个路由器与其之下连接的设备，其实构成一个局域网，交换机工作在路由器之下，也就是交换机工作在局域网内，交换机用户局域网内网的数据转发，路由器用于连接局域网和外网。

举个例子：我们每个人相当于主机，路由器相当于快递员，宿管大爷相当于交换机，学校是一个局域网。
快递员根据学校地址（IP）把包裹送到学校，再根据公寓号（子网IP）把快递交给这个公寓的宿管大爷，宿管大爷根据你的名字（MAC）交给你。