理解网络应用层：协议、HTTP详解与HTTPS安全机制-优快云博客

本文链接：https://blog.youkuaiyun.com/clyss1234/article/details/120191167

本文详细介绍了网络应用层的概念，包括Socket套接字、进程寻址和应用层协议。重点讲解了HTTP协议，分析了HTTP1.0、HTTP1.1和HTTP2.0的特点与区别，如非持久性连接、持久性连接、头部字段和请求方法。此外，文章深入探讨了HTTPS协议，阐述了其加密机制、身份认证和完整性保护。最后，提到了Cookie技术在保持HTTP状态中的作用以及与Session的区别。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

1. 网络应用进程通信

进程：主机上运行的程序
同一主机上进程通信：进程间通信机制、操作系统提供
不同主机上进程通信：消息交换（报文交换）

1.1 Socket套接字

进程间通信利用Socket发送/接收消息实现

1.2 进程寻址

通过IP地址进程主机寻址，为主机上每一个需要通信的进程分配一个端口号，通过端口号进行进程寻址

进程的标识符：IP地址 + 端口号

+++

2. 应用层协议

通过应用层协议规定消息交换的模式、格式等。

协议分类：

公开协议：由RFC（Request For Comments）定义，如HTTP，SMTP等
私有协议：多数P2P文件共享应用

2.1 应用层协议的内容

消息的内容：请求消息、响应消息
消息的语法格式：消息中有哪些字段、每个字段如何描述
字段的语义：字段中信息的含义
规则：进程何时发送/响应消息

+++

3. 网络应用需求

3.1 对传输层服务的要求

3.3.1 数据丢失/可靠性

某些网络应用能容忍一定的数据丢失：网络电话
某些网络应用要求100%可靠的数据传输：文件传输，telnet

3.3.2 时间延迟

网络游戏要求网络延迟足够低

3.3.3 带宽

某些应用只有在带宽达到最低要求时才有效，如网络视频

+++

4. HTTP协议

HTTP优点：

**灵活可扩展：**http非常灵活，在报文中没有做过多的限制，只要按照其规则可以自己定义字段，在传输中也不仅仅限于txt文本格式，也可以传输图片，视频，压缩包等等任意数据。
**可靠性：**因为http是基于tcp/ip传输的，因为tcp/ip是一个连接传输协议，因此是是一个可靠（可靠不是安全）的传输。
**无状态：**因为没有任何记录。可以减轻服务器的负担，能够更多的cpu和内存用来对外提供服务。因为无状态，对服务器无要求，因此可以组成集群。

HTTP缺点：

**无状态：**无状态也就导致每次请求都要确认身份，这将带来不必要的操作负担和资源消耗。（利用cookie技术解决此弊端）
**明文传输：**HTTP采用的是明文进行信息传递，将会给信息被破译和泄露。（HTTPS很好的解决了这点）
请求-问答模式： 此模式下只有一方发起请求，另一方才会相应，这涉及到频繁的连接断开操作。同时发起多个请求也会导致**“队头阻塞”**问题的出现。

4.1 非持久性连接与持久性连接分析

从HTTP1.1开始支持持久性连接（长链接）

**RTT：**从客户端发送一个很小的数据包到服务器并返回所经历的时间。

非持久性连接：Total = RTT (发起建立TCP连接) + RTT（发送HTTP请求消息） + 文件发送时间

获取每个对象需要2个RTT，n个对线需要2n个RTT
操作系统需要为每个TCP连接开销资源

持久性连接：

发送响应后，服务器保持TCP连接的打开，后续的HTTP消息可以通过此连接继续发送
无流水的持久性连接：客户端只有收到前一个响应后才发送新的请求，获取n个对象需要n+1个RTT
流水机制的持久性连接（HTTP1.1默认）：客户端只要遇到一个引用对象就尽快发送请求，获取n个对象需要2个RTT

4.2 HTTP请求格式

HTTP协议有两类消息：请求消息、响应消息

请求报文格式：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hXqEVukm-1631114054948)(…/…/images/计网应用层HTTP请求报文格式.PNG)]

请求方法：GET/POST/HEAD/PUT/DELETE/connec/trace/options 8种
URL：请求地址
协议版本：HTTP1.1
头部字段等等

响应报文格式：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Zcl2z0s8-1631114054952)(…/…/images/计网应用层HTTP响应报文格式.PNG)]

4.2.2 请求方法

客户端发送的 请求报文 第一行为请求行，包含了方法字段。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dYfrG1Yj-1631114054954)(…/…/images/计网应用层Http请求方法.PNG)]

get和post的区别

从功能上讲：GET一般用来从服务器上获取资源，POST一般用来更新服务器上的资源；
从请求参数的形式来看：GET请求的数据会附在URL之后（？分割URL和传输数据，&分割参数），而POST请求会把提交的数据放在请求报文的请求体中
就安全性而言：POST的安全性要比GET的安全性高
就请求的大小而言：GET请求的长度受限于浏览器或服务器对URL长度的限制，允许发送的数据量比较小，而POST请求则是没有大小限制的。（一般GET传输数据限制在2kb，而Post没有限制）
就服务角度上来说：要求GET是幂等的，即读取同一个资源，总是得到相同的数据，而POST不是幂等的，因为每次请求对资源的改变并不是相同的；
在浏览器发送非简单请求产生跨域的时候，POST会发两次TCP请求，而GET只会发一次

4.2.3 响应状态码

服务器返回的 响应报文 中第一行为状态行，包含了状态码以及原因短语，用来告知客户端请求的结果。

状态码	类别	含义
1XX	Informational（信息性状态码）	接收的请求正在处理
2XX	Success（成功状态码）	请求正常处理完毕
3XX	Redirection（重定向状态码）	需要进行附加操作以完成请求
4XX	Client Error（客户端错误状态码）	服务器无法处理请求
5XX	Server Error（服务器错误状态码）	服务器处理请求出错

200 正常
301 永久重定向
302 暂时重定向
404 找不到资源
502 服务器内部错误

4.2.4 首部字段

有 4 种类型的首部字段：通用首部字段、请求首部字段、响应首部字段和实体首部字段。

各种首部字段及其含义如下（不需要全记，仅供查阅）：

通用首部字段：

首部字段名	说明
Cache-Control	控制缓存的行为
Connection	控制不再转发给代理的首部字段、管理持久连接
Date	创建报文的日期时间
Pragma	报文指令
Trailer	报文末端的首部一览
Transfer-Encoding	指定报文主体的传输编码方式
Upgrade	升级为其他协议
Via	代理服务器的相关信息
Warning	错误通知

请求首部字段：

首部字段名	说明
Accept	用户代理可处理的媒体类型
Accept-Charset	优先的字符集
Accept-Encoding	优先的内容编码
Accept-Language	优先的语言（自然语言）
Authorization	Web 认证信息
Expect	期待服务器的特定行为
From	用户的电子邮箱地址
Host	请求资源所在服务器
If-Match	比较实体标记（ETag）
If-Modifified-Since	比较资源的更新时间
If-None-Match	比较实体标记（与 If-Match 相反）
If-Range	资源未更新时发送实体 Byte 的范围请求
If-Unmodifified-Since	比较资源的更新时间（与 If-Modifified-Since 相反）
Max-Forwards	最大传输逐跳数
Proxy-Authorization	代理服务器要求客户端的认证信息
Range	实体的字节范围请求
Referer	对请求中 URI 的原始获取方
TE	传输编码的优先级
User-Agent	HTTP 客户端程序的信息

响应首部字段：

首部字段名	说明
Accept-Ranges	是否接受字节范围请求
Age	推算资源创建经过时间
ETag	资源的匹配信息
Location	令客户端重定向至指定 URI
Proxy-Authenticate	代理服务器对客户端的认证信息
Retry-After	对再次发起请求的时机要求
Server	HTTP 服务器的安装信息
Vary	代理服务器缓存的管理信息
WWW-Authenticate	服务器对客户端的认证信息

实体首部字段：

首部字段名	说明
Allow	资源可支持的 HTTP 方法
Content-Encoding	实体主体适用的编码方式
Content-Language	实体主体的自然语言
Content-Length	实体主体的大小
Content-Location	替代对应资源的 URI
Content-MD5	实体主体的报文摘要
Content-Range	实体主体的位置范围
Content-Type	实体主体的媒体类型
Expires	实体主体过期的日期时间
Last-Modifified	资源的最后修改日期时间

4.3 比较HTTP1.0、HTTP1.1、HTTP2.0

4.3.1 HTTP1.0

HTTP1.0最早在网页中使用是在1996年，那个时候只是使用一些较为简单的网页上和网络请求上，而HTTP1.1则在1999年才开始广泛应用于现在的各大浏览器网络请求中，同时HTTP1.1也是当前使用最为广泛的HTTP协议。

4.3.2 HTTP1.1

长连接，HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。
缓存处理：在HTTP1.0中主要使用header里的If-Modified-Since，Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since， If-Match， If-None-Match等更多可供选择的缓存头来控制缓存策略
带宽优化及网络连接的使用：HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
错误通知的管理，在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
Host头处理，在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。

4.3.3 HTTP2.0

新的二进制格式（Binary Format）：HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
多路复用（MultiPlexing）：即连接共享，即每一个TCP连接中承载了多个双向流通的流，每一个流都有一个独一无二的标识和优先级，流可以交错传输，再在接收端组装成完成数据。多路复用避免了建立大量TCP连接，也避免了拥塞和慢启动，更有效的利用了TCP连接。
header压缩：对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0维护一个字典，差量更新HTTP头部，来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。
服务端推送（server push）：服务端推送能把客户端所需要的资源伴随着index.html一起发送到客户端，省去了客户端重复请求的步骤。
**请求优先级：**可以设置传送的数据帧的优先级，让服务端先处理重要资源，优化用户体验。

2.2 HTTPS

HTTPS （全称：Hyper Text Transfer Protocol over SecureSocket Layer），是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性。

可以认为http + 加密 + 认证 + 完整性保护 = https。

HTTPS 存在不同于 HTTP 的默认端口及一个加密/身份验证层（在 HTTP与 TCP 之间）。这个系统提供了身份验证与加密通讯方法。它被广泛用于万维网上安全敏感的通讯，例如交易支付等方面。

2.2.1 为什么提出HTTPS ?

**HTTP是明文传输的，**因此网络攻击者可以通过网络嗅探，来抓取一些关键信息，比如账户密码手机号等等，造成信息泄露。

另外,HTTP在传输客户端请求和服务端响应时, 唯一的数据完整性检验就是在报文头部包含了本次传输数据的长度, 而对内容是否被篡改不作确认。因此攻击者可以轻易的发动中间人攻击（有请求重放），修改客户端和服务端传输的数据, 甚至在传输数据中插入恶意代码, 导致客户端被引导至恶意网站被植入木马。

因此，为了改进上述目的，HTTPS进行了如下设计：

数据保密性：保证数据内容在传输的过程中不会被第三方查看。就像快递员传递包裹一样，都进行了封装，别人无法获知里面装了什么
数据完整性：及时发现被第三方篡改的传输内容。就像快递员虽然不知道包裹里装了什么东西，但他有可能中途掉包，数据完整性就是指如果被掉包，我们能轻松发现并拒收
身份校验安全性：保证数据到达用户期望的目的地。就像我们邮寄包裹时，虽然是一个封装好的未掉包的包裹，但必须确定这个包裹不会送错地方，通过身份校验来确保送对了地方

2.2.2 加密机制

HTTPS 采用混合的加密机制，使用非对称密钥加密用于传输对称密钥来保证传输过程的安全性，之后使用对称密钥加密进行通信来保证通信过程的效率。（下图中的 Session Key 就是对称密钥）

2.2.3 身份认证机制

通过使用证书来对通信方进行认证。

数字证书认证机构（CA，Certifificate Authority）是客户端与服务器双方都可信赖的第三方机构。

服务器的运营人员向 CA 提出公开密钥的申请，CA 在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公开密钥证书后绑定在一起。

进行 HTTPS 通信时，服务器会把证书发送给客户端。客户端取得其中的公开密钥之后，先使用数字签名进行验证，如果验证通过，就可以开始通信了。

2.2.4 完整性保护

SSL 提供报文摘要功能来进行完整性保护。

HTTP 也提供了 MD5 报文摘要功能，但不是安全的。例如报文内容被篡改之后，同时重新计算 MD5 的值，通信接收方是无法意识到发生了篡改。

HTTPS 的报文摘要功能之所以安全，是因为它结合了加密和认证这两个操作。试想一下，加密之后的报文，遭到篡改之后，也很难重新计算报文摘要，因为无法轻易获取明文。

2.2.5 HTTPS建立连接过程的过程

首先是TCP三次握手，
发送客户端支持的加密协议及版本，如SSL，TLS等
服务器端从中筛选出合适的加密协议，服务端返回公钥和证书到客户端
客户端用证书中的签名hash算法取握手信息的hash值（报文摘要），然后用生成的随机数将[握手信息和握手信息的hash值]进行加密，然后用服务器端的公钥将随机数进行加密后，一起发送给服务端。其中计算握手信息的hash值，目的是为了保证传回到服务端的握手信息没有被篡改。
服务端收到客户端传回来的用随机数加密的信息后，先用私钥解密随机数，然后用解密得到的随机数解密握手信息，获取握手信息和握手信息的hash值，计算自己发送的握手信息的hash值，与客户端传回来的进行对比验证。如果验证无误，同样使用随机字符串加密握手信息和握手信息hash值发回给到客户端。
客户端收到服务端发送过来的握手信息后，用开始自己生成的随机数进行解密，验证被随机数加密的握手信息和握手信息hash值。验证无误后，握手过程就完成了，从此服务端和客户端就开始用那串随机数进行对称加密通信了（常用的对称加密算法有AES）。

4.4.2 HTTPS的认证机制

通过使用证书来对通信方进行认证。

数字证书认证机构（CA，Certifificate Authority）是客户端与服务器双方都可信赖的第三方机构。

进行 HTTPS 通信时，服务器会把证书发送给客户端。客户端取得其中的公开密钥之后，先使用数字签名进行验证，如果验证通过，就可以开始通信了。

4.4.3 HTTPS的完整性保护

SSL 提供报文摘要功能来进行完整性保护。

HTTP 也提供了 MD5 报文摘要功能，但不是安全的。例如报文内容被篡改之后，同时重新计算 MD5 的值，通信接收方是无法意识到发生了篡改。

+++

5. Cookie技术

5.1 HTTP怎么保持状态?

HTTP 是一种不保存状态，即无状态（stateless）协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们保存用户状态呢？Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了（一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个 Session）。

在服务端保存 Session 的方法很多，最常用的就是内存和数据库(比如是使用内存数据库 redis 保存)。既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？大部分情况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。

5.2 Session和Cookie

会话（Session）跟踪是Web程序中常用的技术，用来跟踪用户的整个会话。常用的会话跟踪技术是Cookie与Session。Cookie通过在客户端记录信息确定用户身份，Session通过在服务器端记录信息确定用户身份。

本章将系统地讲述Cookie与Session机制，并比较说明什么时候不能用Cookie，什么时候不能用Session。

Cookie机制

由于HTTP是一种无状态的协议，服务器单从网络连接上无从知道客户身份。怎么办呢？就给客户端们颁发一个通行证吧，每人一个，无论谁访问都必须携带自己通行证。这样服务器就能从通行证上确认客户身份了。这就是Cookie的工作原理。

Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。

Session机制

除了使用Cookie，Web应用程序中还经常使用Session来记录客户端状态。Session是服务器端使用的一种记录客户端状态的机制，使用上比Cookie简单一些，相应的也增加了服务器的存储压力。

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

如果说Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话，那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案，客户来访的时候只需要查询客户档案表就可以了。

1.3.3 Cookie和Session的区别

实现机制：Session的实现常常依赖于Cookie机制，通过Cookie机制回传SessionID；
大小限制：Cookie有大小限制并且浏览器对每个站点也有cookie的个数限制，Session没有大小限制，理论上只与服务器的内存大小有关；
安全性：Cookie存在安全隐患，通过拦截或本地文件找得到cookie后可以进行攻击，而Session由于保存在服务器端，相对更加安全；
服务器资源消耗：Session是保存在服务器端上会存在一段时间才会消失，如果session过多会增加服务器的压力。

+++

6. Web缓存/代理服务器技术

指在不访问服务器的前提下满足客户端的HTTP请求

为什么要发明Web缓存/代理服务器技术？

缩短客户请求的响应时间
减少机构/组织的流量
在大范围内实现有效的内容分发（CDN）

代理过程：

用户设定浏览器通过缓存进行web访问
浏览器向缓存/代理服务器发送所有的HTTP请求
- 如果请求对象在缓存中，返回该对象
- 否则代理服务器向原始服务器发送HTTP请求，获取对象，返回到客户端并保存该对象

条件性GET方法：

浏览器向缓存请求数据
缓存在HTTP请求消息中声明所支持版本的日期， $i f - m o d i f i e d - s i n c e : < d a t e >$ ，并发送到原始服务器
原始服务器如果在该日期后更改请求对象，则响应消息中包含请求对象，否则返回304

+++

7. DNS协议

7.1 DNS服务概述

为了标识世界上数以亿计的主机，因特网使用IP地址进行标记主机，而为了便于记忆，识别主机采用了另一套识别方式——域名系统，但在底层标识的还是IP地址，那么域名与IP地址如何映射呢？ DNS域名解析系统因此而生。

域名系统 / 服务（Domain Name System，DNS，DNS协议）是一种分布式网络目录服务，主要用于域名与 IP 地址的相互转换，以及控制因特网的电子邮件的发送。

域名，又称网域，是由一串用点分隔的名字组成的Internet上某一台计算机或计算机组的名称，用于在数据传输时对计算机的定位标识（有时也指地理位置）。

DNS服务功能：

域名向IP地址的翻译
- 域名的正向解析 – A记录
  
  将主机域名转换为对应的IP地址，以便网络程序能够主动通过主机域名访问到对应的服务器主机
- 域名的反向解析 – PTR记录
  
  将主机的IP地址转换为对应的域名，以便网络程序能够通过IP地址查询到相应域名
主机别名
邮件服务器别名
负载均衡：Web服务器（提供域名对多个IP地址的映射，以轮询方式实现）

7.2 DNS的结构

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bLKMHmP8-1631114054959)(…/…/images/计算机网络之DNS服务架构.PNG)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uPADs25z-1631114054966)(…/…/images/计算机网络之DNS结构.PNG)]

全球只有13台根域名服务器，其中10台在美国，包括1台主根和9台辅根，其于3台辅根服务器分别在英国、瑞典和日本。

只有13台的说法来源

这是源于DNS协议在不使用EDNS0和TCP协议时，通过UDP协议传输的DNS消息最大长度需要限制在512字节（不包括IP头部、UDP头部），超出部分要被截断。有了最大长度限制后，一个UDP协议传输的DNS响应能够返回的资源记录数量就是有限的。

7.3 DNS的工作原理

调用系统缓存需要跨进程，消耗大，所以就有浏览器DNS缓存。浏览器DNS查找顺序一般是这样的：浏览器缓存→系统缓存→路由器缓存→ISP DNS 缓存→递归搜索。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OKHfZetT-1631114054967)(…/…/images/计算机网络之DNS工作原理.PNG)]

当DNS客户机需要在程序中使用名称时，它会查询DNS服务器来解析该名称。客户机发送的每条查询信息包括三条信息：包括：指定的DNS域名，指定的查询类型，DNS域名的指定类别。基于UDP服务，端口53.

该应用一般不直接为用户使用，而是为其他应用服务，如HTTP，SMTP等在其中需要完成主机名到IP地址的转换。

名词解释：

**根域：**就是顶级域名之后省略的 ‘.’，就是根；全世界只要一台主根服务器，其余都是辅根服务器

**一级域名<顶级域|国家域# ** ： com/edu/gov/org/cc/io | cn uk us ru

**域名机构：**就是在网上售卖域名的机构
**递归查询C-S：**一次访问得到结果，一般本地服务器查询是递归查询；
**迭代查询S-S：**多次访问得到结果，本地 DNS 服务器向其他域名服务器请求的过程是迭代查询的过程。

备注：关于本机hosts文件

一般来说本地就有域名与IP的映射文件，在windows中，C:\Windows\System32\drivers\etc\hosts；在linux中， /etc/hosts文件中。

此文件能够提供主机名或域名的解析，且速度较DNS更快，但是前提是知道主机名对应域名，并且需要手动维护。计算机优先寻找hosts文件。

如果本地域名解析服务器无法解析域名时，访问根域名服务器。

DNS缓存：

只要域名解析服务器获得域名——ip映射，即缓存这一映射。但是缓存存在失效时限，并且本地域名服务器一般会缓存顶级域名服务器的映射，所以根域名服务器不经常被访问

正向解析

将主机域名转换为对应的IP地址，以便网络程序能够主动通过主机域名访问到对应的服务器主机。

浏览器先检查自身缓存中有没有被解析过的这个域名对应的ip地址，如果有，解析结束
如果浏览器未命中，浏览器会检查操作系统缓存中有没有对应的已解析过的结果。一般保持在hosts文件中。所以有的攻击者修改你的hosts文件从而将域名解析到其他ip地址上，这就是域名劫持。
如果操作系统还没有，也可能会去路由器中找。
如果至此还没有命中域名，才会真正的请求本地域名服务器（LDNS）来解析这个域名，也就是ISP DNS。如果此时还未找到，则会采用两种方式进行查询，递归查询（默认ISP DNS帮你查）和迭代（DNS客户端自己查）。
查询方式一般是先找到根域名服务器，然后一步一步往下查。

反向解析

反向解析是指实现从IP地址到域名的映射，

DNS服务器里面有两个区域，即“正向查找区域”和“反向查找区域”，正向查找区域就是通常所说的域名解析，反向查找区域即是IP反向解析，它得到作用是通过查找IP地址的PTR记录来得到该IP地址指向的域名。要成功得到域名就必须有该IP地址的PTR记录。

IP反向解析主要应用到邮件服务器中来阻拦垃圾邮件。多数垃圾邮件发送者使用动态分配或者没有注册域名的IP地址来发送垃圾邮件，以避免追踪，使用域名反向解析后，就可以大大降低垃圾邮件的数量。（根据IP查询域名，判断域名是否正确，不正确则丢弃）

**由于在域名系统中，一个IP地址可以对应多个域名，因此从IP出发去找域名，理论上应该遍历整个域名树，但是这在internet上是不现实的。**为了完成逆向域名解析，系统提供一个特别域，该特别域称为逆向解析域in-addr.arpa.这样欲解析的IP地址就会被表达成一种像域名一样的可显示串形式，后缀以逆向解析域域名“in-addr.arpa”结尾。这样就可以根据IP地址来查找域名了，因此逆向解析的很大部分可以纳入正向解析中。

7.4. DNS记录

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-06JfEOgQ-1631114054969)(…/…/images/计算机网络之DNS记录.PNG)]

+++

8. SSH协议

SSH，全称为Secure Shell， SSH 为建立在应用层基础上的安全外壳协议。
SSH是由客户端和服务端的软件组成的，有两个不兼容的版本分别是：1.x和2.x。用SSH 2.x的客户程序是不能连接到SSH 1.x的服务程序上去的。OpenSSH 2.x同时支持SSH 1.x和2.x。
SSH在服务端是一个守护进程(daemon)，他在后台运行并响应来自客户端的连接请求。服务端一般是sshd进程，提供了对远程连接的处理，一般包括公共密钥认证、密钥交换、对称密钥加密和非安全连接。
客户端包含ssh程序以及像scp（远程拷贝）、slogin（远程登陆）、sftp（安全文件传输）等其他的应用程序

SSH协议框架中设计了大量可扩展的冗余能力，比如用户自定义算法、客户自定义密钥规则、高层扩展功能性应用协议。
SSH采用面向连接的TCP协议传输应用22号端口安全系数较高。

9. Socket编程

10. QUIC协议

QUIC(Quick UDP Internet Connection)是Google公司提出的基于UDP的高效可靠协议，他和HTTP一样同样是应用层协议。

为什么高效呢？是因为其基于无连接的UDP而不是基于TCP去实现的。

为什么可靠呢？因为其模仿TCP协议的可靠性，在应用层上做了可靠性的保证。

10.1 QUIC协议的优点

我们知道，传统的TCP协议在数据传输前需要建立连接，三次握手机制实际上有1RTT（Rount-Trip Time，往返时延），而HTTPS还在在TCP的基础上使用SSL/TLS的额外握手，就会有3次RTT，但QUIC就不一样了。

0RTT的连接建立：
更加出色的拥塞控制：TCP中只有Reno算法（慢开始，拥塞避免，快重传，快恢复），在QUIC中使用了更为优秀的机制来控制拥塞控制，它可以针对不同业务，不同网络制式，甚至不同的RTT，使用不同的拥塞控制算法。
更好的重传机制：在QUIC中序列号都是递增的，并且通过offset来确定在包中的真实位置，这样就可以得到更为准确的RTT，从而设置更精准的RTO
没有队头阻塞的多路复用：熟悉HTTP2.0的同学应该知道在2.0中如果访问同一个服务器只会有一个TCP连接，所有的请求都会走这条连接，而每个请求在Connection中叫做Stream，一个Connection中可以有多个Stream，这里有个问题是在TCP中的包是保证时序的，如果某个Stream丢了一个包，他同时也会影响其他的Stream，在更为严重的时候反而多路复用还不如HTTP1.1的多个链接。而在QUIC中，因为底层是基于UDP，UDP不需要保证包的时序，只会在接收包的时候对包进行重组，所以不会存在这个问题。