TCP/IP协议簇

HTTP, FTP, DNS, TCP, UDP, IP, SNMP等等都属于TCP/IP协议簇

TCP/IP协议的分层

TCP/IP协议族是分层管理

OSI协议：应用层、表示层、会话层、传输层、网络层、数据链路层、物理层（可记为：应表会传网数物）

TCP/IP协议：应用层、传输层、网络层、链路层

• 应用层：面向用户的一层（用户可以直接操作该层），该层决定了向用户提供应用服务时的通信活动
  • 又将该层分为：应用层、表示层和会话层
  • HTTP 超文本传输协议
  • FTP 文件传输协议
  • DNS 域名系统 —— 负责域名解析（将域名与IP地址进行相互的转换）
• 传输层：将数据交付给传输层进行传输。
  • TCP 传输控制协议 —— 提供面向连接的，可靠的数据传输服务
  • UDP 用户数据协议 —— 提供无连接的，尽力交付（不保证数据传输的可靠性)

• 网络层：用来处理在网络上流动的数据包，负责在众多网络线路中选择一条传输线路，需要IP地址和MAC地址的支持
  • IP 网际协议
• 链路层：用来处理网络的硬件部分，控制操作系统、硬件设备驱动、NIC
  • 分为数据链路层和物理层
  • NIC（Net Work Card），也就是网卡就位于这一部分，当然光纤也是链路层的一部分

四层协议在数据传输过程中的工作方式

在发送端是应用层 --> 链路层这个方向的封包过程，每经过一层都会增加该层的头部。

而接收端则是从链路层 --> 应用层解包的过程，每经过一层则会去掉相应的首部。

一次完整的 HTTP 请求——协议篇

大致流程

• 根据域名和 DNS 解析到服务器的IP地址 (DNS + CDN)
• 通过ARP协议获得IP地址对应的物理机器的MAC地址
• 浏览器对服务器发起 TCP 三次握手
• 建立 TCP 连接后发起 HTTP 请求报文
• 服务器响应 HTTP 请求，将响应报文返回给浏览器
• 短连接情况下，请求结束则通过 TCP 四次挥手关闭连接，长连接在没有访问服务器的若干时间后，进行连接的关闭
• 浏览器得到响应信息中的 HTML 代码， 并请求 HTML 代码中的资源（如js、css、图片等）
• 浏览器对页面进行渲染并呈现给用户

域名+DNS解析 --> IP地址 --> ARP -->MAC --> TCP三次握手 --> HTTP请求响应报文 --> TCP四次挥手关闭连接 --> 渲染显示页面

DNS解析过程

UDP通信

负责域名解析，浏览器根据访问的域名找到其IP地址

三次握手

TCP 为什么需要3次握手？

原因：TCP协议是双全工，需要两两确认保证通信可靠性，防止已失效的连接请求传送到服务器，产生错误

TCP协议位于传输层，为了确保传输的可靠性，TCP协议在建立连接时需要三次握手

SYN(Synchronize同步)、ACK(Acknowledgement确认号)

第一次握手

• 发送端发送一个带SYN(Synchronize)标志的数据包给接收端，用于询问接收端是否可以接收。如果可以，就进行第二次握手。

第二次握手

• 接收端回传给发送端一个带有SYN/ACK的数据包，给发送端说，我收到你给我发送的SYN标志了，我再给你传一个ACK标志，你能收到吗？
• 如果发送端收到了SYN/ACK这个数据包，就可以确认接收端收到了之前发送的SYN, 然后进行第三次握手。

第三次握手

• 发送端会给接收端发送一个带有ACK标志的数据包，告诉接收端我可以收到你给我发送的SYN/ACK标志。
• 接收端如果收到了这个来自客户端的ACK标志，就意味着三次握手完成，连接建立，就可以开始传输数据了。

四次挥手

第一次挥手

• TCP客户端发送一个FIN报文，用来关闭客户到服务器的数据传送

第二次挥手

• 服务端收到到该 FIN 报文，于是响应客户端一个 ACK 报文，告诉客户端，请求关闭的报文已经收到，我正在处理。

第三次挥手

• 服务端发送一个 FIN 报文，告诉客户端， 我将要关闭连接了。

第四次挥手

• 客户端返回一个 ACK 响应报文，告诉服务端，我收到你刚才发的报文了，我已经确认，你可以关闭连接了。

HTTPS 安全通信机制的建立

HTTP

超文本传输协议，是以明文的方式传输，端口号80（https端口号443）

HTTP报文结构

HTTP 超文本传输协议，是规范客户端和服务器之间通信的协议。协议就是接口，有着共同的通信协议，便于个个设备之间进行沟通通信

HTTP协议中可以分为请求报文和响应报文。

请求报文(Request Message)结构

一个是请求头（Request Headers）,另一个是请求体（Request Body）

1. 请求行：包含请求方法,URI,HTTP版本协议

2. 请求首部字段

3. 请求内容实体

响应报文(Response Message)结构

响应报文的结构与请求报文的结构类似，也分为报文头和报文体。响应头与响应体中间也是有空行进行分割的。

1. 状态行：包含HTTP版本,状态码,状态码原因短语

2. 响应首部字段

3. 响应内容实体

HTTP的请求方法

基于HTTP/1.1的请求方法有GET、POST、PUT、DELETE、HEAD、OPTIONS、TRACE、CONNECT

GET和POST的底层实现都是基于TCP/IP协议

	GET	POST
数据	请求数据	发送数据到后台
安全性	请求在地址栏可见，安全性低	在地址栏不可见，安全性高
提交数据大小	有限	无限

HTTP响应状态码

响应状态码是用来标志HTTP响应状态的，响应状态由响应状态码和响应原因短语构成

• 200 OK : 表示服务端正确处理了客户端发送过来的请求。
• 204 No Content : 表示服务端正确处理请求，但没有报文实体要返回。
• 206 Partial Content ：表示服务端正确处理了客户端的范围请求，并按照请求范围返回该指定范围内的实体内容。
• 301 Moved Permanently：永久性重定向，若之前的URI保存到了书签，则更新书签中的URI。
• 302 Found：临时重定向，该重定向不会变更书签中的内容。
• 303 See Other：临时重定向，与302功能相同，但是303状态吗明确表示客户端应当采用GET方法获取资源。
• 304 Not Modified: 资源未变更，该状态码与重定向并没有什么关系，当返回该状态码时，告诉客户端请求的资源并没有更新，响应报文体中并不会返回所请求的内容。
• 400 Bad Request：错误请求，表示请求报文中包含语法错误。
• 401 Unauthorized：请求未认证，表示此发送的请求需要客户端进行HTTP认证（稍后会提到）。
• 404 Not Found：找不到相应的资源，表示服务器找不到客户端请求的资源。
• 500 Internal Server Error：服务器内部错误，表示服务器在处理请求时出现了错误，发生了异常。
• 503 Service Unavailable：服务不可用，表示服务器处于停机状态，无法处理客户端发来的请求。

HTTPS简介

HTTP + SSL 是HTTP的安全版，加密传输，为数据传输提供安全支持

SSL是

HTTPS就是在HTTP与TCP层中间添加了一个SSL层。因为HTTPS被HTTP多了这层加密的流程，所以HTTPS的速度要比HTTP慢的多。

SSL提供服务

• 认证用户和服务器，确保数据发送到正确的客户机和服务器

• 加密数据以防止数据中途被窃取；

• 维护数据的完整性，确保数据在传输过程中不被改变。

HTTPS的通信过程

SSL的加密过程是RSA与AES混合进行的

通过RSA加密方式来交换AES加解密的密钥，然后使用AES加密的方式来传输报文

• 有客户端发起的第一次握手，此次握手过程的主要目的是从服务端获取数字签名证书，服务端在发送数字签名证书之前要先确认客户端的SSL版本、加密算法等信息。
• 完成第一次握手后，接着进行第二次握手。第二次握手是在客户端收到证书后发起的，主要目的是将AES加解密使用的Key （Pre-master secret）发送给服务端。当然这个AESKEY是使用第一次握手获取的公钥进行加密的。客户端收到这个使用公钥加密后的AESKEY，使用服务端的私钥进行解密。这样客户端和服务端经过二次握手后都持有了AES加解密的KEY。
• 当Client与Server端都持有AES_KEY后，就可以对HTTP报文进行加解密了。
• 最后就是断开连接了

数字签名

HTTP + SSL (TSL)的结合体

HTTP报文经过SSL层加密后交付给TCP层进行传输。SSL(安全套节层)主要采取的是RSA（非对称加密）与AES（对称加密）结合的加密方式。先通过RSA交互AES的密钥，然后通过AES进行报文加密和解密

RSA与AES简述

RSA 公钥加密算法

非对称加密，其在加密和解密的过程中，需要两个Key，一个公钥（public key）加密，一个是私钥（private key）解密

Client内置了一个公钥，该公钥与Server端的私钥是配对的，所以Client端可以使用这个内置的Public key加密，而服务端就可以使用这个private key进行解密。目前最常用的是服务端单向认证机制

AES 高级加密标准

该加密算法有一个密钥，该密钥可以用来加密，也可以用来解密，所以AES是对称加密算法

Client端与Server端有一个共同的Key, 这个Key是用来加密和解密的。

如果报文在传输的过程中被窃取了，没有这个key, 对加密的内容进行破解是非常困难的，当然窃取者如果有key的话，也是可以轻而易举的解密的。

所以在AES中，key是关键

AES加密策略。比如每次加密的Key都是从一个密码本中动态生成的，而这个密码本服务端和客户端都有同一本，每次传输的是一些参数。这些参数在经过一些算法的映射，从密码本中取出相应的key用来解密。这样一来，就相当于给AES加了一层防盗门，加大了破解的难度。这样做的好处是每次加密的key都是不同的，而且需要密码本以及映射算法的支持。

CA证书

自己通过RAS算法生成了一个私钥和公钥，在公钥发送给客户端的过程中有可能被篡改成其他的公钥，而客户端在没有其他措施的保护下是不知道该公钥是否就是服务器那边的私钥对应的公钥的。这种自己做的RAS的公钥和私钥有可能在公钥分发的过程中被篡改。

下方就是Client从Server端获取公钥时被中间者篡改了，将public换成了自己的伪public key, 同样这个中间者持有这个伪public key所对应的伪private key。如果客户端使用的伪public key进行加密传输的话，那么中间者是可以使用自己的private key进行解密的

在RAS加密中有一个第三方机构来负责证明客户端收到的证书就是你发送的证书，中间没有被篡改。这个中间认证机构，就是数组证书认证机构, 其颁发的证书也就是我们常说的CA证书（CA , Certificate Authority）

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

• 服务端人员使用RSA算法生成两个密钥，一个用来加密的公钥；一个用来解密的公钥，只有服务端持有。服务端在将Public Key进行分发证书之前需要向CA机构申请给将要分发的公钥进行数字签名。
• 生成数字签名公钥证书：对于CA机构来说，其也有两个密钥，我们暂且称之为CA私钥和CA公钥。CA机构将服务端的Public Key作为输入参数将其转换为一个特有的Hash值。然后使用CA私钥将这个Hash值进行加密处理，并与服务端的Public Key绑定在一起，生成数字签名证书。其实数字签名证书的本质就是服务端的公钥+CA私钥加密的Hash值。（CA私钥负责签名，CA公钥负责验证）
• 服务器获取到这个已经含有数字签名并带有公钥的证书，将该证书发送给客户端。当客户端收到该公钥数字证书后，会验证其有效性。大部分客户端都会预装CA机构的公钥，也就是CA公钥。客户端使用CA公钥对数字证书上的签名进行验证，这个验证的过程就是使用CA公钥对CA私钥加密的内容进行解密，将解密后的内容与服务端的Public Key所生成的Hash值进行匹配，如果匹配成功，则说明该证书就是相应的服务端发过来的。否则就是非法证书。
• 验证完服务端公钥的合法性后，就可以使用该公钥进行加密通信

参考：

• Http和Https的区别（面试常考题）
• TCP-IP协议族(三) 数字签名与HTTPS详解
• 一次 HTTP 请求的完整过程——协议篇