常见网络协议汇总（一）
时间：2023-02-02 13:48:01 | 来源：建站知识
时间：2023-02-02 13:48:01 来源：建站知识
“网络协议”是指为完成特定的任务而制定的一套规则。网络协议通常用来表示数据传输中一组用于实现一个或多个OT模型级别的规则或规范。在通信时，网络协议定义了在通信时如何进行通信。今天海翎光电的小编就汇总了常见的网络协议，来一起看看。我们先回顾一下计算机网络五层模型，如下图。
协议——DNS协议、HTTP协议、HTTPS协议
- 传输层：负责两台主机之间的数据传输，将数据从发送端传输到接收端
协议——TCP协议、UDP协议
- 网络层：负责传输的地址管理和路由选择，在众多复杂的网络环境中确定一条合适的路径
协议——IP协议
- 数据链路层：负责设备之间数据帧的传送和识别，将网络层传递的数据报封装成帧，在处于同一个数据数据链路节点的两个设备之间传输
协议——ARP协议、MTU协议
- 物理层：负责光电信号的传递方式，实现相邻计算机节点之间比特流的透明传输
对于五层网络模型基本都是耳熟能详，但是有没有思考过，网络为什么要这样分层呢？海翎光电的小编接着分享。 最直接的回答就是
为了简化网络设计的复杂性，通信协议采用分层结构，各层之间既相互独立又相互协调工作，如此以来便达到的高效的目的。如同设计模式中对于设计一个复杂的程序时，尽量使程序各功能之间是解耦合的一样，对于复杂的网络设计，分层设计也是很明智的一种做法。 网络分层的最本质就是
每一层独立的完成一个任务而不必考虑自己任务之外的实现，而因为不同的任务因此就有了每一层所对应的不同设备。(实例到应用就是，物理层只需要关系0和1的光电信号如何传输，而对它所表达的内容毫不关心；再往上数据链路层只需要关心封装好的数据帧如何准确的送到对应的MAC地址的目的主机中，而不必关心数据报的具体内容和具体会通过何种方式光纤还是局域网…同理往上对于所有层)
应用层协议 应用层协议主要负责各个程序间的通信，发生网络传输一个数据时，先由应用层对数据按照对应的协议封装，然后交给下一层传输层，当经过一系列网络传输，数据达到接收端时，一层层的分用，最后一层再由应用层分用，最终得到数据。
DNS协议： DNS协议是一个应用层协议，建立在TCP和UDP的基础之上，使用默认端口为53，其默认通过UDP协议通信，但如果报文过大是则会切换成TCP协议。 域名系统 (DNS) 的作用是将人类可读的域名转换为机器可读的 IP 地址 (如，192.0.2.44)，本质是通过DNS域名和IP地址的对应关系转换，而这种对应关系则保存在DNS服务器中
域名的解析过程： 域名的解析工作大体上可以分为两个步骤：第一步客户端向本地DNS服务器发起一个DNS请求报文，报文里携带需要查询的域名，第二步本地DNS服务器向本机回应一个DNS响应报文，报文里携带查询域名所对应的IP地址
具体流程如下：| 1.在本地缓存中查询，如果有则返回对应IP，如果没有将请求发给DNS服务器2.当本地DNS服务器接收到查询后，先在服务器管理区域记录中查询，若没有再在服务器本地缓存中查询，如果没有将请求发送到根域名服务器3.根域名服务器负责解析请求的根域部分，然后将包含下一级域名信息的DNS服务地址返回给本地DNS服务器4.本地DNS服务器利用根域名服务器解析的地址访问下一级DNS服务器，得到再下一级域的DNS服务器地址5.按照上述递归方法逐级接近查询目标，最后在有目标域名的DNS服务器上找到相应的IP地址信息6.本地DNS服务器将最终查询到的IP返回给客户端，让客户端访问对应主机 |
HTTP协议 HTTP协议是一个简单的请求——响应协议，它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。 同其他应用层协议一样，是为了实现某一类具体应用的协议，并由某一运行在用户空间的应用程序来实现其功能。HTTP是一种协议规范，这种规范记录在文档上，为真正通过HTTP进行通信的HTTP的实现程序。HTTP是基于TCP协议，且面向连接的。典型的HTTP事务处理有如下的过程：
1.客户端与服务器建立连接；2.客户端向服务器提出请求；3.服务器接受请求，并根据请求返回相应的数据作为应答响应；4.客户端与服务器关闭连接。 HTTP协议报文格式 HTTP报文由从客户机到服务器的请求(Request)和从服务器到客户机的响应(Respone)构成
- 请求由请求行，请求头，请求体组成
- 请求行中包含请求方法、路径、版本号，请求头为多个key-value数据，请求正文包含一些请求的数据
- 响应由响应行，响应头，响应体组成
- 响应行中包含状态码，状态码描述，版本号，响应头为多个key-value数据，响应正文包含一些响应的数据
常见HTTP响应状态码汇总200 OK ：客户端请求成功
3XX系列| 301 Moved Permanently ：请求的资源以被永久的移动到新URL中，返回的Response中包含一个Location，浏览器会自动重定向到新URL，以后请求都会被新的URL替代302 Found ：与301类似，但请求的资源只是临时的被移动到新的URL中，下次请求客户端继续使用原URL307 Temporary Redirect ： 临时重定向，类似于302，使用GET请求重定向 |
4XX系列| 400 Bad Request ：客户端请求语法错误，服务器无法理解（在 ajax 请求后台数据时比较常见）401 Unauthorized ：请求要求用户的身份认证403 Forbidden ：服务器理解客户端请求，但是拒绝执行（一般用于用户级别为达到要求等等不支持访问）404 Not Found ： 服务器无法根据客户端请求找到对应资源405 Method Not Allowed ： 服务器不支持该方法 |
5XX系列| 500 Internal Server Error ：服务器内部错误，无法完成请求503 Service Unavailable ：由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中 |
HTTP协议的特点- 支持服务器/客户端模式
- 传输较快速，客户端向服务器发送请求，只需要传输请求方法和路径
- 灵活，HTTP允许传输任意类型的数据对象
- 无连接，每次连接只能处理一个请求，服务器处理完客户端请求，客户端收到响应后就断开连接
- 无状态，协议本身对事务处理没有记忆能力，如果后序连接需要之前发送的信息时就需要重传
HTTP1.0和HTTP1.1和HTTP2.0的区别：
HTTP1.0和HTTP1.1的区别：
| 长连接：HTTP1.0只支持浏览器与服务器的短连接，即每次请求都要重新建立连接，服务器无法记录每个历史请求，HTTP1.1支持长连接即在一次连接下，浏览器可以向服务器发送多次请求增加Host字段：HTTP1.0中认为每个服务器都绑定这唯一一个IP，所有发送的请求头URL中没有host信息，而HTTP1.1在请求和响应中都支持了host头域，且请求消息中如果没有Host头域会报告一个错误(400 Bad Request)缓存：HTTP1.1在1.0的基础上加入了一些cache的新特性，当缓存对象的Age超过Expire时变为stale对象，cache不需要直接抛弃stale对象，而是与源服务器进行重新激活（revalidation）。错误提示：HTTP1.0中定义了16个状态码，对错误或警告的提示不够具体。HTTP1.1引入了一个Warning头域，增加对错误或警告信息的描述，并且还新增了24个状态响应码，如409(Conflict)表示请求的资源与资源的当前状态发生冲突；410(Gone)表示服务器上的某个资源被永久性的删除 |
| 长连接：HTTP1.0只支持浏览器与服务器的短连接，即每次请求都要重新建立连接，服务器无法记录每个历史请求，HTTP1.1支持长连接即在一次连接下，浏览器可以向服务器发送多次请求增加Host字段：HTTP1.0中认为每个服务器都绑定这唯一一个IP，所有发送的请求头URL中没有host信息，而HTTP1.1在请求和响应中都支持了host头域，且请求消息中如果没有Host头域会报告一个错误(400 Bad Request)缓存：HTTP1.1在1.0的基础上加入了一些cache的新特性，当缓存对象的Age超过Expire时变为stale对象，cache不需要直接抛弃stale对象，而是与源服务器进行重新激活（revalidation）。错误提示：HTTP1.0中定义了16个状态码，对错误或警告的提示不够具体。HTTP1.1引入了一个Warning头域，增加对错误或警告信息的描述，并且还新增了24个状态响应码，如409(Conflict)表示请求的资源与资源的当前状态发生冲突；410(Gone)表示服务器上的某个资源被永久性的删除 |
| 长连接：HTTP1.0只支持浏览器与服务器的短连接，即每次请求都要重新建立连接，服务器无法记录每个历史请求，HTTP1.1支持长连接即在一次连接下，浏览器可以向服务器发送多次请求增加Host字段：HTTP1.0中认为每个服务器都绑定这唯一一个IP，所有发送的请求头URL中没有host信息，而HTTP1.1在请求和响应中都支持了host头域，且请求消息中如果没有Host头域会报告一个错误(400 Bad Request)缓存：HTTP1.1在1.0的基础上加入了一些cache的新特性，当缓存对象的Age超过Expire时变为stale对象，cache不需要直接抛弃stale对象，而是与源服务器进行重新激活（revalidation）。错误提示：HTTP1.0中定义了16个状态码，对错误或警告的提示不够具体。HTTP1.1引入了一个Warning头域，增加对错误或警告信息的描述，并且还新增了24个状态响应码，如409(Conflict)表示请求的资源与资源的当前状态发生冲突；410(Gone)表示服务器上的某个资源被永久性的删除 |
| 长连接：HTTP1.0只支持浏览器与服务器的短连接，即每次请求都要重新建立连接，服务器无法记录每个历史请求，HTTP1.1支持长连接即在一次连接下，浏览器可以向服务器发送多次请求增加Host字段：HTTP1.0中认为每个服务器都绑定这唯一一个IP，所有发送的请求头URL中没有host信息，而HTTP1.1在请求和响应中都支持了host头域，且请求消息中如果没有Host头域会报告一个错误(400 Bad Request)缓存：HTTP1.1在1.0的基础上加入了一些cache的新特性，当缓存对象的Age超过Expire时变为stale对象，cache不需要直接抛弃stale对象，而是与源服务器进行重新激活（revalidation）。错误提示：HTTP1.0中定义了16个状态码，对错误或警告的提示不够具体。HTTP1.1引入了一个Warning头域，增加对错误或警告信息的描述，并且还新增了24个状态响应码，如409(Conflict)表示请求的资源与资源的当前状态发生冲突；410(Gone)表示服务器上的某个资源被永久性的删除 |
HTTP1.X和HTTP2.0的区别| 增加二进制格式解析：HTTP1.X解析基于文本，而文本格式本身就具有多样性，很多场景下不方便，而引入二进制后，只有0和1组合，使解析更加方便也增强了健壮性多路复用：即每个request都是是用作连接共享机制的，每个request都对应一个id，使一个连接可以有多个请求，再根据id将request归属到不同的服务端请求里header压缩：HTTP1.X中，每次传输都要写点header头，占用了大量数据，因此HTTP2.0在客户端和服务端各保存了一份header fields表，每次传输时只需传输header的更新信息，将header fields表更新即可实现header传输服务端推送：HTTP2.0也添加了server push功能 |
| 增加二进制格式解析：HTTP1.X解析基于文本，而文本格式本身就具有多样性，很多场景下不方便，而引入二进制后，只有0和1组合，使解析更加方便也增强了健壮性多路复用：即每个request都是是用作连接共享机制的，每个request都对应一个id，使一个连接可以有多个请求，再根据id将request归属到不同的服务端请求里header压缩：HTTP1.X中，每次传输都要写点header头，占用了大量数据，因此HTTP2.0在客户端和服务端各保存了一份header fields表，每次传输时只需传输header的更新信息，将header fields表更新即可实现header传输服务端推送：HTTP2.0也添加了server push功能 |
| 增加二进制格式解析：HTTP1.X解析基于文本，而文本格式本身就具有多样性，很多场景下不方便，而引入二进制后，只有0和1组合，使解析更加方便也增强了健壮性多路复用：即每个request都是是用作连接共享机制的，每个request都对应一个id，使一个连接可以有多个请求，再根据id将request归属到不同的服务端请求里header压缩：HTTP1.X中，每次传输都要写点header头，占用了大量数据，因此HTTP2.0在客户端和服务端各保存了一份header fields表，每次传输时只需传输header的更新信息，将header fields表更新即可实现header传输服务端推送：HTTP2.0也添加了server push功能 |
| 增加二进制格式解析：HTTP1.X解析基于文本，而文本格式本身就具有多样性，很多场景下不方便，而引入二进制后，只有0和1组合，使解析更加方便也增强了健壮性多路复用：即每个request都是是用作连接共享机制的，每个request都对应一个id，使一个连接可以有多个请求，再根据id将request归属到不同的服务端请求里header压缩：HTTP1.X中，每次传输都要写点header头，占用了大量数据，因此HTTP2.0在客户端和服务端各保存了一份header fields表，每次传输时只需传输header的更新信息，将header fields表更新即可实现header传输服务端推送：HTTP2.0也添加了server push功能 |
HTTPS协议 HTTPS同样作为应用层协议，可以说它是HTTP的升级版，增加了传输数据的安全性，HTTPS协议是在HTTP的基础上增加了一个SSL外壳，HTTPS运行在SSL上，SSL运行在TCP上，对数据的加密工作就是在SSL上完成的
其保证安全性的做法是通过证书验证和对信息混合加密的方式
混合加密技术：| 混合加密技术：结合对称加密与非对称加密服务端生成私钥，再通过私钥生成公钥，然后将公钥放在证书中颁发给客户端使用公钥和私钥以非对称方式加密生成密钥客户端接下来的传输数据中，都会用密钥以对称方式对信息加密，再传输给服务端 |
对于，上述提到的公钥和私钥，我们规定用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开 所以HTTPS传输数据是用被密钥加密的密文和用公钥加密的私钥来保证数据安全的
| HTTPS加密，只用对称加密可以吗？ 不行！无法保证安全性，因为只用对称加密即只用密钥对数据加密传输的话，如果传输途中，信息被第三方劫持，获取到密钥，那接下来的传输，第三方都可以通过密钥对数据解密从而得到原始数据。 |
| HTTPS加密，只用非对称加密可以吗？两次呢？ 同样不行，如果只用非对称加密。客户端每次传输数据用公钥加密，服务端再用私钥解密这一方向看似安全，但当服务端发送数据用私钥加密，客户端收到用公钥解密时，第三方劫持到信息，但可能在此之前就获得公钥，因为首次服务端向客户端发送公钥是明文传输的。 而换个角度如果使用两次非对称加密，即两组公钥，两组私钥，客户端服务端各持一组，理论上可以达到安全，但实际HTTPS并未采用，因为非对称加密耗时十分大 |
证书： 单有混合加密技术，看似已经保证了传输的安全性，实则还是有漏洞，问题就在于
服务器根本无法识别发送过来的公钥是否是自己的，如此以来在第三方劫持到数据后，自行再定义一个公钥B，并将公钥B传回给客服端，此时客户端就会利用该公钥B重新加密数据然后发送，此时第三方就可以通过自己的公钥B解密得到原始数据了。 证书就解决了这一问题，指定颁发的为CA机构，当网站使用HTTPS时，会向CA机构申请一个数字证书，证书中可以存放公钥、数据等信息，由此以来，服务端就可以通过证书来向客户端证明正确的公钥是哪一个，以此保证安全。 而对于证书，还有一些自己的放篡改机制，防止第三方获取到使用
在线咨询
